From ipsec-bounces@ietf.org Wed Feb 01 03:08:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4D2F-0008Js-3S; Wed, 01 Feb 2006 03:08:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4D2C-0008EK-6t
	for ipsec@megatron.ietf.org; Wed, 01 Feb 2006 03:08:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20478
	for <ipsec@ietf.org>; Wed, 1 Feb 2006 03:06:10 -0500 (EST)
Received: from moutng.kundenserver.de ([212.227.126.188])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4DCt-0002wI-A1
	for ipsec@ietf.org; Wed, 01 Feb 2006 03:19:17 -0500
Received: from [213.54.68.128] (helo=212.227.126.177)
	by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis),
	id 0ML2Dk-1F4D1e1Nu8-00048t; Wed, 01 Feb 2006 09:07:38 +0100
From: Thomas Otto <t.otto@sharevolution.de>
To: ipsec@ietf.org
Date: Wed, 1 Feb 2006 09:08:00 +0100
User-Agent: KMail/1.9.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200602010908.01078.t.otto@sharevolution.de>
X-Provags-ID: kundenserver.de abuse@kundenserver.de
	login:3105fcefe481186a11ed9e9de1ccc56f
X-Spam-Score: 0.3 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: quoted-printable
Subject: [Ipsec] Bug in IKEv2 shared secret authentication?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi all,

in case of shared secret based authentication, the =A0AUTH payload is
computed as

=A0 =A0 =A0 AUTH =3D prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octet=
s>)

if the shared secret is a password or derived from a password,=20
IKEv2 suggests to store prf ( shared secret, "Key Pad for IKEv2") rather=20
than shared secret itself in the configuration file.

However, since the prf is negotiated during the IKE_SA_INIT exchange,=20
the question arises which prf shall be applied here.=20

Is the "inner" prf pre-negotiated perhaps? Must the configuration file
store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-tiger,
aes128-xcbc)?

I have found a related thread in the IPsec mailing list, which points out,
that the inner prf has been introduced to accomodate handling with prfs
which need a fixed-size key (instead of a key of arbitrary length).

Can anyone clarify?

Thomas

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Wed Feb 01 03:46:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4DdF-00055T-FT; Wed, 01 Feb 2006 03:46:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4DdD-00054P-N4
	for ipsec@megatron.ietf.org; Wed, 01 Feb 2006 03:46:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22712
	for <ipsec@ietf.org>; Wed, 1 Feb 2006 03:44:40 -0500 (EST)
From: Pasi.Eronen@nokia.com
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4DoB-00048q-01
	for ipsec@ietf.org; Wed, 01 Feb 2006 03:57:48 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k118f8DU027175; Wed, 1 Feb 2006 10:41:09 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 1 Feb 2006 10:45:29 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 1 Feb 2006 10:45:29 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ipsec] Bug in IKEv2 shared secret authentication?
Date: Wed, 1 Feb 2006 10:45:28 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F240228725D@esebe105.NOE.Nokia.com>
In-Reply-To: <200602010908.01078.t.otto@sharevolution.de>
Thread-Topic: [Ipsec] Bug in IKEv2 shared secret authentication?
Thread-Index: AcYnB6y1MAN49yGORbW+beuII7BoSAAAonMg
To: <t.otto@sharevolution.de>, <ipsec@ietf.org>
X-OriginalArrivalTime: 01 Feb 2006 08:45:29.0066 (UTC)
	FILETIME=[DA812CA0:01C6270B]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org


Hi Thomas,

You're quite right in that the PRF is negotiated -- and this
context is not an exception.

In my opinion, the most likely options are probably (1) having a
policy which allows only one PRF, so only one stored hash is needed,
(2) storing several hash values as you suggest, or (3) just storing
the plain shared secret instead of the hash.

Choosing between these is an implementation detail not specified
in the protocol spec.=20

About PRFs with fixed-size keys: now that 3664bis has been approved,
we don't have any of those left (and I hope we don't specify any;
the clarifications document spent quite a lot of time on those...).

Best regards,
Pasi=20

> -----Original Message-----
> From: Thomas Otto
> Sent: 01 February, 2006 10:08
> To: ipsec@ietf.org
> Subject: [Ipsec] Bug in IKEv2 shared secret authentication?
>=20
> Hi all,
>=20
> in case of shared secret based authentication, the =A0AUTH payload is
> computed as
>=20
> =A0 =A0 =A0 AUTH =3D prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg =
octets>)
>=20
> if the shared secret is a password or derived from a password,=20
> IKEv2 suggests to store prf ( shared secret, "Key Pad for=20
> IKEv2") rather than shared secret itself in the configuration file.
>=20
> However, since the prf is negotiated during the IKE_SA_INIT exchange,=20
> the question arises which prf shall be applied here.=20
>=20
> Is the "inner" prf pre-negotiated perhaps? Must the configuration file
> store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-tiger,
> aes128-xcbc)?
>=20
> I have found a related thread in the IPsec mailing list, which
> points out, that the inner prf has been introduced to accomodate
> handling with prfs which need a fixed-size key (instead of a key of
> arbitrary length).
>=20
> Can anyone clarify?
>=20
> Thomas

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Thu Feb 02 02:00:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4YRx-0000gQ-76; Thu, 02 Feb 2006 02:00:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4YQk-0000BT-37
	for ipsec@megatron.ietf.org; Thu, 02 Feb 2006 01:58:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04146
	for <ipsec@ietf.org>; Thu, 2 Feb 2006 01:57:20 -0500 (EST)
