From owner-ipsec Wed Jan 1 13:01:04 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05456 Wed, 1 Jan 2003 12:53:21 -0500 (EST) Message-Id: <200301011755.h01HtEJA021700@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Summary of MITM attacks with legacy authentication In-reply-to: Your message of "Tue, 31 Dec 2002 17:03:49 EST." <5.1.0.14.0.20021231163015.00a75ec0@pop.theworld.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 01 Jan 2003 12:55:14 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Jablon writes: David> At 04:04 PM 12/31/02 -0500, Michael Richardson wrote: Charlie> My reading of the SLA proposal is that the mechanisms supported are: Charlie> (1) password sent to Bob, >> >> note that for MD5/DES/Unix-style /etc/passwd, Bob doesn't have a secret, >> just a way to check a value. David> In a responsible implementation, Bob *does* have a secret: David> the hashed password. Exactly how he might use it to verify David> that Alice knows the password depends on the method. For Unix-style /etc/passwd, dictionary attacks (i.e. "crack") aside, the hashed value is actually not a secret. Unix systems get additional defense against "crack" by keeping is secret. The important point is that Bob has no way to generate the same value as Alice. If they could, they could just use that as a PSK, or we could use CHAP. We can not do either with /etc/passwd style passwords. Charlie> OK, guys. How much of this did I get wrong. >> >> I think that you got it perfectly correct. >> But, I think that this is why Legacy Auth is a pain. This is why we must >> make it easy to bootstrap into public key authentication, permitting it to >> be deployed easily - this starts by not tying it to PK*I*. David> I don't understand that reasoning. The option to tie legacy credentials David> to an IKEv2 key may be an important step to make it easy for some David> to bootstrap into public key authentication. When one can establish No, you are missing my point. A common reason for sticking to a legacy authentication method, such, as for instance, NT-domain authentication (which involves no investment in physical tokens, for instance), is because of the very real fact that the only way to move beyond it with many products is to move to a full blown PKI. This makes no sense in a 20 person office. There needs to be things in between PSK/legacy auth, and full-blown PKI. Those things are: 1) raw RSA keys (pre-exchanged) 2) self-signed certificates (pre-exchanged) 3) signed certificates by an untrusted party (signed by, e.g. Verisign's free CA, but pre-exchanged) Note that pretty much all of the legacy auth proposals want the client to authenticate the server using a public key. Yet, many clients/gateways are too locked into their PKIs to even permit a self-signed certificate to be easily loaded in as a trusted key. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPhMrgIqHRg3pndX9AQGecAP6A1mmD8P2NULk7RntTeAV0MFbozwX+Ouo 7aqeqY2F1T9Z/KIA3+FoIjBs9zcwoMtT4v5O4w1XnOE1Lpy5CizMATe93XYXYacP +DBxidC/Qpm6SDx13J4SmMF8rjiqRXYvIPWxXuY1KZc4ZnOrTlQyBSg2jO4x82GS NiWaJ6JJFAg= =8tO0 -----END PGP SIGNATURE----- From owner-ipsec Wed Jan 1 13:42:40 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05547 Wed, 1 Jan 2003 13:38:26 -0500 (EST) Message-Id: <200301011839.h01IdlFq022330@sandelman.ottawa.on.ca> To: IPsec WG Subject: Re: Secure legacy authentication for IKEv2 In-reply-to: Your message of "Wed, 01 Jan 2003 01:03:04 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 01 Jan 2003 13:39:47 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> However, SLA with "proprietary" formats does not solve the problem, it just Hugo> makes it harder for people to use these methods. It requires defining an SLA Hugo> profile for these methods, but if such a profile is created then the mitm Hugo> problem is there again. You are probably right. If we can make it work with EAP, I think that we should. If we have to push on the EAP folks to give us something so that we can bind things together properly - giving Bob half a chance here - then I think we should go that way. Hugo> 1) ipsec people can live with doing ONLY weak [*] methods such as those Hugo> defined in the SLA profiles now (Secure-id, OTP, chall/resp) for which the Hugo> specific encapsulation method (SLA-specific or EAP) makes no difference to Hugo> their security Can we get some other vendor/consultant opinion here? My mandate within FreeS/WAN says that I'm supposed to try to replace this stuff with public key stuff. Previous hats that I've worn as a firewall vendor were sufficiently long ago, that people still thought S/Key was "neat". My consulting experience is with people who outgrow PSK and are scared of PKI. They aren't going to go buy X9.9 devices for everyone. My impression is that the push to support these systems is largely coming from people who have money invested in: 1) SecurID cards 2) X9.9 devices (CryptoCard, etc...) 3) NT-domain authentication/radius (i.e. passwords which can not be used as PSKs, due to secret being unavailable to Bob) Kerberos based methods would be better supported by KINK. Or, is KINK on the list due to it being supported by EAP? The reason for asking this, is because I really think that this is about *legacy* - and by this, I mean - things already paid and deployed. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPhM11oqHRg3pndX9AQE/kQP6A2ayP6RFBh5KTJCC/O6+JEtLeMwCVkZC MbZJyKsL4nL+l3Et4BQCCbtPm3C53QkAVI+Jaw8UdgITvPn7BZKBUdMKufUQHzxW LpOe7Gb1LYaxltgRhAa4W8Jn+rwU99X4v/Sl0GL6WJxJSlKolQDDaABbVJTgHHhO e78MHN50yIc= =W+g0 -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 2 08:55:54 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09947 Thu, 2 Jan 2003 08:45:06 -0500 (EST) Message-Id: <5.1.0.14.0.20021231163015.00a75ec0@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Dec 2002 17:03:49 -0500 To: ipsec@lists.tislabs.com From: David Jablon Subject: Re: Summary of MITM attacks with legacy authentication Cc: Michael Richardson In-Reply-To: <200212312104.gBVL4WWi004154@sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:04 PM 12/31/02 -0500, Michael Richardson wrote: > Charlie> My reading of the SLA proposal is that the mechanisms supported are: > Charlie> (1) password sent to Bob, > > note that for MD5/DES/Unix-style /etc/passwd, Bob doesn't have a secret, >just a way to check a value. In a responsible implementation, Bob *does* have a secret: the hashed password. Exactly how he might use it to verify that Alice knows the password depends on the method. SLA (1) simply sends the password to the server, so what a smarter server might be able to do in another protocol is somewhat irrelevant. But it is important to consider when discussing a more general framework for handling legacy credentials. > Charlie> (2) OTP password sent to Bob, [...] > Charlie> (3) Challenge-Response Card [...] > Charlie> (4) SecurID [...] > Charlie> For all of these mechanisms, MITM protection is impossible because those > Charlie> protocols require that the secret value (and not just a hash of it) be > Charlie> available on the server for verification. > > If it were possible to include some non-transmitted value into the >SKEYSEED, >we might be able to cause the MITM to be unable derive the same >sessions keys. This could be accomplished in X9.9 and SecurID by not >transmitting the entire displayed value - both ends can derive it in >theory. In practice, Bob will use Radius or some such to verify the value, >and the standard protocols do not return the "correct" value to Bob. Without commenting on this specific approach, it is one example of how a more general framework could take advantage of added keying material. > Charlie> OK, guys. How much of this did I get wrong. > > I think that you got it perfectly correct. > But, I think that this is why Legacy Auth is a pain. This is why we must >make it easy to bootstrap into public key authentication, permitting it to >be deployed easily - this starts by not tying it to PK*I*. I don't understand that reasoning. The option to tie legacy credentials to an IKEv2 key may be an important step to make it easy for some to bootstrap into public key authentication. When one can establish a secure connection based soley on a legacy credential, one can find ways to use that connection to securely transfer other necessary information. -- David From owner-ipsec Thu Jan 2 12:24:07 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10975 Thu, 2 Jan 2003 12:17:22 -0500 (EST) Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-05.txt From: Steve Dispensa To: Ari Huttunen Cc: ipsec@lists.tislabs.com In-Reply-To: <3E0B24C7.2000908@F-Secure.com> References: <200212231255.HAA27622@ietf.org> <1040763337.6761.26.camel@stratocaster.positivenetworks.net> <3E0B24C7.2000908@F-Secure.com> Content-Type: text/plain Organization: Positive Networks Message-Id: <1041527767.2790.23.camel@stratocaster.positivenetworks.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 02 Jan 2003 11:16:07 -0600 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2002-12-26 at 09:48, Ari Huttunen wrote: > Steve Dispensa wrote: > > This may be a typo, but the second paragraph of the introduction > > states: "It is up to the need of the clients whether transport mode or > > tunnel mode is to be supported. L2TP/IPsec clients MUST support > > transport mode since [RFC 3193] defines that L2TP/IPsec MUST use > > transport mode], and IPsec tunnel mode clients MUST support tunnel > > mode." Note that RFC 3193 does not, in fact, require the use of > > transport mode with L2TP, just that implementations support transport > > mode. (RFC 3193 section 2.1) This is sort of cleared up in the next > > sentence, but the wording should probably be fixed. > > RFC 3193 seems to say "Transport mode MUST be supported; tunnel > mode MAY be supported." > > We could rephrase the introduction to be something like this, because > otherwise we'd no longer even optionally support this tunnel mode > L2TP/IPsec. Or so it could be seen. At least that's what I see > was intended originally. (Note that I've not read RFC 3193 in full and > hopefully never will.) > > It is up to the need of the clients whether transport mode > or tunnel mode is to be supported. L2TP/IPsec clients MUST support > transport mode and MAY support tunnel mode, as defined in [RFC 3193]. > IPsec tunnel mode clients MUST support tunnel mode. Better; see below. > > FWIW, this is a bit of a sore spot with me. We regularly use L2TP over > > tunnel mode due to separation of the l2tp server from the IPSEC > > concentrator. This creates problems on the client side (Windows users > > in particular) due to dumb client implementations. > > Well, looks to me like those Windows clients are behaving > according to RFC 3193, by not implementing tunnel mode. Tough luck. Not incorrect, just dumb. However, why again is tunnel mode not a 'must'? It seems like an exception case. No IPSEC mode is specified for other traffic; it just matches by policy (or not). We have singled out L2TP as a particular traffic type for which compliant implementations need not bother supporting tunnel mode. Seems oddly arbitrary, and based on an expected implementation that (for me) doesn't work well. -sd From owner-ipsec Thu Jan 2 13:04:42 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11189 Thu, 2 Jan 2003 13:00:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1041527767.2790.23.camel@stratocaster.positivenetworks.net> References: <200212231255.HAA27622@ietf.org> <1040763337.6761.26.camel@stratocaster.positivenetworks.net> <3E0B24C7.2000908@F-Secure.com> <1041527767.2790.23.camel@stratocaster.positivenetworks.net> Date: Thu, 2 Jan 2003 13:01:34 -0500 To: Steve Dispensa From: Stephen Kent Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-05.txt Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:16 AM -0600 1/2/03, Steve Dispensa wrote: > > >Not incorrect, just dumb. However, why again is tunnel mode not a >'must'? It seems like an exception case. No IPSEC mode is specified >for other traffic; it just matches by policy (or not). We have singled >out L2TP as a particular traffic type for which compliant >implementations need not bother supporting tunnel mode. Seems oddly >arbitrary, and based on an expected implementation that (for me) doesn't >work well. > > -sd The IPsec WG didn't specify how to use IPsec with L2TP; the L2TP WG did. We pointed out why we believed tunnel mode was preferable, but they choose to use transport mode instead, perhaps to reduce per-packet overhead. Steve From owner-ipsec Thu Jan 2 14:17:22 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11832 Thu, 2 Jan 2003 14:12:50 -0500 (EST) From: mlafon@arkoon.net X-Lotus-FromDomain: ARKOON To: ipsec@lists.tislabs.com Message-ID: Date: Thu, 2 Jan 2003 20:13:34 +0100 Subject: dratf-ietf-ipsec-nat-t-ike-05.txt ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the IP Security Protocol Working Group of the IETF. >> >> Title : UDP Encapsulation of IPsec Packets >> Author(s) : A. Huttunen et al. >> Filename : draft-ietf-ipsec-udp-encaps-05.txt >> Pages : 0 >> Date : 2002-12-20 Why draft-ietf-ipsec-nat-t-ike-05 has still not been released ? It is referenced in draft-ietf-ipsec-udp-encaps-05 (2002.12.20) but it isn't in the Internet-Drafts directory. Any reasons ? -- Mathieu Lafon - Arkoon Network Security From owner-ipsec Thu Jan 2 14:22:46 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11910 Thu, 2 Jan 2003 14:19:56 -0500 (EST) Message-Id: <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Jan 2003 13:55:23 -0500 To: Thomas Hardjono From: Russ Housley Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: kent@bbn.com, canetti@watson.ibm.com, mbaugher@cisco.com, bew@cisco.com, msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thomas: I have a follow up question to your first ESP recommendation. >--------------------------------------------------------------------- >ESPbis-change#1: SPI allocation and SA lookup > >Section 2.1 (Security Parameters Index) specifies exactly how the >SPI should be dealt with: > > For multicast SAs, the SPI (and optionally the protocol ID) in > combination with the destination address is used to select an SA. > This is because multicast SAs are defined by a multicast > controller, not by each IPsec receiver. (See the Security > Architecture document for more details) [ESPbis]. > >We propose this section to be replaced with the following wording: > > For broadcast, multicast, and anycast SAs, the SPI and protocol > ID (ESP) in combination with the destination address is used to > select an SA. In some cases, other parameters (such as a source > address) MAY be used by a receiver to further identify the > correct SA. This is because multicast SAs may be defined by more > than one multicast group controller. >--------------------------------------------------------------------- Would it help if the SPI indicated whether the associated security association was unicastor multicast (which includes broadcast and anycast)? If there were an indication in the SPI itself, then the implementation would know if the unicast or multicast rules should be applied. If this is of value, the most significant bit could be used to indicate the security association type. Russ From owner-ipsec Thu Jan 2 18:49:51 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13064 Thu, 2 Jan 2003 18:44:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> References: <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> Date: Thu, 2 Jan 2003 18:47:26 -0500 To: Russ Housley From: Stephen Kent Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: Thomas Hardjono , canetti@watson.ibm.com, mbaugher@cisco.com, bew@cisco.com, msec@securemulticast.org, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:55 PM -0500 1/2/03, Russ Housley wrote: >Thomas: > >I have a follow up question to your first ESP recommendation. > >>--------------------------------------------------------------------- >>ESPbis-change#1: SPI allocation and SA lookup >> >>Section 2.1 (Security Parameters Index) specifies exactly how the >>SPI should be dealt with: >> >> For multicast SAs, the SPI (and optionally the protocol ID) in >> combination with the destination address is used to select an SA. >> This is because multicast SAs are defined by a multicast >> controller, not by each IPsec receiver. (See the Security >> Architecture document for more details) [ESPbis]. >> >>We propose this section to be replaced with the following wording: >> >> For broadcast, multicast, and anycast SAs, the SPI and protocol >> ID (ESP) in combination with the destination address is used to >> select an SA. In some cases, other parameters (such as a source >> address) MAY be used by a receiver to further identify the >> correct SA. This is because multicast SAs may be defined by more >> than one multicast group controller. >>--------------------------------------------------------------------- > >Would it help if the SPI indicated whether the associated security >association was unicastor multicast (which includes broadcast and >anycast)? If there were an indication in the SPI itself, then the >implementation would know if the unicast or multicast rules should >be applied. > >If this is of value, the most significant bit could be used to >indicate the security association type. > >Russ Russ, The receiver needs an easy way to tell what fields to examine, and it needs to do so very early in the demuxing process. Otherwise this could become a rate-limiting part of processing. Your suggestion may be a good one, so long as we agree that we will not need to provide more ways of distinguishing which demuxing rules to use, else we would need to reserve even more of the SPI space for further subdividing. From owner-ipsec Fri Jan 3 09:25:48 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02882 Fri, 3 Jan 2003 09:18:15 -0500 (EST) Message-Id: <5.1.0.14.0.20030101154404.00a35170@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Jan 2003 17:46:59 -0500 To: IPsec WG From: David Jablon Subject: Re: "legacy" confusion (was Re: Summary of MITM attacks with legacy authentication) In-Reply-To: References: <5.1.0.14.0.20021231131024.00a746e0@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, I do understand the concept of running a client authentication method as is. But as much as it is an important concern in designing a general framework, the ability to run a method "as is" is hardly a unique aspect or useful discriminator for the definition of "legacy method". I believe overuse of the "legacy" modifier has caused a lot of this confusion over conflicting or irrelevant distinctions. Your comments on trivial solutions do not address my point that the issue of "mixed runs" is not the only issue of concern when binding authentication to keying material. I posted a proposal in a related thread that discusses other general benefits of solutions that bind both client and server authentication to keying material, for example, to address server-spoofing attacks that take advantage of user error. I agree that we may have the luxury of a number of several easy solutions, but we should clarify where these solutions cover different sets of potential problems. Charlie's post noted two classes of solutions that serve the common goal of binding client authentication to the session key: (1) to bind authentication keying material into the IKEv2 keys. (2) to bind the IKEv2 server-authenticated key into client authentication. For what it's worth, one reason to favor class (1) over class (2) is that (1) could support any key-generating EAP method "as is". -- David At 01:12 AM 1/1/03 +0200, Hugo Krawczyk wrote: >David, in your description below you are missing one of the main aspects >of *legacy* methods, namely, that you run them "as is" (i.e. as a "plug >in" and without modifications). If you could modify or redesign them >then, as said many times, you can trivially solve all these irritating >mitm issues in mixed runs by binding the authentication to the protocol's >context (server name, encapsulating tunnel protocol, etc). > >Hugo > >On Tue, 31 Dec 2002, David Jablon wrote: > >> Charlie's summary valiantly dispels some confusion in this discussion, >> and yet it still perpetuates some of it in too-loosely using the term "legacy". >> > "Legacy" seems to have a clear and useful meaning within "legacy credentials". >> There it means something other than a shared key or private/public >> key pair, like a static password or one-time password, essentially any >> non-key data that has historically been simply transmitted to prove >> identity in olden-days. >> >> But "legacy" has no clear meaning in "legacy authentication method". >> From various threads of discussion, this phrase can be interpreted to >> mean a method with almost any combination of the following characteristics: >> >> -- uses a "legacy credential" for authentication >> -- requires secure transmission of the credential >> -- does not require a key >> -- does not establish a key >> -- has been widely used (defined arbitrarily) >> -- has been in use since Month Day, Year (fill in as desired) >> >> The term "Secure Legacy Authentication" is especially confusing >> when it is limited to encompass *only* methods that have historically >> used legacy credentials in *insecure* ways. >> >> This confusion is perpetuated further in reference to Kerberos, MD5-CRAM, >> and SRP as "stronger legacy mechanisms". "Legacy" in what sense? >> "Stronger" than what, and in what ways? Discussions will likely continue >> to circle in unproductive ways until our legacy jargon is replaced. >> >> The common theme seems simple: methods that use passwords as credentials, >> including both re-usable passwords and one-time passwords (e.g. SecurID). >> >> In discussions of threat scenarios it certainly makes sense to distinguish >> between sub-classes of such methods. But when discussing a framework >> for how they can be plugged-in to IKEv2, it seems to make more sense to treat >> them as a comprehensive class in so far as there is no technically >> compelling reason to subdivide. >> >> -- David From owner-ipsec Fri Jan 3 09:25:48 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03082 Fri, 3 Jan 2003 09:21:24 -0500 (EST) Subject: Need Help on IKE implementation (Protocol & Ports) From: venkat To: IPSec Mail Group Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NvUgBKMiPsdP9Ej9Ywii" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jan 2003 15:46:08 +0530 Message-Id: <1041588968.1054.27.camel@venkat> Mime-Version: 1.0 X-Mailserver: Sent using PostMaster (v4.1.13) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=-NvUgBKMiPsdP9Ej9Ywii Content-Type: text/plain Content-Transfer-Encoding: quoted-printable IKE Implementation:: Ports:: UDP/TCP To my understanding IKE should be implemented on UDP/500, but while designing the DOI components it has come to my knowledge that there could be a TCP implementation for IKE.(TCP/500) Could someone clarify on this doubt. Do I integrate both UDP and TCP so that if the negotiation first fails in UDP then we try a TCP conn. Thanks in advance - Venkat --=-NvUgBKMiPsdP9Ej9Ywii Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA+FWLofFa7Ol5nHJkRAv70AJ9QHWEkwni0ToBdsc28Lan/02QVtgCfTmwL Ff94b/Xkic4uKzFXk5vZwJs= =s0Ou -----END PGP SIGNATURE----- --=-NvUgBKMiPsdP9Ej9Ywii Content-Type: text/plain -------------------------------------------------------------- Dexcel Electronics Designs (P) Ltd., Bangalore, India --=-NvUgBKMiPsdP9Ej9Ywii-- From owner-ipsec Fri Jan 3 09:25:47 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02879 Fri, 3 Jan 2003 09:18:14 -0500 (EST) X-Originating-IP: [207.6.242.120] From: "Andrew Krywaniuk" To: dharkins@tibernian.com Cc: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 Date: Thu, 02 Jan 2003 20:56:44 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jan 2003 01:56:45.0194 (UTC) FILETIME=[5E6A86A0:01C2B2CB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But I think your solution would only work for EAP methods that >protect the EAP conversation themselves (like EAP-TLS). If Alice was >to speak EAP-OTP then the attacker could just splice in the "I am >running EAP over an IPsec tunnel" attribute. But when I pointed this out before, I was careful to distinguish between SLA techniques that are MitM-proof *before* we tunnel them over IPsec and those that are already vulnerable to MitM without the addition of IPsec. It seems to me that EAP-OTP would fall into the latter category. My point is that adding a private attribute to EAP is merely a different way of creating a new SLA exchange. This solves the MitM problem for the case where the attacker couldn't mount a MitM attack purely using dial-up. Rather than arguing which attack is possible when, we should be deciding whether it is easier to extend EAP or define our own payload format. Paul already stated that he thinks EAP is too difficult to extend, but we should solicit some more opinions from EAP experts. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. >From: Dan Harkins >To: "Andrew Krywaniuk" >CC: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com >Subject: Re: Secure legacy authentication for IKEv2 Date: Tue, 31 Dec 2002 >08:16:24 -0800 > > Andrew, > > It's probably easier to add things in the EAP WG than the IPsec WG :-) > > But I think your solution would only work for EAP methods that >protect the EAP conversation themselves (like EAP-TLS). If Alice was >to speak EAP-OTP then the attacker could just splice in the "I am >running EAP over an IPsec tunnel" attribute. > > Dan. > >On Tue, 31 Dec 2002 04:27:53 EST you wrote > > > > I suggested a long time ago that we could solve the problem by simply >adding > > a private attribute that says "I am running EAP over an IPsec tunnel", >but I > > was told that adding a new EAP attribute is so hard that it would be >easier > > to design our own SLA protocol. I don't really know enough about EAP to > > confirm or deny this. > > > > Andrew > > -------------------------------------- > > The odd thing about fairness is when > > we strive so hard to be equitable > > that we forget to be correct. > > > > > > I do not agree. The problem is really with legacy authentication > > *protocols*, > > not with legacy *credentials*. If you let me re-design even the most >basic > > of pswd authentication protocols such as CHAP I will do it in a way that > > will change the protocol very slightly (and will use passwds the same >way > > CHAP uses now) but will make the modified protocol resistant to the MitM > > attacks we were discussing here. How? Simply put under the response > > computation the name of the server with which you are comunicating and >(if > > possible) the name of the tunnel protocol under which the protocol is >run > > (with a special "protocol name" for "no tunneling"). Needless to say >this > > does not resolve dictionary attacks if the protocol is run unprotected >but > > that is something that NO solution can avoid (except of course for NOT > > running the protocol unprotected or for switching to dictionary-attack > > resistant methods (which exist of course but not as "legacy"). > > > > > > > > _________________________________________________________________ > > MSN 8: advanced junk mail protection and 3 months FREE*. > > >http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474 > >&SU= > > >http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_advancedjmf_ > >3mf > > _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec Fri Jan 3 09:25:47 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02656 Fri, 3 Jan 2003 09:15:58 -0500 (EST) Message-Id: <5.1.0.14.0.20030102152710.04879d20@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Jan 2003 15:27:11 -0500 To: ipsec@lists.tislabs.com From: David Jablon Subject: A proposal Cc: Paul.Hoffman@vpnc.org, Charlie_Kaufman@notesdev.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here's what seems to me to be an obviously simple and secure extension. I'll be glad to hear feedback of where it fits on other people's conceptual scale from "trivial" to "destroys valuable security properties". Proposal From my reading of www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-03.txt, optional added key material from supplementary authentication methods could be bound to the IKEv2 server-only authenticated key using: KEYMAT = prf+(SK_d, [added_key_material] | Ni | Nr, g^ir) This would extend and replace the existing specification of: KEYMAT = prf+(SK_d, Ni | Nr, g^ir) This fits with IKEv2 with minimal change, and it should not disturb any security analysis of the current IKEv2 specification. It is identical to the way that added key material from a secondary DH exchange is incorporated. The peers' mutual decision to incorporate added_key_material would result from the same process by which they agree to use any optional supplementary authentication method. Note: This presumes that the design of the method that provides the added_key_material endorses the concept of exporting it for session encryption or other such general purposes, especially from the perspective of protecting any supplementary credentials. Such analysis is outside the scope of the IKEv2 draft itself, but should be provided in the definition of the supplementary authentication method and/or framework. Rationale Here's a rationale for proposing this for IKEv2 and either a suitably-extended SLA or any similar proposal for integrating client authentication based on legacy credentials. In a server-only authenticated model, it is far from obvious that a client user will always do what is necessary to insure that the client machine first authenticates the identity of the server in all deployed scenarios. One can categorize these scenarios, and create all kinds of hypotheses, but it should be apparent that the server-only authenticated key model is not as robust as a properly combined server + client authenticated key model. At worst, the server-only authentication model may be prone to mis-use and a variety of so-called server-spoofing attacks. The idea of binding key material from separate acts of client and server authentication is to make key disclosure require the failure of both client and server authentication, rather than a failure of just either one independently. This principle is at least as appropriate when using legacy credentials as it is when using private keys in the standard dual-signature model. A wire protocol specification can only go so far in constraining the actions of client and server devices, let alone the actions of the people who use them. A robust extensible protocol merely enables these devices to do whatever they can to eliminate opportunities for user error. Having IKEv2 able to use added keying material from legacy credentials gives an implementor more ability to safeguard the protocol against server-authentication failures. While it is true that most protocols, clients, and servers today that handle legacy credentials provide no added key material, regardless of the relative proportions of today's installed base, it would be a shame for a new general framework to unnecessarily limit itself to supporting only the least robust of available methods. -- David At 08:15 AM 12/23/02 -0800, Paul Hoffman / VPNC wrote: >The same argument goes for IKEv2's authentication. Are you saying that we should change the key derivation for IKEv2 itself to include material from those authentication methods? If so, please suggest text so the cryptographers can analyze it. > >The current IKEv2 draft has: > > SKEYSEED = prf(Ni | Nr, g^ir) > {SK_d, SK_ai, SK_ar, SK_ei, SK_er} > = prf+ (SKEYSEED, Ni | Nr | CKY-I | CKY-R) > >What is your proposal for improving this in a provably secure way? From owner-ipsec Fri Jan 3 14:26:00 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20419 Fri, 3 Jan 2003 14:18:55 -0500 (EST) Message-Id: <5.0.0.25.2.20030103141628.04104cd0@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 03 Jan 2003 14:20:41 -0500 To: Russ Housley , Thomas Hardjono From: Thomas Hardjono Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: kent@bbn.com, canetti@watson.ibm.com, mbaugher@cisco.com, bew@cisco.com, msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> References: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, The SMuG group a couple of years did consider putting some structure/meaning into the SPI, but the idea was not followed through due to the (perceived) difficulty of moving the idea through the IPsec WG. cheers, thomas ------ At 1/2/2003||01:55 PM, Russ Housley wrote: >Thomas: > >I have a follow up question to your first ESP recommendation. > >>--------------------------------------------------------------------- >>ESPbis-change#1: SPI allocation and SA lookup >> >>Section 2.1 (Security Parameters Index) specifies exactly how the >>SPI should be dealt with: >> >> For multicast SAs, the SPI (and optionally the protocol ID) in >> combination with the destination address is used to select an SA. >> This is because multicast SAs are defined by a multicast >> controller, not by each IPsec receiver. (See the Security >> Architecture document for more details) [ESPbis]. >> >>We propose this section to be replaced with the following wording: >> >> For broadcast, multicast, and anycast SAs, the SPI and protocol >> ID (ESP) in combination with the destination address is used to >> select an SA. In some cases, other parameters (such as a source >> address) MAY be used by a receiver to further identify the >> correct SA. This is because multicast SAs may be defined by more >> than one multicast group controller. >>--------------------------------------------------------------------- > >Would it help if the SPI indicated whether the associated security >association was unicastor multicast (which includes broadcast and >anycast)? If there were an indication in the SPI itself, then the >implementation would know if the unicast or multicast rules should be applied. > >If this is of value, the most significant bit could be used to indicate >the security association type. > >Russ From owner-ipsec Sat Jan 4 21:10:54 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25431 Sat, 4 Jan 2003 21:02:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15895.37558.320000.319012@gargle.gargle.HOWL> Date: Sat, 4 Jan 2003 21:04:38 -0500 From: Paul Koning To: housley@vigilsec.com Cc: ipsec@lists.tislabs.com Subject: Re: Counter Mode: Proposed Way Forward References: <15845.1606.961113.340051@pkoning.dev.equallogic.com> <5.2.0.9.2.20021230143009.00ba5388@mail.binhost.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Russ" == Russ Housley writes: Russ> I updated the AES Counter Mode draft. It should be posted as Russ> soon as the repository administrator returns from the holiday Russ> break. The document describes the use of a nonce as previously Russ> discussed on the list. And, a new section describes the way Russ> that IKE can provide the nonce. This is the only part that has Russ> not already been discussed on the list, so I am posting it here Russ> to foster discussion. Russ> 5. IKE Conventions Russ> As described in section 2.1, implementations MUST use fresh Russ> keys with AES-CTR. The Internet Key Exchange (IKE) [IKE] Russ> protocol can be used to establish fresh keys. IKE can also Russ> provide the nonce value. This section describes the Russ> conventions for obtaining the unpredictable nonce from IKE. Russ> The IKE_SA_init and the IKE_SA_init_response each contain a Russ> nonce. These nonces are used as inputs to cryptographic Russ> functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA Russ> response also contain nonces. These nonces are used to add Russ> freshness to keys for child security associations. In both Russ> cases, these nonces are unpredictable, they are longer than 32 Russ> bits, and IKE transfers the nonce value to the peer. Russ> Each party will use the nonce that it generated for encryption, Russ> and the nonce that the other party generated for decryption. Russ> The 32 least significant bits of the nonce used to establish Russ> the security association will be used in the AES-CTR counter Russ> block. For the first security association, the nonces come Russ> from the IKE_SA_init and IKE_SA_init_response. For subsequent Russ> security associations, the nonces come from the CREATE_CHILD_SA Russ> request and CREATE_CHILD_SA response. Why not simply use some more of the generated key material for the nonce? That seems a lot cleaner than reaching into the internals of IKE for the bits you need. paul From owner-ipsec Sun Jan 5 14:26:30 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26640 Sun, 5 Jan 2003 14:20:52 -0500 (EST) Message-Id: <5.2.0.9.2.20030105141806.00b4c600@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 05 Jan 2003 14:22:38 -0500 To: Paul Koning From: Russ Housley Subject: Re: Counter Mode: Proposed Way Forward Cc: ipsec@lists.tislabs.com In-Reply-To: <15895.37558.320000.319012@gargle.gargle.HOWL> References: <15845.1606.961113.340051@pkoning.dev.equallogic.com> <5.2.0.9.2.20021230143009.00ba5388@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul: There is no need to keep the nonce secret, it just needs to be unpredictable. Given these requirements, there were several discussion over the course of the IETF meeting in Atlanta. I simply documented the conclusion from those discussions. Your proposal obviously works too, but it exceeds the requirements. Do others agree with the conclusion from the discussions in Atlanta? Or, do others like the suggestion made by Paul? Since both obviously meet the requirements, the structure of existing implementations should probably guide us. The people that I talked to in Atlanta saw no problem with the use of IKE nonces. Russ At 09:04 PM 1/4/2003 -0500, Paul Koning wrote: > >>>>> "Russ" == Russ Housley writes: > > Russ> I updated the AES Counter Mode draft. It should be posted as > Russ> soon as the repository administrator returns from the holiday > Russ> break. The document describes the use of a nonce as previously > Russ> discussed on the list. And, a new section describes the way > Russ> that IKE can provide the nonce. This is the only part that has > Russ> not already been discussed on the list, so I am posting it here > Russ> to foster discussion. > > Russ> 5. IKE Conventions > > Russ> As described in section 2.1, implementations MUST use fresh > Russ> keys with AES-CTR. The Internet Key Exchange (IKE) [IKE] > Russ> protocol can be used to establish fresh keys. IKE can also > Russ> provide the nonce value. This section describes the > Russ> conventions for obtaining the unpredictable nonce from IKE. > > Russ> The IKE_SA_init and the IKE_SA_init_response each contain a > Russ> nonce. These nonces are used as inputs to cryptographic > Russ> functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA > Russ> response also contain nonces. These nonces are used to add > Russ> freshness to keys for child security associations. In both > Russ> cases, these nonces are unpredictable, they are longer than 32 > Russ> bits, and IKE transfers the nonce value to the peer. > > Russ> Each party will use the nonce that it generated for encryption, > Russ> and the nonce that the other party generated for decryption. > Russ> The 32 least significant bits of the nonce used to establish > Russ> the security association will be used in the AES-CTR counter > Russ> block. For the first security association, the nonces come > Russ> from the IKE_SA_init and IKE_SA_init_response. For subsequent > Russ> security associations, the nonces come from the CREATE_CHILD_SA > Russ> request and CREATE_CHILD_SA response. > >Why not simply use some more of the generated key material for the >nonce? That seems a lot cleaner than reaching into the internals of >IKE for the bits you need. > > paul From owner-ipsec Mon Jan 6 01:46:41 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA27893 Mon, 6 Jan 2003 01:37:39 -0500 (EST) Date: Mon, 6 Jan 2003 08:40:17 +0200 (IST) From: Hugo Krawczyk To: David Jablon cc: IPsec WG Subject: Re: A proposal In-Reply-To: <5.1.0.14.0.20030102152710.04879d20@pop.theworld.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Jan 2003, David Jablon wrote: > Here's what seems to me to be an obviously simple and secure extension. Not so simple (due to the need to import a key from the underlying authentication method to the tunneling protocol). And definitely not obviously secure. See below. > I'll be glad to hear feedback of where it fits on other people's conceptual > scale from "trivial" to "destroys valuable security properties". > > Proposal > > From my reading of www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-03.txt, > optional added key material from supplementary authentication > methods could be bound to the IKEv2 server-only authenticated key > using: > > KEYMAT = prf+(SK_d, [added_key_material] | Ni | Nr, g^ir) > > This would extend and replace the existing specification of: > > KEYMAT = prf+(SK_d, Ni | Nr, g^ir) > > This fits with IKEv2 with minimal change, and it should not disturb > any security analysis of the current IKEv2 specification. > It is identical to the way that added key material from a secondary > DH exchange is incorporated. > > The peers' mutual decision to incorporate added_key_material would > result from the same process by which they agree to use any > optional supplementary authentication method. An obvious weakness of resolving the mitm problem via the key derivation (rather than by adding an explicit "compund authentication") is that you end the key exchange protocol without an explicit authentication that binds the two protocols. But this by itself can be considered as a DoS issue and not a security bug. However, your specific proposal introduces weaknesses beyond the DoS scenario. It is open to "known-key attacks" by the Man-in-the-mittle attacking the tunneled authentication. A known key attack is one in which the disclosure of one of the keys (e.g the authentication key) compromises another key (e.g the encryption key). Resistance to known key attacks is an important requirement of a well-designed key exchange protocol, and in particular of any good key derivation technique associated to the key exchange protocol. This is just another example of the extreme care one needs to exercise when designing or proposing changes to cryptographic protocols in general and to the subtle ikev2-related protocols in particular. I agree that on the face of it your proposal SEEMS to follow the same logic of ikev2 key derivation, but this is actually wrong. It can be shown (and I sketch this below for those interested in the details) that an attacker that knows SK_d (which is the case of the mitm attacker against which your proposal tries to protect) can mount known-key attacks even WITHOUT knowing the "added-key-material" coming from the underlying authentication method. This is NOT possible in the regular ikev2 scenario where only the legitimate parties to the exchange know SK_d. The specific attacks that I can see are not the most practical, yet they are sufficient to show that one cannot claim (or prove) the compound key derivation that you propose to be secure in a mathematical sense. A secure suggestion is to do a second prf+, similar to the one defined in ikev2, keyd with key "added-key-material", and then XOR the results of the two prf+ computations. This however ASSUMES that the key "added-key-material" was NOT used in any way (not even to key other cryptographic algorithms) in the underlying authentication protocol. And, of course, this still leaves the DoS issue mentioned above due to the lack of explicit authentication binding during the protocol. Hugo PS: for those interested to see how a known-key attack could work against the above proposal, this can be exemplified as follows. It is a bit involved, somewhat artificial and it requires patience to be understood, I will only sketch the idea. Imagine a case in which the keys derived (KEYMAT) in sla/ikev2 are later used by the responder (server) to send confidential information to the iniitator (client), without the latter sending information back. This information could be a confidential real-time stream of data or whatever. In this case, the initiator will never complete its explicit authentication in the protocol since it will never show to the responder that it knows KEYMAT. In particular if this client is the mitm against which we want to protect, this attacker will never have to show that it knows the keys derived in KEYMAT. So far this may be considered only as a DoS attack on the server (which is sending information to a fake client, but one that supposedly cannot decrypt the information). However, this is not the end of the story. Imagine that the attacker records all this information and eventually learns the authentication keys used in the session. (This can be the case if a month later the authentication key shows up in some logs from that session; note that it may make sense to log, even wthout secrecy, authentication keys from expired sessions). Now our mitm attacker can also learn the encryption keys! How? If we imagine that the prf is a block cipher (eg AES-128 or AES-256) then if you look at the prf+ derivation in ikev2 you'll see that the attacker THAT KNOWS SK_d can compute all keys derived via prf+ if it happens to know the output of a single prf+ stage (Ti), and provided that the input to each prf+ stage is no longer than the cipher block. (All of this is possible with 128-bit blocks and even more plaussible with 256-bit blocks when no g^ir is involved, in particular when running phase 1). Moreover, it is only the fortitous definition in ikev2 that specifies that encryption keys are derived from the first octets of the output of prf+, and authentication keys from the last octets, that prevents an even easier attack. Indeed, had the definition been the other way (first derive the the authentication key, then the encryption key ) an attack as above could have been mounted with ANY prf (not just block ciphers as described above) including HMAC. NONE OF THESE ATTACKS or weaknesses ARE APPLICABLE to (or be blamed on) IKEv2. They are possible because of the way the key from the underlying authentication protocol, added_key_material, is involved in the propsed key derivation. > > Note: This presumes that the design of the method that provides > the added_key_material endorses the concept of exporting it > for session encryption or other such general purposes, especially > from the perspective of protecting any supplementary credentials. > Such analysis is outside the scope of the IKEv2 draft itself, > but should be provided in the definition of the supplementary > authentication method and/or framework. > > Rationale > > Here's a rationale for proposing this for IKEv2 and either a > suitably-extended SLA or any similar proposal for integrating > client authentication based on legacy credentials. > > In a server-only authenticated model, it is far from obvious that a > client user will always do what is necessary to insure that the > client machine first authenticates the identity of the server in > all deployed scenarios. One can categorize these scenarios, and > create all kinds of hypotheses, but it should be apparent that the > server-only authenticated key model is not as robust as a properly > combined server + client authenticated key model. At worst, the > server-only authentication model may be prone to mis-use and > a variety of so-called server-spoofing attacks. > > The idea of binding key material from separate acts of client and > server authentication is to make key disclosure require the failure > of both client and server authentication, rather than a failure of just > either one independently. This principle is at least as appropriate > when using legacy credentials as it is when using private keys in > the standard dual-signature model. > > A wire protocol specification can only go so far in constraining the > actions of client and server devices, let alone the actions of > the people who use them. A robust extensible protocol merely > enables these devices to do whatever they can to eliminate > opportunities for user error. Having IKEv2 able to use added > keying material from legacy credentials gives an implementor > more ability to safeguard the protocol against server-authentication > failures. > > While it is true that most protocols, clients, and servers today > that handle legacy credentials provide no added key material, > regardless of the relative proportions of today's installed base, > it would be a shame for a new general framework to unnecessarily > limit itself to supporting only the least robust of available methods. > > -- David > > > At 08:15 AM 12/23/02 -0800, Paul Hoffman / VPNC wrote: > >The same argument goes for IKEv2's authentication. Are you saying that we should change the key derivation for IKEv2 itself to include material from those authentication methods? If so, please suggest text so the cryptographers can analyze it. > > > >The current IKEv2 draft has: > > > > SKEYSEED = prf(Ni | Nr, g^ir) > > {SK_d, SK_ai, SK_ar, SK_ei, SK_er} > > = prf+ (SKEYSEED, Ni | Nr | CKY-I | CKY-R) > > > >What is your proposal for improving this in a provably secure way? > > From owner-ipsec Mon Jan 6 12:22:35 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28576 Mon, 6 Jan 2003 12:16:10 -0500 (EST) Message-Id: <5.1.1.5.2.20030106091406.08c381d8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 06 Jan 2003 09:15:55 -0800 To: Russ Housley From: Mark Baugher Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: ipsec@lists.tislabs.com In-Reply-To: <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> References: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, At 01:55 PM 1/2/2003 -0500, Russ Housley wrote: <...> >Would it help if the SPI indicated whether the associated security >association was unicastor multicast (which includes broadcast and >anycast)? If there were an indication in the SPI itself, then the >implementation would know if the unicast or multicast rules should be applied. The receiver can deduce that by the type of address, unicast or multicast (IPv4 or v6). So there is no need to use the SPI for this purpose. Mark >If this is of value, the most significant bit could be used to indicate >the security association type. > >Russ From owner-ipsec Tue Jan 7 12:53:47 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01217 Tue, 7 Jan 2003 12:42:07 -0500 (EST) Message-Id: <200301071741.h07HfNof046164@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: peer address protection Date: Tue, 07 Jan 2003 18:41:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Peer addresses (as defined in draft-ietf-ipsec-pki-profile-01.txt) are not protected in IKE (not always in IKEv1, not at all in IKEv2 with revised identities). This opens a security hole, not against IKE itself, but using IKE to divert traffic (i.e., not a property we'd like for a security protocol). The I-D editor has just announced the new version of my I-D about the transient pseudo-NAT attack and its application to Mobile IPv4 (documented in the security section of the NAT traversal extension) and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt. I believe we should fix the issue (the security flaw) for the next version of the IKEv2 document. Regards Francis.Dupont@enst-bretagne.fr PS: I have to refresh the draft-dupont-ipsec-mipv6-01.txt too. I'm looking for co-authors... From owner-ipsec Tue Jan 7 13:04:06 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01245 Tue, 7 Jan 2003 13:02:15 -0500 (EST) Message-ID: <3E1B17DC.8000900@creeksidenet.com> Date: Tue, 07 Jan 2003 13:09:32 -0500 From: "jpickering%creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ike2 ambiguities? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While trying to understand IKE2 behavior in the face of man in the middle attacks, I noticed some ambiguities in the spec that could/should be clarified: * In section 4.2 the following statements are made: Each endpoint in the IKE Security Association maintains two "current" Message IDs: the next one to be used for a request it initiates and the next one it expects to see from the other end. These counters increment as requests are generated and received. and Note that Message IDs are cryptographically protected and provide protection against message replays. I am presuming that, for cryptographically protected messages, if the message is not authenticated, the message is rejected and message ID counters are not incremented. If this assumption is correct, the requirement should be explicitly stated somewhere. * In section 4.3 the following requirement is imposed on message initiators: An IKE endpoint MUST NOT exceed the peer's stated window size (see section 5.3.2) for transmitted IKE requests. In other words, if Bob stated his window size is N, then when Alice needs to make a request X, she MUST wait until she has received responses to all requests up through request X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) each request it has sent until it receives the corresponding response. An IKE endpoint MUST keep a copy of (or be able to regenerate with semantic equivalence) the number of previous responses equal to its contracted window size in case its response was lost and the Initiator requests its retransmission by retransmitting the request. However, the required action by a responder if a message is outside the window is not stated in the spec. One would think that an efficient method of rejecting replays would be to reject messages received outside the window. If this is the desired action, it should probably be stated. * While it would seem intuitive that an endpoint would reject all but child-SA messages after IKE-SA establishment, this is not stated in the spec. Failure to reject would allow a MitM to mount a DOS attack by replaying IKE_SA_AUTH messages with an updated message ID (unless all nonces were tracked which imho is adding undesirable state upon msg1 receipt). It would be nice to add to the draft some text about rejecting messages like this and other things that don't make sense in the current context. All feedback appreciated. Jeff From owner-ipsec Tue Jan 7 13:39:26 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01319 Tue, 7 Jan 2003 13:37:33 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200301071838.h07IcnQ05041@sydney.East.Sun.COM> Date: Tue, 7 Jan 2003 13:39:01 -0500 To: "jpickering%creeksidenet.com" , Reply-To: Subject: Re: ike2 ambiguities? X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "jpickering%creeksidenet.com" wrote: > >While trying to understand IKE2 behavior in the face of man in the >middle attacks, I >noticed some ambiguities in the spec that could/should be clarified: > >* In section 4.2 the following statements are made: > >Each endpoint in the IKE Security >Association maintains two "current" Message IDs: the next one to be >used for a request it initiates and the next one it expects to see >from the other end. These counters increment as requests are >generated and received. >and >Note that Message IDs are cryptographically protected and provide >protection against message replays. > >I am presuming that, for cryptographically protected messages, if the >message is >not authenticated, the message is rejected and message ID counters are >not incremented. >If this assumption is correct, the requirement should be explicitly >stated somewhere. Your presumption is correct. If a message is received that does not verify as authentic, it is discarded, and does not affect the message ID. > >* In section 4.3 the following requirement is imposed on message initiators: > >An IKE endpoint MUST NOT exceed the peer's stated window size (see >section 5.3.2) for transmitted IKE requests. In other words, if Bob >stated his window size is N, then when Alice needs to make a request >X, she MUST wait until she has received responses to all requests up >through request X-N. An IKE endpoint MUST keep a copy of (or be able >to regenerate exactly) each request it has sent until it receives the >corresponding response. An IKE endpoint MUST keep a copy of (or be >able to regenerate with semantic equivalence) the number of previous >responses equal to its contracted window size in case its response >was lost and the Initiator requests its retransmission by >retransmitting the request. > >However, the required action by a responder if a message is outside the >window >is not stated in the spec. One would think that an efficient method of >rejecting >replays would be to reject messages received outside the window. If this >is the >desired action, it should probably be stated. > You are correct. If a message is outside the window (too small or too large) it is rejected by the receiver. Perhaps that could be clearer in the spec, which states that the sender isn't allowed to send something outside the window, but doesn't explicitly say the receiver must reject it. >* While it would seem intuitive that an endpoint would reject all but >child-SA messages >after IKE-SA establishment, this is not stated in the spec. Failure to >reject would allow >a MitM to mount a DOS attack by replaying IKE_SA_AUTH messages with >an updated message ID (unless all nonces were tracked which imho is >adding undesirable >state upon msg1 receipt). It would be nice to add to the draft some text >about >rejecting messages like this and other things that don't make sense in >the current context. I'm not sure I quite understand this one, but I think it isn't a problem because an attacker that replayed messages would not be able to increment the message IDs, so they would be rejected without undo computation. Radia From owner-ipsec Wed Jan 8 09:01:15 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03821 Wed, 8 Jan 2003 08:56:33 -0500 (EST) Message-Id: <200301081350.IAA19678@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-02.txt Date: Wed, 08 Jan 2003 08:50:05 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES Counter Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-02.txt Pages : 18 Date : 2003-1-7 This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ctr-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-7161040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ctr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-7161040.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jan 8 09:01:15 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03815 Wed, 8 Jan 2003 08:55:33 -0500 (EST) Message-ID: <3E1B2901.7070809@creeksidenet.com> Date: Tue, 07 Jan 2003 14:22:41 -0500 From: "jpickering%creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: radia.perlman@sun.com CC: ipsec@lists.tislabs.com Subject: Re: ike2 ambiguities? References: <200301071838.h07IcnQ05041@sydney.East.Sun.COM> Content-Type: multipart/alternative; boundary="------------020804090206050703030008" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------020804090206050703030008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Radia Perlman - Boston Center for Networking wrote: > "jpickering%creeksidenet.com" wrote: > >> While trying to understand IKE2 behavior in the face of man in the >> middle attacks, I >> noticed some ambiguities in the spec that could/should be clarified: >> >> * In section 4.2 the following statements are made: >> >> Each endpoint in the IKE Security >> Association maintains two "current" Message IDs: the next one to be >> used for a request it initiates and the next one it expects to see > > >from the other end. These counters increment as requests are > >> generated and received. >> and >> Note that Message IDs are cryptographically protected and provide >> protection against message replays. >> >> I am presuming that, for cryptographically protected messages, if the >> message is >> not authenticated, the message is rejected and message ID counters are >> not incremented. >> If this assumption is correct, the requirement should be explicitly >> stated somewhere. > > > Your presumption is correct. If a message is received that does > not verify as authentic, it is discarded, and does not affect > the message ID. I guess I'd like to see this in the spec for clarity. > >> * In section 4.3 the following requirement is imposed on message initiators: >> >> An IKE endpoint MUST NOT exceed the peer's stated window size (see >> section 5.3.2) for transmitted IKE requests. In other words, if Bob >> stated his window size is N, then when Alice needs to make a request >> X, she MUST wait until she has received responses to all requests up >> through request X-N. An IKE endpoint MUST keep a copy of (or be able >> to regenerate exactly) each request it has sent until it receives the >> corresponding response. An IKE endpoint MUST keep a copy of (or be >> able to regenerate with semantic equivalence) the number of previous >> responses equal to its contracted window size in case its response >> was lost and the Initiator requests its retransmission by >> retransmitting the request. >> >> However, the required action by a responder if a message is outside the >> window >> is not stated in the spec. One would think that an efficient method of >> rejecting >> replays would be to reject messages received outside the window. If this >> is the >> desired action, it should probably be stated. >> > > You are correct. If a message is outside the window (too > small or too large) it is rejected by the receiver. Perhaps that > could be clearer in the spec, which states that the sender isn't > allowed to send something outside the window, but doesn't explicitly > say the receiver must reject it. > >> * While it would seem intuitive that an endpoint would reject all but >> child-SA messages >> after IKE-SA establishment, this is not stated in the spec. Failure to >> reject would allow >> a MitM to mount a DOS attack by replaying IKE_SA_AUTH messages with >> an updated message ID (unless all nonces were tracked which imho is >> adding undesirable >> state upon msg1 receipt). It would be nice to add to the draft some text >> about >> rejecting messages like this and other things that don't make sense in >> the current context. > > > I'm not sure I quite understand this one, but I think it isn't a problem > because an attacker that replayed messages would not be able to increment > the message IDs, so they would be rejected without undo computation. The scenario I was thinking of was if a MitM intercepted msg3, he could replay with the msgId changed to a new valid value without affecting the validity of the message since the header is not encrypted. From my reading of the spec, there is nothing that says Bob should not just blindly process this packet as an AUTH request. This would force Bob to do a DH computation. Of course, if Bob said AHA! I should not process AUTH requests if I am expecting only CHILD-SA exchanges, the DOS could be avoided. But.... there is nothing in the spec that says Bob should do this. > > Radia > > > > --------------020804090206050703030008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Radia Perlman - Boston Center for Networking wrote:
"jpickering%creeksidenet.com" <jpickering@creeksidenet.com> wrote:
While trying to understand IKE2 behavior in the face of man in the 
middle attacks, I
noticed some ambiguities in the spec that could/should be clarified:

* In section 4.2 the following statements are made:

Each endpoint in the IKE Security
Association maintains two "current" Message IDs: the next one to be
used for a request it initiates and the next one it expects to see
>from the other end. These counters increment as requests are
generated and received.
and
Note that Message IDs are cryptographically protected and provide
protection against message replays.

I am presuming that, for cryptographically protected messages, if the 
message is
not authenticated, the message is rejected and message ID counters are 
not incremented.
If this assumption is correct, the requirement should be explicitly 
stated somewhere.

Your presumption is correct. If a message is received that does
not verify as authentic, it is discarded, and does not affect
the message ID.

I guess I'd like to see this in the spec for clarity.


* In section 4.3 the following requirement is imposed on message initiators:

An IKE endpoint MUST NOT exceed the peer's stated window size (see
section 5.3.2) for transmitted IKE requests. In other words, if Bob
stated his window size is N, then when Alice needs to make a request
X, she MUST wait until she has received responses to all requests up
through request X-N. An IKE endpoint MUST keep a copy of (or be able
to regenerate exactly) each request it has sent until it receives the
corresponding response. An IKE endpoint MUST keep a copy of (or be
able to regenerate with semantic equivalence) the number of previous
responses equal to its contracted window size in case its response
was lost and the Initiator requests its retransmission by
retransmitting the request.

However, the required action by a responder if a message is outside the 
window
is not stated in the spec. One would!
 think that an efficient method of 
rejecting
replays would be to reject messages received outside the window. If this 
is the
desired action, it should probably be stated.


You are correct. If a message is outside the window (too
small or too large) it is rejected by the receiver. Perhaps that
could be clearer in the spec, which states that the sender isn't
allowed to send something outside the window, but doesn't explicitly
say the receiver must reject it.

* While it would seem intuitive that an endpoint would reject all but 
child-SA messages
after IKE-SA establishment, this is not stated in the spec. Failure to 
reject would allow
a MitM to mount a DOS attack by replaying IKE_SA_AUTH messages with
an updated message ID (unless all nonces were tracked which imho is 
adding undesirable
state upon msg1 receipt). It would be nice to add to the draft some text 
about
rejecting messages like this and other things that don't make sense in
the current context.

I'm not sure I quite understand this one, but I think it isn't a problem
because an attacker that replayed messages would not be able to increment
the message IDs, so they would be rejected without undo computation.

The scenario I was thinking of was if a MitM intercepted msg3, he could replay with the msgId changed  to a new valid
value without affecting the validity of the message since the header is not encrypted. From my reading of the
spec, there is nothing that says Bob should not just blindly process this packet as an AUTH request. This would
force Bob to do a DH computation. Of course, if Bob said AHA! I should not process AUTH requests if  I am expecting
only CHILD-SA exchanges, the DOS could be avoided. But.... there is nothing in the spec that says Bob should do
this.



Radia





--------------020804090206050703030008-- From owner-ipsec Wed Jan 8 11:35:57 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04311 Wed, 8 Jan 2003 11:30:25 -0500 (EST) Message-Id: <200301081632.h08GWCQ28307@sydney.East.Sun.COM> Date: Wed, 8 Jan 2003 11:32:12 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: ike2 ambiguities? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: x+mHMRZSqObeb8AOPlsYSg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > "jpickering%creeksidenet.com" wrote: The scenario I was thinking of was if a MitM intercepted msg3, he could replay with the msgId changed to a new valid value without affecting the validity of the message since the header is not encrypted. *********** Ah. It's true the header isn't *encrypted*, but it is integrity protected. So replay of message 3 should not be a threat. The spec could be more clear. For instance, in the descriptive intro it says: >> all fields in all >> the messages are authenticated. which certainly could lead someone to believe it's the inside of the messages and doesn't include the header. However, later in the spec (final paragraph of 5.14) it says: >>Integrity Checksum Data is the cryptographic checksum of >>the entire message starting with the Fixed IKE Header >>through the Pad Length. The checksum MUST be computed over >>the encrypted message. Admittedly I had to do some searching to find that text. Since I was involved in the design, I knew the intent was that every bit transmitted, including the header, would be integrity protected, so knew it had to be there somewhere, and still it was not easy to find. So we'll make that clearer. Radia From owner-ipsec Wed Jan 8 11:41:17 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04332 Wed, 8 Jan 2003 11:38:29 -0500 (EST) Message-ID: <3E1C55A3.9020700@creeksidenet.com> Date: Wed, 08 Jan 2003 11:45:23 -0500 From: "jpickering%creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ike2: SAi1 in msg 3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In Ike2, section 3.1 for msg 3 the text reads: The initial payloads in message three are identical to the payloads in message 1. While this may be true for payload types, it is clearly not required for payload contents since the key may differ if Bob chooses a proposal that changes the DH group. This brings up the question of the contents of SAi1 in message 3: Should this payload contain the original proposal set or the single proposal chosen by Bob? And what should Bob do when receiving the payload? Another question regards Bob's nonce contents in message 2: if Bob places state information in message 2, eg. which suite he chose, what is the advantage of encrypting this state if Bob's cookie effectively signs the nonce? Always grateful for helpful clarification. Jeff From owner-ipsec Wed Jan 8 14:22:20 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04797 Wed, 8 Jan 2003 14:13:43 -0500 (EST) Message-Id: <200301081915.h08JFFQ18392@sydney.East.Sun.COM> Date: Wed, 8 Jan 2003 14:15:15 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: ike2: SAi1 in msg 3 To: ipsec@lists.tislabs.com, jpickering@creeksidenet.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4KpkseY+NxJMTQC1BKeIIQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ah. This part will be going away. The original document had the stateless cookie, (if Bob suspected he was under attack), as an extra optional handshake (like OAKLEY did it), so the exchange was 4 messages or else 6 if Bob rejected Alice's first message saying "try again, this time including this cookie". The reason we'd done it that way was it was much simpler since once the real exchange started we could assume Bob was keeping state, and it had other advantages (like protection from a fragmentation attack, and not having to repeat information). When the JFK and IKEv2 teams agreed to all get behind one document, we changed the exchange to the always-4 way, since that was one of the few remaining differences between JFK and IKE. But once we made that change, some people objected (it especially complicated the legacy authentication stuff which wasn't at that point in the document but will be in the next version), and at the IETF meeting Jeff Schiller made the WG actually make a decision rather than vaccillating on stuff that doesn't matter a lot (like suites vs a la carte, another change that got made for the version posted). And the WG decided it preferred 4/6 (where Bob's stateless behavior happens as a pre-handshake pair of messages). So the particular place in the spec that you're talking about is going to change in the next version (which will be posted real soon now). It will be simpler since things don't need to be repeated because Bob is not stateless after message 2. Radia From: "jpickering%creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ike2: SAi1 in msg 3 Content-Transfer-Encoding: 7bit In Ike2, section 3.1 for msg 3 the text reads: The initial payloads in message three are identical to the payloads in message 1. While this may be true for payload types, it is clearly not required for payload contents since the key may differ if Bob chooses a proposal that changes the DH group. This brings up the question of the contents of SAi1 in message 3: Should this payload contain the original proposal set or the single proposal chosen by Bob? And what should Bob do when receiving the payload? Another question regards Bob's nonce contents in message 2: if Bob places state information in message 2, eg. which suite he chose, what is the advantage of encrypting this state if Bob's cookie effectively signs the nonce? Always grateful for helpful clarification. Jeff From owner-ipsec Wed Jan 8 15:07:53 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04940 Wed, 8 Jan 2003 15:05:15 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: draft-ietf-ipsec-ikev2-04.txt To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Wed, 8 Jan 2003 15:00:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 01/08/2003 03:07:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just sent a revised draft of IKEv2 off to the I-D editor. I copied Paul Hoffman, who offered to post it on his web page faster than the I-D editor is likely to be able to post it. This new draft includes NAT traversal, revised IPcomp, changing back to 6/4 messages from always 4, acquiring internal addresses from remote networks, and negotiation of tunnel vs. transport mode. It does not include legacy authentication and proposed "revised identities", which we need to resolve quickly. I'd particularly like experts on NAT traversal to review what I said and tell me how to fix it. I tried to copy the logic from the existing I-Ds, but can't be sure I got it right. It also includes only a single option for cipher suites. There is general agreement that we need more, but I need concrete proposals on what they should be. Currently specified is: 1536-bit Diffie-Hellman; 112-bit 3DES CBC; HMAC-SHA1; ESP. People have advocated something with a smaller D-H group for performance, something with a bigger D-H group for security, 128 bit AES (is that CBC mode, counter mode, or do we need both?). And I would guess someone wants to be able to negotiate AH. Is that with an encryption-only ESP or without? ESP with extended sequence numbers is considered different from ESP without extended sequence numbers. The spec doesn't say which... I'm assuming it should say "without" since this one is intended to reflect what is currently deployed. Can someone verify that is what deployed? Is there any reason to propose an "new" suites (e.g. AES) without extended sequence number support? Would people like to make concrete proposals? I'd like to keep the number of suites in the initial draft to a minimum - we can add more later as necessary - and particularly the number of MUST support ones. But fear there is less than the minimum now. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Wed Jan 8 17:01:51 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05158 Wed, 8 Jan 2003 16:55:32 -0500 (EST) Message-Id: <5.2.0.9.2.20030108145229.00b4e508@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 08 Jan 2003 14:57:22 -0500 To: Mark Baugher From: Russ Housley Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: ipsec@lists.tislabs.com In-Reply-To: <5.1.1.5.2.20030106091406.08c381d8@mira-sjc5-6.cisco.com> References: <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark: I understand that the destination address provides this information. However, my understanding is that people who have tried to implement this stuff for very high-speed environments have found the gathering of information from various sources in the IP and ESP headers is a major portion of the overall small packet processing time. I was wondering if this was a cheap way to assist them. Russ At 09:15 AM 1/6/2003 -0800, Mark Baugher wrote: >The receiver can deduce that by the type of address, unicast or multicast >(IPv4 or v6). So there is no need to use the SPI for this purpose. From owner-ipsec Wed Jan 8 17:30:42 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05227 Wed, 8 Jan 2003 17:26:47 -0500 (EST) Message-Id: <5.1.1.5.2.20030108142715.04ada1a8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 08 Jan 2003 14:28:33 -0800 To: Russ Housley From: Mark Baugher Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: ipsec@lists.tislabs.com In-Reply-To: <5.2.0.9.2.20030108145229.00b4e508@mail.binhost.com> References: <5.1.1.5.2.20030106091406.08c381d8@mira-sjc5-6.cisco.com> <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ Since the destination address is used with the SPI as part of the multicast SA lookup in IPsecbis, I don't see any advantage to encoding the SPI with special information. Mark At 02:57 PM 1/8/2003 -0500, Russ Housley wrote: >Mark: > >I understand that the destination address provides this >information. However, my understanding is that people who have tried to >implement this stuff for very high-speed environments have found the >gathering of information from various sources in the IP and ESP headers is >a major portion of the overall small packet processing time. I was >wondering if this was a cheap way to assist them. > >Russ > >At 09:15 AM 1/6/2003 -0800, Mark Baugher wrote: >>The receiver can deduce that by the type of address, unicast or multicast >>(IPv4 or v6). So there is no need to use the SPI for this purpose. From owner-ipsec Wed Jan 8 17:47:04 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05258 Wed, 8 Jan 2003 17:44:58 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 8 Jan 2003 14:47:00 -0800 To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: draft-ietf-ipsec-ikev2-04.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:00 PM -0500 1/8/03, Charlie_Kaufman@notesdev.ibm.com wrote: >I copied Paul >Hoffman, who offered to post it on his web page faster than the I-D editor >is likely to be able to post it. Right, they're a bit backed up after the holiday. The new draft is available at . --Paul Hoffman, Director --VPN Consortium From owner-ipsec Thu Jan 9 06:54:43 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA06648 Thu, 9 Jan 2003 06:50:39 -0500 (EST) Message-ID: <3E1D6279.1030104@F-Secure.com> Date: Thu, 09 Jan 2003 13:52:25 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-04.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2003 11:52:25.0993 (UTC) FILETIME=[94122790:01C2B7D5] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com wrote: > I'd particularly like experts on NAT traversal to review what I said and > tell me how to fix it. I tried to copy the logic from the existing I-Ds, > but can't be sure I got it right. You can have some comments below, and other NAT-trav. authors will be able to fill in what's left out. > > It also includes only a single option for cipher suites. There is general > agreement that we need more, but I need concrete proposals on what they > should be. Currently specified is: > > 1536-bit Diffie-Hellman; 112-bit 3DES CBC; HMAC-SHA1; ESP. Why 2-key 3DES? Why not 3-key? In my view a sufficient minimum would be these two suites: 1536-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1; ESP. 1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1; ESP. Before getting into NAT traversal, a comment about the configuration payload. It's easy to see how initiator would send CFG_REQUESTs in message 3 and receive responses in message 4, but if you allow for CFG_SETs, their obvious location would be that responder sends CFG_SETs in message 4, and this would force the IKEv2 exchange to become longer. Otherwise the initiator is unable to send CFG_ACKs. Also, IMHO, INTERNAL_ADDRESS_EXPIRY attribute should not exist. It's a way to negotiate connection lifetime. It would be more in the spirit of IKEv2 if the GW would enforce this by forcing a connection re-key and would CFG_SET a new IP address if it needs to change (both in the same message pair). > 3.1.2 Endpoint to Endpoint Transport > > It is possible in this scenario that one of the protected endpoints ^ or both Static NAT at responder is likely relatively common. > will be behind a network address translation (NAT) node, in which > case the tunnelled packets will have to be UDP encapsulated so that ^^^^^^^^^^^^ It is unclear to me if the intention is to say that ESP packets MUST be UDP-encapsulated when a NAT is detected. Note that ESP-tunnel mode packets may work fine through some NATs without any UDP-encapsulation. It would be clearest to mandate UDP-encapsulation. > port numbers in the UDP headers can be used to identify individual > endpoints "behind" the NAT. > 3.1.3 Endpoint to Gateway Transport > In this scenario, it is possible that the protected endpoint will be > behind a NAT. In that case, the IP address as seen by the gateway > will not be the same as the IP address sent by the protected > endpoint, and packets will have to be UDP encapsulated in order to be > routed properly. ditto > 4 IKE Protocol Details and Variations > > IKE normally listens on UDP port 500, though IKE messages may also be > received on UDP port 4500 with a slightly different format. This is somewhat vague.. I would like this to say that IKEv2 implemenations MUST be able to receive messages both on port 500 and port 4500, and that they MAY initiate either to port 500 or to port 4500. If they initiate on port 500, and NAT is detected, at some point they MUST float to port 4500 and stay there, exact details of floating TBD. It's unclear how the NAT-trav. negotiation is supposed to work. In IKEv1 both endpoints send two NAT-D payloads to each other, after which they both know if there's a NAT in between or not. Then they may float to 4500. They then negotiate to UDP-encapsulation by using UDP-Encapsulated-Tunnel 3 UDP-Encapsulated-Transport 4 I wouldn't like to see a similar negotiation in IKEv2, i.e. I wouldn't like to have these two types of suites: 1536-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1; ESP. 1536-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1; ESP-UDP. A better way would be that in message 3 initiator sends the NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP notifies, and message 4 the responder also sends them. (If initiator sends them, the responder MUST also send them.) Then, if a NAT is detected UDP-encapsulation MUST be used, and any further IKEv2 message would be to port 4500 (including possible messages 5,6 of the initial neg., maybe.) Alternatively responder could send in message 4 that UDP-ENCAPSULATION-SELECTED. Unsettled issues include also: - Do we need to support transport mode for IKEv2 NAT-trav. If yes, NAT-OAs need to be specified and when they're to be sent. It may not be needed since L2TP/IPSEC MAY use tunnel mode, as I've recently learned. - NAT keepalive format and sending rules are missing. - NAT-trav. related encapsulation and decapsulation procedures need to be copied to this document. - NAT traversal related security considerations need to be copied to this document. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec Thu Jan 9 09:33:37 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07218 Thu, 9 Jan 2003 09:29:14 -0500 (EST) Message-Id: <200301091423.JAA10886@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-05.txt Date: Thu, 09 Jan 2003 09:23:55 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : More MODP Diffie-Hellman groups for IKE Author(s) : T. Kivinen, M. Kojo Filename : draft-ietf-ipsec-ike-modp-groups-05.txt Pages : 7 Date : 2003-1-8 This document defines new Modular Exponential (MODP) Groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie- Hellman groups numbered starting at 6. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel as described in RFC-2412. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-modp-groups-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-9092409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-modp-groups-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jan 9 09:33:37 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07212 Thu, 9 Jan 2003 09:28:14 -0500 (EST) Message-Id: <200301091424.JAA10906@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-nat-t-ike-05.txt Date: Thu, 09 Jan 2003 09:24:01 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Negotiation of NAT-Traversal in the IKE Author(s) : T. Kivinen et al. Filename : draft-ietf-ipsec-nat-t-ike-05.txt Pages : 12 Date : 2003-1-8 This document describes how to detect one or more network address trans- lation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-nat-t-ike-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-9092422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-t-ike-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9092422.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jan 9 10:08:14 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07326 Thu, 9 Jan 2003 10:04:40 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200301071741.h07HfNof046164@givry.rennes.enst-bretagne.fr> Subject: Re: peer address protection To: Francis Dupont Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Thu, 9 Jan 2003 09:59:24 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 01/09/2003 10:06:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis.Dupont@enst-bretagne.fr wrote: > Peer addresses (as defined in draft-ietf-ipsec-pki-profile-01.txt) are > not protected in IKE (not always in IKEv1, not at all in IKEv2 with > revised identities). This opens a security hole, not against IKE itself, > but using IKE to divert traffic (i.e., not a property we'd like for a > security protocol). > The I-D editor has just announced the new version of my I-D about > the transient pseudo-NAT attack and its application to Mobile IPv4 > (documented in the security section of the NAT traversal extension) > and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt. > I believe we should fix the issue (the security flaw) for the next > version of the IKEv2 document. Please take a look at draft-ietf-ipsec-ikev2-04.txt. As part of NAT traversal, there is a new mechanism for sending protected peer addresses. It does not, however, specify any algorithms for using that information to protect against the kinds of attacks you're worried about. I haven't read your I-D (but I will). I believe the really hard problem for us to solve is how to protect against pseudo-NAT attacks while supporting real NATs given that NATs are generally not capable of providing any cryptographic authentication. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Thu Jan 9 11:36:05 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07560 Thu, 9 Jan 2003 11:32:00 -0500 (EST) Message-ID: <3E1DA59A.90204@creeksidenet.com> Date: Thu, 09 Jan 2003 11:38:50 -0500 From: "jpickering%creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ike2 v4 couple of comments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Couple of comments and a question on V4: - Section 3.2 "All but the headers of all messages that follow are encrypted and integrity protection protected." This is true, but a bit misleading. Could it be rephrased: "For messages that follow all of the message except the header are encrypted. All of the message including the header are intergrity protected." - Section 4.6: "If it matches, the responder knows that SPIr was generated since the last change to ..." Where is SPIr coming from here, given that from the previous page, the responder does not choose an SPI? - Section 4.14 The specification of SK_d,etc computation still refers to CKY-I and CKY-R. Should this be replaced with SPIi and SPIr? Question on CREATE_CHILD_SA initiator/ responder determination. (probably due to misreading something) Section 4.2 states: "There is no ambiguity in the messages, however, because each packet contains enough information to determine which of the four messages a particular one is." When a CREATE_CHILD_SA message is received, I dont see anything in the header that would allow the recipient to determine if the message is a request or response. I also dont see anyting in the payload types that would allow a determination. So how is this done? Thanks, Jeff From owner-ipsec Thu Jan 9 15:03:56 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08078 Thu, 9 Jan 2003 14:49:57 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C723@corpmx14.us.dg.com> To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: AES cipher suites Date: Thu, 9 Jan 2003 14:51:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, > It also includes only a single option for cipher suites. There is > general agreement that we need more, but I need concrete proposals > on what they should be. Currently specified is: > > 1536-bit Diffie-Hellman; 112-bit 3DES CBC; HMAC-SHA1; ESP. > > People have advocated something with a smaller D-H group for performance, > something with a bigger D-H group for security, 128 bit AES (is that CBC > mode, counter mode, or do we need both?). On behalf of the IP Storage (ips) folks who are depending on AES counter mode, I want to make a strong request for specification of *both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR is motivated by a desire to build high-speed hardware. While AES-CTR is the "right thing" for that class of implementation, I'm reluctant to impose it on everyone who wants to use AES by not defining an AES-CBC suite. For ips's usage, AES-CTR does not need a smaller D-H group, and going to a larger one seems reasonable given the motivation to transfer large amounts of data at high speed. While I could live with suites that differed only in the D-H group, I'm not going to propose them, so here are a couple of strawmen to get started: 1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1; ESP. 2048-bit Diffie-Hellman; 128-bit AES CTR; HMAC-SHA1; ESP. The 2048 bit D-H is still weaker than 128 bit AES, but I'm reluctant to go to the 3072 bit group that would bring them closer, since concerns are already being expressed about the overhead of the 1536-bit group. That can wait until there's a realistic need to resist things like O(2^100) attacks. Q: Should AES suites with AES-CBC MAC + XCBC be defined as a backstop against the unlikely event that a disastrous attack on HMAC-SHA1 turns up? AES-CBC MAC + XCBC is the backup MAC algorithm for IP Storage ("SHOULD implement" in the ips drafts). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec Thu Jan 9 19:13:44 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08640 Thu, 9 Jan 2003 19:07:38 -0500 (EST) Date: Thu, 9 Jan 2003 16:09:35 -0800 Subject: Re: a change to the signature processing in IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: IPsec WG To: Hugo Krawczyk From: Derrell Piper In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, There's been scant discussion about this since your post. I've now read your SIGMA paper and I like the first change you proposed. I think explicitly moving the identity binding MAC into the signature definition is a very good change for all the reasons you noted. I would like to see this incorporated into the next revision of the IKEv2 draft, prior to the February submission. Regarding the second change, I'm generally in favor of what you proposed. I've always thought that the authenticator should include all of the information transmitted by a peer. I have in the past heard arguments about wanting to limit the amount of data being signed, which often results in an additional MAC step being applied before the signature. What are your thoughts here? Clearly with SLA we weren't concerned with this since we proposed a 'sign it all' signature, but I bring it up here because the generalized IKEv2 change may imply some potentially long certificate chains will now be included with the addition of messages 3 and 4. Derrell On Monday, December 30, 2002, at 04:38 PM, Hugo Krawczyk wrote: > > This message contains a request for a change to the cryptographic > specifications of ikev2's signatures. It is a relatively easy change > that > will add security to the protocol in the sense of making the protocol's > security more robust to changes (in particular new modes and variants > such > as SLA). It will also improve the protocol by making its logic easier > to > understand and analyze. > > In a previous message I described an "identity misbinding attack" on > SLA. > I said there that this attack against the authenticity of the protocol > is > NOT possible in IKEv2. Indeed, IKEv2 provides strong authentication > via > the combination of a digital signature on the DH exponentials and a MAC > on the signer's identity. This follows the "sign and mac" of the SIGMA > protocols which has been rigorously analyzed. Therefore I have no > complaints about the security of IKEv2 as specified now (draft v3). > > On the other hand, I do have a complaint (that I expressed several > times in > the past) regarding the "robustness" of the IKEv2 design. > The problem is that the essential key-identity binding through a MAC > is achieved in IKEv2 in an indirect way that is not sufficiently > explicit > and thus it is prone to misunderstandings and mistakes in modified > versions > of the protocol. I have been saying (since Nov 2001) that sooner or > later > people will propose variants or changes that will fail to be secure > due to > this design "obscurity". And indeed it happened sooner than later with > the > design of SLA. > > The problem is that IKEv2 authentication (and specifically key-identity > binding) depends on two elements: > > (1) the MAC that is applied through the SK{} processing (which most > people > understand as needed for identity protection, or encryption integrity, > rather than for the core authentication of the protocol) > (2) the transmission of the initiator's identity in message 3 and of > the > responder's in message 4. > > If you remove any of these elements, or move the identities to another > message, the protocol becomes insecure. > SLA is an example in which the authentication in message 4 (the > responder's) > is moved to message 2 but SK{} (and its MAC) is not carried to that > message. > And it is not really the SLA designers fault: the SK{} processing > includes > encryption while message 2 of SLA cannot be encrypted (since it > contains KEr > which needs to be sent in the clear). Moreover, in SLA you do not care > about protecting the identity of the responder (the server) and thus > the > SK{} processing is not only problematic but actually unnecessary. > > Another case in which the protocol's security would break down is in > the > following (not completely) hypotetical scenario. Assume that in some > setting > you do not care about identity protection of the initiator. In this > case it > makes a lot of sense to transmit this identity already in the first > message > so that the responder can make policy decisions early on based on this > identity (this, btw, was one of the properties people liked/wanted in > the > aggressive modes of IKEv1). In this case, the authentication by the > initiator still occurs in message 3, but the identity is not included > there > (since it was sent in message 1). However, while this change (or > option) may > seem very reasonable the resultant protocol would fail to "identity > misbinding" attacks (i.e. the basic "mutual belief" property is lost). > Note that while the effect of such an attack is debatable in the > specific > case of SLA, it is a major vulnerabiity in a general peer-to-peer key > exchange protocol as IKEv2. > > As a fix to SLA and a general fix to this lack of robustness of IKEv2 I > propose the following change to the signature computation (the AUTH > payload) > in IKEv2. > > Currently IKEv2 defines that the signature is to be applied to the > concatenation of the peer's nonce and the contents of certain messages > in > the protocol. The change I am asking for is to add to the signed > information > also a value computed as MAC(SK_a,ID) where SK_a is is the MAC key > already > computed by the protocol, and ID is the identity of the signer. > More specifically, in the initiator's signature (in message 3) this > additional value will be MAC(SK_ai,IDi), while in the responder's > signature > it will be MAC(SK_ar,IDr). > > The computation of the keys SK_ai/SK_ar requires no additional > processing > or change since they are already derived in IKEv2 for use in the MAC > in SK{}. > Also note that the value MAC(SK_a,ID) added to the signature > computation > will NOT be transmitted but just re-computed by the receiving end when > verifying the signature, so it requires no new payload nor it > increases the > length of messages. > > Thus, while the proposed change adds negligible complexity relative to > the > whole complexity of IKEv2 it provides for a significantly more robust > and > easier to analyze design. In particular: > > (1) the signatures can be moved to any message where they make sense > (e.g. > to message 2 in SLA) without loosing the protocols security > (2) the identities can be transmitted in any message (e.g. the > initiator's > identity in message 1) without impacting the authentication of the > protocol > (3) the MAC used in SK{} will be confined to two functionalities: > (a) protecting the identity encryption against active attacks > (b) protecting the authenticity of phase-2 information piggybacked > to msgs 3 and 4. > > Then I would also suggest a second change that will reduce the need for > SK{} to functionality (a) (identity protection) only. The idea is > to expand the signature's scope to the WHOLE information sent by each > signer. > That is, I's signature will be applied to the full messages 1 and 3, > while R's > signature to the full messages 2 and 4. In this case the AUTH payload > can be > moved to the end of messages 3 and 4 (before the SK{} processing). > Relative to what is signed today, this change has the cost that each > signature needs to be applied to two messages (instead of one message > only). > However making sure that you sign ALL the information sent by each > party > makes a better design. And, not less important, we make the MAC under > SK > only needed for identity protection. In particular, the resultant > protocol > can be proven secure even if the whole SK{} processing is omitted in > case > that identity protection is not required. I consider this as a > significant > robustness AND analytical advantage. > > In any case, while I'd prefer to see both changes accepted, I still > consider > the firsr one (adding MAC(SK_a,ID) to the signatures) as more > significant > and needed independently of the second change (i.e. expanding the > scope of > signatures). > > If anyone opposes these changes (especially the first one) please > explain > the rationale of this objection in a message to this list. I would > suggest > that whoever wants to raise objections against these changes first > reads the > SIGMA paper which addresses in much more detail the motivation and > rationale > behind these changes (in particular, see section 5.4 of the paper). > The url (again) is http://www.ee.technion.ac.il/~hugo/sigma.ps [.pdf] > > Happy new year > > Hugo > From owner-ipsec Fri Jan 10 10:29:44 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10134 Fri, 10 Jan 2003 10:22:31 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Van Aken Dirk" , Subject: RE: Proposed Configuration payload for IKEv2 Date: Fri, 10 Jan 2003 10:24:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E5583FA2B@TMM_EDGMSMSG01> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've never implemented draft-ietf-ipsec-dhcp-13.txt but if it works well it could be used for address assignment. However there has been opposition to the short-lived DHCP-specific tunnel and the group that met after the November IETF meeting wanted something that was well understood by implementers, and was deployed. CP (Configuration Payload, AKA modecfg) was a good fit for that. I don't agree that "only a single mechanism is required for host configuration" is true for ipsec-dhcp. First modecfg/CP may, and often does, use DHCP as a back end for address assignment then adds ipsec VPN user specific attributes to the CP. Second, from what I understand of ipsec-dhcp, it would need to do the same thing but tack VPN user specific options on to a DHCPOFFER. So an administrator would configure their DHCP server then the IRAS for VPN user specific stuff for either protocol. Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Van Aken Dirk > Sent: Monday, December 23, 2002 10:10 AM > To: 'ipsec@lists.tislabs.com' > Subject: Re: Proposed Configuration payload for IKEv2 > > > Hello Gents, > > > Is not intended for IP configuration of > remote hosts ? > IMHO, decouples IPSec and IRAC > config in the > sense that only a short lived tunnel is required for DHCP > messages hence all > other complexity is in DHCP. > > What is gained from decoupling IKE from host configuration is that only a > single mechanism is required for host configuration. In that way a system > administrator must not learn new mechanisms/methods to configure hosts. To > her/him it is the same whether configuring a central office or a remote > IPSec protected host. > > Best regards - Dirk > > > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: donderdag 19 december 2002 20:39 > To: Hugo Krawczyk > Cc: ipsec@lists.tislabs.com; ietf-mode-cfg@vpnc.org > Subject: RE: Proposed Configuration payload for IKEv2 > > > > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > > Sent: Thursday, December 19, 2002 12:30 PM > > > > On Wed, 18 Dec 2002, Darren Dukes wrote: > > > > > Attached is a draft which is intended to be merged with the > IKEv2 draft. > > > There is no intent for this draft to continue on its own. It > contains a > > > payload and description of how an IPsec Remote Access Client > > (IRAC) may use > > > that payload to get configuration information (internal IP, > > subnets, etc.) > > > from an IPsec Remote Access Server (IRAS). > > > > > > The payload in this draft is very similar to the IKEv1 modecfg > > draft, this > > > draft states the differences between the two. > > > > > > Why do this? (copied from vpnc.org) "At the IETF meeting in > Atlanta in > > > November, 2002, the IPsec WG decided to add remote access capabilities > > > (legacy authentication and remote client configuration) to > IKEv2. At an > > > > If I understand it correctly, your draft only addresses the > remote client > > configuration issue, not the legacy authentication. How do you envision > > adding the legacy authentication support and still making use of the > > configuration mechanism described in the draft? > > After taking a quick look at Paul's draft he just sent out, I > think CP will > go in the LAS exchange message 3 and message N the same way it's specified > for message 3 and 4 now. > > > Note that you add the > > configuration mechanism to messages 3 and 4 of ikev2 and assume > that it is > > protected under the IKE-SA, however if you need to perform legacy > > authentication then you will not have an established IKE-SA in > messages 3 > > and 4. > > > > Also, it is worth noting that even if client and server use regular IKE > > authentication (signatures or preshared key) then in message 3 > the server > > (responder) is not yet authenticated by the client so the information > > transmitted from IRAC to IRAS in this message is NOT protected. This > > should be documented and explicitly said that this message should not > > contain any confidential information. > > You are right about message 3, and the IRAS not being > authenticated to IRAC. > I think text about the lack of authentication should suffice with strong > suggestions of what configuration attributes should go into the > CFG_REQUEST. > > > > > These problems are solved if the configuration information exchange > > happens in phase 2 (at the expense, of course, of more round trips). > > I had originally thought of this as just a post 'phase-1' > exchange but since > the first Child-SA is always created in message 3 and 4 we will need the > configuration data before or during its creation. Without it the IRAS has > no way of knowing how to narrow TSi in message 4. > > Darren > > > > Hugo > > > > > informal design team meeting after the WG meeting, the VPN > > vendors attending > > > decided that the best options to propose to the WG were to add > > capabilities > > > similar to XAUTH and MODE-CFG." > > > > > > Please send all comments regarding this draft to > ipsec@lists.tislabs.com > > > > > > Thanks, > > > Darren > > > > > From owner-ipsec Fri Jan 10 11:43:36 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10234 Fri, 10 Jan 2003 11:40:16 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090ECE@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , ipsec@lists.tislabs.com Cc: "'baiju.v.patel@intel.com'" , "'bernarda@microsoft.com'" , "'skelly@redcreek.com'" , "'vipul.gupta@eng.sun.com'" , Gadeyne Walter , Dedecker Hans Subject: RE: Proposed Configuration payload for IKEv2 Date: Fri, 10 Jan 2003 17:42:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren, Thank you for you reply. See my comments below. -----Original Message----- From: Darren Dukes [mailto:ddukes@cisco.com] Sent: vrijdag 10 januari 2003 16:24 To: Van Aken Dirk; ipsec@lists.tislabs.com Subject: RE: Proposed Configuration payload for IKEv2 I've never implemented draft-ietf-ipsec-dhcp-13.txt but if it works well it could be used for address assignment. However there has been opposition to the short-lived DHCP-specific tunnel and the group that met after the November IETF meeting wanted something that was well understood by implementers, and was deployed. CP (Configuration Payload, AKA modecfg) was a good fit for that. I don't agree that "only a single mechanism is required for host configuration" is true for ipsec-dhcp. >>> I don't know where I picked up this statement but it is in line with what is happening with PPP-IPCP. The same problem is encountered here. If a PPP link comes up, PPP-IPCP negotiates an IP address and a Primary and Secondary DNS server. However if one looks at DHCP there are lots of other parameters that can be automatically configured but you won't find these in IPCP. Nevertheless IPCP is not further extended because there seems to be objections from working groups. I guess the IETF wants only a single protocol to configure the IP layer being DHCP (I don't know whether this is really the truth but this is what I heard ..) As an example CISCO has a proprietary extension to hand out a subnet via IPCP (see ). I guess for the aforementioned reason, this draft never became an RFC even not an informational one. I have the same problem with IKE-mode config; the draft is no longer available via the IETF and I guess IKE mode config will suffer from option limitation too. e.g. Have a look at the options that are currently available via DHCP and note that these are constantly expanded( ). >>> First modecfg/CP may, and often does, use DHCP as a back end for address assignment then adds ipsec VPN user specific attributes to the CP. Second, from what I understand of ipsec-dhcp, it would need to do the same thing but tack VPN user specific options on to a DHCPOFFER. So an administrator would configure their DHCP server then the IRAS for VPN user specific stuff for either protocol. >>> Yes but is ipsec-dhcp not more "natural" in the sense that DHCP requests arrive in the IRAS which are then forwarded via a DHCP relay to a DHCP server. The latter talks back to the DHCP relay in the IRAS. Note that DHCP relays adding options to DHCP packets is quite a standardized technique. In addition, in other types of VPN such as BGP-MPLS there is quite some activity in trying to come up with a scalable DHCP based IP parameter distribution method (see RFC's and drafts below). Maybe IPSec can apply similar techniques ? 3046 DHCP Relay Agent Information Option 2685 Virtual Private Networks Identifier DHCP VPN Information option VPN Identifier sub-option for the Relay Agent Information Option Link Selection sub-option for the Relay Agent Information Option for DHCPv4 BTW, I analysed a commercially available IPSec remote access solution (VPN Client and VPN Gateway) and came to following conclusion: - towards the external world a VPN client loaded on a Windows machine is performing IKE-mode config - internally though the client drives the Microsoft DHCP client to dynamically configure the IP interface and the routing table with IP parameters - on the IRAS side these IKE-mode config messages are translated back into DHCP messages, passing over a DHCP relay and forwarded towards a stand-alone DHCP server - and of course in the other direction the same process is executed as well. Wouldn't it be simpler to use DHCP all the way i.e. the construct DHCPClient-Relay-Server ? Best regards - Dirk >>> Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Van Aken Dirk > Sent: Monday, December 23, 2002 10:10 AM > To: 'ipsec@lists.tislabs.com' > Subject: Re: Proposed Configuration payload for IKEv2 > > > Hello Gents, > > > Is not intended for IP configuration of > remote hosts ? > IMHO, decouples IPSec and IRAC > config in the > sense that only a short lived tunnel is required for DHCP > messages hence all > other complexity is in DHCP. > > What is gained from decoupling IKE from host configuration is that only a > single mechanism is required for host configuration. In that way a system > administrator must not learn new mechanisms/methods to configure hosts. To > her/him it is the same whether configuring a central office or a remote > IPSec protected host. > > Best regards - Dirk > > > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: donderdag 19 december 2002 20:39 > To: Hugo Krawczyk > Cc: ipsec@lists.tislabs.com; ietf-mode-cfg@vpnc.org > Subject: RE: Proposed Configuration payload for IKEv2 > > > > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > > Sent: Thursday, December 19, 2002 12:30 PM > > > > On Wed, 18 Dec 2002, Darren Dukes wrote: > > > > > Attached is a draft which is intended to be merged with the > IKEv2 draft. > > > There is no intent for this draft to continue on its own. It > contains a > > > payload and description of how an IPsec Remote Access Client > > (IRAC) may use > > > that payload to get configuration information (internal IP, > > subnets, etc.) > > > from an IPsec Remote Access Server (IRAS). > > > > > > The payload in this draft is very similar to the IKEv1 modecfg > > draft, this > > > draft states the differences between the two. > > > > > > Why do this? (copied from vpnc.org) "At the IETF meeting in > Atlanta in > > > November, 2002, the IPsec WG decided to add remote access capabilities > > > (legacy authentication and remote client configuration) to > IKEv2. At an > > > > If I understand it correctly, your draft only addresses the > remote client > > configuration issue, not the legacy authentication. How do you envision > > adding the legacy authentication support and still making use of the > > configuration mechanism described in the draft? From owner-ipsec Fri Jan 10 14:54:35 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10727 Fri, 10 Jan 2003 14:49:10 -0500 (EST) Message-Id: <200301101950.h0AJocGg022596@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-04.txt In-reply-to: Your message of "Thu, 09 Jan 2003 13:52:25 +0200." <3E1D6279.1030104@F-Secure.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jan 2003 11:50:38 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ari" == Ari Huttunen writes: Ari> Also, IMHO, INTERNAL_ADDRESS_EXPIRY attribute should not exist. It's Ari> a way to negotiate connection lifetime. It would be more in the spirit Ari> of IKEv2 if the GW would enforce this by forcing a connection re-key Ari> and would CFG_SET a new IP address if it needs to change (both in the Ari> same message pair). Strongly agree. Get rid of lifetime info. Just rekey when you feel you should. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPh8kDIqHRg3pndX9AQEDvgQAsMwSWbrTWrM4+A1EI7myhEhGYnlpkt5W jqpaqd2gBYwI2Zx5N3OWNQGe7MyJIqsCto/t4MlusAYYy1uHzaql31lNjcVsqPm9 LxQWmhwMqCTLGL3Is1IgjWPz6aEV+/bUrM3l8lEtd6HfVtpGUW37I9vSqNXCYlrB AYxq6W9U+gg= =NCXA -----END PGP SIGNATURE----- From owner-ipsec Fri Jan 10 15:02:46 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10747 Fri, 10 Jan 2003 14:59:16 -0500 (EST) Message-Id: <200301102001.h0AK1LgQ022891@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: AES cipher suites In-reply-to: Your message of "Thu, 09 Jan 2003 14:51:34 EST." <277DD60FB639D511AC0400B0D068B71E0564C723@corpmx14.us.dg.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jan 2003 12:01:20 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Black" == Black David writes: Black> On behalf of the IP Storage (ips) folks who are depending on AES Black> counter mode, I want to make a strong request for specification of Black> *both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR Black> is motivated by a desire to build high-speed hardware. While AES-CTR Specify one, or make it a MUST. I think we are talking MUST here. I also got the impression that this was for phase 1. Maybe I misread. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPh8mj4qHRg3pndX9AQFdIQP8CGOsi6EGplrsEPkP/d66hwTJ/2ke8trQ Cn1fF7EJEBQDKjN2YpBV+A0esEkW+SAim4zsDEGUJhFquERwmrtWOR+UenM6GFfW b1ng+kuQDj/+pujaNaZshNibWrixFvtF9U1ML3k1rVeZi4kziTHDZor5Tvf+BR0s Aj9I+tpoay4= =9X7S -----END PGP SIGNATURE----- From owner-ipsec Fri Jan 10 15:09:03 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10772 Fri, 10 Jan 2003 15:04:23 -0500 (EST) Message-Id: <200301102006.h0AK5xVw023019@sandelman.ottawa.on.ca> To: ddukes@cisco.com cc: "Van Aken Dirk" , ipsec@lists.tislabs.com Subject: Re: Proposed Configuration payload for IKEv2 In-reply-to: Your message of "Fri, 10 Jan 2003 10:24:13 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jan 2003 12:05:59 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Darren" == Darren Dukes writes: Darren> I've never implemented draft-ietf-ipsec-dhcp-13.txt but if it works well it Darren> could be used for address assignment. However there has been opposition to Darren> the short-lived DHCP-specific tunnel and the group that met after the Darren> November IETF meeting wanted something that was well understood by Darren> implementers, and was deployed. CP (Configuration Payload, AKA modecfg) was Darren> a good fit for that. I still think that pushing DHCP payloads over IKE phase 1, and having the gateway IKE either process them directly, or encapsulate them appropriately and punt them to a DHCP server is better than these short lived tunnels with very weird selectors. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPh8npoqHRg3pndX9AQGbXAQA03kRckpqEtskpDR6wohPcvTRCQeXD/h1 JHpTNtU58+xhKkLIokoqrylceAZAl/MaafMRbqGRg3tb4qXl7gALJkhv6RMDNiR2 VGt0ty9zVWWSP0dT3fa+VARLh/vJJylJrfpDHp7Ii/AyIWge6pYx/NSzGLLFSlSb sD/dioXk7Pk= =m0b5 -----END PGP SIGNATURE----- From owner-ipsec Fri Jan 10 16:14:34 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11047 Fri, 10 Jan 2003 16:11:23 -0500 (EST) Message-Id: <200301102112.h0ALCUjt009965@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-04.txt In-Reply-To: Your message of "Fri, 10 Jan 2003 11:50:38 PST." <200301101950.h0AJocGg022596@sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Fri, 10 Jan 2003 16:12:30 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Strongly agree. Get rid of lifetime info. Just rekey when you feel > you should. strongly disagree. absent an expiration time, it's difficult to know when it's safe to nuke inbound security associations from an unreachable and unresponsive peer. From owner-ipsec Fri Jan 10 17:08:08 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11176 Fri, 10 Jan 2003 17:06:01 -0500 (EST) Message-Id: <200301102207.h0AM7dhm026087@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-04.txt In-reply-to: Your message of "Fri, 10 Jan 2003 16:12:30 EST." <200301102112.h0ALCUjt009965@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jan 2003 14:07:39 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: >> Strongly agree. Get rid of lifetime info. Just rekey when you feel >> you should. Bill> strongly disagree. Bill> absent an expiration time, it's difficult to know when it's safe to Bill> nuke inbound security associations from an unreachable and Bill> unresponsive peer. Well, if they are unreachable, and unresponsive (i.e. they refuse to rekey), then, when you have made the decision that they are unresponsive, you should nuke them. The only problem with doing it too soon is that we have no recovery mechanism, such as a birth certificate. This is particularly easy if you can set idle timers on your incoming SAs. Bill, I have been working on a birth certificate mechanism, such as you described some time ago. I got about halfway done last summer, and it has risen to close to the top of my stack again. Do you think that there is time to get a standard notify for boot count into IKEv2? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPh9EKoqHRg3pndX9AQHZvAQAiGjkayC++zr69KrgmIE/winbRbX/A5Ap yd9IpWA4xsdl9lkbE1uXcZKT48MzetVGrOGYLiXVAyqTi8tMCXWRLYE6/raoCqso EmB1JJrjuO9Qlp9ENsKRebESRlNyj2QSG/ac1RZW/nMz5ixnQW7Am+vWVODBpesG mFMtbGtC7H0= =Ds58 -----END PGP SIGNATURE----- From owner-ipsec Fri Jan 10 17:25:34 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11233 Fri, 10 Jan 2003 17:22:19 -0500 (EST) Message-ID: <3E1F473A.5FD8D590@bstormnetworks.com> Date: Fri, 10 Jan 2003 14:20:42 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ddukes@cisco.com CC: Van Aken Dirk , ipsec@lists.tislabs.com Subject: Re: Proposed Configuration payload for IKEv2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I know of several fielded implementations of the ipsec-dhcp draft, and my understanding is that the group which met in Atlanta consisted mostly (if not entirely) of mode-cfg/xauth supporters, so the outcome doesn't seem surprising (or valid as a point of citation). The ipsec-dhcp doc does a nice job of explaining the drawbacks of cfgmode vs tunneled dhcp, and it provides a modular way to implement dynamic host configuration over ipsec tunnels which requires no modifications to ipsec. I have personal experience with implementation, and it is certainly no more difficult than modecfg, and it is far more powerful. Darren Dukes wrote: > > I've never implemented draft-ietf-ipsec-dhcp-13.txt but if it works well it > could be used for address assignment. However there has been opposition to > the short-lived DHCP-specific tunnel and the group that met after the > November IETF meeting wanted something that was well understood by > implementers, and was deployed. CP (Configuration Payload, AKA modecfg) was > a good fit for that. > > I don't agree that "only a single mechanism is required for host > configuration" is true for ipsec-dhcp. First modecfg/CP may, and often > does, use DHCP as a back end for address assignment then adds ipsec VPN user > specific attributes to the CP. Second, from what I understand of > ipsec-dhcp, it would need to do the same thing but tack VPN user specific > options on to a DHCPOFFER. So an administrator would configure their DHCP > server then the IRAS for VPN user specific stuff for either protocol. > > Darren > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Van Aken Dirk > > Sent: Monday, December 23, 2002 10:10 AM > > To: 'ipsec@lists.tislabs.com' > > Subject: Re: Proposed Configuration payload for IKEv2 > > > > > > Hello Gents, > > > > > > Is not intended for IP configuration of > > remote hosts ? > > IMHO, decouples IPSec and IRAC > > config in the > > sense that only a short lived tunnel is required for DHCP > > messages hence all > > other complexity is in DHCP. > > > > What is gained from decoupling IKE from host configuration is that only a > > single mechanism is required for host configuration. In that way a system > > administrator must not learn new mechanisms/methods to configure hosts. To > > her/him it is the same whether configuring a central office or a remote > > IPSec protected host. > > > > Best regards - Dirk > > > > > > -----Original Message----- > > From: Darren Dukes [mailto:ddukes@cisco.com] > > Sent: donderdag 19 december 2002 20:39 > > To: Hugo Krawczyk > > Cc: ipsec@lists.tislabs.com; ietf-mode-cfg@vpnc.org > > Subject: RE: Proposed Configuration payload for IKEv2 > > > > > > > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > > > Sent: Thursday, December 19, 2002 12:30 PM > > > > > > On Wed, 18 Dec 2002, Darren Dukes wrote: > > > > > > > Attached is a draft which is intended to be merged with the > > IKEv2 draft. > > > > There is no intent for this draft to continue on its own. It > > contains a > > > > payload and description of how an IPsec Remote Access Client > > > (IRAC) may use > > > > that payload to get configuration information (internal IP, > > > subnets, etc.) > > > > from an IPsec Remote Access Server (IRAS). > > > > > > > > The payload in this draft is very similar to the IKEv1 modecfg > > > draft, this > > > > draft states the differences between the two. > > > > > > > > Why do this? (copied from vpnc.org) "At the IETF meeting in > > Atlanta in > > > > November, 2002, the IPsec WG decided to add remote access capabilities > > > > (legacy authentication and remote client configuration) to > > IKEv2. At an > > > > > > If I understand it correctly, your draft only addresses the > > remote client > > > configuration issue, not the legacy authentication. How do you envision > > > adding the legacy authentication support and still making use of the > > > configuration mechanism described in the draft? > > > > After taking a quick look at Paul's draft he just sent out, I > > think CP will > > go in the LAS exchange message 3 and message N the same way it's specified > > for message 3 and 4 now. > > > > > Note that you add the > > > configuration mechanism to messages 3 and 4 of ikev2 and assume > > that it is > > > protected under the IKE-SA, however if you need to perform legacy > > > authentication then you will not have an established IKE-SA in > > messages 3 > > > and 4. > > > > > > Also, it is worth noting that even if client and server use regular IKE > > > authentication (signatures or preshared key) then in message 3 > > the server > > > (responder) is not yet authenticated by the client so the information > > > transmitted from IRAC to IRAS in this message is NOT protected. This > > > should be documented and explicitly said that this message should not > > > contain any confidential information. > > > > You are right about message 3, and the IRAS not being > > authenticated to IRAC. > > I think text about the lack of authentication should suffice with strong > > suggestions of what configuration attributes should go into the > > CFG_REQUEST. > > > > > > > > These problems are solved if the configuration information exchange > > > happens in phase 2 (at the expense, of course, of more round trips). > > > > I had originally thought of this as just a post 'phase-1' > > exchange but since > > the first Child-SA is always created in message 3 and 4 we will need the > > configuration data before or during its creation. Without it the IRAS has > > no way of knowing how to narrow TSi in message 4. > > > > Darren > > > > > > Hugo > > > > > > > informal design team meeting after the WG meeting, the VPN > > > vendors attending > > > > decided that the best options to propose to the WG were to add > > > capabilities > > > > similar to XAUTH and MODE-CFG." > > > > > > > > Please send all comments regarding this draft to > > ipsec@lists.tislabs.com > > > > > > > > Thanks, > > > > Darren > > > > > > > From owner-ipsec Sat Jan 11 16:02:29 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13172 Sat, 11 Jan 2003 15:52:42 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: AES cipher suites Date: 11 Jan 2003 20:31:05 GMT Organization: University of California, Berkeley Lines: 13 Distribution: isaac Message-ID: References: <277DD60FB639D511AC0400B0D068B71E0564C723@corpmx14.us.dg.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1042317065 15674 128.32.153.211 (11 Jan 2003 20:31:05 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 11 Jan 2003 20:31:05 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Black wrote: >On behalf of the IP Storage (ips) folks who are depending on AES >counter mode, I want to make a strong request for specification of >*both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR >is motivated by a desire to build high-speed hardware. While AES-CTR >is the "right thing" for that class of implementation, I'm reluctant >to impose it on everyone who wants to use AES by not defining an >AES-CBC suite. Why do you need both? What problem does AES-CBC solve that AES-CTR doesn't? It looks to me like AES-CTR is likely to be good enough for everything that AES-CBC is good enough for -- but then, I'm not familiar with ips. What am I missing? From owner-ipsec Sat Jan 11 17:37:15 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13271 Sat, 11 Jan 2003 17:32:18 -0500 (EST) Message-Id: <3.0.5.32.20030112143542.0082ad00@pop.mindspring.com> X-Sender: tardo@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 12 Jan 2003 14:35:42 -0800 To: daw@mozart.cs.berkeley.edu (David Wagner), ipsec@lists.tislabs.com From: "Joseph J. Tardo" Subject: Re: AES cipher suites In-Reply-To: References: <277DD60FB639D511AC0400B0D068B71E0564C723@corpmx14.us.dg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, wouldn't ips want an AES-CBC-XMAC with AES-CTR suite, as called out in draft-ietf-ips-security-18.txt? At 08:31 PM 1/11/03 GMT, David Wagner wrote: >David Black wrote: >>On behalf of the IP Storage (ips) folks who are depending on AES >>counter mode, I want to make a strong request for specification of >>*both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR >>is motivated by a desire to build high-speed hardware. While AES-CTR >>is the "right thing" for that class of implementation, I'm reluctant >>to impose it on everyone who wants to use AES by not defining an >>AES-CBC suite. > >Why do you need both? What problem does AES-CBC solve that AES-CTR >doesn't? It looks to me like AES-CTR is likely to be good enough for >everything that AES-CBC is good enough for -- but then, I'm not familiar >with ips. What am I missing? > From owner-ipsec Sat Jan 11 23:28:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13737 Sat, 11 Jan 2003 23:23:21 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3E1D6279.1030104@F-Secure.com> Subject: Re: draft-ietf-ipsec-ikev2-04.txt To: Ari Huttunen Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 11 Jan 2003 22:28:50 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 01/11/2003 11:25:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Why 2-key 3DES? Why not 3-key? In my view a sufficient minimum would be these > two suites: > 1536-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1; ESP. > 1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1; ESP. Only because it was my understanding that 2 key 3DES was what was most commonly deployed, and it seemed reasonable for one suite to be the one that is actually out there. What is actually out there? > For ips's usage, AES-CTR does not need a smaller D-H > group, and going to a larger one seems reasonable given the > motivation to transfer large amounts of data at high speed. While > I could live with suites that differed only in the D-H group, I'm > not going to propose them, so here are a couple of strawmen to get > started: > > 1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1; ESP. > 2048-bit Diffie-Hellman; 128-bit AES CTR; HMAC-SHA1; ESP. There are separate suites for IKE SAs and for ESP SAs. The ESP SAs are the ones likely to be performance sensitive. What if the ESP SAs were: 168-bit 3DES CBC; HMAC-SHA1; ESP w/o extended sequence numbers (for backwards compatibility) 128-bit AES CBC; HMAC-SHA1; ESP w/extended sequence numbers 128-bit AES CTR; HMAC-SHA1; ESP w/extended sequence numbers and the IKE suites were: 1024-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1 (for best performance and backwards compatibility) 1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1 2048-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1 Is there any reason to have AES CTR for IKE? Performance is not an issue, but I can imagine people doing CTR mode for ESP not wanting to have to also implement CBC just for IKE. Is there any reason to have AES without extended sequence numbers? Is there any reason to have 3DES with extended sequence numbers? The logic is that AES and extended sequence numbers are the new way to do things. The only reason anyone would not have extended sequence numbers is for backwards compatibility. Am I wrong? Is there any reason to have AES CBC at all? Is it better than AES CTR by some metric that people care about? Or could we just assume that if you're using AES you'll either want to or be willing to use CTR mode? (Don't shoot the questioner... I'm just being naive. I don't care what suites we mandate... just that we settle on something). --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Sat Jan 11 23:28:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13738 Sat, 11 Jan 2003 23:23:21 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200301071741.h07HfNof046164@givry.rennes.enst-bretagne.fr> Subject: Re: peer address protection and NAT Traversal To: Francis Dupont Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 11 Jan 2003 18:22:10 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 01/11/2003 11:25:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've now read and understood draft-dupont-transient-pseudonat-01.txt. I'd like to propose language in the IKEv2 and NAT traversal documents to address it, but I'm eager to hear from the NAT Traversal folk whether the fix will break too many real cases. Francis Dupont wrote: > The I-D editor has just announced the new version of my I-D about > the transient pseudo-NAT attack and its application to Mobile IPv4 > (documented in the security section of the NAT traversal extension) > and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt. > I believe we should fix the issue (the security flaw) for the next > version of the IKEv2 document. While the threat comes up in many contexts, the easiest serious form of it involves UDP encapsulation of IKE and ESP packets. If one endpoint of an IPsec tunnel is behind a NAT, packets it sends will be encapsulated in UDP and sent with source and destination ports both equal to 3500. That endpoint must be the one that initiates the IKE connection. The receiving endpoint will see a different source IP address and UDP port (because they were mapped by the NAT) and will respond to the address and port it sees. The NAT will map these back to the original endpoint's address and port 3500. So far, so good. Mapped UDP port assignments in NATs can be timed out prematurely. When this happens, packets coming from the Internet to the NAT will be dropped (or misrouted) and packets coming from the NAT-protected node to the Internet will be sent with a different source UDP port and possibly different source IP address. For most protocols, that will cause the connection to fail. Sometimes the connection will be dynamically reformed if there is retry at the application layer. A NAT-aware protocol can try to do better. Since there is an SPI in the header of every ESP and IKE packet that uniquely identifies the SA, an endpoint can accept packets ignoring the source IP address and port without confusion. It can send responses to the address and port from which it received the request fairly safely. But for the SA to survive the remapping of UDP ports by the NAT, it must also start sending its own requests and encapsulated ESP packets to the new UDP port and IP address. This is where the opportunity for mischief occurs. If an attacker on the path between the two endpoints pretends to be a NAT and changes the source address and UDP port of a single packet, what should the recipient do? If he starts sending to the new address, it makes the IPsec SA very fragile and potentially causes a packet flooding attack against the node whose IP address was forged in the header. If he doesn't, all the packets sent will be lost in the case where a genuine NAT remapped addresses. Since NATs are not generally capable of cryptographic authentication, there is no reliable way to distinguish these cases. I could imagine lots of clever ways to try to deal with this... all with clever countermeasures that allow an attacker to exploit them. So what I'd like to propose is that IPsec SAs *not* try to survive mid-connection NAT renumberings. That an IP address and UDP port be associated with an SA during initialization and that all subsequent traffic be sent to that address and port until it is timed out and closed. Requests *from* an unexpected IP address/port should be ignored. (Perhaps there is a way to respond with an alert to make the timeout process converge faster, but I couldn't think of one that couldn't be exploited by an attacker). There is a residual attack here where the attacker gets in the middle of the initial SA setup and tricks the endpoints into sending to the wrong address by forwarding all the packets during setup. (If it continues to forward packets throughout the SA, everything works... essentially it *is* a NAT. But if it stops it can temporarily get traffic misdirected). This seems like a difficult attack more easily mounted against other UDP based protocols. It exists for non-cryptographic protocols even in the absence of NATs. And preventing it seems to require detecting NATs and refusing to operate through them. Perhaps there should explicitly be a configuration parameter in IPsec implementations allowing this. I'm out of my depth here. What do existing implementations do? Do they not support mid-connection renumbering or are they subject to the DOS attack? Is there a known better fix? --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Sat Jan 11 23:28:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13739 Sat, 11 Jan 2003 23:23:22 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090ECE@TMM_EDGMSMSG01> Subject: RE: Proposed Configuration payload for IKEv2 To: Van Aken Dirk Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 11 Jan 2003 22:01:47 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 01/11/2003 11:25:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Wouldn't it be simpler to use DHCP all the way i.e. the construct >DHCPClient-Relay-Server ? I initially had the same thought, but was talked out of it. Let me repeat the logic that convinced me, and see if it does anything for you. The bottom line is that while I believe this would be possible, I don't believe it simpler. The problem is that DHCP runs over IP only though heavy kludgery. Since you don't initially know your IP address, you must send initial DHCP messages from IP address zero and get responses either via your hardware address or by multicast. If we wanted to tunnel these messages over IPsec protected ESP, we would have to first set up an ESP SA tunnelling packets from address zero to a broadcast address, and then after the IP address becomes known set up a new ESP SA with the new address. I would expect some substantial confusion with the packet forwarding tables on the server, and a lot of special casing. Alternatively, we could run DHCP over the IKE SA instead of over a special ESP SA set up for that purpose, but this requires even more special casing for what the endnode fills in for hardware address, etc. I would think a not unlikely scenario would be where a user has a permanent internal IP address and the IPsec gateway wants to assign that internal IP address based on the user's identity (independent of what address the user is tunnelling from). This would require more special case kludgery if we wanted the negotiation to look like DHCP but use other fields from the IKE messages. DHCP is capable of carrying lots of kinds of information. Except for dynamic IP address, all of it is obtainable after you have your IP address - and in fact it works more smoothly and efficiently once that happens. So my second thought was that IKE be capable of negotiating an internal IP address after which DHCP tunnelled over ESP could be used for obtaining any other information desired. This would work, and it's my understanding that an endnode could use this mechanism to get DHCP-based information not available through IKE. Throwing a few more commonly used parameters into IKE - like the IP address of a DNS server - is clearly unnecessary but will simplify the common case of implementations that only want that additional information. I could be convinced either way on that one. I had another objection to the design I added to ikev2-04. If we're going to negotiate IP address leases over IKE, it would seem like the lease should last for the duration of the ESP SA rather than expecting the client to periodically renew it. This would require some additional state on the server (renewal timers), and would require that the server close the ESP SA if it were ever unable to renew the lease, but it would simplify the client, simplify the minimal IKE implementation, and reduce the number of error states we could get into. I believe this would be an improvement, but gave in to people who understand this stuff better than I do. But if others with more confidence would like to argue about it... --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Sat Jan 11 23:28:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13740 Sat, 11 Jan 2003 23:23:24 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <5.2.0.9.2.20030105141806.00b4c600@mail.binhost.com> Subject: Re: Counter Mode: Proposed Way Forward To: Russ Housley Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, Paul Koning X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 11 Jan 2003 22:59:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 01/11/2003 11:25:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ Housley wrote: > Your proposal obviously works too, but it exceeds the requirements. > > Do others agree with the conclusion from the discussions in Atlanta? Or, > do others like the suggestion made by Paul? > > Since both obviously meet the requirements, the structure of existing > implementations should probably guide us. The people that I talked to in > Atlanta saw no problem with the use of IKE nonces. >From an "elegance" perspective, I prefer Paul's proposal (getting the counter mode parameter from the keying material), and I see no practical downside. But I also don't think it matters, so if you have a working consensus, go for it! Two nits: Russ> Each party will use the nonce that it generated for encryption, Russ> and the nonce that the other party generated for decryption. Russ> The 32 least significant bits of the nonce used to establish Russ> the security association will be used in the AES-CTR counter Russ> block. For the first security association, the nonces come Russ> from the IKE_SA_init and IKE_SA_init_response. For subsequent Russ> security associations, the nonces come from the CREATE_CHILD_SA Russ> request and CREATE_CHILD_SA response. Nonces are bit strings rather than integers, so I believe the more correct wording is the "final 32 bits" of the nonce rather than the least significant. If the counter block is an integer, some endian-ness may need to be specified in the translation. More substantially, if the IKE SA and the ESP SA both negotiate CTR mode, they will end up with the same nonces (though with different keys). Is that a problem? (In practice no; what about in theory?) --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Sat Jan 11 23:57:02 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13870 Sat, 11 Jan 2003 23:53:50 -0500 (EST) Date: Sat, 11 Jan 2003 23:55:30 -0500 (EST) From: Henry Spencer To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 11 Jan 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > Why 2-key 3DES? Why not 3-key? ... > > Only because it was my understanding that 2 key 3DES was what was most > commonly deployed... Uh, what makes you think that? IPsec 3DES, as specified by RFC 2451, is 3-key and always has been. Henry Spencer henry@spsystems.net From owner-ipsec Sun Jan 12 04:06:08 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14359 Sun, 12 Jan 2003 04:01:43 -0500 (EST) Message-ID: <001a01c2ba19$bb92bd20$06e9fea9@amanda2> Reply-To: "Ahmed Bin Abbas Ahmed Ali Adas" From: "Ahmed Bin Abbas Ahmed Ali Adas" To: "Henry Spencer" , Cc: References: Subject: Re: draft-ietf-ipsec-ikev2-04.txt Date: Sun, 12 Jan 2003 12:05:13 +0300 Organization: KAAU MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer I still believe that the IPSec WG may have to abandon 3DES as a cryptographic system and rather concentrate on IPSec AES, several quantum computing scenarios have indicated that DES and its derivatives can be broken. Regards Ahmed alaadas@kaau.edu.sa ----- Original Message ----- From: "Henry Spencer" To: Cc: Sent: Sunday, January 12, 2003 7:55 AM Subject: Re: draft-ietf-ipsec-ikev2-04.txt > On Sat, 11 Jan 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > > Why 2-key 3DES? Why not 3-key? ... > > > > Only because it was my understanding that 2 key 3DES was what was most > > commonly deployed... > > Uh, what makes you think that? IPsec 3DES, as specified by RFC 2451, is > 3-key and always has been. > > Henry Spencer > henry@spsystems.net > From owner-ipsec Sun Jan 12 11:54:18 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15013 Sun, 12 Jan 2003 11:45:39 -0500 (EST) Message-Id: <200301121644.h0CGiOof066946@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal In-reply-to: Your message of Sat, 11 Jan 2003 18:22:10 EST. Date: Sun, 12 Jan 2003 17:44:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I've now read and understood draft-dupont-transient-pseudonat-01.txt. I'd like to propose language in the IKEv2 and NAT traversal documents to address it, but I'm eager to hear from the NAT Traversal folk whether the fix will break too many real cases. => My purpose is not to drop the NAT traversal feature but to make it optional. This should place the discussion on the default, IMHO we should be default enable NAT traversal for IPv4 and disable it for IPv6. Francis Dupont wrote: > The I-D editor has just announced the new version of my I-D about > the transient pseudo-NAT attack and its application to Mobile IPv4 > (documented in the security section of the NAT traversal extension) > and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt. > I believe we should fix the issue (the security flaw) for the next > version of the IKEv2 document. I could imagine lots of clever ways to try to deal with this... all with clever countermeasures that allow an attacker to exploit them. => this is my claim: there is no easy defense against the attack which keeps the NAT traversal feature... So what I'd like to propose is that IPsec SAs *not* try to survive mid-connection NAT renumberings. => this is another problem, in fact we have several issues: - IKE and IPsec SAs built with fake addresses (my I-D). - mid-connection renumbering of IKE SAs (with or without return routability, i.e., with or without more than two packets exchange) - mid-connection renumbering of IPsec SAs and for the two last we have the choice between explicit and implicit renumbering... That an IP address and UDP port be associated with an SA during initialization and that all subsequent traffic be sent to that address and port until it is timed out and closed. Requests *from* an unexpected IP address/port should be ignored. (Perhaps there is a way to respond with an alert to make the timeout process converge faster, but I couldn't think of one that couldn't be exploited by an attacker). => so you are against the implicit mid-connection renumbering of IPsec SAs. There is a residual attack here where the attacker gets in the middle of the initial SA setup and tricks the endpoints into sending to the wrong address by forwarding all the packets during setup. (If it continues to forward packets throughout the SA, everything works... essentially it *is* a NAT. But if it stops it can temporarily get traffic misdirected). => this is the transient pseudo-NAT attack. This seems like a difficult attack more easily mounted against other UDP based protocols. => I don't understand the second part of your argument (the "more easily"). BTW my I-D describes a second example (Mobile IPv4) where the issue was not ignored (cf. the security consideration of the NAT traversal for Mobile IPv4 I-D). And preventing it seems to require detecting NATs and refusing to operate through them. => exactly. Perhaps there should explicitly be a configuration parameter in IPsec implementations allowing this. => I agree (and I propose a default config in the first answer). I'm out of my depth here. What do existing implementations do? => In many cases the peer address is bound to the authentication (is the SubjectName of the peer certificate for instance) and is indirectly checked (this is why this issue is related to the "revised identity" proposal). In other cases the attack works. Do they not support mid-connection renumbering => they should support implicit renumbering of IKEv1 SAs but they should not support it for IPsec SAs, at least by default. or are they subject to the DOS attack? => there is a little margin between not flexible enough and subject to attacks. IMHO we should avoid implicit mechanisms (i.e., request a to-be-defined(*) explicit renumbering exchange) and define some configuration parameters with defaults in common cases. Is there a known better fix? => see above. Thanks Francis.Dupont@enst-bretagne.fr PS (*): IKEv2 rekeying is already usable, even a bit expensive, as a renumbering exchange for enough flexible implementations (IMHO we should request this flexibility). From owner-ipsec Sun Jan 12 14:02:24 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15208 Sun, 12 Jan 2003 13:57:14 -0500 (EST) From: "Jayant Shukla" To: , "'Francis Dupont'" Cc: , Subject: RE: peer address protection and NAT Traversal Date: Sun, 12 Jan 2003 10:57:11 -0800 Message-ID: <000001c2ba6c$6a085340$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Charlie_Kaufman@notesdev.ibm.com > > So what I'd like to propose is that IPsec SAs *not* try to survive > mid-connection NAT renumberings. That an IP address and UDP port be Mobile IP people may not like this very much at all. > > I'm out of my depth here. What do existing implementations do? Do they not > support mid-connection renumbering or are they subject to the DOS attack? > Is there a known better fix? > We support recovery from floated NAT entries and this is what we do. We use a three-way handshake to exchange the information required for NAT traversal. This significantly reduces the potential threat mentioned by Francis, but does not completely eliminate it. A better solution IMHO would be: To 100% protect against the attack mentioned by Francis if NAT vendors put a mechanism by which those behind the NATs can query the NAT WAN interface address. Then the devices behind NAT can compare this address with the perceived address by the remote sites (echoed back securely) and completely neutralize these attacks. This is true only if there is one NAT in-between and I think it is true for majority of cases. In lieu of this, one can make multiple queries to several sites and check them for consistency. This is a heuristic approach and only reduces the threat, but does not eliminate it. Regards, Jayant www.trlokom.com > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Sun Jan 12 15:40:42 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15358 Sun, 12 Jan 2003 15:36:34 -0500 (EST) Message-Id: <5.2.0.9.2.20030112152344.00b543f0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 12 Jan 2003 15:31:54 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Counter Mode: Proposed Way Forward Cc: pkoning@equallogic.com, Charlie_Kaufman@notesdev.ibm.com In-Reply-To: References: <5.2.0.9.2.20030105141806.00b4c600@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Russ Housley wrote: > > Your proposal obviously works too, but it exceeds the requirements. > > > > Do others agree with the conclusion from the discussions in Atlanta? Or, > > do others like the suggestion made by Paul? > > > > Since both obviously meet the requirements, the structure of existing > > implementations should probably guide us. The people that I talked to in > > Atlanta saw no problem with the use of IKE nonces. > > From an "elegance" perspective, I prefer Paul's proposal (getting the >counter mode parameter from the keying material), and I see no practical >downside. But I also don't think it matters, so if you have a working >consensus, go for it! So far, only Charlie and Paul have comments. David Black has indicated on several occasions that the IP Storage (ips) folks who are depending on AES counter mode. I sure would like to hear from others who plan to implement. >Two nits: > > Russ> Each party will use the nonce that it generated for encryption, > Russ> and the nonce that the other party generated for decryption. > Russ> The 32 least significant bits of the nonce used to establish > Russ> the security association will be used in the AES-CTR counter > Russ> block. For the first security association, the nonces come > Russ> from the IKE_SA_init and IKE_SA_init_response. For subsequent > Russ> security associations, the nonces come from the CREATE_CHILD_SA > Russ> request and CREATE_CHILD_SA response. > >Nonces are bit strings rather than integers, so I believe the more correct >wording is the "final 32 bits" of the nonce rather than the least >significant. If the counter block is an integer, some endian-ness may need >to be specified in the translation. Agree. This is a straightforward change. >More substantially, if the IKE SA and the ESP SA both negotiate CTR mode, >they will end up with the same nonces (though with different keys). Is that >a problem? (In practice no; what about in theory?) I do not see a problem. The nonce needs to be unpredictable, and in both cases it is unpredictable. The only thing that is predictable is that the values will be the same in this once situation. Russ From owner-ipsec Sun Jan 12 16:45:42 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15539 Sun, 12 Jan 2003 16:37:38 -0500 (EST) Message-Id: <200301122139.h0CLdGQY019133@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal In-reply-to: Your message of "Sat, 11 Jan 2003 18:22:10 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 12 Jan 2003 13:39:16 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> Mapped UDP port assignments in NATs can be timed out prematurely. When this Charlie> happens, packets coming from the Internet to the NAT will be dropped (or I thought that a great deal of effort needed to be expended to make sure that this doesn't occur... Charlie> against the node whose IP address was forged in the header. If he doesn't, Charlie> all the packets sent will be lost in the case where a genuine NAT remapped Charlie> addresses. Since NATs are not generally capable of cryptographic Charlie> authentication, there is no reliable way to distinguish these Charlie> cases. ... Charlie> So what I'd like to propose is that IPsec SAs *not* try to survive Charlie> mid-connection NAT renumberings. That an IP address and UDP port be I would agree here. If there were some way for the client to determine that the NAPT mapping has changed, then it could essentially rekey the connection. One way to do this is to have the gateway side reflect the NAPT ports involved to the client *inside* of the IKE SA. Yes, the gateway has to keep track of this stuff, but ultimately, the client worries about rekeying things upon determining that the mapping has changed. The gateway *does* have to always use the new mappings for IKE packets - it just doesn't change the IPsec SA. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPiHggYqHRg3pndX9AQHUiAQAx9N35r2P9r+dIhqTR1tSAGyFWzdwxdmO vtBj4WzB/puqRk25j77Kd8wcvo0Lus8NGVqqiJh8SoAnzkNFHzIJLwwcJ2dA8ebe Ac7EmG8yNER+JK0wAUa9PLBysE/+vocfMfkJoyX9CRTe3LfuAqHL+iUH5IhwfpH6 LLMiwxZQNwc= =OUMF -----END PGP SIGNATURE----- From owner-ipsec Sun Jan 12 16:46:46 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15589 Sun, 12 Jan 2003 16:43:45 -0500 (EST) Message-Id: <200301122145.h0CLjwRB019313@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Proposed Configuration payload for IKEv2 In-reply-to: Your message of "Sat, 11 Jan 2003 22:01:47 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 12 Jan 2003 13:45:57 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> Alternatively, we could run DHCP over the IKE SA instead of over a special Charlie> ESP SA set up for that purpose, but this requires even more special casing Charlie> for what the endnode fills in for hardware address, etc. No, the endnode fills in the normal thing - its hardware address. It is still unique, and still relevant to the DHCP server. Charlie> I would think a not unlikely scenario would be where a user has a permanent Charlie> internal IP address and the IPsec gateway wants to assign that internal IP Charlie> address based on the user's identity (independent of what address the user Charlie> is tunnelling from). This would require more special case kludgery if we Charlie> wanted the negotiation to look like DHCP but use other fields from the IKE Charlie> messages. I disagree. it is not kludgery - it is very intelligent reuse of protocols. Let's be clear - only in rare cases client (i.e. inside MS-Windows) will you get to reuse the DHCP client code. For pretty much everyone else (including *nix systems) you have to at a minimum recompile dhclient code into your IKE daemon. The win is on the gateway side - there is only the one DHCP server, and it can be pretty much any piece of code. Charlie> - and in fact it works more smoothly and efficiently once that happens. So Charlie> my second thought was that IKE be capable of negotiating an internal IP Charlie> address after which DHCP tunnelled over ESP could be used for obtaining any Charlie> other information desired. This would work, and it's my understanding that DHCP Inform. Many of suggested that most of the PPP IP options should have been done with the DHCP Inform over PPP IPCP. Charlie> I had another objection to the design I added to ikev2-04. If we're going Charlie> to negotiate IP address leases over IKE, it would seem like the lease Charlie> should last for the duration of the ESP SA rather than expecting the client Charlie> to periodically renew it. This would require some additional state on the Charlie> server (renewal timers), and would require that the server close the ESP SA Charlie> if it were ever unable to renew the lease, but it would simplify the Charlie> client, simplify the minimal IKE implementation, This sounds complicated to me. And adding state on the gateway is not a good idea (please state "dhcp server" or "ipsec gateway"). If the address assignment on the gateway side is not done by the DHCP server, then it has got to be coordinated - i.e. the gateway will have to speak DHCP (client) to the real dhcp server. This just seems more complicated to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPiHiE4qHRg3pndX9AQHDlQQAtf9R0C8bnBRN0TW/BAjD8kjSQAAZRUtd kioPH/9bGkgAOpsXZ1Dl+vPfEds/EXKWFiE49VGtEfcBdkE6mnNgc0Lvbg1pAY3A u+1fVA1/9n/3gfsfMrJx2osHdk58MZVVb2pnRWE5PnXdnMXbr64Xh1ThW+hcxizB yK8um6ppLJ4= =U0ZZ -----END PGP SIGNATURE----- From owner-ipsec Mon Jan 13 04:20:36 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17126 Mon, 13 Jan 2003 04:16:29 -0500 (EST) Message-Id: <200301130915.h0D9FJof068807@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jayant Shukla" cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal In-reply-to: Your message of Sun, 12 Jan 2003 10:57:11 PST. <000001c2ba6c$6a085340$5803a8c0@trlhpc1> Date: Mon, 13 Jan 2003 10:15:19 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > So what I'd like to propose is that IPsec SAs *not* try to survive > mid-connection NAT renumberings. That an IP address and UDP port be Mobile IP people may not like this very much at all. => this was discussed privately between some mobile IP people and we concluded this is too unsafe. But something is still needed (an explicit mechanism). > I'm out of my depth here. What do existing implementations do? Do they not > support mid-connection renumbering or are they subject to the DOS attack? > Is there a known better fix? > We support recovery from floated NAT entries and this is what we do. We use a three-way handshake to exchange the information required for NAT traversal. This significantly reduces the potential threat mentioned by Francis, but does not completely eliminate it. => three-way handshake == return routability check, i.e., you check the peer can receive packets to its claimed address? A better solution IMHO would be: To 100% protect against the attack mentioned by Francis if NAT vendors put a mechanism by which those behind the NATs can query the NAT WAN interface address. Then the devices behind NAT can compare this address with the perceived address by the remote sites (echoed back securely) and completely neutralize these attacks. This is true only if there is one NAT in-between and I think it is true for majority of cases. => first we'd like to get a passive NAT traversal feature (no midcom), second I am afraid the one NAT constraint is too strong (i.e., it works only in some countries). In lieu of this, one can make multiple queries to several sites and check them for consistency. This is a heuristic approach and only reduces the threat, but does not eliminate it. => I don't believe we should reduce the threat by expensive mechanisms. My proposal is to give the choice between to be immune and to get NAT traversal support. So we need a swicth in configurations, a way (a new notification?) to required peer address protection (already provided by NAT-DETECTION-{SOURCE,DESTINATION}-IP) and an error (another notification) when NAT is detected but not supported. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec Mon Jan 13 04:44:02 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17222 Mon, 13 Jan 2003 04:42:01 -0500 (EST) Message-ID: <3E228A71.90701@F-Secure.com> Date: Mon, 13 Jan 2003 11:44:17 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal References: <200301121644.h0CGiOof066946@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2003 09:44:19.0196 (UTC) FILETIME=[580903C0:01C2BAE8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > In your previous mail you wrote: > > I've now read and understood draft-dupont-transient-pseudonat-01.txt. I'd > like to propose language in the IKEv2 and NAT traversal documents to > address it, but I'm eager to hear from the NAT Traversal folk whether the > fix will break too many real cases. > > => My purpose is not to drop the NAT traversal feature but to make it > optional. This should place the discussion on the default, IMHO we should > be default enable NAT traversal for IPv4 and disable it for IPv6. Well, if you don't have a NAT in an IPv6 (or whatever version of IP) case, no UDP encapsulation will be done. So a better solution is to deploy IPv6 and not deploy NATs. > > Francis Dupont wrote: > > The I-D editor has just announced the new version of my I-D about > > the transient pseudo-NAT attack and its application to Mobile IPv4 > > (documented in the security section of the NAT traversal extension) > > and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt. > > I believe we should fix the issue (the security flaw) for the next > > version of the IKEv2 document. > > I could imagine lots of clever ways to try to deal with this... all with > clever countermeasures that allow an attacker to exploit them. > > => this is my claim: there is no easy defense against the attack which > keeps the NAT traversal feature... This is not suprising. If there's somebody who can change traffic between you and the other guy you want to talk to, all bets are off anyway. Is there a real case where some hacker may be able to do this for a short while, but not arbitrarily long? > > So what I'd like to propose is that IPsec SAs *not* try to survive > mid-connection NAT renumberings. Well, it's intentionally left out of the current NAT traversal drafts. It was discussed at some point between the authors. Instead we specify NAT keepalives. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec Mon Jan 13 04:47:38 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17279 Mon, 13 Jan 2003 04:46:12 -0500 (EST) Message-ID: <3E228B72.1060100@F-Secure.com> Date: Mon, 13 Jan 2003 11:48:34 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayant Shukla CC: Charlie_Kaufman@notesdev.ibm.com, "'Francis Dupont'" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal References: <000001c2ba6c$6a085340$5803a8c0@trlhpc1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2003 09:48:36.0267 (UTC) FILETIME=[F142EFB0:01C2BAE8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant Shukla wrote: > A better solution IMHO would be: > > To 100% protect against the attack mentioned by Francis if NAT vendors > put a mechanism by which those behind the NATs can query the NAT WAN > interface address. Then the devices behind NAT can compare this address > with the perceived address by the remote sites (echoed back securely) > and completely neutralize these attacks. This is true only if there is > one NAT in-between and I think it is true for majority of cases. This won't work because an underlying assumption, with me anyway, is that NATs are 'hostile'. They won't tell you anything of this sort, and even if you made a new RFC about it, no previously existing NAT would still do it. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec Mon Jan 13 05:23:19 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17404 Mon, 13 Jan 2003 05:19:55 -0500 (EST) Message-Id: <200301131018.h0DAIjof069252@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ari Huttunen cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal In-reply-to: Your message of Mon, 13 Jan 2003 11:44:17 +0200. <3E228A71.90701@F-Secure.com> Date: Mon, 13 Jan 2003 11:18:45 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > => My purpose is not to drop the NAT traversal feature but to make it > optional. This should place the discussion on the default, IMHO we should > be default enable NAT traversal for IPv4 and disable it for IPv6. Well, if you don't have a NAT in an IPv6 (or whatever version of IP) case, no UDP encapsulation will be done. So a better solution is to deploy IPv6 and not deploy NATs. => I agree but NAT traversal is in the charter of the WG... > => this is my claim: there is no easy defense against the attack which > keeps the NAT traversal feature... This is not suprising. If there's somebody who can change traffic between you and the other guy you want to talk to, all bets are off anyway. Is there a real case where some hacker may be able to do this for a short while, but not arbitrarily long? => with IKEv2 on a rekey exchange the hacker has only to modify the headers of two packets... Only a keepalive mechanism will detect it (far too late). (note I refer to a SA keepalive, not to a NAT keepalive) > So what I'd like to propose is that IPsec SAs *not* try to survive > mid-connection NAT renumberings. Well, it's intentionally left out of the current NAT traversal drafts. It was discussed at some point between the authors. Instead we specify NAT keepalives. => we have to specify in details the peer address management, and not only for NAT traversal but also for mobility and multi-homing. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec Mon Jan 13 08:51:37 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18030 Mon, 13 Jan 2003 08:47:40 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090ED0@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Charlie_Kaufman@notesdev.ibm.com'" Cc: ipsec@lists.tislabs.com Subject: RE: Proposed Configuration payload for IKEv2 Date: Mon, 13 Jan 2003 14:49:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Charlie_Kaufman@notesdev.ibm.com [mailto:Charlie_Kaufman@notesdev.ibm.com] Sent: zondag 12 januari 2003 4:02 To: Van Aken Dirk Cc: ipsec@lists.tislabs.com Subject: RE: Proposed Configuration payload for IKEv2 Hi Charlie, See my remarks below. >Wouldn't it be simpler to use DHCP all the way i.e. the construct >DHCPClient-Relay-Server ? I initially had the same thought, but was talked out of it. Let me repeat the logic that convinced me, and see if it does anything for you. The bottom line is that while I believe this would be possible, I don't believe it simpler. The problem is that DHCP runs over IP only though heavy kludgery. Since you don't initially know your IP address, you must send initial DHCP messages from IP address zero and get responses either via your hardware address or by multicast. >> Not fully correct ! The reason why the hardware address comes into the picture has all to do with shared media such as Ethernet. e.g. Take following non-IPSec configuration: an Ethernet segment is connected to a router. DHCP client requests, which are per definition broadcasted, are intercepted by the router and DHCP-relayed (that is unicasted..) to a DHCP server. The server's replies arrive back on the router's IP interface. How can this IP interface forward these replies back to the client ? Remember the client still has no IP address hence cannot answer ARP request. Solution: either use Ethernet's broadcast address (FF-FF-FF-FF-FF) or use the client's hardware address (being a MAC unicast address in the Ethernet case) contained in the reply. Doing DHCP on point-to-point links is quite different and IMHO, IPSec Tunnels are point-to-point links ... >> If we wanted to tunnel these messages over IPsec protected ESP, we would have to first set up an ESP SA tunnelling packets from address zero to a broadcast address, and then after the IP address becomes known set up a new ESP SA with the new address. >> Setting up tunnel to and from 0.0.0.0/255.255.255.255;port 67/68 seems not that complicated to me compared to the cryptographic stuff inside IKE. I guess it has more to do with implementations that have implemented only limited IKE functionality. >> I would expect some substantial confusion with the packet forwarding tables on the server, and a lot of special casing. >> I cannot follow you here. Of course a method must be implemented to terminated multiple of such DHCP tunnels simultaneously. More specific you need a method to tag DHCP request coming out of a tunnel. Via this tag, the IPSec gateway can forward the responses from the server back into the appropriate tunnel. Well this is exactly what RFC3046 is intended for i.e. see RFC3046 section 3.1 Agent Circuit ID sub-option. With slight modifications this technique could be reused for IPSec. I guess http://www.strongsec.com/freeswan/dhcprelay/ipsec-dhcp-howto.pdf implements just that. >> Alternatively, we could run DHCP over the IKE SA instead of over a special ESP SA set up for that purpose, but this requires even more special casing for what the endnode fills in for hardware address, etc. >> To be honest, this approach suffers from the same problem as IKE mode config: two protocols are intertwined here: IKE for key establishment and DHCP for IP host configuration. Why can't IKE and host configuration not be completely decoupled ? More specific host configuration is "data" that should be protected such as any other data that needs to be securely transported between two sites. In addition, watching the discussion on the Internal_Address_Expiry attribute confirms my opinion on protocol intertwining. As said before it is PPP-IPCP all over again but then in IKE ... >> I would think a not unlikely scenario would be where a user has a permanent internal IP address and the IPsec gateway wants to assign that internal IP address based on the user's identity (independent of what address the user is tunnelling from). This would require more special case kludgery if we wanted the negotiation to look like DHCP but use other fields from the IKE messages. >> Can you clarify what exactly your scenario is because this type of "permanent/static" assignments already exists for years in DHCP. >> DHCP is capable of carrying lots of kinds of information. Except for dynamic IP address, all of it is obtainable after you have your IP address - and in fact it works more smoothly and efficiently once that happens. So my second thought was that IKE be capable of negotiating an internal IP address after which DHCP tunnelled over ESP could be used for obtaining any other information desired. This would work, and it's my understanding that an endnode could use this mechanism to get DHCP-based information not available through IKE. Throwing a few more commonly used parameters into IKE - like the IP address of a DNS server - is clearly unnecessary but will simplify the common case of implementations that only want that additional information. I could be convinced either way on that one. >> Well, Charlie this is a bold statement: let's say that 70% of the Internet host either use DHCP directly to obtain their IP address or indirectly (via constructs such as PPP-IPCP-DHCP or IKE-DHCP). If there would be problems with this mechanism I guess we would not be discussing right now ... The real point is the following: is the IKEv2 working group willing to adopt and willing to include a pointer towards this draft RFC or does it sticks with yet another in-band IP configuration protocol ? I prefer the first option and below I enumerate my reasons: - clean protocol layering/engineering (IKE for secure cryptographic key establishment DHCP for IP host configuration) - DHCP runs end-to-end - only one IP configuration method must be implemented/tested/maintained versus two in the current situation >> Best regards - Dirk I had another objection to the design I added to ikev2-04. If we're going to negotiate IP address leases over IKE, it would seem like the lease should last for the duration of the ESP SA rather than expecting the client to periodically renew it. This would require some additional state on the server (renewal timers), and would require that the server close the ESP SA if it were ever unable to renew the lease, but it would simplify the client, simplify the minimal IKE implementation, and reduce the number of error states we could get into. I believe this would be an improvement, but gave in to people who understand this stuff better than I do. But if others with more confidence would like to argue about it... --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Mon Jan 13 09:24:04 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18160 Mon, 13 Jan 2003 09:21:32 -0500 (EST) Message-Id: <200301101736.MAA05542@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-04.txt Date: Fri, 10 Jan 2003 12:36:48 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-04.txt Pages : 74 Date : 2003-1-9 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE performs mutual authentication and establishes an IKE security association that can be used to efficiently establish SAs for ESP and/or AH. This version greatly simplifies IKE by replacing the 8 possible phase 1 exchanges with a single exchange based on either public signature keys or shared secret keys. The single exchange provides identity hiding, yet works in 2 round trips (all the identity hiding exchanges in IKE v1 required 3 round trips). Latency of setup of an IPsec SA is further reduced from IKEv1 by allowing setup of an SA for ESP and/or AH to be piggybacked on the initial IKE exchange. It also improves security by allowing the Responder to be stateless until it can be assured that the Initiator can receive at the claimed IP source address. This version also presents the entire protocol in a single self-contained document, in contrast to IKEv1, in which the protocol was described in ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407) documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10122636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10122636.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Jan 13 09:36:04 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18284 Mon, 13 Jan 2003 09:33:56 -0500 (EST) Message-ID: <3E22CEAE.40009@F-Secure.com> Date: Mon, 13 Jan 2003 16:35:26 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal References: <200301131018.h0DAIjof069252@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jan 2003 14:35:28.0600 (UTC) FILETIME=[049C8580:01C2BB11] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > > So what I'd like to propose is that IPsec SAs *not* try to survive > > mid-connection NAT renumberings. > > Well, it's intentionally left out of the current NAT traversal drafts. > It was discussed at some point between the authors. Instead we specify > NAT keepalives. > > => we have to specify in details the peer address management, and not only > for NAT traversal but also for mobility and multi-homing. You or anybody else is welcome to do it. I won't touch that with a long pole :). Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec Mon Jan 13 11:38:47 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18929 Mon, 13 Jan 2003 11:35:42 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C749@corpmx14.us.dg.com> To: daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: RE: AES cipher suites Date: Mon, 13 Jan 2003 11:36:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Why do you need both? What problem does AES-CBC solve that AES-CTR > doesn't? It looks to me like AES-CTR is likely to be good enough for > everything that AES-CBC is good enough for -- but then, I'm > not familiar with ips. What am I missing? Nothing - ips only needs AES-CTR. If that's adequate for everyone who wants to use AES, then AES-CBC is not needed, but I can't draw that conclusion solely based on what IPS envisions ... anyone who wants/needs AES-CBC even if AES-CTR is present needs to speak up promptly. Thanks, --David > -----Original Message----- > From: daw@mozart.cs.berkeley.edu [mailto:daw@mozart.cs.berkeley.edu] > Sent: Saturday, January 11, 2003 3:31 PM > To: ipsec@lists.tislabs.com > Subject: Re: AES cipher suites > > > David Black wrote: > >On behalf of the IP Storage (ips) folks who are depending on AES > >counter mode, I want to make a strong request for specification of > >*both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR > >is motivated by a desire to build high-speed hardware. While AES-CTR > >is the "right thing" for that class of implementation, I'm reluctant > >to impose it on everyone who wants to use AES by not defining an > >AES-CBC suite. > > Why do you need both? What problem does AES-CBC solve that AES-CTR > doesn't? It looks to me like AES-CTR is likely to be good enough for > everything that AES-CBC is good enough for -- but then, I'm > not familiar > with ips. What am I missing? > From owner-ipsec Mon Jan 13 11:53:01 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18984 Mon, 13 Jan 2003 11:51:06 -0500 (EST) Message-ID: <3E22EE02.6368516E@bstormnetworks.com> Date: Mon, 13 Jan 2003 08:49:06 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Van Aken Dirk CC: "'Charlie_Kaufman@notesdev.ibm.com'" , ipsec@lists.tislabs.com Subject: Re: Proposed Configuration payload for IKEv2 References: <421CB3B9B2D2F645B548D213C0A90E55090ED0@TMM_EDGMSMSG01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Dirk, and want to point something out that may not be clear from Charlie's post: this functionality is meant for use in remote access scenarios only. In these cases, the client system has an assigned IP address already, but there is a desire to provide an internal "virtual" address from the target network for various reasons. So, the tunnel does not terminate at either a 0.0.0.0 or a broadcast address. Rather, these are the transport selectors. I urge everyone concerned to read draft-ietf-ipsec-dhcp-13.txt, which is a standards track document, and is pending in the RFC editor's queue. And I re-iterate: I know of several fielded implementations, and have worked on one myself. This is not that hard to do, and it is difficult to understand why it should be worth contorting ikev2 for this functionality when a reasonable solution already exists. Scott Van Aken Dirk wrote: > > -----Original Message----- > From: Charlie_Kaufman@notesdev.ibm.com > [mailto:Charlie_Kaufman@notesdev.ibm.com] > Sent: zondag 12 januari 2003 4:02 > To: Van Aken Dirk > Cc: ipsec@lists.tislabs.com > Subject: RE: Proposed Configuration payload for IKEv2 > > Hi Charlie, > > See my remarks below. > > >Wouldn't it be simpler to use DHCP all the way i.e. the construct > >DHCPClient-Relay-Server ? > > I initially had the same thought, but was talked out of it. Let me repeat > the logic that convinced me, and see if it does anything for you. > > The bottom line is that while I believe this would be possible, I don't > believe it simpler. The problem is that DHCP runs over IP only though heavy > kludgery. Since you don't initially know your IP address, you must send > initial DHCP messages from IP address zero and get responses either via > your hardware address or by multicast. > >> > Not fully correct ! > The reason why the hardware address comes into the picture has all to do > with shared media such as Ethernet. > e.g. Take following non-IPSec configuration: an Ethernet segment is > connected to a router. DHCP client requests, which are per definition > broadcasted, are intercepted by the router and DHCP-relayed (that is > unicasted..) to a DHCP server. The server's replies arrive back on the > router's IP interface. How can this IP interface forward these replies back > to the client ? Remember the client still has no IP address hence cannot > answer ARP request. Solution: either use Ethernet's broadcast address > (FF-FF-FF-FF-FF) or use the client's hardware address (being a MAC unicast > address in the Ethernet case) contained in the reply. > > Doing DHCP on point-to-point links is quite different and IMHO, IPSec > Tunnels are point-to-point links ... > >> > > If we wanted to tunnel these > messages over IPsec protected ESP, we would have to first set up an ESP SA > tunnelling packets from address zero to a broadcast address, and then after > the IP address becomes known set up a new ESP SA with the new address. > >> > Setting up tunnel to and from 0.0.0.0/255.255.255.255;port 67/68 seems not > that complicated to me compared to the cryptographic stuff inside IKE. I > guess it has more to do with implementations that have implemented only > limited IKE functionality. > >> > > I would expect some substantial confusion with the packet forwarding tables > on the server, and a lot of special casing. > >> > I cannot follow you here. Of course a method must be implemented to > terminated multiple of such DHCP tunnels simultaneously. More specific you > need a method to tag DHCP request coming out of a tunnel. Via this tag, the > IPSec gateway can forward the responses from the server back into the > appropriate tunnel. Well this is exactly what RFC3046 is intended for i.e. > see RFC3046 section 3.1 Agent Circuit ID sub-option. With slight > modifications this technique could be reused for IPSec. > > I guess http://www.strongsec.com/freeswan/dhcprelay/ipsec-dhcp-howto.pdf > implements just that. > >> > > Alternatively, we could run DHCP over the IKE SA instead of over a special > ESP SA set up for that purpose, but this requires even more special casing > for what the endnode fills in for hardware address, etc. > >> > To be honest, this approach suffers from the same problem as IKE mode > config: two protocols are intertwined here: IKE for key establishment and > DHCP for IP host configuration. > > Why can't IKE and host configuration not be completely decoupled ? More > specific host configuration is "data" that should be protected such as any > other data that needs to be securely transported between two sites. > In addition, watching the discussion on the Internal_Address_Expiry > attribute confirms my opinion on protocol intertwining. > > As said before it is PPP-IPCP all over again but then in IKE ... > >> > > I would think a not unlikely scenario would be where a user has a permanent > internal IP address and the IPsec gateway wants to assign that internal IP > address based on the user's identity (independent of what address the user > is tunnelling from). This would require more special case kludgery if we > wanted the negotiation to look like DHCP but use other fields from the IKE > messages. > >> > Can you clarify what exactly your scenario is because this type of > "permanent/static" assignments already exists for years in DHCP. > >> > > DHCP is capable of carrying lots of kinds of information. Except for > dynamic IP address, all of it is obtainable after you have your IP address > - and in fact it works more smoothly and efficiently once that happens. So > my second thought was that IKE be capable of negotiating an internal IP > address after which DHCP tunnelled over ESP could be used for obtaining any > other information desired. This would work, and it's my understanding that > an endnode could use this mechanism to get DHCP-based information not > available through IKE. Throwing a few more commonly used parameters into > IKE - like the IP address of a DNS server - is clearly unnecessary but will > simplify the common case of implementations that only want that additional > information. I could be convinced either way on that one. > >> > Well, Charlie this is a bold statement: let's say that 70% of the Internet > host either use DHCP directly to obtain their IP address or indirectly (via > constructs such as PPP-IPCP-DHCP or IKE-DHCP). If there would be problems > with this mechanism I guess we would not be discussing right now ... > > The real point is the following: is the IKEv2 working group willing to adopt > and willing to include a pointer towards this > draft RFC or does it sticks with yet another in-band IP configuration > protocol ? > > I prefer the first option and below I enumerate my reasons: > - clean protocol layering/engineering (IKE for secure cryptographic key > establishment DHCP for IP host configuration) > - DHCP runs end-to-end > - only one IP configuration method must be implemented/tested/maintained > versus two in the current situation > >> > > Best regards - Dirk > > > I had another objection to the design I added to ikev2-04. If we're going > to negotiate IP address leases over IKE, it would seem like the lease > should last for the duration of the ESP SA rather than expecting the client > to periodically renew it. This would require some additional state on the > server (renewal timers), and would require that the server close the ESP SA > if it were ever unable to renew the lease, but it would simplify the > client, simplify the minimal IKE implementation, > and reduce the number of error states we could get into. I believe this > would be an improvement, but gave in to people who understand this stuff > better than I do. But if others with more confidence would like to argue > about it... > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Mon Jan 13 12:22:12 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19110 Mon, 13 Jan 2003 12:19:55 -0500 (EST) From: "Jayant Shukla" To: Cc: , , Subject: RE: peer address protection and NAT Traversal Date: Mon, 13 Jan 2003 09:19:16 -0800 Message-ID: <000201c2bb27$e7021ff0$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <200301130915.h0D9FJof068807@givry.rennes.enst-bretagne.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst- > > => three-way handshake == return routability check, i.e., you check the > peer can receive packets to its claimed address? > Yes, that is how we do it. To recover from floated NAT entries, we use a mechanism where the receiver can signal the sender to re-initiate the three-way handshake. You need the ability to request the three-way handshake in case there are multiple clients behind the same NAT. Regards, Jayant www.trlokom.com From owner-ipsec Mon Jan 13 12:37:15 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19210 Mon, 13 Jan 2003 12:35:26 -0500 (EST) From: "Jayant Shukla" To: "'Francis Dupont'" Cc: , Subject: RE: peer address protection and NAT Traversal Date: Mon, 13 Jan 2003 09:34:53 -0800 Message-ID: <000001c2bb2a$151a7070$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <200301131018.h0DAIjof069252@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > > => we have to specify in details the peer address management, and not only > for NAT traversal but also for mobility and multi-homing. > This is of interest to us as we are currently implementing multi-homing and active load balancing in our VPNs. What work has been done on it so far? Any IDs or RFCs? Regards, Jayant www.trlokom.com > Thanks > > Francis.Dupont@enst-bretagne.fr From owner-ipsec Mon Jan 13 12:53:36 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19304 Mon, 13 Jan 2003 12:50:55 -0500 (EST) Message-ID: <51C7002B020CD411824E009027C469F7DD3487@cldxch01.hifn.com> From: Bob Doud To: "'Black_David@emc.com'" , daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: RE: AES cipher suites Date: Mon, 13 Jan 2003 09:52:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Why do you need both? What problem does AES-CBC solve that AES-CTR > > doesn't? It looks to me like AES-CTR is likely to be good enough for > > everything that AES-CBC is good enough for -- but then, I'm > > not familiar with ips. What am I missing? > > Nothing - ips only needs AES-CTR. If that's adequate for everyone > who wants to use AES, then AES-CBC is not needed, but I can't draw > that conclusion solely based on what IPS envisions ... anyone who > wants/needs AES-CBC even if AES-CTR is present needs to speak up > promptly. Well, for one thing, there are a number of crypto accelerator chips from various companies that only support AES in CBC mode today. CTR mode is just now getting implemented in chips set to come out later this year (noting that the draft has still been fluid recently). So aside from IP storage, I'm sure there are a number of VPN products on the market now that only support CBC mode. Bob > > > > David Black wrote: > > >On behalf of the IP Storage (ips) folks who are depending on AES > > >counter mode, I want to make a strong request for specification of > > >*both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR > > >is motivated by a desire to build high-speed hardware. While AES-CTR > > >is the "right thing" for that class of implementation, I'm reluctant > > >to impose it on everyone who wants to use AES by not defining an > > >AES-CBC suite. > > > > Why do you need both? What problem does AES-CBC solve that AES-CTR > > doesn't? It looks to me like AES-CTR is likely to be good enough for > > everything that AES-CBC is good enough for -- but then, I'm not familiar > > with ips. What am I missing? > > > From owner-ipsec Mon Jan 13 13:54:13 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19563 Mon, 13 Jan 2003 13:50:42 -0500 (EST) Message-ID: <3E2309FE.F66B0B9E@bstormnetworks.com> Date: Mon, 13 Jan 2003 10:48:30 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com CC: daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: Re: AES cipher suites References: <277DD60FB639D511AC0400B0D068B71E0564C749@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are issues of backward compatibility: there are (recently) fielded devices which contain hardware support for aes-cbc and not aes-ctr. Are we to require vendors to forklift these devices? Scott Black_David@emc.com wrote: > > > Why do you need both? What problem does AES-CBC solve that AES-CTR > > doesn't? It looks to me like AES-CTR is likely to be good enough for > > everything that AES-CBC is good enough for -- but then, I'm > > not familiar with ips. What am I missing? > > Nothing - ips only needs AES-CTR. If that's adequate for everyone > who wants to use AES, then AES-CBC is not needed, but I can't draw > that conclusion solely based on what IPS envisions ... anyone who > wants/needs AES-CBC even if AES-CTR is present needs to speak up > promptly. > > Thanks, > --David > > > -----Original Message----- > > From: daw@mozart.cs.berkeley.edu [mailto:daw@mozart.cs.berkeley.edu] > > Sent: Saturday, January 11, 2003 3:31 PM > > To: ipsec@lists.tislabs.com > > Subject: Re: AES cipher suites > > > > > > David Black wrote: > > >On behalf of the IP Storage (ips) folks who are depending on AES > > >counter mode, I want to make a strong request for specification of > > >*both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR > > >is motivated by a desire to build high-speed hardware. While AES-CTR > > >is the "right thing" for that class of implementation, I'm reluctant > > >to impose it on everyone who wants to use AES by not defining an > > >AES-CBC suite. > > > > Why do you need both? What problem does AES-CBC solve that AES-CTR > > doesn't? It looks to me like AES-CTR is likely to be good enough for > > everything that AES-CBC is good enough for -- but then, I'm > > not familiar > > with ips. What am I missing? > > From owner-ipsec Mon Jan 13 14:09:13 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19640 Mon, 13 Jan 2003 14:07:14 -0500 (EST) Message-ID: From: "Mukund, Shridhar" To: "'Black_David@emc.com'" , daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Cc: "'Joseph J. Tardo'" Subject: RE: AES cipher suites Date: Mon, 13 Jan 2003 11:09:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, As Joseph pointed out, AES-CBC-XMAC is needed for authentication along with AES-CTR for confidentiality. It is true that AES-CBC-XMAC does not scale to higher speeds as well as the CTR mode. However, it is a step forward compared to using HMAC-SHA1 along side AES-CTR. Thanks, -Shridhar Mukund > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, January 13, 2003 8:37 AM > To: daw@mozart.cs.berkeley.edu; ipsec@lists.tislabs.com > Subject: RE: AES cipher suites > > > > Why do you need both? What problem does AES-CBC solve that AES-CTR > > doesn't? It looks to me like AES-CTR is likely to be good > enough for > > everything that AES-CBC is good enough for -- but then, I'm > > not familiar with ips. What am I missing? > > Nothing - ips only needs AES-CTR. If that's adequate for everyone > who wants to use AES, then AES-CBC is not needed, but I can't draw > that conclusion solely based on what IPS envisions ... anyone who > wants/needs AES-CBC even if AES-CTR is present needs to speak up > promptly. > > Thanks, > --David > > > -----Original Message----- > > From: daw@mozart.cs.berkeley.edu [mailto:daw@mozart.cs.berkeley.edu] > > Sent: Saturday, January 11, 2003 3:31 PM > > To: ipsec@lists.tislabs.com > > Subject: Re: AES cipher suites > > > > > > David Black wrote: > > >On behalf of the IP Storage (ips) folks who are depending on AES > > >counter mode, I want to make a strong request for specification of > > >*both* an AES-CBC suite and an AES-CTR suite. IPS's use of AES-CTR > > >is motivated by a desire to build high-speed hardware. > While AES-CTR > > >is the "right thing" for that class of implementation, I'm > reluctant > > >to impose it on everyone who wants to use AES by not defining an > > >AES-CBC suite. > > > > Why do you need both? What problem does AES-CBC solve that AES-CTR > > doesn't? It looks to me like AES-CTR is likely to be good > enough for > > everything that AES-CBC is good enough for -- but then, I'm > > not familiar > > with ips. What am I missing? > > > From owner-ipsec Mon Jan 13 17:19:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20248 Mon, 13 Jan 2003 17:10:56 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: AES cipher suites Date: 13 Jan 2003 21:49:39 GMT Organization: University of California, Berkeley Lines: 20 Distribution: isaac Message-ID: References: <277DD60FB639D511AC0400B0D068B71E0564C749@corpmx14.us.dg.com> <3E2309FE.F66B0B9E@bstormnetworks.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1042494579 19463 128.32.153.211 (13 Jan 2003 21:49:39 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 13 Jan 2003 21:49:39 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott G. Kelly wrote: >There are issues of backward compatibility: there are (recently) fielded >devices which contain hardware support for aes-cbc and not aes-ctr. Are >we to require vendors to forklift these devices? Ok, I think there may be some confusion here. I hope the confusion is not my fault. I was not advocating any changes or any forklift upgrades. If I understand correctly, David Black asked for addition of new AES-CBC-encryption ciphersuites. My question was why we need additional AES-CBC-encryption ciphersuites; what's wrong with AES-CTR, or with the status quo? In other words, I'd like to understand what's wrong with the status quo before making changes. Also, please note that there is a difference between AES-CBC-encryption and AES-CBC-MAC (or its variants, like AES-XCBC MAC). They're orthogonal. Modes like AES-CTR or AES-CBC-encryption are for confidentiality. Modes like SHA1-HMAC or AES-CBC-MAC or AES-XCBC are for authentication+integrity. From owner-ipsec Mon Jan 13 18:26:40 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20406 Mon, 13 Jan 2003 18:23:25 -0500 (EST) Message-Id: <200301132325.h0DNPgjt001171@thunk.east.sun.com> From: Bill Sommerfeld To: daw@mozart.cs.berkeley.edu (David Wagner) cc: ipsec@lists.tislabs.com Subject: Re: AES cipher suites In-Reply-To: Your message of "13 Jan 2003 21:49:39 GMT." Reply-to: sommerfeld@east.sun.com Date: Mon, 13 Jan 2003 18:25:42 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [public reply] > In other words, I'd like to understand what's wrong with the status > quo before making changes. The "status quo" of running code and shipping product includes AES-CBC. - Bill From owner-ipsec Mon Jan 13 20:19:50 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20735 Mon, 13 Jan 2003 20:16:23 -0500 (EST) Message-ID: <3E236464.FDCE1C2C@bstormnetworks.com> Date: Mon, 13 Jan 2003 17:14:12 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Wagner CC: ipsec@lists.tislabs.com Subject: Re: AES cipher suites References: <277DD60FB639D511AC0400B0D068B71E0564C749@corpmx14.us.dg.com> <3E2309FE.F66B0B9E@bstormnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments below... David Wagner wrote: > > Scott G. Kelly wrote: > >There are issues of backward compatibility: there are (recently) fielded > >devices which contain hardware support for aes-cbc and not aes-ctr. Are > >we to require vendors to forklift these devices? > > Ok, I think there may be some confusion here. I hope the confusion is > not my fault. > > I was not advocating any changes or any forklift upgrades. > If I understand correctly, David Black asked for addition of new > AES-CBC-encryption ciphersuites. My question was why we need additional > AES-CBC-encryption ciphersuites; what's wrong with AES-CTR, or with the > status quo? In other words, I'd like to understand what's wrong with > the status quo before making changes. > > Also, please note that there is a difference between AES-CBC-encryption > and AES-CBC-MAC (or its variants, like AES-XCBC MAC). They're > orthogonal. Modes like AES-CTR or AES-CBC-encryption are for > confidentiality. Modes like SHA1-HMAC or AES-CBC-MAC or AES-XCBC are > for authentication+integrity. Well, maybe I'm misunderstanding, but I have the impression that the general thrust of this thread has been to *replace* AES-CBC with AES-CTR. There is currently an AES-CBC document in the IESG's doc queue that is a product of this wg, and based on that doc, hardware has been released and products have been shipped. That means that if we toss it out now, lots of time and money has been wasted. I hope that I really have misunderstood. Scott From owner-ipsec Mon Jan 13 21:01:39 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20887 Mon, 13 Jan 2003 20:59:07 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C75C@corpmx14.us.dg.com> To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: More AES suites (was: draft-ietf-ipsec-ikev2-04.txt) Date: Mon, 13 Jan 2003 21:00:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, > > For ips's usage, AES-CTR does not need a smaller D-H > > group, and going to a larger one seems reasonable given the > > motivation to transfer large amounts of data at high speed. While > > I could live with suites that differed only in the D-H group, I'm > > not going to propose them, so here are a couple of strawmen to get > > started: > > > > 1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1; ESP. > > 2048-bit Diffie-Hellman; 128-bit AES CTR; HMAC-SHA1; ESP. > > There are separate suites for IKE SAs and for ESP SAs. The ESP SAs are the > ones likely to be performance sensitive. What if the ESP SAs were: > > 168-bit 3DES CBC; HMAC-SHA1; ESP w/o extended sequence numbers (for > backwards compatibility) > 128-bit AES CBC; HMAC-SHA1; ESP w/extended sequence numbers > 128-bit AES CTR; HMAC-SHA1; ESP w/extended sequence numbers That's a good start, but leaves the issue mentioned by several people of what to do for AES CBC MAC w/XCBC. That's interesting as an alternative to an unlikely HMAC-SHA1 disastrous compromise and for higher speed. The following seems to be a good addition for speed: 128-bit AES CTR; AES CBC MAC w/XCBC; ESP w/extended sequence numbers and someone wanting to build only one and a fraction AES operating modes will probably find this one attractive: 128-bit AES CBC; AES CBC MAC w/XCBC; ESP w/extended sequence numbers as the AES CBC functional block can be built once and used twice. If one believes that the previous 3 are needed, then this fourth one makes sense. OTOH, once "AES CTR; AES CBC MAC w/XCBC ..." exists, it's not clear what the purpose of "AES CTR; HMAC-SHA1 ..." is, as it's slower, and unlikely to help if something goes wrong with the former mode, as the CBC MAC seems to be rather unlikely to get disastrously compromised ... which sounds like a great "famous last words" quote, so perhaps the right thing to do is not over analyze/optimize this and just put in all 4 AES modes. [... rest snipped ...] I have no problem with going to extended sequence numbers for all usage of AES. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec Mon Jan 13 21:02:13 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20893 Mon, 13 Jan 2003 21:01:08 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: AES cipher suites Date: 14 Jan 2003 01:39:04 GMT Organization: University of California, Berkeley Lines: 8 Distribution: isaac Message-ID: References: <277DD60FB639D511AC0400B0D068B71E0564C749@corpmx14.us.dg.com> <3E2309FE.F66B0B9E@bstormnetworks.com> <3E236464.FDCE1C2C@bstormnetworks.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1042508344 22058 128.32.153.211 (14 Jan 2003 01:39:04 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 14 Jan 2003 01:39:04 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott G. Kelly wrote: >Well, maybe I'm misunderstanding, but I have the impression that the >general thrust of this thread has been to *replace* AES-CBC with >AES-CTR. That was never my suggestion; at least, I would not suggest any such change to the standard. If someone else wants to propose it, I leave it to them to justify such a change to the standard. From owner-ipsec Mon Jan 13 23:06:53 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21438 Mon, 13 Jan 2003 23:03:28 -0500 (EST) Message-ID: <3E238C71.2050407@bbn.com> Date: Mon, 13 Jan 2003 23:05:05 -0500 From: David Waitzman User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.2.1) Gecko/20030106 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Scott G. Kelly" CC: ipsec@lists.tislabs.com Subject: Re: AES cipher suites References: <277DD60FB639D511AC0400B0D068B71E0564C749@corpmx14.us.dg.com> <3E2309FE.F66B0B9E@bstormnetworks.com> <3E236464.FDCE1C2C@bstormnetworks.com> In-Reply-To: <3E236464.FDCE1C2C@bstormnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott G. Kelly wrote: > Well, maybe I'm misunderstanding, but I have the impression that the > general thrust of this thread has been to *replace* AES-CBC with > AES-CTR. There is currently an AES-CBC document in the IESG's doc queue > that is a product of this wg, and based on that doc, hardware has been > released and products have been shipped. That means that if we toss it > out now, lots of time and money has been wasted. I hope that I really > have misunderstood. I think you misunderstand the IETF standardization process. I thought the way it worked is that if you ship a product based upon just an I-D you are taking a big gamble. Even after DRAFT Standard things could change if there's a big problem. This should be a motivation for IETF working groups to test interoperability and standardize *quickly*. Yes, the RFC standardization process has long hold times in it, to give time for feedback. But this should level the playing field. -david From owner-ipsec Tue Jan 14 06:13:58 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22777 Tue, 14 Jan 2003 06:08:16 -0500 (EST) Message-Id: <200301141107.h0EB7kof073299@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jayant Shukla" cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: peer address protection and NAT Traversal In-reply-to: Your message of Mon, 13 Jan 2003 09:34:53 PST. <000001c2bb2a$151a7070$5803a8c0@trlhpc1> Date: Tue, 14 Jan 2003 12:07:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > => we have to specify in details the peer address management, and not only > for NAT traversal but also for mobility and multi-homing. This is of interest to us as we are currently implementing multi-homing and active load balancing in our VPNs. What work has been done on it so far? Any IDs or RFCs? => there are many messages in this list and some documents like my I-D about MIPv6 and IPsec (draft-dupont-ipsec-mipv6-01.txt, I am looking for comments and co-authors for a new version). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec Tue Jan 14 09:05:21 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23637 Tue, 14 Jan 2003 08:59:27 -0500 (EST) Message-Id: <5.1.0.14.0.20030110230838.045dd440@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 Jan 2003 10:20:33 -0500 To: Hugo Krawczyk From: David Jablon Subject: Re: A proposal Cc: IPsec WG In-Reply-To: References: <5.1.0.14.0.20030102152710.04879d20@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, You've raised a good point about the use of weaker alternative prf functions in conjunction with my proposal. But the remaining analysis is either incorrect or misdirected. All of the other "attacks" or potential weaknesses that you describe are either directly applicable to IKEv2 or SLA, or do not exist with any of these proposals, and they certainly do *not* result from my proposal to merely include optional added key material in KEYMAT. Furthermore, the one valid point directed at my proposal is *only* valid when one implements prf with a function that is significantly weaker than HMAC, which is currently the only specifically described instantiation in the IKEv2 draft. If the intent is indeed for IKEv2 to permit use of prf's based on reversible functions, such as the cipher-based functions you describe, then something else (like the alternative that you describe) would clearly be needed to fix the problem, and it may be a good idea in any case. If the intent is to not permit cipher-based prf's, and perhaps in any case, it may be a good idea to clarify the required properties of "prf" in the draft. While many of your comments appear to unfairly criticise the proposal, I do note that you gracously ignored the extraneous third argument to prf, a typographical error on my part. I also note that you have not disputed the main point I was trying to make, that the act of *properly* blending key material into the KEYMAT computation does not weaken the security of IKEv2 [+SLA, ...], all else being equal. I elaborate on these concerns in the response below. -- David >On Thu, 2 Jan 2003, David Jablon wrote: >> Here's what seems to me to be an obviously simple and secure extension. At 08:40 AM 1/6/03 +0200, Hugo Krawczyk wrote: >Not so simple (due to the need to import a key from the underlying >authentication method to the tunneling protocol). [David writes:] For the record, my proposal, as a refinement of SLA or similar proposals, does not introduce any new *need* to import a key from an underlying authentication method. It simply provides a mechanism to make use of a suitable imported key when desired and available. [David wrote:] >> Proposal >> >> From my reading of www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-03.txt, >> optional added key material from supplementary authentication >> methods could be bound to the IKEv2 server-only authenticated key >> using: >> >> KEYMAT = prf+(SK_d, [added_key_material] | Ni | Nr, g^ir) >> >> This would extend and replace the existing specification of: >> >> KEYMAT = prf+(SK_d, Ni | Nr, g^ir) >... [Hugo wrote:] >An obvious weakness of resolving the mitm problem via the key derivation >(rather than by adding an explicit "compund authentication") is that you end >the key exchange protocol without an explicit authentication that binds the >two protocols. But this by itself can be considered as a DoS issue and not a >security bug. I see no such "obvious weakness" in resolving the problem via a proper KEYMAT derivation, either from a security or DoS perspective. In a general case, one may legitimately argue that explicitly authenticating a secondary key or credential in the tunnel is not the same as another hypothetical compound tunneled authentication method that binds the keys together and then explicitly authenticates the result. That's a fine academic point, on which I generally agree. But every authentication protocol that can provide keying material either provides (or could provide) explicit authentication of that material, or the legacy credential from which it has been derived. And the intent to encompass tunneled protocols "as is" implies that explicit authentication is typically included. In this case, when explicit authentication is included, and the tunnel is broken, SK_d is compromised by the MITM and direct binding to SK_d becomes irrelevant. If, on the other hand, in your use of "compound authentication" you refer to dual private key based authentication, that hardly seems a reasonable criticism of how my proposal improves upon or diminishes the prior IKEv2 + SLA (or similar) proposal. In my proposal, derived keys are still just as authenticated (or not) by the IKEv2 server authentication steps as they would be without the added keying material. To be absolutely clear, I think it's best to compare apples-to-apples. Consider two cases of using server-only authentication to tunnel a second authentication method based on legacy client credentials. Presume that the tunnelled method exports key material. Case (1) discards this material, while case (2) blends it, properly, into the computation of KEYMAT. Case (2) should be at least as secure as (1). >However, your specific proposal introduces weaknesses beyond the DoS >scenario. It is open to "known-key attacks" by the Man-in-the-mittle >attacking the tunneled authentication. My proposal was made based on prf using HMAC -- the only explicitly specified prf. Your concern is based on prf being instantiated using a formerly unspecified method that might be possble in a future extension to the draft, where HMAC is replaced with a weaker construction. I don't dispute the legitimacy of your concern, but it is limited to such cases. >A known key attack is one in which the disclosure of one of the keys >(e.g the authentication key) compromises another key (e.g the encryption >key). Resistance to known key attacks is an important requirement of a >well-designed key exchange protocol, and in particular of any good key >derivation technique associated to the key exchange protocol. > >[...] > >It can be shown (and I sketch this below for those interested in the >details) that an attacker that knows SK_d (which is the case of the mitm >attacker against which your proposal tries to protect) can mount known-key >attacks even WITHOUT knowing the "added-key-material" coming from the >underlying authentication method. >This is NOT possible in the regular ikev2 scenario where only the legitimate >parties to the exchange know SK_d. For the record, the disclosure of SK_d is not the result of my proposal. It is the result of MITM attack due to failed server-only authentication, a presumed pre-existing issue with SLA. >The specific attacks that I can see are not the most practical, yet they >are sufficient to show that one cannot claim (or prove) the compound key >derivation that you propose to be secure in a mathematical sense. The proper addition of added_key_material into the computation of KEYMAT does not cause the disclosure of an otherwise undisclosable KEYMAT. But, you raise an excellent point about proper constructions, especially since different implementations of "prf" (as specified) may have very different properties: >A secure suggestion is to do a second prf+, similar to the one defined >in ikev2, keyd with key "added-key-material", and then XOR the results of the >two prf+ computations. ... I agree that XOR is a better way to bind the keying material, especially when there is a concern that alternate constructions for prf are allowed, such as the weaker cipher-based constructions that you describe (below). I had presumed the use of the specified HMAC, or something at least as strong, due to its extensive analysis and broad acceptance as a key derivation function. >... This however ASSUMES that the key "added-key-material" >was NOT used in any way (not even to key other cryptographic algorithms) in >the underlying authentication protocol. ... It's not clear to me what you mean by that statement. Any added key material will surely be derived in some way from the credentials used in the underlying protocol. Insuring the security and proper use of the exported/imported key is clearly the dual responsibility of both protocols, as I noted in an earlier post. >PS: for those interested to see how a known-key attack could work against the >above proposal, this can be exemplified as follows. It is a bit involved, >somewhat artificial and it requires patience to be understood, I will only >sketch the idea. Imagine a case in which the keys derived (KEYMAT) in >sla/ikev2 are later used by the responder (server) to send confidential >information to the iniitator (client), without the latter sending information >back. This information could be a confidential real-time stream of data or >whatever. In this case, the initiator will never complete its explicit >authentication in the protocol since it will never show to the responder that >it knows KEYMAT. In particular if this client is the mitm against which we >want to protect, this attacker will never have to show that it knows the keys >derived in KEYMAT. So far this may be considered only as a DoS attack on the >server (which is sending information to a fake client, but one that supposedly >cannot decrypt the information). Again, that sketch of a DoS issue, however (in)significant, seems to be based on a false presumption that there is no explicit authentication within the "tunnel". >However, this is not the end of the story. Imagine that the attacker >records all this information and eventually learns the authentication keys >used in the session. (This can be the case if a month later the >authentication key shows up in some logs from that session; note that it >may make sense to log, even wthout secrecy, authentication keys from >expired sessions). Now our mitm attacker can also learn the encryption >keys! How? If we imagine that the prf is a block cipher (eg AES-128 or > AES-256) then if you look at the prf+ derivation in ikev2 you'll see >that the attacker THAT KNOWS SK_d can compute all keys derived via prf+ >if it happens to know the output of a single prf+ stage (Ti), and > provided that the input to each prf+ stage is no longer than the cipher >block. (All of this is possible with 128-bit blocks and even more >plaussible with 256-bit blocks when no g^ir is involved, in particular >when running phase 1). The known-key attack that you've sketched is only relevant for the case where HMAC is replaced with an alternative weaker construction, such as AES-nnn. As the only prf explicity specified in IKEv2 is HMAC, I had presumed that any suitable key derivation function would have comparable properties. If the draft is intended to permit the use of weaker prf constructions, including those that are based on reversible functions, perhaps it should more clearly specify the required (or non-required) properties of a suitable prf. To be clear on this point: In light of your comments, the IKEv2 draft seems well-defined, given the generally accepted definition of a pseudo-random function. However something stronger than a simple cipher-based prf may be desired, and in any case, it can't hurt to add a reference to more clearly define the intent of "prf" to prevent others from making false assumptions. >Moreover, it is only the fortitous definition in ikev2 that specifies >that encryption keys are derived from the first octets of the output of prf+, >and authentication keys from the last octets, that prevents an even easier >attack. Indeed, had the definition been the other way (first derive the the >authentication key, then the encryption key ) an attack as above could have >been mounted with ANY prf (not just block ciphers as described above) >including HMAC. What I think you're thinking of doesn't work against HMAC. But I see no real point in exploring a non-disclosed "attack as above" that might have been mounted against some other non-specified proposal. >NONE OF THESE ATTACKS or weaknesses ARE APPLICABLE to (or be blamed on) >IKEv2. They are possible because of the way the key from the underlying >authentication protocol, added_key_material, is involved in the proposed >key derivation. I believe I have shown that, for other than the "prf" issue, the concerns that you've raised are either not a concern at all, not a concern with my proposal, or are best directed elsewhere. -- David From owner-ipsec Tue Jan 14 10:42:55 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24618 Tue, 14 Jan 2003 10:40:46 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15908.15852.425000.151307@gargle.gargle.HOWL> Date: Tue, 14 Jan 2003 11:42:20 -0500 From: Paul Koning To: Black_David@emc.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: More AES suites (was: draft-ietf-ipsec-ikev2-04.txt) References: <277DD60FB639D511AC0400B0D068B71E0564C75C@corpmx14.us.dg.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I see two goals: 1. provide AES based suites that allow for high performance 2. provide AES based suites that match what early adopters have done in current chips and yes, (2) is a valid goal; references to the standards process don't change that. I think this is easy to do. Existing crypto chips typically support CBC as the encryption mode, and HMAC as the integrity mode. So to support goal (2) you need modes like that, which means AES-CBC with HMAC-SHA1. For goal (1) you're moving outside the range of what's in early chips, and you get AES-CTR with AES-XCBC-MAC. (Also, possibly, AES-CTR with HMAC-SHA1 if someone wants that; there have been some pretty fast SHA1 implementations -- fast enough to compete with AES-XCBC-MAC?) My point of looking at it this way is to rule out combinations like AES-CBC with AES-XCBC-MAC. That fits neither goal, so I don't see a reason for having it. paul From owner-ipsec Tue Jan 14 11:29:07 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24812 Tue, 14 Jan 2003 11:28:00 -0500 (EST) Message-ID: <3E243A25.FE2F6028@bstormnetworks.com> Date: Tue, 14 Jan 2003 08:26:13 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Waitzman CC: ipsec@lists.tislabs.com Subject: Re: AES cipher suites References: <277DD60FB639D511AC0400B0D068B71E0564C749@corpmx14.us.dg.com> <3E2309FE.F66B0B9E@bstormnetworks.com> <3E236464.FDCE1C2C@bstormnetworks.com> <3E238C71.2050407@bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi David, Under some circumstances, I would agree with you regarding the risks of deploying products based on ID's. And I should make clear that I am not opposed to advancing AES-CTR, as it is faster for some applications. However, I think your comment misses some important points. Firstly, nothing has been found to be *wrong* with AES-CBC. Rather, it has been pointed out that CTR mode can be parallelized in hardware, making it faster at very high data rates. Secondly, while an idealized scenario might entail standardization followed by deployment, strictly in that order, the reality is that vendors must invest resources in order to move this process forward, and they are unlikely to do so if there is high risk of resets everytime the next attractive algorithm shows up. And in this case (cryptographic algorithm, as opposed to protocol, standardization), there are hardware vendors to consider. They require significant lead times to lay out products which the market begins clamoring for at the first hint of the IETF. Like it or not, we cannot ignore these factors. Given the market realities, we must be responsible in how we go about creating standards. Creating documents with MUSTs in them, advancing them to the end of the wg process, and creating IANA registry numbers, when taken together, give the impression that we are on the horse at midstream. Suddenly changing direction because another algorithm looks attractive ignores these factors. Again, I am not advocating that we not advance ctr mode - it is not necessary to dump one for the other - I am saying that we should add both. Scott David Waitzman wrote: > > Scott G. Kelly wrote: > > Well, maybe I'm misunderstanding, but I have the impression that the > > general thrust of this thread has been to *replace* AES-CBC with > > AES-CTR. There is currently an AES-CBC document in the IESG's doc queue > > that is a product of this wg, and based on that doc, hardware has been > > released and products have been shipped. That means that if we toss it > > out now, lots of time and money has been wasted. I hope that I really > > have misunderstood. > > I think you misunderstand the IETF standardization process. > I thought the way it worked is that if you ship a product based upon just > an I-D you are taking a big gamble. Even after DRAFT Standard things could > change if there's a big problem. > > This should be a motivation for IETF working groups to test > interoperability and standardize *quickly*. Yes, the RFC standardization > process has long hold times in it, to give time for feedback. But this > should level the playing field. > > -david From owner-ipsec Tue Jan 14 14:52:01 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25277 Tue, 14 Jan 2003 14:48:55 -0500 (EST) Message-Id: <200301141950.h0EJoRjt006691@thunk.east.sun.com> From: Bill Sommerfeld To: Charlie_Kaufman@notesdev.ibm.com cc: Russ Housley , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, Paul Koning Subject: Re: Counter Mode: Proposed Way Forward In-Reply-To: Your message of "Sat, 11 Jan 2003 22:59:46 EST." Reply-to: sommerfeld@east.sun.com Date: Tue, 14 Jan 2003 14:50:27 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, I'll speak up in favor of Paul's proposal because it better handles separation of key management and AH/ESP. If you use the IKE nonce, folks wishing to use counter-mode-based transforms with other key management protocols will need to do something special since the other KM protocols may not have an exact equivalent. - Bill From owner-ipsec Tue Jan 14 16:49:44 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25512 Tue, 14 Jan 2003 16:45:57 -0500 (EST) Message-ID: <51C7002B020CD411824E009027C469F70107D353@cldxch01.hifn.com> From: Bob Doud To: "'Paul Koning'" Cc: Charlie_Kaufman@notesdev.ibm.com, Black_David@emc.com, ipsec@lists.tislabs.com Subject: RE: More AES suites (was: draft-ietf-ipsec-ikev2-04.txt) Date: Tue, 14 Jan 2003 13:47:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > For goal (1) you're moving outside the range of what's in early chips, > and you get AES-CTR with AES-XCBC-MAC. (Also, possibly, AES-CTR with > HMAC-SHA1 if someone wants that; there have been some pretty fast SHA1 > implementations -- fast enough to compete with AES-XCBC-MAC?) > For single-core designs (as opposed to parallel AES engine architectures), the performance of SHA-1 is very close to that of AES-XCBC-MAC. Typically SHA-1 is a bit slower for smaller packet sizes and faster for medium to large packet sizes. Of course, different vendor implementations may have somewhat different results. --Bob From owner-ipsec Wed Jan 15 09:15:09 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28904 Wed, 15 Jan 2003 09:08:20 -0500 (EST) Message-Id: <200301151258.HAA24361@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-udp-encaps-06.txt Date: Wed, 15 Jan 2003 07:58:19 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen et al. Filename : draft-ietf-ipsec-udp-encaps-06.txt Pages : 0 Date : 2003-1-14 This draft defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-udp-encaps-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-14151013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14151013.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Jan 15 20:03:34 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00568 Wed, 15 Jan 2003 20:00:14 -0500 (EST) Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Message-ID: <3E25CC1E.7670DA45@bell-labs.com> Date: Wed, 15 Jan 2003 16:01:18 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com Original-CC: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: AES cipher suites References: <277DD60FB639D511AC0400B0D068B71E0564C723@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com wrote: > 1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1; ESP. > 2048-bit Diffie-Hellman; 128-bit AES CTR; HMAC-SHA1; ESP. Fine... > Q: Should AES suites with AES-CBC MAC + XCBC be defined as a > backstop against the unlikely event that a disastrous > attack on HMAC-SHA1 turns up? IMHO - yes. > AES-CBC MAC + XCBC is the backup MAC algorithm for IP Storage > ("SHOULD implement" in the ips drafts). From owner-ipsec Thu Jan 16 09:22:22 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03116 Thu, 16 Jan 2003 09:14:52 -0500 (EST) Date: Thu, 16 Jan 2003 19:34:05 +0900 Message-ID: From: Mitsuru KANDA / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?= To: ipsec@lists.tislabs.com Subject: About scheduling the IPsec WG meeting in SF User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Chairs, About the IPsec WG meeting in SF, I would like to avoid scheduling conflict with IPv6 WG. As you know, IPsec is mandatory in IPv6 specification. So I would like to attend both meetings. Regards, ---------------------------------------- Mitsuru KANDA (mk@karaba.org) Toshiba Reseach & Development Center Communication Platform Laboratory (mk@isl.rdc.toshiba.co.jp) USAGI Project (mk@linux-ipv6.org) From owner-ipsec Thu Jan 16 13:19:18 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03950 Thu, 16 Jan 2003 13:17:13 -0500 (EST) Message-Id: <200301161736.MAA17279@ietf.org> To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: The AES Cipher Algorithms and Their Use With IPsec to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 16 Jan 2003 12:36:40 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider The AES Cipher Algorithms and Their Use With IPsec as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-1-30. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-04.txt From owner-ipsec Thu Jan 16 13:19:18 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03944 Thu, 16 Jan 2003 13:16:08 -0500 (EST) Message-Id: <200301161554.KAA14448@ietf.org> To: IETF-Announce:;;;@tislabs.com; Cc: RFC Editor , Internet Architecture Board , ipsec@lists.tislabs.com From: The IESG Subject: Protocol Action: More MODP Diffie-Hellman groups for IKE to Proposed Standard Date: Thu, 16 Jan 2003 10:54:33 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved "More MODP Diffie-Hellman groups for IKE" as a Proposed Standard. The IESG contact persons are Steve Bellovin and Jeff Schiller. Technical Summary This document defines new MODP groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel as described in [RFC-2412]. Working Group Summary There was working group consensus on this document. Protocol Quality These documents were reviewed by Jeff Schiller. From owner-ipsec Fri Jan 17 13:14:31 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07851 Fri, 17 Jan 2003 13:07:28 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: draft-ietf-ipsec-ikev2-04.txt To: Henry Spencer Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Thu, 16 Jan 2003 20:48:09 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/17/2003 01:09:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On Sat, 11 Jan 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > > Why 2-key 3DES? Why not 3-key? ... > > > > Only because it was my understanding that 2 key 3DES was what was most > > commonly deployed... > > Uh, what makes you think that? IPsec 3DES, as specified by RFC 2451, is > 3-key and always has been. > > Henry Spencer > henry@spsystems.net My mistake; I'll fix it. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Sat Jan 18 09:44:35 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10265 Sat, 18 Jan 2003 09:39:44 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200212310220.gBV2KSkG032681@mail2.trpz.com> Subject: Re: Secure legacy authentication for IKEv2 To: Dan Harkins Cc: Hugo Krawczyk , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Fri, 17 Jan 2003 23:04:15 -0500 X-MIMETrack: Serialize by Router on Aretha/Iris(Build V601_01162003NP|January 16, 2003) at 01/18/2003 09:50:44 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I see a number of problems with the SLA proposal posted as an I-D, and have a counterproposal. The SLA proposal says that message 1 is unmodified and Message 2 contains the responder's AUTH payload, moved from message 4. There are a number of problems with this. Message 3 contains the list of roots trusted by the initiator as well as the desired responder identity (the Me Tarzan, You Jane variation). The responder uses those values to decide what identity to respond with. We would either have to disallow that flexibility when SLA was used or move those values to message 1. If we move them to message 1, we lose the protection from passive eavesdroppers. Further, a responder must know whether it is going to use legacy authentication or regular authentication after receiving message 1, which has few clues and therefore a responder could not accept either type. This could be fixed by putting a capability indicator in message 1. In this protocol, the initiator decides what form of legacy authentication it wants to do and the responder can accept or reject that choice. This is the reverse of what happens with EAP, where the responder decides what form of authentication it expects sometimes based on the claimed user identity. This means that if some users of a particular piece of software use challenge/response tokens and some use username/password, it would be up to the user to communicate to the client software what sort of capability he has rather than waiting for the responder to prompt for something. All of these problems can be worked around (but we would have to decide how before we would have a spec), and the limitations may be acceptable, but I believe they are unnecessary. I believe a smaller modification to the protocol avoids these problems. The changes I would propose (derived closely from Stephane Beaulieu's proposal) are to leave the first two messages alone, replace AUTH and CERT in message 3 with an EAP exchange in messages 4 & 5 (and if more needed, 6 & 7, etc), and deferring the completion of the child SA establishment from message 4 to the last message. Or more precisely: No change to message 1. No change to message 2. Message 3: AUTH and CERT payloads are removed - perhaps an optional indication of legacy auth methods supported. Message 4: SAr2, TSi, TSr removed; EAP payload added Message 5: EAP payload Message 6: SAr2, TSi, TSr (where extra pairs of messages can be inserted between 5 and 6 if more than one EAP round trip is required). If a legacy auth method that produces a shared key is used, the next to last message should have an AUTH payload generated using that key. The purpose is to protect against man-in-the-middle attacks. Defense is only possible of the legacy auth method generates keying material, and using that key for creating an AUTH payload is simpler than other proposals that mix that keying material into the keys for the SAs. Note that a (perhaps controversial) aspect of this proposal is that the initiator identity remains in message 2. This has the advantages that it minimizes changes to the protocol and may avoid a round trip in the EAP protocol because the responder doesn't have to separately prompt for username. It has the disadvantage that it presumes that with all legacy authentication methods there is some expression of the user's identity that can be prompted for in a uniform way. I can't think of any case where that wouldn't be true. What do people think? --Charlie Typical protocol run for the legacy auth case where we're just prompting for a username and password would be: HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr HDR*, IDi, [IDr,] SAi2, TSi, TSr} --> <-- HDR*, IDr, [CERT,] AUTH, EAP(pwd) HDR*, EAP(pwd) --> <-- HDR*, SAr2, TSi, TSr} From owner-ipsec Sun Jan 19 12:38:00 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13162 Sun, 19 Jan 2003 12:27:39 -0500 (EST) Message-Id: <200301191729.h0JHTmof096328@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: IKEv2 NAT-DETECTION-*-IP Date: Sun, 19 Jan 2003 18:29:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP were loosely copied from draft-ietf-ipsec-nat-t-ike-05.txt but not in a really sound way: - these notifications work only when the digest of the IKE-SA is negociated, so they cannot be used in the first or second messages of an IKE_SA_INIT exchange but 5.10 specifies they MAY be added to any messages... In draft-ietf-ipsec-nat-t-ike-05.txt they are in the second and third messages of main mode when the digest is negociated but the payload of messages is not protected. - NAT traversal can need the original addresses (TCP in transport mode for instance, because of the inclusion of the original addresses in the TCP checksum). This is not in IKEv2. So my proposal is to put full addresses and ports in the NAT-DETECTION-* notifications and to rely on the standard protection (they should not be sent unprotected and ignored by the receiver in such a case). We need a bit more, i.e., an usage guideline and two notifications to require and to reject them. I propose: - a new status to require them. It should be used by the responder in the second message and its meaning is that the initiator should include NAT-DETECTION-*-IP notification in the third message. - a new error to reject them when a NAT is detected and NAT traversal is not enabled. - a simple usage guideline: when a request includes some NAT-DETECTION notifications, the response should includes the same notifications. (note: this is the way to negociate NAT detection for the initiator). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec Sun Jan 19 12:48:24 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13247 Sun, 19 Jan 2003 12:46:43 -0500 (EST) Message-Id: <200301191748.h0JHm6of096360@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: IKEv2 proxy mode Date: Sun, 19 Jan 2003 18:48:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IKEv1 supports a proxy mode which is (with a terrible wording) described in section 5.5 "Phase 2 - Quick Mode" by: The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. I propose for IKEv2 section 4.11 "Address and Port Agility": If IKE is acting as a client negotiator on behalf of another party (so called the "proxy mode"), the transport mode MUST be specified (by an USE-TRANSPORT-MODE notification) and the TSi gives the address of the party which will override the source peer address in IPsec SAs. Proper local authorization policy will dictate whether the proposals are acceptable for the traffic selectors specified. Note: we should specify the error for failed TS negociation (and not only for this case). If we need a rationale, the proxy mode can be used to when the initiator has several addresses and wants to negociate IPsec SAs for different addresses from the same IKE SA (we can find many reasons to do that). I don't believe the tunnel mode case should be supported (too complex for a very low benefit, a peer address updating mechanism is better). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec Sun Jan 19 13:10:43 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13369 Sun, 19 Jan 2003 13:08:52 -0500 (EST) Date: Sun, 19 Jan 2003 10:09:32 -0800 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Dan Harkins , Hugo Krawczyk , Derrell Piper , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com To: Charlie_Kaufman@notesdev.ibm.com From: Derrell Piper In-Reply-To: Message-Id: <28CAA5E1-2BD9-11D7-AAEC-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Friday, January 17, 2003, at 08:04 PM, Charlie_Kaufman@notesdev.ibm.com wrote: > The changes I would propose (derived closely from Stephane Beaulieu's > proposal) > are to leave the first two messages alone, replace AUTH and CERT in > message > 3 with an EAP exchange in messages 4 & 5 (and if more needed, 6 & 7, > etc), > and deferring the completion of the child SA establishment from > message 4 > to the last message. Or more precisely: > > No change to message 1. > No change to message 2. > Message 3: AUTH and CERT payloads are removed - perhaps an optional > indication of legacy auth methods supported. > Message 4: SAr2, TSi, TSr removed; EAP payload added > Message 5: EAP payload > Message 6: SAr2, TSi, TSr > > (where extra pairs of messages can be inserted between 5 and 6 if more > than one EAP round trip is required). > > If a legacy auth method that produces a shared key is used, the next > to last message should have an AUTH payload generated using that key. > The purpose is to protect against man-in-the-middle attacks. Defense > is only possible of the legacy auth method generates keying material, > and using that key for creating an AUTH payload is simpler than other > proposals that mix that keying material into the keys for the SAs. > > Note that a (perhaps controversial) aspect of this proposal is that > the initiator identity remains in message 2. This has the advantages > that it minimizes changes to the protocol and may avoid a round trip > in the EAP protocol because the responder doesn't have to separately > prompt for username. Is this a valid optimization, i.e., is it that most EAP implementations will be able to avoid an EAP protocol exchange to prompt for user identity if the user identity is available out-of-band (w.r.t. EAP)? RFC2284 says that that exchange is optional, but it doesn't say what's BCP (and I have no idea). It might be worth pointing out that IKEv2 implementations will likely be calling out to existing EAP implementations and therefore need to adhere to whatever existing EAP API's currently allow. More below... > It has the disadvantage that it presumes that > with all legacy authentication methods there is some expression of > the user's identity that can be prompted for in a uniform way. I > can't think of any case where that wouldn't be true. > > What do people think? > > --Charlie > > Typical protocol run for the legacy auth case where we're just > prompting for a username and password would be: > > HDR, SAi1, KEi, Ni --> > <-- HDR, SAr1, KEr, Nr > HDR*, IDi, [IDr,] > SAi2, TSi, TSr} --> > <-- HDR*, IDr, [CERT,] AUTH, EAP(pwd) > HDR*, EAP(pwd) --> > <-- HDR*, SAr2, TSi, TSr} [You have some extra "}"'s here which I assume are transcription errors...] vs. SLA comments: In SLA, the client didn't have to reveal his identity until after the gateway proved its identity. Here, the client sends his identity in message 3 before the gateway proves its identity in message 4. This proposal allows any active attacker to observe client identities by simply replying with message 2. EAP integration comments: Note: I'm convinced that using EAP is a good idea. My comments aren't intended to argue against it... 1) Are existing EAP implementations prepared to associate an externally derived user identity with an EAP exchange? If so, the assumption that the EAP(Request/Identity) and EAP(Reply/Identity) round can be optimized out is valid. If not, it probably ought to begin in message 2. Which bring us to the second point... 2) How does a gateway know its doing SLA? SLA proposed a separate exchange type for this. Since this does not resemble "normal" IKEv2, I think a separate exchange type is justified. It's also good for the responder, since he can tag the larval exchange as being SLA. And it also makes the question about the EAP identity prompt round moot, since the gateway could respond with an EAP(request/identity) payload in message 2. 3) You're missing the final EAP(Success) or EAP(Failure) payload, which needs to be returned by the gateway in its final response (to complete the EAP protocol). That would be message 6, as you've drawn it. All in all, there's not that much difference from what I wrote on 12/21. HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, EAP(Request/Identity), AUTH HDR*, SAi2, TSi, TSr, EAP(Reply/Identity) --> <-- HDR* EAP(n) HDR*, EAP(n) --> <-- HDR*, EAP(SUCCESS), SAr2, TSi, TSr ...or... <-- HDR*, EAP(FAILURE) To summarize the differences, some of which are admittedly trivial: 1) Do we need to allow for the EAP identity exchange? If so, where does it occur? 2) Do we want to require or allow IKE ID payloads in addition to the EAP identity? 3) Addition of optional CERT payload returned by the gateway along with its AUTH payload. 4) What is the order of the EAP payloads relative to other payloads? 5) AUTH payload in message 2 or message 4? --> implication for client identity protection 6) Is this a separate exchange type or not? I still think there's value to having the gateway prove itself *before* the client has to reveal his identity, but that's just my opinion. Note that the change that Hugo proposed to move the identity binding MAC into the signature definition is necessary if the AUTH payload happens in message 2, but not if it happens in message 4 with explicit IKE ID payloads. Derrell From owner-ipsec Sun Jan 19 16:43:17 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13758 Sun, 19 Jan 2003 16:39:17 -0500 (EST) Date: Sun, 19 Jan 2003 16:41:56 -0500 From: Ran Canetti Message-Id: <200301192141.QAA41544@ornavella.watson.ibm.com> To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: cookie definition in IKEv2-04 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, Regarding section 4.6 (cookies): I'm glad that you defined the cookie as a separate payload. It's much better this way. One remark though. The text says: > A good way to do this is to set the responder cookie to be: > > Cookie = | Hash(IPi | SPIi | ) > > where is a randomly generated secret known only to the > responder and periodically changed. The goal of the second field in the cookie is to allow the responder to verify, when it gets the cookie back from the initiator, that the cookie it got is the same as the cookie it sent. The cryptographic mechanism that provides this functionality is a MAC. So the second field in the cookie should be computed using a MAC function, rather than plain unkeyed hash. There are ofcourse many ways to compute a MAC. There is no reason to mandate one way on top of the other (especially since this is not an interoperability issue). In any case, if for sake of concreteness you want to give an example of a hash-based MAC then I'd use HMAC - it has better properties than the rudimentary "append the key" method implied by the current text. In addition, it may be good to add that if the responder wishes to reduce its state per exchange when under attack, then it can use the cookie as a replacement for storage. That is, define Cookie = | | MAC(, IPi | IP | ) where is any additional information that the responder chooses. (Potentially, the information in may be encrypted, if the responder so chooses.) Best, Ran From owner-ipsec Tue Jan 21 08:09:08 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18799 Tue, 21 Jan 2003 07:55:31 -0500 (EST) Cc: Dan Harkins , Hugo Krawczyk , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Message-ID: <3E2C49AA.B846E@bell-labs.com> Date: Mon, 20 Jan 2003 14:10:34 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com Original-CC: Dan Harkins , Hugo Krawczyk , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On the first glance - it looks very reasonable. I'm for it (pending some more thinking). Charlie_Kaufman@notesdev.ibm.com wrote: > > I see a number of problems with the SLA proposal posted as an I-D, > and have a counterproposal. > > The SLA proposal says that message 1 is unmodified and Message 2 contains > the responder's AUTH payload, moved from message 4. There are a number > of problems with this. Message 3 contains the list of roots trusted by > the initiator as well as the desired responder identity (the Me Tarzan, > You Jane variation). The responder uses those values to decide what > identity to respond with. We would either have to disallow that flexibility > when SLA was used or move those values to message 1. If we move them > to message 1, we lose the protection from passive eavesdroppers. > > Further, a responder must know whether it is going to use legacy > authentication or regular authentication after receiving message 1, which > has few clues and therefore a responder could not accept either type. > This could be fixed by putting a capability indicator in message 1. > > In this protocol, the initiator decides what form of legacy authentication > it wants to do and the responder can accept or reject that choice. This > is the reverse of what happens with EAP, where the responder decides > what form of authentication it expects sometimes based on the claimed > user identity. This means that if some users of a particular piece of > software use challenge/response tokens and some use username/password, > it would be up to the user to communicate to the client software what > sort of capability he has rather than waiting for the responder to prompt > for something. > > All of these problems can be worked around (but we would have to decide > how before we would have a spec), and the limitations may be > acceptable, but I believe they are unnecessary. I believe a smaller > modification to the protocol avoids these problems. > > The changes I would propose (derived closely from Stephane Beaulieu's proposal) > are to leave the first two messages alone, replace AUTH and CERT in message > 3 with an EAP exchange in messages 4 & 5 (and if more needed, 6 & 7, etc), > and deferring the completion of the child SA establishment from message 4 > to the last message. Or more precisely: > > No change to message 1. > No change to message 2. > Message 3: AUTH and CERT payloads are removed - perhaps an optional > indication of legacy auth methods supported. > Message 4: SAr2, TSi, TSr removed; EAP payload added > Message 5: EAP payload > Message 6: SAr2, TSi, TSr > > (where extra pairs of messages can be inserted between 5 and 6 if more > than one EAP round trip is required). > > If a legacy auth method that produces a shared key is used, the next > to last message should have an AUTH payload generated using that key. > The purpose is to protect against man-in-the-middle attacks. Defense > is only possible of the legacy auth method generates keying material, > and using that key for creating an AUTH payload is simpler than other > proposals that mix that keying material into the keys for the SAs. > > Note that a (perhaps controversial) aspect of this proposal is that > the initiator identity remains in message 2. This has the advantages > that it minimizes changes to the protocol and may avoid a round trip > in the EAP protocol because the responder doesn't have to separately > prompt for username. It has the disadvantage that it presumes that > with all legacy authentication methods there is some expression of > the user's identity that can be prompted for in a uniform way. I > can't think of any case where that wouldn't be true. > > What do people think? > > --Charlie > > Typical protocol run for the legacy auth case where we're just > prompting for a username and password would be: > > HDR, SAi1, KEi, Ni --> > <-- HDR, SAr1, KEr, Nr > HDR*, IDi, [IDr,] > SAi2, TSi, TSr} --> > <-- HDR*, IDr, [CERT,] AUTH, EAP(pwd) > HDR*, EAP(pwd) --> > <-- HDR*, SAr2, TSi, TSr} From owner-ipsec Tue Jan 21 17:56:00 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20246 Tue, 21 Jan 2003 17:53:09 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C7D8@corpmx14.us.dg.com> To: ipsec@lists.tislabs.com Subject: IKEv2 tunnel changes for ECN Date: Tue, 21 Jan 2003 17:54:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The "small draft" I promised to write on this topic is available at: http://members.bellatlantic.net/~vze4kfz2/drafts/draft-black-ipsec-ikev2-ecn fix-00.txt while the secretariat works on getting it onto the I-D servers. The draft specifies changes to IPsec tunnel decapsulation so that ECN "just works" for any tunnel-mode SA created by IKEv2 in order to avoid carrying the existing ECN negotiation for IKEv2 forward to IKEv2. It is intended to be superseded by 2401bis when that draft is ready, but is being done now to try to avoid carrying the negotiation forward. Please note the open issue described in Section 5.2. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec Tue Jan 21 18:40:22 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20347 Tue, 21 Jan 2003 18:39:44 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 21 Jan 2003 15:41:55 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Ciphersuites for IKEv2 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Given the looming deadline for us to finish on IKEv2, we need to come to some agreement on ciphersuites. The following comments are based on the -04 draft. In section 5.3.1, it says: >For Suite-ID, the following values are defined: > > Name Number Algorithms > IKE_CLASSIC 0 DH-Group #5 (1536 bits) > 3DES encryption > HMAC-SHA1 integrity and prf > > ESP_CLASSIC 1 3DES encryption > HMAC-SHA1 integrity > > values 2-65000 are reserved to IANA. Values 65001-65533 are > for private use among mutually consenting parties. Later, in section 5.14, it says: > The mandatory to implement algorithms are AES-128-CBC and HMAC-SHA1. So far, this list hasn't been able to agree on whether these are good values, mostly due to people having different priorities. I propose that the priority we choose for creating the MUST implement suite be that of greatest interoperability. This means that we should not expect any current IPsec vendor who has hardware acceleration to need to make hardware upgrades to their IPsec devices. Beyond that, we should also define suites that are expected to be used in typical circumstances, but we should not attach a MUST or even a SHOULD to those suites. We should also *not* name the suites because the names will impart meaning in the future that may not be true. For example, the name "IKE_CLASSIC" implies that the values are those used by typical IKEv1 systems, but that is not true because many systems don't even implement DH Group 5 (even though they obviously should). Given those criteria, I propose that the following text be used in section 5.3.1 (and the text noted above in section 5.14 be removed): ===== For Suite-ID, the following values are defined: Suite-ID Meaning -------- ------- 0 Covers: IKE 168-bit 3DES CBC encryption Diffie-Hellman group 2 (1024-bit) HMAC-SHA1 integrity and prf 1 Covers: ESP 3DES encryption with three keys HMAC-SHA1 integrity 2 Covers: AH HMAC-SHA1 integrity 3 Covers: IKE 168-bit 3DES CBC encryption Diffie-Hellman group 5 (1536-bit) HMAC-SHA1 integrity and prf 4 Covers: IKE AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 5 (1536-bit) HMAC-SHA1 integrity and prf 5 Covers: IKE AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 14 (2048-bit) HMAC-SHA1 integrity and prf 6 Covers: ESP AES encryption in CBC mode with 128-bit keys HMAC-SHA1 integrity 7 Covers: IKE AES encryption in CTR mode with 128-bit keys Diffie-Hellman group 14 (2048-bit) AES-CBC MAC + XCBC integrity and prf 8 Covers: ESP AES encryption in CTR mode with 128-bit keys AES-CBC MAC + XCBC integrity Values 9-65000 are reserved to IANA. Values 65001-65533 are for private use among mutually consenting parties. Additional Suite-ID values will be assigned by IANA based on consultation with the IESG. All implementations of IKEv2 MUST be able to negotiate Suite-ID 0 and Suite-ID 1. Implementations SHOULD be able to negotiate Suite-IDs 3, 4, 5, and 6. The must-be-implemented ciphersuites (0 and 1) are based on currently-deployed hardware that meets the security requirements of the vast majority of current IPsec users, and should be useful for at least a decade according to cryptographic estimates from NIST for business user scenarios. The should-be-implemented ciphersuites (3, 4, 5, and 6) are based on expectations of where the security industry is moving (namely, to the AES encryption suite) and where more security-conscious users are moving as current key lengths become more attackable due to the steady lowering of cost to mount brute-force attacks. An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. For example, at the time that this document was being written, many IKEv1 implementers are starting to migrate to AES in CBC mode for VPN applications. Many IPsec systems based on IKEv2 will implement AES, longer Diffie-Hellman keys, and additional hash algorithms, and some IPsec customers already require these algorithms in addition to the mandatory ones listed above. ===== Possible issues: - Some people may want to have more suites as fallbacks in case of a catastrophic failure of an algorithm. The WG seemed to want fewer suites. This is why I had the IANA registry being updated with IESG consultation instead of a standards-track RFC: we could get a number easily for a non-compromised suite. Having a zillion suites defined early won't cause implementers to handle them; note that TIGER was a SHOULD in IKEv1 and almost no one implemented it at all. - Should the ESP and AH MUST and SHOULDs be in the IKEv2 document or in 2401bis? I think they should be in IKEv2, but others have said that because they cover IPsec themselves, they should be in 2401bis. --Paul Hoffman, Director --VPN Consortium From owner-ipsec Tue Jan 21 19:48:23 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20652 Tue, 21 Jan 2003 19:46:45 -0500 (EST) Message-Id: <200301220049.h0M0n1G0009702@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Ciphersuites for IKEv2 In-reply-to: Your message of "Tue, 21 Jan 2003 15:41:55 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Jan 2003 19:49:01 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> Given the looming deadline for us to finish on IKEv2, we need to come to VPNC> some agreement on ciphersuites. The following comments are based on the VPNC> -04 draft. I have reviewed the proposed items, and the 8 combinations make me comfortable. VPNC> SHOULD to those suites. We should also *not* name the suites because the VPNC> names will impart meaning in the future that may not be true. For VPNC> example, the name "IKE_CLASSIC" implies that the values are those used VPNC> by typical IKEv1 systems, but that is not true because many systems VPNC> don't even implement DH Group 5 (even though they obviously VPNC> should). I concur with this reasoning. I would prefer to label 3 as MUST and 0 as SHOULD, but as long as people read 2026 for definition as SHOULD, I'm happy. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPi3qeoqHRg3pndX9AQFI/QQApJRbGRaNdE4y/LXP2QXzv08SU0Rdfov5 wXjpDj+pfHgpux0I2ekQ6ecggUJs6Be3ys1Bkx61DrniXPro7bv5EkpGgwCsh6fC ZiV7GlSq1di/6ogotKuyg/SlQq+KDmAzH3zTTRjSo8k9GAQUxP8yF8SL9hfncC9+ M/XpaCcHpag= =lqpL -----END PGP SIGNATURE----- From owner-ipsec Wed Jan 22 17:58:16 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23901 Wed, 22 Jan 2003 17:50:14 -0500 (EST) Date: Thu, 23 Jan 2003 00:53:01 +0200 (IST) From: Hugo Krawczyk To: Derrell Piper cc: IPsec WG Subject: Re: a change to the signature processing in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Jan 2003, Derrell Piper wrote: > Hugo, > > There's been scant discussion about this since your post. I've now > read your SIGMA paper and I like the first change you proposed. I > think explicitly moving the identity binding MAC into the signature > definition is a very good change for all the reasons you noted. I > would like to see this incorporated into the next revision of the IKEv2 > draft, prior to the February submission. I would like too. It is up to the editor now. Now that version 04 is out I will send explicit language to incorporate this change. It really is a triviality from the point of view of spec and implementation. > > Regarding the second change, I'm generally in favor of what you > proposed. I've always thought that the authenticator should include > all of the information transmitted by a peer. I have in the past heard > arguments about wanting to limit the amount of data being signed, which > often results in an additional MAC step being applied before the > signature. What are your thoughts here? Clearly with SLA we weren't > concerned with this since we proposed a 'sign it all' signature, but I > bring it up here because the generalized IKEv2 change may imply some > potentially long certificate chains will now be included with the > addition of messages 3 and 4. It would really be a better design that each party signs the two messages it sends, that is, each party signs ALL the information it sends in the exchange (including stuff that may be added to the exchange at some future revision...) But this change is less trivial than the above one, in particular as you say because of the potentially long certs that would get included automatically. It is no big deal since hashing this information is very fast, yet it may have a psychological effect on people. Also, signing two messages instead of one makes the spec a bit more complicated due to the need to concatenate the information and possibly move the signature to the end of the message. None of this is big deal but I will not "fight" for it. Thanks for the support. Hugo > > Derrell > > On Monday, December 30, 2002, at 04:38 PM, Hugo Krawczyk wrote: > > > > > This message contains a request for a change to the cryptographic > > specifications of ikev2's signatures. It is a relatively easy change > > that > > will add security to the protocol in the sense of making the protocol's > > security more robust to changes (in particular new modes and variants > > such > > as SLA). It will also improve the protocol by making its logic easier > > to > > understand and analyze. > > > > In a previous message I described an "identity misbinding attack" on > > SLA. > > I said there that this attack against the authenticity of the protocol > > is > > NOT possible in IKEv2. Indeed, IKEv2 provides strong authentication > > via > > the combination of a digital signature on the DH exponentials and a MAC > > on the signer's identity. This follows the "sign and mac" of the SIGMA > > protocols which has been rigorously analyzed. Therefore I have no > > complaints about the security of IKEv2 as specified now (draft v3). > > > > On the other hand, I do have a complaint (that I expressed several > > times in > > the past) regarding the "robustness" of the IKEv2 design. > > The problem is that the essential key-identity binding through a MAC > > is achieved in IKEv2 in an indirect way that is not sufficiently > > explicit > > and thus it is prone to misunderstandings and mistakes in modified > > versions > > of the protocol. I have been saying (since Nov 2001) that sooner or > > later > > people will propose variants or changes that will fail to be secure > > due to > > this design "obscurity". And indeed it happened sooner than later with > > the > > design of SLA. > > > > The problem is that IKEv2 authentication (and specifically key-identity > > binding) depends on two elements: > > > > (1) the MAC that is applied through the SK{} processing (which most > > people > > understand as needed for identity protection, or encryption integrity, > > rather than for the core authentication of the protocol) > > (2) the transmission of the initiator's identity in message 3 and of > > the > > responder's in message 4. > > > > If you remove any of these elements, or move the identities to another > > message, the protocol becomes insecure. > > SLA is an example in which the authentication in message 4 (the > > responder's) > > is moved to message 2 but SK{} (and its MAC) is not carried to that > > message. > > And it is not really the SLA designers fault: the SK{} processing > > includes > > encryption while message 2 of SLA cannot be encrypted (since it > > contains KEr > > which needs to be sent in the clear). Moreover, in SLA you do not care > > about protecting the identity of the responder (the server) and thus > > the > > SK{} processing is not only problematic but actually unnecessary. > > > > Another case in which the protocol's security would break down is in > > the > > following (not completely) hypotetical scenario. Assume that in some > > setting > > you do not care about identity protection of the initiator. In this > > case it > > makes a lot of sense to transmit this identity already in the first > > message > > so that the responder can make policy decisions early on based on this > > identity (this, btw, was one of the properties people liked/wanted in > > the > > aggressive modes of IKEv1). In this case, the authentication by the > > initiator still occurs in message 3, but the identity is not included > > there > > (since it was sent in message 1). However, while this change (or > > option) may > > seem very reasonable the resultant protocol would fail to "identity > > misbinding" attacks (i.e. the basic "mutual belief" property is lost). > > Note that while the effect of such an attack is debatable in the > > specific > > case of SLA, it is a major vulnerabiity in a general peer-to-peer key > > exchange protocol as IKEv2. > > > > As a fix to SLA and a general fix to this lack of robustness of IKEv2 I > > propose the following change to the signature computation (the AUTH > > payload) > > in IKEv2. > > > > Currently IKEv2 defines that the signature is to be applied to the > > concatenation of the peer's nonce and the contents of certain messages > > in > > the protocol. The change I am asking for is to add to the signed > > information > > also a value computed as MAC(SK_a,ID) where SK_a is is the MAC key > > already > > computed by the protocol, and ID is the identity of the signer. > > More specifically, in the initiator's signature (in message 3) this > > additional value will be MAC(SK_ai,IDi), while in the responder's > > signature > > it will be MAC(SK_ar,IDr). > > > > The computation of the keys SK_ai/SK_ar requires no additional > > processing > > or change since they are already derived in IKEv2 for use in the MAC > > in SK{}. > > Also note that the value MAC(SK_a,ID) added to the signature > > computation > > will NOT be transmitted but just re-computed by the receiving end when > > verifying the signature, so it requires no new payload nor it > > increases the > > length of messages. > > > > Thus, while the proposed change adds negligible complexity relative to > > the > > whole complexity of IKEv2 it provides for a significantly more robust > > and > > easier to analyze design. In particular: > > > > (1) the signatures can be moved to any message where they make sense > > (e.g. > > to message 2 in SLA) without loosing the protocols security > > (2) the identities can be transmitted in any message (e.g. the > > initiator's > > identity in message 1) without impacting the authentication of the > > protocol > > (3) the MAC used in SK{} will be confined to two functionalities: > > (a) protecting the identity encryption against active attacks > > (b) protecting the authenticity of phase-2 information piggybacked > > to msgs 3 and 4. > > > > Then I would also suggest a second change that will reduce the need for > > SK{} to functionality (a) (identity protection) only. The idea is > > to expand the signature's scope to the WHOLE information sent by each > > signer. > > That is, I's signature will be applied to the full messages 1 and 3, > > while R's > > signature to the full messages 2 and 4. In this case the AUTH payload > > can be > > moved to the end of messages 3 and 4 (before the SK{} processing). > > Relative to what is signed today, this change has the cost that each > > signature needs to be applied to two messages (instead of one message > > only). > > However making sure that you sign ALL the information sent by each > > party > > makes a better design. And, not less important, we make the MAC under > > SK > > only needed for identity protection. In particular, the resultant > > protocol > > can be proven secure even if the whole SK{} processing is omitted in > > case > > that identity protection is not required. I consider this as a > > significant > > robustness AND analytical advantage. > > > > In any case, while I'd prefer to see both changes accepted, I still > > consider > > the firsr one (adding MAC(SK_a,ID) to the signatures) as more > > significant > > and needed independently of the second change (i.e. expanding the > > scope of > > signatures). > > > > If anyone opposes these changes (especially the first one) please > > explain > > the rationale of this objection in a message to this list. I would > > suggest > > that whoever wants to raise objections against these changes first > > reads the > > SIGMA paper which addresses in much more detail the motivation and > > rationale > > behind these changes (in particular, see section 5.4 of the paper). > > The url (again) is http://www.ee.technion.ac.il/~hugo/sigma.ps [.pdf] > > > > Happy new year > > > > Hugo > > > > From owner-ipsec Wed Jan 22 18:40:00 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24104 Wed, 22 Jan 2003 18:39:11 -0500 (EST) Date: Thu, 23 Jan 2003 01:41:53 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: Re: a change to the signature processing in IKEv2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In a message posted to this list on Dec 31st http://www.vpnc.org/ietf-ipsec/mail-archive/msg02846.html I requested to make a change to the signature processing in ikev2 in order to add to the cryptographic soundness and robustness of the protocol (and, as a nice bonus, to secure SLA). See that message for the rationale of that change. I did not offer specific language then for the change since the ikev2 draft was in transition between 03 to 04 (and from 4 msgs to 6 msgs). Now that 04 is out I can provide with the exact language necessary to specify the change. The change takes 2-3 lines of text in the spec, 10 minutes of programming, and 30 minutes of testing. It also adds several years of extra cryptographic health to the protocol (and its derivatives)... So here is the suggested change. The text that follows should replace the first paragraph of section 4.15 (where the processing of the signature operation is defined) in ikev2-04. No other change is needed. The changes from the current paragraph are minimal and I marked them by putting them under brackets [...]. 4.15 Authentication of the IKE-SA The peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message and end with the last octet of the last payload in the second message. Appended to this (for purposes of computing the signature) [are] the initiator's nonce Ni (just the value, not the payload containing it), [and a value MIDr computed as prf(SK_ar,IDr). Note that neither the nonce Ni or value MIDi are transmitted.] Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) [are] the responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)]. That's all. I gave the name MID to the added value to mean "Mac'ed ID". The name is not strictly necessary since there is no need to refer to this MID value in any other place of the spec (except for rationale). BTW, I am assuming that the keys SK_a are intended for use as keys to the negotiated prf (and not, for example, to key a different MAC function). If I am wrong here please let me know. Regarding the second change I suggested in my note of 12/31, namely, that each peer signs ALL the information it sends during the exchange, I still think that this change would improve the cryptographic design of the protocol, but it also would add some specification complexity. If there is support for that change I can offer some text. In any case, I consider the introduction of the MID field as specified above a first priority (in particular since it makes the protocol security indpendent of the position of the identity in the exchange). Hopefully it will make it to the ikev2 draft by the February's "deadline"... Hugo From owner-ipsec Wed Jan 22 19:39:27 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24232 Wed, 22 Jan 2003 19:37:34 -0500 (EST) Date: Thu, 23 Jan 2003 02:40:52 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG Subject: some comments on ikev2 04 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, Browsing over ikev2-04 I noticed several issues that may require clarifications or simple textual changes. None is crucial, yet here is a list for you to consider. (1) prf, authentication, etc: The draft refers to "prf", "MAC", and "integrity protection" as synonyms. Moreover, it seems that there is only one algorithm negotiated for all of these functionalities (this includes key derivation, authentication in preshared mode, and identity protection in SK{}). If this understanding is correct, I would suggest to make this more clear and explicit in the text. If not, please let me know where is a differentiation between these transforms. Apropos, since the notion of "pseudorandom function" is not well represented in the more popular books about cryptography, it may be a good idea that ikev2 includes some language about what is meant (assumed) as a good prf. The following text (with a small addition) is from ike (v1): prf(key, msg) is the keyed pseudo-random function-- often a keyed hash function-- used to generate a deterministic output that appears pseudo-random, namely, indistinguishable from random for an observer who does not hold the prf key. Pseudo-random functions prf's are used both for key derivations and for authentication (i.e. as a keyed MAC). (See [KBC96]). (2) Anti-DoS cookie: I suggest that in your illustration of how to compute the cookie (page 19) you add to the input of the hash the value Ni. The rationale is that with this addition an attacker that sees message 2 sent from R to I but did not see the corresponding message 1 from I to R cannot use this cookie since it does not know Ni. With your definition, the attacker can use this cookie in a DoS attack by forging I's source IP address (IPi) in its response (i.e. posing as I in message 3). To do this it does not need to see the original first message from I. You may want to take a look at Section 2.3 of my draft http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt The proposal there is similar to what you do, but it includes the nonce Ni and also an anti-replay value T to prevent attackers from replaying valid cookies. The way way you do it is fine but requires frequent changes of the to obsolete old cookies. (3) Nonces (sec 4.10). You say that nonces need to be "at least equal to the key size of the strongest cryptographic algorithm used". Someone may understand that as 1024 (or even 2048) bits as the DH key size... You do not care about "key size" but about "algorithm strength" And, in a related issue: the key to prf in the derivation of the SKEYSEED is Ni|Nr. If you think of HMAC (I know you do) this is not a problem since HMAC has its built-in mechanism to deal with variable length keys. But other perfectly good prf's (e.g. AES-CBC-MAC) will not accept too long keys. You may want to say that the concatentation of Ni|Nr must be of the length of the prf, but if it is longer than specified for the prf then each nonce is truncated to contribute half of the bits of the key. (4) Section 4.13, end of second par: replace "the fixed key size is the size of the output of the HMAC" with "the fixed key size is the size of the output of the underlying hash function" The reason is that people may be confused about what the length of the "output of HMAC" is. Especially in the ipsec context some people think that HMAC outputs 96 bits (I have a lot of experience dealing with these confusions) (5) Last words in 4.14: change them to "the length of the output of the underlying hash function" (6) Sec 4.15. I do not understand what good it makes to concatenate the string "Key Pad for IKEv2" to the shared secret. You justify it on the seemingly "inevitable" use of passwords as shared keys. However, even in this case how does the concatenated string help? If for any reason you still want to put this string there make it an additional input to the prf, not a concatenation to the key. (7) Security considerations: - can you explain to me what is the meaning of the first paragraph. In what sense is the entropy of the DH consumed? (what is this entropy anyway?) Maybe you want to say that using the same phase 1 with many non-DH phase 2's compromises the PFS property of the protocol. -last par: I do not exactly understand the diffeentiation between "random", "pseudo-random" and "strongly random" in this text. I think that ALL these quantities should be cryptographically strong pseudo-random ("purely random" is a special case) (8) I include this to make sure that there is at least one suggestion that you will buy: there is a typo in the title of section 4.17 in the TOC... Hugo From owner-ipsec Wed Jan 22 20:31:29 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24404 Wed, 22 Jan 2003 20:30:26 -0500 (EST) Date: Thu, 23 Jan 2003 03:33:09 +0200 (IST) From: Hugo Krawczyk To: David Jablon cc: IPsec WG Subject: Re: A proposal In-Reply-To: <5.1.0.14.0.20030110230838.045dd440@pop.theworld.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, I do not think this whole issue is too important or that people really care, and I am glad that you agree that the xor-based solution would be an appropriate way to mix the additional key into the key derivation. Yet I do not really like having the "compound authentication" to happen (implicitly) at the level of key derivation. As for your specific responses to the technical objections in my previous message, let me make some clarification that may help dispeling some misunderstandings. The main point in your response is that the weaknesses I point out are possible only if one assumes "weaker" prfs than allowed by IKE (v2). That's wrong. Indeed, I illustrated my attack using a block-cipher based prf. There is NO cryptographic reason to assume that those are bad prf's, actually they may turn out to be better than HMAC-SHA1. These prf's are allowed (and should be allowed) by IKE as IKE remains secure with them. Moreover, my use of cipher-based prf's in the attack was needed because of the fortuitous choice made in ikev2 to derive encryption keys before authentication keys in the KEYMAT derivation. If this specification would have been made the other way around (first authentication keys, then encryption keys -- which is btw the ordering to derive the SKa and SKe keys from SKEYSEED) then your proposal would fail with ANY prf (including HMAC). Another objection that I see in your note is: > For the record, the disclosure of SK_d is not the result of my proposal. > It is the result of MITM attack due to failed server-only authentication, > a presumed pre-existing issue with SLA. You are absolutely right that your propsal does not disclose SK_d. Yet, it does not protect the SK_d derivation either. Thus the whole point of such a propsal is to avoid the MitM from impersonating the user even in case it obtained SK_d (something that is NOT avoided by introducing further keying material in the keymat derivation). Your proposal does succeed to some extent against full user impersonation but fails to known-key attacks. Finally, in response to some of your comments regarding mutual authentication, let me point out that the attack I described works even if each of the tunnel and the underlying "legacy" authentication provide strong mutual authentication. The problem is not with the individual methods but with its composition. In all, I do not believe that there was anything unfair about my comments. Certainly there was no such intention on my part. Hugo > On Mon, 13 Jan 2003, David Jablon wrote: > Hugo, > > You've raised a good point about the use of weaker alternative prf > functions in conjunction with my proposal. But the remaining analysis > is either incorrect or misdirected. > > All of the other "attacks" or potential weaknesses that you describe are > either directly applicable to IKEv2 or SLA, or do not exist with any of these > proposals, and they certainly do *not* result from my proposal to merely > include optional added key material in KEYMAT. > > Furthermore, the one valid point directed at my proposal is *only* valid > when one implements prf with a function that is significantly weaker > than HMAC, which is currently the only specifically described > instantiation in the IKEv2 draft. > > If the intent is indeed for IKEv2 to permit use of prf's based on reversible > functions, such as the cipher-based functions you describe, then > something else (like the alternative that you describe) would clearly be > needed to fix the problem, and it may be a good idea in any case. > If the intent is to not permit cipher-based prf's, and perhaps in any case, > it may be a good idea to clarify the required properties of "prf" in the draft. > > While many of your comments appear to unfairly criticise the proposal, > I do note that you gracously ignored the extraneous third argument to prf, > a typographical error on my part. > > I also note that you have not disputed the main point I was trying to make, > that the act of *properly* blending key material into the KEYMAT > computation does not weaken the security of IKEv2 [+SLA, ...], > all else being equal. > > I elaborate on these concerns in the response below. > > -- David > > > >On Thu, 2 Jan 2003, David Jablon wrote: > >> Here's what seems to me to be an obviously simple and secure extension. > > At 08:40 AM 1/6/03 +0200, Hugo Krawczyk wrote: > >Not so simple (due to the need to import a key from the underlying > >authentication method to the tunneling protocol). > > [David writes:] > For the record, my proposal, as a refinement of SLA or similar proposals, > does not introduce any new *need* to import a key from an underlying > authentication method. It simply provides a mechanism to make use > of a suitable imported key when desired and available. > > [David wrote:] > >> Proposal > >> > >> From my reading of www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-03.txt, > >> optional added key material from supplementary authentication > >> methods could be bound to the IKEv2 server-only authenticated key > >> using: > >> > >> KEYMAT = prf+(SK_d, [added_key_material] | Ni | Nr, g^ir) > >> > >> This would extend and replace the existing specification of: > >> > >> KEYMAT = prf+(SK_d, Ni | Nr, g^ir) > >... > > [Hugo wrote:] > >An obvious weakness of resolving the mitm problem via the key derivation > >(rather than by adding an explicit "compund authentication") is that you end > >the key exchange protocol without an explicit authentication that binds the > >two protocols. But this by itself can be considered as a DoS issue and not a > >security bug. > > I see no such "obvious weakness" in resolving the problem via a proper > KEYMAT derivation, either from a security or DoS perspective. In a > general case, one may legitimately argue that explicitly authenticating a > secondary key or credential in the tunnel is not the same as another > hypothetical compound tunneled authentication method that binds the > keys together and then explicitly authenticates the result. That's a fine > academic point, on which I generally agree. > > But every authentication protocol that can provide keying material either > provides (or could provide) explicit authentication of that material, or the > legacy credential from which it has been derived. And the intent to > encompass tunneled protocols "as is" implies that explicit authentication > is typically included. In this case, when explicit authentication is included, > and the tunnel is broken, SK_d is compromised by the MITM and direct > binding to SK_d becomes irrelevant. > > If, on the other hand, in your use of "compound authentication" you refer > to dual private key based authentication, that hardly seems a reasonable > criticism of how my proposal improves upon or diminishes the prior > IKEv2 + SLA (or similar) proposal. In my proposal, derived keys are still > just as authenticated (or not) by the IKEv2 server authentication steps as > they would be without the added keying material. > > To be absolutely clear, I think it's best to compare apples-to-apples. > Consider two cases of using server-only authentication to tunnel a > second authentication method based on legacy client credentials. > Presume that the tunnelled method exports key material. > Case (1) discards this material, while case (2) blends it, properly, into the > computation of KEYMAT. Case (2) should be at least as secure as (1). > > >However, your specific proposal introduces weaknesses beyond the DoS > >scenario. It is open to "known-key attacks" by the Man-in-the-mittle > >attacking the tunneled authentication. > > My proposal was made based on prf using HMAC -- the only explicitly > specified prf. Your concern is based on prf being instantiated using a > formerly unspecified method that might be possble in a future extension > to the draft, where HMAC is replaced with a weaker construction. > I don't dispute the legitimacy of your concern, but it is limited to such cases. > > >A known key attack is one in which the disclosure of one of the keys > >(e.g the authentication key) compromises another key (e.g the encryption > >key). Resistance to known key attacks is an important requirement of a > >well-designed key exchange protocol, and in particular of any good key > >derivation technique associated to the key exchange protocol. > > > >[...] > > > >It can be shown (and I sketch this below for those interested in the > >details) that an attacker that knows SK_d (which is the case of the mitm > >attacker against which your proposal tries to protect) can mount known-key > >attacks even WITHOUT knowing the "added-key-material" coming from the > >underlying authentication method. > >This is NOT possible in the regular ikev2 scenario where only the legitimate > >parties to the exchange know SK_d. > > For the record, the disclosure of SK_d is not the result of my proposal. > It is the result of MITM attack due to failed server-only authentication, > a presumed pre-existing issue with SLA. > > >The specific attacks that I can see are not the most practical, yet they > >are sufficient to show that one cannot claim (or prove) the compound key > >derivation that you propose to be secure in a mathematical sense. > > The proper addition of added_key_material into the computation of > KEYMAT does not cause the disclosure of an otherwise undisclosable > KEYMAT. But, you raise an excellent point about proper constructions, > especially since different implementations of "prf" (as specified) > may have very different properties: > > >A secure suggestion is to do a second prf+, similar to the one defined > >in ikev2, keyd with key "added-key-material", and then XOR the results of the > >two prf+ computations. ... > > I agree that XOR is a better way to bind the keying material, especially > when there is a concern that alternate constructions for prf are allowed, > such as the weaker cipher-based constructions that you describe (below). > I had presumed the use of the specified HMAC, or something at least as > strong, due to its extensive analysis and broad acceptance as a key > derivation function. > > >... This however ASSUMES that the key "added-key-material" > >was NOT used in any way (not even to key other cryptographic algorithms) in > >the underlying authentication protocol. ... > > It's not clear to me what you mean by that statement. Any added key > material will surely be derived in some way from the credentials used > in the underlying protocol. Insuring the security and proper use of the > exported/imported key is clearly the dual responsibility of both > protocols, as I noted in an earlier post. > > >PS: for those interested to see how a known-key attack could work against the > >above proposal, this can be exemplified as follows. It is a bit involved, > >somewhat artificial and it requires patience to be understood, I will only > >sketch the idea. Imagine a case in which the keys derived (KEYMAT) in > >sla/ikev2 are later used by the responder (server) to send confidential > >information to the iniitator (client), without the latter sending information > >back. This information could be a confidential real-time stream of data or > >whatever. In this case, the initiator will never complete its explicit > >authentication in the protocol since it will never show to the responder that > >it knows KEYMAT. In particular if this client is the mitm against which we > >want to protect, this attacker will never have to show that it knows the keys > >derived in KEYMAT. So far this may be considered only as a DoS attack on the > >server (which is sending information to a fake client, but one that supposedly > >cannot decrypt the information). > > Again, that sketch of a DoS issue, however (in)significant, seems to > be based on a false presumption that there is no explicit authentication > within the "tunnel". > > >However, this is not the end of the story. Imagine that the attacker > >records all this information and eventually learns the authentication keys > >used in the session. (This can be the case if a month later the > >authentication key shows up in some logs from that session; note that it > >may make sense to log, even wthout secrecy, authentication keys from > >expired sessions). Now our mitm attacker can also learn the encryption > >keys! How? If we imagine that the prf is a block cipher (eg AES-128 or > > AES-256) then if you look at the prf+ derivation in ikev2 you'll see > >that the attacker THAT KNOWS SK_d can compute all keys derived via prf+ > >if it happens to know the output of a single prf+ stage (Ti), and > > provided that the input to each prf+ stage is no longer than the cipher > >block. (All of this is possible with 128-bit blocks and even more > >plaussible with 256-bit blocks when no g^ir is involved, in particular > >when running phase 1). > > The known-key attack that you've sketched is only relevant for the > case where HMAC is replaced with an alternative weaker construction, > such as AES-nnn. > > As the only prf explicity specified in IKEv2 is HMAC, I had presumed that > any suitable key derivation function would have comparable properties. > If the draft is intended to permit the use of weaker prf constructions, > including those that are based on reversible functions, perhaps it should > more clearly specify the required (or non-required) properties of a suitable > prf. > > To be clear on this point: In light of your comments, the IKEv2 draft > seems well-defined, given the generally accepted definition of a > pseudo-random function. However something stronger than a simple > cipher-based prf may be desired, and in any case, it can't hurt to add > a reference to more clearly define the intent of "prf" to prevent others > from making false assumptions. > > >Moreover, it is only the fortitous definition in ikev2 that specifies > >that encryption keys are derived from the first octets of the output of prf+, > >and authentication keys from the last octets, that prevents an even easier > >attack. Indeed, had the definition been the other way (first derive the the > >authentication key, then the encryption key ) an attack as above could have > >been mounted with ANY prf (not just block ciphers as described above) > >including HMAC. > > What I think you're thinking of doesn't work against HMAC. But I see no > real point in exploring a non-disclosed "attack as above" that might have > been mounted against some other non-specified proposal. > > >NONE OF THESE ATTACKS or weaknesses ARE APPLICABLE to (or be blamed on) > >IKEv2. They are possible because of the way the key from the underlying > >authentication protocol, added_key_material, is involved in the proposed > >key derivation. > > I believe I have shown that, for other than the "prf" issue, the concerns > that you've raised are either not a concern at all, not a concern with my > proposal, or are best directed elsewhere. > > -- David > From owner-ipsec Wed Jan 22 22:45:32 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24591 Wed, 22 Jan 2003 22:42:25 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <28CAA5E1-2BD9-11D7-AAEC-000393CDFD1A@electric-loft.org> Subject: Re: Secure legacy authentication for IKEv2 To: Derrell Piper Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Wed, 22 Jan 2003 21:56:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/22/2003 10:44:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell Piper wrote on 01/19/2003 01:09:32 PM: > To summarize the differences, some of which are admittedly trivial: > > > 6) Is this a separate exchange type or not? (CKnote: I reordered your differences, for clarity of responses). I had misread the SLA proposal. The fact that it specifies a separate exchange type removes some of my objections. > > 5) AUTH payload in message 2 or message 4? --> implication for client > identity protection I believe this is the most important difference. Moving AUTH from message 4 up to message 2 makes the protocol quite different from the non-SLA case, and (I believe) this makes a lot of other changes necessary. It also complicates the analysis and changes the "what can an eavesdropper figure out" properties. The main advantage is (possibly) saving a round trip, which I would argue is not very important in a protocol that is interacting with people. > 1) Do we need to allow for the EAP identity exchange? If so, where > does it occur? If it's going to happen, I think it should happen in messages 4 & 5. This would extend the protocol one round trip in the case of legacy authentication, with the benefit of protecting the client identity from someone pretending to be the server. As to whether it has to happen, I don't think so. If there were some future EAP exchange that did not start with an identity request, then the ID payload couldn't substitute. But that seems unlikely. >From a technical perspective, it's a trade off between one more round trip and protecting the initiator's claimed identity from something impersonating the server. I don't believe either of these issues is worth fighting over. I'd happily go the other way but anticipated howling over 8 messages for username/password authentication. > > 2) Do we want to require or allow IKE ID payloads in addition to the > EAP identity? I don't think so. I think we want one or the other. I was proposing IKE ID payload as a replacement for EAP identity exchange. > > 3) Addition of optional CERT payload returned by the gateway along with > its AUTH payload. I think this is necessary. You can't necessarily verify a signature without the certs. I also believe the CERTREQ should precede the CERT so the client can specify trusted roots and IDr should precede the CERT so the client can name the server it wants to connect to in the case of a shared IP address. These combined make it possible that message 1 will require fragmentation, which in turn complicate the cookie/DOS stuff. > > 4) What is the order of the EAP payloads relative to other payloads? I don't think we disagree on this one, though the SLA proposal saves a round trip by not using the EAP syntax. I believe that's a false economy. There is another important difference you didn't mention. My proposal has an optional AUTH payload in the final message from client to server in the event that the legacy authentication method establishes a key between the two parties. The SLA spec doesn't say how such a key would be used, though some possibilities have been proposed on the list. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Thu Jan 23 00:09:44 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24797 Thu, 23 Jan 2003 00:08:06 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: a change to the signature processing in IKEv2 To: Hugo Krawczyk Cc: Derrell Piper , IPsec WG , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Wed, 22 Jan 2003 23:29:04 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 12:09:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Regarding the second change, I'm generally in favor of what you > > proposed. I've always thought that the authenticator should include > > all of the information transmitted by a peer. I have in the past heard > > arguments about wanting to limit the amount of data being signed, which > > often results in an additional MAC step being applied before the > > signature. What are your thoughts here? Clearly with SLA we weren't > > concerned with this since we proposed a 'sign it all' signature, but I > > bring it up here because the generalized IKEv2 change may imply some > > potentially long certificate chains will now be included with the > > addition of messages 3 and 4. > > It would really be a better design that each party signs the two messages > it sends, that is, each party signs ALL the information it sends in the > exchange (including stuff that may be added to the exchange at some future > revision...) > But this change is less trivial than the above one, in particular as you > say because of the potentially long certs that would get included > automatically.It is no big deal since hashing this information is very > fast, yet it may have a psychological effect on people. Also, signing two > messages instead of one makes the spec a bit more complicated due to the > need to concatenate the information and possibly move the signature to the > end of the message. None of this is big deal but I will not "fight" for > it. I would argue that the complexity is more than 'a bit', especially in light of proposed revisions where there are more than "the two" messages sent and where one side may send AUTH early in the exchange while the other side sends it late. Beyond performance and spec complexity, there is the issue of "plausible deniability" where I don't want to sign anything that can be used to prove that I intentionally conversed with the named party, but the "Me Tarzan/You Jane" IDr in message 3 would do just that if signed. It all makes my head hurt. I'm glad you won't "fight" for it... I hope no one else will either, and that if they do the argument includes proposed text. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Thu Jan 23 00:09:44 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24796 Thu, 23 Jan 2003 00:08:06 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: a change to the signature processing in IKEv2 To: Hugo Krawczyk Cc: IPsec WG , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Wed, 22 Jan 2003 23:15:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 12:09:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > The peers are authenticated by having each sign (or MAC using a > shared secret as the key) a block of data. For the responder, the > octets to be signed start with the first octet of the first SPI in > the header of the second message and end with the last octet of the > last payload in the second message. Appended to this (for purposes > of computing the signature) [are] the initiator's nonce Ni (just the > value, not the payload containing it), [and a value MIDr computed as > prf(SK_ar,IDr). Note that neither the nonce Ni or value MIDi are > transmitted.] Similarly, the initiator > signs the first message, starting with the first octet of the first > SPI in the header and ending with the last octet of the last payload. > Appended to this (for purposes of computing the signature) [are] the > responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)]. Point of clarification. We have to say whether it's the whole IDi payload, or just the data portion, or the data portion plus the type. My preference would be the while IDi payload, since I believe it's important to cover the type and it's easier to specify the whole thing than to list subparts. I have been resistant to this sort of change in the past believing it to be overkill. But I'll grant that it does make it harder for future changes to the protocol to introduce subtle problems (as illustrated by the SLA discussion), so I'm now inclined to go along unless someone objects. This does have an interaction with another discussion. In various proposals, the IDi field replaced with other (authentication method dependent) fields. This would commit us to always having IDi and IDr fields even if the information they contain duplicates information elsewhere. I can live with that... does anyone else object?? In legacy authentication, I proposed that any shared secret established by the legacy authentication be used to compute the MAC for the client's AUTH field, and that if the legacy authentication method doesn't produce such a shared key then the client never sends an AUTH field. This is instead of somehow mixing that shared key into SKEYSEED. This implies that the key is no stronger than the Diffie-Hellman group used, but that has to be true when using digital signatures and seems acceptable here. Do you have any objections? > BTW, I am assuming that the keys SK_a are intended for use as keys to the > negotiated prf (and not, for example, to key a different MAC function). If > I am wrong here please let me know. SK_a keys are used to compute a MAC over IKE packets. Currently, the only MAC allowed is the negotiated prf, and I can't imagine why anyone would make it anything else. If a different MAC were used, I would presume that the same MAC computed over IDi would be what you should sign. I don't think that needs saying, but there might be a natural place for the words. > Regarding the second change I suggested in my note of 12/31, namely, that > each peer signs ALL the information it sends during the exchange, I still > think that this change would improve the cryptographic design of the > protocol, but it also would add some specification complexity. If there is > support for that change I can offer some text. I agree this would increase the robustness of the protocol against someone revising the specification of the protocol in the future in a way that makes the protocol less secure, but I also believe that it adds significant specification complexity so I continue to oppose it. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Thu Jan 23 08:18:38 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25841 Thu, 23 Jan 2003 08:16:44 -0500 (EST) Message-Id: <200301231247.HAA04841@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-ecnfix-00.txt Date: Thu, 23 Jan 2003 07:47:03 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IKEv2: ECN Requirements for IPsec Tunnels Author(s) : D. Black Filename : draft-ietf-ipsec-ikev2-ecnfix-00.txt Pages : 7 Date : 2003-1-22 IPsec (IP Security) tunnel encapsulation and decapsulation were specified prior to the addition of ECN (Explicit Congestion Notification) to IP, with the potential result that ECN congestion indications could be discarded by IPsec tunnel decapsulators. The current ECN specification includes two ECN operating modes for IPsec tunnels to avoid this situation, and IKEv1/ISAKMP (Internet Key Exchange/Internet Security Association and Key Management Protocol) negotiation extensions to enable ECN to be used correctly with IPsec tunnels. To simplify this situation, IKEv2 requires changes to tunnel decapsulation that prevent discarding of ECN congestion indication, obviating the need for multiple ECN operating modes and associated negotiation support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-ecnfix-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-ecnfix-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-ecnfix-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-22112434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-ecnfix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-ecnfix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-22112434.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Jan 23 08:18:38 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25835 Thu, 23 Jan 2003 08:15:42 -0500 (EST) X-Originating-IP: [64.230.114.253] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com, paul.hoffman@vpnc.org Date: Thu, 23 Jan 2003 04:12:17 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jan 2003 09:12:19.0094 (UTC) FILETIME=[87B23360:01C2C2BF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Values 9-65000 are reserved to IANA. Values 65001-65533 are for private >use among mutually consenting parties. Additional Suite-ID values will >be assigned by IANA based on consultation with the IESG. This sounds unreasonable to me. Why have 65000 values for IANA but only 533 for private use? (Especially considering that this will no doubt be one of the most popular attributes for private use.) Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-ipsec Thu Jan 23 10:56:47 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26322 Thu, 23 Jan 2003 10:53:22 -0500 (EST) Message-ID: <3E300F56.6020904@juniper.net> Date: Thu, 23 Jan 2003 10:50:46 -0500 From: Kevin Dubray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 (CK-SillyDog) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: randy@psg.com, Bert Wijnen Subject: IPsec benchmarking Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, There's an effort in the Benchmarking Methodology WG to assess whether the BMWG should undertake an effort provide benchmarking guidelines for IPsec devices. A link to the initial proposal can be found here: http://www.ietf.org/mail-archive/working-groups/bmwg/current/msg00323.html Discussion can be found on the BMWG mailing list and its archive: http://www.ietf.org/mail-archive/working-groups/bmwg/current/maillist.html If interested, please post your commentary to bmwg@ietf.org. Thanks, Kevin From owner-ipsec Thu Jan 23 12:34:56 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26578 Thu, 23 Jan 2003 12:32:48 -0500 (EST) Message-Id: <5.1.1.5.2.20030123092742.09dd2820@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 23 Jan 2003 09:30:44 -0800 To: skent@gto-mailer1.bbn.com From: Mark Baugher Subject: question on ESPbis, Sec. 2.1 Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt uses the protocol id (ESP or AH) as part of the SA lookup as an option. I don't understand why it is needed in either the unicast or the multicast cases. Mark From owner-ipsec Thu Jan 23 13:25:06 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26732 Thu, 23 Jan 2003 13:24:16 -0500 (EST) Date: Thu, 23 Jan 2003 13:26:29 -0500 (EST) From: Henry Spencer To: Mark Baugher cc: ipsec@lists.tislabs.com Subject: Re: question on ESPbis, Sec. 2.1 In-Reply-To: <5.1.1.5.2.20030123092742.09dd2820@mira-sjc5-6.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 23 Jan 2003, Mark Baugher wrote: > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt uses > the protocol id (ESP or AH) as part of the SA lookup as an option. I don't > understand why it is needed in either the unicast or the multicast cases. The idea is that there is at least the option of giving ESP and AH separate SPI number spaces. This was the case in the past, and there have been IPsec implementations which exploited it: when asked to make a connection using both ESP and AH, they would use the same SPI for both. Henry Spencer henry@spsystems.net From owner-ipsec Thu Jan 23 14:29:16 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26846 Thu, 23 Jan 2003 14:25:26 -0500 (EST) Date: Thu, 23 Jan 2003 11:27:41 -0800 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipsec@lists.tislabs.com To: Charlie_Kaufman@notesdev.ibm.com From: Derrell Piper In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday, January 22, 2003, at 06:56 PM, Charlie_Kaufman@notesdev.ibm.com wrote: >> 5) AUTH payload in message 2 or message 4? --> implication for client >> identity protection > > I believe this is the most important difference. Moving AUTH from > message 4 > up to message 2 makes the protocol quite different from the non-SLA > case, > and (I believe) this makes a lot of other changes necessary. It also > complicates the analysis and changes the "what can an eavesdropper > figure > out" properties. The main advantage is (possibly) saving a round trip, > which I would argue is not very important in a protocol that is > interacting > with people. I was hoping for more discussion from others. I can go either way myself. Since we're running out of time and there's been no other input, I'll defer to your preference. >> 1) Do we need to allow for the EAP identity exchange? If so, where >> does it occur? > > If it's going to happen, I think it should happen in messages 4 & 5. > This > would extend the protocol one round trip in the case of legacy > authentication, with the benefit of protecting the client identity from > someone pretending to be the server. > > As to whether it has to happen, I don't think so. If there were some > future > EAP exchange that did not start with an identity request, then the ID > payload couldn't substitute. But that seems unlikely. > > From a technical perspective, it's a trade off between one more round > trip > and protecting the initiator's claimed identity from something > impersonating the server. I don't believe either of these issues is > worth > fighting over. I'd happily go the other way but anticipated howling > over 8 > messages for username/password authentication. This question is really directed at folks who have implementation experience with EAP. Is it the case that existing EAP implementations generally do not require the optional identity exchange when they have an identity available from some other out-of-band source? I was hoping some EAP folks would speak up here... Or do you sometimes masquerade in an EAP hat? :-) It's certainly cleaner for IKE if that's the case and if we can rely solely on our own ID's. But I'd hate to see us say that that's how it's going to work and then find out that in the real world, BCP for EAP just doesn't work that way... I think it behooves us to make sure that the way we're proposing to use EAP is realistic. Are any EAP people following this discussion? William? Having gotten that off my chest, let's assume this is the case... :-) >> 2) Do we want to require or allow IKE ID payloads in addition to the >> EAP identity? > > I don't think so. I think we want one or the other. I was proposing > IKE ID > payload as a replacement for EAP identity exchange. I'd prefer this too, again as long as this is copasetic with EAP folk. >> 3) Addition of optional CERT payload returned by the gateway along >> with >> its AUTH payload. > > I think this is necessary. You can't necessarily verify a signature > without > the certs. I also believe the CERTREQ should precede the CERT so the > client > can specify trusted roots and IDr should precede the CERT so the > client can > name the server it wants to connect to in the case of a shared IP > address. > These combined make it possible that message 1 will require > fragmentation, > which in turn complicate the cookie/DOS stuff. Yeah, fine. SLA made some aggressive assumptions about its client's configuration and constraints. > There is another important difference you didn't mention. My proposal > has > an optional AUTH payload in the final message from client to server in > the > event that the legacy authentication method establishes a key between > the > two parties. The SLA spec doesn't say how such a key would be used, > though > some possibilities have been proposed on the list. Good point, sorry I missed that. That's a great idea, though there is a nuance to saying that. Does the client aggressively send an AUTH payload whenever *he* thinks the authentication is done, or does he send it only after receiving a positive EAP(success) from the gateway? I.e., does it end: HDR*, EAP(n), AUTH --> <-- HDR*, EAP(success), SAr2, TSi, TSr ...or... HDR*, EAP(n) --> <-- HDR*, EAP(success), SAr2, TSi, TSr HDR*, AUTH --> The issue with the former is that the client might not necessarily know which is his last response. I'm thinking about SecurID Next Code mode, thought that's obviously a bad example for a shared key. The issue with the latter is that it makes the exchange an odd number of messages, which is bad for our retransmission policy. So we should probably chose the former. So in the case of an extra round-trip it ends like this: HDR*, EAP(n), AUTH --> <-- HDR*, EAP(n) HDR*, EAP(n), AUTH --> <-- HDR*, EAP(success), SAr2, TSi, TSr -------- So let's see if we agree on the generic protocol for the simple case (username/password): HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr HDR*, IDi, [CERTREQ], [IDr,] SAi2, TSi, TSr --> <-- HDR*, IDr, [CERT,] AUTH, EAP(n) HDR*, [AUTH,] EAP(n) --> <-- HDR*, EAP(status) [, SAr2, TSi, TSr ] Additional round-trips may occur after after Messages 4 & 5, depending on the EAP exchange type. Additionally, if an EAP identity exchange is required, it begins with Message 4 (and necessitates additional Messages 7 & 8). The final message from the client MAY include an AUTH payload if the legacy authentication method establishes a shared key with the server. If EAP processing requires an additional round-trip, the AUTH payload from the client is repeated in Message 7 and on. The final message from the server completes the CREATE_CHILD_SA setup begun in message 3 and returns SAr2, TSi, TSr only when the EAP authentication was successful. For the case where one additional EAP round-trip is required (e.g., SecurID Next Code mode): HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr HDR*, IDi, [CERTREQ], [IDr,] SAi2, TSi, TSr --> <-- HDR*, IDr, [CERT,] AUTH, EAP(n) HDR*, [AUTH,] EAP(n) --> <-- HDR*, EAP(n) HDR*, [AUTH,] EAP(n) --> <-- HDR*, EAP(status) [, SAr2, TSi, TSr ] When EAP processing requires additional round-trips, Message 6 contains only an EAP payload. Derrell From owner-ipsec Thu Jan 23 14:33:59 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26874 Thu, 23 Jan 2003 14:32:36 -0500 (EST) Date: Thu, 23 Jan 2003 11:34:39 -0800 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipsec@lists.tislabs.com To: Charlie_Kaufman@notesdev.ibm.com From: Derrell Piper In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday, January 22, 2003, at 06:56 PM, Charlie_Kaufman@notesdev.ibm.com wrote: > Derrell Piper wrote on 01/19/2003 01:09:32 PM: > >> To summarize the differences, some of which are admittedly trivial: >> >> >> 6) Is this a separate exchange type or not? > > (CKnote: I reordered your differences, for clarity of responses). > I had misread the SLA proposal. The fact that it specifies a separate > exchange type removes some of my objections. I'd still propose that we use a separate exchange type for the legacy authentication exchange. Derrell From owner-ipsec Thu Jan 23 15:54:30 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27022 Thu, 23 Jan 2003 15:49:39 -0500 (EST) Message-Id: <5.1.1.5.2.20030123125042.09df0270@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 23 Jan 2003 12:52:18 -0800 To: Henry Spencer From: Mark Baugher Subject: Re: question on ESPbis, Sec. 2.1 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.1.5.2.20030123092742.09dd2820@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:26 PM 1/23/2003 -0500, Henry Spencer wrote: >On Thu, 23 Jan 2003, Mark Baugher wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt uses > > the protocol id (ESP or AH) as part of the SA lookup as an option. I > don't > > understand why it is needed in either the unicast or the multicast cases. > >The idea is that there is at least the option of giving ESP and AH >separate SPI number spaces. This was the case in the past, and there have >been IPsec implementations which exploited it: when asked to make a >connection using both ESP and AH, they would use the same SPI for both. Why wouldn't the receiver just allocate separate SPIs and skip the additional overhead of a maintaining and searching a protocol index? Does this somehow aid the sender? Mark > Henry Spencer > henry@spsystems.net From owner-ipsec Thu Jan 23 16:00:34 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27057 Thu, 23 Jan 2003 16:00:08 -0500 (EST) Date: Thu, 23 Jan 2003 16:01:48 -0500 (EST) From: Henry Spencer To: Mark Baugher cc: ipsec@lists.tislabs.com Subject: Re: question on ESPbis, Sec. 2.1 In-Reply-To: <5.1.1.5.2.20030123125042.09df0270@mira-sjc5-6.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 23 Jan 2003, Mark Baugher wrote: > >separate SPI number spaces. This was the case in the past, and there have > >been IPsec implementations which exploited it: when asked to make a > >connection using both ESP and AH, they would use the same SPI for both. > > Why wouldn't the receiver just allocate separate SPIs and skip the > additional overhead of a maintaining and searching a protocol index? In the one case I'm familiar with, it simplified keeping track of which SAs were associated with which connection. > Does this somehow aid the sender? No, it's strictly a receiver issue. Note that there is a backward-compatibility issue: the mere fact that it was allowed in the past means that outlawing it now is problematic. Henry Spencer henry@spsystems.net From owner-ipsec Thu Jan 23 16:18:00 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27103 Thu, 23 Jan 2003 16:17:28 -0500 (EST) Message-Id: <5.1.1.5.2.20030123131442.09df6610@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 23 Jan 2003 13:19:26 -0800 To: Henry Spencer From: Mark Baugher Subject: Re: question on ESPbis, Sec. 2.1 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.1.5.2.20030123125042.09df0270@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:01 PM 1/23/2003 -0500, Henry Spencer wrote: >On Thu, 23 Jan 2003, Mark Baugher wrote: > > >separate SPI number spaces. This was the case in the past, and there have > > >been IPsec implementations which exploited it: when asked to make a > > >connection using both ESP and AH, they would use the same SPI for both. > > > > Why wouldn't the receiver just allocate separate SPIs and skip the > > additional overhead of a maintaining and searching a protocol index? > >In the one case I'm familiar with, it simplified keeping track of which >SAs were associated with which connection. > > > Does this somehow aid the sender? > >No, it's strictly a receiver issue. > >Note that there is a backward-compatibility issue: the mere fact that it >was allowed in the past means that outlawing it now is problematic. Pardon me if I'm being dense. But if it's just a receiver issue and some receiver wants to hand out the same SPI for an AH and an ESP connection, then I don't see why it's a problem to remove it from the spec. Mark > Henry Spencer > henry@spsystems.net From owner-ipsec Thu Jan 23 16:34:30 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27155 Thu, 23 Jan 2003 16:33:53 -0500 (EST) Date: Thu, 23 Jan 2003 16:26:14 -0500 (EST) From: Henry Spencer To: Mark Baugher cc: ipsec@lists.tislabs.com Subject: Re: question on ESPbis, Sec. 2.1 In-Reply-To: <5.1.1.5.2.20030123131442.09df6610@mira-sjc5-6.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 23 Jan 2003, Mark Baugher wrote: > >No, it's strictly a receiver issue... > > Pardon me if I'm being dense. But if it's just a receiver issue and some > receiver wants to hand out the same SPI for an AH and an ESP connection, > then I don't see why it's a problem to remove it from the spec. The point is that the sender must tolerate it -- he must not make assumptions about the SPIs assigned by the receiver being unique. Henry Spencer henry@spsystems.net From owner-ipsec Thu Jan 23 22:16:17 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27912 Thu, 23 Jan 2003 22:09:54 -0500 (EST) Date: Fri, 24 Jan 2003 05:12:57 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG Subject: Re: a change to the signature processing in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk see below On Wed, 22 Jan 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > Hugo Krawczyk wrote: > > > The peers are authenticated by having each sign (or MAC using a > > shared secret as the key) a block of data. For the responder, the > > octets to be signed start with the first octet of the first SPI in > > the header of the second message and end with the last octet of the > > last payload in the second message. Appended to this (for purposes > > of computing the signature) [are] the initiator's nonce Ni (just the > > value, not the payload containing it), [and a value MIDr computed as > > prf(SK_ar,IDr). Note that neither the nonce Ni or value MIDi are > > transmitted.] Similarly, the initiator > > signs the first message, starting with the first octet of the first > > SPI in the header and ending with the last octet of the last payload. > > Appended to this (for purposes of computing the signature) [are] the > > responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)]. > > Point of clarification. We have to say whether it's the whole IDi payload, > or just the data portion, or the data portion plus the type. My preference > would be the while IDi payload, since I believe it's important to cover the > type and it's easier to specify the whole thing than to list subparts. >From the cryptographic point of view the MAC (or prf) needs to contain any information that suffices to identify the signer to the other peer. The data portion of the ID payload is enough for this but adding the whole payload as you suggest is perfectly ok too. > > I have been resistant to this sort of change in the past believing it to be > overkill. But I'll grant that it does make it harder for future changes to > the protocol to introduce subtle problems (as illustrated by the SLA > discussion), so I'm now inclined to go along unless someone objects. I don't object. :) > > This does have an interaction with another discussion. In various > proposals, the IDi field replaced with other (authentication method > dependent) fields. This would commit us to always having IDi and IDr fields > even if the information they contain duplicates information elsewhere. I > can live with that... does anyone else object?? > This issue is unrelated to the change I proposed. IDr should be anything that suffices for I to identify who the peer (responder) to the exchange is. Similarly for IDi. Without such information there would be no notion of "authentication" in the protocol. > In legacy authentication, I proposed that any shared secret established by > the legacy authentication be used to compute the MAC for the client's AUTH > field, and that if the legacy authentication method doesn't produce such a > shared key then the client never sends an AUTH field. This is instead of > somehow mixing that shared key into SKEYSEED. This implies that the key is > no stronger than the Diffie-Hellman group used, but that has to be true > when using digital signatures and seems acceptable here. Do you have any > objections? > This issue, too, is unrelated to the change I sugested. In any case you are right about the key being no stronger than the DH group. Since this is true for the signature mode, and even for the preshared mode with strong (say 128-bit random) key, then I see no objection that the same property will hold for the password-based protocols covered by SLA. > > BTW, I am assuming that the keys SK_a are intended for use as keys to the > > negotiated prf (and not, for example, to key a different MAC function). > If > > I am wrong here please let me know. > > SK_a keys are used to compute a MAC over IKE packets. Currently, the only > MAC > allowed is the negotiated prf, and I can't imagine why anyone would make it > anything else. If a different MAC were used, I would presume that the same > MAC computed over IDi would be what you should sign. I don't think that > needs > saying, but there might be a natural place for the words. I suggest that the draft will make it clear that prf is the function to be used for key derivation and also for the integrity protection function in the "encrypted payload" (it is also used explicitly in the current specification for the AUTH computation under preshared mode). Currently, this dual use of the prf is a "de-facto specification" since the ciphersuites do not accomodate different functions for prf and for integrity. So it is better to say this explicitly. The only reason that one may want a MAC different than the prf is to speed up the MAC computation in SK{}. Indeed, there are MAC functions that are much faster than prf's. But this speed advantage is irrelevant in IKE. For example, by replacing the prf (for integrity) with a 10 times faster MAC you may get (at most) a speed-up of IKE of 1% (this is so so since the computation time in ike is fully dominated by the signature and DH operations). > > > Regarding the second change I suggested in my note of 12/31, namely, that > > each peer signs ALL the information it sends during the exchange, I still > > think that this change would improve the cryptographic design of the > > protocol, but it also would add some specification complexity. If there > is > > support for that change I can offer some text. > > I agree this would increase the robustness of the protocol against someone > revising the specification of the protocol in the future in a way that > makes the protocol less secure, but I also believe that it adds significant > specification complexity so I continue to oppose it. No surprise here... Hugo > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > > From owner-ipsec Thu Jan 23 23:19:06 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28119 Thu, 23 Jan 2003 23:17:24 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Secure legacy authentication for IKEv2 To: Derrell Piper Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Thu, 23 Jan 2003 21:52:36 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 01/23/2003 11:19:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This question is really directed at folks who have implementation > experience with EAP. Is it the case that existing EAP implementations > generally do not require the optional identity exchange when they have > an identity available from some other out-of-band source? I was hoping > some EAP folks would speak up here... Or do you sometimes masquerade > in an EAP hat? :-) I checked my hat collection and none say EAP. I agree it would be nice to get feedback. Anyone??? > Does the client aggressively send an AUTH > payload whenever *he* thinks the authentication is done, or does he > send it only after receiving a positive EAP(success) from the gateway? I would propose that the client sends an AUTH payload whenever he has enough information to have generated the shared key. I believe that would always be before the EAP(success) message, though it would depend on the details of the protocol. Are any key-generating algorithms defined for EAP? > So let's see if we agree on the generic protocol for the simple case > (username/password): > > HDR, SAi1, KEi, Ni --> > <-- HDR, SAr1, KEr, Nr > HDR*, IDi, [CERTREQ], [IDr,] > SAi2, TSi, TSr --> > <-- HDR*, IDr, [CERT,] AUTH, EAP(n) > HDR*, [AUTH,] EAP(n) --> > <-- HDR*, EAP(status) [, SAr2, TSi, TSr ] Yes... that's what I think we should do. > The final message from the client MAY include an AUTH payload if the > legacy authentication method establishes a shared key with the server. > If EAP processing requires an additional round-trip, the AUTH payload > from the client is repeated in Message 7 and on. I would say the client MUST must an AUTH payload *if* the legacy authentication method establisheds a shared key with the server, and it MUST be in the first message from client->server after the client has enough information to generate it. For a given authentication method, that should always be in the same message. I wouldn't repeat it in subsequent messages. I think we're getting close... are others being silent because they agree or because they are behind on email? --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec Fri Jan 24 01:00:06 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA28376 Fri, 24 Jan 2003 00:58:24 -0500 (EST) Message-Id: <5.1.1.5.2.20030123191204.09e2adb8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 23 Jan 2003 19:15:57 -0800 To: Henry Spencer From: Mark Baugher Subject: Re: question on ESPbis, Sec. 2.1 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.1.5.2.20030123131442.09df6610@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:26 PM 1/23/2003 -0500, Henry Spencer wrote: >On Thu, 23 Jan 2003, Mark Baugher wrote: > > >No, it's strictly a receiver issue... > > > > Pardon me if I'm being dense. But if it's just a receiver issue and some > > receiver wants to hand out the same SPI for an AH and an ESP connection, > > then I don't see why it's a problem to remove it from the spec. > >The point is that the sender must tolerate it -- he must not make assumptions >about the SPIs assigned by the receiver being unique. I would think that a sentence in the I-D such that "the sender should not make assumptions about how the receiver assigns SPIs, which may not be unique across different IPsec protocols" would suffice. This is a lot cheaper than adding an index to a database table, which is an option in ESPbis. It would save us two optional features in the ESPbis specification. Mark > Henry Spencer > henry@spsystems.net From owner-ipsec Fri Jan 24 09:07:53 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29707 Fri, 24 Jan 2003 09:04:19 -0500 (EST) Message-Id: <200301241256.HAA17319@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-00.txt Date: Fri, 24 Jan 2003 07:56:39 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES CCM Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ccm-00.txt Pages : 11 Date : 2003-1-23 This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ccm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-23093951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ccm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-23093951.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jan 24 09:46:58 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29820 Fri, 24 Jan 2003 09:46:08 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 20 Jan 2003 17:30:57 -0500 To: Charlie_Kaufman@notesdev.ibm.com From: Stephen Kent Subject: Re: Secure legacy authentication for IKEv2 Cc: Dan Harkins , Hugo Krawczyk , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm comfortable with this approach. Steve From owner-ipsec Fri Jan 24 11:34:49 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00247 Fri, 24 Jan 2003 11:31:38 -0500 (EST) Date: Fri, 24 Jan 2003 11:33:36 -0500 (EST) From: Henry Spencer To: Mark Baugher cc: ipsec@lists.tislabs.com Subject: Re: question on ESPbis, Sec. 2.1 In-Reply-To: <5.1.1.5.2.20030123191204.09e2adb8@mira-sjc5-6.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 23 Jan 2003, Mark Baugher wrote: > I would think that a sentence in the I-D such that "the sender should not > make assumptions about how the receiver assigns SPIs, which may not be > unique across different IPsec protocols" would suffice. This is a lot > cheaper than adding an index to a database table, which is an option in > ESPbis. How so? It seems to me that these are two different ways of saying exactly the same thing -- the receiver is permitted to have separate SPI number spaces for the different protocols, so the sender must not assume distinct SPIs. One wording may be better than the other at explaining it, but I fail to see any technical difference. Henry Spencer henry@spsystems.net From owner-ipsec Fri Jan 24 13:05:51 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00404 Fri, 24 Jan 2003 13:03:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.1.1.5.2.20030123092742.09dd2820@mira-sjc5-6.cisco.com> References: <5.1.1.5.2.20030123092742.09dd2820@mira-sjc5-6.cisco.com> Date: Fri, 24 Jan 2003 12:58:49 -0500 To: Mark Baugher From: Stephen Kent Subject: Re: question on ESPbis, Sec. 2.1 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:30 AM -0800 1/23/03, Mark Baugher wrote: >Steve > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt >uses the protocol id (ESP or AH) as part of the SA lookup as an >option. I don't understand why it is needed in either the unicast >or the multicast cases. > >Mark Mark, Your are right, it is not necessary in either case. But, for backwards compatibility, and because it is a local matter for the receiver, we don't preclude a receiver from using the protocol type if it wishes. Under what circumstances do you envision that a sender might be confused by the possibility that two SAs to the same destination might have the same SPI and be differentiated only by including the protocol field in the lookup? A sender does not uses these values in its lookup of an SAD entry, so I didn't see how this would cause a problem. Steve From owner-ipsec Fri Jan 24 14:10:53 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00631 Fri, 24 Jan 2003 14:09:06 -0500 (EST) Date: Fri, 24 Jan 2003 11:11:06 -0800 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipsec@lists.tislabs.com To: Charlie_Kaufman@notesdev.ibm.com From: Derrell Piper In-Reply-To: Message-Id: <96CECA6A-2FCF-11D7-B1AB-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday, January 23, 2003, at 06:52 PM, Charlie_Kaufman@notesdev.ibm.com wrote: > I would say the client MUST must an AUTH payload *if* the legacy > authentication > method establisheds a shared key with the server, and it MUST be in the > first message from client->server after the client has enough > information > to generate it. For a given authentication method, that should always > be in > the same message. > I wouldn't repeat it in subsequent messages. But it might be that the subsequent EAP exchange generates a new key. For generality, I think it should be shown as optional on subsequent messages... Basically, send it when it's first known and if/when it's changed. Derrell From owner-ipsec Fri Jan 24 14:23:57 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00666 Fri, 24 Jan 2003 14:23:31 -0500 (EST) Message-Id: <5.2.0.9.2.20030124142111.02755298@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 24 Jan 2003 14:25:19 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-00.txt In-Reply-To: <200301241256.HAA17319@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wrote this lnternet-Draft so that we could explore the ESPv3 support for authenticated encryption modes. CCM is the only unencumbered authentication encryption mode that I know about today. I hear that another is under development, but for now, we can work with CCM to determine whether ESPv3 really meets its design objectives. Russ >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Protocol Working Group of the >IETF. > > Title : Using AES CCM Mode With IPsec ESP > Author(s) : R. Housley > Filename : draft-ietf-ipsec-ciph-aes-ccm-00.txt > Pages : 11 > Date : 2003-1-23 > >This document describes the use of AES CCM Mode, with an explicit >initialization vector, as an IPsec Encapsulating Security Payload >(ESP) mechanism to provide confidentiality, data origin >authentication, connectionless integrity. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-00.txt From owner-ipsec Fri Jan 24 14:50:57 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00708 Fri, 24 Jan 2003 14:50:22 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-00.txt Date: 24 Jan 2003 19:28:25 GMT Organization: University of California, Berkeley Lines: 6 Distribution: isaac Message-ID: References: <200301241256.HAA17319@ietf.org> <5.2.0.9.2.20030124142111.02755298@mail.binhost.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1043436505 18926 128.32.153.211 (24 Jan 2003 19:28:25 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 24 Jan 2003 19:28:25 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ Housley wrote: >CCM is the only unencumbered >authentication encryption mode that I know about today. Maybe I'm overlooking something obvious, but: What's wrong with AES-CBC encryption followed by SHA1-HMAC? From owner-ipsec Fri Jan 24 17:08:01 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00990 Fri, 24 Jan 2003 17:01:01 -0500 (EST) Message-Id: <5.2.0.9.2.20030124165812.0275b750@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 24 Jan 2003 16:59:58 -0500 To: daw@mozart.cs.berkeley.edu From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-00.txt Cc: ipsec@lists.tislabs.com In-Reply-To: References: <200301241256.HAA17319@ietf.org> <5.2.0.9.2.20030124142111.02755298@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: Nothing is wrong with AES-CBC encryption followed by SHA1-HMAC. However, this cannot be used to test the new features put in ESPv3 to support authenticated encryption modes. To do that, one needs a mode that uses a single key for confidentiality and integrity. Russ At 07:28 PM 1/24/2003 +0000, David Wagner wrote: >Russ Housley wrote: > >CCM is the only unencumbered > >authentication encryption mode that I know about today. > >Maybe I'm overlooking something obvious, but: >What's wrong with AES-CBC encryption followed by SHA1-HMAC? From owner-ipsec Fri Jan 24 17:53:03 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01162 Fri, 24 Jan 2003 17:51:24 -0500 (EST) Date: Sat, 25 Jan 2003 00:54:29 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: Derrell Piper , IPsec WG Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some comments on the latest proposal (appended) This approach is certainly more compatible with the key exchange method of IKEv2 than the original SLA. This, I guess, is an advantage in terms of specification and implementation. On the other hand it costs one extra round (bringing to 3 rounds the minimal possible exchange, and at least 4 rounds if the anti-DoS round is used). If people feel comfortable with this trade-off then let's go with it. The one thing that I definitely dislike in the appended proposal is that it opens IDi (sent in message 3) to active attacks. If there is one application where identity protection really makes sense is in hiding identities and locations of mobile users, which will be among the main users of SLA. I suggest to make IDi optional in message 3, and make it clear that implementations should NOT assume that this IDi value is available, certainly not in a way that compromises the user's identity. Now regarding the AUTH field in the client's side, which is to be computed with a key exchanged by the underlying legacy authentication method (assuming, of course, that such a key exists and it is made available to SLA). I have no practical (or other) experience with such key-providing legacy authentication methods. However, since these are LEGACY methods then I assume that if they generate a shared key then this key may be intended for other uses. Can we be sure that this key (call it LK for "legacy key"), if used by SLA, will be used ONLY by SLA? Otherwise we may end having one key LK which is used in two different settings. In particular, one may end using one key LK for two different cryptographic algorithms. Are you sure that this is NOT possible? One other question raised in the appended note is when should the AUTH field be sent. Seems to me that the simplest specification is to send it in the last client's message in SLA. Even if this key (LK) is available earlier, it does not buy you much to compute AUTH earlier (and you can always keep the key for authentication at the end). An early authentication using LK can only help against a DoS attack mounted by a MitM attacker; however I doubt that anyone will choose this costly (for the attacker) way to to mount a DoS attack. Finally, if we are already assuming this key LK and use it to calculate AUTH from client to server, why not use it also in the other direction? Namely, to compute an AUTH payload from server to client sent, say, in the last protocol message. (This would be in addition to the AUTH payload that R sends in message 4 using its signature key). One advantage of having this field is that it helps to authenticate the server in the case that the client fails to properly authenticate the server using certificates (this is a natural concern especially in view of certiifcate use in SSL). Also, I have not seen definite enough studies of this MitM issue to be convinced that the authentication by the client using LK is enough to prevent ALL forms of MitM against the tunneled run. Server authentication using this key (which has no real complexity or disadvantages since we are already using LK in SLA) can prevent unseen attacks. (Has anyone done a full analysis to confidently discard the advantage of a server to client authentication using LK?) Hugo On Thu, 23 Jan 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > [....] > > So let's see if we agree on the generic protocol for the simple case > > (username/password): > > > > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr > > HDR*, IDi, [CERTREQ], [IDr,] > > SAi2, TSi, TSr --> > > <-- HDR*, IDr, [CERT,] AUTH, EAP(n) > > HDR*, [AUTH,] EAP(n) --> > > <-- HDR*, EAP(status) [, SAr2, TSi, TSr > ] > > Yes... that's what I think we should do. > > > The final message from the client MAY include an AUTH payload if the > > legacy authentication method establishes a shared key with the server. > > If EAP processing requires an additional round-trip, the AUTH payload > > from the client is repeated in Message 7 and on. > > I would say the client MUST must an AUTH payload *if* the legacy > authentication > method establisheds a shared key with the server, and it MUST be in the > first message from client->server after the client has enough information > to generate it. For a given authentication method, that should always be in > the same message. I wouldn't repeat it in subsequent messages. > > I think we're getting close... are others being silent because they agree > or because they are behind on email? > > --Charlie > From owner-ipsec Fri Jan 24 20:12:56 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01472 Fri, 24 Jan 2003 20:10:30 -0500 (EST) Date: Fri, 24 Jan 2003 20:12:57 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-00.txt In-Reply-To: <5.2.0.9.2.20030124165812.0275b750@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 24 Jan 2003, Russ Housley wrote: > Nothing is wrong with AES-CBC encryption followed by SHA1-HMAC. However, > this cannot be used to test the new features put in ESPv3 to support > authenticated encryption modes. To do that, one needs a mode that uses a > single key for confidentiality and integrity. For just testing, that's easy. Define the Housley-1 authenticating cipher, a mysterious black box (as far as ESP is concerned, anyway) which just happens to call AES-CBC routines using some of its key bits and SHA1-HMAC routines using the rest. Henry Spencer henry@spsystems.net From owner-ipsec Sun Jan 26 14:43:09 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04920 Sun, 26 Jan 2003 14:23:27 -0500 (EST) Date: Sun, 26 Jan 2003 19:26:26 +0000 From: burkhard Subject: CREATE_CHILD_SA exchange with PFS To: ipsec@lists.tislabs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallo all, I have the following question about . Am I allowed to use after the Initial phase 1 Exchange the CREATE_CHILD_SA exchange with PFS or is the CREATE_CHILD_SA exchange with PFS only intended to be for rekeying at a later stage? My understanding by reading the draft is that CREATE_CHILD_SA exchange with PFS is not allowed to be piggybacked on the phase 1 exchange, therefore if I whish to use PFS I need to do a CREATE_CHILD_SA exchange. This will result in 4 Initial phase 1 Exchange transmissions and 2 for the CREATE_CHILD_SA creation with PFS. Does it make sense to use a CREATE_CHILD_SA exchange with PFS straight after the Initial phase 1 Exchange? Burkhard Excerpt from Draft follows: ---------------------------------------------------------------------------- - 4.16 Generating Keying Material for CHILD-SAs CHILD-SAs are created either by being piggybacked on the phase 1 exchange, or in a phase 2 CREATE_CHILD_SA exchange. Keying material for them is generated as follows: KEYMAT = prf+(SK_d, Ni | Nr) Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this request is the first CHILD-SA created or the fresh Ni and Nr from the CREATE_CHILD_SA exchange if this is a subsequent creation. For phase 2 exchanges with PFS the keying material is defined as: IKEv2 [Page 27] INTERNET DRAFT January 2003 KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) where g^ir (ph2) is the shared secret from the ephemeral Diffie- Hellman exchange of this phase 2 exchange, A single CHILD-SA negotiation may result in multiple security associations. ESP and AH SAs exist in pairs (one in each direction), and four SAs could be created in a single CHILD-SA negotiation if a combination of ESP and AH is being negotiated. KEYMAT is generated as described in section 4.13. Keying material is taken from the expanded KEYMAT in the following order: All keys for SAs carrying data from the initiator to the responder are taken before SAs going in the reverse direction. If multiple protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet. If a single protocol has both encryption and authentication keys, the encryption key is taken from the first octets of KEYMAT and the authentication key is taken from the next octets. Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm. 4.17 Rekeying IKE-SAs using a CREATE_CHILD_SA exchange The CREATE_CHILD_SA exchange can be used to re-key an existing IKE-SA (see section 4.8). New Initiator and Responder SPIs are supplied in the SPI fields. The TS payloads are omitted when rekeying an IKE-SA. SKEYSEED for the new IKE-SA is computed using SK_d from the existing IKE-SA as follows: SKEYSEED = prf(SK_d (old), [g^ir (ph2)] | Ni | Nr) where g^ir (ph2) is the shared secret from the ephemeral Diffie- Hellman exchange of this phase 2 exchange and Ni and Nr are the two nonces stripped of any headers. The new IKE-SA MUST reset its message counters to 0. SK_d, SK_ai, SK_ar, and SK_ei, and SK_er are computed from SKEYSEED as specified in section 4.14. From owner-ipsec Sun Jan 26 15:11:15 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05033 Sun, 26 Jan 2003 15:01:35 -0500 (EST) Message-Id: <5.2.0.9.2.20030126150001.00b691d0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 26 Jan 2003 15:03:47 -0500 To: Henry Spencer From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-00.txt Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.2.20030124165812.0275b750@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 24 Jan 2003, Russ Housley wrote: > > Nothing is wrong with AES-CBC encryption followed by SHA1-HMAC. However, > > this cannot be used to test the new features put in ESPv3 to support > > authenticated encryption modes. To do that, one needs a mode that uses a > > single key for confidentiality and integrity. At 08:12 PM 1/24/2003 -0500, Henry Spencer wrote: >For just testing, that's easy. Define the Housley-1 authenticating >cipher, a mysterious black box (as far as ESP is concerned, anyway) which >just happens to call AES-CBC routines using some of its key bits and >SHA1-HMAC routines using the rest. Or, we could use a real authenticated encryption mode that is being used in 802.11 systems. If it turns out that it has nice properties in the IPsec ESP space as well, then there can be common hardware for the two environments, or at least a common core that is used in both. This would provide economy of scale for both communities. Russ From owner-ipsec Mon Jan 27 06:14:15 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA06600 Mon, 27 Jan 2003 05:57:03 -0500 (EST) Message-Id: <200301271058.h0RAwiof029145@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: IPsec and Mobile IPv6 Date: Mon, 27 Jan 2003 11:58:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I submitted a new version of my draft about IPsec and Mobile IPv6 (draft-dupont-ipsec-mipv6-02.txt). I am writting a proposal for an address management feature in IKEv2. Francis.Dupont@enst-bretagne.fr PS: here is the plan of the proposal. First part is already finished, I expect to submit it before the end of this week. Summary of address management for IKEv2 Goals General goals Simplicity Performance (why rekeying is not enough) Security Transient Pseudo-NAT attack Extension of draft 04 Cleanup of NAT-DETECTION-*-IP notifications Hash is not useful No way to request Multiple address support Misused of peer addresses IKE SA lookup by SPI INITIAL-CONTACT issue Revised Identities Proxy case support for transport mode NAT traversal requirements NAT detection (including NAT position) Endpoint addresses (for transport checksums in transport mode) Three way handshake Multi-homing requirements Peer address sets Mobility requirements Strong sequencing of updates Fine grain (i.e., per SA) updates Proposal Kept points from draft 04 Address stability in exchanges (in vs between) Peer address specification and role Small points Proxy case support (for transport mode) INITIAL-CONTACT (lookup by Identity) Peer address protection Address notifications Protection request by the responder Protection request by the initiator Error case(s) Address pairing (optional, for multi-homing) Implicit address update Not for IPsec SAs Not for IKE SA Explicit address update The new notification Sequencing requirement All SAs short update From owner-ipsec Mon Jan 27 10:40:41 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07283 Mon, 27 Jan 2003 10:31:03 -0500 (EST) Message-Id: <200301271515.h0RFFMof029737@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: a proposal of address management for IKEv2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <29730.1043680514.0@givry.rennes.enst-bretagne.fr> Date: Mon, 27 Jan 2003 16:15:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29730.1043680514.1@givry.rennes.enst-bretagne.fr> I've just finished to write my draft about a proposal of address management for IKEv2. I've put it in an attachement to this message and I'll submit it as soon as most of the obvious mistake I've made what signaled and fixed. Francis.Dupont@enst-bretagne.fr ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29730.1043680514.2@givry.rennes.enst-bretagne.fr> Content-Description: draft-dupont-ikev2-addrmgmt-00.txt Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in June 2003 January 2003 Address Management for IKE version 2 Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract The current IKEv2 proposal [1] lacks an address management feature. As it includes a NAT traversal capability, this document extends it to a complete address management with support for NAT traversal, multi-homing and mobility. 1. Introduction In this document, the addresses used to transport IKE messages are named the "peer addresses" (term introduced by [2]). These peer addresses should no more be directly or indirectly included in identities ([3] and [4]) as it is commonly done for IKEv1. draft-dupont-ikev2-addrmgmt-00.txt [Page 1] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 NAT traversal, multi-homing and mobility should take benefit from this flexibility but the current IKEv2 draft [1] takes only account of NAT traversal in a flawed way [5]. This document describes the goals of an address management for IKEv2, including the requirements for NAT traversal, multi-homing and mobility support, and finishes by a concrete proposal. 2. Goals The goals of the address management proposed in the document can be divided in some general goals and in requirements for the three mechanisms which can change the peer addresses. 2.1 General goals 2.1.1 Simplicity, Performance and Security The address management should be as simple as possible, i.e., it should introduce minimal changes to the current IKEv2 draft [1] and each changes should be justified. The performance is an important criterion. For instance, rekeying can update the peer addresses of an IKE SA or of an IPsec SA pair, but rekeying is too expensive and a specific solution is needed. As a security protocol, IKEv2 should get a high security level. Unfortunately we already showed that the NAT traversal feature comes with a security issue (the transient pseudo-NAT attack [5]). Such problems introduced by the peer address flexibility must be described in this document and at least be mitigated by options in configurations. For instance, the NAT traversal feature should never be enabled when one knows that there can not be a NAT as in today IPv6. 2.1.4 Extensions of the IKEv2 draft The first things to fix in the current IKEv2 draft [1] are the notifications for NAT traversal (NAT-DETECTION-*-IP): - They use a hash of the SPIs, address and port, following a specification for IKEv1. This makes no sense for IKEv2. - There is no specified way to request the inclusion of these notifications in messages. - There can be multiple source notifications. IMHO this is a good idea but the rationale (the sender does not know what address it uses) is weak. The API to get the address used for UDP packets to a destination is very standard. draft-dupont-ikev2-addrmgmt-00.txt [Page 2] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 The second missing thing in the current IKEv2 draft [1] is about some misusage of the peer addresses: - At the reception of a message, the lookup of the corresponding IKE SA MUST be done using only the SPIs, never using the peer addresses. - An INITIAL-CONTACT notification deletes old IKE SAs associated to the peer Identity, not to the peer address. Current wording is misleading. - The revised identity proposal [3] should be integrated in the IKEv2 specifications. According to IAB recommendations [4], addresses should not be used as or associated to identities. Note that the last point stresses the issue of the lack of protection of peer addresses. The last thing to fix in the current IKEv2 draft [1] is the support of the proxy case: the setup of transport mode IPsec SAs on the behalf of another party. 2.2 NAT traversal requirements The NAT traversal feature is the support of en-route peer address modifications: - NATs must be detected, including their position, i.e., the receiver of an IKE message should be able to detect any peer address alteration. - The peer addresses are included in the pseudo IP header of transport checksums when a transport mode IPsec SA is used. The peers must know the original peer address of their correspondent. - When there are several VPN clients behind a NAT, the ability to request a three way handshake (a.k.a. a return routability check) is needed [6]. 2.3 Multi-homing requirements In this document, the support of multi-homing is the support of nodes with several global addresses. Some of the addresses can be "better" than others, or "better" for some destinations. Some can, from time to time, be unavailable. draft-dupont-ikev2-addrmgmt-00.txt [Page 3] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 The main requirement for the support of multi-homing is the management of a set of peer addresses for each peer. The set can be partially ordered or some subset can be loosely associated with some destinations (i.e., some subset of the other peer address set). For the communication between multi-addressed hosts, the support of the proxy case can be useful because it provides an easy way to setup transport mode IPsec SAs with different addresses from one IKE SA. In such cases the other party is in fact the same host, this dramatically simplifies the authorization issue. 2.4 Mobility requirements In the context of Mobile IPv6 ([7] and for the special case of Home Agents [8]), the interaction of Mobility and IPsec was analyzed in another document [9]. This document assumes an IPv6 context as Mobile IPv6 is the most powerful mobility proposal available today. An IPv6 mobile node is another type of multi-addressed node with: - a care-of address in a prefix of the visited link. The care-of address is used to route packets. - the home address in a prefix of the home link. The home address is used to identify the mobile node. The care-of address is transient and usually the mobile node can not provide a proof that it is the node using it. So it must be trusted and a return routability check (i.e., an enforced answer from this address) should be used if it is not. With a common correspondent, the mobility is transparent and there is no reason to use another address than the home address. With the home agent, there are three main cases (c.f. [8]): - The mobility signaling which is mandatory protected and raises a specific issue in its initial phase: the IKE SA must be setup using the care-of address as the peer address but this IKE SA is used to build an IPsec SA pair with the home address as traffic selector. This IPsec SA will protect the home registration which will make the home address available. This can be considered as a special proxy case. draft-dupont-ikev2-addrmgmt-00.txt [Page 4] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 - Other genuine communications between the home agent and the mobile node can be covered by the proxy case support too. Note this is the only case at the exception of signaling where mobility behaves in a different way than a mobile IPsec VPN (so we proposed to relax the corresponding rule in a future version of [7] and [8]). - The traffic relayed by the home agent through a tunnel with the mobile node can be partially or fully protected by IPsec SA pair(s). Encapsulation should be performed only once, including for degenerated (but not for free) encapsulation like the home address option or the mobility routing header. In all cases of interaction with the home agent, the mobile node peer address should be a care-of address. When the mobile node moves, another care-of address is used and some SAs, including the IKE SA, must be updated to use the new address. Usually the previous peer address is no more usable. In order to avoid a trivial denial of services, a strong sequencing of updates is required with a way to cancel possible pending updates when fast multiple handoff happen. The IPsec pair which protects the mobility signaling uses the home address as its traffic selector for the mobile node. It must not be updated at each handoff. The update mechanism must provide a fine grain (i.e., per SA) update. 3. Proposal The proposal for an address management in IKEv2 is mainly an extension of the NAT traversal notifications with a new peer address update notification. But there are some points that have to be kept as they are in the current IKEv2 draft [1]. 3.1 Kept points from draft 04 A peer address change has to be supported but not at any time: the peer addresses MUST NOT change during an exchange, i.e., they are allowed to change only between two exchanges. This address stability requirement applies in fact only to the Initial exchange as it is the only exchange with more than two messages specified today. draft-dupont-ikev2-addrmgmt-00.txt [Page 5] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 The peer addresses are used to transport messages. The reply to a request MUST be sent to the source of the request from the destination request, i.e., addresses and ports are reversed between the request and its reply. For tunnel mode IPsec SAs, the endpoint addresses are the peer addresses. We don't propose an alternate way to specify them. The same requirement applies to transport mode IPsec SAs at the exception of the proxy case. 3.2 Small points In the proxy case, the initiator is acting as a client negotiator on the behalf of another party. The address of this other party is sent in the initiator traffic selector and will become the address of this end of the transport mode IPsec SA pair. A proper authorization in the local policy of the responder is REQUIRED. Note that the IPsec SAs built in such cases are not managed in the proposal of these document, and that the proxy case is limited to the transport mode. The INITIAL-CONTACT notification uses only identities. All the references to peer addresses must be removed from or fixed in the current wording. 3.3 Peer address notifications The peer address notifications replace the current NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP notifications. They includes the peer source or destination address and the source or destination port. They SHOULD be used only in protected messages (i.e., not in the first two messages) and SHOULD be ignored when they are not protected, i.e., outside an encrypted payload. For NAT traversal, they are used to detect NATs and their position, and they provide the original peer addresses for transport mode. For multi-homing and mobility, they provide a cryptographically proof of no alteration en-route of the peer addresses and, when multiple peer address notifications for the same peer are included, they encode its whole peer address set. Note: IMHO a whole/partial set flag is needed. draft-dupont-ikev2-addrmgmt-00.txt [Page 6] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 A new notification has to be defined for the peer address notification request by the responder. Typically a responder asking for either NAT traversal or a peer address protection (i.e., the opposite) will put this notification in the second message of the initial exchange. All following messages MUST include the requested peer address notifications. Note: is a way to request source or destination protection needed? For the initiator a simple way to request peer address notifications is to include then in requests: when peer address notifications are required, peer address notifications MUST be included in the encrypted payload of requests. When a peer address notification is included in a request, peer address notifications are required, all following messages MUST include the peer address protection notification(s), beginning by the reply message. If multiple peer address notifications for the same peer are included in a message, the first one SHOULD for the source and MUST for the destination be the used peer address. The extra addresses describe the other possible peer addresses, i.e., there is at least one peer address notification per address in the peer address set. In order to associate some possible peer source addresses to possible peer destination addresses, the source and destination peer addresses notifications MAY be mixed (i.e., not in the common order source(s) first, destination(s) after). For instance S1, S2, D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction with D1, S3 with D2 or D3. When a peer can not find its peer addresses in the peer address notifications for its side, if NAT traversal is disabled then it MUST reject the compromised message and send an error notification to its peer, if NAT traversal is enabled it SHOULD take proper actions when a NAT is detected, for instance switch to the port 4500. This applies only to protected peer address notifications. 3.4 Implicit address update For address update, there is a choice between implicit and explicit mechanisms for IPsec SAs and IKE SAs. We claim that the implicit mechanism for IPsec SAs is far too unsecure: this mechanism is very (too?) simple. When a packet is received from another address, the peer addresses of the IPsec SA pair are updated. This opens the door to easy denial of service attacks and assumes extra-processing by the receiver device. draft-dupont-ikev2-addrmgmt-00.txt [Page 7] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 For the implicit mechanism for IKE SAs the things are even simpler. The implicit mechanism is mainly activated by keepalive exchanges: to switch from the implicit mechanism to the explicit one, only an update notification has to be included. The real difference is in the explicit case an observed peer address change is only a trigger. Note: should we specify a mechanism to advertise the other peer? It seems that NAT traversal needs it or should use an update all SAs in all IKE SA keepalive messages. 3.5 Explicit address update The explicit mechanism MUST be used. A new notification has to be defined. We propose to copy it from the delete notification. The new peer address notification has strong sequencing requirements. It MUST be processed in order and when a pending exchange with a peer address update has to be overrided by a more recent one, the peer address update notification MUST be canceled. Note: IKEv2 messages have a sequence number so the only sequencing issues are the window of processing and pending exchanges. Note: there are two obvious ways to cancel it (remove it from the message or define a cancellation flag) but both modify the message. When the receiver of an update request has to check the validity of the new peer address, it MAY use a return routability check sending an informational request at the new address and waiting for an answer. As informational exchanges are protected no more is needed. Example of a return routability check: I --- address update request --> R I <-- informational RR request - R I --- informational RR reply --> R now the responder knows the initiator should be where it said. I <--- address update reply ---- R As for the delete notification, the peer address update notification specifies the SPIs of the IPsec and IKE SAs it applies to. But a simple way to specify all SAs (i.e., the IKE SA and all the IPsec SAs it negotiated) is needed. Note: the "all SAs" MUST NOT be used when there is a proxy case SA pair. draft-dupont-ikev2-addrmgmt-00.txt [Page 8] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 4. Security Considerations Great care was used to avoid to introduce security threats. The NAT traversal feature comes with a security flaw (the transient pseudo-NAT attack [5]) which can not be easily avoid. IMHO the NAT traversal feature should be enabled only when the presence of NATs is likely/possible. When the NAT traversal feature is disabled, the other peer address can not be changed en-route by an attacker but the proofs the peer is really at its address are: - the trust in the peer - the proof that the peer can receive messages sent to its address The second (a.k.a. the return routability check) works only with at least three messages, i.e., for the initial exchange (with the address stability requirement) and for the explicit optional checks. IMHO these checks SHOULD be required by default. 5. Acknowledgments The need for an address management for IKEv2 was explained at the ipsec session of the Yokohama IETF meeting. It seems most people agree but do not propose concrete solutions. The rare people in the Mobility world with IPsec interests, or in the IPsec world with Mobility interest, should receive all thanks because without them we (me and all the future co-authors) have given up for a long time. 6. Normative References None? 7. Informative References [1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", draft-ietf-ipsec-ikev2-04.txt, January 2003. [2] B. Korver, E. Rescorla, "The Internet IP Security PKI Profile of ISAKMP and PKIX", draft-ietf-ipsec-pki-profile-01.txt, October 2002. [3] P. Hoffman, "Adding revised identities to IKEv2", http://www.vpnc.org/ietf-ipsec/, Message-Id: , November 2002. [4] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", RFC 2956, October 2000. draft-dupont-ikev2-addrmgmt-00.txt [Page 9] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 [5] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", draft-dupont-transient-pseudonat-01.txt, December 2002. [6] Jayant Shukla, "RE: peer address protection and NAT Traversal", http://www.vpnc.org/ietf-ipsec/, Message-ID: <000201c2bb27$e7021ff0$5803a8c0@trlhpc1>, January 2003. [7] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-20.txt, January 2003. [8] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-02.txt, January 2003. [9] F. Dupont, "How to make IPsec more mobile IPv6 friendly", draft-dupont-ipsec-mipv6-02.txt, January 2003. 9. Author's Address Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr draft-dupont-ikev2-addrmgmt-00.txt [Page 10] ------- =_aaaaaaaaaa0-- From owner-ipsec Mon Jan 27 16:10:13 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07998 Mon, 27 Jan 2003 15:54:46 -0500 (EST) Message-Id: <5.2.0.9.2.20030127155047.00bcc998@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 27 Jan 2003 15:56:53 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Ciphersuites for IKEv2 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I support Paul Hoffman's posting regarding MUST implement and SHOULD implement cipher suites. The first thing that I really like is that it includes rationale. Further, it allow the working group to tell implementors what the next set of algorithms that are likely to become MUST implement. I categorize them as follows. MUST implement algorithms - - widely deployed, secure against today's perceived threat, acceptable performance - support backward compatibility with previous generation SHOULD implement algorithms - - best guess at the next generation of algorithms MAY implement algorithms - - everything else Paul's proposal supports this categorization. Russ >Given the looming deadline for us to finish on IKEv2, we need to come to >some agreement on ciphersuites. The following comments are based on the >-04 draft. > >In section 5.3.1, it says: > > >For Suite-ID, the following values are defined: > > > > Name Number Algorithms > > IKE_CLASSIC 0 DH-Group #5 (1536 bits) > > 3DES encryption > > HMAC-SHA1 integrity and prf > > > > ESP_CLASSIC 1 3DES encryption > > HMAC-SHA1 integrity > > > > > values 2-65000 are reserved to IANA. Values 65001-65533 are > > for private use among mutually consenting parties. > >Later, in section 5.14, it says: > > > The mandatory to implement algorithms are AES-128-CBC and HMAC-SHA1. > > >So far, this list hasn't been able to agree on whether these are good >values, mostly due to people having different priorities. I propose that >the priority we choose for creating the MUST implement suite be that of >greatest interoperability. This means that we should not expect any >current IPsec vendor who has hardware acceleration to need to make >hardware upgrades to their IPsec devices. > >Beyond that, we should also define suites that are expected to be used >in typical circumstances, but we should not attach a MUST or even a >SHOULD to those suites. We should also *not* name the suites because the >names will impart meaning in the future that may not be true. For >example, the name "IKE_CLASSIC" implies that the values are those used >by typical IKEv1 systems, but that is not true because many systems >don't even implement DH Group 5 (even though they obviously should). > >Given those criteria, I propose that the following text be used in >section 5.3.1 (and the text noted above in section 5.14 be removed): > >===== > >For Suite-ID, the following values are defined: > >Suite-ID Meaning >-------- ------- >0 Covers: IKE > 168-bit 3DES CBC encryption > Diffie-Hellman group 2 (1024-bit) > HMAC-SHA1 integrity and prf > >1 Covers: ESP > 3DES encryption with three keys > HMAC-SHA1 integrity > >2 Covers: AH > HMAC-SHA1 integrity > >3 Covers: IKE > 168-bit 3DES CBC encryption > Diffie-Hellman group 5 (1536-bit) > HMAC-SHA1 integrity and prf > >4 Covers: IKE > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 5 (1536-bit) > HMAC-SHA1 integrity and prf > >5 Covers: IKE > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit) > HMAC-SHA1 integrity and prf > >6 Covers: ESP > AES encryption in CBC mode with 128-bit keys > HMAC-SHA1 integrity > >7 Covers: IKE > AES encryption in CTR mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit) > AES-CBC MAC + XCBC integrity and prf > >8 Covers: ESP > AES encryption in CTR mode with 128-bit keys > AES-CBC MAC + XCBC integrity > >Values 9-65000 are reserved to IANA. Values 65001-65533 are for private >use among mutually consenting parties. Additional Suite-ID values will >be assigned by IANA based on consultation with the IESG. > >All implementations of IKEv2 MUST be able to negotiate Suite-ID 0 and >Suite-ID 1. Implementations SHOULD be able to negotiate Suite-IDs 3, 4, >5, and 6. > >The must-be-implemented ciphersuites (0 and 1) are based on >currently-deployed hardware that meets the security requirements of the >vast majority of current IPsec users, and should be useful for at least >a decade according to cryptographic estimates from NIST for business >user scenarios. The should-be-implemented ciphersuites (3, 4, 5, and 6) >are based on expectations of where the security industry is moving >(namely, to the AES encryption suite) and where more security-conscious >users are moving as current key lengths become more attackable due to >the steady lowering of cost to mount brute-force attacks. > >An important lesson learned from IKEv1 is that no system should only >implement the mandatory algorithms and expect them to be the best choice >for all customers. For example, at the time that this document was being >written, many IKEv1 implementers are starting to migrate to AES in CBC >mode for VPN applications. Many IPsec systems based on IKEv2 will >implement AES, longer Diffie-Hellman keys, and additional hash >algorithms, and some IPsec customers already require these algorithms in >addition to the mandatory ones listed above. > >===== > >Possible issues: > >- Some people may want to have more suites as fallbacks in case of >a catastrophic failure of an algorithm. The WG seemed to want fewer >suites. This is why I had the IANA registry being updated with IESG >consultation instead of a standards-track RFC: we could get a number >easily for a non-compromised suite. Having a zillion suites defined >early won't cause implementers to handle them; note that TIGER was >a SHOULD in IKEv1 and almost no one implemented it at all. > >- Should the ESP and AH MUST and SHOULDs be in the IKEv2 document or >in 2401bis? I think they should be in IKEv2, but others have said that >because they cover IPsec themselves, they should be in 2401bis. > > >--Paul Hoffman, Director >--VPN Consortium From owner-ipsec Mon Jan 27 19:11:17 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08314 Mon, 27 Jan 2003 19:01:24 -0500 (EST) content-class: urn:content-classes:message Subject: RE: Ciphersuites for IKEv2 Date: Mon, 27 Jan 2003 17:04:09 -0700 Message-ID: <5AE0592A6AF6494F80CE87370A723B1F2344A3@azsmsx401.ch.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Ciphersuites for IKEv2 Thread-Index: AcLCKnfQO5n/lS4bEde/HABQi2jWFgEMqw+g X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 From: "Herbert, Howard C" To: Cc: , X-OriginalArrivalTime: 28 Jan 2003 00:04:11.0427 (UTC) FILETIME=[C92F3730:01C2C660] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA08311 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Per the admonition in David's email below, I would like to request that in addition to the following cipher suites already on the list: AES-CBC + HMAC-SHA-1 AES-CTR + AES-CBC MAC w/XCBC that the following additional cipher suites be added: AES-CBC + AES-CBC-MAC w/XCBC AES-CTR + HMAC-SHA-1 As noted above, these algorithms will already exist in an implementation. Not being able to use them in the added combinations simply because we do not have a ciphersuite defined for them seems like a real easy thing to fix at this point. In addition to the points made by David below, these additional combinations will also help implementers gain the full benefit of the investment that they are making and will allow users to utilize the full capability of the product that they are paying for. Howard -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Wednesday, January 22, 2003 8:14 AM To: ips@ece.cmu.edu Subject: FW: Ciphersuites for IKEv2 The ipsec WG is in the process of defining a new version of the IKE protocol for IPsec authentication, key exchange, SA creation and the like. A major change from the current IKE is that all cryptographic aspects of SA creation are bundled into suites for negotiation rather than being independently negotiable, as fewer combinations to implement and test increases the likelihood of interoperability and reduces the opportunities for things to go worng in peculiar combinations that are unlikely to be useful. This is part of a radical change to IKE/ISAKMP negotiation to fix a number of problems with the way it currently works. The proposal forwarded below has just been floated to define the initial suites. The most important aspect of it is that the proposed AES suite definitions bind encryption mode and integrity algorithm (MAC) together, specifically: - AES-CBC suites are only defined with HMAC-SHA1 (cannot use AES-CBC MAC w/XCBC) - AES-CTR suites are only defined with AES-CBC MAC w/XCBC (cannot use HMAC-SHA1) If this is a problem for anyone, they need to comment on the ipsec mailing list (ipsec@lists.tislabs.com) ASAP. Please read the entire message forwarded below (including the "Possible issues:" section at its end) before commenting. Also, please note that 3DES-CBC and HMAC-SHA1 will be "MUST implement", so hence there's not as much implementation advantage as might initially appear to AES-CBC + AES-CBC MAC w/XCBC as HMAC-SHA1 has to be there anyhow. Further discussion of this should be on the ipsec WG mailing list (ipsec@lists.tislabs.com) - this is just an FYI for IPS folks working with IPsec. None of this affects any requirements in the current IPS protocol specifications - this is an FYI about where this area of technology is headed. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, January 21, 2003 6:42 PM To: ipsec@lists.tislabs.com Subject: Ciphersuites for IKEv2 Given the looming deadline for us to finish on IKEv2, we need to come to some agreement on ciphersuites. The following comments are based on the -04 draft. In section 5.3.1, it says: >For Suite-ID, the following values are defined: > > Name Number Algorithms > IKE_CLASSIC 0 DH-Group #5 (1536 bits) > 3DES encryption > HMAC-SHA1 integrity and prf > > ESP_CLASSIC 1 3DES encryption > HMAC-SHA1 integrity > > values 2-65000 are reserved to IANA. Values 65001-65533 are > for private use among mutually consenting parties. Later, in section 5.14, it says: > The mandatory to implement algorithms are AES-128-CBC and HMAC-SHA1. So far, this list hasn't been able to agree on whether these are good values, mostly due to people having different priorities. I propose that the priority we choose for creating the MUST implement suite be that of greatest interoperability. This means that we should not expect any current IPsec vendor who has hardware acceleration to need to make hardware upgrades to their IPsec devices. Beyond that, we should also define suites that are expected to be used in typical circumstances, but we should not attach a MUST or even a SHOULD to those suites. We should also *not* name the suites because the names will impart meaning in the future that may not be true. For example, the name "IKE_CLASSIC" implies that the values are those used by typical IKEv1 systems, but that is not true because many systems don't even implement DH Group 5 (even though they obviously should). Given those criteria, I propose that the following text be used in section 5.3.1 (and the text noted above in section 5.14 be removed): ===== For Suite-ID, the following values are defined: Suite-ID Meaning -------- ------- 0 Covers: IKE 168-bit 3DES CBC encryption Diffie-Hellman group 2 (1024-bit) HMAC-SHA1 integrity and prf 1 Covers: ESP 3DES encryption with three keys HMAC-SHA1 integrity 2 Covers: AH HMAC-SHA1 integrity 3 Covers: IKE 168-bit 3DES CBC encryption Diffie-Hellman group 5 (1536-bit) HMAC-SHA1 integrity and prf 4 Covers: IKE AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 5 (1536-bit) HMAC-SHA1 integrity and prf 5 Covers: IKE AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 14 (2048-bit) HMAC-SHA1 integrity and prf 6 Covers: ESP AES encryption in CBC mode with 128-bit keys HMAC-SHA1 integrity 7 Covers: IKE AES encryption in CTR mode with 128-bit keys Diffie-Hellman group 14 (2048-bit) AES-CBC MAC + XCBC integrity and prf 8 Covers: ESP AES encryption in CTR mode with 128-bit keys AES-CBC MAC + XCBC integrity Values 9-65000 are reserved to IANA. Values 65001-65533 are for private use among mutually consenting parties. Additional Suite-ID values will be assigned by IANA based on consultation with the IESG. All implementations of IKEv2 MUST be able to negotiate Suite-ID 0 and Suite-ID 1. Implementations SHOULD be able to negotiate Suite-IDs 3, 4, 5, and 6. The must-be-implemented ciphersuites (0 and 1) are based on currently-deployed hardware that meets the security requirements of the vast majority of current IPsec users, and should be useful for at least a decade according to cryptographic estimates from NIST for business user scenarios. The should-be-implemented ciphersuites (3, 4, 5, and 6) are based on expectations of where the security industry is moving (namely, to the AES encryption suite) and where more security-conscious users are moving as current key lengths become more attackable due to the steady lowering of cost to mount brute-force attacks. An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. For example, at the time that this document was being written, many IKEv1 implementers are starting to migrate to AES in CBC mode for VPN applications. Many IPsec systems based on IKEv2 will implement AES, longer Diffie-Hellman keys, and additional hash algorithms, and some IPsec customers already require these algorithms in addition to the mandatory ones listed above. ===== Possible issues: - Some people may want to have more suites as fallbacks in case of a catastrophic failure of an algorithm. The WG seemed to want fewer suites. This is why I had the IANA registry being updated with IESG consultation instead of a standards-track RFC: we could get a number easily for a non-compromised suite. Having a zillion suites defined early won't cause implementers to handle them; note that TIGER was a SHOULD in IKEv1 and almost no one implemented it at all. - Should the ESP and AH MUST and SHOULDs be in the IKEv2 document or in 2401bis? I think they should be in IKEv2, but others have said that because they cover IPsec themselves, they should be in 2401bis. --Paul Hoffman, Director --VPN Consortium From owner-ipsec Mon Jan 27 20:19:26 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08585 Mon, 27 Jan 2003 20:09:33 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5AE0592A6AF6494F80CE87370A723B1F2344A3@azsmsx401.ch.intel.com> References: <5AE0592A6AF6494F80CE87370A723B1F2344A3@azsmsx401.ch.intel.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 27 Jan 2003 17:11:14 -0800 To: "Herbert, Howard C" , From: Paul Hoffman / VPNC Subject: RE: Ciphersuites for IKEv2 Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:04 PM -0700 1/27/03, Herbert, Howard C wrote: >I would like to request that in addition to the following cipher >suites already on the list: > >AES-CBC + HMAC-SHA-1 >AES-CTR + AES-CBC MAC w/XCBC > >that the following additional cipher suites be added: > >AES-CBC + AES-CBC-MAC w/XCBC >AES-CTR + HMAC-SHA-1 Could you explain your specific reasoning for adding these two? It will not increase interoperability or security. Is this for fallback in case of compromise of one of the hash algorithms? > Not being able to use them in the added combinations simply >because we do not have a ciphersuite defined for them seems like a >real easy thing to fix at this point. Not having an named ciphersuite does not prevent their use; it only prevents their interoperable use. For testing, you can always pick a number from the private number space. >In addition to the points made by David below, these additional >combinations will also help implementers gain the full benefit of >the investment that they are making and will allow users to utilize >the full capability of the product that they are paying for. Lots of implementations also implement 56-bit DES. Are you saying that we should therefore assign ciphersuites that use it? --Paul Hoffman, Director --VPN Consortium From owner-ipsec Tue Jan 28 00:39:12 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA09148 Tue, 28 Jan 2003 00:29:09 -0500 (EST) Message-ID: <3E3615A6.ECF65B60@soleil.ocn.ne.jp> Date: Tue, 28 Jan 2003 14:31:18 +0900 From: Alan Chung Reply-To: jrifsd4gfl@soleil.ocn.ne.jp Organization: Financial Link Ltd. X-Mailer: Mozilla 4.78 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: new to VPN Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am very new to this VPN technology. Currently I am reading the documentation around and have some questions on my mind. Could someone please give me an advice? 1. There seems so many types of VPN technologies such as GRE, IPSec, L2TP, PPTP, IP-IP Tunnel...as I have realized so far. To be honest, I am very confused and not sure which direction I should go in order to choose a good solution for my company. First, I wonder what type(s) of technology is generally evaluated as the most secure and widely used one? 2. There is even freeware such as Linux FreeS/WAN using IPSec technology. If so, is this secure enough to use for a big wide area network something above 500 people? Is it true that the hardware VPN solutions are always better, trusted and have higher secure level than software VPN? I am sorry to ask such general questions on this mailing list. But I really appreciate if someone can give me some help with this. Thank you very much. Alan From owner-ipsec Tue Jan 28 09:07:12 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10184 Tue, 28 Jan 2003 08:55:44 -0500 (EST) Message-Id: <5.1.0.14.0.20030127115651.00a78ac0@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 Jan 2003 14:04:20 -0500 To: Hugo Krawczyk From: David Jablon Subject: Re: A proposal Cc: IPsec WG In-Reply-To: References: <5.1.0.14.0.20030110230838.045dd440@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, Just one counterpoint, and some explanation: At 03:33 AM 1/23/03 +0200, Hugo Krawczyk wrote: >David, I do not think this whole issue is too important or that >people really care, ... I have no problem with you expressing *your* opinion. But evidence that some people do care about the whole issue of preventing MITM attack in a legacy credentials context has been, and should be, demonstrated by WG discussion. If, instead, "whole issue" refers to my proposed extension to SLA ... that's a different matter. >... and I am glad that you agree that the xor-based >solution would be an appropriate way to mix the additional key into >the key derivation. Yet I do not really like having the "compound >authentication" to happen (implicitly) at the level of key derivation. I also agree with your preference for explicit authentication, when possible. My proposed extension to SLA was deliberately limited in scope, and not meant to argue against such possibilities. >... >The main point in your response is that the weaknesses I point out are >possible only if one assumes "weaker" prfs than allowed by IKE (v2). >That's wrong. Indeed, I illustrated my attack using a block-cipher based >prf. There is NO cryptographic reason to assume that those are bad prf's, >actually they may turn out to be better than HMAC-SHA1. These prf's are >allowed (and should be allowed) by IKE as IKE remains secure with them. Fair enough, *except* that wasn't exactly my point. What I literally wrote was: > [Hugo's concern] is *only* valid > when one implements prf with a function that is significantly weaker > than HMAC, which is currently the only specifically described > instantiation in the IKEv2 draft. Your recharacterization reads way too much into that statement. I thought it was clear from the overall context of my reply, but just in case it wasn't: * I didn't intend to say that any proposed PRF was weaker as a pseudorandom function. By "weaker function" I was referring to relative weakness as a *key derivation function*, as in, for example, the function of prf in my proposal. * I didn't intend to say that any such function was necessarily any weaker for any context other than in my proposal. * I didn't intend to say that such a function was not allowed by IKEv2. (Though I wanted to imply that this might be a forgivable misinterpretation of the draft. Forgive me for trying.) To be clear, I'll take full blame for misreading it as "prf = only HMAC". I also appreciate the specific changes you've suggested for the draft that (even if for other reasons) clarify the definition and proper use of prf. I'll defer further comment on any remaining issues until they're relevant to a broader discussion. -- David From owner-ipsec Tue Jan 28 09:07:12 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10200 Tue, 28 Jan 2003 08:56:42 -0500 (EST) Message-Id: <200301281145.GAA21828@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-01.txt Date: Tue, 28 Jan 2003 06:45:16 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES CCM Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ccm-01.txt Pages : 11 Date : 2003-1-27 This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ccm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-27081546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ccm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-27081546.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Jan 28 11:22:05 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10649 Tue, 28 Jan 2003 11:11:50 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.44131.464641.710215@pkoning.dev.equallogic.com> Date: Tue, 28 Jan 2003 11:14:27 -0500 From: Paul Koning To: howard.c.herbert@intel.com Cc: ipsec@lists.tislabs.com, Black_David@emc.com, ips@ece.cmu.edu Subject: RE: Ciphersuites for IKEv2 References: <5AE0592A6AF6494F80CE87370A723B1F2344A3@azsmsx401.ch.intel.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Howard" == Howard C Herbert writes: Howard> Per the admonition in David's email below, I would like to Howard> request that in addition to the following cipher suites Howard> already on the list: Howard> AES-CBC + HMAC-SHA-1 AES-CTR + AES-CBC MAC w/XCBC Howard> that the following additional cipher suites be added: Howard> AES-CBC + AES-CBC-MAC w/XCBC AES-CTR + HMAC-SHA-1 Howard> As noted above, these algorithms will already exist in an Howard> implementation. Not being able to use them in the added Howard> combinations simply because we do not have a ciphersuite Howard> defined for them seems like a real easy thing to fix at this Howard> point. The whole point of cipher suites is NOT to expose the O(2^n) combinations. There may be valid reasons to add suites, but "the components already exist" surely is not a valid reason. paul From owner-ipsec Tue Jan 28 17:46:22 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11582 Tue, 28 Jan 2003 17:26:37 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 28 Jan 2003 12:30:10 -0500 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: Ciphersuites for IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I like your analysis and suggestions for MUSTs and SHOULDs. I endorse your proposal. You also asked: >- Should the ESP and AH MUST and SHOULDs be in the IKEv2 document or >in 2401bis? I think they should be in IKEv2, but others have said that >because they cover IPsec themselves, they should be in 2401bis. I'm happy to include these ESP/AH suites in 2401 if the WG AGREES. There is one other feature I would like to see in IKEv2 that is somewhat related to the suites (for IKE). As I noted earlier, some user groups are sophisticated enough to want to define their own groups, for local use. Your proposal allocates a reasonable number of values for private use, so there is no impediment there. But it seems that we still lack a MUST for IKEv2 that facilities private group management support, to ensure that users/admins (not just vendors) can define additional, private groups. Any suggestions of how to define that capability? Steve From owner-ipsec Wed Jan 29 11:55:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14219 Wed, 29 Jan 2003 11:45:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IPsec and IKE in an dynamic NAT environment Date: Wed, 29 Jan 2003 17:43:50 +0100 Message-ID: <24EA9B0638C2AD448F3C2E95E3209ECF40F777@shrdc1.biodata.com> Thread-Topic: [VPN] New security tool: ike-scan (IPsec IKE scanner) released Thread-Index: AcLHCIk4O65cIPGlSIORMRGTeRudjgAqVGbQAADppfA= From: "Nicolas Saurbier" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA14216 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, this is the first time, I post into this list, so "Hi everybody!!!" Now I need a little help: Situation: I have a VPN-Gateway with an official IP-address attached directly to the internet. I have a Router that does ISDN dial-up to my ISP. The Router doesn´t get a fixed IP-address. The Router is doing Masquerading (192.168.0.0/24 => x.x.x.x/32) How it should work: The users in my 192.168.0.0/24 network shall use Software IPsec-clients, I chose "SSH Sentinel 1.4". My problem is, that the IKE is working fine, but the VPN-Gateway denies all incoming esp-packets and sends back an ICMP-packet "Proto 50 unreachable" SSH Sentinel has got an option called "NAT traversel"....did any1 of you ever work with SSH Sentinel??? Any1 of you doing the same as me? NIC From owner-ipsec Wed Jan 29 12:19:18 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14306 Wed, 29 Jan 2003 12:16:18 -0500 (EST) Message-ID: <3E380CDD.DE18C07D@nokia.com> Date: Wed, 29 Jan 2003 09:18:21 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jrifsd4gfl@soleil.ocn.ne.jp CC: ipsec@lists.tislabs.com Subject: Re: new to VPN References: <3E3615A6.ECF65B60@soleil.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2003 17:18:22.0295 (UTC) FILETIME=[6CCC0670:01C2C7BA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 1. There seems so many types of VPN technologies such as GRE, IPSec, > L2TP, PPTP, IP-IP Tunnel...as I have realized so far. > To be honest, I am very confused and not sure which direction I > should go in order to choose a good solution for my company. > First, I wonder what type(s) of technology is generally evaluated as > the most secure and widely used one? Except IPsec, all of the mentioned technologies are for just tunnelling and not for security. You could tunnel the traffic using any of those technologies but then you will need to use some encryption/authentication technology in order to secure your traffic. IPsec is the obvious choice there. > 2. There is even freeware such as Linux FreeS/WAN using IPSec > technology. If so, is this secure enough to use for a big wide area > network something above 500 people? "secure enough" is not a deterministic term and it is the encryption algorithm that decides how secure your VPN is, not the technology. > Is it true that the hardware VPN solutions are always better, > trusted and have higher secure level than software VPN? I don't think so. AFAIK, hardware VPN solution would just be faster than software VPN. HTH, - Mukesh From owner-ipsec Wed Jan 29 14:59:11 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14776 Wed, 29 Jan 2003 14:50:13 -0500 (EST) Date: Wed, 29 Jan 2003 11:02:03 -0800 Message-Id: <200301291902.h0TJ22n03176@localhost.localdomain> From: John Lindal X-Mailer: Arrow 2.0b3 (X11; Linux 2.4.2-2; i686) To: Subject: Re: new to VPN Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Is it true that the hardware VPN solutions are always better, >> trusted and have higher secure level than software VPN? > > I don't think so. AFAIK, hardware VPN solution would just be faster than > software VPN. Custom hardware always has the potential to be faster than software running on standard hardware. However, standard hardware is now so fast that there is little reason to bother with custom hardware any longer. It is possible to get approx. 20Mb/sec using 256 bit AES on a 1GHz Pentium 3 processor. (AFAIK, most cheap VPN boxes provide only one or at most a few Mb/sec.) John From owner-ipsec Wed Jan 29 15:57:42 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14881 Wed, 29 Jan 2003 15:54:50 -0500 (EST) Message-ID: From: "Vohra, Meenakshi" To: ipsec@lists.tislabs.com Subject: VPN Client/Gateway with IKE Keep-Alives Date: Wed, 29 Jan 2003 12:30:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C7D5.32A48740" 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_01C2C7D5.32A48740 Content-Type: text/plain; charset="ISO-8859-1" Hello Everyone, I am looking for a VPN Gateway or a VPN Client which supports IKE Keep-Alives( mainly as a means for SA cleanup). Any suggestions on some vendors which can be used for testing this feature. Thanks, -Meenakshi ------_=_NextPart_001_01C2C7D5.32A48740 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable VPN Client/Gateway with IKE Keep-Alives Hello Everyone, I am looking for a VPN Gateway or a = VPN Client which supports IKE Keep-Alives( mainly as a means for SA = cleanup). Any suggestions on some vendors which can be used for testing = this feature. Thanks, -Meenakshi ------_=_NextPart_001_01C2C7D5.32A48740-- From owner-ipsec Wed Jan 29 17:24:03 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15063 Wed, 29 Jan 2003 17:20:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15928.25124.110000.75173@gargle.gargle.HOWL> Date: Wed, 29 Jan 2003 18:22:12 -0500 From: Paul Koning To: jafl@trlokom.com Cc: ipsec@lists.tislabs.com Subject: Re: new to VPN References: <200301291902.h0TJ22n03176@localhost.localdomain> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "John" == John Lindal writes: >>> Is it true that the hardware VPN solutions are always better, >>> trusted and have higher secure level than software VPN? >> I don't think so. AFAIK, hardware VPN solution would just be >> faster than software VPN. John> Custom hardware always has the potential to be faster than John> software running on standard hardware. However, standard John> hardware is now so fast that there is little reason to bother John> with custom hardware any longer. It is possible to get John> approx. 20Mb/sec using 256 bit AES on a 1GHz Pentium 3 John> processor. (AFAIK, most cheap VPN boxes provide only one or at John> most a few Mb/sec.) Perhaps the cheap boxes you looked at are software-based? Or perhaps they are limited because they have slow network interfaces? For instance, a T1 router or VPN box intended for use with cable modems or DDSL has no use for multi-megabit performance because the wire isn't that fast. High end crypto chips are running now at several gigabits/second, and it's not hard to find applications that have a use for those sort of numbers. (Whether they are willing to pay for the cost of that hardware is quite another matter, though.) So yes, the software implementations are getting faster, but the bandwidth hogs are getting faster, too. paul From owner-ipsec Wed Jan 29 21:42:42 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA15458 Wed, 29 Jan 2003 21:28:35 -0500 (EST) Date: Wed, 29 Jan 2003 20:45:11 -0500 (EST) From: Viswanath Neelavalli To: ipsec@lists.tislabs.com Subject: Hi In-Reply-To: <15928.25124.110000.75173@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I have been following this discussion board for over 3 weeks now and it has helped me try to keep updated with latest happenings. I want to seek advice on a problem I am facing at my company. I am able to establish an L2TP/IPSec VPN connection between 2 Windows2K Advanced Server machines on the same physical LAN.(i.e. they both have the same netid). I properly configured one ofthem as the VPN Server and also made it a Standalone CA for issueing Certifcates. BTW, I am using certificates for the authentication. I make a Dial-Up-Networking VPN coneection from the client. In the "Local Security Policy" of both the machines, I set it to "Secure Server(Require Security)". When I make the connection..I sniff the packet using Ethereal. I can see encrypted ESP traffic..fine. But If I try to make a telnet connection from the client to the server, I can clearly see the text passing thru. In effect, there dones not seem to be any encryption taking place, or I dont know if am mis-reading something seriously. Any prompt pointers or ideas on this will be greatly appreciated..as I am facing a lot of heat from by boss. Many thanks in advance. Best Regards, Viswanath. From owner-ipsec Wed Jan 29 22:58:40 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA15580 Wed, 29 Jan 2003 22:55:32 -0500 (EST) From: "Jayant Shukla" To: "'Mukesh Gupta'" , Cc: Subject: RE: new to VPN Date: Wed, 29 Jan 2003 19:56:11 -0800 Message-ID: <00a501c2c813$871aa780$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E380CDD.DE18C07D@nokia.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Mukesh Gupta > > Is it true that the hardware VPN solutions are always better, > > trusted and have higher secure level than software VPN? > On the contrary, I think software solutions are becoming more secure than the hardware solutions. If you look at technologies related to intrusion prevention or known/unknown Trojan detection, the software solutions have a much better edge. > I don't think so. AFAIK, hardware VPN solution would just be faster than > software VPN. > Fastest VPNs today are hardware solutions, but software VPNs are not too bad. I run a VPN that can sustain almost 24 Mb/s using 1GHz PIII laptop. For a customer we are building a VPN (without any custom hardware) to achieve 1 Gb/s using load balancing. In the end, whatever suits your requirements is the best solution, be it hardware or software. Regards, Jayant www.trlokom.com Fee VPN & Firewall: http://www.tucows.com/preview/295100.html From owner-ipsec Wed Jan 29 23:11:32 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA15636 Wed, 29 Jan 2003 23:09:47 -0500 (EST) From: "Jayant Shukla" To: Subject: RE: new to VPN Date: Wed, 29 Jan 2003 20:10:23 -0800 Message-ID: <00bd01c2c815$82c237f0$5803a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Mukesh Gupta > > Is it true that the hardware VPN solutions are always better, > > trusted and have higher secure level than software VPN? > On the contrary, I think software solutions are becoming more secure than the hardware solutions. If you look at technologies related to intrusion prevention or known/unknown Trojan detection, the software solutions have a much better edge. > I don't think so. AFAIK, hardware VPN solution would just be faster > than software VPN. > Fastest VPNs today are hardware solutions, but software VPNs are not too bad. I run a VPN that can sustain almost 24 Mb/s using 1GHz PIII laptop. For a customer we are building a VPN (without any custom hardware) to achieve 1 Gb/s using load balancing. In the end, whatever suits your requirements is the best solution, be it hardware or software. Regards, Jayant www.trlokom.com From owner-ipsec Thu Jan 30 11:56:55 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17077 Thu, 30 Jan 2003 11:49:28 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 30 Jan 2003 08:50:57 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Ciphersuites for IKEv2, revised Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Based on feedback from the list and offline, here is revised wording for the ciphersuites in IKEv2. The changes are: - clarified where the various Diffie-Hellman groups are defined - changed the split between what is reserved for IANA and what is for private use - added a paragraph to the end of the addition to 5.3.1 to specify that users should be able to use future and private-use Suite-IDs - added a note in Appendix B and a new reference The following text be should be used in section 5.3.1: ===== For Suite-ID, the following values are defined: Suite-ID Meaning -------- ------- 0 Covers: IKE 168-bit 3DES CBC encryption Diffie-Hellman group 2 (1024-bit), defined in Appendix B.2 HMAC-SHA1 integrity and prf 1 Covers: ESP 3DES encryption with three keys HMAC-SHA1 integrity 2 Covers: AH HMAC-SHA1 integrity 3 Covers: IKE 168-bit 3DES CBC encryption Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5 HMAC-SHA1 integrity and prf 4 Covers: IKE AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5 HMAC-SHA1 integrity and prf 5 Covers: IKE AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP] HMAC-SHA1 integrity and prf 6 Covers: ESP AES encryption in CBC mode with 128-bit keys HMAC-SHA1 integrity 7 Covers: IKE AES encryption in CTR mode with 128-bit keys Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP] AES-CBC MAC + XCBC integrity and prf 8 Covers: ESP AES encryption in CTR mode with 128-bit keys AES-CBC MAC + XCBC integrity Values 9-32000 are reserved to IANA. Values 32001-65533 are for private use among mutually consenting parties. Additional Suite-ID values will be assigned by IANA based on consultation with the IESG. All implementations of IKEv2 MUST be able to negotiate Suite-ID 0 and Suite-ID 1. Implementations SHOULD be able to negotiate Suite-IDs 3, 4, 5, and 6. The must-be-implemented ciphersuites (0 and 1) are based on currently-deployed hardware that meets the security requirements of the vast majority of current IPsec users, and should be useful for at least a decade according to cryptographic estimates from NIST for business user scenarios. The should-be-implemented ciphersuites (3, 4, 5, and 6) are based on expectations of where the security industry is moving (namely, to the AES encryption suite) and where more security-conscious users are moving as current key lengths become more attackable due to the steady lowering of cost to mount brute-force attacks. An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. For example, at the time that this document was being written, many IKEv1 implementers are starting to migrate to AES in CBC mode for VPN applications. Many IPsec systems based on IKEv2 will implement AES, longer Diffie-Hellman keys, and additional hash algorithms, and some IPsec customers already require these algorithms in addition to the mandatory ones listed above. It is likely that IANA will add additional Suite-IDs in the future, and some security-conscious users will want to use private-use Suite-IDs. All implementations SHOULD be able to let users set policies that use Suite-IDs from the currently-unassigned IANA values and from the private use values. Of course, there is no standard way to handle all possible new algorithms, Diffie-Hellman groups, and combinations thereof. However, many IPsec users will want to base security policies on Suite-IDs that are not covered in this document and SHOULD be able to do so. ===== Add the following to just before Appendix B.1: Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Future IANA-registered and private use Suite-IDs MAY use Diffie-Hellman groups that have prime values and generators that are different than those in this document or in [ADDGROUP]. Add to the non-normative references: [ADDGROUP] Kivinen, T. et. al., "More MODP Diffie-Hellman groups for IKE", draft-ietf-ipsec-ike-modp-groups-05.txt, in RFC Editor's queue for Proposed Standard. --Paul Hoffman, Director --VPN Consortium From owner-ipsec Thu Jan 30 12:57:46 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17327 Thu, 30 Jan 2003 12:54:42 -0500 (EST) Message-Id: <200301301757.h0UHvBww031090@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: new to VPN In-reply-to: Your message of "Wed, 29 Jan 2003 19:56:11 PST." <00a501c2c813$871aa780$5803a8c0@trlhpc1> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jan 2003 12:57:10 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jayant" == Jayant Shukla writes: Jayant> [mailto:owner-ipsec@lists.tislabs.com] >> On Behalf Of Mukesh Gupta > Is it true that the hardware VPN solutions >> are always better, > trusted and have higher secure level than >> software VPN? >> Jayant> On the contrary, I think software solutions are becoming more Jayant> secure than the hardware solutions. If you look at technologies Jayant> related to intrusion prevention or known/unknown Trojan Jayant> detection, the software solutions have a much better edge. >> I don't think so. AFAIK, hardware VPN solution would just be faster Jayant> than >> software VPN. >> Jayant> Fastest VPNs today are hardware solutions, but software VPNs are Jayant> not too bad. I run a VPN that can sustain almost 24 Mb/s using Jayant> 1GHz PIII laptop. For a customer we are building a VPN (without Jayant> any custom hardware) to achieve 1 Gb/s using load balancing. There are two reasons to go to hardware: 1) speed. Money is no object. Speed is. 2) power. Money (heat!) is the object. Speed isn't. There are a growing number of VPN capable boxes that employ management processors of around 100Mhz, (not ix86) with rather limited power budgets. They are using comodity cipher chips with power budgets that rival that of the fan on the GHz PIII. It is these devices where we will see the most impact of IPsec technology - they are often embedded network elements of various sorts. But, I agree with Jayant - for anyone for whom money is an object, but power consumption is not (anyone not living in California :-]), but moderate speed is also, a PIII is very hard to beat. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjlndIqHRg3pndX9AQE0JgQAucHJe1+/krC6ZPQU88SMpeFD5uAyMeSt sDzP78mZWNPGgIaQr/WrS4PW/wjLAVy04AIpEUd02EmRypWlhE7U0ah29/sQp9FM pjx/wESP4WYRhtWyqH1Y4e821quWeIJX7F3u9ny+bG53bXFO45Q+Gy3jbNlFyET1 +yyd+K2aBSY= =PF9x -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 30 13:33:51 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17413 Thu, 30 Jan 2003 13:32:05 -0500 (EST) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Ciphersuites for IKEv2, revised References: Reply-To: EKR From: Eric Rescorla Date: 30 Jan 2003 10:38:41 -0800 In-Reply-To: Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, So, you're saying that the cipher suites for IKE encryption share the same namespace with those for ESP/AH? That seems kind of confusing. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec Thu Jan 30 14:04:25 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17487 Thu, 30 Jan 2003 14:00:26 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 30 Jan 2003 11:01:42 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Ciphersuites for IKEv2, revised Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:38 AM -0800 1/30/03, Eric Rescorla wrote: >So, you're saying that the cipher suites for IKE >encryption share the same namespace with those for >ESP/AH? Correct. There is only one class of Suite-ID specified in the IKEv2 -04 draft. >That seems kind of confusing. Maybe. But I think that having three different flavors of Suite-ID (one for IKE, one for ESP, one for AH) will be just as confusing to typical users. I assume that any GUI will have an IKE list that only contains Suite-IDs that pertain to IKE, and a ESP list that only contains Suite-IDs that pertain to ESP, and (if they even do AH) an AH list that only contains Suite-IDs that pertain to AH. What you are asking for would cause us to have to change the proposal structure given in section 5.3.1 to split out "area of coverage" from the Suite-ID. Is that really worth it? --Paul Hoffman, Director --VPN Consortium From owner-ipsec Thu Jan 30 15:30:34 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17694 Thu, 30 Jan 2003 15:18:17 -0500 (EST) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Ciphersuites for IKEv2, revised References: Reply-To: EKR From: Eric Rescorla Date: 30 Jan 2003 12:25:52 -0800 In-Reply-To: Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 10:38 AM -0800 1/30/03, Eric Rescorla wrote: > >So, you're saying that the cipher suites for IKE > >encryption share the same namespace with those for > >ESP/AH? > > Correct. There is only one class of Suite-ID specified in the IKEv2 -04 draft. > > >That seems kind of confusing. > > Maybe. But I think that having three different flavors of Suite-ID > (one for IKE, one for ESP, one for AH) will be just as confusing to > typical users. Well, there are three different flavors of suite, regardless of how the ID space is partitioned. I'm just saying that the two structures should match. > What you are asking for would cause us to have to change the proposal > structure given in section 5.3.1 to split out "area of coverage" from > the Suite-ID. I want three tables and three separate sections. > Is that really worth it? I think so. -Ekr From owner-ipsec Thu Jan 30 15:40:34 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17752 Thu, 30 Jan 2003 15:37:27 -0500 (EST) Message-Id: <5.2.0.9.2.20030130153806.02e0a578@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 30 Jan 2003 15:39:50 -0500 To: Paul Hoffman / VPNC , ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Ciphersuites for IKEv2, revised In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I really like way Paul Hoffman has proposed. One minor nit pick. In the Appendix B.1 proposed text, we should change "prime values and generators" to "generator and prime modulus values" Russ At 08:50 AM 1/30/2003 -0800, Paul Hoffman / VPNC wrote: >Greetings again. Based on feedback from the list and offline, here is >revised wording for the ciphersuites in IKEv2. The changes are: > >- clarified where the various Diffie-Hellman groups are defined > >- changed the split between what is reserved for IANA and what is > for private use > >- added a paragraph to the end of the addition to 5.3.1 to specify > that users should be able to use future and private-use Suite-IDs > >- added a note in Appendix B and a new reference > >The following text be should be used in section 5.3.1: > >===== > >For Suite-ID, the following values are defined: > >Suite-ID Meaning >-------- ------- >0 Covers: IKE > 168-bit 3DES CBC encryption > Diffie-Hellman group 2 (1024-bit), defined in Appendix B.2 > HMAC-SHA1 integrity and prf > >1 Covers: ESP > 3DES encryption with three keys > HMAC-SHA1 integrity > >2 Covers: AH > HMAC-SHA1 integrity > >3 Covers: IKE > 168-bit 3DES CBC encryption > Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5 > HMAC-SHA1 integrity and prf > >4 Covers: IKE > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5 > HMAC-SHA1 integrity and prf > >5 Covers: IKE > AES encryption in CBC mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP] > HMAC-SHA1 integrity and prf > >6 Covers: ESP > AES encryption in CBC mode with 128-bit keys > HMAC-SHA1 integrity > >7 Covers: IKE > AES encryption in CTR mode with 128-bit keys > Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP] > AES-CBC MAC + XCBC integrity and prf > >8 Covers: ESP > AES encryption in CTR mode with 128-bit keys > AES-CBC MAC + XCBC integrity > >Values 9-32000 are reserved to IANA. Values 32001-65533 are for private >use among mutually consenting parties. Additional Suite-ID values will >be assigned by IANA based on consultation with the IESG. > >All implementations of IKEv2 MUST be able to negotiate Suite-ID 0 and >Suite-ID 1. Implementations SHOULD be able to negotiate Suite-IDs 3, 4, >5, and 6. > >The must-be-implemented ciphersuites (0 and 1) are based on >currently-deployed hardware that meets the security requirements of the >vast majority of current IPsec users, and should be useful for at least >a decade according to cryptographic estimates from NIST for business >user scenarios. The should-be-implemented ciphersuites (3, 4, 5, and 6) >are based on expectations of where the security industry is moving >(namely, to the AES encryption suite) and where more security-conscious >users are moving as current key lengths become more attackable due to >the steady lowering of cost to mount brute-force attacks. > >An important lesson learned from IKEv1 is that no system should only >implement the mandatory algorithms and expect them to be the best choice >for all customers. For example, at the time that this document was being >written, many IKEv1 implementers are starting to migrate to AES in CBC >mode for VPN applications. Many IPsec systems based on IKEv2 will >implement AES, longer Diffie-Hellman keys, and additional hash >algorithms, and some IPsec customers already require these algorithms in >addition to the mandatory ones listed above. > >It is likely that IANA will add additional Suite-IDs in the future, and >some security-conscious users will want to use private-use Suite-IDs. >All implementations SHOULD be able to let users set policies that use >Suite-IDs from the currently-unassigned IANA values and from the private >use values. Of course, there is no standard way to handle all possible >new algorithms, Diffie-Hellman groups, and combinations thereof. However, >many IPsec users will want to base security policies on Suite-IDs that >are not covered in this document and SHOULD be able to do so. > >===== > >Add the following to just before Appendix B.1: > >Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Future >IANA-registered and private use Suite-IDs MAY use Diffie-Hellman groups >that have prime values and generators that are different than those in >this document or in [ADDGROUP]. > >Add to the non-normative references: > >[ADDGROUP] Kivinen, T. et. al., "More MODP Diffie-Hellman groups for IKE", >draft-ietf-ipsec-ike-modp-groups-05.txt, in RFC Editor's queue for >Proposed Standard. > >--Paul Hoffman, Director >--VPN Consortium From owner-ipsec Thu Jan 30 16:00:49 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17798 Thu, 30 Jan 2003 15:57:30 -0500 (EST) Message-Id: <200301302059.h0UKxYS1003275@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Ciphersuites for IKEv2, revised In-reply-to: Your message of "30 Jan 2003 10:38:41 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jan 2003 15:59:33 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Eric" == Eric Rescorla writes: Eric> Paul, Eric> So, you're saying that the cipher suites for IKE encryption share Eric> the same namespace with those for ESP/AH? Eric> That seems kind of confusing. Yeah, maybe. People also seem to occasionally argue that X is too slow, and I ask, "but this is for IKE!" and they say "no, I'm talking ESP.". So this is really a question of economies of a single list vs some minor confusion. The magic value in this case goes into a proposal in the same place. There is some niceties in having it demux'ed once. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjmSNIqHRg3pndX9AQGnbgP8C/mUTR2KAmUm+XKYbyCnmD5385o1MYir fJ/KYvwTTaK+J2ggiIhbm73he4/9Qw7oGLZMIqEiwfZzGKddfIkfhI0962i/74UJ bw/8gxxYMpOVgcaK1pN9xdchPcvhOtNRhvJhJbiLFz9pHm5kc8a4x5W4Xbsb1emN V5/FzH+TiNs= =jtFO -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 30 16:04:22 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17804 Thu, 30 Jan 2003 16:00:30 -0500 (EST) Message-Id: <200301302103.h0UL3B6d003374@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Ciphersuites for IKEv2, revised In-reply-to: Your message of "Thu, 30 Jan 2003 11:01:42 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jan 2003 16:03:11 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "VPNC" == VPNC writes: >> So, you're saying that the cipher suites for IKE encryption share the >> same namespace with those for ESP/AH? VPNC> Correct. There is only one class of Suite-ID specified in the IKEv2 VPNC> -04 draft. >> That seems kind of confusing. VPNC> Maybe. But I think that having three different flavors of Suite-ID VPNC> (one for IKE, one for ESP, one for AH) will be just as confusing to VPNC> typical users. I assume that any GUI will have an IKE list that VPNC> only contains Suite-IDs that pertain to IKE, and a ESP list that VPNC> only contains Suite-IDs that pertain to ESP, and (if they even do VPNC> AH) an AH list that only contains Suite-IDs that pertain to AH. How about a compromise. A single number space, as we have now. But, 0-8K for IKE 8K-16K for ESP 16K-24K for AH 32K-48K for private use rest is IANA reserved. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec Thu Jan 30 16:47:06 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17950 Thu, 30 Jan 2003 16:40:20 -0500 (EST) Message-Id: <200301302142.h0ULgoOF004630@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Ciphersuites for IKEv2, revised In-reply-to: Your message of "30 Jan 2003 12:25:52 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jan 2003 16:42:49 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Eric" == Eric Rescorla writes: >> Maybe. But I think that having three different flavors of Suite-ID >> (one for IKE, one for ESP, one for AH) will be just as confusing to >> typical users. Eric> Well, there are three different flavors of suite, regardless of how Eric> the ID space is partitioned. I'm just saying that the two Eric> structures should match. >> What you are asking for would cause us to have to change the proposal >> structure given in section 5.3.1 to split out "area of coverage" from >> the Suite-ID. Eric> I want three tables and three separate sections. So, we have to have three different proposal structures, which are identical, except that they negotiate the same things for the different uses? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjmcWIqHRg3pndX9AQEbiAQAuGRjj+N0OhWpzoB0FqWuMFybOVpsLoBb 5YP6qObj5ZczkCECZvFvAwSxYSOURHAkD/nBwWiyxpDZKDwNrwiCn7t8Xks9oUt/ edPQ1A0zDkvTm5sjO+VyW71ujg144ZALUkpuHqkEeyMaGE1KqWYE21kMGbRRlYZL NZ0fk5mi1Bc= =VEtO -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 30 17:42:43 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18077 Thu, 30 Jan 2003 17:39:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200301291902.h0TJ22n03176@localhost.localdomain> References: <200301291902.h0TJ22n03176@localhost.localdomain> Date: Thu, 30 Jan 2003 10:05:19 -0500 To: John Lindal From: Stephen Kent Subject: Re: new to VPN Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:02 AM -0800 1/29/03, John Lindal wrote: > >> Is it true that the hardware VPN solutions are always better, >>> trusted and have higher secure level than software VPN? >> >> I don't think so. AFAIK, hardware VPN solution would just be faster than >> software VPN. > >Custom hardware always has the potential to be faster than software running >on standard hardware. However, standard hardware is now so fast that there >is little reason to bother with custom hardware any longer. It is possible >to get approx. 20Mb/sec using 256 bit AES on a 1GHz Pentium 3 processor. >(AFAIK, most cheap VPN boxes provide only one or at most a few Mb/sec.) > >John If the user of the IPsec technology an individual subscriber then a fast PC can do a good job, IF you are willing to devote the processor cycles to just encryption. However, this may not always be acceptable, e.g., one might want secure communications to take place as a background activity with minimal disruption of other tasks one is performing on the PC. Additionally, hardware can offer far superior security for private keys vs. software, and can offer better assurance that data does not bypass IPsec checks. Of course, if the user for IPsec is an aggregation point such as a firewall, then it seems clear that hardware solutions are much faster than software on a general purpose processor, and one needs to support more than just AES to make a fast IPsec, e.g., there are SA establishment costs re DH and RSA, and per-packet lookup for SA selection and checking. Finally, my experience is that hardware is much faster than software for these security gateways contexts, not at all consistent with you parenthetical comment above. Steve From owner-ipsec Thu Jan 30 17:43:21 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18083 Thu, 30 Jan 2003 17:41:54 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <00a501c2c813$871aa780$5803a8c0@trlhpc1> References: <00a501c2c813$871aa780$5803a8c0@trlhpc1> Date: Thu, 30 Jan 2003 17:42:28 -0500 To: "Jayant Shukla" From: Stephen Kent Subject: RE: new to VPN Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:56 PM -0800 1/29/03, Jayant Shukla wrote: > > -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com] >> On Behalf Of Mukesh Gupta >> > Is it true that the hardware VPN solutions are always better, >> > trusted and have higher secure level than software VPN? >> > >On the contrary, I think software solutions are becoming more secure >than the hardware solutions. If you look at technologies related to >intrusion prevention or known/unknown Trojan detection, the software >solutions have a much better edge. Any software solution executing in a conventional OS context will be vulnerable to all of the vulnerabilities that allow exploitation of that OS. In contrast, an IPsec implementation operating in a constrained environment with a minimal OS, perhaps just a scheduler, is less vulnerable in general. Also, if one uses hardware to generate keys and if one keeps the keys inside the hardware (consistent with FIPS 140-1/2 level 3 design criteria) the keys will be very well protected, something that we simply cannot do in software. Steve From owner-ipsec Thu Jan 30 17:57:41 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18118 Thu, 30 Jan 2003 17:54:53 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Moving forward with IKE V2: A proposal for final edits to ikev2-04 From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Thu, 30 Jan 2003 17:57:09 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie Kaufman, the document editor for IKE v2, has been travelling and out of e-mail contact this past week. I'm told that he will be back and (hopefully) responding to e-mail this weekend, but that he will be away on more travel next week, and will be fully back on-line on February seven. This brings us relative uncomfortably close to our deadline of trying to complete the IKEv2 proposal by February 15th. The good news is that we believe that we are very close, and that one last, good, hard push is what's necessary to get us to get over the finish line. For example, this past week, it looks like we were had almost achieved consensus on the matter of the question of Secure Legacy Authentication, with Derrell Piper (one of the co-authors of draft-hoffman-sla-00.txt), Charlie Kaufman, Uri Blumenthal, and Steve Kent all expressing comfort to his proposal, which represents a very large percentage of the people who have been discussing this issue on the IPSEC mailing list. Never have we been so close to consensus on this issue, which is great! So in order to come to consensus, we would like to present the following straw-man proposal, as a miniature "last call" for the working group. In Atlanta, we received very clear input from the working group that support for Legacy Authentication is very, very important for IKE v2. As we have seen with IKE v1, there are many ways of accomplishing this, and not all people will agree on what might be the "best" method. Even if we continuing arguing for the next two years (and I don't think the IESG will give us that long), it is extremely doubtful that we will ever come to unanimity on this quesiton. For this reason, what we propose is that we pick an approach, and be done with it. The question then before the working group is whether or not there is another way to accomplish the task, but whether there are either (a) fatal flaws in the proposal presented, (b) clear, overwhelming advantages to do things a different way (and no handwaving; it must be a complete proposal), or (c) minor enhancements that all can agree are worthwhile to include in the protocol and worthwhile to implement. Otherwise we will be arguing until the cows come home (and/or when the IESG shuts us down, or the mob from problem-statement mailing list show up with the pitchforks, tar, and feathers :-). So without further ado, please consider and comment the following proposal as final editing directions to ikev2-04.txt: ----------------------------------- 1) Use as the basis of secure legacy authentication the proposal made by Derrell Pipper on January 23rd, 2003: HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr HDR*, IDi, [CERTREQ], [IDr,] SAi2, TSi, TSr --> <-- HDR*, IDr, [CERT,] AUTH, EAP(n) HDR*, [AUTH,] EAP(n) --> <-- HDR*, EAP(status) [, SAr2, TSi, TSr ] For those EAP mechanisms which generate a shared key, the AUTH payload MUST be sent from the client to the server when it has sufficient information to generate it. (as proposed by Charlie) If there exists EAP mechanisms where the a new session key may negotiated during the course of the EAP exchange, the client MUST send another AUTH payload if/when a new session key is generated. (as proposed by Darrell --- this probably isn't a problem in practice) Hugo has suggested that for EAP mechanisms that generate a shared key, the responder should send an AUTH message based on the shared key in the message containing the EAP(success) message, as backup in case for some reason the CERT based exchange might have gotten spoofed somehow. This seems to me to be a case of gilding the lilly, and is probably not be worth the extra complexity, but I encourage comment on the working group about whether or not this additional twist should be included. Hugo has a few other concerns about this proposal; none of them seem fatal, but I encourage working group members to look over his message of January 25th, and to please speak up ASAP if you believe these concerns need to be addressed --- and if so, how. ----------------------------------- 3) Change in signature processing. In a discussion between Hugo and Charlie, on January 22-24th there was agreement to change section 4.15 to make IKEv2 more robust to future changes to the protocol: 4.15 Authentication of the IKE-SA The peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message and end with the last octet of the last payload in the second message. Appended to this (for purposes of computing the signature) [are] the initiator's nonce Ni (just the value, not the payload containing it), [and a value MIDr computed as prf(SK_ar,IDr). Note that neither the nonce Ni or value MIDi are transmitted.] Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) [are] the responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)]. ... where IDi and IDr are the entire Idx payload. --------------------------------------------- 3) For the Cipher Suite issue, that we use Paul Hoffman's proposed set of Cipher suites. There is less consensus on this issue on the mailing list, but most people don't seem to have strong feelings, so we believe we just pick something: Suite-ID Meaning -------- ------- 0 Covers: IKE (MUST) 168-bit 3DES CBC encryption Diffie-Hellman group 2 (1024-bit) HMAC-SHA1 integrity and prf 1 Covers: ESP (MUST) 3DES encryption with three keys HMAC-SHA1 integrity 2 Covers: AH (SHOULD) HMAC-SHA1 integrity 3 Covers: IKE (MUST) 168-bit 3DES CBC encryption Diffie-Hellman group 5 (1536-bit) HMAC-SHA1 integrity and prf 4 Covers: IKE (MUST) AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 5 (1536-bit) HMAC-SHA1 integrity and prf 5 Covers: IKE (MUST) AES encryption in CBC mode with 128-bit keys Diffie-Hellman group 14 (2048-bit) HMAC-SHA1 integrity and prf 6 Covers: ESP (MUST) AES encryption in CBC mode with 128-bit keys HMAC-SHA1 integrity 7 Covers: IKE (SHOULD) AES encryption in CTR mode with 128-bit keys Diffie-Hellman group 14 (2048-bit) AES-CBC MAC + XCBC integrity and prf 8 Covers: ESP (SHOULD) AES encryption in CTR mode with 128-bit keys AES-CBC MAC + XCBC integrity I have adjusted the MUST/SHOULD from Paul's message since I believe that for implementations that will be moving to implement IKEv2, it is reasonable to require the implementation of AES, as it as so many advantages over 3DES. If it weren't for the existing chips that only support AES-CBC, I'd argue for making AES-CTR mandatory instead, but given where we are, this set of MUST/SHOULD seems to me to be the most reasonable set of ciphers. Question: Should AES Counter mode be made mandatory to ensure compatibility in the future? Existing chips only support AES-CBC, so this might make things harder for people as they transition to IKEV2. On the other hand, by the time we see start seeing IKEv2 products, it might be reasonable to require the presence of AES-CTR support. ----------------------------------- (SEMI-)CLOSED ISSUES ===================== The following issues have been burbling on the list, although in the opinion of the IPSEC Working group chairs, there isn't consensus in the IPSEC working group to act on them. If you feel otherwise, please speak now. A) Revised identity -------------------- Paul Hoffman has a proposal, draft-ietf-ipsec-revised-identity-00.txt, which radically changes how identities are handled. Specifically, it would eliminate the ID payload with the following types: ID_IPV4_ADDR 1 ID_FQDN 2 ID_RFC822_ADDR 3 ID_IPV6_ADDR 5 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 et.al, and replaces it with a FullID payload with the following types: 1 PKIX certificate 2 Certificate bundle 3 Hash-and-URL of PKIX certificate 4 URL to a PKIX certificate bundle 5 PKIX keyIdentifier 6 IDForSharedSecret This would be fundamental change in the management and administraton of IPSEC and IKE, so is not something to adopt lightly, and without a clear consensus of the working group. This was discussed in two threads on the IPSEC mailing list: one starting on November 5th (subject Adding revised identities to IKEv2), and one starting on December 8th (subject: Summary of revised identity changes). People who spoke in favor on the mailing list included Francis Dupont and Bill Sommerfeld, with qualified support from Michael Richardson (if support for bare keys is added) and Tero Kivinen (who is concerned about the complexity of the proposal). This proposal was discussed in Atlanta, but Charlie, Barbara, and Ted were left with the impression that there was not consensus among those who met to discuss legacy authentication after the IPSEC wg meeting to pursue adoption of Paul's proposed change. Paul believes otherwise. Since it is the job of working group chairs to determine consensus, we (Barbara and Ted) hereby ask that those who believe we should pursue the revised identity proposal to please speak up. It should be noted that there are some intermediate positions beyond what is currently in draft-ietf-ipsec-ikev2-04.txt and the revised-identies draft. For example, we could add the Hash-and-URL type to the Certificate payload, if the goal is shrink the size of IKE messages (with the tradeoff of increasing complexity in IKE implementations). We could also add a CERT hash type to the ID payload, without nuking the traditional FQDN or IPv4/6 addresses identity mechanisms (although again, by adding new types, we would be increasing the complexity of the specification and implementations). Due the relatively small number of people who have spoken in favor of this proposal or its less-radical alternates, the default choice for IKEv2 has to be what is currently in ikev2-04. So those who believe we should make this change (or those who strongly believe we should not) are requested to speak up now, or forever hold your peace.... B) DHCP-based vs. MODECFG style remote access configuration ----------------------------------------------------------- Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a Configuration payload with defined attributes. An alternate mechanism involves using tunneled DHCP requests. The latter approach is about to be published as an RFC by the IPSRA working group. Proponents of this method argue that it is more powerful than modecfg (because of the extensibility and large number of options already specified for DHCP; for example, being able to specify DNS, time, print, or WINS servers, and so on.) It is also argued that it requires less code on the server/firewall, since an existing DHCP server can be used. Proponents of the modecfg approach argue that many implementation already have support for modecfg, and that setting up sort-lived specialized tunnels to allow the DHCP packets to flow through the gateway is kludgy, and requires multiple special case entries into packet forwarding tables. Modecfg proponents also argue that it is also possible to transform modecfg requests into DHCP requests, so there are implementation choices that do not require reimplementation of the DHCP's address assignment function. They also point out that it certainly is possible --- and in some ways easier --- to obtain the time, print, WINS server information by using DHCP (via the DHCPINFORM request) after the IPSEC tunnel is setup and the client address is assigned. Either approach seems to be workable. It is certainly true that most of the people in Atlanta were implementors who were already familiar with modecfg, representing a large implementation community. That being said, there is also some number of working group members that are in favor of an approach similar to draft-ietf-ipsec-dhcp-13, including Van Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or another, however we need to make a choice and move forward. Given that we have a fully specified solution in the ikev2-04 draft, and it would seem that while there is a sizeable minority in favor of the ipsec-dhcp-13 approach, the majority are comfortable with the modecfg based approach. So at this point, we, as working group chairs, judge that the consensus is with the current approach. If there are those who feel otherwise, or who see fatal problems with the current approach, please speak now. Ted and Barabara IPSEC wg chairs From owner-ipsec Thu Jan 30 18:33:42 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18249 Thu, 30 Jan 2003 18:31:22 -0500 (EST) To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Ciphersuites for IKEv2, revised References: <200301302142.h0ULgoOF004630@marajade.sandelman.ottawa.on.ca> Reply-To: EKR From: Eric Rescorla Date: 30 Jan 2003 15:38:44 -0800 In-Reply-To: <200301302142.h0ULgoOF004630@marajade.sandelman.ottawa.on.ca> Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > So, we have to have three different proposal structures, which are > identical, except that they negotiate the same things for the different uses? My bad. I'd forgotten that "proposal structure" was a technical term. I'd prefer to see the proposal structure explicitly modified to represent the fact that there are three different things being negotiated. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec Thu Jan 30 19:21:36 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18442 Thu, 30 Jan 2003 19:18:01 -0500 (EST) Date: Thu, 30 Jan 2003 15:09:13 -0800 (PST) From: Bernard Aboba To: ipsec@lists.tislabs.com Subject: Modefg considered harmful Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, I'll speak up. One of the major requirements for IPSRA in choosing DHCP-based configuration was so that we could move towards a single configuration model for both real and virtual interfaces -- and one which supported the security features that have been under development over the last few years -- such as RFC 3118 and was compatible with both IPv4 and IPv6. Among other things, Modecfg does not satisfy those requirements, as outlined in RFC 3456. In particular, were Modecfg to be extended to IPv6, it would constitute an alternative to RS/RA, complicating the IPv6 architecture. In addition, Modecfg is incompatible with DHCP security as described in RFC 3118, so that contrary to your statements below, it is *not* easy to integrate it correctly with DHCP. There are lots of other reasons why Modecfg is a bad idea -- and why the IPSRA WG chose not to select it. In fact, there are so many that an entire appendix in RFC 3456 had to be devoted to listing them all (and I left out quite a few). Here is the text: ====================================================================== Appendix - IKECFG evaluation Alternatives to DHCPv4, such as ISAKMP CFG, described in [13], do not meet the basic requirements described in [21], nor do they provide the additional capabilities of DHCPv4. Basic configuration While ISAKMP CFG can provide for IP address assignment as well as configuration of a few additional parameters such as the DNS server and WINS server addresses, the rich configuration facilities of DHCPv4 are not supported. Past experience with similar configuration mechanisms within PPP IPCP [11] has taught us that it is not viable merely to support minimal configuration. Eventually, either much of the functionality embodied in the DHCPv4 options [4] is duplicated or support for DHCPINFORM [3] will be required. Address management integration Since IKECFG is not integrated with existing IP address management facilities, it is difficult to integrate it with policy management services that may be dependent on the user to IP address binding. Address pool management IKECFG does not provide a mechanism for the remote host to indicate a preference for a particular address pool. This makes it difficult to support address pool management. Reconfiguration IKECFG does not support the concept of configuration leases or reconfiguration. Fail-over support Since IKECFG creates a separate pool of address state, it complicates the provisioning of network utility-class reliability, both in the IP address management system and in the security gateways themselves. Security and simplicity As past history with PPP IPCP demonstrates, once it is decided to provide non-integrated address management and configuration facilities within IKE, it will be difficult to limit the duplication of effort to address assignment. Instead, it will be tempting to also duplicate the configuration, authentication and fail-over facilities of DHCPv4. This duplication will greatly increase the scope of work, eventually compromising the security of IKE. Authentication While IKECFG can support mutual authentication of the IPsec tunnel endpoints, it is difficult to integrate IKECFG with DHCPv4 authentication [5]. This is because the security gateway will not typically have access to the client credentials necessary to issue an DHCPv4 authentication option on the client's behalf. As a result, security gateways implementing IKECFG typically request allocation of an IP address on their own behalf, and then assign this to the client via IKECFG. Since IKECFG does not support the concept of an address lease, the security gateway will need to do the renewal itself. This complicates the renewal process. Since RFC 2131 [3] assumes that a DHCPREQUEST will not contain a filled in giaddr field when generated during RENEWING state, the DHCPACK will be sent directly to the client, which will not be expecting it. As a result, it is either necessary for the security gateway to add special code to avoid forwarding such packets, or to wait until REBINDING state. Since [3] does not specify that the giaddr field cannot be filled in when in the REBINDING state, the security gateway may put its own address in the giaddr field when in REBINDING state, thereby ensuring that it can receive the renewal response without treating it as a special case. ====================================================================== B) DHCP-based vs. MODECFG style remote access configuration ----------------------------------------------------------- Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a Configuration payload with defined attributes. An alternate mechanism involves using tunneled DHCP requests. The latter approach is about to be published as an RFC by the IPSRA working group. Proponents of this method argue that it is more powerful than modecfg (because of the extensibility and large number of options already specified for DHCP; for example, being able to specify DNS, time, print, or WINS servers, and so on.) It is also argued that it requires less code on the server/firewall, since an existing DHCP server can be used. Proponents of the modecfg approach argue that many implementation already have support for modecfg, and that setting up sort-lived specialized tunnels to allow the DHCP packets to flow through the gateway is kludgy, and requires multiple special case entries into packet forwarding tables. Modecfg proponents also argue that it is also possible to transform modecfg requests into DHCP requests, so there are implementation choices that do not require reimplementation of the DHCP's address assignment function. They also point out that it certainly is possible --- and in some ways easier --- to obtain the time, print, WINS server information by using DHCP (via the DHCPINFORM request) after the IPSEC tunnel is setup and the client address is assigned. Either approach seems to be workable. It is certainly true that most of the people in Atlanta were implementors who were already familiar with modecfg, representing a large implementation community. That being said, there is also some number of working group members that are in favor of an approach similar to draft-ietf-ipsec-dhcp-13, including Van Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or another, however we need to make a choice and move forward. Given that we have a fully specified solution in the ikev2-04 draft, and it would seem that while there is a sizeable minority in favor of the ipsec-dhcp-13 approach, the majority are comfortable with the modecfg based approach. So at this point, we, as working group chairs, judge that the consensus is with the current approach. If there are those who feel otherwise, or who see fatal problems with the current approach, please speak now. Ted and Barabara IPSEC wg chairs From owner-ipsec Thu Jan 30 19:50:01 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18517 Thu, 30 Jan 2003 19:48:34 -0500 (EST) Message-Id: <200301310051.h0V0pRjt016945@thunk.east.sun.com> From: Bill Sommerfeld To: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-Reply-To: Your message of "Thu, 30 Jan 2003 15:09:13 PST." Reply-to: sommerfeld@east.sun.com Date: Thu, 30 Jan 2003 19:51:27 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "what bernard said". I see modecfg as reinventing a square wheel. DHCP is sufficient to solve this problem. - Bill From owner-ipsec Thu Jan 30 20:00:26 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18555 Thu, 30 Jan 2003 19:58:43 -0500 (EST) Message-Id: <200301310100.h0V10gUL011854@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-reply-to: Your message of "Thu, 30 Jan 2003 15:09:13 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jan 2003 20:00:41 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bernard" == Bernard Aboba writes: Bernard> OK, I'll speak up. Bernard> One of the major requirements for IPSRA in choosing DHCP-based Bernard> configuration was so that we could move towards a single Bernard> configuration model for both real and virtual interfaces -- and Bernard, I support your reasoning for using DHCP. (I'd rather that we used DHCPv6 rather than RS/RA. Since DHCP is a lot easier to secure and extend than RS/RA. But that is a different argument) I still do not understand why creating a ephemeral IPsec SA to carry the DHCP traffic makes sense. I don't see that it is any easier for bump-in-the-stack implementations, nor do I see it easier for in-stack implementations. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjnKuIqHRg3pndX9AQEGywP/dRrtuNSBHGPVgiBFLYhSA1asUiFQYjZW xGu+b/+48x/t0HwhxthBInXiqT1qWwHXf9TxuxK1RPEdpF4+A/bayl7W+bB+UH8q 4q12R+yQkVLvxprJU8VWRxc+Wduzphw9XukDj1gZrIg7MujAIe/YMArJP4LzH8b5 Sk1+sVLVoNE= =rha4 -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 30 20:32:08 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18716 Thu, 30 Jan 2003 20:29:20 -0500 (EST) Message-Id: <4.3.2.7.2.20030130170851.04908778@mira-sjcm-4.cisco.com> X-Sender: cmadson@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Jan 2003 17:31:31 -0800 To: Michael Richardson From: Cheryl Madson Subject: Re: Modefg considered harmful Cc: ipsec@lists.tislabs.com In-Reply-To: <200301310100.h0V10gUL011854@marajade.sandelman.ottawa.on.c a> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:00 PM 1/30/2003, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Bernard" == Bernard Aboba writes: > Bernard> OK, I'll speak up. > > Bernard> One of the major requirements for IPSRA in choosing DHCP-based > Bernard> configuration was so that we could move towards a single > Bernard> configuration model for both real and virtual interfaces -- and > > Bernard, I support your reasoning for using DHCP. > (I'd rather that we used DHCPv6 rather than RS/RA. Since DHCP is a lot >easier to secure and extend than RS/RA. But that is a different argument) > > I still do not understand why creating a ephemeral IPsec SA to carry the >DHCP traffic makes sense. I don't see that it is any easier for >bump-in-the-stack implementations, nor do I see it easier for in-stack >implementations. I've always contended that for IKEv1 that *both* modecfg and DHCP had the same underlying issue -- an introduction of a "special" state into the protocol processing (either somewhat explicitly via "phase 1.5" or implicitly via the "special phase 2 which if it happens has to happen before any other phase 2"). In other words, I have always hated both proposals, basically as it assumed that via some miracle both sides would correctly figure out that this special phase had to happen and not jump ahead in the state machine. IMO we can do better with IKEv2. I don't have much opinion one way or the other about encoding, but we need to explicitly spell it out in any state machine. I don't care in terms of encoding one way or the other, but this lack of determinism has to be addressed. thx - C >] ON HUMILITY: to err is human. To moo, >bovine. | firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device >driver[ >] panic("Just another Debian GNU/Linux using, kernel hacking, security >guy"); [ >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.7 (GNU/Linux) >Comment: Finger me for keys > >iQCVAwUBPjnKuIqHRg3pndX9AQEGywP/dRrtuNSBHGPVgiBFLYhSA1asUiFQYjZW >xGu+b/+48x/t0HwhxthBInXiqT1qWwHXf9TxuxK1RPEdpF4+A/bayl7W+bB+UH8q >4q12R+yQkVLvxprJU8VWRxc+Wduzphw9XukDj1gZrIg7MujAIe/YMArJP4LzH8b5 >Sk1+sVLVoNE= >=rha4 >-----END PGP SIGNATURE----- ==================================== Cheryl Madson Core IP Engineering; Security and Services Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec Thu Jan 30 21:05:54 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18810 Thu, 30 Jan 2003 21:04:07 -0500 (EST) Message-Id: <200301310155.h0V1tuES013708@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-reply-to: Your message of "Thu, 30 Jan 2003 17:31:31 PST." <4.3.2.7.2.20030130170851.04908778@mira-sjcm-4.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jan 2003 20:55:55 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Cheryl" == Cheryl Madson writes: Bernard> OK, I'll speak up. Bernard> One of the major requirements for IPSRA in choosing DHCP-based Bernard> configuration was so that we could move towards a single Bernard> configuration model for both real and virtual interfaces -- and >> Bernard, I support your reasoning for using DHCP. (I'd rather that we >> used DHCPv6 rather than RS/RA. Since DHCP is a lot easier to secure >> and extend than RS/RA. But that is a different argument) >> >> I still do not understand why creating a ephemeral IPsec SA to carry >> the DHCP traffic makes sense. I don't see that it is any easier for >> bump-in-the-stack implementations, nor do I see it easier for in-stack >> implementations. Cheryl> I've always contended that for IKEv1 that *both* modecfg and DHCP Cheryl> had the same underlying issue -- an introduction of a "special" Cheryl> state into the protocol processing (either somewhat explicitly Cheryl> via "phase 1.5" or implicitly via the "special phase 2 which if Cheryl> it happens has to happen before any other phase 2"). Yes, it does seem funny. It seems that we need to be explicit about this. I.e. that the client should really propose something to the gateway, following phase 1 completion (and any legacy auth...) which essentially says "I don't know what to do, tell me". I think that the proposal should have a payload of DHCPDISCOVER payload. The gateway, wraps this up in a some way, sends it to the DHCP server, and sends the reply back. (The "wraps this up in some way" really means putting a layer 2,3 and 4 on the payload. The key thing is that it needs to look like it came via a DHCP relay. The MAC address that is provided to the DHCP server for the client should likely be derived in some way from the public key or legacy auth identity) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjnXpYqHRg3pndX9AQGpTQQAyZJlAvA4KRPwbk3+Ke+ryWPkqjD2oJlC tiV92SKhdTJv5hIiXzk/bj/BnYX30ARFEa1hnHdXFMUUbtFsTOdWbTQIWK+vaksk K+U8QN6NLS633NBlyEGPXkm4P6slOu7ErjCLsvZMG6iehYlZpaNLvxu905DsmXxV HpNFTWuVUg8= =rhdE -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 30 21:22:05 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18859 Thu, 30 Jan 2003 21:20:25 -0500 (EST) Message-Id: <200301310221.h0V2Lpjt017743@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-Reply-To: Your message of "Thu, 30 Jan 2003 20:55:55 EST." <200301310155.h0V1tuES013708@marajade.sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Thu, 30 Jan 2003 21:21:50 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > (The "wraps this up in some way" really means putting a layer 2,3 and 4 > on the payload. The key thing is that it needs to look like it came via a > DHCP relay. Well, the remote access gateway in this case *would* be a DHCP relay. > The MAC address that is provided to the DHCP server for the client > should likely be derived in some way from the public key or legacy > auth identity) MAC address? or client identifier? - Bill From owner-ipsec Thu Jan 30 21:54:23 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18928 Thu, 30 Jan 2003 21:47:55 -0500 (EST) Message-Id: <200301310249.h0V2nsU8016497@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-reply-to: Your message of "Thu, 30 Jan 2003 21:21:50 EST." <200301310221.h0V2Lpjt017743@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jan 2003 21:49:53 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: >> (The "wraps this up in some way" really means putting a layer 2,3 and >> 4 on the payload. The key thing is that it needs to look like it came >> via a DHCP relay. Bill> Well, the remote access gateway in this case *would* be a DHCP Bill> relay. yes, true! >> The MAC address that is provided to the DHCP server for the client >> should likely be derived in some way from the public key or legacy >> auth identity) Bill> MAC address? or client identifier? Yeah... exactly the question. I don't know what the current document says. But, doing address allocation by MAC address is something people are familliar with. Doing it by client identifier option is increasingly easy. I suggest that both should be filled in. I'm not clear that the client should be permitted to set those values directly. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjnkT4qHRg3pndX9AQHJNQP/cnrcNJ1/wi5jnj2OzN+2bJ/XD38jIrqZ r+D7xbka9qEdt1aKYuThRSYCdnU2ZuSZ0ozv2hGd84GOWH2SWoIPAyf2qGLF1q6q +xv4F90hbu0AcrhP2+YNGHc0iPgTnhNCz777RLcFN5jsZ+6AdWhOf+8bbvxbiI/B SPq6Uos+LXY= =xCPm -----END PGP SIGNATURE----- From owner-ipsec Thu Jan 30 22:15:02 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19010 Thu, 30 Jan 2003 22:11:27 -0500 (EST) Date: Thu, 30 Jan 2003 16:59:32 -0800 Message-Id: <200301310059.h0V0xWn06206@localhost.localdomain> From: John Lindal X-Mailer: Arrow 2.0b3 (X11; Linux 2.4.2-2; i686) To: Reply-To: ipsec@lists.tislabs.com Subject: Re: new to VPN Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There are a growing number of VPN capable boxes that employ management > processors of around 100Mhz, (not ix86) with rather limited power > budgets. They are using comodity cipher chips with power budgets that > rival that of the fan on the GHz PIII. It is these devices where we will > see the most impact of IPsec technology - they are often embedded network > elements of various sorts. AFAIK, the PowerPC chips run much cooler than P3's. I'm sure custom hardware can run even cooler, but I suspect that only in extreme circumstances would it be worth the extra effort. > But, I agree with Jayant - for anyone for whom money is an object, but > power consumption is not (anyone not living in California :-]), but > moderate speed is also, a PIII is very hard to beat. Does one extra PIII for an office of, say, 50 people, each of whom has at least one PC on his/her desk, actually make a significant difference in the power budget? An end-to-end IPSec solution that offloads all the work to the end clients would avoid this issue because one would only be using the PC's already on people's desktops. -- Sincerely, John Lindal Chief Software Architect, Trlokom, Inc. http://www.trlokom.com/ From owner-ipsec Fri Jan 31 00:55:30 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19318 Fri, 31 Jan 2003 00:50:22 -0500 (EST) Date: Fri, 31 Jan 2003 00:52:24 -0500 From: "Theodore Ts'o" To: Cheryl Madson Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful Message-ID: <20030131055224.GF16543@think.thunk.org> References: <4.3.2.7.2.20030130170851.04908778@mira-sjcm-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030130170851.04908778@mira-sjcm-4.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jan 30, 2003 at 05:31:31PM -0800, Cheryl Madson wrote: > I've always contended that for IKEv1 that *both* modecfg and DHCP > had the same underlying issue -- an introduction of a "special" state > into the protocol processing (either somewhat explicitly via "phase 1.5" > or implicitly via the "special phase 2 which if it happens has to happen > before any other phase 2"). > > In other words, I have always hated both proposals, basically as it > assumed that via some miracle both sides would > correctly figure out that this special phase had to happen and not > jump ahead in the state machine. > > IMO we can do better with IKEv2. I don't have much opinion one way > or the other about encoding, but we need to explicitly spell it out in > any state machine. I don't care in terms of encoding one way or the > other, but this lack of determinism has to be addressed. Cheryl, I agree with your last point. Indeed, the current Configuration Payload specification in ikev2-04 is pretty explicitly spelled out. There isn't a magic phase1.5; instead, the Configuration payload is included in message 3 (or in any request to create a CHILD-SA), and the response is message 4. To quote from ikev2-04.txt: Initiator Responder ----------------------------- --------------------------- HDR, SAi1, KEi, Ni, Nr, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr} .... For example, message from Initiator to Responder: CP(CFG_REQUEST)= INTERNAL_ADDRESS(0.0.0.0) INTERNAL_NETMASK(0.0.0.0) INTERNAL_DNS(0.0.0.0) TSi = (0, 0-65536,0.0.0.0-255.255.255.255) TSr = (0, 0-65536,0.0.0.0-255.255.255.255) NOTE: Traffic Selectors are a (protocol, port range, address range) Message from Responder to Initiator: CP(CFG_REPLY)= INTERNAL_ADDRESS(192.168.219.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.168.219.0/255.255.255.0) TSi = (0, 0-65536,192.168.219.202-192.168.219.202) TSr = (0, 0-65536,192.168.219.0-192.168.219.255) Although it is very clear that this is much less powerful and less flexible than what RFC 3456 describes (it doesn't support reconfiguration, it doesn't support renewals periods except via SA expiration, etc.) it does have the virtue that I can explain how it works to somone else in about 30 seconds. After reading through the 13 page RFC 3456 (the text devoted to the configuration payload in ikev2-04 is perhaps 1-2 pages long), I very much doubt I could explain the DHCP-based method as easily or as quickly. - Ted From owner-ipsec Fri Jan 31 01:24:39 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA19427 Fri, 31 Jan 2003 01:22:52 -0500 (EST) Date: Fri, 31 Jan 2003 01:25:00 -0500 From: "Theodore Ts'o" To: Bernard Aboba Cc: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful Message-ID: <20030131062500.GG16543@think.thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bernard, Could I volunteer you (or some other RFC-3456 author/supporter) to supply text that could potentially replace the Configuration Payload text in ikev2-04.txt? If it turns out that we have clear working group consensus to replace the Configuration payload with a DHCP-style solution, we need to have specific text that we can send to Charlie to put into the IKEv2 specification. Also, I think it would be easier for the working group to come to consensus --- one way or another --- if they can look at specific text and compare it with what is currently in ikev2-04. Unfortunately, we can't just point at RFC 3456, since enough things have changed in IKEv2. And while experts would probably understand, "RFC 3456, except ignore the part were it talks about Phase 1 and Phase 2, main, agressive, and quick mode, and instead do the obvious Right Thing", it's probably better to lift the specific text from RFC 3456, and then update it for IKE V2. BTW, looking at RFC 3456, it would probably be a good idea to specify exactly what *should* happen in the case of "reconfiguration". Presumably, the client will need to establish a new SA with updated traffic selectors --- which means that on the client side, the DHCP client code will always be inextricably bound with the IPSEC implementation, for better or forworse --- however, RFC 3456 never says so explicitly. - Ted P.S. For my own curiosity/edification, how often do administrators really use DHCP reconfiguration anyway? Given that it can seriously screw over the user, by immediately destroying all existing TCP connections after the IP address of the client is suddenly, precipitously, and without warning changed, it doesn't seem like the sort of thing which would or should be used often. So I'm curious why the IPSRA wg decided that reconfiguration was a requirement that MUST be supported. I can see this being useful for web kiosks, perhaps, but under what circumstances would an administrator want to play such a rude trick on a VPN client? (And I mean besides a BOFH being bored. :-) From owner-ipsec Fri Jan 31 01:45:26 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA19473 Fri, 31 Jan 2003 01:42:21 -0500 (EST) Date: Thu, 30 Jan 2003 21:33:35 -0800 (PST) From: Bernard Aboba To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-Reply-To: <20030131062500.GG16543@think.thunk.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 31 Jan 2003, Theodore Ts'o wrote: > Bernard, > > Could I volunteer you (or some other RFC-3456 author/supporter) to > supply text that could potentially replace the Configuration Payload > text in ikev2-04.txt? If it turns out that we have clear working > group consensus to replace the Configuration payload with a DHCP-style > solution, we need to have specific text that we can send to Charlie to > put into the IKEv2 specification. Also, I think it would be easier > for the working group to come to consensus --- one way or another --- > if they can look at specific text and compare it with what is > currently in ikev2-04. I'd be happy to help any way I can. > Unfortunately, we can't just point at RFC 3456, since enough things > have changed in IKEv2. And while experts would probably understand, > "RFC 3456, except ignore the part were it talks about Phase 1 and > Phase 2, main, agressive, and quick mode, and instead do the obvious > Right Thing", it's probably better to lift the specific text from RFC > 3456, and then update it for IKE V2. I see only three places in RFC 3456 where "quick mode", "phase 2", "main mode" or "aggressive mode" are used: pp.6 (once), pp. 9 (twice). Rather than incorporating the text of a 17 page document into IKEv2, I'd suggest that only the changes be incorporated into IKEv2, or if that doesn't suffice, we can do an RFC 3456bis and reference that. > BTW, looking at RFC 3456, it would probably be a good idea to specify > exactly what *should* happen in the case of "reconfiguration". > Presumably, the client will need to establish a new SA with updated > traffic selectors --- which means that on the client side, the DHCP > client code will always be inextricably bound with the IPSEC > implementation, for better or forworse --- however, RFC 3456 never > says so explicitly. A new SA would only be needed if an address change occurred -- e.g. a Nak was received in response to a DHCP Request. If only new options are received then no new SA is needed. Binding IP address assignment to the IPsec implementation is nothing new, by the way. If you think this is wierd, you ought to read the MIPv6 and MIPv6/IPsec documents :) > P.S. For my own curiosity/edification, how often do administrators > really use DHCP reconfiguration anyway? Given that it can seriously > screw over the user, by immediately destroying all existing TCP > connections after the IP address of the client is suddenly, > precipitously, and without warning changed, it doesn't seem like the > sort of thing which would or should be used often. So I'm curious why > the IPSRA wg decided that reconfiguration was a requirement that MUST > be supported. Reconfiguration can occur whenever DHCP leases expire, so support for leases and reconfiguration was considered a basic configuration facility in an IPv4 network where addresses may be in short supply. On the other hand, *forced* reconfiguration is not used very often, and typically requires DHCP authentication (RFC 3118). > I can see this being useful for web kiosks, perhaps, but under what > circumstances would an administrator want to play such a rude trick on > a VPN client? (And I mean besides a BOFH being bored. :-) When there is a shortage of IPv4 addresses, and the administrator wants to be able to assign an unused address to another VPN client. That's not a rude trick -- it's a necessity in many modern networks, but one which Modecfg does not support. From owner-ipsec Fri Jan 31 02:37:32 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA19684 Fri, 31 Jan 2003 02:34:49 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F04@TMM_EDGMSMSG01> From: Van Aken Dirk To: ipsec@lists.tislabs.com Subject: IKEv2 Terms & Definitions Date: Fri, 31 Jan 2003 08:36:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Folks, When I started reading about IKEv1 a few years ago, I was happy that section "3.2 Notation" was included in RFC2409. Although I assume I had a good a good background in IP protocol engineering it was a complete different world to me back then. Without section 3.2. it would have been even more difficult for me to master this protocol (also because the complete IKEv1 specification is dispersed over 3 documents: IKE, ISAKMP and DOI). As an example, the symbol "|" was an OR function for me but in IKEv1 it means concatenation .. So I find it a little bit odd that this part is left out especially as it is stated that one of the goals of IKEv2 is to define the entire protocol into one document. People new to IKE will have to refer to IKEv1 for terms and definitions. So I wonder whether a similar section can still be included in IKEv2 ? Dirk. Dirk Van Aken THOMSON System Architect Prins Boudewijnlaan 47, Tel. : 03/443.65.08 2650 Edegem Fax.: 03/443.66.32 Belgium vanakend@thmulti.com From owner-ipsec Fri Jan 31 05:49:04 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20086 Fri, 31 Jan 2003 05:45:24 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F07@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Theodore Ts'o'" , Cheryl Madson Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Fri, 31 Jan 2003 11:17:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Theodore Ts'o [mailto:tytso@mit.edu] Sent: vrijdag 31 januari 2003 6:52 To: Cheryl Madson Cc: Michael Richardson; ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful On Thu, Jan 30, 2003 at 05:31:31PM -0800, Cheryl Madson wrote: > I've always contended that for IKEv1 that *both* modecfg and DHCP > had the same underlying issue -- an introduction of a "special" state > into the protocol processing (either somewhat explicitly via "phase 1.5" > or implicitly via the "special phase 2 which if it happens has to happen > before any other phase 2"). > > In other words, I have always hated both proposals, basically as it > assumed that via some miracle both sides would > correctly figure out that this special phase had to happen and not > jump ahead in the state machine. > > IMO we can do better with IKEv2. I don't have much opinion one way > or the other about encoding, but we need to explicitly spell it out in > any state machine. I don't care in terms of encoding one way or the > other, but this lack of determinism has to be addressed. Cheryl, I agree with your last point. Indeed, the current Configuration Payload specification in ikev2-04 is pretty explicitly spelled out. There isn't a magic phase1.5; instead, the Configuration payload is included in message 3 (or in any request to create a CHILD-SA), and the response is message 4. To quote from ikev2-04.txt: Initiator Responder ----------------------------- --------------------------- HDR, SAi1, KEi, Ni, Nr, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr} .... For example, message from Initiator to Responder: CP(CFG_REQUEST)= INTERNAL_ADDRESS(0.0.0.0) INTERNAL_NETMASK(0.0.0.0) INTERNAL_DNS(0.0.0.0) TSi = (0, 0-65536,0.0.0.0-255.255.255.255) TSr = (0, 0-65536,0.0.0.0-255.255.255.255) NOTE: Traffic Selectors are a (protocol, port range, address range) Message from Responder to Initiator: CP(CFG_REPLY)= INTERNAL_ADDRESS(192.168.219.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.168.219.0/255.255.255.0) TSi = (0, 0-65536,192.168.219.202-192.168.219.202) TSr = (0, 0-65536,192.168.219.0-192.168.219.255) Although it is very clear that this is much less powerful and less flexible than what RFC 3456 describes (it doesn't support reconfiguration, it doesn't support renewals periods except via SA expiration, etc.) it does have the virtue that I can explain how it works to somone else in about 30 seconds. After reading through the 13 page RFC 3456 (the text devoted to the configuration payload in ikev2-04 is perhaps 1-2 pages long), I very much doubt I could explain the DHCP-based method as easily or as quickly. - Ted >>> I agree with you if one approaches the subject from an IPSec background, then it is indeed easier to explain the ModeCFG stuff; it are just a few IKE messages and you are done. However in contrast to most people in this working group, my background is IP networking (LAN/WAN) and as DHCP client/relay/server constructs have been around for 20 years in this area, reading the DHCP-based method appears only natural to me. Anyway we should not select a configuration method based on how easy it is to explain. So a first point I want to raise is how well does IKE mode config integrate with the rest of the networking infrastructure ? In this respect, where does the IKE deamon gets its IP address pool from ? Is it configured with a fixed pool or must the IKE deamon talk to a DHCP server hence acts as some kind of DHCP proxy ? If you start asking these kind of questions you immediatly end-up with a construct ModeCfgClient-ModeCfgServer-DHCPClient-DHCPServer (I can think of an even more complex construct i.e., ModeCfgClient-ModeCfgServer-DHCPClient-DHCPRelay-DHCPServer). Looking at the construct DHCPClient(in tunnel)-DHCPRelay(at the VPN GW)-DHCPServer(stand-alone server) it is far more easier to implement and clearly separate IKE from IP configuration. A second point is the scalability of a solution. If you can explain a protocol to me in 30 seconds I sure know it is not scalable at all. As an example, studying the ISAKMP framework a few years ago I immeadiatly realized that protocols derived from ISAKMP will be scalable due to the richness in exchanges, messages, payloads and attributes. And true you cannot explain this framework in 30 seconds and this same reasoning applies to DHCP. Most likely ModeCfg provides a short term solution to a problem but I'm sure it need to be extended to cope with future requirements. IMHO, in order for the ModeCfgClient to be scalable one ends-up with DHCP anyway. As an example suppose two groups of VPN users must get IP addresses from different pools, how is this going to be solved via ModeCfg ? These kind of things are solved already for years in DHCP. Dirk. From owner-ipsec Fri Jan 31 06:32:05 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20214 Fri, 31 Jan 2003 06:30:22 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F08@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Bernard Aboba'" , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Fri, 31 Jan 2003 12:28:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello ipsra people, Thank you for this extensive explanation/motivation ! Personally I'm in favour of RFC3456 solely because of following reasons: 1) RFC3456 allows me to separate IKE from IP configuration. What is the added value of this approach ? Well I don't need to dig into IKE code in order to have remote IP-IPSec configuration working. True I must make changes to the surrounding of IKE (create the necessary policies, cope with short lived tunnels, add some routes modify a DHCP relay etc ..). But the added value is I can leave IKE intact and preserve its security properties. As a remark, my background is not in IPSec but in LAN/WAN networking and I integrate IPSec more from a "building block" point of view. Of course people writing IKE code have the opposite approach. 2) IKE-Mode-Cfg is very limited in features IMHO, the IKE-Mode-Cfg is already limited in its capabilities implying it shall be extended soon, most likely via proprietary extensions. Currently, the IKE-Mode-Cfg features might be sufficient as there are still a lot of implementations around that can only operate with static IP config. For these the move toward dynamic config is a big step. However shortly after that new features will be needed, currently not foreseen in IKEv2. Choosing the DHCP based method on the other hand gives me the assurance that I won't have to change my IKE code in the future just because a new feature is requested. All that I have to foresee in that my IPSec implementation is transparent for DHCP messages. There is an important benefit to this: IKE code remains unchanged in the advent of new features hence security properties are not lowered and extensive validation cycles can be avoided. 3) Scalability & integration with networking infrastructure. A last important factor is how well does an IPSec Gateway embedding IKE-Mode-Cfg integrates with the surrounding network infrastructure ? As an IPSec GW is part of larger infrastructure which is for sure based on DHCP, it will have to integrate with it. This implies tying state machines together. My experience with this kind of constructs is that this will always fail in one form or another because of state machines not being identical, different message formats, different timers and so on. As a last word, I too would like to see a consensus (whatever it is) as it is always better to have one instead of implementing two methods and confusing customers. Dirk >>> Either approach seems to be workable. It is certainly true that most of the people in Atlanta were implementors who were already familiar with modecfg, representing a large implementation community. That being said, there is also some number of working group members that are in favor of an approach similar to draft-ietf-ipsec-dhcp-13, including Van Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or another, however we need to make a choice and move forward. Given that we have a fully specified solution in the ikev2-04 draft, and it would seem that while there is a sizeable minority in favor of the ipsec-dhcp-13 approach, the majority are comfortable with the modecfg based approach. So at this point, we, as working group chairs, judge that the consensus is with the current approach. If there are those who feel otherwise, or who see fatal problems with the current approach, please speak now. Ted and Barabara IPSEC wg chairs >>> From owner-ipsec Fri Jan 31 07:33:04 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA20431 Fri, 31 Jan 2003 07:29:55 -0500 (EST) Message-Id: <200301311232.h0VCWGjt019730@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful In-Reply-To: Your message of "Thu, 30 Jan 2003 21:49:53 EST." <200301310249.h0V2nsU8016497@marajade.sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Fri, 31 Jan 2003 07:32:16 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Bill> Well, the remote access gateway in this case *would* be a DHCP > Bill> relay. > > yes, true! > > >> The MAC address that is provided to the DHCP server for the client > >> should likely be derived in some way from the public key or legacy > >> auth identity) > > Bill> MAC address? or client identifier? > > Yeah... exactly the question. > I don't know what the current document says. > > But, doing address allocation by MAC address is something people are > familliar with. Doing it by client identifier option is increasingly easy. I > suggest that both should be filled in. I'm not clear that the client should > be permitted to set those values directly. dhcp insists that the client fill these in. if you want the relay to add information, there's now a "relay agent information option" (RFC3046) which allows the relay to append additional information to the messages. might do the trick here.. From owner-ipsec Fri Jan 31 09:14:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20681 Fri, 31 Jan 2003 09:10:52 -0500 (EST) Message-Id: <200301311252.HAA05186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-nat-reqts-03.txt Date: Fri, 31 Jan 2003 07:52:11 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec-NAT Compatibility Requirements Author(s) : B. Aboba, W. Dixon Filename : draft-ietf-ipsec-nat-reqts-03.txt Pages : 17 Date : 2003-1-30 Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier to deployment of IPsec in one of its principal uses. This draft describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-nat-reqts-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-30132158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-30132158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jan 31 09:14:28 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20675 Fri, 31 Jan 2003 09:09:50 -0500 (EST) Message-Id: <200301311251.HAA05032@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@tislabs.com; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-03.txt Date: Fri, 31 Jan 2003 07:51:40 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES Counter Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-03.txt Pages : 18 Date : 2003-1-30 This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ctr-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-30103246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ctr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-30103246.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Fri Jan 31 09:59:11 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20779 Fri, 31 Jan 2003 09:57:01 -0500 (EST) Message-Id: <4.3.2.7.2.20030131062231.02567410@mira-sjcm-4.cisco.com> X-Sender: cmadson@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Jan 2003 06:59:29 -0800 To: Van Aken Dirk From: Cheryl Madson Subject: RE: Modefg considered harmful Cc: "'Bernard Aboba'" , ipsec@lists.tislabs.com In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F08@TMM_EDGMSMSG01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:28 AM 1/31/2003, Van Aken Dirk wrote: >Hello ipsra people, > >Thank you for this extensive explanation/motivation ! > >Personally I'm in favour of RFC3456 solely because of following reasons: > >1) RFC3456 allows me to separate IKE from IP configuration. >What is the added value of this approach ? >Well I don't need to dig into IKE code in order to have remote IP-IPSec >configuration working. >True I must make changes to the surrounding of IKE (create the necessary >policies, cope with short lived tunnels, add some routes modify a DHCP relay >etc ..). But the added value is I can leave IKE intact and preserve its >security properties. Well, some of us take the view that this is still really part of IKE, just in a roundabout way (e.g. this whole "special short-lived tunnel" stuff). Sort of like the implicit "phase 0" of PIC. Also, address assignment may in many cases end up being associated with the original user credentials (e.g. what address I give you, if at all, depends on who you are). This means that I can have a finer degree of control over where you might be able to go (think of an SP RAS), so I'd argue that there still is a binding with IKE. Doing it outside of IKE can overly complicate things, IMO. Apart from the above issue, the desired model (in general terms) isn't clear to me. I never saw any discussion of the below in the IPSRA requirements. (Or if it was there, it wasn't represented in a way that us non-remote access geeks understood). Is all this information really pass-through from the "address assignment server" to the client? Is there any case (either now or imagined in the future) where the RAS may have a need to know some of this information (is the RAS expected to enforce something)? If so, how do we define which pieces the RAS has to care about and which pieces the RAS can ignore (which becomes an issue in terms of extensibility)? thx - C ==================================== Cheryl Madson Core IP Engineering; Security and Services Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec Fri Jan 31 10:19:49 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20873 Fri, 31 Jan 2003 10:16:51 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F0A@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'sommerfeld@east.sun.com'" , Michael Richardson Cc: ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Fri, 31 Jan 2003 16:18:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Bill, I'm a little in the dark regarding this discussion on MAC address and Client identifier. Can you elaborate a little such that I understand what the problem exactly is ? Here is may current ;-) understanding of Client-Relay-Server behaviour: A DHCP client (whether a PC or a VPN client is irrelvant) issues a DHCP request and fills out the chaddr field (client HW address) and the client identifier in the client identifier option. Of course the client id can be equal to the HW address. A DHCP server uses clientID and/or the chaddr field to bind a lease to a client hence must be unique within a subnet. In larger configurations, where there are gateways between server and client, the giaddr IP address is also taken into account as an implicit means for subnet selection (pool selection). Note, giaddr (gateway IP address) is automatically added by a DHCP relay. For explicit pool selection, the DHCP Relay Information Option can be used: it is an extensable mechanism to add information to DHCP packets (client-to-server direction). This information can be used 1) in the server for explicit pool selection and 2) by the relay to forward replies back to the appropriate client (in the VPN case into the right tunnel). -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] Sent: vrijdag 31 januari 2003 13:32 To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Modefg considered harmful > Bill> Well, the remote access gateway in this case *would* be a DHCP > Bill> relay. > > yes, true! > > >> The MAC address that is provided to the DHCP server for the client > >> should likely be derived in some way from the public key or legacy > >> auth identity) > > Bill> MAC address? or client identifier? > > Yeah... exactly the question. > I don't know what the current document says. > > But, doing address allocation by MAC address is something people are > familliar with. Doing it by client identifier option is increasingly easy. I > suggest that both should be filled in. I'm not clear that the client should > be permitted to set those values directly. dhcp insists that the client fill these in. if you want the relay to add information, there's now a "relay agent information option" (RFC3046) which allows the relay to append additional information to the messages. might do the trick here.. From owner-ipsec Fri Jan 31 10:54:44 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20958 Fri, 31 Jan 2003 10:52:25 -0500 (EST) Date: Fri, 31 Jan 2003 06:42:48 -0800 (PST) From: Bernard Aboba To: Cheryl Madson cc: Van Aken Dirk , Subject: RE: Modefg considered harmful In-Reply-To: <4.3.2.7.2.20030131062231.02567410@mira-sjcm-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > roundabout way (e.g. this whole "special short-lived tunnel" stuff). Sort of > like the implicit "phase 0" of PIC. Also, address assignment may in many > cases end up being associated with the original user credentials (e.g. > what address I give you, if at all, depends on who you are). Conditional address assignment is supported by most modern DHCP servers, and the facilities are quite rich. So it probably makes more sense to use the existing DHCP facilities (including conditional processing of the Class and Client-Identifier options), rather than try to add this functionality to IKE -- especially since the contents of the IKE identifier payload does not necessarily map well to the identifiers used for DHCP conditional address assignment. That means that with Modecfg it is actually quite difficult to create a unified IP addressing plan. > Apart from the above issue, the desired model (in general terms) isn't > clear to me. I never saw any discussion of the below in the IPSRA > requirements. The general requirements are there -- but the details are left for discussion in RFC 3456. > Is all this information really pass-through from the "address assignment > server" to the client? Is there any case (either now or imagined in the > future) where the RAS may have a need to know some of this information > (is the RAS expected to enforce something)? Well, the RAS does need to know what address was assigned to plumb the correct route. But the address assignment and configuration *is* end-to-end -- the RAS is a DHCP Relay, not a DHCP proxy. > If so, how do we define > which pieces the RAS has to care about and which pieces the RAS can > ignore (which becomes an issue in terms of extensibility)? Because the RAS is a DHCP Relay all the obligations of a DHCP Relay apply, as it would for any other Relay application. From owner-ipsec Fri Jan 31 11:09:29 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21017 Fri, 31 Jan 2003 11:07:06 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090F0B@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'Cheryl Madson'" Cc: "'Bernard Aboba'" , ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful Date: Fri, 31 Jan 2003 17:09:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Cheryl Madson [mailto:cmadson@cisco.com] Sent: vrijdag 31 januari 2003 15:59 To: Van Aken Dirk Cc: 'Bernard Aboba'; ipsec@lists.tislabs.com Subject: RE: Modefg considered harmful At 03:28 AM 1/31/2003, Van Aken Dirk wrote: >Hello ipsra people, > >Thank you for this extensive explanation/motivation ! > >Personally I'm in favour of RFC3456 solely because of following reasons: > >1) RFC3456 allows me to separate IKE from IP configuration. >What is the added value of this approach ? >Well I don't need to dig into IKE code in order to have remote IP-IPSec >configuration working. >True I must make changes to the surrounding of IKE (create the necessary >policies, cope with short lived tunnels, add some routes modify a DHCP relay >etc ..). But the added value is I can leave IKE intact and preserve its >security properties. Well, some of us take the view that this is still really part of IKE, just in a roundabout way (e.g. this whole "special short-lived tunnel" stuff). Sort of like the implicit "phase 0" of PIC. Also, address assignment may in many cases end up being associated with the original user credentials (e.g. what address I give you, if at all, depends on who you are). This means that I can have a finer degree of control over where you might be able to go (think of an SP RAS), so I'd argue that there still is a binding with IKE. Doing it outside of IKE can overly complicate things, IMO. >> On the credentials I can more or less agree with you. However I wonder then what your solution is when multiple ModeCfg request must be answered by a VPN GW. This happens in the case where there is a small VPN GW talking to a large one and proxying for a few PC's (not VPN clients). Always use the same credentials for several requests ? On the other hand one might consider the DHCP Relay Agent Information option. A DHCP relay in the VPN GW can easily add user credentials to DHCP requests that must be forwarded. This request travels then on the trusted network to the DHCP server which can further take this information into account. On its way back the DHCP Relay removes this information of course. >> Apart from the above issue, the desired model (in general terms) isn't clear to me. I never saw any discussion of the below in the IPSRA requirements. (Or if it was there, it wasn't represented in a way that us non-remote access geeks understood). >> Hi Cheryl, A reason why there was maybe no discussion in the IPSRA is because DHCP has proven its capabilities and extensibility. >> Is all this information really pass-through from the "address assignment server" to the client? Is there any case (either now or imagined in the future) where the RAS may have a need to know some of this information (is the RAS expected to enforce something)? If so, how do we define which pieces the RAS has to care about and which pieces the RAS can ignore (which becomes an issue in terms of extensibility)? >> I'm no RAS expert either although I'm active in this arena (DSL routers). A RAS configuration is rather simple: a user starts a PPP session with the front-end of an Access Concentrator and provides its credentials (username & password). Typically a Radius client on the back-end of the AC passes this information toward a Radius server who performs the necessary checks. If the user is allowed, an IP address is requested to a DHCP server and given to the Access Concentrator. The AC adds a route in its forwarding table and supplies the IP address to its front-end AC-PPP-deamon. The latter finally delivers it to the original requestor. Again you have the construct of two state machines that must be tied together: PPP and DHCP. The reason of not having DHCP all the way is IMHO historical. PPP grew up in the WAN arena and BOOTP/DHCP in the LAN. Due to broadband Access the boundary between WAN and LAN is disappearing and I guess VPN technology will only accelerate this I cannot answer for the future and extensibility. What I do know is that ModeCfg is almost identical to PPP-IPCP (RFC1332, RFC1877) in functionality: it supports a bare minimum on IP parameters. thx - C ==================================== Cheryl Madson Core IP Engineering; Security and Services Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec Fri Jan 31 11:22:18 2003 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21043 Fri, 31 Jan 2003 11:19:28 -0500 (EST) Date: Fri, 31 Jan 2003 07:09:57 -0800 (PST) From: Bernard Aboba To: Van Aken Dirk cc: "'Cheryl Madson'" , Subject: RE: Modefg considered harmful In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090F0B@TMM_EDGMSMSG01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I cannot answer for the future and extensibility. What I do know is that > ModeCfg is almost identical to PPP-IPCP (RFC1332, RFC1877) in functionality: > it supports a bare minimum on IP parameters. RFC 1877 has been heavily criticized over the years (see James Carlson's PPP book), and the island of address state that it created has proven to be a headache. Also, it became apparent that the set of parameters defined in RFC 1877 was not enough -- and that attempting to duplicate all the DHCP options was not fruitful. So PPP peers such as Windows 2000 and XP had to add support for DHCP anyway! Given what we have learned from history, it makes little sense to continue on with this approach, particularly with IPv6, where there are a well defined set of address and configuration mechanisms for all types of interfaces.