From owner-ipsec@lists.tislabs.com Thu Feb 1 00:09:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04741; Thu, 1 Feb 2001 00:09:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07340 Thu, 1 Feb 2001 02:03:28 -0500 (EST) Reply-To: From: "Vinod Porwal" To: Subject: NAT and IPSEC and Packet Filters Date: Thu, 1 Feb 2001 12:51:08 +0530 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I've scanned through few drafts , articles which talk about NAT and IPSEC. Most of them talk about having IPSEC traffic going through NAT devices. I'am interested only in implementing a Security Gateway (SG) which protects the Private network from the internet (Packet Filters) , does NAT allowing the private network to reach the internet & is able to establish VPN tunnels to other SG. Here there is no need for having traffic being NAT'ed and IPSec'd at the same time. Could some one guide me to few issues that I may have to consider in getting this kind of solution. The interaction between NAT and IPSEC implementaiton that may be required etc.. >From what I see most of the commercial boxes like SonicWall, CheckPoint right now support the above mentioned configuration. Am I right ? Regards, Vinod Porwal. From owner-ipsec@lists.tislabs.com Thu Feb 1 02:21:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA19702; Thu, 1 Feb 2001 02:21:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07766 Thu, 1 Feb 2001 04:28:23 -0500 (EST) Message-ID: <7BFD0278CE22D411B1EE0008C791860401392B44@zjbac004.net.matranortel.com> From: "Nathalie Rivat" To: "vinod.porwal" , ipsec Subject: RE: NAT and IPSEC and Packet Filters Date: Thu, 1 Feb 2001 09:26:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C31.1C2C5F10" 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_01C08C31.1C2C5F10 Content-Type: text/plain; charset="iso-8859-1" Vinod, There is no particular issues about NATing clear IP packets that are forwarded by the IPsec gateway between the Intranet and the Internet. It is just a local policy implementation specifying that you NAT those packets. Just to add another reference that supports this feature : the Contivity VPN switch (Nortel). Regards, Nathalie -----Original Message----- From: Vinod Porwal [mailto:vinod.porwal@ishoni.com] Sent: Thursday, February 01, 2001 8:21 AM To: ipsec Subject: NAT and IPSEC and Packet Filters Hi, I've scanned through few drafts , articles which talk about NAT and IPSEC. Most of them talk about having IPSEC traffic going through NAT devices. I'am interested only in implementing a Security Gateway (SG) which protects the Private network from the internet (Packet Filters) , does NAT allowing the private network to reach the internet & is able to establish VPN tunnels to other SG. Here there is no need for having traffic being NAT'ed and IPSec'd at the same time. Could some one guide me to few issues that I may have to consider in getting this kind of solution. The interaction between NAT and IPSEC implementaiton that may be required etc.. >From what I see most of the commercial boxes like SonicWall, CheckPoint right now support the above mentioned configuration. Am I right ? Regards, Vinod Porwal. ------_=_NextPart_001_01C08C31.1C2C5F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: NAT and IPSEC and Packet Filters

Vinod,

There is no particular issues about NATing clear IP = packets that are forwarded by the IPsec gateway between the Intranet = and the Internet. It is just a local policy implementation specifying = that you NAT those packets.

Just to add another reference that supports this = feature : the Contivity VPN switch (Nortel).

Regards,
Nathalie

-----Original Message-----
From: Vinod Porwal [mailto:vinod.porwal@ishoni.com]
Sent: Thursday, February 01, 2001 8:21 AM
To: ipsec
Subject: NAT and IPSEC and Packet Filters


Hi,

I've scanned through few drafts , articles which talk = about NAT and IPSEC.
Most of them talk about having IPSEC traffic going = through NAT devices.

I'am interested only in implementing a Security = Gateway (SG) which protects
the Private network from the internet (Packet = Filters) ,  does NAT allowing
the private network to reach the internet = &  is able to establish VPN
tunnels to other SG. Here there is no need for = having  traffic being NAT'ed
and IPSec'd at the same time.  Could some one = guide me to few issues that I
may have to consider in getting this kind of = solution.  The interaction
between NAT and IPSEC implementaiton that may be = required etc..

From what I see most of the commercial boxes like = SonicWall, CheckPoint
right now support the above mentioned configuration. = Am I right ?

Regards,

Vinod Porwal.






------_=_NextPart_001_01C08C31.1C2C5F10-- From owner-ipsec@lists.tislabs.com Thu Feb 1 03:15:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24011; Thu, 1 Feb 2001 03:15:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07924 Thu, 1 Feb 2001 05:35:37 -0500 (EST) Reply-To: From: "Vinod Porwal" To: "'Nathalie Rivat'" Cc: "'ipsec'" Subject: RE: NAT and IPSEC and Packet Filters Date: Thu, 1 Feb 2001 16:22:52 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C08C6A.ED125EC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C08C6A.ED125EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Nathalie, What you mean to say is that on the same box I would have to NAT first and then IPSec on the outgoing direction. The IPSec rules also will refer to the Private addresses. That means NAT should not translate (port or address translation) any Traffic that may get tunneled at the IPSec Module ? Probably that could also be just controlled by appropriate policies at the NAT module. Am I right ? Regards, Vinod Porwal. -----Original Message----- From: Nathalie Rivat [mailto:nrivat@nortelnetworks.com] Sent: Thursday, February 01, 2001 2:57 PM To: Vinod Kumar A Porwal; ipsec Subject: RE: NAT and IPSEC and Packet Filters Vinod, There is no particular issues about NATing clear IP packets that are forwarded by the IPsec gateway between the Intranet and the Internet. It is just a local policy implementation specifying that you NAT those packets. Just to add another reference that supports this feature : the Contivity VPN switch (Nortel). Regards, Nathalie -----Original Message----- From: Vinod Porwal [ mailto:vinod.porwal@ishoni.com] Sent: Thursday, February 01, 2001 8:21 AM To: ipsec Subject: NAT and IPSEC and Packet Filters Hi, I've scanned through few drafts , articles which talk about NAT and IPSEC. Most of them talk about having IPSEC traffic going through NAT devices. I'am interested only in implementing a Security Gateway (SG) which protects the Private network from the internet (Packet Filters) , does NAT allowing the private network to reach the internet & is able to establish VPN tunnels to other SG. Here there is no need for having traffic being NAT'ed and IPSec'd at the same time. Could some one guide me to few issues that I may have to consider in getting this kind of solution. The interaction between NAT and IPSEC implementaiton that may be required etc.. >From what I see most of the commercial boxes like SonicWall, CheckPoint right now support the above mentioned configuration. Am I right ? Regards, Vinod Porwal. ------=_NextPart_000_0014_01C08C6A.ED125EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: NAT and IPSEC and Packet Filters
Hi=20 Nathalie,
 
What=20 you mean to say is that on the same box I would have to NAT first and = then IPSec=20 on the outgoing direction.  The IPSec rules also will refer to = the=20 Private addresses. That means NAT should not translate (port or = address=20 translation) any Traffic that may get tunneled at the IPSec Module ? = Probably=20 that could also be just controlled by appropriate policies at the = NAT=20 module. Am I right ?
 
Regards,
 
Vinod=20 Porwal.
 
-----Original = Message-----
From:=20 Nathalie Rivat [mailto:nrivat@nortelnetworks.com]
Sent: = Thursday,=20 February 01, 2001 2:57 PM
To: Vinod Kumar A Porwal;=20 ipsec
Subject: RE: NAT and IPSEC and Packet Filters

Vinod,

There is no particular issues about NATing clear IP = packets=20 that are forwarded by the IPsec gateway between the Intranet and the = Internet.=20 It is just a local policy implementation specifying that you NAT those = packets.

Just to add another reference that supports this = feature : the=20 Contivity VPN switch (Nortel).

Regards,
Nathalie =

-----Original Message-----
From: Vinod=20 Porwal [mailto:vinod.porwal@ishoni.com]=20
Sent: Thursday, February 01, 2001 8:21 AM =
To: ipsec
Subject: NAT and IPSEC = and Packet=20 Filters


Hi,

I've scanned through few drafts , articles which = talk about=20 NAT and IPSEC.
Most of them talk about = having IPSEC=20 traffic going through NAT devices.

I'am interested only in implementing a Security = Gateway (SG)=20 which protects
the Private network from the = internet=20 (Packet Filters) ,  does NAT allowing
the private=20 network to reach the internet &  is able to establish = VPN=20
tunnels to other SG. Here there is no need for = having =20 traffic being NAT'ed
and IPSec'd at the same = time.  Could some one guide me to few issues that I =
may have to consider in getting this kind of solution.  = The=20 interaction
between NAT and IPSEC = implementaiton that=20 may be required etc..

From what I see most of the commercial boxes like = SonicWall,=20 CheckPoint
right now support the above = mentioned=20 configuration. Am I right ?

Regards,

Vinod Porwal.=20






------=_NextPart_000_0014_01C08C6A.ED125EC0-- From owner-ipsec@lists.tislabs.com Thu Feb 1 07:40:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12377; Thu, 1 Feb 2001 07:40:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08586 Thu, 1 Feb 2001 09:50:36 -0500 (EST) Message-ID: <20010201145334.11116.qmail@web1405.mail.yahoo.com> Date: Thu, 1 Feb 2001 06:53:34 -0800 (PST) From: Pyda Srisuresh Subject: RE: NAT and IPSEC and Packet Filters To: vinod.porwal@ishoni.com, "'Nathalie Rivat'" Cc: "'ipsec'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You might want to take a look at RFC 2709. cheers, suresh --- Vinod Porwal wrote: > Hi Nathalie, > > What you mean to say is that on the same box I would have to NAT first and > then IPSec on the outgoing direction. The IPSec rules also will refer to > the Private addresses. That means NAT should not translate (port or address > translation) any Traffic that may get tunneled at the IPSec Module ? > Probably that could also be just controlled by appropriate policies at the > NAT module. Am I right ? > > Regards, > > Vinod Porwal. > > -----Original Message----- > From: Nathalie Rivat [mailto:nrivat@nortelnetworks.com] > Sent: Thursday, February 01, 2001 2:57 PM > To: Vinod Kumar A Porwal; ipsec > Subject: RE: NAT and IPSEC and Packet Filters > > Vinod, > > There is no particular issues about NATing clear IP packets that are > forwarded by the IPsec gateway between the Intranet and the Internet. It is > just a local policy implementation specifying that you NAT those packets. > > Just to add another reference that supports this feature : the Contivity VPN > switch (Nortel). > > Regards, > Nathalie > > -----Original Message----- > From: Vinod Porwal [ mailto:vinod.porwal@ishoni.com] > Sent: Thursday, February 01, 2001 8:21 AM > To: ipsec > Subject: NAT and IPSEC and Packet Filters > > > Hi, > > I've scanned through few drafts , articles which talk about NAT and IPSEC. > Most of them talk about having IPSEC traffic going through NAT devices. > > I'am interested only in implementing a Security Gateway (SG) which protects > the Private network from the internet (Packet Filters) , does NAT allowing > the private network to reach the internet & is able to establish VPN > tunnels to other SG. Here there is no need for having traffic being NAT'ed > and IPSec'd at the same time. Could some one guide me to few issues that I > may have to consider in getting this kind of solution. The interaction > between NAT and IPSEC implementaiton that may be required etc.. > > From what I see most of the commercial boxes like SonicWall, CheckPoint > right now support the above mentioned configuration. Am I right ? > > Regards, > > Vinod Porwal. > > > > > > > ===== __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Feb 1 07:40:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12404; Thu, 1 Feb 2001 07:40:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08543 Thu, 1 Feb 2001 09:41:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 1 Feb 2001 09:40:05 -0500 To: "sankar ramamoorthi" From: Stephen Kent Subject: RE: ipsec error protocol Cc: Content-Type: multipart/alternative; boundary="============_-1231083737==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1231083737==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sankar, > >RE: ipsec error protocolFrom: Stephen Kent >[kent@bbn.com] >>Sent: Wednesday, January 31, 2001 2:59 PM >>To: sankar ramamoorthi >>Cc: ipsec@lists.tislabs.com >>Subject: RE: ipsec error protocol >> >>Sankar, >> >> >> >> >> This is where I was getting confused. How are sequence numbers maintained >> on the outbound side? >> >>as full 64-bit values >> >> >> Is it maintained as a continously incresing 64bit counter? If so >> since the upper 32 bits are not sent over the wire, a replayed packet and a >> genuine packet whose lower 32 bit has rolled over may look the same to >> the receiver of the packet - right? >> >> >>it would look the same until the integrity check was performed. >> >> >>admittedly, this scheme places a limit on receiver window size, >>i.e., it must be less than 2**32. >> >> >>anyone have a problem with that? >> > > >If the receiver window is limited to 2**32 bits, then it means >at 10Gig/sec speeds the receiver has to rekey after 400 seconds. > >Is that acceptable? me thinks you're not reading the words I write! The receiver window does not determine rekey times; it determines how late (in packet delivery order) a packet can arrive at a receiver and still be accepted (vs. being rejected as a replay even when it is not a relay). Steve --============_-1231083737==_ma============ Content-Type: text/html; charset="us-ascii" RE: ipsec error protocol
Sankar,