Received: from wproxy.gmail.com ([64.233.184.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Yc3-00062w-PT
	for ipsec@ietf.org; Thu, 02 Feb 2006 02:10:40 -0500
Received: by wproxy.gmail.com with SMTP id i22so326222wra
	for <ipsec@ietf.org>; Wed, 01 Feb 2006 22:58:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=TdCme979AzK43iKlIY98OaQmWoxr4ABC7h1bstBWP6BTbYX7YDdxSe8CvbxJXXY1gc3QtIIyeZThxDT6yQtAilpMOQK/6hr0faCnfFXmSwKcl61zLsZwowrbDZnOWM2Bw0pPCnBFi6Pux3n7P3JGsYrRlkBESEOjBWnA4dLE4os=
Received: by 10.65.242.7 with SMTP id u7mr201915qbr;
	Wed, 01 Feb 2006 22:58:53 -0800 (PST)
Received: by 10.65.218.10 with HTTP; Wed, 1 Feb 2006 22:58:53 -0800 (PST)
Message-ID: <9d75bf160602012258v576ae8d3ka86d78673af46326@mail.gmail.com>
Date: Thu, 2 Feb 2006 12:28:53 +0530
From: Basudev achary <pba80862002@gmail.com>
To: ipsec@ietf.org
In-Reply-To: <43e0eae4.2ea5791f.7c3d.214bSMTPIN_ADDED@mx.gmail.com>
MIME-Version: 1.0
References: <43e0eae4.2ea5791f.7c3d.214bSMTPIN_ADDED@mx.gmail.com>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4
Subject: [Ipsec] Re: Ipsec Digest, Vol 22, Issue 1
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0625468579=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============0625468579==
Content-Type: multipart/alternative; 
	boundary="----=_Part_27657_4133530.1138863533403"

------=_Part_27657_4133530.1138863533403
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all ,
             In configure the IPsec VPN in PIX 252 model , if  Phase 1 is
connected and  phase 2 is not connected then what is error msgs is diaplay
on console /????

On 2/1/06, ipsec-request@ietf.org <ipsec-request@ietf.org> wrote:
>
> Send Ipsec mailing list submissions to
>         ipsec@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www1.ietf.org/mailman/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to
>         ipsec-request@ietf.org
>
> You can reach the person managing the list at
>         ipsec-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ipsec digest..."
>
>
> Today's Topics:
>
>    1. Bug in IKEv2 shared secret authentication? (Thomas Otto)
>    2. RE: Bug in IKEv2 shared secret authentication?
>       (Pasi.Eronen@nokia.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 1 Feb 2006 09:08:00 +0100
> From: Thomas Otto <t.otto@sharevolution.de>
> Subject: [Ipsec] Bug in IKEv2 shared secret authentication?
> To: ipsec@ietf.org
> Message-ID: <200602010908.01078.t.otto@sharevolution.de>
> Content-Type: text/plain;  charset=3D"iso-8859-1"
>
> Hi all,
>
> in case of shared secret based authentication, the AUTH payload is
> computed as
>
>   AUTH =3D prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
>
> if the shared secret is a password or derived from a password,
> IKEv2 suggests to store prf ( shared secret, "Key Pad for IKEv2") rather
> than shared secret itself in the configuration file.
>
> However, since the prf is negotiated during the IKE_SA_INIT exchange,
> the question arises which prf shall be applied here.
>
> Is the "inner" prf pre-negotiated perhaps? Must the configuration file
> store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-tiger,
> aes128-xcbc)?
>
> I have found a related thread in the IPsec mailing list, which points out=
,
> that the inner prf has been introduced to accomodate handling with prfs
> which need a fixed-size key (instead of a key of arbitrary length).
>
> Can anyone clarify?
>
> Thomas
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 1 Feb 2006 10:45:28 +0200
> From: Pasi.Eronen@nokia.com
> Subject: RE: [Ipsec] Bug in IKEv2 shared secret authentication?
> To: <t.otto@sharevolution.de>, <ipsec@ietf.org>
> Message-ID:
>         <B356D8F434D20B40A8CEDAEC305A1F240228725D@esebe105.NOE.Nokia.com>
> Content-Type: text/plain;       charset=3D"iso-8859-1"
>
>
> Hi Thomas,
>
> You're quite right in that the PRF is negotiated -- and this
> context is not an exception.
>
> In my opinion, the most likely options are probably (1) having a
> policy which allows only one PRF, so only one stored hash is needed,
> (2) storing several hash values as you suggest, or (3) just storing
> the plain shared secret instead of the hash.
>
> Choosing between these is an implementation detail not specified
> in the protocol spec.
>
> About PRFs with fixed-size keys: now that 3664bis has been approved,
> we don't have any of those left (and I hope we don't specify any;
> the clarifications document spent quite a lot of time on those...).
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: Thomas Otto
> > Sent: 01 February, 2006 10:08
> > To: ipsec@ietf.org
> > Subject: [Ipsec] Bug in IKEv2 shared secret authentication?
> >
> > Hi all,
> >
> > in case of shared secret based authentication, the AUTH payload is
> > computed as
> >
> > AUTH =3D prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
> >
> > if the shared secret is a password or derived from a password,
> > IKEv2 suggests to store prf ( shared secret, "Key Pad for
> > IKEv2") rather than shared secret itself in the configuration file.
> >
> > However, since the prf is negotiated during the IKE_SA_INIT exchange,
> > the question arises which prf shall be applied here.
> >
> > Is the "inner" prf pre-negotiated perhaps? Must the configuration file
> > store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-tiger,
> > aes128-xcbc)?
> >
> > I have found a related thread in the IPsec mailing list, which
> > points out, that the inner prf has been introduced to accomodate
> > handling with prfs which need a fixed-size key (instead of a key of
> > arbitrary length).
> >
> > Can anyone clarify?
> >
> > Thomas
>
>
>
> ------------------------------
>
> _______________________________________________
> Ipsec mailing list
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
>
>
> End of Ipsec Digest, Vol 22, Issue 1
> ************************************
>



--
Thanking U
P.Basudev
Mob: 09886242840
Email: Basudev.a@gmail.com
          Basudev.a@hotmail.com

------=_Part_27657_4133530.1138863533403
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all ,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
In configure the IPsec VPN in PIX 252 model , if&nbsp; Phase 1 is
connected and&nbsp; phase 2 is not connected then what is error msgs is
diaplay on console /????<br><br><div><span class=3D"gmail_quote">On 2/1/06,=
 <b class=3D"gmail_sendername"><a href=3D"mailto:ipsec-request@ietf.org">ip=
sec-request@ietf.org</a></b> &lt;<a href=3D"mailto:ipsec-request@ietf.org">=
ipsec-request@ietf.org
</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;">Send Ipsec mailing list submissions to<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;<a href=3D"mailto:ipsec@ietf.org">
ipsec@ietf.org</a><br><br>To subscribe or unsubscribe via the World Wide We=
b, visit<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"http=
s://www1.ietf.org/mailman/listinfo/ipsec">https://www1.ietf.org/mailman/lis=
tinfo/ipsec</a><br>or, via email, send a message with subject or body 'help=
' to
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"mailto:ipsec=
-request@ietf.org">ipsec-request@ietf.org</a><br><br>You can reach the pers=
on managing the list at<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
<a href=3D"mailto:ipsec-owner@ietf.org">ipsec-owner@ietf.org</a><br><br>Whe=
n replying, please edit your Subject line so it is more specific
<br>than &quot;Re: Contents of Ipsec digest...&quot;<br><br><br>Today's Top=
ics:<br><br>&nbsp;&nbsp; 1. Bug in IKEv2 shared secret authentication? (Tho=
mas Otto)<br>&nbsp;&nbsp; 2. RE: Bug in IKEv2 shared secret authentication?=
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(<a href=3D"mailto:Pasi.Eronen@noki=
a.com">
Pasi.Eronen@nokia.com</a>)<br><br><br>-------------------------------------=
---------------------------------<br><br>Message: 1<br>Date: Wed, 1 Feb 200=
6 09:08:00 +0100<br>From: Thomas Otto &lt;<a href=3D"mailto:t.otto@sharevol=
ution.de">
t.otto@sharevolution.de</a>&gt;<br>Subject: [Ipsec] Bug in IKEv2 shared sec=
ret authentication?<br>To: <a href=3D"mailto:ipsec@ietf.org">ipsec@ietf.org=
</a><br>Message-ID: &lt;<a href=3D"mailto:200602010908.01078.t.otto@sharevo=
lution.de">
200602010908.01078.t.otto@sharevolution.de</a>&gt;<br>Content-Type: text/pl=
ain;&nbsp;&nbsp;charset=3D&quot;iso-8859-1&quot;<br><br>Hi all,<br><br>in c=
ase of shared secret based authentication, the AUTH payload is<br>computed =
as<br><br>
&nbsp;&nbsp;AUTH =3D prf(prf(Shared Secret,&quot;Key Pad for IKEv2&quot;), =
&lt;msg octets&gt;)<br><br>if the shared secret is a password or derived fr=
om a password,<br>IKEv2 suggests to store prf ( shared secret, &quot;Key Pa=
d for IKEv2&quot;) rather
<br>than shared secret itself in the configuration file.<br><br>However, si=
nce the prf is negotiated during the IKE_SA_INIT exchange,<br>the question =
arises which prf shall be applied here.<br><br>Is the &quot;inner&quot; prf=
 pre-negotiated perhaps? Must the configuration file
<br>store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-tiger,<=
br>aes128-xcbc)?<br><br>I have found a related thread in the IPsec mailing =
list, which points out,<br>that the inner prf has been introduced to accomo=
date handling with prfs
<br>which need a fixed-size key (instead of a key of arbitrary length).<br>=
<br>Can anyone clarify?<br><br>Thomas<br><br><br><br>----------------------=
--------<br><br>Message: 2<br>Date: Wed, 1 Feb 2006 10:45:28 +0200<br>From:=
=20
<a href=3D"mailto:Pasi.Eronen@nokia.com">Pasi.Eronen@nokia.com</a><br>Subje=
ct: RE: [Ipsec] Bug in IKEv2 shared secret authentication?<br>To: &lt;<a hr=
ef=3D"mailto:t.otto@sharevolution.de">t.otto@sharevolution.de</a>&gt;, &lt;
<a href=3D"mailto:ipsec@ietf.org">ipsec@ietf.org</a>&gt;<br>Message-ID:<br>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href=3D"mailto:B356D=
8F434D20B40A8CEDAEC305A1F240228725D@esebe105.NOE.Nokia.com">B356D8F434D20B4=
0A8CEDAEC305A1F240228725D@esebe105.NOE.Nokia.com
</a>&gt;<br>Content-Type: text/plain;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c=
harset=3D&quot;iso-8859-1&quot;<br><br><br>Hi Thomas,<br><br>You're quite r=
ight in that the PRF is negotiated -- and this<br>context is not an excepti=
on.<br><br>In my opinion, the most likely options are probably (1) having a
<br>policy which allows only one PRF, so only one stored hash is needed,<br=
>(2) storing several hash values as you suggest, or (3) just storing<br>the=
 plain shared secret instead of the hash.<br><br>Choosing between these is =
an implementation detail not specified
<br>in the protocol spec.<br><br>About PRFs with fixed-size keys: now that =
3664bis has been approved,<br>we don't have any of those left (and I hope w=
e don't specify any;<br>the clarifications document spent quite a lot of ti=
me on those...).
<br><br>Best regards,<br>Pasi<br><br>&gt; -----Original Message-----<br>&gt=
; From: Thomas Otto<br>&gt; Sent: 01 February, 2006 10:08<br>&gt; To: <a hr=
ef=3D"mailto:ipsec@ietf.org">ipsec@ietf.org</a><br>&gt; Subject: [Ipsec] Bu=
g in IKEv2 shared secret authentication?
<br>&gt;<br>&gt; Hi all,<br>&gt;<br>&gt; in case of shared secret based aut=
hentication, the AUTH payload is<br>&gt; computed as<br>&gt;<br>&gt; AUTH =
=3D prf(prf(Shared Secret,&quot;Key Pad for IKEv2&quot;), &lt;msg octets&gt=
;)
<br>&gt;<br>&gt; if the shared secret is a password or derived from a passw=
ord,<br>&gt; IKEv2 suggests to store prf ( shared secret, &quot;Key Pad for=
<br>&gt; IKEv2&quot;) rather than shared secret itself in the configuration=
 file.
<br>&gt;<br>&gt; However, since the prf is negotiated during the IKE_SA_INI=
T exchange,<br>&gt; the question arises which prf shall be applied here.<br=
>&gt;<br>&gt; Is the &quot;inner&quot; prf pre-negotiated perhaps? Must the=
 configuration file
<br>&gt; store the hash of all supported prfs (hmac-md5, hmac-sha1, hmac-ti=
ger,<br>&gt; aes128-xcbc)?<br>&gt;<br>&gt; I have found a related thread in=
 the IPsec mailing list, which<br>&gt; points out, that the inner prf has b=
een introduced to accomodate
<br>&gt; handling with prfs which need a fixed-size key (instead of a key o=
f<br>&gt; arbitrary length).<br>&gt;<br>&gt; Can anyone clarify?<br>&gt;<br=
>&gt; Thomas<br><br><br><br>------------------------------<br><br>_________=
______________________________________
<br>Ipsec mailing list<br><a href=3D"mailto:Ipsec@ietf.org">Ipsec@ietf.org<=
/a><br><a href=3D"https://www1.ietf.org/mailman/listinfo/ipsec">https://www=
1.ietf.org/mailman/listinfo/ipsec</a><br><br><br>End of Ipsec Digest, Vol 2=
2, Issue 1
<br>************************************<br></blockquote></div><br><br clea=
r=3D"all"><br>-- <br>Thanking U<br>P.Basudev<br>Mob: 09886242840<br>Email: =
<a href=3D"mailto:Basudev.a@gmail.com">Basudev.a@gmail.com</a><br>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href=3D"mailto:Basudev.a@hotmail.com">Basudev.a@hotmail.com</a>

------=_Part_27657_4133530.1138863533403--


--===============0625468579==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

--===============0625468579==--




From ipsec-bounces@ietf.org Thu Feb 02 09:54:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4fqc-0002mw-62; Thu, 02 Feb 2006 09:54:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4fqb-0002jg-92
	for ipsec@megatron.ietf.org; Thu, 02 Feb 2006 09:54:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09250
	for <ipsec@ietf.org>; Thu, 2 Feb 2006 09:52:23 -0500 (EST)
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4g1r-0006Wj-9A
	for ipsec@ietf.org; Thu, 02 Feb 2006 10:05:47 -0500
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
	[192.44.77.29])
	by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with
	ESMTP id k12ErRh15641; Thu, 2 Feb 2006 15:53:27 +0100
Received: from givry.rennes.enst-bretagne.fr
	(localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id
	k12ErQ9O050308; Thu, 2 Feb 2006 15:53:27 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200602021453.k12ErQ9O050308@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@point6.net>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Ipsec] First draft of IKEv2.1 
In-reply-to: Your message of Thu, 29 Dec 2005 13:41:59 PST.
	<p06230946bfda06ff78c5@[10.20.30.249]> 
