From owner-ipsec@lists.tislabs.com Fri Feb 1 09:19:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11HJt310628; Fri, 1 Feb 2002 09:19:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26672 Fri, 1 Feb 2002 11:00:51 -0500 (EST) From: dfox@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A018EACED@email.quarrytech.com> To: jerry.wang@tumbleweed.com Cc: ipsec@lists.tislabs.com Subject: RE: interoperability of IPSec between solaris 8 and win2k Date: Fri, 1 Feb 2002 11:11:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB3B.0BB8B8C0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C1AB3B.0BB8B8C0 Content-Type: text/plain; charset="iso-8859-1" Jerry, That isn't all that unusual. While they may not be able to do dynamic negotiation of keys, you should still be able to verify interoperability with manual tunnels. What you would be verifying in this case is that the IPsec encryption, AH and/or ESP, was working. The "restriction" in Solaris 8 for having the key comprised of the authentication and encryption keys is not unique. I previously tested the SSR family of routers at Cabletron, which had IPsec support. That was exactly how we specified the keys. The software then split up the provided key in the correct proportions to satisfy the authentication and encryption key needs. In that case, depending on the hashing and encryption algorithms that you choose, you will need to provide a long enough key for both. In the Win2K environment, you'll need to figure out where the split in the key is so that you can specify them separately, if that is how Win2K requires them to be specified. With two different implementations, the trick is to specify the parameters to both implementations, in their native management environment, such that they will be able to communicate. You should be able to make it happen after a little trial and error, I suspect. I am not aware if they have been submitted for a mark from VPNC or ICSA. If they were, and received their respective mark for whatever subset they were submitted to be tested against, then they will have been tested for interoperability with the lab's "reference set" of routers. If they passed, then you've got your interoperability answer. ICSA is at www.icsalabs.com and VPNC is at www.vpnc.org . Good luck! David Fox =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Fox Quarry Technologies dfox@quarrytech.com 8 New England Executive Park Direct: 781-359-5094 Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 www.quarrytech.com FAX: 781-505-8316 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: jerry.wang@tumbleweed.com [mailto:jerry.wang@tumbleweed.com] Sent: Wednesday, January 30, 2002 4:55 PM To: ipsec@lists.tislabs.com Subject: interoperability of IPSec between solaris 8 and win2k Hi all, I am testing the interoperability of IPSec between the native support from solaris 8 and win2k. It seems not possible due to the fact that solaris 8's ipsec implementation is not full-fledged, and it only allows for manual keyed sa. Also the length of the keys is dependent on the authentication and encryption algorithm on solaris 8 while win2k doesn't seem to have this constraint. Win2k configuration tool only allows for authentication key to be manually configured, not encryption key. So I can't see how these two would work together. Does anyone have a similar experiment and draw the same or opposite conclusions? Thanks. ------_=_NextPart_001_01C1AB3B.0BB8B8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

J= erry,

<= span style=3D'mso-tab-count:1'>       &nbs= p;    That isn’t all that unusual.  = While they may not be able to do dynamic negotiation of keys, you should still be = able to verify interoperability with manual tunnels.  What you would be verifying in this case is that the = IPsec encryption, AH and/or ESP, was = working.

<= ![if = !supportEmptyParas]> 

=

<= span style=3D'mso-tab-count:1'>       &nbs= p;    The “restriction” in Solaris 8 for having the key comprised of = the authentication and encryption keys is not unique.  I previously tested the SSR family of routers at Cabletron, = which had IPsec support.  That was = exactly how we specified the keys.  = The software then split up the provided key in the correct proportions to satisfy = the authentication and encryption key needs.  In that case, depending on the hashing and encryption algorithms = that you choose, you will need to provide a long enough key for both.  In the Win2K environment, = you’ll need to figure out where the split in the key is so that you can specify = them separately, if that is how Win2K requires them to be = specified.

<= ![if = !supportEmptyParas]> 

=

<= span style=3D'mso-tab-count:1'>       &nbs= p;    With two different implementations, the trick is to specify the parameters = to both implementations, in their native management environment, such that they = will be able to communicate.  You = should be able to make it happen after a little trial and error, I = suspect.

<= ![if = !supportEmptyParas]> 

=

<= span style=3D'mso-tab-count:1'>       &nbs= p;    I am not aware if they have been submitted for a mark from VPNC or = ICSA.  If they were, and received = their respective mark for whatever subset they were submitted to be tested = against, then they will have been tested for interoperability with the = lab’s “reference set” of routers.  = If they passed, then you’ve got your interoperability answer.  ICSA is at www.icsalabs.com and VPNC is at www.vpnc.org.  

<= ![if = !supportEmptyParas]> 

=

G= ood luck!

<= ![if = !supportEmptyParas]> 

=

<= span style=3D'mso-tab-count:1'>       &nbs= p;    David Fox

<= /p>

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D<= /p>

David Fox           &= nbsp;           &= nbsp;                    &= nbsp;   <= /p>

Quarry Technologies           &= nbsp;           &= nbsp;        dfox@quarrytech.com<= /p>

8 New England Executive Park           &= nbsp;   Direct: 781-359-5094<= /p>

Burlington, Massachusetts  01803         Main: = 781-505-8300 x5094<= /p>

www.quarrytech.com           &= nbsp;           &= nbsp;         FAX:   = 781-505-8316<= /p>

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D<= /p>

=  

=

-----Original Message-----
From: = jerry.wang@tumbleweed.com [mailto:jerry.wang@tumbleweed.com]
Sent: Wednesday, January = 30, 2002 4:55 PM
To: = ipsec@lists.tislabs.com
Subject: = interoperability of IPSec between solaris 8 and win2k

 

Hi = all,=

 =

I am testing the interoperability of IPSec between the native support from = solaris 8 and win2k. It seems not possible due to the fact that solaris 8's ipsec implementation is not full-fledged, and it only allows for manual keyed = sa. Also the length of the keys is dependent on the authentication and = encryption algorithm on solaris 8 while win2k doesn't seem to have this = constraint. Win2k configuration tool only allows for authentication key to be = manually configured, not encryption key. =

 =

So I can't see how these two would work together. Does anyone have a similar experiment and draw the same or opposite conclusions? = Thanks.=

 =

------_=_NextPart_001_01C1AB3B.0BB8B8C0-- From owner-ipsec@lists.tislabs.com Fri Feb 1 09:23:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11HN0310727; Fri, 1 Feb 2002 09:23:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26747 Fri, 1 Feb 2002 11:24:36 -0500 (EST) Message-ID: <009701c1ab3e$64a806e0$6501a8c0@samwise> From: "Jerry Wang" To: Cc: References: <496A8683261CD211BF6C0008C733261A018EACED@email.quarrytech.com> Subject: Re: interoperability of IPSec between solaris 8 and win2k Date: Fri, 1 Feb 2002 11:34:53 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C1AB14.779E4040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C1AB14.779E4040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. I tried to figure out how solaris and win2k managed the keys so = that I could make them compatible at the configuration level (not the = user interface level) by supplying carefully picked keys. So far I = haven't gotten any luck. Jerry ----- Original Message -----=20 From: dfox@quarrytech.com=20 To: jerry.wang@tumbleweed.com=20 Cc: ipsec@lists.tislabs.com=20 Sent: Friday, February 01, 2002 11:11 AM Subject: RE: interoperability of IPSec between solaris 8 and win2k Jerry, That isn't all that unusual. While they may not be able = to do dynamic negotiation of keys, you should still be able to verify = interoperability with manual tunnels. What you would be verifying in = this case is that the IPsec encryption, AH and/or ESP, was working. =20 The "restriction" in Solaris 8 for having the key = comprised of the authentication and encryption keys is not unique. I = previously tested the SSR family of routers at Cabletron, which had = IPsec support. That was exactly how we specified the keys. The = software then split up the provided key in the correct proportions to = satisfy the authentication and encryption key needs. In that case, = depending on the hashing and encryption algorithms that you choose, you = will need to provide a long enough key for both. In the Win2K = environment, you'll need to figure out where the split in the key is so = that you can specify them separately, if that is how Win2K requires them = to be specified. =20 With two different implementations, the trick is to = specify the parameters to both implementations, in their native = management environment, such that they will be able to communicate. You = should be able to make it happen after a little trial and error, I = suspect. =20 I am not aware if they have been submitted for a mark from = VPNC or ICSA. If they were, and received their respective mark for = whatever subset they were submitted to be tested against, then they will = have been tested for interoperability with the lab's "reference set" of = routers. If they passed, then you've got your interoperability answer. = ICSA is at www.icsalabs.com and VPNC is at www.vpnc.org. =20 =20 Good luck! =20 David Fox = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D David Fox =20 Quarry Technologies dfox@quarrytech.com 8 New England Executive Park Direct: 781-359-5094 Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 www.quarrytech.com FAX: 781-505-8316 = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D =20 -----Original Message----- From: jerry.wang@tumbleweed.com [mailto:jerry.wang@tumbleweed.com] Sent: Wednesday, January 30, 2002 4:55 PM To: ipsec@lists.tislabs.com Subject: interoperability of IPSec between solaris 8 and win2k =20 Hi all, =20 I am testing the interoperability of IPSec between the native support = from solaris 8 and win2k. It seems not possible due to the fact that = solaris 8's ipsec implementation is not full-fledged, and it only allows = for manual keyed sa. Also the length of the keys is dependent on the = authentication and encryption algorithm on solaris 8 while win2k doesn't = seem to have this constraint. Win2k configuration tool only allows for = authentication key to be manually configured, not encryption key.=20 =20 So I can't see how these two would work together. Does anyone have a = similar experiment and draw the same or opposite conclusions? Thanks. =20 ------=_NextPart_000_0092_01C1AB14.779E4040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks. I tried to figure out how = solaris and win2k=20 managed the keys so that I could make them compatible at the = configuration level=20 (not the user interface level) by supplying carefully picked keys. So = far I=20 haven't gotten any luck.
 
Jerry
 
----- Original Message -----
From:=20 dfox@quarrytech.com
Sent: Friday, February 01, 2002 = 11:11=20 AM
Subject: RE: interoperability = of IPSec=20 between solaris 8 and win2k

Jerry,

           =20 That isn’t all that unusual. =20 While they may not be able to do dynamic negotiation of keys, = you=20 should still be able to verify interoperability with manual = tunnels.  What you would be verifying = in this=20 case is that the IPsec encryption, AH and/or ESP, was=20 working.

 

           =20 The “restriction” in Solaris 8 for having the key = comprised of the=20 authentication and encryption keys is not unique.  I previously tested the SSR = family of=20 routers at Cabletron, which had IPsec support.  That was exactly how we = specified the=20 keys.  The software then = split up=20 the provided key in the correct proportions to satisfy the = authentication and=20 encryption key needs.  = In that=20 case, depending on the hashing and encryption algorithms that you = choose, you=20 will need to provide a long enough key for both.  In the Win2K environment, = you’ll need=20 to figure out where the split in the key is so that you can specify = them=20 separately, if that is how Win2K requires them to be=20 specified.

 

           =20 With two different implementations, the trick is to specify the = parameters to both implementations, in their native management = environment,=20 such that they will be able to communicate.  You should be able to make = it happen=20 after a little trial and error, I = suspect.

 

           =20 I am not aware if they have been submitted for a mark from VPNC = or=20 ICSA.  If they were, and = received=20 their respective mark for whatever subset they were submitted to be = tested=20 against, then they will have been tested for interoperability with the = lab’s=20 “reference set” of routers.  If=20 they passed, then you’ve got your interoperability answer.  ICSA is at www.icsalabs.com and VPNC is at = www.vpnc.org.  

 

Good=20 luck!

 

           =20 David Fox

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D

David Fox           &n= bsp;           &nb= sp;        =20            &n= bsp;   

Quarry Technologies           &n= bsp;           &nb= sp;       =20 dfox@quarrytech.com

8 New England Executive = Park           &n= bsp;  =20 Direct: 781-359-5094

Burlington, Massachusetts  01803        =20 Main: 781-505-8300 x5094

www.quarrytech.com           &n= bsp;           &nb= sp;        =20 FAX:  =20 781-505-8316

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D

<= SPAN=20 class=3DEmailStyle15> 

-----Original=20 Message-----
From:=20 jerry.wang@tumbleweed.com = [mailto:jerry.wang@tumbleweed.com]
Sent: Wednesday, January 30, = 2002 4:55=20 PM
To:=20 ipsec@lists.tislabs.com
Subject: interoperability of = IPSec=20 between solaris 8 and win2k

 

Hi=20 all,

 

I am=20 testing the interoperability of IPSec between the native support from = solaris=20 8 and win2k. It seems not possible due to the fact that solaris 8's = ipsec=20 implementation is not full-fledged, and it only allows for manual = keyed sa.=20 Also the length of the keys is dependent on the authentication and = encryption=20 algorithm on solaris 8 while win2k doesn't seem to have this = constraint.=20 Win2k configuration tool only allows for authentication key to be = manually configured, not encryption key.

 

So I=20 can't see how these two would work together. Does anyone have a = similar=20 experiment and draw the same or opposite conclusions?=20 Thanks.

 

------=_NextPart_000_0092_01C1AB14.779E4040-- From owner-ipsec@lists.tislabs.com Fri Feb 1 12:30:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11KUa316105; Fri, 1 Feb 2002 12:30:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27204 Fri, 1 Feb 2002 14:35:40 -0500 (EST) From: "Andrew Wenlang Zhu" To: Subject: What is the standardization status of AES in IPSec? Date: Fri, 1 Feb 2002 11:45:56 -0800 Message-ID: <001001c1ab59$11becac0$6f690d0f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello: Can any one give me an update on the standardization status of using AES in IPSec? I am reading “The AES Cipher Algorithm and Its Use With IPsec” and read “ Once NIST has published the AES FIPS ... AES should become a default and mandatory-to-implement cipher algorithm for IPSec”. FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is expected to come out? Thanks, --------------------------------------- Andrew Zhu HP Systems Networking Solution Lab IP Security & System Firewall Project Andrew_zhu@hp.com From owner-ipsec@lists.tislabs.com Fri Feb 1 12:51:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11Kpg316737; Fri, 1 Feb 2002 12:51:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27354 Fri, 1 Feb 2002 15:01:20 -0500 (EST) Message-ID: <00cd01c1ab5c$9f0b1890$9080ad40@cisco.com> From: "Scott Fanning" To: "Andrew Wenlang Zhu" , References: <001001c1ab59$11becac0$6f690d0f@AZ735043> Subject: Re: What is the standardization status of AES in IPSec? Date: Fri, 1 Feb 2002 11:59:25 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk and on that note.. If AES is the MUST implement algorithm, does that include all key sizes? Scott ----- Original Message ----- From: "Andrew Wenlang Zhu" To: Sent: Friday, February 01, 2002 11:45 AM Subject: What is the standardization status of AES in IPSec? > Hello: > > Can any one give me an update on the standardization status of using AES in > IPSec? > > I am reading "The AES Cipher Algorithm and Its Use With IPsec" > and read " Once NIST has published > the AES FIPS ... AES should become a default and mandatory-to-implement > cipher algorithm for IPSec". > > FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is expected to come out? > > Thanks, > --------------------------------------- > Andrew Zhu > HP Systems Networking Solution Lab > IP Security & System Firewall Project > Andrew_zhu@hp.com > > From owner-ipsec@lists.tislabs.com Fri Feb 1 13:09:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11L99317226; Fri, 1 Feb 2002 13:09:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27412 Fri, 1 Feb 2002 15:20:13 -0500 (EST) From: dfox@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A018EACF0@email.quarrytech.com> To: jerry.wang@tumbleweed.com, dfox@quarrytech.com Cc: ipsec@lists.tislabs.com Subject: RE: interoperability of IPSec between solaris 8 and win2k Date: Fri, 1 Feb 2002 12:03:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB42.6BF58BD0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C1AB42.6BF58BD0 Content-Type: text/plain; charset="iso-8859-1" Jerry, Can't help you with the specifics of Solaris and Win2K as I haven't had to use them, as yet. When I hear someone talk about "managing" the keys, I think of dynamic tunnels using ISAKMP. I could be wrong but I don't think there is anything you have to "manage" with manual tunnels. You are statically going to pick key values that aren't going to change. For simplicity in testing, you can use the same key for in-bound and out-bound manual keys. You just need to split them according to the requirements of the authentication and encryption needs. To further simplify, until you get the first tunnel running, why not try just AH or just ESP encryption? The key lengths will be smaller and you won't have to worry about keying multiple protocols. If you don't have the list handy, here are the key lengths required by the algorithms: - Authentication: MD5 - 16 bytes SHA-1 - 20 bytes - Encryption: DES - 8 bytes Triple-DES - 24 bytes If you need to use different keys, remember that the OUT-bound key and SPI on one side is the IN-bound key and SPI on the other side. Maybe someone else can chime in with specifics on the two implementations? Good luck! David =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Fox Quarry Technologies dfox@quarrytech.com 8 New England Executive Park Direct: 781-359-5094 Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 www.quarrytech.com FAX: 781-505-8316 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: Jerry Wang [mailto:jerry.wang@tumbleweed.com] Sent: Friday, February 01, 2002 11:35 AM To: dfox@quarrytech.com Cc: ipsec@lists.tislabs.com Subject: Re: interoperability of IPSec between solaris 8 and win2k Thanks. I tried to figure out how solaris and win2k managed the keys so that I could make them compatible at the configuration level (not the user interface level) by supplying carefully picked keys. So far I haven't gotten any luck. Jerry ----- Original Message ----- From: dfox@quarrytech.com To: jerry.wang@tumbleweed.com Cc: ipsec@lists.tislabs.com Sent: Friday, February 01, 2002 11:11 AM Subject: RE: interoperability of IPSec between solaris 8 and win2k Jerry, That isn't all that unusual. While they may not be able to do dynamic negotiation of keys, you should still be able to verify interoperability with manual tunnels. What you would be verifying in this case is that the IPsec encryption, AH and/or ESP, was working. The "restriction" in Solaris 8 for having the key comprised of the authentication and encryption keys is not unique. I previously tested the SSR family of routers at Cabletron, which had IPsec support. That was exactly how we specified the keys. The software then split up the provided key in the correct proportions to satisfy the authentication and encryption key needs. In that case, depending on the hashing and encryption algorithms that you choose, you will need to provide a long enough key for both. In the Win2K environment, you'll need to figure out where the split in the key is so that you can specify them separately, if that is how Win2K requires them to be specified. With two different implementations, the trick is to specify the parameters to both implementations, in their native management environment, such that they will be able to communicate. You should be able to make it happen after a little trial and error, I suspect. I am not aware if they have been submitted for a mark from VPNC or ICSA. If they were, and received their respective mark for whatever subset they were submitted to be tested against, then they will have been tested for interoperability with the lab's "reference set" of routers. If they passed, then you've got your interoperability answer. ICSA is at www.icsalabs.com and VPNC is at www.vpnc.org . Good luck! David Fox =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Fox Quarry Technologies dfox@quarrytech.com 8 New England Executive Park Direct: 781-359-5094 Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 www.quarrytech.com FAX: 781-505-8316 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: jerry.wang@tumbleweed.com [mailto:jerry.wang@tumbleweed.com] Sent: Wednesday, January 30, 2002 4:55 PM To: ipsec@lists.tislabs.com Subject: interoperability of IPSec between solaris 8 and win2k Hi all, I am testing the interoperability of IPSec between the native support from solaris 8 and win2k. It seems not possible due to the fact that solaris 8's ipsec implementation is not full-fledged, and it only allows for manual keyed sa. Also the length of the keys is dependent on the authentication and encryption algorithm on solaris 8 while win2k doesn't seem to have this constraint. Win2k configuration tool only allows for authentication key to be manually configured, not encryption key. So I can't see how these two would work together. Does anyone have a similar experiment and draw the same or opposite conclusions? Thanks. ------_=_NextPart_001_01C1AB42.6BF58BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jerry,

     &nb= sp;      Can’t help you with the specifics of Solaris and Win2K as I haven’t had = to use them, as yet.  =

 

=

       &nbs= p;    When I hear someone talk about “managing” the keys, I think of = dynamic tunnels using ISAKMP.  I could be wrong = but I don’t think there is anything you have to “manage” with manual = tunnels.  You are statically going to = pick key values that aren’t going to change.  For simplicity in testing, you can use the same key for in-bound = and out-bound manual keys.  = You just need to split them according to the requirements of the authentication = and encryption needs.  To further = simplify, until you get the first tunnel running, why not try just AH or just ESP encryption?  The key = lengths will be smaller and you won’t have to worry about keying multiple = protocols.

 

=

       &nbs= p;    If you don’t have the list handy, here are the key lengths required = by the algorithms:

 

=

-          Authentication:        = MD5 – 16 bytes

SHA-1 – 20 = bytes

 

=

-          Encryption:        &nbs= p;     DES – 8 bytes

T= riple-DES – 24 bytes

 

=

If you need to use different keys, remember that the OUT-bound = key and SPI on one side is the IN-bound key and SPI on the other = side.

 

=

Maybe someone else can chime in with specifics on the two implementations?

 

=

Good luck!

       &nbs= p;    David

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D

David Fox           &= nbsp;           &= nbsp;                    &= nbsp;   

Quarry Technologies           &= nbsp;           &= nbsp;        dfox@quarrytech.com

8 New England Executive = Park           &= nbsp;   Direct: 781-359-5094

Burlington, Massachusetts  01803         Main: = 781-505-8300 x5094

www.quarrytech.com           &= nbsp;           &= nbsp;         FAX:   = 781-505-8316

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D

= <= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Jerry Wang [mailto:jerry.wang@tumbleweed.com]
Sent: Friday, February = 01, 2002 11:35 AM
To: = dfox@quarrytech.com
Cc: = ipsec@lists.tislabs.com
Subject: Re: = interoperability of IPSec between solaris 8 and win2k

 

Thanks. I tried to figure out how solaris and win2k managed the keys so that I = could make them compatible at the configuration level (not the user interface = level) by supplying carefully picked keys. So far I haven't gotten any = luck.=

 =

Jerry=

 =

----- Original Message -----

To: jerry.wang@tumbleweed.com

Cc: ipsec@lists.tislabs.com

Sent: Friday, February 01, 2002 11:11 AM

Subject: RE: interoperability of IPSec between solaris 8 and = win2k

 =

Jerry,

       &nbs= p;   That isn’t all that unusual.  = While they may not be able to do dynamic negotiation of keys, you should still be = able to verify interoperability with manual tunnels.  What you would be verifying in this case is that the = IPsec encryption, AH and/or ESP, was = working.

 

       &nbs= p;   The “restriction” in Solaris 8 for having the key comprised of = the authentication and encryption keys is not unique.  I previously tested the SSR family of routers at Cabletron, = which had IPsec support.  That was = exactly how we specified the keys.  = The software then split up the provided key in the correct proportions to = satisfy the authentication and encryption key needs.  In that case, depending on the hashing and = encryption algorithms that you choose, you will need to provide a long enough key = for both.  In the Win2K = environment, you’ll need to figure out where the split in the key is so that = you can specify them separately, if that is how Win2K requires them to be = specified.

 

       &nbs= p;   With two different implementations, the trick is to specify the parameters = to both implementations, in their native management environment, such that they = will be able to communicate.  You = should be able to make it happen after a little trial and error, I = suspect.

 

       &nbs= p;   I am not aware if they have been submitted for a mark from VPNC or = ICSA.  If they were, and received = their respective mark for whatever subset they were submitted to be tested = against, then they will have been tested for interoperability with the = lab’s “reference set” of routers.  = If they passed, then you’ve got your interoperability answer.  ICSA is at www.icsalabs.com and VPNC is at www.vpnc.org.  =

 

Good luck!

 

       &nbs= p;   David Fox

=

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D=

David Fox           &= nbsp;           &= nbsp;           &= nbsp;           

Quarry Technologies           &= nbsp;           &= nbsp;        dfox@quarrytech.com=

8 = New England Executive Park          =      Direct: 781-359-5094

Burlington, Massachusetts  01803         Main: 781-505-8300 x5094=

www.quarrytech.com           &= nbsp;           &= nbsp;         FAX:   = 781-505-8316=

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D=

 

-----Original Message-----
From: = jerry.wang@tumbleweed.com [mailto:jerry.wang@tumbleweed.com]
Sent: Wednesday, January = 30, 2002 4:55 PM
To: = ipsec@lists.tislabs.com
Subject: = interoperability of IPSec between solaris 8 and win2k=

 =

Hi all,

 =

I am testing the interoperability of IPSec between the = native support from solaris 8 and win2k. It seems not possible due to the fact = that solaris 8's ipsec implementation is not full-fledged, and it only = allows for manual keyed sa. Also the length of the keys is dependent on the = authentication and encryption algorithm on solaris 8 while win2k doesn't seem to = have this constraint. Win2k configuration tool only allows for = authentication key to be manually configured, not encryption key. = =

 =

So I can't see how these two would work together. Does = anyone have a similar experiment and draw the same or opposite conclusions? = Thanks.=

 =

------_=_NextPart_001_01C1AB42.6BF58BD0-- From owner-ipsec@lists.tislabs.com Fri Feb 1 13:19:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11LJU317480; Fri, 1 Feb 2002 13:19:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27478 Fri, 1 Feb 2002 15:29:16 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <001001c1ab59$11becac0$6f690d0f@AZ735043> References: <001001c1ab59$11becac0$6f690d0f@AZ735043> Date: Fri, 1 Feb 2002 15:36:21 -0500 To: "Andrew Wenlang Zhu" From: Stephen Kent Subject: Re: What is the standardization status of AES in IPSec? Cc: Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA27475 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Hello: > >Can any one give me an update on the standardization status of using AES in >IPSec? > >I am reading ěThe AES Cipher Algorithm and Its Use With IPsecî > and read ě Once NIST has published >the AES FIPS ... AES should become a default and mandatory-to-implement >cipher algorithm for IPSecî. > >FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is expected to come out? > >Thanks, >--------------------------------------- >Andrew Zhu >HP Systems Networking Solution Lab >IP Security & System Firewall Project >Andrew_zhu@hp.com I anticipate mandating use of AES in ESP, initially in CBC mode. I would anticipate 128 bit key support as the default. As always, vendors are free to support other modes and key lengths, but we have to select a default, mandatory to implement mode and key length for the standard. Steve From owner-ipsec@lists.tislabs.com Fri Feb 1 13:47:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11LlC318298; Fri, 1 Feb 2002 13:47:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27616 Fri, 1 Feb 2002 16:01:51 -0500 (EST) Message-ID: <01f701c1ab65$69ff9a50$36c02ca1@cisco.com> From: "Stephane Beaulieu" To: "Scott Fanning" Cc: References: <001001c1ab59$11becac0$6f690d0f@AZ735043> <00cd01c1ab5c$9f0b1890$9080ad40@cisco.com> Subject: Re: What is the standardization status of AES in IPSec? Date: Fri, 1 Feb 2002 16:14:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nope. The I-D specifies 128 bits as a MUST. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-03.txt section 2.2 This document specifies the default (i.e. MUST be supported) key size for the AES cipher algorithm. The default key size that implementa- tions MUST support for IPsec is 128 bits. In addition, implementa- tions MAY support key sizes of 192 and 256 bits. ----- Original Message ----- From: "Scott Fanning" To: "Andrew Wenlang Zhu" ; Sent: Friday, February 01, 2002 2:59 PM Subject: Re: What is the standardization status of AES in IPSec? > and on that note.. If AES is the MUST implement algorithm, does that include > all key sizes? > > Scott > ----- Original Message ----- > From: "Andrew Wenlang Zhu" > To: > Sent: Friday, February 01, 2002 11:45 AM > Subject: What is the standardization status of AES in IPSec? > > > > Hello: > > > > Can any one give me an update on the standardization status of using AES > in > > IPSec? > > > > I am reading "The AES Cipher Algorithm and Its Use With IPsec" > > and read " Once NIST has published > > the AES FIPS ... AES should become a default and mandatory-to-implement > > cipher algorithm for IPSec". > > > > FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is expected to come > out? > > > > Thanks, > > --------------------------------------- > > Andrew Zhu > > HP Systems Networking Solution Lab > > IP Security & System Firewall Project > > Andrew_zhu@hp.com > > > > > From owner-ipsec@lists.tislabs.com Fri Feb 1 13:52:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11LqT318432; Fri, 1 Feb 2002 13:52:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27622 Fri, 1 Feb 2002 16:03:05 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0D4D@MAIL.NetOctave.com> From: Mark Winstead To: "'Andrew Wenlang Zhu'" , ipsec@lists.tislabs.com Subject: RE: What is the standardization status of AES in IPSec? Date: Fri, 1 Feb 2002 16:13:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB65.5A964A50" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C1AB65.5A964A50 Content-Type: text/plain; charset="iso-8859-1" Additionally, some new Oakley groups should be identified at the same time. Some of those will undoubtly have to be ECDH groups in order to reasonably support 256 bit keys (anyone want to deal with 15K bit Oakley groups?) -----Original Message----- From: Andrew Wenlang Zhu [mailto:Andrew_zhu@hp.com] Sent: Friday, February 01, 2002 2:46 PM To: ipsec@lists.tislabs.com Subject: What is the standardization status of AES in IPSec? Hello: Can any one give me an update on the standardization status of using AES in IPSec? I am reading "The AES Cipher Algorithm and Its Use With IPsec" and read " Once NIST has published the AES FIPS ... AES should become a default and mandatory-to-implement cipher algorithm for IPSec". FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is expected to come out? Thanks, --------------------------------------- Andrew Zhu HP Systems Networking Solution Lab IP Security & System Firewall Project Andrew_zhu@hp.com ------_=_NextPart_001_01C1AB65.5A964A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: What is the standardization status of AES in IPSec?

Additionally, some new Oakley groups should be = identified at the same time. Some of those will undoubtly have to be = ECDH groups in order to reasonably support 256 bit keys (anyone want to = deal with 15K bit Oakley groups?)



-----Original Message-----
From: Andrew Wenlang Zhu [mailto:Andrew_zhu@hp.com]
Sent: Friday, February 01, 2002 2:46 PM
To: ipsec@lists.tislabs.com
Subject: What is the standardization status of AES = in IPSec?


Hello:

Can any one give me an update on the standardization = status of using AES in
IPSec?

I am reading "The AES Cipher Algorithm and Its Use = With IPsec"
<draft-ietf-ipsec-ciph-aes-cbc-03.txt> and = read " Once NIST has published
the AES FIPS ... AES should become a default and = mandatory-to-implement
cipher algorithm for IPSec".

FIPS-197 was out in Nov-2001. When an IPSec/AES RFC = is expected to come out?

Thanks,
---------------------------------------
Andrew Zhu
HP Systems Networking Solution Lab
IP Security & System Firewall Project
Andrew_zhu@hp.com

------_=_NextPart_001_01C1AB65.5A964A50-- From owner-ipsec@lists.tislabs.com Sat Feb 2 11:25:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g12JP0321987; Sat, 2 Feb 2002 11:25:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01037 Sat, 2 Feb 2002 13:31:18 -0500 (EST) From: "Hilarie Orman, Purple Streak Development" To: Mark.Winstead@NetOctave.com Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage <49B96FCC784BC54F9675A6B558C3464E5D0D4D@MAIL.NetOctave.com> Subject: RE: What is the standardization status of AES in IPSec? Message-Id: Date: Sat, 02 Feb 2002 11:42:11 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm curious as to how many people believe that a MUST for a 128-bit AES key means a MUST for 128 bits of entropy in the key. The *strength* of the key determination algorithm need not match the *length* of the cipher key, thus one might not need larger groups for larger keys. And, if anyone really wants that must strength in key determination, the computational advantages of elliptic curve groups are overwhelming. Hilarie > Additionally, some new Oakley groups should be identified at the same time. > Some of those will undoubtly have to be ECDH groups in order to reasonably > support 256 bit keys (anyone want to deal with 15K bit Oakley groups?) > From: Andrew Wenlang Zhu [mailto:Andrew_zhu@hp.com] > Hello: > Can any one give me an update on the standardization status of using AES in > IPSec? > I am reading "The AES Cipher Algorithm and Its Use With IPsec" > and read " Once NIST has published > the AES FIPS ... AES should become a default and mandatory-to-implement > cipher algorithm for IPSec". > FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is expected to come out? > Thanks, > --------------------------------------- > Andrew Zhu > HP Systems Networking Solution Lab > IP Security & System Firewall Project > Andrew_zhu@hp.com From owner-ipsec@lists.tislabs.com Sat Feb 2 23:37:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g137b6311396; Sat, 2 Feb 2002 23:37:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02062 Sun, 3 Feb 2002 01:31:12 -0500 (EST) Message-ID: <02bd01c1ac7d$f73c53e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Hilarie Orman, Purple Streak Development" , Cc: References: Subject: Re: What is the standardization status of AES in IPSec? Date: Sun, 3 Feb 2002 08:42:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm curious as to how many people believe that a MUST for a 128-bit AES > key means a MUST for 128 bits of entropy in the key. I don't. While I believe we should move to AES as soon as possible, I don't necessarily believe in the statement that all components of the protocol set must be equally strong; you should be able to take advantage of a new good algorithm even if you can't for e.g. computational reasons increase Diffie-Hellman key lengths quite as much. Thus, I believe we should standardize groups matching AES strength, but not make them mandatory. And we need to explain the strength issues somewhere. Jari From owner-ipsec@lists.tislabs.com Mon Feb 4 01:46:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g149k1303749; Mon, 4 Feb 2002 01:46:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29176 Mon, 4 Feb 2002 03:35:10 -0500 (EST) Message-Id: <3.0.6.32.20020204094841.01d7cf28@10.36.4.42> X-Sender: martius@10.36.4.42 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 04 Feb 2002 09:48:41 +0100 To: "Scott Fanning" , "Andrew Wenlang Zhu" , From: Kai Martius Subject: Re: What is the standardization status of AES in IPSec? In-Reply-To: <00cd01c1ab5c$9f0b1890$9080ad40@cisco.com> References: <001001c1ab59$11becac0$6f690d0f@AZ735043> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, (I was just about to ask a similar / related question...) At 11:59 01.02.2002 -0800, Scott Fanning wrote: >and on that note.. If AES is the MUST implement algorithm, does that include >all key sizes? ... and how are different key sizes reflected by the identifiers? Will we have different identifiers in IKE and IPsec for 128, 192 and 256 bits? For the currently IANA-defined identifiers ESP_AES and OAKLEY_AES_CBC, it is assumed to be 128bit, I think (?). Kai -- Kai Martius secunet Security Networks AG Dresden - Germany From owner-ipsec@lists.tislabs.com Mon Feb 4 06:05:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14E56322485; Mon, 4 Feb 2002 06:05:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29605 Mon, 4 Feb 2002 08:07:12 -0500 (EST) Message-ID: <003f01c1ad7e$4a25cb80$69f77a90@bilten.metu.edu.tr> From: =?iso-8859-1?Q?Kerem_=D6nal?= To: References: <001001c1ab59$11becac0$6f690d0f@AZ735043> <3.0.6.32.20020204094841.01d7cf28@10.36.4.42> Subject: Rijndael Date: Mon, 4 Feb 2002 15:17:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, What should I do to use Rijndael, which is chosen as the Advance Encryption Standard, in IPSEC? Kerem From owner-ipsec@lists.tislabs.com Mon Feb 4 08:04:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14G4l300284; Mon, 4 Feb 2002 08:04:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29949 Mon, 4 Feb 2002 10:09:52 -0500 (EST) From: steve.robinson@metaware.com Subject: Re: What is the standardization status of AES in IPSec? To: "Scott Fanning" Cc: "Andrew Wenlang Zhu" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 1 Feb 2002 16:32:00 -0500 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.8 |June 18, 2001) at 02/01/2002 09:32:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, since FIPS-197 says that one of the three key lengths MUST be supported, and that the other two SHOULD be supported, it's probably a good idea to follow that lead, and choose a single key size that must be supported, and the keep the others optional. "Scott Fanning" , > Sent by: cc: owner-ipsec@lists.t Subject: Re: What is the standardization status of AES in IPSec? islabs.com 02/01/02 02:59 PM and on that note.. If AES is the MUST implement algorithm, does that include all key sizes? Scott ----- Original Message ----- From: "Andrew Wenlang Zhu" To: Sent: Friday, February 01, 2002 11:45 AM Subject: What is the standardization status of AES in IPSec? > Hello: > > Can any one give me an update on the standardization status of using AES in > IPSec? > > I am reading "The AES Cipher Algorithm and Its Use With IPsec" > and read " Once NIST has published > the AES FIPS ... AES should become a default and mandatory-to-implement > cipher algorithm for IPSec". > > FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is expected to come out? > > Thanks, > --------------------------------------- > Andrew Zhu > HP Systems Networking Solution Lab > IP Security & System Firewall Project > Andrew_zhu@hp.com > > From owner-ipsec@lists.tislabs.com Mon Feb 4 08:09:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14G9X301035; Mon, 4 Feb 2002 08:09:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29959 Mon, 4 Feb 2002 10:12:21 -0500 (EST) Message-ID: <002201c1ad8f$c042b3d0$9080ad40@cisco.com> From: "Scott Fanning" To: "Andrew Wenlang Zhu" , , "Kai Martius" References: <001001c1ab59$11becac0$6f690d0f@AZ735043> <3.0.6.32.20020204094841.01d7cf28@10.36.4.42> Subject: Re: What is the standardization status of AES in IPSec? Date: Mon, 4 Feb 2002 07:22:23 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You would use the Key length attribute to describe the size of the keys in the proposal for MM and QM (see RFC 2407). Maybe we can use the key rounds attribute for 3AES :-) Scott ----- Original Message ----- From: "Kai Martius" To: "Scott Fanning" ; "Andrew Wenlang Zhu" ; Sent: Monday, February 04, 2002 12:48 AM Subject: Re: What is the standardization status of AES in IPSec? > > Hello, > > (I was just about to ask a similar / related question...) > > At 11:59 01.02.2002 -0800, Scott Fanning wrote: > >and on that note.. If AES is the MUST implement algorithm, does that include > >all key sizes? > > ... and how are different key sizes reflected by the identifiers? Will we > have different identifiers in IKE and IPsec for 128, 192 and 256 bits? For > the currently IANA-defined identifiers ESP_AES and OAKLEY_AES_CBC, it is > assumed to be 128bit, I think (?). > > Kai > > -- > Kai Martius > secunet Security Networks AG > Dresden - Germany From owner-ipsec@lists.tislabs.com Mon Feb 4 09:07:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14H70304554; Mon, 4 Feb 2002 09:07:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00192 Mon, 4 Feb 2002 11:14:00 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0D52@MAIL.NetOctave.com> From: Mark Winstead To: "'Jari Arkko'" , "Hilarie Orman, Purple Streak Development" , Mark Winstead Cc: ipsec@lists.tislabs.com Subject: RE: What is the standardization status of AES in IPSec? Date: Mon, 4 Feb 2002 11:24:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AD98.7989C1F0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C1AD98.7989C1F0 Content-Type: text/plain; charset="iso-8859-1" Forgive the intrusion of this thought, but those of us working commercially have to ask: would use of AES 128 without 128 bits of entropy have any FIPS implications? FIPS 197 doesn't mandate (from what I can tell) 128 bits of entropy for 128 bit key AES, but is there another FIPS document that would imply that x bit keys require x bit of entropy? Additionally, it makes me a bit uneasy to not use 128 bits of entropy here. I believe AES with 128 bit keys carries the idea of 128 bits of entropy to the uneducated and lesser educated, even if they don't understand entropy and all the other concepts involved. mark -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Sunday, February 03, 2002 1:43 AM To: Hilarie Orman, Purple Streak Development; Mark.Winstead@NetOctave.com Cc: ipsec@lists.tislabs.com Subject: Re: What is the standardization status of AES in IPSec? > I'm curious as to how many people believe that a MUST for a 128-bit AES > key means a MUST for 128 bits of entropy in the key. I don't. While I believe we should move to AES as soon as possible, I don't necessarily believe in the statement that all components of the protocol set must be equally strong; you should be able to take advantage of a new good algorithm even if you can't for e.g. computational reasons increase Diffie-Hellman key lengths quite as much. Thus, I believe we should standardize groups matching AES strength, but not make them mandatory. And we need to explain the strength issues somewhere. Jari ------_=_NextPart_001_01C1AD98.7989C1F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: What is the standardization status of AES in IPSec?

Forgive the intrusion of this thought, but those of = us working commercially have to ask: would use of AES 128 without 128 = bits of entropy have any FIPS implications? FIPS 197 doesn't mandate = (from what I can tell) 128 bits of entropy for 128 bit key AES, but is = there another FIPS document that would imply that x bit keys require x = bit of entropy?

Additionally, it makes me a bit uneasy to not use 128 = bits of entropy here. I believe AES with 128 bit keys carries the idea = of 128 bits of entropy to the uneducated and lesser educated, even if = they don't understand entropy and all the other concepts = involved.

mark

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
Sent: Sunday, February 03, 2002 1:43 AM
To: Hilarie Orman, Purple Streak Development;
Mark.Winstead@NetOctave.com
Cc: ipsec@lists.tislabs.com
Subject: Re: What is the standardization status of = AES in IPSec?



> I'm curious as to how many people believe that a = MUST for a 128-bit AES
> key means a MUST for 128 bits of entropy in the = key.

I don't. While I believe we should move to AES as = soon as possible, I
don't necessarily believe in the statement that all = components of the
protocol set must be equally strong; you should be = able to take advantage
of a new good algorithm even if you can't for e.g. = computational reasons
increase Diffie-Hellman key lengths quite as = much.

Thus, I believe we should standardize groups matching = AES strength,
but not make them mandatory. And we need to explain = the strength
issues somewhere.

Jari


------_=_NextPart_001_01C1AD98.7989C1F0-- From owner-ipsec@lists.tislabs.com Mon Feb 4 09:18:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14HIP304891; Mon, 4 Feb 2002 09:18:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00323 Mon, 4 Feb 2002 11:25:49 -0500 (EST) Date: Mon, 4 Feb 2002 11:36:12 -0500 (EST) From: Henry Spencer To: =?iso-8859-1?Q?Kerem_=D6nal?= cc: ipsec@lists.tislabs.com Subject: Re: Rijndael In-Reply-To: <003f01c1ad7e$4a25cb80$69f77a90@bilten.metu.edu.tr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 4 Feb 2002, =?iso-8859-1?Q?Kerem_=D6nal?= wrote: > What should I do to use Rijndael, which is chosen as the Advance Encryption > Standard, in IPSEC? Obtain an IPsec implementation which supports it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Feb 4 09:45:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14HjQ305633; Mon, 4 Feb 2002 09:45:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00463 Mon, 4 Feb 2002 11:55:44 -0500 (EST) Message-Id: <200202041655.ADN75759@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 04 Feb 2002 09:03:00 -0800 To: Kerem =?iso-8859-1?Q?=D6nal?= , From: Scott Fluhrer Subject: Re: Rijndael In-Reply-To: <003f01c1ad7e$4a25cb80$69f77a90@bilten.metu.edu.tr> References: <001001c1ab59$11becac0$6f690d0f@AZ735043> <3.0.6.32.20020204094841.01d7cf28@10.36.4.42> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA00460 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:17 AM 2/4/02 , Kerem Önal wrote: >Hi, > >What should I do to use Rijndael, which is chosen as the Advance Encryption >Standard, in IPSEC? If you're an implementor, you can start by implementing the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-00.txt (either that, or wait for the official RFCs). If you're an end-user, then you'll need to talk to whoever implements IPSec for you. -- scott From owner-ipsec@lists.tislabs.com Mon Feb 4 10:19:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14IJB306632; Mon, 4 Feb 2002 10:19:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00541 Mon, 4 Feb 2002 12:20:01 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <49B96FCC784BC54F9675A6B558C3464E5D0D52@MAIL.NetOctave.com> References: <49B96FCC784BC54F9675A6B558C3464E5D0D52@MAIL.NetOctave.com> Date: Mon, 4 Feb 2002 12:07:47 -0500 To: Mark Winstead From: Stephen Kent Subject: RE: What is the standardization status of AES in IPSec? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:24 AM -0500 2/4/02, Mark Winstead wrote: >Forgive the intrusion of this thought, but those of us working >commercially have to ask: would use of AES 128 without 128 bits of >entropy have any FIPS implications? FIPS 197 doesn't mandate (from >what I can tell) 128 bits of entropy for 128 bit key AES, but is >there another FIPS document that would imply that x bit keys require >x bit of entropy? > >Additionally, it makes me a bit uneasy to not use 128 bits of >entropy here. I believe AES with 128 bit keys carries the idea of >128 bits of entropy to the uneducated and lesser educated, even if >they don't understand entropy and all the other concepts involved. > >mark Algorithm certification under FIPS processes generally does not address the question of key bit entropy, since the algorithm implementation often will receive keys externally. Thus that evaluation would not address the issues of the entropy of bits extracted from a DH exchange and later used as an AES key. FIPS 140-x certification addresses RNGs and PRNGs as sources of randomness for keys, but that's not what we use in IKE. There is a table that NIST has produced that recommends corresponding key sizes for AES/RSA/DH, and various EC variants, but I don't believe it is a requirement in any of the certification processes. Steve From owner-ipsec@lists.tislabs.com Mon Feb 4 11:56:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14Jui310318; Mon, 4 Feb 2002 11:56:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00903 Mon, 4 Feb 2002 14:08:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15454.56970.740984.179073@pkoning.dev.equallogic.com> Date: Mon, 4 Feb 2002 14:18:34 -0500 (EST) From: Paul Koning To: jari.arkko@kolumbus.fi Cc: ipsec@lists.tislabs.com Subject: Re: What is the standardization status of AES in IPSec? References: <02bd01c1ac7d$f73c53e0$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jari" == Jari Arkko writes: >> I'm curious as to how many people believe that a MUST for a >> 128-bit AES key means a MUST for 128 bits of entropy in the key. Jari> I don't. While I believe we should move to AES as soon as Jari> possible, I don't necessarily believe in the statement that all Jari> components of the protocol set must be equally strong; you Jari> should be able to take advantage of a new good algorithm even Jari> if you can't for e.g. computational reasons increase Jari> Diffie-Hellman key lengths quite as much. Jari> Thus, I believe we should standardize groups matching AES Jari> strength, but not make them mandatory. And we need to explain Jari> the strength issues somewhere. Agreed 100%. Make sure the option is there -- don't mandate it. paul From owner-ipsec@lists.tislabs.com Mon Feb 4 12:37:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14KbW311520; Mon, 4 Feb 2002 12:37:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00987 Mon, 4 Feb 2002 14:43:07 -0500 (EST) From: "Hilarie Orman, Purple Streak Development" To: jari.arkko@kolumbus.fi Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage <02bd01c1ac7d$f73c53e0$8a1b6e0a@arenanet.fi> Subject: Re: What is the standardization status of AES in IPSec? Message-Id: Date: Mon, 04 Feb 2002 12:54:03 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think you are asking for key exchange groups that match the *maximum* strength of each AES key. But can you say why that is that actually necessary, at this time? As for explaining strength issues, there's draft-orman-public-key-lengths-05.txt. Hilarie > > I'm curious as to how many people believe that a MUST for a 128-bit AES > > key means a MUST for 128 bits of entropy in the key. > I don't. While I believe we should move to AES as soon as possible, I > don't necessarily believe in the statement that all components of the > protocol set must be equally strong; you should be able to take advantage > of a new good algorithm even if you can't for e.g. computational reasons > increase Diffie-Hellman key lengths quite as much. > Thus, I believe we should standardize groups matching AES strength, > but not make them mandatory. And we need to explain the strength > issues somewhere. > Jari From owner-ipsec@lists.tislabs.com Mon Feb 4 13:08:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14L8p312305; Mon, 4 Feb 2002 13:08:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01172 Mon, 4 Feb 2002 15:14:09 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3C5EE4CB.5FB72E17@bell-labs.com> Date: Mon, 04 Feb 2002 14:45:16 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Mark Winstead Original-CC: ipsec@lists.tislabs.com Subject: Re: What is the standardization status of AES in IPSec? References: <49B96FCC784BC54F9675A6B558C3464E5D0D52@MAIL.NetOctave.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Winstead wrote: > ........... would use of AES 128 without 128 bits of > entropy have any FIPS implications? ............ is > there another FIPS document that would imply that x bit keys > require x bit of entropy? No to both, IMHO. > Additionally, it makes me a bit uneasy to not use 128 bits of > entropy here. Whatever people need... > I believe AES with 128 bit keys carries the idea of 128 bits > of entropy to the uneducated and lesser educated...... Carries the idea of *up to* 128 bits of entropy. [don't have to use it all.] -- Regards, Uri. -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Mon Feb 4 14:35:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14MZ5314649; Mon, 4 Feb 2002 14:35:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01362 Mon, 4 Feb 2002 16:42:02 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 4 Feb 2002 13:52:51 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RESEND: Thoughts on identity attacks Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [[ This message got a total of zero responses. Hopefully, people consider the type of identity protection given in SuccessorToIKE to be important. If it isn't important, we should start talking about the other issues that are. ]] Greetings again. Some users want to have their identities hidden when they use IPsec because they do not want an attacker to know with whom they are communicating. This is a summary discussion from the mailing list, the WG sessions in Salt Lake City, and side conversations. 1. Attacks to get identities There are two types of attacks that can mounted to find out the identity of one or both of the parties in a key exchange protocol: - Passive attacks look for identities that passed in the clear during the negotiation. In a passive attack, neither party can detect that the identity is being seen. - Active attacks find identities by being a man-in-the-middle or by replacing the responder in the negotiation. The attacker proceeds through the key negotiation with the attackee until the attackee has revealed its identity. In a well-designed system, the negotiation will fail after the attackee has revealed its identity because the attacker cannot spoof the identity of the originally-intended system. The attackee might then suspect that there was an attack because the other side failed before it gave its identity. Therefore, an active attack cannot be persistent because it would prevent all legitimate access to the desired IPsec system. 2. Properties of identities In certificate-based IPsec, the identities are those that are bound in each side's certificates. For reasons of history but not necessity, the identities in these certificates are usually a human and/or company name, an IP address, a DNS name, or an email address. However, PKIX certificates can contain any sort of identity, including opaque blobs, in the subjectAltName using the otherName or registeredID types. 3. Who needs identity protection In key negotiations, the IP address of each IPsec system is always known to a passive or active attacker. The identities being protected by the key negotiation system are those in the certificates or identification payloads. Typically, an IPsec system that is at the same IP address over a long period of time does not need identity protection because an attacker can use other means (such as traceroute and reverse DNS lookup) to determine its identity. Identity protection is most useful to users with dynamic IP addresses, usually users whose IP address is assigned by DHCP or by a variety of different ISPs. The four cases for a negotiation are: Stationary initiator, stationary responder -- This is typical of gateway-to-gateway VPNs. Identity protection would not achieve much here. Mobile initiator, stationary responder -- This is a typical remote-access scenario. Even though the responder's identity can probably be determined by other means, the initiator can get value from identity protection. Stationary initiator, mobile responder -- For the initiator to be able to find the responder, there must have been some recent prior contact between the two parties. This could, for example, be a rekeying of an existing SA. In this case, the responder would want its identity protected. Mobile initiator, mobile responder -- For the initiator to be able to find the responder, there must have been some recent prior contact between the two parties. This could, for example, be a rekeying of an existing SA. In this case, each side would want its identity protected. 4. Identity protection in the current proposals The following describes IKE and the different proposals for its successors. IKEv1, IKEv2 draft 00, and LBJ (a proposal briefly made by Angelos in Salt Lake City that will be an option in JFK draft 01) all have the same properties. There is no passive attack possible, and an active attack is possible against the initiator's identity. Such an attack will reveal the identity but will cause the negotiation to fail in the next message. In JFK draft 00, there is a passive attack on the responder's identity, but no active attack possible on the initiator. SIGMA has proposals that match each of the above two identity protections. 5. Personal observations The model in JFK draft 00 (expose the responder's identity in order to protect the initiator's identity from active attacks) only works if the initiator never turns into a responder. However, in JFK draft 00, there is a strong chance that the original responder will want to rekey the SA, at which point the original initiator will have to expose its identity. The only ways around this are to change the protocol to never allow the original responder to rekey (very bad from a security policy standpoint), or to add some mechanism whereby the two parties can agree to who will reveal their identity first (bad from a complexity standpoint). Although IKEv1, IKEv2 draft 00, and LBJ expose the initiator's identity to an active attack, that attack seems unlikely to be common. The man-in-the-middle would have to be intermittent, and even then would raise suspicion every time the attack was successful. These solutions also solve the "original responder rekeys first" problem of JFK draft 00. Further, when talking to someone who hasn't investigated identity attacks, it is much easier to explain "no passive attacks" than it is to explain "a passive attack against one of the two parties is OK because the other party gets better protection". If the parties in a negotiation are worried about an attack on their identities, they can use PKIX identities that will give the attacker little or no information about the real identities. This sometimes means that the CA that they mutually trust needs to issue certificates with identities other than the typical ones, but any reasonable CA system should be able to do this. Further, depending on the level of worry, the parties can get new certificates with new identities as often as they wish (or as often as their mutually-trusted CA can handle). --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Feb 4 20:50:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g154oQ325181; Mon, 4 Feb 2002 20:50:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01897 Mon, 4 Feb 2002 22:52:13 -0500 (EST) Message-Id: <200202050402.g1542U214434@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-reply-to: Your message of "Mon, 04 Feb 2002 13:52:51 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 04 Feb 2002 23:02:29 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> 2. Properties of identities VPNC> In certificate-based IPsec, the identities are those that are bound VPNC> in each side's certificates. For reasons of history but not VPNC> necessity, the identities in these certificates are usually a human VPNC> and/or company name, an IP address, a DNS name, or an email VPNC> address. However, PKIX certificates can contain any sort of VPNC> identity, including opaque blobs, in the subjectAltName using the VPNC> otherName or registeredID types. I think that there is something else that is important about identities. 1) we try to make them unique. 2) we try to use identities which can be looked in some database to retrieve the public key. (this doesn't mean that you can't load them from trusted store) VPNC> 3. Who needs identity protection VPNC> In key negotiations, the IP address of each IPsec system is always VPNC> known to a passive or active attacker. The identities being VPNC> protected by the key negotiation system are those in the VPNC> certificates or identification payloads. VPNC> Typically, an IPsec system that is at the same IP address over a VPNC> long period of time does not need identity protection because an VPNC> attacker can use other means (such as traceroute and reverse DNS VPNC> lookup) to determine its identity. Identity protection is most VPNC> useful to users with dynamic IP addresses, usually users whose IP VPNC> address is assigned by DHCP or by a variety of different ISPs. 3) a system may have numerous identities. People have forgotten this in the windoz-road-warrior<->gateway scenarios, but those of building ("real") systems that use IPsec in routine process-process scenarios have a multitude of identities (i.e. users, servers) that may cause negotiation to occur. VPNC> The four cases for a negotiation are: VPNC> Stationary initiator, stationary responder -- This is typical of VPNC> gateway-to-gateway VPNs. Identity protection would not achieve much VPNC> here. I strongly disagree. VPNC> Mobile initiator, stationary responder -- This is a typical VPNC> remote-access scenario. Even though the responder's identity can VPNC> probably be determined by other means, the initiator can get value VPNC> from identity protection. VPNC> Stationary initiator, mobile responder -- For the initiator to be VPNC> able to find the responder, there must have been some recent prior VPNC> contact between the two parties. This could, for example, be a VPNC> rekeying of an existing SA. In this case, the responder would want VPNC> its identity protected. In a peer to peer network, these two scenarios are equivalent, so I'm not certain I see what we gain by splitting them. I can trivially scan dialups (or IETF terminal room laptops) to find people who will respond on port 500. Thus, every machine is always potentially in the situation of being a responder. One thing that has been asked for, particularly for gateways that can reboot now and then, is for the gateway to remember for a period where the mobile nodes are and initiate to them again after the reboot. (see "Address inertia" on http://www.quintillion.com/moat/wishlist.html) VPNC> Mobile initiator, mobile responder -- For the initiator to be able VPNC> to find the responder, there must have been some recent prior VPNC> contact between the two parties. This could, for example, be a VPNC> rekeying of an existing SA. In this case, each side would want its VPNC> identity protected. Or, more practically, could be due to a registration in an online game, a SIP gateway, the latest instant messaging protocol, etc.. VPNC> The model in JFK draft 00 (expose the responder's identity in order VPNC> to protect the initiator's identity from active attacks) only works VPNC> if the initiator never turns into a responder. However, in JFK VPNC> Although IKEv1, IKEv2 draft 00, and LBJ expose the initiator's VPNC> identity to an active attack, that attack seems unlikely to be VPNC> common. The man-in-the-middle would have to be intermittent, and Depends upon private key hygiene, and law enforcement regime, but I agree in principle, that this should be the case. VPNC> If the parties in a negotiation are worried about an attack on VPNC> their identities, they can use PKIX identities that will give the VPNC> attacker little or no information about the real identities. This VPNC> sometimes means that the CA that they mutually trust needs to issue VPNC> certificates with identities other than the typical ones, but any VPNC> reasonable CA system should be able to do this. Further, depending The protocols should permit some notion of "rekeying" for identities within the phase 1 SA. That is, I should be able to use this opaque (but trusted) identity to start things off, and then offer new identities afterwards. Whether one permits multiple concurrent identities (attaching them to individual phase 2 negotiations perhaps) or only a single identity at a time, is an engineering tradeoff that needs to be made. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPF9ZU4qHRg3pndX9AQEixgP/UtuQGvj3CZNOlhOOUKi/XEpFbvqsMJK4 t4hleYLopbarUvO3+rfouT8nzfE6BIcRKU6VrwQXdIQbOxZ2CEm444P0rE5k8kzx 7wFKrWvwUEgu2kTUcS7Y0bO5biFKk+j0QL9iz2oD5VQFFjrqp5cko5UsBxiuin8L 2fUymDjIJ5A= =HpP4 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Feb 5 02:02:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15A2K329923; Tue, 5 Feb 2002 02:02:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02526 Tue, 5 Feb 2002 03:38:44 -0500 (EST) Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_What_is_the_standardization_status_of?= AES in IPSec? To: Paul Koning Cc: ipsec@lists.tislabs.com, jari.arkko@kolumbus.fi X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Romain BERRENDONNER" Date: Tue, 5 Feb 2002 09:49:32 +0100 X-MIMETrack: Serialize by Router on ESTUAIRE/SAGEM(Release 5.0.8 |June 18, 2001) at 05/02/2002 09:49:36 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA02523 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wonder what is the use of having symetric algorithms with keys longer than 128bits. All the papers I read show that is sufficient for protecting data in the next 20 years ... And is data worth being protected during 20 years sent over the wires ? As I see things, IPsec provides a kind of 'tactical' security : it protects data during the time sufficient for making it irrelevant for an attacker. If I send my credit card number on the Internet, the information is valid for at most two years. If I send the price of a new range of products, it is confidential while my products aren't for sale in a shop. Consequently, If I had to design a fully-secure Ipsec implementation, I would focus on having good entropy in keys rather than the longest key size possible. And I do agree with you that mandating "good" entropy isn't a good idea : it would remove a way to fine-grain systems' security (i.e. for export purpose). Regards -- Romain Berrendonner Paul Koning cc : ipsec@lists.tislabs.com, (ccc : Romain BERRENDONNER/DRD/SAGEM) Envoyé par : Objet : Re: What is the standardization status of AES in IPSec? owner-ipsec@lists.t islabs.com 04/02/2002 20:18 >>>>> "Jari" == Jari Arkko writes: >> I'm curious as to how many people believe that a MUST for a >> 128-bit AES key means a MUST for 128 bits of entropy in the key. Jari> I don't. While I believe we should move to AES as soon as Jari> possible, I don't necessarily believe in the statement that all Jari> components of the protocol set must be equally strong; you Jari> should be able to take advantage of a new good algorithm even Jari> if you can't for e.g. computational reasons increase Jari> Diffie-Hellman key lengths quite as much. Jari> Thus, I believe we should standardize groups matching AES Jari> strength, but not make them mandatory. And we need to explain Jari> the strength issues somewhere. Agreed 100%. Make sure the option is there -- don't mandate it. paul From owner-ipsec@lists.tislabs.com Tue Feb 5 10:02:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15I2Y302987; Tue, 5 Feb 2002 10:02:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03848 Tue, 5 Feb 2002 12:05:31 -0500 (EST) Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_R=E9f=2E_=3A_Re=3A_What_is_the?= standardization status of AES in IPSec? To: Paul Koning Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Romain BERRENDONNER" Date: Tue, 5 Feb 2002 18:16:22 +0100 X-MIMETrack: Serialize by Router on ESTUAIRE/SAGEM(Release 5.0.8 |June 18, 2001) at 05/02/2002 18:16:24 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA03845 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you for your precision about the value of information being sent over the wires. I fully agree that IPsec must be designed for any use, including the one we don't think of. BTW, I believed that 40 bits DES encryption for export was often usual 56 bits with 16 bits zeroed. I call it "limit the amount of entropy" ;-) But it suppose it's highly implementation-dependent. Regards, -- Romain Berrendonner Paul Koning cc : ipsec@lists.tislabs.com Objet : Re: Réf. : Re: What is the standardization status of AES in IPSec? 05/02/2002 17:59 Excerpt of message (sent 5 February 2002) by Romain BERRENDONNER: > > I wonder what is the use of having symetric algorithms with > keys longer than 128bits. All the papers I read show that is sufficient for > protecting data > in the next 20 years ... And is data worth being protected during 20 years > sent over the wires ? I would assume that it might be, absolutely. > As I see things, IPsec provides a kind of 'tactical' security : it protects > data during the time sufficient > for making it irrelevant for an attacker. If I send my credit card number > on the Internet, the information > is valid for at most two years. Not true, unless your credit card company changes your credit card number (not just its expiration date) when it renews the card. That happens occasionally but it is not routine in my experience. In any case, I don't think it's in the IPsec protocol goals to protect only data that's worth protecting no longer than a year or two. > Consequently, If I had to design a fully-secure Ipsec implementation, I > would focus on having good > entropy in keys rather than the longest key size possible. And I do agree > with you that mandating > "good" entropy isn't a good idea : it would remove a way to fine-grain > systems' security (i.e. for export > purpose). I don't know of any export controls that have ever limited the amount of allowable entropy. The only ones that have been used (in the USA, at least) restrict key lengths. And note that key length limitations, while not completely gone, are very much less an issue than they were in the past. Finally, IPsec is in no way limited to exportable encryption, nor should it be. (See also RFC 1984.) paul From owner-ipsec@lists.tislabs.com Tue Feb 5 10:04:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15I46303071; Tue, 5 Feb 2002 10:04:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03803 Tue, 5 Feb 2002 11:48:48 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.3938.568000.644432@gargle.gargle.HOWL> Date: Tue, 5 Feb 2002 11:59:14 -0500 From: Paul Koning To: romain.berrendonner@sagem.com Cc: ipsec@lists.tislabs.com Subject: Re: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_What_is_the_standardization_status_of?= AES in IPSec? References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 5 February 2002) by Romain BERRENDONNER: > > I wonder what is the use of having symetric algorithms with > keys longer than 128bits. All the papers I read show that is sufficient for > protecting data > in the next 20 years ... And is data worth being protected during 20 years > sent over the wires ? I would assume that it might be, absolutely. > As I see things, IPsec provides a kind of 'tactical' security : it protects > data during the time sufficient > for making it irrelevant for an attacker. If I send my credit card number > on the Internet, the information > is valid for at most two years. Not true, unless your credit card company changes your credit card number (not just its expiration date) when it renews the card. That happens occasionally but it is not routine in my experience. In any case, I don't think it's in the IPsec protocol goals to protect only data that's worth protecting no longer than a year or two. > Consequently, If I had to design a fully-secure Ipsec implementation, I > would focus on having good > entropy in keys rather than the longest key size possible. And I do agree > with you that mandating > "good" entropy isn't a good idea : it would remove a way to fine-grain > systems' security (i.e. for export > purpose). I don't know of any export controls that have ever limited the amount of allowable entropy. The only ones that have been used (in the USA, at least) restrict key lengths. And note that key length limitations, while not completely gone, are very much less an issue than they were in the past. Finally, IPsec is in no way limited to exportable encryption, nor should it be. (See also RFC 1984.) paul From owner-ipsec@lists.tislabs.com Tue Feb 5 10:04:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15I4K303095; Tue, 5 Feb 2002 10:04:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03811 Tue, 5 Feb 2002 11:51:33 -0500 (EST) Message-ID: <3C601026.92201A32@austin.ibm.com> Date: Tue, 05 Feb 2002 11:02:30 -0600 From: bhargavi Reply-To: bhargavi@austin.ibm.com X-Mailer: Mozilla 4.76iC-CCK-MCD [en_US] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Certificates from Verisign Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi! Can anyone tell me how to request for a personal certificate and a CA Certificate from Verisign. I need to do some testing in signature mode of authentication. I could not locate it on the Verisign website... verisign.com. Thanks, Bhargavi From owner-ipsec@lists.tislabs.com Tue Feb 5 11:03:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15J3b304909; Tue, 5 Feb 2002 11:03:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04023 Tue, 5 Feb 2002 13:16:44 -0500 (EST) Message-ID: From: Greg Carter To: "'bhargavi@austin.ibm.com'" , ipsec@lists.tislabs.com Subject: RE: Certificates from Verisign Date: Tue, 5 Feb 2002 13:27:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE72.B6999DB0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C1AE72.B6999DB0 Content-Type: text/plain; charset="iso-8859-1" Well not a Verisign site, you can get test certificates from Entrust at: http://216.191.252.72/ Greg Carter - http://www.carter-engineering.com Entrust Inc - http://www.entrust.com -----Original Message----- From: bhargavi [mailto:bhargavi@austin.ibm.com] Sent: Tuesday, February 05, 2002 12:03 PM To: ipsec@lists.tislabs.com Subject: Certificates from Verisign Hi! Can anyone tell me how to request for a personal certificate and a CA Certificate from Verisign. I need to do some testing in signature mode of authentication. I could not locate it on the Verisign website... verisign.com. ------_=_NextPart_001_01C1AE72.B6999DB0 Content-Type: text/html; charset="iso-8859-1" RE: Certificates from Verisign

Well not a Verisign site, you can get test certificates from Entrust at:

http://216.191.252.72/


Greg Carter - http://www.carter-engineering.com
Entrust Inc - http://www.entrust.com

-----Original Message-----
From: bhargavi [mailto:bhargavi@austin.ibm.com]
Sent: Tuesday, February 05, 2002 12:03 PM
To: ipsec@lists.tislabs.com
Subject: Certificates from Verisign


Hi!

 Can anyone tell me how to request for a personal certificate and a CA
Certificate from Verisign. I need to do some testing in signature mode
of authentication. I could not locate it on the Verisign website...
verisign.com. 

------_=_NextPart_001_01C1AE72.B6999DB0-- From owner-ipsec@lists.tislabs.com Tue Feb 5 12:57:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15Kv8307571; Tue, 5 Feb 2002 12:57:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04294 Tue, 5 Feb 2002 15:03:50 -0500 (EST) From: "Andrew Wenlang Zhu" To: , "'Scott Fanning'" Cc: Subject: RE: What is the standardization status of AES in IPSec? Date: Tue, 5 Feb 2002 12:14:02 -0800 Message-ID: <001501c1ae81$a829cb10$6f690d0f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think it a good idea to begin with one key length such as 128. Because this key length can fit in the current IKE and virtually needs no dramatic changes. Larger DH group MODP length may be the only exception. Actually, if IETF do not make 128 entropy a MUST for AES-128, DH 1024 and 1536 MODP is still a viable thing. One of the benefits of using AES in this way is its performance. In our HP lab available soft-implementation of AES and 3DES, AES only takes almost 1/3 of 3DES time in en/de-crypt ion. Performance is crucial especially to software-only IPSec implementation. Interesting enough, I found nearly the same speed ratio in some hardware implementation. Andrew ----------------------------- Andrew Zhu HP Systems Networking Solution Lab IP Security & System Firewall Project Andrew_zhu@hp.com >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of >steve.robinson@metaware.com >Sent: Friday, February 01, 2002 1:32 PM >To: Scott Fanning >Cc: Andrew Wenlang Zhu; ipsec@lists.tislabs.com; >owner-ipsec@lists.tislabs.com >Subject: Re: What is the standardization status of AES in IPSec? > > > >Well, since FIPS-197 says that one of the three key lengths MUST be >supported, and that the other two SHOULD be supported, it's >probably a good >idea to follow that lead, and choose a single key size that must be >supported, and the keep the others optional. > > > > > > "Scott Fanning" > > Wenlang Zhu" , > > > > > Sent by: cc: > > owner-ipsec@lists.t Subject: >Re: What is the standardization status of AES in IPSec? > islabs.com > > > > > > 02/01/02 02:59 PM > > > > > > > > > >and on that note.. If AES is the MUST implement algorithm, does that >include >all key sizes? > >Scott >----- Original Message ----- >From: "Andrew Wenlang Zhu" >To: >Sent: Friday, February 01, 2002 11:45 AM >Subject: What is the standardization status of AES in IPSec? > > > > Hello: > > > > Can any one give me an update on the standardization status >of using AES >in > > IPSec? > > > > I am reading "The AES Cipher Algorithm and Its Use With IPsec" > > and read " Once NIST >has published > > the AES FIPS ... AES should become a default and >mandatory-to-implement > > cipher algorithm for IPSec". > > > > FIPS-197 was out in Nov-2001. When an IPSec/AES RFC is >expected to come >out? > > > > Thanks, > > --------------------------------------- > > Andrew Zhu > > HP Systems Networking Solution Lab > > IP Security & System Firewall Project > > Andrew_zhu@hp.com > > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Feb 5 14:18:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15MI7312276; Tue, 5 Feb 2002 14:18:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04400 Tue, 5 Feb 2002 16:13:05 -0500 (EST) Message-ID: <3C604D55.1D19089B@juniper.net> Date: Tue, 05 Feb 2002 13:23:33 -0800 From: Kalyan Reply-To: kalyan@juniper.net Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: bhargavi@austin.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: Certificates from Verisign References: <3C601026.92201A32@austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You can use entrust certs for your testing (not very sure whether Verisign gives free certs). http://freecerts.entrust.com/vpncerts/index.htm Kalyan. bhargavi wrote: > > Hi! > > Can anyone tell me how to request for a personal certificate and a CA > Certificate from Verisign. I need to do some testing in signature mode > of authentication. I could not locate it on the Verisign website... > verisign.com. > > Thanks, > Bhargavi From owner-ipsec@lists.tislabs.com Tue Feb 5 15:52:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15NqE318140; Tue, 5 Feb 2002 15:52:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04639 Tue, 5 Feb 2002 18:03:49 -0500 (EST) Message-ID: <3C606767.7314CB85@sonicwall.com> Date: Tue, 05 Feb 2002 15:14:47 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks References: <200202050402.g1542U214434@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2002 23:14:50.0344 (UTC) FILETIME=[E92ECE80:01C1AE9A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few comments interspersed below... Michael Richardson wrote: > VPNC> 3. Who needs identity protection > > VPNC> In key negotiations, the IP address of each IPsec system is always > VPNC> known to a passive or active attacker. The identities being > VPNC> protected by the key negotiation system are those in the > VPNC> certificates or identification payloads. > > VPNC> Typically, an IPsec system that is at the same IP address over a > VPNC> long period of time does not need identity protection because an > VPNC> attacker can use other means (such as traceroute and reverse DNS > VPNC> lookup) to determine its identity. Identity protection is most > VPNC> useful to users with dynamic IP addresses, usually users whose IP > VPNC> address is assigned by DHCP or by a variety of different ISPs. > > 3) a system may have numerous identities. > > People have forgotten this in the windoz-road-warrior<->gateway > scenarios, but those of building ("real") systems that use IPsec in > routine process-process scenarios have a multitude of identities > (i.e. users, servers) that may cause negotiation to occur. Precisely - an IKE implementation may use different identities for different flows, and I don't think the fact not many fielded vpn implementations currently support this should be used as proof that this capability is not important. > The protocols should permit some notion of "rekeying" for identities > within the phase 1 SA. That is, I should be able to use this opaque (but > trusted) identity to start things off, and then offer new identities > afterwards. Whether one permits multiple concurrent identities (attaching > them to individual phase 2 negotiations perhaps) or only a single identity at > a time, is an engineering tradeoff that needs to be made. I think I agree, but upon re-reading, I'm not sure that what I think I understand is what you actually mean. I think the current IPsec spec has hooks for this via the phase 2 ID payloads. That is, it is conceivable that a given phase 1 identity is "authorized" to represent one or more phase 2 identities (which may be presented in phase 2 ID payloads). Is this the capability you are after, or are you referring to something else? Scott From owner-ipsec@lists.tislabs.com Tue Feb 5 19:17:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g163HT325310; Tue, 5 Feb 2002 19:17:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04988 Tue, 5 Feb 2002 21:22:30 -0500 (EST) Message-Id: <200202052350.g15NolT27459@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-reply-to: Your message of "Tue, 05 Feb 2002 15:14:47 PST." <3C606767.7314CB85@sonicwall.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Feb 2002 18:50:47 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: >> The protocols should permit some notion of "rekeying" for identities >> within the phase 1 SA. That is, I should be able to use this opaque >> (but trusted) identity to start things off, and then offer new >> identities afterwards. Whether one permits multiple concurrent >> identities (attaching them to individual phase 2 negotiations perhaps) >> or only a single identity at a time, is an engineering tradeoff that >> needs to be made. Scott> I think I agree, but upon re-reading, I'm not sure that what I Scott> think I understand is what you actually mean. I think the current Scott> IPsec spec has hooks for this via the phase 2 ID payloads. That Scott> is, it is conceivable that a given phase 1 identity is Scott> "authorized" to represent one or more phase 2 identities (which Scott> may be presented in phase 2 ID payloads). Is this the capability Scott> you are after, or are you referring to something else? No, not quite. The problem with using meaningless identities in phase 1 (because they might be vulnerable to identity attacks) is that they may not have the authority to speak for the phase 2 IDs that one wishes. The multiuser machine is a good example - use the machine IDs for phase 1. Particularly if these identities are strongly linked to IP addresses, there is very little identity leakage. Having done that, one still wants actually use identity (i.e. public/private keypair) "mcr" to authorize a per-port SA for port 23 (telnet). If you consider that things like SSH-agent, then things can become very interesting. So, I'm suggesting that one might want to permit one to either change or augment the phase *1* IDs, since those are what are involved in the authentication (and therefore the authorization). [We can not base the authorization to login on the machine ID, any more than we can trust that ports <1024 are only superuser] ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGBv1YqHRg3pndX9AQGf1QP+JBBgehDdVF/B5Bg1k96bcpKrgej3IYr4 6dKaJjvNyA2gaX8ZdvIBDvxMr4YanbfilqfURdbFy58Xxa0HlB/xUJfCkiBG/B+O 10PUBUSOZod1JfvpSC6yGPdKLf/vivfQYZKzDMbE05QqZFSrQ4TxDsKkwOgfATME Bm6nWelYbwg= =LKkB -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Feb 5 23:13:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g167DY311338; Tue, 5 Feb 2002 23:13:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05350 Wed, 6 Feb 2002 01:20:21 -0500 (EST) From: "Sami Ahvenniemi" To: Cc: Subject: RE: Certificates from Verisign Date: Wed, 6 Feb 2002 08:31:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3C601026.92201A32@austin.ibm.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id BAA05347 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you need a certificate, not necessarily VeriSign certificate, you can also use pki.ssh.com. -Sami > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of bhargavi > Sent: Tuesday, February 05, 2002 7:03 PM > To: ipsec@lists.tislabs.com > Subject: Certificates from Verisign > > > Hi! > > Can anyone tell me how to request for a personal certificate and a CA > Certificate from Verisign. I need to do some testing in signature mode > of authentication. I could not locate it on the Verisign website... > verisign.com. > > Thanks, > Bhargavi > From owner-ipsec@lists.tislabs.com Wed Feb 6 00:07:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1687j320233; Wed, 6 Feb 2002 00:07:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA05442 Wed, 6 Feb 2002 02:21:11 -0500 (EST) Message-ID: <008b01c1aee2$e5f89500$ae0510ac@roc.com> Reply-To: "Lokesh" From: "Lokesh" To: Subject: Interoperability test for AES. Date: Wed, 6 Feb 2002 13:20:06 +0530 Organization: Intoto Software India Pvt Ltd. Secunderabad. (India) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, Is there any site to test Interoperability of AES in Ipsec implementation online? both with manual and auto keying. Some time ago NIST was offering that facility at http://ipsec-wit.antd.nist.gov but it got silently closed down since a month I suppose. any help in this regard is appreciated. Thanks -Lokesh From owner-ipsec@lists.tislabs.com Wed Feb 6 02:37:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Ab0314355; Wed, 6 Feb 2002 02:37:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA05786 Wed, 6 Feb 2002 04:32:51 -0500 (EST) Date: Wed, 06 Feb 2002 11:39:17 +0200 From: Sara Bitan Subject: Re: RESEND: Thoughts on identity attacks To: ipsec@lists.tislabs.com, Paul Hoffman / VPNC Message-id: <005b01c1aef2$5cc41ec0$9ba6003e@bilbo> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul! Two issues: > If the parties in a negotiation are worried about an attack on their > identities, they can use PKIX identities that will give the attacker > little or no information about the real identities. This sometimes > means that the CA that they mutually trust needs to issue > certificates with identities other than the typical ones, but any > reasonable CA system should be able to do this. Further, depending on > the level of worry, the parties can get new certificates with new > identities as often as they wish (or as often as their > mutually-trusted CA can handle). I don't think we should bind IKE's identiy protection properties into other protocols (PKIX). The only requirement from certificates in the context of IKE is binding between an identity and a public key, and I think we should leave it this way - and not rely on certificates to give us identity protection. > > Although IKEv1, IKEv2 draft 00, and LBJ expose the initiator's > identity to an active attack, that attack seems unlikely to be > common. The man-in-the-middle would have to be intermittent, and even > then would raise suspicion every time the attack was successful. > These solutions also solve the "original responder rekeys first" > problem of JFK draft 00. > Further, when talking to someone who hasn't > investigated identity attacks, it is much easier to explain "no > passive attacks" than it is to explain "a passive attack against one > of the two parties is OK because the other party gets better > protection". > I agree that it is easier to explain "no passive attacks", but as Radia said in a previous mail - it is better to have the responder authenticate the initiator before he sends its identity. Otherwise - responders will expose their identities to anyone initiating an IKE exchange with them. This is not a man-in-the-middle attack, and it is very easy to launch. When you rekey, and you turn from a reponder to an initiator, this attack is no longer relvant - because now an attacker that wants to expose your identity will have to do the MIM attack. As you said, this is the level of identity protection IKEv1 gives, and I think new IKE should supply the same level: protection against passive attacks to the initiator, and protection against active attacks to the responder. Sara > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 6 10:35:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16IZZ317096; Wed, 6 Feb 2002 10:35:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06733 Wed, 6 Feb 2002 12:26:01 -0500 (EST) Message-Id: <4.3.2.7.2.20020206121921.00b59430@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Feb 2002 12:29:35 -0500 To: ipsec@lists.tislabs.com From: Sheila Frankel Subject: RE: Interoperability test for AES Cc: David Fox , Lokesh , Doug Montgomery Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The NIST IPsec Interoperability tester, IPsec-WIT, was the victim of a serious hack attack (how ironic!!), and we're in the process of rebuilding. We hope to re-deploy it within the next few weeks. Sheila sheila.frankel@nist.gov > Hi All, Is there any site to test Interoperability of AES in Ipsec > implementation online? both with manual and auto keying. Some time ago NIST > was offering that facility at http://ipsec-wit.antd.nist.gov but it got > silently closed down since a month I suppose. any help in this regard is > appreciated. Thanks -Lokesh From owner-ipsec@lists.tislabs.com Wed Feb 6 11:33:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16JXc320701; Wed, 6 Feb 2002 11:33:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06752 Wed, 6 Feb 2002 12:32:12 -0500 (EST) From: "Khaja E. Ahmed" To: , Subject: RE: Certificates from VeriSign Date: Wed, 6 Feb 2002 09:39:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C601026.92201A32@austin.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you are going to be doing PKI based testing it is a good idea to be able to issues your own certs with different extensions and profiles. Some options for free certificates are: Windows NT and later server versions come with a CA, OpenSSL includes a CA (well, the ability to issue certs and CRLs anyway) and you can download eval versions of the Netscape CMS CA as well. Khaja > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of bhargavi > Sent: Tuesday, February 05, 2002 9:03 AM > To: ipsec@lists.tislabs.com > Subject: Certificates from Verisign > > > Hi! > > Can anyone tell me how to request for a personal certificate and a CA > Certificate from Verisign. I need to do some testing in signature mode > of authentication. I could not locate it on the Verisign website... > verisign.com. > > Thanks, > Bhargavi > From owner-ipsec@lists.tislabs.com Wed Feb 6 11:53:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Jrn322050; Wed, 6 Feb 2002 11:53:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06983 Wed, 6 Feb 2002 13:55:57 -0500 (EST) From: "Khaja E. Ahmed" To: "Paul Hoffman / VPNC" , Subject: RE: RESEND: Thoughts on identity attacks Date: Wed, 6 Feb 2002 11:05:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Perhaps the fact that there were no responses suggests that not enough people think it is important. Let me introduce a counter view. I not only think it is not important but I think that pursuit of this goal risks further complicating an already too complicated protocol. I really think our energies are best directed at more important issues. After a year of discussions on requirements with product management of all the big VPN manufacturers, I have never even once heard that identity protection or 'obfuscated identities' are a requirement. Of course as the chair of the VPNC you may know much more about these matters and I would be delighted if you or someone could point me at data that suggests that this is a requirement among manufacturers and/or the user community. My concern is that this requirement comes out of our own knowledge of what good security practices should be - however far removed from current practices they are. Is it unreasonable to ask that what we know as good security practices be reconciled with the ability of the user community to employ and the manufacturers to support? Can't some kind of a balance be struck? The risk if we proceed with this feature is that it may get tested and have a couple of 'reference implementations built but will never be used in any reasonable sized deployment. We will have satisfied our academic and research interests but will not have produced a thing widely used/usable. In fact we may have complicated the overall solution and made it's adoption even harder. I think most companies find PKI itself too complicated. Both VPN solution providers and large users seem to prefer to stick with shared passwords rather than build support for or manage a PKI. Things like PKIX compliant path validation, CRL / OCSP support, certificate life cycle management, enrollment, etc. scare away all but the most intrepid. At this point I would NOT recommend adding any more features and would only consider removing/simplifying some. After there is a large population of users we can learn from actual security breaches and address security concerns that arise - as they arise - in future enhancements to the protocol. Khaja =============================== Khaja E. Ahmed khaja.ahmed@cavium.com khaja.ahmed@attbi.com ================================ > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Monday, February 04, 2002 1:53 PM > To: ipsec@lists.tislabs.com > Subject: RESEND: Thoughts on identity attacks > > > [[ This message got a total of zero responses. Hopefully, people > consider the type of identity protection given in SuccessorToIKE to > be important. If it isn't important, we should start talking about > the other issues that are. ]] > > Greetings again. Some users want to have their identities hidden when > they use IPsec because they do not want an attacker to know with whom > they are communicating. This is a summary discussion from the mailing > list, the WG sessions in Salt Lake City, and side conversations. > > 1. Attacks to get identities > > There are two types of attacks that can mounted to find out the > identity of one or both of the parties in a key exchange protocol: > > - Passive attacks look for identities that passed in the clear during > the negotiation. In a passive attack, neither party can detect that > the identity is being seen. > > - Active attacks find identities by being a man-in-the-middle or by > replacing the responder in the negotiation. The attacker proceeds > through the key negotiation with the attackee until the attackee has > revealed its identity. In a well-designed system, the negotiation > will fail after the attackee has revealed its identity because the > attacker cannot spoof the identity of the originally-intended system. > The attackee might then suspect that there was an attack because the > other side failed before it gave its identity. Therefore, an active > attack cannot be persistent because it would prevent all legitimate > access to the desired IPsec system. > > 2. Properties of identities > > In certificate-based IPsec, the identities are those that are bound > in each side's certificates. For reasons of history but not > necessity, the identities in these certificates are usually a human > and/or company name, an IP address, a DNS name, or an email address. > However, PKIX certificates can contain any sort of identity, > including opaque blobs, in the subjectAltName using the otherName or > registeredID types. > > 3. Who needs identity protection > > In key negotiations, the IP address of each IPsec system is always > known to a passive or active attacker. The identities being protected > by the key negotiation system are those in the certificates or > identification payloads. > > Typically, an IPsec system that is at the same IP address over a long > period of time does not need identity protection because an attacker > can use other means (such as traceroute and reverse DNS lookup) to > determine its identity. Identity protection is most useful to users > with dynamic IP addresses, usually users whose IP address is assigned > by DHCP or by a variety of different ISPs. > > The four cases for a negotiation are: > > Stationary initiator, stationary responder -- This is typical of > gateway-to-gateway VPNs. Identity protection would not achieve much > here. > > Mobile initiator, stationary responder -- This is a typical > remote-access scenario. Even though the responder's identity can > probably be determined by other means, the initiator can get value > from identity protection. > > Stationary initiator, mobile responder -- For the initiator to be > able to find the responder, there must have been some recent prior > contact between the two parties. This could, for example, be a > rekeying of an existing SA. In this case, the responder would want > its identity protected. > > Mobile initiator, mobile responder -- For the initiator to be able to > find the responder, there must have been some recent prior contact > between the two parties. This could, for example, be a rekeying of an > existing SA. In this case, each side would want its identity > protected. > > 4. Identity protection in the current proposals > > The following describes IKE and the different proposals for its > successors. > > IKEv1, IKEv2 draft 00, and LBJ (a proposal briefly made by Angelos in > Salt Lake City that will be an option in JFK draft 01) all have the > same properties. There is no passive attack possible, and an active > attack is possible against the initiator's identity. Such an attack > will reveal the identity but will cause the negotiation to fail in > the next message. > > In JFK draft 00, there is a passive attack on the responder's > identity, but no active attack possible on the initiator. > > SIGMA has proposals that match each of the above two identity protections. > > 5. Personal observations > > The model in JFK draft 00 (expose the responder's identity in order > to protect the initiator's identity from active attacks) only works > if the initiator never turns into a responder. However, in JFK draft > 00, there is a strong chance that the original responder will want to > rekey the SA, at which point the original initiator will have to > expose its identity. The only ways around this are to change the > protocol to never allow the original responder to rekey (very bad > from a security policy standpoint), or to add some mechanism whereby > the two parties can agree to who will reveal their identity first > (bad from a complexity standpoint). > > Although IKEv1, IKEv2 draft 00, and LBJ expose the initiator's > identity to an active attack, that attack seems unlikely to be > common. The man-in-the-middle would have to be intermittent, and even > then would raise suspicion every time the attack was successful. > These solutions also solve the "original responder rekeys first" > problem of JFK draft 00. Further, when talking to someone who hasn't > investigated identity attacks, it is much easier to explain "no > passive attacks" than it is to explain "a passive attack against one > of the two parties is OK because the other party gets better > protection". > > If the parties in a negotiation are worried about an attack on their > identities, they can use PKIX identities that will give the attacker > little or no information about the real identities. This sometimes > means that the CA that they mutually trust needs to issue > certificates with identities other than the typical ones, but any > reasonable CA system should be able to do this. Further, depending on > the level of worry, the parties can get new certificates with new > identities as often as they wish (or as often as their > mutually-trusted CA can handle). > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 6 12:59:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16KxV327399; Wed, 6 Feb 2002 12:59:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07217 Wed, 6 Feb 2002 15:05:46 -0500 (EST) Message-Id: <200202062016.g16KGBv10853@marajade.sandelman.ottawa.on.ca> To: "Khaja E. Ahmed" cc: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-reply-to: Your message of "Wed, 06 Feb 2002 11:05:52 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 06 Feb 2002 15:16:10 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Khaja" == Khaja E Ahmed writes: Khaja> Perhaps the fact that there were no responses suggests that not Khaja> enough people think it is important. Let me introduce a counter Khaja> view. I not only think it is not important but I think that Khaja> pursuit of this goal risks further complicating an already too Khaja> complicated protocol. I really think our energies are best Khaja> directed at more important issues. Yes, like getting a PKI implementation that people can actually use. I'll bet that 90% of the "complexity" of IKE is really the I of PKI. Khaja> After a year of discussions on requirements with product Khaja> management of all the big VPN manufacturers, I have never even Well, that's nice. I suggest that you write an IPsec VPN BCP. This is not the VPN WG. Khaja> I think most companies find PKI itself too complicated. Both VPN I think that most companies have made very poor purchasing decisions when it comes to PKI products. I can't blame them. The offerings have been very horrible. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGGPB4qHRg3pndX9AQEphwP+K6C6BZ+o70+TUIWHvoGmLAfYjv3ADXKd 5+nBfYH8JrFHO7EWuXWjuJTWXmSdlV/AN/1nrqS2WHRs/ceFGHlrk7+BisJyg6VC 33yWXkmD7p1OCgGqWhkkl0WQnuN3Yu0I078rHhz/TxAXtX7lbvZ44ggcrmbM2usI GSrfbOW80NI= =wQ58 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 6 20:11:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g174BU317641; Wed, 6 Feb 2002 20:11:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07916 Wed, 6 Feb 2002 22:06:49 -0500 (EST) From: "Khaja E. Ahmed" To: "Michael Richardson" Cc: Subject: RE: RESEND: Thoughts on identity attacks Date: Wed, 6 Feb 2002 19:16:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200202062016.g16KGBv10853@marajade.sandelman.ottawa.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, My recommendation is quite simple: Do not add any feature or capability to the protocol (or indeed any protocol or product for that matter) unless there is substantial reason to believe that it serves a useful purpose and will be used. It is simply good engineering practice not to build functionality into any standard or product that is not truly needed or is not likely to be used. Of course if is needed in the judgment of this list then we don't need to have this debate. Paul's message specifically pointed out that there was no response/interest and invited discussion on the subject. I am reporting that I have not found any interest whatsoever in this feature in any application that uses IPsec. (I mentioned VPNs only as an example.) Your, and others', experience could well be different. What will be of great help is for you, Paul or someone else to cite sources/information that makes a case for putting this feature in. The criteria being that such a feature would not only be useful in the judgment of this list but also be perceived as useful by users/product makers. The latter serves as an indication that the capability will actually get used. By the way, it is probably not productive to exhume that old battle where RFC writers/editors/contributors blame implementers for doing a sloppy/mercenary job and implementers blaming RFC writers for producing ambiguous, impractical and over engineered standards. Mistakes can and are made on both sides. Please, let us not go there. Khaja > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Wednesday, February 06, 2002 12:16 PM > To: Khaja E. Ahmed > Cc: ipsec@lists.tislabs.com > Subject: Re: RESEND: Thoughts on identity attacks > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Khaja" == Khaja E Ahmed writes: > Khaja> Perhaps the fact that there were no responses suggests that not > Khaja> enough people think it is important. Let me introduce > a counter > Khaja> view. I not only think it is not important but I think that > Khaja> pursuit of this goal risks further complicating an already too > Khaja> complicated protocol. I really think our energies are best > Khaja> directed at more important issues. > > Yes, like getting a PKI implementation that people can actually use. > > I'll bet that 90% of the "complexity" of IKE is really the I of PKI. > > Khaja> After a year of discussions on requirements with product > Khaja> management of all the big VPN manufacturers, I have never even > > Well, that's nice. I suggest that you write an IPsec VPN BCP. > This is not the VPN WG. > > Khaja> I think most companies find PKI itself too > complicated. Both VPN > > I think that most companies have made very poor purchasing decisions > when it comes to PKI products. I can't blame them. The offerings have been > very horrible. > > ] ON HUMILITY: to err is human. To moo, bovine. | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ > |device driver[ > ] panic("Just another NetBSD/notebook using, kernel hacking, > security guy"); [ > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Finger me for keys > > iQCVAwUBPGGPB4qHRg3pndX9AQEphwP+K6C6BZ+o70+TUIWHvoGmLAfYjv3ADXKd > 5+nBfYH8JrFHO7EWuXWjuJTWXmSdlV/AN/1nrqS2WHRs/ceFGHlrk7+BisJyg6VC > 33yWXkmD7p1OCgGqWhkkl0WQnuN3Yu0I078rHhz/TxAXtX7lbvZ44ggcrmbM2usI > GSrfbOW80NI= > =wQ58 > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 6 20:57:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g174vj320562; Wed, 6 Feb 2002 20:57:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08055 Wed, 6 Feb 2002 23:20:57 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: Thoughts on identity attacks Date: Wed, 6 Feb 2002 23:26:18 -0500 Message-ID: <000001c1af8f$97a19de0$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, I think the passive attack is the most important. Against an active attack, it would be nice for the initiator's id to be protected in in road-warrior cases and the responder's id to be protected otherwise. I don't agree with obfuscating the certificate contents as a means of identity protection. The data in the certificate is there for a reason (at least some of it). William brought up a good point at the IETF, which is that even a cert request for a specific CA can leak important information. A hacker could go around looking for cert requests from a specific CA in order to target employees from a specific company. BTW, If you're wondering why your original posting didn't get many answers, it's probably due to its length. For whatever reason, long/dense messages tend to get fewer responses. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed Feb 6 23:06:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1776q324880; Wed, 6 Feb 2002 23:06:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA08289 Thu, 7 Feb 2002 01:26:27 -0500 (EST) Message-Id: <200202070635.g176Zbe02063@fatty.lounge.org> To: "Khaja E. Ahmed" Cc: "Paul Hoffman / VPNC" , ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-Reply-To: Your message of "Wed, 06 Feb 2002 11:05:52 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2060.1013063737.1@tibernian.com> Date: Wed, 06 Feb 2002 22:35:37 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 06 Feb 2002 11:05:52 PST you wrote > Paul, > > Perhaps the fact that there were no responses suggests that not enough > people think it is important. Let me introduce a counter view. I not only > think it is not important but I think that pursuit of this goal risks > further complicating an already too complicated protocol. I really think > our energies are best directed at more important issues. I don't think you understand the context here. It is not to add some new feature to "an too already complicated protocol", it is to determine what a new protocol should/must have. As far as "already complicated protocols" go the one we're stuck with now already has a mode of protecting both identities from passive attack and also one that protects both from active attack (provided the Initiator already knows the Responder's public key). So this discussion is about _simplifying_ things by removing what is not needed not further complicating things by adding something new. > After a year of discussions on requirements with product management of all > the big VPN manufacturers, I have never even once heard that identity > protection or 'obfuscated identities' are a requirement. Of course as the > chair of the VPNC you may know much more about these matters and I would be > delighted if you or someone could point me at data that suggests that this > is a requirement among manufacturers and/or the user community. Product management of all the big VPN manufacturers? Aren't those the same ones who said, "We know it's insecure but it's easy to deploy and customers want it so shut up and implement it." Product management from any company do not frame debate here. On the other hand if someone from product management from a big VPN manufacturer wishes to add his or her points of view it would probably be better done directly and not through rumor. > I think most companies find PKI itself too complicated. Both VPN solution > providers and large users seem to prefer to stick with shared passwords > rather than build support for or manage a PKI. Things like PKIX compliant > path validation, CRL / OCSP support, certificate life cycle management, > enrollment, etc. scare away all but the most intrepid. At this point I > would NOT recommend adding any more features and would only consider > removing/simplifying some. After there is a large population of users we > can learn from actual security breaches and address security concerns that > arise - as they arise - in future enhancements to the protocol. There is no support for shared passwords with the current protocol so I'm not really sure what you're proposing here. Limiting the feature set to something that is not there while simultaneously recommending against adding new features? Dan. From owner-ipsec@lists.tislabs.com Thu Feb 7 10:24:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17IOO327394; Thu, 7 Feb 2002 10:24:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09371 Thu, 7 Feb 2002 12:13:24 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869947@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ipsec@lists.tislabs.com Subject: IPSECv2 Was: Thoughts on identity attacks Date: Thu, 7 Feb 2002 09:25:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I think the passive attack is the most important. Against an active attack, > it would be nice for the initiator's id to be protected in in road-warrior > cases and the responder's id to be protected otherwise. I think I disagree with this charaterisation. There are some active attacksthat is hard, others is not. For example the class of active man in the middle attacks in which the attacker intercepts all messages and replaces them somehow is very challenging. The class of active attack in which the attacker observes some information on the network and then introduces packets based on that data is not at all challenging. I absolutely agree that a security protocol that does not protect against active man-in-the-middle can add a lot of value. I don't think there is any value in a protocol that protects against passive attack but leaves all types of active attack out of scope. The other issue I think has been lost in this thread is that the requirements of VPN manufacturers are not necessarily the most relevant issue for IPSEC. IPSEC is meant to be a heck of a lot more than a VPN protocol. I think it is essential that IPSEC meet the requirements set by VPN marketing depts, but that is a necessary not a sufficient condition. Equally I think it is important that the requirement for identity concealment be justified by a requirement from some group of end users somewhere and for reasons that are grounded in a genuine security threat for which the proposed feature provides an effective control. The discussion is relevant in the context of son-of-IKE. The issue of whether identity concealment is actually required and and whether achieved in practice has a practical impact, it decides if you require 1 round trip plus a possible additional for DoS protection or require 2 in every case. The complexity of IKE is irrelevant to these discussions. Moreover the structure of IETF is not that of an industry consortium. The IETF structure is encourages proliferation of features and definition of six different ways to skin a cat. What we are really discussing here is IPSECv2, which will hopefully allow IPSEC to meet the original goal of A SECURE INTERNET PROTOCOL. It is good that IPSECv1 has found a useful niche in providing VPN support, but we are still travelling hopefully, we have not arrived. To achieve the goals of IPSECv2 it is essential that the complexity of the protocol be managed more effectively. Eliminating ESP mode and employing son-of-IKE reduce the complexity of the client, putting IPSEC within the reach of 802.11* NICs, handheld devices, media jukeboxes etc. It is also essential to address the complexity of the trust relationships. I disagree with the assertion that 90% of the complexity of PKI is in the I. In the case of IPSEC the main source of complexity is the fact that the PKI support in current products is simply insufficient to address applications beyond the closed VPN model. Nor is it the case that inserting the full PKIX stack into every client is going to solve this problem, in the first place the stack is too big to fit, in the second real world trust relationships are typically more subtle than can be expressed in a fixed certificate format such as X.509 that is limited to private keys. One approach is to take the complexity out of the IPSEC end points and put it in a trust service that is a specialist in that role. This is essentially what KINK attempts to do. The fundamental flaw of KINK is that attempting to scale symmetric key protocols up to Internet scale is hard, even if leavened with a smattering of post-facto public key features. Another approach is to use DNSSEC in some form, provided the working group agrees that the ability to deploy DNSSEC in the largest zones should be a requirement. This has promise but is only applicable for entities that have DNS names which is insufficient to address the full range of the potential of IPSEC. The approach I have been advocating for some time now is delegate the PKI processing functions from the IPSEC applications to a specialist trust service. We are currently working on an XML based protocol to do this in the W3C XKMS working group http://www.w3.org/2001/XKMS/. An XKMS trust service may be used to access keys from any underlying PKI, including PKIX, DNSSEC. The point about XKMS is not that it is necessarily the solution to every problem. I would be very happy if vendors said that they will implement a full PKIX stack in their product instead! What XKMS does do however is it removes the excuse that PKI is too complex so we either won't do it at all or do only a minimal wimpy version that is only useful in a very small application area. This stuff should be simple. IPSEC deployment should be made so simple that it can be done by consumers and network operators without even having to know how the thing works. What is more, it CAN be made simple. Cryptographic Plug and Play is well within the capabilities of the specifications out there already. All we have to do is come to an agreement about how they fit together. Phill From owner-ipsec@lists.tislabs.com Thu Feb 7 10:54:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Ist328316; Thu, 7 Feb 2002 10:54:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09470 Thu, 7 Feb 2002 13:04:11 -0500 (EST) Message-Id: <200202071715.g17HFZq00911@marajade.sandelman.ottawa.on.ca> To: "Khaja E. Ahmed" cc: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-reply-to: Your message of "Wed, 06 Feb 2002 19:16:46 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 07 Feb 2002 12:15:33 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Khaja" == Khaja E Ahmed writes: Khaja> My recommendation is quite simple: Do not add any feature or capability to Khaja> the protocol (or indeed any protocol or product for that matter) unless Khaja> there is substantial reason to believe that it serves a useful purpose and Khaja> will be used. okay, but please define "substantial". If your definition is equal to "popular" then we should be running PPTP. Khaja> What will be of great help is for you, Paul or someone else to cite Khaja> sources/information that makes a case for putting this feature in. The IPsec is a technology. It is not a solution. This is why I suggest that if you think that identity protection is unnecessary for your application, that you write a BCP on applying IPsec to solve your problem. I'm very serious here - take an appropriate subset of IPsec useful to VPN vendors, write *that* down. IPsec is NOT "network layer encryption". It is strong security features for IP. Khaja> By the way, it is probably not productive to exhume that old battle where Khaja> RFC writers/editors/contributors blame implementers for doing a Khaja> sloppy/mercenary job and implementers blaming RFC writers for producing Khaja> ambiguous, impractical and over engineered standards. Mistakes can and are Khaja> made on both sides. Please, let us not go there. ah, but if the real culprit for making IKE complex is in fact the certificate problems, then it seems unfair to demand that IKE get simpler when it is in fact dealing with certificates that makes it hard. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGK2M4qHRg3pndX9AQEKqAP8Cp2bpUAscCd11tLcxWo0JegW5h0dwPuf f8TAxtmo5wItTdpLuT2pD7U6vHCIEKtsS6K9uBkq23ZVu7IN+F7LhCLVX3VoiTQH 2BXIcRe3yuFquARmpvM768tS+b0PgcH30onFPCNhqS3+7EpnYvJ5H9eW5Y3XqcmF ArtHzLmtxeo= =SK2g -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Feb 7 10:56:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17Iue328386; Thu, 7 Feb 2002 10:56:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09489 Thu, 7 Feb 2002 13:11:59 -0500 (EST) Message-Id: <200202071822.NAA04583@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-sctp-03.txt Date: Thu, 07 Feb 2002 13:22:54 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : On the Use of SCTP with IPsec Author(s) : S. Bellovin et al. Filename : draft-ietf-ipsec-sctp-03.txt Pages : Date : 06-Feb-02 This document describes functional requirements for IPsec [RFC2401] and IKE [RFC2409] to facilitate their use for securing SCTP [RFC2960] traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-sctp-03.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-ietf-ipsec-sctp-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020206132218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-sctp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-sctp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020206132218.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Feb 8 08:35:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18GZs312593; Fri, 8 Feb 2002 08:35:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11636 Fri, 8 Feb 2002 10:32:30 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40586994E@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'bhargavi@austin.ibm.com'" , ipsec@lists.tislabs.com Subject: RE: Certificates from Verisign Date: Fri, 8 Feb 2002 07:44:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B0B7.728FE060" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_000_01C1B0B7.728FE060 Content-Type: text/plain; charset="iso-8859-1" Hi, Sorry for the delay, I have asked our partner relations people to get this information to you. I believe that the general approach has been more of the form 'how do we configure the VRSN PKI to deliver the certs you need'. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: bhargavi [mailto:bhargavi@austin.ibm.com] > Sent: Tuesday, February 05, 2002 12:03 PM > To: ipsec@lists.tislabs.com > Subject: Certificates from Verisign > > > Hi! > > Can anyone tell me how to request for a personal certificate and a CA > Certificate from Verisign. I need to do some testing in signature mode > of authentication. I could not locate it on the Verisign website... > verisign.com. > > Thanks, > Bhargavi > ------_=_NextPart_000_01C1B0B7.728FE060 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1B0B7.728FE060-- From owner-ipsec@lists.tislabs.com Fri Feb 8 10:52:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18IqS316006; Fri, 8 Feb 2002 10:52:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12043 Fri, 8 Feb 2002 13:06:12 -0500 (EST) Message-ID: From: "Flynn, Michael" To: "Hallam-Baker, Phillip" , "'bhargavi@austin.ibm.com'" , ipsec@lists.tislabs.com Subject: RE: Certificates from Verisign Date: Fri, 8 Feb 2002 09:09:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bhargavi, VeriSign has a site http://www.verisign.com/partnernet/enterprise/tools/bakeoff/main.html from which you can obtain certificates for IPsec testing. To enroll for a cert you can specify a file containing a PKCS#10, or use SCEP, CRS, etc. The details are on the site. Just remember to email bakeoff-support@verisign.com when you have enrolled so that somebody will approve it or if you have other questions. Michael > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Friday, February 08, 2002 7:44 AM > To: 'bhargavi@austin.ibm.com'; ipsec@lists.tislabs.com > Subject: RE: Certificates from Verisign > > > Hi, > > Sorry for the delay, I have asked our partner relations > people to > get this information to you. > > I believe that the general approach has been more of > the form 'how > do we configure the VRSN PKI to deliver the certs you need'. > > Phill > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: bhargavi [mailto:bhargavi@austin.ibm.com] > > Sent: Tuesday, February 05, 2002 12:03 PM > > To: ipsec@lists.tislabs.com > > Subject: Certificates from Verisign > > > > > > Hi! > > > > Can anyone tell me how to request for a personal > certificate and a CA > > Certificate from Verisign. I need to do some testing in > signature mode > > of authentication. I could not locate it on the Verisign website... > > verisign.com. > > > > Thanks, > > Bhargavi > > > > From owner-ipsec@lists.tislabs.com Sun Feb 10 09:38:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1AHcn327756; Sun, 10 Feb 2002 09:38:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15864 Sun, 10 Feb 2002 11:17:45 -0500 (EST) Message-Id: <200202101628.g1AGSYw01145@marajade.sandelman.ottawa.on.ca> To: internet-drafts@ietf.org cc: ipsec@lists.tislabs.com, design@lists.freeswan.org Subject: rewritten Opportunistic Encryption draft (-05) available Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 Feb 2002 11:28:34 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ID editor, please publish: http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic-05.txt Readers, I have not done change bars on this one. The document has been rototiled based upon suggestion to "make it more RFC791-like". What was previously specified in terms of packet timing diagrams is not specified as two intertwined state machine definitions (forwarding and control plane). The previous packet timing diagram is now just an illustrated example. I would strongly appreciate feedback on the readability and flow of this document. I think that it is much improved in technical content. Thank you. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGafsIqHRg3pndX9AQH1twP/ZDOcgpiF3SbDz+JpI+jQH3eON4yK1Cj9 HLa8VSK/YuGuFzZjdnkFWTnbsv8Z5CG/QnwaYFnb1KQWvMoh89RR9Km+ebzAMASf AjTgLqLm0bsjAq2ueMbnzgPPU50+waT3NKrp7kSn5ZohMstcY/3PhDZhc4E2aPEx 9qYvVsSWcKg= =jLnr -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Feb 11 09:16:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BHGj302422; Mon, 11 Feb 2002 09:16:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18144 Mon, 11 Feb 2002 11:11:51 -0500 (EST) Message-ID: <20020211162256.59253.qmail@web21006.mail.yahoo.com> Date: Mon, 11 Feb 2002 08:22:56 -0800 (PST) From: Yang Xiao Reply-To: YangXiao@ieee.org Subject: CFP: Modeling, Analysis, and Simulation of Wireless LANs and Mobile Ad Hoc Networks and QoS Issues To: YangXiao@ieee.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My apologies if you receive this CFP duplicated. ------------------- Call for Papers- Deadline extented Invited Session Title: Modeling, Analysis, and Simulation of Wireless LANs and Mobile Ad Hoc Networks and QoS Issues Invited Session in the 6th World Multi-Conference on Systemics, Cybernetics and Informatics, (SCI 2002) Orlando, Florida, USA, July 14 -18, 2002 Topics of Interest Wireless LANs & Mobile Ad Hoc Networks (not limited to) Simulation, Modeling and performance evaluation of Wireless LANs, such as IEEE 802.11, HIPERLAN, and Ad hoc Networks. Quality-of-service issues in Wireless LANs (IEEE 802.11e, HIPERLAN/2, etc.) and Ad Hoc Networks. Power Consumption issues Higher data rates 3G/4G-WLAN Differentiated Services for Wireless LANs Co-existence of the IEEE 802.11 and 802.15 Resource Management Analytical methods. Deadlines Submission of Extended Abstracts: February 25, 2002 Notification of Acceptance: March 15, 2002 Camera Ready Copies: April 03, 2002 Session Co-Organizers/co-chairs Dr. Yang Xiao, Micro Linear, USA Dr. Bin Wang, Wright State University, USA Instructions For Submission Submission should be in the form of extended abstracts up to 4 pages long. All submitted contributions will be subject to peer review on the basis of technical correctness, quality, relevance, originality, significance, and clarity. Abstracts should be in MS Word, PDF or PS format. Submissions should be sent to the session's co-organizers. Successful submissions will be asked to submit a full paper. Full papers must be formatted according to IEEE-CS guidelines Electronic Submission: Dr. Yang Xiao: YangXiao@IEEE.ORG Dr. Bin Wang: bwang@cs.wright.edu For more details check at http://www.iiis.org/sci2002/ last updated 02/11/02 __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-ipsec@lists.tislabs.com Tue Feb 12 06:08:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CE86303824; Tue, 12 Feb 2002 06:08:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA20046 Tue, 12 Feb 2002 07:57:50 -0500 (EST) Message-ID: <001901c1b3c8$f2c7dc60$ae0510ac@roc.com> Reply-To: "Lokesh" From: "Lokesh" To: Subject: doubt on draft-ietf-ipsec-nat-t-ike-01.txt Date: Tue, 12 Feb 2002 18:56:55 +0530 Organization: Intoto Software India Pvt Ltd. Secunderabad. (India) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, Following is a doubt regrading ID draft-ietf-ipsec-nat-t-ike-01 It proposes, that sending party should calculate NAT-D paylods for both Destination and source(its own) IP address and port pairs. that is HASH = HASH( CKY-I | CKY-R | IP | Port) So in Normal case,(host is not multihomed) there will be two NAT-D payloads. I want to know why it is proposed to send 2 NAT-D payloads? For me , it looks that, there is not need for First NAT-D payload which is Hash on Destination IP and port. because Destination IP and Ports are not going to change in NAT, only Source ip and source ports are changed. sending party can send only Second NAT-D payload (HASH on its own IP and src port) , and receiving can determine occurance of NAT as follows. take src ip and src port selectors from incoming packet, prepare HASH on them and compare with HASH or NAT-D payload sent by other peer. If match is ok, there is no NAT, if it fails, there is a NAT. Is that Ok? or Am I missing some point here? if so correct me please. Thanks -Lokesh From owner-ipsec@lists.tislabs.com Tue Feb 12 07:20:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CFKr306443; Tue, 12 Feb 2002 07:20:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20342 Tue, 12 Feb 2002 09:37:33 -0500 (EST) To: "Lokesh" Cc: Subject: Re: doubt on draft-ietf-ipsec-nat-t-ike-01.txt References: <001901c1b3c8$f2c7dc60$ae0510ac@roc.com> From: Derek Atkins Date: 12 Feb 2002 09:48:39 -0500 In-Reply-To: <001901c1b3c8$f2c7dc60$ae0510ac@roc.com> Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk By sending the Destination you can tell the Initiator whether they are behind a NAT. The initiator cannot tell on their own without help. If the initiator gets a NAT_T payload that says "here is the hash of _your_ IP/Port as I received it" and the hash doesn't match what the initiator hashed for its own IP/Port, then now it knows it's behind a NAT. -derek "Lokesh" writes: > Hi All, > Following is a doubt regrading ID draft-ietf-ipsec-nat-t-ike-01 > It proposes, that sending party should calculate NAT-D paylods for > both Destination and source(its own) IP address and port pairs. > that is HASH = HASH( CKY-I | CKY-R | IP | Port) > So in Normal case,(host is not multihomed) there will be > two NAT-D payloads. > I want to know why it is proposed to send 2 NAT-D payloads? > For me , it looks that, there is not need for First NAT-D payload > which is Hash on Destination IP and port. > because Destination IP and Ports are not going to change in NAT, > only Source ip and source ports are changed. sending party can send > only Second NAT-D payload (HASH on its own IP and src port) , > and receiving can determine occurance of NAT as follows. > take src ip and src port selectors from incoming packet, > prepare HASH on them and compare with HASH or NAT-D payload sent > by other peer. If match is ok, there is no NAT, if it fails, there is a NAT. > > Is that Ok? or Am I missing some point here? if so correct me please. > > Thanks > -Lokesh > > > > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Feb 12 08:26:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CGQV309457; Tue, 12 Feb 2002 08:26:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20616 Tue, 12 Feb 2002 10:32:54 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: doubt on draft-ietf-ipsec-nat-t-ike-01.txt References: <001901c1b3c8$f2c7dc60$ae0510ac@roc.com> Organization: SSH Communications Security From: Markus Stenberg Date: 12 Feb 2002 17:50:29 +0200 Message-ID: <87pu3aaed6.fsf@ssh.com> Lines: 50 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA20599 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk lokeshnb@intotoinc.com ("Lokesh") writes: > Hi All, Hi. > Following is a doubt regrading ID draft-ietf-ipsec-nat-t-ike-01 > It proposes, that sending party should calculate NAT-D paylods for > both Destination and source(its own) IP address and port pairs. > that is HASH = HASH( CKY-I | CKY-R | IP | Port) > So in Normal case,(host is not multihomed) there will be > two NAT-D payloads. > I want to know why it is proposed to send 2 NAT-D payloads? > For me , it looks that, there is not need for First NAT-D payload > which is Hash on Destination IP and port. > because Destination IP and Ports are not going to change in NAT, [*] > only Source ip and source ports are changed. sending party can send only > Second NAT-D payload (HASH on its own IP and src port) , and receiving > can determine occurance of NAT as follows. take src ip and src port > selectors from incoming packet, prepare HASH on them and compare with > HASH or NAT-D payload sent by other peer. If match is ok, there is no > NAT, if it fails, there is a NAT. > > Is that Ok? or Am I missing some point here? if so correct me please. [*] Oh? Is there a guarantee about this somewhere? Consider this: initiator ---> contacts 1.2.3.4 ---> static nat ---> responder (2.3.4.5) Obviously, the responder is behind the NAT, and not the initiator. It should be possible to run IPsec regardless given the payloads specified in the draft, but not with changes you specify. Also, in normal NAT case, with your changes, the other side would NOT know about the NAT; obviously, when the responder sends his src address, it stays the same to the initiator (as nobody alters it) and initiator wouldn't know of presence of a NAT device, unless responder sent something else than just normal address as response (like the `DECISION' payload in my older draft). > Thanks > -Lokesh -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) SSH $B0O8k@h@8(B From owner-ipsec@lists.tislabs.com Tue Feb 12 13:24:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CLOE315982; Tue, 12 Feb 2002 13:24:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21201 Tue, 12 Feb 2002 15:24:18 -0500 (EST) From: "Khaja E. Ahmed" To: "Dan Harkins" Cc: "Paul Hoffman / VPNC" , Subject: RE: RESEND: Thoughts on identity attacks Date: Tue, 12 Feb 2002 12:34:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200202070635.g176Zbe02063@fatty.lounge.org> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Please do not treat this as an assault on the product of your love and labor. Treat this as nothing more than an appeal for simplicity in any successor/replacement to IKE. IKE is clearly is a very sophisticated, rich and elaborate protocol. It's influence and comprehensiveness is also evidenced by the fact that popular successor candidates have really made no departure from IKE1s current structure or even the entirety of it's goals. I may well be the only one who wishes this but I was thinking that it would be great to have a radically simple alternative that can be an option perhaps coexisting with IKE2. Rather like the coexistence of SSL 2.0 and 3.0 in implementations supporting the two. I was hoping to see such an alternative fielded as a successor. Such an alternative would do only the minimum necessary to create an SA for ESP. You are quite right to point out that I may not be aware of the context here. I am not as active a participant/reader of this list as I would like to be so I don't know if it is acceptable for a candidate successor to IKE to start from a clean slate and even sacrifice backward compatibility with IKE. One goal that such an alternative could depart from is the goal of affording anything like Identity protection. Firstly, it is really hard to deliver given all the other things that give away identity, in most cases, of communicating parties. Secondly, and more importantly, there seems to be no one clamoring for this feature. I am not even hearing anything to suggest that anyone thinks otherwise. The only comment I hear on this suggests that input from product managers and users would be deemed worthless. You, and perhaps others, appear to have written of one as being apathetic and the other as being stupid. I myself don't subscribe to the view that a few really clever people who understand it all can devise the solution and save the users from corporate avarice and their own ignorance. Also, I am not sure that many product managers or users are likely to step forward and feel comfortable sharing their views given how they are viewed. As for Identity Protection, it is clear that IKE1 is stuck with it. It is less clear that we should accept that as our permanent fate. I suggest that at some point if we eliminate that requirement as a goal it is quite likely that it contribute to the simplification of whatever we come up with as a method to achieve the goal. Once again, this is not a criticism of all the excellent work that you and many other people have put in to develop/refine IKE and it's successors. If nothing else, treat this as a suggestion to reexamine the constraints / requirements that we may have placed on SuccessorToIKE. Couple of final clarifications: I mentioned VPNs only as an example. In most other applications Identity protection is equally uninteresting or even less (as in iSCSI). I meant shared secrets not shared password. Khaja > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Wednesday, February 06, 2002 10:36 PM > To: Khaja E. Ahmed > Cc: Paul Hoffman / VPNC; ipsec@lists.tislabs.com > Subject: Re: RESEND: Thoughts on identity attacks > > > On Wed, 06 Feb 2002 11:05:52 PST you wrote > > Paul, > > > > Perhaps the fact that there were no responses suggests that not enough > > people think it is important. Let me introduce a counter view. > I not only > > think it is not important but I think that pursuit of this goal risks > > further complicating an already too complicated protocol. I > really think > > our energies are best directed at more important issues. > > I don't think you understand the context here. It is not to add some new > feature to "an too already complicated protocol", it is to determine what > a new protocol should/must have. > > As far as "already complicated protocols" go the one we're stuck with now > already has a mode of protecting both identities from passive attack and > also one that protects both from active attack (provided the Initiator > already knows the Responder's public key). So this discussion is about > _simplifying_ things by removing what is not needed not further > complicating > things by adding something new. > > > After a year of discussions on requirements with product > management of all > > the big VPN manufacturers, I have never even once heard that identity > > protection or 'obfuscated identities' are a requirement. Of > course as the > > chair of the VPNC you may know much more about these matters > and I would be > > delighted if you or someone could point me at data that > suggests that this > > is a requirement among manufacturers and/or the user community. > > Product management of all the big VPN manufacturers? Aren't those the same > ones who said, "We know it's insecure but it's easy to deploy and > customers > want it so shut up and implement it." > > Product management from any company do not frame debate here. On the other > hand if someone from product management from a big VPN manufacturer wishes > to add his or her points of view it would probably be better done directly > and not through rumor. > > > I think most companies find PKI itself too complicated. Both > VPN solution > > providers and large users seem to prefer to stick with shared passwords > > rather than build support for or manage a PKI. Things like > PKIX compliant > > path validation, CRL / OCSP support, certificate life cycle management, > > enrollment, etc. scare away all but the most intrepid. At this point I > > would NOT recommend adding any more features and would only consider > > removing/simplifying some. After there is a large population > of users we > > can learn from actual security breaches and address security > concerns that > > arise - as they arise - in future enhancements to the protocol. > > There is no support for shared passwords with the current protocol so I'm > not really sure what you're proposing here. Limiting the feature set to > something that is not there while simultaneously recommending > against adding > new features? > > Dan. > > > > From owner-ipsec@lists.tislabs.com Tue Feb 12 14:12:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMCx317061; Tue, 12 Feb 2002 14:12:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21260 Tue, 12 Feb 2002 16:32:12 -0500 (EST) Message-Id: <200202122141.g1CLfih00390@fatty.lounge.org> To: "Khaja E. Ahmed" Cc: "Paul Hoffman / VPNC" , ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-Reply-To: Your message of "Tue, 12 Feb 2002 12:34:17 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <387.1013550103.1@tibernian.com> Date: Tue, 12 Feb 2002 13:41:44 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Khaja, On Tue, 12 Feb 2002 12:34:17 PST you wrote > Please do not treat this as an assault on the product of your love and > labor. Treat this as nothing more than an appeal for simplicity in any > successor/replacement to IKE. IKE is clearly is a very sophisticated, rich > and elaborate protocol. It's influence and comprehensiveness is also > evidenced by the fact that popular successor candidates have really made no > departure from IKE1s current structure or even the entirety of it's goals. > I may well be the only one who wishes this but I was thinking that it would > be great to have a radically simple alternative that can be an option > perhaps coexisting with IKE2. Rather like the coexistence of SSL 2.0 and > 3.0 in implementations supporting the two. I was hoping to see such an > alternative fielded as a successor. Such an alternative would do only the > minimum necessary to create an SA for ESP. Please don't take this or my previous email as an assault on your sincere desire for simplicity. And you don't need to make gratuitous compliments. IKE is a protocol that no one likes, including me. What features are the "the minimum necessary"? > You are quite right to point out that I may not be aware of the context > here. I am not as active a participant/reader of this list as I would like > to be so I don't know if it is acceptable for a candidate successor to IKE > to start from a clean slate and even sacrifice backward compatibility with > IKE. There are no restrictions on what can be the replacement protocol for IKE. I encourage you to check out the proposals and see for yourself. > One goal that such an alternative could depart from is the goal of affording > anything like Identity protection. Firstly, it is really hard to deliver > given all the other things that give away identity, in most cases, of > communicating parties. Secondly, and more importantly, there seems to be no > one clamoring for this feature. I am not even hearing anything to suggest > that anyone thinks otherwise. The only comment I hear on this suggests that > input from product managers and users would be deemed worthless. You, and > perhaps others, appear to have written of one as being apathetic and the > other as being stupid. I myself don't subscribe to the view that a few > really clever people who understand it all can devise the solution and save > the users from corporate avarice and their own ignorance. Also, I am not > sure that many product managers or users are likely to step forward and feel > comfortable sharing their views given how they are viewed. It is interesting that you admit to not knowing the context of the discussion and did obviously not use the past week (since our last exchange of emails) to come up to speed on the issues yet you seem to know that no one wants identity protection. How do you know that? What do they want then? If you know what the requirements are then please tell us all what they are so we can just avoid this (apparently pointless) discussion and get on to the task of satisfying them. Some people obviously think identiy protection is needed or we wouldn't be discussing it. But if you know otherwise then please enlighten us. My reference to the product marketing people from the major VPN vendors was in the support for a group pre-shared key (or worse a NULL pre-shared key) and XAUTH. Most every "major VPN vendor" supports this horribly insecure hack. Why? Because customers want it. That's why. And product management insisted on it being implemented. It is not really apathetic or stupid. It is more like putting expediency above security. People who would demand such a thing should be made uncomfortable. I'm glad they don't work for "major healthcare providers". > Once again, this is not a criticism of all the excellent work that you and > many other people have put in to develop/refine IKE and it's successors. If > nothing else, treat this as a suggestion to reexamine the constraints / > requirements that we may have placed on SuccessorToIKE. Please, you're making me blush.... > Couple of final clarifications: > I mentioned VPNs only as an example. In most other applications Identity > protection is equally uninteresting or even less (as in iSCSI). > > I meant shared secrets not shared password. If that's what you meant then you shouldn't have written "shared password". But please explain the difference anyway. What sort of authentication technique do "VPN solution providers and large users" want? Dan. From owner-ipsec@lists.tislabs.com Tue Feb 12 14:46:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMkg317567; Tue, 12 Feb 2002 14:46:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21324 Tue, 12 Feb 2002 17:06:02 -0500 (EST) Message-Id: <5.1.0.14.0.20020212220819.04870d60@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Feb 2002 22:27:00 -0500 To: Dan Harkins From: David Jablon Subject: Re: RESEND: Thoughts on identity attacks Cc: "Khaja E. Ahmed" , "Paul Hoffman / VPNC" , ipsec@lists.tislabs.com In-Reply-To: <200202122141.g1CLfih00390@fatty.lounge.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:41 PM 2/12/02 -0800, Dan Harkins wrote: >On Tue, 12 Feb 2002 12:34:17 PST Khaja wrote >> I meant shared secrets not shared password. > > If that's what you meant then you shouldn't have written "shared password". >But please explain the difference anyway. [...] I'm pretty sure that Dan was asking a rhetorical question here. But it is a point of common confusion. To help, I propose the following definitions, based on observed common usage: shared [secret] password: a low-entropy secret authenticator. shared [secret] key: a high-entropy cryptographic secret. shared secret: a key that was probably derived from a password, but used in a cryptographic system in which there is misplaced hope that the secret truly does have high entropy. I think this, plus the ambiguity argument, makes a good case for "shared secret" to be deprecated. -- David From owner-ipsec@lists.tislabs.com Tue Feb 12 14:46:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CMkg317568; Tue, 12 Feb 2002 14:46:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21331 Tue, 12 Feb 2002 17:09:30 -0500 (EST) Message-Id: <200202122220.RAA20265@bcn.East.Sun.COM> Date: Tue, 12 Feb 2002 17:20:37 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: RESEND: Thoughts on identity attacks To: khaja.ahmed@attbi.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: R7l962zD0MHq3ii5QksTKw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Khaja, Invariably protocols get designed with options and functionality that aren't all that important. Sometimes people like to have things that might prove useful in the future, if they aren't that expensive to provide, so that a new protocol won't need to be designed if people do decide the feature is important. Assuming it was possible to have a radically simpler protocol for most cases, if it were *in addition* to the more general protocol for the rest of the cases, the total solution would obviously be more complicated than something that solves what the WG wants (or thinks it wants). You are proposing getting rid of identity hiding completely. If that would make the protocol radically simpler, that would certainly be a good idea. So, the question is, what is the cost of providing identity hiding in IKEv2? IKEv2 is a four-message exchange that sets up not only a phase 1 SA but an ESP SA. How could it be simpler than that? Well, one could make IKEv2 be a two-message protocol if you gave up not just identity hiding, but anti-clogging protection of computation and state, ability to send certificates along with the handshake so you don't need another mechanism to obtain the other side's cert, crypto negotiation, rekeying SAs, and the ability to cheaply create lots of child-SAs off a single IKE SA. Is all that functionality worth having 4 messages rather than 2? Once you go with 4 messages, the identity hiding is free. It does not complicate the protocol. It seems prudent, if IKEv2 is simple enough, not to try to remove functionality that a significant number of people think is or might be important. That is...IF it isn't really expensive to provide it. This is all engineering tradeoff stuff...each option that might be useful makes the protocol slightly more complex. If one goes overboard, one gets something everyone will clearly say is too complicated. I think IKEv1 was clearly too complicated, but it wasn't only because of too many options and features...it was also that the documents were so hard to understand and in so many pieces that nobody got a chance to really get the whole protocol in their heads to think it through and keep it clean. I, at least, think that the IKEv2 document fits in a mortal's head, and it could be somewhat simpler if we did, for instance: a) remove the two phases...I argued for getting rid of phase 2 originally, but I've gotten enough feedback from people who really want to create lots of phase 2 SAs so that different flows can use different keys. Also it makes rekeying easy. b) remove identity hiding entirely...but there are "peer-to-peer" people who have said they think it might wind up important in certain scenarios, as well as Charlie K's example of "protecting the customer of the sleazy porn merchant" c) remove AH...there are vocal advocates of AH d) remove crypto negotiation entirely: define one suite, and that's what IPsec uses. That's undoubtedly too radical, unfortunately. I'd love it if the protocol said "use AES for encryption, etc." but with changing export laws, crypto algorithms getting broken, countries and or organizations wanting to substitute their own crypto, etc., I've come to accept this as a necessity. e) change crypto negotiation to entire suites rather than each algorithm separately...I would like to see this done...it simplifies things somewhat...not spectacularly...it's really just syntax. I am always an advocate of simplicity, but in engineering no single factor outweighs all others. You have to trade off functionality, flexibility, and time-to-market (which includes getting a WG who has come to want a certain feature to be willing to get rid of it, which will be a difficult sell if the feature really doesn't make the protocol significantly more complicated or expensive). Should the WG argue about getting rid of all the above in order to have the "simplest possible" protocol, if it winds up being only slightly simpler? Radia From owner-ipsec@lists.tislabs.com Tue Feb 12 16:38:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D0cM319705; Tue, 12 Feb 2002 16:38:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21532 Tue, 12 Feb 2002 18:59:42 -0500 (EST) Message-Id: <200202130009.g1D09Bh00648@fatty.lounge.org> To: David Jablon Cc: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-Reply-To: Your message of "Tue, 12 Feb 2002 22:27:00 EST." <5.1.0.14.0.20020212220819.04870d60@pop.theworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <645.1013558951.1@tibernian.com> Date: Tue, 12 Feb 2002 16:09:11 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well not entirely rhetorical. What I was asking for was his opinion of what these people want and are using. The mandatory-to-implement authentication method for IKE does not distinguish between a "shared [secret] password" and a "shared [secret] key". As long as it's shared and symmetric the "entropy" doesn't matter. But given how broken the mandatory-to-implement authentication method is I'm surprised that this is what is being used in the large deployments he was talking about. Or maybe he's talking about legacy authentication using RADIUS or the like. I don't know. I'd like to know though. Dan. On Tue, 12 Feb 2002 22:27:00 EST you wrote > At 01:41 PM 2/12/02 -0800, Dan Harkins wrote: > >On Tue, 12 Feb 2002 12:34:17 PST Khaja wrote > >> I meant shared secrets not shared password. > > > > If that's what you meant then you shouldn't have written "shared password" >. > >But please explain the difference anyway. [...] > > I'm pretty sure that Dan was asking a rhetorical question here. > But it is a point of common confusion. > > To help, I propose the following definitions, based on observed common usage: > > shared [secret] password: > a low-entropy secret authenticator. > > shared [secret] key: > a high-entropy cryptographic secret. > > shared secret: > a key that was probably derived from a password, but used in > a cryptographic system in which there is misplaced hope that > the secret truly does have high entropy. > > I think this, plus the ambiguity argument, makes a good case for > "shared secret" to be deprecated. > > -- David > > From owner-ipsec@lists.tislabs.com Wed Feb 13 01:28:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D9SG324720; Wed, 13 Feb 2002 01:28:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA22375 Wed, 13 Feb 2002 03:33:17 -0500 (EST) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC0173B991@highway> From: 827 <827@nu.edu.pk> To: "'ipsec@lists.tislabs.com'" Subject: Block Mode? Date: Wed, 13 Feb 2002 13:46:32 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I heard that there is some new mode under consideration, by the name of "Block Mode"?... If yes, can any one help where can i get help for that? Regards From owner-ipsec@lists.tislabs.com Wed Feb 13 06:39:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DEd4317761; Wed, 13 Feb 2002 06:39:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23061 Wed, 13 Feb 2002 08:40:00 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: RE: RESEND: Thoughts on identity attacks To: "Khaja E. Ahmed" Cc: "Dan Harkins" , "Paul Hoffman / VPNC" , X-Mailer: Lotus Notes Build M12_01312002 Pre-release 1 January 31, 2002 Message-ID: Date: Tue, 12 Feb 2002 18:06:35 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.9a |January 7, 2002) at 02/12/2002 06:05:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Khaja E. Ahmed" wrote: > Please do not treat this as an assault on the product of your love and > labor. Treat this as nothing more than an appeal for simplicity in any > successor/replacement to IKE. IKE is clearly is a very sophisticated, rich > and elaborate protocol. It's influence and comprehensiveness is also > evidenced by the fact that popular successor candidates have really made no > departure from IKE1s current structure or even the entirety of it's goals. > I may well be the only one who wishes this but I was thinking that it would > be great to have a radically simple alternative that can be an option > perhaps coexisting with IKE2. Rather like the coexistence of SSL 2.0 and > 3.0 in implementations supporting the two. I was hoping to see such an > alternative fielded as a successor. Such an alternative would do only the > minimum necessary to create an SA for ESP. > > You are quite right to point out that I may not be aware of the context > here. I am not as active a participant/reader of this list as I would like > to be so I don't know if it is acceptable for a candidate successor to IKE > to start from a clean slate and even sacrifice backward compatibility with > IKE. > > One goal that such an alternative could depart from is the goal of affording > anything like Identity protection.... Creeping complexity seems almost inevitable in the evolution of protocols. There are several causes. Designers find features that are really neat and appear almost free, so what the heck. Usually these features turn out to not be free as they interact with later design changes. People propose requirements that might be useful in some application that may or may not materialize, and it's easier to acquiesce than to argue. And deployment experience reveals weaknesses that need to be plugged. Rarely does anyone propose a simplification, because it would offend the person who added the feature and rarely would a single simplification make a protocol that much better. It takes a reengineering from the ground up. I believe many features in IKE are in the category of "seemed almost free" at the time, and so are included without any demonstrated need. Identity hiding is one. Stateless cookies is another. The ability to craft incredibly complex combinations of crypto algorithms and ESP/AH/IPCOMP combinations is a third. Having a phase I and a phase II is a fourth. There are options that I suspect no one uses but were added on speculation. These include certificate requests. There are options that exist only because people couldn't make decisions, like Aggressive Mode vs. Main Mode. I wish I could say there are things added based on deployment experience, but I don't think there are any. If we ever hope to use IPSEC to secure shared system to shared system communications, there will be a need for some identity information beyond what we have today, but I am loathe to propose anything based on speculation... that's how we got here. As one of the contributors to an IKEv2 proposal, I went into the project with the enthusiasm you express for making radical simplifications. But my higher priority was to get something that was clearly and unambiguously specified, and in many cases didn't argue for a simplification because it seemed more likely to spur debate than to quell it. The clear feedback from the last meeting and the list is that more simplification would be good... well, except that authentication based on configured secret keys should probably be added back. We're trying to do that. I see the following as "so easy that there is no point removing it". In aggregate they add significant complexity. 1) Identity hiding 2) Stateless cookies 3) Multiple phase IIs from a phase I 4) Piggybacked certificate requests 5) AH 6) IPcomp I haven't dared propose removing any of them. Nor am I doing so now. But I'm certainly not prepared to defend any of them on any grounds other than "I think we would spend more time debating their removal than making them work." Your mileage may vary. --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. From owner-ipsec@lists.tislabs.com Wed Feb 13 07:57:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DFvK322274; Wed, 13 Feb 2002 07:57:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23368 Wed, 13 Feb 2002 10:14:00 -0500 (EST) Message-Id: <5.1.0.14.0.20020213041156.00a6c620@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Feb 2002 15:32:18 -0500 To: Dan Harkins From: David Jablon Subject: Re: RESEND: Thoughts on identity attacks Cc: ipsec@lists.tislabs.com In-Reply-To: <200202130009.g1D09Bh00648@fatty.lounge.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I couldn't help but notice some odd comments on keys and passwords in your response: At 04:09 PM 2/12/02 -0800, Dan Harkins wrote: >... The mandatory-to-implement >authentication method for IKE does not distinguish between a "shared >[secret] password" and a "shared [secret] key". ... IKE definines it as "authentication via pre-shared keys", with "key" very clearly present, and "password" nowhere to be found. The distinction seems clear to me. > As long as it's shared >and symmetric the "entropy" doesn't matter. ... Of course entropy (as a measure of randomness) matters, just like size. A suffiently low-entropy pre-shared key makes IKE completely broken. A sufficiently high-entropy pre-shared key, if mananaged properly, works just fine, even though such systems may encounter scalability problems in certain environments. >... But given how broken the >mandatory-to-implement authentication method is I'm surprised that this >is what is being used in the large deployments he was talking about. ... It seems that you've using the word "broken" in a very specialized sense, highlighting advantages of the "non-mandatory" public-key-based authentication methods. The trouble is, the world has enough trouble coming to grips with the basic distinction of passwords vs. keys. Noone benefits from blurring this distinction. Perhaps the confusion reflects your focus on certain issues to the exclusion of others, which, I'll admit, is also a problem not unfamiliar to me. :-) -- David From owner-ipsec@lists.tislabs.com Wed Feb 13 08:45:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DGjm323913; Wed, 13 Feb 2002 08:45:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23508 Wed, 13 Feb 2002 11:12:55 -0500 (EST) Message-Id: <200202131623.g1DGNkb11702@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-reply-to: Your message of "Tue, 12 Feb 2002 18:06:35 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Feb 2002 11:23:46 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> I believe many features in IKE are in the category of "seemed Charlie> almost free" at the time, and so are included without any Charlie> demonstrated need. Identity hiding is one. Stateless cookies is Charlie> another. The ability to craft incredibly complex combinations of Charlie> crypto algorithms and ESP/AH/IPCOMP combinations is a Charlie> third. Having a phase I and a phase II is a fourth. Well, FreeSWAN oe specifies: - Identity hiding (always use Main Mode) - Cookies are required because we are prepared to talk to anyone, so we can't ignore connections we do not recognize. - we agree that the combination of crypto algorithms is silly, we should have suites. There was the feeling that there would be too many suites at the time. - we take advantage of phase I/II very frequently, as we do per-host keying. It lets us amortize DH work over many connections. Charlie> There are options that I suspect no one uses but were added on If you like, you may say "the option to not use these" is an option that maybe nobody uses. Charlie> good... well, except that authentication based on configured Charlie> secret keys should probably be added back. We're trying to do Charlie> that. As long as you don't create a new option akin to "aggressive mode" ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPGqTEIqHRg3pndX9AQGSxAP/c70j7ulQ7mujCQoKH84RfS7X3VqWUS0A uBZNpQeNxllpOjTqtx/t4rmAStjTPNsJkr8YGIDoZtwJufrWhdOoP7+HnTaR2YZ3 NIH1/y7rL7wRVvru4e5xkBNwOz6maOElLfzzWnph1acvNRfmUCm0K4UwpVGzmD8a 6jvv4XjFQCI= =mlcu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 13 11:47:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DJlN329503; Wed, 13 Feb 2002 11:47:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23973 Wed, 13 Feb 2002 13:56:41 -0500 (EST) To: Charlie_Kaufman@notesdev.ibm.com Cc: "Khaja E. Ahmed" , "Dan Harkins" , "Paul Hoffman / VPNC" , Subject: Re: RESEND: Thoughts on identity attacks References: From: Derek Atkins Date: 13 Feb 2002 14:04:05 -0500 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com writes: > I believe many features in IKE are in the category of "seemed almost free" > at the time, and so are included without any demonstrated need. Identity > hiding is one. Stateless cookies is another. The ability to craft > incredibly > complex combinations of crypto algorithms and ESP/AH/IPCOMP combinations > is a third. Having a phase I and a phase II is a fourth. I think stateless cookies are extremely important to protect against resource starvation attacks (ala the TCP SYN attack). If I can cause your IKE daemon to store a lot of state by sending it a single (forged) UDP packet, I can effectively starve your system. With stateless cookies you at least have reachability to gain a better idea who is trying to attack you -- the attacker must be somewhere on the path between you and the IP address being used to attack you. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Feb 13 12:29:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DKTo301149; Wed, 13 Feb 2002 12:29:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24109 Wed, 13 Feb 2002 14:52:57 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869966@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , Charlie_Kaufman@notesdev.ibm.com Cc: "Khaja E. Ahmed" , Dan Harkins , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: RE: RESEND: Thoughts on identity attacks Date: Wed, 13 Feb 2002 12:04:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B4C9.AF979E60" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_000_01C1B4C9.AF979E60 Content-Type: text/plain; charset="iso-8859-1" Derek, I agree that the stateless cookie is very important. However there is no value in the stateless cookie unless you also have the ability to filter out DoS attacks from fixed IP addresses. This being the case I would rather unpack the stateless cookie and make it a part of a DoS package. I much prefer the following scheme: 1) All Initiators (aka clients) MUST be capable of repeating a request with a stateless cookie if required 2) Responders MAY respond to a cookie-less request by requesting a cookie. This allows the 2 round trip JFK scheme to be reduced to 1 required and 1 optional round trip. A responder that is not going to do anything more sophisticated can require cookies on every request. It is not much more work to only require cookies on an 'as necessary' basis. A responder that has code to deal with the DoS from fixed IP address problem would not be impacted in a major way. Remember that if we do cookie protection well it becomes unnecessary because there is no point in an attacker trying that approach. So 1 mandatory + 1 optional round trip becomes on average 1 round trip. There is a major performance difference between 1 round trip and 2 on many of the wireless applications. Certainly when it comes for Web services I will be pushing for a generic DoS protection mechanism for Web services generally (i.e. at the SOAP layer) rather than a mechanism that is limited to one specific protocol such as XKMS or XKASS. As for the rest of Charlie's list. I would very much like to define an IPSEC subset that is as streamlined as possible and does go to the trouble of removing unnecessary junk. I do not believe that the current set of specifications built arround the capabilities of engineering workstations is viable when applied to low cost embedded devices. As to Charlie's point about 'the cost of argument'. It is notable that most of the advances in computer science come from throwing junk out rather than adding more. Java is only interesting because it chucked out the junk in C++. C was interesting because it chucked out the junk of CPL. It is very easy to develop an ADA in committee. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Wednesday, February 13, 2002 2:04 PM > To: Charlie_Kaufman@notesdev.ibm.com > Cc: Khaja E. Ahmed; Dan Harkins; Paul Hoffman / VPNC; > ipsec@lists.tislabs.com > Subject: Re: RESEND: Thoughts on identity attacks > > > Charlie_Kaufman@notesdev.ibm.com writes: > > > I believe many features in IKE are in the category of > "seemed almost free" > > at the time, and so are included without any demonstrated > need. Identity > > hiding is one. Stateless cookies is another. The ability to craft > > incredibly > > complex combinations of crypto algorithms and ESP/AH/IPCOMP > combinations > > is a third. Having a phase I and a phase II is a fourth. > > I think stateless cookies are extremely important to protect against > resource starvation attacks (ala the TCP SYN attack). If I can cause > your IKE daemon to store a lot of state by sending it a single > (forged) UDP packet, I can effectively starve your system. With > stateless cookies you at least have reachability to gain a better idea > who is trying to attack you -- the attacker must be somewhere on the > path between you and the IP address being used to attack you. > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > ------_=_NextPart_000_01C1B4C9.AF979E60 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1B4C9.AF979E60-- From owner-ipsec@lists.tislabs.com Wed Feb 13 14:09:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DM9E304070; Wed, 13 Feb 2002 14:09:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24288 Wed, 13 Feb 2002 16:25:52 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hallam-Baker, Phillip'" Cc: Subject: RE: RESEND: Thoughts on identity attacks Date: Wed, 13 Feb 2002 16:30:53 -0500 Message-ID: <002501c1b4d5$b8193ce0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869966@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phill, Have you read the JFK draft? The idea of a generalized cookie mechanism for IP/TCP is something I've toyed with. For applications where you don't necessarily want to do IPsec, but DoS attacks are very important (e.g. wireless, specifically IP paging), it would be nice if your access router could generate an ICMP_ROUTABILITY_TEST message which would force the initiator to retry with a nonce/cookie. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > Hallam-Baker, Phillip > Sent: Wednesday, February 13, 2002 3:05 PM > To: 'Derek Atkins'; Charlie_Kaufman@notesdev.ibm.com > Cc: Khaja E. Ahmed; Dan Harkins; Paul Hoffman / VPNC; > ipsec@lists.tislabs.com > Subject: RE: RESEND: Thoughts on identity attacks > > > > Derek, > > I agree that the stateless cookie is very important. > However there > is no value in the stateless cookie unless you also have the > ability to > filter out DoS attacks from fixed IP addresses. This being > the case I would > rather unpack the stateless cookie and make it a part of a > DoS package. I > much prefer the following scheme: > > 1) All Initiators (aka clients) MUST be capable of repeating > a request with > a stateless cookie if required > 2) Responders MAY respond to a cookie-less request by > requesting a cookie. > > This allows the 2 round trip JFK scheme to be reduced > to 1 required > and 1 optional round trip. A responder that is not going to > do anything more > sophisticated can require cookies on every request. It is not > much more work > to only require cookies on an 'as necessary' basis. A > responder that has > code to deal with the DoS from fixed IP address problem would not be > impacted in a major way. > > Remember that if we do cookie protection well it > becomes unnecessary > because there is no point in an attacker trying that approach. So 1 > mandatory + 1 optional round trip becomes on average 1 round > trip. There is > a major performance difference between 1 round trip and 2 on > many of the > wireless applications. > > Certainly when it comes for Web services I will be pushing for a > generic DoS protection mechanism for Web services generally > (i.e. at the > SOAP layer) rather than a mechanism that is limited to one > specific protocol > such as XKMS or XKASS. > > > As for the rest of Charlie's list. I would very much > like to define > an IPSEC subset that is as streamlined as possible and does go to the > trouble of removing unnecessary junk. I do not believe that > the current set > of specifications built arround the capabilities of > engineering workstations > is viable when applied to low cost embedded devices. > > As to Charlie's point about 'the cost of argument'. It > is notable > that most of the advances in computer science come from > throwing junk out > rather than adding more. Java is only interesting because it > chucked out the > junk in C++. C was interesting because it chucked out the junk of CPL. > > It is very easy to develop an ADA in committee. > > Phill > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@mit.edu] > > Sent: Wednesday, February 13, 2002 2:04 PM > > To: Charlie_Kaufman@notesdev.ibm.com > > Cc: Khaja E. Ahmed; Dan Harkins; Paul Hoffman / VPNC; > > ipsec@lists.tislabs.com > > Subject: Re: RESEND: Thoughts on identity attacks > > > > > > Charlie_Kaufman@notesdev.ibm.com writes: > > > > > I believe many features in IKE are in the category of > > "seemed almost free" > > > at the time, and so are included without any demonstrated > > need. Identity > > > hiding is one. Stateless cookies is another. The ability to craft > > > incredibly > > > complex combinations of crypto algorithms and ESP/AH/IPCOMP > > combinations > > > is a third. Having a phase I and a phase II is a fourth. > > > > I think stateless cookies are extremely important to protect against > > resource starvation attacks (ala the TCP SYN attack). If I > can cause > > your IKE daemon to store a lot of state by sending it a single > > (forged) UDP packet, I can effectively starve your system. With > > stateless cookies you at least have reachability to gain a > better idea > > who is trying to attack you -- the attacker must be somewhere on the > > path between you and the IP address being used to attack you. > > > > -derek > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > > > From owner-ipsec@lists.tislabs.com Wed Feb 13 14:36:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DMas304900; Wed, 13 Feb 2002 14:36:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24387 Wed, 13 Feb 2002 17:06:22 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40A1DFB25@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: andrew.krywaniuk@alcatel.com, "'Hallam-Baker, Phillip'" Cc: ipsec@lists.tislabs.com Subject: RE: RESEND: Thoughts on identity attacks Date: Wed, 13 Feb 2002 14:18:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B4DC.552DE340" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_000_01C1B4DC.552DE340 Content-Type: text/plain; charset="iso-8859-1" > Phill, > > Have you read the JFK draft? Have you read my extensive comments on the JFK draft posted to the list? > The idea of a generalized cookie mechanism for IP/TCP is > something I've > toyed with. For applications where you don't necessarily want > to do IPsec, > but DoS attacks are very important (e.g. wireless, > specifically IP paging), > it would be nice if your access router could generate an > ICMP_ROUTABILITY_TEST message which would force the initiator > to retry with > a nonce/cookie. I don't think that has much value. For the cookie to be useful it really has to be strongly bound to a particular request and a specific IP port. Otherwise an attacker can get one legitimate cookie and then SPAM you to death with it. Phill ------_=_NextPart_000_01C1B4DC.552DE340 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1B4DC.552DE340-- From owner-ipsec@lists.tislabs.com Wed Feb 13 14:55:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DMtj305391; Wed, 13 Feb 2002 14:55:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24429 Wed, 13 Feb 2002 17:23:50 -0500 (EST) Message-Id: <200202132234.g1DMYeK15715@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: RESEND: Thoughts on identity attacks In-reply-to: Your message of "Wed, 13 Feb 2002 12:04:47 PST." <2F3EC696EAEED311BB2D009027C3F4F405869966@vhqpostal.verisign.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Feb 2002 17:34:39 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker> I agree that the stateless cookie is very Hallam-Baker> important. However there is no value in the stateless Hallam-Baker> cookie unless you also have the ability to filter out DoS Hallam-Baker> attacks from fixed IP addresses. This being the case I Hallam-Baker> would rather unpack the stateless cookie and make it a Hallam-Baker> part of a DoS package. I much prefer the following scheme: Hallam-Baker> 1) All Initiators (aka clients) MUST be capable of Hallam-Baker> repeating a request with a stateless cookie if required 2) Hallam-Baker> Responders MAY respond to a cookie-less request by Hallam-Baker> requesting a cookie. Hallam-Baker> This allows the 2 round trip JFK scheme to be reduced to 1 Hallam-Baker> required and 1 optional round trip. A responder that is Hallam-Baker> not going to do anything more sophisticated can require Hallam-Baker> cookies on every request. It is not much more work to only Ah, choices. I believe it is choices as to whether or not to do use a feature that causes complexity, not the feature itself. I'm for always using cookies. Hallam-Baker> trying that approach. So 1 mandatory + 1 optional round Hallam-Baker> trip becomes on average 1 round trip. There is a major Hallam-Baker> performance difference between 1 round trip and 2 on many Hallam-Baker> of the wireless applications. What are these wireless applications? How do they differ from VPN, OE, or per-socket uses? I'm asking because I don't see 1 round trip vs 2 much a big deal once you factor in DNS lookups (including reverse DNS lookups on the responder for logging purposes). The only impact that I can see is wireless applications that initiate from new IP addresses all the time as they roam. MobileIP would not do such a thing as it would expect an SA from the home address to the peers. Hallam-Baker> unnecessary junk. I do not believe that the current set of Hallam-Baker> specifications built arround the capabilities of Hallam-Baker> engineering workstations is viable when applied to low Hallam-Baker> cost embedded devices. I'm willing to be convinced that such a profile should exist, but I'm not sure that it matters to devices that are stationary - they should not be rekeying often enough to matter. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Feb 13 18:23:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E2NT310815; Wed, 13 Feb 2002 18:23:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24871 Wed, 13 Feb 2002 20:32:39 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hallam-Baker, Phillip'" Cc: Subject: RE: RESEND: Thoughts on identity attacks Date: Wed, 13 Feb 2002 20:37:42 -0500 Message-ID: <003401c1b4f8$32f28c10$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40A1DFB25@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Have you read the JFK draft? > > Have you read my extensive comments on the JFK draft posted > to the list? Obviously my question was tongue in cheek. In your last message you suggest that cookies be made optional. You state "This allows the 2 round trip JFK scheme to be reduced to 1 required and 1 optional round trip." Then you go on to describe a protocol which bears absolutely no resemblance to JFK at all. JFK is a protocol which has 8 stated goals: security, simplicity, memory-DoS, Computation-DoS, Privacy, Efficiency, Non-Negotiated, and PFS. You didn't give all the details of your 'JFKbis' protocol, but it is almost certain to forego at least 5 of these: security, memory-DoS, Computation-DoS, Privacy, and PFS. Plus it is bound to add new weaknesses, such as replay attacks (although I suppose those could be lumped in under memory-DoS). The JFK approach was to take 90% of the crypto features that IKEv2 implements in average case 4 messages (worst case 6) and do them in constant time 4 messages. What you have done is take the same idea from IKEv2 (optional cookies), graft it onto XKASS, and then somehow pretend that this is related to JFK. I hate to resort to tired cliches, but if for some reason all you require is fast negotiation, irregardless of the security drawbacks, then perhaps that should be done by a separate protocol. > > The idea of a generalized cookie mechanism for IP/TCP is > > something I've > > toyed with. For applications where you don't necessarily want > > to do IPsec, > > but DoS attacks are very important (e.g. wireless, > > specifically IP paging), > > it would be nice if your access router could generate an > > ICMP_ROUTABILITY_TEST message which would force the initiator > > to retry with > > a nonce/cookie. > > I don't think that has much value. For the cookie to be useful it > really has to be strongly bound to a particular request and a specific > IP port. Otherwise an attacker can get one legitimate cookie and then > SPAM you to death with it. And why couldn't it be? The only stumbling block is that the legitimate owner of the IP/port has to be able to determine whether he recently sent you a packet. This is easy with TCP & not so easy with IP. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Feb 14 08:15:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EGFv309241; Thu, 14 Feb 2002 08:15:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26569 Thu, 14 Feb 2002 10:13:18 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40A1DFC05@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: andrew.krywaniuk@alcatel.com, "'Hallam-Baker, Phillip'" Cc: ipsec@lists.tislabs.com Subject: RE: RESEND: Thoughts on identity attacks Date: Thu, 14 Feb 2002 07:25:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B56B.CAF422D0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_000_01C1B56B.CAF422D0 Content-Type: text/plain; charset="iso-8859-1" > In your last message you suggest that cookies be made > optional. You state > "This allows the 2 round trip JFK scheme to be reduced to 1 > required and 1 > optional round trip." Then you go on to describe a protocol > which bears > absolutely no resemblance to JFK at all. If you think that I don't think you understand JFK. > The JFK approach was to take 90% of the crypto features that IKEv2 > implements in average case 4 messages (worst case 6) and do > them in constant > time 4 messages. What you have done is take the same idea from IKEv2 > (optional cookies), graft it onto XKASS, and then somehow > pretend that this > is related to JFK. Look at the crypto. And when it comes to a security model, XKASS describes its security model with far more rigor than JFK. So please don't get into the histrionics. > I hate to resort to tired cliches, but if for some reason all > you require is > fast negotiation, irregardless of the security drawbacks, > then perhaps that > should be done by a separate protocol. Straw man, I have presented a formalized analysis of the security model, JFK does not. All I see in JFK is a catalogue of previously discovered problems. That is not a security model in my view. Phill ------_=_NextPart_000_01C1B56B.CAF422D0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1B56B.CAF422D0-- From owner-ipsec@lists.tislabs.com Thu Feb 14 09:14:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EHEd310661; Thu, 14 Feb 2002 09:14:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26790 Thu, 14 Feb 2002 11:32:44 -0500 (EST) Message-ID: <20020214164353.75508.qmail@web21007.mail.yahoo.com> Date: Thu, 14 Feb 2002 08:43:53 -0800 (PST) From: Yang Xiao Reply-To: YangXiao@ieee.org Subject: CFP-Deadline correction To: YangXiao@ieee.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My apologies if you receive this CFP duplicated. ------------------- Call for Papers- Deadline correction Invited Session Title: Modeling, Analysis, and Simulation of Wireless LANs and Mobile Ad Hoc Networks and QoS Issues Invited Session in the 6th World Multi-Conference on Systemics, Cybernetics and Informatics, (SCI 2002) Orlando, Florida, USA, July 14 -18, 2002 Topics of Interest Wireless LANs & Mobile Ad Hoc Networks (not limited to) Simulation, Modeling and performance evaluation of Wireless LANs, such as IEEE 802.11, HIPERLAN, and Ad hoc Networks. Quality-of-service issues in Wireless LANs (IEEE 802.11e, HIPERLAN/2, etc.) and Ad Hoc Networks. Power Consumption issues Higher data rates 3G/4G-WLAN Differentiated Services for Wireless LANs Co-existence of the IEEE 802.11 and 802.15 Resource Management Analytical methods. Deadlines Submission of Extended Abstracts: February 17, 2002 Notification of Acceptance: March 10, 2002 Camera Ready Copies: April 03, 2002 Session Co-Organizers/co-chairs Dr. Yang Xiao, Micro Linear, USA Dr. Bin Wang, Wright State University, USA Instructions For Submission Submission should be in the form of extended abstracts up to 4 pages long. All submitted contributions will be subject to peer review on the basis of technical correctness, quality, relevance, originality, significance, and clarity. Abstracts should be in MS Word, PDF or PS format. Submissions should be sent to the session's co-organizers. Successful submissions will be asked to submit a full paper. Full papers must be formatted according to IEEE-CS guidelines Electronic Submission: Dr. Yang Xiao: YangXiao@IEEE.ORG Dr. Bin Wang: bwang@cs.wright.edu For more details check at http://www.iiis.org/sci2002/ last updated 02/11/02 __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-ipsec@lists.tislabs.com Thu Feb 14 11:56:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EJux319034; Thu, 14 Feb 2002 11:56:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27161 Thu, 14 Feb 2002 14:05:24 -0500 (EST) From: "Khaja E. Ahmed" To: "Dan Harkins" , "David Jablon" Cc: Subject: RE: RESEND: Thoughts on identity attacks Date: Thu, 14 Feb 2002 11:15:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200202130009.g1D09Bh00648@fatty.lounge.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, You have asked (in this and in another message) what I think people are using and how, what they might really want and what I recommend. Before I answer those questions I should explain what I believe the threats to be that we should worry about. That way there is a frame of reference to these opinions. I do not believe that we should devote much energy to developing military grade security. Our work should be to invent technologies for civilian organizations and individuals. Attackers with the motivation, funding and capabilities of the KGB, Mossad, NSA or other governments, etc are not what we should worry about. (If those dudes are after your information you have serious problems and nothing from any standards body is going to help you anyway.) I do recognize however that the level of security needed by SWIFT for inter-bank funds transfers (for example) will be different from that needed by a small company trying to allow it's employees to telecommute over VPN. That will require that our standards accommodate something of a range of solutions. The worst we need to worry about is, at the high end of the threat, a serious and capable cryptographer going over to the dark side and working with some COTS equipment. I would not assume that the attacker has access to hundreds of computers for example. This is just my opinion - like the rest of the message - and others may feel completely differently about this. My 'opinion of what these people are using': Product developers / companies have done as best a job as they can with implementations of IKE, sometimes leveraging open source stuff (e.g. Pluto) and sometimes licensing code from OEMs (e.g. SSH) and rarely developing the thing entirely in-house. I suspect that most of their code is not used and they know it and worry about it. All that unused and redundant functionality constitutes moving parts in their products, bugs waiting to surface, a QA nightmare, a documentation burden, and clutter which impacts the reliability, supportability and maintainability of the product. If there was a small core of standardized, mandatory, minimum functionality that could be implemented it would make the products more maintainable and reliable. Also as Phil Hallam-Baker has pointed out, such solutions will more easily fit on devices with severe CPU and memory constraints. This would be all that would be needed for 95% of their customers and the rest could be served with optional modules / upgrades / add-ons. Most of their customers, the end users, appear quite content to use shared secrets. The knowledge that someone casually sniffing packets will not see their data and can not easily decrypt it, appears sufficient for most. The fact that an attacker would actually have to have a pretty serious level of competence, resources and motivation to hack at their data is all the comfort and assurance they need. At the high end of security consciousness, most large Financial Institutions, Healthcare/big pharma, and some Fortune 500 companies are trying to be more serious about security. These guys care about key sizes to the extent that they want 3DES and not DES. Even in this crew Aggressive mode is viewed as quite adequate. No main mode needed. Some are venturing into certificate based authentication. The few who did, have generally ignored certificate status checking. No OCSP, no CRLs and a somewhat relaxed attitude towards certificate life cycle management and PKIX compliance. I have no doubt that there are large installed bases doing everything by the book but they are about as rare as the dodo bird. The ones I worry about are using NAT and thinking they have a firewall. And when I contemplate how many SMEs have NOTHING and are quite happy to have employees pop their corporate mail from home with no VPN or SSL the mind boggles. It would seem more urgent to focus on getting this crew to use ANY security before sweating the ratios of key sizes to amount of data encrypted if and when they do use some security. For many small companies in this category even a group shared-key would be an improvement. What they need is some minimal, non-invasive, low maintenance solution. This is NOT to say that I think the rest of the world should be dragged down to the modest security aspirations of this segment but certainly this is a need that is currently left unserved. Frankly, we deny this segment a useful and adequate solution by steadfastly refusing to come up with something they can digest. In fact, it appears that what we deliver is hard to use even for Financial Institutions and large corporations with huge IT staffs. In other words, while we ignore this lot, we give more attention than is valued/utilized to the somewhat more security conscious users. My 'opinion of what these people want': Product developers and companies want simpler standards, with fewer choices. The rest can be options. Current options are really not options. The choices are really not choices because they are not adequately separated in the standard. It would be a boon to engineering teams around the world to have a standard that clearly articulates a mandatory minimum which is truly minimal and not knitted along and mixed with the options. Such a standard itself would be modular. That allows for the development of high end, low end, and mobile/PDA solutions with clear demarcations of functionality. The trouble with the 'go write yourself a profile or a BCP' argument is that it almost never gets done. First, it is not trivial to do that with IKE and many other standards. And then to have to once again go through the gut wrenching consensus building process that the standard already has been through to get the 'profile' accepted by a community is too painful, wasteful, intimidating and generally will not get done. This might be a crazy idea, but while we are talking about opinions, why not modularize the standard itself? If the SuccessorToIKE were to specify clearly a minimum required as the core and document everything else as optional modules, it would dramatically increase adoption, acceptance and *use* of the technology. A more modular standard would also be facilitate profiling. It might even make the process of developing the standard itself easier and less contentious if additional capabilities when added were discrete modules. Reference implementations would be easy to develop and adopt, basic interoperability testing would be easy. Manufacturers, application-classes and interest groups could select identifiable sub-sets of the standard for their use. Current IKE, IMHO, does not lend itself to easy separation of a core minimum that is easily implementable. Even gnarly stuff like SSL and PKIX is by comparison easier to profile. For what it is worth, the Identrus PKIX profile took less than a day to document. (let's not discuss the consensus building part). It was even straightforward to hack SSL down to something smaller and leaner, (although less flexible) for use between really weak CPU and low memory, low baud rate IrDA port equipped devices. My opinion is, that to do the same with IKE is a good deal harder. This might be heresy, but it might be worth considering an approach completely outside of current ISAKMP, Oakley and IKE shadows and influence. IMHO these standards deliver a level of sophistication and a wealth of capabilities that might, at most, be needed by the top 5% of the potential user population. The unwashed masses cant handle it and are therefore doing nothing. In fact SSL is emerging as a solution where ideally IPsec should be used simply because SSL (without client auth) is brain dead simple and easy to implement. Most users want far less security than we wish to have them use. Not because they like being insecure but because we have not yet found ways of delivering the security without a penalty in usage complexity, product reliability/robustness and/or cost that exceeds (in the judgment of the user) it's value. For what it is worth I am myself a late convert to the 'adequate and no more' security religion. This came after nearly a decade and a half of working on and trying to promote security solutions that we thought were right for the market but the market thought otherwise. A token based authentication product died on us in the market 1990. Our elegant, GUI driven CC:Mail and MS Mail digital signature / PKI enabler add-on was given the cold shoulder by users in 1992. With nearly monotonous regularity since 1992, every year I have seen at least one PKI and SmartCard initiative rise, take a few steps forward in some sort of pilot and crash. It doesn't matter, it turns out, how secure you want users to be. It doesn't matter how secure the standard or standards compliant products are. They are all non-starters if they don't meet user requirements. Perhaps incremental security is the answer. The scores of unveilings of the golden solution have mostly all been let downs with few exceptions - like SSL. ESP combined with some simple key/SA management protocol can be a huge success. Not a large collection of protocols to setup an SA (ISAKMP) to setup an SA (IKE) to setup an SA (IPsec)! No I am NOT knocking the brilliant work done by so many people. I am just saying that it serves the legitimate needs of too few and we need something for the rest. Finally, Charlie Kaufman has beautifully captured and explained how standards get bloated in congressional fashion. It is good food for thought. If we don't find a way of solving that problem, there isn't much hope of being able to produce lean, efficient and easy to adopt standards. He explains how and why 'a camel is a horse designed by committee.' Perhaps we can consider things like adopting a process which mandates that there will always be a cleanly separated 'minimum and mandatory to implement' part in any standard. Nothing gets added to it unless a compelling case is made for it. Everything else is separated into optional modules etc. Khaja > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Tuesday, February 12, 2002 4:09 PM > To: David Jablon > Cc: ipsec@lists.tislabs.com > Subject: Re: RESEND: Thoughts on identity attacks > > > Well not entirely rhetorical. What I was asking for was his opinion of > what these people want and are using. The mandatory-to-implement > authentication method for IKE does not distinguish between a "shared > [secret] password" and a "shared [secret] key". As long as it's shared > and symmetric the "entropy" doesn't matter. But given how broken the > mandatory-to-implement authentication method is I'm surprised that this > is what is being used in the large deployments he was talking about. > Or maybe he's talking about legacy authentication using RADIUS or the > like. I don't know. I'd like to know though. > > Dan. > > On Tue, 12 Feb 2002 22:27:00 EST you wrote > > At 01:41 PM 2/12/02 -0800, Dan Harkins wrote: > > >On Tue, 12 Feb 2002 12:34:17 PST Khaja wrote > > >> I meant shared secrets not shared password. > > > > > > If that's what you meant then you shouldn't have written > "shared password" > >. > > >But please explain the difference anyway. [...] > > > > I'm pretty sure that Dan was asking a rhetorical question here. > > But it is a point of common confusion. > > > > To help, I propose the following definitions, based on observed > common usage: > > > > shared [secret] password: > > a low-entropy secret authenticator. > > > > shared [secret] key: > > a high-entropy cryptographic secret. > > > > shared secret: > > a key that was probably derived from a > password, but used in > > a cryptographic system in which there is > misplaced hope that > > the secret truly does have high entropy. > > > > I think this, plus the ambiguity argument, makes a good case for > > "shared secret" to be deprecated. > > > > -- David > > > > From owner-ipsec@lists.tislabs.com Thu Feb 14 12:22:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EKMp321040; Thu, 14 Feb 2002 12:22:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27330 Thu, 14 Feb 2002 14:49:32 -0500 (EST) Date: Thu, 14 Feb 2002 15:00:00 -0500 (EST) From: Henry Spencer To: IP Security List Subject: nature of standards (was RE: RESEND: Thoughts on identity attacks) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Feb 2002, Khaja E. Ahmed wrote: > He explains how and why 'a camel is a horse designed by committee.' Perhaps > we can consider things like adopting a process which mandates that there > will always be a cleanly separated 'minimum and mandatory to implement' part > in any standard. Nothing gets added to it unless a compelling case is made > for it. Everything else is separated into optional modules etc. As an implementor, I'd like to see the process go one step farther, with most of those "optional modules" simply discarded as not meriting standardization. I was somewhat involved with the original standardization of C. One of the most important decisions that committee made was that they did not wish to see 2^5 or 2^10 different "standard C" languages... and every time you add an "optional module" to the spec, you add another factor of 2. They did eventually end up having, essentially, *one* optional module -- containing all the standard libraries and certain promises about the execution environment, not necessarily supportable in small embedded environments -- but that was all. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Feb 14 13:27:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ELRv325549; Thu, 14 Feb 2002 13:27:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27560 Thu, 14 Feb 2002 15:37:41 -0500 (EST) From: "Greg Bailey" To: Cc: "ark-gvb-x" Subject: Procedures Date: Thu, 14 Feb 2002 12:47:38 -0800 Message-ID: MIME-Version: 1.0 charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I’m in the midst of an original implementation of IPSec / ISAKMP / IKE for our IPv4 stack and after reading the relevant RFC’s in parallel find some unanswered questions which are going to be difficult to impossible to investigate empirically, such as precise handling of weak key tests in the key material extraction for each of the three subkeys of 3DES. Is there a compilation of clarifications on such questions anywhere available? Secondary question is whether it is appropriate to post questions to this list and if not to whom should they be addressed? Direct replies would be appreciated, no need to swamp this group with them. Thanks in advance. Greg Bailey | ATHENA Programming, Inc | 503-295-7703 | ---------------- | 310 SW 4th Ave Ste 530 | fax 295-6935 | greg@minerva.com | Portland, OR 97204 US | From owner-ipsec@lists.tislabs.com Thu Feb 14 13:35:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ELZC326051; Thu, 14 Feb 2002 13:35:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27627 Thu, 14 Feb 2002 15:58:18 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3C4C@NS-CA> From: Michael Choung Shieh To: "'Henry Spencer'" , IP Security List Subject: RE: nature of standards (was RE: RESEND: Thoughts on identity att acks) Date: Thu, 14 Feb 2002 13:06:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It would be hard to remove all optional modules since the protocols are developed to be used under different business cases. As long as the options are popular, they will come out as a non-standarded standard. I see SCEP and Xauth as the examples. Even "C" is the same. All latest C compilers support "//" as comment but it's not defined in the original C. -------------------------------------------- Michael Shieh -------------------------------------------- -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Thursday, February 14, 2002 12:00 PM To: IP Security List Subject: nature of standards (was RE: RESEND: Thoughts on identity attacks) On Thu, 14 Feb 2002, Khaja E. Ahmed wrote: > He explains how and why 'a camel is a horse designed by committee.' Perhaps > we can consider things like adopting a process which mandates that there > will always be a cleanly separated 'minimum and mandatory to implement' part > in any standard. Nothing gets added to it unless a compelling case is made > for it. Everything else is separated into optional modules etc. As an implementor, I'd like to see the process go one step farther, with most of those "optional modules" simply discarded as not meriting standardization. I was somewhat involved with the original standardization of C. One of the most important decisions that committee made was that they did not wish to see 2^5 or 2^10 different "standard C" languages... and every time you add an "optional module" to the spec, you add another factor of 2. They did eventually end up having, essentially, *one* optional module -- containing all the standard libraries and certain promises about the execution environment, not necessarily supportable in small embedded environments -- but that was all. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Feb 14 21:46:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1F5kk310132; Thu, 14 Feb 2002 21:46:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28284 Thu, 14 Feb 2002 23:55:48 -0500 (EST) Date: Fri, 15 Feb 2002 00:06:17 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: nature of standards (was RE: RESEND: Thoughts on identity att acks) In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3C4C@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Feb 2002, Michael Choung Shieh wrote: > It would be hard to remove all optional modules since the protocols are > developed to be used under different business cases... Oddly enough, TCP/IP is used under all those "different business cases", seldom needing optional modules. It's stupid to design a "core protocol" which is so stripped down that almost nobody can use it by itself. One does have to draw the line somewhere, but we should try to include most users inside the line. > Even "C" is the same. All latest C compilers support "//" as comment but > it's not defined in the original C. It's in the revised C standard, which came out a year or two ago. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Feb 15 09:32:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FHWi308636; Fri, 15 Feb 2002 09:32:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00323 Fri, 15 Feb 2002 11:31:15 -0500 (EST) X-Envelope-Sender-Is: ewilkinson@efficient.com (at relayer ns0.sbs.siemens.com) Message-ID: <36C2EB69D2F9D411A9AB00D0B7200334F81527@eniwest.inside.efficient.com> From: Edward Wilkinson To: "'Khaja E. Ahmed'" , Dan Harkins , David Jablon Cc: ipsec@lists.tislabs.com Subject: RE: RESEND: Thoughts on identity attacks Date: Fri, 15 Feb 2002 08:36:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Khaja, I must applauded you. As a person that implements and supports this mass of security protocols I to believe that it is way to complicated for most people, and causes far to many interop problems. Ed -----Original Message----- From: Khaja E. Ahmed [mailto:khaja.ahmed@attbi.com] Sent: Thursday, February 14, 2002 11:15 AM To: Dan Harkins; David Jablon Cc: ipsec@lists.tislabs.com Subject: RE: RESEND: Thoughts on identity attacks Dan, You have asked (in this and in another message) what I think people are using and how, what they might really want and what I recommend. Before I answer those questions I should explain what I believe the threats to be that we should worry about. That way there is a frame of reference to these opinions. I do not believe that we should devote much energy to developing military grade security. Our work should be to invent technologies for civilian organizations and individuals. Attackers with the motivation, funding and capabilities of the KGB, Mossad, NSA or other governments, etc are not what we should worry about. (If those dudes are after your information you have serious problems and nothing from any standards body is going to help you anyway.) I do recognize however that the level of security needed by SWIFT for inter-bank funds transfers (for example) will be different from that needed by a small company trying to allow it's employees to telecommute over VPN. That will require that our standards accommodate something of a range of solutions. The worst we need to worry about is, at the high end of the threat, a serious and capable cryptographer going over to the dark side and working with some COTS equipment. I would not assume that the attacker has access to hundreds of computers for example. This is just my opinion - like the rest of the message - and others may feel completely differently about this. My 'opinion of what these people are using': Product developers / companies have done as best a job as they can with implementations of IKE, sometimes leveraging open source stuff (e.g. Pluto) and sometimes licensing code from OEMs (e.g. SSH) and rarely developing the thing entirely in-house. I suspect that most of their code is not used and they know it and worry about it. All that unused and redundant functionality constitutes moving parts in their products, bugs waiting to surface, a QA nightmare, a documentation burden, and clutter which impacts the reliability, supportability and maintainability of the product. If there was a small core of standardized, mandatory, minimum functionality that could be implemented it would make the products more maintainable and reliable. Also as Phil Hallam-Baker has pointed out, such solutions will more easily fit on devices with severe CPU and memory constraints. This would be all that would be needed for 95% of their customers and the rest could be served with optional modules / upgrades / add-ons. Most of their customers, the end users, appear quite content to use shared secrets. The knowledge that someone casually sniffing packets will not see their data and can not easily decrypt it, appears sufficient for most. The fact that an attacker would actually have to have a pretty serious level of competence, resources and motivation to hack at their data is all the comfort and assurance they need. At the high end of security consciousness, most large Financial Institutions, Healthcare/big pharma, and some Fortune 500 companies are trying to be more serious about security. These guys care about key sizes to the extent that they want 3DES and not DES. Even in this crew Aggressive mode is viewed as quite adequate. No main mode needed. Some are venturing into certificate based authentication. The few who did, have generally ignored certificate status checking. No OCSP, no CRLs and a somewhat relaxed attitude towards certificate life cycle management and PKIX compliance. I have no doubt that there are large installed bases doing everything by the book but they are about as rare as the dodo bird. The ones I worry about are using NAT and thinking they have a firewall. And when I contemplate how many SMEs have NOTHING and are quite happy to have employees pop their corporate mail from home with no VPN or SSL the mind boggles. It would seem more urgent to focus on getting this crew to use ANY security before sweating the ratios of key sizes to amount of data encrypted if and when they do use some security. For many small companies in this category even a group shared-key would be an improvement. What they need is some minimal, non-invasive, low maintenance solution. This is NOT to say that I think the rest of the world should be dragged down to the modest security aspirations of this segment but certainly this is a need that is currently left unserved. Frankly, we deny this segment a useful and adequate solution by steadfastly refusing to come up with something they can digest. In fact, it appears that what we deliver is hard to use even for Financial Institutions and large corporations with huge IT staffs. In other words, while we ignore this lot, we give more attention than is valued/utilized to the somewhat more security conscious users. My 'opinion of what these people want': Product developers and companies want simpler standards, with fewer choices. The rest can be options. Current options are really not options. The choices are really not choices because they are not adequately separated in the standard. It would be a boon to engineering teams around the world to have a standard that clearly articulates a mandatory minimum which is truly minimal and not knitted along and mixed with the options. Such a standard itself would be modular. That allows for the development of high end, low end, and mobile/PDA solutions with clear demarcations of functionality. The trouble with the 'go write yourself a profile or a BCP' argument is that it almost never gets done. First, it is not trivial to do that with IKE and many other standards. And then to have to once again go through the gut wrenching consensus building process that the standard already has been through to get the 'profile' accepted by a community is too painful, wasteful, intimidating and generally will not get done. This might be a crazy idea, but while we are talking about opinions, why not modularize the standard itself? If the SuccessorToIKE were to specify clearly a minimum required as the core and document everything else as optional modules, it would dramatically increase adoption, acceptance and *use* of the technology. A more modular standard would also be facilitate profiling. It might even make the process of developing the standard itself easier and less contentious if additional capabilities when added were discrete modules. Reference implementations would be easy to develop and adopt, basic interoperability testing would be easy. Manufacturers, application-classes and interest groups could select identifiable sub-sets of the standard for their use. Current IKE, IMHO, does not lend itself to easy separation of a core minimum that is easily implementable. Even gnarly stuff like SSL and PKIX is by comparison easier to profile. For what it is worth, the Identrus PKIX profile took less than a day to document. (let's not discuss the consensus building part). It was even straightforward to hack SSL down to something smaller and leaner, (although less flexible) for use between really weak CPU and low memory, low baud rate IrDA port equipped devices. My opinion is, that to do the same with IKE is a good deal harder. This might be heresy, but it might be worth considering an approach completely outside of current ISAKMP, Oakley and IKE shadows and influence. IMHO these standards deliver a level of sophistication and a wealth of capabilities that might, at most, be needed by the top 5% of the potential user population. The unwashed masses cant handle it and are therefore doing nothing. In fact SSL is emerging as a solution where ideally IPsec should be used simply because SSL (without client auth) is brain dead simple and easy to implement. Most users want far less security than we wish to have them use. Not because they like being insecure but because we have not yet found ways of delivering the security without a penalty in usage complexity, product reliability/robustness and/or cost that exceeds (in the judgment of the user) it's value. For what it is worth I am myself a late convert to the 'adequate and no more' security religion. This came after nearly a decade and a half of working on and trying to promote security solutions that we thought were right for the market but the market thought otherwise. A token based authentication product died on us in the market 1990. Our elegant, GUI driven CC:Mail and MS Mail digital signature / PKI enabler add-on was given the cold shoulder by users in 1992. With nearly monotonous regularity since 1992, every year I have seen at least one PKI and SmartCard initiative rise, take a few steps forward in some sort of pilot and crash. It doesn't matter, it turns out, how secure you want users to be. It doesn't matter how secure the standard or standards compliant products are. They are all non-starters if they don't meet user requirements. Perhaps incremental security is the answer. The scores of unveilings of the golden solution have mostly all been let downs with few exceptions - like SSL. ESP combined with some simple key/SA management protocol can be a huge success. Not a large collection of protocols to setup an SA (ISAKMP) to setup an SA (IKE) to setup an SA (IPsec)! No I am NOT knocking the brilliant work done by so many people. I am just saying that it serves the legitimate needs of too few and we need something for the rest. Finally, Charlie Kaufman has beautifully captured and explained how standards get bloated in congressional fashion. It is good food for thought. If we don't find a way of solving that problem, there isn't much hope of being able to produce lean, efficient and easy to adopt standards. He explains how and why 'a camel is a horse designed by committee.' Perhaps we can consider things like adopting a process which mandates that there will always be a cleanly separated 'minimum and mandatory to implement' part in any standard. Nothing gets added to it unless a compelling case is made for it. Everything else is separated into optional modules etc. Khaja > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Tuesday, February 12, 2002 4:09 PM > To: David Jablon > Cc: ipsec@lists.tislabs.com > Subject: Re: RESEND: Thoughts on identity attacks > > > Well not entirely rhetorical. What I was asking for was his opinion of > what these people want and are using. The mandatory-to-implement > authentication method for IKE does not distinguish between a "shared > [secret] password" and a "shared [secret] key". As long as it's shared > and symmetric the "entropy" doesn't matter. But given how broken the > mandatory-to-implement authentication method is I'm surprised that this > is what is being used in the large deployments he was talking about. > Or maybe he's talking about legacy authentication using RADIUS or the > like. I don't know. I'd like to know though. > > Dan. > > On Tue, 12 Feb 2002 22:27:00 EST you wrote > > At 01:41 PM 2/12/02 -0800, Dan Harkins wrote: > > >On Tue, 12 Feb 2002 12:34:17 PST Khaja wrote > > >> I meant shared secrets not shared password. > > > > > > If that's what you meant then you shouldn't have written > "shared password" > >. > > >But please explain the difference anyway. [...] > > > > I'm pretty sure that Dan was asking a rhetorical question here. > > But it is a point of common confusion. > > > > To help, I propose the following definitions, based on observed > common usage: > > > > shared [secret] password: > > a low-entropy secret authenticator. > > > > shared [secret] key: > > a high-entropy cryptographic secret. > > > > shared secret: > > a key that was probably derived from a > password, but used in > > a cryptographic system in which there is > misplaced hope that > > the secret truly does have high entropy. > > > > I think this, plus the ambiguity argument, makes a good case for > > "shared secret" to be deprecated. > > > > -- David > > > > From owner-ipsec@lists.tislabs.com Fri Feb 15 11:09:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FJ9F311346; Fri, 15 Feb 2002 11:09:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00672 Fri, 15 Feb 2002 13:27:21 -0500 (EST) Message-ID: <009201c1b64f$dd3a1f50$33c02ca1@cisco.com> From: "Scott Fanning" To: Subject: WG Meeting Date: Fri, 15 Feb 2002 10:37:46 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C1B60C.CEA5CE00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C1B60C.CEA5CE00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there a WG meeting in Minneapolis? There appears to be none listed on = the agenda. Scott ------=_NextPart_000_008F_01C1B60C.CEA5CE00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there a WG meeting in Minneapolis? There appears to be none = listed on=20 the agenda.
 
Scott
------=_NextPart_000_008F_01C1B60C.CEA5CE00-- From owner-ipsec@lists.tislabs.com Fri Feb 15 13:30:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FLUe314984; Fri, 15 Feb 2002 13:30:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00987 Fri, 15 Feb 2002 15:43:09 -0500 (EST) Message-ID: <20020215203616.8395.qmail@web13402.mail.yahoo.com> Date: Fri, 15 Feb 2002 12:36:16 -0800 (PST) From: Bob Fontain Subject: RE: RESEND: Thoughts on identity attacks To: ewilkinson@efficient.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Applaud? Huh? He sends a 100% buzzword compliant but completely content free 150 line post (which I snipped-- you're welcome) that didn't even have one bit of specificity. It's like autodesigners debating whether a new car should have fold down back seats to extend the trunk space and someone interrupts to explain the life of a soccer mom and that what people really want in a new car is safety and affordability. Oh, what an epiphany! The problem isn't people intentionally designing unintuitive and complex protocols (or intentionally designing unsafe and unaffordable cars) so to extoll the virtues of simplicity (or affordable and safe cars) is a waste. It also derails the discussion before a range of opinions have been expressed. Back to the subject, OK? I think protection against a passive attack is basically free in all these protocols. And protecting against an active attack only protects one side. If Alice's identity is hidden when talking to Bob then all Trudy has to do is initiate a connection to Alice. "Ding dong" usually gets a response of "who's there?" not "You've reached Alice." My vote is for protection against passive attacks. No options to optionally expose Alice or Bob. my 2 cents. -- Bob Fontain -----Original Message----- From: Edward Wilkinson To: "'Khaja E. Ahmed'" , Dan Harkins , David Jablon Cc: ipsec@lists.tislabs.com Subject: RE: RESEND: Thoughts on identity attacks Khaja, I must applauded you. As a person that implements and supports this mass of security protocols I to believe that it is way to complicated for most people, and causes far to many interop problems. Ed __________________________________________________ Do You Yahoo!? Got something to say? Say it better with Yahoo! Video Mail http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Fri Feb 15 15:11:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FNBQ317028; Fri, 15 Feb 2002 15:11:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01144 Fri, 15 Feb 2002 17:31:52 -0500 (EST) Date: Fri, 15 Feb 2002 17:42:53 -0500 From: Theodore Tso To: Scott Fanning Cc: ipsec@lists.tislabs.com Subject: Re: WG Meeting Message-ID: <20020215174253.L4003@thunk.org> References: <009201c1b64f$dd3a1f50$33c02ca1@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <009201c1b64f$dd3a1f50$33c02ca1@cisco.com>; from sfanning@cisco.com on Fri, Feb 15, 2002 at 10:37:46AM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Feb 15, 2002 at 10:37:46AM -0800, Scott Fanning wrote: > Is there a WG meeting in Minneapolis? There appears to be none listed on the agenda. > Yes, there will be. We did request WG slots, but I think we've been held in AD-wait. We'll ping them again.... - Ted From owner-ipsec@lists.tislabs.com Fri Feb 15 15:29:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FNTj317409; Fri, 15 Feb 2002 15:29:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01217 Fri, 15 Feb 2002 17:58:03 -0500 (EST) Message-ID: <3C6D871D.7070005@alum.mit.edu> Date: Fri, 15 Feb 2002 15:09:33 -0700 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: RE: RESEND: Thoughts on identity attacks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you send a horse to do a camel's job, you will end up with a dead horse which can then be beaten indefinitely. Hilarie From owner-ipsec@lists.tislabs.com Fri Feb 15 17:38:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1G1cO320693; Fri, 15 Feb 2002 17:38:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01414 Fri, 15 Feb 2002 19:53:40 -0500 (EST) From: "Khaja E. Ahmed" To: "The Purple Streak \(Hilarie Orman\)" , Subject: RE: RESEND: Thoughts on identity attacks Date: Fri, 15 Feb 2002 17:03:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3C6D871D.7070005@alum.mit.edu> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And if you put a camel in a horse race it is a non-starter. Won't even fit in the starting gate. Khaja > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of The Purple Streak > (Hilarie Orman) > Sent: Friday, February 15, 2002 2:10 PM > To: ipsec@lists.tislabs.com > Subject: RE: RESEND: Thoughts on identity attacks > > > If you send a horse to do a camel's job, you will end up with a dead > horse which can then be beaten indefinitely. > > Hilarie > > From owner-ipsec@lists.tislabs.com Sat Feb 16 13:11:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1GLBw301567; Sat, 16 Feb 2002 13:11:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02970 Sat, 16 Feb 2002 15:03:51 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Khaja E. Ahmed'" , "'The Purple Streak \(Hilarie Orman\)'" , Subject: And on the subject of JFK... Date: Sat, 16 Feb 2002 15:08:47 -0500 Message-ID: <000a01c1b725$be6dbba0$6369e640@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Beware of Greeks bearing gifts. This is fun! Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Khaja E. Ahmed > Sent: Friday, February 15, 2002 8:04 PM > To: The Purple Streak (Hilarie Orman); ipsec@lists.tislabs.com > Subject: RE: RESEND: Thoughts on identity attacks > > > And if you put a camel in a horse race it is a non-starter. > Won't even fit > in the starting gate. > > Khaja > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of The Purple Streak > > (Hilarie Orman) > > Sent: Friday, February 15, 2002 2:10 PM > > To: ipsec@lists.tislabs.com > > Subject: RE: RESEND: Thoughts on identity attacks > > > > > > If you send a horse to do a camel's job, you will end up with a dead > > horse which can then be beaten indefinitely. > > > > Hilarie > > > > > > From owner-ipsec@lists.tislabs.com Mon Feb 18 08:27:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1IGRU327439; Mon, 18 Feb 2002 08:27:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05868 Mon, 18 Feb 2002 10:20:13 -0500 (EST) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC034A21F6@highway> From: 867 <867@nu.edu.pk> To: "'ipsec@lists.tislabs.com'" Subject: why the SAs are unidirectional Date: Mon, 18 Feb 2002 20:31:16 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, I have a query regarding SAs (Security Associations ), why SAs are defined in one direction. Separate for inbound and outbond traffic. Why are they not defined in both ways. thanks. regards, From owner-ipsec@lists.tislabs.com Mon Feb 18 10:02:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1II23329776; Mon, 18 Feb 2002 10:02:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06086 Mon, 18 Feb 2002 12:19:06 -0500 (EST) Message-Id: <200202181729.g1IHTmsY012966@ack.east.sun.com> From: Bill Sommerfeld To: 867 <867@nu.edu.pk> cc: "'ipsec@lists.tislabs.com'" Subject: Re: why the SAs are unidirectional In-Reply-To: Your message of "Mon, 18 Feb 2002 20:31:16 +0500." <4F7DD203738DD411B71A00B0D03DDECC034A21F6@highway> Reply-to: sommerfeld@east.sun.com Date: Mon, 18 Feb 2002 12:29:47 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I have a query regarding SAs (Security Associations ), why SAs are defined > in one direction. Separate for inbound and outbond traffic. Why are they not > defined in both ways. 1) reusing the same key in both directions makes reflection attacks easier; using a different key makes them much harder. 2) reusing the same SPI in both directions is impossible in general since the owner of each destination address controls/allocates its own inbound SPI space. Most key management protocols create pairs of SA's, one in each direction. From owner-ipsec@lists.tislabs.com Mon Feb 18 11:46:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1IJkB302064; Mon, 18 Feb 2002 11:46:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06301 Mon, 18 Feb 2002 14:05:07 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: , "'867'" <867@nu.edu.pk> Cc: Subject: RE: why the SAs are unidirectional Date: Mon, 18 Feb 2002 14:09:50 -0500 Message-ID: <001601c1b8af$d827d040$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200202181729.g1IHTmsY012966@ack.east.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Also, it's because you want to have different sequence numbers in each direction. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bill Sommerfeld > Sent: Monday, February 18, 2002 12:30 PM > To: 867 > Cc: 'ipsec@lists.tislabs.com' > Subject: Re: why the SAs are unidirectional > > > > I have a query regarding SAs (Security Associations ), why > SAs are defined > > in one direction. Separate for inbound and outbond traffic. > Why are they not > > defined in both ways. > > 1) reusing the same key in both directions makes reflection attacks > easier; using a different key makes them much harder. > > 2) reusing the same SPI in both directions is impossible in general > since the owner of each destination address controls/allocates its own > inbound SPI space. > > Most key management protocols create pairs of SA's, one in each > direction. > From owner-ipsec@lists.tislabs.com Mon Feb 18 13:36:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ILal304562; Mon, 18 Feb 2002 13:36:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06525 Mon, 18 Feb 2002 15:47:45 -0500 (EST) Message-Id: <200202182058.PAA03976@bcn.East.Sun.COM> Date: Mon, 18 Feb 2002 15:58:59 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: why the SAs are unidirectional To: sommerfeld@east.sun.com, 867@nu.edu.pk, andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CaQpTocvkSCTXdACC7NIGg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>"867" (is that really your name? :-) ) asked why Ipsec SAs unidirectional. >>Bill Sommerfeld and Andrew Krywaniuk pointed out that it is useful >>to have separate keys, SPIs and sequence numbers in the two directions. There's no reason why you can't create a bidirectional SA with different SPIs, sequence numbers, and keys in the two directions. For instance, SSL has different keys for the two directions. IKEv1 should have but didn't. You really wouldn't want to create a true unidirectional SA, since it is hard to tell if it's a black hole. So IPsec SAs get created in pairs, and sometimes it's awkward to match up what the proper SA in the other direction is in case you'd want to send an error message. Radia From owner-ipsec@lists.tislabs.com Mon Feb 18 13:41:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ILf2304654; Mon, 18 Feb 2002 13:41:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06563 Mon, 18 Feb 2002 16:08:37 -0500 (EST) Message-Id: <200202182119.g1ILJLsY013224@ack.east.sun.com> From: Bill Sommerfeld To: Radia Perlman - Boston Center for Networking cc: sommerfeld@east.sun.com, 867@nu.edu.pk, andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: why the SAs are unidirectional In-Reply-To: Your message of "Mon, 18 Feb 2002 15:58:59 EST." <200202182058.PAA03976@bcn.East.Sun.COM> Reply-to: sommerfeld@east.sun.com Date: Mon, 18 Feb 2002 16:19:21 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It really helps people to communicate (especially confused newbies) if everyone uses the same terminology. IPsec SA's could have been defined to be bidirectional, but they weren't, and changing the terminology now would just create confusion. - Bill From owner-ipsec@lists.tislabs.com Mon Feb 18 13:41:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ILfM304668; Mon, 18 Feb 2002 13:41:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06573 Mon, 18 Feb 2002 16:09:45 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Radia Perlman - Boston Center for Networking'" , , <867@nu.edu.pk> Cc: Subject: RE: why the SAs are unidirectional Date: Mon, 18 Feb 2002 16:14:33 -0500 Message-ID: <000401c1b8c1$43700be0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200202182058.PAA03976@bcn.East.Sun.COM> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At this point, it just comes down to what you want to name things. In IPsec, an SA is unidirectional object with a 32 bit id, so we're stuck with that. Since IKE does all its operations on pairs of SAs, it is very easy to create a "Bidirectional SA" abstraction that has two 33 bit ids. In our case, we went one step further and created a "Protection Suite" abstraction, which is composed of all the ESP, AH, and IPCOMP SAs in both directions. The fact that the protection suite is sent on the wire as a bunch of individual SAs doesn't make much difference, implementation wise, except that it's perhaps not the optimal encoding. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Radia Perlman - Boston Center for Networking > [mailto:Radia.Perlman@Sun.COM] > Sent: Monday, February 18, 2002 3:59 PM > To: sommerfeld@east.sun.com; 867@nu.edu.pk; > andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: why the SAs are unidirectional > > > >>"867" (is that really your name? :-) ) asked why Ipsec SAs > unidirectional. > >>Bill Sommerfeld and Andrew Krywaniuk pointed out that it is useful > >>to have separate keys, SPIs and sequence numbers in the two > directions. > > There's no reason why you can't create a bidirectional SA > with different > SPIs, sequence numbers, and keys in the two directions. For > instance, SSL > has different keys for the two directions. IKEv1 should have > but didn't. > > You really wouldn't want to create a true unidirectional SA, since it > is hard to tell if it's a black hole. So IPsec SAs get > created in pairs, and > sometimes it's awkward to match up what the proper SA in the > other direction > is in case you'd want to send an error message. > > Radia > > From owner-ipsec@lists.tislabs.com Mon Feb 18 15:39:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1INdv306719; Mon, 18 Feb 2002 15:39:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07057 Mon, 18 Feb 2002 18:03:57 -0500 (EST) From: "Hilarie Orman, Purple Streak Development" To: ipsec@lists.tislabs.com Subject: RE: why the SAs are unidirectional Message-Id: Date: Mon, 18 Feb 2002 16:15:10 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > You really wouldn't want to create a true unidirectional SA, since it > is hard to tell if it's a black hole. So IPsec SAs get created in pairs, It depends on what you mean by "an SA". It's no more strange than UDP and port numbers which are also "unidirectional" channels, and sometimes they are useful as singletons. The naming convention makes IPsec channels naturally unidirectional because the SPI is only unique for the receiver. That turns out to be useful, because the sending and receiving algorithms can be different and because it's easy to define asymmetric protocol use, such as for multicast. Hilarie From owner-ipsec@lists.tislabs.com Mon Feb 18 15:56:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1INu9307007; Mon, 18 Feb 2002 15:56:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07144 Mon, 18 Feb 2002 18:25:14 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 18 Feb 2002 18:36:28 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: RE: why the SAs are unidirectional Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For mutlicast, unidirectional SAs are very appropriate, especially given our sequence number and SPI conventions. Steve From owner-ipsec@lists.tislabs.com Mon Feb 18 18:03:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1J23A309026; Mon, 18 Feb 2002 18:03:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07306 Mon, 18 Feb 2002 20:14:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15473.43370.526000.819610@gargle.gargle.HOWL> Date: Mon, 18 Feb 2002 20:24:58 -0500 From: Paul Koning To: andrew.krywaniuk@alcatel.com Cc: Radia.Perlman@sun.com, sommerfeld@east.sun.com, 867@nu.edu.pk, ipsec@lists.tislabs.com Subject: RE: why the SAs are unidirectional References: <200202182058.PAA03976@bcn.East.Sun.COM> <000401c1b8c1$43700be0$1e72788a@ca.alcatel.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 18 February 2002) by Andrew Krywaniuk: > At this point, it just comes down to what you want to name things. In IPsec, > an SA is unidirectional object with a 32 bit id, so we're stuck with that. > Since IKE does all its operations on pairs of SAs, it is very easy to create > a "Bidirectional SA" abstraction that has two 33 bit ids. Radia brings up a good point, though. Yes, the fundamental construct in IPsec is an SA, which is unidirectional, so they are created in pairs to make a bidirectional channel. Unfortunately, this is a somewhat messy graft on top of the basic mechanism. The protocol really treats each SA as separate, and the fact that the pairs need to go together is something that requires constant care and attention and lots of ugly code in IKE. Compare with SSL, where the bidirectional channel is a fundamental construct, not a kluge patched on top of unidirectional channels. paul From owner-ipsec@lists.tislabs.com Mon Feb 18 23:00:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1J70l313846; Mon, 18 Feb 2002 23:00:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07787 Tue, 19 Feb 2002 01:00:09 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "IETF_DavidChen" To: "Khaja E. Ahmed" Cc: References: Subject: Re: RESEND: Thoughts on identity attacks Date: Tue, 19 Feb 2002 01:09:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 19 Feb 2002 06:10:53.0159 (UTC) FILETIME=[2F8CD770:01C1B90C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Khaja, Don't see your suggestion make sense: 1) IPSec is the only protocol for secured IP connection. 2) If what you said happen, none will use 'low-end' security IPSec. Just as none will buy a car with spec. says a 'low-end' safety standard is used. (such as tires will cause your car crash) 3) Need another protocol for 'high-end' security IP and the compability between 'low-end' and 'high-end' becomes issue and etc.... (maybe 'middle-end' security will be required :-) I hope IPSec is 'the best we can offer but not perfect' rather than what you suggested 'not the best we known and its "ok" to use it'. --- David ----- Original Message ----- From: "Khaja E. Ahmed" To: "IETF_DavidChen" Sent: Friday, February 15, 2002 9:15 PM Subject: RE: RESEND: Thoughts on identity attacks > David, > > I think I understand your concern. There is certainly a high end in the > 'civilian' world that converges with the 'military' world. One can think of > companies like Boeing, Lockheed Martin, and some projects in Intel and IBM > that are of national security relevance. This is probably less than 1% of > the target population for which the IETF develops standards. > > I am not suggesting that we build solutions that do not serve their needs. I > am suggesting that we not deprive the rest of the population of a usable > solution in an effort to cater to the needs of this small and select group. > We need to develop standards and products that can be used by everyone. The > absolute high end of the need curve can and should be catered to by special > options that do not get in the way of everyone else. > > Khaja > > > -----Original Message----- > > From: IETF_DavidChen [mailto:ietf_davidchen@hotmail.com] > > Sent: Friday, February 15, 2002 7:19 AM > > To: Khaja E. Ahmed > > Subject: Re: RESEND: Thoughts on identity attacks > > > > > > Khaja, > > I have to point out that: > > The civilian attacker is called terrorist. > > The KGB (and alike) attack is called espionage. > > Have you heard 'Industrial espionage'? > > Think about who is the 'Industry'. > > > > Please define more clearly about 'security for civilian' and 'security for > > non-civilian'. > > Furthermore, if 'Our work should be to invent technologies for civilian > > organizations and individuals.' > > as you said then this 'invented' technology is the best available on the > > face of earth. > > Why it is only for civilian? > > Or you have different meaning of 'invention'? > > > > --- David > > > > > > > > > > ----- Original Message ----- > > From: "Khaja E. Ahmed" > > To: "Dan Harkins" ; "David Jablon" > > > > Cc: > > Sent: Thursday, February 14, 2002 2:15 PM > > Subject: RE: RESEND: Thoughts on identity attacks > > > > > > > Dan, > > > > > > You have asked (in this and in another message) what I think people are > > > using and how, what they might really want and what I recommend. > > > > > > Before I answer those questions I should explain what I believe the > > threats > > > to be that we should worry about. That way there is a frame of > > reference > > to > > > these opinions. I do not believe that we should devote much energy to > > > developing military grade security. Our work should be to invent > > > technologies for civilian organizations and individuals. Attackers with > > the > > > motivation, funding and capabilities of the KGB, Mossad, NSA or other > > > governments, etc are not what we should worry about. (If those > > dudes are > > > after your information you have serious problems and nothing from any > > > standards body is going to help you anyway.) I do recognize > > however that > > > the level of security needed by SWIFT for inter-bank funds > > transfers (for > > > example) will be different from that needed by a small company trying to > > > allow it's employees to telecommute over VPN. That will > > require that our > > > standards accommodate something of a range of solutions. The worst we > > need > > > to worry about is, at the high end of the threat, a serious and capable > > > cryptographer going over to the dark side and working with some COTS > > > equipment. I would not assume that the attacker has access to > > hundreds of > > > computers for example. This is just my opinion - like the rest of the > > > message - and others may feel completely differently about this. > > > > > > My 'opinion of what these people are using': > > > > > > Product developers / companies have done as best a job as they can with > > > implementations of IKE, sometimes leveraging open source stuff (e.g. > > Pluto) > > > and sometimes licensing code from OEMs (e.g. SSH) and rarely developing > > the > > > thing entirely in-house. I suspect that most of their code is not used > > and > > > they know it and worry about it. All that unused and redundant > > > functionality constitutes moving parts in their products, bugs > > waiting to > > > surface, a QA nightmare, a documentation burden, and clutter > > which impacts > > > the reliability, supportability and maintainability of the product. If > > > there was a small core of standardized, mandatory, minimum functionality > > > that could be implemented it would make the products more > > maintainable and > > > reliable. Also as Phil Hallam-Baker has pointed out, such solutions will > > > more easily fit on devices with severe CPU and memory constraints. This > > > would be all that would be needed for 95% of their customers > > and the rest > > > could be served with optional modules / upgrades / add-ons. > > > > > > Most of their customers, the end users, appear quite content to > > use shared > > > secrets. The knowledge that someone casually sniffing packets will not > > see > > > their data and can not easily decrypt it, appears sufficient for most. > > The > > > fact that an attacker would actually have to have a pretty serious level > > of > > > competence, resources and motivation to hack at their data is all the > > > comfort and assurance they need. At the high end of security > > consciousness, > > > most large Financial Institutions, Healthcare/big pharma, and > > some Fortune > > > 500 companies are trying to be more serious about security. These guys > > care > > > about key sizes to the extent that they want 3DES and not DES. Even in > > this > > > crew Aggressive mode is viewed as quite adequate. No main mode needed. > > Some > > > are venturing into certificate based authentication. The few who did, > > have > > > generally ignored certificate status checking. No OCSP, no CRLs and a > > > somewhat relaxed attitude towards certificate life cycle management and > > PKIX > > > compliance. I have no doubt that there are large installed bases doing > > > everything by the book but they are about as rare as the dodo bird. > > > > > > The ones I worry about are using NAT and thinking they have a firewall. > > And > > > when I contemplate how many SMEs have NOTHING and are quite > > happy to have > > > employees pop their corporate mail from home with no VPN or SSL the mind > > > boggles. It would seem more urgent to focus on getting this crew to use > > ANY > > > security before sweating the ratios of key sizes to amount of data > > encrypted > > > if and when they do use some security. For many small companies in this > > > category even a group shared-key would be an improvement. > > What they need > > > is some minimal, non-invasive, low maintenance solution. This is NOT to > > say > > > that I think the rest of the world should be dragged down to the modest > > > security aspirations of this segment but certainly this is a > > need that is > > > currently left unserved. Frankly, we deny this segment a useful and > > adequate > > > solution by steadfastly refusing to come up with something they can > > digest. > > > In fact, it appears that what we deliver is hard to use even > > for Financial > > > Institutions and large corporations with huge IT staffs. In > > other words, > > > while we ignore this lot, we give more attention than is valued/utilized > > to > > > the somewhat more security conscious users. > > > > > > My 'opinion of what these people want': > > > Product developers and companies want simpler standards, with fewer > > choices. > > > The rest can be options. Current options are really not options. The > > > choices are really not choices because they are not adequately separated > > in > > > the standard. It would be a boon to engineering teams around > > the world to > > > have a standard that clearly articulates a mandatory minimum which is > > truly > > > minimal and not knitted along and mixed with the options. Such > > a standard > > > itself would be modular. That allows for the development of > > high end, low > > > end, and mobile/PDA solutions with clear demarcations of functionality. > > The > > > trouble with the 'go write yourself a profile or a BCP' argument is that > > it > > > almost never gets done. First, it is not trivial to do that > > with IKE and > > > many other standards. And then to have to once again go through the gut > > > wrenching consensus building process that the standard already has been > > > through to get the 'profile' accepted by a community is too painful, > > > wasteful, intimidating and generally will not get done. This might be a > > > crazy idea, but while we are talking about opinions, why not modularize > > the > > > standard itself? If the SuccessorToIKE were to specify clearly > > a minimum > > > required as the core and document everything else as optional > > modules, it > > > would dramatically increase adoption, acceptance and *use* of the > > > technology. A more modular standard would also be facilitate profiling. > > It > > > might even make the process of developing the standard itself easier and > > > less contentious if additional capabilities when added were discrete > > > modules. Reference implementations would be easy to develop and adopt, > > > basic interoperability testing would be easy. Manufacturers, > > > application-classes and interest groups could select > > identifiable sub-sets > > > of the standard for their use. Current IKE, IMHO, does not > > lend itself to > > > easy separation of a core minimum that is easily implementable. Even > > gnarly > > > stuff like SSL and PKIX is by comparison easier to profile. For what it > > is > > > worth, the Identrus PKIX profile took less than a day to > > document. (let's > > > not discuss the consensus building part). It was even > > straightforward to > > > hack SSL down to something smaller and leaner, (although less flexible) > > for > > > use between really weak CPU and low memory, low baud rate IrDA port > > equipped > > > devices. My opinion is, that to do the same with IKE is a good deal > > > harder. This might be heresy, but it might be worth considering an > > approach > > > completely outside of current ISAKMP, Oakley and IKE shadows and > > influence. > > > IMHO these standards deliver a level of sophistication and a wealth of > > > capabilities that might, at most, be needed by the top 5% of > > the potential > > > user population. The unwashed masses cant handle it and are therefore > > doing > > > nothing. In fact SSL is emerging as a solution where ideally > > IPsec should > > > be used simply because SSL (without client auth) is brain dead > > simple and > > > easy to implement. > > > > > > Most users want far less security than we wish to have them use. Not > > > because they like being insecure but because we have not yet > > found ways of > > > delivering the security without a penalty in usage complexity, product > > > reliability/robustness and/or cost that exceeds (in the judgment of the > > > user) it's value. For what it is worth I am myself a late > > convert to the > > > 'adequate and no more' security religion. This came after > > nearly a decade > > > and a half of working on and trying to promote security > > solutions that we > > > thought were right for the market but the market thought otherwise. A > > token > > > based authentication product died on us in the market 1990. > > Our elegant, > > > GUI driven CC:Mail and MS Mail digital signature / PKI enabler > > add-on was > > > given the cold shoulder by users in 1992. With nearly monotonous > > regularity > > > since 1992, every year I have seen at least one PKI and SmartCard > > initiative > > > rise, take a few steps forward in some sort of pilot and crash. It > > doesn't > > > matter, it turns out, how secure you want users to be. It > > doesn't matter > > > how secure the standard or standards compliant products are. > > They are all > > > non-starters if they don't meet user requirements. Perhaps incremental > > > security is the answer. The scores of unveilings of the golden solution > > > have mostly all been let downs with few exceptions - like SSL. ESP > > combined > > > with some simple key/SA management protocol can be a huge > > success. Not a > > > large collection of protocols to setup an SA (ISAKMP) to setup > > an SA (IKE) > > > to setup an SA (IPsec)! No I am NOT knocking the brilliant > > work done by > > so > > > many people. I am just saying that it serves the legitimate > > needs of too > > > few and we need something for the rest. > > > > > > Finally, Charlie Kaufman has beautifully captured and explained how > > > standards get bloated in congressional fashion. It is good food for > > > thought. If we don't find a way of solving that problem, there > > isn't much > > > hope of being able to produce lean, efficient and easy to adopt > > standards. > > > He explains how and why 'a camel is a horse designed by committee.' > > Perhaps > > > we can consider things like adopting a process which mandates that there > > > will always be a cleanly separated 'minimum and mandatory to implement' > > part > > > in any standard. Nothing gets added to it unless a compelling case is > > made > > > for it. Everything else is separated into optional modules etc. > > > > > > Khaja > > > > > > > -----Original Message----- > > > > From: owner-ipsec@lists.tislabs.com > > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > > > Sent: Tuesday, February 12, 2002 4:09 PM > > > > To: David Jablon > > > > Cc: ipsec@lists.tislabs.com > > > > Subject: Re: RESEND: Thoughts on identity attacks > > > > > > > > > > > > Well not entirely rhetorical. What I was asking for was his > > opinion of > > > > what these people want and are using. The mandatory-to-implement > > > > authentication method for IKE does not distinguish between a "shared > > > > [secret] password" and a "shared [secret] key". As long as it's shared > > > > and symmetric the "entropy" doesn't matter. But given how broken the > > > > mandatory-to-implement authentication method is I'm surprised > > that this > > > > is what is being used in the large deployments he was talking about. > > > > Or maybe he's talking about legacy authentication using RADIUS or the > > > > like. I don't know. I'd like to know though. > > > > > > > > Dan. > > > > > > > > On Tue, 12 Feb 2002 22:27:00 EST you wrote > > > > > At 01:41 PM 2/12/02 -0800, Dan Harkins wrote: > > > > > >On Tue, 12 Feb 2002 12:34:17 PST Khaja wrote > > > > > >> I meant shared secrets not shared password. > > > > > > > > > > > > If that's what you meant then you shouldn't have written > > > > "shared password" > > > > >. > > > > > >But please explain the difference anyway. [...] > > > > > > > > > > I'm pretty sure that Dan was asking a rhetorical question here. > > > > > But it is a point of common confusion. > > > > > > > > > > To help, I propose the following definitions, based on observed > > > > common usage: > > > > > > > > > > shared [secret] password: > > > > > a low-entropy secret authenticator. > > > > > > > > > > shared [secret] key: > > > > > a high-entropy cryptographic secret. > > > > > > > > > > shared secret: > > > > > a key that was probably derived from a > > > > password, but used in > > > > > a cryptographic system in which there is > > > > misplaced hope that > > > > > the secret truly does have high entropy. > > > > > > > > > > I think this, plus the ambiguity argument, makes a good case for > > > > > "shared secret" to be deprecated. > > > > > > > > > > -- David > > > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Feb 18 23:36:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1J7af319127; Mon, 18 Feb 2002 23:36:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07902 Tue, 19 Feb 2002 02:01:38 -0500 (EST) Date: Tue, 19 Feb 2002 09:12:53 +0200 Message-Id: <200202190712.JAA07341@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <15473.43370.526000.819610@gargle.gargle.HOWL> (message from Paul Koning on Mon, 18 Feb 2002 20:24:58 -0500) Subject: Re: why the SAs are unidirectional References: <200202182058.PAA03976@bcn.East.Sun.COM> <000401c1b8c1$43700be0$1e72788a@ca.alcatel.com> <15473.43370.526000.819610@gargle.gargle.HOWL> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Unfortunately, this is a somewhat messy graft on top of the basic > mechanism. The protocol really treats each SA as separate, and the > fact that the pairs need to go together is something that requires > constant care and attention and lots of ugly code in IKE. Which is why it shouldn't have tried that in the first place. As I have said several times, IPSEC would work just fine if key negotiation just negetiated a key for unidirectional SA. Very simple compared to the current mess. From owner-ipsec@lists.tislabs.com Tue Feb 19 00:25:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1J8PU325609; Tue, 19 Feb 2002 00:25:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08001 Tue, 19 Feb 2002 02:47:31 -0500 (EST) Message-ID: <20020219075813.72578.qmail@web8006.mail.in.yahoo.com> Date: Tue, 19 Feb 2002 07:58:13 +0000 (GMT) From: =?iso-8859-1?q?ranjeet=20barve?= Subject: RE: why the SAs are unidirectional To: "Hilarie Orman, Purple Streak Development" , ipsec@lists.tislabs.com Cc: achitale@pace.stpp.soft.net, adeshmukh@pace.stpp.soft.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > That turns out to be useful, > because the sending > and receiving algorithms can be different and > because it's easy to > define asymmetric protocol use, such as for > multicast. Does this mean that the Property of an SA being Uni-Directional allows the existence of the following scenario Policy Database: Peer 1 Peer2 Inbound ESP Tunnel(3DES) AH Tunnel(HMAC-MD5) Outbound AH Tunnel(HMAC-MD5) ESP Tunnel(3DES) Thus no matter who initiates a connection, whenever Peer1 sends data to Peer2, AH Tunnel mode will be used and when Peer 2 sends data to Peer 1, ESP Tunnel mode will be used. Also if IKE is used for SA exchange, 4 SAs will be created at each Peer, two for AH Tunnel mode and two for ESP Tunnel Mode. Please correct me if I am wrong. Does the Initiator of the Data transfer Dominate the type of IPsec Tunneling between the Peers? e.g if Peer 1 initiates the Data Transfer, then the AH Tunnel mode SAs will be used for Data transfer between the peers till the SAs expire or the Connection Terminates. Regards, Ranjeet Barve. M.Tech, IITB. ________________________________________________________________________ Looking for a job? Visit Yahoo! India Careers Visit http://in.careers.yahoo.com From owner-ipsec@lists.tislabs.com Tue Feb 19 10:15:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1JIFI307691; Tue, 19 Feb 2002 10:15:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09099 Tue, 19 Feb 2002 12:08:23 -0500 (EST) Message-Id: <200202191718.g1JHHsQ00388@fatty.lounge.org> To: Markku Savela Cc: ipsec@lists.tislabs.com Subject: Re: why the SAs are unidirectional In-Reply-To: Your message of "Tue, 19 Feb 2002 09:12:53 +0200." <200202190712.JAA07341@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <385.1014139074.1@tibernian.com> Date: Tue, 19 Feb 2002 09:17:54 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes and every time you've mentioned it people have pointed out how that wouldn't work, the last time being the compare-jfk-sigma.txt thread of early December last year. Dan. On Tue, 19 Feb 2002 09:12:53 +0200 you wrote > > > Unfortunately, this is a somewhat messy graft on top of the basic > > mechanism. The protocol really treats each SA as separate, and the > > fact that the pairs need to go together is something that requires > > constant care and attention and lots of ugly code in IKE. > > Which is why it shouldn't have tried that in the first place. As I > have said several times, IPSEC would work just fine if key negotiation > just negetiated a key for unidirectional SA. Very simple compared to > the current mess. > From owner-ipsec@lists.tislabs.com Wed Feb 20 01:48:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1K9mc316216; Wed, 20 Feb 2002 01:48:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA10657 Wed, 20 Feb 2002 03:44:21 -0500 (EST) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC0173B99D@highway> From: 827 <827@nu.edu.pk> To: "'ipsec@lists.tislabs.com'" Subject: IPsec inbound processing Date: Wed, 20 Feb 2002 13:57:22 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The RFC 2401's section 5.2.1 says about selecting an SA / SA bundle for Inbound IP traffic. I am at the moment quite confused about the sequence of searching and using an SA. Why is it so that we first directly look for an SA from SAD using the selector valus of the packet? Why not we directly refer to SPD than get the SA pointer from there (SPD) to look it in SAD. And if it is not the way i have written it, how an inbound ip packet is processed? Regards. Siddique FAST - NU Pakistan From owner-ipsec@lists.tislabs.com Wed Feb 20 02:01:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KA1s318640; Wed, 20 Feb 2002 02:01:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10728 Wed, 20 Feb 2002 04:19:05 -0500 (EST) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC0173B99E@highway> From: 827 <827@nu.edu.pk> To: "'ipsec'" Subject: Tunnel Mode and Auditable Events Date: Wed, 20 Feb 2002 14:31:41 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have two questions: 1) Why is it necessary for an SA involiving a Security Gateway to be in Tunnel Mode? 2) What are auditable events (how are they defined?)? Regards From owner-ipsec@lists.tislabs.com Wed Feb 20 04:03:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KC3J325227; Wed, 20 Feb 2002 04:03:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10935 Wed, 20 Feb 2002 06:23:59 -0500 (EST) Message-Id: <200202201133.g1KBX8g43873@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: 827 <827@nu.edu.pk> cc: "'ipsec'" Subject: Re: Tunnel Mode and Auditable Events In-reply-to: Your message of Wed, 20 Feb 2002 14:31:41 +0500. <4F7DD203738DD411B71A00B0D03DDECC0173B99E@highway> Date: Wed, 20 Feb 2002 12:33:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I have two questions: 1) Why is it necessary for an SA involiving a Security Gateway to be in Tunnel Mode? => because SAs in transport mode are end-to-end and the term Security Gateway includes the gateway notion, i.e. the opposite of end-to-end. This is only a question of terminology, you can have a transport mode SA between two nodes which are security gateways too, but RFC 2401 section 4.3 way to describe things, they are hosts which are also security gateways. 2) What are auditable events (how are they defined?)? => look at RFC 2401 section 7. Regards Francis.Dupont@enst-bretagne.fr PS: IMHO everything is already in RFCs 240x but they are not the best written documents so you can have some difficulties to understand some small but so important details... From owner-ipsec@lists.tislabs.com Wed Feb 20 04:03:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KC3V325242; Wed, 20 Feb 2002 04:03:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10904 Wed, 20 Feb 2002 06:15:34 -0500 (EST) Message-Id: <200202201124.g1KBORg43849@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: 827 <827@nu.edu.pk> cc: "'ipsec@lists.tislabs.com'" Subject: Re: IPsec inbound processing In-reply-to: Your message of Wed, 20 Feb 2002 13:57:22 +0500. <4F7DD203738DD411B71A00B0D03DDECC0173B99D@highway> Date: Wed, 20 Feb 2002 12:24:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: The RFC 2401's section 5.2.1 says about selecting an SA / SA bundle for Inbound IP traffic. I am at the moment quite confused about the sequence of searching and using an SA. => RFC 2401 has a high level of details and experience showed this was/is necessary. Of course, they (the details) are not easy to understand... Why is it so that we first directly look for an SA from SAD using the selector valus of the packet? Why not we directly refer to SPD than get the SA pointer from there (SPD) to look it in SAD. => just a little question, how can you do this with ESP in tunnel mode (which is BTW the most common IPsec SA type)? And if it is not the way i have written it, how an inbound ip packet is processed? => RFC 2401 section 5.2 (read, reread, and don't stop when you believe you've understood :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Feb 20 06:21:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KELg303724; Wed, 20 Feb 2002 06:21:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11198 Wed, 20 Feb 2002 08:29:40 -0500 (EST) To: ranjeet barve Cc: "Hilarie Orman, Purple Streak Development" , ipsec@lists.tislabs.com, achitale@pace.stpp.soft.net, adeshmukh@pace.stpp.soft.net From: Derek Atkins Subject: Re: why the SAs are unidirectional References: <20020219075813.72578.qmail@web8006.mail.in.yahoo.com> Date: 19 Feb 2002 10:24:26 -0500 In-Reply-To: <20020219075813.72578.qmail@web8006.mail.in.yahoo.com> Message-ID: Lines: 49 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ranjeet barve writes: > Does this mean that the Property of an SA being > Uni-Directional allows the existence of the following > scenario > > Policy Database: > Peer 1 Peer2 > Inbound ESP Tunnel(3DES) AH Tunnel(HMAC-MD5) > > Outbound AH Tunnel(HMAC-MD5) ESP Tunnel(3DES) > > Thus no matter who initiates a connection, whenever > Peer1 sends data to Peer2, AH Tunnel mode will be used > and when Peer 2 sends data to Peer 1, ESP Tunnel mode > will be used. Theoretically, yes, you could setup a pair of peers with this type of configuration, although I don't think IKE would actually be able to negotiate such a result. > Also if IKE is used for SA exchange, 4 SAs will be > created at each Peer, two for AH Tunnel mode and two > for ESP Tunnel Mode. > Please correct me if I am wrong. Well, this is confusing. If you assumed that IKE could negotiation non-symmetric protection, then no, only TWO SAs will be created at east Peer. Each peer has ONE INBOUND and ONE OUTBOUND SA. So, yes, there are four SAs in total, but only two per peer. > Does the Initiator of the Data transfer Dominate the > type of IPsec Tunneling between the Peers? e.g if Peer > 1 initiates the Data Transfer, then the AH Tunnel mode > SAs will be used for Data transfer between the peers > till the SAs expire or the Connection Terminates. No, the two IKE peers MUST agree on on the protection suite. > Regards, > Ranjeet Barve. > M.Tech, IITB. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Feb 20 06:21:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KELl303740; Wed, 20 Feb 2002 06:21:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11234 Wed, 20 Feb 2002 08:42:32 -0500 (EST) Date: Wed, 20 Feb 2002 14:53:14 +0100 (MET) Message-Id: <200202201353.OAA24930@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: Tunnel Mode and Auditable Events In-Reply-To: <200202201133.g1KBX8g43873@givry.rennes.enst-bretagne.fr> References: <4F7DD203738DD411B71A00B0D03DDECC0173B99E@highway> <200202201133.g1KBX8g43873@givry.rennes.enst-bretagne.fr> Organization: Département Logiciels - Réseaux X-Mailer: Sylpheed version 0.6.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi > In your previous mail you wrote: > > I have two questions: > 1) Why is it necessary for an SA involiving a Security Gateway to be in > Tunnel Mode? > > => because SAs in transport mode are end-to-end and the term Security > Gateway includes the gateway notion, i.e. the opposite of end-to-end. > This is only a question of terminology, you can have a transport mode SA > between two nodes which are security gateways too, but RFC 2401 section > 4.3 way to describe things, they are hosts which are also security > gateways. I don't know if "a question of terminology" should be the right term here, though it may be sufficient for the end user. I'll try to give extra info here. Let's take 2 hosts A and B, Scenario 1: A may communicate directly with B, with end to end security; this is transport mode. There are no intermediates. Scenario 2: A is behing a security gateway GA, B is behind a security gateway GB. Eg, A would send in-clear packets to B, but it is not in the company policy: for B's network, GA's policy database states that encryption should be used. GA encrypts A packets and sends them to GB, which decrypts them and forwards them to B. This is a tunnel mode operation. Note that a gateway may use transport mode if it acts as a host: GA may be configured securely from a host in GA's network using transport mode. > 2) What are auditable events (how are they defined?)? > > => look at RFC 2401 section 7. Good catch. RFCs 2401 and 2411 are good entrances and references for IPsec standards. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: IMHO everything is already in RFCs 240x but they are not the best > written documents so you can have some difficulties to understand some > small but so important details... I wanted to have a closer (though not exhaustive) look: ~/documents/ietf/rfc/ipsec$ grep -B 1 -A 1 -n "auditable" * | more (I cleaned the output and joined it below for people interested) It appears that: * An auditable event *usually* occurs when it should not; the audit function keeps trace of such a problem: sequence number overflow, wrong combination of two null algo, wrong processing required, validation failed, misconfiguration option... * Some auditable events are given in 240xs, if these events are taken into account by an implementation, some informations SHOULD be included (SPI, date, time, source...) and some additional MAY be included. * Auditing events and with which granularity is above all a local matter. Hope it helps. -- Jean-Jacques Puig rfc2401.txt-1199- "Sequence Counter Overflow: a flag indicating whether overflow of the Sequence Number Counter should generate an auditable event and prevent transmission of additional packets..." rfc2401.txt-1650- "...determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event. If the traffic is allowed to bypass IPsec processing, the packet continues through..." rfc2401.txt-1688- "...ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event..." rfc2401.txt-2138- "...the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications and for each of these events a minimum set..." rfc2401.txt-2145- "...no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service..." rfc2402.txt-437- "An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.)." rfc2402.txt-689- "...i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value..." rfc2402.txt-712- "...receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination..." rfc2402.txt-772- "...If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI..." rfc2402.txt-806- "...If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry SHOULD include the SPI value, date/time..." rfc2402.txt-833- "...part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be..." rfc2402.txt-848- "...receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action." rfc2406.txt-634- "...An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.)..." rfc2406.txt-708- "...i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value..." rfc2406.txt-740- "...example, the receiver has no key), the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source..." rfc2406.txt-805- "...ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI..." rfc2406.txt-828- "...and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time..." rfc2406.txt-946- "...part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be..." rfc2406.txt-961- "...receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action." rfc2407.txt-1033- "...other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable." From owner-ipsec@lists.tislabs.com Wed Feb 20 06:55:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KEta307316; Wed, 20 Feb 2002 06:55:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11338 Wed, 20 Feb 2002 09:17:37 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4F7DD203738DD411B71A00B0D03DDECC0173B99D@highway> References: <4F7DD203738DD411B71A00B0D03DDECC0173B99D@highway> Date: Wed, 20 Feb 2002 09:23:52 -0500 To: 827 <827@nu.edu.pk> From: Stephen Kent Subject: Re: IPsec inbound processing Cc: "'ipsec@lists.tislabs.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:57 PM +0500 2/20/02, 827 wrote: >The RFC 2401's section 5.2.1 says about selecting an SA / SA bundle for >Inbound IP traffic. I am at the moment quite confused about the sequence of >searching and using an SA. > >Why is it so that we first directly look for an SA from SAD using the >selector valus of the packet? Why not we directly refer to SPD than get the >SA pointer from there (SPD) to look it in SAD. > >And if it is not the way i have written it, how an inbound ip packet is >processed? > >Regards. > >Siddique >FAST - NU Pakistan Siddique, We are in the process of revising 2401, after we finish with ESP and AH. In the revision we will include a new processing model that clarifies what has to be done and which will eliminate the discussion of searching the SPD. The wording used in this part of 2401 has caused considerable confusion over time and I apologize for that. Steve From owner-ipsec@lists.tislabs.com Wed Feb 20 06:55:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KEth307329; Wed, 20 Feb 2002 06:55:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11337 Wed, 20 Feb 2002 09:17:36 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4F7DD203738DD411B71A00B0D03DDECC0173B99E@highway> References: <4F7DD203738DD411B71A00B0D03DDECC0173B99E@highway> Date: Wed, 20 Feb 2002 09:25:54 -0500 To: 827 <827@nu.edu.pk> From: Stephen Kent Subject: Re: Tunnel Mode and Auditable Events Cc: "'ipsec'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I have two questions: >1) Why is it necessary for an SA involiving a Security Gateway to be in >Tunnel Mode? > >2) What are auditable events (how are they defined?)? > >Regards SAs terminating at SGs must be in tunnel mode, if they are for transit traffic, because otherwise we could have problems when a set of hosts (e.g., a campus network) is served by multiple SGs (i.e., multihomed). Throughout the RFCs (2401, 2402, 2406) we define what should be audited; those are auditable events. Steve From owner-ipsec@lists.tislabs.com Wed Feb 20 12:43:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KKh6316951; Wed, 20 Feb 2002 12:43:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12111 Wed, 20 Feb 2002 14:35:21 -0500 (EST) Message-ID: <49F78F5E3F07D511818200508B5C78510459A464@BALNTEX001.qwest.net> From: "Shetty, Snehal S" To: "'ipsec@lists.tislabs.com'" Subject: Lifetime & rekeying Date: Wed, 20 Feb 2002 12:46:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am trying to understand what happens after an IPSEC SA reaches its Lifetime. I know that another SA is established before the previous SA goes down but is there a new key used on this SA, if IKE is configured with pre-shared keys. Thanks From owner-ipsec@lists.tislabs.com Wed Feb 20 14:30:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KMUG319348; Wed, 20 Feb 2002 14:30:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12611 Wed, 20 Feb 2002 16:48:40 -0500 (EST) Message-ID: From: "Lordello, Claudio" To: "'Shetty, Snehal S'" , "'ipsec@lists.tislabs.com'" Subject: RE: Lifetime & rekeying Date: Wed, 20 Feb 2002 16:59:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, a new set of session keys is established for the new SA in a phase 2 exchange. This new phase 2 exchange may or may not require a new phase 1 depending on whether a phase 1 is still around or not. The IKE pre-shared keys are used to authenticate the endpoints of the communication during a phase 1 exchange. The IKE pre-shared keys do not expire. Claudio. > -----Original Message----- > From: Shetty, Snehal S [mailto:snehal.shetty@qwest.com] > Sent: Wednesday, February 20, 2002 2:46 PM > To: 'ipsec@lists.tislabs.com' > Subject: Lifetime & rekeying > > > > > I am trying to understand what happens after an IPSEC SA reaches its > Lifetime. I know that another SA is established before the > previous SA goes > down but is there a new key used on this SA, if IKE is configured with > pre-shared keys. > > > Thanks > > From owner-ipsec@lists.tislabs.com Wed Feb 20 15:21:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KNLA320608; Wed, 20 Feb 2002 15:21:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12761 Wed, 20 Feb 2002 17:45:53 -0500 (EST) From: arohit@miel.mot.com Message-Id: <5.1.0.14.0.20020220175214.00ae4028@ganga.miel.mot.com> X-Sender: arohit@ganga.miel.mot.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 17:57:51 -0500 To: "Shetty, Snehal S" , "'ipsec@lists.tislabs.com'" Subject: Re: Lifetime & rekeying In-Reply-To: <49F78F5E3F07D511818200508B5C78510459A464@BALNTEX001.qwest. net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Snehal, softlifetime expiry of IPSEC SA will trigger the key manager to renegotiate for the dying SA , The successful key exchange will result in new pair of keys for new SA. -Rohit At 12:46 PM 2/20/2002 -0700, Shetty, Snehal S wrote: > > >I am trying to understand what happens after an IPSEC SA reaches its >Lifetime. I know that another SA is established before the previous SA goes >down but is there a new key used on this SA, if IKE is configured with >pre-shared keys. > > >Thanks > From owner-ipsec@lists.tislabs.com Wed Feb 20 20:07:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1L47H327656; Wed, 20 Feb 2002 20:07:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13386 Wed, 20 Feb 2002 22:12:12 -0500 (EST) From: "Andrew Wenlang Zhu" To: , "'Shetty, Snehal S'" , Subject: RE: Lifetime & rekeying Date: Wed, 20 Feb 2002 19:22:40 -0800 Message-ID: <001d01c1ba87$05b083d0$5ba8f40f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <5.1.0.14.0.20020220175214.00ae4028@ganga.miel.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rohit: I did not find crystal clear statement in existing RFC about when to re-negotiate a new SA for a dying one, though soft lifetime trig a new negotiation is a good practice. I only recall that Linux FreeSwan group come up with a implementation "Draft" including discussion on this issues. Andrew >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of arohit@miel.mot.com >Sent: Wednesday, February 20, 2002 2:58 PM >To: Shetty, Snehal S; 'ipsec@lists.tislabs.com' >Subject: Re: Lifetime & rekeying > > >Snehal, > softlifetime expiry of IPSEC SA will trigger the key >manager to >renegotiate for the dying SA , The successful key exchange >will result in >new pair of keys for new SA. > >-Rohit >At 12:46 PM 2/20/2002 -0700, Shetty, Snehal S wrote: >> >> >>I am trying to understand what happens after an IPSEC SA reaches its >>Lifetime. I know that another SA is established before the >previous SA goes >>down but is there a new key used on this SA, if IKE is configured with >>pre-shared keys. >> >> >>Thanks >> > > > From owner-ipsec@lists.tislabs.com Thu Feb 21 08:11:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LGBi322533; Thu, 21 Feb 2002 08:11:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14762 Thu, 21 Feb 2002 10:18:26 -0500 (EST) From: arohit@miel.mot.com Message-Id: <5.1.0.14.0.20020221102458.00aec160@ganga.miel.mot.com> X-Sender: arohit@ganga.miel.mot.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 10:30:17 -0500 To: "Andrew Wenlang Zhu" , "'Shetty, Snehal S'" , Subject: RE: Lifetime & rekeying In-Reply-To: <001d01c1ba87$05b083d0$5ba8f40f@AZ735043> References: <5.1.0.14.0.20020220175214.00ae4028@ganga.miel.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, IMHO renegotiating a new SA (if required) after a softlife timer goes off for a exisiting SA is a standard practice and i guess that justifies the existance of softlifetime for a paritcular SA. -Regards Rohit At 07:22 PM 2/20/2002 -0800, Andrew Wenlang Zhu wrote: >Rohit: > >I did not find crystal clear statement in existing RFC about when to >re-negotiate a new SA for a dying one, though soft lifetime trig a new >negotiation is a good practice. > >I only recall that Linux FreeSwan group come up with a implementation >"Draft" including discussion on this issues. > >Andrew > > > >-----Original Message----- > >From: owner-ipsec@lists.tislabs.com > >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of arohit@miel.mot.com > >Sent: Wednesday, February 20, 2002 2:58 PM > >To: Shetty, Snehal S; 'ipsec@lists.tislabs.com' > >Subject: Re: Lifetime & rekeying > > > > > >Snehal, > > softlifetime expiry of IPSEC SA will trigger the key > >manager to > >renegotiate for the dying SA , The successful key exchange > >will result in > >new pair of keys for new SA. > > > >-Rohit > >At 12:46 PM 2/20/2002 -0700, Shetty, Snehal S wrote: > >> > >> > >>I am trying to understand what happens after an IPSEC SA reaches its > >>Lifetime. I know that another SA is established before the > >previous SA goes > >>down but is there a new key used on this SA, if IKE is configured with > >>pre-shared keys. > >> > >> > >>Thanks > >> > > > > > > From owner-ipsec@lists.tislabs.com Thu Feb 21 11:32:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJW9328702; Thu, 21 Feb 2002 11:32:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15131 Thu, 21 Feb 2002 13:48:47 -0500 (EST) Message-Id: <4.3.2.7.1.20020221104734.00c7b760@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Feb 2002 10:57:32 -0800 To: "Andrew Wenlang Zhu" , , "'Shetty, Snehal S'" , From: Ramana Yarlagadda Subject: RE: Lifetime & rekeying In-Reply-To: <001d01c1ba87$05b083d0$5ba8f40f@AZ735043> References: <5.1.0.14.0.20020220175214.00ae4028@ganga.miel.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, the RFC doesn't talk about , how to derive the softlife time value . but section 4.4.3 , talks about the guide lines and it is clear from the RFC that it is implementation specific. Long time back there was a draft from Tim Jenkins about IPSec re-keying issues. And if i remember even that doesn't talk about the , specific values (to derive softlife time values) -ramana At 07:22 PM 2/20/02 -0800, Andrew Wenlang Zhu wrote: >Rohit: > >I did not find crystal clear statement in existing RFC about when to >re-negotiate a new SA for a dying one, though soft lifetime trig a new >negotiation is a good practice. > >I only recall that Linux FreeSwan group come up with a implementation >"Draft" including discussion on this issues. > >Andrew > > > >-----Original Message----- > >From: owner-ipsec@lists.tislabs.com > >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of arohit@miel.mot.com > >Sent: Wednesday, February 20, 2002 2:58 PM > >To: Shetty, Snehal S; 'ipsec@lists.tislabs.com' > >Subject: Re: Lifetime & rekeying > > > > > >Snehal, > > softlifetime expiry of IPSEC SA will trigger the key > >manager to > >renegotiate for the dying SA , The successful key exchange > >will result in > >new pair of keys for new SA. > > > >-Rohit > >At 12:46 PM 2/20/2002 -0700, Shetty, Snehal S wrote: > >> > >> > >>I am trying to understand what happens after an IPSEC SA reaches its > >>Lifetime. I know that another SA is established before the > >previous SA goes > >>down but is there a new key used on this SA, if IKE is configured with > >>pre-shared keys. > >> > >> > >>Thanks > >> > > > > > > From owner-ipsec@lists.tislabs.com Thu Feb 21 12:22:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LKM1329974; Thu, 21 Feb 2002 12:22:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15308 Thu, 21 Feb 2002 14:38:48 -0500 (EST) Message-Id: <4.3.2.7.1.20020221114724.00ca4710@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Feb 2002 11:47:33 -0800 To: 827 <827@nu.edu.pk>, "'ipsec@lists.tislabs.com'" From: Ramana Yarlagadda Subject: Re: IPsec inbound processing In-Reply-To: <4F7DD203738DD411B71A00B0D03DDECC0173B99D@highway> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:57 PM 2/20/02 +0500, 827 wrote: >The RFC 2401's section 5.2.1 says about selecting an SA / SA bundle for >Inbound IP traffic. I ]At 01:57 PM 2/20/02 +0500, you wrote: >The RFC 2401's section 5.2.1 says about selecting an SA / SA bundle for >Inbound IP traffic. I am at the moment quite confused about the sequence of >searching and using an SA. > >Why is it so that we first directly look for an SA from SAD using the >selector valus of the packet? Why not we directly refer to SPD than get the >SA pointer from there (SPD) to look it in SAD. Think of how you can extract the selectos from an encrypted packet. To look into the SPD, the required input values are selector values (Source addr, dest addr, src port, dest port and protocol . ). >And if it is not the way i have written it, how an inbound ip packet is >processed? >am at the moment quite confused about the sequence of >searching and using an SA. > >Why is it so that we first directly look for an SA from SAD using the >selector valus of the packet? Why not we directly refer to SPD than get the >SA pointer from there (SPD) to look it in SAD. > >And if it is not the way i have written it, how an inbound ip packet is >processed? > >Regards. > >Siddique >FAST - NU Pakistan From owner-ipsec@lists.tislabs.com Thu Feb 21 14:33:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMXa303086; Thu, 21 Feb 2002 14:33:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15713 Thu, 21 Feb 2002 16:44:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15477.27823.571356.512000@pkoning.dev.equallogic.com> Date: Thu, 21 Feb 2002 16:54:55 -0500 (EST) From: Paul Koning To: ramana@chiplogic.com Cc: ipsec@lists.tislabs.com Subject: RE: Lifetime & rekeying References: <5.1.0.14.0.20020220175214.00ae4028@ganga.miel.mot.com> <4.3.2.7.1.20020221104734.00c7b760@golf.cpgdesign.analog.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ramana" == Ramana Yarlagadda writes: Ramana> Yes, the RFC doesn't talk about , how to derive the softlife Ramana> time value . but section 4.4.3 , talks about the guide lines Ramana> and it is clear from the RFC that it is implementation Ramana> specific. That's sensible. If you want to rekey before the hard expiration of the SA, that's fine, and you can do so at any time. There are no interoperability issues (it doesn't matter what rules you use) so it is proper for protocol standards to be silent about this. Ramana> Long time back there was a draft from Tim Jenkins about IPSec Ramana> re-keying issues. And if i remember even that doesn't talk Ramana> about the , specific values (to derive softlife time values) Tim's draft was addressing a different issue, which is how to coordinate the changeover from the old SA pair to the new SA pair so you would (a) delete the right SAs after rekeying, (b) not lose packets by sending to an SA the other side had already deleted. Strictly speaking that's not a correctness issue (it's legal for packets to be dropped at times) but this was sometimes causing a black hole for at least several seconds, which is enough of a performance hit to be worth fixing. Unfortunately, I don't think that this draft was ever carried through to adoption. paul From owner-ipsec@lists.tislabs.com Thu Feb 21 15:02:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LN2k303732; Thu, 21 Feb 2002 15:02:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15829 Thu, 21 Feb 2002 17:26:14 -0500 (EST) X-Envelope-Sender-Is: ewilkinson@efficient.com (at relayer ns0.sbs.siemens.com) Message-ID: <36C2EB69D2F9D411A9AB00D0B7200334F8156F@eniwest.inside.efficient.com> From: Edward Wilkinson To: "Ipsec (E-mail)" Subject: Phase 1 Lifetime and Lifedata Date: Thu, 21 Feb 2002 14:31:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When using some of the gateways and clients, I see an option to set lifedata.. Is this filed valid in phase 1 and if it is how would it be used. From owner-ipsec@lists.tislabs.com Thu Feb 21 15:59:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LNxn305104; Thu, 21 Feb 2002 15:59:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15973 Thu, 21 Feb 2002 18:20:52 -0500 (EST) From: dfox@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A018EADBD@email.quarrytech.com> To: ewilkinson@efficient.com Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Lifetime and Lifedata Date: Thu, 21 Feb 2002 18:31:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the last couple of implementations, that I was involved with testing, we didn't use Lifedata in Phase 1. The reason for this is that the ISAKMP communications are so small that it didn't make sense. If it was sent to us, we dealt with it appropriately. We always used Lifetime, however. David =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Fox Quarry Technologies dfox@quarrytech.com 8 New England Executive Park Direct: 781-359-5094 Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 www.quarrytech.com FAX: 781-505-8316 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: Edward Wilkinson [mailto:ewilkinson@efficient.com] Sent: Thursday, February 21, 2002 5:31 PM To: Ipsec (E-mail) Subject: Phase 1 Lifetime and Lifedata When using some of the gateways and clients, I see an option to set lifedata.. Is this filed valid in phase 1 and if it is how would it be used. From owner-ipsec@lists.tislabs.com Thu Feb 21 16:32:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1M0Wi306375; Thu, 21 Feb 2002 16:32:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16058 Thu, 21 Feb 2002 18:57:37 -0500 (EST) Message-Id: <200202220008.g1M08iQ02440@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Lifetime & rekeying In-reply-to: Your message of "Thu, 21 Feb 2002 16:54:55 EST." <15477.27823.571356.512000@pkoning.dev.equallogic.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Feb 2002 19:08:44 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: >>>>> "Ramana" == Ramana Yarlagadda writes: Ramana> Yes, the RFC doesn't talk about , how to derive the softlife Ramana> time value . but section 4.4.3 , talks about the guide lines Ramana> and it is clear from the RFC that it is implementation Ramana> specific. Paul> That's sensible. If you want to rekey before the hard expiration of Paul> the SA, that's fine, and you can do so at any time. There are no Paul> interoperability issues (it doesn't matter what rules you use) so it Paul> is proper for protocol standards to be silent about this. Ramana> Long time back there was a draft from Tim Jenkins about IPSec Ramana> re-keying issues. And if i remember even that doesn't talk Ramana> about the , specific values (to derive softlife time values) Paul> Tim's draft was addressing a different issue, which is how to Paul> coordinate the changeover from the old SA pair to the new SA pair so Paul> you would (a) delete the right SAs after rekeying, (b) not lose Paul> packets by sending to an SA the other side had already deleted. draft-spencer-ipsec-ike-implementation-01.txt proposes a clear method to do this transition. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Feb 21 17:09:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1M19E306995; Thu, 21 Feb 2002 17:09:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16127 Thu, 21 Feb 2002 19:25:55 -0500 (EST) X-Envelope-Sender-Is: ewilkinson@efficient.com (at relayer ns0.sbs.siemens.com) Message-ID: <36C2EB69D2F9D411A9AB00D0B7200334F81574@eniwest.inside.efficient.com> From: Edward Wilkinson To: "'dfox@quarrytech.com'" Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Lifetime and Lifedata Date: Thu, 21 Feb 2002 16:31:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I normally do not use it either, but some implementations have both enabled by default. Others do not support it in phase one. I guess the question should be, should it be supported and if so why. Ed -----Original Message----- From: dfox@quarrytech.com [mailto:dfox@quarrytech.com] Sent: Thursday, February 21, 2002 3:32 PM To: ewilkinson@efficient.com Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Lifetime and Lifedata In the last couple of implementations, that I was involved with testing, we didn't use Lifedata in Phase 1. The reason for this is that the ISAKMP communications are so small that it didn't make sense. If it was sent to us, we dealt with it appropriately. We always used Lifetime, however. David =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Fox Quarry Technologies dfox@quarrytech.com 8 New England Executive Park Direct: 781-359-5094 Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 www.quarrytech.com FAX: 781-505-8316 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: Edward Wilkinson [mailto:ewilkinson@efficient.com] Sent: Thursday, February 21, 2002 5:31 PM To: Ipsec (E-mail) Subject: Phase 1 Lifetime and Lifedata When using some of the gateways and clients, I see an option to set lifedata.. Is this filed valid in phase 1 and if it is how would it be used. From owner-ipsec@lists.tislabs.com Thu Feb 21 21:09:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1M59g312289; Thu, 21 Feb 2002 21:09:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16644 Thu, 21 Feb 2002 23:09:37 -0500 (EST) From: "Jayant Shukla" To: Subject: NAT Traversal Date: Thu, 21 Feb 2002 20:17:49 -0800 Message-ID: <001501c1bb57$e35b87e0$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <36C2EB69D2F9D411A9AB00D0B7200334F81574@eniwest.inside.efficient.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The proposed NAT traversal method runs into problems with some routers that monitor the IKE cookies. What steps are being taken to overcome this problem? Regards, Jayant From owner-ipsec@lists.tislabs.com Thu Feb 21 22:20:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1M6K3313515; Thu, 21 Feb 2002 22:20:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA16859 Fri, 22 Feb 2002 00:41:11 -0500 (EST) Message-ID: <002b01c1bb67$e3b80c80$ae0510ac@roc.com> From: "Lokesh" To: "IPsec Mailing List" Subject: questions on Anti Replay Check Date: Fri, 22 Feb 2002 11:42:19 +0530 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C1BB95.FC3A87A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C1BB95.FC3A87A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I have Following doubts regarding Antireplay service. My understanding of replay attack is a hacker can get hold of a = legitimate packet in the traffic and transmit it to recevier after a while, this can cause = confusion or have some undesirable consequences at the receiving end. right? Usually Antireplay check is not done for IPsec SA's of manual key = management. why? Like any other secure traffic, traffic carried such SA too can be = hacked by=20 replay attack right? ESP RFC 2406 says: The anti- replay service may be selected only if data origin = authentication is selected, and its election is solely at the discretion of the = receiver. Why only if data origin authentication is selcted? esp trafiic without = authentication can't come under replay attack?[ assuming AH is not used ] Thanks Lokesh ------=_NextPart_000_0028_01C1BB95.FC3A87A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
I have Following doubts regarding = Antireplay=20 service.
 
My understanding of replay attack is a = hacker can=20 get hold of a legitimate packet
in the traffic and transmit it to = recevier after a=20 while, this can cause confusion or
have some undesirable consequences at = the receiving=20 end. right?
 
Usually Antireplay check is not done = for IPsec SA's=20 of manual key management.
why? Like any other secure traffic, = traffic carried=20 such SA too can be hacked by
replay attack right?
 
ESP RFC 2406 says:
 
 The anti- replay service may be = selected only=20 if data origin authentication is
   selected, and its = election is=20 solely at the discretion of the  receiver.
 
 Why only if data origin = authentication is=20 selcted? esp trafiic without authentication
  can't come under replay attack?[ = assuming AH=20 is not used ]
 
Thanks
Lokesh
 
 
 
------=_NextPart_000_0028_01C1BB95.FC3A87A0-- From owner-ipsec@lists.tislabs.com Fri Feb 22 01:39:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1M9dM311406; Fri, 22 Feb 2002 01:39:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17243 Fri, 22 Feb 2002 03:50:02 -0500 (EST) Date: Fri, 22 Feb 2002 10:00:38 +0100 (MET) Message-Id: <200202220900.KAA10074@hugo.int-evry.fr> From: Jean-Jacques Puig To: "Lokesh" Cc: ipsec@lists.tislabs.com Subject: Re: questions on Anti Replay Check In-Reply-To: <002b01c1bb67$e3b80c80$ae0510ac@roc.com> References: <002b01c1bb67$e3b80c80$ae0510ac@roc.com> Organization: Département Logiciels - Réseaux X-Mailer: Sylpheed version 0.6.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi ! Lokesh wrote: > My understanding of replay attack is a hacker can get hold of a legitimate packet > in the traffic and transmit it to recevier after a while, this can cause confusion or > have some undesirable consequences at the receiving end. right? Right. Depending on the protocol, one can also cause troubles replaying the packet to another receveir, or even to the original sender. > Usually Antireplay check is not done for IPsec SA's of manual key management. > why? Usually, manual keying sets directly the secrets of the SA. The anti-replay window will cycle after many exchanges, and SA's adminitrator may not bother about manually rekeying again and again. Thus, LEGAL packets, with the same caracteristics (SPI...) and sequence numbers of ones of the previous cycle will be sent. For a manual-keyed SA to last for many cycles, antireplay check must be disabled, or cycling packets are likely to be dropped. >Like any other secure traffic, traffic carried such SA too can be hacked by > replay attack right? Yes. May be an easy way to solve this situation would be to manually set a key seed for the SA, and the key material would be automatically derived from that key on both sides in order to refresh SA's secrets when anti-replay window is about to cycle. But there are hazards of loss of key synchronization beetween hosts. > ESP RFC 2406 says: > > The anti- replay service may be selected only if data origin authentication is > selected, and its election is solely at the discretion of the receiver. > > Why only if data origin authentication is selcted? esp trafiic without authentication > can't come under replay attack?[ assuming AH is not used ] If there is no data origin authentication, one may build or alter a packet with a correct sequence number which will bypass the anti-replay service. This service is useless in such a case. Building a new packet is eased by the lack of authentication. Alter a packet is eased by the improper use of integrity without authentication. Thus authentication is necessary for anti-replay service. -- Jean-Jacques Puig "There is a Chinese proverb for all situations" -- Chinese proverb -- From owner-ipsec@lists.tislabs.com Fri Feb 22 01:52:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1M9qA311891; Fri, 22 Feb 2002 01:52:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17315 Fri, 22 Feb 2002 04:20:27 -0500 (EST) Message-ID: <119170422361D311B41900A0CC419794E0F0E9@white3.nvc.co.jp> From: Takaoka Takayoshi To: "'Jayant Shukla'" , ipsec@lists.tislabs.com Subject: RE: NAT Traversal Date: Fri, 22 Feb 2002 18:43:27 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That means, a certain router drop the IKE keep-alive packet, right? I need more information for this issue. Best regards, Taka -----Original Message----- From: Jayant Shukla [mailto:jshukla@trlokom.com] Sent: Friday, February 22, 2002 1:18 PM To: ipsec@lists.tislabs.com Subject: NAT Traversal The proposed NAT traversal method runs into problems with some routers that monitor the IKE cookies. What steps are being taken to overcome this problem? Regards, Jayant From owner-ipsec@lists.tislabs.com Fri Feb 22 04:13:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MCDS322078; Fri, 22 Feb 2002 04:13:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA17587 Fri, 22 Feb 2002 06:33:39 -0500 (EST) Message-ID: <002101c1bb99$1d28fb60$ae0510ac@roc.com> From: "Lokesh" To: "Jean-Jacques Puig" Cc: References: <002b01c1bb67$e3b80c80$ae0510ac@roc.com> <200202220900.KAA10074@hugo.int-evry.fr> Subject: Re: questions on Anti Replay Check Date: Fri, 22 Feb 2002 17:34:33 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks , please see questions inlined. -Lokesh ----- Original Message ----- From: Jean-Jacques Puig To: Lokesh Cc: Sent: Friday, February 22, 2002 2:30 PM Subject: Re: questions on Anti Replay Check > Hi ! > > Lokesh wrote: > > > My understanding of replay attack is a hacker can get hold of a legitimate packet > > in the traffic and transmit it to recevier after a while, this can cause confusion or > > have some undesirable consequences at the receiving end. right? > > Right. Depending on the protocol, one can also cause troubles replaying the packet to another receveir, or even to the original sender. > Troubles to original sender? how? ones like sender getting two ACKs for one packet sent? > > Usually Antireplay check is not done for IPsec SA's of manual key management. > > why? > > Usually, manual keying sets directly the secrets of the SA. The anti-replay window will cycle after many exchanges, and SA's adminitrator may not bother about manually rekeying again and again. Thus, LEGAL packets, with the same caracteristics (SPI...) and sequence numbers of ones of the previous cycle will be sent. For a manual-keyed SA to last for many cycles, antireplay check must be disabled, or cycling packets are likely to be dropped. > > >Like any other secure traffic, traffic carried such SA too can be hacked by > > replay attack right? > > Yes. > May be an easy way to solve this situation would be to manually set a key seed for the SA, and the key material would be automatically derived from that key on both sides in order to refresh SA's secrets when anti-replay window is about to cycle. But there are hazards of loss of key synchronization beetween hosts. > > > ESP RFC 2406 says: > > > > The anti- replay service may be selected only if data origin authentication is > > selected, and its election is solely at the discretion of the receiver. > > > > Why only if data origin authentication is selcted? esp trafiic without authentication > > can't come under replay attack?[ assuming AH is not used ] > > If there is no data origin authentication, one may build or alter a packet with a correct sequence number which will bypass the anti-replay service. This service is useless in such a case. > > Building a new packet is eased by the lack of authentication. > Alter a packet is eased by the improper use of integrity without authentication. > > Thus authentication is necessary for anti-replay service. So manual keying as well as using ESP without authentication are prone to replay attack. and there are no safe and easy mechanisms to protect them. Am I right? > > -- > Jean-Jacques Puig > > "There is a Chinese proverb for all situations" > -- Chinese proverb -- From owner-ipsec@lists.tislabs.com Fri Feb 22 06:58:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MEw8302695; Fri, 22 Feb 2002 06:58:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17994 Fri, 22 Feb 2002 09:00:45 -0500 (EST) Date: Fri, 22 Feb 2002 15:11:25 +0100 (MET) Message-Id: <200202221411.PAA12285@hugo.int-evry.fr> From: Jean-Jacques Puig To: "Lokesh" Cc: ipsec@lists.tislabs.com Subject: Re: questions on Anti Replay Check In-Reply-To: <002101c1bb99$1d28fb60$ae0510ac@roc.com> References: <002b01c1bb67$e3b80c80$ae0510ac@roc.com> <200202220900.KAA10074@hugo.int-evry.fr> <002101c1bb99$1d28fb60$ae0510ac@roc.com> Organization: Département Logiciels - Réseaux X-Mailer: Sylpheed version 0.6.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Lokesh" wrote: > Thanks , > please see questions inlined. > -Lokesh > ----- Original Message ----- > From: Jean-Jacques Puig > To: Lokesh > Cc: > Sent: Friday, February 22, 2002 2:30 PM > Subject: Re: questions on Anti Replay Check > > > > Hi ! > > > > Lokesh wrote: > > > > > My understanding of replay attack is a hacker can get hold of a > legitimate packet > > > in the traffic and transmit it to recevier after a while, this can cause > confusion or > > > have some undesirable consequences at the receiving end. right? > > > > Right. Depending on the protocol, one can also cause troubles replaying > the packet to another receveir, or even to the original sender. > > > > Troubles to original sender? how? ones like sender getting two ACKs for one > packet sent? Are you talking about TCP's ACK ? Replaying would be difficult on connection oriented protocols (with real ACKs), like TCP, since the connection state evolves and the sequence number changes. Out of connection oriented protocols, the "acks" may contain data, or even authenticated data, and the original sender may act on the knowledge of these data. But, it works also out of the "ack" context, with multirecipients: Imagine a network game running on a lan using udp with multicast or broadcast. In this game, characters are A, B, C... and move in a plane. A sends an authenticated message to group/broadcast: "A is at (X,Y)". Messages have no anti-replay window; M (Martin ;-) keeps this message. A is about to kill M at (X2,Y2); Martin replays the message "A is at (X,Y)", and A appears at X,Y because computer will believe A sent the message. At (X,Y), B (M's fellow) was waiting for him with the RPG. Note that every computer will believe the replayed message, and may be A's computer also. > > > Usually Antireplay check is not done for IPsec SA's of manual key > management. > > > why? > > > > Usually, manual keying sets directly the secrets of the SA. The > anti-replay window will cycle after many exchanges, and SA's adminitrator > may not bother about manually rekeying again and again. Thus, LEGAL packets, > with the same caracteristics (SPI...) and sequence numbers of ones of the > previous cycle will be sent. For a manual-keyed SA to last for many cycles, > antireplay check must be disabled, or cycling packets are likely to be > dropped. > > > > >Like any other secure traffic, traffic carried such SA too can be hacked > by > > > replay attack right? > > > > Yes. > > May be an easy way to solve this situation would be to manually set a key > seed for the SA, and the key material would be automatically derived from > that key on both sides in order to refresh SA's secrets when anti-replay > window is about to cycle. But there are hazards of loss of key > synchronization beetween hosts. > > > > > ESP RFC 2406 says: > > > > > > The anti- replay service may be selected only if data origin > authentication is > > > selected, and its election is solely at the discretion of the > receiver. > > > > > > Why only if data origin authentication is selcted? esp trafiic without > authentication > > > can't come under replay attack?[ assuming AH is not used ] > > > > If there is no data origin authentication, one may build or alter a packet > with a correct sequence number which will bypass the anti-replay service. > This service is useless in such a case. > > > > Building a new packet is eased by the lack of authentication. > > Alter a packet is eased by the improper use of integrity without > authentication. > > > > Thus authentication is necessary for anti-replay service. > > So manual keying as well as using ESP without authentication are > prone to replay attack. > and there are no safe and easy mechanisms to protect them. Am I right? IMHO, yes; but I am not an IPsec expert. In correct order: /Anti-replay is of no use without authentication (the attacker will alter the sequence number to get through the window) |_Even with authentication, manual keying is vulnerable to replay attack. (Manual keying will be safe only if the replay window does not cycle.) I hope someone here will correct this if I am wrong. > > -- > > Jean-Jacques Puig > > > > "There is a Chinese proverb for all situations" > > -- Chinese proverb -- -- Jean-Jacques Puig "Don't care about Chinese proverbs" -- Irish proverb -- From owner-ipsec@lists.tislabs.com Fri Feb 22 19:27:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1N3RW322401; Fri, 22 Feb 2002 19:27:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19172 Fri, 22 Feb 2002 21:24:55 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3C95@NS-CA> From: Michael Choung Shieh To: ipsec@lists.tislabs.com Subject: info on new nat-t Date: Fri, 22 Feb 2002 18:33:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I heard about there is a new nat-traversal draft under development to address the issues of fragment and ipsec pass-through on NAT device. Does anyone know the status and progress? -------------------------------------------- Michael Shieh -------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Feb 22 20:44:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1N4im323748; Fri, 22 Feb 2002 20:44:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19284 Fri, 22 Feb 2002 23:04:37 -0500 (EST) From: "Jayant Shukla" To: "'Takaoka Takayoshi'" , Subject: RE: NAT Traversal Date: Fri, 22 Feb 2002 20:12:48 -0800 Message-ID: <000001c1bc20$5acc5340$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <119170422361D311B41900A0CC419794E0F0E9@white3.nvc.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, it is the same issue that causes several problems. IPsec pass-thru enabled routers monitor the cookie to route the IKE messages (they use cookies for IKE and SPI for IPsec messages). Putting 8 bytes of zero where the cookie should be creates problems for IPsec messages as they might be routed to the wrong host. In keep-alive messages there is nothing where the cookie should be and so they get dropped. Regards, Jayant > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Takaoka Takayoshi > Sent: Friday, February 22, 2002 1:43 AM > To: 'Jayant Shukla'; ipsec@lists.tislabs.com > Subject: RE: NAT Traversal > > That means, a certain router drop the IKE keep-alive packet, right? > I need more information for this issue. > > Best regards, > Taka > > -----Original Message----- > From: Jayant Shukla [mailto:jshukla@trlokom.com] > Sent: Friday, February 22, 2002 1:18 PM > To: ipsec@lists.tislabs.com > Subject: NAT Traversal > > > > The proposed NAT traversal method runs into problems with some routers > that > monitor the IKE cookies. What steps are being taken to overcome this > problem? > > Regards, > Jayant > > From owner-ipsec@lists.tislabs.com Fri Feb 22 23:02:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1N729326201; Fri, 22 Feb 2002 23:02:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA19557 Sat, 23 Feb 2002 01:10:41 -0500 (EST) From: "Jayant Shukla" To: "'Derek Atkins'" Cc: "'Takaoka Takayoshi'" , Subject: RE: NAT Traversal Date: Fri, 22 Feb 2002 22:18:46 -0800 Message-ID: <000001c1bc31$f361d920$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > How can such demon-spawn even use SPI for ESP/AH messages? The > SPI is encrypted within IKE and is not symmetric, so when the > NAT box receives a message for SPI X, how does it know where > to route it? > What demon-spawn?? That is the RSIP method and it is widely deployed. I think the following link should help you understand how it works. If you still don't get it, do feel free to ask questions. http://www.ietf.org/proceedings/99jul/slides/nat-rsip-99jul/sld011.htm > Boxes that do this are just plain broken and should be > completely nuked from orbit. > > -derek How did you figure that out? I don't think you would have said that if you understood the RSIP method. If anything should be called demon-spawn or broken, it is the NAT traversal draft. Moreover, after you have examined the NAT Traversal draft you might also notice several problems/drawbacks it has. Regards, Jayant > > "Jayant Shukla" writes: > > > Yes, it is the same issue that causes several problems. IPsec pass-thru > > enabled routers monitor the cookie to route the IKE messages (they use > > cookies for IKE and SPI for IPsec messages). > > > > Putting 8 bytes of zero where the cookie should be creates problems for > > IPsec messages as they might be routed to the wrong host. In keep-alive > > messages there is nothing where the cookie should be and so they get > > dropped. > > > > > > Regards, > > Jayant > > > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com] > > > On Behalf Of Takaoka Takayoshi > > > Sent: Friday, February 22, 2002 1:43 AM > > > To: 'Jayant Shukla'; ipsec@lists.tislabs.com > > > Subject: RE: NAT Traversal > > > > > > That means, a certain router drop the IKE keep-alive packet, right? > > > I need more information for this issue. > > > > > > Best regards, > > > Taka > > > > > > -----Original Message----- > > > From: Jayant Shukla [mailto:jshukla@trlokom.com] > > > Sent: Friday, February 22, 2002 1:18 PM > > > To: ipsec@lists.tislabs.com > > > Subject: NAT Traversal > > > > > > > > > > > > The proposed NAT traversal method runs into problems with some routers > > > that > > > monitor the IKE cookies. What steps are being taken to overcome this > > > problem? > > > > > > Regards, > > > Jayant > > > > > > > > > > > > > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Sat Feb 23 13:07:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1NL7u320386; Sat, 23 Feb 2002 13:07:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20636 Sat, 23 Feb 2002 15:10:33 -0500 (EST) From: "Jayant Shukla" To: "'Michael Choung Shieh'" , Subject: RE: info on new nat-t Date: Sat, 23 Feb 2002 12:18:45 -0800 Message-ID: <000001c1bca7$4ba5ec50$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3C95@NS-CA> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't know whose effort you are referring to, but we have a great solution that has not yet been publicized. It will be shown at Networld+Interop 2002 in Las Vegas. Regards, Jayant > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Michael Choung Shieh > Sent: Friday, February 22, 2002 6:34 PM > To: ipsec@lists.tislabs.com > Subject: info on new nat-t > > > I heard about there is a new nat-traversal draft under development to > address the issues of fragment and ipsec pass-through on NAT device. Does > anyone know the status and progress? > > -------------------------------------------- > Michael Shieh > -------------------------------------------- > > From owner-ipsec@lists.tislabs.com Sat Feb 23 14:57:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1NMvP322701; Sat, 23 Feb 2002 14:57:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20824 Sat, 23 Feb 2002 17:18:43 -0500 (EST) To: "Jayant Shukla" Cc: "'Michael Choung Shieh'" , Subject: Re: info on new nat-t References: <000001c1bca7$4ba5ec50$0100a8c0@trlhpc1> From: Derek Atkins Date: 23 Feb 2002 17:30:01 -0500 In-Reply-To: <000001c1bca7$4ba5ec50$0100a8c0@trlhpc1> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you are referring to your patent-pending solution, then that is a non-starter and is not interesting. -derek "Jayant Shukla" writes: > I don't know whose effort you are referring to, but we have a great > solution that has not yet been publicized. It will be shown at > Networld+Interop 2002 in Las Vegas. > > Regards, > Jayant > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > > On Behalf Of Michael Choung Shieh > > Sent: Friday, February 22, 2002 6:34 PM > > To: ipsec@lists.tislabs.com > > Subject: info on new nat-t > > > > > > I heard about there is a new nat-traversal draft under development to > > address the issues of fragment and ipsec pass-through on NAT device. > Does > > anyone know the status and progress? > > > > -------------------------------------------- > > Michael Shieh > > -------------------------------------------- > > > > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Sat Feb 23 20:09:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1O49K326811; Sat, 23 Feb 2002 20:09:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21209 Sat, 23 Feb 2002 22:11:55 -0500 (EST) From: "Jayant Shukla" To: "'Derek Atkins'" Cc: Subject: RE: info on new nat-t Date: Sat, 23 Feb 2002 19:20:04 -0800 Message-ID: <000001c1bce2$2756b830$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > If you are referring to your patent-pending solution, > then that is a non-starter and is not interesting. People who do work like to benefit from it, like it or not. I am sure you don't consult for free either. As far as interest is concerned, you will be surprised. I expect even more of it as people find the limitations of and problems with NAT-T. While our intention is to give away the related patent rights in _full_ to IETF soon, we do wish to benefit a bit from it. We will submit an ID later and discuss the release of IP at that time. BTW, you might recall the NAT-T authors also claimed patents rights early on and I don't recall you talking about IP issues then. In fact, thanks to us, they gave up their IP soon after we released our original draft. Also, you might want to read the SSH IP claim in case you think they have given up all claims on their IP. Regards, Jayant From owner-ipsec@lists.tislabs.com Sat Feb 23 20:10:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1O4Al326889; Sat, 23 Feb 2002 20:10:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21219 Sat, 23 Feb 2002 22:18:10 -0500 (EST) From: "Jayant Shukla" To: "'Derek Atkins'" Cc: Subject: RE: NAT Traversal Date: Sat, 23 Feb 2002 19:26:20 -0800 Message-ID: <000101c1bce3$0716d720$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Note that RSIP != NAT (per se). Since RSIP requires interaction > between the sending client and the translator gateway, I don't see a > problem with the NAT traversal drafts. If the client is RSIPsec > aware, then it does not need IPsec NAT traversal (because it knows > what the external address will be). So, what's the problem? If it's > using RSIP, it doesn't use NAT Traversal. It's sort of like if you're > using TCP on a socket, you can't use UDP on that socket. > > So, again, I don't see the problem. There are two protocols that > effectively do the same thing; you just cannot use them both at the > same time. However, the client KNOWS when it's using one of them so > it can make the choice about which one to use. > > -derek So you have concluded that there is NO problem? This is great, just a while ago you had no clue how the pass-thru worked and now you have concluded that there is no problem. Amazing! Regards, Jayant From owner-ipsec@lists.tislabs.com Sun Feb 24 20:02:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1P42D300744; Sun, 24 Feb 2002 20:02:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23411 Sun, 24 Feb 2002 21:58:40 -0500 (EST) Message-ID: <119170422361D311B41900A0CC419794E0F0F1@white3.nvc.co.jp> From: Takaoka Takayoshi To: IPsec Mailing List Subject: IPsec VPN v.s. MPLS VPN Date: Mon, 25 Feb 2002 12:21:05 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BDAB.769B6830" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C1BDAB.769B6830 Content-Type: text/plain; charset="iso-2022-jp" Hi, everyone! I want to discuss the superiority both type of VPN, IPsec and MPLS. Now our company run after the tech of VPN to provide the secure zone for all customer, and this classfication is as following I think; IPsec VPN -use the Internet for this infrastructure, don't be needed the additional capital investment, so this is match for the enterprise security solution. But there is no expectation to ensure the intelligent Traffic Engineering that MPLS VPN can do. MPLS VPN - use the closed network with the exclusive router, and this closed network is provided by the carrier, this complecated switching network can give us high performance and perfect ToS, and no need to encrypt the traffic data. Now I think, it's just my opinion, if the internet infrastructure become has a big pipe and high performance, of couse the investment for this owe to all of carrier, the intelligent traffic engineering is no use anymore and great through put can provide to anyone connecting to internet. That means, in the future, the intelligent ToS isn't neccesary, we don't need to care of the ToS, extremely I can say. That fact also means, the end security gateway only take care of high performance encryption & decryption, that based on ASIC. I wonder, there is some possibility in the future, all of client has exclusive ASIC for encryption for itself, and also the internet has security gateway routing protocol, this system can be swith the all of client request with IPsec. The client can connect to all of internet server or client using security tunnel that provided by VPN swith network which spreading all over the world! Anyway, now I want to change my question to you like that, "Do you think the MPLS tech can survive in the security solution?" Best regards, Taka $B"#(JNetwork Value Components, Ltd. $B!!!!(J|-Group$B!'(JSystem Engineering Group 2 $B!!!!!!!!(J|-Name$B!'(JTakayoshi Takaoka $B!!!!!!!!(J|-Mail$B!'(Jttakaoka@nvc.co.jp $B!!!!!!!!(J|-Phone$B!'(J0468-20-1800 $B!!!!!!!!(J|-FAX$B!'(J0468-25-8053 $B!!!!!!!!(J|-URL$B!'(Jhttp://www.nvc.co.jp ------_=_NextPart_001_01C1BDAB.769B6830 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable IPsec VPN v.s. MPLS VPN

Hi, everyone!

I want to discuss the = superiority both type of VPN, IPsec and MPLS.
Now our company run = after the tech of VPN to provide the secure zone for all customer, and = this classfication is as following I think;

IPsec VPN -use the = Internet for this infrastructure, don't be needed the additional = capital investment, so this is match for the enterprise security = solution. But there is no expectation to ensure the intelligent Traffic = Engineering that MPLS VPN can do.

MPLS VPN - use the = closed network with the exclusive router, and this closed network is = provided by the carrier, this complecated switching network can give us = high performance and perfect ToS, and no need to encrypt the traffic = data.

Now I think, it's just = my opinion, if the internet infrastructure become has a big pipe and = high performance, of couse the investment for this owe to all of = carrier, the intelligent traffic engineering is no use anymore and = great through put can provide to anyone connecting to internet. That = means, in the future, the intelligent ToS isn't neccesary, we don't = need to care of the ToS, extremely I can say.

That fact also means, = the end security gateway only take care of high performance encryption = & decryption, that based on ASIC.

I wonder, there is some = possibility in the future, all of client has exclusive ASIC for = encryption for itself, and also the internet has security gateway = routing protocol, this system can be swith the all of client request = with IPsec. The client can connect to all of internet server or client = using security tunnel that provided by VPN swith network which = spreading all over the world!

Anyway, now I want to = change my question to you like that,

"Do you think the = MPLS tech can survive in the security solution?"


Best regards,
Taka
 

=1B$B"#=1B(JNetwork Value Components, Ltd.
=1B$B!!!!=1B(J|-Group=1B$B!'=1B(JSystem Engineering Group 2
=1B$B!!!!!!!!=1B(J|-Name=1B$B!'=1B(JTakayoshi Takaoka
=1B$B!!!!!!!!=1B(J|-Mail=1B$B!'=1B(Jttakaoka@nvc.co.jp
=1B$B!!!!!!!!=1B(J|-Phone=1B$B!'=1B(J0468-20-1800
=1B$B!!!!!!!!=1B(J|-FAX=1B$B!'=1B(J0468-25-8053
=1B$B!!!!!!!!=1B(J|-URL=1B$B!'=1B(Jhttp://www.nvc.co.jp



------_=_NextPart_001_01C1BDAB.769B6830-- From owner-ipsec@lists.tislabs.com Mon Feb 25 01:57:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1P9vK303289; Mon, 25 Feb 2002 01:57:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24127 Mon, 25 Feb 2002 03:55:57 -0500 (EST) From: "Christian Fanzen" To: , Cc: Subject: RE: Phase 1 Lifetime and Lifedata Date: Mon, 25 Feb 2002 10:07:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <496A8683261CD211BF6C0008C733261A018EADBD@email.quarrytech.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, theory and praxis are allways different. In this case lifedata is defined by the IKE RFC, the theoretical part. But in practice for most vendors (Cisco, Checkpoint, Raptor, Win2K) the lifedata value MUST be set to zero! Otherwise the negotiation fails. In my opinion this configuration-data-field should be diasabled in order to not insecure users and admins. Christian > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of dfox@quarrytech.com > Sent: Freitag, 22. Februar 2002 00:32 > To: ewilkinson@efficient.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Phase 1 Lifetime and Lifedata > > > In the last couple of implementations, that I was involved with > testing, we > didn't use Lifedata in Phase 1. The reason for this is that the ISAKMP > communications are so small that it didn't make sense. If it was sent to > us, we dealt with it appropriately. We always used Lifetime, however. > > David > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > David Fox > Quarry Technologies dfox@quarrytech.com > 8 New England Executive Park Direct: 781-359-5094 > Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 > www.quarrytech.com FAX: 781-505-8316 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > -----Original Message----- > From: Edward Wilkinson [mailto:ewilkinson@efficient.com] > Sent: Thursday, February 21, 2002 5:31 PM > To: Ipsec (E-mail) > Subject: Phase 1 Lifetime and Lifedata > > When using some of the gateways and clients, I see an option to set > lifedata.. Is this filed valid in phase 1 and if it is how would it be > used. > From owner-ipsec@lists.tislabs.com Mon Feb 25 06:28:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PES3319584; Mon, 25 Feb 2002 06:28:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24821 Mon, 25 Feb 2002 08:41:45 -0500 (EST) To: "Jayant Shukla" Cc: "'Takaoka Takayoshi'" , From: "'Derek Atkins'" Subject: Re: NAT Traversal References: <000001c1bc31$f361d920$0100a8c0@trlhpc1> Date: 23 Feb 2002 11:06:49 -0500 In-Reply-To: <000001c1bc31$f361d920$0100a8c0@trlhpc1> Message-ID: Lines: 117 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that RSIP != NAT (per se). Since RSIP requires interaction between the sending client and the translator gateway, I don't see a problem with the NAT traversal drafts. If the client is RSIPsec aware, then it does not need IPsec NAT traversal (because it knows what the external address will be). So, what's the problem? If it's using RSIP, it doesn't use NAT Traversal. It's sort of like if you're using TCP on a socket, you can't use UDP on that socket. So, again, I don't see the problem. There are two protocols that effectively do the same thing; you just cannot use them both at the same time. However, the client KNOWS when it's using one of them so it can make the choice about which one to use. -derek "Jayant Shukla" writes: > > > > How can such demon-spawn even use SPI for ESP/AH messages? The > > SPI is encrypted within IKE and is not symmetric, so when the > > NAT box receives a message for SPI X, how does it know where > > to route it? > > > > What demon-spawn?? That is the RSIP method and it is widely deployed. > I think the following link should help you understand how it works. If > you still don't get it, do feel free to ask questions. > > http://www.ietf.org/proceedings/99jul/slides/nat-rsip-99jul/sld011.htm > > > > Boxes that do this are just plain broken and should be > > completely nuked from orbit. > > > > -derek > > How did you figure that out? I don't think you would have said that if > you understood the RSIP method. If anything should be called demon-spawn > or broken, it is the NAT traversal draft. Moreover, after you have > examined the NAT Traversal draft you might also notice several > problems/drawbacks it has. > > > Regards, > Jayant > > > > > "Jayant Shukla" writes: > > > > > Yes, it is the same issue that causes several problems. IPsec > pass-thru > > > enabled routers monitor the cookie to route the IKE messages (they > use > > > cookies for IKE and SPI for IPsec messages). > > > > > > Putting 8 bytes of zero where the cookie should be creates problems > for > > > IPsec messages as they might be routed to the wrong host. In > keep-alive > > > messages there is nothing where the cookie should be and so they get > > > dropped. > > > > > > > > > Regards, > > > Jayant > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com] > > > > On Behalf Of Takaoka Takayoshi > > > > Sent: Friday, February 22, 2002 1:43 AM > > > > To: 'Jayant Shukla'; ipsec@lists.tislabs.com > > > > Subject: RE: NAT Traversal > > > > > > > > That means, a certain router drop the IKE keep-alive packet, > right? > > > > I need more information for this issue. > > > > > > > > Best regards, > > > > Taka > > > > > > > > -----Original Message----- > > > > From: Jayant Shukla [mailto:jshukla@trlokom.com] > > > > Sent: Friday, February 22, 2002 1:18 PM > > > > To: ipsec@lists.tislabs.com > > > > Subject: NAT Traversal > > > > > > > > > > > > > > > > The proposed NAT traversal method runs into problems with some > routers > > > > that > > > > monitor the IKE cookies. What steps are being taken to overcome > this > > > > problem? > > > > > > > > Regards, > > > > Jayant > > > > > > > > > > > > > > > > > > > > > -- > > Derek Atkins > > Computer and Internet Security Consultant > > derek@ihtfp.com www.ihtfp.com > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 25 06:28:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PES7319598; Mon, 25 Feb 2002 06:28:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24831 Mon, 25 Feb 2002 08:42:40 -0500 (EST) To: "Jayant Shukla" Cc: From: Derek Atkins Subject: Re: NAT Traversal References: <000101c1bce3$0716d720$0100a8c0@trlhpc1> Date: 23 Feb 2002 23:11:41 -0500 In-Reply-To: <000101c1bce3$0716d720$0100a8c0@trlhpc1> Message-ID: Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Jayant Shukla" writes: > > Note that RSIP != NAT (per se). Since RSIP requires interaction > > between the sending client and the translator gateway, I don't see a > > problem with the NAT traversal drafts. If the client is RSIPsec > > aware, then it does not need IPsec NAT traversal (because it knows > > what the external address will be). So, what's the problem? If it's > > using RSIP, it doesn't use NAT Traversal. It's sort of like if you're > > using TCP on a socket, you can't use UDP on that socket. > > > > So, again, I don't see the problem. There are two protocols that > > effectively do the same thing; you just cannot use them both at the > > same time. However, the client KNOWS when it's using one of them so > > it can make the choice about which one to use. > > > > -derek > > So you have concluded that there is NO problem? This is great, just a > while ago you had no clue how the pass-thru worked and now you have > concluded that there is no problem. Amazing! Note that I started with RSIP != NAT. I still maintain this. RSIP requires client interaction with the gateway (RSIP server) for it to work. Sure, you can base a multiplexing on the SPI if the client is going to tell it to the gateway. But that is __NOT__ a NAT. NAT boxes imply a box that just munges packets. My point is that what you are complaining about, NAT-T v. RSIP, isn't an issue, because the client would know not to use NAT-T if they are using RSIP. Considering the client needs to be aware of (and involved in) the RSIP negotiation, they can easily not perform the NAT-T negotiation, too. > Regards, > Jayant -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 25 06:28:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PES9319612; Mon, 25 Feb 2002 06:28:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24820 Mon, 25 Feb 2002 08:41:40 -0500 (EST) To: "Jayant Shukla" Cc: "'Takaoka Takayoshi'" , From: Derek Atkins Subject: Re: NAT Traversal References: <000001c1bc20$5acc5340$0100a8c0@trlhpc1> Date: 23 Feb 2002 00:28:08 -0500 In-Reply-To: <000001c1bc20$5acc5340$0100a8c0@trlhpc1> Message-ID: Lines: 66 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How can such demon-spawn even use SPI for ESP/AH messages? The SPI is encrypted within IKE and is not symmetric, so when the NAT box receives a message for SPI X, how does it know where to route it? Boxes that do this are just plain broken and should be completely nuked from orbit. -derek "Jayant Shukla" writes: > Yes, it is the same issue that causes several problems. IPsec pass-thru > enabled routers monitor the cookie to route the IKE messages (they use > cookies for IKE and SPI for IPsec messages). > > Putting 8 bytes of zero where the cookie should be creates problems for > IPsec messages as they might be routed to the wrong host. In keep-alive > messages there is nothing where the cookie should be and so they get > dropped. > > > Regards, > Jayant > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > > On Behalf Of Takaoka Takayoshi > > Sent: Friday, February 22, 2002 1:43 AM > > To: 'Jayant Shukla'; ipsec@lists.tislabs.com > > Subject: RE: NAT Traversal > > > > That means, a certain router drop the IKE keep-alive packet, right? > > I need more information for this issue. > > > > Best regards, > > Taka > > > > -----Original Message----- > > From: Jayant Shukla [mailto:jshukla@trlokom.com] > > Sent: Friday, February 22, 2002 1:18 PM > > To: ipsec@lists.tislabs.com > > Subject: NAT Traversal > > > > > > > > The proposed NAT traversal method runs into problems with some routers > > that > > monitor the IKE cookies. What steps are being taken to overcome this > > problem? > > > > Regards, > > Jayant > > > > > > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 25 06:40:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PEef320193; Mon, 25 Feb 2002 06:40:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24924 Mon, 25 Feb 2002 09:05:04 -0500 (EST) Message-Id: <5.1.0.14.2.20020225151326.00bda828@144.254.15.68> X-Sender: fmajstor@brussels.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 15:15:15 +0100 To: Takaoka Takayoshi From: Franjo Majstor Subject: Re: IPsec VPN v.s. MPLS VPN Cc: IPsec Mailing List In-Reply-To: <119170422361D311B41900A0CC419794E0F0F1@white3.nvc.co.jp> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11756324==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_11756324==_.ALT Content-Type: text/plain; charset="us-ascii" This might help you for start... http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-01.txt Franjo At 04:21 2/25/2002, Takaoka Takayoshi wrote: >Hi, everyone! > >I want to discuss the superiority both type of VPN, IPsec and MPLS. >Now our company run after the tech of VPN to provide the secure zone for all customer, and this classfication is as following I think; > >IPsec VPN -use the Internet for this infrastructure, don't be needed the additional capital investment, so this is match for the enterprise security solution. But there is no expectation to ensure the intelligent Traffic Engineering that MPLS VPN can do. > >MPLS VPN - use the closed network with the exclusive router, and this closed network is provided by the carrier, this complecated switching network can give us high performance and perfect ToS, and no need to encrypt the traffic data. > >Now I think, it's just my opinion, if the internet infrastructure become has a big pipe and high performance, of couse the investment for this owe to all of carrier, the intelligent traffic engineering is no use anymore and great through put can provide to anyone connecting to internet. That means, in the future, the intelligent ToS isn't neccesary, we don't need to care of the ToS, extremely I can say. > >That fact also means, the end security gateway only take care of high performance encryption & decryption, that based on ASIC. > >I wonder, there is some possibility in the future, all of client has exclusive ASIC for encryption for itself, and also the internet has security gateway routing protocol, this system can be swith the all of client request with IPsec. The client can connect to all of internet server or client using security tunnel that provided by VPN swith network which spreading all over the world! > >Anyway, now I want to change my question to you like that, > >"Do you think the MPLS tech can survive in the security solution?" > >Best regards, >Taka > > >Network Value Components, Ltd. >GroupSystemNameTakayoshiMailttakaoka@nvc.co.jp >Phone0468-20-1800 >FAX0468-25-8053 >URLhttp://www.nvc.co.jp > ............................................................................................................. Franjo Majstor CCIE #1507 Access,Security EMEA Consulting Engineer CISSP Phone : +32-2-778.4395 Fax : +32-2-778.4300 Mobile: +32-475-36.3202 PGP Key: available on request Cisco Systems, Av. Marcel Thiry 77,1200 Brussels, Belgium _______________________________________________ --=====================_11756324==_.ALT Content-Type: text/html; charset="us-ascii" This might help you for start...

http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-01.txt

Franjo


At 04:21 2/25/2002, Takaoka Takayoshi wrote:

Hi, everyone!

I want to discuss the superiority both type of VPN, IPsec and MPLS.
Now our company run after the tech of VPN to provide the secure zone for all customer, and this classfication is as following I think;

IPsec VPN -use the Internet for this infrastructure, don't be needed the additional capital investment, so this is match for the enterprise security solution. But there is no expectation to ensure the intelligent Traffic Engineering that MPLS VPN can do.

MPLS VPN - use the closed network with the exclusive router, and this closed network is provided by the carrier, this complecated switching network can give us high performance and perfect ToS, and no need to encrypt the traffic data.

Now I think, it's just my opinion, if the internet infrastructure become has a big pipe and high performance, of couse the investment for this owe to all of carrier, the intelligent traffic engineering is no use anymore and great through put can provide to anyone connecting to internet. That means, in the future, the intelligent ToS isn't neccesary, we don't need to care of the ToS, extremely I can say.

That fact also means, the end security gateway only take care of high performance encryption & decryption, that based on ASIC.

I wonder, there is some possibility in the future, all of client has exclusive ASIC for encryption for itself, and also the internet has security gateway routing protocol, this system can be swith the all of client request with IPsec. The client can connect to all of internet server or client using security tunnel that provided by VPN swith network which spreading all over the world!

Anyway, now I want to change my question to you like that,

"Do you think the MPLS tech can survive in the security solution?"

Best regards,
Taka
 

Network Value Components, Ltd.
GroupSystemNameTakayoshiMailttakaoka@nvc.co.jp
Phone0468-20-1800
FAX0468-25-8053
URLhttp://www.nvc.co.jp

.............................................................................................................
Franjo Majstor                              CCIE #1507 Access,Security                                              
EMEA Consulting Engineer       CISSP

Phone : +32-2-778.4395         Fax : +32-2-778.4300                  
Mobile:  +32-475-36.3202       PGP Key: available on request
Cisco Systems, Av. Marcel Thiry 77,1200 Brussels, Belgium
_______________________________________________





 --=====================_11756324==_.ALT-- From owner-ipsec@lists.tislabs.com Mon Feb 25 07:08:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PF8U323226; Mon, 25 Feb 2002 07:08:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25026 Mon, 25 Feb 2002 09:30:00 -0500 (EST) From: juha.ollila@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: Length of pre-shared key MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 25 Feb 2002 16:41:20 +0200 Message-ID: Thread-Topic: Length of pre-shared key Thread-Index: AcG+Cn1dED63lvw4QYqCKfdiiVsN1Q== To: X-OriginalArrivalTime: 25 Feb 2002 14:41:21.0273 (UTC) FILETIME=[7DCEA690:01C1BE0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA25021 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello! Have IPsec and IKE specifications any requirements about the pre-shared keys? I didn't find the required length of pre-shared key. Best Regards, Juha Ollila From owner-ipsec@lists.tislabs.com Mon Feb 25 08:48:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PGmG301106; Mon, 25 Feb 2002 08:48:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25267 Mon, 25 Feb 2002 11:01:20 -0500 (EST) From: James Tiller Reply-To: James Tiller To: juha.ollila@nokia.com Cc: ipsec@lists.tislabs.com Date: Mon, 25 Feb 2002 11:08:27 -0500 X-Mailer: The Bat! (v1.53d) Organization: Lucent Technolgies X-Priority: 3 (Normal) Message-ID: <1312550977.20020225110827@lucent.com> Subject: Re: Length of pre-shared key In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Juha - I'm going out on a limb here... but technically there is no limit since the key is only used locally in the creation of the SKEYID. The real limit is in the PRF inputs, i.e. SKEYID = prf(pre-shared-key, Ni_b | Nr_b) Seeing that the Nonce can be between 8 and 256 bytes, it *could* be logically surmised that the shared secret would have the same consideration based on the PRF - but this depends on the process implemented and supported. Just my $0.02 ------------- Best regards, Jim Tiller, CISSP Global Security Product Manager Lucent Worldwide Services -- tiller@lucent.com 10:58 AM - 2/25/2002 Monday, February 25, 2002, 9:41:20 AM, juha wrote: ollila> Hello! ollila> Have IPsec and IKE specifications any requirements about the pre-shared keys? I didn't find the required length of pre-shared key. ollila> Best Regards, ollila> Juha Ollila From owner-ipsec@lists.tislabs.com Mon Feb 25 08:50:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PGof301483; Mon, 25 Feb 2002 08:50:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25274 Mon, 25 Feb 2002 11:02:06 -0500 (EST) From: "Jayant Shukla" To: "'Derek Atkins'" Cc: Subject: RE: NAT Traversal Date: Mon, 25 Feb 2002 08:10:11 -0800 Message-ID: <000501c1be16$e7131530$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > My point is that what you are complaining about, NAT-T v. RSIP, isn't > an issue, How do you know it's not an issue? Read the minutes of SLC meeting first. > because the client would know not to use NAT-T if they are > using RSIP. Considering the client needs to be aware of (and involved > in) the RSIP negotiation, they can easily not perform the NAT-T > negotiation, too. > > > -derek > What makes you think the client is involved? IPsec pass-thru implemented in most low end NAT boxes is not complete RSIP as that would require modifications to client and the gateway. The simplification is that the client and gateway do not have to agree upon the cookie or SPI value. With this simplification the client has to do nothing about NAT traversal. There can be a problem (although unlikely) if two clients try to connect to the same domain. That is the reason manufacturers say these boxes support multiple client pass-thru sessions, but only one VPN session per VPN tunnel "terminator". So the client cannot just choose to use IPsec pass-thru or NAT-T. If you have one of these IPsec pass-thru routers, you have problem with NAT-T. Regards, Jayant From owner-ipsec@lists.tislabs.com Mon Feb 25 09:10:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PHAw303028; Mon, 25 Feb 2002 09:10:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25351 Mon, 25 Feb 2002 11:24:56 -0500 (EST) To: "Jayant Shukla" Cc: From: "Derek Atkins" Subject: Re: NAT Traversal References: <000501c1be16$e7131530$0100a8c0@trlhpc1> Date: 25 Feb 2002 11:36:15 -0500 In-Reply-To: <000501c1be16$e7131530$0100a8c0@trlhpc1> Message-ID: Lines: 61 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Jayant Shukla" writes: > > because the client would know not to use NAT-T if they are > > using RSIP. Considering the client needs to be aware of (and involved > > in) the RSIP negotiation, they can easily not perform the NAT-T > > negotiation, too. > > > > > > -derek > > > > > What makes you think the client is involved? IPsec pass-thru implemented > in most low end NAT boxes is not complete RSIP as that would require > modifications to client and the gateway. See what I said before about demon-spawn!!! NAT traversal via IPsec pass-thru[sic] is just plain wrong, broken, and lots of other words that I don't want to use in mixed company. > The simplification is that the client and gateway do not have to agree > upon the cookie or SPI value. With this simplification the client has to > do nothing about NAT traversal. There can be a problem (although > unlikely) if two clients try to connect to the same domain. That is the > reason manufacturers say these boxes support multiple client pass-thru > sessions, but only one VPN session per VPN tunnel "terminator". Well, this is the problem, now, isn't it. These boxes are trying to be half-RSIP, and in the process of being half-RSIP are broken. If the NAT box worked as a real NAT box (instead of trying to do something 'special') than NAT-T would work fine. If these boxes were full RSIP, then they would work fine, too. Clearly these boxes are broken in more ways than one. Should we really be spending our time trying to get protocols to work with all of these broken boxes? If so, then what if jane random company comes up with yet another broken way of doing things -- should we bend over backwards to support her, too? When does this maddness end? > So the client cannot just choose to use IPsec pass-thru or NAT-T. If you > have one of these IPsec pass-thru routers, you have problem with NAT-T. No, the client should rip IPsec pass-thru boxes out of the network and throw them in the garbage, where they belong. The easy alternative is to move IKE + NAT-T to a second UDP port. > Regards, > Jayant -derek PS: Can I repeat my mantra? NAT is the spawn of the devil and should be eradicated from the face of the planet. If necessary, we should nuke it from orbit -- it's the only way to be sure! -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Feb 25 09:39:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PHda303755; Mon, 25 Feb 2002 09:39:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25514 Mon, 25 Feb 2002 11:56:57 -0500 (EST) Message-Id: <200202251706.g1PH6Xr00398@fatty.lounge.org> To: juha.ollila@nokia.com Cc: ipsec@lists.tislabs.com Subject: Re: Length of pre-shared key In-Reply-To: Your message of "Mon, 25 Feb 2002 16:41:20 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <395.1014656793.1@tibernian.com> Date: Mon, 25 Feb 2002 09:06:33 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IKE uses the pre-shared key as the key to an HMAC. RFC2104 specifies that the key to an HMAC should not be less than the output of the under- lying hash function. So if you're using HMAC-SHA that's 20 bytes. Dan. On Mon, 25 Feb 2002 16:41:20 +0200 you wrote > Hello! > > Have IPsec and IKE specifications any requirements about the pre-shared keys? > I didn't find the required length of pre-shared key. > > Best Regards, > Juha Ollila From owner-ipsec@lists.tislabs.com Mon Feb 25 10:36:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PIaf305318; Mon, 25 Feb 2002 10:36:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25689 Mon, 25 Feb 2002 12:46:32 -0500 (EST) X-Envelope-Sender-Is: ewilkinson@efficient.com (at relayer ns1.sbs.siemens.com) Message-ID: <36C2EB69D2F9D411A9AB00D0B7200334F81591@eniwest.inside.efficient.com> From: Edward Wilkinson To: "'Christian Fanzen'" , dfox@quarrytech.com Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Lifetime and Lifedata Date: Mon, 25 Feb 2002 09:51:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, I have not encountered the Raptor yet, could you provide some additional information on that product. A search of the web finds lots of birds. Ed -----Original Message----- From: Christian Fanzen [mailto:cfranzenml@atsec.com] Sent: Monday, February 25, 2002 1:08 AM To: dfox@quarrytech.com; ewilkinson@efficient.com Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 Lifetime and Lifedata Hi, theory and praxis are allways different. In this case lifedata is defined by the IKE RFC, the theoretical part. But in practice for most vendors (Cisco, Checkpoint, Raptor, Win2K) the lifedata value MUST be set to zero! Otherwise the negotiation fails. In my opinion this configuration-data-field should be diasabled in order to not insecure users and admins. Christian > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of dfox@quarrytech.com > Sent: Freitag, 22. Februar 2002 00:32 > To: ewilkinson@efficient.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Phase 1 Lifetime and Lifedata > > > In the last couple of implementations, that I was involved with > testing, we > didn't use Lifedata in Phase 1. The reason for this is that the ISAKMP > communications are so small that it didn't make sense. If it was sent to > us, we dealt with it appropriately. We always used Lifetime, however. > > David > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > David Fox > Quarry Technologies dfox@quarrytech.com > 8 New England Executive Park Direct: 781-359-5094 > Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 > www.quarrytech.com FAX: 781-505-8316 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > -----Original Message----- > From: Edward Wilkinson [mailto:ewilkinson@efficient.com] > Sent: Thursday, February 21, 2002 5:31 PM > To: Ipsec (E-mail) > Subject: Phase 1 Lifetime and Lifedata > > When using some of the gateways and clients, I see an option to set > lifedata.. Is this filed valid in phase 1 and if it is how would it be > used. > From owner-ipsec@lists.tislabs.com Mon Feb 25 11:56:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PJuM307198; Mon, 25 Feb 2002 11:56:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26026 Mon, 25 Feb 2002 14:14:19 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: , Subject: RE: Length of pre-shared key Date: Mon, 25 Feb 2002 14:17:35 -0500 Message-ID: <003301c1be31$163ff610$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think there is a specific limit. After all, HMAC tells you how to stretch the input if it is less that the size of the hash output. But use your common sense: the shorter the input, the easier it will be for a cracking program to guess it. Also, it's the entropy in the password, not the length, that matters. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > juha.ollila@nokia.com > Sent: Monday, February 25, 2002 9:41 AM > To: ipsec@lists.tislabs.com > Subject: Length of pre-shared key > > > Hello! > > Have IPsec and IKE specifications any requirements about the > pre-shared keys? I didn't find the required length of pre-shared key. > > Best Regards, > Juha Ollila > From owner-ipsec@lists.tislabs.com Mon Feb 25 12:09:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PK9h307680; Mon, 25 Feb 2002 12:09:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26093 Mon, 25 Feb 2002 14:33:24 -0500 (EST) Date: Mon, 25 Feb 2002 11:43:45 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: Jayant Shukla , Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 25 Feb 2002, Derek Atkins wrote: > "Jayant Shukla" writes: > > > > What makes you think the client is involved? IPsec pass-thru implemented > > in most low end NAT boxes is not complete RSIP as that would require > > modifications to client and the gateway. > > See what I said before about demon-spawn!!! NAT traversal via IPsec > pass-thru[sic] is just plain wrong, broken, and lots of other words > that I don't want to use in mixed company. > NAT translates all protocols in a transparent manner using some protocol parameters, Eg. ports in case of UDP and TCP. I don't see why we should not try and apply a similar model to IPsec, using cookies and SPIs. Sure the SPIs are encrypted during IKE negotiation and the NAT box cannot see which SPIs are a pair. But if we somehow relate one SPI to another in each pair, the NAT box can translate ESP traffic with a high probability of success. Well, it's not pretty, but that is the inherent nature of NAT itself. chinna From owner-ipsec@lists.tislabs.com Mon Feb 25 14:12:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMCM311288; Mon, 25 Feb 2002 14:12:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26589 Mon, 25 Feb 2002 16:30:56 -0500 (EST) Message-Id: <5.1.0.14.0.20020225211127.04aba9c0@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 21:49:21 -0500 To: From: David Jablon Subject: RE: Length of pre-shared key Cc: , In-Reply-To: <003301c1be31$163ff610$1e72788a@ca.alcatel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't see anywhere that RFC 2104 says anything about "stretch"ing a short input key into a longer one. What it does is to hash (squeeze?) a key that's longer than 64 bytes into a hash block. Also, one should not confuse a password with a key in this context. At 02:17 PM 2/25/02 -0500, Andrew Krywaniuk wrote: >I don't think there is a specific limit. After all, HMAC tells you how to >stretch the input if it is less that the size of the hash output. But use >your common sense: the shorter the input, the easier it will be for a >cracking program to guess it. Also, it's the entropy in the password, not >the length, that matters. From owner-ipsec@lists.tislabs.com Mon Feb 25 14:26:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMQf311703; Mon, 25 Feb 2002 14:26:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26619 Mon, 25 Feb 2002 16:52:27 -0500 (EST) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'David Jablon'" , "Andrew Krywaniuk" Cc: , Subject: RE: Length of pre-shared key Date: Mon, 25 Feb 2002 16:56:59 -0500 Message-ID: <000e01c1be47$5ab7e080$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020225211127.04aba9c0@pop.theworld.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (1) append zeros to the end of K to create a B byte string (e.g., if K is of length 20 bytes and B=64, then K will be appended with 44 zero bytes 0x00) It's not a very fancy stretching technique, and admittedly unrelated to the length of the hash output (I meant to say block size). Sorry about using the word password instead of key. It's just that I speak binary. :-) Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: David Jablon [mailto:dpj@world.std.com] > Sent: Monday, February 25, 2002 9:49 PM > To: andrew.krywaniuk@alcatel.com > Cc: juha.ollila@nokia.com; ipsec@lists.tislabs.com > Subject: RE: Length of pre-shared key > > > I don't see anywhere that RFC 2104 says anything about "stretch"ing > a short input key into a longer one. What it does is to hash > (squeeze?) > a key that's longer than 64 bytes into a hash block. > > Also, one should not confuse a password with a key in this context. > > At 02:17 PM 2/25/02 -0500, Andrew Krywaniuk wrote: > >I don't think there is a specific limit. After all, HMAC > tells you how to > >stretch the input if it is less that the size of the hash > output. But use > >your common sense: the shorter the input, the easier it will be for a > >cracking program to guess it. Also, it's the entropy in the > password, not > >the length, that matters. > > > From owner-ipsec@lists.tislabs.com Mon Feb 25 14:28:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMSF311762; Mon, 25 Feb 2002 14:28:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26634 Mon, 25 Feb 2002 16:53:19 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869979@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , Jayant Shukla Cc: ipsec@lists.tislabs.com Subject: RE: NAT Traversal Date: Mon, 25 Feb 2002 14:05:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BE48.85C3D0D0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_000_01C1BE48.85C3D0D0 Content-Type: text/plain; charset="iso-8859-1" > PS: Can I repeat my mantra? NAT is the spawn of the devil and should > be eradicated from the face of the planet. If necessary, we should > nuke it from orbit -- it's the only way to be sure! You can repeat it as long as you like, just recognise that the need for NAT arose in part from design decisions the IETF itself screwed up and that an Internet protocol, particularly a security protocol has no business being deployed if it can't cope with NAT. Like it or not, NAT is part of the infrastructure we have to deal with in the real world. It is as much a part of the Internet as sendmail or any of the other junk that is out there. On the other hand I don't see any reason that ESP mode needs to work with NAT, but then again I never saw a need for ESP. I think it is important that a solution is decided upon quickly however. Otherwise the number of ad-hoc fixes that grow up to fix the NAT problem will grow exponentially and with it the number of additional targets that Derek will be lobbying to add to the axis of evil. The problem with NAT suggests to me that their authentication role was not properly understood in IPSEC. I have never seen an internet service advertised by IP address (except for the A root). Ergo it is not a primary authentication point. The IP address is sometimes a secondary authentication mechanism and should be validated as part of the process of establishing an SA. Phill ------_=_NextPart_000_01C1BE48.85C3D0D0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BE48.85C3D0D0-- From owner-ipsec@lists.tislabs.com Mon Feb 25 16:14:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q0Ep314054; Mon, 25 Feb 2002 16:14:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26944 Mon, 25 Feb 2002 18:29:41 -0500 (EST) Message-Id: <200202252339.g1PNd6r03363@fatty.lounge.org> To: andrew.krywaniuk@alcatel.com Cc: "'David Jablon'" , juha.ollila@nokia.com, ipsec@lists.tislabs.com Subject: Re: Length of pre-shared key In-Reply-To: Your message of "Mon, 25 Feb 2002 16:56:59 EST." <000e01c1be47$5ab7e080$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3360.1014680346.1@tibernian.com> Date: Mon, 25 Feb 2002 15:39:06 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually you're stretching it to the block size of the underlying hash algorithm not to the length of the output of the underlying hash algorithm. Here is the 1st paragraph of section 3.0 of RFC2104 where H is the underlying hash function, B is the block size of H, and L is the length of the output of H: The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.) Less than L is bad. Between L and B it doesn't matter as the key will be appended with zeros (and it doesn't significantly increase the function strength) and greater than B doesn't matter because the key will be hashed down to L and appended with zeros. So the answer to Juha's question is "not less than the length of the output of the underlying hash function." Dan. On Mon, 25 Feb 2002 16:56:59 EST you wrote > > (1) append zeros to the end of K to create a B byte string > (e.g., if K is of length 20 bytes and B=64, then K will be > appended with 44 zero bytes 0x00) > > It's not a very fancy stretching technique, and admittedly unrelated to the > length of the hash output (I meant to say block size). > > Sorry about using the word password instead of key. It's just that I speak > binary. :-) > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: David Jablon [mailto:dpj@world.std.com] > > Sent: Monday, February 25, 2002 9:49 PM > > To: andrew.krywaniuk@alcatel.com > > Cc: juha.ollila@nokia.com; ipsec@lists.tislabs.com > > Subject: RE: Length of pre-shared key > > > > > > I don't see anywhere that RFC 2104 says anything about "stretch"ing > > a short input key into a longer one. What it does is to hash > > (squeeze?) > > a key that's longer than 64 bytes into a hash block. > > > > Also, one should not confuse a password with a key in this context. > > > > At 02:17 PM 2/25/02 -0500, Andrew Krywaniuk wrote: > > >I don't think there is a specific limit. After all, HMAC > > tells you how to > > >stretch the input if it is less that the size of the hash > > output. But use > > >your common sense: the shorter the input, the easier it will be for a > > >cracking program to guess it. Also, it's the entropy in the > > password, not > > >the length, that matters. > > > > > > > From owner-ipsec@lists.tislabs.com Mon Feb 25 17:01:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q11P314788; Mon, 25 Feb 2002 17:01:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27093 Mon, 25 Feb 2002 19:26:48 -0500 (EST) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Dan Harkins'" , "Andrew Krywaniuk" Cc: "'David Jablon'" , , Subject: RE: Length of pre-shared key Date: Mon, 25 Feb 2002 19:31:17 -0500 Message-ID: <001401c1be5c$e8c1acc0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200202252339.g1PNd6r03363@fatty.lounge.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I disagree. It comes down to the same basic question of "What DH group do I use with my cipher." The answer is not that you need to match the DH group to the cipher exactly. The answer is that you need to choose an overall system strength against attempts to derive the encryption key (X) and make sure both variables meet or exceed that. For IKE using preshared keys, the signature does not depend on g^xy, which means that the preshared key can be cracked offline. The result is that you need to choose an overall system strength against offline attacks to derive the authentication key (Y), and ensure that both variables (entropy in the key and the length of hash output) are greater than Y. Y does not necessarily have to be as large as X because not many people are concerned about 20 year secrecy for their authentication keys. The original question asked if there were required lengths for preshared keys. The answer is no there aren't. Using L is okay if you want to err on the side of caution, but it's not a hard requirement. Let's say you want to create an ASCII password using a random string of mixed case letters and numbers and you want Y to be 90 bits. Each character contains about 5 bits of entropy, so you will need to use passwords that are at least 15 bytes long. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@tibernian.com] > Sent: Monday, February 25, 2002 6:39 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'David Jablon'; juha.ollila@nokia.com; ipsec@lists.tislabs.com > Subject: Re: Length of pre-shared key > > > Actually you're stretching it to the block size of the underlying > hash algorithm not to the length of the output of the underlying hash > algorithm. Here is the 1st paragraph of section 3.0 of RFC2104 where H > is the underlying hash function, B is the block size of H, and L > is the length of the output of H: > > The key for HMAC can be of any length (keys longer than B bytes are > first hashed using H). However, less than L bytes is strongly > discouraged as it would decrease the security strength of the > function. Keys longer than L bytes are acceptable but the extra > length would not significantly increase the function strength. (A > longer key may be advisable if the randomness of the key is > considered weak.) > > Less than L is bad. Between L and B it doesn't matter as the > key will be > appended with zeros (and it doesn't significantly increase > the function > strength) and greater than B doesn't matter because the key > will be hashed > down to L and appended with zeros. So the answer to Juha's question is > "not less than the length of the output of the underlying > hash function." > > Dan. > > On Mon, 25 Feb 2002 16:56:59 EST you wrote > > > > (1) append zeros to the end of K to create a B byte string > > (e.g., if K is of length 20 bytes and B=64, then K will be > > appended with 44 zero bytes 0x00) > > > > It's not a very fancy stretching technique, and admittedly > unrelated to the > > length of the hash output (I meant to say block size). > > > > Sorry about using the word password instead of key. It's > just that I speak > > binary. :-) > > > > Andrew > > ------------------------------------------- > > There are no rules, only regulations. Luckily, > > history has shown that with time, hard work, > > and lots of love, anyone can be a technocrat. > > > > > > > > > -----Original Message----- > > > From: David Jablon [mailto:dpj@world.std.com] > > > Sent: Monday, February 25, 2002 9:49 PM > > > To: andrew.krywaniuk@alcatel.com > > > Cc: juha.ollila@nokia.com; ipsec@lists.tislabs.com > > > Subject: RE: Length of pre-shared key > > > > > > > > > I don't see anywhere that RFC 2104 says anything about > "stretch"ing > > > a short input key into a longer one. What it does is to hash > > > (squeeze?) > > > a key that's longer than 64 bytes into a hash block. > > > > > > Also, one should not confuse a password with a key in > this context. > > > > > > At 02:17 PM 2/25/02 -0500, Andrew Krywaniuk wrote: > > > >I don't think there is a specific limit. After all, HMAC > > > tells you how to > > > >stretch the input if it is less that the size of the hash > > > output. But use > > > >your common sense: the shorter the input, the easier it > will be for a > > > >cracking program to guess it. Also, it's the entropy in the > > > password, not > > > >the length, that matters. > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Feb 25 17:18:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q1IH315107; Mon, 25 Feb 2002 17:18:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27128 Mon, 25 Feb 2002 19:41:04 -0500 (EST) From: "Greg Bailey" To: Cc: "ark-gvb-x" Subject: RE: NAT Traversal Date: Mon, 25 Feb 2002 16:48:27 -0800 Message-ID: MIME-Version: 1.0 charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869979@vhqpostal.verisign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hallam-Baker, Phillip > Sent: Mon 25 Feb 02 14:05 > To: 'Derek Atkins'; Jayant Shukla > Cc: ipsec@lists.tislabs.com > Subject: RE: NAT Traversal [...] > The problem with NAT suggests to me that their authentication role was not > properly understood in IPSEC. I have never seen an internet service > advertised by IP address (except for the A root). Ergo it is not a primary > authentication point. Inasmuch as the job description of a NAT box is to lie about identities in terms of IP addresses, it seems to me that the authentication role of a NAT box is basically to emphasize the importance of having at least one mandatory type of supported ID that is capable of being globally unique for use in lieu of IP address when the actual IP address of an end point is neither unique nor visible in IP headers sent or received by the other end point. Unless the NAT box is formally acting as a security gateway, I would much rather base my policies on what the "invisible" box on the other end says its identity is rather than on something which could be a total fabrication by the NAT box. Not that this is a complete solution but given the "signa- ture" difficulty of grokking what is going on at the other end of a NAT box I think it would make the rest of a solution easier. The lack of an alternate, mandatory ID form is also something that seems to me to limit the usefulness of IKEv1 when defining policies for talking to a particular privileged mobile computer whose IP address varies with its location of the moment. > The IP address is sometimes a secondary authentication mechanism and should > be validated as part of the process of establishing an SA. > > Phill Greg Bailey | ATHENA Programming, Inc | 503-295-7703 | ---------------- | 310 SW 4th Ave Ste 530 | fax 295-6935 | greg@minerva.com | Portland, OR 97204 US | From owner-ipsec@lists.tislabs.com Mon Feb 25 17:28:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q1Sl315310; Mon, 25 Feb 2002 17:28:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27162 Mon, 25 Feb 2002 19:54:47 -0500 (EST) Message-Id: <200202260104.g1Q14Br03534@fatty.lounge.org> To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: Re: Length of pre-shared key In-Reply-To: Your message of "Mon, 25 Feb 2002 19:31:17 EST." <001401c1be5c$e8c1acc0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3531.1014685451.1@tibernian.com> Date: Mon, 25 Feb 2002 17:04:11 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You can disagree but you better take it up with the authors of RFC2104. It specifically says that you "stretch" the key to the block size of the hash algorithm, not, as you said, to its output. And using a "password" that is 15 bytes long as the key to a either HMAC-SHA or HMAC-MD5 (the two mandatory to implement algorithms for IKE) would be bad as the authors of RFC2104 have said. It is "strongly discouraged". That doesn't mean that you can enter the length into some nebulous equation of strength and maybe use it if the output from that equation is satisfactory. It means you shouldn't use a "password" that is 15 bytes long as the key to either one of those HMACs. Period. Full stop. Doing otherwise would be misusing this cryptographic primitive. Dan. On Mon, 25 Feb 2002 19:31:17 EST you wrote > I disagree. It comes down to the same basic question of "What DH group do I > use with my cipher." The answer is not that you need to match the DH group > to the cipher exactly. The answer is that you need to choose an overall > system strength against attempts to derive the encryption key (X) and make > sure both variables meet or exceed that. > > For IKE using preshared keys, the signature does not depend on g^xy, which > means that the preshared key can be cracked offline. The result is that you > need to choose an overall system strength against offline attacks to derive > the authentication key (Y), and ensure that both variables (entropy in the > key and the length of hash output) are greater than Y. Y does not > necessarily have to be as large as X because not many people are concerned > about 20 year secrecy for their authentication keys. > > The original question asked if there were required lengths for preshared > keys. The answer is no there aren't. Using L is okay if you want to err on > the side of caution, but it's not a hard requirement. Let's say you want to > create an ASCII password using a random string of mixed case letters and > numbers and you want Y to be 90 bits. Each character contains about 5 bits > of entropy, so you will need to use passwords that are at least 15 bytes > long. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@tibernian.com] > > Sent: Monday, February 25, 2002 6:39 PM > > To: andrew.krywaniuk@alcatel.com > > Cc: 'David Jablon'; juha.ollila@nokia.com; ipsec@lists.tislabs.com > > Subject: Re: Length of pre-shared key > > > > > > Actually you're stretching it to the block size of the underlying > > hash algorithm not to the length of the output of the underlying hash > > algorithm. Here is the 1st paragraph of section 3.0 of RFC2104 where H > > is the underlying hash function, B is the block size of H, and L > > is the length of the output of H: > > > > The key for HMAC can be of any length (keys longer than B bytes are > > first hashed using H). However, less than L bytes is strongly > > discouraged as it would decrease the security strength of the > > function. Keys longer than L bytes are acceptable but the extra > > length would not significantly increase the function strength. (A > > longer key may be advisable if the randomness of the key is > > considered weak.) > > > > Less than L is bad. Between L and B it doesn't matter as the > > key will be > > appended with zeros (and it doesn't significantly increase > > the function > > strength) and greater than B doesn't matter because the key > > will be hashed > > down to L and appended with zeros. So the answer to Juha's question is > > "not less than the length of the output of the underlying > > hash function." > > > > Dan. > > > > On Mon, 25 Feb 2002 16:56:59 EST you wrote > > > > > > (1) append zeros to the end of K to create a B byte string > > > (e.g., if K is of length 20 bytes and B=64, then K will be > > > appended with 44 zero bytes 0x00) > > > > > > It's not a very fancy stretching technique, and admittedly > > unrelated to the > > > length of the hash output (I meant to say block size). > > > > > > Sorry about using the word password instead of key. It's > > just that I speak > > > binary. :-) > > > > > > Andrew > > > ------------------------------------------- > > > There are no rules, only regulations. Luckily, > > > history has shown that with time, hard work, > > > and lots of love, anyone can be a technocrat. > > > > > > > > > > > > > -----Original Message----- > > > > From: David Jablon [mailto:dpj@world.std.com] > > > > Sent: Monday, February 25, 2002 9:49 PM > > > > To: andrew.krywaniuk@alcatel.com > > > > Cc: juha.ollila@nokia.com; ipsec@lists.tislabs.com > > > > Subject: RE: Length of pre-shared key > > > > > > > > > > > > I don't see anywhere that RFC 2104 says anything about > > "stretch"ing > > > > a short input key into a longer one. What it does is to hash > > > > (squeeze?) > > > > a key that's longer than 64 bytes into a hash block. > > > > > > > > Also, one should not confuse a password with a key in > > this context. > > > > > > > > At 02:17 PM 2/25/02 -0500, Andrew Krywaniuk wrote: > > > > >I don't think there is a specific limit. After all, HMAC > > > > tells you how to > > > > >stretch the input if it is less that the size of the hash > > > > output. But use > > > > >your common sense: the shorter the input, the easier it > > will be for a > > > > >cracking program to guess it. Also, it's the entropy in the > > > > password, not > > > > >the length, that matters. > > > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Feb 25 22:24:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q6OK321140; Mon, 25 Feb 2002 22:24:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA27824 Tue, 26 Feb 2002 00:23:24 -0500 (EST) From: "Khaja E. Ahmed" To: "Edward Wilkinson" , "'Christian Fanzen'" , Cc: Subject: RE: Phase 1 Lifetime and Lifedata Date: Mon, 25 Feb 2002 21:33:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <36C2EB69D2F9D411A9AB00D0B7200334F81591@eniwest.inside.efficient.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Raptor, was acquired by Axent, which in turn was acquired by Symantec. It is now a Symantec product and appears to have been renamed. http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=47 Khaja > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Edward Wilkinson > Sent: Monday, February 25, 2002 9:52 AM > To: 'Christian Fanzen'; dfox@quarrytech.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Phase 1 Lifetime and Lifedata > > > > Thanks, > I have not encountered the Raptor yet, could you provide some additional > information on that product. A search of the web finds lots of birds. > > Ed > > -----Original Message----- > From: Christian Fanzen [mailto:cfranzenml@atsec.com] > Sent: Monday, February 25, 2002 1:08 AM > To: dfox@quarrytech.com; ewilkinson@efficient.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Phase 1 Lifetime and Lifedata > > > Hi, > > theory and praxis are allways different. In this case lifedata is > defined by > the IKE RFC, the theoretical part. But in practice for most > vendors (Cisco, > Checkpoint, Raptor, Win2K) the lifedata value MUST be set to > zero! Otherwise > the negotiation fails. > In my opinion this configuration-data-field should be diasabled > in order to > not insecure users and admins. > > Christian > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of dfox@quarrytech.com > > Sent: Freitag, 22. Februar 2002 00:32 > > To: ewilkinson@efficient.com > > Cc: ipsec@lists.tislabs.com > > Subject: RE: Phase 1 Lifetime and Lifedata > > > > > > In the last couple of implementations, that I was involved with > > testing, we > > didn't use Lifedata in Phase 1. The reason for this is that the ISAKMP > > communications are so small that it didn't make sense. If it > was sent to > > us, we dealt with it appropriately. We always used Lifetime, however. > > > > David > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > David Fox > > Quarry Technologies dfox@quarrytech.com > > 8 New England Executive Park Direct: 781-359-5094 > > Burlington, Massachusetts 01803 Main: 781-505-8300 x5094 > > www.quarrytech.com FAX: 781-505-8316 > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > -----Original Message----- > > From: Edward Wilkinson [mailto:ewilkinson@efficient.com] > > Sent: Thursday, February 21, 2002 5:31 PM > > To: Ipsec (E-mail) > > Subject: Phase 1 Lifetime and Lifedata > > > > When using some of the gateways and clients, I see an option to set > > lifedata.. Is this filed valid in phase 1 and if it is how would it be > > used. > > From owner-ipsec@lists.tislabs.com Mon Feb 25 22:30:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q6Um321245; Mon, 25 Feb 2002 22:30:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA27889 Tue, 26 Feb 2002 00:49:57 -0500 (EST) Message-ID: <3C7B26A7.D01E2150@multitech.co.in> Date: Tue, 26 Feb 2002 11:39:43 +0530 From: Ravi Ganesh Organization: MTSS X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Franjo Majstor CC: Takaoka Takayoshi , IPsec Mailing List Subject: Re: IPsec VPN v.s. MPLS VPN References: <5.1.0.14.2.20020225151326.00bda828@144.254.15.68> Content-Type: multipart/alternative; boundary="------------6C1E8888C24DE63CEDD00AA3" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------6C1E8888C24DE63CEDD00AA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IPSec VPN and MPLS VPNs are two different entities. Increasing the pipe capacity is not a solution for a legacy Internet. The number of subscribers are exponentially growing day by day. I feel, we need to stop investing on the Infrastructure, concentrate more on utilizing the existing network resources to the maximum. This is where the challenge lies. MPLS -VPN is a two fold solution which highlight on security for sure, but also engineers the network backbone efficiently and effectively using Traffic Engineering. This means a great deal of improvement in the performance to the end user. There is no technology which is complex. Its just the way we look at it. All we need to worry about is, "Where this technology best fits in and the area of deployment (Carrier, Provider edge, Enterprise)". Regards, Ravi. Franjo Majstor wrote: > This might help you for start... > > http://www.ietf.org/internet-draf > s/draft-behringer-mpls-security-01.txt > > Franjo > > > At 04:21 2/25/2002, Takaoka Takayoshi wrote: > > >> Hi, everyone! >> >> I want to discuss the superiority both type of VPN, IPsec and MPLS. >> Now our company run after the tech of VPN to provide the secure zone >> for all customer, and this classfication is as following I think; >> >> IPsec VPN -use the Internet for this infrastructure, don't be needed >> the additional capital investment, so this is match for the >> enterprise security solution. But there is no expectation to ensure >> the intelligent Traffic Engineering that MPLS VPN can do. >> >> MPLS VPN - use the closed network with the exclusive router, and >> this closed network is provided by the carrier, this complecated >> switching network can give us high performance and perfect ToS, and >> no need to encrypt the traffic data. >> >> Now I think, it's just my opinion, if the internet infrastructure >> become has a big pipe and high performance, of couse the investment >> for this owe to all of carrier, the intelligent traffic engineering >> is no use anymore and great through put can provide to anyone >> connecting to internet. That means, in the future, the intelligent >> ToS isn't neccesary, we don't need to care of the ToS, extremely I >> can say. >> >> That fact also means, the end security gateway only take care of >> high performance encryption & decryption, that based on ASIC. >> >> I wonder, there is some possibility in the future, all of client has >> exclusive ASIC for encryption for itself, and also the internet has >> security gateway routing protocol, this system can be swith the all >> of client request with IPsec. The client can connect to all of >> internet server or client using security tunnel that provided by VPN >> swith network which spreading all over the world! >> >> Anyway, now I want to change my question to you like that, >> >> "Do you think the MPLS tech can survive in the security solution?" >> >> Best regards, >> Taka >> >> >> Network Value Components, Ltd. >> GroupSystemNameTakayoshiMailttakaoka@nvc.co.jp >> Phone0468-20-1800 >> FAX0468-25-8053 >> URLhttp://www.nvc.co.jp >> > > > ............................................................................................................ > > Franjo Majstor CCIE #1507 Access,Security > > EMEA Consulting Engineer CISSP > > Phone : +32-2-778.4395 Fax : +32-2-778.4300 > Mobile: +32-475-36.3202 PGP Key: available on request > Cisco Systems, Av. Marcel Thiry 77,1200 Brussels, Belgium > _______________________________________________ > > > > > --------------6C1E8888C24DE63CEDD00AA3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit IPSec VPN and MPLS VPNs are two different entities.

Increasing the pipe capacity is not a solution for a legacy Internet. The number of subscribers are exponentially growing day by day.  I feel, we need to stop investing on the Infrastructure, concentrate more on utilizing the existing network resources to the maximum. This is where the challenge lies.

MPLS -VPN is a two fold solution which highlight on security for sure, but also engineers the network backbone efficiently and effectively using Traffic Engineering. This means a great deal of improvement in the performance to the end user.

There is no technology which is complex. Its just the way we look at it. All we need to worry about is, "Where this technology best fits in and the area of deployment (Carrier, Provider edge, Enterprise)".

Regards,
Ravi.

Franjo Majstor wrote:

 This might help you for start...

http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-01.txt

Franjo
 

At 04:21 2/25/2002, Takaoka Takayoshi wrote:
 

Hi, everyone!

I want to discuss the superiority both type of VPN, IPsec and MPLS.
Now our company run after the tech of VPN to provide the secure zone for all customer, and this classfication is as following I think;

IPsec VPN -use the Internet for this infrastructure, don't be needed the additional capital investment, so this is match for the enterprise security solution. But there is no expectation to ensure the intelligent Traffic Engineering that MPLS VPN can do.

MPLS VPN - use the closed network with the exclusive router, and this closed network is provided by the carrier, this complecated switching network can give us high performance and perfect ToS, and no need to encrypt the traffic data.

Now I think, it's just my opinion, if the internet infrastructure become has a big pipe and high performance, of couse the investment for this owe to all of carrier, the intelligent traffic engineering is no use anymore and great through put can provide to anyone connecting to internet. That means, in the future, the intelligent ToS isn't neccesary, we don't need to care of the ToS, extremely I can say.

That fact also means, the end security gateway only take care of high performance encryption & decryption, that based on ASIC.

I wonder, there is some possibility in the future, all of client has exclusive ASIC for encryption for itself, and also the internet has security gateway routing protocol, this system can be swith the all of client request with IPsec. The client can connect to all of internet server or client using security tunnel that provided by VPN swith network which spreading all over the world!

Anyway, now I want to change my question to you like that,

"Do you think the MPLS tech can survive in the security solution?"

Best regards,
Taka
 

Network Value Components, Ltd.
GroupSystemNameTakayoshiMailttakaoka@nvc.co.jp
Phone0468-20-1800
FAX0468-25-8053
URLhttp://www.nvc.co.jp
 

.............................................................................................................
Franjo Majstor                              CCIE #1507 Access,Security
EMEA Consulting Engineer       CISSP

Phone : +32-2-778.4395         Fax : +32-2-778.4300
Mobile:  +32-475-36.3202       PGP Key: available on request
Cisco Systems, Av. Marcel Thiry 77,1200 Brussels, Belgium
_______________________________________________
 
 
 
 
 

--------------6C1E8888C24DE63CEDD00AA3-- From owner-ipsec@lists.tislabs.com Tue Feb 26 02:00:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QA0V320988; Tue, 26 Feb 2002 02:00:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA28456 Tue, 26 Feb 2002 04:08:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message Subject: RE: NAT Traversal Date: Tue, 26 Feb 2002 01:16:51 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE6B62@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: NAT Traversal Thread-Index: AcG+YPgtnjbF2d6KRH23aUeLF1YGQgAQ1lGg From: "William Dixon" To: "Greg Bailey" , Cc: "ark-gvb-x" X-OriginalArrivalTime: 26 Feb 2002 09:16:51.0518 (UTC) FILETIME=[53578DE0:01C1BEA6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a status note that the NAT-T authors are reviewing an option to start on 500, then float the port off of 500 to another well-known port because of the Ipsec-aware NATs already out there. Our test code showed that doing this passed 10-12 major NAT boxes in both their normal and "IPsec aware" modes, for 1 and 2 clients behind the NAT, with serially established IPsec SA pairs UDPnon-500-ESP to the same dest IP. I regret that I haven't been able to post the earlier or even the later test results, just due to lack of bandwidth. The task is still in queue, I haven't given up yet...and hopefully Ted & Barbara were able to allow 15min on the agenda in Minneapolis. With this change, I see no deployment blocker for IKE and IPsec working transparent through "normal" NATs and "IPsec aware" NATs. However, adoption may still require IPR clarification. Jayant, I don't see the Trlokom IPR notice on the IETF site. Didn't you say you submitted one ? -----Original Message----- From: Greg Bailey [mailto:greg@minerva.com] Sent: Monday, February 25, 2002 4:48 PM To: ipsec@lists.tislabs.com Cc: ark-gvb-x Subject: RE: NAT Traversal > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hallam-Baker, > Phillip > Sent: Mon 25 Feb 02 14:05 > To: 'Derek Atkins'; Jayant Shukla > Cc: ipsec@lists.tislabs.com > Subject: RE: NAT Traversal [...] > The problem with NAT suggests to me that their authentication role was > not properly understood in IPSEC. I have never seen an internet > service advertised by IP address (except for the A root). Ergo it is > not a primary authentication point. Inasmuch as the job description of a NAT box is to lie about identities in terms of IP addresses, it seems to me that the authentication role of a NAT box is basically to emphasize the importance of having at least one mandatory type of supported ID that is capable of being globally unique for use in lieu of IP address when the actual IP address of an end point is neither unique nor visible in IP headers sent or received by the other end point. Unless the NAT box is formally acting as a security gateway, I would much rather base my policies on what the "invisible" box on the other end says its identity is rather than on something which could be a total fabrication by the NAT box. Not that this is a complete solution but given the "signa- ture" difficulty of grokking what is going on at the other end of a NAT box I think it would make the rest of a solution easier. The lack of an alternate, mandatory ID form is also something that seems to me to limit the usefulness of IKEv1 when defining policies for talking to a particular privileged mobile computer whose IP address varies with its location of the moment. > The IP address is sometimes a secondary authentication mechanism and > should be validated as part of the process of establishing an SA. > > Phill Greg Bailey | ATHENA Programming, Inc | 503-295-7703 | ---------------- | 310 SW 4th Ave Ste 530 | fax 295-6935 | greg@minerva.com | Portland, OR 97204 US | From owner-ipsec@lists.tislabs.com Tue Feb 26 06:10:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QEA8305902; Tue, 26 Feb 2002 06:10:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28911 Tue, 26 Feb 2002 08:18:30 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: NAT Traversal References: Organization: SSH Communications Security From: Markus Stenberg Date: 26 Feb 2002 12:04:30 +0200 Message-ID: <87adtwzhht.fsf@ssh.com> Lines: 48 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA28613 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > On 25 Feb 2002, Derek Atkins wrote: > > "Jayant Shukla" writes: > > > > > > What makes you think the client is involved? IPsec pass-thru implemented > > > in most low end NAT boxes is not complete RSIP as that would require > > > modifications to client and the gateway. > > > > See what I said before about demon-spawn!!! NAT traversal via IPsec > > pass-thru[sic] is just plain wrong, broken, and lots of other words > > that I don't want to use in mixed company. > NAT translates all protocols in a transparent manner using some protocol > parameters, Eg. ports in case of UDP and TCP. I don't see why we should > not try and apply a similar model to IPsec, using cookies and SPIs. > > Sure the SPIs are encrypted during IKE negotiation and the NAT box cannot > see which SPIs are a pair. But if we somehow relate one SPI to another in > each pair, the NAT box can translate ESP traffic with a high probability > of success. Indeed? I'd like to know how my ESP transport mode's TCP checksum is fixed by the NAT box. Note: IPsec is other things than VPNs, too. Or, in tunnel mode, actually (*gasp*) more than one client behind large NAT accessing (*gasp*) SAME security gateway! High probability of success my .. foot. > Well, it's not pretty, but that is the inherent nature of NAT itself. It's far from pretty. It seems that using some obscure port, or having disclaimer about 'This is copyright protected material, if you try to reverse-engineer this ROT-0 encrypted packet you will be sued to hell' are the only two ways to deal with it. I'm starting to agree with Derek about what should be done with NATs.. > chinna -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) SSH $B0O8k@h@8(B From owner-ipsec@lists.tislabs.com Tue Feb 26 13:20:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QLKi323390; Tue, 26 Feb 2002 13:20:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29866 Tue, 26 Feb 2002 15:18:47 -0500 (EST) Date: Tue, 26 Feb 2002 12:29:32 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Markus Stenberg cc: Subject: Re: NAT Traversal In-Reply-To: <87adtwzhht.fsf@ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 26 Feb 2002, Markus Stenberg wrote: > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > On 25 Feb 2002, Derek Atkins wrote: > > > "Jayant Shukla" writes: > > > > > > > > What makes you think the client is involved? IPsec pass-thru implemented > > > > in most low end NAT boxes is not complete RSIP as that would require > > > > modifications to client and the gateway. > > > > > > See what I said before about demon-spawn!!! NAT traversal via IPsec > > > pass-thru[sic] is just plain wrong, broken, and lots of other words > > > that I don't want to use in mixed company. > > NAT translates all protocols in a transparent manner using some protocol > > parameters, Eg. ports in case of UDP and TCP. I don't see why we should > > not try and apply a similar model to IPsec, using cookies and SPIs. > > > > Sure the SPIs are encrypted during IKE negotiation and the NAT box cannot > > see which SPIs are a pair. But if we somehow relate one SPI to another in > > each pair, the NAT box can translate ESP traffic with a high probability > > of success. > > Indeed? I'd like to know how my ESP transport mode's TCP checksum is fixed > by the NAT box. > > Note: IPsec is other things than VPNs, too. Transport mode in general is used when IPsec is being used to protect already tunneled traffic like L2TP or GRE. So, in these cases the TCP checksum is not an issue because the original IP datagram tunneled by other tunnelling protocols will have the right checksum. Generally these original addresses of the original IP datagram will be private addresses that we don't want to translate in a VPN. In what "other" cases are you saying we need to do IPsec transport mode through NAT? Someone gets a private address, and does plain IPsec transport mode through NAT! to whom? and why? Well sounds familiar: we don't know how it will be used, or who needs it, but it has to be there, and we will bend over backwards to accomplish it. > > Or, in tunnel mode, actually (*gasp*) more than one client behind large NAT > accessing (*gasp*) SAME security gateway! > > High probability of success my .. foot. I prefer a civilized debate, but if you insist... I said, "if we somehow relate the SPIs in a pair", the NAT box can take advantage of that to demultiplex. It's a very simple idea: make one spi (or part of it) a hash of the other so that the NAT box can relate a pair of SPIs. We have this working in our products. > > > Well, it's not pretty, but that is the inherent nature of NAT itself. > > It's far from pretty. > -Adding an encapsulation overhead of > 20 bytes is very pretty! we have people already screaming about the overhead that ESP adds! -Modifing IKE to do "NAT discovery" is very pretty! IKE isn't doing much yet, so lets add more. -Using adhoc keepalives schemes to maintain the unpredictable NAT translations is very very pretty! -Most of all, massive hand waving about "built-in host NAT implementation within the IPsec stack" is the most prettiest of all Probably NAT and pretty cannot be in the same sentence for most of us anyway. So, let's not focus on the "pretty" factor of the solutions. chinna > It seems that using some obscure port, or having disclaimer about 'This is > copyright protected material, if you try to reverse-engineer this ROT-0 > encrypted packet you will be sued to hell' are the only two ways to deal > with it. > > I'm starting to agree with Derek about what should be done with NATs.. > > > chinna > > -Markus > > -- > Markus Stenberg of SSH Communications Security (www.ssh.com) > SSH $B0O8k@h@8(B > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Feb 26 17:04:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1R14k328265; Tue, 26 Feb 2002 17:04:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00479 Tue, 26 Feb 2002 19:16:43 -0500 (EST) To: "Chinna N.R. Pellacuru" Cc: Markus Stenberg , From: Derek Atkins Subject: Re: NAT Traversal References: Date: 26 Feb 2002 19:28:01 -0500 In-Reply-To: Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" writes: > In what "other" cases are you saying we need to do IPsec transport mode > through NAT? Someone gets a private address, and does plain IPsec > transport mode through NAT! to whom? and why? Here's an example: A person at a conference who's laptop is setup to perform RSA-based transport-mode opportunistic encryption, but where the conference is sitting on a NAT? I've been to conferences where they conference LAN is sitting behind a NAT, but I would still like to be able to use my laptop and the services it has the same way I would if I were NOT sitting behind a NAT. To my laptop, it shouldn't matter. Keep in mind that the user who wants to run IPsec and the manager who runs the network with a NAT may NOT be the same person! -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Feb 26 20:01:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1R41Y301755; Tue, 26 Feb 2002 20:01:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA00856 Tue, 26 Feb 2002 22:10:24 -0500 (EST) Date: Tue, 26 Feb 2002 19:20:35 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: Markus Stenberg , Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 26 Feb 2002, Derek Atkins wrote: > "Chinna N.R. Pellacuru" writes: > > > In what "other" cases are you saying we need to do IPsec transport mode > > through NAT? Someone gets a private address, and does plain IPsec > > transport mode through NAT! to whom? and why? > > Here's an example: A person at a conference who's laptop is setup to > perform RSA-based transport-mode opportunistic encryption, but where > the conference is sitting on a NAT? I've been to conferences where > they conference LAN is sitting behind a NAT, but I would still like to > be able to use my laptop and the services it has the same way I would > if I were NOT sitting behind a NAT. To my laptop, it shouldn't > matter. > > Keep in mind that the user who wants to run IPsec and the manager who > runs the network with a NAT may NOT be the same person! > Could you elaborate this scenario more. What/who are you doing transport mode with and what kind of applications are generating this traffic? In general we see people running tunnel mode in this case to a border security gateway or a remote access aggregator, and access the machines within the network which is behind the aggregator. Or people could run L2TP or GRE to a border router (if they want multicast), and run IPsec transport mode on those tunnels. Consider a sample network at a conference which gives out private addresses and runs NAT at its border laptop+-----------+NAT+-----( cloud )-------+IPsec peer laptop got an address 10.0.0.5 NAT box is going to translate it to say 5.0.0.1 IPsec peer is 6.0.0.1 Now, IPsec proxy identities are 10.0.0.5 and 6.0.0.1. Question1: So, do the applications on the IPsec peer think that they are talking to 10.0.0.5 or do they think they are talking to 5.0.0.1? You can't have the applications on IPsec peer to expect the traffic to be coming from a private address space(10.0.0.5 in our case), of which he has no knowledge about, and only the network administrator of the conference has control over. IPsec peer cannot route traffic based on the private addresses becuase it has no prior knowledge or control of the private address space, and there could be overlapping private address spaces. We do IPsec after routing. If we can't route properly, we won't even get to IPsec. So, let's say the address that is expected is address that NAT gives it, which is 5.0.0.1. Because the IPsec proxy identities are 10.0.0.5 and 6.0.0.1, the NAT decapsulation process will need to change the source address from 5.0.0.1 to 10.0.0.5 before checking the packet against the SADB. This check is for seeing whether the packet matches the proxy identities negotiated for this SA. After that we need to use the appropriate source IP address based on the answer to Question1. If the applications are expecting 5.0.0.1, then before we ship the datagram to the applications we need to change the source IP address on the datagram back to 5.0.0.1 after the SADB check. Say the NAT box uses a source port of 9999 in the UDP encapsulation header for your laptop. For another laptop it uses 8888. Now if both the laptops are talking to the IPsec peer, the return traffic will all be traffic to 5.0.0.1, because applications only know about 5.0.0.1. How will the IPsec layer decide which SA to use (hence which UDP port to use in the UDP encapsulation header)? If we don't use the right UDP port, the NAT box cannot demultiplex properly between the laptops. Now if you want to make IPsec even more NAT aware, we need to keep track of the source and destination ports of the data traffic in the IPsec layer (in addition to ports in the UDP encapsulation header). Now if the first laptop was doing TCP from port 5000 to 23, and the second laptop is doing TCP from port 6000 to 23, then we can store this information in the IPsec-NAT translation table and use that information to pick up the right IPsec SA. This would NOT work if both laptops pick up the same source TCP port though. This also would NOT work for protocols that don't have ports. Now if it is some other protocol, then the IPsec layer should understand that protocol and some how keep enough information to pick the right SAs. This is just a slippery slope. -So, people have to do a "built-in host NAT implementation within the IPsec stack". I just can't imagine how pretty that would be. -Curious why this is not being acknowledged in the latest drafts. -In order to go through NAT, we will implement the whole of NAT in IPsec! Now we don't have to worry about how many NATs are there enroute, but we got this done by having a NAT implementation in each IPsec implementation! -Now everytime a new application layer protocol comes along which NAT has to deal with, we go and change our NAT implementation and also our own NAT implementation within our IPsec implementation too! -So, all NAT boxes have to be upgraded for dealing with non-IPsec traffic of this new protocol and all IPsec implementations will need to be upgraded if that new protocol needs to be IPsec protected! -Doesn't it look like bending over backwards to accommidate some scenario we are not sure how/who, if at all, will use it? -Even after doing all this, it may not work in some cases. I think it is not prudent to judge solutions based on such corner cases. Even if we consider the above technique as a way to solve this corner case, it is not easy to implement, and it forces all IPsec implementations to do a full NAT implementation, and even if we do it, it still may not work in even more corner cases. chinna From owner-ipsec@lists.tislabs.com Tue Feb 26 21:03:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1R535302837; Tue, 26 Feb 2002 21:03:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA01024 Tue, 26 Feb 2002 23:20:23 -0500 (EST) From: "Jayant Shukla" To: "'Derek Atkins'" , "'Chinna N.R. Pellacuru'" Cc: Subject: RE: NAT Traversal Date: Tue, 26 Feb 2002 20:28:31 -0800 Message-ID: <000001c1bf47$367e88d0$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Derek Atkins > Sent: Tuesday, February 26, 2002 4:28 PM > To: Chinna N.R. Pellacuru > Cc: Markus Stenberg; ipsec@lists.tislabs.com > Subject: Re: NAT Traversal > > "Chinna N.R. Pellacuru" writes: > > > In what "other" cases are you saying we need to do IPsec transport mode > > through NAT? Someone gets a private address, and does plain IPsec > > transport mode through NAT! to whom? and why? > > Here's an example: A person at a conference who's laptop is setup to > perform RSA-based transport-mode opportunistic encryption, but where > the conference is sitting on a NAT? I've been to conferences where > they conference LAN is sitting behind a NAT, but I would still like to > be able to use my laptop and the services it has the same way I would > if I were NOT sitting behind a NAT. To my laptop, it shouldn't > matter. > > Keep in mind that the user who wants to run IPsec and the manager who > runs the network with a NAT may NOT be the same person! > > -derek > Are you sure you are allowed to use the transport mode?? AFAIK, Section 4.6.2 of the draft (draft-richardson-ipsec-opportunistic-06.txt) mandates the use of TUNNEL mode. Your example is not good! Regards, Jayant http://www.trlokom.com From owner-ipsec@lists.tislabs.com Wed Feb 27 00:33:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1R8XJ320971; Wed, 27 Feb 2002 00:33:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01355 Wed, 27 Feb 2002 02:39:22 -0500 (EST) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC01BA72F3@highway> From: 837 <837@nu.edu.pk> To: "'ipsec@lists.tislabs.com'" Subject: Some queries regarding RFC 2401: Authentication Header Date: Wed, 27 Feb 2002 12:50:59 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some Questions realted to RFC 2401, "Authentication Header": > 1) In section 2.2, Payload Length, it is stated that we can use a "null" > algorithm, but i read in RFC 2401, that one must provide at least one > service at one time. It doesnt make sense to provide null algorithm. For > what sort of debugging is it used ? > > 2) In IPv6, do we compute the "Payload Length" in 64-bit words or 32-bit > words? and do we subtract 2 or 1 in any case for that count? > > 3)In case of Sequence Number cycle, do we just drop the packet and report > an auditable event or do we create a new SA and Key every time it happens > or do we do both? > > 4) In the section 3.3.3.2.1 "Authentication Data padding", its is stated > that "These padding bytes are included in the Authetication Data > calculation", dont we just zero the authentication data field while > computing the ICV. If not, in what perspective the above statement has > been made? > > > I shall be grateful if someone clears out the confusion(s). Afzal Khan From owner-ipsec@lists.tislabs.com Wed Feb 27 03:19:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RBJh311199; Wed, 27 Feb 2002 03:19:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA01713 Wed, 27 Feb 2002 05:23:23 -0500 (EST) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC01BA72F5@highway> From: 837 <837@nu.edu.pk> To: "'ipsec@lists.tislabs.com'" Subject: correction Date: Wed, 27 Feb 2002 15:31:30 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk correction on my previous mail regarding queries for "RFC 2401: Authentication Header", which is in fact RFC 2402. My queries are related to "RFC 2402: Authentication Header". Afzal From owner-ipsec@lists.tislabs.com Wed Feb 27 03:19:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RBJl311211; Wed, 27 Feb 2002 03:19:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA01731 Wed, 27 Feb 2002 05:37:37 -0500 (EST) Date: Wed, 27 Feb 2002 11:46:08 +0100 (MET) Message-Id: <200202271046.LAA15927@hugo.int-evry.fr> From: Jean-Jacques Puig To: 837 <837@nu.edu.pk> Cc: ipsec@lists.tislabs.com Subject: Re: Some queries regarding RFC 2401: Authentication Header In-Reply-To: <4F7DD203738DD411B71A00B0D03DDECC01BA72F3@highway> References: <4F7DD203738DD411B71A00B0D03DDECC01BA72F3@highway> Organization: Département Logiciels - Réseaux X-Mailer: Sylpheed version 0.6.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 837, > Some Questions realted to RFC 2401, "Authentication Header": Authentication Header is 2402. 2401 is worth a look anyway. > > 1) In section 2.2, Payload Length, it is stated that we can use a "null" > > algorithm, but i read in RFC 2401, that one must provide at least one > > service at one time. It doesnt make sense to provide null algorithm. For > > what sort of debugging is it used ? I believe it's up to implementors to deal with this question. An example would be to check if a communication with NULL AUTH works; if it does not, there is no point going further anyway. If it does and if it fails with non-NULL AUTH, may be the AUTH algorithmn should be check again, or the algo lookup, the algo use (params...). NULL AUTH is free. Why shouldn't it make sense ? > > 2) In IPv6, do we compute the "Payload Length" in 64-bit words or 32-bit > > words? and do we subtract 2 or 1 in any case for that count? The section 2.2 is actually clear about it. IPv4 word length = 32 bits IPv6 word length = 64 bits But you should only care about what you really need to know for this payload: AH Payload length is mesured (in both IPv4 and IPv6) in 32 bits words, minus 2. Beware of padding, which may involve different payload length for IPv4 and IPv6 (see section 3.3.3.2.1). Again, IMHO, section 2.2 and section 3.3.3.2.1 are quite clear about it. > > 3)In case of Sequence Number cycle, do we just drop the packet and report > > an auditable event or do we create a new SA and Key every time it happens > > or do we do both? Sections 3.3.2 and 3.4.3 deals with that. 3.3.2 states: "If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5.) However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero." and 3.4.3: "If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number." Thus, if anti-replay is disabled, you should not care about cycling. Now, if anti-replay is enabled: 3.3.2 says: "Thus, if the counter has cycled, the sender will set up a new SA and key..." Ok, it may be unclear. I thing that the peer which is about to send the first cycling packet SHOULD NOT send such a packet, but SHOULD immediately set up new keying material via IKE. Logically, peers should not, in a certain way, 'replay' packets of their own (the data from packet sequenced 1 on firts cycled packet could be the same). Thus, if sequence number cycle, you should drop the packet. This is an auditable event. > > 4) In the section 3.3.3.2.1 "Authentication Data padding", its is stated > > that "These padding bytes are included in the Authetication Data > > calculation", dont we just zero the authentication data field while > > computing the ICV. If not, in what perspective the above statement has > > been made? It has nothing to do with the Authentication Data field padding (section 3.3.3.2.1). Section 3.3.3.2.2 explains how PACKET is padded in order to meet ICV computation blocksize requirements. e.g. if your authentication algo operate on blocks of 17 octets, you should padd the end your packet with (17*(Esup(packet_length/17)) - packet_length) zeros, where Esup() is: packet_length/17 is this is an integer (no padding required) E(packet_length/17) + 1 if packet_length/17 is not an integer (E() being floor() or trunc()). -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Wed Feb 27 05:01:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RD1B314882; Wed, 27 Feb 2002 05:01:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA01860 Wed, 27 Feb 2002 07:11:15 -0500 (EST) Message-Id: <200202271222.HAA17658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-rationale-00.txt Date: Wed, 27 Feb 2002 07:22:37 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Design Rationale for IKEv2 Author(s) : D. Harkins et al. Filename : draft-ietf-ipsec-ikev2-rationale-00.txt Pages : 10 Date : 26-Feb-02 This document describes the reasons for the design choices in IKEv2, the protocol described in draft-ietf-ipsec-ikev2-01.txt. This document describes why certain features are supported, and explains the modifications between the second draft of IKEv2 and the first. It describes both the changes we chose to make and the changes that we considered but chose not to make. The changes are minor and mostly based on feedback received from the first draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-rationale-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-ikev2-rationale-00.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-ietf-ipsec-ikev2-rationale-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-rationale-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-rationale-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Feb 27 08:31:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RGUx327715; Wed, 27 Feb 2002 08:31:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02138 Wed, 27 Feb 2002 10:24:36 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: NAT Traversal References: Organization: SSH Communications Security From: Markus Stenberg Date: 27 Feb 2002 12:20:01 +0200 Message-ID: <87u1s3p6pa.fsf@ssh.com> Lines: 130 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > On 26 Feb 2002, Markus Stenberg wrote: > > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > > On 25 Feb 2002, Derek Atkins wrote: > > > > "Jayant Shukla" writes: > > > > > > > > > > What makes you think the client is involved? IPsec pass-thru implemented > > > > > in most low end NAT boxes is not complete RSIP as that would require > > > > > modifications to client and the gateway. > > > > > > > > See what I said before about demon-spawn!!! NAT traversal via IPsec > > > > pass-thru[sic] is just plain wrong, broken, and lots of other words > > > > that I don't want to use in mixed company. > > > NAT translates all protocols in a transparent manner using some protocol > > > parameters, Eg. ports in case of UDP and TCP. I don't see why we should > > > not try and apply a similar model to IPsec, using cookies and SPIs. > > > > > > Sure the SPIs are encrypted during IKE negotiation and the NAT box cannot > > > see which SPIs are a pair. But if we somehow relate one SPI to another in > > > each pair, the NAT box can translate ESP traffic with a high probability > > > of success. > > > > Indeed? I'd like to know how my ESP transport mode's TCP checksum is fixed > > by the NAT box. > > > > Note: IPsec is other things than VPNs, too. > Transport mode in general is used when IPsec is being used to protect > already tunneled traffic like L2TP or GRE. So, in these cases the TCP > checksum is not an issue because the original IP datagram tunneled by > other tunnelling protocols will have the right checksum. Generally these > original addresses of the original IP datagram will be private addresses > that we don't want to translate in a VPN. And unless you control both ends L2TP implementations, they might have UDP checksumming on.. *oops* And so he quoteth the RFC 2661: ,---- | The default for any L2TP implementation is that UDP checksums MUST be | enabled for both control and data messages. An L2TP implementation | MAY provide an option to disable UDP checksums for data messages. It | is recommended that UDP checksums always be enabled on control | packets. `---- > In what "other" cases are you saying we need to do IPsec transport mode > through NAT? Someone gets a private address, and does plain IPsec > transport mode through NAT! to whom? and why? Well, in case you want to do something else than VPN; if you limit your designs to VPN cases only, they CAN be used only for VPN cases (and I know for a fact that IPsec is being used in very strange applications these days, although I can't speak of them). > Well sounds familiar: we don't know how it will be used, or who needs it, > but it has to be there, and we will bend over backwards to accomplish it. Yes, right, learn to read RFC before whining. L2TP, for example, is out there. > > Or, in tunnel mode, actually (*gasp*) more than one client behind large NAT > > accessing (*gasp*) SAME security gateway! > > > > High probability of success my .. foot. > I prefer a civilized debate, but if you insist... "Mommy, she started it!" > I said, "if we somehow relate the SPIs in a pair", the NAT box can take > advantage of that to demultiplex. It's a very simple idea: make one spi > (or part of it) a hash of the other so that the NAT box can relate a pair > of SPIs. We have this working in our products. Whole point of SPI's is that they're values that are convenient for the receiver to handle. Thus, having them mandated by either remote SPI selection, or some mystical 'NAT compatibility hash function' sounds not-so-convenient to me. What do you do in case of collisions? Not let traffic through? One big server can have say, 10k SAs up at any time, so chance of collision _does_ exist there, and solution that works on best-effort basis isn't very good one. Also, finally, I haven't heard of this being documented practice and until it is, it's unfortunately something that _might_ work for you but not others. Same could be said also of some other NAT-T approaches we've played with, but I believe mr. Dixon will talk about them in the next IETF. Where's your draft on this SPI magic? If we resort to 'my proprietary solution is better than yours', I don't think we should be on IETF mailing list, but instead playing on the sandbox and contesting who has the best toy.. We can do this by email if you wish. > > > Well, it's not pretty, but that is the inherent nature of NAT itself. > > It's far from pretty. > -Adding an encapsulation overhead of > 20 bytes is very pretty! we have > people already screaming about the overhead that ESP adds! > > -Modifing IKE to do "NAT discovery" is very pretty! IKE isn't doing much > yet, so lets add more. > > -Using adhoc keepalives schemes to maintain the unpredictable NAT > translations is very very pretty! I'd like to see a big NAT box that has VPN-passthrough for N users to M servers, where it doesn't expire mappings at all (because obviously otherwise it breaks connectivity if the user say, goes for lunch in the middle). You _should_ know how big NATs some ISPs have already rolled out. Infinite memory, anyone? > -Most of all, massive hand waving about "built-in host NAT implementation > within the IPsec stack" is the most prettiest of all It isn't mandatory; however, it makes possible what the simple 'passthru' fails in. > Probably NAT and pretty cannot be in the same sentence for most of us > anyway. So, let's not focus on the "pretty" factor of the solutions. At least something I can agree with.. > chinna narasimha reddy pellacuru > s/w engineer -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ipsec@lists.tislabs.com Wed Feb 27 09:29:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RHTb301178; Wed, 27 Feb 2002 09:29:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02247 Wed, 27 Feb 2002 11:38:31 -0500 (EST) To: "Chinna N.R. Pellacuru" Cc: Markus Stenberg , From: Derek Atkins Subject: Re: NAT Traversal References: Date: 27 Feb 2002 11:49:51 -0500 In-Reply-To: Message-ID: Lines: 75 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" writes: > Could you elaborate this scenario more. What/who are you doing transport > mode with and what kind of applications are generating this traffic? Ok, here's an example: Assumption: My home LAN is insecure! It's sitting on a wireless network, I don't know who may be listening in on it. Now, based on that assumption, here's my scenario: I've got a laptop that I use as my primary environment, but I use a bunch of network services off my home network. Keep in mind that my home network is insecure -- I do not trust it! Therefore, I want to setup IPsec between my laptop and each of my home servers. So, I setup IPsec transport between my laptop and my file server to protect my file system traffic. I setup IPsec with my mail server so I can securely send and receive email. Expand until you have a full mesh of transport-mode IPsec connections! When I travel, I want to continue doing this. I don't want to change my behavior just because I happen to be sitting behind a NAT (and no, Phill, I wasn't talking about IETF -- I was actually referring to Usenix Security). This way I can work the same (modulo network latencies) regrdless of my current physical location. > In general we see people running tunnel mode in this case to a border > security gateway or a remote access aggregator, and access the machines > within the network which is behind the aggregator. Or people could run > L2TP or GRE to a border router (if they want multicast), and run IPsec > transport mode on those tunnels. Of course that's how you see it, but that's not the only way that IPsec can be run. The original goal of IPsec (assuming you were around for those discussions in '92-93) were to enable end-to-end IPsec. If I tunneled back to my home LAN it would still violate assumption #1, that my home LAN is insecure. I want end-to-end security; tunneling to a security gateway does not provide that. > Consider a sample network at a conference which gives out private > addresses and runs NAT at its border > > laptop+-----------+NAT+-----( cloud )-------+IPsec peer > > laptop got an address 10.0.0.5 > NAT box is going to translate it to say 5.0.0.1 > IPsec peer is 6.0.0.1 > > Now, IPsec proxy identities are 10.0.0.5 and 6.0.0.1. > > Question1: So, do the applications on the IPsec peer think that they are > talking to 10.0.0.5 or do they think they are talking to 5.0.0.1? It doesn't matter. The Security Association has a binding to: Certificate, RSA, id=Derek Atkins or perhaps Certificate, RSA, id=derek-laptop.ihtfp.com The point being that IPsec knows who I am regardless of the IP address. The IP address can be anything, and that's ok. Applications that want to depend on IPsec for security should not key off the IP Address; they should key off the SA. The SA knows all. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Feb 27 09:31:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RHVj301237; Wed, 27 Feb 2002 09:31:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02239 Wed, 27 Feb 2002 11:38:00 -0500 (EST) Message-ID: <003d01c1bfae$c6c02360$0101a8c0@mv.lucent.com> From: "David W. Faucher" To: "Chinna N.R. Pellacuru" , "Derek Atkins" Cc: "Markus Stenberg" , References: Subject: Re: NAT Traversal Date: Wed, 27 Feb 2002 08:00:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To build on this scenario, assume that the laptop (behind the nat) wants to communicate with an IPSec peer behind a corporate gateway through which all traffic must be IPSec protected. ------------ Transport mode IPSec ------------ | | | --------- Tunnel mode IPSec ---- | | | | laptop+-----+NAT+---( cloud )----+GW+---+IPsec peer Wouldn't there be a requirement that the tunnel mode IPSec SAs be setup prior to negotiating the transport mode IPSec SAs? The reason being that the GW would be performing NAT for those cases where the laptop is using private addresses thus changing the addresses the IPSec peer would see. ----- Original Message ----- From: "Chinna N.R. Pellacuru" To: "Derek Atkins" Cc: "Markus Stenberg" ; Sent: Tuesday, February 26, 2002 9:20 PM Subject: Re: NAT Traversal | On 26 Feb 2002, Derek Atkins wrote: | | > "Chinna N.R. Pellacuru" writes: | > | > > In what "other" cases are you saying we need to do IPsec transport mode | > > through NAT? Someone gets a private address, and does plain IPsec | > > transport mode through NAT! to whom? and why? | > | > Here's an example: A person at a conference who's laptop is setup to | > perform RSA-based transport-mode opportunistic encryption, but where | > the conference is sitting on a NAT? I've been to conferences where | > they conference LAN is sitting behind a NAT, but I would still like to | > be able to use my laptop and the services it has the same way I would | > if I were NOT sitting behind a NAT. To my laptop, it shouldn't | > matter. | > | > Keep in mind that the user who wants to run IPsec and the manager who | > runs the network with a NAT may NOT be the same person! | > | | Could you elaborate this scenario more. What/who are you doing transport | mode with and what kind of applications are generating this traffic? | | In general we see people running tunnel mode in this case to a border | security gateway or a remote access aggregator, and access the machines | within the network which is behind the aggregator. Or people could run | L2TP or GRE to a border router (if they want multicast), and run IPsec | transport mode on those tunnels. | | Consider a sample network at a conference which gives out private | addresses and runs NAT at its border | | laptop+-----------+NAT+-----( cloud )-------+IPsec peer | | laptop got an address 10.0.0.5 | NAT box is going to translate it to say 5.0.0.1 | IPsec peer is 6.0.0.1 | | Now, IPsec proxy identities are 10.0.0.5 and 6.0.0.1. | | Question1: So, do the applications on the IPsec peer think that they are | talking to 10.0.0.5 or do they think they are talking to 5.0.0.1? | | You can't have the applications on IPsec peer to expect the traffic to be | coming from a private address space(10.0.0.5 in our case), of which he has | no knowledge about, and only the network administrator of the conference | has control over. IPsec peer cannot route traffic based on the private | addresses becuase it has no prior knowledge or control of the private | address space, and there could be overlapping private address spaces. We | do IPsec after routing. If we can't route properly, we won't even get to | IPsec. So, let's say the address that is expected is address that NAT | gives it, which is 5.0.0.1. | | Because the IPsec proxy identities are 10.0.0.5 and 6.0.0.1, the NAT | decapsulation process will need to change the source address from 5.0.0.1 | to 10.0.0.5 before checking the packet against the SADB. This check is for | seeing whether the packet matches the proxy identities negotiated for this | SA. After that we need to use the appropriate source IP address based on | the answer to Question1. If the applications are expecting 5.0.0.1, then | before we ship the datagram to the applications we need to change the | source IP address on the datagram back to 5.0.0.1 after the SADB check. | | Say the NAT box uses a source port of 9999 in the UDP encapsulation header | for your laptop. For another laptop it uses 8888. Now if both the laptops | are talking to the IPsec peer, the return traffic will all be traffic to | 5.0.0.1, because applications only know about 5.0.0.1. How will the IPsec | layer decide which SA to use (hence which UDP port to use in the UDP | encapsulation header)? If we don't use the right UDP port, the NAT box | cannot demultiplex properly between the laptops. | | Now if you want to make IPsec even more NAT aware, we need to keep track | of the source and destination ports of the data traffic in the IPsec layer | (in addition to ports in the UDP encapsulation header). Now if the first | laptop was doing TCP from port 5000 to 23, and the second laptop is doing | TCP from port 6000 to 23, then we can store this information in the | IPsec-NAT translation table and use that information to pick up the right | IPsec SA. This would NOT work if both laptops pick up the same source TCP | port though. This also would NOT work for protocols that don't have ports. | Now if it is some other protocol, then the IPsec layer should understand | that protocol and some how keep enough information to pick the right SAs. | This is just a slippery slope. | | -So, people have to do a "built-in host NAT implementation within the | IPsec stack". I just can't imagine how pretty that would be. | | -Curious why this is not being acknowledged in the latest drafts. | | -In order to go through NAT, we will implement the whole of NAT in IPsec! | Now we don't have to worry about how many NATs are there enroute, but we | got this done by having a NAT implementation in each IPsec implementation! | | -Now everytime a new application layer protocol comes along which NAT has | to deal with, we go and change our NAT implementation and also our own NAT | implementation within our IPsec implementation too! | | -So, all NAT boxes have to be upgraded for dealing with non-IPsec traffic | of this new protocol and all IPsec implementations will need to be | upgraded if that new protocol needs to be IPsec protected! | | -Doesn't it look like bending over backwards to accommidate some scenario | we are not sure how/who, if at all, will use it? | | -Even after doing all this, it may not work in some cases. | | I think it is not prudent to judge solutions based on such corner cases. | Even if we consider the above technique as a way to solve this corner | case, it is not easy to implement, and it forces all IPsec implementations | to do a full NAT implementation, and even if we do it, it still may not | work in even more corner cases. | | chinna | | From owner-ipsec@lists.tislabs.com Wed Feb 27 09:34:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RHXx301320; Wed, 27 Feb 2002 09:33:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02255 Wed, 27 Feb 2002 11:40:31 -0500 (EST) To: "Jayant Shukla" Cc: "'Chinna N.R. Pellacuru'" , From: Derek Atkins Subject: Re: NAT Traversal References: <000001c1bf47$367e88d0$0100a8c0@trlhpc1> Date: 27 Feb 2002 11:51:31 -0500 In-Reply-To: <000001c1bf47$367e88d0$0100a8c0@trlhpc1> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Jayant Shukla" writes: > Are you sure you are allowed to use the transport mode?? AFAIK, Section > 4.6.2 of the draft (draft-richardson-ipsec-opportunistic-06.txt) > mandates the use of TUNNEL mode. Your example is not good! Perhaps I was a little careless in my choice of words. I was not specifically refererring to draft-richardson-ipsec-opportunistic-06.txt. I was referring to the overlying concept of "encrypt as much traffic as you can as often as you can". I'm sorry to confuse you. > Regards, > Jayant > http://www.trlokom.com -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Feb 27 09:43:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RHhi301542; Wed, 27 Feb 2002 09:43:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02305 Wed, 27 Feb 2002 12:01:25 -0500 (EST) Message-Id: <200202271712.g1RHCIg79022@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Cc: mobile-ip@sunroof.eng.sun.com Subject: draft-dupont-ipsec-mipv6-00.txt Date: Wed, 27 Feb 2002 18:12:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wrote a draft explaining "how to make IPsec more mobile IPv6 friendly". Please send comments to me or to the IPsec mailing list, *not* the mobile-ip mailing list *please*. Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Feb 27 10:27:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RIRr302598; Wed, 27 Feb 2002 10:27:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02458 Wed, 27 Feb 2002 12:39:40 -0500 (EST) Date: Wed, 27 Feb 2002 09:49:56 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: Markus Stenberg , Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 27 Feb 2002, Derek Atkins wrote: > "Chinna N.R. Pellacuru" writes: > > > Could you elaborate this scenario more. What/who are you doing transport > > mode with and what kind of applications are generating this traffic? > > Ok, here's an example: > > Assumption: My home LAN is insecure! It's sitting on a wireless > network, I don't know who may be listening in on it. you could also choose to run a layer 2 security protocol to secure your home wireless network. Otherwise you need to run IPsec between all the nodes on your home network when one talks to another. That would be a bit hard to manage: a certificate for each of your machines at home, possibly including home appliances which are on the network. > > Now, based on that assumption, here's my scenario: I've got a laptop > that I use as my primary environment, but I use a bunch of network > services off my home network. Keep in mind that my home network is > insecure -- I do not trust it! Therefore, I want to setup IPsec > between my laptop and each of my home servers. > Or possibly one might have an array of laptops and palmtops to access different services from different servers or even simultaneously from the same server on the home network. > So, I setup IPsec transport between my laptop and my file server to > protect my file system traffic. I setup IPsec with my mail server so > I can securely send and receive email. Expand until you have a full > mesh of transport-mode IPsec connections! > OK. Even multiply that by a factor of N, N being the number of access devices one is using. > When I travel, I want to continue doing this. I don't want to change > my behavior just because I happen to be sitting behind a NAT (and no, > Phill, I wasn't talking about IETF -- I was actually referring to > Usenix Security). This way I can work the same (modulo network > latencies) regrdless of my current physical location. You could choose to do IPsec tunnel mode with private addresses from your home network on the inside, but if you don't want to make any concessions at all, you would want to do transport mode only, just like if NAT did not exist. But with the current set of UDP encapsulation drafts, it would add more than 20 bytes for the UDP encapsulation anyway. And, it does NOT work for this scenario. In another mail it was mentioned that it is NOT mandatory that any NAT IPsec solution has to solve this scenario. > > > In general we see people running tunnel mode in this case to a border > > security gateway or a remote access aggregator, and access the machines > > within the network which is behind the aggregator. Or people could run > > L2TP or GRE to a border router (if they want multicast), and run IPsec > > transport mode on those tunnels. > > Of course that's how you see it, but that's not the only way that > IPsec can be run. The original goal of IPsec (assuming you were > around for those discussions in '92-93) were to enable end-to-end > IPsec. If I tunneled back to my home LAN it would still violate > assumption #1, that my home LAN is insecure. > > I want end-to-end security; tunneling to a security gateway does not > provide that. > I've been following IPsec only since '96. I've been a software developer and an implementor of IPsec ever since. I wasnt' around in the discussions of '92-93. End-to-end security is fine, but what authentication infrastructure was envisoned? I hope it wasn't global pre-shared keys. Global pre-shared keys are a rather radical idea that gained popularity in more recent times, probably from frustration over PKI. The idea is that the pre-shared key is "global", IE. a large section or even all users of a particualr authentication infrastructure will use the same pre-shared key. > > Consider a sample network at a conference which gives out private > > addresses and runs NAT at its border > > > > laptop+-----------+NAT+-----( cloud )-------+IPsec peer > > > > laptop got an address 10.0.0.5 > > NAT box is going to translate it to say 5.0.0.1 > > IPsec peer is 6.0.0.1 > > > > Now, IPsec proxy identities are 10.0.0.5 and 6.0.0.1. > > > > Question1: So, do the applications on the IPsec peer think that they are > > talking to 10.0.0.5 or do they think they are talking to 5.0.0.1? > > It doesn't matter. It matters. > > The Security Association has a binding to: > Certificate, RSA, id=Derek Atkins > or perhaps > Certificate, RSA, id=derek-laptop.ihtfp.com > > The point being that IPsec knows who I am regardless of the IP > address. The IP address can be anything, and that's ok. > > Applications that want to depend on IPsec for security should not key > off the IP Address; they should key off the SA. The SA knows all. I agree, this is the IKE Security association, and we don't need to have IP addresses as the IKE identities. I am referring to the end points of the actual data, the application data. If you look at the section that was snipped from this mail, the IP addresses being used and expected are important to do routing. Unless you can route it properly, the data won't even reach IPsec. chinna From owner-ipsec@lists.tislabs.com Wed Feb 27 11:45:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RJj7304191; Wed, 27 Feb 2002 11:45:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02718 Wed, 27 Feb 2002 13:57:27 -0500 (EST) To: "Chinna N.R. Pellacuru" Cc: Markus Stenberg , From: Derek Atkins Subject: Re: NAT Traversal References: Date: 27 Feb 2002 13:58:12 -0500 In-Reply-To: Message-ID: Lines: 94 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" writes: > > Assumption: My home LAN is insecure! It's sitting on a wireless > > network, I don't know who may be listening in on it. > > you could also choose to run a layer 2 security protocol to secure your > home wireless network. Otherwise you need to run IPsec between all the Except there are none that work. WEP certainly doesn't fit this bill. What do you propose? Also, that presupposes that I _WANT_ a closed network. What if I'm a member of an open neighborhood network, ala NYCWireless? > nodes on your home network when one talks to another. That would be a bit > hard to manage: a certificate for each of your machines at home, possibly > including home appliances which are on the network. Why is a certificate-per-machine hard to manage? > End-to-end security is fine, but what authentication infrastructure was > envisoned? I hope it wasn't global pre-shared keys. Global pre-shared keys > are a rather radical idea that gained popularity in more recent times, > probably from frustration over PKI. The idea is that the pre-shared key is > "global", IE. a large section or even all users of a particualr > authentication infrastructure will use the same pre-shared key. IIRC, back in the old days the authentication infrastructure envisioned was the (non-existant) PKI.. The "there will be this global PKI that will solve all our problems" answer, which we know today doesn't quite exist. > > > Question1: So, do the applications on the IPsec peer think that they are > > > talking to 10.0.0.5 or do they think they are talking to 5.0.0.1? > > > > It doesn't matter. > > It matters. No, honestly, it does not. The application should not be making access-control decisions based on the IP address. It should be making access-control decisions based on the cryptographic authentication of the SA. Obviously the packet needs to be routed, which implies that it would see an IP address of the (last) NAT box in the network. For example I've run in this situation: A B C D VMWare Guest -- VMWare Host -- [Internet] - Server In this architecture I'd like a secure end-to-end connection between the VMWare Guest (client) and the Server, but there are TWO nat's involved. Obviously for routing purposes the server needs to send packets back to address D in order to physically get them to the client. Obviously in transport ESP you wouldn't be able to protect the IP address, but that's ok. It's not the IP address itself that's important. It's the fact that the address does not change over time that's important. You want linkability, and that is sufficient. > > The Security Association has a binding to: > > Certificate, RSA, id=Derek Atkins > > or perhaps > > Certificate, RSA, id=derek-laptop.ihtfp.com > > > > The point being that IPsec knows who I am regardless of the IP > > address. The IP address can be anything, and that's ok. > > > > Applications that want to depend on IPsec for security should not key > > off the IP Address; they should key off the SA. The SA knows all. > > I agree, this is the IKE Security association, and we don't need to have > IP addresses as the IKE identities. > > I am referring to the end points of the actual data, the application data. > If you look at the section that was snipped from this mail, the IP > addresses being used and expected are important to do routing. Unless you > can route it properly, the data won't even reach IPsec. Right. In my mind it would use whatever address it would see if you used regular NAT without IPsec. My point is: the fact that I don't know the IP address that you see shouldn't affect my ability to use IPsec with you. > chinna -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Feb 27 11:56:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RJu6304398; Wed, 27 Feb 2002 11:56:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02756 Wed, 27 Feb 2002 14:14:28 -0500 (EST) Date: Wed, 27 Feb 2002 11:25:16 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Markus Stenberg cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <87u1s3p6pa.fsf@ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 27 Feb 2002, Markus Stenberg wrote: > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > On 26 Feb 2002, Markus Stenberg wrote: > > > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > > > On 25 Feb 2002, Derek Atkins wrote: > > > > > "Jayant Shukla" writes: > > > > > > > > > > > > What makes you think the client is involved? IPsec pass-thru implemented > > > > > > in most low end NAT boxes is not complete RSIP as that would require > > > > > > modifications to client and the gateway. > > > > > > > > > > See what I said before about demon-spawn!!! NAT traversal via IPsec > > > > > pass-thru[sic] is just plain wrong, broken, and lots of other words > > > > > that I don't want to use in mixed company. > > > > NAT translates all protocols in a transparent manner using some protocol > > > > parameters, Eg. ports in case of UDP and TCP. I don't see why we should > > > > not try and apply a similar model to IPsec, using cookies and SPIs. > > > > > > > > Sure the SPIs are encrypted during IKE negotiation and the NAT box cannot > > > > see which SPIs are a pair. But if we somehow relate one SPI to another in > > > > each pair, the NAT box can translate ESP traffic with a high probability > > > > of success. > > > > > > Indeed? I'd like to know how my ESP transport mode's TCP checksum is fixed > > > by the NAT box. > > > > > > Note: IPsec is other things than VPNs, too. > > Transport mode in general is used when IPsec is being used to protect > > already tunneled traffic like L2TP or GRE. So, in these cases the TCP > > checksum is not an issue because the original IP datagram tunneled by > > other tunnelling protocols will have the right checksum. Generally these > > original addresses of the original IP datagram will be private addresses > > that we don't want to translate in a VPN. > > And unless you control both ends L2TP implementations, they might have UDP > checksumming on.. *oops* > > And so he quoteth the RFC 2661: > ,---- > | The default for any L2TP implementation is that UDP checksums MUST be > | enabled for both control and data messages. An L2TP implementation > | MAY provide an option to disable UDP checksums for data messages. It > | is recommended that UDP checksums always be enabled on control > | packets. > `---- If you look a telnet packet which is going through L2TP, it looks like: IP ESP [UDP L2TP PPP IP TCP DATA]* where * denotes encrypted and DATA is generally one byte. The inner most IP and TCP header are not touched by anything regardless of what scheme you use, or don't use. That is what I am referring to above. Now a UDP encapsulation of the above packet would look like: IP UDP IKE-NAT ESP [UDP L2TP PPP IP TCP DATA]* Wondering if IESG or someone else has a limit on the number of encapsulations that are allowed. Coming to the UDP checksum in the L2TP UDP encapsulation header the current drafts say: Depending on local policy, one of the following MUST be done: a) If the protocol header after the ESP header is a TCP/UDP header, zero the checksum field in the TCP/UDP header. b) If the protocol header after the ESP header is a TCP/UDP header, recompute the checksum field in the TCP/UDP header. c) If the protocol header after the ESP header is a TCP/UDP header and the peer's real source IP address has been received according to [Kiv00], incrementally recompute the TCP/UDP checksum: - subtract the IP source address in the received packet from the checksum - add the real IP source address received via IKE to the checksum - What "local policy" is being reffered to here? How do you not have to "control both ends of the L2TP implementation" in this case? In general someone always controls both ends of an L2TP deployment. Sane people don't randomly pick an L2TP LNS and try to talk to it, just for the heck of it. You would want to talk to your own L2TP LNS. - If it is OK here to just "recompute the checksum field" why not do it for all ESP decapsulation. We will hack up the checksum in general that we won't have any checksum issues at all. I don't see why checksum is such a big design criteria. It is optional for most protocols, and more and more it is loosing it's popularity. For example IPv6 doesn't have a checksum field. Obviously if people are just hacking up checksums by recomputing them before passing on to the upper layers, it is seen more as a pain than a benefit. - There is NOTHING special about your solution in dealing with checksums. > > > In what "other" cases are you saying we need to do IPsec transport mode > > through NAT? Someone gets a private address, and does plain IPsec > > transport mode through NAT! to whom? and why? > > Well, in case you want to do something else than VPN; if you limit your > designs to VPN cases only, they CAN be used only for VPN cases (and I know > for a fact that IPsec is being used in very strange applications these > days, although I can't speak of them). > Please save us from that crap about special needs that no one knows about. I am sure the rest of us don't have time to go through it. > > Well sounds familiar: we don't know how it will be used, or who needs it, > > but it has to be there, and we will bend over backwards to accomplish it. > > Yes, right, learn to read RFC before whining. L2TP, for example, is out there. > Looks like you have read a lot of RFCs. That's good. Also try to understand basic practical deployments of those protocols that you read about. That will help you from not coming up with weird schemes for imaginary special cases. > > > Or, in tunnel mode, actually (*gasp*) more than one client behind large NAT > > > accessing (*gasp*) SAME security gateway! > > > > > > High probability of success my .. foot. > > I prefer a civilized debate, but if you insist... > > "Mommy, she started it!" > I can understand your frustration. Sorry to be the one to spoil your party here. Massive hand waving will only get you so far. It's really amazing that you made it upto "last call". Next time try to come up with something that will work. Get used to it, and try not to take it personally. You will grow up someday, but until then ask your mom or some other adult to proof read your mails before posting it to a large audience like this working group. > > I said, "if we somehow relate the SPIs in a pair", the NAT box can take > > advantage of that to demultiplex. It's a very simple idea: make one spi > > (or part of it) a hash of the other so that the NAT box can relate a pair > > of SPIs. We have this working in our products. > > Whole point of SPI's is that they're values that are convenient for the > receiver to handle. Thus, having them mandated by either remote SPI > selection, or some mystical 'NAT compatibility hash function' sounds > not-so-convenient to me. > OK, it's the prettyness and other vague arguments again: - IKE is a key management protocol. "NAT discovery" doesn't belong in a key management protocol. Go get your own protocol to do weird things like "NAT discovery". We have enough people pulling their hair off, looking at the complexity of IKE. We are trying to simplify it in Son-of-IKE, but looks like some people just don't get it. How does Son-of-IKE do "NAT discovery"?! Why should "NAT discovery" be a requirement for a key management protocol? Yeah, IKE will soon solve all our problems, and we can go home happy and start thinking about the grandson-of-IKE. How convenient! - Cookies are used to identify IKE SAs. Just because you have a bizzare scheme and set the IKE cookies to zero, it doesn't mean that the rest of the world that existed and thrived on the original assumption, should just vanish. What a way to propose a solution! How convenient! - Port 500 is for IKE, not for UDP encapsulated ESP traffic. The rest of the world assumed that, and now that you are coming in later and breaking that assumption, you should deal it somehow, and not expect the rest of the world to just vanish. How convenient! What design principles is your solution based on? Why is not changing a NAT device the "most important" design principle? NAT changes every day to accomidate new protocols. It's not the case that NAT devices don't change at all, and all new protocols have to do UDP encapsulation to get through NAT! We will not change NAT but screw up most of IKE and IPsec! > What do you do in case of collisions? Not let traffic through? One big > server can have say, 10k SAs up at any time, so chance of collision _does_ > exist there, and solution that works on best-effort basis isn't very good > one. Tell me about it. How does your "NAT keepalives" make absolutely sure that the NAT translations are kept alive? Are you sending a keepalive every microsecond to be absolutely sure that no NAT translation expires? What if some NAT box is using a sub microsecond timeout to blow away it's UDP translations. There are practical and acceptable limits for everything. You can very rarely design for the absoute, if at all. In your case if a NAT translation expires for some reason beyond your control (for example a NAT implementation decides to prune it's translations randomly because there are too many translations), then you are completely hosed! ------------------------------------------------------------------ Important note: But if NAT is translating on SPI matching, it can always setup the translations again just by matching the SPIs. ------------------------------------------------------------------ We all know what happens to chatty protocols that MUST send a lot of traffic to work. They just die. Ever wonder why most IT administratos want to get rid of Apple Talk. > > Also, finally, I haven't heard of this being documented practice and until > it is, it's unfortunately something that _might_ work for you but not > others. Same could be said also of some other NAT-T approaches we've > played with, but I believe mr. Dixon will talk about them in the next > IETF. Where's your draft on this SPI magic? > > If we resort to 'my proprietary solution is better than yours', I don't > think we should be on IETF mailing list, but instead playing on the sandbox > and contesting who has the best toy.. We can do this by email if you wish. Good point. We'll write up an ID and submit it. You can discuss possible solutions until there is some critical mass. You don't have to absoultely start with an ID to even start discussing some ideas. As usual Cisco has a patent application on this technique, and I am 100% sure that Cisco will give it to IETF if this is accepted as a standard, as Cisco has done with so many other things in the IETF. > > > > > Well, it's not pretty, but that is the inherent nature of NAT itself. > > > It's far from pretty. > > -Adding an encapsulation overhead of > 20 bytes is very pretty! we have > > people already screaming about the overhead that ESP adds! > > > > -Modifing IKE to do "NAT discovery" is very pretty! IKE isn't doing much > > yet, so lets add more. > > > > -Using adhoc keepalives schemes to maintain the unpredictable NAT > > translations is very very pretty! > > I'd like to see a big NAT box that has VPN-passthrough for N users to M > servers, where it doesn't expire mappings at all (because obviously > otherwise it breaks connectivity if the user say, goes for lunch in the > middle). > > You _should_ know how big NATs some ISPs have already rolled out. > > Infinite memory, anyone? > As I pointed out before, this is more a FATAL deficiency of your scheme then ours. This is because your scheme ridiculously assumes that you can somehow maintain a NAT translation for as long as you want! I think it's prudent to let NAT do it's job, so that it knows what it is doing. This is more natural, and this is how NAT deals with all protocols under the sun. But as usual, IPsec want's to act special. We are special, we are immortal, we are a "security protocol"! Ever wonder why customers are buying those "IPsec pass-through" boxes like crazy? Because they work and it is simple and elegant and because of it's simplicity they are cheap. I hope that in the best interest of the customers a good working solution gets standardized, not something that is bizzare and does NOT work. > > -Most of all, massive hand waving about "built-in host NAT implementation > > within the IPsec stack" is the most prettiest of all > > It isn't mandatory; however, it makes possible what the simple 'passthru' > fails in. Please stop this hand waving atleast until someone gets back to me on the details of how this will work. I am yet to receive a clarification on the scenario I described in my other mail. For now let's just say that no solution can handle this scenario, and it is not a requirement to move forward. Expect to see our ID soon, and you can try and poke holes in our approach. It's nothing special. It's just the IPsec pass-through with the added SPI matching to give NAT more intelligence about IPsec. chinna > > > Probably NAT and pretty cannot be in the same sentence for most of us > > anyway. So, let's not focus on the "pretty" factor of the solutions. > > At least something I can agree with.. > > > chinna narasimha reddy pellacuru > > s/w engineer > > -Markus > > -- > Markus Stenberg of SSH Communications Security (www.ssh.com) > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Feb 27 12:22:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RKMb305177; Wed, 27 Feb 2002 12:22:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02830 Wed, 27 Feb 2002 14:39:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15485.14453.598786.187116@pkoning.dev.equallogic.com> Date: Wed, 27 Feb 2002 14:50:13 -0500 From: Paul Koning To: pcn@cisco.com Cc: ipsec@lists.tislabs.com Subject: Re: NAT Traversal References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chinna" == Chinna N R Pellacuru writes: Chinna> On 27 Feb 2002, Derek Atkins wrote: >> ... >> Assumption: My home LAN is insecure! It's sitting on a wireless >> network, I don't know who may be listening in on it. Chinna> you could also choose to run a layer 2 security protocol to Chinna> secure your home wireless network. Which one? Not WEP, since it's not a security protocol. paul From owner-ipsec@lists.tislabs.com Wed Feb 27 13:03:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RL3n306177; Wed, 27 Feb 2002 13:03:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02975 Wed, 27 Feb 2002 15:13:40 -0500 (EST) Date: Wed, 27 Feb 2002 12:23:54 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Derek Atkins cc: Markus Stenberg , ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 27 Feb 2002, Derek Atkins wrote: > "Chinna N.R. Pellacuru" writes: > > > > Assumption: My home LAN is insecure! It's sitting on a wireless > > > network, I don't know who may be listening in on it. > > > > you could also choose to run a layer 2 security protocol to secure your > > home wireless network. Otherwise you need to run IPsec between all the > > Except there are none that work. WEP certainly doesn't fit this > bill. What do you propose? > > Also, that presupposes that I _WANT_ a closed network. What if I'm > a member of an open neighborhood network, ala NYCWireless? Are you saying that doing layer 2 encryption will be impossible. If not WEP some other protocol will do it given reasonable requirements. I would be surprised if no one is working on it. There should be some requirements for people to come up with WEP in the first place. > > > nodes on your home network when one talks to another. That would be a bit > > hard to manage: a certificate for each of your machines at home, possibly > > including home appliances which are on the network. > > Why is a certificate-per-machine hard to manage? > We don't yet have a certificate per person, it will probably be some time before we can have a certifiate per device. > > End-to-end security is fine, but what authentication infrastructure was > > envisoned? I hope it wasn't global pre-shared keys. Global pre-shared keys > > are a rather radical idea that gained popularity in more recent times, > > probably from frustration over PKI. The idea is that the pre-shared key is > > "global", IE. a large section or even all users of a particualr > > authentication infrastructure will use the same pre-shared key. > > IIRC, back in the old days the authentication infrastructure > envisioned was the (non-existant) PKI.. The "there will be this > global PKI that will solve all our problems" answer, which we know > today doesn't quite exist. > Exactly. > > > > Question1: So, do the applications on the IPsec peer think that they are > > > > talking to 10.0.0.5 or do they think they are talking to 5.0.0.1? > > > > > > It doesn't matter. > > > > It matters. > > No, honestly, it does not. The application should not be making > access-control decisions based on the IP address. It should be making > access-control decisions based on the cryptographic authentication of > the SA. > It's not about access control. > Obviously the packet needs to be routed, which implies that it would > see an IP address of the (last) NAT box in the network. For example > I've run in this situation: > > A B C D > VMWare Guest -- VMWare Host -- [Internet] - Server > > In this architecture I'd like a secure end-to-end connection between > the VMWare Guest (client) and the Server, but there are TWO nat's > involved. Obviously for routing purposes the server needs to send > packets back to address D in order to physically get them to the > client. > > Obviously in transport ESP you wouldn't be able to protect the IP > address, but that's ok. It's not the IP address itself that's > important. It's the fact that the address does not change over time > that's important. You want linkability, and that is sufficient. > I am referring to the routing decision that the IP stack on the Server has to make on the return traffic from the applications running on the server, back to the client. Are you assuming that the Server is not multi homed, and there is only one wireless network it is connected to. It could also be connected to a high bandwidth optical ring within the house for whatever reason. We don't know what kind of address spaces these different networks will use, and so we can't just inject a route to a private address that the client got somewhere into the global routing table. You would have to inject the route to the global IP address that the NAT gave for this to work on a multi-homed server, and in some cases even on a single homed server (what if the server and the home network is also a private network, and the address you got in your guest network is already being used by a node in your home network). > > > The Security Association has a binding to: > > > Certificate, RSA, id=Derek Atkins > > > or perhaps > > > Certificate, RSA, id=derek-laptop.ihtfp.com > > > > > > The point being that IPsec knows who I am regardless of the IP > > > address. The IP address can be anything, and that's ok. > > > > > > Applications that want to depend on IPsec for security should not key > > > off the IP Address; they should key off the SA. The SA knows all. > > > > I agree, this is the IKE Security association, and we don't need to have > > IP addresses as the IKE identities. > > > > I am referring to the end points of the actual data, the application data. > > If you look at the section that was snipped from this mail, the IP > > addresses being used and expected are important to do routing. Unless you > > can route it properly, the data won't even reach IPsec. > > Right. In my mind it would use whatever address it would see if you > used regular NAT without IPsec. My point is: the fact that I don't > know the IP address that you see shouldn't affect my ability to use > IPsec with you. Yes, so while decapsulating, you use that address that the last NAT finally gave us, we would jumble with the IP source address to do the SADB check, and then put that address as the source address before shipping the datagram to the applications. On the return traffic, you can't pick the right SA. Please see my previous mail on why this is so. chinna > > > chinna > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Feb 27 14:15:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RMFRi08048; Wed, 27 Feb 2002 14:15:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03151 Wed, 27 Feb 2002 16:18:21 -0500 (EST) Message-Id: <200202272128.g1RLS1K01222@fatty.lounge.org> To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ikev2-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1219.1014845281.1@tibernian.com> Date: Wed, 27 Feb 2002 13:28:01 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An updated IKEv2 draft has been submitted to the I-D editor. Due to the last second rush it might be a while before it appears in the repository. So in the interest of giving everyone a few more days to read and comment I've posted it at: http://www.lounge.org/draft-ietf-ipsec-ikev2-01.txt Comments to the list, please. Enjoy! Dan. From owner-ipsec@lists.tislabs.com Wed Feb 27 17:13:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1S1Dji11961; Wed, 27 Feb 2002 17:13:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03493 Wed, 27 Feb 2002 19:20:56 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" , Subject: RE: draft-ietf-ipsec-ikev2-01.txt Date: Wed, 27 Feb 2002 19:25:25 -0500 Message-ID: <000901c1bfee$6bd94f90$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200202272128.g1RLS1K01222@fatty.lounge.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few comments: ADDRESS-NOTIFICATION 26 Don't understand. huh? Repeated re-keying using Phase 2 without PFS can consume the entropy of the Diffie-Hellman shared secret. Implementers should take note of this fact and set a limit on Phase 2 Exchanges between exponentiations. This memo does not prescribe such a limit. I always hated this text from IKEv1. What does it mean to "consume the entropy" of a secret anyway? How about: "Repeated re-keying using Phase 2 without PFS will increase the amount of data that will be exposed if the Diffie-Hellman key is ever compromised. Rekeying without PFS could also aid an attacker in cryptanalysing encrypted ESP data if a weakness in the PRF algorithm is ever discovered." - All previous proposals (IKEv1, IKEv2, JFK, and SIGMA) were vulnerable to an active attacker answering Alice's message with bogus information. Alice cannot distinguish a legitimate message 2 from a bogus message 2. In this draft we explain how Alice can protect herself from this attack, which is to be willing to continue negotiation with every reply she receives. Only the legitimate Bob will be able to send an acceptable message 4, so the multiple SA's- in-progress will only last until the SA is set up. Solving this sort of DoS attack in which the adversary is either (a) on the same LAN as the responder or (b) located along the data path should be a non-goal. These sorts of adversaries can generally do all sorts of nasty things like (a) arping for you or (b) simply removing your packets from the wire. The danger here is that one SA request by Alice can result in 1000 replies by Bob (and 1000 DHs that Alice has to compute). The best response to this sort of attack is simply to give up on the negotiation and retry after some comfort period. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Wednesday, February 27, 2002 4:28 PM > To: ipsec@lists.tislabs.com > Subject: draft-ietf-ipsec-ikev2-01.txt > > > An updated IKEv2 draft has been submitted to the I-D editor. Due to > the last second rush it might be a while before it appears in the > repository. So in the interest of giving everyone a few more days to > read and comment I've posted it at: > http://www.lounge.org/draft-ietf-ipsec-ikev2-01.txt Comments to the list, please. Enjoy! Dan. From owner-ipsec@lists.tislabs.com Wed Feb 27 17:50:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1S1oki12516; Wed, 27 Feb 2002 17:50:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03627 Wed, 27 Feb 2002 20:12:56 -0500 (EST) From: "Catherine A. Meadows" Date: Wed, 27 Feb 2002 20:24:18 -0500 (EST) Message-Id: <200202280124.UAA08164@liverwurst.fw5540.net> To: ipsec@lists.tislabs.com, dharkins@tibernian.com Subject: Re: draft-ietf-ipsec-ikev2-01.txt Cc: meadows@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan: I've got a question on the use of shared secrets to authenticate messages in the Phase I exchange in ikev2-01. I assume that shared secrets are linked to the peers' identities. The initiator authenticates before it has learned the responder's identity. So, if it authenticates using a shared secret, how does it determine what key to use? Does it assume that the responder's IP address is its identity (as I believe was done in IKEv1), or do we assume that the initiator has some other way of learning the responder's identity? Thanks in advance, Cathy Meadows From owner-ipsec@lists.tislabs.com Thu Feb 28 07:19:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SFJei03989; Thu, 28 Feb 2002 07:19:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04992 Thu, 28 Feb 2002 09:10:23 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: NAT Traversal References: Organization: SSH Communications Security From: Markus Stenberg Date: 28 Feb 2002 15:09:18 +0200 In-Reply-To: Message-ID: <878z9dpxc1.fsf@ssh.com> Lines: 128 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > Whole point of SPI's is that they're values that are convenient for the > > receiver to handle. Thus, having them mandated by either remote SPI > > selection, or some mystical 'NAT compatibility hash function' sounds > > not-so-convenient to me. > OK, it's the prettyness and other vague arguments again: > > - IKE is a key management protocol. "NAT discovery" doesn't belong in a > key management protocol. Go get your own protocol to do weird things like > "NAT discovery". We have enough people pulling their hair off, looking at > the complexity of IKE. We are trying to simplify it in Son-of-IKE, but > looks like some people just don't get it. How does Son-of-IKE do "NAT > discovery"?! Why should "NAT discovery" be a requirement for a key > management protocol? Yeah, IKE will soon solve all our problems, and we > can go home happy and start thinking about the grandson-of-IKE. How > convenient! Setting SPIs by some magic formula sounds of NAT-oriented kludge to me as well. > What design principles is your solution based on? Why is not changing a > NAT device the "most important" design principle? NAT changes every day to > accomidate new protocols. It's not the case that NAT devices don't change > at all, and all new protocols have to do UDP encapsulation to get through > NAT! We will not change NAT but screw up most of IKE and IPsec! Unfortunately you are NOT usually able to choose which type of NAT you are behind. Some of the hotels, ISPs et al whose "Internet Access" I've tried to use have had awful kludge NATs that basically do simple TCP/UDP NAPT without any support for other protocols or application level handling. If 'change all network devices' was applicable solution, I'd say we'd be running IPv6 and not worrying about the legacy issues (such as NAT) at all. Why isn't RSIP out there everywhere if that is a valid assumption? > > What do you do in case of collisions? Not let traffic through? One big > > server can have say, 10k SAs up at any time, so chance of collision _does_ > > exist there, and solution that works on best-effort basis isn't very good > > one. > Tell me about it. How does your "NAT keepalives" make absolutely sure that > the NAT translations are kept alive? Are you sending a keepalive every > microsecond to be absolutely sure that no NAT translation expires? What if > some NAT box is using a sub microsecond timeout to blow away it's UDP > translations. There are practical and acceptable limits for everything. > You can very rarely design for the absoute, if at all. > > In your case if a NAT translation expires for some reason beyond your > control (for example a NAT implementation decides to prune it's > translations randomly because there are too many translations), then you > are completely hosed! > > ------------------------------------------------------------------ > Important note: But if NAT is translating on SPI matching, it can always > setup the translations again just by matching the SPIs. > ------------------------------------------------------------------ What if traffic is (mostly) unidirectional? I believe this match-SPI logic works on assumption that you have traffic going out semi-constantly. Is that valid assumption? In case of some UDP-based streaming applications, for example, I have encountered up to minute of unidirectional traffic. If your NAT happens to reset mappings in 30 seconds (which seems to be industry minimum, barring running out of memory), your stream is screwed half the time. > Good point. We'll write up an ID and submit it. You can discuss possible > solutions until there is some critical mass. You don't have to absoultely > start with an ID to even start discussing some ideas. Obviously. But comparison is unfair if one solution is totally specified and other one is mostly handwaving (I've seen maybe one or two paragraphs about it here). And I believe comparison is what you're very bent on. > I think it's prudent to let NAT do it's job, so that it knows what it is > doing. This is more natural, and this is how NAT deals with all protocols > under the sun. But as usual, IPsec want's to act special. We are special, > we are immortal, we are a "security protocol"! You believe we can actually keep all NATs up to date constantly? By that argument, we could get instant upgrade to IPv6 as well as long as IPv4 worked side-by-side. I don't believe in that. > Ever wonder why customers are buying those "IPsec pass-through" boxes like > crazy? Because they work and it is simple and elegant and because of it's > simplicity they are cheap. The pass-thru works for end-user but not for ISP. In case of single user, you don't need to maintain state and state resets don't hurt (you can have dedicated memory easily enough for few IKE/IPsec SAs). > I hope that in the best interest of the customers a good working solution > gets standardized, not something that is bizzare and does NOT work. Likewise. > > > -Most of all, massive hand waving about "built-in host NAT implementation > > > within the IPsec stack" is the most prettiest of all > > It isn't mandatory; however, it makes possible what the simple 'passthru' > > fails in. > Please stop this hand waving atleast until someone gets back to me on the > details of how this will work. I am yet to receive a clarification on the > scenario I described in my other mail. For now let's just say that no > solution can handle this scenario, and it is not a requirement to move > forward. Read draft-stenberg-ipsec-nat-traversal-02.txt (it's long expired but it's still available on the 'net and it details some design things better than current drafts). Section 3.4 details built-in NAT functionality. > Expect to see our ID soon, and you can try and poke holes in our approach. > It's nothing special. It's just the IPsec pass-through with the added SPI > matching to give NAT more intelligence about IPsec. Looking forward to it. > chinna -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ipsec@lists.tislabs.com Thu Feb 28 08:55:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SGtsi09101; Thu, 28 Feb 2002 08:55:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05195 Thu, 28 Feb 2002 11:01:36 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699A7@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , "Chinna N.R. Pellacuru" Cc: Markus Stenberg , ipsec@lists.tislabs.com Subject: ACC device certificates RE: NAT Traversal Date: Thu, 28 Feb 2002 08:13:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1C072.E178CE40" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_000_01C1C072.E178CE40 Content-Type: text/plain; charset="iso-8859-1" > > nodes on your home network when one talks to another. That > would be a bit > > hard to manage: a certificate for each of your machines at > home, possibly > > including home appliances which are on the network. > > Why is a certificate-per-machine hard to manage? It has been made hard because people have been insisting on applying PKI techniques designed to support authentication of humans to authenticate devices. With a device you can embed a private key during manufacture that is unique to the device. We already do this with cable modems (and no the economics are not prohibitive). I just published a White paper on this subject on the VRSN research web site: http://www.verisignlabs.com/Papers/ACC1.html The basic idea is to embed a private key in the device during manufacture, tie the public key to the serial number of the device using a certificate and use the combination for the SOLE PURPOSE of authenticating the device when it applies to authenticate application keys that are generated in the device during initialization. If the device is decomissioned the applications keys are cleared but the ACC key remains so that the next purchaser can initialize it. The genuinely paranoid (i.e. the military) might have the option of paying a lot more to install their own ACC keys The objective is plug and play for cryptography. Every device should initialize with the absolute minimum of fuss. This needs to be simple enough that your granny can install it. This does not remove the need for certs to authenticate humans. But that is a separate layer of authentication. Phill ------_=_NextPart_000_01C1C072.E178CE40 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1C072.E178CE40-- From owner-ipsec@lists.tislabs.com Thu Feb 28 12:05:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SK5fi15960; Thu, 28 Feb 2002 12:05:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05516 Thu, 28 Feb 2002 14:12:20 -0500 (EST) Date: Thu, 28 Feb 2002 11:23:17 -0800 (PST) From: "Chinna N.R. Pellacuru" To: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <878z9dpxc1.fsf@ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, I would like to request that the visionaries of "IPsec Pass-through" (who were probably banished to the underground in this and other forums), to join us, and help us refine our approach more and come up with a more solid proposal. I would also like to extend the request to everyone (the veterans who can help us technically and also guide us through the IETF process, and frankly THE MORE THE MERRIER). Please join us if you want to help us. If you are skeptical of us due to the flame exchange, honestly, that's not our true nature. Please send me an email. On 28 Feb 2002, Markus Stenberg wrote: > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > I assume that there is not much disagreement on the snipped portions, and hence snipped. > > > Whole point of SPI's is that they're values that are convenient for the > > > receiver to handle. Thus, having them mandated by either remote SPI > > > selection, or some mystical 'NAT compatibility hash function' sounds > > > not-so-convenient to me. > > OK, it's the prettyness and other vague arguments again: > > > > - IKE is a key management protocol. "NAT discovery" doesn't belong in a > > key management protocol. Go get your own protocol to do weird things like > > "NAT discovery". We have enough people pulling their hair off, looking at > > the complexity of IKE. We are trying to simplify it in Son-of-IKE, but > > looks like some people just don't get it. How does Son-of-IKE do "NAT > > discovery"?! Why should "NAT discovery" be a requirement for a key > > management protocol? Yeah, IKE will soon solve all our problems, and we > > can go home happy and start thinking about the grandson-of-IKE. How > > convenient! > > Setting SPIs by some magic formula sounds of NAT-oriented kludge to me as > well. > Yes, we propose a NAT oriented solution. NAT mucks with all protocols that were finalized before it came into existance, and all newer protocols are designed to work with NAT. I think it is not very prudent to try and sneak through NAT, and when you get burnt, give up. We would like to call our solution: ESP Aware NAT (eNAT). Our goal is to make NAT as intelligent as possible about IKE and more importantly ESP, so that NAT doesn't step all over these protocols. > > > > What design principles is your solution based on? Why is not changing a > > NAT device the "most important" design principle? NAT changes every day to > > accomidate new protocols. It's not the case that NAT devices don't change > > at all, and all new protocols have to do UDP encapsulation to get through > > NAT! We will not change NAT but screw up most of IKE and IPsec! > > Unfortunately you are NOT usually able to choose which type of NAT you are > behind. Some of the hotels, ISPs et al whose "Internet Access" I've tried > to use have had awful kludge NATs that basically do simple TCP/UDP NAPT > without any support for other protocols or application level handling. What do these ISPs and hotels advertise? Fast movie downloads at greater than 2Mbps speeds? If any ISP or hotel is serious about their business, it is in their best interest to have the right equipment. I personally would stay away from any entity whose *only* focus is fast movie downloads and doesn't want to listen to legitimate requirements. Or is the assumption that the rest of the world is so dumb. If people were so dumb, they would also put a firewall which only allows TCP port 80. Why don't you use TCP port 80 then. I think that's the feedback we are getting from some of the UDP encapsulation deployments. Use TCP, it works better. Use TCP but don't do retransmissions. Does it sound familiar? TCP translations aren't pruned as aggressively as UDP translations. So, use TCP. Probably you should make the encapsulation scheme generic enough to negotiate what protocol and what port will be used. So, if someone blocks even TCP port 80, then you can do a port scan and pick the port and protocol that is being allowed. We can negotiate this in IKE. Seriously, first IKE can do a port scan, and negotiate the ports and protocols that are being allowed. That way we can get through the dumbest of the dumb boxes out there. We can tell all firewall administrators that doing a port scan is legit, and we are actually a "security protocol" and we have genuine reasons to do it. > > If 'change all network devices' was applicable solution, I'd say we'd be > running IPv6 and not worrying about the legacy issues (such as NAT) at all. I think that is probably another myth. IPv6 will get rid of NAT. NAT is being used for other reasons than just getting over the IPv4 address shortage problem. For example NAT can be used for using a different address space without having to re-number your whole network overnight. And there are those people who live and die by their NAT boxes, because they beleive NAT provides "security by obscurity" also they would have a lot of flexibilty in addressing if they use NATs. Have you heard of NAT-PT, NAT Protocol Translation in IPv6? I think it is too simplistic to assume that NAT will die as soon as IPv6 hits the field, or in the near future. NAT already translates scores of protocols by knowing intimate details of each of the protocols, and there are still dozens on the to-do list to be translated. If upgrading NAT is such a no-no, why are dozens of protocols still waiting on the queue to be translated. > > Why isn't RSIP out there everywhere if that is a valid assumption? > Probably because RSIP is a very generic solution, that is trying to be a one size fits all. It fits everybody somewhat, but no one perfectly?! I am not an expert on RSIP, but I think assuming that RSIP wasn't deployed solely because people were not willing to upgrade their equipment is being foolish. > > > What do you do in case of collisions? Not let traffic through? One big > > > server can have say, 10k SAs up at any time, so chance of collision _does_ > > > exist there, and solution that works on best-effort basis isn't very good > > > one. > > Tell me about it. How does your "NAT keepalives" make absolutely sure that > > the NAT translations are kept alive? Are you sending a keepalive every > > microsecond to be absolutely sure that no NAT translation expires? What if > > some NAT box is using a sub microsecond timeout to blow away it's UDP > > translations. There are practical and acceptable limits for everything. > > You can very rarely design for the absoute, if at all. > > > > In your case if a NAT translation expires for some reason beyond your > > control (for example a NAT implementation decides to prune it's > > translations randomly because there are too many translations), then you > > are completely hosed! > > > > ------------------------------------------------------------------ > > Important note: But if NAT is translating on SPI matching, it can always > > setup the translations again just by matching the SPIs. > > ------------------------------------------------------------------ > > What if traffic is (mostly) unidirectional? I believe this match-SPI logic > works on assumption that you have traffic going out semi-constantly. > > Is that valid assumption? > > In case of some UDP-based streaming applications, for example, I have > encountered up to minute of unidirectional traffic. If your NAT happens to > reset mappings in 30 seconds (which seems to be industry minimum, barring > running out of memory), your stream is screwed half the time. Translations are reset even if there is continuous traffic in one direction?! NAT translations are prime candidates for pruning when there is NO TRAFFIC, NOT when there is unidirectional traffic all the time. What NAT implementations are you basing your design on. Now is the assumption that even the NAT implementations are also dumb, or are you playing around with undergrad student's projects. NAT resetting the translation is NOT a problem in our solution. That is what the note above is saying. This is because we made NAT intelligent enough about ESP that it can reset and re-establish the translation as many times as it wants. > > > > Good point. We'll write up an ID and submit it. You can discuss possible > > solutions until there is some critical mass. You don't have to absoultely > > start with an ID to even start discussing some ideas. > > Obviously. But comparison is unfair if one solution is totally specified > and other one is mostly handwaving (I've seen maybe one or two paragraphs > about it here). And I believe comparison is what you're very bent on. > Let me know what other details you want. I can give you all the details you want in the mean time. But, the fact of the matter is that the whole solution can be described fully in a couple of paragraphs. If you are expecting us to come up with 3 drafts like your solution, then each draft will have only one sentence each. The solution is the "IPsec pass-through" with "SPI matching". The "SPI matching" is done by making one SPI (or part of it) a hash of the other. Now which part of this solution is not clear to you. Most of the details are pretty obvious to anyone who has implemented NAT. There is a NAT translation table, and you should keep the parameters of the protocol that is being translated (SPIs and cookies in our case), in the translation table, and translate the protocol by knowing how the protocol works. If you agree that "IPsec pass-through" generally works, "SPI matching" will only make it more scalable, and predictable. > > > I think it's prudent to let NAT do it's job, so that it knows what it is > > doing. This is more natural, and this is how NAT deals with all protocols > > under the sun. But as usual, IPsec want's to act special. We are special, > > we are immortal, we are a "security protocol"! > > You believe we can actually keep all NATs up to date constantly? By that > argument, we could get instant upgrade to IPv6 as well as long as IPv4 > worked side-by-side. I don't believe in that. Frankly, I am amazed to hear something like this from someone working for a company based in the EU. Ironically, even though I work for a company based in the US, I beleive that people will upgrade to IPv6 as the demand, and pressure builds up. At some point it becomes easy to just upgrade to IPv6, instead of cobbling up your IPv4 network. It depends on which is the less painful. No serious entity runs IPv4 or IPv6 just for the heck of it. All upgrade decisions depend on the pain factor of the various options available. > > > Ever wonder why customers are buying those "IPsec pass-through" boxes like > > crazy? Because they work and it is simple and elegant and because of it's > > simplicity they are cheap. > > The pass-thru works for end-user but not for ISP. In case of single user, > you don't need to maintain state and state resets don't hurt (you can have > dedicated memory easily enough for few IKE/IPsec SAs). How many times do I have to repeat that, our solution allows NAT to reset and re-establish an ESP translation as many times as it wants. In the interest of everyone, please stop your impulsive responses, and take some timeout to understand our position. > > > I hope that in the best interest of the customers a good working solution > > gets standardized, not something that is bizzare and does NOT work. > > Likewise. > > > > > -Most of all, massive hand waving about "built-in host NAT implementation > > > > within the IPsec stack" is the most prettiest of all > > > It isn't mandatory; however, it makes possible what the simple 'passthru' > > > fails in. > > Please stop this hand waving atleast until someone gets back to me on the > > details of how this will work. I am yet to receive a clarification on the > > scenario I described in my other mail. For now let's just say that no > > solution can handle this scenario, and it is not a requirement to move > > forward. > > Read draft-stenberg-ipsec-nat-traversal-02.txt (it's long expired but it's > still available on the 'net and it details some design things better than > current drafts). Section 3.4 details built-in NAT functionality. "built-in NAT functionality"! Yes, I read that thing a long time ago, and still didn't recover from the shock. A whole NAT implementation within the IPsec implementation! I can't beleive that this is even being proposed as a solution. Please see my other mail on this topic. > > > Expect to see our ID soon, and you can try and poke holes in our approach. > > It's nothing special. It's just the IPsec pass-through with the added SPI > > matching to give NAT more intelligence about IPsec. > > Looking forward to it. > I am waiting for some help (one and all, please just send me a note if you are interested). We can have it out soon, because the underlying design is pretty simple. chinna > > chinna > > -Markus > > -- > Markus Stenberg of SSH Communications Security (www.ssh.com) > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Feb 28 12:23:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SKNZi16681; Thu, 28 Feb 2002 12:23:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05608 Thu, 28 Feb 2002 14:47:15 -0500 (EST) Message-ID: <005b01c1c092$6060cf40$4a2c12ce@riverside> From: "Jin Zhang" To: , "Dan Harkins" References: <200202272128.g1RLS1K01222@fatty.lounge.org> Subject: Re: draft-ietf-ipsec-ikev2-01.txt Date: Thu, 28 Feb 2002 11:59:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk my 2 cents: 1) Page 7, sec 2.2 Use of sequence number for message id. AH and ESP both has a sequence number begins with 1, why IKE will begin with 0? Somebody may forget to set the sequence number but still sends out a valid sequence number, personally think 1 is better. 2) Page 4, Section 1.2 Change history. How about most recently first? 3) Page 4 para 5, "If the Responder feels it is under attack,..." To implement the 'FEELS' is much more difficult than 'If the Responder's local policy requires anti-attack...' Anyway, maybe how to implement is not under consideration. 4) The IKEv1 has a seperate RFC regarding OAKLEY/ISAKMP, and IKEv2 combines them together. However, the sequence should be kept consistant. It is maybe better to have section 7 'The IKE Header" moved to an earlier position, in order to avoid situation like that we have HDRs, payloads everywhere before we have a formal introduction to them. 5) Maybe too picky for this one. Page 14 para 3. " To negotiate an SA that does ESP, IPcomp, and AH, ...three proposals... one proposing ESP, ... one proposing AH... and one proposing IPcomp". It should have consistant sequence, say, "ESP, AH and IPcomp" 6) Page 11. Section 2.6 Cookies. " ..the SA is uniquely defined by the recipient's SA identifier ..." From the context, the recipient's SA identifier means the Recipient's SPI (responder cookie). How this value can uniquely define the IKE-SA? You mean ? or ? If so, we still need a hash, there seems no way to be "convenient for the IKE-SA identifier to be an index into a table". I must have missed something? Thanks, Jin ----- Original Message ----- From: "Dan Harkins" To: Sent: Wednesday, February 27, 2002 1:28 PM Subject: draft-ietf-ipsec-ikev2-01.txt > An updated IKEv2 draft has been submitted to the I-D editor. Due to > the last second rush it might be a while before it appears in the > repository. So in the interest of giving everyone a few more days to > read and comment I've posted it at: > > http://www.lounge.org/draft-ietf-ipsec-ikev2-01.txt > > Comments to the list, please. > > Enjoy! > > Dan. > > From owner-ipsec@lists.tislabs.com Thu Feb 28 13:12:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SLCni17735; Thu, 28 Feb 2002 13:12:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05820 Thu, 28 Feb 2002 15:32:23 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15486.35392.127648.448194@ryijy.hel.fi.ssh.com> Date: Thu, 28 Feb 2002 21:51:28 +0200 From: Tero Kivinen To: andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") CC: , Subject: Re: draft-ietf-ipsec-ikev2-01.txt References: <000901c1bfee$6bd94f90$1e72788a@ca.alcatel.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 13 min X-Total-Time: 14 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes: > How about: "Repeated re-keying using Phase 2 without PFS will increase the > amount of data that will be exposed if the Diffie-Hellman key is ever > compromised. Rekeying without PFS could also aid an attacker in > cryptanalysing encrypted ESP data if a weakness in the PRF algorithm is ever > discovered." I like that text. > - All previous proposals (IKEv1, IKEv2, JFK, and SIGMA) were > vulnerable to an active attacker answering Alice's message with bogus > information. Alice cannot distinguish a legitimate message 2 from a > bogus message 2. In this draft we explain how Alice can protect > herself from this attack, which is to be willing to continue > negotiation with every reply she receives. Only the legitimate Bob > will be able to send an acceptable message 4, so the multiple SA's- > in-progress will only last until the SA is set up. > > Solving this sort of DoS attack in which the adversary is either (a) on the > same LAN as the responder or (b) located along the data path should be a > non-goal. Why? There are cases where I would really like to protect against this kind of DoS attacks too... Quite often the attacker cannot for example remove packets (it is just listening), and doing for example arp attacks are easily detectable by the other devices on the network so they might just draw attention to the attacker. Sending faked packet can be done from completely different host (some hacked machine out there in Elboinia), and from different machine every time. This way finding the attackers listening post is much harder, and he can continue the attack much longer. > These sorts of adversaries can generally do all sorts of nasty > things like (a) arping for you or (b) simply removing your packets from the > wire. Yes, but if he starts doing that he draws attention to his machine, and someone will unplug the machine from the network quite soon... > The danger here is that one SA request by Alice can result in 1000 > replies by Bob (and 1000 DHs that Alice has to compute). True, but now it is the initiators choise how many of those he is willing to try. If the connection is very, very important he can simply continue until he succeeds. If he thinks it really doesn't matter even if he cannot read the daily dilbert using ipsec he can just forget the connection immediately. Anyways if both ends are willing to consume enough resources to the exchange then the exchange will succeed finally, no matter the passive listener + active sender type attacker does. Currently you only need one UDP packet for each IKE packet you see to kill all negotiations between two hosts. Also if the attacker needs to flood stuff instead of single packet it again draws more attention towards the attacker (itrace etc). > The best response to this sort of attack is simply to give up on the > negotiation and retry after some comfort period. In same case yes, but lets say you want to go remote server to shut it down because you know that someone is just about to break into it using some newly discovered method (needing some time to actually do the attack) and the attacker really really wants to stop you closing the security hole before he can get in... In that case it really doesn't matter how many diffie-hellman calculations my laptops (and propably all of my friends borrowod laptops too, to distribute my diffie-hellamns) do before they can get it. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Feb 28 13:13:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SLD3i17755; Thu, 28 Feb 2002 13:13:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05819 Thu, 28 Feb 2002 15:32:22 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> Date: Thu, 28 Feb 2002 21:34:36 +0200 From: Tero Kivinen To: pcn@cisco.com ("Chinna N.R. Pellacuru") CC: ipsec@lists.tislabs.com Subject: Re: NAT Traversal References: X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 26 min X-Total-Time: 25 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > Depending on local policy, one of the following MUST be done: > a) If the protocol header after the ESP header is a TCP/UDP > header, zero the checksum field in the TCP/UDP header. > b) If the protocol header after the ESP header is a TCP/UDP > header, recompute the checksum field in the TCP/UDP header. > c) If the protocol header after the ESP header is a TCP/UDP > header and the peer's real source IP address has been received > according to [Kiv00], incrementally recompute the TCP/UDP checksum: > - subtract the IP source address in the received packet > from the checksum > - add the real IP source address received via IKE to the checksum > > - What "local policy" is being reffered to here? Implementations own local policy. If the implementation knows for sure that it's TCP/UDP stack does not care about checksums, it can simply zero them. If the IPsec + NAT-T is working under operating system TCP/UDP stack, and cannot affect the checksumming code of the stack, it needs to recalculate the checksum (either by incremental update or with full packet). > - If it is OK here to just "recompute the checksum field" why not do it > for all ESP decapsulation. Performance reasons. Also it is simply extra stuff if you know that the operating system stack is going to ignore it anyways. > - IKE is a key management protocol. "NAT discovery" doesn't belong in a I agree. Some people in the WG think that we should also allow NATs to live, thus we must cope with them. If you do not agree with the IPsec WG, then you should complain to WG in general. The IPsec WG charter has item: ---------------------------------------------------------------------- The IPSEC working group will restrict itself to the following short-term work items to improve the existing key management protocol (IKE) and IPSEC encapsulation protocols: 1. Changes to IKE to support NAT/Firewall traversal ... ---------------------------------------------------------------------- > - Cookies are used to identify IKE SAs. Just because you have a bizzare Yes. Cookies identify IKE, and there is NOTHING anybody else can assume that the cookies are. For example the one of the son of the ike drafts changes the order of the cookies to fix one problem in IKE (i.e the cookie order will always be receiver, sender, not initiator, responder). Also the sender cookie can change. This means that all the NATs doing IKE cookie magic will be broken again... > - Port 500 is for IKE, not for UDP encapsulated ESP traffic. The rest of > the world assumed that, and now that you are coming in later and breaking > that assumption, you should deal it somehow, and not expect the rest of > the world to just vanish. How convenient! Because of the broken NAT boxes we propably need to do special hack to switch ports on the fly inside phase 1 just to get those broken NAT boxes working. > What design principles is your solution based on? Has to work with existing hardware. When this proposal was first made none of the NAT boxes did this kind of broken magic on the IKE packets, thus it worked fine with NAT boxes out there. Then we suddenly noticed that our fine proposal that worked everywhere has been broken by people doing some kind of magic that do work sometimes somewhere if the phase of the moon is right. > Why is not changing a NAT device the "most important" design > principle? I think second largist (or so) ISP in Finland would be too happy if I go there and say that I want to change their NAT boxes, so that I can run IPsec through it. > NAT changes every day to accomidate new protocols. NAT might change, installed base does not change that often. What I would really like to see to get those broken NAT boxes to support basic IP properly before they start breaking other protocols. If the NAT vendors cannot even get the fragmentation/reassembly working I don't think we can assume they can get anything done properly. > Ever wonder why customers are buying those "IPsec pass-through" boxes like > crazy? Propably because they don't know anything about it and they do not know how it works? They think it might work, and next time when they start using it they will notice that it only works in some limited cases? > Because they work and it is simple and elegant and because of it's > simplicity they are cheap. Considering how much IPsec is now used if we count out all the VPN stuff, I don't think you can say that they work because people buy them... I think most of the customers who buy them haven't run single IPsec session through the boxes. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Feb 28 13:44:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SLiki18583; Thu, 28 Feb 2002 13:44:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05984 Thu, 28 Feb 2002 16:06:27 -0500 (EST) Date: Thu, 28 Feb 2002 16:16:59 -0500 (EST) From: Henry Spencer To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: NAT Traversal In-Reply-To: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 28 Feb 2002, Tero Kivinen wrote: > > - What "local policy" is being reffered to here? > > Implementations own local policy. If the implementation knows for sure > that it's TCP/UDP stack does not care about checksums, it can simply > zero them. There is no such thing as a (standard conforming) TCP/UDP stack which does not care about checksums. Checking checksums is mandatory; discarding packets with bad checksums is mandatory. A UDP implementation may optionally choose not to include a checksum with a packet it generates (by setting the checksum field to zero), but it must still check checksums on incoming packets and discard bad ones. A TCP implementation does not even have that little bit of flexibility; the TCP checksum is not optional. See RFC 1122. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Feb 28 14:30:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SMUTi19697; Thu, 28 Feb 2002 14:30:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06161 Thu, 28 Feb 2002 16:39:41 -0500 (EST) Date: Thu, 28 Feb 2002 11:23:17 -0800 (PST) From: "Chinna N.R. Pellacuru" To: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <878z9dpxc1.fsf@ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, I would like to request that the visionaries of "IPsec Pass-through" (who were probably banished to the underground in this and other forums), to join us, and help us refine our approach more and come up with a more solid proposal. I would also like to extend the request to everyone (the veterans who can help us technically and also guide us through the IETF process, and frankly THE MORE THE MERRIER). Please join us if you want to help us. If you are skeptical of us due to the flame exchange, honestly, that's not our true nature. Please send me an email. On 28 Feb 2002, Markus Stenberg wrote: > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > I assume that there is not much disagreement on the snipped portions, and hence snipped. > > > Whole point of SPI's is that they're values that are convenient for the > > > receiver to handle. Thus, having them mandated by either remote SPI > > > selection, or some mystical 'NAT compatibility hash function' sounds > > > not-so-convenient to me. > > OK, it's the prettyness and other vague arguments again: > > > > - IKE is a key management protocol. "NAT discovery" doesn't belong in a > > key management protocol. Go get your own protocol to do weird things like > > "NAT discovery". We have enough people pulling their hair off, looking at > > the complexity of IKE. We are trying to simplify it in Son-of-IKE, but > > looks like some people just don't get it. How does Son-of-IKE do "NAT > > discovery"?! Why should "NAT discovery" be a requirement for a key > > management protocol? Yeah, IKE will soon solve all our problems, and we > > can go home happy and start thinking about the grandson-of-IKE. How > > convenient! > > Setting SPIs by some magic formula sounds of NAT-oriented kludge to me as > well. > Yes, we propose a NAT oriented solution. NAT mucks with all protocols that were finalized before it came into existance, and all newer protocols are designed to work with NAT. I think it is not very prudent to try and sneak through NAT, and when you get burnt, give up. We would like to call our solution: ESP Aware NAT (eNAT). Our goal is to make NAT as intelligent as possible about IKE and more importantly ESP, so that NAT doesn't step all over these protocols. > > > > What design principles is your solution based on? Why is not changing a > > NAT device the "most important" design principle? NAT changes every day to > > accomidate new protocols. It's not the case that NAT devices don't change > > at all, and all new protocols have to do UDP encapsulation to get through > > NAT! We will not change NAT but screw up most of IKE and IPsec! > > Unfortunately you are NOT usually able to choose which type of NAT you are > behind. Some of the hotels, ISPs et al whose "Internet Access" I've tried > to use have had awful kludge NATs that basically do simple TCP/UDP NAPT > without any support for other protocols or application level handling. What do these ISPs and hotels advertise? Fast movie downloads at greater than 2Mbps speeds? If any ISP or hotel is serious about their business, it is in their best interest to have the right equipment. I personally would stay away from any entity whose *only* focus is fast movie downloads and doesn't want to listen to legitimate requirements. Or is the assumption that the rest of the world is so dumb. If people were so dumb, they would also put a firewall which only allows TCP port 80. Why don't you use TCP port 80 then. I think that's the feedback we are getting from some of the UDP encapsulation deployments. Use TCP, it works better. Use TCP but don't do retransmissions. Does it sound familiar? TCP translations aren't pruned as aggressively as UDP translations. So, use TCP. Probably you should make the encapsulation scheme generic enough to negotiate what protocol and what port will be used. So, if someone blocks even TCP port 80, then you can do a port scan and pick the port and protocol that is being allowed. We can negotiate this in IKE. Seriously, first IKE can do a port scan, and negotiate the ports and protocols that are being allowed. That way we can get through the dumbest of the dumb boxes out there. We can tell all firewall administrators that doing a port scan is legit, and we are actually a "security protocol" and we have genuine reasons to do it. > > If 'change all network devices' was applicable solution, I'd say we'd be > running IPv6 and not worrying about the legacy issues (such as NAT) at all. I think that is probably another myth. IPv6 will get rid of NAT. NAT is being used for other reasons than just getting over the IPv4 address shortage problem. For example NAT can be used for using a different address space without having to re-number your whole network overnight. And there are those people who live and die by their NAT boxes, because they beleive NAT provides "security by obscurity" also they would have a lot of flexibilty in addressing if they use NATs. Have you heard of NAT-PT, NAT Protocol Translation in IPv6? I think it is too simplistic to assume that NAT will die as soon as IPv6 hits the field, or in the near future. NAT already translates scores of protocols by knowing intimate details of each of the protocols, and there are still dozens on the to-do list to be translated. If upgrading NAT is such a no-no, why are dozens of protocols still waiting on the queue to be translated. > > Why isn't RSIP out there everywhere if that is a valid assumption? > Probably because RSIP is a very generic solution, that is trying to be a one size fits all. It fits everybody somewhat, but no one perfectly?! I am not an expert on RSIP, but I think assuming that RSIP wasn't deployed solely because people were not willing to upgrade their equipment is being foolish. > > > What do you do in case of collisions? Not let traffic through? One big > > > server can have say, 10k SAs up at any time, so chance of collision _does_ > > > exist there, and solution that works on best-effort basis isn't very good > > > one. > > Tell me about it. How does your "NAT keepalives" make absolutely sure that > > the NAT translations are kept alive? Are you sending a keepalive every > > microsecond to be absolutely sure that no NAT translation expires? What if > > some NAT box is using a sub microsecond timeout to blow away it's UDP > > translations. There are practical and acceptable limits for everything. > > You can very rarely design for the absoute, if at all. > > > > In your case if a NAT translation expires for some reason beyond your > > control (for example a NAT implementation decides to prune it's > > translations randomly because there are too many translations), then you > > are completely hosed! > > > > ------------------------------------------------------------------ > > Important note: But if NAT is translating on SPI matching, it can always > > setup the translations again just by matching the SPIs. > > ------------------------------------------------------------------ > > What if traffic is (mostly) unidirectional? I believe this match-SPI logic > works on assumption that you have traffic going out semi-constantly. > > Is that valid assumption? > > In case of some UDP-based streaming applications, for example, I have > encountered up to minute of unidirectional traffic. If your NAT happens to > reset mappings in 30 seconds (which seems to be industry minimum, barring > running out of memory), your stream is screwed half the time. Translations are reset even if there is continuous traffic in one direction?! NAT translations are prime candidates for pruning when there is NO TRAFFIC, NOT when there is unidirectional traffic all the time. What NAT implementations are you basing your design on. Now is the assumption that even the NAT implementations are also dumb, or are you playing around with undergrad student's projects. NAT resetting the translation is NOT a problem in our solution. That is what the note above is saying. This is because we made NAT intelligent enough about ESP that it can reset and re-establish the translation as many times as it wants. > > > > Good point. We'll write up an ID and submit it. You can discuss possible > > solutions until there is some critical mass. You don't have to absoultely > > start with an ID to even start discussing some ideas. > > Obviously. But comparison is unfair if one solution is totally specified > and other one is mostly handwaving (I've seen maybe one or two paragraphs > about it here). And I believe comparison is what you're very bent on. > Let me know what other details you want. I can give you all the details you want in the mean time. But, the fact of the matter is that the whole solution can be described fully in a couple of paragraphs. If you are expecting us to come up with 3 drafts like your solution, then each draft will have only one sentence each. The solution is the "IPsec pass-through" with "SPI matching". The "SPI matching" is done by making one SPI (or part of it) a hash of the other. Now which part of this solution is not clear to you. Most of the details are pretty obvious to anyone who has implemented NAT. There is a NAT translation table, and you should keep the parameters of the protocol that is being translated (SPIs and cookies in our case), in the translation table, and translate the protocol by knowing how the protocol works. If you agree that "IPsec pass-through" generally works, "SPI matching" will only make it more scalable, and predictable. > > > I think it's prudent to let NAT do it's job, so that it knows what it is > > doing. This is more natural, and this is how NAT deals with all protocols > > under the sun. But as usual, IPsec want's to act special. We are special, > > we are immortal, we are a "security protocol"! > > You believe we can actually keep all NATs up to date constantly? By that > argument, we could get instant upgrade to IPv6 as well as long as IPv4 > worked side-by-side. I don't believe in that. Frankly, I am amazed to hear something like this from someone working for a company based in the EU. Ironically, even though I work for a company based in the US, I beleive that people will upgrade to IPv6 as the demand, and pressure builds up. At some point it becomes easy to just upgrade to IPv6, instead of cobbling up your IPv4 network. It depends on which is the less painful. No serious entity runs IPv4 or IPv6 just for the heck of it. All upgrade decisions depend on the pain factor of the various options available. > > > Ever wonder why customers are buying those "IPsec pass-through" boxes like > > crazy? Because they work and it is simple and elegant and because of it's > > simplicity they are cheap. > > The pass-thru works for end-user but not for ISP. In case of single user, > you don't need to maintain state and state resets don't hurt (you can have > dedicated memory easily enough for few IKE/IPsec SAs). How many times do I have to repeat that, our solution allows NAT to reset and re-establish an ESP translation as many times as it wants. In the interest of everyone, please stop your impulsive responses, and take some timeout to understand our position. > > > I hope that in the best interest of the customers a good working solution > > gets standardized, not something that is bizzare and does NOT work. > > Likewise. > > > > > -Most of all, massive hand waving about "built-in host NAT implementation > > > > within the IPsec stack" is the most prettiest of all > > > It isn't mandatory; however, it makes possible what the simple 'passthru' > > > fails in. > > Please stop this hand waving atleast until someone gets back to me on the > > details of how this will work. I am yet to receive a clarification on the > > scenario I described in my other mail. For now let's just say that no > > solution can handle this scenario, and it is not a requirement to move > > forward. > > Read draft-stenberg-ipsec-nat-traversal-02.txt (it's long expired but it's > still available on the 'net and it details some design things better than > current drafts). Section 3.4 details built-in NAT functionality. "built-in NAT functionality"! Yes, I read that thing a long time ago, and still didn't recover from the shock. A whole NAT implementation within the IPsec implementation! I can't beleive that this is even being proposed as a solution. Please see my other mail on this topic. > > > Expect to see our ID soon, and you can try and poke holes in our approach. > > It's nothing special. It's just the IPsec pass-through with the added SPI > > matching to give NAT more intelligence about IPsec. > > Looking forward to it. > I am waiting for some help (one and all, please just send me a note if you are interested). We can have it out soon, because the underlying design is pretty simple. chinna > > chinna > > -Markus > > -- > Markus Stenberg of SSH Communications Security (www.ssh.com) > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Feb 28 16:14:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g210Eai22202; Thu, 28 Feb 2002 16:14:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06397 Thu, 28 Feb 2002 18:27:06 -0500 (EST) Message-Id: <200202282336.g1SNaB015585@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: new ISAKMP ping draft In-reply-to: Your message of "Thu, 21 Feb 2002 23:55:19 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Feb 2002 18:36:07 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I submitted a new draft, draft-richardson-ipsec-ikeping-00.txt. It documents two new exchanges for ISAKMP, an echo request/reply. This is primarily intended for diagnostics purposes. There were some initial comments from among those who saw the draft last week: 1) why not use an Informational exchange? In general, my reason to avoid this is because both are essentially components of mainstream ISAKMP/IKE. That is, it is tied strongly to IKE 1.0 as documented. Informational Exchanges can be encrypted and authenticated, can be associated (via the cookies) with active exchanges going on. 2408 says: >4.8 Informational Exchange > > The Informational Exchange is designed as a one-way transmittal of > information that can be used for security association management. The intention is not one, way and is not for SA management. Basically, I'd like to stay completely out of that place. 2) why not use a notify? Well, using a notify means sending it in some kind of exchange, e.g. an Informational Exchange. If not using Informational Exchanges, I see no reason to use a notify. 3) combine with the heartbeat/make-dead systems. These are used to detect a dead phase 1 SA. They are, AFAIK, encrypted Notifies. I do not want the ISAKMP echo request/reply to take any crypto resources (in particular, no entropy!) and I do not want anyone to be confused into thinking that these have anything to do with the things sent within a phase 1 SA. 4) It has been suggested that the cookies match the current IKE style rather than any proposed replacement. I made up the cookie stuff. I didn't want the responder to waste a single iota of entropy, but to do something easily noticable to the packet. I do not really care about the cookies, and upon reflection, the current proposal likely won't get through "IKE enabled" NAT boxes. I'm open to anything. 5) echo response I considered having the responder copy the source IP and port number into the body of the reply. It could even stick it in as its cookie. That would permit a request'or to diagnose that they are in fact behind a NAT. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPH6+5IqHRg3pndX9AQHk2AP9GkqWleMmC1uSEddWWgC4hRNDwEKAgYL1 KgpXD6SxPfe6VhtTaOCtEE90koIKYnNwJNiuRdg09fydhG7zwMsrAurOYU/SVK6G Vx2kXOSMDgdsrP1zLI1iM95s7HKgzlar1n+w8mbQM4ninTqPTmq74VDYGZfU3stB 2ja52RmKAF0= =gYj4 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Feb 28 16:36:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g210aui22726; Thu, 28 Feb 2002 16:36:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06473 Thu, 28 Feb 2002 19:02:31 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Tero Kivinen'" Cc: Subject: RE: draft-ietf-ipsec-ikev2-01.txt Date: Thu, 28 Feb 2002 19:06:58 -0500 Message-ID: <002101c1c0b5$01e7b320$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <15486.35392.127648.448194@ryijy.hel.fi.ssh.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Solving this sort of DoS attack in which the adversary is > either (a) on the > > same LAN as the responder or (b) located along the data > path should be a > > non-goal. > > Why? There are cases where I would really like to protect against this > kind of DoS attacks too... Quite often the attacker cannot for example > remove packets (it is just listening), and doing for example arp > attacks are easily detectable by the other devices on the network so > they might just draw attention to the attacker. It is easy to write software to check if someone is spoofing your IP from your own LAN if you're so inclined, although I suppose they could be silently listening on the LAN, forwarding the cookies to another location and spoofing the responses from there. > Sending faked packet can be done from completely different host > (some hacked machine out there in Elboinia), and from different > machine every time. This way finding the attackers listening post is > much harder, and he can continue the attack much longer. I'm not including those cases because we're talking about attacks against the initiator here. The adversary has to be on the data path in order to learn the initiator's cookie. > > The danger here is that one SA request by Alice can result in 1000 > > replies by Bob (and 1000 DHs that Alice has to compute). > > True, but now it is the initiators choise how many of those he is > willing to try. If the connection is very, very important he can > simply continue until he succeeds. If he thinks it really doesn't > matter even if he cannot read the daily dilbert using ipsec he can > just forget the connection immediately. Well, the new draft of IKEv2 seems to imply that this is the expected behaviour of the initiator (a SHOULD). I have no problems with it being a MAY, but I don't think this should be the default behaviour. You are merely trading one DoS attack for another. > Currently you only need one UDP packet for each IKE packet you see to > kill all negotiations between two hosts. Also if the attacker needs to > flood stuff instead of single packet it again draws more attention > towards the attacker (itrace etc). Let's face it. Most machines out there aren't ultra-reliable under load. So unless you're ultra-confident about your robustness, you shouldn't try to outlast a DoS attack. Also, if you're being swamped with bogus replies then chances are you are dropping some packets. If so, you might as well drop the packets that are 99% likely to be spoofed and focus on giving good QoS to the rest of your flows. If you have some spare cycles, you can try to process some of the spoofed packets in the hope that it really is Bob. Keep in mind that Alice is not necessarily a user sitting in front of the computer who has the ability to abort the connection in real time. I just noticed that with IKEv2 you can avoid this attack against the gateway in a client to gateway scenario (the original responder can take advantage of IKEv2's ability to rekey under the protection of the original phase 1), which is good. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Thursday, February 28, 2002 2:51 PM > To: "Andrew Krywaniuk" > Cc: dharkins@tibernian.com; ipsec@lists.tislabs.com > Subject: Re: draft-ietf-ipsec-ikev2-01.txt > > > andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes: > > How about: "Repeated re-keying using Phase 2 without PFS > will increase the > > amount of data that will be exposed if the Diffie-Hellman > key is ever > > compromised. Rekeying without PFS could also aid an attacker in > > cryptanalysing encrypted ESP data if a weakness in the PRF > algorithm is ever > > discovered." > > I like that text. > > > - All previous proposals (IKEv1, IKEv2, JFK, and SIGMA) were > > vulnerable to an active attacker answering Alice's > message with bogus > > information. Alice cannot distinguish a legitimate > message 2 from a > > bogus message 2. In this draft we explain how Alice can protect > > herself from this attack, which is to be willing to continue > > negotiation with every reply she receives. Only the > legitimate Bob > > will be able to send an acceptable message 4, so the > multiple SA's- > > in-progress will only last until the SA is set up. > > > > Solving this sort of DoS attack in which the adversary is > either (a) on the > > same LAN as the responder or (b) located along the data > path should be a > > non-goal. > > Why? There are cases where I would really like to protect against this > kind of DoS attacks too... Quite often the attacker cannot for example > remove packets (it is just listening), and doing for example arp > attacks are easily detectable by the other devices on the network so > they might just draw attention to the attacker. > > Sending faked packet can be done from completely different host > (some hacked machine out there in Elboinia), and from different > machine every time. This way finding the attackers listening post is > much harder, and he can continue the attack much longer. > > > These sorts of adversaries can generally do all sorts of nasty > > things like (a) arping for you or (b) simply removing your > packets from the > > wire. > > Yes, but if he starts doing that he draws attention to his machine, > and someone will unplug the machine from the network quite soon... > > > The danger here is that one SA request by Alice can result in 1000 > > replies by Bob (and 1000 DHs that Alice has to compute). > > True, but now it is the initiators choise how many of those he is > willing to try. If the connection is very, very important he can > simply continue until he succeeds. If he thinks it really doesn't > matter even if he cannot read the daily dilbert using ipsec he can > just forget the connection immediately. > > Anyways if both ends are willing to consume enough resources to the > exchange then the exchange will succeed finally, no matter the passive > listener + active sender type attacker does. > > Currently you only need one UDP packet for each IKE packet you see to > kill all negotiations between two hosts. Also if the attacker needs to > flood stuff instead of single packet it again draws more attention > towards the attacker (itrace etc). > > > The best response to this sort of attack is simply to give up on the > > negotiation and retry after some comfort period. > > In same case yes, but lets say you want to go remote server to shut it > down because you know that someone is just about to break into it > using some newly discovered method (needing some time to actually do > the attack) and the attacker really really wants to stop you closing > the security hole before he can get in... > > In that case it really doesn't matter how many diffie-hellman > calculations my laptops (and propably all of my friends borrowod > laptops too, to distribute my diffie-hellamns) do before they can get > it. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Thu Feb 28 17:24:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g211Oii23592; Thu, 28 Feb 2002 17:24:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06607 Thu, 28 Feb 2002 19:48:27 -0500 (EST) Message-Id: <200203010059.TAA29105@bcn.East.Sun.COM> Date: Thu, 28 Feb 2002 19:59:51 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: draft-ietf-ipsec-ikev2-01.txt To: ipsec@lists.tislabs.com, dharkins@tibernian.com, meadows@itd.nrl.navy.mil Cc: meadows@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ETi5NERLsOxMFJy87YxlYA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> From: "Catherine A. Meadows" >> I've got a question on the use of shared secrets to authenticate >> messages in the Phase I exchange in ikev2-01. I assume that shared >> secrets are linked to the peers' identities. The initiator authenticates >> before it has learned the responder's identity. So, if it authenticates >> using a shared secret, how does it determine what key to use? >> Does it assume that the responder's IP address is its identity (as >> I believe was done in IKEv1), or do we assume that the initiator has >> some other way of learning the responder's identity? No the responder's identity does not have to be an IP address. The assumption is that the initiator already knows who she is intending to talk to. She looked up Bob's address based on his name "Bob" and mapped it to an IP address. So Alice knows the shared key she shares with "Bob". Radia From owner-ipsec@lists.tislabs.com Thu Feb 28 21:21:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g215LMi00627; Thu, 28 Feb 2002 21:21:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07190 Thu, 28 Feb 2002 23:32:50 -0500 (EST) From: "Jayant Shukla" To: "'Tero Kivinen'" , "'\"Chinna N.R. Pellacuru\"'" Cc: Subject: RE: NAT Traversal Date: Thu, 28 Feb 2002 20:41:06 -0800 Message-ID: <000301c1c0db$4d408790$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > > > - IKE is a key management protocol. "NAT discovery" doesn't belong in a > > I agree. Some people in the WG think that we should also allow NATs to > live, thus we must cope with them. If you do not agree with the IPsec > WG, then you should complain to WG in general. > > The IPsec WG charter has item: > > ---------------------------------------------------------------------- > The IPSEC working group will restrict itself to the following > short-term work items to improve the existing key management protocol > (IKE) and IPSEC encapsulation protocols: > > 1. Changes to IKE to support NAT/Firewall traversal > ... > ---------------------------------------------------------------------- > This charter item came long after you guys had proposed using IKE for NAT discovery etc. Didn't you have any input in getting it into the charter? If so, don't try to justify a wrong by using the charter item as an excuse. > > > What design principles is your solution based on? > > Has to work with existing hardware. When this proposal was first made > none of the NAT boxes did this kind of broken magic on the IKE > packets, thus it worked fine with NAT boxes out there. Then we > suddenly noticed that our fine proposal that worked everywhere has > been broken by people doing some kind of magic that do work sometimes > somewhere if the phase of the moon is right. > > kivinen@ssh.fi This argument just does not hold any water. It's not like your proposal has not changed over past two years. Moreover, the last time you made a big change, these boxes where already out there in numbers. Regards, Jayant From owner-ipsec@lists.tislabs.com Thu Feb 28 21:34:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g215Yvi00837; Thu, 28 Feb 2002 21:34:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07310 Fri, 1 Mar 2002 00:02:35 -0500 (EST) Date: Thu, 28 Feb 2002 21:13:25 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Tero Kivinen cc: ipsec mailling list Subject: Re: NAT Traversal In-Reply-To: <15486.34380.426269.330989@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 28 Feb 2002, Tero Kivinen wrote: > pcn@cisco.com ("Chinna N.R. Pellacuru") writes: > > Depending on local policy, one of the following MUST be done: > > a) If the protocol header after the ESP header is a TCP/UDP > > header, zero the checksum field in the TCP/UDP header. > > b) If the protocol header after the ESP header is a TCP/UDP > > header, recompute the checksum field in the TCP/UDP header. > > c) If the protocol header after the ESP header is a TCP/UDP > > header and the peer's real source IP address has been received > > according to [Kiv00], incrementally recompute the TCP/UDP checksum: > > - subtract the IP source address in the received packet > > from the checksum > > - add the real IP source address received via IKE to the checksum > > > > - What "local policy" is being reffered to here? > > Implementations own local policy. If the implementation knows for sure > that it's TCP/UDP stack does not care about checksums, it can simply > zero them. If the IPsec + NAT-T is working under operating system > TCP/UDP stack, and cannot affect the checksumming code of the stack, > it needs to recalculate the checksum (either by incremental update or > with full packet). "local policy" is only applicable to end system IPsec implementations. If we are dealing with a security gateway IPsec implementation, then it won't be easy to make any assumptions on what the hundreds of applications expect which are running on thousands of hosts behind it. These machines could be running different Operating Systems too. > > > - If it is OK here to just "recompute the checksum field" why not do it > > for all ESP decapsulation. > > Performance reasons. Also it is simply extra stuff if you know that > the operating system stack is going to ignore it anyways. > Calculating the checksum is a very cheap operation. > > - IKE is a key management protocol. "NAT discovery" doesn't belong in a > > I agree. Some people in the WG think that we should also allow NATs to > live, thus we must cope with them. If you do not agree with the IPsec > WG, then you should complain to WG in general. > > The IPsec WG charter has item: > > ---------------------------------------------------------------------- > The IPSEC working group will restrict itself to the following > short-term work items to improve the existing key management protocol > (IKE) and IPSEC encapsulation protocols: > > 1. Changes to IKE to support NAT/Firewall traversal > ... > ---------------------------------------------------------------------- > My only question is why should "NAT discovery" be included in a key management protocol. Why can't it be done as a separate protocol, in and of itself, so that as more generic protocols for "NAT discovery" evolve, we can easily use those. "NAT discovery" is a generic problem that many people are trying to solve. Why do we have to clutter the IKE protocol with another vendor-id? Why should we try and come up with yet another way of discovering NAT when there is already a lot of work done in the NAT related working groups. > > - Cookies are used to identify IKE SAs. Just because you have a bizzare > > Yes. Cookies identify IKE, and there is NOTHING anybody else can > assume that the cookies are. For example the one of the son of the ike > drafts changes the order of the cookies to fix one problem in IKE (i.e > the cookie order will always be receiver, sender, not initiator, > responder). Also the sender cookie can change. This means that all the > NATs doing IKE cookie magic will be broken again... But, the UDP encapsulation scheme tries to use the cookie as a "NON-IKE marker". If cookies only identify the IKE SA, and there is NOTHING anybody else can assume, why is the UDP encapsulation scheme trying to use the cookie as a differentiator of whether the IKE packet is a IKE packet or a packet which has ESP encapsulated in UDP? You can use something else. Possibly a flag in the IKE header? Even if you change the order of the cookies in son-of-ike, the cookies are still being used for identifying an IKE SA. And, how often do we revise a protocol like IKE? "IKE cookie magic" is actually being done by NAT boxes not because the NAT boxes are broken, but because of some broken IPsec implementations! The "IKE cookie magic" is being done by NAT boxes because some IKE implementations cannot deal with a src port other than 500 on the IKE packets! The NAT boxes are trying to workaround broken IPsec boxes. I don't think it is fair to turn around and blame those NAT boxes in this situation. So, for some reason, people felt that upgrading the NAT box by working around a broken IPsec implementation is much easier than fixing and upgrading the IPsec implementation. And, your "most important" design goal is to not touch the NAT box, but only upgrade all IPsec boxes! This supports our assumption that the NAT boxes are the ones which are upgraded all the time, even if it so happens that there are some broken IPsec boxes, and NAT has to come up with a workaround for it. > > > - Port 500 is for IKE, not for UDP encapsulated ESP traffic. The rest of > > the world assumed that, and now that you are coming in later and breaking > > that assumption, you should deal it somehow, and not expect the rest of > > the world to just vanish. How convenient! > > Because of the broken NAT boxes we propably need to do special hack to > switch ports on the fly inside phase 1 just to get those broken NAT > boxes working. > Those NAT boxes are not broken. They are just trying to help out with broken IKE implementations. > > What design principles is your solution based on? > > Has to work with existing hardware. When this proposal was first made > none of the NAT boxes did this kind of broken magic on the IKE > packets, thus it worked fine with NAT boxes out there. Then we > suddenly noticed that our fine proposal that worked everywhere has > been broken by people doing some kind of magic that do work sometimes > somewhere if the phase of the moon is right. > Does "existing hardware" include all existing hardware? UDP doesn't seem to be working with all existing hardware. TCP seems to be the better choice in some situations. If your goal is to work with all existing hardware, then you should consider flexibility in which protocol to use for encapsulation. > > Why is not changing a NAT device the "most important" design > > principle? > > I think second largist (or so) ISP in Finland would be too happy if I > go there and say that I want to change their NAT boxes, so that I can > run IPsec through it. Probably that is the reason they are only the second largest, and not the largest. What would it take to upgrade a handful of NAT boxes wihtout a blip, and that too for such an important protocol like IPsec. To stay competitive ISPs have to upgrade and honor the requirements of its users. If there is no solution, then it's fine, but when there is a solution, if one ISP doesn't upgrade, users will find one that is more sensible. I don't see why upgrading a NAT box is being portrayed as if it is something like upgrading all the switches in a Frame Relay cloud at once. If you look at how NAT works, NAT is probably the simplest of all the upgrades an ISP has to deal with. > > > NAT changes every day to accomidate new protocols. > > NAT might change, installed base does not change that often. What I > would really like to see to get those broken NAT boxes to support > basic IP properly before they start breaking other protocols. If the > NAT vendors cannot even get the fragmentation/reassembly working I > don't think we can assume they can get anything done properly. If basic stuff is broken, then we are hosed anyway. Why bother to even encapsulate ESP in another protocol? > > > Ever wonder why customers are buying those "IPsec pass-through" boxes like > > crazy? > > Propably because they don't know anything about it and they do not > know how it works? They think it might work, and next time when they > start using it they will notice that it only works in some limited > cases? > Firstly, UDP encapsulation will also only work in some limited cases. There are claims of supporting some more *corner* cases by having a "built-in NAT" implementation, which is actually a whole NAT implementation within IPsec. I don't think anyone will actually implement a whole NAT implementation within the IPsec implementation just to cover some corner cases. I know that Cisco has only recently implemented the basic "IPsec pass-through" becuase of customers asking for it. This is deployed in the field, and is working in production networks. These customers are not consumers (not that consumers are not real customers), but real enterprises who run business critical data over IPsec and use NAT. So, saying that the "IPsec pass-through" doesn't work, is just trying to mis-lead everyone here. > > Because they work and it is simple and elegant and because of it's > > simplicity they are cheap. > > Considering how much IPsec is now used if we count out all the VPN > stuff, I don't think you can say that they work because people buy > them... I think most of the customers who buy them haven't run single > IPsec session through the boxes. > -- No, there are real enterprises running their business critical data over "IPsec pass-through" solution. The pressure on Cisco was so high that we had to come up with something in a very short time that will improve the scalability and predictablity of the "IPsec pass-through" solution, by doing the SPI matching. This solution is not something that we just made up. We already have it working. > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Feb 28 22:49:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g216nIi02149; Thu, 28 Feb 2002 22:49:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07487 Fri, 1 Mar 2002 01:10:29 -0500 (EST) Mime-Version: 1.0 X-Sender: karen.seo@po1.bbn.com Message-Id: Date: Fri, 1 Mar 2002 01:31:10 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: new version of ID -- IP Authentication Header (AH) Cc: skent@bbn.com, clynn@bbn.com, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A new version of the AH ID has been submitted to the IETF secretariat. In addition to some clarifications, this draft differs from the previous AH spec (RFC 2402) as follows: o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. Thank you, Karen From owner-ipsec@lists.tislabs.com Thu Feb 28 22:49:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g216nJi02159; Thu, 28 Feb 2002 22:49:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07492 Fri, 1 Mar 2002 01:10:31 -0500 (EST) Mime-Version: 1.0 X-Sender: karen.seo@po1.bbn.com Message-Id: Date: Fri, 1 Mar 2002 01:31:21 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: revised ID -- IP Encapsulating Security Payload (ESP) Cc: skent@bbn.com, clynn@bbn.com, kseo@bbn.com Content-Type: multipart/alternative; boundary="============_-1197158211==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1197158211==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, A revision of the ESP ID has been submitted to the IETF secretariat. This email contains 2 lists describing: 1. changes to the previous draft 2. issues that reviewers raised that did not result in changes. Please let us know if you have any questions, comments, etc. Thank you, Karen The new draft of the ESP ID has the following changes (not counting fixes to typos and grammatical errors) All page numbers refer to the previous draft, not the new one. 1. All 3 of the following sentences should be consistent with the idea that encryption-only service MAY be offered. On Page 4, paragraph 4, first sentence: "An implementation MAY offer confidentiality independent of all other services...." This whole paragraph has been modified per item 2 below. On Page 5, paragraph 2, first bullet: "-- confidentiality-only (SHOULD be supported)" Changed "SHOULD" to "MAY" On Page 33, section 7, first bullet: "Confidentiality-only service -- now a SHOULD, not a MUST Changed "SHOULD" to "MAY" 2. Page 4, Introduction, paragraph 4, has been changed (to make a stronger recommendation against using encryption without integrity) from: "An implementation MAY offer confidentiality independent of all other services. Use of confidentiality without integrity (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service (see [Bel96]). ESP allows confidentiality-only SAs because this may offer considerably better performance and still provide adequate security, e.g., when higher layer authentication/integrity protection is offered independently. However, this standard does not require all ESP implementations to offer this service separately." to: "Using encryption-only for confidentiality is allowed by ESP. However, it should be noted that in general, this will provide defense only against passive attackers. Using encryption without a strong integrity mechanism on top of it (either in ESP or separately in AH) may render the confidentiality service insecure against active attackers [Bel96, Kra01]. Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against active attackers [Kra01]. ESP allows encryption-only SAs because this may offer considerably better performance and still provide adequate security, e.g., when higher layer authentication/integrity protection is offered independently. However, this standard does not require all ESP implementations to offer thi service separately." and the reference [Kra01] has been added [Kra01] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)", CRYPTO' 2001. This paper can be found at: http://eprint.iacr.org/2001/045 3. Page 7, A note has been added before Figure 2, that clarifies that this diagram is for a bits-on-the-wire format... "(Note: This diagram shows bits-on-the-wire. So even if extended sequence numbers are being used, only 32 bits of the Sequence Number will be transmitted (see Section 2.2.1).)" 4. Clarification on Page 14, Section 2.4, first bullet on page has been changed from: o For the purpose of ensuring that the bits to be encrypted ...... If a combined algorithm mode requires transmission of the SPI and Sequence Number to effect integrity, then these data items, and any associated, ICV-equivalent data, are included in the computation.... to: o For the purpose of ensuring that the bits to be encrypted ...... If a combined algorithm mode requires transmission of the SPI and Sequence Number to effect integrity, e.g., replication of the SPI and Sequence Number in the Payload Data, then the replicated versions of these data items, and any associated, ICV-equivalent data, are included in the computation... 5. Page 23. Section 3.3.2.2 the following item has been changed from: "2. adds any necessary padding -- includes optional TFC padding and Padding." to: "2. adds any necessary padding -- includes optional TFC padding and (encryption) Padding." 6. An Appendix on "Extended (64-bit) Sequence Numbers" has been added. The following issues/questions were raised, but did not result in changes to the spec. A. Page 32, Section 5 "Conformance Requirements". For "AES in CBC mode", should there be a default key size (128/192/256/etc)? We will adopt 128 as the default key size, as recently discussed on the list, unless we hear otherwise. B. Page 32, Section 5 "Conformance Requirements". Should 3DES be required for compatibility with existing implementations? The previous version of ESP required DES, not 3DES, so not all compliant existing implementations would offer 3DES. In practice, it is likely to be true that most folks do offer 3DES CBC, but making this a mandatory mode removes the incentive to go to AES CBC, which will be faster. So, this version of ESP does not include 3DES CBC as a mandatory mode. C. Page 32, Section 5 - What should the draft say about a counter mode standard? There are several counter mode proposals floating around as IDs, but it is too early to put anything in the draft yet. The WG will have to select a counter mode standard and decide if it will be a mandatory mode and thus included in the ESP spec, or if it will be an optional mode and thus not part of the ESP spec. D. Page 12, Section 2.2.1 "Extended Sequence Number" -- both ends must know when this feature is used for an SA; however the text says "Use of an Extended Sequence Number (ESN) SHOULD be negotiated by an SA management protocol, although it could also be part of the configuration data for a manually configured SA." The draft says "SHOULD" vs. "MUST" in case someone wants to go with manual configuration of this feature. However, we propose to change this to "MUST" if the WG concurs. --============_-1197158211==_ma============ Content-Type: text/html; charset="us-ascii" revised ID -- IP Encapsulating Security Payload (ESP)
Folks,

A revision of the ESP ID has been submitted to the IETF secretariat.  This email contains 2 lists describing:
        1. changes to the previous draft
        2. issues that reviewers raised that did not result
           in changes.

Please let us know if you have any questions, comments, etc.  Thank you,
Karen

The new draft of the ESP ID has the following changes (not counting fixes to typos and grammatical errors)  All page numbers refer to the previous draft, not the new one.

1. All 3 of the following sentences should be consistent with the idea
   that encryption-only service MAY be offered.

    On Page 4, paragraph 4, first sentence:
     "An implementation MAY offer confidentiality independent of
        all other services...."
                This whole paragraph has been modified per item 2 below.

    On Page 5, paragraph 2, first bullet:
        "-- confidentiality-only (SHOULD be supported)"
                Changed "SHOULD" to "MAY"

    On Page 33, section 7, first bullet:
        "Confidentiality-only service -- now a SHOULD, not a MUST
                Changed "SHOULD" to "MAY"

2. Page 4, Introduction, paragraph 4, has been changed (to make a
   stronger recommendation against using encryption without
   integrity) from:

        "An implementation MAY offer confidentiality independent
        of all other  services.  Use of confidentiality without
        integrity (either in ESP or   separately in AH) may subject
        traffic to certain forms of active   attacks that could
        undermine the confidentiality service (see   [Bel96]).
        ESP allows confidentiality-only SAs because this may offer
        considerably better performance and still provide adequate
        security, e.g., when higher layer authentication/integrity
        protection is offered independently. However, this standard
        does not require all  ESP implementations to offer this
        service separately."

   to:
        "Using encryption-only for confidentiality is allowed by
        ESP. However, it should be noted that in general, this
        will provide defense only against passive attackers.  Using
        encryption without a strong integrity mechanism on top of
        it (either in ESP or separately in AH) may render the
        confidentiality service insecure against active attackers
        [Bel96, Kra01].  Moreover, an underlying integrity service,
        such as AH, applied before encryption does not necessarily
        protect the encryption-only confidentiality against active
        attackers [Kra01]. ESP allows encryption-only SAs because
        this may offer considerably better performance and still
        provide adequate security, e.g., when higher layer
        authentication/integrity protection is offered independently.
        However, this standard does not require all ESP
        implementations to offer thi service separately."

   and the reference [Kra01] has been added

        [Kra01]   Krawczyk, H., "The Order of Encryption and
        Authentication for Protecting Communications (Or: How
        Secure Is SSL?)", CRYPTO' 2001.

   This paper can be found at: http://eprint.iacr.org/2001/045


3. Page 7, A note has been added before Figure 2, that clarifies that
   this diagram is for a bits-on-the-wire format...

        "(Note: This diagram shows bits-on-the-wire.  So even if
        extended sequence numbers are being used, only 32 bits of
        the Sequence Number will be transmitted (see Section
        2.2.1).)"

4. Clarification on Page 14, Section 2.4, first bullet on page
   has been changed from:

      o For the purpose of ensuring that the bits to be encrypted
         ...... If a combined algorithm mode requires transmission
         of the SPI and Sequence Number to effect integrity, then
         these data items, and any associated, ICV-equivalent data,
         are included in the computation....

   to:
       o For the purpose of ensuring that the bits to be encrypted
         ...... If a combined algorithm mode requires transmission
         of the SPI and Sequence Number to effect integrity, e.g.,
         replication of the SPI and Sequence Number in the Payload
         Data, then the replicated versions of these data items,
         and any associated, ICV-equivalent data, are included in
         the computation...

5. Page 23. Section 3.3.2.2 the following item has been changed
   from:

          "2. adds any necessary padding -- includes optional
              TFC padding and Padding."
   to:
          "2. adds any necessary padding -- includes optional
              TFC padding and (encryption) Padding."

6. An Appendix on "Extended (64-bit) Sequence Numbers" has been added.


The following issues/questions were raised, but did not result in changes to the spec.


A. Page 32, Section 5 "Conformance Requirements".  For "AES in CBC   mode", should there be a default key size (128/192/256/etc)?

        We will adopt 128 as the default key size, as recently
        discussed on the list, unless we hear otherwise.

B. Page 32, Section 5 "Conformance Requirements". Should 3DES be
   required for compatibility with existing implementations?

        The previous version of ESP required DES, not 3DES, so not
        all compliant existing implementations would offer 3DES.
        In practice, it is likely to be true that most folks do
        offer 3DES CBC, but making this a mandatory mode removes
        the incentive to go to AES CBC, which will be faster.  So,
        this version of ESP does not include 3DES CBC as a
        mandatory mode.

C. Page 32, Section 5 -  What should the draft say about a counter
   mode standard?

        There are several counter mode proposals floating around
        as IDs, but it is too early to put anything in the draft
        yet.  The WG will have to select a counter mode standard
        and decide if it will be a mandatory mode and thus
        included in the ESP spec,  or if it will be an optional
        mode and thus not part of the ESP spec.

D. Page 12, Section 2.2.1 "Extended Sequence Number" -- both ends must
   know when this feature is used for an SA; however the text says
   "Use of an Extended Sequence Number (ESN) SHOULD be negotiated
   by an SA management protocol, although it could also be part of
   the configuration data for a manually configured SA."

        The draft says "SHOULD" vs. "MUST" in case someone wants
        to go with manual configuration of this feature. However,
        we propose to change this to "MUST" if the WG concurs.

--============_-1197158211==_ma============-- From owner-ipsec@lists.tislabs.com Thu Feb 28 22:54:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g216shi02367; Thu, 28 Feb 2002 22:54:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07530 Fri, 1 Mar 2002 01:22:01 -0500 (EST) Message-ID: <0A02EC2BB62AD611B47700A0CC4197940DE20A@white3.nvc.co.jp> From: Takaoka Takayoshi To: "'Radia Perlman - Boston Center for Networking'" , ipsec@lists.tislabs.com, dharkins@tibernian.com, meadows@itd.nrl.navy.mil Subject: RE: draft-ietf-ipsec-ikev2-01.txt Date: Fri, 1 Mar 2002 15:44:44 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please give me the link of this draft. Best regards, Taka -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@sun.com] Sent: Friday, March 01, 2002 10:00 AM To: ipsec@lists.tislabs.com; dharkins@tibernian.com; meadows@itd.nrl.navy.mil Cc: meadows@itd.nrl.navy.mil Subject: Re: draft-ietf-ipsec-ikev2-01.txt >> From: "Catherine A. Meadows" >> I've got a question on the use of shared secrets to authenticate >> messages in the Phase I exchange in ikev2-01. I assume that shared >> secrets are linked to the peers' identities. The initiator authenticates >> before it has learned the responder's identity. So, if it authenticates >> using a shared secret, how does it determine what key to use? >> Does it assume that the responder's IP address is its identity (as >> I believe was done in IKEv1), or do we assume that the initiator has >> some other way of learning the responder's identity? No the responder's identity does not have to be an IP address. The assumption is that the initiator already knows who she is intending to talk to. She looked up Bob's address based on his name "Bob" and mapped it to an IP address. So Alice knows the shared key she shares with "Bob". Radia