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

Robert Moskowitz <rgm@htt-consult.com> Wed, 09 July 2014 20:40 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C741A0015 for <hipsec@ietfa.amsl.com>; Wed, 9 Jul 2014 13:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF3uzCi_f90w for <hipsec@ietfa.amsl.com>; Wed, 9 Jul 2014 13:40:07 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7A1A0011 for <hipsec@ietf.org>; Wed, 9 Jul 2014 13:40:07 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5652163440; Wed, 9 Jul 2014 20:40:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydhlvaqeELD4; Wed, 9 Jul 2014 16:39:54 -0400 (EDT)
Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1E5B66343C; Wed, 9 Jul 2014 16:39:54 -0400 (EDT)
Message-ID: <53BDA896.3080104@htt-consult.com>
Date: Wed, 09 Jul 2014 16:39:50 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tom Henderson <tomh@tomh.org>
References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <53BBE66D.2080807@htt-consult.com> <53BD5652.300@htt-consult.com> <53BDA59C.4000004@tomh.org>
In-Reply-To: <53BDA59C.4000004@tomh.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/f7f0EsCd-wbyQF_mh63Ui-MHeuY
Cc: hipsec@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2014 20:40:09 -0000

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
>