Date: Thu, 02 Feb 2006 15:53:26 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: IPsec WG <ipsec@ietf.org>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Some comments:
 - I am not very convinced it is a good idea to demoted almost half of
   the SHOULDs...
 - typo in 2.6.1 tp -> to
 - in 2.8 what is the "in-place" rekeying of SAs (it seems it is
   rekey before expiration but the wording is not very clear)
 - in 3.15 there is a good example of a SHOULD I'd like to see kept:

   {{ Demoted the SHOULD }} Extensions via the CP payload should not be
   used for general purpose management.  Its main intent is to provide a
   bootstrap mechanism to exchange information within IPsec from IRAS to
   IRAC.  While it MAY be useful to use such a method to exchange
   information between some Security Gateways (SGW) or small networks,
   existing management protocols such as DHCP [DHCP], RADIUS [RADIUS],
   SNMP, or LDAP [LDAP] should be preferred for enterprise management as
   well as subsequent information exchanges.

   As an IPv6 person I believe the CP stuff will never replace something
   like DHCPv6 over XXX.

Regards

Francis.Dupont@point6.net

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Thu Feb 02 13:14:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4iyP-0007HO-2l; Thu, 02 Feb 2006 13:14:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4iyM-0007Ds-Fn
	for ipsec@megatron.ietf.org; Thu, 02 Feb 2006 13:14:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25826
	for <ipsec@ietf.org>; Thu, 2 Feb 2006 13:12:45 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4j9l-0005ZF-Bv
	for ipsec@ietf.org; Thu, 02 Feb 2006 13:26:10 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k12IEDkQ073083;
	Thu, 2 Feb 2006 10:14:14 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06230979c007fa7d7347@[10.20.30.249]>
In-Reply-To: <200602021453.k12ErQ9O050308@givry.rennes.enst-bretagne.fr>
References: <200602021453.k12ErQ9O050308@givry.rennes.enst-bretagne.fr>
Date: Thu, 2 Feb 2006 10:11:39 -0800
To: Francis Dupont <Francis.Dupont@point6.net>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Ipsec] First draft of IKEv2.1
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: IPsec WG <ipsec@ietf.org>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

At 3:53 PM +0100 2/2/06, Francis Dupont wrote:
>Some comments:
>  - I am not very convinced it is a good idea to demoted almost half of
>    the SHOULDs...

Could you be specific about which specific SHOULD changes are not a 
"good idea"? Again, the ones made in this document are to make it 
align with RFC 2119.

>  - typo in 2.6.1 tp -> to

Got it, thanks.

>  - in 2.8 what is the "in-place" rekeying of SAs (it seems it is
>    rekey before expiration but the wording is not very clear)

That is the same wording as RFC 4306.

>  - in 3.15 there is a good example of a SHOULD I'd like to see kept:
>
>    {{ Demoted the SHOULD }} Extensions via the CP payload should not be
>    used for general purpose management.  Its main intent is to provide a
>    bootstrap mechanism to exchange information within IPsec from IRAS to
>    IRAC.  While it MAY be useful to use such a method to exchange
>    information between some Security Gateways (SGW) or small networks,
>    existing management protocols such as DHCP [DHCP], RADIUS [RADIUS],
>    SNMP, or LDAP [LDAP] should be preferred for enterprise management as
>    well as subsequent information exchanges.
>
>    As an IPv6 person I believe the CP stuff will never replace something
>    like DHCPv6 over XXX.

That's fine, but what is the value of making that first sentence a 
2119-level requirement?

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Thu Feb 02 18:29:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4ntD-0006n8-4V; Thu, 02 Feb 2006 18:29:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ntB-0006lx-9S
	for ipsec@megatron.ietf.org; Thu, 02 Feb 2006 18:29:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26362
	for <ipsec@ietf.org>; Thu, 2 Feb 2006 18:27:31 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4o4S-0002HU-VF
	for ipsec@ietf.org; Thu, 02 Feb 2006 18:41:01 -0500
Received: from [165.227.249.220] (adsl-66-125-125-79.dsl.pltn13.pacbell.net
	[66.125.125.79]) (authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k12NT60H016201
	for <ipsec@ietf.org>; Thu, 2 Feb 2006 15:29:08 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p062309b5c0083e4314aa@[10.20.30.249]>
Date: Thu, 2 Feb 2006 15:28:02 -0800
To: IPsec WG <ipsec@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Subject: [Ipsec] IKEv2 clarifications -07: request for final comments
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Greetings again. The latest version of the IKEv2 clarifications draft 
has been published at 
<http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-07.txt>.

Pasi and I believe that this one may be nearly ready for IETF-wide 
last call. Thus, we would like people on this list to take another 
careful look at the document before we ask for that wider review.

In particular, we would like folks to review section 4.1 and section 
5.1, where we have clarified the use of KEi and KEr; also, please 
read section 5.13 for this. Also, please read all subsections of 
section 5.12 to see if we have covered all the cases that have been 
brought to the list; the topic is long and messy, but it will 
certainly have an impact on interoperability when we see more IKEv2 
deployments. Section 7.13 is also new.

Of course, we would appreciate it if any IKEv2 developer can do a 
full review, not just of the changed sections. After this round, we 
intend to remove section 8 (the status section) and all the 
placeholder sections in the document.

We would like to ask for AD review and IETF last call in 
approximately two weeks from now. Please comment here before then. 
Thanks in advance!

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Thu Feb 02 18:29:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4ntD-0006nb-OZ; Thu, 02 Feb 2006 18:29:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ntB-0006ly-Go
	for ipsec@megatron.ietf.org; Thu, 02 Feb 2006 18:29:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26360
	for <ipsec@ietf.org>; Thu, 2 Feb 2006 18:27:30 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4o4S-0002HK-0B
	for ipsec@ietf.org; Thu, 02 Feb 2006 18:41:00 -0500
Received: from [165.227.249.220] (adsl-66-125-125-79.dsl.pltn13.pacbell.net
	[66.125.125.79]) (authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k12NT60F016201
	for <ipsec@ietf.org>; Thu, 2 Feb 2006 15:29:07 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p062309b4c0083e270e24@[10.20.30.249]>
Date: Thu, 2 Feb 2006 15:27:58 -0800
To: IPsec WG <ipsec@ietf.org>
From: Internet-Drafts@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [Ipsec] I-D ACTION:draft-eronen-ipsec-ikev2-clarifications-07.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: IKEv2 Clarifications and Implementation Guidelines
	Author(s)	: P. Hoffman, P. Eronen
	Filename	: draft-eronen-ipsec-ikev2-clarifications-07.txt
	Pages		: 58
	Date		: 2006-2-2

This document clarifies many areas of the IKEv2 specification.  It
    does not to introduce any changes to the protocol, but rather
    provides descriptions that are less prone to ambiguous
    interpretations.  The purpose of this document is to encourage the
    development of interoperable implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-07.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body 
of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-eronen-ipsec-ikev2-clarifications-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-eronen-ipsec-ikev2-clarifications-07.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


[The following attachment must be fetched by mail. Command-click the 
URL below and send the resulting message to get the attachment.]
<mailto:mailserv@ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-07.txt>
[The following attachment must be fetched by ftp.  Command-click the 
URL below to ask your ftp client to fetch it.]
<ftp://ftp.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-07.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Feb 03 15:28:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F57Xa-000448-Ig; Fri, 03 Feb 2006 15:28:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F57XX-0003y9-EP
	for ipsec@megatron.ietf.org; Fri, 03 Feb 2006 15:28:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07550
	for <ipsec@ietf.org>; Fri, 3 Feb 2006 15:26:34 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F57j3-0003Ci-Dx
	for ipsec@ietf.org; Fri, 03 Feb 2006 15:40:14 -0500
Received: from [10.20.30.249] (adsl-66-125-125-79.dsl.pltn13.pacbell.net
	[66.125.125.79]) (authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k13KS8Uq090693
	for <ipsec@ietf.org>; Fri, 3 Feb 2006 12:28:08 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0623090fc0096d49718a@[10.20.30.249]>
Date: Fri, 3 Feb 2006 12:28:08 -0800
To: IPsec WG <ipsec@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Subject: [Ipsec] Last Call: 'The AES-CMAC-PRF-128 Algorithm for the Internet
 Key Exchange Protocol (IKE)' to Proposed Standard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

The IESG has received a request from an individual submitter to consider the
following document:

- 'The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)
'
    <draft-songlee-aes-cmac-prf-128-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-03-03.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-prf-128-02.txt


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 06 03:43:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F61y3-0004hQ-HA; Mon, 06 Feb 2006 03:43:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F61y1-0004g6-0P
	for ipsec@megatron.ietf.org; Mon, 06 Feb 2006 03:43:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28675
	for <ipsec@ietf.org>; Mon, 6 Feb 2006 03:41:43 -0500 (EST)
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]
	ident=[U2FsdGVkX18gmtxjumJIyJzpZ0nvOyyqc7aOOWH9h4s=])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F62A7-00055r-75
	for ipsec@ietf.org; Mon, 06 Feb 2006 03:55:58 -0500
Received: from i72xindi.tm.uni-karlsruhe.de ([141.3.71.103] helo=i72xindi)
	by iramx2.ira.uni-karlsruhe.de with esmtpsa 
	id 1F61xe-0004ih-Hw; Mon, 06 Feb 2006 09:43:04 +0100
From: =?iso-8859-1?Q?Lars_V=F6lker?= <ipsec-mail@larsvoelker.de>
To: "'IPsec'" <ipsec@ietf.org>
Subject: RE: [Ipsec] Errata RFC4305
Date: Mon, 6 Feb 2006 09:42:53 +0100
Message-ID: <003c01c62af9$573ce630$6747038d@tm.unikarlsruhe.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcYX9I0QikhfGvpWTh2ME/9wF2lMlQAAAZ1AAAAJetAEwP7ngA==
In-Reply-To: <BB6D74C75CC76A419B6D6FA7C38317B2C3A8D9@sinett-sbs.SiNett.LAN>
X-Spam-Score: -104.4 (---------------------------------------------------)
X-Spam-Status: No
X-Spam-Report: -100 ATIS_ASMTP SMTP with authentification via ATIS-Server
	-1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP
	-2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: quoted-printable
Cc: 'Russ Housley' <housley@vigilsec.com>, 'Stephen Kent' <kent@bbn.com>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi!

Is this a bug that RFC 4305 obsoletes 2402 (AH) and 2404 (SHA1)?
4305 says that 2404 is a must but also obsoletes it? Shouldn't it
obsolete 2402 (AH) and 2406 (ESP)? Do I miss a point?

Lars

--=20
Dipl.-Inform. Lars V=F6lker
Universit=E4t Karlsruhe (TH)
Institut f=FCr Telematik
Zirkel 2, 76128 Karlsruhe
Phone: +49 721 - 608 6397
Fax:   +49 721 - 608 6789=20


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 06 09:56:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F67me-00044L-Js; Mon, 06 Feb 2006 09:56:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F67md-00043l-6q; Mon, 06 Feb 2006 09:56:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24682;
	Mon, 6 Feb 2006 09:54:13 -0500 (EST)
From: Pasi.Eronen@nokia.com
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F67ye-00004v-IU; Mon, 06 Feb 2006 10:08:32 -0500
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1F67mO-0005I6-Sv; Mon, 06 Feb 2006 09:55:50 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k16ErVFP021805; Mon, 6 Feb 2006 16:53:35 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 6 Feb 2006 16:53:24 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 6 Feb 2006 16:53:24 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ipsec] Last Call: 'The AES-CMAC-PRF-128 Algorithm for the
	Internet Key Exchange Protocol (IKE)' to Proposed Standard
