Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document

<Pasi.Eronen@nokia.com> Fri, 30 October 2009 08:53 UTC

Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B0C3A69A6 for <ipsec@core3.amsl.com>; Fri, 30 Oct 2009 01:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.568
X-Spam-Level:
X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqfUieqlRmPo for <ipsec@core3.amsl.com>; Fri, 30 Oct 2009 01:53:58 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 66CE73A67C1 for <ipsec@ietf.org>; Fri, 30 Oct 2009 01:53:58 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9U8s8Uu030745; Fri, 30 Oct 2009 03:54:14 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:54:09 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:54:09 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:54:03 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 30 Oct 2009 09:54:02 +0100
From: Pasi.Eronen@nokia.com
To: kivinen@iki.fi, sheila.frankel@nist.gov
Date: Fri, 30 Oct 2009 09:54:01 +0100
Thread-Topic: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
Thread-Index: AcpS8yoVaeLJy/jhTiaJzP8hPhTkLAGSylbA
Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F6F461F@NOK-EUMSG-01.mgdnok.nokia.com>
References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> <D7A0423E5E193F40BE6E94126930C4930789878B5E@MBCLUSTER.xchange.nist.gov> <19168.6686.368531.842814@fireball.kivinen.iki.fi>
In-Reply-To: <19168.6686.368531.842814@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Oct 2009 08:54:03.0806 (UTC) FILETIME=[880083E0:01CA593E]
X-Nokia-AV: Clean
Cc: ipsec@ietf.org
Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2009 08:53:59 -0000

Tero:

I think you're correct that RFC 4307 has a bug: ENCR_NULL
should be MUST NOT, instead of MAY (note that ENCR_NULL
in 4305/4835 is MUST). Go ahead and submit an errata
about this!

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of ext Tero Kivinen
> Sent: 22 October, 2009 11:39
> To: Frankel, Sheila E.
> Cc: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap
> document
> 
> Frankel, Sheila E. writes:
> > I interpreted RFC 4307 slightly differently than Tero does, and I
> > stand by the wording of both the USGv6 Profile and the IPsec
> > Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly
> > specifies both those algorithms used within IKEv2 and also those
> > algorithms that IKEv2 negotiates for use by IPsec. That is why there
> > are 2 separate lists of algorithms: Section 3.1.1 (Encrypted Payload
> > Algorithms) specifies those algorithms that are used BY IKEv2 in its
> > Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1
> > Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists
> > those algorithms that IKEv2 should be able to negotiate for use
> > within IPsec/child SAs. One detail that supports this interpretation
> > is the inclusion of NULL encryption in section 3.1.3 - clearly, this
> > is not appropriate in the IKE Encrypted Payload. If the
> > applicability of Sections 3.1.3 and 3.1.5 is limited to IKEv2 SAs,
> > then there is no need for the more constrained list in Section
> > 3.1.1, which clearly applies only to IKEv2's payloads.
> 
> Hmm... Yes, it could be interpreted so also, but what is the
> relationship between RFC4307 and RFC4305/4835 then. Would
> RFC4305/RFC4835 then cover only manual keying and IKEv1? I always
> assumed that RFC4307 talks about IKEv2 SAs and RFC4305/4835 talks
> about ESP and AH (i.e. IPsec SAs aka Child SAs).
> 
> One reason I think this is the correct interpretation is that RFC4307
> section 3.1.4 lists Transform Type 2 Algorithms (Pseudor-random
> functions, PRFs), and those are applicable ONLY to IKEv2. IPsec
> SAs/Child SAs/ESP/AH cannot have PRFs.
> 
> Also section 3.1.5 does not give any status for NONE authentication
> (as it cannot be used for IKEv2 SAs), but for example RFC4305/RFC4835
> both give requirement for it (MUST / MAY).
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec