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 >
- [Hipsec] NULL encryption mode in RFC 5202-bis Tom Henderson
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Miika Komu
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Stephen Farrell
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Stephen Farrell
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Tom Henderson
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Robert Moskowitz
- Re: [Hipsec] NULL encryption mode in RFC 5202-bis Paul Lambert
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… James Cloos
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… James Cloos
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Paul Lambert
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Henry B Hotz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Michael Richardson
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Edward Lopez
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Robert Moskowitz
- Re: [Hipsec] [saag] NULL encryption mode in RFC 5… Ted Lemon