Date: Mon, 6 Feb 2006 16:53:36 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24022F36C2@esebe105.NOE.Nokia.com>
In-Reply-To: <p0623090fc0096d49718a@[10.20.30.249]>
Thread-Topic: [Ipsec] Last Call: 'The AES-CMAC-PRF-128 Algorithm for the
	Internet Key Exchange Protocol (IKE)' to Proposed Standard
Thread-Index: AcYpAV6Qb3IsM8PfQtSiT/yaOL5e/QCKupHA
To: <iesg@ietf.org>, <ipsec@ietf.org>
X-OriginalArrivalTime: 06 Feb 2006 14:53:24.0172 (UTC)
	FILETIME=[145BC8C0:01C62B2D]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

=20
A couple of comments for IETF last call. Nothing major, mostly
the document seems OK.

1) Section 3 writes "When using the PRF described in this document=20
   with IKEv2, the PRF is considered to be fixed-length for generating=20
   keying material but variable-length for authentication."

   Draft-hoffman-rfc3664bis included this "somewhat tortured logic" to
   preserve compatibility with RFC 3664. Here we don't have the
   compatibility issue, so wouldn't it be simpler to consider it
   variable-length for all purposes?

2) Section 6 says: "However, if using collision-resistant hash
   function such as AES-CMAC when generating new key for=20
   pseudo-random function"

   It's pretty trivial to show that f(x)=3DAES-CMAC(0^128,x) is not=20
   a collision-resistant hash function. But collision-resistance is=20
   not exactly the property we need here, because the input VK is=20
   secret.

3) Section 6 says: "Keys need to be chosen at random based on RFC=20
   4086 [RFC4086] and should be kept in safe and periodically=20
   refreshed."

   This paragraph doesn't make much sense in a document which defines=20
   a PRF for IKEv2. The keys come from the DH exchange (etc.), and=20
   thus cannot be chosen at random according to RFC 4086 (with
   the exception of manually configured shared secret).

4) An extremely quick and rough implementation (not based on the
   draft-songlee-aes-cmac code) produced the same values as the=20
   test vectors listed in the draft.

Purely editorial suggestions:

5) idnits: "There are 37 instances of too long lines in the document,
   the longest one being 717 characters in excess of 72."

6) Abstract: The abstact is copied from RFC 3664 (and was OK there),
   but might need some rephrasing here: we already have one=20
   AES-based PRF for IKEv2, so why another? (draft-songlee-aes-
   cmac-96 has some motivational text)

7) Section 1: "128 bits output is useful as a long-lived pseudo-
   random function (PRF) in either IKE version 1 or version 2."=20
   Since this document does not specify a PRF for IKEv1, mentioning=20
   it is a bit confusing.

8) Section 9.1: IKEv2 is now RFC 4306.

9) Section 9.2: Neither [AH] not [ROADMAP] are cited anywhere in
   the text; suggest removing them.=20

Best regards,
Pasi=20

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 06 11:55:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F69ef-0002cj-Mz; Mon, 06 Feb 2006 11:55:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F69ec-0002aW-DE
	for ipsec@megatron.ietf.org; Mon, 06 Feb 2006 11:55:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03402
	for <ipsec@ietf.org>; Mon, 6 Feb 2006 11:54:04 -0500 (EST)
Received: from aragorn.bbn.com ([128.33.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F69qf-0008IV-JA
	for ipsec@ietf.org; Mon, 06 Feb 2006 12:08:22 -0500
Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106])
	by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k16GtQIE016056;
	Mon, 6 Feb 2006 11:55:27 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06230906c00d2e13ae9c@[128.89.89.106]>
In-Reply-To: <003c01c62af9$573ce630$6747038d@tm.unikarlsruhe.de>
References: <003c01c62af9$573ce630$6747038d@tm.unikarlsruhe.de>
Date: Mon, 6 Feb 2006 11:53:13 -0500
To: Lars =?iso-8859-1?Q?V=F6lker?=  <ipsec-mail@larsvoelker.de>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [Ipsec] Errata RFC4305
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41
X-Virus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: quoted-printable
Cc: 'IPsec' <ipsec@ietf.org>, 'Russ Housley' <housley@vigilsec.com>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

At 9:42 AM +0100 2/6/06, Lars V=F6lker wrote:
>Hi!
>
>Is this a bug that RFC 4305 obsoletes 2402 (AH) and 2404 (SHA1)?
>4305 says that 2404 is a must but also obsoletes it? Shouldn't it
>obsolete 2402 (AH) and 2406 (ESP)? Do I miss a point?
>
>Lars

2402 is replaced by 4302, and 2406 is replaced by=20
4303, which is what the headers of these new RFCs=20
state.

This document supercedes very small parts of 2402=20
and 2406, but it is not the replacement for those=20
documents.   2404 was a narrow document,=20
specifying how to use HMAC-SHA-1 with AH and ESP.=20
I agree that 4305 should NOT be considered a=20
replacement for 2404 OR for 2406.  These are=20
errors.

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 06 19:10:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6GQx-0005Nb-K1; Mon, 06 Feb 2006 19:10:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6GQv-0005Me-RE
	for ipsec@megatron.ietf.org; Mon, 06 Feb 2006 19:10:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26189
	for <ipsec@ietf.org>; Mon, 6 Feb 2006 19:08:22 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Gd2-0004Sg-2v
	for ipsec@ietf.org; Mon, 06 Feb 2006 19:22:45 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k1709xZR030801
	for <ipsec@ietf.org>; Mon, 6 Feb 2006 16:10:00 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06230919c00d95b992ec@[10.20.30.249]>
Date: Mon, 6 Feb 2006 16:09:54 -0800
To: IPsec WG <ipsec@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Subject: [Ipsec] Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to
 Proposed Standard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

The IESG has received a request from an individual submitter to consider the
following document:

- 'IKE and IKEv2 Authentication Using ECDSA '
    <draft-ietf-ipsec-ike-auth-ecdsa-05.txt> as a Proposed Standard

This document is an individual submission.  It was discussed in the
IPsec Working Group, but that working group was closed before reaching
consensus on this document.  Thus, it is not affiliated with any IETF
Working Group.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-03-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-05.txt


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Wed Feb 08 12:37:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6tG1-00069U-9F; Wed, 08 Feb 2006 12:37:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tFz-00068X-Oo
	for ipsec@megatron.ietf.org; Wed, 08 Feb 2006 12:37:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13573
	for <ipsec@ietf.org>; Wed, 8 Feb 2006 12:35:50 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6tSb-0005hb-NV
	for ipsec@ietf.org; Wed, 08 Feb 2006 12:50:35 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k18HbG4C068472
	for <ipsec@ietf.org>; Wed, 8 Feb 2006 09:37:17 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0623098ac00fdcc0d2b5@[10.20.30.249]>
Date: Wed, 8 Feb 2006 09:37:15 -0800
To: IPsec WG <ipsec@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [Ipsec] Protocol Action: 'The AES-CMAC-96 Algorithm and its use
 with IPsec' to Proposed Standard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

The IESG has approved the following document:

- 'The AES-CMAC-96 Algorithm and its use with IPsec '
    <draft-songlee-aes-cmac-96-04.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-96-04.txt

Technical Summary

   National Institute of Standards and Technology (NIST) has recently
   specified the Cipher based MAC (CMAC).  This document specifies the
   use of CMAC mode as the authentication mechanism of IPsec
   Encapsulating Security Payload (ESP) and Authentication Header (AH)
   protocols.  This algorithm is referred to as AES-CMAC-96.

Working Group Summary

   This document is an individual submission.  It is not affiliated with
   any IETF Working Group.

Protocol Quality

   The AES-CMAC is one of choices for the message authentication code
   (MAC) and key derivation function (KDF) supported in IEEE 802.16e.  We
   believe that AES-CMAC has been implemented by INTEL, Runcom and
   SAMSUNG for their IEEE 802.16e-compliant products.  We believe that
   other vendors develop or have developed AES-CMAC for their IEEE
   802.16e-compliant products.

   This document was reviewed by Russ Housley for the IESG.


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Thu Feb 09 13:40:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7Giq-0001Ma-7r; Thu, 09 Feb 2006 13:40:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Gio-0001IQ-3c
	for ipsec@megatron.ietf.org; Thu, 09 Feb 2006 13:40:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19460
	for <ipsec@ietf.org>; Thu, 9 Feb 2006 13:39:07 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Gvd-0002fu-K3
	for ipsec@ietf.org; Thu, 09 Feb 2006 13:54:07 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k19IefIG008145
	for <ipsec@ietf.org>; Thu, 9 Feb 2006 10:40:42 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p062309bec0113cb3d5d0@[10.20.30.249]>
In-Reply-To: <p062309b5c0083e4314aa@[10.20.30.249]>
References: <p062309b5c0083e4314aa@[10.20.30.249]>
Date: Thu, 9 Feb 2006 10:40:39 -0800
To: IPsec WG <ipsec@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [Ipsec] NUDGE: IKEv2 clarifications -07: request for final comments
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

[[ Pasi and I would love to believe that the document needs no 
changes, but we wanted to give another nudge. The "two weeks" below 
is now "one week". Please review thoroughly. Thanks! ]]

Greetings again. The latest version of the IKEv2 clarifications draft 
has been published at 
<http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-07.txt>.

Pasi and I believe that this one may be nearly ready for IETF-wide 
last call. Thus, we would like people on this list to take another 
careful look at the document before we ask for that wider review.

