³SHOULD² is a good improvement for those of us that may not be as fond of NULL encryption.
On 7/9/14, 1:39 PM, "Robert Moskowitz" <[email protected]> wrote: >I am comfortable with these changes. > >On 07/09/2014 04:27 PM, Tom Henderson wrote: >> On 07/09/2014 07:48 AM, Robert Moskowitz wrote: >>> 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. >>> >> >> I would be fine with lessening this MUST to SHOULD. We probably >> should do the same for RFC 5201 (the HIP CIPHER). >> >> Below are some suggested edits along the lines of your suggestions >> above; any comments or concerns? >> >> In Section 5.2.8 of RFC 5201-bis: >> >> OLD TEXT: >> >> Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is >> included for testing purposes. >> >> NEW TEXT: >> >> Mandatory implementation: AES-128-CBC. Implementors SHOULD support >> NULL for testing/debugging purposes, but MUST NOT offer or accept this >> value unless explicitly configured for testing/debugging of the HIP >> protocol. >> >> In Section 3.3.5 of RFC 5202-bis: >> >> OLD TEXT: >> >> In addition to AES-128-CBC, all implementations MUST implement the >> ESP NULL encryption algorithm. When the ESP NULL encryption is used, >> it MUST be used together with SHA-256 authentication as specified in >> Section 5.1.2 >> >> NEW TEXT: >> >> In addition to AES-128-CBC, all implementations SHOULD implement the >> ESP NULL encryption algorithm. When the ESP NULL encryption is used, >> it MUST be used together with SHA-256 authentication as specified in >> Section 5.1.2. >> >> When an authentication-only suite is used (NULL, >> AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT >> be accepted if offered by the peer unless the local policy >> configuration regarding the peer host is explicitly set to allow an >> authentication-only mode. This is to prevent sessions from being >> downgraded to an authentication-only mode when one side's policy >> requests privacy for the session. >> >> In Section 5.1.2 of RFC 5202-bis: >> >> OLD TEXT: >> >> Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL >> with HMAC-SHA-256. >> >> NEW TEXT: >> >> Mandatory implementation: AES-128-CBC with HMAC-SHA-256. NULL with >> HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5). >> >> >> >> - Tom >> > >_______________________________________________ >Hipsec mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