>RE: ipsec error protocolFrom: Stephen Kent [kent@bbn.com]
>Sent: Wednesday, January 31, 2001 2:59 PM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
>Subject: RE: ipsec error protocol
>
>Sankar,
>
>
>  <snip>
>
>  This is where I was getting confused. How are sequence numbers maintained
>  on the outbound side?
>
>as full 64-bit values
>
>
>  Is it maintained as a continously incresing 64bit counter? If so
>  since the upper 32 bits are not sent over the wire, a replayed packet and a
>  genuine packet whose lower 32 bit has rolled over may look the same to
>  the receiver of the packet - right?
>
>
>it would look the same until the integrity check was performed.
>
>
>admittedly, this scheme places a limit on receiver window size, i.e., it must be less than 2**32.
>
>
>anyone have a problem with that?
>
 
 
If the receiver window is limited to 2**32 bits, then it means
at 10Gig/sec speeds  the receiver has to rekey after 400 seconds.
 
Is that acceptable?

me thinks you're not reading the words I write! The receiver window does not determine rekey times; it determines how late (in packet delivery order) a packet can arrive at a receiver and still be accepted (vs. being rejected as a replay even when it is not a relay).

Steve
--============_-1231083737==_ma============-- From owner-ipsec@lists.tislabs.com Thu Feb 1 08:11:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15096; Thu, 1 Feb 2001 08:11:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08737 Thu, 1 Feb 2001 10:19:38 -0500 (EST) To: Cc: Subject: Re: NAT and IPSEC and Packet Filters References: From: Derek Atkins Date: 01 Feb 2001 10:22:34 -0500 In-Reply-To: "Vinod Porwal"'s message of "Thu, 1 Feb 2001 12:51:08 +0530" Message-ID: Lines: 44 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is easy. On the NAT/SG box, you setup routes that: a) go through IPSec to the remote SG for particular networks, b) go through NAT for the default route This way you will NOT be NAT'ed for the SGs but you WILL be NATed for everything else. Luckily the routing priority is such that this works with a normal routing table. -derek "Vinod Porwal" writes: > Hi, > > I've scanned through few drafts , articles which talk about NAT and IPSEC. > Most of them talk about having IPSEC traffic going through NAT devices. > > I'am interested only in implementing a Security Gateway (SG) which protects > the Private network from the internet (Packet Filters) , does NAT allowing > the private network to reach the internet & is able to establish VPN > tunnels to other SG. Here there is no need for having traffic being NAT'ed > and IPSec'd at the same time. Could some one guide me to few issues that I > may have to consider in getting this kind of solution. The interaction > between NAT and IPSEC implementaiton that may be required etc.. > > From what I see most of the commercial boxes like SonicWall, CheckPoint > right now support the above mentioned configuration. Am I right ? > > Regards, > > Vinod Porwal. > > > > > > -- 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 Thu Feb 1 08:11:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15113; Thu, 1 Feb 2001 08:11:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08731 Thu, 1 Feb 2001 10:19:19 -0500 (EST) To: "sankar ramamoorthi" Cc: "Stephen Kent" , Subject: Re: ipsec error protocol References: From: Derek Atkins Date: 01 Feb 2001 10:19:00 -0500 In-Reply-To: "sankar ramamoorthi"'s message of "Wed, 31 Jan 2001 16:49:39 -0800" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "sankar ramamoorthi" writes: > If the receiver window is limited to 2**32 bits, then it means > at 10Gig/sec speeds the receiver has to rekey after 400 seconds. No, the receiver 'replay' window is limited to 2^32 bits. This means you can only accept packets within this 400-second window, so if a packet gets delayed by 400 seconds it will be dropped (because it is now outside this window). You still only need to rekey every 2^64, which is 400*2^32 seconds, which is a LARGE number. > Is that acceptable? I think the limitation of dropping packets delayed by 400s may be acceptible, provided we're not talking about interplanetary internets. I certainly believe that the 400*2^32 is sufficiently large. -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 Thu Feb 1 08:14:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15189; Thu, 1 Feb 2001 08:14:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08778 Thu, 1 Feb 2001 10:31:43 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A78C90B.7E8475D9@cisco.com> References: <3A6FD6E4.93F510EE@cisco.com> <3A772CDF.4E0AEE26@cisco.com> <3A78C90B.7E8475D9@cisco.com> Date: Thu, 1 Feb 2001 10:34:34 -0500 To: fd@cisco.com From: Stephen Kent Subject: Re: ipsec error protocol Cc: ipsec@lists.tislabs.com 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 KAA08775 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:25 AM +0100 2/1/01, Frédéric Detienne wrote: >Stephen Kent wrote: >> >Obviously, no retransmission of any sort nor any expectation in the >> >order of arrival (replay detection stays as it is): we just ack the >> >biggest packet ID received (piggy backed if possible). >> >> I have to admit that, at this point in the exchange (and trying to >> deal with threads o other lists at the same time) that I'm lost. What >> problem are we trying to solve? Is it the loss of state at the other >> IPsec device, or the parallel crypto chip and sequence number problem >> that Dan raised? > >the loss of state (and only that). Thanks for the clarification. Steve From owner-ipsec@lists.tislabs.com Thu Feb 1 08:14:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15203; Thu, 1 Feb 2001 08:14:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08758 Thu, 1 Feb 2001 10:22:20 -0500 (EST) Message-ID: From: Jorma Soucey To: "'vinod.porwal@ishoni.com'" , "'Nathalie Rivat'" Cc: "'ipsec'" Subject: RE: NAT and IPSEC and Packet Filters Date: Thu, 1 Feb 2001 07:24:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C63.1D998468" 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_01C08C63.1D998468 Content-Type: text/plain; charset="iso-8859-1" Vinod, The last issue of Cisco's Internet Protocol Journal ran a great article on configuring IPSec w/ NAT. It includes references if you want to dig deeper. http://www.cisco.com/warp/public/759/ipj_issues.html The gist of it is, as long as you consistently NAT first, then IPSec (on both ends) you should be fine. -Jorma -----Original Message----- From: Vinod Porwal [mailto:vinod.porwal@ishoni.com] Sent: Thursday, February 01, 2001 5:53 AM To: 'Nathalie Rivat' Cc: 'ipsec' Subject: RE: NAT and IPSEC and Packet Filters Hi Nathalie, What you mean to say is that on the same box I would have to NAT first and then IPSec on the outgoing direction. The IPSec rules also will refer to the Private addresses. That means NAT should not translate (port or address translation) any Traffic that may get tunneled at the IPSec Module ? Probably that could also be just controlled by appropriate policies at the NAT module. Am I right ? Regards, Vinod Porwal. -----Original Message----- From: Nathalie Rivat [mailto:nrivat@nortelnetworks.com] Sent: Thursday, February 01, 2001 2:57 PM To: Vinod Kumar A Porwal; ipsec Subject: RE: NAT and IPSEC and Packet Filters Vinod, There is no particular issues about NATing clear IP packets that are forwarded by the IPsec gateway between the Intranet and the Internet. It is just a local policy implementation specifying that you NAT those packets. Just to add another reference that supports this feature : the Contivity VPN switch (Nortel). Regards, Nathalie -----Original Message----- From: Vinod Porwal [ mailto:vinod.porwal@ishoni.com ] Sent: Thursday, February 01, 2001 8:21 AM To: ipsec Subject: NAT and IPSEC and Packet Filters Hi, I've scanned through few drafts , articles which talk about NAT and IPSEC. Most of them talk about having IPSEC traffic going through NAT devices. I'am interested only in implementing a Security Gateway (SG) which protects the Private network from the internet (Packet Filters) , does NAT allowing the private network to reach the internet & is able to establish VPN tunnels to other SG. Here there is no need for having traffic being NAT'ed and IPSec'd at the same time. Could some one guide me to few issues that I may have to consider in getting this kind of solution. The interaction between NAT and IPSEC implementaiton that may be required etc.. >From what I see most of the commercial boxes like SonicWall, CheckPoint right now support the above mentioned configuration. Am I right ? Regards, Vinod Porwal. ------_=_NextPart_001_01C08C63.1D998468 Content-Type: text/html; charset="iso-8859-1" RE: NAT and IPSEC and Packet Filters
Vinod,
    The last issue of Cisco's Internet Protocol Journal ran a great article on configuring IPSec w/ NAT. It includes references if you want to dig deeper.
    The gist of it is, as long as you consistently NAT first, then IPSec (on both ends) you should be fine.
    -Jorma
-----Original Message-----
From: Vinod Porwal [mailto:vinod.porwal@ishoni.com]
Sent: Thursday, February 01, 2001 5:53 AM
To: 'Nathalie Rivat'
Cc: 'ipsec'
Subject: RE: NAT and IPSEC and Packet Filters

Hi Nathalie,
 
What you mean to say is that on the same box I would have to NAT first and then IPSec on the outgoing direction.  The IPSec rules also will refer to the Private addresses. That means NAT should not translate (port or address translation) any Traffic that may get tunneled at the IPSec Module ? Probably that could also be just controlled by appropriate policies at the NAT module. Am I right ?
 
Regards,
 
Vinod Porwal.
 
-----Original Message-----
From: Nathalie Rivat [mailto:nrivat@nortelnetworks.com]
Sent: Thursday, February 01, 2001 2:57 PM
To: Vinod Kumar A Porwal; ipsec
Subject: RE: NAT and IPSEC and Packet Filters

Vinod,

There is no particular issues about NATing clear IP packets that are forwarded by the IPsec gateway between the Intranet and the Internet. It is just a local policy implementation specifying that you NAT those packets.

Just to add another reference that supports this feature : the Contivity VPN switch (Nortel).

Regards,
Nathalie

-----Original Message-----
From: Vinod Porwal [mailto:vinod.porwal@ishoni.com]
Sent: Thursday, February 01, 2001 8:21 AM
To: ipsec
Subject: NAT and IPSEC and Packet Filters


Hi,

I've scanned through few drafts , articles which talk about NAT and IPSEC.
Most of them talk about having IPSEC traffic going through NAT devices.

I'am interested only in implementing a Security Gateway (SG) which protects
the Private network from the internet (Packet Filters) ,  does NAT allowing
the private network to reach the internet &  is able to establish VPN
tunnels to other SG. Here there is no need for having  traffic being NAT'ed
and IPSec'd at the same time.  Could some one guide me to few issues that I
may have to consider in getting this kind of solution.  The interaction
between NAT and IPSEC implementaiton that may be required etc..