In particular, we would like folks to review section 4.1 and section 
5.1, where we have clarified the use of KEi and KEr; also, please 
read section 5.13 for this. Also, please read all subsections of 
section 5.12 to see if we have covered all the cases that have been 
brought to the list; the topic is long and messy, but it will 
certainly have an impact on interoperability when we see more IKEv2 
deployments. Section 7.13 is also new.

Of course, we would appreciate it if any IKEv2 developer can do a 
full review, not just of the changed sections. After this round, we 
intend to remove section 8 (the status section) and all the 
placeholder sections in the document.

We would like to ask for AD review and IETF last call in 
approximately two weeks from now. Please comment here before then. 
Thanks in advance!

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Sun Feb 12 17:58:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8QAN-0007da-Qj; Sun, 12 Feb 2006 17:58:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8QAM-0007dV-KQ
	for ipsec@megatron.ietf.org; Sun, 12 Feb 2006 17:58:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21619
	for <ipsec@ietf.org>; Sun, 12 Feb 2006 17:56:17 -0500 (EST)
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8QNn-0000r3-By
	for ipsec@ietf.org; Sun, 12 Feb 2006 18:11:59 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with
	ESMTP id k1CMvmZJ006747
	for <ipsec@ietf.org>; Sun, 12 Feb 2006 23:57:48 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
	[192.44.77.29])
	by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with
	ESMTP id k1CMvjIZ006743
	for <ipsec@ietf.org>; Sun, 12 Feb 2006 23:57:45 +0100
Received: from givry.rennes.enst-bretagne.fr
	(localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id
	k1CMvjeC016405
	for <ipsec@ietf.org>; Sun, 12 Feb 2006 23:57:45 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200602122257.k1CMvjeC016405@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@point6.net>
To: ipsec@ietf.org
Date: Sun, 12 Feb 2006 23:57:45 +0100
X-Virus-Scanned: amavisd-new at enst-bretagne.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Subject: [Ipsec] impl of AES CCM or GCM?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

I am looking for an open source implementation of a combined mode
like AES CCM (RFC 4309) or GCM (RFC 4106) for a KAME BSD or
a Linux kernel 2.6.

Francis.Dupont@point6.net

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 13 07:58:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8dI4-00079l-4Y; Mon, 13 Feb 2006 07:58:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8dI2-00079d-7y
	for ipsec@megatron.ietf.org; Mon, 13 Feb 2006 07:58:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16819
	for <ipsec@ietf.org>; Mon, 13 Feb 2006 07:57:04 -0500 (EST)
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8dVa-0007Td-BS
	for ipsec@ietf.org; Mon, 13 Feb 2006 08:12:54 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with
	ESMTP id k1DCwUsD012116; Mon, 13 Feb 2006 13:58:30 +0100
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
	[192.44.77.29])
	by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with
	ESMTP id k1DCwQ6L012109; Mon, 13 Feb 2006 13:58:26 +0100
Received: from givry.rennes.enst-bretagne.fr
	(localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id
	k1DCwOUV018098; Mon, 13 Feb 2006 13:58:24 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200602131258.k1DCwOUV018098@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@point6.net>
To: ipsec@ietf.org
Date: Mon, 13 Feb 2006 13:58:24 +0100
X-Virus-Scanned: amavisd-new at enst-bretagne.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: Yves Correc <correc@celar.fr>
Subject: [Ipsec] november meetings
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

We'd like to know what are the IPsec/Network security related conferences /
meetings / etc scheduled in november 2006.

Regards

Francis.Dupont@point6.net

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 13 09:30:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8ej9-0001O6-99; Mon, 13 Feb 2006 09:30:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ej7-0001O1-AJ
	for ipsec@megatron.ietf.org; Mon, 13 Feb 2006 09:30:53 -0500
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23536
	for <ipsec@lists.ietf.org>; Mon, 13 Feb 2006 09:29:08 -0500 (EST)
Received: from root by ciao.gmane.org with local (Exim 4.43)
	id 1F8eit-0001J7-UJ
	for ipsec@lists.ietf.org; Mon, 13 Feb 2006 15:30:45 +0100
Received: from mail.sernet.com.cn ([222.92.90.190])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <ipsec@lists.ietf.org>; Mon, 13 Feb 2006 15:30:39 +0100
Received: from fog.hua by mail.sernet.com.cn with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <ipsec@lists.ietf.org>; Mon, 13 Feb 2006 15:30:39 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ipsec@ietf.org
From: Fog Hua <fog.hua@gmail.com>
Date: Mon, 13 Feb 2006 17:03:29 +0800
Lines: 1
Message-ID: <m3oe1bfx5q.fsf@fog-ibm.sernet.com.cn>
References: <v04220803b8ec7b2f1ed4@[10.33.1.28]>
	<001401c1eba5$da214830$0a3193cc@verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: mail.sernet.com.cn
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
Cancel-Lock: sha1:hI8kQx8XfVvdJarfnWfUMSog5GE=
Subject: [Ipsec] Re: Dead Peer Detection (DPD)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Sure,it is RFC3706


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Thu Feb 16 11:10:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F9liI-0004Um-Ns; Thu, 16 Feb 2006 11:10:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F9liG-0004U7-6k
	for ipsec@megatron.ietf.org; Thu, 16 Feb 2006 11:10:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08241
	for <ipsec@ietf.org>; Thu, 16 Feb 2006 11:08:47 -0500 (EST)
Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9lwT-0003SZ-2X
	for ipsec@ietf.org; Thu, 16 Feb 2006 11:25:20 -0500
Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1])
	by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k1GGAPa0011896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 16 Feb 2006 18:10:25 +0200 (EET)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.13.4/8.12.11) id k1GGAMhE018867;
	Thu, 16 Feb 2006 18:10:22 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17396.41966.36578.565695@fireball.kivinen.iki.fi>
Date: Thu, 16 Feb 2006 18:10:22 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 7.17 under Emacs 21.4.1
X-Edit-Time: 73 min
X-Total-Time: 156 min
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: 7bit
Cc: dbrown@certicom.com, housley@vigilsec.com, defu@orion.ncsc.mil
Subject: [Ipsec] draft-ietf-ipsec-ike-ecp-groups-02.txt / ecc-groups-08.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Some comments to the ECP/ECC group drafts.

The ECP and ECC drafts are inconsistent in the way they describe the
actual format of the final secrets and KE payloads. Note, that IKEv2
(RFC4306) does NOT specify any format for the KE payloads nor the
secrets generated for the elliptic curves. The RFC4306 only defines
those formats for MODP groups.

The ECP draft does not define what format should be used, but it still
uses some format in the test vectors. IKEv1 RFC 2409 does not specify
any format for the ECP group key exchange payloads either. The ECP
draft needs a section explaining what is put to the KE payloads of the
IKEv1 and IKEv2 protocols (Note, that the IKEv1 and IKEv2 uses
different KE payload format). It also needs to specify what is the
final shared secret generated.

>From the test vectors it seems that at least in the IKEv2 the KEi and
KEr payloads are filled with the concatenation of the gix and giy, but
it does not specify what kind of padding (if any) is done when those
values are concatenated to the KE payload. The IKEv2 document does say
that for MODP Diffie-Hellman "The length of the Diffie-Hellman public
value MUST be equal to the length of the prime modulus over which the
exponentiation was performed, prepending zero bits to the value if
necessary." Something similar is required for the ECP groups too.

Also the shared secret value for the ECP groups is not defined
anywhere. The IKEv2 RFC does not specify it, and the ECP draft simply
gives test vector which makes g^ir by combining girx and giry
together. Again no mention about the padding or similar is not given.

Also as far as I understand the giry value does not really add that
much to the shared secret as for each solution girx there is 2
possible y coordinates, thus adding that to the shared secret only
adds one bit of entropy to the shared secret.

The IKEv1 RFC actually omitted to mention how the g^xy is used in the
elliptic curve groups, i.e. whether the both x and y coordinates where
used and whether they were padded or not.

The IKEv2 RFC only says that the "g^ir is the shared secret from
ephemeral Diffie-Hellman exchange. g^ir is represented as a string of
octets in big endian order padded with zeros if necessary to make it
the length of the modulus."

The ecc-groups draft defines format for the KE payload saying:

    	For elliptic curve groups, the data in the KE payload when
	using this group is the octet string representation specified
	in ANSI X9.62, ANSI X9.63, FIPS 186-2, and IEEE P1363 of the
	point on the curve chosen by taking the randomly chosen secret
	Ka and computing Ka*G, where * is the repetition of the group
	addition.

I do not know what ANSI X9.62, ANSI X9.63, FIPS 186-2 or IEEE P1363
say about the octet string representation, but I would think we should
specify the format here, not to refer some external document which is
not available in general (for example the FIPS-182-2 url returns
error).

The ecc-groups also defines format for the secret:

	If the initiator chooses secret i and the responder chooses
	secret r, then the KEi is i*G and KEr is r*G. The raw shared
	secret is the x-coordinate (only) of (ir)*G.

The IKEv1 defines that the format of the KE payload of EC2N groups is:

   The data in the KE payload when using this group is the value x from
   the solution (x,y), the point on the curve chosen by taking the
   randomly chosen secret Ka and computing Ka*P, where * is the
   repetition of the group addition and double operations, P is the
   curve point with x coordinate equal to generator 1 and the y
   coordinate determined from the defining equation. The equation of
   curve is implicitly known by the Group Type and the A and B
   coefficients. There are two possible values for the y coordinate;
   either one can be used successfully (the two parties need not agree
   on the selection).

thus only value of x from the solution. If ecc-groups draft tries to
be compatible with the IKEv1 then at least for IKEv1 that format
should be used (don't know if it is used, as it does not define it but
refers to external documents).

On the other hand I do not know why would be using different format
for ECP and EC2N groups for the KE and shared secret, i.e. for ECP
include both X and Y and for EC2N only include the X. If there is
patent or other reasons not to use one version then we should use that
other version in both cases at least for IKEv2 (where backward
compatibility is not an issue).

Another generic comment for both of these drafts is that they do not
take account that the IKEv1 and IKEv2 IANA registries are separate. To
allocate numbers for both of those you need to allocate the numbers
from both of them. Actually the ecc-groups draft is missing the IANA
considerations section completely. 

For the IKEv2 the correct IANA registry is "Internet Key Exchange
Version 2 (IKEv2) Parameters - Diffie-Hellman Transform Ids".

