Sent to the HIPSEC list from my HIPSEC user:
The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed
payload, and in many use cases, the Initiator has pre-deteremined the
Responder's HI and HIT so it can check the SIG before processing the ESP
TRANSFORM parameters. In sensornets where the Initiator cannot
pre-determine the Responder's (typically some sensor controller) HI and
HIT, then it is a concern.
Further eventhough I1 is unsigned, the Initiator 'knows' what suites it
wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC
back, it MUST NOT complete the exchange. If in the R1 it gets NULL,
CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC.
If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST
NOT complete the exchange.
The HIP design team spent a long time working out downgrade attacks. I
have to thank Tobias Heer and Miika Komu for a couple day design when I
was visiting HIIT in Helsinki.
NULL, CMAC, or GMAC should only be configured as allowable suites when
they are needed for debug, or the situation requires auth-only. And I
should point out there are devices and situations where auth-only is the
case, so those suites are needed. IMNSHO.
In the worst case scenario, we could cover with text that clearifies the
privacy versus auth-only suites with requirements that these suites not
be mixed in an exchange and if one is expected, the other not accepted.
Of course 'servers' (I say that parenthetically, as HIP is a peer
exchange) MIGHT need to support both classes of customers and thus need
to respond based on the unprotectable I1 packet. Even there, the
Initiator still can bid back if its I1 was altered by a MiTM.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