From what I see most of the commercial boxes like SonicWall, CheckPoint
right now support the above mentioned configuration. Am I right ?

Regards,

Vinod Porwal.






------_=_NextPart_001_01C08C63.1D998468-- From owner-ipsec@lists.tislabs.com Thu Feb 1 10:06:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22169; Thu, 1 Feb 2001 10:06:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09330 Thu, 1 Feb 2001 12:10:49 -0500 (EST) From: "sankar ramamoorthi" To: "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Thu, 1 Feb 2001 09:18:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C08C2F.E2EF9EC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C08C2F.E2EF9EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RE: ipsec error protocol>RE: ipsec error protocolFrom: owner-ipsec@lists.tislabs.com on behalf of Stephen Kent [kent@bbn.com] >Sent: Thursday, February 01, 2001 6:40 AM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: RE: ipsec error protocol > >Sankar, > > > >RE: ipsec error protocolFrom: Stephen Kent [kent@bbn.com] > >Sent: Wednesday, January 31, 2001 2:59 PM > >To: sankar ramamoorthi > >Cc: ipsec@lists.tislabs.com > >Subject: RE: ipsec error protocol > > > >Sankar, > > > > > > > > > > This is where I was getting confused. How are sequence numbers maintained > > on the outbound side? > > > >as full 64-bit values > > > > > > Is it maintained as a continously incresing 64bit counter? If so > > since the upper 32 bits are not sent over the wire, a replayed packet and a > > genuine packet whose lower 32 bit has rolled over may look the same to > > the receiver of the packet - right? > > > > > >it would look the same until the integrity check was performed. > > > > > >admittedly, this scheme places a limit on receiver window size, i.e., it must be less than 2**32. > > > > > >anyone have a problem with that? > > > > > If the receiver window is limited to 2**32 bits, then it means > at 10Gig/sec speeds the receiver has to rekey after 400 seconds. > > Is that acceptable? > > >me thinks you're not reading the words I write! The receiver window does not determine rekey times; it determines how late (in packet delivery order) a packet can arrive at a receiver and still be accepted (vs. being rejected as a replay even when it is not a relay). > Agreed - I was not reading the words properly. It was due to my jumping to the conclusion that the upper bound of the receiver window has to be 2**32. That conclusion came from my misunderstanding that only 32 bits of the sequence number space is included in the checksum calculation. I overlooked the part about all the 64 bits of the sequence space being included in the checksum, though Joseph Harwood pointed it out earlier. Thanks for all the explanations. Sorry about the noise. > >Steve ------=_NextPart_000_0006_01C08C2F.E2EF9EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: ipsec error protocol
>RE: ipsec error = protocolFrom:=20 owner-ipsec@lists.tislabs.com on behalf of Stephen Kent [kent@bbn.com]
>Sent: Thursday, February 01, 2001 6:40 AM
>To: = sankar=20 ramamoorthi
>Cc: ipsec@lists.tislabs.com
>Subject: RE: ipsec error=20 protocol
>
>Sankar,
>
>
>  >RE: = ipsec=20 error protocolFrom: Stephen Kent [kent@bbn.com]
>  >Sent: Wednesday, January 31, 2001 2:59=20 PM
>  >To: sankar ramamoorthi
>  >Cc: = ipsec@lists.tislabs.com
>  >Subject: RE: ipsec error protocol
> =20 >
>  >Sankar,
>  >
> =20 >
>  >  <snip>
>  = >
> =20 >  This is where I was getting confused. How are sequence = numbers=20 maintained
>  >  on the outbound side?
> =20 >
>  >as full 64-bit values
>  = >
> =20 >
>  >  Is it maintained as a continously = incresing 64bit=20 counter? If so
>  >  since the upper 32 bits are not = sent=20 over the wire, a replayed packet and a
>  >  genuine = packet=20 whose lower 32 bit has rolled over may look the same to
>  = > =20 the receiver of the packet - right?
>  >
> =20 >
>  >it would look the same until the integrity check = was=20 performed.
>  >
>  >
>  = >admittedly,=20 this scheme places a limit on receiver window size, i.e., it must be = less than=20 2**32.
>  >
>  >
>  >anyone = have a=20 problem with that?
>  >
>
>
>  If = the=20 receiver window is limited to 2**32 bits, then it means
>  at = 10Gig/sec speeds  the receiver has to rekey after 400=20 seconds.
>
>  Is that = acceptable?
>
>
>me=20 thinks you're not reading the words I write! The receiver window does = not=20 determine rekey times; it determines how late (in packet delivery order) = a=20 packet can arrive at a receiver and still be accepted (vs. being = rejected as a=20 replay even when it is not a relay).
>
Agreed - I was not = reading the=20 words properly. It was due to my =20 jumping to
the conclusion that the upper bound of the receiver = window has=20 to
be 2**32. That conclusion came from my misunderstanding that only = 32 bits=20 of
the sequence number space is included in the checksum=20 calculation.
 
I = overlooked the part=20 about all the 64 bits of the sequence space
being included in the = checksum,=20 though Joseph Harwood pointed it out
earlier. Thanks for all the=20 explanations. Sorry about the=20 noise. 
 