For the IKEv1 the correct IANA registry is "Internet Key Exchange
(IKE) Attributes - IKE Attributes - Group Description".

Currently the allocated points in both have same values, but for
example the IKEv2 - Diffie-Hellman Transform Ids registry do not have
any values for any of the elliptic curve groups, only for the MODP
groups.

Because of this it might be better not to define any numbers here in
the text, but simply give a group names (like RFC3524 used 1536-bit
MODP group etc) and leave the actual registry work (i.e. which number
matches which named group) to the IANA.

I.e. instead of sections "2.1 Nineteenth Group" change it to section
"2.1 256-bit Random Curve Group" and "2.2 Seventh Group" to "2.2
Koblitz Curve Group Over GF[2^163]" or similar. 


Some other comments to the ecc-groups draft:

The ecc-groups draft have strength estimates which are not taking
account the memory space required to run the algorithms, i.e. it gives
way too big requirements for the DH/DSA/RSA groups. See
http://www.rsasecurity.com/rsalabs/node.asp?id=2088 for more
information (or the strength estimates from the RFC3526)

If talking the space cost in the calculations the 1620 bit RSA key has
the same strength than 256 bit elliptic curve and 128 bit symmetric
key, compared to the 3072 given by the ecc-groups draft.

The ecc-groups draft has also using the non-ietf way when talking
about the 3DES, calling it TDES (for example in section 2), and also
talking about the TDES with key lengths of 168 and 112 bits. The key
length for 3DES used in IPsec is always 168 bits, thus talking about
2-key version of TDES here is just misleading. 

Also the group definitions have very long lines, that should be
breaked up to the shorter, and perhaps adding spaces every 8 hex-digit
as done in RFC 3526 would make the numbers more readable. 
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Thu Feb 16 11:38:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F9m94-0001iX-27; Thu, 16 Feb 2006 11:38:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F9m92-0001iS-Pb
	for ipsec@megatron.ietf.org; Thu, 16 Feb 2006 11:38:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10386
	for <ipsec@ietf.org>; Thu, 16 Feb 2006 11:36:30 -0500 (EST)
Received: from [216.183.86.37] (helo=mail.ca.certicom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9mNA-0004Sk-Jl
	for ipsec@ietf.org; Thu, 16 Feb 2006 11:53:01 -0500
Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1])
	by mail.ca.certicom.com (Postfix) with ESMTP id 304061006B009;
	Thu, 16 Feb 2006 11:37:59 -0500 (EST)
Received: from mail.ca.certicom.com ([127.0.0.1])
	by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 09009-34; Thu, 16 Feb 2006 11:37:57 -0500 (EST)
Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24])
	by mail.ca.certicom.com (Postfix) with ESMTP id 595061006B001;
	Thu, 16 Feb 2006 11:37:57 -0500 (EST)
In-Reply-To: <17396.41966.36578.565695@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <OF50F6DDC7.9EA5B9A4-ON85257117.005B1F42-85257117.005BB659@certicom.com>
From: Daniel Brown <DBrown@certicom.com>
Date: Thu, 16 Feb 2006 11:37:25 -0500
X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27,
	2005) at 02/16/2006 11:37:25 AM,
	Serialize complete at 02/16/2006 11:37:25 AM
X-Spam-Score: 0.5 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: ipsec@ietf.org, housley@vigilsec.com, defu@orion.ncsc.mil
Subject: [Ipsec] Re: draft-ietf-ipsec-ike-ecp-groups-02.txt /
	ecc-groups-08.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0585752059=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

This is a multipart message in MIME format.
--===============0585752059==
Content-Type: multipart/alternative;
	boundary="=_alternative 005BB65585257117_="

This is a multipart message in MIME format.
--=_alternative 005BB65585257117_=
Content-Type: text/plain; charset="US-ASCII"

Hi,

Tero Kivinen <kivinen@iki.fi> wrote on 02/16/2006 11:10:22 AM:

> Some comments to the ECP/ECC group drafts.

> ...

Very helpful comments, so I'll prepare an ECC-09 to address them. 

Thanks,

Dan Brown
(905) 501-3857
http://www.certicom.com


--=_alternative 005BB65585257117_=
Content-Type: text/html; charset="US-ASCII"


<br><tt><font size=2>Hi,</font></tt>
<br>
<br><tt><font size=2>Tero Kivinen &lt;kivinen@iki.fi&gt; wrote on 02/16/2006
11:10:22 AM:<br>
<br>
&gt; Some comments to the ECP/ECC group drafts.<br>
</font></tt>
<br><tt><font size=2>&gt; ...</font></tt>
<br>
<br><tt><font size=2>Very helpful comments, so I'll prepare an ECC-09 to
address them. </font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br>
<br><tt><font size=2>Dan Brown<br>
(905) 501-3857<br>
http://www.certicom.com</font></tt>
<br>
<br>
--=_alternative 005BB65585257117_=--


--===============0585752059==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

--===============0585752059==--




From ipsec-bounces@ietf.org Fri Feb 17 10:23:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FA7CG-0002Im-5T; Fri, 17 Feb 2006 10:07:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FA7Bd-0001pj-7x; Fri, 17 Feb 2006 10:06:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18347;
	Fri, 17 Feb 2006 10:04:32 -0500 (EST)
From: Pasi.Eronen@nokia.com
Received: from mgw-ext02.nokia.com ([131.228.20.94])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FA7Q3-0004FI-Fv; Fri, 17 Feb 2006 10:21:17 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k1HF6CFF006744; Fri, 17 Feb 2006 17:06:17 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 17 Feb 2006 17:05:55 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 17 Feb 2006 17:05:55 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Feb 2006 17:05:55 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24023FDDD9@esebe105.NOE.Nokia.com>
In-Reply-To: <p06230919c00d95b992ec@[10.20.30.249]>
Thread-Topic: Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to
	Proposed Standard
Thread-Index: AcYrfiukbfTlmFTOToy/IS4Nr3Yr+AIU/VtQ
To: <iesg@ietf.org>, <ipsec@ietf.org>
X-OriginalArrivalTime: 17 Feb 2006 15:05:55.0495 (UTC)
	FILETIME=[A6B9D370:01C633D3]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Ipsec] RE: Last Call: 'IKE and IKEv2 Authentication Using ECDSA'
	to Proposed Standard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org


Some last call comments about draft-ietf-ipsec-ike-auth-ecdsa-05:

1) First of all, it looks like properly reviewing (or implementing)
   this draft is quite difficult if you don't have X9.62. Too bad
   it's not free (as in beer)...

2) References: The reference to X9.62 should be updated to=20
   X9.62-2005 (which was approved in November; i.e., after this=20
   Internet-Draft was published).

3) Section 3: "signature consisting [..] of a pair of integers s=20
   and t": X9.62 calls these integers "r" and "s", and it also=20
   looks like Section 6 uses different symbols than X9.62.=20
   I'd strongly recommend using the same notation!

4) Section 3: "Implementers may find it convenient, when using ECDSA
   as the authentication method, to specify the hash used by ECDSA as=20
   the value of the hash algorithm attribute."

   First of all, this text applies only to IKEv1, as IKEv2 does not
   have a hash algorithm attribute. Second, I think the text is
   misleading.  To me it looks like the signature algorithms are each
   "tied to a particular hash algorithms" (in the RFC2409 Section 5.1
   sense), so it would be perfectly OK to use a different algorithm
   for the signature and IKEv1 hash algorithm attribute, right? The
   "may find it convenient" part smells of interoperability problems
   to me: either the algorithms MUST always be the same, or
   implementations MUST NOT assume they're the same!

5) Section 3: "The Diffie-Hellman group is understood to use the base
   points supplied in [IKE-ECP].  Therefore the selection of IANA
   identifier from the above table completely specifies the parameters
   necessary for verifying the signature."

   According to X9.62 Section 7.4.1, to verify a signature you need
   the message, the signature, the domain parameters, the public key,
   and the hash function. The domain parameters and the public key
   come from the certificate, right? And the hash function is given=20
   by the authentication attribute number. But where does the
   Diffie-Hellman group come in? (Perhaps I'm missing something here,
   I'm not that familiar with EC math details...)

   (IKE/IKEv2 of course do Diffie-Hellman, but ECDSA signatures could
   be used with non-ECC DH as well, or the curve used for ECDSA could
   be totally different from the one used for IKE_SA_INIT DH
   exchange.)

   BTW, if everything except the hash algorithm is already conveyed
   in the certificate, we could just use the IKEv1 hash algorithm
   attribute to indicate the hash algorithm, and a single number for
   ECDSA would be enough (but maybe we still need three for IKEv2).

6) Section 3: "the signature payload SHALL contain an encoding of the
   computed signature consisting of the concatenation of a pair of
   integers s and t."

   Concatenated how? Suggested change: "the signature payload SHALL
   contain a DER-encoded ECDSA-Sig-Value structure as specified=20
   in [X9.62]".

7) Section 5 (IANA Considerations) and Section 2: The current text=20
   covers only IKEv1 authentication algorithm numbers. IKEv2
   has separate registries.

Purely editorial comments:

8) idnits produced number of boilerplate and formatting errors.
   Presumably, the RFC editor will fix most of them.

9) s/IKE-SA-INIT/IKE_SA_INIT/ and s/IKE-AUTH/IKE_AUTH/

10) References: [IANA] is probably not a normative reference,
   maybe not [IKE-ECP] either.

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Feb 17 13:17:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FAAAU-0005Tf-5c; Fri, 17 Feb 2006 13:17:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAAS-0005Ta-IM
	for ipsec@megatron.ietf.org; Fri, 17 Feb 2006 13:17:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18562
	for <ipsec@ietf.org>; Fri, 17 Feb 2006 13:15:32 -0500 (EST)
Received: from palrel11.hp.com ([156.153.255.246])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAAOw-0000CW-5m
	for ipsec@ietf.org; Fri, 17 Feb 2006 13:32:18 -0500
Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net
	[16.92.1.67]) by palrel11.hp.com (Postfix) with ESMTP id 13FEB36A6B
	for <ipsec@ietf.org>; Fri, 17 Feb 2006 10:17:11 -0800 (PST)
Received: from cacexc10.americas.cpqcorp.net ([16.92.1.47]) by
	cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 17 Feb 2006 10:17:10 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Feb 2006 10:17:10 -0800
