Re: [Hipsec] NULL encryption mode in RFC 5202-bis

[Robert Moskowitz <[e-mail]>]

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.