>
>Steve
------=_NextPart_000_0006_01C08C2F.E2EF9EC0-- From owner-ipsec@lists.tislabs.com Thu Feb 1 10:07:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22235; Thu, 1 Feb 2001 10:07:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09378 Thu, 1 Feb 2001 12:23:55 -0500 (EST) Message-ID: <3A799C0F.2D44DE1@storm.ca> Date: Thu, 01 Feb 2001 12:25:35 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: vinod.porwal@ishoni.com CC: ipsec@lists.tislabs.com Subject: Re: NAT and IPSEC and Packet Filters References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Vinod Porwal wrote: > I've scanned through few drafts , articles which talk about NAT and IPSEC. > Most of them talk about having IPSEC traffic going through NAT devices. There's some discussion of this in the FreeS/WAN (IPSEC for Linux) docs: http://www.freeswan.org/freeswan_trees/freeswan-1.8/doc/firewall.html#NAT I'm the author and would appreciate comment or criticism, preferably off-list. From owner-ipsec@lists.tislabs.com Thu Feb 1 12:06:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29830; Thu, 1 Feb 2001 12:06:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09652 Thu, 1 Feb 2001 13:44:42 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: ipsec error protocol Date: Thu, 1 Feb 2001 13:43:28 -0500 Message-Id: <007b01c08c7e$defbdd70$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 Importance: Normal In-Reply-To: <200101310103.f0V13J5152166@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Can we please not be dogmatic about this? Keepalives come > with certain > > well-known pitfalls; if you know what they are, you can > invent a scheme with > > whatever design tolerances you desire. > > keepalives: > > - do not quickly detect loss of state unless the keepalive timeout is > very short. > > - generate traffic even when applications have nothing to say. if > the keepalive timeout is short, they may even generate more overhead > packets than "real" traffic > > - have no way to distinguish temporary loss of connectivity > from permanent loss of state, resulting in premature > disconnects. I don't dispute that (although these are all adjustable parameters). I was merely responding to the comment that "NO. Once and for all: keepalives are Bad. Evil. Broken," which seems rather dogmatic to me. There was a reason why I didn't call them keepalives in my draft, which is that they don't function in the way Steve described. In fact, I quite like your solution in principle. It's elegant and clever. Of course this WG typically ignores elegant/clever solutions to problems (e.g. Photuris cookies, client puzzles, message id as counter, base mode, etc.) so that doesn't mean it is any more likely to be accepted. The choice of technique depends on what you want the operational vulnerabilities to be. Your solution requires that both hosts take action based on error messages from the peer (in one case a cert validation, which could be time-consuming). This requires rate limiting and a strategy for bounding state creation. It also suggests various attacks, such as the fact that an unprivileged attacker could prevent a connection from being re-established simply by periodically spoofing fake birth certificates at the rate-limited interval. My solution admittedly has a higher overhead, but it has less potential to be manipulated by an attacker. In response to your comments above, I would never expect anyone to use my protocol with a short timeout in today's world. The acceptable timeout interval is inversely related to the speed of the link. As technology improves, the timeout can be reduced. However, I would still say that your birth certificates technique is my second favorite of all the proposals we have heard so far. It could be a perfectly acceptable solution, given some caveats which I previously mentioned in http://www.vpnc.org/ietf-ipsec/mail-archive/msg01490.html. Most notably, I still think you need to mandate continuous channel mode in order to prevent SADB desynchronization. (Or I guess you could use that ACK-within ESP thing, although that has some problems of its own.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Thu Feb 1 17:45:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17437; Thu, 1 Feb 2001 17:45:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10922 Thu, 1 Feb 2001 19:31:14 -0500 (EST) From: "Christian Franzen" To: Subject: lifetimes Date: Fri, 2 Feb 2001 01:34:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, while implementing IPSec on our Routers, I got into trouble. It would be great if you could help me: Which lifetime is typically used, when defining a combination of IPSec protocols, e.g. ESP+AH, with different lifetimes for each protocol? One for all, each seperately or...? What are todays' implementations doing? Thanks a lot for your help Christian CFranzen@elsa.de From owner-ipsec@lists.tislabs.com Thu Feb 1 18:02:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17716; Thu, 1 Feb 2001 18:02:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11048 Thu, 1 Feb 2001 20:12:56 -0500 (EST) Message-Id: <200102020109.RAA23297@potassium.network-alchemy.com> To: "Christian Franzen" cc: ipsec@lists.tislabs.com Subject: Re: lifetimes In-reply-to: Your message of "Fri, 02 Feb 2001 01:34:02 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23294.981076146.1@network-alchemy.com> Date: Thu, 01 Feb 2001 17:09:07 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Christian, The lifetime used really depends on what the users of your routers want. You should allow for both seconds and KB to be specified. Most people I know feel that when the two protocols are negotiated together to protect one type of traffic that they should be deleted/rekeyed as a pair. So if the lifetime counter for one gets hit before the lifetime counter for another they are both rekeyed. Doing so would make your boxes more interoperable with existing implementations. What company do you work for? regards, Dan. On Fri, 02 Feb 2001 01:34:02 +0100 you wrote > Hi, > > while implementing IPSec on our Routers, I got into trouble. It would be > great if you could help me: > > Which lifetime is typically used, when defining a combination of IPSec > protocols, e.g. ESP+AH, with different lifetimes for each protocol? > One for all, each seperately or...? > What are todays' implementations doing? > > Thanks a lot for your help > Christian > > CFranzen@elsa.de > From owner-ipsec@lists.tislabs.com Fri Feb 2 08:22:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25430; Fri, 2 Feb 2001 08:22:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13172 Fri, 2 Feb 2001 09:52:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <87elxhwi8y.fsf@porsas.hel.fi.ssh.com> References: <87elxhwi8y.fsf@porsas.hel.fi.ssh.com> Date: Fri, 2 Feb 2001 09:56:40 -0500 To: Markus Stenberg From: Stephen Kent Subject: Re: ipsec error protocol Cc: Derek Atkins , "sankar ramamoorthi" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markus, >Derek Atkins writes: >> "sankar ramamoorthi" writes: >> > If the receiver window is limited to 2**32 bits, then it means >> > at 10Gig/sec speeds the receiver has to rekey after 400 seconds. >> No, the receiver 'replay' window is limited to 2^32 bits. This means >> you can only accept packets within this 400-second window, so if a >> packet gets delayed by 400 seconds it will be dropped (because it is >> now outside this window). You still only need to rekey every 2^64, >> which is 400*2^32 seconds, which is a LARGE number. > >Yes.. But.. (pointing out something not addressed in the discussion before, >although I do not think it's big issue at least currently) > >> > Is that acceptable? >> I think the limitation of dropping packets delayed by 400s may be >> acceptible, provided we're not talking about interplanetary internets. >> I certainly believe that the 400*2^32 is sufficiently large. > >Obviously, this is the case. However, what if the route happens to be down >say, 5 minutes? The window _may_ have moved by roughly 0.8*2^32, and the >receiver cannot make decent guesstimates about real sequence number. Okay, >that's the trivial case (two guesses).. > >Assuming that the draffic is unidirectional (IPsec SA for say, multimedia >or whatever traffic).. > >How about downtime of hour in SA with lifetime of say, ten hours? 10 >guesses? New SA? > >Downtime of two days in SA with lifetime of year? 500 guesses? New SA? > >The so-far-simple logic gets suddenly somewhat more complex. I'm not sure >if this is an issue, though, because typically first guess would be always >correct and it'd require (at least with current communication speeds) N >years of dead link for guessing-delay to actually matter. You raise an interesting issue. The second example I think is not credible, i.e., an SA lifetime of a year. But, in the context of a unidirectional traffic flow, a serious outage might be long enough at very high speeds to cause the counter to wrap more than once, creating ambiguity at the receiver and a loss of synch. If we adopt any of the keep alive (or is that make dead?) proposals, we have a chance to detect and address this problem, but we do need to think about this and have a good answer. Steve From owner-ipsec@lists.tislabs.com Fri Feb 2 10:13:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01343; Fri, 2 Feb 2001 10:13:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13752 Fri, 2 Feb 2001 12:10:52 -0500 (EST) Message-ID: <20010202171352.11935.qmail@web1405.mail.yahoo.com> Date: Fri, 2 Feb 2001 09:13:52 -0800 (PST) From: Pyda Srisuresh Subject: IKE extensions to support dynamic policies To: ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Jan Vilhuber and I have a draft out on IKE extensions to support dynamic policy negotiation. The draft ID is . Below is an abstract of the draft. WOuld appreciate hearing your comments on the draft. Thanks. As IPsec is widely deployed, there is increasing need to negotiate security keys using IKE at application level granularity. IKE, as currently proposed, has restrictions in negotiating keys for applications with bundled sessions and complex policies. The draft identifies the problem with IKE and suggests extensions to make IKE application and policy friendly. The proposed solution suggests extensions to the conceptual operation of IPsec as well as IKE, but does not require changes to existing IKE payloads. The document introduces a new policy payload that complements existing IKE payloads and suggests replacing ID payload with the Policy payload, in Quick mode. cheers, suresh __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Fri Feb 2 10:15:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01497; Fri, 2 Feb 2001 10:15:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13656 Fri, 2 Feb 2001 12:05:38 -0500 (EST) Message-Id: <200102012022.MAA04952@gallium.network-alchemy.com> To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: Increased sequence number in ESP/AH In-Reply-To: Message from Stephen Kent of "Mon, 29 Jan 2001 18:15:44 EST." Date: Thu, 01 Feb 2001 12:22:41 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, >Well, I hate to add new fields to the packet format, but we may have >to do that at some point. However, the approach you propose here has >the advantage of being dynamic with less overhead (no QM exchange), >by allowing creation of new flows without creating new SAs. The flow >IDs separate out the sequence number spaces, each on a separate >crypto processor, right? So, the sequence numbers will be sequential >per flow, but packets for the same SPD-defined flow may be >distributed over various SA flows, to support parallelism. Yes, that's right. We probably only need six to eight bits for this. You could embed this in the upper byte of the new 64-bit sequence numbers. Derrell From owner-ipsec@lists.tislabs.com Fri Feb 2 10:15:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01517; Fri, 2 Feb 2001 10:15:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13641 Fri, 2 Feb 2001 12:04:38 -0500 (EST) Subject: lifetimes To: ipsec@lists.tislabs.com From: "Christian Franzen" Date: Thu, 1 Feb 2001 19:42:53 +0100 Message-ID: X-MIMETrack: Serialize by Router on ACSMTP/ELSA/DE(Release 5.0.6a |January 17, 2001) at 01.02.2001 19:43:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, while implementing IPSec on our Routers I got some questions regarding lifetimes of Proposals. It would be great, if someone could help me. What will be the typical practice, when using more than one Ipsec protocol in combination, e.g. ESP+AH with seperate configurable lifetimes? Just to use only one lifetime (and which?) for all protocols or to use different lifetimes for each? Thanks a lot Christian From owner-ipsec@lists.tislabs.com Fri Feb 2 10:17:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01713; Fri, 2 Feb 2001 10:17:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13657 Fri, 2 Feb 2001 12:05:43 -0500 (EST) To: Derek Atkins Cc: "sankar ramamoorthi" , "Stephen Kent" , Subject: Re: ipsec error protocol References: From: Markus Stenberg Date: 02 Feb 2001 11:23:41 +0200 In-Reply-To: Message-ID: <87elxhwi8y.fsf@porsas.hel.fi.ssh.com> Lines: 49 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins writes: > "sankar ramamoorthi" writes: > > If the receiver window is limited to 2**32 bits, then it means > > at 10Gig/sec speeds the receiver has to rekey after 400 seconds. > No, the receiver 'replay' window is limited to 2^32 bits. This means > you can only accept packets within this 400-second window, so if a > packet gets delayed by 400 seconds it will be dropped (because it is > now outside this window). You still only need to rekey every 2^64, > which is 400*2^32 seconds, which is a LARGE number. Yes.. But.. (pointing out something not addressed in the discussion before, although I do not think it's big issue at least currently) > > Is that acceptable? > I think the limitation of dropping packets delayed by 400s may be > acceptible, provided we're not talking about interplanetary internets. > I certainly believe that the 400*2^32 is sufficiently large. Obviously, this is the case. However, what if the route happens to be down say, 5 minutes? The window _may_ have moved by roughly 0.8*2^32, and the receiver cannot make decent guesstimates about real sequence number. Okay, that's the trivial case (two guesses).. Assuming that the draffic is unidirectional (IPsec SA for say, multimedia or whatever traffic).. How about downtime of hour in SA with lifetime of say, ten hours? 10 guesses? New SA? Downtime of two days in SA with lifetime of year? 500 guesses? New SA? The so-far-simple logic gets suddenly somewhat more complex. I'm not sure if this is an issue, though, because typically first guess would be always correct and it'd require (at least with current communication speeds) N years of dead link for guessing-delay to actually matter. > -derek -Markus > -- > 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 -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ipsec@lists.tislabs.com Fri Feb 2 11:51:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05926; Fri, 2 Feb 2001 11:51:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14219 Fri, 2 Feb 2001 13:57:19 -0500 (EST) From: "Joseph D. Harwood" To: "Stephen Kent" , "Markus Stenberg" Cc: "Derek Atkins" , "sankar ramamoorthi" , Subject: RE: ipsec error protocol Date: Fri, 2 Feb 2001 11:00:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C08D07.63FEBBE0" 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.00.2615.200 In-Reply-To: Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C08D07.63FEBBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > > You raise an interesting issue. The second example I think is not > credible, i.e., an SA lifetime of a year. But, in the context of a > unidirectional traffic flow, a serious outage might be long enough at > very high speeds to cause the counter to wrap more than once, > creating ambiguity at the receiver and a loss of synch. If we adopt > any of the keep alive (or is that make dead?) proposals, we have a > chance to detect and address this problem, but we do need to think > about this and have a good answer. > > Steve > I had also wondered about the situation where an outage occurs that lasts long enough for the Sequence Number to wrap a few times. Perhaps a unidirectional message between IKE peers (sender -> receiver) every time the sending Sequence Number wraps at bit 31? This mechanism would be redundant when there are no link problems, but would enable resynchronization when the link went down for a while. Even if some of these messages get dropped after the link comes back up, eventually one of the messages would get through and synchronization would be restored (i.e., don't have to have ack's or reliable transport for this notification message). Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com ------=_NextPart_000_0008_01C08D07.63FEBBE0 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0008_01C08D07.63FEBBE0-- From owner-ipsec@lists.tislabs.com Fri Feb 2 12:23:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08543; Fri, 2 Feb 2001 12:23:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14366 Fri, 2 Feb 2001 14:27:53 -0500 (EST) To: "Joseph D. Harwood" Cc: "Stephen Kent" , "Markus Stenberg" , "sankar ramamoorthi" , Subject: Re: ipsec error protocol References: From: Derek Atkins Date: 02 Feb 2001 14:30:50 -0500 In-Reply-To: "Joseph D. Harwood"'s message of "Fri, 2 Feb 2001 11:00:44 -0800" Message-ID: Lines: 68 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Also, this is only an issue for non-TCP protocols. TCP will notice the lack of acknowledgement and backoff packet transmission. It will not constantly send packets for the full duration of the outage. -derek "Joseph D. Harwood" writes: > > > > You raise an interesting issue. The second example I think is not > > credible, i.e., an SA lifetime of a year. But, in the context of a > > unidirectional traffic flow, a serious outage might be long enough at > > very high speeds to cause the counter to wrap more than once, > > creating ambiguity at the receiver and a loss of synch. If we adopt > > any of the keep alive (or is that make dead?) proposals, we have a > > chance to detect and address this problem, but we do need to think > > about this and have a good answer. > > > > Steve > > > > I had also wondered about the situation where an outage occurs that lasts > long enough for the Sequence Number to wrap a few times. Perhaps a > unidirectional message between IKE peers (sender -> receiver) every time the > sending Sequence Number wraps at bit 31? This mechanism would be redundant > when there are no link problems, but would enable resynchronization when the > link went down for a while. Even if some of these messages get dropped > after the link comes back up, eventually one of the messages would get > through and synchronization would be restored (i.e., don't have to have > ack's or reliable transport for this notification message). > > > Best Regards, > Joseph D. Harwood > jharwood@vesta-corp.com > www.vesta-corp.com > > ------=_NextPart_000_0008_01C08D07.63FEBBE0 > Content-Type: text/x-vcard; > name="Joseph D. Harwood.vcf" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="Joseph D. Harwood.vcf" > > BEGIN:VCARD > VERSION:2.1 > N:Harwood;Joseph;D. > FN:Joseph D. Harwood > ORG:Vesta Corporation > ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = > Clara;CA;95054 > LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = > Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D > CA 95054 > URL: > URL:http://www.vesta-corp.com > EMAIL;PREF;INTERNET:jharwood@vesta-corp.com > REV:20001011T162328Z > END:VCARD > > ------=_NextPart_000_0008_01C08D07.63FEBBE0-- > -- 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 Fri Feb 2 12:23:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08612; Fri, 2 Feb 2001 12:23:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14312 Fri, 2 Feb 2001 14:15:08 -0500 (EST) X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: ipsec@lists.tislabs.com Subject: IKE entropy issues with long keys From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 02 Feb 2001 09:41:25 -0800 Message-ID: Lines: 106 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've not seen that this analysis is indicated anywhere in the IPSEC RFCs, so I'll submit it here and suggest that the results probably should be mentioned in the IKE document directly. (It has been mentioned previously on the ipsec mailing list (I saw at least once reference in the archives from 96)). For situations where the needed key length of an ISAKMP SA encryption algorithm is greater than what the prf() (hash) algorithm generates, appendix B of RFC 2409 specifies that longer keying material should be generated using: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where SKEYID_e is defined previously in section 5 as: SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) The problem with the method of chaining hash outputs for generating a longer key is the entropy of the longer key doesn't increase beyond the entropy generated by a single hashing pass. Let me switch to "example" mode, where we'll use the BlowFish encryption algorithm with a 448 bit key and HMAC-MD5 as the prf() function. SKEYID_e = 160 bits long (the length of the SHA1 output). K1,K2,K3 = 160 bits. K = 160*3 = 480 bits (which is then truncated to 448). However, if I was to brute force breaking of the ISAKMP SA, I would merely iterate over the SKEYID_e values and use that to calculate Ka. At most I would have to iterate over all the possible values of SKEYID_e, which would be only 160 bits, since the full key can be derived from it. This reduces the entropy of encryption algorithm to the prf()'s entropy, in this case only 160 bits. The ISAKMP SA is then used in the future to negotiate new SAs. Fortunately, the strength of these new keys is depends on more information: Assuming a brute force attack against the ISAKMP SA is used, the following derivations of the key material for the new SA can be derived with the same entropy level if no new key exchange material is used for future key negotiation. From section 5.5 describing Quick Mode: KEYMAT = K1 | K2 | K3 where K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) etc. Assuming the ISAKMP SA has been broken, all of the above attributes are known except SKEYID_d and g(qm)^xy (protocol, SPI, Ni_b, Nr_b are all retrievable from the decrypted ISAKMP SA packets). If a new key exchange message is not included with future SA negotiations, then the strength of the entropy associtaed with the SA keys will be limited to the strength of the SKEYID_d value, which is again the output of the hashing (or prf) function. Fortunately, if the optional Key Exchange portion has been included the entropy of the g(qm)^xy must also be included, which should be significantly larger. Therefore, I submit that to brute-force any encryption algorithm negotiated by IKE one needs only to iterate through 2^N iterations, where N is the number of bits produced by the prf/hashing algorthim and not the number of bits used the encryption algorithm. This would result in 128 bit entropy for algorithms using keys derived from MD5, 160 bit entropy for algorithms using SHA-1 and ? bit entropy for algorithms using TIGER. Fortunately, SHA-256, SHA-384 and SHA-512 have been defined which should help produce larger entropy keys. I feel this should be mentioned in the documents (but more briefly), as people expecting full strength from their encryption algorthim will not get it if they allow the simultaneous use of a smaller hash/prf algorithm. (Fortunately for the time being, 128/160 bit keys seem strong enough for my personal use). This will become more and more important as larger key sizes are used in the new algorthims like AES. Not mentioning it may give people a false sense of security. IMHO, the proper thing that should be done (or should have been done) is to require more Key Exchange packets to generate larger key lengths such that chaining was not used to generate longer keys, but rather the key segments be generated independently from different g^xy values: SKEYID_d = prf(SKEYID #1, g^xy #1 | CKY-I | CKY-R | 2) | prf(SKEYID #1, g^xy #2 | CKY-I | CKY-R | 2) [ | ... ] whhere SKEYID #N = prf(Ni_b | nr_b, g^xy #N) (being careful to make sure the entropy of the g^xy value is greater than that of the hashing algorthim). -- "Ninjas aren't dangerous. They're more afraid of you than you are of them." From owner-ipsec@lists.tislabs.com Fri Feb 2 15:53:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21798; Fri, 2 Feb 2001 15:53:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14948 Fri, 2 Feb 2001 17:53:57 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Wes Hardaker'" , Subject: RE: IKE entropy issues with long keys Date: Fri, 2 Feb 2001 17:53:13 -0500 Message-Id: <00c401c08d6a$ec99b500$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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wes, some of these issues have been discussed recently on this list. See: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01288.html and: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01817.html and the discussions surrounding them. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Sat Feb 3 03:03:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29757; Sat, 3 Feb 2001 03:03:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16091 Sat, 3 Feb 2001 04:45:51 -0500 (EST) Date: Sat, 3 Feb 2001 15:12:21 +0530 (IST) From: Neeraj Kapoor To: ipsec mailing list Subject: Need help! Regarding aggressive mode of Oakley Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hello friends! i am new to this list . and obviusly i have a problem. Can anybody tell me in the case of the aggressive mode of Oakley Protocol why does the initiator needs to send the g^x again to the reponder in the 3'rd mesg along with the group information and also EHAS ? (in the case of Oakley protocol) CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP,ID(I), ID(R), Ni, Nr, S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki This statement of mine if with reference to RFC2412 of Oakley Protocol. thanks in advance neeraj ------------------------------------------------------------------------------ From owner-ipsec@lists.tislabs.com Sat Feb 3 09:50:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25245; Sat, 3 Feb 2001 09:50:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16786 Sat, 3 Feb 2001 11:48:26 -0500 (EST) Date: Sat, 3 Feb 2001 22:14:57 +0530 (IST) From: Neeraj Kapoor To: ipsec mailing list Subject: Need help! Regarding aggressive mode of Oakley Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hello friends! i am new to this list . and obviously i have a problem. Can anybody tell me in the case of the aggressive mode of Oakley Protocol why does the initiator needs to send the g^x again to the reponder in the 3'rd mesg along with the group information and also EHAS ? (in the case of Oakley protocol) CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP,ID(I), ID(R), Ni, Nr, S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki This statement of mine if with reference to RFC2412 of Oakley Protocol. thanks in advance neeraj ------------------------------------------------------------------------------ From owner-ipsec@lists.tislabs.com Sun Feb 4 08:44:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22494; Sun, 4 Feb 2001 08:44:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19206 Sun, 4 Feb 2001 10:22:32 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Wes Hardaker Cc: ipsec@lists.tislabs.com Subject: Re: IKE entropy issues with long keys Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Feb 2001 10:25:31 -0500 Message-Id: <20010204152531.99CDA35C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Wes Hardaker writes: Here's my problem with your posting: > >However, if I was to brute force breaking of the ISAKMP SA I don't believe in brute-force attacks of (to usey our example) 2^160 operations. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Sun Feb 4 22:19:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA16835; Sun, 4 Feb 2001 22:19:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20937 Mon, 5 Feb 2001 00:05:36 -0500 (EST) Reply-To: From: "Awan Kumar Sharma" To: "IpsecMailingList (E-mail)" Subject: Collision of IPSec SA negotiation. Date: Mon, 5 Feb 2001 10:40:59 +0530 Message-Id: <000401c08f32$07f976a0$6d0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C08F60.21B1B2A0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C08F60.21B1B2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, I am having a question related to the Collision of IPSec SA negotiation. I had raised this question sometime back, but I did not get any satisfactory reply. Hope to get some this time. Let us take the examples where IPsec operates as a security gateway(SG) this case, security gateway P has got one Security Policy for traffic from host A in network X to host B in network Y with security gateway as Q. Initially they won't have any SA to use. Now when traffic originates from A for B, P decides to establish an IPSec SA between host A in network X and host B in network Y. If at the same time, traffic originates from B for A, Security gateway for Y i.e. Q. Q will see that there is no SA for this traffic, so it will also start SA negotiation. So, now we have two SA negotiations going on for the same traffic between two security gateways. A similar type of situation will arise when we take the byte lifetime into consideration. In both the peers, the soft byte lifetime may expire at the same time, leading to the collision of IPSec SA negotiation by the peers. Although I could not find anything in RFC 2401 which prevents this situation, I think that if one SG as already started negotiating for some traffic, it is useless for the other peer SG to negotiate SA for the same traffic. I think this is the case of IPSec SA negotiation collision. I have observed that all the protocols which have something to negotiate between two entities prevents the collision problem by explicitly describing them in the RFC. Although for IPSec, I think this may not be required as this collision will not lead to any undesirable effects, but at the same time, I think this is irrelevant too. So, can anybody explain to me why any collision avoidance algorithm is not specified in IPSec related set of RFC's. Also, I am wrong in any respect, your correction will be highly acknowledged. Expecting for a better response this time because I feel that this is an important issue. Regards, Awan Kumar Sharma ------=_NextPart_000_0005_01C08F60.21B1B2A0 Content-Type: text/x-vcard; name="Awan Kumar Sharma (E-mail).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Awan Kumar Sharma (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Sharma;Awan FN:Awan Kumar Sharma (E-mail) ORG:Future Software Ltd.;NEC-DF TITLE:Software Engg. TEL;WORK;VOICE:+91 (4330550) - 437 TEL;HOME;VOICE:+91 (044) 8205625 ADR;WORK:;;480-481, Mount Road,;Chennai;Tamil Nadu;;India LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:480-481, Mount = Road,=3D0D=3D0AChennai, Tamil Nadu=3D0D=3D0AIndia EMAIL;PREF;INTERNET:awank@future.futsoft.com REV:20001110T092335Z END:VCARD ------=_NextPart_000_0005_01C08F60.21B1B2A0-- From owner-ipsec@lists.tislabs.com Mon Feb 5 11:49:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26104; Mon, 5 Feb 2001 11:49:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23880 Mon, 5 Feb 2001 13:39:28 -0500 (EST) X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "'Wes Hardaker'" , Subject: Re: IKE entropy issues with long keys References: <00c401c08d6a$ec99b500$1e72788a@andrewk3.ca.alcatel.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 05 Feb 2001 09:45:26 -0800 In-Reply-To: <00c401c08d6a$ec99b500$1e72788a@andrewk3.ca.alcatel.com> Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Fri, 2 Feb 2001 17:53:13 -0500, "Andrew Krywaniuk" said: Andrew> Wes, some of these issues have been discussed recently on this list. Andrew> See: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01288.html Andrew> and: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01817.html Andrew> and the discussions surrounding them. I wasn't suggesting the problem be solved (since its too late). It should, IMHO, be at least mentioned in the documents even if the problem itself is ignored and not solved. Also, IMHO, The "2^128 is large enough" response is a silly one. If that were true, we wouldn't bother developing new algorithms with longer key lengths. The AES requirements required longer key lengths for a reason. Currently unknown attacks may reduce the functional key space of an algorithm to something that is computationally feasible. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec@lists.tislabs.com Mon Feb 5 12:40:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29591; Mon, 5 Feb 2001 12:40:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24167 Mon, 5 Feb 2001 14:48:09 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Wes Hardaker Cc: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: IKE entropy issues with long keys Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Feb 2001 14:51:00 -0500 Message-Id: <20010205195100.8B99635C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Wes Hardaker writes: >>>>>> On Fri, 2 Feb 2001 17:53:13 -0500, "Andrew Krywaniuk" alcatel.com> said: > > >Also, IMHO, The "2^128 is large enough" response is a silly one. If >that were true, we wouldn't bother developing new algorithms with >longer key lengths. The AES requirements required longer key lengths >for a reason. Currently unknown attacks may reduce the functional key >space of an algorithm to something that is computationally feasible. >-- Well, some of us don't think that AES needed 256-bit keys... More to the point, I'm by no means excluding new attacks. In particular, attacks that produce some of the key bits but require brute-force searches of the remaining bits are not at all implausible. What I had said is that cryptanalytic actiity of order 2^128 operations is infeasible, whether for factoring or for finding AES keys. An attack that lowers the workload for factoring almost certainly does not reduce the difficulty of finding an AES key by the same amount, though of course it does lower the difficulty of getting at the plaintext. Put another way, matching the factoring (or discrete log) workloads isn't interesting unless you think that an attacker can must that much work, of either sort. You allow headroom for either or both only to the extent that you are afraid of breakthroughs that will lower the amount of work needed. But except for a straight Moore's Law play, the two don't need to match. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Mon Feb 5 12:55:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00585; Mon, 5 Feb 2001 12:55:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24203 Mon, 5 Feb 2001 15:03:54 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 05 Feb 2001 13:06:12 -0700 From: "Hilarie Orman" To: Cc: Subject: Re: IKE entropy issues with long keys Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA24200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The AES requirements have more to do with cryptanalysis than brute force key search. The real enemy of 128 bits is quantum computers*. Hilarie *Everytime someone writes "quantum computer" it seems to validate the idea that there is or could be a quantum computer. That's not the intent of my use of the term. >>> Wes Hardaker 02/05/01 10:45AM >>> >>>>> On Fri, 2 Feb 2001 17:53:13 -0500, "Andrew Krywaniuk" said: Andrew> Wes, some of these issues have been discussed recently on this list. Andrew> See: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01288.html Andrew> and: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01817.html Andrew> and the discussions surrounding them. I wasn't suggesting the problem be solved (since its too late). It should, IMHO, be at least mentioned in the documents even if the problem itself is ignored and not solved. Also, IMHO, The "2^128 is large enough" response is a silly one. If that were true, we wouldn't bother developing new algorithms with longer key lengths. The AES requirements required longer key lengths for a reason. Currently unknown attacks may reduce the functional key space of an algorithm to something that is computationally feasible. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec@lists.tislabs.com Mon Feb 5 18:13:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12620; Mon, 5 Feb 2001 18:13:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25851 Mon, 5 Feb 2001 20:31:00 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 05 Feb 2001 18:33:25 -0700 From: "Hilarie Orman" To: Cc: Subject: Re: IKE entropy issues with long keys Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA25848 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This bit-halving computation sounds interesting. Beyond that, I think you are trying to conflate two independent issues. Cryptanalysis can lead to ways to attack a cipher that are less effort than brute force key search, but this doesn't mean that it is necessary to add more entropy to the key. Hilarie >>> Wes Hardaker 02/05/01 05:51PM >>> >>>>> On Mon, 05 Feb 2001 13:06:12 -0700, "Hilarie Orman" said: Hilarie> The AES requirements have more to do with cryptanalysis than Hilarie> brute force key search. The real enemy of 128 bits is Hilarie> quantum computers*. Right, if an attack is found that reduces your effective bit size to half of its original, I can only hope that you're using a 256 bit key to begin with (and one with 256 bits of entropy). -- Wes Hardaker NAI Labs Network Associates From owner-ipsec@lists.tislabs.com Mon Feb 5 18:14:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12643; Mon, 5 Feb 2001 18:14:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25618 Mon, 5 Feb 2001 20:18:57 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Wes Hardaker'" Cc: Subject: RE: IKE entropy issues with long keys Date: Mon, 5 Feb 2001 20:18:43 -0500 Message-Id: <002001c08fda$bfe8ee50$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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's not that I think that 2^128 bits isn't enough. I just don't think it's a good idea to hardcode a field based on that assumption or to arbitrarily discard entropy such that it looks like you're getting 256 bits when you're really only getting 128. As Steve also pointed out, there is dubious value to using 256 bit AES for matching matching the discrete log workload, although the impetus has actually been the other way around (see the recent draft on bigger DH groups). I don't agree with the example you brought up about using PFS to generate extra uncorrelated key bits. The fact that the key bits come out of a PRF should mean that they are sufficiently uncorrelated. The real reason for rekeying is to minimize the impact of a compromise, not to make the compromise less likely. I (and others) have actually suggested before that we need an RFC which documents the implicit security properties of IKE. There is simply too much unwritten knowledge out there, in the archives and in the brains of the list members, which is not obvious to someone who is evaluating the protocol. I would undertake this myself, except that these things tend to carry more weight if you get someone with a bunch of letters after their name. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: Wes Hardaker [mailto:wes@hardakers.net] > Sent: Monday, February 05, 2001 12:45 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Wes Hardaker'; ipsec@lists.tislabs.com > Subject: Re: IKE entropy issues with long keys > > > >>>>> On Fri, 2 Feb 2001 17:53:13 -0500, "Andrew Krywaniuk" > said: > > Andrew> Wes, some of these issues have been discussed > recently on this list. > > Andrew> See: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01288.html > Andrew> and: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01817.html > > Andrew> and the discussions surrounding them. > > I wasn't suggesting the problem be solved (since its too late). It > should, IMHO, be at least mentioned in the documents even if the > problem itself is ignored and not solved. > > Also, IMHO, The "2^128 is large enough" response is a silly one. If > that were true, we wouldn't bother developing new algorithms with > longer key lengths. The AES requirements required longer key lengths > for a reason. Currently unknown attacks may reduce the functional key > space of an algorithm to something that is computationally feasible. > -- > Wes Hardaker > NAI Labs > Network Associates > From owner-ipsec@lists.tislabs.com Tue Feb 6 04:13:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01864; Tue, 6 Feb 2001 04:13:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA28286 Tue, 6 Feb 2001 05:56:02 -0500 (EST) Message-ID: From: Chris Trobridge To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: IKE entropy issues with long keys Date: Tue, 6 Feb 2001 10:56:44 -0000 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 Does IKE preclude the use of SHA-256 or SHA-512 for AES? Chris > -----Original Message----- > From: Andrew Krywaniuk [mailto:andrew.krywaniuk@alcatel.com] > Sent: 06 February 2001 01:19 > To: 'Wes Hardaker' > Cc: ipsec@lists.tislabs.com > Subject: RE: IKE entropy issues with long keys > > > It's not that I think that 2^128 bits isn't enough. I just > don't think it's > a good idea to hardcode a field based on that assumption or > to arbitrarily > discard entropy such that it looks like you're getting 256 > bits when you're > really only getting 128. > > As Steve also pointed out, there is dubious value to using > 256 bit AES for > matching matching the discrete log workload, although the impetus has > actually been the other way around (see the recent draft on bigger DH > groups). > > I don't agree with the example you brought up about using PFS > to generate > extra uncorrelated key bits. The fact that the key bits come > out of a PRF > should mean that they are sufficiently uncorrelated. The real > reason for > rekeying is to minimize the impact of a compromise, not to make the > compromise less likely. > > I (and others) have actually suggested before that we need an > RFC which > documents the implicit security properties of IKE. There is > simply too much > unwritten knowledge out there, in the archives and in the > brains of the list > members, which is not obvious to someone who is evaluating > the protocol. I > would undertake this myself, except that these things tend to > carry more > weight if you get someone with a bunch of letters after their name. > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > > -----Original Message----- > > From: Wes Hardaker [mailto:wes@hardakers.net] > > Sent: Monday, February 05, 2001 12:45 PM > > To: andrew.krywaniuk@alcatel.com > > Cc: 'Wes Hardaker'; ipsec@lists.tislabs.com > > Subject: Re: IKE entropy issues with long keys > > > > > > >>>>> On Fri, 2 Feb 2001 17:53:13 -0500, "Andrew Krywaniuk" > > said: > > > > Andrew> Wes, some of these issues have been discussed > > recently on this list. > > > > Andrew> See: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01288.html > Andrew> and: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01817.html > > Andrew> and the discussions surrounding them. > > I wasn't suggesting the problem be solved (since its too late). It > should, IMHO, be at least mentioned in the documents even if the > problem itself is ignored and not solved. > > Also, IMHO, The "2^128 is large enough" response is a silly one. If > that were true, we wouldn't bother developing new algorithms with > longer key lengths. The AES requirements required longer key lengths > for a reason. Currently unknown attacks may reduce the functional key > space of an algorithm to something that is computationally feasible. > -- > Wes Hardaker > NAI Labs > Network Associates > This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Tue Feb 6 05:25:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06402; Tue, 6 Feb 2001 05:25:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28933 Tue, 6 Feb 2001 07:37:18 -0500 (EST) Date: Tue, 6 Feb 2001 14:38:39 +0200 (IST) From: Hugo Krawczyk To: Wes Hardaker cc: ipsec list Subject: Re: IKE entropy issues with long keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wes, this is in answer to your message from Feb 2nd and to the following On 5 Feb 2001, Wes Hardaker wrote: > > I wasn't suggesting the problem be solved (since its too late). It > should, IMHO, be at least mentioned in the documents even if the > problem itself is ignored and not solved. There is no problem to solve. The design of key derivation in IKE is correct. If you want to use Blowfish with 448-bit key (as in your example) and you feel that your current hash function is not strong enough then upgrade the prf: for example, use Blowfish with 448-bit in CBC-MAC mode as your prf. Doing repeated DH exchanges as you suggested in a previous message does not upgrade the security of the whole thing. It still remains the minimum between the security of DH and the security of the prf. BTW, since we are not talking about brute force here (any of the hash algorithms in current use are goood enough in that sense) then we are talking cryptanalysis. Now, the feedback mode in the definition of key derivation in IKE was introduced exactly to make cryptanalysis very hard. Think about how much known plaintext you have, and how many applications of the prf with the same key the attacker sees. This is NOT like an attacker against the data encryption function who sees lots of plaintext encrypted under the same key and may know or even choose the encrypted plaintexts. Crypto design is NOT based in simplistic (entropy or other) arithmetics but in careful protocol analysis and reduction of the protocol strength to the assumed difficulty of breaking the underlying crypto functions. Hugo From owner-ipsec@lists.tislabs.com Tue Feb 6 09:02:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20618; Tue, 6 Feb 2001 09:02:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00192 Tue, 6 Feb 2001 11:00:48 -0500 (EST) X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "'Wes Hardaker'" , Subject: Re: IKE entropy issues with long keys References: <002001c08fda$bfe8ee50$1e72788a@andrewk3.ca.alcatel.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 05 Feb 2001 21:27:25 -0800 In-Reply-To: <002001c08fda$bfe8ee50$1e72788a@andrewk3.ca.alcatel.com> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Mon, 5 Feb 2001 20:18:43 -0500, "Andrew Krywaniuk" said: Andrew> I don't agree with the example you brought up about using PFS Andrew> to generate extra uncorrelated key bits. The fact that the key Andrew> bits come out of a PRF should mean that they are sufficiently Andrew> uncorrelated. The real reason for rekeying is to minimize the Andrew> impact of a compromise, not to make the compromise less Andrew> likely. I'm not sure to which example you're referring, but thats ok... Andrew> I (and others) have actually suggested before that we need an Andrew> RFC which documents the implicit security properties of Andrew> IKE. Thats probably a really good idea. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec@lists.tislabs.com Tue Feb 6 09:03:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20700; Tue, 6 Feb 2001 09:03:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00216 Tue, 6 Feb 2001 11:01:49 -0500 (EST) X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: "Hilarie Orman" Cc: , Subject: Re: IKE entropy issues with long keys References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 05 Feb 2001 21:35:55 -0800 In-Reply-To: Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Mon, 05 Feb 2001 18:33:25 -0700, "Hilarie Orman" said: Hilarie> Beyond that, I think you are trying to conflate two Hilarie> independent issues. Cryptanalysis can lead to ways to attack Hilarie> a cipher that are less effort than brute force key search, Hilarie> but this doesn't mean that it is necessary to add more Hilarie> entropy to the key. You're assuming that you could never tie a cryptanalysis attack together with an attack on the entropy of the key itself. Currently there aren't known attacks that can take, for example, an attack against an algorithm using a statistical analysis that is strengthend by a simultaneous attack against the lack of entropy in the keys. But I'm sure that something like that could never ever happen and we're safe and shouldn't need to worry about it, right? Anyway, this discussion has turned far away from my original point, that the issue should at least be mentioned somewhere lest people get the wrong assumption about the algorithms they've selected. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec@lists.tislabs.com Tue Feb 6 09:04:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20727; Tue, 6 Feb 2001 09:04:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00231 Tue, 6 Feb 2001 11:02:49 -0500 (EST) Message-ID: <3A7FFD92.8B92FA5E@sookmyung.ac.kr> Date: Tue, 06 Feb 2001 22:35:14 +0900 From: Gwangsoo Rhee Reply-To: rhee@sookmyung.ac.kr X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neeraj Kapoor CC: ipsec mailing list Subject: Re: Need help! Regarding aggressive mode of Oakley References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can only guess: (1) EHAS is necessary in the 3rd msg so that the responder can be assured that the initiator correctly received the responder's choice. (2) the need for GRP is not clear; but, it'll make the 1st msg and the 3rd msg use the same format (3) similarly for g^x; with one comment: the responder won't have to retain the 1st msg after it sends out the 2nd msg. Neeraj Kapoor wrote: > hello friends! i am new to this list . and obviously i have a problem. Can > anybody tell me in the case of the aggressive mode of Oakley Protocol why does > the initiator needs to send the g^x again to the reponder in the 3'rd mesg along > with the group information and also EHAS ? (in the case of Oakley protocol) > > CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP,ID(I), ID(R), Ni, Nr, S{ID(I) | > ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki > > This statement of mine if with reference to RFC2412 of Oakley Protocol. > > thanks in advance > neeraj > ------------------------------------------------------------------------------ -- --------------------------------------- Gwangsoo Rhee tel: +82-2-710-9429 fax: 710-9296 HP: 011-9691-9541 --------------------------------------- From owner-ipsec@lists.tislabs.com Tue Feb 6 09:08:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20943; Tue, 6 Feb 2001 09:08:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00193 Tue, 6 Feb 2001 11:00:53 -0500 (EST) X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: "Hilarie Orman" Cc: , Subject: Re: IKE entropy issues with long keys References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 05 Feb 2001 16:51:04 -0800 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Mon, 05 Feb 2001 13:06:12 -0700, "Hilarie Orman" said: Hilarie> The AES requirements have more to do with cryptanalysis than Hilarie> brute force key search. The real enemy of 128 bits is Hilarie> quantum computers*. Right, if an attack is found that reduces your effective bit size to half of its original, I can only hope that you're using a 256 bit key to begin with (and one with 256 bits of entropy). -- Wes Hardaker NAI Labs Network Associates From owner-ipsec@lists.tislabs.com Tue Feb 6 10:36:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25605; Tue, 6 Feb 2001 10:36:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00820 Tue, 6 Feb 2001 12:34:05 -0500 (EST) Date: Tue, 6 Feb 2001 23:00:37 +0530 (IST) From: Neeraj Kapoor To: Gwangsoo Rhee cc: ipsec mailing list Subject: Re: Need help! Regarding aggressive mode of Oakley In-Reply-To: <3A7FFD92.8B92FA5E@sookmyung.ac.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Gwangsoo, regarding your comment #(3) similarly for g^x; # with one comment: the responder won't have to retain the 1st msg after it # sends out the 2nd msg. It has been specified in the rfc that due to the first transmissin of the message the responder saves g^x in the state information. And so in any way that g^x seems to me as a waste (other than it may simplify the generation of the message and parsing on the other side. ================================= Neeraj Kapoor M.Tech.(Computer Sc. & Engg. F-304, Hall- IV, Indian Institute of Technology Kanpur(UP), India PIN : 208016 e-mail: neerajk@cse.iitk.ac.in Phone: (0512)-597314,597114 (Hostel) (0512)-597653 (Lab) ================================= From owner-ipsec@lists.tislabs.com Tue Feb 6 16:25:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15606; Tue, 6 Feb 2001 16:25:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03025 Tue, 6 Feb 2001 18:12:48 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Chris Trobridge'" Cc: Subject: RE: IKE entropy issues with long keys Date: Tue, 6 Feb 2001 18:12:42 -0500 Message-Id: <004501c09092$4f707950$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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, of course not. That's beside the point. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Chris Trobridge > Sent: Tuesday, February 06, 2001 5:57 AM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: IKE entropy issues with long keys > > > Does IKE preclude the use of SHA-256 or SHA-512 for AES? > > Chris From owner-ipsec@lists.tislabs.com Tue Feb 6 21:47:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22204; Tue, 6 Feb 2001 21:47:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA04446 Tue, 6 Feb 2001 23:37:39 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: ipsec@lists.tislabs.com Subject: Re: IKE entropy issues with long keys Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Feb 2001 19:43:11 -0500 Message-Id: <20010207004326.99BDF35DC7@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie Orman noted: > >Hilarie> The AES requirements have more to do with cryptanalysis than >Hilarie> brute force key search. The real enemy of 128 bits is >Hilarie> quantum computers*. I checked with Peter Shor -- *the* expert in quantum computing -- on this. Here's his answer: That's essentially the case. For symmetric cipher keys, the best known speed-up is a square root factor, so doubling the key length will give security against quantum computers (using known algorithms). For standard RSA, quantum computers can crack RSA in essentially the same number of steps that classical computers take to encode. So it's not a good idea to use RSA against quantum computers (unless they're NMR quantum computers, which right now have REALLY slow clock rates). In other words, Hilarie is right -- 192-bit or 256-bit AES is needed if you think that quantum computers are (or will be) a threat. (Note, of course, that we're still talking a brute-force attack of order 2^96 or 2^128, which implies a really fast, massively- parallel quantum computer -- and that's almost certainly much further off than a simple quantum computer.) But note the second part (I didn't ask about discrete log, though I seem to recall that it's similar to factoring in its complexity on quantum computers): factoring becomes *much* cheaper. Going to an RSA modulus size whose factoring would require O(2^128) operations by today's algorithms doesn't do the trick. In fact, nothing would do the trick; if you can afford to encrypt it, the guys in quantum black helicopters can decrypt it. We *still* don't have any rationale for making the symmetric key size comparable in number of operations to the D-H size. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Wed Feb 7 09:37:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24375; Wed, 7 Feb 2001 09:37:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07015 Wed, 7 Feb 2001 09:58:56 -0500 (EST) X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: ipsec@lists.tislabs.com Subject: Re: IKE entropy issues with long keys MIME-Version: 1.0 Date: Tue, 06 Feb 2001 19:43:11 -0500 Message-ID: <20010207004326.99BDF35DC7@berkshire.research.att.com> X-WSS-ID: 169FBF254813-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie Orman noted: > >Hilarie> The AES requirements have more to do with cryptanalysis than >Hilarie> brute force key search. The real enemy of 128 bits is >Hilarie> quantum computers*. I checked with Peter Shor -- *the* expert in quantum computing -- on this. Here's his answer: That's essentially the case. For symmetric cipher keys, the best known speed-up is a square root factor, so doubling the key length will give security against quantum computers (using known algorithms). For standard RSA, quantum computers can crack RSA in essentially the same number of steps that classical computers take to encode. So it's not a good idea to use RSA against quantum computers (unless they're NMR quantum computers, which right now have REALLY slow clock rates). In other words, Hilarie is right -- 192-bit or 256-bit AES is needed if you think that quantum computers are (or will be) a threat. (Note, of course, that we're still talking a brute-force attack of order 2^96 or 2^128, which implies a really fast, massively- parallel quantum computer -- and that's almost certainly much further off than a simple quantum computer.) But note the second part (I didn't ask about discrete log, though I seem to recall that it's similar to factoring in its complexity on quantum computers): factoring becomes *much* cheaper. Going to an RSA modulus size whose factoring would require O(2^128) operations by today's algorithms doesn't do the trick. In fact, nothing would do the trick; if you can afford to encrypt it, the guys in quantum black helicopters can decrypt it. We *still* don't have any rationale for making the symmetric key size comparable in number of operations to the D-H size. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Wed Feb 7 13:21:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06331; Wed, 7 Feb 2001 13:21:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00872 Wed, 7 Feb 2001 15:17:05 -0500 (EST) Date: Thu, 8 Feb 2001 01:43:43 +0530 (IST) From: Neeraj Kapoor To: ipsec mailing list Subject: Again with another doubt! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello friends, As stated in the rfc the Oakley tries to to stateless in a way that means that all the data sent earlier is repeated in the later messages, i.e later messages only add new stuff to packet they never remove anything from the packet. Well, i have a doubt in this case which goes on like this. Let's have a look at the "agressive mode with hidden identities" Initiator Responder --------- --------- -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, E{ID(R), ID(I), Nr}Ki, prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <- -> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) -> This last exchange violates the thing stated as we can see that values 0(zero) have been specified for the fields g^x and EHAS. ? Thus the statement that the messages always add content rather than removing any of the previous information is also not fully justified.....although the rfc2412 speaks that Can anybody help me in this regard ???. neeraj ================================= Neeraj Kapoor M.Tech.(Computer Sc. & Engg. F-304, Hall- IV, Indian Institute of Technology Kanpur(UP), India PIN : 208016 e-mail: neerajk@cse.iitk.ac.in Phone: (0512)-597314,597114 (Hostel) (0512)-597653 (Lab) ================================= From owner-ipsec@lists.tislabs.com Thu Feb 8 09:01:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29747; Thu, 8 Feb 2001 09:01:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04484 Thu, 8 Feb 2001 10:41:27 -0500 (EST) Date: Thu, 8 Feb 2001 10:43:55 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RSA != RSA? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The final fundamental step in generating an RSA key pair is to compute the decryption key, d, such that e d === 1 mod (p-1)(q-1) Or is it? RFC 2437, aka PKCS #1, RSA Labs's own spec for how to do RSA, says that the modulus should be lcm(p-1,q-1), where lcm is Least Common Multiple. Say what?!? The original R/S/A paper in CACM, which is what the IPsec RFCs reference, says (p-1)(q-1). So does Schneier 2nd edition, a common reference on such things. Clearly, any key pair built using the (p-1)(q-1) version will pass any test based on the lcm version, since (p-1)(q-1) is necessarily an integer multiple of lcm(p-1,q-1). However, the converse is not true: key pairs built using the lcm version won't necessarily satisfy the stricter test. (Unless I have missed something, there is *at best* a 50% chance that an lcm key pair is also a (p-1)(q-1) key pair, since the lcm is guaranteed to take out at least one factor of 2.) I assume, without immediately being able to prove it, that either version of the decryption key will actually work. This smells like an optimization that somebody noticed after the original publication. The problem naturally is not visible when exchanging *public* keys, since d is found only in the private key. It becomes an issue only when a key *pair* is being generated on one system for use by another, and the receiving system is being cautious and checking the key for consistency. God knows we have enough difficulties exchanging RSA keys already, since no two groups seem to agree on a data format for it. But I thought we all agreed on what an RSA key *is*! Does anybody know the story behind this discrepancy? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Feb 8 12:27:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01290; Thu, 8 Feb 2001 12:27:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05295 Thu, 8 Feb 2001 14:01:31 -0500 (EST) Message-ID: <01a101c09201$78dc73f0$65030a0a@chromatix.com> Reply-To: "Steve Wang" From: "Steve Wang" To: "Henry Spencer" , "IP Security List" References: Subject: Re: RSA != RSA? Date: Thu, 8 Feb 2001 14:00:41 -0500 Organization: Entegrity Solutions 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 > The problem naturally is not visible when exchanging *public* keys, since > d is found only in the private key. It becomes an issue only when a key > *pair* is being generated on one system for use by another, and the > receiving system is being cautious and checking the key for consistency. It depends on how the consistency checking goes. If one just chooses a random message, m, compute c = m^e mod n, m'=c^d mod n, and compare m = m' mod n, then the checking will pass. If one chooses to compute de = 1 mod **, then it may fail. Steve From owner-ipsec@lists.tislabs.com Thu Feb 8 12:51:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA00529; Thu, 8 Feb 2001 12:51:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05466 Thu, 8 Feb 2001 14:54:42 -0500 (EST) Date: Thu, 8 Feb 2001 14:57:08 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: RSA != RSA? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An addendum... I wrote: > I assume, without immediately being able to prove it, that either version > of the decryption key will actually work... Sandy Harris of our team promptly came up with a proof. So the added lcm is, presumably, an optimization. I'd still be curious to know how this came about, if anybody knows. And this is an interoperability booby-trap that ought to be noted somewhere. It's a limited one, since it involves the private key, which isn't traded around a lot... but we ran into it in exactly that way, an interoperability failure. Preferably it should get explicit mention; at the very least, the IPsec RFCs should reference PKCS#1 as well as the original paper. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Feb 8 15:58:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA11246; Thu, 8 Feb 2001 15:58:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05884 Thu, 8 Feb 2001 17:54:13 -0500 (EST) To: Henry Spencer Cc: IP Security List Subject: Re: RSA != RSA? References: From: Derek Atkins Date: 08 Feb 2001 17:57:08 -0500 In-Reply-To: Henry Spencer's message of "Thu, 8 Feb 2001 14:57:08 -0500 (EST)" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Basically there are multiple decryption keys, d, that are valid for any particular encryption key, e, mod N. I believe the lcm(p-1,q-1) will force you to generate necessarily one of the multiple d keys. -derek Henry Spencer writes: > An addendum... I wrote: > > I assume, without immediately being able to prove it, that either version > > of the decryption key will actually work... > > Sandy Harris of our team promptly came up with a proof. So the added lcm > is, presumably, an optimization. > > I'd still be curious to know how this came about, if anybody knows. > > And this is an interoperability booby-trap that ought to be noted > somewhere. It's a limited one, since it involves the private key, which > isn't traded around a lot... but we ran into it in exactly that way, an > interoperability failure. Preferably it should get explicit mention; at > the very least, the IPsec RFCs should reference PKCS#1 as well as the > original paper. > > Henry Spencer > henry@spsystems.net > > -- 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 Fri Feb 9 02:16:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA21517; Fri, 9 Feb 2001 02:16:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA07266 Fri, 9 Feb 2001 03:56:12 -0500 (EST) Message-ID: From: Chris Trobridge To: Derek Atkins , Henry Spencer Cc: IP Security List Subject: RE: RSA != RSA? Date: Fri, 9 Feb 2001 08:59:16 -0000 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 Any idea how many? (just for academic interest) Chris > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: 08 February 2001 22:57 > To: Henry Spencer > Cc: IP Security List > Subject: Re: RSA != RSA? > > > Basically there are multiple decryption keys, d, that are valid for > any particular encryption key, e, mod N. I believe the lcm(p-1,q-1) > will force you to generate necessarily one of the multiple d keys. > > -derek ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Fri Feb 9 07:00:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA10529; Fri, 9 Feb 2001 07:00:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07905 Fri, 9 Feb 2001 08:30:20 -0500 (EST) Message-Id: <3.0.3.32.20010209115025.00b13250@pop.datafellows.com> X-Sender: alexey@pop.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 09 Feb 2001 11:50:25 +0200 To: IP Security List From: Alexey Kirichenko Subject: Re: RSA != RSA? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:57 8.2.2001 -0500, you wrote: >An addendum... I wrote: >> I assume, without immediately being able to prove it, that either version >> of the decryption key will actually work... > >Sandy Harris of our team promptly came up with a proof. So the added lcm >is, presumably, an optimization. It is an optimization (and obvious one). >The problem naturally is not visible when exchanging *public* keys, since >d is found only in the private key. It becomes an issue only when a key >*pair* is being generated on one system for use by another, and the >receiving system is being cautious and checking the key for consistency. Then the consistency check should be (mod LCM). The condition ed = 1 mod LCM(p-1, q-1) is a _necessary_ one for the key pair (e, d) be "correct" for all possible plaintexts, that is, if it's not satisfied then M^(ed) != M mod pq for a significant portion of plaintexts M (at least, for all M which are primitive roots mod p or those mod q). So, checking (mod LCM), we check the _necessary_and_sufficient_ condition, can't be better. >And this is an interoperability booby-trap that ought to be noted >somewhere. It's a limited one, since it involves the private key, which >isn't traded around a lot... but we ran into it in exactly that way, an >interoperability failure. Preferably it should get explicit mention; at >the very least, the IPsec RFCs should reference PKCS#1 as well as the >original paper. Very true. Alexey From owner-ipsec@lists.tislabs.com Fri Feb 9 07:00:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA10559; Fri, 9 Feb 2001 07:00:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07904 Fri, 9 Feb 2001 08:30:14 -0500 (EST) Message-Id: <3.0.3.32.20010209123615.00b13250@pop.datafellows.com> X-Sender: alexey@pop.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 09 Feb 2001 12:36:15 +0200 To: IP Security List From: Alexey Kirichenko Subject: RE: RSA != RSA? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:59 9.2.2001 -0000, you wrote: >Any idea how many? (just for academic interest) > >Chris This depends. Generally, if you find one such a value, say, d0, then any other has a form d = d0 + k * LCM(p-1, q-1), k is integer, and you're interested only in values that belong to [1, p*q - 1] interval. For example, if LCM(p-1, q-1) = (p-1) * (q-1) / 2, then there are just two (for absolute majority of encryption keys) or three (in rare cases) distinct values of the decryption key. If (p-1) and (q-1) have some more common factors, then the number of distinct decryption keys will be greater, it's approximately equal to GCD(p-1, q-1). Alexey From owner-ipsec@lists.tislabs.com Fri Feb 9 09:55:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA22667; Fri, 9 Feb 2001 09:55:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08569 Fri, 9 Feb 2001 11:32:37 -0500 (EST) To: Chris Trobridge Cc: Henry Spencer , IP Security List Subject: Re: RSA != RSA? References: From: Derek Atkins Date: 09 Feb 2001 11:34:56 -0500 In-Reply-To: Chris Trobridge's message of "Fri, 9 Feb 2001 08:59:16 -0000" Message-ID: Lines: 67 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If I recall correctly, the number of possilble keys is dependent on the factorization of (p-1)(q-1). Namely, the more factors you have, the greater the number of possible keys. (Note: I might have the wrong number being factored -- we discussed this in class about 7 years ago and I'm nowhere near my class notes ;) But basically, IIRC, if you choose p and q as strong primes, such that both (p-1)/2 and (q-1)/2 are prime, then you will minimize the number of potential decryption keys to 2. As a simple example, take p=7,q=5, N=35. You can choose, e.g. e=5, as 5 is relatively prime to (p-1)(q-1) = (6*4) = 24. You can then show that either d=11 or d=23 will work to decrypt a message: m=5 c = m^e mod n = 5^5 mod 35 = 10 m = c^d mod n = 10^11 mod 35 = 5 = 10^23 mod 35 = 5 Enjoy, -derek Chris Trobridge writes: > Any idea how many? (just for academic interest) > > Chris > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@mit.edu] > > Sent: 08 February 2001 22:57 > > To: Henry Spencer > > Cc: IP Security List > > Subject: Re: RSA != RSA? > > > > > > Basically there are multiple decryption keys, d, that are valid for > > any particular encryption key, e, mod N. I believe the lcm(p-1,q-1) > > will force you to generate necessarily one of the multiple d keys. > > > > -derek > > > ----------------------------------------------------------------------------------------------------------------- > The information contained in this message is confidential and is intended > for the addressee(s) only. If you have received this message in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this message is > strictly forbidden. Baltimore Technologies plc will not be liable for direct, > special, indirect or consequential damages arising from alteration of the > contents of this message by a third party or as a result of any virus being > passed on. > > In addition, certain Marketing collateral may be added from time to time to > promote Baltimore Technologies products, services, Global e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. -- 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 10 13:19:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA24334; Sat, 10 Feb 2001 13:19:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11685 Sat, 10 Feb 2001 14:59:23 -0500 (EST) Message-ID: <3A859E12.74041F4E@storm.ca> Date: Sat, 10 Feb 2001 15:01:22 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: IP Security List Subject: Re: RSA != RSA? References: <3.0.3.32.20010209115025.00b13250@pop.datafellows.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alexey Kirichenko wrote: > >Sandy Harris of our team promptly came up with a proof. So the added lcm > >is, presumably, an optimization. > > It is an optimization (and obvious one). The gain is typically tiny. Reducing the operand by a small constant factor (p-1)*(q-1)/lcm(p-1,q-1) = gcd(p-1,q-1) saves about log2(gcd(p-1,q-1) iterations. Still, worth having since it costs nothing and always saves at least one iteration. > >... It becomes an issue only when a key > >*pair* is being generated on one system for use by another, and the > >receiving system is being cautious and checking the key for consistency. > > Then the consistency check should be (mod LCM). ... Yes. > So, checking (mod LCM), we check the _necessary_and_sufficient_ > condition, can't be better. > > >And this is an interoperability booby-trap that ought to be noted > >somewhere. ... Preferably it should get explicit mention; at > >the very least, the IPsec RFCs should reference PKCS#1 as well as the > >original paper. > > Very true. I agree. From owner-ipsec@lists.tislabs.com Mon Feb 12 06:51:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA29823; Mon, 12 Feb 2001 06:51:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA17493 Mon, 12 Feb 2001 07:55:34 -0500 (EST) Message-ID: From: Kulwinder Atwal To: "'zeroconf@merit.edu'" , seamoby@cdma-2000.org, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, "'srvloc@srvloc.org'" , "'aaa-wg@merit.edu'" , "'manet@itd.nrl.navy.mil'" , "'ipsec@lists.tislabs.com'" , "'ipsec-policy@vpnc.org'" , "'ietf-ipsra@vpnc.org'" , "'ietf-sacred@imc.org'" , "'enum@ietf.org'" , "'sigtran@standards.nortelnetworks.com'" , "'ietf@ietf.org'" , "'IETF-Announce@ietf.org'" , "'BLUETOOTH-BOF@mailbag.cps.intel.com'" Cc: "'Thomas Narten'" , Akers Ron-WRA001 Subject: BOF: IP over Bluetooth for 50th Meeting of IETF. Date: Fri, 9 Feb 2001 19:02:30 -0500 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 Myself and Ron Akers have requested an IP over Bluetooth BOF for the 50th Meeting of the IETF in Minneapolis. The BOF will discuss the creation of a IETF Working Group to investigate the most open and efficient way to place IP over the Bluetooth Host Controller. Current work in this area within the Bluetooth SIG concentrates on defining IP over a set of other lower-layer stacks. Currently there are two options defined by the Bluetoth SIG: Option 1: IP/PPP/RFCOM/L2CAP/Host Controller Option 2: IP/PAN Profile/L2CAP/Host Controller (where the PAN Profile is a Bluetooth SIG work in progress) We are proposing that the IETF form a WG to define a more efficient way of running IP over Bluetooth. In particular, IP would run over an IETF protocol over the Host Controller without L2CAP. This option may be adopted by the Bluetooth SIG at a later date as a Profile. Since all Bluetooth SIG Profiles are optional, a customer may choose any combination of Profiles in a final product. Further, since Bluetooth Working Groups have it in their mandate to adopt protocols from other standards making bodies such as the IETF, there exists a clear path for IETF work to be adopted by the Bluetooth SIG. Whereas the last BOF was informational only and organized by the Bluetooth SIG itself, the objective of this BOF will be to foster innovation, and speed progress by placing IP related protocol development wihin the IETF and Bluetooth-specific protocol development within the Bluetooth SIG, by developing an IP over Bluetooth IETF Working Group. This effort will define its own way of running IP over Bluetooth, by carefully selecting a set of Bluetooth protocols (freely available from published specifications at http://www.bluetooth.com/developer/specification/specification.asp) on which to build IP. Please join myself, Kulwinder Atwal, and Ron Akers on the pre-BOF mailing list: This site runs version 2.0.1 of the "Mailman" list manager. The following describes commands you can send to get information about, and control your subscription to the lists at this site. Note that much of the following can also be accomplished via the World Wide Web, at: http://internet.motlabs.com/mailman/listinfo/bluetooth In particular, you can use the Web site to have your password sent to your delivery address. Email commands can be in the subject line or in the body of the message. The commands should be set to the following address: About the descriptions - words in "<>"s signify REQUIRED items and words in "[]" denote OPTIONAL items. Do not include the "<>"s or "[]"s when you use the commands. The following commands are valid: subscribe [password] [digest-option] [address=
] Subscribe to the mailing list. Your password must be given to unsubscribe or change your options. When you subscribe to the list, you'll be reminded of your password periodically. 'digest-option' may be either: 'nodigest' or 'digest' (no quotes!) If you wish to subscribe an address other than the address you send this request from, you may specify "address=" (no brackets around the email address, no quotes!) unsubscribe [address] Unsubscribe from the mailing list. Your password must match the one you gave when you subscribed. If you are trying to unsubscribe from a different address than the one you subscribed from, you may specify it in the 'address' field. who See everyone who is on this mailing list. info View the introductory information for this list. lists See what mailing lists are run by this Mailman server. help This message. set