Message-ID: <FEBDD75B8539E04397626AFDF6747484017E7CA2@cacexc10.americas.cpqcorp.net>
Thread-Topic: Protocol OPAQUE in SPD matches specific protocol in packet?
Thread-Index: AcYzKFJ7ilnIfK0kRLKlzmMwVDHacA==
From: "He, Wenxiao" <wenxiao.he@hp.com>
To: <ipsec@ietf.org>
X-OriginalArrivalTime: 17 Feb 2006 18:17:10.0962 (UTC)
	FILETIME=[5EA32120:01C633EE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: quoted-printable
Subject: [Ipsec] Protocol OPAQUE in SPD matches specific protocol in packet?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org


Hello,

I have a question on OPAQUE. My understanding is that protocol OPAQUE in
SPD does NOT match the specific protocol in packet. However in RFC4301
"4.4.2.2.  Relationship between SPD, PFP flag, packet, and SAD" there is
such an example:

         protocol  list of prot's*   0  prot. "P"    list of prot's*
                   ANY**             0  prot. "P"    ANY
                   OPAQUE****        0  prot. "P"    OPAQUE
<=3D=3D=3D ???

The above line should not result in a creating of SA entry because the
protocol "P" does not match "OPAQUE" in the SPD, correct? Shouldn't it
be changed to something like:

                   OPAQUE****        0  prot. "P"    <SPD/packet not
match>

Thanks,
Wenxiao


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 20 11:17:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBDiH-0000XJ-GI; Mon, 20 Feb 2006 11:16:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDiF-0000X5-Q5
	for ipsec@ietf.org; Mon, 20 Feb 2006 11:16:35 -0500
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBDiC-0003uA-Dh
	for ipsec@ietf.org; Mon, 20 Feb 2006 11:16:35 -0500
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1KGVYVH000012
	for <ipsec@ietf.org>; Mon, 20 Feb 2006 09:31:34 -0700 (MST)
Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5])
	by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k1KGSOCK008044
	for <ipsec@ietf.org>; Mon, 20 Feb 2006 10:28:24 -0600 (CST)
Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72)
	id <DPBJLWKN>; Mon, 20 Feb 2006 11:16:30 -0500
Message-ID: <62173B970AE0A044AED8723C3BCF23810CC861C2@ma19exm01.e6.bcs.mot.com>
From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
To: Michael Hernecq <michael.hernecq@philips.com>
Date: Mon, 20 Feb 2006 11:16:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: ipsec@ietf.org, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>,
	rfc-editor@rfc-editor.org
Subject: [Ipsec] Errata in 4305 RE: Question about RFC 4305
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0716745998=="
Errors-To: ipsec-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0716745998==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C63639.02348530"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C63639.02348530
Content-Type: text/plain

Ahhh.... Looks to me like the Obsoletes header in RFC 4305 should say "2402, 2406". Not "2404, 2406".
 
This should be added to the errata database and fixed in RFC obsoletes/updates database.
 
2404 had not been obsoleted!
 
Donald
 
 From: Michael Hernecq [mailto:michael.hernecq@philips.com]   
Sent: Friday, February 17, 2006 11:13 AM
To: Eastlake III Donald-LDE008
Subject: Question about RFC 4503


Hello, 

I'm software engineer in Philips Semiconductors, and I'm currently reading RFCs related to IPSEC. 
I have a question about the RFC 4305. 

In the header of this RFC it is stated that RFC 2404 is now obsolete, but later in the same documents 
the same RFC is mentionned as MUST. 

In section 3.1.1 
      Requirement    Authentication Algorithm (notes)
     -----------    ------------------------
     MUST           HMAC-SHA1-96 [RFC2404]
     MUST           NULL (1)
     SHOULD+        AES-XCBC-MAC-96 [RFC3566]
     MAY            HMAC-MD5-96 [RFC2403] (2)

In section 3.2 
      Requirement    Algorithm (notes)
     -----------    ---------
     MUST           HMAC-SHA1-96 [RFC2404]
     SHOULD+        AES-XCBC-MAC-96 [RFC3566]
     MAY            HMAC-MD5-96 [RFC2403] (1)


What is the meaning of the obsolete statement ? This is quite strange for me. 
Could you help me to clarify this ? 

Thank you in advance for your answer. 

Best regards,
-- 
Michael Hernecq
Telecom SubSystem
PHILIPS SEMICONDUCTORS
Route d'Angers - 72081 Le Mans Cedex 09 - France          


------_=_NextPart_001_01C63639.02348530
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA2LjAwLjI4MDAuMTUyOCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW
IGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0y
PjxTUEFOIA0KY2xhc3M9ODkwNDQxMjE4LTE4MDIyMDA2PkFoaGguLi4uIExvb2tzIHRvIG1lIGxp
a2UgdGhlIE9ic29sZXRlcyBoZWFkZXIgaW4gUkZDIA0KNDMwNSBzaG91bGQgc2F5ICIyNDAyLCAy
NDA2Ii4gTm90ICIyNDA0LCAyNDA2Ii48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJViBkaXI9bHRy
IGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiAN
CmNsYXNzPTg5MDQ0MTIxOC0xODAyMjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ
ViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9
Mj48U1BBTiANCmNsYXNzPTg5MDQ0MTIxOC0xODAyMjAwNj5UaGlzIHNob3VsZCBiZSBhZGRlZCB0
byB0aGUgZXJyYXRhIGRhdGFiYXNlIGFuZCBmaXhlZCANCmluIFJGQyBvYnNvbGV0ZXMvdXBkYXRl
cyBkYXRhYmFzZS48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+
PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTg5MDQ0
MTIxOC0xODAyMjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFs
aWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCmNs
YXNzPTg5MDQ0MTIxOC0xODAyMjAwNj4yNDA0IGhhZCBub3QgYmVlbiBvYnNvbGV0ZWQhPC9TUEFO
PjwvRk9OVD48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwg
Y29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz04OTA0NDEyMTgtMTgwMjIwMDY+PC9T
UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZh
Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz04OTA0NDEyMTgtMTgw
MjIwMDY+RG9uYWxkPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0
PjxGT05UIHNpemU9KzA+PFNQQU4gDQpjbGFzcz04OTA0NDEyMTgtMTgwMjIwMDY+PC9TUEFOPjwv
Rk9OVD48Rk9OVCBmYWNlPVRhaG9tYT48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz04OTA0NDEy
MTgtMTgwMjIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmY+PC9GT05UPjwvU1BB
Tj48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZP
TlQgZmFjZT1UYWhvbWE+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9ODkwNDQxMjE4LTE4MDIy
MDA2PiZuYnNwOzwvU1BBTj48U1RST05HPkZyb206PC9TVFJPTkc+IE1pY2hhZWwgSGVybmVjcSAN
ClttYWlsdG86bWljaGFlbC5oZXJuZWNxQHBoaWxpcHMuY29tXSZuYnNwOzxTUEFOIA0KY2xhc3M9
ODkwNDQxMjE4LTE4MDIyMDA2PiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIGZhY2U9
VGFob21hPjxGT05UIA0Kc2l6ZT0yPjxTUEFOIGNsYXNzPTg5MDQ0MTIxOC0xODAyMjAwNj4mbmJz
cDs8L1NQQU4+PEJSPjxCPlNlbnQ6PC9CPiBGcmlkYXksIA0KRmVicnVhcnkgMTcsIDIwMDYgMTE6
MTMgQU08QlI+PEI+VG86PC9CPiBFYXN0bGFrZSBJSUkgDQpEb25hbGQtTERFMDA4PEJSPjxCPlN1
YmplY3Q6PC9CPiBRdWVzdGlvbiBhYm91dCBSRkMgNDxTUEFOIA0KY2xhc3M9ODkwNDQxMjE4LTE4
MDIyMDA2PjUwMzwvU1BBTj48QlI+PC9GT05UPjwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjwvRElW
PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTg5MDQ0MTIxOC0xODAy
MjAwNj48Rk9OVCANCmZhY2U9VGFob21hPkg8L0ZPTlQ+PC9TUEFOPmVsbG8sPC9GT05UPjwvRk9O
VD4gPEJSPjxCUj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPkknbSBzb2Z0d2FyZSBlbmdpbmVl
ciBpbiBQaGlsaXBzIFNlbWljb25kdWN0b3JzLCBhbmQgSSdtIGN1cnJlbnRseSANCnJlYWRpbmcg
UkZDcyByZWxhdGVkIHRvIElQU0VDLjwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y
PkkgaGF2ZSBhIA0KcXVlc3Rpb24gYWJvdXQgdGhlIFJGQyA0MzA1LjwvRk9OVD4gPEJSPjxCUj48
Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JbiB0aGUgDQpoZWFkZXIgb2YgdGhpcyBSRkMgaXQgaXMg
c3RhdGVkIHRoYXQgUkZDIDI0MDQgaXMgbm93IG9ic29sZXRlLCBidXQgbGF0ZXIgaW4gdGhlIA0K
c2FtZSBkb2N1bWVudHM8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj50aGUgc2Ft
ZSBSRkMgaXMgbWVudGlvbm5lZCBhcyANCk1VU1QuPC9GT05UPiA8QlI+PEJSPjxGT05UIGZhY2U9
QXJpYWwgc2l6ZT0yPkluIHNlY3Rpb24gMy4xLjE8L0ZPTlQ+IDxCUj48Rk9OVCANCmZhY2U9QXJp
YWwgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFJlcXVpcmVtZW50ICZuYnNwOyAmbmJzcDtB
dXRoZW50aWNhdGlvbiANCkFsZ29yaXRobSAobm90ZXMpPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7
LS0tLS0tLS0tLS0gJm5ic3A7IA0KJm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPiZu
YnNwOyAmbmJzcDsgJm5ic3A7TVVTVCAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiZuYnNwOyAmbmJz
cDsgSE1BQy1TSEExLTk2IFtSRkMyNDA0XTxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwO01VU1QgJm5i
c3A7ICZuYnNwOyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7IE5VTEwgKDEpPEJSPiZuYnNwOyAmbmJz
cDsgJm5ic3A7U0hPVUxEKyAmbmJzcDsgJm5ic3A7IA0KJm5ic3A7ICZuYnNwO0FFUy1YQ0JDLU1B
Qy05NiBbUkZDMzU2Nl08QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtNQVkgJm5ic3A7ICZuYnNwOyAN
CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hNQUMtTUQ1LTk2IFtSRkMyNDAzXSAoMik8QlI+
PC9GT05UPjxCUj48Rk9OVCANCmZhY2U9QXJpYWwgc2l6ZT0yPkluIHNlY3Rpb24gMy4yPC9GT05U
PiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7IA0KJm5ic3A7ICZuYnNwOyBSZXF1
aXJlbWVudCAmbmJzcDsgJm5ic3A7QWxnb3JpdGhtIChub3Rlcyk8QlI+Jm5ic3A7ICZuYnNwOyAN
CiZuYnNwOy0tLS0tLS0tLS0tICZuYnNwOyAmbmJzcDstLS0tLS0tLS08QlI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDtNVVNUICZuYnNwOyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBITUFDLVNI
QTEtOTYgW1JGQzI0MDRdPEJSPiZuYnNwOyAmbmJzcDsgDQombmJzcDtTSE9VTEQrICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwO0FFUy1YQ0JDLU1BQy05NiBbUkZDMzU2Nl08QlI+Jm5ic3A7IA0K
Jm5ic3A7ICZuYnNwO01BWSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O0hNQUMtTUQ1LTk2IFtSRkMyNDAzXSANCigxKTxCUj48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBmYWNl
PUFyaWFsIHNpemU9Mj5XaGF0IGlzIHRoZSBtZWFuaW5nIG9mIHRoZSANCm9ic29sZXRlIHN0YXRl
bWVudCA/IFRoaXMgaXMgcXVpdGUgc3RyYW5nZSBmb3IgbWUuPC9GT05UPiA8QlI+PEZPTlQgZmFj
ZT1BcmlhbCANCnNpemU9Mj5Db3VsZCB5b3UgaGVscCBtZSB0byBjbGFyaWZ5IHRoaXMgPzwvRk9O
VD4gPEJSPjxCUj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPlRoYW5rIHlvdSBpbiBhZHZhbmNl
IGZvciB5b3VyIGFuc3dlci48L0ZPTlQ+IDxCUj48QlI+PEZPTlQgDQpmYWNlPXNhbnMtc2VyaWYg
c2l6ZT0yPkJlc3QgcmVnYXJkcyw8QlI+LS0gPEJSPk1pY2hhZWwgSGVybmVjcTxCUj5UZWxlY29t
IA0KU3ViU3lzdGVtPEJSPlBISUxJUFMgU0VNSUNPTkRVQ1RPUlM8QlI+Um91dGUgZCdBbmdlcnMg
LSA3MjA4MSBMZSBNYW5zIENlZGV4IDA5IC0gDQpGcmFuY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOzxCUj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg==

