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
