IETF Logo Mail Archive

[Hipsec] NULL encryption mode in RFC 5202-bis

Tom Henderson <tomh@tomh.org> Tue, 08 July 2014 04:54 UTC

Return-Path: <tomh@tomh.org>
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 C9E111B2A30 for <hipsec@ietfa.amsl.com>; Mon, 7 Jul 2014 21:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable
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 WLdIWRG0ldoh for <hipsec@ietfa.amsl.com>; Mon, 7 Jul 2014 21:54:52 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 04AE61A0ADC for <hipsec@ietf.org>; Mon, 7 Jul 2014 21:54:51 -0700 (PDT)
Received: (qmail 3149 invoked by uid 0); 8 Jul 2014 04:54:50 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 8 Jul 2014 04:54:50 -0000
Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id Pmub1o00X2molgS01mueUT; Tue, 08 Jul 2014 04:54:48 -0600
X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=zOy1VSPGCM8A:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=8DlgOUzT2xeDgoSnnPAA:9 a=wPNLvfGTeEIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=HHE21bycryu05SSOooMvTV2ewvqyHXjMVM/zhZ1cAUY=; b=WelnMfVFIHNCX5nkN0puFjUGcKgxzwyhStu3bi28+ou/hR+O3c9tTbxmr5blcOxsYlHluDJK8f0bwpVrxZocVNR38Znmq6LLpCCaMOzTaZhd/EzPpggTGfY1vM0tYM1k;
Received: from [71.231.123.189] (port=58688 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <tomh@tomh.org>) id 1X4NQL-0008AQ-E4; Mon, 07 Jul 2014 22:54:37 -0600
Message-ID: <53BB798A.3080101@tomh.org>
Date: Mon, 07 Jul 2014 21:54:34 -0700
From: Tom Henderson <tomh@tomh.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: hipsec@ietf.org, saag@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org}
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/6TiPWTvuS5BN_iR07ccID-Z6GT4
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [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: Tue, 08 Jul 2014 04:54:54 -0000

Hi all,

Apologies for cross-posting, but Stephen Farrell raised a DISCUSS 
(seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: 
   Using the Encapsulating Security Payload (ESP) Transport Format with 
the Host Identity Protocol (HIP).  Stephen asked me to raise this 
question for discussion on both the HIP and SAAG lists.

Stephen's discuss questions the specification of "MUST to implement" for 
the NULL encryption option of the ESP_TRANSFORM parameter:

http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2

Stephen asks why is this a MUST to implement?  The history behind this 
that I'm aware of is that since HIP does not have an AH, only ESP, the 
ESP with NULL encryption mode can provide authentication.  It was also 
stated in previous drafts that this mode supports debugging.

Null encryption was also specified as a MUST to implement in RFC5202 and 
dates back to earlier versions of the HIP base draft (to 2003: 
http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).

- Tom

v2.23.0 | Report a Bug | By Email