------_=_NextPart_001_01C63639.02348530--


--===============0716745998==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

--===============0716745998==--




From ipsec-bounces@ietf.org Mon Feb 20 11:33:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBDwd-0002I2-UN; Mon, 20 Feb 2006 11:31:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDwc-0002Hp-Jd
	for ipsec@ietf.org; Mon, 20 Feb 2006 11:31:26 -0500
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBDwc-0004er-AF
	for ipsec@ietf.org; Mon, 20 Feb 2006 11:31:26 -0500
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1KGkStk004435
	for <ipsec@ietf.org>; Mon, 20 Feb 2006 09:46:28 -0700 (MST)
Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5])
	by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k1KGhw2X011821
	for <ipsec@ietf.org>; Mon, 20 Feb 2006 10:43:58 -0600 (CST)
Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72)
	id <DPBJLW3M>; Mon, 20 Feb 2006 11:31:24 -0500
Message-ID: <62173B970AE0A044AED8723C3BCF23810CC86221@ma19exm01.e6.bcs.mot.com>
From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
To: "'IPsec'" <ipsec@ietf.org>
Subject: RE: [Ipsec] Errata RFC4305
Date: Mon, 20 Feb 2006 11:31:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: Russ Housley <housley@vigilsec.com>, rfc-editor@rfc-editor.org
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Steve/Lars,

Since 2402 and 2406 are Obsoleted, it is desirable for the complete =
list of RFCs which obsolete/replace them to be clear from the RFC =
database when searched. Thus, for example, both 4302 and 4305 should be =
listed in the "Obsoleted by" list for RFC 2402 even if the bulk is =
obsoleted by 4302 and only a small part obsoleted by 4305.

It is a simple typo, as per the other message I just posted and cc'ed =
to the RFC-Editor as well as Ipsec, that RFC 4305 says at the top of =
its first page that it obsoletes "2404, 2406". It should say "2402, =
2406". It does not, as far as I can see, say "2402, 2404" as implied by =
the first message below.

Donald

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf =
Of Stephen Kent
Sent: Monday, February 06, 2006 11:53 AM
To: Lars V=F6lker
Cc: 'IPsec'; 'Russ Housley'
Subject: RE: [Ipsec] Errata RFC4305

At 9:42 AM +0100 2/6/06, Lars V=F6lker wrote:
>Hi!
>
>Is this a bug that RFC 4305 obsoletes 2402 (AH) and 2404 (SHA1)?
>4305 says that 2404 is a must but also obsoletes it? Shouldn't it=20
>obsolete 2402 (AH) and 2406 (ESP)? Do I miss a point?
>
>Lars

2402 is replaced by 4302, and 2406 is replaced by 4303, which is what =
the headers of these new RFCs state.

This document supercedes very small parts of 2402 and 2406, but it is =
not the replacement for those=20
documents.   2404 was a narrow document,=20
specifying how to use HMAC-SHA-1 with AH and ESP.=20
I agree that 4305 should NOT be considered a replacement for 2404 OR =
for 2406.  These are errors.

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Feb 27 17:48:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDr9z-0000Mo-B3; Mon, 27 Feb 2006 17:48:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDr9y-0000Mb-9u
	for ipsec@ietf.org; Mon, 27 Feb 2006 17:48:06 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDr9x-0003PP-Tv
	for ipsec@ietf.org; Mon, 27 Feb 2006 17:48:06 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k1RMm4IJ078646
	for <ipsec@ietf.org>; Mon, 27 Feb 2006 15:48:05 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06230941c02932140a00@[10.20.30.249]>
Date: Mon, 27 Feb 2006 14:47:59 -0800
To: IPsec WG <ipsec@ietf.org>
From: rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Subject: [Ipsec] RFC 4434 on The AES-XCBC-PRF-128 Algorithm for the Internet
 Key Exchange Protocol (IKE)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org


A new Request for Comments is now available in online RFC libraries.


         RFC 4434

         Title:      The AES-XCBC-PRF-128 Algorithm for the
                     Internet Key Exchange Protocol (IKE)
         Author:     P. Hoffman
         Status:     Standards Track
         Date:       February 2006
         Mailbox:    paul.hoffman@vpnc.org
         Pages:      6
         Characters: 9384
         Obsoletes:  RFC3664
         See-Also:

         I-D Tag:    draft-hoffman-rfc3664bis-05.txt

         URL:        http://www.rfc-editor.org/rfc/rfc4434.txt

Some implementations of IP Security (IPsec) may want to use a
pseudo-random function derived from the Advanced Encryption Standard
(AES).  This document describes such an algorithm, called 
AES-XCBC-PRF-128.  [STANDARDS TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and
suggestions for improvements.Please refer to the current edition of the
Internet Official Protocol Standards (STD 1) for the standardization state
and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body

help: ways_to_get_rfcs. For example:

         To: rfc-info@RFC-EDITOR.ORG
         Subject: getting rfcs

         help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Tue Feb 28 20:43:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEGND-0007ms-F2; Tue, 28 Feb 2006 20:43:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEGNC-0007hi-Fz
	for ipsec@ietf.org; Tue, 28 Feb 2006 20:43:26 -0500
Received: from smtp1.suda.edu.cn ([202.195.128.15])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEGN5-0004z3-1h
	for ipsec@ietf.org; Tue, 28 Feb 2006 20:43:26 -0500
Received: from proxy3.suda.edu.cn ([202.195.128.8]) by smtp1.suda.edu.cn with
	InterScan Messaging Security Suite; Wed, 01 Mar 2006 09:58:35 +0800
Received: from dcy (unknown [210.29.174.137])
	by proxy3.suda.edu.cn (PMail) with ESMTP id 88CC86CA09
	for <ipsec@ietf.org>; Wed,  1 Mar 2006 09:32:39 +0800 (CST)
Date: Wed, 1 Mar 2006 09:45:44 +0800
From: "=?GB2312?B?ILbFtLrR4ChEVSBDaHVuLXlhbik=?=" <210313041@suda.edu.cn>
To: "ipsec@ietf.org" <ipsec@ietf.org>
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Message-Id: <20060301013239.88CC86CA09@proxy3.suda.edu.cn>
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Subject: [Ipsec] each side uses different authentication method?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1142202564=="
Errors-To: ipsec-bounces@ietf.org

--===============1142202564==
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGksDQoNCkluIHNlY3Rpb24gMi4xNSBvZiBSRkM0MzA2o6wiVGhlcmUgaXMgbm8gcmVxdWlybWVu
dCB0aGF0IHRoZSBpbml0aWF0b3IgYW5kIHJlc3BvbmRlciBzaWduIHdpdGggdGhlIHNhbWUgY3J5
cHRvZ3JhcGhpYyBhbGdvcml0aG1zLiIiSW4gcGFydGljdWxhciwgdGhlIGluaXRpYXRvciBtYXkg
YmUgdXNpbmcgYSBzaGFyZWQga2V5IHdoaWxlIHRoZSByZXNwb25kZXIgbWF5IGhhdmUgYSBwdWJs
aWMgc2lnbmF0dXJlIGtleSBhbmQgY2VydGlmaWNhdGUuIg0KSG93IGNvdWxkIGl0IGJlIHBvc3Np
YmxlPyAgRG9lcyBpdCBtZWFuIHRoYXQgZWFjaCBzaWRlIGZpcnN0bHkgdXNlcyB0aGUgc2hhcmUg
c2VjcmV0IGtleSBhbmQgdGhlbiB1c2VzIHNpZ25hdHVyZSBtZXRob2QsIG5hbWVseSBkb2luZyBh
dXRoZW50aWNhdGlvbiB0d2ljZSB0byBjb21wbGV0ZSBJS0VfQVVUSCBleGNoYW5nZT8NClRoYW5r
cyBmb3IgaGVscC4gICANCg0KCQ0KDQoNCqGhoaGhoaGhoaGhoaGhoaFEVSBDaHVuLXlhbg0KoaGh
oaGhoaGhoaGhoaGhoTIxMDMxMzA0MUBzdWRhLmVkdS5jbg0KoaGhoaGhoaGhoaGhoaGhoaGhoaEy
MDA2LTAyLTI4DQo=



--===============1142202564==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

--===============1142202564==--