Re: [Hipsec] NULL encryption mode in RFC 5202-bis
Paul Lambert <paul@marvell.com> Wed, 09 July 2014 20:43 UTC
Return-Path: <paul@marvell.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 C3AEA1A0011 for <hipsec@ietfa.amsl.com>; Wed, 9 Jul 2014 13:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 dZBCZu_W0bWP for <hipsec@ietfa.amsl.com>; Wed, 9 Jul 2014 13:43:12 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F419F1A0015 for <hipsec@ietf.org>; Wed, 9 Jul 2014 13:43:11 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s69Kh4OJ000551; Wed, 9 Jul 2014 13:43:04 -0700
Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1n0s1y36f1-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Jul 2014 13:43:04 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 9 Jul 2014 13:42:53 -0700
From: Paul Lambert <paul@marvell.com>
To: Robert Moskowitz <rgm@htt-consult.com>, Tom Henderson <tomh@tomh.org>
Date: Wed, 09 Jul 2014 13:42:51 -0700
Thread-Topic: [Hipsec] NULL encryption mode in RFC 5202-bis
Thread-Index: Ac+btlshjkIDG7NcSiGLirSuiviRXQ==
Message-ID: <CFE2F72A.447B3%paul@marvell.com>
References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <53BBE66D.2080807@htt-consult.com> <53BD5652.300@htt-consult.com> <53BDA59C.4000004@tomh.org> <53BDA896.3080104@htt-consult.com>
In-Reply-To: <53BDA896.3080104@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.2.140509
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-09_05:2014-07-09,2014-07-09,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407090252
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/3APHBA1Ip46tlyjR9kUfOk8sj6o
Cc: "hipsec@ietf.org" <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:43:13 -0000
³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" <rgm@htt-consult.com> 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 >Hipsec@ietf.org >https://www.ietf.org/mailman/listinfo/hipsec
- [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