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

[Paul Lambert <[e-mail]>]

³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" <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/hipsec