From owner-ipsec@lists.tislabs.com Sat Mar 1 00:24:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h218OZY16454; Sat, 1 Mar 2003 00:24:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA15978 Sat, 1 Mar 2003 02:50:11 -0500 (EST) Message-ID: <3E606674.1020703@indigo.ie> Date: Sat, 01 Mar 2003 07:51:16 +0000 From: Martin Falconer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-gb MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: remove Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk remove From owner-ipsec@lists.tislabs.com Sat Mar 1 08:35:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h21GZNY27528; Sat, 1 Mar 2003 08:35:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16570 Sat, 1 Mar 2003 10:57:55 -0500 (EST) Message-Id: <200303011415.h21EFcof079054@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dan Harkins cc: ipsec@lists.tislabs.com Subject: Re: CREATE_CHILD_SA exchange in IKEv2-05 In-reply-to: Your message of Fri, 28 Feb 2003 09:12:53 PST. <200302281712.h1SHCrE64086@homebrew.trpz.com> Date: Sat, 01 Mar 2003 15:15:38 +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: Towards the end of section 1.3 it says, "Traffic selectors are omitted if this CREATE_CHILD_SA request is being used to change the key of the IKE-SA." What about the suite? => I don't understand your concern: suites are in the SA payload as proposals so are NOT optional. So one knows the exchange is an IKE-SA rekey as soon as it decodes the SA payload. Doesn't that determine whether the request is being used to change the key of the IKE SA? => yes. What would happend if the SA specified an ESP suite but there were no Traffic Selectors? => an error as only the IKE-SA has no traffic selectors. Also, can the suite change from one IKE SA to the next? => I don't believe we have to allow this (suite change). Suggested verbage: "When the CREATE_CHILD_SA request is used to rekey the IKE SA Traffic Selectors MUST be omitted and the suite used to negotiate the IKE SA MUST be the same as that from the IKE_SA_INIT exchange that created the SA being rekeyed." => this seems better than the original wording. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sat Mar 1 08:35:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h21GZdY27541; Sat, 1 Mar 2003 08:35:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16571 Sat, 1 Mar 2003 10:58:00 -0500 (EST) Message-Id: <200303011357.h21Dvvof078944@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jayant Shukla" cc: ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question In-reply-to: Your message of Fri, 28 Feb 2003 08:59:50 PST. <02c501c2df4a$ce821240$5803a8c0@trlhpc1> Date: Sat, 01 Mar 2003 14:57:57 +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 concern is that I believe the way you fix the checksum will give > a correct checksum from a wrong one, i.e., you loose the detection > of errors which is the purpose of the checksum. > IMHO the checksum must be fixed using the original and new IP addresses, > i.e., you add the original addresses and substract the new addresses > in an one-complement arithmetic (the checksum is the opposite of the > sum of the pseudo-header and the transport message in one-complement. > At the exception of UDP/IPv4, zero is normalized, i.e., +0 is used. > What I propose is a direct application of RFC 1624 which requires > the original addresses). > I don't think you need to do what you have explained. => I need it if I consider the transport layer is independent. Since you will authenticate and decrypt the packet, it guarantees that you don't have any flipped bits in the body of the encapsulated data. => the transport checksum is between transport layers. If I believe in your argument, it is impossible to get errors as soon as packets don't go through a link without CRCs... This is contrary to real world experiences where bad TCP checksums occured on an Ethernet link... IMHO we should not violate the principle of layer separation here. If you want, test the checksum before you authenticate/decrypt the packet. => how? the checksum is ciphered. Regards Francis.Dupont@enst-bretagne.fr PS: about NAT traversal for IKEv2, I always follow Tero Kivinen's I-D (draft-ietf-ipsec-nat-t-ike-05.txt) which is a complete and already used (i.e., experimentally proved) specification. From owner-ipsec@lists.tislabs.com Sat Mar 1 09:15:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h21HFBY28282; Sat, 1 Mar 2003 09:15:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16645 Sat, 1 Mar 2003 11:42:56 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66A72@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'ipsec@lists.tislabs.com'" , "'charlie_kaufman@notesdev.ibm.com'" Cc: "Darren Dukes (E-mail)" Subject: RE: CP(CFG_REQUEST) required? Date: Sat, 1 Mar 2003 08:42:31 -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 After talking this through with Darren Dukes, here is what we came up with: Design Goals: - we do not want bob to have to perform a config server look up if he doesn't know for sure that alice can/will accept the CFG_REPLY - Bob should not send something that conflicts with local (policy) configuration, i.e. if local policy configuraiton dictates that for IDi=alice CP is required, if alice does not send CFG_REQUEST, bob needs to fail the connection - A CP failure should be accompanied by a reason So here is the proposed text in sect 2.19: "Responder MUST not send a CFG_REPLY withouth having first received a CP(CFG_REQUEST) from Initiator, because we do not want the IRAS to perform an unneccesary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS SHOULD fail the request, and terminate the IKE exchange with the appropriate error message. "The protocol terminates when the Responder sends the Initiator CP(CFG_REPLY) payload , or when the Responder terminates IKE due to a policy conflict. In the case of a policy conflict, Responder will terminate by sending [FOO]." Charlie (others), I need some help with [FOO]. It wasn't immediately clear to me the best way for Responder to terminate IKE. What is clear is that we need a specific failure message that communicates something like, "CP required, but no CP(CFG_REQUEST) received." Possibly the way to do this is to creat a new NOTIFY MESSAGE for Responder to send, something like CP-REQUIRED. Here is a proposal, but feel free to suggest something better. In sect. 3.10.1: "FAILED-CP-REQUIRED 37 "Sent by Responder in the case where CP(CFG_REQUEST) was expected, but not recieved, and such is a conflict of locally configured policy. There is no associated data." We would also need to do the IANA-thing on Notify Type 37. Let me know what you think, Gregory. > -----Original Message----- > From: Gregory Lebovitz [mailto:Gregory@netscreen.com] > Sent: Friday, February 28, 2003 6:05 PM > To: ipsec@lists.tislabs.com > Subject: CP(CFG_REQUEST) required? > > > What happens in the case where, for a certain IDi, the > Responder's local > policy dictates that CP(CFG) is required, but the Initiator > did not send the > CP(CFG_REQUEST)? Can Responder simply send the CP(CFG_REPLY) > as if he had > gotten the request? > !! NETSCREEN HAS MOVED !! New Contact Info: 408.543.8002 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.543.8002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ From owner-ipsec@lists.tislabs.com Sat Mar 1 10:12:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h21ICvY01222; Sat, 1 Mar 2003 10:12:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16740 Sat, 1 Mar 2003 12:41:00 -0500 (EST) Message-Id: <200303011659.h21Gxsof080098@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: comments/concerns about ikev2-05 Date: Sat, 01 Mar 2003 17:59:54 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk - question - section 1.2: why the SA2 stuff is mandatory, i.e., why the IKE_AUTH has to build an IPsec SA pair? The answer seems to be this is simpler but I don't know if a paranoid guy should not prefer to get PFS also for the first IPsec SA pair... - comment - section 1.5: this section (and the 2.21 one) uses to hidden and incorrect assumption that an address identifies only one node. Of course with NAT traversal many nodes can share the same address (but not the same port), and a node can use many addresses. I'd like to see more care in the wording. - comment - section 2.1: the text is not enough accurate about what is retransmitted. IMHO it is the IKE message itself only. For instance if a responder receives for the second time a request but from a different address, it should send the same reply but to the new address. To solve this kind of issues I propose: * to make very clear that replies are sent with the reversed addresses and ports (i.e., source becomes destination and destination source, both for the IP header addresses and the UDP ports). Note this rule is very strict and suffers no exception. * to specify that what is restransmitted/cached/etc is the IKE message itself and not the whole IP packet. - comment - section 2.19: the term IRAC and IRAS must be introduced (there is no acronym section). - comment - section 2.21: read the comment about section 1.5 and the "UDP port 500" should be changed in "UDP port 500 or 4500". - concern - section 2.23: "responses SHOULD be sent to the port from whence they came" has to be changed in "responses MUST be sent to the address and port from whence they came and from the address and port to whence they came". Read the comment about section 2.1. Note that I have a concern about to perform NAT detection in the IKE_SA_INIT exchange, cf my comment about section 3.10.1. - question - section 3.6: this section defines certificate encoding values without the corresponding layout, i.e., some defined types are not usable because underspecified. It is the case of the DNS signed key. Is it the KEY RRset with its SIG RRs in wire format (cf RFC 1035 and 2535)? - question - section 3.6: hash and URL of PKIX stuff doesn't require HTTP URLs. This is fine but HTTP-CERT-LOOKUP-SUPPORTED seems to be more restricting. LDAP at least should be allowed. (IMHO the "HTTP-based URL" idea (?) is the source of this issue) Note: I'd like to be able to get certificates or public keys through the DNS in a standardized way. - typo - section 3.10.1: INVALID-SPI is defined twice. At least one should be specialized, i.e., value 4 for INVALID-IKE-SPI or value 11 for INVALID-IPSEC-SPI. - typo - section 3.10.1: where is the COOKIE-REQUIRED notification? (proposal: either define or delete it) - concern - section 3.10.1: I signaled that NAT-DETECTION-*-IPs were buggy. Unfortunately they are still wrong. If we look at the Tero's draft about NAT traversal (draft-ietf-ipsec-nat-t-ike-05.txt): - the detection can be done in the second exchange (IKE_AUTH). - the SHA-1 of SPIs (why?), addresses and ports can be easily faked by an attacker. As the NAT traversal is less secure, the current spec opens the door to a bidding down attack. I tried both to fix the NAT traversal support and to introduce mobility/multihoming support in my draft about address management. A new version should be available soon, the name of my I-D is: draft-dupont-ikev2-addrmgmt-01.txt Everything in it should be considered at the exception of the explicit peer address mechanism (same effect can be got with rekeying, of course not at the same price). - typo - section 3.14: s/Encrpted/Encrypted/ - typo - appendix A: two 12) - typo - history H.4: s/from IKEv2-05/from IKEv2-04/ - comment: there is nothing about IKE keepalives... If it is added one day (IMHO it should be), with NAT traversal the peer behind a NAT SHOULD send requests. Regards Francis.Dupont@enst-bretagne.fr PS: of course detailed concerns with proposals can be found in my draft. I submitted it two days ago but I can send it to impatients... From owner-ipsec@lists.tislabs.com Sat Mar 1 17:02:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h2212NY22458; Sat, 1 Mar 2003 17:02:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17403 Sat, 1 Mar 2003 19:11:42 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200302271032.h1RAWGof067116@givry.rennes.enst-bretagne.fr> Subject: Re: Another NAT Traversal question To: Francis Dupont Cc: ipsec@lists.tislabs.com, "Jayant Shukla" X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Fri, 28 Feb 2003 23:11:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 03/01/2003 07:14:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen wrote: > Francis Dupont wrote: > > >From what I recall, the authors had given up on the transport mode and > > one of them had stated on this list that only 'tunnel mode' will be > > pushed for v2. > > > > => I am afraid that there is no consensus to drop the transport mode, > > so as the NAT traversal is in the charter, there is a problem to > > really solve. > > Let's ask it this way: what is the real need for transport mode ESP > to work over NAT? You can do everything with tunnel mode ESP, including > L2TP/IPsec. IKEv2 certainly hasn't given up on transport mode (though I share with others some skepticism concerning its value). Whether to support transport mode through a NAT is a fair question. It will add some complexity to the ESP implementation because on decapsulation ESP would have to adjust the TCP checksums because they are based on the IP addresses that the NAT changed but the NAT can't fix the checksums because they are encrypted. My vote would be to just say no to using transport through NATs, but it isn't that hard to specify. The spec currently says that tunnel mode is mandatory to support and transport mode is optional, so an implementation could choose to not support transport mode over NATs without losing interoperability (though it would lose performance). Francis.Dupont@enst-bretagne.fr wrote: > > PS (for the list): should we be more accurate in IKEv2 draft? > Current text in draft-ietf-ipsec-nat-t-ike-05.txt is: > > The original source and destination addresses are used in > transport mode to incrementally update the TCP/IP checksums so that they > will match after the NAT transform (The NAT cannot do this, because the > TCP/IP checksum is inside the UDP encapsulated IPsec packet). > > (BTW this text is fine for me, the issue is that it is not in both drafts). You're right. I thought I'd copied that text to draft-ietf-ipsec-ikev2-05.txt, but I see that it's not there. The spec as it stands is not incorrect, but fails to specify how you're supposed to compute and adjust the TCP checksums for transport mode through NATs. But looking at it again here, I don't think this works. If the TCP checksum is computed based on the addresses the sender of the packet sees, then packets going from the node with real addresses destined for the node with NATed addresses will have a TCP checksum computed based on the source address of the node with the real address and the destination address of the IPsec gateway. To adjust the checksum, the receiver would have to know the address of the NAT box, but I believe that as currently specified in both IKEv2 and NAT Traversal for IKEv1, the NATed node does not know the IP address of the NAT box. How does this work in deployed systems?? We could add more fields, but I have an alternate proposal: The traffic selectors have to contain the IP addresses of each node as known to the node itself. What if we said that if you use NATed transport mode, you have to compute and verify the TCP checksums using the addresses in the traffic selectors. That way the NAT-OA payload is not needed and the above problem is solved. --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@lists.tislabs.com Sat Mar 1 18:52:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h222q9Y27019; Sat, 1 Mar 2003 18:52:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17571 Sat, 1 Mar 2003 21:20:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15969.24975.315000.180702@gargle.gargle.HOWL> Date: Sat, 1 Mar 2003 20:42:39 -0500 From: Paul Koning To: shacham@trpz.com Cc: dharkins@trpz.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200302281717.h1SHHAE64102@homebrew.trpz.com> <15967.51785.279370.267569@pkoning.dev.equallogic.com> <3E5FF092.3090409@trpz.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Abraham" == Abraham Shacham writes: Abraham> Paul Koning wrote: >> IKEv1 handled this by negotiation, but 90% of what it does for >> IPcomp is unnecessary and confusing. Abraham> Could you substantiate "90%", detail what is exactly Abraham> "unnecessary", and "confusing" to whom? We discussed that a while back, and Henry Spencer just summarized it very nicely. As for "confusing" -- to the implementer of IKEv1. paul From owner-ipsec@lists.tislabs.com Sat Mar 1 20:21:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h224LGY01075; Sat, 1 Mar 2003 20:21:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17705 Sat, 1 Mar 2003 22:45:59 -0500 (EST) From: "Jayant Shukla" To: Cc: Subject: RE: Another NAT Traversal question Date: Sat, 1 Mar 2003 19:46:44 -0800 Message-ID: <02e801c2e06e$584bc420$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: <200303011357.h21Dvvof078944@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst- > bretagne.fr] > > I don't think you need to do what you have explained. > > => I need it if I consider the transport layer is independent. > Transport layer is not independent of IP layer. The pseudo-header in transport layer checksum contains IP header information. > If you want, test the checksum before you authenticate/decrypt the > packet. > > => how? the checksum is ciphered. > Checksum of the UDP header! If you check the checksum of the UDP header, and authenticate the packet, how in the world can you have errors or wrong checksum in the encapsulated part of the packet (I mean apart from the wrong IP address)? Please explain! Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Sat Mar 1 22:24:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h226OSY06583; Sat, 1 Mar 2003 22:24:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17824 Sun, 2 Mar 2003 00:48:02 -0500 (EST) From: "Jayant Shukla" To: "'Andrew Krywaniuk'" , Subject: RE: suites vs. a la carte and IPcomp in IKEv2-05 Date: Sat, 1 Mar 2003 20:37:22 -0800 Message-ID: <02e901c2e075$6ac731f0$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 Andrew Krywaniuk > Sent: Friday, February 28, 2003 3:33 PM > To: ipsec@lists.tislabs.com > Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 > > > >I think the best way to accomodate this disconnect is with the > >"gui suites" proposal -- on the wire, send a la carte parameters, but > >require only the suite combinations to be supported through the > >management interfaces. > > My sentiments exactly. > I am sure if I completely understood you, but you are proposing GUI suites, but require one or more a la carte proposals to be supported? In that case I would agree with you. Speaking as someone whose product has a GUI to build proposals! We had trouble in interop testing with a third party VPN hardware box because our proposals did not match the only proposal that device would accept. The GUI helps in building proposals easily, but if the proposal does not exactly match what the other side would accept, you got problems. I almost put in a method to analyze received proposals to see if they could be generated by our GUI. Cipher suites are important if you want security according to your needs/requirements and a la carte proposals are important for interop. Regards, Jayant www.trlokom.com > 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@lists.tislabs.com Sat Mar 1 22:47:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h226lGY07476; Sat, 1 Mar 2003 22:47:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA17888 Sun, 2 Mar 2003 01:19:06 -0500 (EST) From: "Jayant Shukla" To: Cc: Subject: RE: Another NAT Traversal question Date: Sat, 1 Mar 2003 22:14:12 -0800 Message-ID: <02eb01c2e082$f2059e60$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 > > My vote would be to just say no to using transport through NATs, I agree! > But looking at it again here, I don't think this works. If the TCP > checksum > is computed based on the addresses the sender of the packet sees, then > packets going from the node with real addresses destined for the node with > NATed addresses will have a TCP checksum computed based on the source > address of the node with the real address and the destination address of You are correct and transport mode NAT traversal only works with L2TP or if there is only one host behind the destination NAT. Another reason to kill it because it is not a general solution. > the IPsec gateway. To adjust the checksum, the receiver would have to know > the address of the NAT box, but I believe that as currently specified in > both IKEv2 and NAT Traversal for IKEv1, the NATed node does not know the > IP > address of the NAT box. How does this work in deployed systems?? We could > add more fields, but I have an alternate proposal: > > The traffic selectors have to contain the IP addresses of each node as > known to the node itself. What if we said that if you use NATed transport > mode, you have to compute and verify the TCP checksums using the addresses > in the traffic selectors. That way the NAT-OA payload is not needed and > the > above problem is solved. > Good suggestion! Now you are moving in the direction of our method. :-) Regarding how it works in deployed systems! A more general version of your proposal is in our product and there are tens of thousands users using it in all kinds of situations. You will realize that using the IP address of the node as known to node itself is not good either as there may be IP address conflict between road warriors. Take a look at the free version of our product to see how we have solved the problem. Anyway, we have addressed all possible deployment scenarios except for mobile IP. We are hard at work to address that. Unfortunately, there are only 24 hrs in a day. :-) IMHO, killing the current transport mode with NAT traversal is very important. Especially if one is concerned about efficiency, security, and QoS for applications like VoIP. There is no need for a solution that is not covered by another solution and at the same time creates obstacles in deployment of many important applications and a better solution. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Sun Mar 2 01:40:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h229erY07583; Sun, 2 Mar 2003 01:40:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18179 Sun, 2 Mar 2003 04:07:20 -0500 (EST) From: "Yoav Nir" To: "'Gregory Lebovitz'" , , Cc: "'Darren Dukes \(E-mail\)'" Subject: RE: CP(CFG_REQUEST) required? Date: Sun, 2 Mar 2003 11:09:32 +0200 Message-ID: <004301c2e09b$705fe280$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66A72@SARATOGA.netscreen.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds right to me Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gregory Lebovitz Sent: Saturday, March 01, 2003 6:43 PM To: 'ipsec@lists.tislabs.com'; 'charlie_kaufman@notesdev.ibm.com' Cc: Darren Dukes (E-mail) Subject: RE: CP(CFG_REQUEST) required? After talking this through with Darren Dukes, here is what we came up with: Design Goals: - we do not want bob to have to perform a config server look up if he doesn't know for sure that alice can/will accept the CFG_REPLY - Bob should not send something that conflicts with local (policy) configuration, i.e. if local policy configuraiton dictates that for IDi=alice CP is required, if alice does not send CFG_REQUEST, bob needs to fail the connection - A CP failure should be accompanied by a reason So here is the proposed text in sect 2.19: "Responder MUST not send a CFG_REPLY withouth having first received a CP(CFG_REQUEST) from Initiator, because we do not want the IRAS to perform an unneccesary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS SHOULD fail the request, and terminate the IKE exchange with the appropriate error message. "The protocol terminates when the Responder sends the Initiator CP(CFG_REPLY) payload , or when the Responder terminates IKE due to a policy conflict. In the case of a policy conflict, Responder will terminate by sending [FOO]." Charlie (others), I need some help with [FOO]. It wasn't immediately clear to me the best way for Responder to terminate IKE. What is clear is that we need a specific failure message that communicates something like, "CP required, but no CP(CFG_REQUEST) received." Possibly the way to do this is to creat a new NOTIFY MESSAGE for Responder to send, something like CP-REQUIRED. Here is a proposal, but feel free to suggest something better. In sect. 3.10.1: "FAILED-CP-REQUIRED 37 "Sent by Responder in the case where CP(CFG_REQUEST) was expected, but not recieved, and such is a conflict of locally configured policy. There is no associated data." We would also need to do the IANA-thing on Notify Type 37. Let me know what you think, Gregory. > -----Original Message----- > From: Gregory Lebovitz [mailto:Gregory@netscreen.com] > Sent: Friday, February 28, 2003 6:05 PM > To: ipsec@lists.tislabs.com > Subject: CP(CFG_REQUEST) required? > > > What happens in the case where, for a certain IDi, the > Responder's local > policy dictates that CP(CFG) is required, but the Initiator > did not send the > CP(CFG_REQUEST)? Can Responder simply send the CP(CFG_REPLY) > as if he had > gotten the request? > !! NETSCREEN HAS MOVED !! New Contact Info: 408.543.8002 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.543.8002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ From owner-ipsec@lists.tislabs.com Sun Mar 2 06:39:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22EdwY26872; Sun, 2 Mar 2003 06:39:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18519 Sun, 2 Mar 2003 09:01:30 -0500 (EST) Message-Id: <200303021400.h22E0tof082387@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com, "Jayant Shukla" Subject: Re: Another NAT Traversal question In-reply-to: Your message of Fri, 28 Feb 2003 23:11:07 EST. Date: Sun, 02 Mar 2003 15:00:55 +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: Whether to support transport mode through a NAT is a fair question. => personally I have no interest in NAT traversal (my objective is to reconcile IPsec with mobility and multihoming) so I use Tero's draft as the state of art for NAT traversal. There is in it a simple solution for transport mode through a NAT so I can't see a good reason to give up on it. It will add some complexity to the ESP implementation because on decapsulation ESP would have to adjust the TCP checksums because they are based on the IP addresses that the NAT changed but the NAT can't fix the checksums because they are encrypted. My vote would be to just say no to using transport through NATs, but it isn't that hard to specify. => I agree: if the burden is small enough, just keep it. The spec currently says that tunnel mode is mandatory to support and transport mode is optional, so an implementation could choose to not support transport mode over NATs without losing interoperability (though it would lose performance). => NAT traversal itself is optional. > PS (for the list): should we be more accurate in IKEv2 draft? > Current text in draft-ietf-ipsec-nat-t-ike-05.txt is: > > The original source and destination addresses are used in > transport mode to incrementally update the TCP/IP checksums so that they > will match after the NAT transform (The NAT cannot do this, because the > TCP/IP checksum is inside the UDP encapsulated IPsec packet). > > (BTW this text is fine for me, the issue is that it is not in both drafts). You're right. I thought I'd copied that text to draft-ietf-ipsec-ikev2-05.txt, but I see that it's not there. The spec as it stands is not incorrect, but fails to specify how you're supposed to compute and adjust the TCP checksums for transport mode through NATs. => I am afraid the spec as it stands is incorrect, but not about this point. But looking at it again here, I don't think this works. => I disagree but we have a procedure point here: can we assume that the draft-ietf-ipsec-ikev2-05.txt works and just imports the NAT traversal stuff from it with as little as possible changes (i.e., no spurious change :-)? If the TCP checksum is computed based on the addresses the sender of the packet sees, then packets going from the node with real addresses destined for the node with NATed addresses will have a TCP checksum computed based on the source address of the node with the real address and the destination address of the IPsec gateway. => which IPsec gateway? It is transport mode. To adjust the checksum, the receiver would have to know the address of the NAT box, but I believe that as currently specified in both IKEv2 and NAT Traversal for IKEv1, the NATed node does not know the IP address of the NAT box. How does this work in deployed systems?? => the node which is at the good side (i.e., not behind) of NATs knows the real address of the other node. There are two equivalent ways to implement this: - exchange the real address with the NATed address when packets go between the network (where IPsec is) and transport layers. Theorically this is the best because the PCB will get the real address but it is hairy to implement. - adjust the transport checksum when packets go between the network and transport layers. This is the solution described in Tero's draft. Note that this is an "incremental update", not a recomputation, so the checksum is still end-to-end between the transport layers of the two peers. We could add more fields, but I have an alternate proposal: => I prefer Tero's draft one because it is proved to work. In fact, I propose to discuss this in Tero's draft context only. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Mar 2 06:51:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22EpKY27073; Sun, 2 Mar 2003 06:51:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18544 Sun, 2 Mar 2003 09:20:32 -0500 (EST) Message-Id: <200303021420.h22EKQof082513@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jayant Shukla" cc: ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question In-reply-to: Your message of Sat, 01 Mar 2003 19:46:44 PST. <02e801c2e06e$584bc420$5803a8c0@trlhpc1> Date: Sun, 02 Mar 2003 15:20:26 +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 don't think you need to do what you have explained. > > => I need it if I consider the transport layer is independent. Transport layer is not independent of IP layer. => it is a wording concern. What I tried to mean is that the transport layer and the network layer are two different layers. The pseudo-header in transport layer checksum contains IP header information. > If you want, test the checksum before you authenticate/decrypt the > packet. > > => how? the checksum is ciphered. Checksum of the UDP header! If you check the checksum of the UDP header, and authenticate the packet, how in the world can you have errors or wrong checksum in the encapsulated part of the packet (I mean apart from the wrong IP address)? Please explain! => for instance in the hardware which manages IPsec and the main memory. There is a lot of stuff about this in the archive because the discussion about "why the transport checksum is mandatory even we use links with stronger error detection, ..." is very recurrent (just a bit less than "why IPv6 has no header checksum"). BTW I propose to move the object of this discussion to Tero's NAT traversal I-D (draft-ietf-ipsec-nat-t-ike-05.txt) which seems to be already implemented and used. Regards Francis.Dupont@enst-bretagne.fr PS: I didn't follow the iSCSI list but I'll be surprised if there is nothing about "remove the transport checksum because ..." in its archive. From owner-ipsec@lists.tislabs.com Sun Mar 2 08:07:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22G7nY02245; Sun, 2 Mar 2003 08:07:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18744 Sun, 2 Mar 2003 10:36:40 -0500 (EST) From: "Jayant Shukla" To: "'Andrew Krywaniuk'" , Subject: RE: suites vs. a la carte and IPcomp in IKEv2-05 Date: Sun, 2 Mar 2003 07:37:44 -0800 Message-ID: <02f401c2e0d1$addaa790$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Andrew Krywaniuk [mailto:askrywan@hotmail.com] > Sent: Sunday, March 02, 2003 1:58 AM > To: jshukla@trlokom.com; ipsec@lists.tislabs.com > Subject: RE: suites vs. a la carte and IPcomp in IKEv2-05 > > >Cipher suites are important if you want security according to your > >needs/requirements and a la carte proposals are important for interop. > > Well actually I waws thinking pretty much the opposite. Cipher suites are > important for interop and a la carte proposals are important if you want > security according to your needs/requirements > Never mind, it was my mistake! I swapped the two and ended up saying exactly opposite of what I meant. It was getting late last night. :-) Regards, Jayant www.trlokom.com > Andrew > -------------------------------------- > The odd thing about fairness is when > we strive so hard to be equitable > that we forget to be correct. > > > > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-ipsec@lists.tislabs.com Sun Mar 2 09:50:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h22HoNY10896; Sun, 2 Mar 2003 09:50:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18852 Sun, 2 Mar 2003 12:12:53 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <02f401c2e0d1$addaa790$5803a8c0@trlhpc1> References: <02f401c2e0d1$addaa790$5803a8c0@trlhpc1> 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: Sun, 2 Mar 2003 09:16:24 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: UI suites (was: suites vs. a la carte and IPcomp in IKEv2-05) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a small point of clarification. The original proposal was for *UI* suites, not *GUI* suites. You don't need a dialog box to type in the number "12" (which could be one type of suite identifier) or to type in the name "Suite C". Saying "GUI suites" makes it sound like you would have a bunch of radio buttons, check boxes, and drop-down lists, which is exactly what UI suites avoids. Maybe you have a single drop-down list with the supported suite numbers or names, but that's pretty much it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun Mar 2 17:59:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h231xnY27653; Sun, 2 Mar 2003 17:59:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19577 Sun, 2 Mar 2003 20:22:50 -0500 (EST) Message-ID: From: "Wong, Stephen" To: ipsec@lists.tislabs.com Subject: RE: remove Date: Sun, 2 Mar 2003 17:26:25 -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 Remove From owner-ipsec@lists.tislabs.com Sun Mar 2 20:13:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h234DlY01666; Sun, 2 Mar 2003 20:13:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19854 Sun, 2 Mar 2003 22:43:02 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200302281707.h1SH7LE64056@homebrew.trpz.com> Subject: Re: comments on IKEv2-05 To: Dan Harkins Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 1 Mar 2003 17:00:08 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/02/2003 10:45:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > I have several comments on IKEv2 that I'm going to spread > across different messages to keep from sending on huge post. A wonderful idea that I will try to emulate. Sorting messages by thread is a lot easier when there is only one topic in each one. > I'll start here with minor nits: > > - Section 2.13 describes a Diffie-Hellman group as a cryptographic > algorithm that takes fixed size key. That is wrong. Fixed. > > - page 82 and the TOC: s/Author/Editor/ Fixed. > > - Section 8.1 should include a normative reference to RFC2451. > (A good way to tell whether it's normative or informative is to > check if implementation of the requirement can be visible > externally and if it has an impact on interoperability. Yes on > both counts: normative). Done, though I'd quibble with the criteria. I'd say it's normative if you can't implement something compliant with this spec without information from the other. A normative reference can be made informative by copying its critical content into the referencing document. RFC2451 is clearly normative by my definition as well. I believe there are a lot of other normative references missing. I keep not getting to tracking them all down. If others would like to point them out to me, there's a better chance the list will be complete. > > - Section 1.4 The Informational Exchange says, "When SAs are nested, > as when data (and IP headers if in tunnel mode) are encapsulated > first with IPcomp, then with ESP, and finally with AH between the > same pair of endpoints...." How does one negotiate such nested SAs > using IKEv2? I don't think it's possible. One would have to define a suite that contains multiple nested protocols. The spec says how to pass the multiple SPIs in that case. There are currently no suites defined that negotiate nested SAs. I believe they are a bad idea, but I didn't dare remove the functionality from the protocol for fear someone would deem it crucial. Unless you support a suite that includes nested SAs, there is no implementation complexity added by their possibility. > > - page breaks need to be thought through more. For instance, the > Authentication Payload in section 3.8 is bisected by a page break. I went through and fixed the most obvious problems. Of course, another set will come up when I run it off again, but I'll try to keep on top of this. I did make sure that there would be no page breaks in figures of immediately following section titles. --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@lists.tislabs.com Mon Mar 3 03:19:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23BJhY11662; Mon, 3 Mar 2003 03:19:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20409 Mon, 3 Mar 2003 05:47:51 -0500 (EST) Date: Mon, 3 Mar 2003 10:33:34 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: The CR payload still In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 26 Feb 2003, Pekka Riikonen wrote: : : explicit specifications about when the CERT and CERTREQ packets much : : be sent and how they should be handled, the addition of crypto suites, : : : I would still raise the issue of CR payload usage I mentioned a while : back. The ability for initiator to request 'any' cert from responder : (regardless of the CA) would be in my opinion important to have. The way : specs seems to suggest implementation to work is that CERT is not sent if : CERTREQ is not sent, if CERTREQ was sent but no such CA was found CERT is : still not sent. This means that you must know the CA before hand or you : must have the cert cached for the exchange to ever succeed (since you : won't have the public key to verify the AUTH). Now, maybe in ideal world : everyone always know who everyone else trusts or everybody trusts always : the same CAs but I think in real world this won't be the case. : : The way in IKEv1 this was done was to unofficially agree between vendors : (eg. in every bakeoff for past several years I've attended to) that empty : CR payload means kind of "any" request. IKEv2 does not allow this, but : pki-profile provides a loophole for it anyway. What I am suggesting is : that empty CR payloads would be allowed in IKEv2 (explicitly), or by some : other mechanism (eg. ANY cert encoding (but I don't like this very much)). : Ted, to your call for people to write the text for their ideas, I shall reply to my own email with the text for this CERTREQ. :) It says, Empty (zero length) CA names MUST NOT be generated and SHOULD be ignorred. should be removed and later to say something like this, If empty CERTREQ payload is received the sender indicates that it does not require any specific certificate or certificate chain, but it may accept any certificate. If so the processor SHOULD send its local certificate or certificate chain it is going to use in the negotiation. The sender of this payload will later decide whether it will trust the certificate (by perhaps prompting first a human operator). or something like that... Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SSH Communications Security Corp. | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Mon Mar 3 03:20:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23BK0Y11703; Mon, 3 Mar 2003 03:20:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20403 Mon, 3 Mar 2003 05:46:54 -0500 (EST) Message-ID: <3E630CD7.9090108@trpz.com> Date: Mon, 03 Mar 2003 00:05:43 -0800 From: Abraham Shacham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Spencer CC: IP Security List , Dan Harkins , ippcp Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nowhere in the IKEv2 I-D the issue of using IPComp CPIs from the pre-assigned transform ID range is mentioned, afaik. On the other hand, IPCOMP-SUPPORTED (page 54) seems to provide all the parameters available via IKEv1, namely 16-bit CPI, 8-bit transform ID, and optional attributes: IPCOMP-SUPPORTED 24581 This notification may only be included in a message containing an SA payload negotiating a CHILD-SA and indicates a willingness by its sender to use IPcomp on this SA. The data associated with this notification includes a two byte IPcomp CPI followed by a one octet transform ID optionally followed by attributes whose length and format is defined by that transform ID. A message proposing an SA may contain multiple IPCOMP-SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one. Please note that using a CPI from the predefined range has its limitation, as the implementation notes in RFC-3173 detail. Regards, avram Henry Spencer wrote: > On Fri, 28 Feb 2003, Dan Harkins wrote: > >> You do have to agree on something. Namely, which of the 3 possible >>compression algorithms you will be using to uncompress the data >>you receive... > > > No, there is no need for negotiated agreement on that. It suffices that > the other end sends with an algorithm you have advertised your willingness > to uncompress with. (Since compression is *always* at the sender's option, > the receiver can never require it.) > > Only if the algorithms involve non-trivial parameters that the two ends > must agree on (and which there is no reasonable default for) is actual > negotiation more or less required. > > >>and what CPI will be used in the IPcomp header that >>encapsulates that compressed data. > > > There is no need for negotiated agreement on that either, since there are > pre-assigned CPIs for the standard algorithms. > > Henry Spencer > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Mon Mar 3 03:20:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23BK1Y11705; Mon, 3 Mar 2003 03:20:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20402 Mon, 3 Mar 2003 05:46:52 -0500 (EST) Message-ID: <3E6310A7.9080801@trpz.com> Date: Mon, 03 Mar 2003 00:21:59 -0800 From: Abraham Shacham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IP Security List CC: ippcp Subject: IKEv2-05: IPComp (editorial) comments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk s/IPcomp/IPComp/ s/RFC 2393/RFC 3173/ In page 54: The Transform IDs currently defined are: Name Number Defined In RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 (RFC2394) IPCOMP_LZS 3 (RFC2395) Following RFC-3051, add: IPCOMP_LZJH 4 (RFC3051) Thanks, avram From owner-ipsec@lists.tislabs.com Mon Mar 3 05:52:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23DqKY23657; Mon, 3 Mar 2003 05:52:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20704 Mon, 3 Mar 2003 08:15:30 -0500 (EST) Message-ID: <3E634815.3060509@f-secure.com> Date: Mon, 03 Mar 2003 14:18:29 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayant Shukla CC: "'Francis Dupont'" , ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question References: <02c501c2df4a$ce821240$5803a8c0@trlhpc1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2003 12:18:34.0824 (UTC) FILETIME=[030F8480:01C2E17F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant Shukla wrote: > >>-----Original Message----- >>From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com] > >>On Behalf Of Francis Dupont >> >>=> my concern is that I believe the way you fix the checksum will give >>a correct checksum from a wrong one, i.e., you loose the detection >>of errors which is the purpose of the checksum. >>IMHO the checksum must be fixed using the original and new IP > > addresses, > >>i.e., you add the original addresses and substract the new addresses >>in an one-complement arithmetic (the checksum is the opposite of the >>sum of the pseudo-header and the transport message in one-complement. >>At the exception of UDP/IPv4, zero is normalized, i.e., +0 is used. >>What I propose is a direct application of RFC 1624 which requires >>the original addresses). >> > > > I don't think you need to do what you have explained. Since you will > authenticate and decrypt the packet, it guarantees that you don't have > any flipped bits in the body of the encapsulated data. No, this guarantees only that the bits didn't flip while they were encrypted. If the bits were flipped before they entered the ESP tunnel, that's another question. Please don't anybody try to reinvent the wheel, unless you find the existing wheel is not round enough. :) 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@lists.tislabs.com Mon Mar 3 07:55:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23FtAY28858; Mon, 3 Mar 2003 07:55:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21055 Mon, 3 Mar 2003 10:18:31 -0500 (EST) Date: Mon, 3 Mar 2003 10:23:55 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Configuration portion of OPEN ISSUES... In-Reply-To: <200302262313.h1QND0Im030476@marajade.sandelman.ottawa.on.ca> Message-ID: References: <200302262313.h1QND0Im030476@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : >> I *think* everyone can live with this. Some have expressed a desire : >> for other solutions (DHCP in IKE for example), but I have not heard : >> anyone say that the above solution is not acceptable. : : Bill> You should have heard people (including myself) say that any : Bill> configuration scheme within IKE should reuse as much of DHCP syntax : Bill> and option codes as possible rather than defining a wholly new : Bill> parameter space. : : I want to emphasis that just because one says "DHCP-over-IKE", that : does not mean that such a system has to talk to a DHCP server. Decoding : DHCP messages is no more difficult than radius, PPP or IKEv2. (Maybe : a lot easier than IKEv1) : : You can implement the relevant pieces in the gateway. DHCP vs modecfg : can be just about syntax. : : I will fill the state machine changes, and suggest text for dhcp-over-ike, : but I won't bother if there is no interest. : I was saying that I like DHCP but it's exchange is too long IMHO for IKE. Rather CP should just use DHCP options (RFC2132) and keep the exchange as short as possible. This wouldn't require clients to do DHCP client protocol (just options encoder/decoder) and gateways could translate them to whatever needed. I don't know what Michael exactly meant what he wrote, whether it was effectively this same thing or not but, I think Michael you should update the DHCP over IKE draft to reflect your idea. Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SSH Communications Security Corp. | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Mon Mar 3 09:00:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23H0jY05495; Mon, 3 Mar 2003 09:00:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21328 Mon, 3 Mar 2003 11:22:58 -0500 (EST) X-Originating-IP: [207.6.241.221] From: "Andrew Krywaniuk" To: jshukla@trlokom.com, ipsec@lists.tislabs.com Subject: RE: suites vs. a la carte and IPcomp in IKEv2-05 Date: Sun, 02 Mar 2003 04:57:37 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Mar 2003 09:57:38.0233 (UTC) FILETIME=[28206290:01C2E0A2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Cipher suites are important if you want security according to your >needs/requirements and a la carte proposals are important for interop. Well actually I waws thinking pretty much the opposite. Cipher suites are important for interop and a la carte proposals are important if you want security according to your needs/requirements Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-ipsec@lists.tislabs.com Mon Mar 3 09:06:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23H5xY05778; Mon, 3 Mar 2003 09:05:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21331 Mon, 3 Mar 2003 11:22:59 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Sun, 2 Mar 2003 02:11:10 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: IPsec -- new versions of AH and ESP Cc: kseo@bbn.com Content-Type: multipart/alternative; boundary="============_-1165533422==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1165533422==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, We just submitted new versions of the AH and ESP IDs to the IETF secretariat. This email describes the changes that were made and one as yet unresolved issue. A. multicast + how should one demux inbound multicast traffic? + how should sequence numbering/anti-replay be handled B. tunnel vs transport mode -- when should each mode be used? C. mandatory algorithms -- should these be removed from the AH and ESP drafts in a manner analogous to their removal from IKE? D. miscellaneous other changes, e.g.,: AH - correction to table describing header fields - changed text re: use of 51 in Protocol or Next Header field from "will" to "SHALL" ESP - correction to tunnel mode processing in Section 3.4.4.1 AH & ESP - added text to ESP to define byte order within cypher block. This is already stated in 2401, but someone requested that it also be put in ESP. Some edits to the two IDs are not included in this email, e.g., correcting typos, simplifying/clarifying text, updating references, etc. Thank you, Karen **************************************************************************** A. Multicast: Based on discussion with the multicast security working group, we have made the following changes: Authentication Header (AH) ========================== 2.4 Security Parameters Index (SPI) -- paragraph 1, last sentence From: The SPI field is mandatory. To: The SPI field is mandatory and the mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all AH implementations. 2.4 Security Parameters Index (SPI) -- paragraph 2 From: 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.) To: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is used for SA matching. (Only the SPI, and, optionally, the protocol field are employed.) For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. For multicast methods (e.g., SSM [HCO3]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE. 2.5.1 Extended (64-bit) Sequence Number -- paragraph 1, added sentence at end of paragraph Added: (The ESN feature is applicable to multicast as well as unicast SAs.) 3.2 Integrity Algorithms -- paragraph 1 From: The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms..... To: The integrity algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast communication, a variety of cryptographic strategies for providing integrity have been developed and research continues in this area..... 3.3.2 Sequence Number Generation -- paragraph 4, added sentence From: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. To: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) 3.4.2 Security Association Lookup -- paragraph 1 From: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), and the SPI..... To: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.4. For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.4.... 3.4.3 Sequence Number Verification -- paragraph 1 From: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) To: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below. 7. Differences from RFC 2402 -- first bullet From: o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with the destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (AH) in selecting the SPI, then the security protocol is also used in the lookup. (I had the security protocol as (ESP) -- am I correct to assume that was a boo-boo?) 7. Differences from RFC 2402 -- second bullet From: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. To: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. Encapsulating Security Payload (ESP) ==================================== 2.1 Security Parameters Index -- 1 and 2 From: The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Since the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. To: The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Since, for unicast SAs, the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. The SPI field is mandatory and the mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all ESP implementations. 2.1 Security Parameters Index (SPI) -- paragraph 3 From: 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.) To: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is used for SA matching. (Only the SPI, and, optionally, the protocol field are employed.) For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. For multicast methods (e.g., SSM [cite]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE. 2.2.1 Extended (64-bit) Sequence Number -- paragraph 1, added sentence at end of paragraph Added: (The ESN feature is applicable to multicast as well as unicast SAs.) 3.3.3 Sequence Number Generation -- paragraph 4, added sentence From: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. To: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) 3.4.2 Security Association Lookup -- paragraph 1 From: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the SPI alone (unicast) or SPI combined with destination IP address (multicast).... To: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.1..... 3.4.3 Sequence Number Verification -- paragraph 1 From: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) To: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below. 7. Differences from RFC 2402 -- second bullet From: o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with the destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (ESP) in selecting the SPI, then the security protocol is also used in the lookup. 7. Differences from RFC 2402 -- third bullet From: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. To: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. **************************************************************************** B. Tunnel vs Transport mode -- A design team is still discussing how IPsec should deal with tunneling in various contexts. It seems likely that we will change the current processing flow in 2401, and redefine the rules on when to use tunnel mode vs. transport mode, e.g., to better accommodate overlay nets, PPVPN applications, etc. However, to facilitate moving the AH and ESP specs to Last Call, we have: a. changed "upper layer protocol" to "next layer protocol" throughout these 2 specs b. removed the text in these two specs that says WHEN to use these modes and deferred that to the Architecture spec (2401bis). The AH and ESP specs will continue to discuss the transport and tunnel mechanisms and the Architecture spec will describe when to use them. Authentication Header (AH) ========================== 1. Introduction -- paragraph 3 From: AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). To: AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 3.1 Authentication Header Location -- paragraph 1 From (some of this text was moved to Section 3.1.1 -- see below) Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) To: Like ESP, AH may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for a description of when each should be used.) 3.1 Authentication Header Location -- paragraph 2, sentence 1 From: AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data.... To: AH provides authentication for as much of the IP header as possible, as well as for next level protocol data.... 3.1.1 Transport Mode -- paragraph 1, sentences 1 and 2 From: In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol..... To: In transport mode, AH is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the next layer protocol..... 3.1.1 Transport Mode -- paragraph 1, deleted sentence 5 From: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) To: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) 3.1.1 Transport Mode -- added at the end of this section some of the text removed from 3.1 (see above) Note that in transport mode, for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use. 3.1.2 Tunnel Mode From: Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect transit traffic), tunnel mode MUST be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. To: In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers," e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. 3.3 Outbound Packet Processing -- paragraph 1, sentence 1 From: In transport mode, the sender inserts the AH header after the IP header and before an upper layer protocol header, as described above..... To: In transport mode, the sender inserts the AH header after the IP header and before a next layer protocol header, as described above..... 3.3 Outbound Packet Processing -- paragraph 2 Deleted (To be addressed in Architecture document): If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network.) 3.3.3 Integrity Check Value Calculation -- paragraph 1, bullet 3 From: The AH ICV is computed over: o.... o.... o the upper level protocol data, which is assumed to be immutable in transit To: The AH ICV is computed over: o.... o.... o the next level protocol data, which is assumed to be immutable in transit 3.3.4 Fragmentation -- paragraph 2 From: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. To: NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. Encapsulating Security Payload (ESP) ==================================== 1. Introduction -- paragraph 1, sentence 2 From: ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA98b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA98a], hereafter referred to as the Security Architecture document). To: ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA98b], or in a nested fashion, (see "Security Architecture for the Internet Protocol" [KA98a], hereafter referred to as the Security Architecture document). 1. Introduction -- paragraph 2, sentence 1 From: The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). To: The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). 1. Introduction -- paragraph 8 From: The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in tunnel mode between security gateways, and only if sufficient traffic flows between these gateways to conceal the characteristics of specific, individual subscriber traffic flows. To: The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. 2.3 Payload Data -- paragraph 2 From: Note that the beginning of the transport header (transport mode) or the beginning of the encapsulated IP datagram (tunnel mode) MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes. To: Note that the beginning of next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes. 2.4 Padding (for Encryption) -- paragraph 1, 3rd bullet has been modified and changed to be a regular paragraph, not a bullet. From: Three factors require or motivate use of the Padding field. o ..... o ..... o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of TFC. The padding field described here offers limited opportunity for concealing the length of the plaintext and thus a new, separate mechanism is described below for use when TFC is required (see Section 2.7). To: Two factors require or motivate use of the Padding field. o ..... o ..... Padding beyond that required for the algorithm or alignment reasons cited above, could be used to conceal the actual length of the payload, in support of TFC. However, the Padding field described is too limited to be effective for TFC and thus should not be used for that purpose. Instead, the new, separate mechanism described below (see Section 2.7) should be used when TFC is required. 2.6 Next Header -- paragraph 1 From: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or an upper layer header and data. To: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. 2.7 Traffic Flow Confidentiality (TFC) Padding -- paragraph 4 Deleted: In transport mode, this facility generally will not be available, consistent with the earlier admonition that effective TFC service in IPsec generally requires use of tunnel mode between security gateways. 3.1 ESP Header Location From: ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable to host implementations and provides protection for upper layer protocols, but not the IP header. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) To: ESP may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for description of when each should be used.) 3.1.1 Transport Mode Processing -- paragraph 1, sentence 1 and 2 From: In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol..... To: In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol..... 3.1.1 Transport Mode -- paragraph 1, deleted sentence 5 From: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) To: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) 3.1.1 Transport Mode -- added text Added at the end of this section some of the text removed from 3.1 Note that in transport mode, for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use. 3.1.2 Tunnel Mode Processing From: Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway to protect subscriber transit traffic, tunnel mode MUST be used. (Transport mode MAY be used to protect management or similar traffic terminating at a security gateway.) In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header contains the addresses of the IPsec peers. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. To: In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header contains the addresses of the IPsec peers. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. 3.3 Outbound Packet Processing -- paragraph 1, sentence 1 From: In transport mode, the sender encapsulates the upper layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). To: In transport mode, the sender encapsulates the next layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). 3.3 Outbound Packet Processing -- paragraph 1 Deleted last sentence (to be addressed in Architecture document) If more than one IPsec header/extension is required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.2.1 Separate Confidentiality and Integrity Algorithms -- paragraph 1, step 1 From: If separate confidentiality and integrity algorithms are employed, the sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. To: If separate confidentiality and integrity algorithms are employed, the sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original next layer protocol information. 3.3.2.2 Combined Confidentiality and Integrity Algorithms -- paragraph 1, step 1 From: If a combined confidentiality/integrity algorithm is employed, the sender: 1. encapsulates into the ESP Payload Data field: - for transport mode -- just the original upper layer protocol information. To: If a combined confidentiality/integrity algorithm is employed, the sender: 1. encapsulates into the ESP Payload Data field: - for transport mode -- just the original next layer protocol information. 3.3.4 Fragmentation -- paragraph 2 From: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. To: NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. 3.4.4.1 Separate Confidentiality and Integrity Algorithms -- paragraph 1, step 5 From: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field To: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original next layer protocol information in the ESP Payload field **************************************************************************** C. Mandatory Algorithms -- Does the working group want to remove the text that describes the mandatory algorithms and move them to another document? If yes, then the following sections would be removed/edited. Authentication Header (AH) ========================== 3.2 Integrity Algorithms -- paragraph one, sentence 4 .... The mandatory-to-implement integrity algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 5. Conformance Requirements -- paragraph one, sentence 4 .... A compliant AH implementation MUST support the following mandatory-to-implement algorithms: - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] Encapsulating Security Payload (ESP) ==================================== 3.2 Algorithms -- first 2 sentences The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements." Other algorithms MAY be supported.... 5. Conformance Requirements -- paragraph one, sentence 4 .... A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - AES (with 128-bit keys) in CBC mode - HMAC with MD5 [MG98a] - HMAC with SHA-1 [MG98b] - NULL Encryption algorithm (RFC 2410) **************************************************************************** D. Other Changes Authentication Header (AH) ========================== 2. Authentication Header Format -- paragraph 1 From: The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. To: The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header SHALL contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. Figure 1 illustrates the format for AH. 2. Authentication Header Format -- table From: (removed "D" = dummy from Requ'd column for "IP datagram". There is a "dummy" value in ESP, but not in AH.) What What # of Requ'd Integ is bytes [1] Covers Xmtd ------ ------ ------ ------ IP Header variable M [2] plain Next Header 1 M Y plain Payload Len 1 M Y plain RESERVED 2 M Y plain SPI 4 M Y plain Seq# (low order 32-bits) 4 M Y plain ICV variable M Y[3] plain IP datagram [4] variable M or D Y plain Seq# (high order 32-bits) 4 if ESN Y not xmtd ICV Padding variable if need Y not xmtd [1] - M = mandatory; D = dummy To: What What # of Requ'd Integ is bytes [1] Covers Xmtd ------ ------ ------ ------ IP Header variable M [2] plain Next Header 1 M Y plain Payload Len 1 M Y plain RESERVED 2 M Y plain SPI 4 M Y plain Seq# (low order 32-bits) 4 M Y plain ICV variable M Y[3] plain IP datagram [4] variable M Y plain Seq# (high order 32-bits) 4 if ESN Y not xmtd ICV Padding variable if need Y not xmtd [1] - M = mandatory 2. Authentication Header Format -- added the following text at the end of this section. "Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order." 3.3.4 Fragmentation -- paragraph 1, sentence 3 (and added a parenthetical sentence after sentence 3.) From: .....An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver.... To: .....An IPv4 packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. (This does not apply to IPv6, where there is no router-initiated fragmentation.) 3.4.2 Security Association Lookup -- added paragraph at end (Note that SA management traffic, e.g., IKE packets, does not need to be processed based on SPI, i.e., one can demultiplex this traffic separately, e.g., based on Next Protocol and Port fields.) Encapsulating Security Payload (ESP) ==================================== 2. Encapsulating Security Payload Packet Format -- added the following text at the end of this section. "Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order." 3.4.4.1 Separate Confidentiality and Integrity Algorithms, paragraph 1, step 5 -- corrected tunnel mode processing From: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. To: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- outer IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- the entire IP datagram in the ESP Payload field. --============_-1165533422==_ma============ Content-Type: text/html; charset="us-ascii" Folks, We just submitted new versions of the AH and ESP IDs to the IETF secretariat. This email describes the changes that were made and one as yet unresolved issue. A. multicast + how should one demux inbound multicast traffic? + how should sequence numbering/anti-replay be handled B. tunnel vs transport mode -- when should each mode be used? C. mandatory algorithms -- should these be removed from the AH and ESP drafts in a manner analogous to their removal from IKE? D. miscellaneous other changes, e.g.,: AH - correction to table describing header fields - changed text re: use of 51 in Protocol or Next Header field from "will" to "SHALL" ESP - correction to tunnel mode processing in Section 3.4.4.1 AH & ESP - added text to ESP to define byte order within cypher block. This is already stated in 2401, but someone requested that it also be put in ESP. Some edits to the two IDs are not included in this email, e.g., correcting typos, simplifying/clarifying text, updating references, etc. Thank you, Karen **************************************************************************** A. Multicast: Based on discussion with the multicast security working group, we have made the following changes: Authentication Header (AH) ========================== 2.4 Security Parameters Index (SPI) -- paragraph 1, last sentence From: The SPI field is mandatory. To: The SPI field is mandatory and the mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all AH implementations. 2.4 Security Parameters Index (SPI) -- paragraph 2 From: 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.) To: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is used for SA matching. (Only the SPI, and, optionally, the protocol field are employed.) For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. For multicast methods (e.g., SSM [HCO3]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE. 2.5.1 Extended (64-bit) Sequence Number -- paragraph 1, added sentence at end of paragraph Added: (The ESN feature is applicable to multicast as well as unicast SAs.) 3.2 Integrity Algorithms -- paragraph 1 From: The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms..... To: The integrity algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast communication, a variety of cryptographic strategies for providing integrity have been developed and research continues in this area..... 3.3.2 Sequence Number Generation -- paragraph 4, added sentence From: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. To: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) 3.4.2 Security Association Lookup -- paragraph 1 From: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), and the SPI..... To: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.4. For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.4.... 3.4.3 Sequence Number Verification -- paragraph 1 From: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) To: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below. 7. Differences from RFC 2402 -- first bullet From: o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with the destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (AH) in selecting the SPI, then the security protocol is also used in the lookup. (I had the security protocol as (ESP) -- am I correct to assume that was a boo-boo?) 7. Differences from RFC 2402 -- second bullet From: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. To: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. Encapsulating Security Payload (ESP) ==================================== 2.1 Security Parameters Index -- 1 and 2 From: The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Since the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. To: The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Since, for unicast SAs, the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. The SPI field is mandatory and the mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all ESP implementations. 2.1 Security Parameters Index (SPI) -- paragraph 3 From: 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.) To: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is used for SA matching. (Only the SPI, and, optionally, the protocol field are employed.) For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. For multicast methods (e.g., SSM [cite]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE. 2.2.1 Extended (64-bit) Sequence Number -- paragraph 1, added sentence at end of paragraph Added: (The ESN feature is applicable to multicast as well as unicast SAs.) 3.3.3 Sequence Number Generation -- paragraph 4, added sentence From: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. To: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) 3.4.2 Security Association Lookup -- paragraph 1 From: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the SPI alone (unicast) or SPI combined with destination IP address (multicast).... To: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.1..... 3.4.3 Sequence Number Verification -- paragraph 1 From: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) To: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below. 7. Differences from RFC 2402 -- second bullet From: o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with the destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (ESP) in selecting the SPI, then the security protocol is also used in the lookup. 7. Differences from RFC 2402 -- third bullet From: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. To: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. **************************************************************************** B. Tunnel vs Transport mode -- A design team is still discussing how IPsec should deal with tunneling in various contexts. It seems likely that we will change the current processing flow in 2401, and redefine the rules on when to use tunnel mode vs. transport mode, e.g., to better accommodate overlay nets, PPVPN applications, etc. However, to facilitate moving the AH and ESP specs to Last Call, we have: a. changed "upper layer protocol" to "next layer protocol" throughout these 2 specs b. removed the text in these two specs that says WHEN to use these modes and deferred that to the Architecture spec (2401bis). The AH and ESP specs will continue to discuss the transport and tunnel mechanisms and the Architecture spec will describe when to use them. Authentication Header (AH) ========================== 1. Introduction -- paragraph 3 From: AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). To: AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 3.1 Authentication Header Location -- paragraph 1 From (some of this text was moved to Section 3.1.1 -- see below) Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) To: Like ESP, AH may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for a description of when each should be used.) 3.1 Authentication Header Location -- paragraph 2, sentence 1 From: AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data.... To: AH provides authentication for as much of the IP header as possible, as well as for next level protocol data.... 3.1.1 Transport Mode -- paragraph 1, sentences 1 and 2 From: In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol..... To: In transport mode, AH is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the next layer protocol..... 3.1.1 Transport Mode -- paragraph 1, deleted sentence 5 From: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) To: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) 3.1.1 Transport Mode -- added at the end of this section some of the text removed from 3.1 (see above) Note that in transport mode, for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use. 3.1.2 Tunnel Mode From: Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect transit traffic), tunnel mode MUST be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. To: In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers," e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. 3.3 Outbound Packet Processing -- paragraph 1, sentence 1 From: In transport mode, the sender inserts the AH header after the IP header and before an upper layer protocol header, as described above..... To: In transport mode, the sender inserts the AH header after the IP header and before a next layer protocol header, as described above..... 3.3 Outbound Packet Processing -- paragraph 2 Deleted (To be addressed in Architecture document): If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network.) 3.3.3 Integrity Check Value Calculation -- paragraph 1, bullet 3 From: The AH ICV is computed over: o.... o.... o the upper level protocol data, which is assumed to be immutable in transit To: The AH ICV is computed over: o.... o.... o the next level protocol data, which is assumed to be immutable in transit 3.3.4 Fragmentation -- paragraph 2 From: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. To: NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. Encapsulating Security Payload (ESP) ==================================== 1. Introduction -- paragraph 1, sentence 2 From: ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA98b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA98a], hereafter referred to as the Security Architecture document). To: ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA98b], or in a nested fashion, (see "Security Architecture for the Internet Protocol" [KA98a], hereafter referred to as the Security Architecture document). 1. Introduction -- paragraph 2, sentence 1 From: The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). To: The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). 1. Introduction -- paragraph 8 From: The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in tunnel mode between security gateways, and only if sufficient traffic flows between these gateways to conceal the characteristics of specific, individual subscriber traffic flows. To: The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. 2.3 Payload Data -- paragraph 2 From: Note that the beginning of the transport header (transport mode) or the beginning of the encapsulated IP datagram (tunnel mode) MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes. To: Note that the beginning of next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes. 2.4 Padding (for Encryption) -- paragraph 1, 3rd bullet has been modified and changed to be a regular paragraph, not a bullet. From: Three factors require or motivate use of the Padding field. o ..... o ..... o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of TFC. The padding field described here offers limited opportunity for concealing the length of the plaintext and thus a new, separate mechanism is described below for use when TFC is required (see Section 2.7). To: Two factors require or motivate use of the Padding field. o ..... o ..... Padding beyond that required for the algorithm or alignment reasons cited above, could be used to conceal the actual length of the payload, in support of TFC. However, the Padding field described is too limited to be effective for TFC and thus should not be used for that purpose. Instead, the new, separate mechanism described below (see Section 2.7) should be used when TFC is required. 2.6 Next Header -- paragraph 1 From: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or an upper layer header and data. To: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. 2.7 Traffic Flow Confidentiality (TFC) Padding -- paragraph 4 Deleted: In transport mode, this facility generally will not be available, consistent with the earlier admonition that effective TFC service in IPsec generally requires use of tunnel mode between security gateways. 3.1 ESP Header Location From: ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable to host implementations and provides protection for upper layer protocols, but not the IP header. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) To: ESP may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for description of when each should be used.) 3.1.1 Transport Mode Processing -- paragraph 1, sentence 1 and 2 From: In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol..... To: In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol..... 3.1.1 Transport Mode -- paragraph 1, deleted sentence 5 From: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) To: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) 3.1.1 Transport Mode -- added text Added at the end of this section some of the text removed from 3.1 Note that in transport mode, for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use. 3.1.2 Tunnel Mode Processing From: Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway to protect subscriber transit traffic, tunnel mode MUST be used. (Transport mode MAY be used to protect management or similar traffic terminating at a security gateway.) In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header contains the addresses of the IPsec peers. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. To: In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header contains the addresses of the IPsec peers. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. 3.3 Outbound Packet Processing -- paragraph 1, sentence 1 From: In transport mode, the sender encapsulates the upper layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). To: In transport mode, the sender encapsulates the next layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). 3.3 Outbound Packet Processing -- paragraph 1 Deleted last sentence (to be addressed in Architecture document) If more than one IPsec header/extension is required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.2.1 Separate Confidentiality and Integrity Algorithms -- paragraph 1, step 1 From: If separate confidentiality and integrity algorithms are employed, the sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. To: If separate confidentiality and integrity algorithms are employed, the sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original next layer protocol information. 3.3.2.2 Combined Confidentiality and Integrity Algorithms -- paragraph 1, step 1 From: If a combined confidentiality/integrity algorithm is employed, the sender: 1. encapsulates into the ESP Payload Data field: - for transport mode -- just the original upper layer protocol information. To: If a combined confidentiality/integrity algorithm is employed, the sender: 1. encapsulates into the ESP Payload Data field: - for transport mode -- just the original next layer protocol information. 3.3.4 Fragmentation -- paragraph 2 From: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. To: NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. 3.4.4.1 Separate Confidentiality and Integrity Algorithms -- paragraph 1, step 5 From: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field To: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original next layer protocol information in the ESP Payload field **************************************************************************** C. Mandatory Algorithms -- Does the working group want to remove the text that describes the mandatory algorithms and move them to another document? If yes, then the following sections would be removed/edited. Authentication Header (AH) ========================== 3.2 Integrity Algorithms -- paragraph one, sentence 4 .... The mandatory-to-implement integrity algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 5. Conformance Requirements -- paragraph one, sentence 4 .... A compliant AH implementation MUST support the following mandatory-to-implement algorithms: - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] Encapsulating Security Payload (ESP) ==================================== 3.2 Algorithms -- first 2 sentences The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements." Other algorithms MAY be supported.... 5. Conformance Requirements -- paragraph one, sentence 4 .... A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - AES (with 128-bit keys) in CBC mode - HMAC with MD5 [MG98a] - HMAC with SHA-1 [MG98b] - NULL Encryption algorithm (RFC 2410) **************************************************************************** D. Other Changes Authentication Header (AH) ========================== 2. Authentication Header Format -- paragraph 1 From: The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. To: The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header SHALL contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. Figure 1 illustrates the format for AH. 2. Authentication Header Format -- table From: (removed "D" = dummy from Requ'd column for "IP datagram". There is a "dummy" value in ESP, but not in AH.) What What # of Requ'd Integ is bytes [1] Covers Xmtd ------ ------ ------ ------ IP Header variable M [2] plain Next Header 1 M Y plain Payload Len 1 M Y plain RESERVED 2 M Y plain SPI 4 M Y plain Seq# (low order 32-bits) 4 M Y plain ICV variable M Y[3] plain IP datagram [4] variable M or D Y plain Seq# (high order 32-bits) 4 if ESN Y not xmtd ICV Padding variable if need Y not xmtd [1] - M = mandatory; D = dummy To: What What # of Requ'd Integ is bytes [1] Covers Xmtd ------ ------ ------ ------ IP Header variable M [2] plain Next Header 1 M Y plain Payload Len 1 M Y plain RESERVED 2 M Y plain SPI 4 M Y plain Seq# (low order 32-bits) 4 M Y plain ICV variable M Y[3] plain IP datagram [4] variable M Y plain Seq# (high order 32-bits) 4 if ESN Y not xmtd ICV Padding variable if need Y not xmtd [1] - M = mandatory 2. Authentication Header Format -- added the following text at the end of this section. "Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order." 3.3.4 Fragmentation -- paragraph 1, sentence 3 (and added a parenthetical sentence after sentence 3.) From: .....An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver.... To: .....An IPv4 packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. (This does not apply to IPv6, where there is no router-initiated fragmentation.) 3.4.2 Security Association Lookup -- added paragraph at end (Note that SA management traffic, e.g., IKE packets, does not need to be processed based on SPI, i.e., one can demultiplex this traffic separately, e.g., based on Next Protocol and Port fields.) Encapsulating Security Payload (ESP) ==================================== 2. Encapsulating Security Payload Packet Format -- added the following text at the end of this section. "Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order." 3.4.4.1 Separate Confidentiality and Integrity Algorithms, paragraph 1, step 5 -- corrected tunnel mode processing From: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. To: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- outer IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- the entire IP datagram in the ESP Payload field. --============_-1165533422==_ma============-- From owner-ipsec@lists.tislabs.com Mon Mar 3 09:10:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23HAAY05911; Mon, 3 Mar 2003 09:10:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21381 Mon, 3 Mar 2003 11:33:59 -0500 (EST) To: Charlie_Kaufman@notesdev.ibm.com Cc: Francis Dupont , ipsec@lists.tislabs.com, "Jayant Shukla" From: Derek Atkins Subject: Re: Another NAT Traversal question References: Date: 03 Mar 2003 11:37:07 -0500 In-Reply-To: Message-ID: Lines: 49 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com writes: > Whether to support transport mode through a NAT is a fair question. > It will add some complexity to the ESP implementation because > on decapsulation ESP would have to adjust the TCP checksums because > they are based on the IP addresses that the NAT changed but the > NAT can't fix the checksums because they are encrypted. Yes, but it's just an incremental update. For the record, the ESP code to handle this for both TCP and UDP is approximately 60 lines of C, and is based on having a NAT_OA payload during the phase-2 exchange. > But looking at it again here, I don't think this works. If the TCP checksum > is computed based on the addresses the sender of the packet sees, then > packets going from the node with real addresses destined for the node with > NATed addresses will have a TCP checksum computed based on the source > address of the node with the real address and the destination address of > the IPsec gateway. To adjust the checksum, the receiver would have to know > the address of the NAT box, but I believe that as currently specified in > both IKEv2 and NAT Traversal for IKEv1, the NATed node does not know the IP > address of the NAT box. How does this work in deployed systems?? We could > add more fields, but I have an alternate proposal: It works by just completely recomputing the checksum rather than incrementally recomputing the checksum if you don't have a NAT-OA. Sure, it takes more time to do this, but it means you don't need to know the NAT's external IP Address. Besides, when you're using IPsec (especially with authentication), the UDP/TCP checksums are generally irrelevant. > The traffic selectors have to contain the IP addresses of each node as > known to the node itself. What if we said that if you use NATed transport > mode, you have to compute and verify the TCP checksums using the addresses > in the traffic selectors. That way the NAT-OA payload is not needed and the > above problem is solved. Which problem? The problem of not being able to _incrementally_ update the checksum? I'm not convinced it's a major issue, having implemented the logic to do this. > --Charlie -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Mar 3 09:11:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23HBwY05969; Mon, 3 Mar 2003 09:11:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21398 Mon, 3 Mar 2003 11:37:03 -0500 (EST) To: Hugo Krawczyk Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: Date: 03 Mar 2003 11:39:43 -0500 In-Reply-To: Message-ID: Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, thanks for correcting me.. To everyone else: I mistakenly asserting a position of Hugo. Below is his ACTUAL opinion on the topic. -derek Hugo Krawczyk writes: > You may want to send to the list the > clarification below as I sent to you. At least it will document my real > opinion before people start attributing to me something I disagree > with. > > > > Hugo Krawczyk writes: > > > > > On 28 Feb 2003, Derek Atkins wrote: > > > > > > > Perhaps some people's comments jumbled together after reading through > > > > 2000+ messages. I seem to recall that you had an issue with choosing > > > > algorithms a la carte due to the lack of security proof of arbitrary > > > > combinations of various algorithms. > > > > > > This was not (and is not) my opinion. > > > Actually one of the main criteria I use in designing crypto protocols is > > > that their security will not depend on specific functions but rather on > > > general functionalities (or "primitives", as we usally call these in > > > cryptography). Therefore if the protocol uses a prf, a MAC and > > > encryption, then ANY secure implementations of these functions will do. > > > No need to check the specific inter-relations. Those are taken care > > > already in the protocol analysis. In particular this is the case for the > > > IKE's design. > > > > > > Hugo -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Mar 3 09:47:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23HlsX07297; Mon, 3 Mar 2003 09:47:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21602 Mon, 3 Mar 2003 12:15:40 -0500 (EST) From: "Jayant Shukla" To: "'Ari Huttunen'" Cc: "'Francis Dupont'" , Subject: RE: Another NAT Traversal question Date: Mon, 3 Mar 2003 09:16:53 -0800 Message-ID: <031001c2e1a8$b7b78c10$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: <3E634815.3060509@f-secure.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 Ari Huttunen > > > > I don't think you need to do what you have explained. Since you will > > authenticate and decrypt the packet, it guarantees that you don't have > > any flipped bits in the body of the encapsulated data. > > No, this guarantees only that the bits didn't flip while they > were encrypted. If the bits were flipped before they entered > the ESP tunnel, that's another question. > So you are worried about the errors before the packet hits the wire?!!!!!!! Remember we are talking about the transport mode processing, so that packet has not hit the wire yet. What I gather from the RFC 760 is that the checksums were meant to detect errors on the wire. Quote from RFC 760 --- "Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments." --- I laud your effort if you want to use the checksum to detect the errors inside the device. BTW, do you also have a mechanism to detect errors that may happen when the data is handed over by the application to the TCP/IP stack? > Please don't anybody try to reinvent the wheel, unless you > find the existing wheel is not round enough. :) > Not unless someone has turned a wheel into a square peg. Transport mode is supposed to be end-to-end (client to client), and transport mode with NAT traversal is _not_ end-to-end secure. This should be enough reason for the area directors to kill it. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Mon Mar 3 09:59:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23Hx3X07689; Mon, 3 Mar 2003 09:59:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21672 Mon, 3 Mar 2003 12:28:03 -0500 (EST) Date: Mon, 3 Mar 2003 12:01:14 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: suites vs. a la carte and IPcomp in IKEv2-05 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 Sun, 2 Mar 2003, Andrew Krywaniuk wrote: > >Cipher suites are important if you want security according to your > >needs/requirements and a la carte proposals are important for interop. > > Well actually I waws thinking pretty much the opposite. Cipher suites are > important for interop and a la carte proposals are important if you want > security according to your needs/requirements I think the missing word that explains this difference in outlook is "standardized". *In the absence* of *standardized* suites, flexibility is important for successful interop. However, clearly the right way to do interop-with-the-world is to have a standardized suite, or at most a few such suites, so everybody knows what to do to interoperate. The current a la carte world has widespread interop capability mostly because there is wide implicit agreement on one or two suites. The IPsec specifications themselves have far too much unnecessary flexibility and provide far too little guidance about preferred choices. (Back when I was with the FreeS/WAN project, we made a first attempt at remedying this with our "IKE Implementation Issues" informational-RFC draft, but the draft appears to have fallen down the crack caused by my departure.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 3 10:14:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23IEHX08384; Mon, 3 Mar 2003 10:14:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21734 Mon, 3 Mar 2003 12:43:20 -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: Mon, 3 Mar 2003 09:46:32 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: suites vs. a la carte and IPcomp in IKEv2-05 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:57 AM -0500 3/2/03, Andrew Krywaniuk wrote: >Cipher suites are important for interop Exactly. > and a la carte proposals are important if you want security >according to your needs/requirements Note that a la carte is only needed if no suites cover your needs/requirements. If a reasonable set of suites is chosen, fewer than 5% of users would ever actually need a la carte. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 3 10:22:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23IMKX08624; Mon, 3 Mar 2003 10:22:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21763 Mon, 3 Mar 2003 12:47:28 -0500 (EST) Message-ID: <3E639600.3F1639AF@airespace.com> Date: Mon, 03 Mar 2003 09:50:56 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Lebovitz CC: "'ipsec@lists.tislabs.com'" , "'charlie_kaufman@notesdev.ibm.com'" , "Darren Dukes (E-mail)" Subject: Re: CP(CFG_REQUEST) required? References: <541402FFDC56DA499E7E13329ABFEA87E66A72@SARATOGA.netscreen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2003 17:51:06.0208 (UTC) FILETIME=[77031E00:01C2E1AD] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gregory Lebovitz wrote: > So here is the proposed text in sect 2.19: > > "Responder MUST not send a CFG_REPLY withouth having first received a > CP(CFG_REQUEST) from Initiator, because we do not want the IRAS to perform > an unneccesary configuration lookup if the IRAC cannot process the REPLY. In > the case where the IRAS's configuration requires that CP be used for a given > identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS SHOULD > fail the request, and terminate the IKE exchange with the appropriate error > message. Whatever form a CP payload ultimately takes, in the case where security policy *requires* that the IRAS send the request and yet it does not, shouldn't the language read "...IRAS MUST fail the request..." (MUST rather than SHOULD)? Scott From owner-ipsec@lists.tislabs.com Mon Mar 3 10:23:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23IN5X08658; Mon, 3 Mar 2003 10:23:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21837 Mon, 3 Mar 2003 12:54:39 -0500 (EST) Date: Mon, 3 Mar 2003 12:57:45 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: Another NAT Traversal question In-Reply-To: <031001c2e1a8$b7b78c10$5803a8c0@trlhpc1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 3 Mar 2003, Jayant Shukla wrote: > What I gather from the RFC 760 is that the checksums were meant to > detect errors on the wire. Note that RFC 760 is obsoleted by RFC 791. Wire-level CRCs etc. are normally necessary and sufficient for detecting errors on the wire. The TCP/IP checksums are primarily for errors that are not caught by wire-level mechanisms, such as bugs in router firmware. > I laud your effort if you want to use the checksum to detect the errors > inside the device. BTW, do you also have a mechanism to detect errors > that may happen when the data is handed over by the application to the > TCP/IP stack? It has been observed in the past that the TCP and UDP checksums ideally should be generated and checked by the application (presumably by a subroutine library it calls), not by the system, to give the strongest possible end-to-end checking -- that being what those checksums are for. There are practical difficulties with that, but it's a useful model. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 3 10:28:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23ISSX08970; Mon, 3 Mar 2003 10:28:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21884 Mon, 3 Mar 2003 12:55:45 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Scott G. Kelly" , "Gregory Lebovitz" Cc: , Subject: RE: CP(CFG_REQUEST) required? Date: Mon, 3 Mar 2003 12:58:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E639600.3F1639AF@airespace.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Scott G.Kelly > > Gregory Lebovitz wrote: > > > So here is the proposed text in sect 2.19: > > > > "Responder MUST not send a CFG_REPLY withouth having first received a > > CP(CFG_REQUEST) from Initiator, because we do not want the IRAS > to perform > > an unneccesary configuration lookup if the IRAC cannot process > the REPLY. In > > the case where the IRAS's configuration requires that CP be > used for a given > > identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS SHOULD > > fail the request, and terminate the IKE exchange with the > appropriate error > > message. > > Whatever form a CP payload ultimately takes, in the case where security > policy *requires* that the IRAS send the request and yet it does not, > shouldn't the language read "...IRAS MUST fail the request..." (MUST > rather than SHOULD)? I agree. Darren > > Scott From owner-ipsec@lists.tislabs.com Mon Mar 3 10:59:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23IxtX11179; Mon, 3 Mar 2003 10:59:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22010 Mon, 3 Mar 2003 13:25:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15971.40681.967000.840582@gargle.gargle.HOWL> Date: Mon, 3 Mar 2003 13:28:57 -0500 From: Paul Koning To: askrywan@hotmail.com Cc: jshukla@trlokom.com, ipsec@lists.tislabs.com Subject: RE: suites vs. a la carte and IPcomp in IKEv2-05 References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: >> Cipher suites are important if you want security according to your >> needs/requirements and a la carte proposals are important for >> interop. Andrew> Well actually I waws thinking pretty much the Andrew> opposite. Cipher suites are important for interop and a la Andrew> carte proposals are important if you want security according Andrew> to your needs/requirements Maybe, maybe not. I once implemented IPsec for a router; it offered suites at the UI level. It came standard with 3 suites (authentication only; auth + encrypt DES, auth + encrypt 3DES). The only reason it was 3 and not 2 is because of the mistaken insistence in the existing specs that DES is required. There was also an ability to add suites; I don't think this was ever used by customers. We told them "use the auth + 3DES suite" and that was the end of the discussion. So I think a small number of suites, perhaps more than the number of thumbs on your hand but fewer than your fingers, is ample for "security according to your needs/requirements". The standards have WAY too much flexibility to no practical benefit. paul From owner-ipsec@lists.tislabs.com Mon Mar 3 12:04:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23K4fX16612; Mon, 3 Mar 2003 12:04:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22262 Mon, 3 Mar 2003 14:21:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 3 Mar 2003 14:04:39 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: IPsec -- new versions of AH and ESP Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My apologies for the previous line-noise version of this email. It looked fine on my screen but the intervening mail forwarding systems mangled it. Hopefully, this version will be more readable. Folks, We just submitted new versions of the AH and ESP IDs to the IETF secretariat. This email describes the changes that were made and one as yet unresolved issue. A. multicast + how should one demux inbound multicast traffic? + how should sequence numbering/anti-replay be handled B. tunnel vs transport mode -- when should each mode be used? C. mandatory algorithms -- should these be removed from the AH and ESP drafts in a manner analogous to their removal from IKE? D. miscellaneous other changes, e.g.,: AH - correction to table describing header fields - changed text re: use of 51 in Protocol or Next Header field from "will" to "SHALL" ESP - correction to tunnel mode processing in Section 3.4.4.1 AH & ESP - added text to ESP to define byte order within cypher block. This is already stated in 2401, but someone requested that it also be put in ESP. Some edits to the two IDs are not included in this email, e.g., correcting typos, simplifying/clarifying text, updating references, etc. Thank you, Karen **************************************************************************** A. Multicast: Based on discussion with the multicast security working group, we have made the following changes: Authentication Header (AH) ========================== 2.4 Security Parameters Index (SPI) -- paragraph 1, last sentence From: The SPI field is mandatory. To: The SPI field is mandatory and the mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all AH implementations. 2.4 Security Parameters Index (SPI) -- paragraph 2 From: 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.) To: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is used for SA matching. (Only the SPI, and, optionally, the protocol field are employed.) For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. For multicast methods (e.g., SSM [HCO3]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE. 2.5.1 Extended (64-bit) Sequence Number -- paragraph 1, added sentence at end of paragraph Added: (The ESN feature is applicable to multicast as well as unicast SAs.) 3.2 Integrity Algorithms -- paragraph 1 From: The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms..... To: The integrity algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast communication, a variety of cryptographic strategies for providing integrity have been developed and research continues in this area..... 3.3.2 Sequence Number Generation -- paragraph 4, added sentence From: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. To: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) 3.4.2 Security Association Lookup -- paragraph 1 From: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), and the SPI..... To: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.4. For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.4.... 3.4.3 Sequence Number Verification -- paragraph 1 From: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) To: All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below. 7. Differences from RFC 2402 -- first bullet From: o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with the destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (AH) in selecting the SPI, then the security protocol is also used in the lookup. (I had the security protocol as (ESP) -- am I correct to assume that was a boo-boo?) 7. Differences from RFC 2402 -- second bullet From: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. To: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. Encapsulating Security Payload (ESP) ==================================== 2.1 Security Parameters Index -- 1 and 2 From: The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Since the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. To: The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Since, for unicast SAs, the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. The SPI field is mandatory and the mechanism for mapping inbound traffic to unicast SAs described above MUST be supported by all ESP implementations. 2.1 Security Parameters Index (SPI) -- paragraph 3 From: 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.) To: IPsec implementations SHOULD be prepared to support both unicast and multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. Each entry in the Security Association Database (SAD) [KA97a] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI (and, optionally, the protocol field). Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is used for SA matching. (Only the SPI, and, optionally, the protocol field are employed.) For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI (and, optionally the protocol) to determine the appropriate SA. For multicast methods (e.g., SSM [cite]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE. 2.2.1 Extended (64-bit) Sequence Number -- paragraph 1, added sentence at end of paragraph Added: (The ESN feature is applicable to multicast as well as unicast SAs.) 3.3.3 Sequence Number Generation -- paragraph 4, added sentence From: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. To: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) 3.4.2 Security Association Lookup -- paragraph 1 From: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the SPI alone (unicast) or SPI combined with destination IP address (multicast).... To: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. For multicast SAs, the destination address is also employed in the lookup (in addition to the SPI and, optionally the protocol), and the sender address also may be employed, as described in Section 2.1..... 3.4.3 Sequence Number Verification -- paragraph 1 From: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA (irrespective of whether the destination address is unicast, broadcast, or multicast). Thus the anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA.) To: All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below. 7. Differences from RFC 2402 -- second bullet From: o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. To: o SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with the destination address, and optionally the source address, to select an SA. If the receiver (unicast) or the multicast controller (multicast) opted to use the security protocol (ESP) in selecting the SPI, then the security protocol is also used in the lookup. 7. Differences from RFC 2402 -- third bullet From: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. To: o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. **************************************************************************** B. Tunnel vs Transport mode -- A design team is still discussing how IPsec should deal with tunneling in various contexts. It seems likely that we will change the current processing flow in 2401, and redefine the rules on when to use tunnel mode vs. transport mode, e.g., to better accommodate overlay nets, PPVPN applications, etc. However, to facilitate moving the AH and ESP specs to Last Call, we have: a. changed "upper layer protocol" to "next layer protocol" throughout these 2 specs b. removed the text in these two specs that says WHEN to use these modes and deferred that to the Architecture spec (2401bis). The AH and ESP specs will continue to discuss the transport and tunnel mechanisms and the Architecture spec will describe when to use them. Authentication Header (AH) ========================== 1. Introduction -- paragraph 3 From: AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). To: AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP) [KA97b], or in a nested fashion (see "Security Architecture for the Internet Protocol" [KA97a], hereafter referred to as the Security Architecture document). 3.1 Authentication Header Location -- paragraph 1 From (some of this text was moved to Section 3.1.1 -- see below) Like ESP, AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) To: Like ESP, AH may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for a description of when each should be used.) 3.1 Authentication Header Location -- paragraph 2, sentence 1 From: AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data.... To: AH provides authentication for as much of the IP header as possible, as well as for next level protocol data.... 3.1.1 Transport Mode -- paragraph 1, sentences 1 and 2 From: In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the upper layer protocol..... To: In transport mode, AH is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. In the context of IPv4, this calls for placing AH after the IP header (and any options that it contains), but before the next layer protocol..... 3.1.1 Transport Mode -- paragraph 1, deleted sentence 5 From: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) To: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) 3.1.1 Transport Mode -- added at the end of this section some of the text removed from 3.1 (see above) Note that in transport mode, for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use. 3.1.2 Tunnel Mode From: Tunnel mode AH may be employed in either hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document). When AH is implemented in a security gateway (to protect transit traffic), tunnel mode MUST be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. To: In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers," e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. 3.3 Outbound Packet Processing -- paragraph 1, sentence 1 From: In transport mode, the sender inserts the AH header after the IP header and before an upper layer protocol header, as described above..... To: In transport mode, the sender inserts the AH header after the IP header and before a next layer protocol header, as described above..... 3.3 Outbound Packet Processing -- paragraph 2 Deleted (To be addressed in Architecture document): If there is more than one IPsec header/extension required, the order of the application of the security headers MUST be defined by security policy. For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. (While a native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers that it applies itself, it won't be possible for it to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network.) 3.3.3 Integrity Check Value Calculation -- paragraph 1, bullet 3 From: The AH ICV is computed over: o.... o.... o the upper level protocol data, which is assumed to be immutable in transit To: The AH ICV is computed over: o.... o.... o the next level protocol data, which is assumed to be immutable in transit 3.3.4 Fragmentation -- paragraph 2 From: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. To: NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. Encapsulating Security Payload (ESP) ==================================== 1. Introduction -- paragraph 1, sentence 2 From: ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA98b], or in a nested fashion, e.g., through the use of tunnel mode (see "Security Architecture for the Internet Protocol" [KA98a], hereafter referred to as the Security Architecture document). To: ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA98b], or in a nested fashion, (see "Security Architecture for the Internet Protocol" [KA98a], hereafter referred to as the Security Architecture document). 1. Introduction -- paragraph 2, sentence 1 From: The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). To: The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). 1. Introduction -- paragraph 8 From: The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in tunnel mode between security gateways, and only if sufficient traffic flows between these gateways to conceal the characteristics of specific, individual subscriber traffic flows. To: The traffic flow confidentiality (TFC) service generally is effective only if ESP is employed in a fashion that conceals the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways, and only if sufficient traffic flows between IPsec peers (either naturally or as a result of generation of masking traffic) to conceal the characteristics of specific, individual subscriber traffic flows. 2.3 Payload Data -- paragraph 2 From: Note that the beginning of the transport header (transport mode) or the beginning of the encapsulated IP datagram (tunnel mode) MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes. To: Note that the beginning of next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes. 2.4 Padding (for Encryption) -- paragraph 1, 3rd bullet has been modified and changed to be a regular paragraph, not a bullet. From: Three factors require or motivate use of the Padding field. o ..... o ..... o Padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of TFC. The padding field described here offers limited opportunity for concealing the length of the plaintext and thus a new, separate mechanism is described below for use when TFC is required (see Section 2.7). To: Two factors require or motivate use of the Padding field. o ..... o ..... Padding beyond that required for the algorithm or alignment reasons cited above, could be used to conceal the actual length of the payload, in support of TFC. However, the Padding field described is too limited to be effective for TFC and thus should not be used for that purpose. Instead, the new, separate mechanism described below (see Section 2.7) should be used when TFC is required. 2.6 Next Header -- paragraph 1 From: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or an upper layer header and data. To: The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. 2.7 Traffic Flow Confidentiality (TFC) Padding -- paragraph 4 Deleted: In transport mode, this facility generally will not be available, consistent with the earlier admonition that effective TFC service in IPsec generally requires use of tunnel mode between security gateways. 3.1 ESP Header Location From: ESP may be employed in two ways: transport mode or tunnel mode. The former mode is applicable to host implementations and provides protection for upper layer protocols, but not the IP header. (In this mode, note that for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.) To: ESP may be employed in two ways: transport mode or tunnel mode. (See the Security Architecture document for description of when each should be used.) 3.1.1 Transport Mode Processing -- paragraph 1, sentence 1 and 2 From: In transport mode, ESP is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the upper layer protocol..... To: In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol..... 3.1.1 Transport Mode -- paragraph 1, deleted sentence 5 From: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP. For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode.) To: (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) 3.1.1 Transport Mode -- added text Added at the end of this section some of the text removed from 3.1 Note that in transport mode, for "bump-in- the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use. 3.1.2 Tunnel Mode Processing From: Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway to protect subscriber transit traffic, tunnel mode MUST be used. (Transport mode MAY be used to protect management or similar traffic terminating at a security gateway.) In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header contains the addresses of the IPsec peers. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. To: In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header contains the addresses of the IPsec peers. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. 3.3 Outbound Packet Processing -- paragraph 1, sentence 1 From: In transport mode, the sender encapsulates the upper layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). To: In transport mode, the sender encapsulates the next layer protocol information between the ESP header and the ESP trailer fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). 3.3 Outbound Packet Processing -- paragraph 1 Deleted last sentence (to be addressed in Architecture document) If more than one IPsec header/extension is required by security policy, the order of the application of the security headers MUST be defined by security policy. 3.3.2.1 Separate Confidentiality and Integrity Algorithms -- paragraph 1, step 1 From: If separate confidentiality and integrity algorithms are employed, the sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original upper layer protocol information. To: If separate confidentiality and integrity algorithms are employed, the sender: 1. encapsulates (into the ESP Payload field): - for transport mode -- just the original next layer protocol information. 3.3.2.2 Combined Confidentiality and Integrity Algorithms -- paragraph 1, step 1 From: If a combined confidentiality/integrity algorithm is employed, the sender: 1. encapsulates into the ESP Payload Data field: - for transport mode -- just the original upper layer protocol information. To: If a combined confidentiality/integrity algorithm is employed, the sender: 1. encapsulates into the ESP Payload Data field: - for transport mode -- just the original next layer protocol information. 3.3.4 Fragmentation -- paragraph 2 From: NOTE: For transport mode -- As mentioned at the beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. To: NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet. 3.4.4.1 Separate Confidentiality and Integrity Algorithms -- paragraph 1, step 5 From: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original upper layer protocol information in the ESP Payload field To: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original next layer protocol information in the ESP Payload field **************************************************************************** C. Mandatory Algorithms -- Does the working group want to remove the text that describes the mandatory algorithms and move them to another document? If yes, then the following sections would be removed/edited. Authentication Header (AH) ========================== 3.2 Integrity Algorithms -- paragraph one, sentence 4 .... The mandatory-to-implement integrity algorithms are described in Section 5 "Conformance Requirements". Other algorithms MAY be supported. 5. Conformance Requirements -- paragraph one, sentence 4 .... A compliant AH implementation MUST support the following mandatory-to-implement algorithms: - HMAC with MD5 [MG97a] - HMAC with SHA-1 [MG97b] Encapsulating Security Payload (ESP) ==================================== 3.2 Algorithms -- first 2 sentences The mandatory-to-implement algorithms are described in Section 5, "Conformance Requirements." Other algorithms MAY be supported.... 5. Conformance Requirements -- paragraph one, sentence 4 .... A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - AES (with 128-bit keys) in CBC mode - HMAC with MD5 [MG98a] - HMAC with SHA-1 [MG98b] - NULL Encryption algorithm (RFC 2410) **************************************************************************** D. Other Changes Authentication Header (AH) ========================== 2. Authentication Header Format -- paragraph 1 From: The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. To: The protocol header (IPv4, IPv6, or IPv6 Extension) immediately preceding the AH header SHALL contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. Figure 1 illustrates the format for AH. 2. Authentication Header Format -- table From: (removed "D" = dummy from Requ'd column for "IP datagram". There is a "dummy" value in ESP, but not in AH.) What What # of Requ'd Integ is bytes [1] Covers Xmtd ------ ------ ------ ------ IP Header variable M [2] plain Next Header 1 M Y plain Payload Len 1 M Y plain RESERVED 2 M Y plain SPI 4 M Y plain Seq# (low order 32-bits) 4 M Y plain ICV variable M Y[3] plain IP datagram [4] variable M or D Y plain Seq# (high order 32-bits) 4 if ESN Y not xmtd ICV Padding variable if need Y not xmtd [1] - M = mandatory; D = dummy To: What What # of Requ'd Integ is bytes [1] Covers Xmtd ------ ------ ------ ------ IP Header variable M [2] plain Next Header 1 M Y plain Payload Len 1 M Y plain RESERVED 2 M Y plain SPI 4 M Y plain Seq# (low order 32-bits) 4 M Y plain ICV variable M Y[3] plain IP datagram [4] variable M Y plain Seq# (high order 32-bits) 4 if ESN Y not xmtd ICV Padding variable if need Y not xmtd [1] - M = mandatory 2. Authentication Header Format -- added the following text at the end of this section. "Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order." 3.3.4 Fragmentation -- paragraph 1, sentence 3 (and added a parenthetical sentence after sentence 3.) From: .....An IP packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver.... To: .....An IPv4 packet to which AH has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. (This does not apply to IPv6, where there is no router-initiated fragmentation.) 3.4.2 Security Association Lookup -- added paragraph at end (Note that SA management traffic, e.g., IKE packets, does not need to be processed based on SPI, i.e., one can demultiplex this traffic separately, e.g., based on Next Protocol and Port fields.) Encapsulating Security Payload (ESP) ==================================== 2. Encapsulating Security Payload Packet Format -- added the following text at the end of this section. "Note: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order." 3.4.4.1 Separate Confidentiality and Integrity Algorithms, paragraph 1, step 5 -- corrected tunnel mode processing From: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- original IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- tunnel IP header + the entire IP datagram in the ESP Payload field. To: 5. the receiver reconstructs the original IP datagram from: - for transport mode -- outer IP header plus the original next layer protocol information in the ESP Payload field - for tunnel mode -- the entire IP datagram in the ESP Payload field. From owner-ipsec@lists.tislabs.com Mon Mar 3 16:15:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h240FBX25383; Mon, 3 Mar 2003 16:15:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22939 Mon, 3 Mar 2003 18:41:44 -0500 (EST) Date: Tue, 4 Mar 2003 01:44:42 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: comments on ikev2 05 (editorial) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is a list of (mostly) editorial changes to ikev2-05 that I suggest for the next revision of the document. It includes several of the more significant editorial comments on version 04 included in a message from Jan 23rd (message under the subject: "some comments on ikev2 04") and not reflected in 05. Comments are numbered and text from the current draft is marked with >>>. (1) Section 1.2: In section "1.2 The Initial Exchange" the role of keys SKa and SKe is explained. In contrast there is no reference to SK_d which appears without earlier explanation in section 1.3. I suggest to explicitly mention and explain the value SK_d at the end of 1.2. Something like: "In addition to the keys SKe and SKa derived from the DH value for protection of the initial exchange, also a key SKd is derived and used for derivation of further keying material (for CHILD-SAs)." I also suggest to add an explicit pointer in section 1.2 to section 2.15 where the field AUTH is specified. (2) Section 2.2, page 13: the text says: >>> can be very different. There is no ambiguity in the messages, >>> however, because each the (I)nitiator and (R)eply bits in the message I guess that (R)eply should be replaced with (R)esponder. (3) Section 2.6, page 18: typo >>> An IKE implementation SHOULD implement its responder cookie >>> generation is such a way as to not require any saved state to is->in (4) In same page you define Cookie as: >>> Cookie = | Hash(IPi | SPIi | ) I suggested to add Ni inside the Hash. This has no extra cost and improves protection against DoS. Specifically, 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 specification, 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) without need to see (or generate) the original first message from I. >>> where is a randomly generated secret known only to the >>> responder and periodically changed. should be >>> changed whenever is regenerated. The cookie can be >>> recomputed when the IKE_SA_INIT arrives the second time and compared >>> to the cookie in the received message. If it matches, the responder >>> knows that SPIr was generated since the last change to and >>> that IPi must be the same as the source address it saw the first >>> time. Incorporating SPIi into the calculation assures that if >>> multiple IKE-SAs are being set up in parallel they will all get >>> different cookies (assuming the initiator chooses unique SPIi's). >>> >>> If a new value for is chosen while there are connections in >>> the process of being initialized, an IKE_SA_INIT might be returned >>> >>> >>>IKEv2 [Page 18] >>> >>> >>>INTERNET DRAFT February 2003 >>> >>> >>> with other than the current . The responder in >>> that case MAY reject the message by sending another response with a >>> new cookie or it MAY keep the old value of around for a >>> short time and accept cookies computed from either one. The >>> responder SHOULD NOT accept cookies indefinitely after is >>> changed, since that would defeat part of the denial of service >>> protection. (5) Add: "This means that the responder should change the value frequently, especially if under attack" Another option is to include a counter (or timestamp) under Hash and accept only cookies with the counter value in certain window. (6) Section 2.10 Page 22: >>>2.10 Nonces >>> >>> The IKE_SA_INIT messages each contain a nonce. These nonces are used >>> as inputs to cryptographic functions. The CREATE_CHILD_SA request >>> and the CREATE_CHILD_SA response also contain nonces. These nonces >>> are used to add freshness to the key derivation technique used to >>> obtain keys for CHILD-SAs. Nonces used in IKEv2 MUST therefore be >>> randomly chosen and of size at least equal to the key size of the >>> strongest cryptographic algorithm used. This may be confusing. For example, the strongest key may be 2048 bits. The point is not in matching size but strength. Moreover, in no case it makes sense to use nonces longer than 128 bits. Actually 64 bits are usually sufficient (assuming you do not use the same SK_d value in more than 2^30 SA-CHILD's). (7) Section 2.13 Page 24: >>> In the context of the IKE-SA, three cryptographic algorithms are >>> negotiated: an encryption algorithm, a Diffie-Hellman group, and a >>> pseudo-random function (prf). The pseudo-random function is used both >>> for integrity protection of the IKE payloads and for the construction >>> of keying material for all of the cryptographic algorithms used in >>> both the IKE-SA and the CHILD-SAs. In the suites there are two different algorithms negotiated: prf and integrity protection. You should clarify Which one is used for the integrity protection in SK{}. I am not sure what's the intention in the current text. >>> We assume that each cryptographic algorithm accepts a fixed size key, >>> and that any randomly chosen value of that fixed size can serve as an >>> appropriate key. For functions that accept a variable length key, a >>> fixed key size MUST be specified as part of the cryptographic suite >>> negotiated. For prf functions based on HMAC, the fixed key size is >>> the size of the output of the HMAC. (8) change last line to: "the length of the output of the underlying hash function." (That is more precise than the "output of the HMAC" which may actually be different than the length of the hash output.) (9) Section 2.14 page 25: >>> subsequent exchanges. SKEYSEED and its derivatives are computed as >>> follows: >>> >>> SKEYSEED = prf(Ni | Nr, g^ir) What happens if Ni|Nr is longer than the prf key? You should specify that the values concatenated above are Ni and Nr each truncated (if necessary) to half the length of the prf key. (This is particularly relevant to prf's based on block ciphers, e.g. AES-CBC-MAC.) >>> {SK_d, SK_ai, SK_ar, SK_ei, SK_er} >>> = prf+ (SKEYSEED, g^ir | Ni | Nr | SPIi | SPIr ) delete g^ir from this computation (and the text referring to g^ir below) Also note that there is no real need to put Ni|Nr here since they were already used in the derivation of SKEYSEED. That is, you can leave SPIi|SPIr as the only input to prf+. >>> (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er >>> are taken in order from the generated bits of the prf+). g^ir is the >>> shared secret from the ephemeral Diffie-Hellman exchange. g^ir is >>> represented as a string of octets in big endian order padded with >>> zeros if necessary to make it the length of the modulus. Ni and Nr >>> are the nonces, stripped of any headers. >>> >>> The two directions of flow use different keys. The keys used to >>> protect messages from the original initiator are SK_ai and SK_ei. The >>> keys used to protect messages in the other direction are SK_ar and >>> SK_er. Each algorithm takes a fixed number of bits of keying >>> material, which is specified as part of the algorithm. For integrity >>> algorithms based on HMAC, the key size is always equal to the length >>> of the underlying hash function. change last line to: "of the output of the underlying hash function." (10) Section 2.15 >>>2.15 Authentication of the IKE-SA >>> >>> When not using extended authentication (see section 2.16), 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) is the initiator's nonce Ni (just the value, not the >>> payload containing it) and the contents of the responder's ID payload change "the contents of the responder's ID payload" to "the value prf(SK_ar,IDr') where IDr' represents the responder's ID payload (excluding fixed header)." >>> (excluding fixed header). 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) is the responder's nonce Nr >>> and the initiator's ID payload (excluding fixed header). It is >>> Same change as above (11) Then in the same section you specify: >>> In the case of a pre-shared key, the AUTH value is computed as: >>> >>> AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) >>> >>> where the string "Key Pad for IKEv2" is ASCII encoded and not null >>> terminated. The shared secret can be variable length. The pad string >>> is added so that if the shared secret is derived from a password, >>> this exchange will not compromise use of the same password in other >>> protocols. As noted above, deriving the shared secret from a >>> password is not secure. This construction is used because it is >>> anticipated that people will do it anyway. >>> As I noted in a previous message this pad does not give anything. It does not hurt either except for giving a false feeling of security. If I am confused and you have an argument why this pad helps please explain to me. The only way this can help against another protocol it that protocol uses the same prf with the same . And, again, if you still want to add the pad, it should be concatenated to the input not to the keyL that is AUTH = prf(Shared Secret, "Key Pad for IKEv2" | ) (12) In page 28, sec 2.17: >>> For CREATE_CHILD_SA exchanges with PFS the keying material is defined >>> as: >>> >>> KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) >>> delete g^ir from this computation (and the text referring to g^ir below) >>> >>> where g^ir (ph2) is the shared secret from the ephemeral Diffie- >>> Hellman exchange of this CREATE_CHILD_SA exchange (represented as an >>> octet string in big endian order padded with zeros if necessary to >>> make it the length of the modulus), >>> >>> 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 2.13. >>> (13) erase last sentence, seems to be a left over from previous text. (14) Section 2.18 page 29 >>> >>> >>> 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 CREATE_CHILD_SA exchange (represented as an >>> octet string in big endian order padded with zeros if necessary to >>> make it the length of the modulus) and Ni and Nr are the two nonces >>> stripped of any headers. Here g^ir is ok! Also, I'd suggest that since "ph2" stands for "phase 2" a term not used in ikev2 may be you should change ph2 to "(new)". (15) Page 38: Section 3.1 >>> o Message ID (4 octets) - Message identifier used to control >>> retransmission of lost packets and matching of requests and >>> responses. See section 2.2. It is important to say (here and even better in section 1.3) that the Message ID has an essential security role, namely, avoiding replay attacks in CHILD-SA establishment. (16) In sec 5 (security considerations) page 71: >>> >>> themselves. There is nothing in IKE which prohibits using stronger >>> groups nor is there anything which will dilute the strength obtained >>> from stronger groups. In fact, the extensible framework of IKE This is inaccurate. The key derivation (via its prf) and the actual algorithms negotiated for ipsec may dilute this strength if they are weaker than the strength of the DH groups (note that it may make sense to use stronger DH groups than prf or other crypto algorithms if one suspects that cryptanalysis of DH may advance faster than cryptanalysis of these other algorithms, e.g. in the case of EC groups). This is the case if you include g^ir only for deriving SKEYSEED (as I suggest) and also if g^ir is included in the derivation under prf+ as done in version 05. >>> encourages the definition of more groups; use of elliptical curve >>> groups may greatly increase strength using much smaller numbers. >>> >>> It is assumed that the Diffie-Hellman exponents in this exchange are >>> erased from memory after use. In particular, these exponents MUST NOT >>> be derived from long-lived secrets like the seed to a pseudo-random >>> generator that is not erased after use. >>> >>> The security of this protocol is critically dependent on the >>> randomness of the Diffie-Hellman exponents, which should be generated >>> by a strong random or properly seeded pseudo-random source (see >>> RFC1715). While the protocol was designed to be secure even if the >>> Nonces and other values specified as random are not strongly random, (17) I do not know what "not strongly random" means. We assume that Ni,Nr are random and then they should be "stronly pseudo-random", not less than the DH exponents. >>> they should similarly be generated from a strong random source as >>> part of a conservative design. >>> From owner-ipsec@lists.tislabs.com Mon Mar 3 16:15:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h240FBX25382; Mon, 3 Mar 2003 16:15:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22932 Mon, 3 Mar 2003 18:38:44 -0500 (EST) Date: Tue, 4 Mar 2003 01:42:07 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: comments on ikev2 05 (cryptography) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have several remarks on the ikev2 draft version 05. Most of them are just editorial. I will send those in a separate message. Here I point out to two main issues related to the cryptographic design of IKEv2. None of these issues is new but rather reflect "negative progress" relative to what we agreed over the list (the first issue) or what already was in version 04 (the second issue). Fixing these issues involves no added complexity (in some cases it is actually a simplification). Don't be surprised if you feel this message as just a familiar deja vu... First Issue: Macing the identity. =========== The text we agreed upon was (this text appears in my message to the list on Jan 23rd, Charlie's agreed to it in his response message; there were no objections in the list). 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)]. Note: The text between [...] denotes the suggested changes relative to version 04; the terms MIDi,MIDr can be omitted as they are not referred to in other parts of the spec. Instead of this, the text of 05 changes the values MIDr=prf(SK_ar,IDr) and MIDi=prf(SK_ai,IDi) with the contents of payloads IDr and IDi, respectively. I have no idea what motivated this change. I guess that Charlie convinced himself (or someone convinced him) that putting the identities under the signatures achieves the same effect as adding the MAC (or prf) of the identities as we agreed earlier. THIS IS WRONG. The added identities do NOTHING to solve the issues that motivated the addition of the values MIDi and MIDr. Actually, adding the plain identities (as done in 05) inside the signature has no real cryptographic advantage. Recall that the problem in 04 was that the design was susceptible to seemingly "innocent changes" to the protocol that actually render the protocol insecure. One such potential change, illustrated very clearly with the initial design of the SLA protocol, is moving the signature to a message that is not covered by the SK{} transform (in SLA the responder's signature was moved to message 2 which cannot be encrypted and then one cannot apply SK{} to it). This strips the responder's identity from the protection of the outside MAC provided by SK{} and makes the protocol insecure by opening it to authentication attacks ("identity misbinding"). As I pointed out, this problem is easily resolved by including the MAC OF THE SIGNER'S IDENTITY inside the signature. All of this, which may be very counter-intuitive at first glance, is explained in full detail in my sigma paper (to which I referred here repeatedly in relation to this and other ikev2 design issues). Moreover, if you read that paper you will see that the solution in 05, i.e. putting the signer's identity (instead of its MAC) under the signature does nothing to prevent the authentication attack. Indeed, the same attacks that are possible without the identity inside the signature are possible also if you include the identity. The point is in MACing THE IDENTITY as provided by the MIDi/r values in my original proposal. The other vulnerability of the design in 04 was that if one does not transmit the identity of the responder in message 4 (for example, by moving it to message 2), or similarly if one omits the transmission of the initiator's identity from message 3 then (again) the authentication features of the protocol are broken. (Yes, this is explained in the sigma paper too :). It may seem at first glance that incorporating the identity of the signer under the signature solves this problem. This is wrong too. Also in this case the authentication of the protocol is broken (even with the SK{} transform covering the signature). In contrast, the inclusion of the MACed identity solves this problem too by freeing the security of the authentication from the actual positioning of the transmitted identity and from the need to apply SK{} on top of the signature. (The SK{} is still needed for identity hiding and for authenticating the piggybacked CHILD-SA elements, SA2 and TS.) Therefore, PLEASE PLEASE PLEASE, go back to our agreed solution: instead of adding the signer's identity to the signed data, add to it the MAC of this identity. I do not see room for controversy here, but if anyone objects to this please send your rationale to this list (preferably after reading the full rationale for these changes in the sigma paper). Second issue: adding g^ir to the prf+ derivation ============ The key derivation presented in 05 is: SKEYSEED = prf(Ni | Nr, g^ir) {SK_d, SK_ai, SK_ar, SK_ei, SK_er} = prf+ (SKEYSEED, g^ir | Ni | Nr | SPIi | SPIr ) The key derivation in 04 was the same except that g^ir was not included. The "benefit" of including g^ir under prf is that the DH key randomizes each of the iterations of prf under the prf+ definition, thus providing seemingly better (heuristic) security. The drawback is that the inclusion of g^ir eliminates the mathematical support behind the use of a prf. As I explained in the past: since SKEYSEED is derived from g^ir then the (circular) construction prf+(SKEYSEED, g^ir ....) cannot be formally claimed to be secure. This (in contrast to the MAC(ID) issue above) may not have immediate practical consequences since the standard candidates for prf (such as HMAC-SHA1 or AES) do not necessarily break when g^ir is included under prf+. On the other hand, the alleged benefit of including g^ir has no practical relevance at all. Indeed, the supporters of this inclusion in the past have argued that this is necessary to avoid "reducing" the strength of the derived keys to the strength of the prf. This, however, is a misleading argument since the keys derived later via the KEYMAT mechanism are still NO STRONGER than the prf. Indeed, this derivation uses the same prf keyed with SK_d and thus is no stronger than the prf even if we used g^ir as an argument to prf+ when deriving SK_d. Furthermore, we do not need the key derivation to be stronger than the crypto algorithms for which these keys are used (e.g. in ipsec). Thus the best you can do is to choose a prf that matches the strength of these algorithms, and that's what HMAC-SHA1 or AES give you. And for those that 128 or 160 bits of strength are not enough: you can use HMAC-SHA-256 as the prf (but then don't forget to match it with DH exponents of 16000 bits [draft-ietf-ipsec-ciph-aes-cbc-0x.txt]). Bottom line: by including g^ir under prf+ we loose the theoretical soundness without any practical gain. Not a wise tradeoff. Security Considerations ======================= One thing that is clear from the above issues (especially the first) is that the cryptographic design of IKEv2 is not well understood. This was a big problem with IKEv1 too and led to a lot of misunderstandings over the years (and even unfounded "rumours" of insecurity). To some extent, I take personal responsibility for this situation for never documenting this rationale. Now, somewhat too late for IKE but on time for IKEv2 I have written the sigma paper to document this rationale (and a more mathematical paper with Ran with a rigorous analysis of these protocols). This rationale is too involved to be added as part of the ikev2 document, instead I do ask that the security considerations section provides a pointer to the sigma paper (whose coming revision will also include the rationale for the prf+ based key derivation). There could be the option, in principle, of making an ascii (ietf-friendly) version of the paper for publication as an i-d (or informational RFC) but that's probably a lot of work and I am not sure that an ascii version of such a paper will have any advantage to a publicly available pdf or postscript versions (does the ietf allow to publish rfc's in pdf/ps format?). Finally one more comment on the security considerations text establishing that: The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs it is difficult to determine the strength of a key for any of the defined groups. Diffie-Hellman group number two when used with a strong random number generator and an exponent no less than 160 bits is sufficient to use for 3DES. Groups three through five provide greater security. Group I do not agree that 160 bits are sufficient for use with 3DES given that these exponents allow for a full break of the DH exchange in 2^80 operations. I would suggest a minimum of 180 or even 200 bits. Hugo From owner-ipsec@lists.tislabs.com Mon Mar 3 20:37:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h244bpX02099; Mon, 3 Mar 2003 20:37:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23515 Mon, 3 Mar 2003 22:56:06 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Mon, 3 Mar 2003 21:19:36 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/03/2003 10:59:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For people advocating that the working group reconsider the suites vs. a la carte decision, it might help clarify things if you specified whether you advocated a la carte as specified in ikev2-02 or whether you preferred some alternate encoding of offers and the accepted combination (and if so, what encoding). It would also be helpful if you specified how each of the attributes listed below should be negotiated (if different from ikev2-05). There seems to be some confusion over exactly what's negotiated as part of a suite and what's not in ikev2-05. Even advocates of suites might want some different organization. Currently, the following attributes of SAs are negotiated as a suite: ESP vs AH vs IKE SA Diffie-Hellman Group Encryption Algorithm (including mode and key size) Integrity Protection Algorithm (including whether Extended Sequence Numbers are used) PRF Algorithm (for IKE SAs only) There are some other SA attributes that are negotiated independently. Compression algorithms (IPcomp) are proposed by the initiator and selected (or not) by the responder. By not including compression algorithms in the cryptographic suites, we avoid the multiplicative explosion we should get in the likely case that implementations supported multiple suites and multiple compression algorithms. What we lose is the ability to offer Suite 1 with LZS or Suite 2 with DEFLATE but not Suite 1 with DEFLATE or Suite 2 with LZS. So far, no one has made a case for needing that flexibility and several people have pointed out the perils of including compression in the cryptographic suite. Transport Mode (vs. tunnel) is proposed by the initiator and accepted (or not) by the responder. Support for transport mode is optional. There is a presumption that if the initiator proposes transport mode that she would prefer to use it. There is a presumption that if the responder does not support transport mode, that the initiator will accept an SA in tunnel mode with the same cryptographic suite. If that's not true in some implementation, the initiator would have to close the SA without using it. And as with compression, there is no ability to offer Suite 1 with transport Mode or Suite 2 with tunnel mode but not the other combination. Explicit Congestion Notification was negotiated in IKEv1 but a single algorithm (not negotiable) is specified for all SAs negotiated with IKEv2. No one (yet) has argued for the ability to negotiate alternate ECN protocols, much less to make such negotiation tied in with cryptographic suites. I would imagine that should we need such negotiation in the future, it would be negotiated independently of the other SA attributes. UDP Encapsulation for NAT Traversal was negotiated in IKEv1 but is not in IKEv2. UDP Encapsulation is unilaterally selected by the initiator in IKEv2 upon detecting a NAT, and any SA negotiated via an encapsulated IKE SA will also be encapsulated using the same UDP ports. Authentication Algorithm is unilaterally selected by the initiator in IKEv1. In IKEv2, each end chooses its own authentication algorithm (sometimes with hints from the other end as to what is supported). SA Lifetime was negotiated in IKEv1. In IKEv2, each end independently chooses an SA Lifetime and whoever has the shorter one will initiate a key rollover. A case could be made for negotiating use of Extended Sequence Numbers independently from crypto suite in a manner similar to transport vs tunnel mode. I proposed including it in crypto suite because I assumed that the only reason to not use ESNs was for backwards compatibility and that all new cryptographic suites would require them. --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@lists.tislabs.com Mon Mar 3 20:43:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h244hKX02181; Mon, 3 Mar 2003 20:43:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23570 Mon, 3 Mar 2003 23:17:14 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: RE: CP(CFG_REQUEST) required? To: Cc: "Gregory Lebovitz" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "Scott G. Kelly" X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Mon, 3 Mar 2003 22:37:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/03/2003 11:20:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Done. I added the supplied text to section 2.19 and the error code to 3.10.1. --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@lists.tislabs.com Mon Mar 3 20:44:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h244iFX02212; Mon, 3 Mar 2003 20:44:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23571 Mon, 3 Mar 2003 23:17:13 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3E5E831D.9080809@nortelnetworks.com> Subject: Re: KE payload To: Lakshminath Dondeti Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Mon, 3 Mar 2003 22:46:41 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/03/2003 11:20:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem is that with the advent of suites, there is no registry of DH group numbers. There are a number of them published in [ADDGROUP], but IKE is not limited to using only those. A newly defined suite could use its own private DH group, and it would have no identifier other than the suite-id. --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). Lakshminath Dondeti wrote: > I may have missed the discussion on it, but why can't the Suite-ID in > the KE payload be "DH group #"? > > regards, > Lakshminath > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload !C! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Suite-ID ! RESERVED (MBZ) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Key Exchange Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 8: Key Exchange Payload Format > From owner-ipsec@lists.tislabs.com Mon Mar 3 20:50:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h244oDX02320; Mon, 3 Mar 2003 20:50:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23562 Mon, 3 Mar 2003 23:17:08 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Mon, 3 Mar 2003 21:50:06 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/03/2003 11:20:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think in the discussion of this feature, there has been some confusion concerning what it's for and what endpoints MUST, SHOULD, and MAY do to follow the spec. The sole addition to the protocol is that the initiator MAY in Message 3 include the DNS name of the node he's trying to connect to. The responder MUST ignore the value supplied unless he has multiple identities by which he can authenticate, in which case he SHOULD select an identity based on the supplied DNS name. So most implementations of responders will ignore the value and most implementations of initiators will either not supply it or will drop in a DNS name. The motivation for this feature springs from a problem commonly experienced with HTTP over SSL. It is fairly common for "vanity" web sites like www.batmanforever.com (which existed when the movie came out and may still) to be hosted on a machine that hosts a lot of other web sites. In the early days, this was implemented by having a whole range of IP addresses routed to the one server, and that server would decide which content to send you according to the IP address to which the request was directed. This became sufficiently wasteful of scarce IPv4 addresses and HTTP was modified to optionally include the DNS name of the web site in the request so that the vanity web sites sharing a server could also share an IP address. But today, this solution is not available to web sites that use SSL, because the SSL server has to authenticate before it gets the HTTP request. So they continue to require a separate IP address for each virtual server they host. By putting this extra field in Message 3, an implementation could have a single IP address but many DNS names and authenticate as being the node the initiator was trying to talk to. It would be good practice for initiators that are looking up the responder by DNS name to include the name in case the responder is so configured. --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@lists.tislabs.com Mon Mar 3 23:17:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h247HoX10069; Mon, 3 Mar 2003 23:17:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24007 Tue, 4 Mar 2003 01:47:50 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66A78@SARATOGA.netscreen.com> From: Gregory Lebovitz To: ddukes@cisco.com, "Scott G. Kelly" , charlie_kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: RE: CP(CFG_REQUEST) required? Date: Mon, 3 Mar 2003 22:44:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > > From: Scott G.Kelly > > > > Gregory Lebovitz wrote: > > > > > So here is the proposed text in sect 2.19: > > > > > > "Responder MUST not send a CFG_REPLY withouth having > first received a > > > CP(CFG_REQUEST) from Initiator, because we do not want the IRAS > > to perform > > > an unneccesary configuration lookup if the IRAC cannot process > > the REPLY. In > > > the case where the IRAS's configuration requires that CP be > > used for a given > > > identity IDi, but IRAC has failed to send a > CP(CFG_REQUEST), IRAS SHOULD > > > fail the request, and terminate the IKE exchange with the > > appropriate error > > > message. > > > > Whatever form a CP payload ultimately takes, in the case > where security > > policy *requires* that the IRAS send the request and yet it > does not, Scott, did you mean to say "IRAC"? > > shouldn't the language read "...IRAS MUST fail the request..." (MUST > > rather than SHOULD)? > > I agree. What I originally said was that the IRAS local configuration was set for CP. I did not say that the local configuration requires IRAC to send anything. (The difference between the two is biproduct of our chosen protocol design). Anyway, the reason I chose SHOULD instead of MUST is that "configuration" has more to do with customers' implementation and policy desires, and less to do with the operation of the protocol. So I was thinking we ought leave it implementation specific. However, Thinking through it a little further, if IRAS were to send an unsolicited CFG_RESPONSE, how should IRAC respond? According to it's local configuration, right? Well, if IRAC's configuration (on |off) for CP was set ON, then it would have sent a CFG_REQUEST in the first place. If IRAC'c configuration had CP set OFF, then it probably ought (would) not respond to an unsolicited CFG_RESPONSE, right? So, I guess I agree too. The "... IRAS MUST fail the request..." will be cleaner. Charlie, can you make that change to the text I suggested? Gregory. From owner-ipsec@lists.tislabs.com Tue Mar 4 03:30:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24BUtX10718; Tue, 4 Mar 2003 03:30:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA24469 Tue, 4 Mar 2003 05:55:21 -0500 (EST) Message-Id: <200303041054.h24Asqof090044@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Hugo Krawczyk cc: IPsec WG Subject: Re: comments on ikev2 05 (editorial) In-reply-to: Your message of Tue, 04 Mar 2003 01:44:42 +0200. Date: Tue, 04 Mar 2003 11:54:52 +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: (2) Section 2.2, page 13: the text says: >>> can be very different. There is no ambiguity in the messages, >>> however, because each the (I)nitiator and (R)eply bits in the message I guess that (R)eply should be replaced with (R)esponder. => no, the (I)nitiator bit is for the original initiator (it is used to recognize its SPI in SPIi | SPIr), the (R)eply bit is about the current exchange (it is used to know if the message is a request or a reply, this information is needed to interpret the sequence number, aka message ID). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 4 03:50:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24BoKX13595; Tue, 4 Mar 2003 03:50:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA24542 Tue, 4 Mar 2003 06:22:22 -0500 (EST) Message-Id: <200303041122.h24BM0of090178@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 In-reply-to: Your message of Mon, 03 Mar 2003 21:19:36 EST. Date: Tue, 04 Mar 2003 12:22:00 +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: UDP Encapsulation for NAT Traversal was negotiated in IKEv1 but is not in IKEv2. UDP Encapsulation is unilaterally selected by the initiator in IKEv2 upon detecting a NAT, and any SA negotiated via an encapsulated IKE SA will also be encapsulated using the same UDP ports. => the IKEv2 mechanism has to be revised because it is subject to a bidding down attack. Can we open a thread about this? Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 4 05:41:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24DfsX20214; Tue, 4 Mar 2003 05:41:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24884 Tue, 4 Mar 2003 08:14:07 -0500 (EST) Message-Id: <200303041228.HAA14641@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-02.txt Date: Tue, 04 Mar 2003 07:28:33 -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-02.txt Pages : 12 Date : 2003-3-3 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-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-ccm-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-ccm-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-3-3144823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ccm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144823.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Mar 4 05:42:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24DguX20314; Tue, 4 Mar 2003 05:42:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24848 Tue, 4 Mar 2003 08:10:02 -0500 (EST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Mon, 03 Mar 2003 17:48:37 -0800 Subject: Re: The CR payload still From: Brian Korver To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 3/3/03 1:33 AM, "Pekka Riikonen" wrote: > Ted, to your call for people to write the text for their ideas, I shall > reply to my own email with the text for this CERTREQ. :) > > It says, > > Empty (zero length) CA names MUST NOT be generated and SHOULD be > ignorred. > > should be removed and later to say something like this, > > If empty CERTREQ payload is received the sender indicates that it does > not require any specific certificate or certificate chain, but it may > accept any certificate. If so the processor SHOULD send its local > certificate or certificate chain it is going to use in the negotiation. > The sender of this payload will later decide whether it will trust the > certificate (by perhaps prompting first a human operator). > > or something like that... > > Pekka > ___________________________________________________________________________ > Pekka Riikonen | Email: priikone@iki.fi > SSH Communications Security Corp. | http://iki.fi/priikone/ > Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio > PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc Pekka, I understand what you are advocating and I am sympathetic to opportunistic IPsec, but I don't think the zero-length CERTREQ payloads should be permitted in the non-opportunistic case because they do not make sense in any other context. - brian briank@briank.com From owner-ipsec@lists.tislabs.com Tue Mar 4 05:42:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24DgwX20325; Tue, 4 Mar 2003 05:42:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24883 Tue, 4 Mar 2003 08:14:05 -0500 (EST) Message-Id: <200303041228.HAA14623@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-doi-tc-mib-07.txt Date: Tue, 04 Mar 2003 07:28:28 -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 DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-ietf-ipsec-doi-tc-mib-07.txt Pages : 23 Date : 2003-3-3 This document defines textual conventions for the constants used in MIBs for the IPsec protocols. In particular, it documents those numbers whose assignments are managed by the IANA, with new assignments being made over time. The textual conventions provide IPsec-related MIBs with clearer documentation, and insulate them from having to track new assignments by the IANA. The MIB documented by this document will become a separate living document maintained by the IANA, and will be the document of record for these assignments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-07.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-doi-tc-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-3-3144815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doi-tc-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Mar 4 08:35:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24GZBX02794; Tue, 4 Mar 2003 08:35:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26843 Tue, 4 Mar 2003 10:56:30 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 4 Mar 2003 10:59:57 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Clarification re: new versions of AH and ESP Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Sorry for causing confusion. When I said "A design team is still discussing how IPsec should deal with tunneling....", I didn't mean to imply that there was a formal set of people who were doing this separately from the working group. I was just trying to convey that there is a group of people who've been discussing this topic and working together to resolve it. Apologies, Karen From owner-ipsec@lists.tislabs.com Tue Mar 4 09:01:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24H1WX05028; Tue, 4 Mar 2003 09:01:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27102 Tue, 4 Mar 2003 11:27:04 -0500 (EST) Message-ID: <3E64D48A.6D1EB4C9@airespace.com> Date: Tue, 04 Mar 2003 08:30:02 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Lebovitz CC: ddukes@cisco.com, charlie_kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: CP(CFG_REQUEST) required? References: <541402FFDC56DA499E7E13329ABFEA87E66A78@SARATOGA.netscreen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2003 16:30:16.0416 (UTC) FILETIME=[56B95600:01C2E26B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gregory Lebovitz wrote: > > > Whatever form a CP payload ultimately takes, in the case > > where security > > > policy *requires* that the IRAS send the request and yet it > > does not, > > Scott, did you mean to say "IRAC"? Yes. From owner-ipsec@lists.tislabs.com Tue Mar 4 09:52:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24HqlX06489; Tue, 4 Mar 2003 09:52:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27263 Tue, 4 Mar 2003 12:09:37 -0500 (EST) Date: Tue, 4 Mar 2003 12:04:27 -0500 (EST) From: Henry Spencer To: Abraham Shacham cc: IP Security List , ippcp Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 In-Reply-To: <3E630CD7.9090108@trpz.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 3 Mar 2003, Abraham Shacham wrote: > Nowhere in the IKEv2 I-D the issue of using IPComp CPIs from > the pre-assigned transform ID range is mentioned, afaik. The current IKEv2 draft has opted for a more conservative approach than what some of the list discussion indicated was possible. I'm personally a bit disappointed, but I see no grave disadvantages and hence don't feel strongly about it. > Please note that using a CPI from the predefined range has its limitation, > as the implementation notes in RFC-3173 detail. The implementation notes describe difficulties that some implementations might encounter, but which careful design can entirely avoid in the context of IPsec. (IPComp processing in IPsec is always associated with at least one IPsec SA, which eliminates any "which connection?" ambiguity arising from use of predefined CPIs.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 4 10:53:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24IrsX11499; Tue, 4 Mar 2003 10:53:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27454 Tue, 4 Mar 2003 13:01:04 -0500 (EST) Reply-To: From: "Darren Dukes" To: Subject: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: Configuration portion of OPEN ISSUES...] Date: Tue, 4 Mar 2003 13:03:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Reply-By: Sat, 1 Mar 2003 12:45:00 -0500 X-Message-Flag: Follow up Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Gregory Lebovitz [mailto:Gregory@netscreen.com] > Sent: Wednesday, February 26, 2003 12:38 PM > > Or maybe: > * Keep configuration payload, and show (possibly in Appendix or another > document) how it works with various backend config servers, i.e. DHCP, > RADIUS, LDAP. > > BTW, Darren Dukes and I are working right now on some text for this. Stay > tuned. We've spent the last several days in a bit of a mad dash to get this description of Configuration Payloads back ended by DHCPv4 and RADIUS fleshed out and to the list while the configuration discussion still has legs. The descriptions of how CP can work with backend config servers is about 90% complete and will be cleaned up and more completely fleshed out over the next week. Any suggestions, comments, questions, or answers to questions in the draft can be sent directly to the authors or to the ipsec list. Since we missed the cutoff date for new drafts Paul Hoffman/VPNC has temporarily hosted the draft. You can get it here: There are many stray extended ASCII characters that made their way into this revision, they'll be scrubbed out when the next revision is posted. Darren Dukes and Gregory Lebovitz From owner-ipsec@lists.tislabs.com Tue Mar 4 11:00:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24J0BX11793; Tue, 4 Mar 2003 11:00:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27544 Tue, 4 Mar 2003 13:17:23 -0500 (EST) Message-ID: <3E64EE08.2080100@trpz.com> Date: Tue, 04 Mar 2003 10:18:48 -0800 From: Abraham Shacham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Spencer CC: IP Security List , ippcp Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > On Mon, 3 Mar 2003, Abraham Shacham wrote: > >>Nowhere in the IKEv2 I-D the issue of using IPComp CPIs from >>the pre-assigned transform ID range is mentioned, afaik. > > > The current IKEv2 draft has opted for a more conservative approach than > what some of the list discussion indicated was possible. I'm personally a > bit disappointed, but I see no grave disadvantages and hence don't feel > strongly about it. > Reaching a consensus, even a rough one, is always the goal, thanks. > >>Please note that using a CPI from the predefined range has its limitation, >>as the implementation notes in RFC-3173 detail. > > > The implementation notes describe difficulties that some implementations > might encounter, but which careful design can entirely avoid in the > context of IPsec. (IPComp processing in IPsec is always associated with > at least one IPsec SA, which eliminates any "which connection?" ambiguity > arising from use of predefined CPIs.) Using the IPsce SA to define the IPComp session is an approach implementations may elect to use. Establishing a unique IPComp CPI per session -- as most current implementations do, afaik -- is another legitimate approach for sure. Mandating the first over the other is not on the turf of the key exchange protocol, imo, and IKEv2-05 in fact follows that logic. Thanks, avram From owner-ipsec@lists.tislabs.com Tue Mar 4 12:39:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24KdAX19021; Tue, 4 Mar 2003 12:39:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27831 Tue, 4 Mar 2003 14:36:26 -0500 (EST) Message-Id: <200303041937.h24Jb5gm001383@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com cc: Charlie_Kaufman@notesdev.ibm.com Subject: bidding down attach on NAT-T In-reply-to: Your message of "Tue, 04 Mar 2003 12:22:00 +0100." <200303041122.h24BM0of090178@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 04 Mar 2003 14:37:05 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Francis" == Francis Dupont writes: Francis> => the IKEv2 mechanism has to be revised because it is subject Francis> to a bidding down attack. Can we open a thread about this? As I understood things, this issue is not that a third party can force UDP encapsulation of the ESP packets by playing with the UDP headers of the IKE exchange. The issue is that said attacker can force all transmissions from the gateway to the client to go via itself. It does this by pretending to be a NAT, and futzing with the source IP/port#. The gateway will use that address for the packets it sends. We can not, in general have the gateway refuse to change its notion of where to send things because: 1) the attacker could have started futzing at the beginning of the exchange anyway. 2) a NAT may legitimately assign new port numbers/IP addresses to the flow. So, what in the end is the effect of having the IKE/ESP flow sent via some malicious third party? Assuming that the third party does not drop any packets in the flow, we have: a) additional latency. b) traffic analysis. I assume that the crypto is good. If it isn't, and the attacker can break the crypto, all bets are off anyway. The most serious thing that the third party can do is to hijack the flow with the intent to disrupt the flow. This is a denial of service attack. I have a notion on how to deal with this, but before I get into it, I'd like be sure that we are solving the right problem. The problem is: is there a way for the client/gateway to agree that they have a functional UDP pipe between each other before committing to a change. ] 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 iQCVAwUBPmUAXIqHRg3pndX9AQEphwQA1hNr9fabCWeEjQ60V0HQcKY84YEp365d tqI6IHAh5gF65V3YKcNoPdOeSkmgHcfWwm3o/+cuJu9pBuT/3/wPYuyVJXwFmTKG kK0MoqCzFLDdSq4nbyu4Sb2MZqdOV2lhV2Evl9xYiBCo3qgEnMd9Dwez+Vei2Ymj HeJxznmEUSI= =7TL/ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 5 01:33:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h259Xj325881; Wed, 5 Mar 2003 01:33:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29511 Wed, 5 Mar 2003 03:55:45 -0500 (EST) From: "Yoav Nir" To: Subject: RE: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: Configuration portion of OPEN ISSUES...] Date: Wed, 5 Mar 2003 11:08:44 +0200 Message-ID: <007301c2e2f6$d3b630c0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Darren and Gregory >From your draft: "The htype MUST be set to 31 so the DHCP server can distinguish..." Your draft mandates the use of htype 31 when contacting a DHCP server. This would work if all DHCP servers in the world supported the IPsec tunnel option. In fact many don't. I suggest that the MUST in the above sentence be changed to SHOULD, and that an option be added for gateways to act as DHCP relay agents. Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Darren Dukes Sent: Tuesday, March 04, 2003 8:04 PM To: ipsec@lists.tislabs.com Subject: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: Configuration portion of OPEN ISSUES...] > -----Original Message----- > From: Gregory Lebovitz [mailto:Gregory@netscreen.com] > Sent: Wednesday, February 26, 2003 12:38 PM > > Or maybe: > * Keep configuration payload, and show (possibly in Appendix or another > document) how it works with various backend config servers, i.e. DHCP, > RADIUS, LDAP. > > BTW, Darren Dukes and I are working right now on some text for this. Stay > tuned. We've spent the last several days in a bit of a mad dash to get this description of Configuration Payloads back ended by DHCPv4 and RADIUS fleshed out and to the list while the configuration discussion still has legs. The descriptions of how CP can work with backend config servers is about 90% complete and will be cleaned up and more completely fleshed out over the next week. Any suggestions, comments, questions, or answers to questions in the draft can be sent directly to the authors or to the ipsec list. Since we missed the cutoff date for new drafts Paul Hoffman/VPNC has temporarily hosted the draft. You can get it here: There are many stray extended ASCII characters that made their way into this revision, they'll be scrubbed out when the next revision is posted. Darren Dukes and Gregory Lebovitz From owner-ipsec@lists.tislabs.com Wed Mar 5 01:55:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h259t1301645; Wed, 5 Mar 2003 01:55:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29540 Wed, 5 Mar 2003 04:29:46 -0500 (EST) From: "Jesse Alpert" To: Subject: QoS and IKEv2 Date: Wed, 5 Mar 2003 11:36:08 +0200 Message-ID: <001101c2e2fa$a797f3d0$7b2e1dc2@jesse> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, If I understood correctly one of the reasons for supporting "fast" creation of multiple SAs between a single pair of entities (via the CREATE_CHILD_SA exchange) was to allow support for QoS. The theory was that data streams requiring different QoS levels are to be sent over separate tunnels to avoid problems with the replay counter which arise when some packets are tunneled faster than others. The original requirements document (draft-ietf-ipsec-sonofike-rqts-00.txt) stated that: "negotiation of IPsec tunnels needs to accommodate QoS information, predominantly in the set of selectors used to identify the contents of any particular IPsec tunnel" I can not find any reference to this in the current IKEv2 draft (ikev2-05). A peer may need to create multiple tunnels with the exact same traffic selectors but with different QoS levels (ToS). How does one peer inform the other what type of traffic is to pass in each tunnel. Theoretically this information does not have to be negotiated as the initiator can establish a few tunnels and send the data over them any way he wishes, but the responder should at least expect this behavior and be willing to keep multiple identical SAs for an extended period of time (the draft currently states that "An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling"). In addition if the traffic is bi-directional, the responder will have to somehow select a different tunnel for every different QoS level of the packets it is sending. It seems to me it may be easier to explicitly include this (ToS) information in the TS payload. Am I missing something? Jesse From owner-ipsec@lists.tislabs.com Wed Mar 5 06:21:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25EL3323131; Wed, 5 Mar 2003 06:21:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29933 Wed, 5 Mar 2003 08:42:30 -0500 (EST) Message-Id: <200303051131.GAA26242@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-dpd-02.txt Date: Wed, 05 Mar 2003 06:31:09 -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 : A Traffic-Based Method of Detecting Dead IKE Peers Author(s) : G. Huang, S. Beaulieu, D. Rochefort Filename : draft-ietf-ipsec-dpd-02.txt Pages : 10 Date : 2003-3-4 This draft describes a method of detecting a dead IKE peer. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to limit the number of IKE messages sent. DPD, like other keepalive mechanisms, is often necessary to perform IKE peer failover, or to reclaim lost resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dpd-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-dpd-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-dpd-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-3-4174254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dpd-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dpd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174254.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Mar 5 06:23:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25ENm323186; Wed, 5 Mar 2003 06:23:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29936 Wed, 5 Mar 2003 08:42:31 -0500 (EST) Message-Id: <200303051131.GAA26263@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-xcbc-mac-03.txt Date: Wed, 05 Mar 2003 06:31:15 -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 : The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, H. Herbert Filename : draft-ietf-ipsec-ciph-aes-xcbc-mac-03.txt Pages : 11 Date : 2003-3-4 A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for mes- sages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-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-xcbc-mac-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-xcbc-mac-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-3-4174303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-xcbc-mac-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174303.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Mar 5 08:41:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25Gfp327528; Wed, 5 Mar 2003 08:41:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00448 Wed, 5 Mar 2003 10:51:43 -0500 (EST) Message-Id: <200303051554.h25FsIof095517@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec@lists.tislabs.com, Charlie_Kaufman@notesdev.ibm.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of Tue, 04 Mar 2003 14:37:05 EST. <200303041937.h24Jb5gm001383@marajade.sandelman.ottawa.on.ca> Date: Wed, 05 Mar 2003 16:54:18 +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: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Francis" == Francis Dupont writes: Francis> => the IKEv2 mechanism has to be revised because it is subject Francis> to a bidding down attack. Can we open a thread about this? As I understood things, this issue is not that a third party can force UDP encapsulation of the ESP packets by playing with the UDP headers of the IKE exchange. => there are two things, the bidding down attack and the attack using the NAT traversal. Your text is about the second: it is useful but it is not the bidding down attack, i.e., it is just an explaination of the "bidding down". The issue is that said attacker can force all transmissions from the gateway to the client to go via itself. => not itself but someone. It does this by pretending to be a NAT, and futzing with the source IP/port#. The gateway will use that address for the packets it sends. We can not, in general have the gateway refuse to change its notion of where to send things because: 1) the attacker could have started futzing at the beginning of the exchange anyway. 2) a NAT may legitimately assign new port numbers/IP addresses to the flow. So, what in the end is the effect of having the IKE/ESP flow sent via some malicious third party? Assuming that the third party does not drop any packets in the flow, we have: a) additional latency. b) traffic analysis. I assume that the crypto is good. If it isn't, and the attacker can break the crypto, all bets are off anyway. The most serious thing that the third party can do is to hijack the flow with the intent to disrupt the flow. This is a denial of service attack. I have a notion on how to deal with this, but before I get into it, I'd like be sure that we are solving the right problem. => yes, the main issue is the DoS attack. IKE itself is secure but it can be (ab)used to launch attacks. The problem is: is there a way for the client/gateway to agree that they have a functional UDP pipe between each other before committing to a change. => there is none. It seems we agree that the NAT traversal feature is less secure so: - it should be disabled when one knows there cannot be a NAT on the path. - the NAT detection should be safe, i.e., it should not give false positive. This is my "bidding down" argument against the current mechanism (which has many other problems but one is enough). Thanks Francis.Dupont@enst-bretagne.fr PS: the bidding down attack itself is obvious: the attacker has only to change a NAT-DETECTION-*-IP in the IKE_SA_INIT reply. PPS: the reference about attacks using IKE (not against IKE) is draft-dupont-transient-pseudonat-01.txt From owner-ipsec@lists.tislabs.com Wed Mar 5 09:37:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25Hb8302274; Wed, 5 Mar 2003 09:37:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00603 Wed, 5 Mar 2003 11:52:35 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: The CR payload still To: Brian Korver Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 4 Mar 2003 22:28:02 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/05/2003 11:56:03 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think I'm hearing variations on the following proposal: An empty CERTREQ payload is requesting any certificate or certificate chain the other side has without giving any hints as to what certificates are preferred. A missing CERTREQ payload is requesting that the other side not bother sending any certificates. When would an IKE implementation want to express the second request? I had assumed that if CERTREQ was missing that the other side should send whatever certificate it has, so an empty CERTREQ would just be a less efficient encoding of the same request. I get the impression from this discussion that IKEv1 had the two versions of the request as above. Were they both used? If someone has a use for requesting no certificates, I think this is a fine way to encode it. But I'm reluctant to add a feature unless someone thinks they need 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@lists.tislabs.com Wed Mar 5 09:37:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25Hb9302286; Wed, 5 Mar 2003 09:37:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00605 Wed, 5 Mar 2003 11:52:38 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 To: IP Security List , ippcp X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 4 Mar 2003 22:46:33 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/05/2003 11:56:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > On Mon, 3 Mar 2003, Abraham Shacham wrote: > > Nowhere in the IKEv2 I-D the issue of using IPComp CPIs from > > the pre-assigned transform ID range is mentioned, afaik. > > The current IKEv2 draft has opted for a more conservative approach than > what some of the list discussion indicated was possible. I'm personally a > bit disappointed, but I see no grave disadvantages and hence don't feel > strongly about it. Let me make sure I understand what you're saying. At one point, I had proposed allowing multiple IPcomp CPIs to be valid within a single ESP SA. That way, a sender could try compressing a packet in multiple ways and send the one that came out the shortest. But no one seemed to get excited about this capability and several people warned about adding options without a documented need, so I never added it to the spec. Is that what you're talking about? I'm even more reluctant to add functionality now, but would note that it would not be difficult to add it (optionally) to some future revision of the protocol. --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@lists.tislabs.com Wed Mar 5 09:38:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25HcS302516; Wed, 5 Mar 2003 09:38:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00604 Wed, 5 Mar 2003 11:52:37 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200303041937.h24Jb5gm001383@marajade.sandelman.ottawa.on.ca> Subject: Re: bidding down attach on NAT-T To: Michael Richardson Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 4 Mar 2003 23:12:56 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/05/2003 11:56:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > The issue is that said attacker can force all transmissions from the > gateway to the client to go via itself. It does this by pretending to > be a NAT, and futzing with the source IP/port#. The gateway will use that > address for the packets it sends. I would claim that an attacker can only do this if it is on the path between the two IPsec endpoints. The attacker would have to prevent delivery of the packet with the original IP address/port # and send a packet with the same innards but a different source IP/port#. At this point, I would claim the attacker *is* a NAT, since that's exactly what NATs do. > So, what in the end is the effect of having the IKE/ESP flow sent via > some malicious third party? Assuming that the third party does not drop > any packets in the flow, we have: > a) additional latency. > b) traffic analysis. But any party on the path between the two IPsec endpoints can do this anyway - with or without invoking NAT-T. That's not to say that these threats aren't serious. Just that there is nothing we could possibly do within IKE or ESP to improve the situation. What am I missing? --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@lists.tislabs.com Wed Mar 5 10:04:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25I4o305471; Wed, 5 Mar 2003 10:04:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00684 Wed, 5 Mar 2003 12:19:57 -0500 (EST) Message-Id: <200303051722.h25HMI4f014682@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of "Tue, 04 Mar 2003 23:12:56 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Mar 2003 12:22:18 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: >> The issue is that said attacker can force all transmissions from the >> gateway to the client to go via itself. It does this by pretending to >> be a NAT, and futzing with the source IP/port#. The gateway will use >> that address for the packets it sends. Charlie> I would claim that an attacker can only do this if it is on the Charlie> path between the two IPsec endpoints. The attacker would have to Charlie> prevent delivery of the packet with the original IP address/port Well, they do not need to be in the reverse path. It enough to be in the forward path. (client->gateway) The replay protection means that it isn't enough to replay the packet, unless one can do it faster than the original packet. So, I agree that the attacker pretty much has to be inline. >> So, what in the end is the effect of having the IKE/ESP flow sent via >> some malicious third party? Assuming that the third party does not >> drop any packets in the flow, we have: a) additional latency. b) >> traffic analysis. Charlie> But any party on the path between the two IPsec endpoints can do Charlie> this anyway - with or without invoking NAT-T. I agree. I'm wasn't explicit in saying that these aren't unique attacks to NAT-T. Charlie> That's not to say that these threats aren't serious. Just that Charlie> there is nothing we could possibly do within IKE or ESP to Charlie> improve the situation. The thing that we could do, is require some kind of three way handshake to change the UDP port #/IP address. That could be a rekey. This assures that the flow doesn't get aimed at some innocent bystandard until the real client speaks again. The sequence would go something like this: gateway receives new UDP port #/IP #1 sends notify to old UDP port #/IP, indicating that it thinks it should change #2 sends notify to new UDP port #/IP, indicating that it thinks it is time to rekey A client receiving #1 can reply, saying "no thank you" if it doesn't want to rekey yet. A client receiving #2 can reply with a rekey. A client receiving both could cancel the rekey with some token from #1. This might all fit into Dead Peer Detection. Note that an observer can easily figure out which is IKE traffic and which is ESP traffic. The truly paranoid may want to have the gateway send the IKE traffic inside the ESP tunnel. This seems very fragile 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 iQCVAwUBPmYyR4qHRg3pndX9AQE2OwP/a6wpIgkeXPPBktRkgbqzjI7ftC4QQLhH OOgp5urjM/br3B+UhtNqfW6/Z968xUi8s3GqEjSctT1nBt0DbBCGdg4F5leF0d/G GvZ1FxDG7zdUvC42Rcb1BVA29PS5rneWFMHGQTx2b9Vq82DPFfjScagdOLcDeFmt eMmIGiegWQI= =eZWE -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 5 10:55:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25ItB307295; Wed, 5 Mar 2003 10:55:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00957 Wed, 5 Mar 2003 13:12:41 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C9B8@corpmx14.us.dg.com> To: jalpert@CheckPoint.com, ipsec@lists.tislabs.com Subject: RE: QoS and IKEv2 Date: Wed, 5 Mar 2003 13:13:08 -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 > It seems to me it may be easier to explicitly include this (ToS) > information in the TS payload. Actually, it should be PHB information. For more discussion of QoS and tunnels, see RFC 2983. RFC 3308 contains a worked solution to this sort of problem for L2TP. 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: Jesse Alpert [mailto:jalpert@CheckPoint.com] > Sent: Wednesday, March 05, 2003 4:36 AM > To: ipsec@lists.tislabs.com > Subject: QoS and IKEv2 > > > Hi, > > If I understood correctly one of the reasons for supporting "fast" creation > of multiple SAs between a single pair of entities (via the CREATE_CHILD_SA > exchange) was to allow support for QoS. The theory was that data streams > requiring different QoS levels are to be sent over separate tunnels to avoid > problems with the replay counter which arise when some packets are tunneled > faster than others. > > The original requirements document > (draft-ietf-ipsec-sonofike-rqts-00.txt) > stated that: > "negotiation of IPsec tunnels needs to accommodate QoS > information, predominantly in the set of selectors used to identify > the contents of any particular IPsec tunnel" > > I can not find any reference to this in the current IKEv2 draft (ikev2-05). > A peer may need to create multiple tunnels with the exact same traffic > selectors but with different QoS levels (ToS). How does one peer inform the > other what type of traffic is to pass in each tunnel. Theoretically this > information does not have to be negotiated as the initiator can establish a > few tunnels and send the data over them any way he wishes, but the responder > should at least expect this behavior and be willing to keep multiple > identical SAs for an extended period of time (the draft currently states > that "An endpoint SHOULD wait a random amount of time before closing a > redundant SA to prevent cycling"). In addition if the traffic is > bi-directional, the responder will have to somehow select a different tunnel > for every different QoS level of the packets it is sending. It seems to me > it may be easier to explicitly include this (ToS) information in the TS > payload. > > Am I missing something? > > Jesse > From owner-ipsec@lists.tislabs.com Wed Mar 5 11:34:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25JYM309459; Wed, 5 Mar 2003 11:34:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01048 Wed, 5 Mar 2003 13:52:01 -0500 (EST) Message-Id: <200303051854.h25IsAp9022652@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: The CR payload still In-reply-to: Your message of "Tue, 04 Mar 2003 22:28:02 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Mar 2003 13:54:09 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Charlie" == Charlie Kaufman writes: Charlie> An empty CERTREQ payload is requesting any certificate or Charlie> certificate chain the other side has without giving any hints as Charlie> to what certificates are preferred. Charlie> A missing CERTREQ payload is requesting that the other side not Charlie> bother sending any certificates. Charlie> When would an IKE implementation want to express the second Charlie> request? I had assumed that if CERTREQ was missing that the 1) when it isn't using certificates 2) when it already has, preconfigured the right things Charlie> If someone has a use for requesting no certificates, I think Charlie> this is a fine way to encode it. But I'm reluctant to add a Charlie> feature unless someone thinks they need it. Charlie, you seem to have fallen into the trap of making IKEv2 depend way too heavily upon PKIX. There is significant deployment of RSA keys that does not use that stuff. ] 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@lists.tislabs.com Wed Mar 5 11:45:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25Jjl310682; Wed, 5 Mar 2003 11:45:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01162 Wed, 5 Mar 2003 14:08:08 -0500 (EST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Wed, 05 Mar 2003 11:07:04 -0800 Subject: Re: The CR payload still From: Brian Korver To: CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 3/4/03 7:28 PM, "Charlie_Kaufman@notesdev.ibm.com" wrote: > I think I'm hearing variations on the following proposal: > > An empty CERTREQ payload is requesting any certificate or certificate chain > the other side has without giving any hints as to what certificates are > preferred. > > A missing CERTREQ payload is requesting that the other side not bother > sending any certificates. > > When would an IKE implementation want to express the second request? I had > assumed that if CERTREQ was missing that the other side should send > whatever certificate it has, so an empty CERTREQ would just be a less > efficient encoding of the same request. I get the impression from this > discussion that IKEv1 had the two versions of the request as above. Were > they both used? > > If someone has a use for requesting no certificates, I think this is a fine > way to encode it. But I'm reluctant to add a feature unless someone thinks > they need 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). Carlie, As you point out, no CERTREQ means "don't bother to send any CERTs", but the question remains as to what an empty CERTREQ means. ISAKMP states that an empty CERTREQ means "send any CERTs you want, I don't care". Except for the case of opportunistic IPsec, I don't see the point of telling your peer "I don't care". Therefore, I agree that an empty CERTREQ should be prohibited in IKEv2, especially because it creates an interoperability rat hole. - brian briank@briank.com From owner-ipsec@lists.tislabs.com Wed Mar 5 12:16:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25KGH312155; Wed, 5 Mar 2003 12:16:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01225 Wed, 5 Mar 2003 14:33:34 -0500 (EST) Date: Wed, 5 Mar 2003 14:28:57 -0500 (EST) From: Henry Spencer To: Charlie_Kaufman@notesdev.ibm.com cc: IP Security List , ippcp Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 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 Tue, 4 Mar 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > The current IKEv2 draft has opted for a more conservative approach than > > what some of the list discussion indicated was possible... > > Let me make sure I understand what you're saying. At one point, I had > proposed allowing multiple IPcomp CPIs to be valid within a single ESP SA... > Is that what you're talking about? Not quite. The list discussion suggested that there is really no need to *negotiate* IPComp at all. It suffices for each end to advertise, as a side issue during negotiations, which *decompression* algorithms it is willing to use (perhaps in an order of preference, in which case there should be a way to signify "no compression" somewhere in the preference order -- it isn't necessarily always last choice). There is no need for the two ends to *agree* on anything. IPComp decompression must be stateless, so the only thing the receiver needs to know is which algorithm it must apply, and that can be explicitly indicated using preassigned CPIs, so the receiver needs no agreed-on state to decompress packets. In IPComp it is always the sender's choice as to whether a particular packet gets compressed at all, so the receiver can't use such state to do any useful error checking either. So the receiver has no particular need to even remember whether a particular IPsec connection is using IPComp. At the output end of the AH/ESP receiver, you check whether the emerging packet's Protocol is IPComp and the algorithm is one you implement, and if so, you decompress it. The sender probably wants to maintain state to decide whether to compress the next packet, and if so, how, but the only thing he actually needs to know about the receiver is what algorithms the receiver knows. If there is more than one choice acceptable to both, the sender needs to make a decision somehow. The receiver has no need to know what that decision is. There is no need for the decision to be the same in both directions, or for it to be the same for every packet. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Mar 5 12:57:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25KvT316029; Wed, 5 Mar 2003 12:57:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01358 Wed, 5 Mar 2003 15:17:04 -0500 (EST) Message-ID: <1068316.1046890550575.JavaMail.nobody@beaker.psp.pas.earthlink.net> Date: Wed, 5 Mar 2003 10:57:14 -0800 (PST) From: Jayant Shukla Reply-To: jshukla@trlokom.com To: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: Re: bidding down attach on NAT-T Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Web Access Mail version 3.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -------Original Message------- From: Michael Richardson Charlie> there is nothing we could possibly do within IKE or ESP to Charlie> improve the situation. The thing that we could do, is require some kind of three way handshake to change the UDP port #/IP address. That could be a rekey. We had this discussion a few days ago. This is the exact method we are using in our NAT traversal. However, this method too is not perfect as an attacker can falsly convince you to keep doing three-way handshakes. Not a big problem, and can be solved by rate limiting the three-way handshakes, but an annoynace none the less. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Wed Mar 5 14:13:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25MDb318741; Wed, 5 Mar 2003 14:13:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01545 Wed, 5 Mar 2003 16:31:57 -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, 5 Mar 2003 13:31:48 -0800 To: Brian Korver , From: Paul Hoffman / VPNC Subject: Re: The CR payload still Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:07 AM -0800 3/5/03, Brian Korver wrote: >Except for the case of opportunistic IPsec, I don't see the point >of telling your peer "I don't care". There are other meanings than "I don't care". We need to be able to say "send me a cert of type other than 4", namely types 11, 12, and 13. Currently, we can't specify that. > Therefore, I agree that an empty >CERTREQ should be prohibited in IKEv2, especially because it creates an >interoperability rat hole. It won't do that if we scope it correctly. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 5 15:05:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25N5t320199; Wed, 5 Mar 2003 15:05:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01712 Wed, 5 Mar 2003 17:24:31 -0500 (EST) Message-ID: <3E6677C0.2020501@trpz.com> Date: Wed, 05 Mar 2003 14:18:40 -0800 From: Abraham Shacham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Spencer CC: Charlie_Kaufman@notesdev.ibm.com, IP Security List , ippcp Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > On Tue, 4 Mar 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > >>>The current IKEv2 draft has opted for a more conservative approach than >>>what some of the list discussion indicated was possible... >> >>Let me make sure I understand what you're saying. At one point, I had >>proposed allowing multiple IPcomp CPIs to be valid within a single ESP SA... >>Is that what you're talking about? > > > Not quite. The list discussion suggested A more accurate way to describe the discussion could be: *some* on the list suggested, and others disagreed. After all, your words yesterday regarding the current content of IKEv2-05: ...but I see no grave disadvantages and hence don't feel strongly about it. > that there is really no need to > *negotiate* IPComp at all. It suffices for each end to advertise, as a > side issue during negotiations, which *decompression* algorithms it is > willing to use (perhaps in an order of preference, in which case there > should be a way to signify "no compression" somewhere in the preference > order -- it isn't necessarily always last choice). There is no need for > the two ends to *agree* on anything. > The current IKE and IKEv2-05 provide IPComp implementations with a mechanism to negotiate, in other words to agree on, IPComp specific parameters. That capability is in use in actual implementations. As for using only the CPIs from the pre-defined range, both the current IKE and IKEv2-05 provide implementations with a mechanism to use the well-known CPIs or to negotiate a CPI. The fact is, most implementations use a CPI from the negotiated range. Mandating using the the first over the other is not on the turf of the key exchange protocol, imo, and IKEv2-05 should continue following that logic. Regards, acvram From owner-ipsec@lists.tislabs.com Wed Mar 5 16:09:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2609K322962; Wed, 5 Mar 2003 16:09:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01847 Wed, 5 Mar 2003 18:30:14 -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, 5 Mar 2003 15:33:52 -0800 To: Brian Korver From: Paul Hoffman / VPNC Subject: Re: The CR payload still Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:39 PM -0800 3/5/03, Brian Korver wrote: >On 3/5/03 1:31 PM, "Paul Hoffman / VPNC" wrote: >> There are other meanings than "I don't care". We need to be able to >> say "send me a cert of type other than 4", namely types 11, 12, and >> 13. Currently, we can't specify that. >> >> It won't do that if we scope it correctly. >> >> --Paul Hoffman, Director >> --VPN Consortium > >Paul, > >An empty CERTREQ still contains a cert type field. The issue >being discussed is the semantics of a missing CA field (in >other words the CA's DN), not a missing cert type. The document says: While intended to allow for future expansion, the only form of certificate request currently defined is X.509 signing certificate (4). That's a pretty clear statement that other types are not covered by the CERTREQ. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 6 01:20:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h269KO327328; Thu, 6 Mar 2003 01:20:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02841 Thu, 6 Mar 2003 03:25:47 -0500 (EST) Message-ID: <00c501c2e3ba$872e83f0$640572d4@trustworks.com> From: "Valery Smyslov" To: Subject: Auth Method Date: Thu, 6 Mar 2003 11:29:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greeting, IKEv2-05 specifies only 2 values for Auth Method field in Authentication Payload: Digital Signature (1) and Shared Key Message Integrity Code (2). How could receiver unambiguously determine what digital signature algorithm was used: RSA, DSA or something else? By examining Authentication Payload length? - not very reliable method. Via the other entity's certificate? - but Certificate Payload is optional, and the entity may have several certificates of different type. In message http://www.vpnc.org/ietf-ipsec/mail-archive/msg02440.html Charlie Kaufman wrote: Unless someone objects, I'll add a specifier of the authentication data type, of which we currently have 3: RSA signature, DSA signature, and shared key HMAC. So, the original intention was to make Auth Type more specific than we have now, indicating what particular digital signature algorithm was used. I'm curious what was the rationale to change that intention. Another issue - how each side can advertise auth methods she supports. In the same message there was some discussion on this topic and suggestion to use CertRequest Payload for that purpose. Unfortunately, it hasn't been done. Why? Are there strong objections against it? Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Thu Mar 6 01:20:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h269KW327363; Thu, 6 Mar 2003 01:20:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02865 Thu, 6 Mar 2003 03:38:48 -0500 (EST) Message-ID: <00ce01c2e3bc$5efb27b0$640572d4@trustworks.com> From: "Valery Smyslov" To: "Brian Korver" , , "Paul Hoffman / VPNC" Cc: References: Subject: Re: The CR payload still Date: Thu, 6 Mar 2003 11:42:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > At 11:07 AM -0800 3/5/03, Brian Korver wrote: > >Except for the case of opportunistic IPsec, I don't see the point > >of telling your peer "I don't care". > > There are other meanings than "I don't care". We need to be able to > say "send me a cert of type other than 4", namely types 11, 12, and > 13. Currently, we can't specify that. Nor can we currently request a CRL(s). It's a pity, because either it forces the other side to always send (probably huge) CRL(s), or leaves us without critical revocation information in case we cannot get it from other sources. > > Therefore, I agree that an empty > >CERTREQ should be prohibited in IKEv2, especially because it creates an > >interoperability rat hole. > > It won't do that if we scope it correctly. > > --Paul Hoffman, Director > --VPN Consortium Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Thu Mar 6 02:36:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26Aap307217; Thu, 6 Mar 2003 02:36:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03230 Thu, 6 Mar 2003 04:42:56 -0500 (EST) Date: Thu, 6 Mar 2003 10:46:21 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Brian Korver Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: The CR payload still In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : > 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). : : Carlie, : : As you point out, no CERTREQ means "don't bother to send any CERTs", : but the question remains as to what an empty CERTREQ means. ISAKMP : states that an empty CERTREQ means "send any CERTs you want, I don't : care". : : Except for the case of opportunistic IPsec, I don't see the point : of telling your peer "I don't care". Therefore, I agree that an empty : CERTREQ should be prohibited in IKEv2, especially because it creates an : interoperability rat hole. : I can respect that but I don't understand what is the interoperability problem. If it is stated explicitly there are no problems. The current one is bigger problem since pki-profile provides a loophole for this (allowing empty CR's) and that will cause confusion unless that too is fixed to include MUST NOT explicitly. There is also other than "opportunistic crypto" cases. You have to remember that someone may not want to trust some CA just because it wants to talk to you (it don't want to trust everybody). Some implementation may want to always use only self-signed certs and there are no CAs in this case. By not allowing "give me ANY cert you are using now" disallows the use of self-signed certs in IKEv2, or rather you MAY receive it during IKE, or may not. Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SSH Communications Security Corp. | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Thu Mar 6 02:48:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26AmS307953; Thu, 6 Mar 2003 02:48:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03284 Thu, 6 Mar 2003 04:56:56 -0500 (EST) Date: Thu, 6 Mar 2003 11:00:06 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Paul Hoffman / VPNC Cc: Brian Korver , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: The CR payload still In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : At 11:07 AM -0800 3/5/03, Brian Korver wrote: : >Except for the case of opportunistic IPsec, I don't see the point : >of telling your peer "I don't care". : : There are other meanings than "I don't care". We need to be able to : say "send me a cert of type other than 4", namely types 11, 12, and : 13. Currently, we can't specify that. : If the IKEv2 document doesn't want to specify other usage for CERTREQ then surely it is possible to write additional specifications for those other types. In fact, for an empty CERTREQ case whould there be any harm in saying: If empty CERTREQ payload is received the sender indicates that it does not require any specific certificate or certificate chain, but it may accept any certificate. The Cert Encoding field indicates the type of certificate encoding sender is expecting. If so the processor SHOULD send its local certificate or certificate chain of correct type it is going to use in the negotiation. The sender of this payload will later decide whether it will trust the certificate (by perhaps prompting first a human operator). By including multiple CERTREQs in exchange would allow request of multiple different kind of certs and public keys. Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SSH Communications Security Corp. | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Thu Mar 6 04:10:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26CAh314122; Thu, 6 Mar 2003 04:10:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03588 Thu, 6 Mar 2003 06:10:41 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Yoav Nir" , Subject: RE: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: Configuration portion of OPEN ISSUES...] Date: Wed, 5 Mar 2003 13:44:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <007301c2e2f6$d3b630c0$292e1dc2@YnirNew> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk MUST to SHOULD - Done "Act as a relay agent", does this mean 1 - an RFC3456 relay (snooping yiaddr, inject packets into ipsec flows) 2 - a relay that provides is used by the DHCP clients on the IRAS which I mention in the draft as a todo item? I'm guessing #2, which I'm writing the text for now. Thanks. Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Yoav Nir > Sent: Wednesday, March 05, 2003 4:09 AM > To: ipsec@lists.tislabs.com > Subject: RE: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: > Configuration portion of OPEN ISSUES...] > > > Hi Darren and Gregory > > From your draft: > > "The htype MUST be set to 31 so the DHCP server can distinguish..." > > Your draft mandates the use of htype 31 when contacting a DHCP > server. This > would work if all DHCP servers in the world supported the IPsec tunnel > option. In fact many don't. I suggest that the MUST in the > above sentence > be changed to SHOULD, and that an option be added for gateways to act as > DHCP relay agents. > > Yoav > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Darren Dukes > Sent: Tuesday, March 04, 2003 8:04 PM > To: ipsec@lists.tislabs.com > Subject: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: > Configuration portion of OPEN ISSUES...] > > > > -----Original Message----- > > From: Gregory Lebovitz [mailto:Gregory@netscreen.com] > > Sent: Wednesday, February 26, 2003 12:38 PM > > > > > Or maybe: > > * Keep configuration payload, and show (possibly in Appendix or another > > document) how it works with various backend config servers, i.e. DHCP, > > RADIUS, LDAP. > > > > BTW, Darren Dukes and I are working right now on some text for > this. Stay > > tuned. > > We've spent the last several days in a bit of a mad dash to get this > description of Configuration Payloads back ended by DHCPv4 and RADIUS > fleshed out and to the list while the configuration discussion still has > legs. The descriptions of how CP can work with backend config servers is > about 90% complete and will be cleaned up and more completely fleshed out > over the next week. Any suggestions, comments, questions, or answers to > questions in the draft can be sent directly to the authors or to the ipsec > list. > > Since we missed the cutoff date for new drafts Paul Hoffman/VPNC has > temporarily hosted the draft. You can get it here: > > > There are many stray extended ASCII characters that made their > way into this > revision, they'll be scrubbed out when the next revision is posted. > > Darren Dukes and Gregory Lebovitz > > From owner-ipsec@lists.tislabs.com Thu Mar 6 05:16:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26DG9319189; Thu, 6 Mar 2003 05:16:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03845 Thu, 6 Mar 2003 07:26:54 -0500 (EST) Message-Id: <200303052347.h25NlaHI008736@marajade.sandelman.ottawa.on.ca> To: jshukla@trlokom.com cc: ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of "Wed, 05 Mar 2003 10:57:14 PST." <1068316.1046890550575.JavaMail.nobody@beaker.psp.pas.earthlink.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Mar 2003 18:47:35 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jayant" == Jayant Shukla writes: mcr> The thing that we could do, is require some kind of three way mcr> handshake to change the UDP port #/IP address. That could be a mcr> rekey. Jayant> We had this discussion a few days ago. This is the exact method Jayant> we are using in our NAT traversal. However, this method too is Jayant> not perfect as an attacker can falsly convince you to keep doing Jayant> three-way handshakes. Not a big problem, and can be solved by As I said in another message, if you include this as part of the dead-peer detection, then it should work fine. The trick is not doing both at the same time. I haven't looked at all at the DPD stuff, so I don't know. The other thing is making sure that the client can somehow become aware that something may be trying to spoof it. ] 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 iQCVAwUBPmaMkoqHRg3pndX9AQGQSwQA66vFrvsO6TYrl7/dr3xvMBoYhgRiLrqH XQpP3YO875mXywvBKfIbamUIF8US0YfJnE4dk/vOjKbfbcPzLYNF5GIvj33wYdnM AWnacjCqUJFVlCpLEZtynDjSX3ifVBQuz2znkAr09J+BEyeLPWTImrjOOnI4lS8D HWoQ9gQDBnA= =X5xW -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Mar 6 05:28:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26DSd319764; Thu, 6 Mar 2003 05:28:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03922 Thu, 6 Mar 2003 07:47:03 -0500 (EST) Message-ID: <002601c2e3df$041a7490$cb06b684@isl.mei.co.jp> From: "Atsuhiro Tsuji" To: Subject: SPI in Delete Payload of IKE / IKEv2 Date: Thu, 6 Mar 2003 21:50:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, all, I'd like to discuss about SPI value in the Delete Payload of IKE / IKEv2. It is the first time to send a question to the mailing list, so if my behavior/expression is not appropriate, please kindly point it out to me. As you know, there is a field which contains SPIs in Delete Payload of IKE / IKEv2. But I cannot find the direction of the SA. So, I'm confused I have to delete the INBOUND SA or OUTBOUND SA, especially for IPsec-SA. Is there any rule for this? I wonder we had better add a new field which indicates the direction. If you've already discussed this issue, please tell me the pointer for them. I'm looking forward to your joining this discussion. Thank you in advance. ----- Atsuhiro Tsuji [tsuji.atsuhiro@jp.panasonic.com] From owner-ipsec@lists.tislabs.com Thu Mar 6 05:36:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26Dag319980; Thu, 6 Mar 2003 05:36:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03910 Thu, 6 Mar 2003 07:46:03 -0500 (EST) Message-Id: <200303061127.GAA02952@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-rfc2402bis-02.txt Date: Thu, 06 Mar 2003 06:27:35 -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 : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-02.txt Pages : 32 Date : 2003-3-5 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98c]. Section 7 provides a brief review of the differences between this document and RFC 2402. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-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-rfc2402bis-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-rfc2402bis-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-3-5140821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140821.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Mar 6 05:37:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26Dba320000; Thu, 6 Mar 2003 05:37:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03941 Thu, 6 Mar 2003 07:50:07 -0500 (EST) Message-ID: <3E673960.D2E2BC10@creeksidenet.com> Date: Thu, 06 Mar 2003 07:04:48 -0500 From: jeff pickering X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Valery Smyslov CC: ipsec@lists.tislabs.com Subject: Re: Auth Method References: <00c501c2e3ba$872e83f0$640572d4@trustworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The public key type is encoded in the key itself. So even if you use signatures without certs, you still have the information. Jeff Valery Smyslov wrote: > Greeting, > > IKEv2-05 specifies only 2 values for Auth Method field in > Authentication Payload: Digital Signature (1) and Shared Key > Message Integrity Code (2). How could receiver unambiguously > determine what digital signature algorithm was used: RSA, DSA or > something else? By examining Authentication Payload length? - not > very reliable method. Via the other entity's certificate? - but > Certificate Payload is optional, and the entity may have several > certificates of different type. > > In message http://www.vpnc.org/ietf-ipsec/mail-archive/msg02440.html > Charlie Kaufman wrote: > > Unless someone objects, I'll add a specifier of the > authentication data type, of which we currently have 3: RSA > signature, > DSA signature, and shared key HMAC. > > So, the original intention was to make Auth Type more specific than we > have now, indicating what particular digital signature algorithm was used. > I'm curious what was the rationale to change that intention. > > Another issue - how each side can advertise auth methods she supports. > In the same message there was some discussion on this topic and > suggestion to use CertRequest Payload for that purpose. Unfortunately, > it hasn't been done. Why? Are there strong objections against it? > > Regards, > Valery Smyslov. From owner-ipsec@lists.tislabs.com Thu Mar 6 05:41:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26DfU320099; Thu, 6 Mar 2003 05:41:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03909 Thu, 6 Mar 2003 07:46:00 -0500 (EST) Message-Id: <200303061127.GAA02994@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-esp-v3-04.txt Date: Thu, 06 Mar 2003 06:27: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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-04.txt Pages : 42 Date : 2003-3-5 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-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-esp-v3-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-esp-v3-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-3-5140835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140835.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Mar 6 06:01:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26E1c320520; Thu, 6 Mar 2003 06:01:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04038 Thu, 6 Mar 2003 08:17:52 -0500 (EST) From: "Jesse Alpert" To: , Subject: RE: QoS and IKEv2 Date: Thu, 6 Mar 2003 14:39:16 +0200 Message-ID: <000f01c2e3dd$6753d4e0$7b2e1dc2@jesse> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C9B8@corpmx14.us.dg.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Thanks for your response, > Actually, it should be PHB information. For more discussion of QoS > and tunnels, see RFC 2983. RFC 3308 contains a worked solution to > this sort of problem for L2TP. RFC 2983 specifies: "If reordering-based differentiation is desired within such tunnels, multiple parallel tunnels between the same endpoints should be used." I was merely saying that the IKEv2 draft does not seem to support this, since there is no way to indicate to the responder what the tunnels are going to be used for (see my original message below). Indeed the responder is advised to "wait a random amount of time before closing a redundant SA" [ikev2-05] - which would seem to prevent creation of multiple IPsec tunnels differing only by PHB information. Again, it seems to me it might be easier to explicitly include this (PHB) information in the TS payload. This requires modifications to the IKEv2 draft. Thanks again, Jesse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Black_David@emc.com Sent: Wednesday, March 05, 2003 8:13 PM To: jalpert@CheckPoint.com; ipsec@lists.tislabs.com Subject: RE: QoS and IKEv2 > It seems to me it may be easier to explicitly include this (ToS) > information in the TS payload. Actually, it should be PHB information. For more discussion of QoS and tunnels, see RFC 2983. RFC 3308 contains a worked solution to this sort of problem for L2TP. 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: Jesse Alpert [mailto:jalpert@CheckPoint.com] > Sent: Wednesday, March 05, 2003 4:36 AM > To: ipsec@lists.tislabs.com > Subject: QoS and IKEv2 > > > Hi, > > If I understood correctly one of the reasons for supporting "fast" creation > of multiple SAs between a single pair of entities (via the CREATE_CHILD_SA > exchange) was to allow support for QoS. The theory was that data streams > requiring different QoS levels are to be sent over separate tunnels to avoid > problems with the replay counter which arise when some packets are tunneled > faster than others. > > The original requirements document > (draft-ietf-ipsec-sonofike-rqts-00.txt) > stated that: > "negotiation of IPsec tunnels needs to accommodate QoS > information, predominantly in the set of selectors used to identify > the contents of any particular IPsec tunnel" > > I can not find any reference to this in the current IKEv2 draft (ikev2-05). > A peer may need to create multiple tunnels with the exact same traffic > selectors but with different QoS levels (ToS). How does one peer inform the > other what type of traffic is to pass in each tunnel. Theoretically this > information does not have to be negotiated as the initiator can establish a > few tunnels and send the data over them any way he wishes, but the responder > should at least expect this behavior and be willing to keep multiple > identical SAs for an extended period of time (the draft currently states > that "An endpoint SHOULD wait a random amount of time before closing a > redundant SA to prevent cycling"). In addition if the traffic is > bi-directional, the responder will have to somehow select a different tunnel > for every different QoS level of the packets it is sending. It seems to me > it may be easier to explicitly include this (ToS) information in the TS > payload. > > Am I missing something? > > Jesse > From owner-ipsec@lists.tislabs.com Thu Mar 6 07:16:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26FGq325541; Thu, 6 Mar 2003 07:16:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04275 Thu, 6 Mar 2003 09:19:34 -0500 (EST) From: "Yoav Nir" To: "'Atsuhiro Tsuji'" , Subject: RE: SPI in Delete Payload of IKE / IKEv2 Date: Thu, 6 Mar 2003 15:55:42 +0200 Message-ID: <001b01c2e3e8$146a16d0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <002601c2e3df$041a7490$cb06b684@isl.mei.co.jp> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, You send a Delete-SA to stop the peer from using that SA. The IPsec SA is outbound for the peer, but inbound for you. If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B sends packets with SPI 49. If A wants this traffic to stop, he sends B a Delete payload with the SPI field 49. To stop transmissions on SPI 17, A needs not send out anything. It is enough that he stops using it. It might have been nice to also be able to tell peer B that no more traffic will come with SPI 17, so that peer B has an easier time dropping fake packets, but this is not in the spec. Hope this helps. Yoav Nir -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Atsuhiro Tsuji Sent: Thursday, March 06, 2003 2:51 PM To: ipsec@lists.tislabs.com Subject: SPI in Delete Payload of IKE / IKEv2 Hi, all, I'd like to discuss about SPI value in the Delete Payload of IKE / IKEv2. It is the first time to send a question to the mailing list, so if my behavior/expression is not appropriate, please kindly point it out to me. As you know, there is a field which contains SPIs in Delete Payload of IKE / IKEv2. But I cannot find the direction of the SA. So, I'm confused I have to delete the INBOUND SA or OUTBOUND SA, especially for IPsec-SA. Is there any rule for this? I wonder we had better add a new field which indicates the direction. If you've already discussed this issue, please tell me the pointer for them. I'm looking forward to your joining this discussion. Thank you in advance. ----- Atsuhiro Tsuji [tsuji.atsuhiro@jp.panasonic.com] From owner-ipsec@lists.tislabs.com Thu Mar 6 07:36:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26Fad326074; Thu, 6 Mar 2003 07:36:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04392 Thu, 6 Mar 2003 09:56:51 -0500 (EST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Wed, 05 Mar 2003 14:39:18 -0800 Subject: Re: The CR payload still From: Brian Korver To: Paul Hoffman / VPNC CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 3/5/03 1:31 PM, "Paul Hoffman / VPNC" wrote: > There are other meanings than "I don't care". We need to be able to > say "send me a cert of type other than 4", namely types 11, 12, and > 13. Currently, we can't specify that. > > It won't do that if we scope it correctly. > > --Paul Hoffman, Director > --VPN Consortium Paul, An empty CERTREQ still contains a cert type field. The issue being discussed is the semantics of a missing CA field (in other words the CA's DN), not a missing cert type. - brian briank@briank.com From owner-ipsec@lists.tislabs.com Thu Mar 6 08:23:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26GNw301133; Thu, 6 Mar 2003 08:23:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04551 Thu, 6 Mar 2003 10:42:24 -0500 (EST) Message-Id: <200303061545.h26Fjiof099791@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of Tue, 04 Mar 2003 23:12:56 EST. Date: Thu, 06 Mar 2003 16:45:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > The issue is that said attacker can force all transmissions from the > gateway to the client to go via itself. It does this by pretending to > be a NAT, and futzing with the source IP/port#. The gateway will use that > address for the packets it sends. I would claim that an attacker can only do this if it is on the path between the two IPsec endpoints. The attacker would have to prevent delivery of the packet with the original IP address/port # and send a packet with the same innards but a different source IP/port#. At this point, I would claim the attacker *is* a NAT, since that's exactly what NATs do. => I agree: this is why I called the attacker in this context a pseudo-NAT. > So, what in the end is the effect of having the IKE/ESP flow sent via > some malicious third party? Assuming that the third party does not drop > any packets in the flow, we have: > a) additional latency. > b) traffic analysis. But any party on the path between the two IPsec endpoints can do this anyway - with or without invoking NAT-T. That's not to say that these threats aren't serious. Just that there is nothing we could possibly do within IKE or ESP to improve the situation. What am I missing? => the attacker can divert a lot of ESP traffic when it modifies only a very small number of IKE messages. It can, for instance, quit the path between the two IKE peers as soon as its job is done (this is why I called it a transient pseudo-NAT). Thanks Francis.Dupont@enst-bretagne.fr PS: for this part of my "bidding down" argument, we need only to agree that NAT traversal is less secure than no NAT traversal. Especially we don't need to find defense against the "transient pseudo-NAT" attack other than to protect the peer addresses (easy and efficient but not compatible with NAT traversal). From owner-ipsec@lists.tislabs.com Thu Mar 6 08:36:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26GaN302092; Thu, 6 Mar 2003 08:36:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04632 Thu, 6 Mar 2003 10:54:29 -0500 (EST) Message-Id: <200303061558.h26Fw6of099857@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of Wed, 05 Mar 2003 12:22:18 EST. <200303051722.h25HMI4f014682@marajade.sandelman.ottawa.on.ca> Date: Thu, 06 Mar 2003 16:58:06 +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: Well, they do not need to be in the reverse path. It enough to be in the forward path. (client->gateway) => IMHO this is only true for the bidding down attack itself because for the transient pseudo-NAT attack the initiator/client won't receive the reply so will retransmit the request. The replay protection means that it isn't enough to replay the packet, unless one can do it faster than the original packet. So, I agree that the attacker pretty much has to be inline. => agreed I'm wasn't explicit in saying that these aren't unique attacks to NAT-T. => in fact the only useful thing in favor of my bidding down argument is that NAT-T is less secure. The thing that we could do, is require some kind of three way handshake to change the UDP port #/IP address. That could be a rekey. => it won't be enough: you just increase the number of messages the pseudo-NAT attacker has to patch. This assures that the flow doesn't get aimed at some innocent bystandard until the real client speaks again. The sequence would go something like this: gateway receives new UDP port #/IP #1 sends notify to old UDP port #/IP, indicating that it thinks it should change #2 sends notify to new UDP port #/IP, indicating that it thinks it is time to rekey A client receiving #1 can reply, saying "no thank you" if it doesn't want to rekey yet. A client receiving #2 can reply with a rekey. A client receiving both could cancel the rekey with some token from #1. This might all fit into Dead Peer Detection. Note that an observer can easily figure out which is IKE traffic and which is ESP traffic. The truly paranoid may want to have the gateway send the IKE traffic inside the ESP tunnel. This seems very fragile to me. => we (me and Tero) already discussed about this kind of three way handshakes... in fact they are more useful for mobility/multihoming (they provide more than the trust in the other peer to own its address). About NAT-T, it seems the best defense is to support an implicit address change, i.e., the peer address is updated in all SAs as soon as a packet (ESP or IKE) is received from a new address. The transient pseudo-NAT attack still works but its effect is transient, i.e., the first unmodified packet from the peer will put again the right address. And this is more efficient for the NAT-T itself. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Mar 6 12:03:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26K3X311122; Thu, 6 Mar 2003 12:03:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05054 Thu, 6 Mar 2003 14:16:10 -0500 (EST) Message-Id: <200303061917.h26JH1ma000279@fatty.lounge.org> To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 In-Reply-To: Your message of "Mon, 03 Mar 2003 21:19:36 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <265.1046977239.1@tibernian.com> Date: Thu, 06 Mar 2003 11:17:01 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, When we started the IKEv2 effort we wanted to use the lessons learned from deployment of IKEv1 to decide what to change and how to change it. One of the things that almost never happened in a non-lab, non-bakeoff environment was negotiation of SAs. No one ever really took advantage of the complex ANDing and ORing of arbitrary proposals. So we did away with it. I'll return to this in a second but... To answer your question, yes I prefer the a la carte method specified in ikev2-02 more than I prefer the suites _and_ a la carte method specified in ikev2-05. We should either have suites period or a la carte period. Having both strikes me as redoing the mistakes from IKEv1 (in an attempt to get "consensus" I tried to satisfy everyone's demands and ended up with an overly complex beast that we all have grown to hate). You mention that a Diffie-Hellman group is part of the attributes of SAs negotiated as a suite. Well, not really, as I said in my original post on this subject. They're not part of the IPsec suites which makes the supporting a Diffie-Hellman exchange in the CREATE_CHILD exchange difficult. Do you guess the group by the length of the KE payload? That doesn't seem right and if that's the way to do it then why have the Diffie-Hellman group as part of the IKE suite? So properly supporting Diffie-Hellman groups in IPsec suites requires a doubling of the IPsec suites. That is an argument against suites. Now back to negotiation. You say we lose the ability to offer different compression algorithms with different suites. But our deployment experience would show that such a capability is not necessary because it wouldn't be used. We just have to allow the each side to say what algorithm they are willing to do and what CPI they want to do it under (for the reasons Avram mentioned). Such a la carte "negotiation" is currently supported in IKEv2-05 but that's because IKEv2-05 mandates BOTH suites and a la carte. IKEv2-02 has a whole bunch of vanity algorithms (triple IDEA, IDEA, RC5, TIGER, etc) that we can do away with. But the method of specifying what you wanted to do was much simpler and it avoids the suite explosion we're already seeing. IKEv2-02 also had the complex ANDing and ORing that I think we should get rid of. Why not just have a single SA payload that contains TLVs for each of the necessary attributes? Multiple occurances of an attribute mean "I'll do either" (as it was in IKEv2-02 even though I doubt that would be used much if ever). initiator: "ESP: 3DES, HMAC-SHA, Group 5, LZS, CPI=x" responder: "ESP: 3DES, HMAC-SHA, Group 5". There, IPcomp was just un-negotiated. And they agreed on everything else. Whether we have suites or a la carte our deployment experience shows that 99% of the time the initiator will just offer a single suite or an a la carte offer of one algorithm each. There won't be any "negotiation". It's just agreement or it's a mis-configuration. Dan. On Mon, 03 Mar 2003 21:19:36 EST you wrote > > For people advocating that the working group reconsider the suites vs. a la > carte decision, it might help clarify things if you specified whether you > advocated a la carte as specified in ikev2-02 or whether you preferred some > alternate encoding of offers and the accepted combination (and if so, what > encoding). It would also be helpful if you specified how each of the > attributes listed below should be negotiated (if different from ikev2-05). > > There seems to be some confusion over exactly what's negotiated as part of > a suite and what's not in ikev2-05. Even advocates of suites might want > some different organization. Currently, the following attributes of SAs are > negotiated as a suite: > > ESP vs AH vs IKE SA > Diffie-Hellman Group > Encryption Algorithm (including mode and key size) > Integrity Protection Algorithm (including whether Extended Sequence Numbers > are used) > PRF Algorithm (for IKE SAs only) > > There are some other SA attributes that are negotiated independently. > > Compression algorithms (IPcomp) are proposed by the initiator and selected > (or not) by the responder. By not including compression algorithms in the > cryptographic suites, we avoid the multiplicative explosion we should get > in the likely case that implementations supported multiple suites and > multiple compression algorithms. What we lose is the ability to offer Suite > 1 with LZS or Suite 2 with DEFLATE but not Suite 1 with DEFLATE or Suite 2 > with LZS. So far, no one has made a case for needing that flexibility and > several people have pointed out the perils of including compression in the > cryptographic suite. > > Transport Mode (vs. tunnel) is proposed by the initiator and accepted (or > not) by the responder. Support for transport mode is optional. There is a > presumption that if the initiator proposes transport mode that she would > prefer to use it. There is a presumption that if the responder does not > support transport mode, that the initiator will accept an SA in tunnel mode > with the same cryptographic suite. If that's not true in some > implementation, the initiator would have to close the SA without using it. > And as with compression, there is no ability to offer Suite 1 with > transport Mode or Suite 2 with tunnel mode but not the other combination. > > Explicit Congestion Notification was negotiated in IKEv1 but a single > algorithm (not negotiable) is specified for all SAs negotiated with IKEv2. > No one (yet) has argued for the ability to negotiate alternate ECN > protocols, much less to make such negotiation tied in with cryptographic > suites. I would imagine that should we need such negotiation in the future, > it would be negotiated independently of the other SA attributes. > > UDP Encapsulation for NAT Traversal was negotiated in IKEv1 but is not in > IKEv2. UDP Encapsulation is unilaterally selected by the initiator in IKEv2 > upon detecting a NAT, and any SA negotiated via an encapsulated IKE SA will > also be encapsulated using the same UDP ports. > > Authentication Algorithm is unilaterally selected by the initiator in > IKEv1. In IKEv2, each end chooses its own authentication algorithm > (sometimes with hints from the other end as to what is supported). > > SA Lifetime was negotiated in IKEv1. In IKEv2, each end independently > chooses an SA Lifetime and whoever has the shorter one will initiate a key > rollover. > > A case could be made for negotiating use of Extended Sequence Numbers > independently from crypto suite in a manner similar to transport vs tunnel > mode. I proposed including it in crypto suite because I assumed that the > only reason to not use ESNs was for backwards compatibility and that all > new cryptographic suites would require them. > > --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@lists.tislabs.com Thu Mar 6 17:16:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h271Gj323540; Thu, 6 Mar 2003 17:16:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05553 Thu, 6 Mar 2003 19:41:59 -0500 (EST) Message-ID: <001201c2e442$f01c5bc0$cb06b684@isl.mei.co.jp> From: "Atsuhiro Tsuji" To: Cc: "'Atsuhiro Tsuji'" References: <001b01c2e3e8$146a16d0$292e1dc2@YnirNew> Subject: Re: SPI in Delete Payload of IKE / IKEv2 Date: Fri, 7 Mar 2003 09:46:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Mr. Nir, Thank you for your telling me the spec. of Delete Payload. I understand that is reasonable under the current spec. By the way, I wonder you don't mind that you tell me where the spec. is written. On the other hand, I think it is useful we can tell the deletion of the outbound SA to the peer, and I wonder why don't we specify it... Because "Simple is Best."? Have anyone discussed this? Thank you and I hope you help me again. Atsuhiro Tsuji ----- Original Message ----- From: "Yoav Nir" To: "'Atsuhiro Tsuji'" ; Sent: Thursday, March 06, 2003 10:55 PM Subject: RE: SPI in Delete Payload of IKE / IKEv2 > Hi, > > You send a Delete-SA to stop the peer from using that SA. The IPsec SA is > outbound for the peer, but inbound for you. > > If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B > sends packets with SPI 49. If A wants this traffic to stop, he sends B a > Delete payload with the SPI field 49. > > To stop transmissions on SPI 17, A needs not send out anything. It is > enough that he stops using it. It might have been nice to also be able to > tell peer B that no more traffic will come with SPI 17, so that peer B has > an easier time dropping fake packets, but this is not in the spec. > > Hope this helps. > > Yoav Nir > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On > Behalf Of Atsuhiro Tsuji > Sent: Thursday, March 06, 2003 2:51 PM > To: ipsec@lists.tislabs.com > Subject: SPI in Delete Payload of IKE / IKEv2 > > > Hi, all, > > I'd like to discuss about SPI value in the Delete Payload > of IKE / IKEv2. > > It is the first time to send a question to the mailing list, > so if my behavior/expression is not appropriate, > please kindly point it out to me. > > > As you know, there is a field which contains SPIs in Delete Payload > of IKE / IKEv2. But I cannot find the direction of the SA. > So, I'm confused I have to delete the INBOUND SA or OUTBOUND SA, > especially for IPsec-SA. > > Is there any rule for this? > I wonder we had better add a new field which indicates the direction. > > If you've already discussed this issue, please tell me the pointer > for them. > > I'm looking forward to your joining this discussion. > > Thank you in advance. > > ----- > Atsuhiro Tsuji [tsuji.atsuhiro@jp.panasonic.com] From owner-ipsec@lists.tislabs.com Thu Mar 6 18:32:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h272WE325380; Thu, 6 Mar 2003 18:32:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05812 Thu, 6 Mar 2003 21:01:33 -0500 (EST) Message-Id: <200303061127.GAA03012@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-tutorial-01.txt Date: Thu, 06 Mar 2003 06:27:46 -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 : Understanding IKEv2: Tutorial, and rationale for decisions Author(s) : R. Perlman Filename : draft-ietf-ipsec-ikev2-tutorial-01.txt Pages : 15 Date : 2003-3-5 The main job of a protocol specification is to document how the protocol works. It is sometimes difficult to learn how a protocol works from such a document, because there are so many details, and the necessary formalism for accuracy makes a specification long and intimidating to read. What also is usually lost in the process of creating an RFC for a protocol is documentation of the tradeoffs that were considered when making controversial choices. Sometimes it is possible to find this information on the email archives, but that is a daunting task. This document is intended to work both as a tutorial to understanding IKEv2, and a summary of the controversial issues, with the reasoning on all sides of each issue. If any differences in details exist between this document and the IKEv2 specification, the IKEv2 specification is authoritative. This document is intended only to make the IKEv2 specification more understandable on the first reading, as well as documenting reasoning behind decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-tutorial-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-ikev2-tutorial-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-ikev2-tutorial-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-3-5140957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-tutorial-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-tutorial-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140957.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Mar 6 18:32:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h272WG325391; Thu, 6 Mar 2003 18:32:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05818 Thu, 6 Mar 2003 21:03:31 -0500 (EST) X-Originating-IP: [64.114.95.129] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T Date: Thu, 06 Mar 2003 20:01:14 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Mar 2003 01:01:14.0542 (UTC) FILETIME=[0D379CE0:01C2E445] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This seems like such an imaginary problem. I mean, what are you going to do to prevent it? An international registry of authorized NATs? Bring back strick source routing? A while back when I was working on keepalives, people used to complain that the protocol was insecure because the intermediate router could simply drop the keepalive packets, thus making the link appear dead. To which I replied sure, but they could also just drop all the packets, making the link really dead. IPsec is supposed to be secure communication over an insecure medium. Let's try to work within that scope. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Thu Mar 6 21:44:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h275ic300981; Thu, 6 Mar 2003 21:44:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06355 Fri, 7 Mar 2003 00:14:30 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: comments on ikev2 05 (cryptography) To: Hugo Krawczyk Cc: IPsec WG , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Thu, 6 Mar 2003 23:19:54 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/07/2003 12:17:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > First Issue: Macing the identity. > =========== > The text we agreed upon was (this text appears in my message to the list > on Jan 23rd, Charlie's agreed to it in his response message; there were no > objections in the list). > ... > Instead of this, the text of 05 changes the values MIDr=prf(SK_ar,IDr) and > MIDi=prf(SK_ai,IDi) with the contents of payloads IDr and IDi, respectively. > > I have no idea what motivated this change. I guess that Charlie convinced > himself (or someone convinced him) that putting the identities under the > signatures achieves the same effect as adding the MAC (or prf) of the > identities as we agreed earlier. THIS IS WRONG. Hanson's Razor: Never ascribe to malice that which can be adequately explained by incompetence. I didn't convince myself, nor did anyone convince me. I just made the changes to the spec from memory and got it wrong. I've fixed it in the draft I'm working on. > Second issue: adding g^ir to the prf+ derivation > ============ > > The key derivation presented in 05 is: > > SKEYSEED = prf(Ni | Nr, g^ir) > > {SK_d, SK_ai, SK_ar, SK_ei, SK_er} > = prf+ (SKEYSEED, g^ir | Ni | Nr | SPIi | SPIr ) > > The key derivation in 04 was the same except that g^ir was not included. > The "benefit" of including g^ir under prf is that the DH key randomizes each > of the iterations of prf under the prf+ definition, thus providing seemingly > better (heuristic) security. > The drawback is that the inclusion of g^ir eliminates the mathematical > support behind the use of a prf. As I explained in the past: since SKEYSEED > is derived from g^ir then the (circular) construction > prf+(SKEYSEED, g^ir ....) cannot be formally claimed to be secure. Actually, this change was made between -03 and -04. I have only a vague recollection as to why. I remember a discussion on the list in early December, but don't remember who the advocates for the change were and can't find it now. I'm tempted to change it back based on Hugo's objection, but would hate to have someone else who doesn't notice this note object in -07. Would anyone care to express an opinion? I think everyone agrees that the change has no practical impact on security either way. > Now, somewhat too late for IKE but on time > for IKEv2 I have written the sigma paper to document this rationale > (and a more > mathematical paper with Ran with a rigorous analysis of these protocols). > This rationale is too involved to be added as part of the ikev2 document, > instead I do ask that the security considerations section provides > a pointer to the sigma paper (whose coming revision will also include the > rationale for the prf+ based key derivation). Sure. Can you send me the latest current citation and the new one as soon as it is available? > The strength of a key derived from a Diffie-Hellman exchange using > any of the groups defined here depends on the inherent strength of > the group, the size of the exponent used, and the entropy provided by > the random number generator used. Due to these inputs it is difficult > to determine the strength of a key for any of the defined groups. > Diffie-Hellman group number two when used with a strong random number > generator and an exponent no less than 160 bits is sufficient to use > for 3DES. Groups three through five provide greater security. Group > > I do not agree that 160 bits are sufficient for use with 3DES given that these > exponents allow for a full break of the DH exchange in 2^80 > operations. I would > suggest a minimum of 180 or even 200 bits. Done! --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@lists.tislabs.com Fri Mar 7 01:30:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h279UG329751; Fri, 7 Mar 2003 01:30:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06694 Fri, 7 Mar 2003 03:57:23 -0500 (EST) Date: Thu, 6 Mar 2003 10:46:21 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Brian Korver Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: The CR payload still In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk : > 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). : : Carlie, : : As you point out, no CERTREQ means "don't bother to send any CERTs", : but the question remains as to what an empty CERTREQ means. ISAKMP : states that an empty CERTREQ means "send any CERTs you want, I don't : care". : : Except for the case of opportunistic IPsec, I don't see the point : of telling your peer "I don't care". Therefore, I agree that an empty : CERTREQ should be prohibited in IKEv2, especially because it creates an : interoperability rat hole. : I can respect that but I don't understand what is the interoperability problem. If it is stated explicitly there are no problems. The current one is bigger problem since pki-profile provides a loophole for this (allowing empty CR's) and that will cause confusion unless that too is fixed to include MUST NOT explicitly. There is also other than "opportunistic crypto" cases. You have to remember that someone may not want to trust some CA just because it wants to talk to you (it don't want to trust everybody). Some implementation may want to always use only self-signed certs and there are no CAs in this case. By not allowing "give me ANY cert you are using now" disallows the use of self-signed certs in IKEv2, or rather you MAY receive it during IKE, or may not. Pekka ___________________________________________________________________________ Pekka Riikonen | Email: priikone@iki.fi SSH Communications Security Corp. | http://iki.fi/priikone/ Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc From owner-ipsec@lists.tislabs.com Fri Mar 7 01:39:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h279dc301402; Fri, 7 Mar 2003 01:39:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06715 Fri, 7 Mar 2003 04:14:22 -0500 (EST) Message-Id: <200303070917.h279HZof002884@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Andrew Krywaniuk" cc: ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of Thu, 06 Mar 2003 20:01:14 EST. Date: Fri, 07 Mar 2003 10:17:35 +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: This seems like such an imaginary problem. I mean, what are you going to do to prevent it? An international registry of authorized NATs? Bring back strick source routing? => I believe you missed the fact I didn't try to make NAT traversal secure (I clearly wrote I believe it is near impossible): you are in my side, i.e., you consider that NAT traversal has an untrackable security issue with attackers which behave like NATs. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Mar 7 02:27:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27ARw306114; Fri, 7 Mar 2003 02:27:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06821 Fri, 7 Mar 2003 04:55:35 -0500 (EST) Message-ID: <00c501c2e3ba$872e83f0$640572d4@trustworks.com> From: "Valery Smyslov" To: Subject: Auth Method Date: Thu, 6 Mar 2003 11:29:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greeting, IKEv2-05 specifies only 2 values for Auth Method field in Authentication Payload: Digital Signature (1) and Shared Key Message Integrity Code (2). How could receiver unambiguously determine what digital signature algorithm was used: RSA, DSA or something else? By examining Authentication Payload length? - not very reliable method. Via the other entity's certificate? - but Certificate Payload is optional, and the entity may have several certificates of different type. In message http://www.vpnc.org/ietf-ipsec/mail-archive/msg02440.html Charlie Kaufman wrote: Unless someone objects, I'll add a specifier of the authentication data type, of which we currently have 3: RSA signature, DSA signature, and shared key HMAC. So, the original intention was to make Auth Type more specific than we have now, indicating what particular digital signature algorithm was used. I'm curious what was the rationale to change that intention. Another issue - how each side can advertise auth methods she supports. In the same message there was some discussion on this topic and suggestion to use CertRequest Payload for that purpose. Unfortunately, it hasn't been done. Why? Are there strong objections against it? Regards, Valery Smyslov. From jonla@nortelnetworks.com Fri Mar 7 06:11:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27EBR324926 for ; Fri, 7 Mar 2003 06:11:27 -0800 (PST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27EBLk07407 for ; Fri, 7 Mar 2003 09:11:21 -0500 (EST) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 09:11:20 -0500 Message-ID: <6204FDDE129D364D8040A98BCCB290EF041572BC@zbl6c004.corpeast.baynetworks.com> From: "JON LAWRENCE" To: "'ietf-ipsec@www.vpnc.org'" Subject: subscribe Date: Fri, 7 Mar 2003 09:11:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E4B3.6C026390" 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_01C2E4B3.6C026390 Content-Type: text/plain ------_=_NextPart_001_01C2E4B3.6C026390 Content-Type: text/html subscribe
------_=_NextPart_001_01C2E4B3.6C026390-- From owner-ipsec@lists.tislabs.com Fri Mar 7 06:17:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27EHJ325145; Fri, 7 Mar 2003 06:17:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07305 Fri, 7 Mar 2003 08:37:39 -0500 (EST) Message-Id: <200303071153.GAA21218@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-pki-profile-02.txt Date: Fri, 07 Mar 2003 06:53:04 -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 : The Internet IP Security PKI Profile of ISAKMP and PKIX Author(s) : B. Korver, E. Rescorla Filename : draft-ietf-ipsec-pki-profile-02.txt Pages : 34 Date : 2003-3-6 ISAKMP and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of ISAKMP and PKIX that defines the requirements for using PKI technology in the context of IPsec. The document compliments protocol specifica- tions such as IKE, which assume the existence of public key certifi- cates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-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-pki-profile-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-pki-profile-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-3-6125201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-profile-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-profile-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125201.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Mar 7 06:38:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Ecd326044; Fri, 7 Mar 2003 06:38:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07346 Fri, 7 Mar 2003 09:08:47 -0500 (EST) Message-Id: <200303071411.h27EBLof004912@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: Brian Korver , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: The CR payload still In-reply-to: Your message of Tue, 04 Mar 2003 22:28:02 EST. Date: Fri, 07 Mar 2003 15:11:21 +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: If someone has a use for requesting no certificates, I think this is a fine way to encode it. But I'm reluctant to add a feature unless someone thinks they need it. => I know cases where this (a way to request no certificate) is very useful (i.e., it avoids fragmentation problems too) in the mobility context. Today it is done by specific configuration but a standardized mechanism is far better. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Mar 7 07:38:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Fc2327739; Fri, 7 Mar 2003 07:38:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07504 Fri, 7 Mar 2003 10:04:38 -0500 (EST) Message-Id: <200303061558.h26Fw6of099857@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of Wed, 05 Mar 2003 12:22:18 EST. <200303051722.h25HMI4f014682@marajade.sandelman.ottawa.on.ca> Date: Thu, 06 Mar 2003 16:58:06 +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: Well, they do not need to be in the reverse path. It enough to be in the forward path. (client->gateway) => IMHO this is only true for the bidding down attack itself because for the transient pseudo-NAT attack the initiator/client won't receive the reply so will retransmit the request. The replay protection means that it isn't enough to replay the packet, unless one can do it faster than the original packet. So, I agree that the attacker pretty much has to be inline. => agreed I'm wasn't explicit in saying that these aren't unique attacks to NAT-T. => in fact the only useful thing in favor of my bidding down argument is that NAT-T is less secure. The thing that we could do, is require some kind of three way handshake to change the UDP port #/IP address. That could be a rekey. => it won't be enough: you just increase the number of messages the pseudo-NAT attacker has to patch. This assures that the flow doesn't get aimed at some innocent bystandard until the real client speaks again. The sequence would go something like this: gateway receives new UDP port #/IP #1 sends notify to old UDP port #/IP, indicating that it thinks it should change #2 sends notify to new UDP port #/IP, indicating that it thinks it is time to rekey A client receiving #1 can reply, saying "no thank you" if it doesn't want to rekey yet. A client receiving #2 can reply with a rekey. A client receiving both could cancel the rekey with some token from #1. This might all fit into Dead Peer Detection. Note that an observer can easily figure out which is IKE traffic and which is ESP traffic. The truly paranoid may want to have the gateway send the IKE traffic inside the ESP tunnel. This seems very fragile to me. => we (me and Tero) already discussed about this kind of three way handshakes... in fact they are more useful for mobility/multihoming (they provide more than the trust in the other peer to own its address). About NAT-T, it seems the best defense is to support an implicit address change, i.e., the peer address is updated in all SAs as soon as a packet (ESP or IKE) is received from a new address. The transient pseudo-NAT attack still works but its effect is transient, i.e., the first unmodified packet from the peer will put again the right address. And this is more efficient for the NAT-T itself. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Mar 7 07:38:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27FcC327773; Fri, 7 Mar 2003 07:38:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07539 Fri, 7 Mar 2003 10:08:45 -0500 (EST) Message-Id: <200303071450.JAA06444@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-04.txt Date: Fri, 07 Mar 2003 09:50:15 -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-04.txt Pages : 17 Date : 2003-3-6 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-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-nat-reqts-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-nat-reqts-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-3-6135140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-reqts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6135140.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Mar 7 07:40:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27FeY328172; Fri, 7 Mar 2003 07:40:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07550 Fri, 7 Mar 2003 10:09:45 -0500 (EST) Message-Id: <200303071450.JAA06480@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-flow-monitoring-mib-02.txt Date: Fri, 07 Mar 2003 09:50:29 -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 Flow Monitoring MIB Author(s) : C. Madson, L. Temoshenko, c. Pellecuru, R. Somasundaram, N. Timms Filename : draft-ietf-ipsec-flow-monitoring-mib-02.txt Pages : 150 Date : 2003-3-6 This document describes a high-level MIB for monitoring, accounting trending and failure detection for IPsec-based networks. Optional features of the MIB include trending of IPsec-related metrics and archiving of VPN failures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-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-flow-monitoring-mib-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-flow-monitoring-mib-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-3-6140320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-flow-monitoring-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6140320.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Mar 7 08:17:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27GHo301238; Fri, 7 Mar 2003 08:17:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07660 Fri, 7 Mar 2003 10:45:10 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Yoav Nir" , Subject: RE: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: Configuration portion of OPEN ISSUES...] Date: Wed, 5 Mar 2003 13:44:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <007301c2e2f6$d3b630c0$292e1dc2@YnirNew> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk MUST to SHOULD - Done "Act as a relay agent", does this mean 1 - an RFC3456 relay (snooping yiaddr, inject packets into ipsec flows) 2 - a relay that provides is used by the DHCP clients on the IRAS which I mention in the draft as a todo item? I'm guessing #2, which I'm writing the text for now. Thanks. Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Yoav Nir > Sent: Wednesday, March 05, 2003 4:09 AM > To: ipsec@lists.tislabs.com > Subject: RE: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: > Configuration portion of OPEN ISSUES...] > > > Hi Darren and Gregory > > From your draft: > > "The htype MUST be set to 31 so the DHCP server can distinguish..." > > Your draft mandates the use of htype 31 when contacting a DHCP > server. This > would work if all DHCP servers in the world supported the IPsec tunnel > option. In fact many don't. I suggest that the MUST in the > above sentence > be changed to SHOULD, and that an option be added for gateways to act as > DHCP relay agents. > > Yoav > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Darren Dukes > Sent: Tuesday, March 04, 2003 8:04 PM > To: ipsec@lists.tislabs.com > Subject: temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt [WAS: > Configuration portion of OPEN ISSUES...] > > > > -----Original Message----- > > From: Gregory Lebovitz [mailto:Gregory@netscreen.com] > > Sent: Wednesday, February 26, 2003 12:38 PM > > > > > Or maybe: > > * Keep configuration payload, and show (possibly in Appendix or another > > document) how it works with various backend config servers, i.e. DHCP, > > RADIUS, LDAP. > > > > BTW, Darren Dukes and I are working right now on some text for > this. Stay > > tuned. > > We've spent the last several days in a bit of a mad dash to get this > description of Configuration Payloads back ended by DHCPv4 and RADIUS > fleshed out and to the list while the configuration discussion still has > legs. The descriptions of how CP can work with backend config servers is > about 90% complete and will be cleaned up and more completely fleshed out > over the next week. Any suggestions, comments, questions, or answers to > questions in the draft can be sent directly to the authors or to the ipsec > list. > > Since we missed the cutoff date for new drafts Paul Hoffman/VPNC has > temporarily hosted the draft. You can get it here: > > > There are many stray extended ASCII characters that made their > way into this > revision, they'll be scrubbed out when the next revision is posted. > > Darren Dukes and Gregory Lebovitz > > From owner-ipsec@lists.tislabs.com Fri Mar 7 08:17:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27GHq301248; Fri, 7 Mar 2003 08:17:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07666 Fri, 7 Mar 2003 10:46:10 -0500 (EST) Message-Id: <200303061127.GAA02994@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;;@tislabs.com;;;;;;;;;, @tislabs.com;@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-esp-v3-04.txt Date: Thu, 06 Mar 2003 06:27: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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-04.txt Pages : 42 Date : 2003-3-5 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-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-esp-v3-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-esp-v3-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-3-5140835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140835.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Mar 7 09:15:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27HFj307153; Fri, 7 Mar 2003 09:15:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07867 Fri, 7 Mar 2003 11:38:17 -0500 (EST) To: Francis Dupont Cc: "Andrew Krywaniuk" , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: bidding down attach on NAT-T References: <200303070917.h279HZof002884@givry.rennes.enst-bretagne.fr> Date: 07 Mar 2003 11:41:19 -0500 In-Reply-To: <200303070917.h279HZof002884@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, Francis Dupont writes: > => I believe you missed the fact I didn't try to make NAT traversal > secure (I clearly wrote I believe it is near impossible): you are > in my side, i.e., you consider that NAT traversal has an untrackable > security issue with attackers which behave like NATs. While I agree that peers should not use NAT-T if there is no NAT between them, I do think that NAT-T support should be required. You never know when there will be a NAT between you and your peer. Note that you CAN securely detect a NAT (and I consider a pseudo-NAT to be equivalent to a NAT in this sense) because the IKE messages are secured. So the only real attack is some router performing NAT on you -- but that router could just as easily drop your packets too, so I don't think this is a credible threat. Personally, I feel that being able to use IPsec through a NAT is more important than worrying about some router dropping your packets or trying to re-NAT you. > Regards > > Francis.Dupont@enst-bretagne.fr -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 7 09:47:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Hl3307991; Fri, 7 Mar 2003 09:47:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08028 Fri, 7 Mar 2003 12:16:43 -0500 (EST) Message-Id: <200303071719.h27HJFof007722@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Derek Atkins cc: "Andrew Krywaniuk" , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of 07 Mar 2003 11:41:19 EST. Date: Fri, 07 Mar 2003 18:19:15 +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: Francis Dupont writes: > => I believe you missed the fact I didn't try to make NAT traversal > secure (I clearly wrote I believe it is near impossible): you are > in my side, i.e., you consider that NAT traversal has an untrackable > security issue with attackers which behave like NATs. While I agree that peers should not use NAT-T if there is no NAT between them, => fine, we agree at 100%. I do think that NAT-T support should be required. => I have no objection but: - configuration must have a knob to disable NAT-T support - NAT detection must be secure. You never know when there will be a NAT between you and your peer. => I agree but there are some cases where you don't want to support a NAT between you and your peer. Note that you CAN securely detect a NAT (and I consider a pseudo-NAT to be equivalent to a NAT in this sense) because the IKE messages are secured. => yes but the current draft does the NAT detection in the only unsecured IKE messages, i.e, too soon! So the only real attack is some router performing NAT on you -- but that router could just as easily drop your packets too, so I don't think this is a credible threat. => this should be the only real attack! Personally, I feel that being able to use IPsec through a NAT is more important than worrying about some router dropping your packets or trying to re-NAT you. => I agree but I'd like to have NAT traversal active only when I know it is possible to get a NAT on the path (i.e., a disable knob in the config) and when there really is a NAT on the path (i.e., secure the NAT detection). Please read the NAT-DETECTION-*-IP stuff and say whether you are happy with it (I am *not*)? Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Mar 7 17:45:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h281jj328726; Fri, 7 Mar 2003 17:45:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08960 Fri, 7 Mar 2003 20:13:25 -0500 (EST) Message-ID: <001201c2e442$f01c5bc0$cb06b684@isl.mei.co.jp> From: "Atsuhiro Tsuji" To: Cc: "'Atsuhiro Tsuji'" References: <001b01c2e3e8$146a16d0$292e1dc2@YnirNew> Subject: Re: SPI in Delete Payload of IKE / IKEv2 Date: Fri, 7 Mar 2003 09:46:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Mr. Nir, Thank you for your telling me the spec. of Delete Payload. I understand that is reasonable under the current spec. By the way, I wonder you don't mind that you tell me where the spec. is written. On the other hand, I think it is useful we can tell the deletion of the outbound SA to the peer, and I wonder why don't we specify it... Because "Simple is Best."? Have anyone discussed this? Thank you and I hope you help me again. Atsuhiro Tsuji ----- Original Message ----- From: "Yoav Nir" To: "'Atsuhiro Tsuji'" ; Sent: Thursday, March 06, 2003 10:55 PM Subject: RE: SPI in Delete Payload of IKE / IKEv2 > Hi, > > You send a Delete-SA to stop the peer from using that SA. The IPsec SA is > outbound for the peer, but inbound for you. > > If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B > sends packets with SPI 49. If A wants this traffic to stop, he sends B a > Delete payload with the SPI field 49. > > To stop transmissions on SPI 17, A needs not send out anything. It is > enough that he stops using it. It might have been nice to also be able to > tell peer B that no more traffic will come with SPI 17, so that peer B has > an easier time dropping fake packets, but this is not in the spec. > > Hope this helps. > > Yoav Nir > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On > Behalf Of Atsuhiro Tsuji > Sent: Thursday, March 06, 2003 2:51 PM > To: ipsec@lists.tislabs.com > Subject: SPI in Delete Payload of IKE / IKEv2 > > > Hi, all, > > I'd like to discuss about SPI value in the Delete Payload > of IKE / IKEv2. > > It is the first time to send a question to the mailing list, > so if my behavior/expression is not appropriate, > please kindly point it out to me. > > > As you know, there is a field which contains SPIs in Delete Payload > of IKE / IKEv2. But I cannot find the direction of the SA. > So, I'm confused I have to delete the INBOUND SA or OUTBOUND SA, > especially for IPsec-SA. > > Is there any rule for this? > I wonder we had better add a new field which indicates the direction. > > If you've already discussed this issue, please tell me the pointer > for them. > > I'm looking forward to your joining this discussion. > > Thank you in advance. > > ----- > Atsuhiro Tsuji [tsuji.atsuhiro@jp.panasonic.com] From owner-ipsec@lists.tislabs.com Sat Mar 8 05:42:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28Dgv321211; Sat, 8 Mar 2003 05:42:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10104 Sat, 8 Mar 2003 08:04:59 -0500 (EST) X-Originating-IP: [64.114.95.129] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: comments on ikev2 05 (cryptography) Date: Fri, 07 Mar 2003 18:12:47 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Mar 2003 23:12:47.0623 (UTC) FILETIME=[11345170:01C2E4FF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The strength of a key derived from a Diffie-Hellman exchange using > any of the groups defined here depends on the inherent strength of > the group, the size of the exponent used, and the entropy provided by > the random number generator used. Due to these inputs it is difficult > to determine the strength of a key for any of the defined groups. > Diffie-Hellman group number two when used with a strong random number > generator and an exponent no less than 160 bits is sufficient to use > for 3DES. Groups three through five provide greater security. Group > >I do not agree that 160 bits are sufficient for use with 3DES given that these >exponents allow for a full break of the DH exchange in 2^80 >operations. I would >suggest a minimum of 180 or even 200 bits. I seem to remember from Hillarie's earlier paper on key sizes that the size of the exponent is not the dominant factor that contributes to the strength of the DH exchange. When you increase the modulus from 1024 bits to 2048 bits, you now have to do 2048 bit multiplies instead of 1024 bit multiples and that also involves a lot more memory reads. The order of this effect is sub-exponential, but still very significant. Could this be why the exponent size was set to 160? 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@lists.tislabs.com Sat Mar 8 05:42:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28Dgv321210; Sat, 8 Mar 2003 05:42:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10110 Sat, 8 Mar 2003 08:06:00 -0500 (EST) X-Originating-IP: [64.114.95.129] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T Date: Thu, 06 Mar 2003 20:01:14 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Mar 2003 01:01:14.0542 (UTC) FILETIME=[0D379CE0:01C2E445] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This seems like such an imaginary problem. I mean, what are you going to do to prevent it? An international registry of authorized NATs? Bring back strick source routing? A while back when I was working on keepalives, people used to complain that the protocol was insecure because the intermediate router could simply drop the keepalive packets, thus making the link appear dead. To which I replied sure, but they could also just drop all the packets, making the link really dead. IPsec is supposed to be secure communication over an insecure medium. Let's try to work within that scope. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Sat Mar 8 06:23:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28ENj321996; Sat, 8 Mar 2003 06:23:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10204 Sat, 8 Mar 2003 08:58:15 -0500 (EST) Date: Sat, 8 Mar 2003 09:01:05 -0500 From: Ran Canetti Message-Id: <200303081401.JAA32612@ornavella.watson.ibm.com> To: Charlie_Kaufman@notesdev.ibm.com, hugo@ee.technion.ac.il Subject: Re: comments on ikev2 05 (cryptography) Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, > From: Charlie_Kaufman@notesdev.ibm.com > > > Second issue: adding g^ir to the prf+ derivation > > ============ > > > > The key derivation presented in 05 is: > > > > SKEYSEED = prf(Ni | Nr, g^ir) > > > > {SK_d, SK_ai, SK_ar, SK_ei, SK_er} > > = prf+ (SKEYSEED, g^ir | Ni | Nr | SPIi | SPIr ) > > > > The key derivation in 04 was the same except that g^ir was not included. > > The "benefit" of including g^ir under prf is that the DH key randomizes > each > > of the iterations of prf under the prf+ definition, thus providing > seemingly > > better (heuristic) security. > > The drawback is that the inclusion of g^ir eliminates the mathematical > > support behind the use of a prf. As I explained in the past: since > SKEYSEED > > is derived from g^ir then the (circular) construction > > prf+(SKEYSEED, g^ir ....) cannot be formally claimed to be secure. > > Actually, this change was made between -03 and -04. I have only a vague > recollection as to why. I remember a discussion on the list in early > December, but don't remember who the advocates for the change were and > can't find it now. I'm tempted to change it back based on Hugo's objection, > but would hate to have someone else who doesn't notice this note object in > -07. Would anyone care to express an opinion? I think everyone agrees that > the change has no practical impact on security either way. As Hugo said, adding g^ir to the input of the prf+ would prevent us from claiming that the key derivation mechanism of IKE is sound from a cryptographic point of view, based on the standard cryptographic formulation of pseudorandom functions. (This is due to the fact that a pseudorandom function provides no guarantee on the security of the outcome when its input is significantly related to its key - which is the case in the current spec.) So now the question is whether the existence of a security proof has "practical impact" on the protocol or not. I tend to say that it does. As a customer, I'd rather spend my money on a security product that has a security proof assciated with it. (but, no, i woldn't want the proof in my owner's manual :) Ran From owner-ipsec@lists.tislabs.com Sun Mar 9 01:26:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h299QJ320828; Sun, 9 Mar 2003 01:26:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11807 Sun, 9 Mar 2003 03:46:41 -0500 (EST) From: "Yoav Nir" To: "'Atsuhiro Tsuji'" , Subject: RE: SPI in Delete Payload of IKE / IKEv2 Date: Sun, 9 Mar 2003 10:59:29 +0200 Message-ID: <000601c2e61a$326fef90$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001201c2e442$f01c5bc0$cb06b684@isl.mei.co.jp> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is described in RFC 2408 section 3.15 -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Atsuhiro Tsuji Sent: Friday, March 07, 2003 2:46 AM To: ipsec@lists.tislabs.com Cc: 'Atsuhiro Tsuji' Subject: Re: SPI in Delete Payload of IKE / IKEv2 Hi, Mr. Nir, Thank you for your telling me the spec. of Delete Payload. I understand that is reasonable under the current spec. By the way, I wonder you don't mind that you tell me where the spec. is written. On the other hand, I think it is useful we can tell the deletion of the outbound SA to the peer, and I wonder why don't we specify it... Because "Simple is Best."? Have anyone discussed this? Thank you and I hope you help me again. Atsuhiro Tsuji ----- Original Message ----- From: "Yoav Nir" To: "'Atsuhiro Tsuji'" ; Sent: Thursday, March 06, 2003 10:55 PM Subject: RE: SPI in Delete Payload of IKE / IKEv2 > Hi, > > You send a Delete-SA to stop the peer from using that SA. The IPsec SA is > outbound for the peer, but inbound for you. > > If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B > sends packets with SPI 49. If A wants this traffic to stop, he sends B a > Delete payload with the SPI field 49. > > To stop transmissions on SPI 17, A needs not send out anything. It is > enough that he stops using it. It might have been nice to also be able to > tell peer B that no more traffic will come with SPI 17, so that peer B has > an easier time dropping fake packets, but this is not in the spec. > > Hope this helps. > > Yoav Nir > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On > Behalf Of Atsuhiro Tsuji > Sent: Thursday, March 06, 2003 2:51 PM > To: ipsec@lists.tislabs.com > Subject: SPI in Delete Payload of IKE / IKEv2 > > > Hi, all, > > I'd like to discuss about SPI value in the Delete Payload > of IKE / IKEv2. > > It is the first time to send a question to the mailing list, > so if my behavior/expression is not appropriate, > please kindly point it out to me. > > > As you know, there is a field which contains SPIs in Delete Payload > of IKE / IKEv2. But I cannot find the direction of the SA. > So, I'm confused I have to delete the INBOUND SA or OUTBOUND SA, > especially for IPsec-SA. > > Is there any rule for this? > I wonder we had better add a new field which indicates the direction. > > If you've already discussed this issue, please tell me the pointer > for them. > > I'm looking forward to your joining this discussion. > > Thank you in advance. > > ----- > Atsuhiro Tsuji [tsuji.atsuhiro@jp.panasonic.com] From owner-ipsec@lists.tislabs.com Sun Mar 9 09:18:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h29HIH323409; Sun, 9 Mar 2003 09:18:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12494 Sun, 9 Mar 2003 11:29:51 -0500 (EST) Message-Id: <200303091632.h29GWZof017065@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ikev2-tutorial-01.txt Date: Sun, 09 Mar 2003 17:32:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have many comments about draft-ietf-ipsec-ikev2-tutorial-01.txt section 9.0 NAT Traversal: NAT-Traversal [KSH01] designed a mechanism that was deployed in IKEv1, and IKEv2 copied the design. => this is unfortunately *not* true. [KSH01] is more complete (it supports transport mode) and secure (it has not the bidding down attack against the NAT-T detection). The NAT-Traversal design accommodated existing NATs as much as possible (without sacrificing security or significantly impacting performance). => I disagree about the first point (without sacrificing security) because IKE/IPsec NAT-T is clearly less secure than IKE/IPsec without it. But this is a problem which has no easy/simple solution so my concern is only about the misleading statement. And it even allows a network using some addressing scheme different from IPv4 to connect to the Internet. => this wording won't make IPv6 people happy. The reason it is a hash rather than the actual address is because some people have argued that the actual address of a node behind a NAT might be secret. => this is the reason given by Tero Kivinen. My address management provides the same thing (in a better way according the text which follows the quote) by a "hashed" address family. In addition to sending the child-SA packets on 4500, IKE (once the NAT is detected) sends the remaining messages of the IKE handshake over port 4500 instead of 500 (and does not insist on receiving them from source port 4500). => this is not accurate because this (port 4500) applies to all further packets after the current exchange (the "after" constraint comes from the reply to reversed address and port rule). => there are missing points, for instance NAT-T should include an implicit peer address update mechanism because the NAT is by definition out of control and can change mappings for the peer behind it. With such a mechanism the first packet sent by the peer behind the NAT will update its mapped peer address on the other peer. This has other advantages: - it makes the switch to port 4500 possible after the second (IKE_AUTH) exchange, so the NAT detection can be safely done in this second exchange. - it is the best defense against an attacker which plays the role of a NAT and diverts the IPsec traffic by mapping the peer address to a victim address. Regards Francis.Dupont@enst-bretagne.fr PS: the formating of the draft is still disaster. From owner-ipsec@lists.tislabs.com Sun Mar 9 17:51:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A1po310908; Sun, 9 Mar 2003 17:51:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA13325 Sun, 9 Mar 2003 20:19:06 -0500 (EST) Message-ID: <001001c2e6a3$a5f8f810$cb06b684@isl.mei.co.jp> From: "Atsuhiro Tsuji" To: "Yoav Nir" , Cc: "'Atsuhiro Tsuji'" References: <000601c2e61a$326fef90$292e1dc2@YnirNew> Subject: Re: SPI in Delete Payload of IKE / IKEv2 Date: Mon, 10 Mar 2003 10:23:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear, Mr. Nir, Thank you for your reply. While I was almost convinced of your explanation, the draft of IKEv2 is making me confused... # Sorry, It was the first time I read draft-ietf-ipsec-ikev2-05.txt. Actually, RFC2408 section 3.15 describes as: "Deletion which is concerned with a Protocol SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s)." Do you mean "the sending entity's SPI(s)." expresses INBOUND SA'(s) SPI? And during I'm reviewing the draft-ietf-ipsec-ikev2-05.txt section 3.11, I found it describes as: "Deletion of a CHILD-SA, such as ESP or AH, will contain the Protocol-Id of that protocol (1 for ESP, 2 for AH) and the SPI is the SPI the sending endpoint would place in outbound ESP or AH packets. It may describe the different specification from you... What do you think? Am I misunderstanding the draft of IKEv2? Sincerely yours, Atsuhiro Tsuji ----- Original Message ----- From: "Yoav Nir" To: "'Atsuhiro Tsuji'" ; Sent: Sunday, March 09, 2003 5:59 PM Subject: RE: SPI in Delete Payload of IKE / IKEv2 > It is described in RFC 2408 section 3.15 > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Atsuhiro Tsuji > Sent: Friday, March 07, 2003 2:46 AM > To: ipsec@lists.tislabs.com > Cc: 'Atsuhiro Tsuji' > Subject: Re: SPI in Delete Payload of IKE / IKEv2 > > > Hi, Mr. Nir, > > Thank you for your telling me the spec. of Delete Payload. > I understand that is reasonable under the current spec. > > By the way, I wonder you don't mind that you tell me where the spec. is > written. > > On the other hand, > I think it is useful we can tell the deletion of the outbound SA to the > peer, > and I wonder why don't we specify it... > Because "Simple is Best."? > Have anyone discussed this? > > Thank you and I hope you help me again. > > Atsuhiro Tsuji > > ----- Original Message ----- > From: "Yoav Nir" > To: "'Atsuhiro Tsuji'" ; > > Sent: Thursday, March 06, 2003 10:55 PM > Subject: RE: SPI in Delete Payload of IKE / IKEv2 > > > > Hi, > > > > You send a Delete-SA to stop the peer from using that SA. The IPsec SA is > > outbound for the peer, but inbound for you. > > > > If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B > > sends packets with SPI 49. If A wants this traffic to stop, he sends B a > > Delete payload with the SPI field 49. > > > > To stop transmissions on SPI 17, A needs not send out anything. It is > > enough that he stops using it. It might have been nice to also be able to > > tell peer B that no more traffic will come with SPI 17, so that peer B has > > an easier time dropping fake packets, but this is not in the spec. > > > > Hope this helps. > > > > Yoav Nir > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On > > Behalf Of Atsuhiro Tsuji > > Sent: Thursday, March 06, 2003 2:51 PM > > To: ipsec@lists.tislabs.com > > Subject: SPI in Delete Payload of IKE / IKEv2 > > > > > > Hi, all, > > > > I'd like to discuss about SPI value in the Delete Payload > > of IKE / IKEv2. > > > > It is the first time to send a question to the mailing list, > > so if my behavior/expression is not appropriate, > > please kindly point it out to me. > > > > > > As you know, there is a field which contains SPIs in Delete Payload > > of IKE / IKEv2. But I cannot find the direction of the SA. > > So, I'm confused I have to delete the INBOUND SA or OUTBOUND SA, > > especially for IPsec-SA. > > > > Is there any rule for this? > > I wonder we had better add a new field which indicates the direction. > > > > If you've already discussed this issue, please tell me the pointer > > for them. > > > > I'm looking forward to your joining this discussion. > > > > Thank you in advance. > > > > ----- > > Atsuhiro Tsuji [tsuji.atsuhiro@jp.panasonic.com] From owner-ipsec@lists.tislabs.com Sun Mar 9 19:56:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A3us313269; Sun, 9 Mar 2003 19:56:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13559 Sun, 9 Mar 2003 22:25:44 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200303071719.h27HJFof007722@givry.rennes.enst-bretagne.fr> Subject: Re: bidding down attach on NAT-T To: Francis Dupont Cc: "Andrew Krywaniuk" , Derek Atkins , ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sun, 9 Mar 2003 20:13:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/09/2003 10:29:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > Please read the NAT-DETECTION-*-IP stuff and say whether you are happy > with it (I am *not*)? Please do, everyone. I tried to copy the philosophy of the NAT-T documents into IKEv2, but I may have gotten it wrong and the documents I copied may have been wrong. Proofreading by people knowledgeable in this space is vital. For example, I was just rereading ESP encapsulation and it is different than I remembered and different than what I wrote in IKEv2-05. It's a detail, but it's important. How does a packet sent to UDP port 4500 get identified as ESP or IKE. What I remember (and wrote) was that IKE messages have four bytes of zero prepended and ESP SPIs are not allowed to be zero. This leads to no overhead for ESP and 4 bytes for IKE. But reading draft-ietf-udp-encaps-01.txt (April 2002), it calls for eight bytes of zero prepended to ESP packets and IKE SPIs are not allowed to be zero. This results in no overhead for IKE packets and 8 bytes for ESP. Did this change somewhere along the line, and if so which proposal won? Either design works, but they can't be mixed on a single port. > I do think that NAT-T support should be required. > > => I have no objection but: > - configuration must have a knob to disable NAT-T support > - NAT detection must be secure. > > You never know when there will be a NAT between you and your peer. > > => I agree but there are some cases where you don't want to support > a NAT between you and your peer. Currently ikev2-05 says that NAT support is optional in an IKE implementation. There are other statements that could be made. It could say that implementations MUST support NAT-T but that it MAY be configured off. It could say that if an implementation supports NAT-T, then it MUST have a configuration switch to turn it off. I don't have strong feelings. My priorities are keeping the MUST features minimal while assuring that any two implementations with the MUST features can be configured to interoperate. How important is it for everyone to support NAT-T? > => yes but the current draft does the NAT detection in the only unsecured > IKE messages, i.e, too soon! The current draft does NAT detection in the first two messages, which are not directly cryptographically protected. They are indirectly protected, however, because MACs of the first two messages are included in subsequent messages. So someone faking out the NAT detection messages would not successfully set up an SA. Michael Richardson wrote: > The thing that we could do, is require some kind of three way handshake to > change the UDP port #/IP address. That could be a rekey. > > This assures that the flow doesn't get aimed at some innocent bystandard > until the real client speaks again. > > The sequence would go something like this: > > gateway receives new UDP port #/IP > #1 sends notify to old UDP port #/IP, > indicating that it thinks it should change > #2 sends notify to new UDP port #/IP, > indicating that it thinks it is time to rekey I think you're assuming a feature in the protocol that's not there. There is no way specified to change the UDP port # / IP address of an existing SA. The assumption is that if the NAT changes the translation of ports and addresses in the middle of the SA, packets in at least one direction will stop being delivered and the SA will fail (by timing out). One or both endpoints MAY then try to open a new SA with the new addresses and ports. Something missing from the spec in general is how often to retry failed SAs and whether to retry immediately when one fails. One could imagine some really bad strategies (from a performance point of view). I thought it unnecessary to specify it because it does not affect interoperability and prescribing such behavior requires that we agree on what it should be. But some "implementer's hints" would probably be a good idea. If we were to support address and port changes in the middle of an SA, there would be possible attacks of the sort you describe and we should try to defend against them. But is there really a need? TCP connections fail if addresses and ports change in the middle of a connection. The endpoints are expected to start over. With Mobile-IP, this may be a common case, so perhaps they have to deal with it. But do we? --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@lists.tislabs.com Sun Mar 9 19:58:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A3w4313299; Sun, 9 Mar 2003 19:58:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13558 Sun, 9 Mar 2003 22:25:43 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <001201c2e442$f01c5bc0$cb06b684@isl.mei.co.jp> Subject: Re: SPI in Delete Payload of IKE / IKEv2 To: "Atsuhiro Tsuji" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "'Atsuhiro Tsuji'" X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sun, 9 Mar 2003 21:24:29 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/09/2003 10:29:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note: this exchange has uncovered an unintended difference between IKEv1 and IKEv2. Question for the list: should I change IKEv2 to match (assuming it's true that IKEv1 works as described). "Yoav Nir" wrote: > Hi, > > You send a Delete-SA to stop the peer from using that SA. The IPsec SA is > outbound for the peer, but inbound for you. > > If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B > sends packets with SPI 49. If A wants this traffic to stop, he sends B a > Delete payload with the SPI field 49. > > To stop transmissions on SPI 17, A needs not send out anything. It is > enough that he stops using it. It might have been nice to also be able to > tell peer B that no more traffic will come with SPI 17, so that peer B has > an easier time dropping fake packets, but this is not in the spec. > > Hope this helps. > > Yoav Nir "Atsuhiro Tsuji" wrote: > Thank you for your telling me the spec. of Delete Payload. > I understand that is reasonable under the current spec. > > By the way, I wonder you don't mind that you tell me where the spec. > is written. For IKEv2 (draft-ietf-ipsec-ikev2-05.txt), the processing is described in Section 3.11: Delete Payload. It says: "Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but no SPIs. Deletion of a CHILD-SA, such as ESP or AH, will contain the Protocol-Id of that protocol (1 for ESP, 2 for AH) and the SPI is the SPI the sending endpoint would place in outbound ESP or AH packets." So in IKEv2, you identify the SA to delete by the SPI chosen by the other end. Apparently in IKEv1, it was identified by the SPI chosen by you. > On the other hand, > I think it is useful we can tell the deletion of the outbound SA to the peer, > and I wonder why don't we specify it... > Because "Simple is Best."? > Have anyone discussed this? For IKEv2, this is discussed in section 1.4 The INFORMATIONAL Exchange. The ESP SAs in the two directions MUST be closed together. When you get a request to close one side, you MUST close the other (unless it's already closed in an unlikely race condition where both ends decide to close the SAs simultaneously). I don't know how this was handled in IKEv1. --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@lists.tislabs.com Sun Mar 9 19:58:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A3wS313317; Sun, 9 Mar 2003 19:58:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13557 Sun, 9 Mar 2003 22:25:40 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: comments on ikev2 05 (cryptography) To: "Andrew Krywaniuk" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sun, 9 Mar 2003 21:42:14 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/09/2003 10:29:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Andrew Krywaniuk" wrote: > I seem to remember from Hillarie's earlier paper on key sizes that the size > of the exponent is not the dominant factor that contributes to the strength > of the DH exchange. When you increase the modulus from 1024 bits to 2048 > bits, you now have to do 2048 bit multiplies instead of 1024 bit multiples > and that also involves a lot more memory reads. The order of this effect is > sub-exponential, but still very significant. > > Could this be why the exponent size was set to 160? Yes. Generally, when doing Diffie-Hellman exchanges, the exponent size can be substantially smaller than the modulus size without losing security. There is a substantial performance gain by doing so. The only question is what the appropriate size exponent is to match a 1024 bit modulus. The text said 160, but Hugo suggested that 180 or 200 would be more appropriate. I'm certainly willing to take his word for it. For a 2048 bit modulus, the exponent size would be bigger, but no where near double. There's probably a table in some cryptographer's handbook somewhere. --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@lists.tislabs.com Sun Mar 9 19:58:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A3wV313337; Sun, 9 Mar 2003 19:58:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13560 Sun, 9 Mar 2003 22:25:48 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <00c501c2e3ba$872e83f0$640572d4@trustworks.com> Subject: Re: Auth Method To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sun, 9 Mar 2003 20:57:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_02272003NP|February 27, 2003) at 03/09/2003 10:29:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Valery Smyslov" wrote: > In message http://www.vpnc.org/ietf-ipsec/mail-archive/msg02440.html > Charlie Kaufman wrote: > > Unless someone objects, I'll add a specifier of the > authentication data type, of which we currently have 3: RSA > signature, > DSA signature, and shared key HMAC. > > So, the original intention was to make Auth Type more specific than we > have now, indicating what particular digital signature algorithm was used. > I'm curious what was the rationale to change that intention. I really need a better filing system for things I say I will do unless someone objects. In this case, I remembered to add the type code, but forgot that you wanted separate ones for RSA vs DSA. I've now added a third code value for DSA. > Another issue - how each side can advertise auth methods she supports. > In the same message there was some discussion on this topic and > suggestion to use CertRequest Payload for that purpose. Unfortunately, > it hasn't been done. Why? Are there strong objections against it? I'm not convinced this is useful. It is only useful when one side can use more than one set of credentials to authenticate and can't figure out which the other side would prefer based on the CERTREQ. If we were to support such a capability, my preference would be to put it in a NOTIFY payload that the other end would be free to ignore if it didn't want to support this case. I don't think there were strong objections last time around, but neither did I hear a groundswell of support. As I noted then, this could easily be added to the protocol later in a backward compatible way if we discovered we needed 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@lists.tislabs.com Sun Mar 9 20:59:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A4xW314452; Sun, 9 Mar 2003 20:59:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13741 Sun, 9 Mar 2003 23:28:17 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200303100431.h2A4VUJ12268@sydney.East.Sun.COM> Date: Sun, 9 Mar 2003 23:31:38 -0500 To: Reply-To: Subject: RE: QoS and IKEv2 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 "Jesse Alpert" wrote: >Again, it seems to me it might be easier to explicitly include this (PHB) >information in the TS payload. This requires modifications to the IKEv2 >draft. > >Thanks again, >Jesse > > Thank you for noticing that, Jesse. The problem (to summarize without diffserv acronyms) is that IKEv2 says that two child-SAs with the same traffic selectors are redundant, and extra ones should be closed. But it also says that you might want several between the same endpoints with the same traffic selectors for different QOS. I'd propose that there should be some way to create multiple SAs with the same traffic selectors, and that it's not necessary to negotiate what QOS things go over which ones. It's up to the sender to decide that. And there might in the future be other reasons to create multiple SAs and we wouldn't be able to tell the difference based solely on the fields in the traffic selector (protocol type, address, and port). So I'd propose one more field in the traffic selector for "uniquifier". Alice can create multiple child-SAs to Bob with the same traffic selectors, as long as they have different uniquifiers. The only function of the uniquifier is so that the multiple SAs won't look redundant to Bob. Which traffic gets sent over which SA is up to the sender. Radia From owner-ipsec@lists.tislabs.com Sun Mar 9 21:22:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A5Mq314789; Sun, 9 Mar 2003 21:22:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13828 Sun, 9 Mar 2003 23:56:33 -0500 (EST) Message-ID: <007f01c2e6c2$04ae4950$cb06b684@isl.mei.co.jp> From: "Atsuhiro Tsuji" To: Cc: , , "'Atsuhiro Tsuji'" References: Subject: Re: SPI in Delete Payload of IKE / IKEv2 Date: Mon, 10 Mar 2003 14:00:49 +0900 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear, Mr. Kaufman, Thank you for your pointing it out and giving comments. Actually, I sent another mail and asked the difference between v1 and v2. Message-id: <001001c2e6a3$a5f8f810$cb06b684@isl.mei.co.jp> Date: Mon, 10 Mar 2003 10:23:25 +0900 From: "Atsuhiro Tsuji" To: "Yoav Nir" , ipsec@lists.tislabs.com Cc: "'Atsuhiro Tsuji'" References: <000601c2e61a$326fef90$292e1dc2@YnirNew> Subject: Re: SPI in Delete Payload of IKE / IKEv2 And the points to be discussed are: 1. If we don't change the payload format, which direction's IPsec SA should we sent for Delete Payload? 2. Shouldn't we add the field which indicates the direction? I understand the INFORMATIONAL Exchange of IKEv2 : Closing SA. So the 2nd point may not be needed, but I dared to list it up. About the 1st point, let me summery the cases. Case (a) : Outbound IPsec SA for Delete Payload That will mean: "I don't send anymore with this IPsec SA, so you don't have to maintain the corresponding Inbound IPsec SA." And all packets before the deletion of the peer Inbound IPsec SA can be received. Case (b) : Inbound IPsec SA for Delete Payload That will mean: "I deleted this IPsec SA, so please don't send anymore with the corresponding Outbound IPsec SA." And some packets may drop since my deletion of Inbound SA to his deletion of Outbound SA. Which is the specification, and which is better? And how is everyone implementing for IKEv1? By the way, I found a IPsec BOX which sends Delete Payload for both Inbound and Outbound IPsec SAs. One of the persons who are selling it said, "Our BOX manages SPI so that they are unique for both direction. So we can know which direction they are." But if the opposite IKE isn't theirs, .....oops. Sincerely yours, Atsuhiro Tsuji ----- Original Message ----- From: To: "Atsuhiro Tsuji" Cc: ; ; "'Atsuhiro Tsuji'" Sent: Monday, March 10, 2003 11:24 AM Subject: Re: SPI in Delete Payload of IKE / IKEv2 > Note: this exchange has uncovered an unintended difference between IKEv1 > and IKEv2. Question for the list: should I change IKEv2 to match (assuming > it's true that IKEv1 works as described). > > "Yoav Nir" wrote: > > Hi, > > > > You send a Delete-SA to stop the peer from using that SA. The IPsec SA > is > > outbound for the peer, but inbound for you. > > > > If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B > > sends packets with SPI 49. If A wants this traffic to stop, he sends B a > > Delete payload with the SPI field 49. > > > > To stop transmissions on SPI 17, A needs not send out anything. It is > > enough that he stops using it. It might have been nice to also be able > to > > tell peer B that no more traffic will come with SPI 17, so that peer B > has > > an easier time dropping fake packets, but this is not in the spec. > > > > Hope this helps. > > > > Yoav Nir > > > "Atsuhiro Tsuji" wrote: > > Thank you for your telling me the spec. of Delete Payload. > > I understand that is reasonable under the current spec. > > > > By the way, I wonder you don't mind that you tell me where the spec. > > is written. > > For IKEv2 (draft-ietf-ipsec-ikev2-05.txt), the processing is described in > Section 3.11: Delete Payload. It says: > > "Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but no > SPIs. Deletion of a CHILD-SA, such as ESP or AH, will contain the > Protocol-Id of that protocol (1 for ESP, 2 for AH) and the SPI is the SPI > the sending endpoint would place in outbound ESP or AH packets." > > So in IKEv2, you identify the SA to delete by the SPI chosen by the other > end. Apparently in IKEv1, it was identified by the SPI chosen by you. > > > On the other hand, > > I think it is useful we can tell the deletion of the outbound SA to the > peer, > > and I wonder why don't we specify it... > > Because "Simple is Best."? > > Have anyone discussed this? > > For IKEv2, this is discussed in section 1.4 The INFORMATIONAL Exchange. The > ESP SAs in the two directions MUST be closed together. When you get a > request to close one side, you MUST close the other (unless it's already > closed in an unlikely race condition where both ends decide to close the > SAs simultaneously). > > I don't know how this was handled in IKEv1. > > --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@lists.tislabs.com Mon Mar 10 01:28:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A9S4314159; Mon, 10 Mar 2003 01:28:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA14504 Mon, 10 Mar 2003 03:55:02 -0500 (EST) Message-ID: <3E6C53BC.90709@f-secure.com> Date: Mon, 10 Mar 2003 10:58:36 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: Francis Dupont , Andrew Krywaniuk , Derek Atkins , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2003 08:58:38.0384 (UTC) FILETIME=[3D844B00:01C2E6E3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com wrote: > > > > Francis Dupont wrote: > >>Please read the NAT-DETECTION-*-IP stuff and say whether you are happy >>with it (I am *not*)? > > > Please do, everyone. I tried to copy the philosophy of the NAT-T documents > into IKEv2, but I may have gotten it wrong and the documents I copied may > have been wrong. Proofreading by people knowledgeable in this space is > vital. > > For example, I was just rereading ESP encapsulation and it is different > than I remembered and different than what I wrote in IKEv2-05. It's a > detail, but it's important. How does a packet sent to UDP port 4500 get > identified as ESP or IKE. What I remember (and wrote) was that IKE messages > have four bytes of zero prepended and ESP SPIs are not allowed to be zero. > This leads to no overhead for ESP and 4 bytes for IKE. But reading > draft-ietf-udp-encaps-01.txt (April 2002), it calls for eight bytes of zero > prepended to ESP packets and IKE SPIs are not allowed to be zero. This > results in no overhead for IKE packets and 8 bytes for ESP. Did this change > somewhere along the line, and if so which proposal won? Either design > works, but they can't be mixed on a single port. Yes, most of the design decisions have changed at least a couple of times, along the line. That's a long line too. You should be reading the latest documents like this http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt > > >> I do think that NAT-T support should be required. >> >>=> I have no objection but: >> - configuration must have a knob to disable NAT-T support >> - NAT detection must be secure. >> >> You never know when there will be a NAT between you and your peer. >> >>=> I agree but there are some cases where you don't want to support >>a NAT between you and your peer. > > > Currently ikev2-05 says that NAT support is optional in an IKE > implementation. There are other statements that could be made. It could say > that implementations MUST support NAT-T but that it MAY be configured off. > It could say that if an implementation supports NAT-T, then it MUST have a > configuration switch to turn it off. > > I don't have strong feelings. My priorities are keeping the MUST features > minimal while assuring that any two implementations with the MUST features > can be configured to interoperate. How important is it for everyone to > support NAT-T? I'd say the MUST part is recognizing NAT-T related payloads and being able say to the other guy that no-NAT-T-spoken here. I'd also like there to be no VIDs for that purpose, so you'd be able to put NAT-T payloads in whatever message is most suitable. Still, I'd say that it would be highly desirable for IKEv2 to just work in spite of NATs. As to the details, I think I'll pass that. I just don't have time/interest to do that, and I'd just get some part wrong. 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@lists.tislabs.com Mon Mar 10 03:05:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AB5N323295; Mon, 10 Mar 2003 03:05:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA14701 Mon, 10 Mar 2003 05:35:53 -0500 (EST) Message-Id: <200303101039.h2AAd3of019316@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: "Andrew Krywaniuk" , Derek Atkins , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of Sun, 09 Mar 2003 20:13:07 EST. Date: Mon, 10 Mar 2003 11:39:03 +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: > Please read the NAT-DETECTION-*-IP stuff and say whether you are happy > with it (I am *not*)? Please do, everyone... => the first thing I don't understand is why they are in the first two messages... Currently ikev2-05 says that NAT support is optional in an IKE implementation. There are other statements that could be made. It could say that implementations MUST support NAT-T but that it MAY be configured off. It could say that if an implementation supports NAT-T, then it MUST have a configuration switch to turn it off. => I really like the last thing (a mandatory config knob to turn NAT-T off when it is supported). How important is it for everyone to support NAT-T? => I don't believe a MUST support is a good idea because this makes no sense for an IPv6 implementation. > => yes but the current draft does the NAT detection in the only unsecured > IKE messages, i.e, too soon! The current draft does NAT detection in the first two messages, => this is a point I don't understand the reason of. which are not directly cryptographically protected. They are indirectly protected, however, because MACs of the first two messages are included in subsequent messages. So someone faking out the NAT detection messages would not successfully set up an SA. => I prefer direct protection. For instance, it makes the caching of NAT detection (the only way to reach an initial responder behind a NAT) far easier to code safely. > The sequence would go something like this: > > gateway receives new UDP port #/IP > #1 sends notify to old UDP port #/IP, > indicating that it thinks it should change > #2 sends notify to new UDP port #/IP, > indicating that it thinks it is time to rekey I think you're assuming a feature in the protocol that's not there. => IMHO Michael assumed an implicit peer address update mechanism which is very common in NAT-T context. There is no way specified to change the UDP port # / IP address of an existing SA. The assumption is that if the NAT changes the translation of ports and addresses in the middle of the SA, packets in at least one direction will stop being delivered and the SA will fail (by timing out). => this is why the peer address update mechanism is used. And it is not unsecure, in fact, one can argue it improves security. One or both endpoints MAY then try to open a new SA with the new addresses and ports. => only the endpoint behind the NAT can. And this is really painful. Note that rekeying doesn't really solve the issue because the NAT is by definition out of control: it can change mappings when it likes and of course never sends notifications to its victims. Something missing from the spec in general is how often to retry failed SAs and whether to retry immediately when one fails. One could imagine some really bad strategies (from a performance point of view). I thought it unnecessary to specify it because it does not affect interoperability and prescribing such behavior requires that we agree on what it should be. But some "implementer's hints" would probably be a good idea. => I disagree, in the case of NAT-T the solution *is* to implement an implicit peer address update mechanism. If we were to support address and port changes in the middle of an SA, there would be possible attacks of the sort you describe => these attacks are possible as soon as the NAT-T feature is active. So the implicit mechanism must be enabled only in this case. and we should try to defend against them. => with NAT-T the best defense is the implicit mechanism: it opens a race between the attacker and the peer behind the NAT, the attacker has to stay on the path, i.e., it becomes an ordinary rogue NAT. But is there really a need? TCP connections fail if addresses and ports change in the middle of a connection. => we never assumed that the tunnel mode is no more used (:-). The endpoints are expected to start over. With Mobile-IP, this may be a common case, so perhaps they have to deal with it. But do we? => the two other common cases where an address management is needed, mobility and multi-homing, need an explicit mechanism with peer address protection. Today, there is a very inefficient explicit mechanism, rekeying, and still no good way to protect peer addresses. Thanks Francis.Dupont@enst-bretagne.fr PS: I noted I have to add a protection against long term bidding down attacks for NAT-T in my draft. The text will be something like: In order to avoid a bidding down attack, the implicit mechanism MUST verify the presence of a NAT on the path, i.e., the new peer address MUST be checked against the peer address in the corresponding peer address notification. NOTE: what to do when they match? PPS: has someone a good idea about the note? From owner-ipsec@lists.tislabs.com Mon Mar 10 09:26:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AHQe318175; Mon, 10 Mar 2003 09:26:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15333 Mon, 10 Mar 2003 11:40:36 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C9EA@corpmx14.us.dg.com> To: radia.perlman@sun.com, ipsec@lists.tislabs.com Subject: RE: QoS and IKEv2 Date: Mon, 10 Mar 2003 11:27:30 -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 Radia and Jesse, Comments embedded ... Thanks, --David > >Again, it seems to me it might be easier to explicitly include this (PHB) > >information in the TS payload. This requires modifications to the IKEv2 > >draft. > > > >Thanks again, > >Jesse > > Thank you for noticing that, Jesse. The problem (to summarize > without diffserv acronyms) is that IKEv2 says that two > child-SAs with the same traffic selectors are redundant, > and extra ones should be closed. But it also says that > you might want several between the same endpoints with > the same traffic selectors for different QOS. > > I'd propose that there should be some way to create > multiple SAs with the same traffic selectors, and > that it's not necessary to negotiate what QOS things > go over which ones. It's up to the sender to > decide that. And there might in the future be > other reasons to create multiple SAs and > we wouldn't be able to tell the difference > based solely on the fields in the traffic > selector (protocol type, address, and port). Part of the sender deciding that might involve some sort of QoS protocol or protocol feature run through the SA to get some sort of agreement between the ends. Two examples are RSVP using the DCLASS object (RFC 2996) and L2TP using its DiffServ Extension (RFC 3308); these function in somewhat different fashions to achieve similar ends. This functional difference is among the reasons for keeping IKE out of this QoS negotiation area. Some discussion of leaving QoS negotiation and the like to protocols that run through the CHILD SA after it's been created would be a good thing for the IKEv2 draft, including these two examples. > So I'd propose one more field in the traffic > selector for "uniquifier". Alice can create > multiple child-SAs to Bob with the same > traffic selectors, as long as they have different > uniquifiers. > > The only function of the uniquifier is so that > the multiple SAs won't look redundant to Bob. > Which traffic gets sent over which SA is up > to the sender. > > Radia From owner-ipsec@lists.tislabs.com Mon Mar 10 11:38:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJc1324334; Mon, 10 Mar 2003 11:38:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15750 Mon, 10 Mar 2003 13:56:39 -0500 (EST) To: Francis Dupont Cc: Charlie_Kaufman@notesdev.ibm.com, "Andrew Krywaniuk" , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: bidding down attach on NAT-T References: <200303101039.h2AAd3of019316@givry.rennes.enst-bretagne.fr> Date: 10 Mar 2003 13:54:12 -0500 In-Reply-To: <200303101039.h2AAd3of019316@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > How important is it for everyone to support NAT-T? > > => I don't believe a MUST support is a good idea because this makes no > sense for an IPv6 implementation. Can we agree on "MUST support NAT-T if you support IPv4"? If you ONLY support v6, then NAT-T can be relegated to a SHOULD or MAY. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Mar 10 11:47:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJlm325261; Mon, 10 Mar 2003 11:47:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15764 Mon, 10 Mar 2003 14:13:56 -0500 (EST) To: Dan Harkins Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> Date: 10 Mar 2003 14:08:56 -0500 In-Reply-To: <200303061917.h26JH1ma000279@fatty.lounge.org> Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > already seeing. IKEv2-02 also had the complex ANDing and ORing that I > think we should get rid of. Why not just have a single SA payload that > contains TLVs for each of the necessary attributes? Multiple occurances > of an attribute mean "I'll do either" (as it was in IKEv2-02 even though > I doubt that would be used much if ever). While I agree with everything else you said about 02 vs 05 (cut from this reply), I do need to add that the one argument I heard that implies AND and OR are necessary in an a la carte system is for hardware deployments that support multiple algorithms but NOT in arbitrary combinations. For example, a hardware implementation that ONLY supports 3DES with MD5, or AES with SHA-1... Granted, this is probably a rare occurance, but I've heard this argument from a few people over the years so I have no reason to ignore it. In order to support this architecture you need some mechanism to negotiate pseudo-suites. It's rare, and obviously in a software implementation you don't need to worry about it. However if we wish to support specialized hardware implementations we do kind of need this mechanism. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Mar 10 13:24:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ALO9302109; Mon, 10 Mar 2003 13:24:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16038 Mon, 10 Mar 2003 15:52:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15980.64456.752003.222139@pkoning.dev.equallogic.com> Date: Mon, 10 Mar 2003 15:55:36 -0500 From: Paul Koning To: derek@ihtfp.com Cc: dharkins@tibernian.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> Dan Harkins writes: >> already seeing. IKEv2-02 also had the complex ANDing and ORing >> that I think we should get rid of. Why not just have a single SA >> payload that contains TLVs for each of the necessary attributes? >> Multiple occurances of an attribute mean "I'll do either" (as it >> was in IKEv2-02 even though I doubt that would be used much if >> ever). Derek> While I agree with everything else you said about 02 vs 05 Derek> (cut from this reply), I do need to add that the one argument Derek> I heard that implies AND and OR are necessary in an a la carte Derek> system is for hardware deployments that support multiple Derek> algorithms but NOT in arbitrary combinations. For example, a Derek> hardware implementation that ONLY supports 3DES with MD5, or Derek> AES with SHA-1... Derek> Granted, this is probably a rare occurance, but I've heard Derek> this argument from a few people over the years so I have no Derek> reason to ignore it. I wonder: is this still a real issue today? It would be good not to add messes to the protocol to support strange hardware architectures that are long obsolete. Certainly this issue doesn't appear in any hardware I have ever seen. (Come to think of it, if I saw this when doing device selection, I'd be very tempted to exclude such a device.) paul From owner-ipsec@lists.tislabs.com Mon Mar 10 15:17:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ANH9307681; Mon, 10 Mar 2003 15:17:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16306 Mon, 10 Mar 2003 17:46:21 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <200303061917.h26JH1ma000279@fatty.lounge.org> 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, 10 Mar 2003 14:11:19 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:08 PM -0500 3/10/03, Derek Atkins wrote: >Dan Harkins writes: > >> already seeing. IKEv2-02 also had the complex ANDing and ORing that I >> think we should get rid of. Why not just have a single SA payload that >> contains TLVs for each of the necessary attributes? Multiple occurances >> of an attribute mean "I'll do either" (as it was in IKEv2-02 even though >> I doubt that would be used much if ever). > >While I agree with everything else you said about 02 vs 05 (cut from >this reply), I do need to add that the one argument I heard that >implies AND and OR are necessary in an a la carte system is for >hardware deployments that support multiple algorithms but NOT in >arbitrary combinations. For example, a hardware implementation that >ONLY supports 3DES with MD5, or AES with SHA-1... One of the early goals for IKEv2 was simplicity. Doing AND and OR moves sharply away from that. Dan's proposal above would be much simpler to implement. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 10 15:38:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ANc6308235; Mon, 10 Mar 2003 15:38:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16366 Mon, 10 Mar 2003 18:04:43 -0500 (EST) To: Paul Koning Cc: derek@ihtfp.com, dharkins@tibernian.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> <15980.64456.752003.222139@pkoning.dev.equallogic.com> Reply-To: EKR From: Eric Rescorla Date: 10 Mar 2003 15:13:08 -0800 In-Reply-To: <15980.64456.752003.222139@pkoning.dev.equallogic.com> Message-ID: Lines: 21 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 Koning writes: > I wonder: is this still a real issue today? It would be good not to > add messes to the protocol to support strange hardware architectures > that are long obsolete. Certainly this issue doesn't appear in any > hardware I have ever seen. (Come to think of it, if I saw this when > doing device selection, I'd be very tempted to exclude such a device.) It's generally not an issue of individual pieces of hardware but of what happens when you have an implementation based on multiple CSP-like modules. Say, for the sake of argument that you have a piece of hardware that processes single IPsec records and supports 3DES and SHA. You then add another CSP that supports AES and MD5. You can't necessarily mix and match here, so you need to provide profiles. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Mar 10 15:44:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ANi3308403; Mon, 10 Mar 2003 15:44:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16402 Mon, 10 Mar 2003 18:16:02 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15981.7487.502193.596127@pkoning.dev.equallogic.com> Date: Mon, 10 Mar 2003 18:18:23 -0500 From: Paul Koning To: ekr@rtfm.com Cc: derek@ihtfp.com, dharkins@tibernian.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> <15980.64456.752003.222139@pkoning.dev.equallogic.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Eric" == Eric Rescorla writes: Eric> Paul Koning writes: >> I wonder: is this still a real issue today? It would be good not >> to add messes to the protocol to support strange hardware >> architectures that are long obsolete. Certainly this issue >> doesn't appear in any hardware I have ever seen. (Come to think >> of it, if I saw this when doing device selection, I'd be very >> tempted to exclude such a device.) Eric> It's generally not an issue of individual pieces of hardware Eric> but of what happens when you have an implementation based on Eric> multiple CSP-like modules. Eric> Say, for the sake of argument that you have a piece of hardware Eric> that processes single IPsec records and supports 3DES and SHA. Eric> You then add another CSP that supports AES and MD5. You can't Eric> necessarily mix and match here, so you need to provide Eric> profiles. Sure, you can suppose such things, but are they real? That's my point. I can't think of real hardware that matches your supposition. paul From owner-ipsec@lists.tislabs.com Mon Mar 10 15:45:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ANjX308446; Mon, 10 Mar 2003 15:45:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16414 Mon, 10 Mar 2003 18:19:07 -0500 (EST) To: Paul Koning Cc: derek@ihtfp.com, dharkins@tibernian.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> <15980.64456.752003.222139@pkoning.dev.equallogic.com> <15981.7487.502193.596127@pkoning.dev.equallogic.com> Reply-To: EKR From: Eric Rescorla Date: 10 Mar 2003 15:27:29 -0800 In-Reply-To: <15981.7487.502193.596127@pkoning.dev.equallogic.com> Message-ID: Lines: 32 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 Koning writes: > >>>>> "Eric" == Eric Rescorla writes: > > Eric> Paul Koning writes: > >> I wonder: is this still a real issue today? It would be good not > >> to add messes to the protocol to support strange hardware > >> architectures that are long obsolete. Certainly this issue > >> doesn't appear in any hardware I have ever seen. (Come to think > >> of it, if I saw this when doing device selection, I'd be very > >> tempted to exclude such a device.) > > Eric> It's generally not an issue of individual pieces of hardware > Eric> but of what happens when you have an implementation based on > Eric> multiple CSP-like modules. > > Eric> Say, for the sake of argument that you have a piece of hardware > Eric> that processes single IPsec records and supports 3DES and SHA. > Eric> You then add another CSP that supports AES and MD5. You can't > Eric> necessarily mix and match here, so you need to provide > Eric> profiles. > > Sure, you can suppose such things, but are they real? That's my > point. I can't think of real hardware that matches your supposition. What, you can't think of real hardware that doesn't support AES? How about the HiFn 7811? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Mar 10 16:25:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B0Pf309698; Mon, 10 Mar 2003 16:25:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16587 Mon, 10 Mar 2003 18:53:12 -0500 (EST) Message-ID: <3E6D2642.3B1BEDBE@airespace.com> Date: Mon, 10 Mar 2003 15:56:50 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: derek@ihtfp.com, dharkins@tibernian.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> <15980.64456.752003.222139@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2003 23:56:06.0239 (UTC) FILETIME=[9D56E6F0:01C2E760] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Paul - I've evaluated and used a number of crypto processors in the last few years, and I don't think any of them had this limitation, and I think Paul is right that spec'ing around such behavior is probably not required (or a good idea). Scott Paul Koning wrote: > > >>>>> "Derek" == Derek Atkins writes: > > Derek> Dan Harkins writes: > >> already seeing. IKEv2-02 also had the complex ANDing and ORing > >> that I think we should get rid of. Why not just have a single SA > >> payload that contains TLVs for each of the necessary attributes? > >> Multiple occurances of an attribute mean "I'll do either" (as it > >> was in IKEv2-02 even though I doubt that would be used much if > >> ever). > > Derek> While I agree with everything else you said about 02 vs 05 > Derek> (cut from this reply), I do need to add that the one argument > Derek> I heard that implies AND and OR are necessary in an a la carte > Derek> system is for hardware deployments that support multiple > Derek> algorithms but NOT in arbitrary combinations. For example, a > Derek> hardware implementation that ONLY supports 3DES with MD5, or > Derek> AES with SHA-1... > > Derek> Granted, this is probably a rare occurance, but I've heard > Derek> this argument from a few people over the years so I have no > Derek> reason to ignore it. > > I wonder: is this still a real issue today? It would be good not to > add messes to the protocol to support strange hardware architectures > that are long obsolete. Certainly this issue doesn't appear in any > hardware I have ever seen. (Come to think of it, if I saw this when > doing device selection, I'd be very tempted to exclude such a device.) > > paul From owner-ipsec@lists.tislabs.com Mon Mar 10 17:04:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B14P310789; Mon, 10 Mar 2003 17:04:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16735 Mon, 10 Mar 2003 19:38:13 -0500 (EST) Date: Tue, 11 Mar 2003 02:41:28 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: comments on ikev2 05 (cryptography) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In answer to your discussion below: The exponent was set to 160 bits since the best attacks that are known against DH keys that use exponents of length t bits (and when the order of the DH group is a Sophie-Germain prime, i.e. a prime of the form 2q+1 for prime q) are of complexity 2^(t/2). Since Oakley (and then IKEv1 and now IKEv2) specifies groups of Sophie-Germain prime order, then an exponent of 160 bits will give you security of (at most) 2^80. This was considered sufficient at the time of publishing the ikev1 rfc. Now people seem concerned with strengths of 2^128, and there is a popular belief that you should not do anything that allows attacks under 2^90 operations. If so, 160 bits (or attack complexity of 2^80 or less) are not sufficent. Moreover, the use of 160 bits assumes that no (even small) improvement on cryptanalytical methods will happen. And there is the (implicit) assumption that all implementations will use the standard groups, or non-standard groups of Sophie-Germain prime order (an assumption that is not specified anywhere in IKE v1/v2). Note that if one uses regular primes, say a random prime of the required length, then we ALREADY know of attacks better than the 2^(t/2) bound (i.e better than 2^80 with exponents of length 160) [van Oorschot-Wiener, ca 1995]. Moreover, the "square root attacks" (such as lambda or shanks) are parallelizable, making their 2^80 complexity not immediately practical but certainly weaker than anything people are advocating for ikev2/ipsec. Hugo On Sun, 9 Mar 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > "Andrew Krywaniuk" wrote: > > I seem to remember from Hillarie's earlier paper on key sizes that the > size > > of the exponent is not the dominant factor that contributes to the > strength > > of the DH exchange. When you increase the modulus from 1024 bits to 2048 > > bits, you now have to do 2048 bit multiplies instead of 1024 bit > multiples > > and that also involves a lot more memory reads. The order of this effect > is > > sub-exponential, but still very significant. > > > > Could this be why the exponent size was set to 160? > > Yes. > > Generally, when doing Diffie-Hellman exchanges, the exponent size can be > substantially smaller than the modulus size without losing security. There > is a substantial performance gain by doing so. The only question is what > the appropriate size exponent is to match a 1024 bit modulus. The text said > 160, but Hugo suggested that 180 or 200 would be more appropriate. I'm > certainly willing to take his word for it. For a 2048 bit modulus, the > exponent size would be bigger, but no where near double. There's probably a > table in some cryptographer's handbook somewhere. > > --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@lists.tislabs.com Mon Mar 10 17:21:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B1L3311115; Mon, 10 Mar 2003 17:21:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16784 Mon, 10 Mar 2003 19:51:37 -0500 (EST) Date: Tue, 11 Mar 2003 02:54:34 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG , owner-ipsec@lists.tislabs.com Subject: Re: comments on ikev2 05 (cryptography) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Hanson's Razor: Never ascribe to malice that which can be adequately > explained by incompetence. I didn't convince myself, nor did anyone > convince me. I just made the changes to the spec from memory and got it > wrong. I've fixed it in the draft I'm working on. I am glad to see that the discrepancy between 05 and my earlier sugestions was a simple oversight. If you need contribution of text on these issues please let me know. As for a pointer to the SIGMA paper, the current version can be referred to as Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", Nov. 2002. http://www.ee.technion.ac.il/~hugo/sigma.html When I'll have a complete version I will post it in a broadly accesible repository (probably the eprint archive of the iacr). This will certainly happen before ikev2 goes for rfc... Hugo From owner-ipsec@lists.tislabs.com Mon Mar 10 18:54:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B2sA314127; Mon, 10 Mar 2003 18:54:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17080 Mon, 10 Mar 2003 21:18:27 -0500 (EST) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> Date: 10 Mar 2003 21:21:44 -0500 In-Reply-To: Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 2:08 PM -0500 3/10/03, Derek Atkins wrote: > >Dan Harkins writes: > > > >> already seeing. IKEv2-02 also had the complex ANDing and ORing that I > >> think we should get rid of. Why not just have a single SA payload that > >> contains TLVs for each of the necessary attributes? Multiple occurances > >> of an attribute mean "I'll do either" (as it was in IKEv2-02 even though > >> I doubt that would be used much if ever). > > > >While I agree with everything else you said about 02 vs 05 (cut from > >this reply), I do need to add that the one argument I heard that > >implies AND and OR are necessary in an a la carte system is for > >hardware deployments that support multiple algorithms but NOT in > >arbitrary combinations. For example, a hardware implementation that > >ONLY supports 3DES with MD5, or AES with SHA-1... > > One of the early goals for IKEv2 was simplicity. Doing AND and OR > moves sharply away from that. Dan's proposal above would be much > simpler to implement. That's fine. I have no specific, personal objection to leaving out the AND and OR functionality. I was just pointing out that there were reasonable reasons to have such functionality. If we DO decide to leave it out in the name of simplicity we should at least add some text that shows that we thought about this issue. I would propose something like: Certain hardware architectural implementations may only support limited combinations of algorithms. For example, a piece of hardware may only support 3DES+MD5 or AES+SHA1, but there is no way to actually negotiate for one or the other combinations. The working group acknowledges this limitation, but decided in favor of the simplicity of ruling out such architectures. > --Paul Hoffman, Director > --VPN Consortium -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Mon Mar 10 20:37:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B4bx317124; Mon, 10 Mar 2003 20:37:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17309 Mon, 10 Mar 2003 23:09:08 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <007f01c2e6c2$04ae4950$cb06b684@isl.mei.co.jp> Subject: Re: SPI in Delete Payload of IKE / IKEv2 To: "Atsuhiro Tsuji" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Mon, 10 Mar 2003 22:12:26 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/10/2003 11:12:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe the right thing to do at this point is to change the IKEv2 spec to match the IKEv1 behavior as deployed. The change was unintentional, and based on my misunderstanding of the arguably ambiguous text in IKEv1. In particular, to change: >the SPI [in the DELETE payload] is the SPI the sending >endpoint would place in outbound ESP or AH packets. to: >the SPI is the SPI the sending endpoint would expect >in inbound ESP or AH packets. does anyone object? "Yoav Nir" wrote: > The Informational exchange with the delete payload has been used to correct > situations where you receive packets encrypted with an IPsec SA that you do > not recognize. Suppose you get a packet with an SPI value you don't > recognize (for example, after you reboot) you can send a delete to the peer, > to make it stop sending. I would claim this is incorrect behavior in IKEv2. There is a NOTIFY error code "INVALID-SPI" specifically for this case. I would claim it was a protocol violation to close an SA that you don't know is open. The spec doesn't say what to do if it receives a request to close a nonexistent SPI. I can imagine anything from ignoring it to logging it to closing the IKE-SA. I don't believe the spec needs to say because it's not an interoperability issue. "Atsuhiro Tsuji" wrote: > About the 1st point, let me summery the cases. > > Case (a) : Outbound IPsec SA for Delete Payload > > That will mean: > "I don't send anymore with this IPsec SA, so you don't have to > maintain the corresponding Inbound IPsec SA." > And all packets before the deletion of the peer Inbound IPsec SA > can be received. > > Case (b) : Inbound IPsec SA for Delete Payload > > That will mean: > "I deleted this IPsec SA, so please don't send anymore with > the corresponding Outbound IPsec SA." > And some packets may drop since my deletion of Inbound SA > to his deletion of Outbound SA. The current spec requires that the SAs in the two directions be opened and closed together, so I don't believe there is any advantage to being able to specify either SPI. If I send a notification to delete the pair, I promise not to send any additional packets on the outbound SA and once sent the sender is free to discard any subsequent packets arriving on the inbound SA. Because of packet reordering on the network, it is possible that packets will arrive on an SA after it is deleted. These packets should be discarded, though I don't believe any harm is done if an implementation accepts them late. --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@lists.tislabs.com Mon Mar 10 21:47:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B5lu318516; Mon, 10 Mar 2003 21:47:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17487 Tue, 11 Mar 2003 00:18:06 -0500 (EST) Message-ID: <001601c2e78e$2ae0c0e0$cb06b684@isl.mei.co.jp> From: "Atsuhiro Tsuji" To: , "Atsuhiro Tsuji" , Cc: References: Subject: Re: SPI in Delete Payload of IKE / IKEv2 Date: Tue, 11 Mar 2003 14:22:10 +0900 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mr. Kaufman wrote: "I don't believe there is any advantage to being able to specify either SPI." And I understand that for IKEv2. So only remaining points which I'm concerned are, (1) Finally, does the expression in IKEv1, "the sending entity's SPI(s)", really mean the "Inbound SA" or not? If possible, I would like to get the comments from the editors, too. ==>> I hope Mr. Maughan is checking this mail. :-P (Sorry that I send this mail to Mr. Maughan directly without agreement.) (2) And does everyone agree with that? Some implementers may misunderstand the editor's meanings. The (1) is about the editor's intention, and (2) is about a lot of real products. Maybe, I shouldn't discuss about the real products in this mailing list. If I shoudn't, please kindly point it out. Sincerely yours, Atsuhiro Tsuji > I believe the right thing to do at this point is to change the IKEv2 spec > to match the IKEv1 behavior as deployed. The change was unintentional, and > based on my misunderstanding of the arguably ambiguous text in IKEv1. In > particular, to change: > > >the SPI [in the DELETE payload] is the SPI the sending > >endpoint would place in outbound ESP or AH packets. > > to: > > >the SPI is the SPI the sending endpoint would expect > >in inbound ESP or AH packets. > > does anyone object? > > "Yoav Nir" wrote: > > The Informational exchange with the delete payload has been used to > correct > > situations where you receive packets encrypted with an IPsec SA that you > do > > not recognize. Suppose you get a packet with an SPI value you don't > > recognize (for example, after you reboot) you can send a delete to the > peer, > > to make it stop sending. > > I would claim this is incorrect behavior in IKEv2. There is a NOTIFY error > code "INVALID-SPI" specifically for this case. I would claim it was a > protocol violation to close an SA that you don't know is open. The spec > doesn't say what to do if it receives a request to close a nonexistent SPI. > I can imagine anything from ignoring it to logging it to closing the > IKE-SA. I don't believe the spec needs to say because it's not an > interoperability issue. > > "Atsuhiro Tsuji" wrote: > > About the 1st point, let me summery the cases. > > > > Case (a) : Outbound IPsec SA for Delete Payload > > > > That will mean: > > "I don't send anymore with this IPsec SA, so you don't have > to > > maintain the corresponding Inbound IPsec SA." > > And all packets before the deletion of the peer Inbound IPsec SA > > can be received. > > > > Case (b) : Inbound IPsec SA for Delete Payload > > > > That will mean: > > "I deleted this IPsec SA, so please don't send anymore with > > the corresponding Outbound IPsec SA." > > And some packets may drop since my deletion of Inbound SA > > to his deletion of Outbound SA. > > The current spec requires that the SAs in the two directions be opened and > closed together, so I don't believe there is any advantage to being able to > specify either SPI. If I send a notification to delete the pair, I promise > not to send any additional packets on the outbound SA and once sent the > sender is free to discard any subsequent packets arriving on the inbound > SA. Because of packet reordering on the network, it is possible that > packets will arrive on an SA after it is deleted. These packets should be > discarded, though I don't believe any harm is done if an implementation > accepts them late. > > --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@lists.tislabs.com Mon Mar 10 21:57:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B5v0318692; Mon, 10 Mar 2003 21:57:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17523 Tue, 11 Mar 2003 00:31:16 -0500 (EST) Message-ID: <001501c2e78f$f2c39a00$cb06b684@isl.mei.co.jp> From: "Atsuhiro Tsuji" To: "Atsuhiro Tsuji" , , Cc: References: <001601c2e78e$2ae0c0e0$cb06b684@isl.mei.co.jp> Subject: Re: SPI in Delete Payload of IKE / IKEv2 Date: Tue, 11 Mar 2003 14:34:55 +0900 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.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, Mr. Maughan's mail address seems to have been changed. Please remove his old mail address when you send the reply to my last mail. Thank you. ----- the Last Mail ----- From: "Atsuhiro Tsuji" To: ; "Atsuhiro Tsuji" ; Cc: Sent: Tuesday, March 11, 2003 2:22 PM Message-id: <001601c2e78e$2ae0c0e0$cb06b684@isl.mei.co.jp> Subject: Re: SPI in Delete Payload of IKE / IKEv2 From owner-ipsec@lists.tislabs.com Tue Mar 11 01:23:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B9NS316597; Tue, 11 Mar 2003 01:23:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17899 Tue, 11 Mar 2003 03:52:29 -0500 (EST) Message-Id: <200303110855.h2B8trof023411@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Derek Atkins cc: Charlie_Kaufman@notesdev.ibm.com, "Andrew Krywaniuk" , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of 10 Mar 2003 13:54:12 EST. Date: Tue, 11 Mar 2003 09:55:53 +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: Francis Dupont writes: > How important is it for everyone to support NAT-T? > > => I don't believe a MUST support is a good idea because this makes no > sense for an IPv6 implementation. Can we agree on "MUST support NAT-T if you support IPv4"? => I am not in favor of a MUST which has nothing to do with interoperability, IMHO we should let the market do its job... And I don't believe implementors who still have NAT-T support in their plans like to become not compliant. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 11 01:56:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B9ug319766; Tue, 11 Mar 2003 01:56:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17950 Tue, 11 Mar 2003 04:26:41 -0500 (EST) Message-Id: <200303110930.h2B9ULof023890@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: "Atsuhiro Tsuji" , ipsec@lists.tislabs.com Subject: Re: SPI in Delete Payload of IKE / IKEv2 In-reply-to: Your message of Mon, 10 Mar 2003 22:12:26 EST. Date: Tue, 11 Mar 2003 10:30:21 +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 would claim this is incorrect behavior in IKEv2. There is a NOTIFY error code "INVALID-SPI" specifically for this case. I would claim it was a ... => which INVALID-SPI: there are two defined in the current document (:-)? Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 11 03:56:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BBuB329054; Tue, 11 Mar 2003 03:56:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18249 Tue, 11 Mar 2003 06:14:18 -0500 (EST) From: "Jesse Alpert" To: , Subject: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) Date: Tue, 11 Mar 2003 13:20:31 +0200 Message-ID: <005801c2e7c0$3b2d0b20$7b2e1dc2@jesse> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200303100431.h2A4VUJ12268@sydney.East.Sun.COM> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi again, > So I'd propose one more field in the traffic > selector for "uniquifier". Alice can create I like this "uniquifier" idea. Indeed there may be more reasons for creating apparently redundant IPsec SAs to avoid problems caused by the IPsec replay counter. For instance if one of the peers is a cluster of machines performing load sharing. It may want to establish multiple IPsec SAs with the peer, one for each machine belonging to the cluster. Each 'cluster member' will have its own SA which it can use for outbound traffic. This way the IPsec replay counter does not have to be synchronized between the cluster members. To the non-cluster peer however, these SAs may seem redundant as they share the exact same traffic selectors (The cluster has a single external IP address and the cluster members are not exposed). In this scenario the "uniquifier" will help, since it will indicate that these tunnels are not redundant - they are used by the peer for some (unknown) purpose. Jesse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Radia Perlman - Boston Center for Networking Sent: Monday, March 10, 2003 6:32 AM To: ipsec@lists.tislabs.com Subject: RE: QoS and IKEv2 "Jesse Alpert" wrote: >Again, it seems to me it might be easier to explicitly include this (PHB) >information in the TS payload. This requires modifications to the IKEv2 >draft. > >Thanks again, >Jesse > > Thank you for noticing that, Jesse. The problem (to summarize without diffserv acronyms) is that IKEv2 says that two child-SAs with the same traffic selectors are redundant, and extra ones should be closed. But it also says that you might want several between the same endpoints with the same traffic selectors for different QOS. I'd propose that there should be some way to create multiple SAs with the same traffic selectors, and that it's not necessary to negotiate what QOS things go over which ones. It's up to the sender to decide that. And there might in the future be other reasons to create multiple SAs and we wouldn't be able to tell the difference based solely on the fields in the traffic selector (protocol type, address, and port). So I'd propose one more field in the traffic selector for "uniquifier". Alice can create multiple child-SAs to Bob with the same traffic selectors, as long as they have different uniquifiers. The only function of the uniquifier is so that the multiple SAs won't look redundant to Bob. Which traffic gets sent over which SA is up to the sender. Radia From owner-ipsec@lists.tislabs.com Tue Mar 11 05:34:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BDYn307682; Tue, 11 Mar 2003 05:34:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18565 Tue, 11 Mar 2003 08:04:46 -0500 (EST) Date: Tue, 11 Mar 2003 15:08:28 +0200 Message-Id: <200303111308.h2BD8SEp004934@burp.tkv.asdf.org> From: Markku Savela To: jalpert@CheckPoint.com CC: radia.perlman@sun.com, ipsec@lists.tislabs.com In-reply-to: <005801c2e7c0$3b2d0b20$7b2e1dc2@jesse> (jalpert@CheckPoint.com) Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) References: <005801c2e7c0$3b2d0b20$7b2e1dc2@jesse> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just stirring the soup, food for thought... > From: "Jesse Alpert" > > In this scenario the "uniquifier" will help, since it will indicate that > these tunnels are not redundant - they are used by the peer for some > (unknown) purpose. SPI itself is already "uniquifier". Maybe the problem is not here, but instead in the definition of what is "redundant"? Perhaps it should be changed, remove the following from spec: > ... is that IKEv2 says that two child-SAs with the same traffic > selectors are redundant, and extra ones should be closed. ..especially the "should be closed part". The same thing that would decide whether to include "uniquifier", could also decide whether to issue DELETE's for the "redundant SA" or not. From owner-ipsec@lists.tislabs.com Tue Mar 11 06:04:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BE4J308636; Tue, 11 Mar 2003 06:04:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18653 Tue, 11 Mar 2003 08:34:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15981.59050.591928.626821@pkoning.dev.equallogic.com> Date: Tue, 11 Mar 2003 08:37:46 -0500 From: Paul Koning To: ekr@rtfm.com Cc: derek@ihtfp.com, dharkins@tibernian.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> <15980.64456.752003.222139@pkoning.dev.equallogic.com> <15981.7487.502193.596127@pkoning.dev.equallogic.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Eric" == Eric Rescorla writes: Eric> Paul Koning writes: >> >>>>> "Eric" == Eric Rescorla writes: >> Eric> Paul Koning writes: >> >> I wonder: is this still a real issue today? It would be good >> not >> to add messes to the protocol to support strange hardware >> >> architectures that are long obsolete. Certainly this issue >> >> doesn't appear in any hardware I have ever seen. (Come to think >> >> of it, if I saw this when doing device selection, I'd be very >> >> tempted to exclude such a device.) >> Eric> It's generally not an issue of individual pieces of hardware Eric> but of what happens when you have an implementation based on Eric> multiple CSP-like modules. >> Eric> Say, for the sake of argument that you have a piece of hardware Eric> that processes single IPsec records and supports 3DES and SHA. Eric> You then add another CSP that supports AES and MD5. You can't Eric> necessarily mix and match here, so you need to provide Eric> profiles. >> Sure, you can suppose such things, but are they real? That's my >> point. I can't think of real hardware that matches your >> supposition. Eric> What, you can't think of real hardware that doesn't support Eric> AES? How about the HiFn 7811? Sure I know about that hardware, but that wasn't your example. You said "3DES and SHA" vs. "AES and MD5". 7811 supports 3DES with either SHA or MD5; later chips support AES with either SHA or MD5. So the choice for authentication function does not affect whether you are able to perform a given encryption algorithm. paul From owner-ipsec@lists.tislabs.com Tue Mar 11 06:41:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEfk310305; Tue, 11 Mar 2003 06:41:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18776 Tue, 11 Mar 2003 09:11:20 -0500 (EST) From: "Yoav Nir" To: "'Markku Savela'" , Cc: , Subject: RE: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) Date: Tue, 11 Mar 2003 16:13:36 +0200 Message-ID: <001601c2e7d8$690da7d0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200303111308.h2BD8SEp004934@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you remove the "should be closed" part you lose the way to delete tunnels which are truely redundant. It is entirely possible to have peer A require several tunnels, while peer B does not. Without a uniquifier, peer A will open several tunnels, and peer B will close all but the last. A uniquifier will allow peer B to know that peer A opened several different tunnels on purpose, rather than by mistake. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Markku Savela Sent: Tuesday, March 11, 2003 3:08 PM To: jalpert@CheckPoint.com Cc: radia.perlman@sun.com; ipsec@lists.tislabs.com Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) Just stirring the soup, food for thought... > From: "Jesse Alpert" > > In this scenario the "uniquifier" will help, since it will indicate that > these tunnels are not redundant - they are used by the peer for some > (unknown) purpose. SPI itself is already "uniquifier". Maybe the problem is not here, but instead in the definition of what is "redundant"? Perhaps it should be changed, remove the following from spec: > ... is that IKEv2 says that two child-SAs with the same traffic > selectors are redundant, and extra ones should be closed. ..especially the "should be closed part". The same thing that would decide whether to include "uniquifier", could also decide whether to issue DELETE's for the "redundant SA" or not. From owner-ipsec@lists.tislabs.com Tue Mar 11 06:42:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEgG310334; Tue, 11 Mar 2003 06:42:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18770 Tue, 11 Mar 2003 09:10:17 -0500 (EST) From: "Jesse Alpert" To: "'Markku Savela'" , Subject: RE: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) Date: Tue, 11 Mar 2003 16:15:42 +0200 Message-ID: <005b01c2e7d8$b3a23720$7b2e1dc2@jesse> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200303111308.h2BD8SEp004934@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Markku, > SPI itself is already "uniquifier". Maybe the problem is not here, but > instead in the definition of what is "redundant"? You are right, and that will probably work as well. However: If I understood correctly, IKEv2 draft was referring to the case where both peers initiate a CHILD-SA exchange almost at once, resulting in two identical IPsec SAs one of which IS redundant. In such a case you would want to close one of the SAs to save on resources. The "uniquifier" can be used to indicate this is not the case. For example, if you are simply creating a new tunnel (or rekeying an existing one) specify 0 for the "uniquifier" value. If, on the other hand, you are opening a 'special' tunnel (identical to one which already exists) to be used for some 'special' purpose (e.g. different QoS level) or rekeying for such a tunnel, then use some non-zero "uniquifier" value. The "uniquifier" is nice since it explicitly states that these apparently identical tunnels are used for different purposes. Another option would be to ignore the (rare?) case of both peers initiating an exchange at once (maybe add some text about using a random jitter) and stating that peers should not assume that two identical tunnels are redundant. Jesse -----Original Message----- From: Markku Savela [mailto:msa@burp.tkv.asdf.org] Sent: Tuesday, March 11, 2003 3:08 PM To: jalpert@CheckPoint.com Cc: radia.perlman@sun.com; ipsec@lists.tislabs.com Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) Just stirring the soup, food for thought... > From: "Jesse Alpert" > > In this scenario the "uniquifier" will help, since it will indicate that > these tunnels are not redundant - they are used by the peer for some > (unknown) purpose. SPI itself is already "uniquifier". Maybe the problem is not here, but instead in the definition of what is "redundant"? Perhaps it should be changed, remove the following from spec: > ... is that IKEv2 says that two child-SAs with the same traffic > selectors are redundant, and extra ones should be closed. ..especially the "should be closed part". The same thing that would decide whether to include "uniquifier", could also decide whether to issue DELETE's for the "redundant SA" or not. From owner-ipsec@lists.tislabs.com Tue Mar 11 06:57:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEvB310816; Tue, 11 Mar 2003 06:57:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18818 Tue, 11 Mar 2003 09:29:32 -0500 (EST) From: Ghislaine Labouret To: ipsec@lists.tislabs.com Subject: IPsec bakeoff in July 2003 confirmed Date: Tue, 11 Mar 2003 14:56:38 +0100 X-Mailer: Forte Agent 1.93/32.576 Francais MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030311135542.DDF7923A78@etheria.labouret.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The organization of an IPsec bakeoff in France, the week after IETF 57 in Vienna, has been confirmed. Registration is now open. Here is the announcement by the organizer, ETSI: ----- Begin Forwarded message ----- From: Philippe Cousin Sent: 06 March 2003 15:30 Subject: Registration for the IPsec interoperability event 21-25 July now open! Dear all, ETSI is pleased to invite you to the IPsec Interoperability Event (21-25 July 2003). The event will take place the week after 57th IETF meeting (Vienna, Austria). Companies with IPsec implementation but also PKI providers are invited to demonstrate interoperability between products in a multi-vendors environment. Tests will be performed with a specific focus on IKEv2. Feedback on generic problems encountered will be published after the event. It is reminded that detailed information during the event are confidential and the event strictly reserved to technical people with products. Marketing and Sales representatives as well as observers are not allowed. All information and registration now open on line can be found at the following link: http://www.etsi.org/plugtests/02UpcomingEvents/IPsec/IPsec_home.htm A mailing list for discussing the technical details and preparing the event is also open and information given in the web site. Look forward having companies successfully progressing together IPsec interoperability at the event. Best regards, Philippe COUSIN Interoperability Service Manager Tel: + 33 (0)4 92 94 4306 Fax: +33 (0)4 92 38 5248 http://www.etsi.org/plugtests/ ----- End Forwarded message ----- From owner-ipsec@lists.tislabs.com Tue Mar 11 07:20:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFKi311973; Tue, 11 Mar 2003 07:20:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18923 Tue, 11 Mar 2003 09:50:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200303100431.h2A4VUJ12268@sydney.East.Sun.COM> References: <200303100431.h2A4VUJ12268@sydney.East.Sun.COM> Date: Tue, 11 Mar 2003 09:51:28 -0500 To: From: Stephen Kent Subject: RE: QoS and IKEv2 Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:31 PM -0500 3/9/03, Radia Perlman - Boston Center for Networking wrote: >"Jesse Alpert" wrote: > >>Again, it seems to me it might be easier to explicitly include this (PHB) >>information in the TS payload. This requires modifications to the IKEv2 >>draft. >> >>Thanks again, >>Jesse >> >> > >Thank you for noticing that, Jesse. The problem (to summarize >without diffserv acronyms) is that IKEv2 says that two >child-SAs with the same traffic selectors are redundant, >and extra ones should be closed. But it also says that >you might want several between the same endpoints with >the same traffic selectors for different QOS. > >I'd propose that there should be some way to create >multiple SAs with the same traffic selectors, and >that it's not necessary to negotiate what QOS things >go over which ones. It's up to the sender to >decide that. And there might in the future be >other reasons to create multiple SAs and >we wouldn't be able to tell the difference >based solely on the fields in the traffic >selector (protocol type, address, and port). > >So I'd propose one more field in the traffic >selector for "uniquifier". Alice can create >multiple child-SAs to Bob with the same >traffic selectors, as long as they have different >uniquifiers. > >The only function of the uniquifier is so that >the multiple SAs won't look redundant to Bob. >Which traffic gets sent over which SA is up >to the sender. Radia, Traffic selectors are values used to map outbound traffic to SAs, based on IP and transport layer header fields. So the notion of a new selector that does not correspond to any header field is not really consistent with the terminology as it has been defined in 2401. I don't disagree with the possible utility of having some way to distinguish among multiple SAs with identical selectors, but first one needs to describe how traffic will be mapped to each one, given that the selector mapping would not otherwise distinguish among them. For inbound traffic, as someone already noted, the SPIs provide the necessary demuxing capability. One possible solution is to use the virtual interface ID (VID) that I proposed adding to 2401bis, to separate route selection from SA selection. I don't recall whether messages on this topic circulated on the list, or if they were just exchanged among a set of folks who were looking at how to better accommodate overlay nets and PPVPN applications. The short description is that we plan to augment the current processing model to include an explicit routing/forwarding lookup, which returns a VID and the VID is used to select the SPD for outbound processing. The VID is kept with the packet after processing, to allow selection of a physical interface or for use in a ciphertext-side lookup table for outer header selection. In a trivial case, where there is just one virtual interface (on the ciphertext side) the VID is constant. Steve From owner-ipsec@lists.tislabs.com Tue Mar 11 07:58:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFw6315176; Tue, 11 Mar 2003 07:58:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19092 Tue, 11 Mar 2003 10:25:18 -0500 (EST) To: Paul Koning Cc: derek@ihtfp.com, dharkins@tibernian.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: <200303061917.h26JH1ma000279@fatty.lounge.org> <15980.64456.752003.222139@pkoning.dev.equallogic.com> <15981.7487.502193.596127@pkoning.dev.equallogic.com> <15981.59050.591928.626821@pkoning.dev.equallogic.com> Reply-To: EKR From: Eric Rescorla Date: 11 Mar 2003 07:33:34 -0800 In-Reply-To: <15981.59050.591928.626821@pkoning.dev.equallogic.com> Message-ID: Lines: 25 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 Koning writes: > Sure I know about that hardware, but that wasn't your example. You > said "3DES and SHA" vs. "AES and MD5". 7811 supports 3DES with either > SHA or MD5; later chips support AES with either SHA or MD5. So the > choice for authentication function does not affect whether you are > able to perform a given encryption algorithm. I don't know of any real hardware that supports the second combination, but I wouldn't be at all surprised to hear about it. I haven't examined this particular IPsec situation in excruciating detail but I can tell you that this kind of thing used to come up all the time with SSL, especially when the private keying material is also in hardware for security purposes. So, for instance, you couldn't mix and match Skipjack with DH. And the more individual negotiable items one has, the worse things get. For instance, if one ends up negotiating compression as well.. However, if none of the hardware guys care, I suppose that one can consider this a theoretical issue. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Tue Mar 11 08:15:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BGFj316574; Tue, 11 Mar 2003 08:15:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19162 Tue, 11 Mar 2003 10:47:32 -0500 (EST) To: Francis Dupont Cc: Charlie_Kaufman@notesdev.ibm.com, "Andrew Krywaniuk" , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: bidding down attach on NAT-T References: <200303110855.h2B8trof023411@givry.rennes.enst-bretagne.fr> Date: 11 Mar 2003 10:35:16 -0500 In-Reply-To: <200303110855.h2B8trof023411@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 44 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > Francis Dupont writes: > > > How important is it for everyone to support NAT-T? > > > > => I don't believe a MUST support is a good idea because this makes no > > sense for an IPv6 implementation. > > Can we agree on "MUST support NAT-T if you support IPv4"? > > => I am not in favor of a MUST which has nothing to do with > interoperability, IMHO we should let the market do its job... > And I don't believe implementors who still have NAT-T support > in their plans like to become not compliant. HUH? What do you mean it has nothing to do with interoperability. If implementations don't implement NAT-T then it wont work across a NAT. I would certainly call that an interoperability problem, wouldn't you? I also do not understand your last sentence. If they are implementing NAT-T then they WOULD be compliant -- it's only people who DON'T implement who would be compliant. Besides, this is only for implementors who support IPv6. Your initial complaint about MUST was that it didn't make sense for v6. I agree with that, but now you say it doesn't make sense for v4, either? If we're not going to make sure that IKEv2 works across NAT, then I think we should just go home now. Read after me: A road warrior has no choice over whether there is a NAT is between them and their home base. We should support this (EXTREMELY) common case. > Thanks > > Francis.Dupont@enst-bretagne.fr -derek, who has been stuck behind a NAT at TOO MANY conferences. -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Tue Mar 11 10:30:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BIUG327570; Tue, 11 Mar 2003 10:30:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19409 Tue, 11 Mar 2003 12:48:48 -0500 (EST) From: "Jesse Alpert" To: "'Uri Blumenthal'" Cc: Subject: RE: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) Date: Tue, 11 Mar 2003 17:33:49 +0200 Message-ID: <005e01c2e7e3$9d892b00$7b2e1dc2@jesse> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E6DF809.8070900@bell-labs.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > I don't think it would work the way you describe - i.e. both > hosts are unaware and so created SAs with "uniquifier" 0... I didn't mean to say that the "uniquifier" will solve the problem of the concurrent rekeying. Just that the "uniquifier" can help distinguish between redundant SAs created by accident (e.g. because of concurrent rekeying) and identical SAs created on purpose by one of the peers. A peer which means to create an additional tunnel on purpose would use different "uniquifiers". Jesse -----Original Message----- From: Uri Blumenthal [mailto:uri@bell-labs.com] Sent: Tuesday, March 11, 2003 4:52 PM To: Jesse Alpert Cc: 'Markku Savela'; ipsec@lists.tislabs.com Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) Jesse Alpert wrote: >>SPI itself is already "uniquifier". Maybe the problem is not here, but >>instead in the definition of what is "redundant"? > > You are right, and that will probably work as well. Then why multiply the entities? Occham's Razor... > However: > If I understood correctly, IKEv2 draft was referring to the case where both > peers initiate a CHILD-SA exchange almost at once, resulting in two > identical IPsec SAs one of which IS redundant. In such a case you would want > to close one of the SAs to save on resources. The "uniquifier" can be used > to indicate this is not the case. I don't think it would work the way you describe - i.e. both hosts are unaware and so created SAs with "uniquifier" 0... I don't know how to deal with the described problem efficiently. From owner-ipsec@lists.tislabs.com Tue Mar 11 11:03:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJ3I329173; Tue, 11 Mar 2003 11:03:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19577 Tue, 11 Mar 2003 13:28:17 -0500 (EST) Cc: "'Markku Savela'" , ipsec@lists.tislabs.com Message-ID: <3E6DF809.8070900@bell-labs.com> Date: Tue, 11 Mar 2003 09:51:53 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Jesse Alpert Original-CC: "'Markku Savela'" , ipsec@lists.tislabs.com Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2) References: <005b01c2e7d8$b3a23720$7b2e1dc2@jesse> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jesse Alpert wrote: >>SPI itself is already "uniquifier". Maybe the problem is not here, but >>instead in the definition of what is "redundant"? > > You are right, and that will probably work as well. Then why multiply the entities? Occham's Razor... > However: > If I understood correctly, IKEv2 draft was referring to the case where both > peers initiate a CHILD-SA exchange almost at once, resulting in two > identical IPsec SAs one of which IS redundant. In such a case you would want > to close one of the SAs to save on resources. The "uniquifier" can be used > to indicate this is not the case. I don't think it would work the way you describe - i.e. both hosts are unaware and so created SAs with "uniquifier" 0... I don't know how to deal with the described problem efficiently. From owner-ipsec@lists.tislabs.com Tue Mar 11 14:47:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BMlE313364; Tue, 11 Mar 2003 14:47:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20158 Tue, 11 Mar 2003 17:12:46 -0500 (EST) Message-Id: <200303112215.h2BMFp023450@sydney.East.Sun.COM> Date: Tue, 11 Mar 2003 17:15:51 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Another field for traffic selector? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ghK0/yv4IYqYlLg0Lv4RBA== 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 Sorry Charlie... (for what I'm about to bring up) I was just talking to someone about some routing thing, and realized that IPsec might need another traffic selector field, for "virtual network number". Suppose you have several customer intranets, C1, C2, C3, C4, all using local IP addresses, so there's no way to distinguish traffic based on IP addresses, ports, or protocol types. And you have two firewalls F1 and F2 that are providing VPN service to different offices of customers C1, C2, C3, C4. These customers are not talking to each other. They are only talking between their own nodes, but they are all utilizing IPsec tunnels between F1 and F2. What would solve the problem is for F1 and F2 to create 4 different SAs, one for each of C1, C2, C3, and C4. But they have to negotiate which is which. So if there were another traffic selector field for "virtual network", 4 different child-SAs could be created, and F2 then would know, when it received a packet, which customer net it belonged to based on which SA it was received on. I'm not sure what to call it, or what size it ought to be. Other protocols need to solve this problem. The "VLAN tag" is used in 802. "Partition ID" is used in infiniband. I've heard the name "virtual router ID" for something, but I think that's a terrible name (since it's a virtual net, not a virtual router). If anyone can suggest an already-recognized name for this concept, an already-recognized size of the field, and an already-recognized numbering scheme, we should adopt it. Otherwise, I'd suggest the name "virtual net", size 2 bytes, and a numbering scheme that is local to F1 and F2 (someone would configure it compatibly at the two ends and map it to specific customer nets). So, there are two issues: a) I think we need to add this field to the traffic selector in IKE b) If at this late date extra things (this plus the uniquifier) are coming up as needing to be in the traffic selector, perhaps the encoding of traffic selector should be more flexible, so that new fields can be added in the future. Radia From owner-ipsec@lists.tislabs.com Tue Mar 11 17:20:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C1Kt320341; Tue, 11 Mar 2003 17:20:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20280 Tue, 11 Mar 2003 19:46:25 -0500 (EST) Message-Id: <200303112246.h2BMk1L5014356@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IPsec bakeoff in July 2003 confirmed In-reply-to: Your message of "Tue, 11 Mar 2003 14:56:38 +0100." <20030311135542.DDF7923A78@etheria.labouret.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Mar 2003 14:46:00 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ghislaine" == Ghislaine Labouret writes: Ghislaine> The organization of an IPsec bakeoff in France, the week after Ghislaine> IETF 57 Ghislaine> in Vienna, has been confirmed. Registration is now open. Here Ghislaine> is the Ghislaine> announcement by the organizer, ETSI: I would not agree. Registration is a mess. The passwords often do not work. The list of hotels is a questionable .DOC file (I didn't open it. I suggest that nobody should ever open or post such a document on a web site). We are told that the hotels are far enough from the facility that we are told to rent a car twice. (And we are told that we should do this because the town cares too much about the environment!?!?!) It is not in Cannes or in Nice, but in some suburb in between. The event registration is over 900 Euros/person. And it will be high season in the south of france. My vote would be to talk to the Hotel in Vienna, and stay there! ] 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@lists.tislabs.com Tue Mar 11 19:42:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C3gm324044; Tue, 11 Mar 2003 19:42:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20729 Tue, 11 Mar 2003 22:10:20 -0500 (EST) Reply-To: From: "Jimmy Zhang" To: Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-v3-04.txt Date: Tue, 11 Mar 2003 19:12:38 -0800 Message-ID: <000101c2e845$3d2c5c20$cbf0630c@mshome.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Steve, Since we have a dedicated section 7, Differences from RFC 2406, IMO, it would be better to list the new requirement of AES algorithm, and the removal of DES and 3DES requirement. This change is pretty important in the cryptography community. Page 28-29 the DISCUSSION, since ESN is a new thing, it would be better to say something about it here. In my understanding, we need to include ESN higher order bits, if applicable, in the ICV computation. It is appended just after the possible implicit padding. DISCUSSION: Begin by removing and saving the ICV field. Next check the overall length of the ESP packet minus the ICV field. If implicit padding is required, based on the blocksize of the integrity algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. (**** say something about ESN higher order bits here ***) Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. On page 9 Table 1 and page 10 Table 2: Next Header 1 M Y Y cipher[3] Seq# (high order bits) 4 if ESN [5] Y not xmtd ICV Padding variable if need Y not xmtd ICV variable M [6] plain Suggest change to the following (swap ESN high order bits and ICV padding, so that they are consistant to their position when we compute ICV) Next Header 1 M Y Y cipher[3] ICV Padding variable if need Y not xmtd Seq# (high order bits) 4 if ESN [5] Y not xmtd ICV variable M [6] plain Thanks, Jimmy From owner-ipsec@lists.tislabs.com Tue Mar 11 20:54:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C4sd325888; Tue, 11 Mar 2003 20:54:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20879 Tue, 11 Mar 2003 23:24:34 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Use of AES as prf in IKEv2 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 11 Mar 2003 23:05:49 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/11/2003 11:27:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo pointed out that the IKEv2 spec assumes that prf functions accept variable (and arbitrary) size keys, which won't always be the case. I thought the question was only theoretical because HMAC does and that was the only prf we defined. But I notice that we added an IKE Suite #5, which specifies: "AES-CBC MAC + XCBC integrity and prf". I'm having multiple problems parsing that. I think I know what AES-CBC MAC is as an integrity protection function. But what does "+ XCBC" mean and how do we feed two variable length inputs into this thing for the purpose of doing key expansion. I suspect AES-CBC MAC + XCBC integrity is well defined and hopefully in an RFC somewhere. But I'll bet we need to specify a fixed key size (we use 128 bits for encryption, that's probably the intent for integrity protection). And I'll bet no one really thought about how to use it with a variable length key for key expansion. IKEv2 computes SKEYSEED = prf ( Ni | Nr , g^xy). Nonces are variable length. We could specify (as Hugo recommended) that each nonce be truncated at half the fixed key size. I'd be happier using SHA-1(Ni | Nr) truncated as the key. I'd be happier still saying that even if we're using AES-CBC + XCBC for integrity we still use SHA-1 as our prf. What do others think? --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@lists.tislabs.com Tue Mar 11 20:57:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C4vm326100; Tue, 11 Mar 2003 20:57:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20877 Tue, 11 Mar 2003 23:24:29 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200303110930.h2B9ULof023890@givry.rennes.enst-bretagne.fr> Subject: Re: SPI in Delete Payload of IKE / IKEv2 To: Francis Dupont Cc: ipsec@lists.tislabs.com, "Atsuhiro Tsuji" X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 11 Mar 2003 20:43:05 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/11/2003 11:27:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > In your previous mail you wrote: > > I would claim this is incorrect behavior in IKEv2. There is a NOTIFY error > code "INVALID-SPI" specifically for this case. I would claim it was a > ... > > => which INVALID-SPI: there are two defined in the current document (:-)? How embarrassing. There are currently two different errors with the same name. I picked up the error codes from ISAKMP, where code 4 was INVALID-COOKIE and code 11 was INVALID-SPI. But when I switched terminology to refer to the IKE connection identifiers are SPIs instead of cookies, I renamed error code 4 and created the duplicate. Fixed. --Charlie From owner-ipsec@lists.tislabs.com Tue Mar 11 20:59:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C4xT326156; Tue, 11 Mar 2003 20:59:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20878 Tue, 11 Mar 2003 23:24:31 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: comments on ikev2 05 (editorial) To: Hugo Krawczyk Cc: IPsec WG , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 11 Mar 2003 22:43:59 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/11/2003 11:27:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > Here is a list of (mostly) editorial changes to ikev2-05 that I suggest > for the next revision of the document. > It includes several of the more significant editorial comments on version 04 > included in a message from Jan 23rd (message under the subject: > "some comments > on ikev2 04") and not reflected in 05. Sorry to have somehow missed these changes last time around, and thank you for the careful review. I've incorporated your comments except as noted below: > (9) Section 2.14 page 25: > > >>> subsequent exchanges. SKEYSEED and its derivatives are computed as > >>> follows: > >>> > >>> SKEYSEED = prf(Ni | Nr, g^ir) > > What happens if Ni|Nr is longer than the prf key? You should specify that the > values concatenated above are Ni and Nr each truncated (if > necessary) to half the > length of the prf key. (This is particularly relevant to prf's basedon block > ciphers, e.g. AES-CBC-MAC.) I'm not comfortable with this change. When the prf is HMAC, which accepts an arbitrary length key, there is no problem. I'm concerned that truncating the nonces makes the protocol more fragile in the case where an implementation fails to choose the nonces adequately randomly. I added: "If the prf does not accept variable length key, its specification for use with IKEv2 must include a procedure for deriving its required fixed length key from a variable length key". I'll start a new string asking the AES-CBC MAC advocates how they want to handle this. > (11) Then in the same section you specify: > > >>> In the case of a pre-shared key, the AUTH value is computed as: > >>> > >>> AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) > >>> > >>> where the string "Key Pad for IKEv2" is ASCII encoded and not null > >>> terminated. The shared secret can be variable length. The pad string > >>> is added so that if the shared secret is derived from a password, > >>> this exchange will not compromise use of the same password in other > >>> protocols. As noted above, deriving the shared secret from a > >>> password is not secure. This construction is used because it is > >>> anticipated that people will do it anyway. > >>> > > As I noted in a previous message this pad does not give anything. > It does not hurt either except for giving a false feeling of security. > If I am confused and you have an argument why this pad helps please > explain to me. > The only way this can help against another protocol it that protocol > uses the same prf > with the same . > And, again, if you still want to add the pad, it should be > concatenated to the input not > to the keyL that is > > AUTH = prf(Shared Secret, "Key Pad for IKEv2" | ) I added the following explanatory text: The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store a one way transformation of it that could not be used as a password equivalent for protocols other than IKEv2. Adding the key pad as a prefix to the message bytes does not in general give the same security benefit. If you still don't understand the goal, I can try to elaborate more. If you do understand but think it does not provide the promised benefit, please explain. --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@lists.tislabs.com Wed Mar 12 00:08:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C88K310918; Wed, 12 Mar 2003 00:08:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21363 Wed, 12 Mar 2003 02:38:09 -0500 (EST) Message-ID: <005601c2e86a$db331290$96f1fea9@jnpr.net> From: "sankar ramamoorthi" To: "Radia Perlman - Boston Center for Networking" , References: <200303112215.h2BMFp023450@sydney.East.Sun.COM> Subject: Re: Another field for traffic selector? Date: Tue, 11 Mar 2003 23:40:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Radia Perlman - Boston Center for Networking" To: Sent: Tuesday, March 11, 2003 2:15 PM Subject: Another field for traffic selector? > Sorry Charlie... (for what I'm about to bring up) > > I was just talking to someone about some routing thing, > and realized that IPsec might need another traffic selector > field, for "virtual network number". > > Suppose you have several customer intranets, C1, C2, C3, C4, > all using local IP addresses, so there's no way to distinguish > traffic based on IP addresses, ports, or protocol types. > > And you have two firewalls F1 and F2 that are providing VPN > service to different offices of customers C1, C2, C3, C4. > > These customers are not talking to each other. They are only > talking between their own nodes, but they are all utilizing > IPsec tunnels between F1 and F2. > > What would solve the problem is for F1 and F2 to create 4 different > SAs, one for each of C1, C2, C3, and C4. But they have to negotiate > which is which. So if there were another traffic selector field for > "virtual network", 4 different child-SAs could be created, and > F2 then would know, when it received a packet, which customer net > it belonged to based on which SA it was received on. > > I'm not sure what to call it, or what size it ought to be. > Other protocols need to solve this problem. The "VLAN tag" > is used in 802. "Partition ID" is used in infiniband. I've > heard the name "virtual router ID" for something, but I think > that's a terrible name (since it's a virtual net, not a virtual > router). If anyone can suggest an already-recognized name > for this concept, an already-recognized size of the field, > and an already-recognized numbering scheme, we should adopt it. > Otherwise, I'd suggest the name "virtual net", size 2 bytes, > and a numbering scheme that is local to F1 and F2 (someone > would configure it compatibly at the two ends and map it > to specific customer nets). > > So, there are two issues: > a) I think we need to add this field to the traffic selector in IKE While this is a very useful feature for the reasons you describe the thing that bothers me is.. How are the packets coming out of a tunnel verified to ensure they match the negotiated virtual net? Virtual net field is negotiated along with the traffic selectors. However a packet arriving in a SA can only be verified for a match with the traffic selctor information since there is no information about the Virtual net field in the packet. The only information available is the SA on which the packet arrived. It implies the peer has to be trusted to send the packet in the right tunnel for the negotiated virtual net. This seems to be at odds with a long thread of arguments that occurred in the past regarding strict verification of SA selector information for packets coming out a tunnel. Or am I missing something? Is Virtual net field expected to be part of ipsec headers also? -- sankar -- > b) If at this late date extra things (this plus the uniquifier) > are coming up as needing to be in the traffic selector, perhaps > the encoding of traffic selector should be more flexible, so > that new fields can be added in the future. > > Radia > > > From owner-ipsec@lists.tislabs.com Wed Mar 12 00:40:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C8eO314781; Wed, 12 Mar 2003 00:40:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21445 Wed, 12 Mar 2003 03:15:18 -0500 (EST) Message-ID: <3E6EED64.3108A80E@alcatel.be> Date: Wed, 12 Mar 2003 09:18:44 +0100 From: jeremy.de_clercq@alcatel.be X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com, marco.carugi@nortelnetworks.com Subject: Re: Another field for traffic selector? References: <200303112215.h2BMFp023450@sydney.East.Sun.COM> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/12/2003 09:18:45, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/12/2003 09:18:53, Serialize complete at 03/12/2003 09:18:53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm not sure what to call it, or what size it ought to be. > Other protocols need to solve this problem. The "VLAN tag" > is used in 802. "Partition ID" is used in infiniband. I've > heard the name "virtual router ID" for something, but I think > that's a terrible name (since it's a virtual net, not a virtual > router). If anyone can suggest an already-recognized name > for this concept, an already-recognized size of the field, > and an already-recognized numbering scheme, we should adopt it. > Otherwise, I'd suggest the name "virtual net", size 2 bytes, > and a numbering scheme that is local to F1 and F2 (someone > would configure it compatibly at the two ends and map it > to specific customer nets). For some VPN approaches, the PPVPN WG refers to the "Virtual Private Networks Identifier" defined in RFC 2685. > So, there are two issues: > a) I think we need to add this field to the traffic selector in IKE 1. I support this idea, and 2. if it is accepted by the ipsec community, I propose to allign with the ppvpn wg. thanks, Jeremy. > b) If at this late date extra things (this plus the uniquifier) > are coming up as needing to be in the traffic selector, perhaps > the encoding of traffic selector should be more flexible, so > that new fields can be added in the future. > > Radia From owner-ipsec@lists.tislabs.com Wed Mar 12 03:36:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CBap303860; Wed, 12 Mar 2003 03:36:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA21881 Wed, 12 Mar 2003 05:57:19 -0500 (EST) Message-Id: <200303121100.h2CB0oof028533@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Derek Atkins cc: Charlie_Kaufman@notesdev.ibm.com, "Andrew Krywaniuk" , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of 11 Mar 2003 10:35:16 EST. Date: Wed, 12 Mar 2003 12:00:50 +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: Francis Dupont writes: > In your previous mail you wrote: > > Francis Dupont writes: > > > How important is it for everyone to support NAT-T? > > > > => I don't believe a MUST support is a good idea because this makes no > > sense for an IPv6 implementation. > > Can we agree on "MUST support NAT-T if you support IPv4"? > > => I am not in favor of a MUST which has nothing to do with > interoperability, IMHO we should let the market do its job... > And I don't believe implementors who still have NAT-T support > in their plans like to become not compliant. HUH? What do you mean it has nothing to do with interoperability. => I should have put an explicit reference to RFC 2119. If implementations don't implement NAT-T then it wont work across a NAT. I would certainly call that an interoperability problem, wouldn't you? => I disagree. A MUST for NAT-T support doesn't make more sense than a MUST for IPv6 support for instance. I also do not understand your last sentence. => easy: if a feature is mandatory then all implementations which don't (yet) support it are (still) not compliant. If they are implementing NAT-T then they WOULD be compliant -- it's only people who DON'T implement who would be compliant. Besides, this is only for implementors who support IPv6. Your initial complaint about MUST was that it didn't make sense for v6. => IPv6 is an example of a real world environment where there is *no* NAT. I agree with that, but now you say it doesn't make sense for v4, either? => MUST is not about what we'd like to get, it is about what is needed in order to get the protocol work. If we're not going to make sure that IKEv2 works across NAT, then I think we should just go home now. Read after me: A road warrior has no choice over whether there is a NAT is between them and their home base. We should support this (EXTREMELY) common case. => we disagree only about the good usage of a MUST in a standard track document. IMHO here a MUST should not be used and even if we put a MUST it'll have no direct effect about what we'll get in the real world. -derek, who has been stuck behind a NAT at TOO MANY conferences. => yes, I have no NAT at my office or at home, but conferences or worse, interop events are places where I can keep up my hate for NATs! Thanks Francis.Dupont@enst-bretagne.fr PS: from RFC 2119: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. So NAT-T support should not get a MUST, but support of NAT-T detection (i.e., NAT-DETECTION-*-IP (or better) stuff) should get one. From owner-ipsec@lists.tislabs.com Wed Mar 12 05:50:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CDoY314614; Wed, 12 Mar 2003 05:50:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22164 Wed, 12 Mar 2003 08:19:03 -0500 (EST) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Wed, 12 Mar 2003 07:22:01 -0600 (CST) From: Tylor Allison X-X-Sender: To: Derek Atkins cc: Paul Hoffman / VPNC , Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 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 10 Mar 2003, Derek Atkins wrote: > Paul Hoffman / VPNC writes: > > > At 2:08 PM -0500 3/10/03, Derek Atkins wrote: > > >Dan Harkins writes: > > > > > >> already seeing. IKEv2-02 also had the complex ANDing and ORing that I > > >> think we should get rid of. Why not just have a single SA payload that > > >> contains TLVs for each of the necessary attributes? Multiple occurances > > >> of an attribute mean "I'll do either" (as it was in IKEv2-02 even though > > >> I doubt that would be used much if ever). > > > > > >While I agree with everything else you said about 02 vs 05 (cut from > > >this reply), I do need to add that the one argument I heard that > > >implies AND and OR are necessary in an a la carte system is for > > >hardware deployments that support multiple algorithms but NOT in > > >arbitrary combinations. For example, a hardware implementation that > > >ONLY supports 3DES with MD5, or AES with SHA-1... > > > > One of the early goals for IKEv2 was simplicity. Doing AND and OR > > moves sharply away from that. Dan's proposal above would be much > > simpler to implement. > > That's fine. I have no specific, personal objection to leaving out > the AND and OR functionality. I was just pointing out that there > were reasonable reasons to have such functionality. I agree with this approach as well... > If we DO decide to leave it out in the name of simplicity we should at > least add some text that shows that we thought about this issue. I > would propose something like: > > Certain hardware architectural implementations may only support > limited combinations of algorithms. For example, a piece of > hardware may only support 3DES+MD5 or AES+SHA1, but there is no way > to actually negotiate for one or the other combinations. The > working group acknowledges this limitation, but decided in favor of > the simplicity of ruling out such architectures. Or perhaps add text which states that the limitation exists, and is up to such implementation to work within the rules of the protocol. Such a device can still interoperate, it will just be harder for the implementation. For example, they can attempt to negotiate an AES+SHA1 SA first... failing that, attempt a new SA negotiation for 3DES+MD5. Granted, this is not pretty, but neither is the hardware implementation that they are trying to support. > > --Paul Hoffman, Director > > --VPN Consortium > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Wed Mar 12 09:51:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CHpE324597; Wed, 12 Mar 2003 09:51:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22760 Wed, 12 Mar 2003 12:11:33 -0500 (EST) Message-ID: <3E6F6B39.DA5CEFDD@airespace.com> Date: Wed, 12 Mar 2003 09:15:37 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <200303112215.h2BMFp023450@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Radia, I'm a little confused about this (sorry, not a ppvpn person). I have some questions interspersed below. Radia Perlman - Boston Center for Networking wrote: > > Sorry Charlie... (for what I'm about to bring up) > > I was just talking to someone about some routing thing, > and realized that IPsec might need another traffic selector > field, for "virtual network number". > > Suppose you have several customer intranets, C1, C2, C3, C4, > all using local IP addresses, so there's no way to distinguish > traffic based on IP addresses, ports, or protocol types. I don't have a clear picture of this in mind. Are you saying that the customers are using overlapping private address spaces, e.g. C1: 10.1.1.0-10.1.2.255 C2: 10.1.1.0-10.1.1.255 C3: 10.1.2.0-10.1.2.255 C4: 10.1.1.0-10.2.1.255 or do you mean something else? > And you have two firewalls F1 and F2 that are providing VPN > service to different offices of customers C1, C2, C3, C4. This leads me to think of implementations which sit just inside the cloud between the customer networks - is this what you mean? Thanks for your indulgence, Scott ----end of questions--------- > These customers are not talking to each other. They are only > talking between their own nodes, but they are all utilizing > IPsec tunnels between F1 and F2. > > What would solve the problem is for F1 and F2 to create 4 different > SAs, one for each of C1, C2, C3, and C4. But they have to negotiate > which is which. So if there were another traffic selector field for > "virtual network", 4 different child-SAs could be created, and > F2 then would know, when it received a packet, which customer net > it belonged to based on which SA it was received on. > > I'm not sure what to call it, or what size it ought to be. > Other protocols need to solve this problem. The "VLAN tag" > is used in 802. "Partition ID" is used in infiniband. I've > heard the name "virtual router ID" for something, but I think > that's a terrible name (since it's a virtual net, not a virtual > router). If anyone can suggest an already-recognized name > for this concept, an already-recognized size of the field, > and an already-recognized numbering scheme, we should adopt it. > Otherwise, I'd suggest the name "virtual net", size 2 bytes, > and a numbering scheme that is local to F1 and F2 (someone > would configure it compatibly at the two ends and map it > to specific customer nets). > > So, there are two issues: > a) I think we need to add this field to the traffic selector in IKE > b) If at this late date extra things (this plus the uniquifier) > are coming up as needing to be in the traffic selector, perhaps > the encoding of traffic selector should be more flexible, so > that new fields can be added in the future. > > Radia From owner-ipsec@lists.tislabs.com Wed Mar 12 10:08:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CI8v326046; Wed, 12 Mar 2003 10:08:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22899 Wed, 12 Mar 2003 12:40:33 -0500 (EST) Date: Tue, 11 Mar 2003 21:53:41 +0200 (EET) Message-Id: <200303111953.h2BJrfU09648@tero.kivinen.iki.fi> X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05 References: Organization: Helsinki University of Technology Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ekr@rtfm.com (Eric Rescorla) writes: > Say, for the sake of argument that you have a piece of hardware > that processes single IPsec records and supports 3DES and SHA. > You then add another CSP that supports AES and MD5. You can't Then the IKE must select one of those and offer only that. If the negotiation fails it can try the other. As told earlier in this thread most of the IPsec initiators are configured to only send one offer anyways, so I don't really think this is very big issue. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Mar 12 10:09:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CI95326080; Wed, 12 Mar 2003 10:09:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22887 Wed, 12 Mar 2003 12:38:28 -0500 (EST) Message-ID: <6204FDDE129D364D8040A98BCCB290EF048B54AC@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: jeremy.de_clercq@alcatel.be, Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com, "Marco Carugi" Subject: RE: Another field for traffic selector? Date: Wed, 12 Mar 2003 12:34:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8BD.96822610" 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_01C2E8BD.96822610 Content-Type: text/plain Hi Radia and Jeremy, I'll second Jeremy's support for this. The need for including something like a VPN-ID as a traffic selector has been discussed in at least two individual drafts in the PPVPN WG: - draft-knight-ppvpn-vr-protocol-00.txt (Protocol Actions for Virtual Router VPNs) - draft-duffy-ppvpn-ipsec-vlink-00.txt (Framework for IPsec Protected Virtual Links for PPVPNs) I would definitely support adding extensibility or flexibility to the encoding of the traffic selector, since even for VPN-ID, there is still not a universal format. (RFC 2685 specifies 7 bytes; RFC 2547 has a Target VPN or Route Target which is 8 bytes.) I think the field should accommodate these sizes when VPN-ID is used as a selector. It may be possible to use a smaller field, but the signaling to negotiate a smaller field and ensure its uniqueness would probably be more burdensome than simply having a field which can accommodate current VPN-IDs. Draft-knight-ppvpn-vr-protocol-00.txt suggests: The Traffic Selector (TS) payload proposed in [IKE-V2] may be suitable for this purpose [carrying the VPN-ID]. The TS Payload specifies address ranges, and thus does not appear to be a clear fit for specifying a single VPN-ID, but it may be possible to define an additional TS Type with semantics suitable for the VPN-ID. Also, as a quick response to Sankar's question: (How are the packets coming out of a tunnel verified to ensure they match the negotiated virtual net? [....] Is Virtual net field expected to be part of ipsec headers also?) Yes, I think including a VPN-ID in the IPsec header is needed to map the packets to the VPN. Regards, Paul "The world is a jungle in general, and the networking game contributes many animals." - RFC 826 > -----Original Message----- > From: jeremy.de_clercq@alcatel.be > [mailto:jeremy.de_clercq@alcatel.be] > Sent: Wednesday, March 12, 2003 3:19 AM > To: Radia Perlman - Boston Center for Networking > Cc: ipsec@lists.tislabs.com; Carugi, Marco [CTF:0000:EXCH] > Subject: Re: Another field for traffic selector? > > > > > I'm not sure what to call it, or what size it ought to be. Other > > protocols need to solve this problem. The "VLAN tag" is > used in 802. > > "Partition ID" is used in infiniband. I've heard the name "virtual > > router ID" for something, but I think that's a terrible name (since > > it's a virtual net, not a virtual router). If anyone can suggest an > > already-recognized name for this concept, an > already-recognized size > > of the field, and an already-recognized numbering scheme, we should > > adopt it. Otherwise, I'd suggest the name "virtual net", > size 2 bytes, > > and a numbering scheme that is local to F1 and F2 (someone > > would configure it compatibly at the two ends and map it > > to specific customer nets). > > For some VPN approaches, the PPVPN WG refers to the "Virtual > Private Networks Identifier" defined in RFC 2685. > > > So, there are two issues: > > a) I think we need to add this field to the traffic selector in IKE > > 1. I support this idea, and > 2. if it is accepted by the ipsec community, I propose to > allign with the ppvpn wg. > > thanks, > Jeremy. > > > > b) If at this late date extra things (this plus the uniquifier) are > > coming up as needing to be in the traffic selector, perhaps the > > encoding of traffic selector should be more flexible, so that new > > fields can be added in the future. > > > > Radia > ------_=_NextPart_001_01C2E8BD.96822610 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Another field for traffic selector?

Hi Radia and Jeremy,

I'll second Jeremy's support for this.  The need = for including something like a VPN-ID as a traffic selector has been = discussed in at least two individual drafts in the PPVPN WG:

- draft-knight-ppvpn-vr-protocol-00.txt (Protocol = Actions for Virtual Router VPNs)
- draft-duffy-ppvpn-ipsec-vlink-00.txt (Framework = for IPsec Protected Virtual Links for PPVPNs)

I would definitely support adding extensibility or = flexibility to the encoding of the traffic selector, since even for = VPN-ID, there is still not a universal format.  (RFC 2685 = specifies 7 bytes; RFC 2547 has a Target VPN or Route Target which is 8 = bytes.)  I think the field should accommodate these sizes when = VPN-ID is used as a selector.  It may be possible to use a smaller = field, but the signaling to negotiate a smaller field and ensure its = uniqueness would probably be more burdensome than simply having a field = which can accommodate current VPN-IDs.

Draft-knight-ppvpn-vr-protocol-00.txt = suggests:
   The Traffic Selector (TS) payload = proposed in [IKE-V2] may be
   suitable for this purpose [carrying the = VPN-ID].  The TS Payload specifies address ranges,
   and thus does not appear to be a clear = fit for specifying a single
   VPN-ID, but it may be possible to = define an additional TS Type with
   semantics suitable for the VPN-ID. =

Also, as a quick response to Sankar's question: =
(How are the packets coming out of a tunnel verified = to ensure they match the negotiated virtual net? [....] Is Virtual net = field expected to be part of ipsec headers also?)

Yes, I think including a VPN-ID in the IPsec header = is needed to map the packets to the VPN.

Regards,
Paul

"The world is a jungle in general, and the = networking game contributes many animals."  - RFC 826

> -----Original Message-----
> From: jeremy.de_clercq@alcatel.be
> [mailto:jeremy.de_clercq@alca= tel.be]
> Sent: Wednesday, March 12, 2003 3:19 AM
> To: Radia Perlman - Boston Center for = Networking
> Cc: ipsec@lists.tislabs.com; Carugi, Marco = [CTF:0000:EXCH]
> Subject: Re: Another field for traffic = selector?
>
>
>
> > I'm not sure what to call it, or what size = it ought to be. Other
> > protocols need to solve this problem. The = "VLAN tag" is
> used in 802.
> > "Partition ID" is used in = infiniband. I've heard the name "virtual
> > router ID" for something, but I think = that's a terrible name (since
> > it's a virtual net, not a virtual router). = If anyone can suggest an
> > already-recognized name for this concept, = an
> already-recognized size
> > of the field, and an already-recognized = numbering scheme, we should
> > adopt it. Otherwise, I'd suggest the name = "virtual net",
> size 2 bytes,
> > and a numbering scheme that is local to F1 = and F2 (someone
> > would configure it compatibly at the two = ends and map it
> > to specific customer nets).
>
> For some VPN approaches, the PPVPN WG refers to = the "Virtual
> Private Networks Identifier" defined in = RFC 2685.
>
> > So, there are two issues:
> > a) I think we need to add this field to = the traffic selector in IKE
>
> 1. I support this idea, and
> 2. if it is accepted by the ipsec community, I = propose to
> allign with the ppvpn wg.
>
> thanks,
> Jeremy.
>
>
> > b) If at this late date extra things (this = plus the uniquifier) are
> > coming up as needing to be in the traffic = selector, perhaps the
> > encoding of traffic selector should be = more flexible, so that new
> > fields can be added in the future.
> >
> > Radia
>

------_=_NextPart_001_01C2E8BD.96822610-- From owner-ipsec@lists.tislabs.com Wed Mar 12 10:11:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CIBg326515; Wed, 12 Mar 2003 10:11:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22881 Wed, 12 Mar 2003 12:38:26 -0500 (EST) Message-ID: <3E6F25EC.6010301@creeksidenet.com> Date: Wed, 12 Mar 2003 07:19:56 -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: Valery Smyslov CC: ipsec@lists.tislabs.com Subject: Re: Auth Method References: <00c501c2e3ba$872e83f0$640572d4@trustworks.com> <3E673960.D2E2BC10@creeksidenet.com> <00f401c2e3dc$3d4bc000$640572d4@trustworks.com> Content-Type: multipart/alternative; boundary="------------050801030408010102080401" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------050801030408010102080401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I guess my point was that you must have a public key in order to try to verify the signature. If you know the public key type, there is no real reason to also know the private key type used by the remote end to sign. If there sender signs with a different private key type than the public key he/she sent you, the sig just wont verify. Of course, to determine the type of public key you hold, you need to do some ASN1 decoding. Getting this from the AUTH payload may be easier for some implementations, so adding an RSA/DSA differentiator may be helpful. Regards, Jeff Valery Smyslov wrote: >> The public key type is encoded in the key itself. So even if you use >> signatures without certs, you still have the information. >> >> Jeff >> > > I don't think so. Authentication payload contains the signature, not the > key. > And encoding of this signature in payload is not defined in the > document (BTW, I think it needs to be fixed anyway). > And if encoding follows the same rules as in IKEv1 (PKCS#1 for RSA > and raw signature for DSS), receiving side has no reliable means > to distinguish between them. > > Regards, > Valery Smyslov. > >> Valery Smyslov wrote: >> >>> Greeting, >>> >>> IKEv2-05 specifies only 2 values for Auth Method field in >>> Authentication Payload: Digital Signature (1) and Shared Key >>> Message Integrity Code (2). How could receiver unambiguously >>> determine what digital signature algorithm was used: RSA, DSA or >>> something else? By examining Authentication Payload length? - not >>> very reliable method. Via the other entity's certificate? - but >>> Certificate Payload is optional, and the entity may have several >>> certificates of different type. >>> >>> In message http://www.vpnc.org/ietf-ipsec/mail-archive/msg02440.html >>> Charlie Kaufman wrote: >>> >>> Unless someone objects, I'll add a specifier of the >>> authentication data type, of which we currently have 3: RSA >>> signature, >>> DSA signature, and shared key HMAC. >>> >>> So, the original intention was to make Auth Type more specific than we >>> have now, indicating what particular digital signature algorithm was >> > used. > >>> I'm curious what was the rationale to change that intention. >>> >>> Another issue - how each side can advertise auth methods she supports. >>> In the same message there was some discussion on this topic and >>> suggestion to use CertRequest Payload for that purpose. Unfortunately, >>> it hasn't been done. Why? Are there strong objections against it? >>> >>> Regards, >>> Valery Smyslov. >> --------------050801030408010102080401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
I guess my point was that you must have a public key in order to try to verify the signature.
If you know the public key type, there is no real reason to also know the private key type used
by the remote end to sign. If there sender signs with a different private key type than
the public key he/she sent you, the sig just wont verify.

Of course, to determine the type of public key you hold, you need to do some ASN1 decoding.
Getting this from the AUTH payload may be easier for some implementations, so adding an
RSA/DSA differentiator may be helpful.

Regards,
Jeff

Valery Smyslov wrote:
The public key type is encoded in the key itself. So even if you use
signatures without certs, you still have the information.

Jeff


I don't think so. Authentication payload contains the signature, not the
key.
And encoding of this signature in payload is not defined in the
document (BTW, I think it needs to be fixed anyway).
And if encoding follows the same rules as in IKEv1 (PKCS#1 for RSA
and raw signature for DSS), receiving side has no reliable means
to distinguish between them.

Regards,
Valery Smyslov.

Valery Smyslov wrote:

Greeting,

IKEv2-05 specifies only 2 values for Auth Method field in
Authentication Payload: Digital Signature (1) and Shared Key
Message Integrity Code (2). How could receiver unambiguously
determine what digital signature algorithm was used: RSA, DSA or
something else? By examining Authentication Payload length? - not
very reliable method. Via the other entity's certificate? - but
Certificate Payload is optional, and the entity may have several
certificates of different type.

In message http://www.vpnc.org/ietf-ipsec/mail-archive/msg02440.html
Charlie Kaufman wrote:

        Unless someone objects, I'll add a specifier of the
        authentication data type, of which we currently have 3: RSA
signature,
       !
 DSA signature, and shared key HMAC.

So, the original intention was to make Auth Type more specific than we
have now, indicating what particular digital signature algorithm was
used.
I'm curious what was the rationale to change that intention.

Another issue - how each side can advertise auth methods she supports.
In the same message there was some discussion on this topic and
suggestion to use CertRequest Payload for that purpose. Unfortunately,
it hasn't been done. Why? Are there strong objections against it?

Regards,
Valery Smyslov.

--------------050801030408010102080401-- From owner-ipsec@lists.tislabs.com Wed Mar 12 10:11:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CIBj326534; Wed, 12 Mar 2003 10:11:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22875 Wed, 12 Mar 2003 12:37:25 -0500 (EST) Message-ID: <3E6F23B5.8050703@creeksidenet.com> Date: Wed, 12 Mar 2003 07:10:29 -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: Derek Atkins CC: Francis Dupont , Charlie_Kaufman@notesdev.ibm.com, Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T References: <200303110855.h2B8trof023411@givry.rennes.enst-bretagne.fr> Content-Type: multipart/alternative; boundary="------------050008050105070903080006" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------050008050105070903080006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Just a reminder that there are many non-VPN uses for IKE2, such as RPSec's interest to use IKE/IPSec to secure routing protocols. Such use does not require NAT. Regards, Jeff Derek Atkins wrote: > Francis Dupont writes: > >> In your previous mail you wrote: >> >> Francis Dupont writes: >> >> > How important is it for everyone to support NAT-T? >> > >> > => I don't believe a MUST support is a good idea because this makes no >> > sense for an IPv6 implementation. >> >> Can we agree on "MUST support NAT-T if you support IPv4"? >> >> => I am not in favor of a MUST which has nothing to do with >> interoperability, IMHO we should let the market do its job... >> And I don't believe implementors who still have NAT-T support >> in their plans like to become not compliant. > > > HUH? What do you mean it has nothing to do with interoperability. > If implementations don't implement NAT-T then it wont work across a NAT. > I would certainly call that an interoperability problem, wouldn't you? > > I also do not understand your last sentence. If they are implementing > NAT-T then they WOULD be compliant -- it's only people who DON'T > implement who would be compliant. Besides, this is only for implementors > who support IPv6. Your initial complaint about MUST was that it didn't > make sense for v6. I agree with that, but now you say it doesn't make > sense for v4, either? > > If we're not going to make sure that IKEv2 works across NAT, then I > think we should just go home now. Read after me: A road warrior has > no choice over whether there is a NAT is between them and their home > base. We should support this (EXTREMELY) common case. > >> Thanks >> >> Francis.Dupont@enst-bretagne.fr > > > -derek, who has been stuck behind a NAT at TOO MANY conferences. > --------------050008050105070903080006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Just a reminder that there are many non-VPN uses for IKE2, such as RPSec's
interest to use IKE/IPSec to secure routing protocols. Such use does not require
NAT.

Regards,
Jeff

Derek Atkins wrote:
Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:

 In your previous mail you wrote:

   Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
   
   >    How important is it for everyone to support NAT-T?
   > 
   > => I don't believe a MUST support is a good idea because this makes no
   > sense for an IPv6 implementation.
   
   Can we agree on "MUST support NAT-T if you support IPv4"?

=> I am not in favor of a MUST which has nothing to do with
interoperability, IMHO we should let the market do its job...
And I don't believe implementors who still have NAT-T support
in their plans like to become not compliant.

HUH?  What do you mean it has nothing to do with interoperability.
If implementations don't implement NAT-T then it wont work across a NAT.
I would certainly call that an interoperability problem, wouldn't you?

I also do not understand your last sentence.  If they are implementing
NAT-T then they WOULD be compliant -- it's only people who DON'T
implement who would be compliant.  Besides, this is only for implementors
who support IPv6.  Your initial complaint about MUST was that it didn't
make sense for v6.  I agree with that, but now you say it doesn't make
sense for v4, either?

If we're not going to make sure that IKEv2 works across NAT, then I
think we should just go home now.  Read after me: A road warrior has
no choice over whether there is a NAT is between them and their home
base.  We should support this (EXTREMELY) common case.

Thanks

Francis.Dupont@enst-bretagne.fr

-derek, who has been stuck behind a NAT at TOO MANY conferences.


--------------050008050105070903080006-- From owner-ipsec@lists.tislabs.com Wed Mar 12 10:12:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CICV326694; Wed, 12 Mar 2003 10:12:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22911 Wed, 12 Mar 2003 12:41:33 -0500 (EST) Message-ID: <2F8E7538CA01D711BC5900B0D079E7102330DC@zin03exm01.corp.mot.com> From: Mittal Harshwardhan-A18990 To: "'ipsec@lists.tislabs.com'" Subject: oakley groups Date: Wed, 12 Mar 2003 13:08:03 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, I have one basic doubt. DH-768 support is mandactory as per rfc-2409. For a demo implementation is it possible to do IKE negotiation without DH-768 and 1024 support? by using ECC-163 in place. Thanks & Regards, Harsh ********************************************** Harsh Mittal Software Engineer Motorola India Electronics Ltd. H.No. 6-3-1090, TSR Towers, Rajbhavan Road, Somajiguda, Hyderabad-500082 Phone: +91-40-23308090 Ex.2026 Email:- harshmittal@motorola.com ************************************************ [ x] General Business Information [ ] Motorola Internal Use only [ ] Motorola Confidential Proprietary [ ] Non-Business Information ************************************************ From owner-ipsec@lists.tislabs.com Wed Mar 12 11:14:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CJEa301430; Wed, 12 Mar 2003 11:14:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23251 Wed, 12 Mar 2003 13:34:11 -0500 (EST) Message-ID: <3E6F4B73.3060007@creeksidenet.com> Date: Wed, 12 Mar 2003 10:00:03 -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, Radia Subject: ike2 reliable rekeying Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a couple of concerns about rekying IKE-SAs and how simultaneous rekey is currently spec'd. I also believe there is a simple way around the issue. My concerns are: - When simultaneous rekey does occur, you can end up with multiple SAs temporarily. In order to prevent explosion of SAs across multiple rekeys, one of the SAs needs to be deleted. The spec says to wait a random amout of time when this is detected and delete one of the SAs, altough which SA is not specified. There is clearly the possibility that each side will wait the same random time and delete different SAs, resulting in loss of connectivity at least temporarily. IMHO, there will be applications where this is a very bad thing. - My second concern is more a a matter of implementation difficulty. When multiple SAs do exist, you need to "accept incoming packets through either SA". This just seems rather ugly from my point of view. Both these issues could be solved by using a rekey collision detection mechanism that could work as follows: 1) When an IKE instance sends a rekey request on an IKE SA, it marks the SA with a rekey flag. 2) If an instance receives a rekey request with the flag set and before it has received a response to its request, it makes a choice as to which SA is preferred. Preference could be based on peer address. If the request it sent is preferred, it drops the received request. Otherwise it responds normally. 3) If an instance receives a rekey request with the flags set, but after it has recieved a response to its request, it drops the request. This could occur due to packet loss and retransmission. 4) When an instance recieves a rekey request when the flag is not set, it prevents itself from originating new rekey requests. This mechanism would prevent duplicate established SAs. The worst the could occur would be an outstanding request on an SA when it received the delete payload from the preferred instance. Of course this seems logical as I write it, but may appear non-sensical later, so I'd appreciate comments. Regards, Jeff From owner-ipsec@lists.tislabs.com Wed Mar 12 11:26:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CJQc301766; Wed, 12 Mar 2003 11:26:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23313 Wed, 12 Mar 2003 13:50:42 -0500 (EST) To: "jpickering@creeksidenet.com" Cc: Francis Dupont , Charlie_Kaufman@notesdev.ibm.com, Andrew Krywaniuk , ipsec@lists.tislabs.com From: Derek Atkins Subject: Re: bidding down attach on NAT-T References: <200303110855.h2B8trof023411@givry.rennes.enst-bretagne.fr> <3E6F23B5.8050703@creeksidenet.com> Date: 12 Mar 2003 13:50:11 -0500 In-Reply-To: <3E6F23B5.8050703@creeksidenet.com> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "jpickering@creeksidenet.com" writes: > Just a reminder that there are many non-VPN uses for IKE2, such as RPSec's > interest to use IKE/IPSec to secure routing protocols. Such use does > not require > NAT. Sure, but just because some uses don't require a feature does not imply that it shouldn't be a "MUST." For example, VPNs don't use AH, but AH is still a MUST. Similarly, if NAT-T is defined as "MUST implement if you support ipv4", it does not imply that you have to _USE_ NAT-T. Just a reminder that "must implement" does not imply "must use." > Regards, > Jeff -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed Mar 12 11:34:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CJYG302008; Wed, 12 Mar 2003 11:34:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23406 Wed, 12 Mar 2003 14:06:31 -0500 (EST) Message-ID: <3E6F4B73.3060007@creeksidenet.com> Date: Wed, 12 Mar 2003 10:00:03 -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, Radia Subject: ike2 reliable rekeying Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a couple of concerns about rekying IKE-SAs and how simultaneous rekey is currently spec'd. I also believe there is a simple way around the issue. My concerns are: - When simultaneous rekey does occur, you can end up with multiple SAs temporarily. In order to prevent explosion of SAs across multiple rekeys, one of the SAs needs to be deleted. The spec says to wait a random amout of time when this is detected and delete one of the SAs, altough which SA is not specified. There is clearly the possibility that each side will wait the same random time and delete different SAs, resulting in loss of connectivity at least temporarily. IMHO, there will be applications where this is a very bad thing. - My second concern is more a a matter of implementation difficulty. When multiple SAs do exist, you need to "accept incoming packets through either SA". This just seems rather ugly from my point of view. Both these issues could be solved by using a rekey collision detection mechanism that could work as follows: 1) When an IKE instance sends a rekey request on an IKE SA, it marks the SA with a rekey flag. 2) If an instance receives a rekey request with the flag set and before it has received a response to its request, it makes a choice as to which SA is preferred. Preference could be based on peer address. If the request it sent is preferred, it drops the received request. Otherwise it responds normally. 3) If an instance receives a rekey request with the flags set, but after it has recieved a response to its request, it drops the request. This could occur due to packet loss and retransmission. 4) When an instance recieves a rekey request when the flag is not set, it prevents itself from originating new rekey requests. This mechanism would prevent duplicate established SAs. The worst the could occur would be an outstanding request on an SA when it received the delete payload from the preferred instance. Of course this seems logical as I write it, but may appear non-sensical later, so I'd appreciate comments. Regards, Jeff From owner-ipsec@lists.tislabs.com Wed Mar 12 12:25:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CKPm303524; Wed, 12 Mar 2003 12:25:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23613 Wed, 12 Mar 2003 14:43:05 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15983.36512.982539.443990@thomasm-u1.cisco.com> Date: Wed, 12 Mar 2003 11:46:40 -0800 (PST) To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: Another field for traffic selector? In-Reply-To: <200303112215.h2BMFp023450@sydney.East.Sun.COM> References: <200303112215.h2BMFp023450@sydney.East.Sun.COM> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia, This strikes me as opening Pandora's box and then some. There are many possible ways that you might want to influence traffic on the egress side of the tunnel including VLAN's as you mention, but also MPLS and other fell creatures. Also: this seemingly overlaps with other ways of signaling in the QoS domain (RSVP) which is another way of thinking about this problem. My big question is this: why does it need to go into IKEv2 instead of considering it separately? At the very least, the requirements would need to be fleshed out and that sounds like a very deep rathole. Mike Radia Perlman - Boston Center for Networking writes: > Sorry Charlie... (for what I'm about to bring up) > > I was just talking to someone about some routing thing, > and realized that IPsec might need another traffic selector > field, for "virtual network number". > > Suppose you have several customer intranets, C1, C2, C3, C4, > all using local IP addresses, so there's no way to distinguish > traffic based on IP addresses, ports, or protocol types. > > And you have two firewalls F1 and F2 that are providing VPN > service to different offices of customers C1, C2, C3, C4. > > These customers are not talking to each other. They are only > talking between their own nodes, but they are all utilizing > IPsec tunnels between F1 and F2. > > What would solve the problem is for F1 and F2 to create 4 different > SAs, one for each of C1, C2, C3, and C4. But they have to negotiate > which is which. So if there were another traffic selector field for > "virtual network", 4 different child-SAs could be created, and > F2 then would know, when it received a packet, which customer net > it belonged to based on which SA it was received on. > > I'm not sure what to call it, or what size it ought to be. > Other protocols need to solve this problem. The "VLAN tag" > is used in 802. "Partition ID" is used in infiniband. I've > heard the name "virtual router ID" for something, but I think > that's a terrible name (since it's a virtual net, not a virtual > router). If anyone can suggest an already-recognized name > for this concept, an already-recognized size of the field, > and an already-recognized numbering scheme, we should adopt it. > Otherwise, I'd suggest the name "virtual net", size 2 bytes, > and a numbering scheme that is local to F1 and F2 (someone > would configure it compatibly at the two ends and map it > to specific customer nets). > > So, there are two issues: > a) I think we need to add this field to the traffic selector in IKE > b) If at this late date extra things (this plus the uniquifier) > are coming up as needing to be in the traffic selector, perhaps > the encoding of traffic selector should be more flexible, so > that new fields can be added in the future. > > Radia > > From owner-ipsec@lists.tislabs.com Wed Mar 12 12:53:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CKrJ305599; Wed, 12 Mar 2003 12:53:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23767 Wed, 12 Mar 2003 15:22:20 -0500 (EST) Message-ID: <3E6F7449.8060404@isi.edu> Date: Wed, 12 Mar 2003 09:54:17 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030305 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <200303112215.h2BMFp023450@sydney.East.Sun.COM> In-Reply-To: <200303112215.h2BMFp023450@sydney.East.Sun.COM> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030202080307040608080809" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030202080307040608080809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Radia Perlman - Boston Center for Networking wrote: > > I was just talking to someone about some routing thing, > and realized that IPsec might need another traffic selector > field, for "virtual network number". > > Suppose you have several customer intranets, C1, C2, C3, C4, > all using local IP addresses, so there's no way to distinguish > traffic based on IP addresses, ports, or protocol types. > > And you have two firewalls F1 and F2 that are providing VPN > service to different offices of customers C1, C2, C3, C4. > > These customers are not talking to each other. They are only > talking between their own nodes, but they are all utilizing > IPsec tunnels between F1 and F2. > > What would solve the problem is for F1 and F2 to create 4 different > SAs, one for each of C1, C2, C3, and C4. But they have to negotiate > which is which. So if there were another traffic selector field for > "virtual network", 4 different child-SAs could be created, and > F2 then would know, when it received a packet, which customer net > it belonged to based on which SA it was received on. > > I'm not sure what to call it, or what size it ought to be. This is very similar to the VPN ID that was proposed a while ago. Adding a VPN ID of N bits is equivalent to increasing the address space by N bits. The VPN ID will still need to be globally unique, otherwise a site may be connected to two VPNs that happen to use the same VPN ID and address space, resulting in the same issues they have now. Making sure that VPN IDs are unique for all overlays connected to a site is the same overhead as making sure that their address spaces do not overlap, which makes VPN IDs seem rather ineffective. (I'm ready to be convinced otherwise.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms030202080307040608080809 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDMxMjE3NTQxN1owIwYJKoZIhvcNAQkEMRYEFDgts8kf7fxHc5vQdgH+ FuYbxr2ZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAl0G4ihpoQAAdjQ4NGI1fdqaHmK8J0yOwuFnt llTmIFzRhVjpGFSEI9873q733T7pzG7+6hd1Xp0mFBRw4HDHRupt5oHJ2cp5e/d5T0c0QeCu DWbt8JDC4X1eiExTxqsziPks+ExBeRrMmm6K4AKskIIeh8u/sjVCqNMbnPmWLoV4j8nn+yei nWacxCfoosjXoiPRggoCjjM/9Q0qPigxpzV7EOUTsc+kiklkGajYduQomaKx+uuhv4AU11Cr bJGmO3BY9dv9XzYwQ5Lm1TBJzU2Qukz1TAHLvvEDXKuEw4qSU6PGSoO6C+iorLEGbnvrPnge TuAhqBBPBjESHT2c/gAAAAAAAA== --------------ms030202080307040608080809-- From owner-ipsec@lists.tislabs.com Wed Mar 12 14:18:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CMIc310355; Wed, 12 Mar 2003 14:18:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23944 Wed, 12 Mar 2003 16:42:58 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66AC4@SARATOGA.netscreen.com> From: Gregory Lebovitz To: ipsec@lists.tislabs.com, "Darren Dukes (E-mail)" Subject: CP consensus Date: Wed, 12 Mar 2003 13:42:35 -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 CP was one of the Big 4 IKEv2 open issues that Barbara and Ted asked us all to address. Darren and I posted a draft to the list which explains how to use either DHCPv4 or RADIUS with CP for client configuration (we also have placeholder sections for LDAP, and DHCPv6 but need help filling those out). You can get the draft here: Based on these explanations, do we have consensus on CP? Gregory. !! NETSCREEN HAS MOVED !! New Contact Info: 408.543.8002 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.543.8002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ From owner-ipsec@lists.tislabs.com Wed Mar 12 15:28:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CNS6314314; Wed, 12 Mar 2003 15:28:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24164 Wed, 12 Mar 2003 17:52:04 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15983.47777.849792.382994@ryijy.hel.fi.ssh.com> Date: Thu, 13 Mar 2003 00:54:25 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: charlie_kaufman@notesdev.ibm.com Subject: draft-ietf-ipsec-ikev2-05.txt comments X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 68 min X-Total-Time: 86 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 1.4 The INFORMATIONAL Exchange ... > A node SHOULD regard half open connections as anomalous and audit I think we should talk about half closed connections instead of half open. > 2.8 Rekeying ... > If the two ends have the same lifetime policies, it is possible that > both will initiate a rekeying at the same time (which will result in > redundant SAs). To reduce the probability of this happening, the > timing of rekeying requests SHOULD be jittered (delayed by a random > amount of time after the need for rekeying is noticed). > > This form of rekeying may temporarily result in multiple similar SAs > between the same pairs of nodes. When there are two SAs eligible to > receive packets, a node MUST accept incoming packets through either > SA. An endpoint SHOULD wait a random amount of time before closing a > redundant SA to prevent cycling. Which one is redundant? What if both ends happen to select different SAs and destroy them at the same time? Or is it enough to have random wait and assume that only one of them will be destroyed and if both are destroyed then both ends will start creating the IPsec SA again when they want to send next packet. > 2.9 Traffic Selector Negotiation ... > To enable Bob to choose the appropriate range in this case, if Alice > has initiated the SA due to a data packet, Alice MAY include as the ^^^ I think that should be SHOULD. I.e if there is data packet put the first TS matching to it. If there is no data packet then you can leave it out. > first traffic selector in each of TSi and TSr a very specific traffic > selector including the addresses in the packet triggering the > request. In the example, Alice would include in TSi two traffic > selectors: the first containing the address range (10.2.16.43 - > 10.2.16.43) and the source port and protocol from the packet and the > second containing (10.2.16.0 - 10.2.16.255) with all ports and > protocols. She would similarly include two traffic selectors in TSr. ... > 2.15 Authentication of the IKE-SA ... > Optionally, messages 3 and 4 MAY include a certificate, or > certificate chain providing evidence that the key used to compute a > digital signature belongs to the name in the ID payload. The > signature or MAC will be computed using algorithms dictated by the > type of key used by the signer, an RSA-signed PKCS1-padded-hash for ^^^^ I assume this is the negotiatiated hash algorithm like it was in the IKEv1? > an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital > signature, or the negotiated PRF function for a pre-shared key. ... > 2.16 Extended Authentication Protocol Methods ... > The Initiator of an IKE-SA using EAP SHOULD be capable of extending > the initial protocol exchange to at least ten IKE_AUTH exchanges in > the event the Responder sends notification messages and/or retries > the authentication prompt. The protocol terminates when the Responder > sends the Initiator and EAP payload containing either a success or ^^^ typo. > failure type. ... > 2.19 Requesting an internal address on a remote network ... > This function provides address allocation to an IRAC trying to tunnel > into a network protected by an IRAS. Since the IKE_AUTH exchange > creates an IKE-SA and a CHILD-SA the IRAC MUST request the internal > address, and optionally other information concerning the internal > network, in the IKE_AUTH exchange. The may IRAS procure an internal ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? > 2.23 NAT Traversal > > NAT (Network Address Translation) gateways are a controversial > subject. This appendix briefly describes what they are and how they ^^^^^^^^ section ... > Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When > working through a NAT, it is generally better to pass IKE packets > over port 4500 because some older NATs modify IKE traffic on port 500 > in an attempt to transparently establish IPsec connections. Such NATs > may interfere with the straightforward NAT traversal envisioned by > this document, so an IPsec endpoint that discovers a NAT between it > and its correspondent SHOULD send all subsequent traffic to and from ^^^^^^ MUST The NAT-T protocol does not work with current NAT boxes if you try to run it over port 500. We must change the port from the 500 to 4500 immediately when we detect NAT. Also the NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP must be in the first two packets, so we can detect NAT before we start negotiating the child SA (especially if we want to add the ORIGINAL-ADDRESS notification or similar to support transport mode ESP). > port 4500, which all NATs should know run the NAT-friendly protocol. > > The specific requirements for supporting NAT traversal are listed > below. Support for NAT traversal is optional. In this section only, > requirements listed as MUST only apply to implementations supporting > NAT. ^^^ "NAT traversal". > IKE MUST listen on port 4500 as well as port 500. IKE MUST respond > to the IP address and port from which packets arrived. > > The IKE responder MUST include in its IKE_SA_INIT response Notify > payloads of type NAT-DETECTION-SOURCE-IP and NAT-DETECTION- > DESTINATION-IP. The IKE initiator MUST check these payloads if > present and if they do not match the addresses in the outer packet > MUST tunnel all future IKE, ESP, and AH packets associated with > this IKE-SA over UDP port 4500. I assume that this means that we do not negotiate the UDP-tunnel or UDP-transport mode as in IKEv1? This is fine with me, but I think we need some more text here to say so. Also we need some references to how to actually encapsulate the ESP packets etc. We also need to specify better how to detect which side is behind NAT (the UDP encapsulation protocol needs that information to enabled keepalives only from the host behind NAT, and the IKE needs that to enable implicit port updating if and only if the other end is behind NAT (it MUST NOT be enabled if the other end is not behind NAT)). I.e something like this: ---------------------------------------------------------------------- The IKE responder MUST include in its IKE_SA_INIT response Notify payloads of type NAT-DETECTION-SOURCE-IP and NAT-DETECTION- DESTINATION-IP. The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST switch to port 4500 for the IKE traffic and all IPsec SAs traffic (ESP packets) MUST use the UDP encapsulation over port 4500 as defined in the [Hutt02]. The changing to port 4500 MUST happen immediately after IKE_SA_INIT exchange, i.e IKE_AUTH payloads are sent with port 4500 (the reply to IKE_SA_INIT must come back to port 500, as specified by generic rule that reply back to address where you got the packet, and also because the mapping for the port 4500 is not yet open in the NAT box, i.e the first packet must come from the inside). The purpose of NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP notifications is twofold, It not only detects the presence of NAT between two IKE peers, it also detects where the NAT is. The location of the NAT device is important in that the keepalives need to initiate from the peer "behind" the NAT, and also so that implicit address updating is only enabled if and only if the other end is behind NAT. If the host detects it is behind the NAT, it should start sending keepalives as defined in the [Hutt02]. If the host detects that the other end is behind the NAT, then it SHOULD enable the implicit address updating for the other end, i.e if the any authenticated packet from the other end (IKE, UDP encapsulated ESP) is received whose source IP address and/or port is changed the other ends addresses for that IKE SA should be changed to that address (that address is used to when sending UDP encapsulated ESP packets to the other end and also for future rekeying and notifications). 2.24 NAT Traversal Implicit Address Updating There are cases where NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover from those hosts which are NOT behind NAT SHOULD use the last valid authenticated packet from the other end to determine which IP and port addresses should be used. The host behind dynamic NAT MUST NOT do this as otherwise it opens DoS attack possibility, and there is no need for that, because the IP address or port of other host will not change (it is not behind NAT). Keepalives cannot be used for this purposes as they are not authenticated, but any IKE authenticated IKE packet or UDP encapsulated ESP packet can be used to detect that the IP address or the port has changed. ---------------------------------------------------------------------- ... > All implementations of IKEv2 MUST include a management facility > that enables a user or system administratror to specify the Suite > IDs that are acceptable for use with IKE. Upon receipt of a > payload with a suite ID, the implementation must compare the > transmitted suite ID against those locally configured via the > management controls, to verify that the proposed suite is > acceptable based on local policy. The implementation MUST reject > key exchange payloads that are not authorized by these IKE suite ^^^^^^^^^^^^ "securety association payloads"? > 3.4 Key Exchange Payload > > The Key Exchange Payload, denoted KE in this memo, is used to > exchange Diffie-Hellman public numbers as part of a Diffie-Hellman > key exchange. The Key Exchange Payload consists of the IKE generic > header followed by the Diffie-Hellman public value itself. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload !C! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Suite-ID ! RESERVED (MBZ) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I do not really understand why do we have still these "RESERVED (MBZ)" fields here? They cannot be here for the alignment purposes because previous packets might not be aligned, thus the packet can be unaligned anyways. I actually think we should remove those which are not because of the IKEv1 compatibility (i.e Key exchange payload, auth payload, traffic selectors, configuration payload). > 3.7 Certificate Request Payload ... > Empty (zero length) CA names MUST NOT be generated and SHOULD be > ignored. This has already been talked earlier, nothing more now... ... > While intended to allow for future expansion, the only form of > certificate request currently defined is X.509 signing certificate > (4). For that type, the CA value is a concatenated list of SHA-1 > hashes of the public keys of trusted root CAs. How about type 11 (Raw RSA key)? I think it would be useful to send certificate request payload for type 11, and leave the contents empty (as it really does not matter). And types 1 (PKCS 7), 7 (CRL), 8 (ARL), 12, and 13 (Hash and URL types) should have same format as type 4. > 3.10 Notify Payload ... > o Protocol-Id (1 octet) - Specifies the protocol about which > this notification is being sent. For IKE-SA notifications, > this field MUST be zero (0). For notifications > concerning IPsec SAs this field will contain either (1) > to indicate ESP or (2) to indicate AH. For notifications > for which no protocol ID is relevant, this field MUST be > sent as zero and MUST be ignored. This is different, that what was used in the IKEv1. I think this should be mentioned in the appendix A (the payload looks same, but it isn't). > 3.10.1 Notify Message Types ... > INVALID-MESSAGE-ID 9 > > Sent when an IKE MESSAGE-ID outside the supported window is > received. This Notify MUST NOT be sent in a response; the > invalid request MUST NOT be acknowledged. Instead, inform > the other side by initiating an INFORMATIONAL exchange with > Notification data containing the four octet invalid MESSAGE- > ID. Sending this notification is optional, MUST be rate > limited, and MUST NOT be sent unless an IKE-SA exists to the > sending address and port. How can you get invalid message-id if you do not have IKE-SA, as the message id is property of the IKE-SA? Remove the ", and MUST NOT be sent unless an IKE-SA exists to the sending address and port.". > NAT-DETECTION-SOURCE-IP 24582 > > This notification is used to by its recipient to determine > whether the source is behind a NAT box. The data associated > with this notification is a SHA-1 digest of the SPIs, IP > address and port on which this packet was sent. There MAY > be multiple notify payloads of this type in a message if the > sender does not know which of several network attachments > will be used to send the packet. The recipient of this > notification MAY compare the supplied value to a hash of the > source IP address and port and if they don't match it MAY ^^^ > invoke NAT specific handling (like using UDP encapsulation > of ESP packets and subsequent IKE packets). Alternately, it > MAY reject the connection attempt if NAT traversal is not > supported. >From the "The recipient of this notification ..." change to this: ---------------------------------------------------------------------- The recipient of this notification MAY compare the supplied value to a hash of the source IP address and port and if they don't match it SHOULD enable NAT traversal (see section 2.23). Alternately, it MAY reject the connection attempt if NAT traversal is not supported. If this check fails it means that the other end is behind NAT and this end SHOULD enable the NAT Traversal implicit address updating (see section 2.24). ---------------------------------------------------------------------- > > NAT-DETECTION-DESTINATION-IP 24583 > > This notification is used to by its recipient to determine > whether it is behind a NAT box. The data associated with > this notification is a SHA-1 digest of the SPIs, IP address > and port to which this packet was sent. Again remove this: > The recipient of > this notification MAY compare the supplied value to a hash > of the destination IP address and port and if they don't > match it MAY invoke NAT specific handling (like using UDP > encapsulation of ESP packets and subsequent IKE packets). > Alternately, it MAY reject the connection attempt if NAT > traversal is not supported. and replace with this: ---------------------------------------------------------------------- The recipient of this notification MAY compare the supplied value to a hash of the destination IP address and port and if they don't match it SHOULD invoke NAT traversal (see section 2.23). Alternately, it MAY reject the connection attempt if NAT traversal is not supported. If this check fails it means that this end is behind NAT and this end should start sending keepalives as defined in the [Hutt02]. ---------------------------------------------------------------------- The [Hutt02] reference is to the [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", draft-ietf-ipsec-udp-encaps-05.txt, December 2002 > 3.11 Delete Payload > o Protocol-Id (1 octet) - Must be zero for an IKE-SA, 1 for > ESP, or 2 for AH. Again different from IKEv1. > 3.13 Traffic Selector Payload ... > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload !C! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Number of TSs ! RESERVED ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... > o RESERVED - This field MUST be sent as zero and MUST be ignored. Is there any reason for this reserved? > 3.13.1 Traffic Selector ... > The following table lists the assigned values for the Traffic > Selector Type field and the corresponding Address Selector Data. > > TS Type Value > ------- ----- > RESERVED 0 > > TS_IPV4_ADDR_RANGE 7 > TS_IPV6_ADDR_RANGE 8 As this is new payload, I see no use to try to reuse the numbers from the old identity type values. I think it is better to create new repository and renumber these to 1 and 2. > 3.15.1 Configuration Attributes ... > Multi- > Attribute Type Value Valued Length > ======================= ===== ====== ================== > INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets > INTERNAL_IP6_SUBNET 15 NO 17 octets I think those two should be multi-valued, at least the description later indicates that there might be multiple subnets behind (at least you can request multiple subnets). > o INTERNAL_IP4_SUBNET - The protected sub-networks that this > edge-device protects. This attribute is made up of two fields; > the first being an IP address and the second being a netmask. > Multiple sub-networks MAY be requested. The responder MAY > respond with zero or more sub-network attributes. ... > o INTERNAL_IP6_SUBNET - The protected sub-networks that this > edge-device protects. This attribute is made up of two fields; > the first being a 16 octet IPv6 address the second being a one > octet prefix-mask as defined in [ADDRIPV6]. Multiple > sub-networks MAY be requested. The responder MAY respond with > zero or more sub-network attributes. > 5 Security Considerations The NAT traversal needs some more entries here (copied from draft-ietf-ipsec-nat-t-ike-05): ---------------------------------------------------------------------- As the internal address space is only 32 bits, and it is usually very sparse, it might be possible for the attacker to find out the internal address used behind the NAT box by trying all possible IP-addresses and trying to find the matching hash. The port numbers are normally fixed to 500, and the SPIs can be extracted from the packet. This limits the hash calculations down to 2^32. If educated guess of use of private address space is done, then the number of hash calculations needed to find out the internal IP address goes down to the 2^24 + 2 * (2^16). Updating the IKE SA / ESP UDP encapsulation IP addresses and ports for each valid authenticated packet can cause DoS in case we have attacker who can listen all traffic in the network, and can change the order of the packet and inject new packets before the packet he has already seen. I.e attacker can take the authenticated packet from the host behind NAT, change the packet UDP source or destination ports or IP addresses and sent it out to the other end before the real packet reaches there. The host not behind the NAT will update its IP address and port mapping and sends further traffic to wrong host or port. This situation is fixed immediately when the attacker stops modifying the packets as the first real packet will fix the situation back to normal. Implementations SHOULD AUDIT the event every time the mapping is changed, as in normal case it should not happen that often. > 7 Acknowledgements > 8 References I think we need the section "Intellectual property rights" section because of the NAT traversal. ---------------------------------------------------------------------- 7. Intellectual property rights The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. ---------------------------------------------------------------------- > Appendix B: Diffie-Hellman Groups > B.1 Group 1 - 768 Bit MODP As there is no suite id allocated for this group, I think it should be removed from this document. If someone wants to use this group (i.e create new suite id), they can reference it from the RFC2409. > B.2 Group 2 - 1024 Bit MODP > B.3 Group 3 - 155 Bit EC2N > B.4 Group 4 - 185 Bit EC2N Same goes for groups 3 and 4. They are not used, so why are they added here. > B.5 Group 5 - 1536 Bit MODP -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Mar 12 15:40:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CNe3314660; Wed, 12 Mar 2003 15:40:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24216 Wed, 12 Mar 2003 18:08:29 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15983.48760.96383.959888@ryijy.hel.fi.ssh.com> Date: Thu, 13 Mar 2003 01:10:48 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: New 12288 and 16384 bit groups X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 16 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The 12288 bit group was fast to generate (only 13 days), the 16384 bit group took little longer (9.5 months), but finally they are here. Now you all can finally start using the full strength of the AES :-) Those primes have not been proven to be primes, only probabilistic tests have been done, and I do not intend to put them to draft-ietf-ipsec-ike-modp-groups-05. I would like to get them proven first, but that will probably take another year or so, provided that I can actually find windows machine running primo that stays stable for that long. I tried to prove the 12288 bit group earlier, but every time the machine or the program crashed before it get very far (about two weeks or so). ---------------------------------------------------------------------- XXX. 12288-bit MODP Group This group is assigned id XXX. This prime is: 2^12288 - 2^12224 - 1 + 2^64 * { [2^12158 pi] + 7425765 } Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9 22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71 60C980DD 98A573EA 4472065A 139CD290 6CD1CB72 9EC52A52 86D44014 A694CA45 7583D5CF EF26F1B9 0AD8291D A0799D00 022E9BED 55C6FA47 FCA5BB1A CA837645 6D98D948 79EE7E6D BFCD014B B1615599 14EC0B57 6A67E3E8 422E91E6 5BA141DA 92DE9C3A 6D6CCA51 36DD424B B1064988 EB5BA9AC 1269F7DF 673B982E 23FB6C99 BB2AA31C 5A6685FF D599149B 30AC67B8 464D80A9 5D42530A 681644D0 39060E8F 8FD52626 96D0A759 5AE3F935 A67DCFF5 A874A701 FBFA0C3D 534B4E39 BC095770 53374821 A11C3AC9 98E0BA71 8087B317 825A1ACF CFAEBBF2 4F25C605 1ADA9C28 5A1FCD61 14A838A1 ADE714C1 6A9401CD CF81E107 1FF7AB97 239F513B 15C5BCAE 2C0EB68D FC140303 7C0707C1 00802CFF EB833D46 8F2D5D2C 8960DE96 3702486F 746444FE 5F2A4BFD A50C91DC C8BD51C0 4EB97960 4DF0B6B7 322D5D8D 26BCF769 EA511851 83F400C3 BB3231CF A91D4790 788E3366 4EFA838B CCA02EE8 460FACCC 539522CE 13DB6E42 1BD08340 FD82812F CB2E04A4 0925DF1E 559E6C1C AF2BE26B F7A69DC7 F664C204 2CE2EB84 B733CFCB 95449C87 CB9ADC49 1406B779 A7E13361 DE9611C6 1D023685 EF27E6AF 3A52DF63 3B1EBB0E B6E1477E 98C250D9 B11930F4 BBC70611 CC857642 3750CECD C930AE85 84A85350 CA997114 54250000 84CEB937 5C77FE27 840C5395 606B1DF5 97C44666 C10D55BC 75E8F1DA CF04460E D6492942 7CA3F9BB 666DCDE2 FFFFFFFF FFFFFFFF The generator is: 2. XXX. 16384-bit MODP Group This group is assigned id XXX. This prime is: 2^16384 - 2^16320 - 1 + 2^64 * { [2^16254 pi] + 50814484 } Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9 22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71 60C980DD 98A573EA 4472065A 139CD290 6CD1CB72 9EC52A52 86D44014 A694CA45 7583D5CF EF26F1B9 0AD8291D A0799D00 022E9BED 55C6FA47 FCA5BB1A CA837645 6D98D948 79EE7E6D BFCD014B B1615599 14EC0B57 6A67E3E8 422E91E6 5BA141DA 92DE9C3A 6D6CCA51 36DD424B B1064988 EB5BA9AC 1269F7DF 673B982E 23FB6C99 BB2AA31C 5A6685FF D599149B 30AC67B8 464D80A9 5D42530A 681644D0 39060E8F 8FD52626 96D0A759 5AE3F935 A67DCFF5 A874A701 FBFA0C3D 534B4E39 BC095770 53374821 A11C3AC9 98E0BA71 8087B317 825A1ACF CFAEBBF2 4F25C605 1ADA9C28 5A1FCD61 14A838A1 ADE714C1 6A9401CD CF81E107 1FF7AB97 239F513B 15C5BCAE 2C0EB68D FC140303 7C0707C1 00802CFF EB833D46 8F2D5D2C 8960DE96 3702486F 746444FE 5F2A4BFD A50C91DC C8BD51C0 4EB97960 4DF0B6B7 322D5D8D 26BCF769 EA511851 83F400C3 BB3231CF A91D4790 788E3366 4EFA838B CCA02EE8 460FACCC 539522CE 13DB6E42 1BD08340 FD82812F CB2E04A4 0925DF1E 559E6C1C AF2BE26B F7A69DC7 F664C204 2CE2EB84 B733CFCB 95449C87 CB9ADC49 1406B779 A7E13361 DE9611C6 1D023685 EF27E6AF 3A52DF63 3B1EBB0E B6E1477E 98C250D9 B11930F4 BBC70611 CC857642 3750CECD C930AE85 84A85350 CA997114 54250000 84CEB937 5C77FE27 840C5395 606B1DF5 97C44666 C10D55BC 75E8F1DA CF04460E D6492942 7CA3F9BB 65FC7EFE A7AEAFCB 07854F1B A1B8D15C 3ABA5BEC 61839782 968F8AAC DDC7F9C7 138F41BE 8A59772E 6679C743 E00FA275 9499B209 4B93325E 27042CDA B18543AE A538BA9E 297F0F14 C7828B7D 3CBDD3A9 CD874ACF 464E4983 C6709E58 1488E9C2 3DC4C4AD BAEB7F9B BAB0C7D9 B8EF1165 699EF220 EC5FCDF4 40633FCA 30CCB77B EF9B16A9 59560861 5A2AE600 BBB3A943 F6CBE54E CABBDF6B 56DB8BE1 05486D8A 0A41D85C 3B3751DD 5867C544 04F32A0C 3AD86F65 80CD3F87 AA80D8F3 ED5CD724 131C288E 7567A782 F2EAB785 3BB321AF 18188B29 E72AD72A ECBCE11B 9922C7AB C66F7C32 A808DA6E 5956AED4 101A168C 8F0AAD2C CC67BA75 70086E3D E6D502C6 61D7E826 657DE65F 988F5F6A 3E0DE226 A5F8CB5D C47B64D7 C59A04A0 438D620A 71F987F5 A5B7B7E8 5E162EA6 55FD6129 46C89C98 E6E0F0FF C6B091A5 B36CC2BA D4CB8C15 23F65239 1B6F0C4A 163AFCBB CD31BFFA BF8A3B58 7B9F0F1C D7528536 7A192DF8 D0841745 080F84F8 117BB8AD A8EAAAFA B6DB13C5 7EB2D3F4 31D0BD10 BBDAAEED 5953CEC7 50734841 76079E67 A1A15371 F912D1DA 8F605894 33D8A87C 96E34991 BF2220E8 3071EDA8 DFC54930 DA72DD24 91E12282 D5A4ACA1 4256EFC0 2B465227 4518AC5D 08E08380 1610A34A 83157D7A 876B7D0F 88CFDC18 4CDCBC24 A364DF90 7597FB3C 5B088EF6 DF378DD6 72FB9D18 10217CA9 F39DCC9B A981E021 0985723A FFFFFFFF FFFFFFFF The generator is: 2. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Mar 12 16:04:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D049315512; Wed, 12 Mar 2003 16:04:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24270 Wed, 12 Mar 2003 18:32:04 -0500 (EST) Message-Id: <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Mar 2003 18:35:31 -0500 To: "Paul Knight" , jeremy.de_clercq@alcatel.be, Radia Perlman - Boston Center for Networking From: Mark Duffy Subject: RE: Another field for traffic selector? Cc: ipsec@lists.tislabs.com, "Marco Carugi" In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF048B54AC@zbl6c004.corpeast .baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Radia and others, I too would love to see a "VPN-ID" conveyable by IKEv2. RFC 2685 style VPN-ID (7 bytes) would seem a fine format. RFC 2547 Route Targets (8 bytes) are another possibility but given that RFC 2547 allows them to be a) different in one direction than in the other, and b) not have a 1:1 correspondence to what Radia has dubbed "customer intranets, C1, C2, C3, C4", I suspect it would be difficult to use them. Both types are (or can be) structured to be globally unique. An encoding that could transparently carry either would probably be wise at this point. On the question of verifying received packets to see that they match the VPN ID of the negotiated traffic selectors, this doesn't seem necessary to me, based on my motivations anyway :-). Especially given that there is currently no VPN ID field in the AH/ESP packet to be verified. The SPI can be used to deliver the received packets to the correct context, so this is an access control issue only. Perhaps then VPN-ID shouldn't be a Traffic Selector at all but rather some other attribute that can be bound to an SA. Sorry but I don't know enough about IKEv2 to know whether such a concept fits or not. In my mind this would be analogous to the "Remote End ID" AVP in l2tpv3, which can be used to bind a VPN ID to an l2tp session at the time the session is created. Just substitute "IPsec SA" for "l2tp session" to get the same ability with IPsec. --Mark From owner-ipsec@lists.tislabs.com Wed Mar 12 16:59:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D0xk317996; Wed, 12 Mar 2003 16:59:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24435 Wed, 12 Mar 2003 19:17:28 -0500 (EST) Message-Id: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> Date: Wed, 12 Mar 2003 19:20:35 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: Another field for traffic selector? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uB6XV1JvGNn7xVAeA6xq0w== 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 OK. Let me summarize the issue and what I'll propose as the solution, and try to answer all the comments. The issue: two firewalls F1 and F2 are creating VPN service on behalf of multiple customer nets (C1, C2, C3, C4), and the nets have the same IP address space (can be overlapping, can be identical ranges...point being that an IP address is no longer unique for F2 to know who to deliver a packet to). Let's say that all customer nets have the address range 10.1.1.0-10.1.2.255. Within a customer net the addresses are unique, but between them they are not. F1 and F2 are trusted to glue together the pieces of C1, C2, C3, and C4, but they won't know which is which based solely on addresses. ********* The proposed solution: 1. Use a "VPN-ID" which need not be globally unique. It only has to be such that F1 and F2 know which customer is being referred to. If F2 and F3 have a similar topology, they could, in theory, map customer net Cn to a different VPN-ID than Cn was assigned between F1 and F2. I prefer something where we don't need globally unique VPN-IDs, since it takes fewer bytes, and because I suspect fewer errors will be made when configuring a 2-byte quantity than a 7-byte quantity. I imagine the firewall administrator knowing that they have customers C1, C2, C3, and C4, and assigning them the numbers 71, 22, 3, 1, and it's just necessary that "C4" get assigned the same number at F2 as at F1. But if we have globally unique ones, that's fine too. Mark Duffy says if we want to copy RFC 2685 it would take 7 bytes, or to copy RFC 2547 would take 8 bytes). 2. The VPN-ID does NOT appear in data packets. It only exists in the IKE negotiation for the child-SA. "I'd like to create an ESP tunnel with SPI x, and IP address range k-j, with VPN-ID 7". 3. F2, when it receives a packet from F1 over SPI x, knows that it needs to get routed to the customer net that has been assigned VPN-ID 7. The VPN-ID is implicitly known based on the SPI. 4. Since on a particular SA, there should be no possibility of mixing traffic from multiple VPNs, the field shouldn't go in the traffic selector (which can appear multiple times if there are multiple IP ranges) but instead, I'd claim, in the "Traffic Selector Payload" (section 3.13 of IKEv2 spec). There's currently a 3-octet "reserved" field. I'd suggest using 2 octets of that for VPN-ID, and not have globally unique VPN-IDs (the assumption being that firewalls wouldn't have more than 2^16 VPNs...if not, we can use all 24 bits). ***************** Comments on various people's comments, if I think the above doesn't answer the comments... 1) packets do not need to be verified as coming on a particular virtual net. Assuming there is end-to-end IPsec as well as firewall-to-firewall, packets would just get lost if misrouted, since the key wouldn't work. If there is only firewall-to-firewall IPsec, then you were trusted the firewalls anyway, and the firewalls can (as they could without VPN-IDs) modify IP addresses, route between the VPNs, etc. 2) Why does it need to go into IKEv2?...because otherwise there's no way to route the packets, if the IP addresses in the customer nets overlap. Radia From owner-ipsec@lists.tislabs.com Wed Mar 12 17:08:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D18W318226; Wed, 12 Mar 2003 17:08:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24491 Wed, 12 Mar 2003 19:37:00 -0500 (EST) Message-ID: <3E6FD375.6010006@isi.edu> Date: Wed, 12 Mar 2003 16:40:21 -0800 From: Yu-Shun Wang Organization: USC /ISI User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030307 X-Accept-Language: en-us, en, zh-tw MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> In-Reply-To: <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Some questions regarding the practice of VPN-ID inline. Mark Duffy wrote: > Hi Radia and others, > > I too would love to see a "VPN-ID" conveyable by IKEv2. > > RFC 2685 style VPN-ID (7 bytes) would seem a fine format. > > RFC 2547 Route Targets (8 bytes) are another possibility but given that > RFC 2547 allows them to be a) different in one direction than in the > other, and b) not have a 1:1 correspondence to what Radia has dubbed > "customer intranets, C1, C2, C3, C4", I suspect it would be difficult to > use them. > > Both types are (or can be) structured to be globally unique. But how is that "global uniqueness" established in the first place? How is making sure that different VPNs using unique VPN-IDs different than making sure they use non-overlapping private (virtual) IP addresses? > An encoding that could transparently carry either would probably be wise > at this point. A different aspect of this discussion is about the scope of IPsec or IKE. The trend of "adding more fields for traffic selector" is like chasing a moving target. We now have TCP/UDP port numbers. Why not SCTP? Why not some other fields from some other transport protocols? Why not IP src-dest for IP-IP packets? How about GRE? RDP? Pick your favorite ones, they are all transport, aren't they? If we want to do transport layer security, shouldn't we resort to transport layer security protocols or mechanisms? Doing it in IP not only violates layering, and we end up inventing firewall again, only this time it's on routers (or "security gateways",) too! Are we defining firewall inside IPsec in the disguise of "traffic selectors"? If we are, it would not surprise me that advocates of some other transport protocols will want to get on the "traffic selector" thingy. (Well, we do IP-IP tunnels, so I think the inner IP source-destination address pair should be part of the "traffic selector", too. See how easy it is?) Cheers, yushun. > On the question of verifying received packets to see that they match the > VPN ID of the negotiated traffic selectors, this doesn't seem necessary > to me, based on my motivations anyway :-). Especially given that there > is currently no VPN ID field in the AH/ESP packet to be verified. The > SPI can be used to deliver the received packets to the correct context, > so this is an access control issue only. > > Perhaps then VPN-ID shouldn't be a Traffic Selector at all but rather > some other attribute that can be bound to an SA. Sorry but I don't know > enough about IKEv2 to know whether such a concept fits or not. In my > mind this would be analogous to the "Remote End ID" AVP in l2tpv3, which > can be used to bind a VPN ID to an l2tp session at the time the session > is created. Just substitute "IPsec SA" for "l2tp session" to get the > same ability with IPsec. > > --Mark -- ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California From owner-ipsec@lists.tislabs.com Wed Mar 12 17:10:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D1AC318275; Wed, 12 Mar 2003 17:10:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24494 Wed, 12 Mar 2003 19:37:02 -0500 (EST) Message-Id: <200303130040.h2D0eT011294@sydney.East.Sun.COM> Date: Wed, 12 Mar 2003 19:40:29 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: QoS and IKEv2 To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Fxjr/Ru4+kOZEAiIwDzMVg== 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 I don't think we need the uniquifier field! To summarize the problem again: This problem was brought up by Jess Alpert, which is that for various reasons (QOS being only one of them) F1 and F2 might want to create multiple SAs between them, and the traffic selectors on them might be the same, so they would look redundant. The current IKEv2 spec isn't too explicit about redundant SA's, which (before Jesse brought up the issue) we'd assumed were unintentional, due to creating SAs simultaneously in each direction, upon startup or upon rekeying. What the current spec says about redundant SAs is: "An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling." It doesn't say you have to close redundant SAs, or even that you should. Here's a proposal (but in the next paragraph I'll propose an even simpler solution): only the initiator of an SA is allowed to close an SA due to its looking redundant. (you're allowed to close it for some other reason, but not because it looks redundant). You still need to wait the random delay if you're closing an SA that you think is redundant with one created by the other end, so that the two ends don't create and delete a single SA simultaneously. But it allows one end to create as many SAs as it wants, and it doesn't require a uniquifier field. It's none of Bob's business why Alice wants to create n SAs all with the same traffic selectors. Bob has to accept traffic on any of them. This is a nice simple rule, and perhaps could be made even simpler by ignoring the case where redundant SAs get created because of simultaneous creation on the two ends. What's the harm of that case, really? Just occasionally you'll have more SAs than you intended, but not by a lot. Worst case is a factor of 2, but that seems unlikely. So, if we're willing to live with occasionally unintentionally redundant SAs due to simultaneous SA creation on the two ends, the rule would be simply that you do not close an SA unless: a) you initiated its creation b) it is redundant with another SA that you also created (and you don't actually need redundant SAs). then we don't need the uniquifier, and we don't need to worry about random delays and unintentionally closing both ends at once. Radia From owner-ipsec@lists.tislabs.com Wed Mar 12 18:53:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D2r4321572; Wed, 12 Mar 2003 18:53:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24910 Wed, 12 Mar 2003 21:21:02 -0500 (EST) Subject: Re: bidding down attach on NAT-T From: Steve Dispensa To: Derek Atkins Cc: Francis Dupont , Charlie_Kaufman@notesdev.ibm.com, Andrew Krywaniuk , ipsec@lists.tislabs.com In-Reply-To: References: <200303110855.h2B8trof023411@givry.rennes.enst-bretagne.fr> Content-Type: text/plain Organization: Positive Networks Message-Id: <1047522184.2078.25.camel@bilbo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Mar 2003 20:23:04 -0600 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 2003-03-11 at 09:35, Derek Atkins wrote: > Francis Dupont writes: > => I am not in favor of a MUST which has nothing to do with > > interoperability, IMHO we should let the market do its job... > > And I don't believe implementors who still have NAT-T support > > in their plans like to become not compliant. > > If we're not going to make sure that IKEv2 works across NAT, then I > think we should just go home now. Read after me: A road warrior has > no choice over whether there is a NAT is between them and their home > base. We should support this (EXTREMELY) common case. Let me second this. The market *is* doing its job - *lots* of remote worker products are moving to non-IPSEC encryption protocols. Look at URoam, Neoteris, Netilla, Aventail, Openreach, SafeWeb, Imperito, and lots of others (including us). And that's just the "remote work" industry. IPSEC (as implemented) is a massive pain wrt NAT. Even if users have a choice to remove their NAT (i.e. their home Linksys router), they usually don't want to or can't. I realize there are lots of other ways for IPSEC to be employed, but remote network access is certainly a key area that is hurting because of this. I strongly recommend a MUST for NAT-T. -sd From owner-ipsec@lists.tislabs.com Wed Mar 12 22:30:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D6UJ326236; Wed, 12 Mar 2003 22:30:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25450 Thu, 13 Mar 2003 01:01:25 -0500 (EST) Message-Id: <5.2.0.9.0.20030313010054.01e965b0@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 01:04:58 -0500 To: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com From: Mark Duffy Subject: RE: Another field for traffic selector? In-Reply-To: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia, thank you. What you propose sounds fine. However, I will make a small pitch here for the globally unique VPN-ID: In a PPVPN (provider provisioned VPN) view of things, the "firewalls" may be called "Provider Edge devices" (PEs). And a number of these may participate in a VPN membership discovery scheme in which they learn which VPNs (by VPN-ID) are "present" in which PE devices. Then they might initiate IKE signalling amongst themselves, using this super-duper capability to bind the SAs to VPN contexts. A 2-octet VPN-ID would be very limiting in this environment because a) a given network operator might service more than 64K VPNs, and b) if used in an interdomain environment it would not be practical to ensure the uniqueness of locally-significant 2-octet VPN-IDs. Globally unique RFC 2685 VPN-IDs would solve this nicely. BTW, the rfc 2685 VPN-IDs are hierarchically structured, consisting of an organization number, and a VPN number from a space maintained by that organization. So I don't think the length of the thing per se should lead to configuration errors -- in scenarios such as the one you describe, that don't need all that uniqueness, the high order bits would just be a constant. Looked at another way, if IKE permits an opaque 8 octet field, it can be up to whoever is operating the equipment what to use as VPN-IDs. They can still use e.g. 71, 22, 3, 1, etc. --Mark At 07:20 PM 3/12/2003 -0500, Radia Perlman - Boston Center for Networking wrote: >OK. Let me summarize the issue and what I'll propose >as the solution, and try to answer all the comments. > >The issue: two firewalls F1 and F2 are creating VPN service on behalf >of multiple customer nets (C1, C2, C3, C4), >and the nets have the same IP address >space (can be overlapping, can be identical ranges...point being >that an IP address is no longer unique for F2 to know who >to deliver a packet to). Let's say that all customer nets have >the address range 10.1.1.0-10.1.2.255. > >Within a customer net the addresses are unique, but between >them they are not. > >F1 and F2 are trusted to glue together the pieces of C1, C2, C3, and C4, >but they won't know which is which based solely on addresses. > >********* >The proposed solution: > >1. Use a "VPN-ID" which need not be globally unique. It only has > to be such that F1 and F2 know which customer is being referred to. > > If F2 and F3 have a similar topology, they could, in theory, map > customer net Cn to a different VPN-ID than Cn was assigned between > F1 and F2. > > I prefer something where we don't need globally unique VPN-IDs, since > it takes fewer bytes, and because I suspect fewer errors will be > made when configuring a 2-byte quantity than a 7-byte quantity. > I imagine the firewall administrator knowing that they have > customers C1, C2, C3, and C4, and assigning them the numbers > 71, 22, 3, 1, and it's just necessary that "C4" get assigned the > same number at F2 as at F1. > > But if we have globally unique ones, that's fine too. > Mark Duffy says if we want to copy RFC 2685 it would take > 7 bytes, or to copy RFC 2547 would take 8 bytes). > >2. The VPN-ID does NOT appear in data packets. It only exists in the > IKE negotiation for the child-SA. "I'd like to create an ESP tunnel > with SPI x, and IP address range k-j, with VPN-ID 7". > >3. F2, when it receives a packet from F1 over SPI x, knows that it > needs to get routed to the customer net that has been assigned VPN-ID 7. > The VPN-ID is implicitly known based on the SPI. > >4. Since on a particular SA, there should be no possibility of mixing > traffic from multiple VPNs, the field shouldn't go in the traffic > selector (which can appear multiple times if there are multiple > IP ranges) but instead, I'd claim, in the "Traffic Selector Payload" > (section 3.13 of IKEv2 spec). There's currently a 3-octet "reserved" > field. I'd suggest using 2 octets of that for VPN-ID, and not > have globally unique VPN-IDs (the assumption being that firewalls > wouldn't have more than 2^16 VPNs...if not, we can use all 24 bits). > >***************** >Comments on various people's comments, if I think the above doesn't >answer the comments... > >1) packets do not need to be verified as coming on a particular virtual >net. Assuming there is end-to-end IPsec as well as firewall-to-firewall, >packets would just get lost if misrouted, since the key wouldn't work. >If there is only firewall-to-firewall IPsec, then you were trusted >the firewalls anyway, and the firewalls can (as they could without >VPN-IDs) modify IP addresses, route between the VPNs, etc. > >2) Why does it need to go into IKEv2?...because otherwise there's >no way to route the packets, if the IP addresses in the customer >nets overlap. > >Radia From owner-ipsec@lists.tislabs.com Thu Mar 13 01:14:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D9El318089; Thu, 13 Mar 2003 01:14:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25843 Thu, 13 Mar 2003 03:45:27 -0500 (EST) From: "Yoav Nir" To: "'Radia Perlman - Boston Center for Networking'" , Subject: RE: QoS and IKEv2 Date: Thu, 13 Mar 2003 10:52:03 +0200 Message-ID: <008c01c2e93d$d1e88a70$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200303130040.h2D0eT011294@sydney.East.Sun.COM> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about rephrasing this: This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling. Into this: This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. A node MAY only close a redundant SA if it was the initiator in the negotiation that led to the creation of the SA. An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling. The only problem I see with this is that this requires that this introduces a concept of an "owner" of an SA. A node would have to keep track of which SAs belong to it (are "local") and which SAs do not (are "remote"). I think I can live with it, although I like the uniquifier idea better. I don't think we need a lot of uniquifier. One byte of the three reserved bytes in the TS payload would be enough. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Radia Perlman - The current IKEv2 spec isn't too explicit about redundant SA's, which (before Jesse brought up the issue) we'd assumed were unintentional, due to creating SAs simultaneously in each direction, upon startup or upon rekeying. What the current spec says about redundant SAs is: "An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling." It doesn't say you have to close redundant SAs, or even that you should. Here's a proposal (but in the next paragraph I'll propose an even simpler solution): only the initiator of an SA is allowed to close an SA due to its looking redundant. (you're allowed to close it for some other reason, but not because it looks redundant). You still need to wait the random delay if you're closing an SA that you think is redundant with one created by the other end, so that the two ends don't create and delete a single SA simultaneously. But it allows one end to create as many SAs as it wants, and it doesn't require a uniquifier field. It's none of Bob's business why Alice wants to create n SAs all with the same traffic selectors. Bob has to accept traffic on any of them. From owner-ipsec@lists.tislabs.com Thu Mar 13 02:08:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DA8k325962; Thu, 13 Mar 2003 02:08:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25991 Thu, 13 Mar 2003 04:40:52 -0500 (EST) Message-ID: <005901c2e945$2456aab0$96f1fea9@jnpr.net> From: "sankar ramamoorthi" To: "Radia Perlman - Boston Center for Networking" , References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> Subject: Re: Another field for traffic selector? Date: Thu, 13 Mar 2003 01:42:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 13 Mar 2003 09:44:29.0186 (UTC) FILETIME=[245C9E20:01C2E945] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Radia Perlman - Boston Center for Networking" To: Sent: Wednesday, March 12, 2003 4:20 PM Subject: RE: Another field for traffic selector? > Comments on various people's comments, if I think the above doesn't > answer the comments... > > 1) packets do not need to be verified as coming on a particular virtual > net. Assuming there is end-to-end IPsec as well as firewall-to-firewall, > packets would just get lost if misrouted, since the key wouldn't work. > If there is only firewall-to-firewall IPsec, then you were trusted > the firewalls anyway, and the firewalls can (as they could without > VPN-IDs) modify IP addresses, route between the VPNs, etc. This is how I understood the VPN-ID usage. What I was trying to point out that this IKEV1 went into a lot of effort to ensure negotiated traffic selector parameters are verified for each packet. This issue comes up periodically. There was a long thread last year questioning the need for TS. One of the points that was emphasized repeatedly was the access control features of ipsec. If we now make part of the negotiated traffic selector (VPN-ID) to be not sent on the wire but implicitly trust the peer to send the data through the right SA, are we loosening the access control mechanisms in ipsec? What does it imply? > > 2) Why does it need to go into IKEv2?...because otherwise there's > no way to route the packets, if the IP addresses in the customer > nets overlap. > > Radia > > > From owner-ipsec@lists.tislabs.com Thu Mar 13 06:35:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DEZE317585; Thu, 13 Mar 2003 06:35:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27273 Thu, 13 Mar 2003 09:02:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: Another field for traffic selector? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 12 Mar 2003 21:43:02 -0500 Disposition-Notification-To: "Claudio Lordello" Message-ID: <6157E7BE4F8B9548AAE5EB84DBF5D46A09919D@pion.jnpr.net> Thread-Topic: Another field for traffic selector? Thread-Index: AcLo/3ZAM7xdvTA/TCO42qTZEtcSqAAB+q1w From: "Claudio Lordello" To: "Radia Perlman - Boston Center for Networking" , X-OriginalArrivalTime: 13 Mar 2003 02:43:06.0314 (UTC) FILETIME=[469882A0:01C2E90A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA24971 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 3 years ago I authored a draft proposing an RFC-2685 style VPN-ID as an "qualifier" for the regular traffic selector identities of IKEv1 ("draft-lordello-ipsec-vpn-doi-01.txt"), and yes, I would love to see a VPN-ID as traffic selector "attribute". However, it seems to me that a globally unique VPN-ID, as described by RFC-2685, and in my original draft, would be more beneficial. What difference does the VPN-ID lengh makes if it will not appear on every packet anyways? Claudio. -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@sun.com] Sent: Wednesday, March 12, 2003 7:21 PM To: ipsec@lists.tislabs.com Subject: RE: Another field for traffic selector? OK. Let me summarize the issue and what I'll propose as the solution, and try to answer all the comments. The issue: two firewalls F1 and F2 are creating VPN service on behalf of multiple customer nets (C1, C2, C3, C4), and the nets have the same IP address space (can be overlapping, can be identical ranges...point being that an IP address is no longer unique for F2 to know who to deliver a packet to). Let's say that all customer nets have the address range 10.1.1.0-10.1.2.255. Within a customer net the addresses are unique, but between them they are not. F1 and F2 are trusted to glue together the pieces of C1, C2, C3, and C4, but they won't know which is which based solely on addresses. ********* The proposed solution: 1. Use a "VPN-ID" which need not be globally unique. It only has to be such that F1 and F2 know which customer is being referred to. If F2 and F3 have a similar topology, they could, in theory, map customer net Cn to a different VPN-ID than Cn was assigned between F1 and F2. I prefer something where we don't need globally unique VPN-IDs, since it takes fewer bytes, and because I suspect fewer errors will be made when configuring a 2-byte quantity than a 7-byte quantity. I imagine the firewall administrator knowing that they have customers C1, C2, C3, and C4, and assigning them the numbers 71, 22, 3, 1, and it's just necessary that "C4" get assigned the same number at F2 as at F1. But if we have globally unique ones, that's fine too. Mark Duffy says if we want to copy RFC 2685 it would take 7 bytes, or to copy RFC 2547 would take 8 bytes). 2. The VPN-ID does NOT appear in data packets. It only exists in the IKE negotiation for the child-SA. "I'd like to create an ESP tunnel with SPI x, and IP address range k-j, with VPN-ID 7". 3. F2, when it receives a packet from F1 over SPI x, knows that it needs to get routed to the customer net that has been assigned VPN-ID 7. The VPN-ID is implicitly known based on the SPI. 4. Since on a particular SA, there should be no possibility of mixing traffic from multiple VPNs, the field shouldn't go in the traffic selector (which can appear multiple times if there are multiple IP ranges) but instead, I'd claim, in the "Traffic Selector Payload" (section 3.13 of IKEv2 spec). There's currently a 3-octet "reserved" field. I'd suggest using 2 octets of that for VPN-ID, and not have globally unique VPN-IDs (the assumption being that firewalls wouldn't have more than 2^16 VPNs...if not, we can use all 24 bits). ***************** Comments on various people's comments, if I think the above doesn't answer the comments... 1) packets do not need to be verified as coming on a particular virtual net. Assuming there is end-to-end IPsec as well as firewall-to-firewall, packets would just get lost if misrouted, since the key wouldn't work. If there is only firewall-to-firewall IPsec, then you were trusted the firewalls anyway, and the firewalls can (as they could without VPN-IDs) modify IP addresses, route between the VPNs, etc. 2) Why does it need to go into IKEv2?...because otherwise there's no way to route the packets, if the IP addresses in the customer nets overlap. Radia From owner-ipsec@lists.tislabs.com Thu Mar 13 06:35:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DEZE317584; Thu, 13 Mar 2003 06:35:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27184 Thu, 13 Mar 2003 09:01:21 -0500 (EST) X-Originating-IP: [64.114.95.129] From: "Andrew Krywaniuk" To: charlie_kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Use of AES as prf in IKEv2 Date: Wed, 12 Mar 2003 20:09:03 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2003 01:09:03.0794 (UTC) FILETIME=[23644920:01C2E8FD] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some claim that the rationale for using AES for MAC'ing in addition to symmetric crypto is to reduce the code footprint. Using SHA to pre-hash the key would defeat that. If truncating the nonces is lossy (which is only true if your PRNG is bad) then why not just use XOR? [Assume 128 bit AES.] Divide up the keystream into 128 bit blocks and XOR them all together. If someone is going to claim that XORing the 2 nonces together is insecure, then you could still XOR the nonces into two separate 64 bit blocks. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Thu Mar 13 06:35:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DEZF317606; Thu, 13 Mar 2003 06:35:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27135 Thu, 13 Mar 2003 09:00:16 -0500 (EST) Date: Wed, 12 Mar 2003 15:23:00 -0700 From: Shane Amante To: Paul Knight Cc: jeremy.de_clercq@alcatel.be, Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com, Marco Carugi Subject: Re: Another field for traffic selector? Message-ID: <20030312222300.GI4806@ns1.castlepoint.net> Mail-Followup-To: Paul Knight , jeremy.de_clercq@alcatel.be, Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com, Marco Carugi References: <6204FDDE129D364D8040A98BCCB290EF048B54AC@zbl6c004.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF048B54AC@zbl6c004.corpeast.baynetworks.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Instead of creating another field in the IPSec header, why can't the receiver use the IPSec SPI be used to direct the traffic into the appropriate VPN context? For the record, I also support deployment of signalling VPN-ID's within IKEv2. One example of where signalling VPN-ID's is most useful is multi-user/customer IPSec GW's, where: a) there is only a single, unique public IP address on the public side of the chassis; and, b) there are multiple customers on the private side of the chassis, each of which has the same, overlapping RFC1918 address space, e.g.: C1-private: 192.168.1.0/24 C2-private: 192.168.1.0/25 C3-private: 192.168.0.0/23 ... NOTE: All three of the above customers/contexts ARE NOT related to one another, e.g.: do not share security policies, etc. As it stands now, the only way to overcome the above limitation (aside from proprietary signalling) is to create a unique, public IP address per customer/context, which: a) hurts SP's that strive to conserve their public IP addresses; and, b) is no different than deploying a whole IPSec GW per customer. -shane On Wed, Mar 12, 2003 at 12:34:09PM -0500, Paul Knight wrote: > Hi Radia and Jeremy, > > I'll second Jeremy's support for this. The need for including something > like a VPN-ID as a traffic selector has been discussed in at least two > individual drafts in the PPVPN WG: > - draft-knight-ppvpn-vr-protocol-00.txt (Protocol Actions for Virtual Router > VPNs) > - draft-duffy-ppvpn-ipsec-vlink-00.txt (Framework for IPsec Protected > Virtual Links for PPVPNs) > > I would definitely support adding extensibility or flexibility to the > encoding of the traffic selector, since even for VPN-ID, there is still not > a universal format. (RFC 2685 specifies 7 bytes; RFC 2547 has a Target VPN > or Route Target which is 8 bytes.) I think the field should accommodate > these sizes when VPN-ID is used as a selector. It may be possible to use a > smaller field, but the signaling to negotiate a smaller field and ensure its > uniqueness would probably be more burdensome than simply having a field > which can accommodate current VPN-IDs. > > Draft-knight-ppvpn-vr-protocol-00.txt suggests: > The Traffic Selector (TS) payload proposed in [IKE-V2] may be > suitable for this purpose [carrying the VPN-ID]. The TS Payload > specifies address ranges, > and thus does not appear to be a clear fit for specifying a single > VPN-ID, but it may be possible to define an additional TS Type with > semantics suitable for the VPN-ID. > > Also, as a quick response to Sankar's question: > (How are the packets coming out of a tunnel verified to ensure they match > the negotiated virtual net? [....] Is Virtual net field expected to be part > of ipsec headers also?) > > Yes, I think including a VPN-ID in the IPsec header is needed to map the > packets to the VPN. > > Regards, > Paul > > "The world is a jungle in general, and the networking game contributes many > animals." - RFC 826 > > > -----Original Message----- > > From: jeremy.de_clercq@alcatel.be > > [mailto:jeremy.de_clercq@alcatel.be] > > Sent: Wednesday, March 12, 2003 3:19 AM > > To: Radia Perlman - Boston Center for Networking > > Cc: ipsec@lists.tislabs.com; Carugi, Marco [CTF:0000:EXCH] > > Subject: Re: Another field for traffic selector? > > > > > > > > > I'm not sure what to call it, or what size it ought to be. Other > > > protocols need to solve this problem. The "VLAN tag" is > > used in 802. > > > "Partition ID" is used in infiniband. I've heard the name "virtual > > > router ID" for something, but I think that's a terrible name (since > > > it's a virtual net, not a virtual router). If anyone can suggest an > > > already-recognized name for this concept, an > > already-recognized size > > > of the field, and an already-recognized numbering scheme, we should > > > adopt it. Otherwise, I'd suggest the name "virtual net", > > size 2 bytes, > > > and a numbering scheme that is local to F1 and F2 (someone > > > would configure it compatibly at the two ends and map it > > > to specific customer nets). > > > > For some VPN approaches, the PPVPN WG refers to the "Virtual > > Private Networks Identifier" defined in RFC 2685. > > > > > So, there are two issues: > > > a) I think we need to add this field to the traffic selector in IKE > > > > 1. I support this idea, and > > 2. if it is accepted by the ipsec community, I propose to > > allign with the ppvpn wg. > > > > thanks, > > Jeremy. > > > > > > > b) If at this late date extra things (this plus the uniquifier) are > > > coming up as needing to be in the traffic selector, perhaps the > > > encoding of traffic selector should be more flexible, so that new > > > fields can be added in the future. > > > > > > Radia > > From owner-ipsec@lists.tislabs.com Thu Mar 13 06:35:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DEZE317586; Thu, 13 Mar 2003 06:35:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27324 Thu, 13 Mar 2003 09:03:27 -0500 (EST) Message-ID: <3E707945.CE5851E5@steria.se> Date: Thu, 13 Mar 2003 13:27:49 +0100 From: Joachim =?iso-8859-1?Q?Abrahms=E9n?= Organization: IT Security, Steria AB X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec mailing list Subject: DPD message format Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by steria.se id NAA43176 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id HAA26384 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi everybody, I have two questions regarding the DPD-draft. Question 1: In draft-ietf-ipsec-dpd-02.txt the following is stated: 6.2 Message Exchanges The DPD exchange is a bidirectional (HELLO/ACK) Notify message. The exchange is defined as: Sender Responder -------- ----------- HDR*, NOTIFY(R-U-THERE), HASH ------> <------ HDR*, NOTIFY(R-U-THERE- ACK), HASH But RFC 2409 section 5.7 says: Initiator Responder ----------- ----------- HDR*, HASH(1), N/D --> i.e. the Hash-payload is before the Notification-payload, not after as the DPD-draft suggests. Those of you who have implemented the DPD-draft, did you follow the example of the DPD-draft or RFC 2409? We intend to encode the DPD-messages as RFC 2409 suggest. Will this break any existing DPD-implemetations? Question 2: Although now stated explicitly, I assume that the R-U-THERE and R-U-THERE-ACK have unrelated message-Ids in the ISAKMP-header. Is that correct? I think I would have treaten it as an exchange having the same message-Id in the same sense QM has, and the IV calculated as for QM, but that would of cause break what RFC's says about indepentent message-Id of Informational messages. Any other reason for not doing so? Is the role of the sequence number in the payload data to be able to map the R-U-THERE-ACK to the corresonding R-U-THERE, as the message-Id otherwize (if they were equal) would? Best regards Joachim AbrahmsÈn Steria AB From owner-ipsec@lists.tislabs.com Thu Mar 13 09:05:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DH5C323183; Thu, 13 Mar 2003 09:05:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28167 Thu, 13 Mar 2003 11:29:33 -0500 (EST) Date: Thu, 13 Mar 2003 11:32:37 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Another field for traffic selector? In-Reply-To: <3E6FD375.6010006@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Mar 2003, Yu-Shun Wang wrote: > Are we defining firewall inside IPsec in the disguise of "traffic > selectors"? The IPsec SPD is deliberately meant as a specification of a minimal firewall mechanism. Firewalling is an important part of IP security, after all. (IPsec is more than just encryption, although encryption tends to get most of the attention.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 13 10:56:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DIuH302394; Thu, 13 Mar 2003 10:56:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28392 Thu, 13 Mar 2003 13:16:05 -0500 (EST) Message-Id: <5.2.0.9.0.20030313130251.01d843d0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 13:14:32 -0500 To: Yu-Shun Wang , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: Another field for traffic selector? In-Reply-To: <3E6FD375.6010006@isi.edu> References: <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:40 PM 3/12/2003 -0800, Yu-Shun Wang wrote: >Hi, > >Some questions regarding the practice of VPN-ID inline. > >Mark Duffy wrote: >>Hi Radia and others, >>I too would love to see a "VPN-ID" conveyable by IKEv2. >>RFC 2685 style VPN-ID (7 bytes) would seem a fine format. >>RFC 2547 Route Targets (8 bytes) are another possibility but given that >>RFC 2547 allows them to be a) different in one direction than in the >>other, and b) not have a 1:1 correspondence to what Radia has dubbed >>"customer intranets, C1, C2, C3, C4", I suspect it would be difficult to >>use them. >>Both types are (or can be) structured to be globally unique. > >But how is that "global uniqueness" established in the first place? Through a (hierarchical) regime of number assignment. >How is making sure that different VPNs using unique VPN-IDs different >than making sure they use non-overlapping private (virtual) IP addresses? The customers of the sort we are talking about here are *already* using overlapping addresses. Unique VPN-IDs can be applied now, after the fact so to speak, to create unique (VPN-ID + IP address)s. Not only does it let them continue to use the addresses they are using, it lets them continue to have private to themselves the complete address space they have now. >>An encoding that could transparently carry either would probably be wise >>at this point. > >A different aspect of this discussion is about the scope of IPsec or >IKE. The trend of "adding more fields for traffic selector" is like >chasing a moving target. We now have TCP/UDP port numbers. Why not >SCTP? Why not some other fields from some other transport protocols? >Why not IP src-dest for IP-IP packets? How about GRE? RDP? Pick your >favorite ones, they are all transport, aren't they? As far as your question here about IPsec supporting selectors for TCP, UDP and not for other protocols, I'll leave that to others. The current issue about VPN ID is about something else entirely. It is a about when there are multiple independent contexts of (TCP, UDP, whatever over) IP and we want to bind an SA to one of those contexts. >If we want to do transport layer security, shouldn't we resort to >transport layer security protocols or mechanisms? Doing it in IP >not only violates layering, and we end up inventing firewall again, >only this time it's on routers (or "security gateways",) too! > >Are we defining firewall inside IPsec in the disguise of "traffic >selectors"? If we are, it would not surprise me that advocates of >some other transport protocols will want to get on the "traffic >selector" thingy. (Well, we do IP-IP tunnels, so I think the >inner IP source-destination address pair should be part of the >"traffic selector", too. See how easy it is?) > >Cheers, > >yushun. From owner-ipsec@lists.tislabs.com Thu Mar 13 11:02:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DJ2G302552; Thu, 13 Mar 2003 11:02:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28414 Thu, 13 Mar 2003 13:26:19 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15984.52758.635053.55854@thomasm-u1.cisco.com> Date: Thu, 13 Mar 2003 10:29:42 -0800 (PST) To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: RE: Another field for traffic selector? In-Reply-To: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking writes: > 2) Why does it need to go into IKEv2?...because otherwise there's > no way to route the packets, if the IP addresses in the customer > nets overlap. This evades the real question. Why does this need to be part of the base spec? There's lots of world hunger that IKEv2 doesn't solve. Why can't this be deferred for later consideration, rather than an ill-advised last minute addition? If IKEv2 does not lend itself to such additions, maybe we asking ourselves how we can make IKEv2 more amenable to these kinds of additions rather than loading up the kitchen sink blindly. Mike From owner-ipsec@lists.tislabs.com Thu Mar 13 11:44:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DJi3304059; Thu, 13 Mar 2003 11:44:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28659 Thu, 13 Mar 2003 14:12:55 -0500 (EST) Message-Id: <5.2.0.9.0.20030313133850.01e7f9c8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 14:16:45 -0500 To: Shane Amante , Paul Knight From: Mark Duffy Subject: Re: Another field for traffic selector? Cc: jeremy.de_clercq@alcatel.be, Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com, Marco Carugi In-Reply-To: <20030312222300.GI4806@ns1.castlepoint.net> References: <6204FDDE129D364D8040A98BCCB290EF048B54AC@zbl6c004.corpeast.baynetworks.com> <6204FDDE129D364D8040A98BCCB290EF048B54AC@zbl6c004.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Shane, I think your point here raises an interesting question. When one uses a unique public IP address per customer/context (as you describe below) one ends up with separate IKE SAs, and probably separate identities, used for each customer/context. OTOH, putting the VPN ID in the Traffic Selector Payload as proposed in this thread binds each child SA to a VPN; the IKE SA is shared across multiple VPNs. Another possibility that presents itself is putting the VPN ID attribute in some payload that binds it to the IKE SA. (HDR payload? An optional VPN-ID payload?) This would make it more similar to the way you describe below, only not require all the separate IP addresses. Which is better? Sharing an IKE SA across VPN contexts probably scales better and is probably sufficient when say a service provider is operating the SGs at both ends. However, for the case of multi-user/customer IPSec GW's, especially where the remote peer might be a single-user GW or a multi-user one operated by a different service provider, it might be the case that each user/customer would want to use their own identity. --Mark At 03:23 PM 3/12/2003 -0700, Shane Amante wrote: [snip] >One example of where signalling VPN-ID's is most useful >is multi-user/customer IPSec GW's, where: >a) there is only a single, unique public IP address on the public side >of the chassis; and, >b) there are multiple customers on the private side of the chassis, >each of which has the same, overlapping RFC1918 address space, e.g.: > C1-private: 192.168.1.0/24 > C2-private: 192.168.1.0/25 > C3-private: 192.168.0.0/23 > ... >NOTE: All three of the above customers/contexts ARE NOT related to >one another, e.g.: do not share security policies, etc. > >As it stands now, the only way to overcome the above limitation (aside >from proprietary signalling) is to create a unique, public IP address >per customer/context, which: a) hurts SP's that strive to conserve >their public IP addresses; and, b) is no different than deploying a >whole IPSec GW per customer. > >-shane From owner-ipsec@lists.tislabs.com Thu Mar 13 12:01:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DK1k304589; Thu, 13 Mar 2003 12:01:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28739 Thu, 13 Mar 2003 14:31:32 -0500 (EST) Cc: charlie_kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Message-ID: <3E70D221.8010600@bell-labs.com> Date: Thu, 13 Mar 2003 13:46:57 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Andrew Krywaniuk Original-CC: charlie_kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Use of AES as prf in IKEv2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > Some claim that the rationale for using AES for MAC'ing in addition to > symmetric crypto is to reduce the code footprint. Using SHA to pre-hash > the key would defeat that. Yes to both. We could use AES for hashing as well. > If truncating the nonces is lossy (which is only true if your PRNG is > bad) then why not just use XOR? [Assume 128 bit AES.] Divide up the > keystream into 128 bit blocks and XOR them all together. ??? > If someone is going to claim that XORing the 2 nonces together is > insecure, then you could still XOR the nonces into two separate 64 bit > blocks. This sounds much better. From owner-ipsec@lists.tislabs.com Thu Mar 13 12:01:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DK1k304590; Thu, 13 Mar 2003 12:01:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28725 Thu, 13 Mar 2003 14:30:28 -0500 (EST) Message-ID: <3E70D2B3.3080300@isi.edu> Date: Thu, 13 Mar 2003 10:49:23 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030305 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Mark Duffy CC: Yu-Shun Wang , ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> <5.2.0.9.0.20030313130251.01d843d0@email> In-Reply-To: <5.2.0.9.0.20030313130251.01d843d0@email> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030505040508020901090204" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030505040508020901090204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Duffy wrote: > >> How is making sure that different VPNs using unique VPN-IDs different >> than making sure they use non-overlapping private (virtual) IP addresses? > > The customers of the sort we are talking about here are *already* using > overlapping addresses. Unique VPN-IDs can be applied now, after the > fact so to speak, to create unique (VPN-ID + IP address)s. Not only > does it let them continue to use the addresses they are using, it lets > them continue to have private to themselves the complete address space > they have now. The notion of VPN ID seems to be tied to the PPVPN view where your VPNs start and end at the first-hop gateway, and hosts connected to it are part of only one VPN at a given time. Routers have to change to support VPN IDs (but that may be OK), current host implementations just work. Once you extend the notion of VPN to include both hosts and routers, i.e. when your hosts can be part of more than one VPN at any given time, EVERY node will need to be modified to understand VPN IDs. This is when the VPN ID becomes equivalent to an extended, unique, globally managed address space. Lars -- Lars Eggert USC Information Sciences Institute --------------ms030505040508020901090204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDMxMzE4NDkyM1owIwYJKoZIhvcNAQkEMRYEFMD67G2mLCvDcmI+G6n3 14c2faI3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAijXL1KEvVc6h4a73cU0xuGhiwS0IERYk58Ia e/+lKaWO6YJpKDh53/Dk3SDF8VKEAU6a7PAKo2tXKntAezV0vWdE4QBK/AmsPmLSE4gJHi1o t9kxj3u+o9Ops9UVQCS47t6Ntqzw+/W61MNo7B7Eu7qy15fZlxCZD7R1MAPds4XKGL6vYMoj UTfaSlp2bLyfJRC0fmb735S3Nu20WdAB8IJ2nDmy3KlDmbB74QrKJzciKQOt5bKdFxAvWsCT E4MaO1wjFViFJv6HdDWKWIiwup373N+7AKqsADTB3L+L2kpB9mBpolXhxGvqU++WRAUyl1Oq 5d3204JBtYeuyAfWiwAAAAAAAA== --------------ms030505040508020901090204-- From owner-ipsec@lists.tislabs.com Thu Mar 13 12:02:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DK2v304638; Thu, 13 Mar 2003 12:02:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28743 Thu, 13 Mar 2003 14:31:34 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3E70D2FF.4010600@bell-labs.com> Date: Thu, 13 Mar 2003 13:50:39 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com Original-CC: ipsec@lists.tislabs.com Subject: Re: Use of AES as prf in IKEv2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com wrote: > Hugo pointed out that the IKEv2 spec assumes that prf functions accept > variable (and arbitrary) size keys, which won't always be the case. I > thought the question was only theoretical because HMAC does and that was > the only prf we defined. (:-) Defined for now! > But I notice that we added an IKE Suite #5, which specifies: "AES-CBC MAC + > XCBC integrity and prf". I'm having multiple problems parsing that. I think > I know what AES-CBC MAC is as an integrity protection function. But what > does "+ XCBC" mean and how do we feed two variable length inputs into this > thing for the purpose of doing key expansion. I think Suite #5 is a Good thing, but requires details to be fleshed out. > And I'll bet no one really thought about how to use it with a variable > length key for key expansion. IKEv2 computes SKEYSEED = prf ( Ni | Nr , > g^xy). Nonces are variable length. We could specify (as Hugo recommended) > that each nonce be truncated at half the fixed key size. I'd be happier > using SHA-1(Ni | Nr) truncated as the key. I'd be happier still saying that > even if we're using AES-CBC + XCBC for integrity we still use SHA-1 as our > prf. What do others think? I think that using SHA in this context sucks. But am not ready YET to offer an acceptable variable-input AES-based hash. Talk to y'all at the meeting. From owner-ipsec@lists.tislabs.com Thu Mar 13 12:21:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DKLX305253; Thu, 13 Mar 2003 12:21:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28841 Thu, 13 Mar 2003 14:53:24 -0500 (EST) Message-ID: <3E70E44E.6050805@isi.edu> Date: Thu, 13 Mar 2003 12:04:30 -0800 From: Yu-Shun Wang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> <5.2.0.9.0.20030312175021.034cc410@email.quarrytech.com> <5.2.0.9.0.20030313130251.01d843d0@email> In-Reply-To: <5.2.0.9.0.20030313130251.01d843d0@email> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: (The part about the usage scenario probably belongs to ppvpn mailing list.) >> A different aspect of this discussion is about the scope of IPsec or >> IKE. The trend of "adding more fields for traffic selector" is like >> chasing a moving target. We now have TCP/UDP port numbers. Why not >> SCTP? Why not some other fields from some other transport protocols? >> Why not IP src-dest for IP-IP packets? How about GRE? RDP? Pick your >> favorite ones, they are all transport, aren't they? > > > As far as your question here about IPsec supporting selectors for TCP, > UDP and not for other protocols, I'll leave that to others. The current > issue about VPN ID is about something else entirely. It is a about when > there are multiple independent contexts of (TCP, UDP, whatever over) IP > and we want to bind an SA to one of those contexts. That may be true, but if the proposed solution is to "ADD" another field to the IPsec traffic selector (can we call it IPsec-firewall?), the my question stands: are we opening the door to let other IP options and/or transport protocol fields to be considered for IPsec traffic selectors? IMHO, this not only affects IKE, the implication affects IPsec (2401bis?) as a whole. yushun. >> If we want to do transport layer security, shouldn't we resort to >> transport layer security protocols or mechanisms? Doing it in IP >> not only violates layering, and we end up inventing firewall again, >> only this time it's on routers (or "security gateways",) too! >> >> Are we defining firewall inside IPsec in the disguise of "traffic >> selectors"? If we are, it would not surprise me that advocates of >> some other transport protocols will want to get on the "traffic >> selector" thingy. (Well, we do IP-IP tunnels, so I think the >> inner IP source-destination address pair should be part of the >> "traffic selector", too. See how easy it is?) >> >> Cheers, >> >> yushun. From owner-ipsec@lists.tislabs.com Thu Mar 13 12:26:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DKQ6305415; Thu, 13 Mar 2003 12:26:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28865 Thu, 13 Mar 2003 14:56:35 -0500 (EST) From: "Geoffrey Huang" To: , Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 Date: Thu, 13 Mar 2003 11:59:59 -0800 Message-ID: <005001c2e99b$2095dc10$e1a36b80@amer.cisco.com> 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.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Dan Harkins' previous comment that the responder can pick how to authenticate itself based on the initiator's identity. Since both the IDi and the optional IDr come at the same time, I don't see how including the optional payload buys you anything. The difference between IKE and SSL is that SSL doesn't use the identity of the "initiator" to demux its own possible identities. A related question I have is what happens if the responder sends an identity that's different from the IDr requested by the initiator? -g > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of > Charlie_Kaufman@notesdev.ibm.com > Sent: Monday, March 03, 2003 6:50 PM > To: ipsec@lists.tislabs.com > Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 > > > > > > > I think in the discussion of this feature, there has been > some confusion > concerning what it's for and what endpoints MUST, SHOULD, and > MAY do to > follow the spec. > > The sole addition to the protocol is that the initiator MAY > in Message 3 > include the DNS name of the node he's trying to connect to. > The responder > MUST ignore the value supplied unless he has multiple > identities by which > he can authenticate, in which case he SHOULD select an > identity based on > the supplied DNS name. So most implementations of responders > will ignore > the value and most implementations of initiators will either > not supply it > or will drop in a DNS name. > > The motivation for this feature springs from a problem > commonly experienced > with HTTP over SSL. It is fairly common for "vanity" web sites like > www.batmanforever.com (which existed when the movie came out > and may still) > to be hosted on a machine that hosts a lot of other web > sites. In the early > days, this was implemented by having a whole range of IP > addresses routed > to the one server, and that server would decide which content > to send you > according to the IP address to which the request was > directed. This became > sufficiently wasteful of scarce IPv4 addresses and HTTP was > modified to > optionally include the DNS name of the web site in the > request so that the > vanity web sites sharing a server could also share an IP address. But > today, this solution is not available to web sites that use > SSL, because > the SSL server has to authenticate before it gets the HTTP > request. So they > continue to require a separate IP address for each virtual server they > host. > > By putting this extra field in Message 3, an implementation > could have a > single IP address but many DNS names and authenticate as > being the node the > initiator was trying to talk to. It would be good practice > for initiators > that are looking up the responder by DNS name to include the > name in case > the responder is so configured. > > --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@lists.tislabs.com Thu Mar 13 12:32:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DKWv305849; Thu, 13 Mar 2003 12:32:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28901 Thu, 13 Mar 2003 15:03:48 -0500 (EST) From: "Geoffrey Huang" To: Subject: Using config mode together with extended authentication Date: Thu, 13 Mar 2003 12:07:38 -0800 Message-ID: <005301c2e99c$3207b0d0$e1a36b80@amer.cisco.com> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've looked over the sections regarding EAP/XAuth and Config mode in IKEv2-05, and there are packet descriptions in each section describing what IKE looks like if either one is used. But what happens if you do the cfg request and EAP? Based on the EAP description, the responder sends an EAP request in the 4th message, starting off an EAP exchange. But the Cfg Request description says that the initiator sends a CP payload before the SAi2 payload. Does this mean that if we do both CP and EAP it looks like: INIT RESPO msg1 ----> <---- msg2 msg3+CP ----> <---- msg4+EAP EAP ----> <---- CP reply, etc. Maybe it's described in the document, and I just missed it. -g From owner-ipsec@lists.tislabs.com Thu Mar 13 13:49:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DLneg01599; Thu, 13 Mar 2003 13:49:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29292 Thu, 13 Mar 2003 16:23:31 -0500 (EST) From: "Geoffrey Huang" To: , Cc: "'Charlie Kaufman'" Subject: RE: Using config mode together with extended authentication Date: Thu, 13 Mar 2003 13:26:58 -0800 Message-ID: <005c01c2e9a7$472eb9d0$e1a36b80@amer.cisco.com> 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.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK - that's what I thought, that CP brackets the EAP exchange. I just wanted to be sure. It'd be good to add the example below to the document. -g > -----Original Message----- > From: Darren Dukes [mailto:ddukes@cisco.com] > Sent: Thursday, March 13, 2003 1:20 PM > To: Geoffrey Huang; ipsec@lists.tislabs.com > Cc: Charlie Kaufman > Subject: RE: Using config mode together with extended authentication > > > In the scenario you mention the CP is sent before SAi2 and > SAr2. So the > initiator sends CP(CFG_REQUEST) in the first IKE_AUTH exchange and the > responder sends CP(CFG_REPLY) in the last IKE_AUTH exchange. > Using the EAP > example from the IKEv2-05 draft and inserting CP it would > look like this... > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > HDR, SK {IDi, [CERTREQ,] [IDr,] > [CP], SAi2, TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP } > HDR, SK {EAP, [AUTH] } --> > <-- HDR, SK {EAP, [AUTH], > [CP], SAr2, TSi, TSr } > > > Charlie, could you add the CP payloads to the example for EAP > so this is > clearer? > > Darren > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Geoffrey Huang > > Sent: Thursday, March 13, 2003 3:08 PM > > To: ipsec@lists.tislabs.com > > Subject: Using config mode together with extended authentication > > > > > > I've looked over the sections regarding EAP/XAuth and Config mode in > > IKEv2-05, and there are packet descriptions in each section > describing > > what IKE looks like if either one is used. But what > happens if you do > > the cfg request and EAP? Based on the EAP description, the > responder > > sends an EAP request in the 4th message, starting off an > EAP exchange. > > > > But the Cfg Request description says that the initiator sends a CP > > payload before the SAi2 payload. Does this mean that if we > do both CP > > and EAP it looks like: > > > > INIT RESPO > > msg1 ----> > > <---- msg2 > > msg3+CP ----> > > <---- msg4+EAP > > EAP ----> > > <---- CP reply, etc. > > > > Maybe it's described in the document, and I just missed it. > > > > -g > > > > From owner-ipsec@lists.tislabs.com Thu Mar 13 13:49:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DLnog01618; Thu, 13 Mar 2003 13:49:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29313 Thu, 13 Mar 2003 16:23:40 -0500 (EST) Message-ID: <3E70F7B6.DC4BC108@airespace.com> Date: Thu, 13 Mar 2003 13:27:18 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> <15984.52758.635053.55854@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2003 21:26:45.0307 (UTC) FILETIME=[3F7270B0:01C2E9A7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Aside from the question of deferring this, I think there's a larger question pertaining to whether the spec needs to solve this at all. I've seen this problem (overlapping address space) solved by using per-customer tunnels, and static nat'ing the private addresses at either end when the customers want to interact (extranet scenarios). I really don't see why everyone's ipsec implementation must be modified to accommodate someone's aversion to per-customer tunnels. If I'm missing something, please let me know. Scott Michael Thomas wrote: > > Radia Perlman - Boston Center for Networking writes: > > 2) Why does it need to go into IKEv2?...because otherwise there's > > no way to route the packets, if the IP addresses in the customer > > nets overlap. > > This evades the real question. Why does this need > to be part of the base spec? There's lots of world > hunger that IKEv2 doesn't solve. Why can't this be > deferred for later consideration, rather than an > ill-advised last minute addition? If IKEv2 does > not lend itself to such additions, maybe we asking > ourselves how we can make IKEv2 more amenable to > these kinds of additions rather than loading up > the kitchen sink blindly. > > Mike From owner-ipsec@lists.tislabs.com Thu Mar 13 13:50:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DLoFg01694; Thu, 13 Mar 2003 13:50:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29270 Thu, 13 Mar 2003 16:16:17 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Geoffrey Huang" , Cc: "Charlie Kaufman" Subject: RE: Using config mode together with extended authentication Date: Thu, 13 Mar 2003 16:20:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <005301c2e99c$3207b0d0$e1a36b80@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the scenario you mention the CP is sent before SAi2 and SAr2. So the initiator sends CP(CFG_REQUEST) in the first IKE_AUTH exchange and the responder sends CP(CFG_REPLY) in the last IKE_AUTH exchange. Using the EAP example from the IKEv2-05 draft and inserting CP it would look like this... Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] [CP], SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP, [AUTH] } --> <-- HDR, SK {EAP, [AUTH], [CP], SAr2, TSi, TSr } Charlie, could you add the CP payloads to the example for EAP so this is clearer? Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Geoffrey Huang > Sent: Thursday, March 13, 2003 3:08 PM > To: ipsec@lists.tislabs.com > Subject: Using config mode together with extended authentication > > > I've looked over the sections regarding EAP/XAuth and Config mode in > IKEv2-05, and there are packet descriptions in each section describing > what IKE looks like if either one is used. But what happens if you do > the cfg request and EAP? Based on the EAP description, the responder > sends an EAP request in the 4th message, starting off an EAP exchange. > > But the Cfg Request description says that the initiator sends a CP > payload before the SAi2 payload. Does this mean that if we do both CP > and EAP it looks like: > > INIT RESPO > msg1 ----> > <---- msg2 > msg3+CP ----> > <---- msg4+EAP > EAP ----> > <---- CP reply, etc. > > Maybe it's described in the document, and I just missed it. > > -g > From owner-ipsec@lists.tislabs.com Thu Mar 13 14:31:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DMVLg04920; Thu, 13 Mar 2003 14:31:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29503 Thu, 13 Mar 2003 17:03:58 -0500 (EST) Message-ID: <3E71010E.5060604@isi.edu> Date: Thu, 13 Mar 2003 14:07:10 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> <15984.52758.635053.55854@thomasm-u1.cisco.com> <3E70F7B6.DC4BC108@airespace.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One key issue about VPN-IDs: The VPN-ID itself (RFC 2685) is spec'd only as a format - it may be standards-track but it refers to a 'work in progress' for its architecture and management (presumably the document that later became RFC2764). I.e., some of the assertions about how the VPN-ID is managed appear to be based on an Informational RFC only. Joe From owner-ipsec@lists.tislabs.com Thu Mar 13 14:37:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DMbWg05244; Thu, 13 Mar 2003 14:37:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29530 Thu, 13 Mar 2003 17:11:10 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66ACB@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Geoffrey Huang'" , ddukes@cisco.com, ipsec@lists.tislabs.com Cc: "'Charlie Kaufman'" Subject: RE: Using config mode together with extended authentication Date: Thu, 13 Mar 2003 14:10:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agreed on adding the example to the ikev2 document. The case of CP + EAP, as Darren described it below, is also covered in our draft with respect to how to handle do EAP and CP where an off-gateway RADIUS server acts as the authentication server and provides the CP parameters that the gateway will send to the IRAC. Gregory. > -----Original Message----- > From: Geoffrey Huang [mailto:ghuang@cisco.com] > Sent: Thursday, March 13, 2003 1:27 PM > To: ddukes@cisco.com; ipsec@lists.tislabs.com > Cc: 'Charlie Kaufman' > Subject: RE: Using config mode together with extended authentication > > > OK - that's what I thought, that CP brackets the EAP exchange. I just > wanted to be sure. It'd be good to add the example below to the > document. > > -g > > > -----Original Message----- > > From: Darren Dukes [mailto:ddukes@cisco.com] > > Sent: Thursday, March 13, 2003 1:20 PM > > To: Geoffrey Huang; ipsec@lists.tislabs.com > > Cc: Charlie Kaufman > > Subject: RE: Using config mode together with extended authentication > > > > > > In the scenario you mention the CP is sent before SAi2 and > > SAr2. So the > > initiator sends CP(CFG_REQUEST) in the first IKE_AUTH > exchange and the > > responder sends CP(CFG_REPLY) in the last IKE_AUTH exchange. > > Using the EAP > > example from the IKEv2-05 draft and inserting CP it would > > look like this... > > > > Initiator Responder > > ----------- ----------- > > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > > [CP], SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > > EAP } > > HDR, SK {EAP, [AUTH] } --> > > <-- HDR, SK {EAP, [AUTH], > > [CP], SAr2, TSi, TSr } > > > > > > Charlie, could you add the CP payloads to the example for EAP > > so this is > > clearer? > > > > Darren > > > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Geoffrey Huang > > > Sent: Thursday, March 13, 2003 3:08 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Using config mode together with extended authentication > > > > > > > > > I've looked over the sections regarding EAP/XAuth and > Config mode in > > > IKEv2-05, and there are packet descriptions in each section > > describing > > > what IKE looks like if either one is used. But what > > happens if you do > > > the cfg request and EAP? Based on the EAP description, the > > responder > > > sends an EAP request in the 4th message, starting off an > > EAP exchange. > > > > > > But the Cfg Request description says that the initiator sends a CP > > > payload before the SAi2 payload. Does this mean that if we > > do both CP > > > and EAP it looks like: > > > > > > INIT RESPO > > > msg1 ----> > > > <---- msg2 > > > msg3+CP ----> > > > <---- msg4+EAP > > > EAP ----> > > > <---- CP reply, etc. > > > > > > Maybe it's described in the document, and I just missed it. > > > > > > -g > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 13 16:45:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E0j9g10549; Thu, 13 Mar 2003 16:45:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29847 Thu, 13 Mar 2003 19:15:10 -0500 (EST) Message-Id: <5.2.0.9.0.20030313161341.02e2bd30@postoffice.pacbell.net> X-Sender: trevp@postoffice.pacbell.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 16:18:16 -0800 To: ipsec@lists.tislabs.com From: Trevor Perrin Subject: Re: New 12288 and 16384 bit groups In-Reply-To: <15983.48760.96383.959888@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Out of curiosity, are the primes currently in draft-ietf-ipsec-ike-modp-groups-05 proven to be safe primes (of the form N=2q+1, where q is prime), or just proven to be prime? Trevor At 01:10 AM 3/13/2003 +0200, Tero Kivinen wrote: >Content-Transfer-Encoding: 7bit > >The 12288 bit group was fast to generate (only 13 days), the 16384 bit >group took little longer (9.5 months), but finally they are here. Now >you all can finally start using the full strength of the AES :-) > >Those primes have not been proven to be primes, only >probabilistic tests have been done, and I do not intend to put >them to draft-ietf-ipsec-ike-modp-groups-05. I would like to get >them proven first, but that will probably take another year or >so, provided that I can actually find windows machine running >primo that stays stable for that long. I tried to prove the 12288 >bit group earlier, but every time the machine or the program >crashed before it get very far (about two weeks or so). > >---------------------------------------------------------------------- >XXX. 12288-bit MODP Group > >This group is assigned id XXX. > >This prime is: 2^12288 - 2^12224 - 1 + 2^64 * { [2^12158 pi] + 7425765 } >Its hexadecimal value is: > > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 > 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD > EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 > E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED > EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D > C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F > 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D > 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B > E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 > DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 > 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 > ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 > ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B > F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C > BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 > 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 > 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA > 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 > 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED > 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 > 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492 > 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD > F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831 > 179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B > DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF > 5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6 > D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3 > 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA > CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 > 06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C > DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE > 12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4 > 38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300 > 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568 > 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9 > 22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B > 4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A > 062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36 > 4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1 > B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92 > 4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47 > 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71 > 60C980DD 98A573EA 4472065A 139CD290 6CD1CB72 9EC52A52 > 86D44014 A694CA45 7583D5CF EF26F1B9 0AD8291D A0799D00 > 022E9BED 55C6FA47 FCA5BB1A CA837645 6D98D948 79EE7E6D > BFCD014B B1615599 14EC0B57 6A67E3E8 422E91E6 5BA141DA > 92DE9C3A 6D6CCA51 36DD424B B1064988 EB5BA9AC 1269F7DF > 673B982E 23FB6C99 BB2AA31C 5A6685FF D599149B 30AC67B8 > 464D80A9 5D42530A 681644D0 39060E8F 8FD52626 96D0A759 > 5AE3F935 A67DCFF5 A874A701 FBFA0C3D 534B4E39 BC095770 > 53374821 A11C3AC9 98E0BA71 8087B317 825A1ACF CFAEBBF2 > 4F25C605 1ADA9C28 5A1FCD61 14A838A1 ADE714C1 6A9401CD > CF81E107 1FF7AB97 239F513B 15C5BCAE 2C0EB68D FC140303 > 7C0707C1 00802CFF EB833D46 8F2D5D2C 8960DE96 3702486F > 746444FE 5F2A4BFD A50C91DC C8BD51C0 4EB97960 4DF0B6B7 > 322D5D8D 26BCF769 EA511851 83F400C3 BB3231CF A91D4790 > 788E3366 4EFA838B CCA02EE8 460FACCC 539522CE 13DB6E42 > 1BD08340 FD82812F CB2E04A4 0925DF1E 559E6C1C AF2BE26B > F7A69DC7 F664C204 2CE2EB84 B733CFCB 95449C87 CB9ADC49 > 1406B779 A7E13361 DE9611C6 1D023685 EF27E6AF 3A52DF63 > 3B1EBB0E B6E1477E 98C250D9 B11930F4 BBC70611 CC857642 > 3750CECD C930AE85 84A85350 CA997114 54250000 84CEB937 > 5C77FE27 840C5395 606B1DF5 97C44666 C10D55BC 75E8F1DA > CF04460E D6492942 7CA3F9BB 666DCDE2 FFFFFFFF FFFFFFFF > >The generator is: 2. > > >XXX. 16384-bit MODP Group > >This group is assigned id XXX. > >This prime is: 2^16384 - 2^16320 - 1 + 2^64 * { [2^16254 pi] + 50814484 } >Its hexadecimal value is: > > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 > 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD > EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 > E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED > EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D > C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F > 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D > 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B > E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 > DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 > 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 > ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 > ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B > F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C > BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 > 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 > 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA > 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 > 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED > 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 > 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492 > 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD > F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831 > 179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B > DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF > 5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6 > D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3 > 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA > CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 > 06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C > DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE > 12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4 > 38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300 > 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568 > 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9 > 22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B > 4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A > 062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36 > 4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1 > B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92 > 4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47 > 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71 > 60C980DD 98A573EA 4472065A 139CD290 6CD1CB72 9EC52A52 > 86D44014 A694CA45 7583D5CF EF26F1B9 0AD8291D A0799D00 > 022E9BED 55C6FA47 FCA5BB1A CA837645 6D98D948 79EE7E6D > BFCD014B B1615599 14EC0B57 6A67E3E8 422E91E6 5BA141DA > 92DE9C3A 6D6CCA51 36DD424B B1064988 EB5BA9AC 1269F7DF > 673B982E 23FB6C99 BB2AA31C 5A6685FF D599149B 30AC67B8 > 464D80A9 5D42530A 681644D0 39060E8F 8FD52626 96D0A759 > 5AE3F935 A67DCFF5 A874A701 FBFA0C3D 534B4E39 BC095770 > 53374821 A11C3AC9 98E0BA71 8087B317 825A1ACF CFAEBBF2 > 4F25C605 1ADA9C28 5A1FCD61 14A838A1 ADE714C1 6A9401CD > CF81E107 1FF7AB97 239F513B 15C5BCAE 2C0EB68D FC140303 > 7C0707C1 00802CFF EB833D46 8F2D5D2C 8960DE96 3702486F > 746444FE 5F2A4BFD A50C91DC C8BD51C0 4EB97960 4DF0B6B7 > 322D5D8D 26BCF769 EA511851 83F400C3 BB3231CF A91D4790 > 788E3366 4EFA838B CCA02EE8 460FACCC 539522CE 13DB6E42 > 1BD08340 FD82812F CB2E04A4 0925DF1E 559E6C1C AF2BE26B > F7A69DC7 F664C204 2CE2EB84 B733CFCB 95449C87 CB9ADC49 > 1406B779 A7E13361 DE9611C6 1D023685 EF27E6AF 3A52DF63 > 3B1EBB0E B6E1477E 98C250D9 B11930F4 BBC70611 CC857642 > 3750CECD C930AE85 84A85350 CA997114 54250000 84CEB937 > 5C77FE27 840C5395 606B1DF5 97C44666 C10D55BC 75E8F1DA > CF04460E D6492942 7CA3F9BB 65FC7EFE A7AEAFCB 07854F1B > A1B8D15C 3ABA5BEC 61839782 968F8AAC DDC7F9C7 138F41BE > 8A59772E 6679C743 E00FA275 9499B209 4B93325E 27042CDA > B18543AE A538BA9E 297F0F14 C7828B7D 3CBDD3A9 CD874ACF > 464E4983 C6709E58 1488E9C2 3DC4C4AD BAEB7F9B BAB0C7D9 > B8EF1165 699EF220 EC5FCDF4 40633FCA 30CCB77B EF9B16A9 > 59560861 5A2AE600 BBB3A943 F6CBE54E CABBDF6B 56DB8BE1 > 05486D8A 0A41D85C 3B3751DD 5867C544 04F32A0C 3AD86F65 > 80CD3F87 AA80D8F3 ED5CD724 131C288E 7567A782 F2EAB785 > 3BB321AF 18188B29 E72AD72A ECBCE11B 9922C7AB C66F7C32 > A808DA6E 5956AED4 101A168C 8F0AAD2C CC67BA75 70086E3D > E6D502C6 61D7E826 657DE65F 988F5F6A 3E0DE226 A5F8CB5D > C47B64D7 C59A04A0 438D620A 71F987F5 A5B7B7E8 5E162EA6 > 55FD6129 46C89C98 E6E0F0FF C6B091A5 B36CC2BA D4CB8C15 > 23F65239 1B6F0C4A 163AFCBB CD31BFFA BF8A3B58 7B9F0F1C > D7528536 7A192DF8 D0841745 080F84F8 117BB8AD A8EAAAFA > B6DB13C5 7EB2D3F4 31D0BD10 BBDAAEED 5953CEC7 50734841 > 76079E67 A1A15371 F912D1DA 8F605894 33D8A87C 96E34991 > BF2220E8 3071EDA8 DFC54930 DA72DD24 91E12282 D5A4ACA1 > 4256EFC0 2B465227 4518AC5D 08E08380 1610A34A 83157D7A > 876B7D0F 88CFDC18 4CDCBC24 A364DF90 7597FB3C 5B088EF6 > DF378DD6 72FB9D18 10217CA9 F39DCC9B A981E021 0985723A > FFFFFFFF FFFFFFFF > >The generator is: 2. >-- >kivinen@ssh.fi >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Mar 13 17:58:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E1wfg13213; Thu, 13 Mar 2003 17:58:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00058 Thu, 13 Mar 2003 20:26:27 -0500 (EST) Message-Id: <5.2.0.9.0.20030313202125.01d9d260@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 20:29:16 -0500 To: "Scott G. Kelly" , Michael Thomas From: Mark Duffy Subject: Re: Another field for traffic selector? Cc: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com In-Reply-To: <3E70F7B6.DC4BC108@airespace.com> References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> <15984.52758.635053.55854@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think this is in fact *specifically* so that we can have per-customer tunnels. That is, per-customer tunnels, for multiple customers at once, that terminate in the same IPsec device. Without this proposed feature there is no attractive alternative for the security gateways to agree on which tunnels are for which customers. I also believe that "everyone's ipsec implementation" need not be modified to do anything with a VPN-ID attribute. Devices that support only one VPN context would presumably ignore this. Mark At 01:27 PM 3/13/2003 -0800, Scott G. Kelly wrote: >Aside from the question of deferring this, I think there's a larger >question pertaining to whether the spec needs to solve this at all. I've >seen this problem (overlapping address space) solved by using >per-customer tunnels, and static nat'ing the private addresses at either >end when the customers want to interact (extranet scenarios). I really >don't see why everyone's ipsec implementation must be modified to >accommodate someone's aversion to per-customer tunnels. > >If I'm missing something, please let me know. > >Scott > >Michael Thomas wrote: > > > > Radia Perlman - Boston Center for Networking writes: > > > 2) Why does it need to go into IKEv2?...because otherwise there's > > > no way to route the packets, if the IP addresses in the customer > > > nets overlap. > > > > This evades the real question. Why does this need > > to be part of the base spec? There's lots of world > > hunger that IKEv2 doesn't solve. Why can't this be > > deferred for later consideration, rather than an > > ill-advised last minute addition? If IKEv2 does > > not lend itself to such additions, maybe we asking > > ourselves how we can make IKEv2 more amenable to > > these kinds of additions rather than loading up > > the kitchen sink blindly. > > > > Mike From owner-ipsec@lists.tislabs.com Thu Mar 13 18:17:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E2Hbg13691; Thu, 13 Mar 2003 18:17:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00169 Thu, 13 Mar 2003 20:49:58 -0500 (EST) Message-ID: <3E713643.EA20F48A@airespace.com> Date: Thu, 13 Mar 2003 17:54:11 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: Michael Thomas , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> <15984.52758.635053.55854@thomasm-u1.cisco.com> <5.2.0.9.0.20030313202125.01d9d260@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 01:53:39.0107 (UTC) FILETIME=[886A6730:01C2E9CC] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess I don't see why you can't have multiple tunnels between the devices, since the tunnel selectors (the nat'd network addresses) are unique. Alternatively, you can use an encapsulation of some sort (GRE, UDP, L2TP, etc), which permits unique per-customer selectors. This can be done cleanly without modifying the ipsec protocols, can't it? Mark Duffy wrote: > > I think this is in fact *specifically* so that we can have per-customer > tunnels. That is, per-customer tunnels, for multiple customers at once, > that terminate in the same IPsec device. Without this proposed feature > there is no attractive alternative for the security gateways to agree on > which tunnels are for which customers. > > I also believe that "everyone's ipsec implementation" need not be modified > to do anything with a VPN-ID attribute. Devices that support only one VPN > context would presumably ignore this. > > Mark > > At 01:27 PM 3/13/2003 -0800, Scott G. Kelly wrote: > >Aside from the question of deferring this, I think there's a larger > >question pertaining to whether the spec needs to solve this at all. I've > >seen this problem (overlapping address space) solved by using > >per-customer tunnels, and static nat'ing the private addresses at either > >end when the customers want to interact (extranet scenarios). I really > >don't see why everyone's ipsec implementation must be modified to > >accommodate someone's aversion to per-customer tunnels. > > > >If I'm missing something, please let me know. > > > >Scott > > > >Michael Thomas wrote: > > > > > > Radia Perlman - Boston Center for Networking writes: > > > > 2) Why does it need to go into IKEv2?...because otherwise there's > > > > no way to route the packets, if the IP addresses in the customer > > > > nets overlap. > > > > > > This evades the real question. Why does this need > > > to be part of the base spec? There's lots of world > > > hunger that IKEv2 doesn't solve. Why can't this be > > > deferred for later consideration, rather than an > > > ill-advised last minute addition? If IKEv2 does > > > not lend itself to such additions, maybe we asking > > > ourselves how we can make IKEv2 more amenable to > > > these kinds of additions rather than loading up > > > the kitchen sink blindly. > > > > > > Mike From owner-ipsec@lists.tislabs.com Thu Mar 13 19:18:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E3ITg15056; Thu, 13 Mar 2003 19:18:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00367 Thu, 13 Mar 2003 21:47:24 -0500 (EST) Message-Id: <5.2.0.9.0.20030313213505.01ebd588@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 21:49:10 -0500 To: "Scott G. Kelly" , Mark Duffy From: Mark Duffy Subject: Re: Another field for traffic selector? Cc: Michael Thomas , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com In-Reply-To: <3E713643.EA20F48A@airespace.com> References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> <15984.52758.635053.55854@thomasm-u1.cisco.com> <5.2.0.9.0.20030313202125.01d9d260@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, I'm not sure if I understand what you mean but let me try to answer. I think you are assuming that the plaintext packets would be NAT'ed before they arrive at the "shared" security gateway. I think this is an incorrect assumption, at least for the types of scenarios I envision. Plenty of people won't want NATs in the middle of their private intranets - it breaks too many things. The other suggestion, encapsulating the plaintext packets before they arrive at the "shared" security gateway, seems to me equally improbable. The problem we are trying to solve here IMHO is where some sort of service provider is providing security gateway services to multiple independent customers, using a shared IPsec box. But the customers will want it to work just as transparently as if they were being served by a dedicated IPsec box. This transparency is not consistent with placing extra NAT or encapsulation boxes in the path. -Mark At 05:54 PM 3/13/2003 -0800, Scott G. Kelly wrote: >I guess I don't see why you can't have multiple tunnels between the >devices, since the tunnel selectors (the nat'd network addresses) are >unique. Alternatively, you can use an encapsulation of some sort (GRE, >UDP, L2TP, etc), which permits unique per-customer selectors. This can >be done cleanly without modifying the ipsec protocols, can't it? > >Mark Duffy wrote: > > > > I think this is in fact *specifically* so that we can have per-customer > > tunnels. That is, per-customer tunnels, for multiple customers at once, > > that terminate in the same IPsec device. Without this proposed feature > > there is no attractive alternative for the security gateways to agree on > > which tunnels are for which customers. > > > > I also believe that "everyone's ipsec implementation" need not be modified > > to do anything with a VPN-ID attribute. Devices that support only one VPN > > context would presumably ignore this. > > > > Mark > > > > At 01:27 PM 3/13/2003 -0800, Scott G. Kelly wrote: > > >Aside from the question of deferring this, I think there's a larger > > >question pertaining to whether the spec needs to solve this at all. I've > > >seen this problem (overlapping address space) solved by using > > >per-customer tunnels, and static nat'ing the private addresses at either > > >end when the customers want to interact (extranet scenarios). I really > > >don't see why everyone's ipsec implementation must be modified to > > >accommodate someone's aversion to per-customer tunnels. > > > > > >If I'm missing something, please let me know. > > > > > >Scott > > > > > >Michael Thomas wrote: > > > > > > > > Radia Perlman - Boston Center for Networking writes: > > > > > 2) Why does it need to go into IKEv2?...because otherwise there's > > > > > no way to route the packets, if the IP addresses in the customer > > > > > nets overlap. > > > > > > > > This evades the real question. Why does this need > > > > to be part of the base spec? There's lots of world > > > > hunger that IKEv2 doesn't solve. Why can't this be > > > > deferred for later consideration, rather than an > > > > ill-advised last minute addition? If IKEv2 does > > > > not lend itself to such additions, maybe we asking > > > > ourselves how we can make IKEv2 more amenable to > > > > these kinds of additions rather than loading up > > > > the kitchen sink blindly. > > > > > > > > Mike From owner-ipsec@lists.tislabs.com Thu Mar 13 22:53:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E6rdg20511; Thu, 13 Mar 2003 22:53:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA00720 Fri, 14 Mar 2003 01:22:29 -0500 (EST) Message-Id: <5.2.0.9.0.20030313220052.03584280@mail.attbi.com> X-Sender: alten@mail.attbi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Mar 2003 22:24:02 -0800 To: ipsec@lists.tislabs.com From: Alex Alten Subject: AES & IPsec questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some big vendors have incorporated AES into their IPsec VPN offerings. I have some questions about these that I hope someone on this list can answer. 1. Are these proprietary extensions or based on one of the AES drafts? 2. Are they supported by proprietary or draft extensions to IKE? 3. What performance has actually been achieved in practice, in software, on a Intel PC? (It would be helpful to specify the GHz of the CPU in your answer.) I'm particularly interested in Cisco's implementation, however info about other vendors or Linux open source is also welcome. Thanks in advance, - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Thu Mar 13 23:50:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E7oZg29845; Thu, 13 Mar 2003 23:50:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA00882 Fri, 14 Mar 2003 02:22:19 -0500 (EST) Date: Fri, 14 Mar 2003 09:25:15 +0200 Message-Id: <200303140725.h2E7PFN6006134@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <5.2.0.9.0.20030313202125.01d9d260@localhost> (message from Mark Duffy on Thu, 13 Mar 2003 20:29:16 -0500) Subject: Re: Another field for traffic selector? References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> <15984.52758.635053.55854@thomasm-u1.cisco.com> <5.2.0.9.0.20030313202125.01d9d260@localhost> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Assuming just for a moment that some "VPN-ID" type attribute would be useful. Then, wouldn't something similar be required if someone actually implemented "userid" specific selector? And, wanted to have separate SA's for each user on a multiuser system (even when communicating with the same other end). If I ever implemented it, the policy would actually read as dst = -> use_user_specicic_IPSEC (e.g. selector would match all traffic to/from , but the specification instructs system negotiate SA pair per user). From owner-ipsec@lists.tislabs.com Fri Mar 14 06:30:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EEUmg13929; Fri, 14 Mar 2003 06:30:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01674 Fri, 14 Mar 2003 08:55:42 -0500 (EST) X-Originating-IP: [64.114.95.129] From: "Andrew Krywaniuk" To: kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: RE: draft-ietf-ipsec-ikev2-05.txt comments Date: Thu, 13 Mar 2003 18:34:02 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2003 23:34:02.0299 (UTC) FILETIME=[0772F0B0:01C2E9B9] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >1.4 The INFORMATIONAL Exchange ... > A node SHOULD regard half open connections as anomalous and audit I think we should talk about half closed connections instead of half open. => Agreed. "Half open" should be used to refer to connections where one side has sent the final packet of the exhange, but the peer hasn't received it. Or where the peer rejects it, but the notify message is lost (which hopefully shouldn't happen much any more). > signature or MAC will be computed using algorithms dictated by the > type of key used by the signer, an RSA-signed PKCS1-padded-hash for ^^^^ I assume this is the negotiatiated hash algorithm like it was in the IKEv1? => Didn't we change it to the hash algorithm in the certificate? Or has that been changed back since? > Multi- > Attribute Type Value Valued Length > ======================= ===== ====== ================== > INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets > INTERNAL_IP6_SUBNET 15 NO 17 octets I think those two should be multi-valued, at least the description later indicates that there might be multiple subnets behind (at least you can request multiple subnets). => And while we're at it, shouldn't INTERNAL_IP6_SUBNET be 0 or 17 octets? Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From owner-ipsec@lists.tislabs.com Fri Mar 14 06:30:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EEUmg13930; Fri, 14 Mar 2003 06:30:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01682 Fri, 14 Mar 2003 08:56:44 -0500 (EST) Message-Id: <5.1.0.14.0.20030314085026.03329900@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Mar 2003 08:57:26 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: AES & IPsec questions In-Reply-To: <5.2.0.9.0.20030313220052.03584280@mail.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA01100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 22:24 13.03.2003 -0800, you wrote: >Some big vendors have incorporated AES into their IPsec VPN offerings. >I have some questions about these that I hope someone on this list can answer. > >1. Are these proprietary extensions or based on one of the AES drafts? drafts. >2. Are they supported by proprietary or draft extensions to IKE? Well, the algorithm numbers in IKE for AES are not draft, but really official, I believe. >3. What performance has actually been achieved in practice, in software, on > a Intel PC? (It would be helpful to specify the GHz of the CPU in > your answer.) 70mbps/Ghz for ESP tunnel with md5, which is just a bit better than CAST, our previously fastest algorithm. >I'm particularly interested in Cisco's implementation, however info about >other >vendors or Linux open source is also welcome. > >Thanks in advance, > >- Alex > >Alex Alten >Alten@ATTBI.com > J–rn Sierwald From owner-ipsec@lists.tislabs.com Fri Mar 14 10:26:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EIQ9g25848; Fri, 14 Mar 2003 10:26:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02188 Fri, 14 Mar 2003 12:49:47 -0500 (EST) Message-ID: <3E721737.B5536C5C@airespace.com> Date: Fri, 14 Mar 2003 09:53:59 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: Michael Thomas , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? References: <200303130020.h2D0KZ009828@sydney.East.Sun.COM> <15984.52758.635053.55854@thomasm-u1.cisco.com> <5.2.0.9.0.20030313202125.01d9d260@localhost> <5.2.0.9.0.20030313213505.01ebd588@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 17:53:30.0243 (UTC) FILETIME=[9F685D30:01C2EA52] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Okay, I think I understand a bit better now. In the case where customers don't have access to one another's networks, you will not want (or need) to nat traffic. However, I think Sankar's point is an important one: the provider must strictly control the boxes at both ends, or else you lose the access controls provided by ipsec, and are open to spoofing attacks. As an aside, I believe that some vendors support a "virtual router" concept which might permit the tunnels to be handled independently, but I'm not sure if this would work for your scenario or not. Scott Mark Duffy wrote: > > Hi Scott, > I'm not sure if I understand what you mean but let me try to answer. > > I think you are assuming that the plaintext packets would be NAT'ed before > they arrive at the "shared" security gateway. I think this is an incorrect > assumption, at least for the types of scenarios I envision. Plenty of > people won't want NATs in the middle of their private intranets - it breaks > too many things. The other suggestion, encapsulating the plaintext packets > before they arrive at the "shared" security gateway, seems to me equally > improbable. > > The problem we are trying to solve here IMHO is where some sort of service > provider is providing security gateway services to multiple independent > customers, using a shared IPsec box. But the customers will want it to > work just as transparently as if they were being served by a dedicated > IPsec box. This transparency is not consistent with placing extra NAT or > encapsulation boxes in the path. > > -Mark > > At 05:54 PM 3/13/2003 -0800, Scott G. Kelly wrote: > >I guess I don't see why you can't have multiple tunnels between the > >devices, since the tunnel selectors (the nat'd network addresses) are > >unique. Alternatively, you can use an encapsulation of some sort (GRE, > >UDP, L2TP, etc), which permits unique per-customer selectors. This can > >be done cleanly without modifying the ipsec protocols, can't it? > > > >Mark Duffy wrote: > > > > > > I think this is in fact *specifically* so that we can have per-customer > > > tunnels. That is, per-customer tunnels, for multiple customers at once, > > > that terminate in the same IPsec device. Without this proposed feature > > > there is no attractive alternative for the security gateways to agree on > > > which tunnels are for which customers. > > > > > > I also believe that "everyone's ipsec implementation" need not be modified > > > to do anything with a VPN-ID attribute. Devices that support only one VPN > > > context would presumably ignore this. > > > > > > Mark > > > > > > At 01:27 PM 3/13/2003 -0800, Scott G. Kelly wrote: > > > >Aside from the question of deferring this, I think there's a larger > > > >question pertaining to whether the spec needs to solve this at all. I've > > > >seen this problem (overlapping address space) solved by using > > > >per-customer tunnels, and static nat'ing the private addresses at either > > > >end when the customers want to interact (extranet scenarios). I really > > > >don't see why everyone's ipsec implementation must be modified to > > > >accommodate someone's aversion to per-customer tunnels. > > > > > > > >If I'm missing something, please let me know. > > > > > > > >Scott > > > > > > > >Michael Thomas wrote: > > > > > > > > > > Radia Perlman - Boston Center for Networking writes: > > > > > > 2) Why does it need to go into IKEv2?...because otherwise there's > > > > > > no way to route the packets, if the IP addresses in the customer > > > > > > nets overlap. > > > > > > > > > > This evades the real question. Why does this need > > > > > to be part of the base spec? There's lots of world > > > > > hunger that IKEv2 doesn't solve. Why can't this be > > > > > deferred for later consideration, rather than an > > > > > ill-advised last minute addition? If IKEv2 does > > > > > not lend itself to such additions, maybe we asking > > > > > ourselves how we can make IKEv2 more amenable to > > > > > these kinds of additions rather than loading up > > > > > the kitchen sink blindly. > > > > > > > > > > Mike From owner-ipsec@lists.tislabs.com Fri Mar 14 10:40:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EIehg27652; Fri, 14 Mar 2003 10:40:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02250 Fri, 14 Mar 2003 13:13:06 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200303141815.h2EIFp006401@sydney.East.Sun.COM> Date: Fri, 14 Mar 2003 13:18:42 -0500 To: "Scott G. Kelly" , "Mark Duffy" Cc: , "Michael Thomas" Reply-To: Subject: Re: Another field for traffic selector? 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 When traffic is going from one part of the customer's intranet to another (as opposed to talking to a node off the intranet) there's no natting. A locally significant IP address is simply forwarded across to the other part of the intranet. The firewalls are just creating an "internal" wire on behalf of the customer nets. The issue is what happens if the same pair of firewalls are creating multiple internal wires for multiple customers. You can have two conversations going on, each looking, to IP, like the same locally significant IP addresses. If there is some way to tell what "wire" things are coming on, as for instance if they are different MPLS tunnels, then there's no problem. But if they are forwarding simply with IP, then without this way of negotiating on SA creation, I don't see how the firewalls can do this. Radia "Scott G. Kelly" wrote: >I guess I don't see why you can't have multiple tunnels between the >devices, since the tunnel selectors (the nat'd network addresses) are >unique. Alternatively, you can use an encapsulation of some sort (GRE, >UDP, L2TP, etc), which permits unique per-customer selectors. This can >be done cleanly without modifying the ipsec protocols, can't it? > From owner-ipsec@lists.tislabs.com Fri Mar 14 10:48:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EImgg28118; Fri, 14 Mar 2003 10:48:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02280 Fri, 14 Mar 2003 13:20:17 -0500 (EST) Message-ID: <3E721E44.45A614D6@airespace.com> Date: Fri, 14 Mar 2003 10:24:04 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: radia.perlman@sun.com CC: Mark Duffy , ipsec@lists.tislabs.com, Michael Thomas Subject: Re: Another field for traffic selector? References: <200303141815.h2EIFp006401@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2003 18:23:35.0082 (UTC) FILETIME=[D32CF0A0:01C2EA56] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Radia, I gather my last post hadn't yet propagated through the list when you composed this. I get it now. I think there are other ways to handle this (e.g. routing encapsulation by the gateways), but I can see where folks might like a solution with lower overhead. Sorry if I seemed dense. Scott Radia Perlman - Boston Center for Networking wrote: > > When traffic is going from one part of the customer's > intranet to another (as opposed to talking to a > node off the intranet) there's no natting. A locally > significant IP address is simply forwarded across > to the other part of the intranet. > The firewalls are just creating an "internal" wire > on behalf of the customer nets. The issue is > what happens if the same > pair of firewalls are creating multiple internal > wires for multiple customers. You can have two > conversations going on, each looking, to IP, > like the same locally significant IP addresses. > > If there is some way to tell what "wire" things > are coming on, as for instance if they are > different MPLS tunnels, then there's no problem. > But if they are forwarding simply with IP, then > without this way of negotiating on SA creation, > I don't see how the firewalls can do this. > > Radia > > "Scott G. Kelly" wrote: > >I guess I don't see why you can't have multiple tunnels between the > >devices, since the tunnel selectors (the nat'd network addresses) are > >unique. Alternatively, you can use an encapsulation of some sort (GRE, > >UDP, L2TP, etc), which permits unique per-customer selectors. This can > >be done cleanly without modifying the ipsec protocols, can't it? > > From owner-ipsec@lists.tislabs.com Fri Mar 14 11:42:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EJgDg00625; Fri, 14 Mar 2003 11:42:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02449 Fri, 14 Mar 2003 14:06:49 -0500 (EST) To: Cc: "Scott G. Kelly" , "Mark Duffy" , , "Michael Thomas" From: Derek Atkins Subject: Re: Another field for traffic selector? References: <200303141815.h2EIFp006401@sydney.East.Sun.COM> Date: 14 Mar 2003 14:03:43 -0500 In-Reply-To: <200303141815.h2EIFp006401@sydney.East.Sun.COM> Message-ID: Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking writes: > If there is some way to tell what "wire" things > are coming on, as for instance if they are > different MPLS tunnels, then there's no problem. > But if they are forwarding simply with IP, then > without this way of negotiating on SA creation, > I don't see how the firewalls can do this. Why not just use different identities? The ingres firewall already needs some out-of-band mechanism to know that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can know this because it's arriving on a different port or a different MPLS tunnel. Regardless, it doesn't matter, it knows the source. This means that any firewall endpoint must necessarily have some meta-IP method to determine VPNs. If one piece of hardware is acting as an IPsec terminal point, why can't it use a different IKE identity per VPN? If I want to set up a tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for VPN-1. A box could internally apply the meta-IP information for SA selection. How this is done does not need to be standardized, IMHO. -derek > Radia > > "Scott G. Kelly" wrote: > >I guess I don't see why you can't have multiple tunnels between the > >devices, since the tunnel selectors (the nat'd network addresses) are > >unique. Alternatively, you can use an encapsulation of some sort (GRE, > >UDP, L2TP, etc), which permits unique per-customer selectors. This can > >be done cleanly without modifying the ipsec protocols, can't it? > > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 14 12:17:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EKHhg02388; Fri, 14 Mar 2003 12:17:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02546 Fri, 14 Mar 2003 14:45:37 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200303141948.h2EJmQ019098@sydney.East.Sun.COM> Date: Fri, 14 Mar 2003 14:51:15 -0500 To: "Derek Atkins" Cc: Reply-To: Subject: Re: Another field for traffic selector? 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 Aha. I think Derek's suggestion is a more elegant solution to the problem. To explain it again just because seeing it explained in different words is always helpful, to perform VPN service on behalf of four customer nets, (C1, C2, C3, C4), firewall n would have four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and also have 4 certificates (for each of the identities) and form four IKE tunnels. Then which customer net the child-SA is for is based on which IKE tunnel it was formed under. The identities could have the same public key or different public keys for the different. It don't think it matters. Radia "Derek Atkins" wrote: >Radia Perlman - Boston Center for Networking writes: > >> If there is some way to tell what "wire" things >> are coming on, as for instance if they are >> different MPLS tunnels, then there's no problem. >> But if they are forwarding simply with IP, then >> without this way of negotiating on SA creation, >> I don't see how the firewalls can do this. > >Why not just use different identities? > >The ingres firewall already needs some out-of-band mechanism to know >that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can >know this because it's arriving on a different port or a different >MPLS tunnel. Regardless, it doesn't matter, it knows the source. >This means that any firewall endpoint must necessarily have some >meta-IP method to determine VPNs. > >If one piece of hardware is acting as an IPsec terminal point, why >can't it use a different IKE identity per VPN? If I want to set up a >tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for >VPN-1. > >A box could internally apply the meta-IP information for SA selection. >How this is done does not need to be standardized, IMHO. > >-derek > >> Radia >> >> "Scott G. Kelly" wrote: >> >I guess I don't see why you can't have multiple tunnels between the >> >devices, since the tunnel selectors (the nat'd network addresses) are >> >unique. Alternatively, you can use an encapsulation of some sort (GRE, >> >UDP, L2TP, etc), which permits unique per-customer selectors. This can >> >be done cleanly without modifying the ipsec protocols, can't it? >> > >> > >-- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 14 15:14:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ENEmg12910; Fri, 14 Mar 2003 15:14:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02916 Fri, 14 Mar 2003 17:44:55 -0500 (EST) Message-Id: <5.2.0.9.0.20030314170119.01ea5f70@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Mar 2003 17:41:00 -0500 To: , "Derek Atkins" From: Mark Duffy Subject: Re: Another field for traffic selector? Cc: In-Reply-To: <200303141948.h2EJmQ019098@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ah. I was ready to say I didn't think this solved the problem, because there was no way for Bob to know which context Alice wanted to have an SA with. And AFAIK that was true for IKEv1. For IKEv2, I think this would be done by Alice sending the optional [IDr,] payload to Bob. Is that what you have in mind? I think that would do pretty well. A minor deficiency from the PPVPN POV would be that VPN membership discovery schemes may be passing around VPN-IDs and so VPN-IDs would be what the device has available to send to the IKE peer. I suppose this could be addressed by having the membership discovery scheme pass some recognized IKE identity type instead, or by stuffing VPN-ID into ID_KEY_ID, or by defining a new IKE ID type that has type VPN-ID. --Mark At 02:51 PM 3/14/2003 -0500, Radia Perlman - Boston Center for Networking wrote: >Aha. I think Derek's suggestion is a more >elegant solution to the problem. To explain >it again just because seeing it explained in different >words is always helpful, >to perform VPN service on behalf of four customer >nets, (C1, C2, C3, C4), firewall n would have >four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and >also have 4 certificates (for each of the identities) and >form four IKE tunnels. Then which customer >net the child-SA is for is based on which IKE >tunnel it was formed under. > >The identities could have the same public key or different >public keys for the different. >It don't think it matters. > >Radia > > >"Derek Atkins" wrote: > >Radia Perlman - Boston Center for Networking writes: > > > >> If there is some way to tell what "wire" things > >> are coming on, as for instance if they are > >> different MPLS tunnels, then there's no problem. > >> But if they are forwarding simply with IP, then > >> without this way of negotiating on SA creation, > >> I don't see how the firewalls can do this. > > > >Why not just use different identities? > > > >The ingres firewall already needs some out-of-band mechanism to know > >that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can > >know this because it's arriving on a different port or a different > >MPLS tunnel. Regardless, it doesn't matter, it knows the source. > >This means that any firewall endpoint must necessarily have some > >meta-IP method to determine VPNs. > > > >If one piece of hardware is acting as an IPsec terminal point, why > >can't it use a different IKE identity per VPN? If I want to set up a > >tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for > >VPN-1. > > > >A box could internally apply the meta-IP information for SA selection. > >How this is done does not need to be standardized, IMHO. > > > >-derek > > > >> Radia > >> > >> "Scott G. Kelly" wrote: > >> >I guess I don't see why you can't have multiple tunnels between the > >> >devices, since the tunnel selectors (the nat'd network addresses) are > >> >unique. Alternatively, you can use an encapsulation of some sort (GRE, > >> >UDP, L2TP, etc), which permits unique per-customer selectors. This can > >> >be done cleanly without modifying the ipsec protocols, can't it? > >> > > >> > > > >-- > > Derek Atkins > > Computer and Internet Security Consultant > > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 14 15:31:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ENVeg13425; Fri, 14 Mar 2003 15:31:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02945 Fri, 14 Mar 2003 18:01:14 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Another field for traffic selector? Date: Fri, 14 Mar 2003 18:04:33 -0500 Message-ID: Thread-Topic: Another field for traffic selector? Thread-Index: AcLqai7Gz0MGjWOGSa+pulgjuytWxAAEdKNQ From: "Cambria, Michael (Michael)" To: Cc: , "Derek Atkins" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA02942 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, How would there be 4 IKE tunnels (ISAKMP SAs?) between each IKE entity? I understood the original problem as having only one (physical) FW at each end. Each of these FW's had one IP address into the "cloud" network which would be used to connect to the (physical) FW at the remote end. The goal was to have one IKEv2 tunnel over the cloud used to setup all the SA's between customer subnets. In order to have a FW have 4 identities (and 4 IKE tunnels), would IKE need to use different UDP ports between identities or have 4 different IP addresses (i.e. one per customer) into the cloud? Am I missing something? Thanks, MikeC -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@sun.com] Sent: Friday, March 14, 2003 2:51 PM To: Derek Atkins Cc: ipsec@lists.tislabs.com Subject: Re: Another field for traffic selector? Aha. I think Derek's suggestion is a more elegant solution to the problem. To explain it again just because seeing it explained in different words is always helpful, to perform VPN service on behalf of four customer nets, (C1, C2, C3, C4), firewall n would have four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and also have 4 certificates (for each of the identities) and form four IKE tunnels. Then which customer net the child-SA is for is based on which IKE tunnel it was formed under. The identities could have the same public key or different public keys for the different. It don't think it matters. Radia "Derek Atkins" wrote: >Radia Perlman - Boston Center for Networking writes: > >> If there is some way to tell what "wire" things >> are coming on, as for instance if they are >> different MPLS tunnels, then there's no problem. >> But if they are forwarding simply with IP, then >> without this way of negotiating on SA creation, >> I don't see how the firewalls can do this. > >Why not just use different identities? > >The ingres firewall already needs some out-of-band mechanism to know >that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can >know this because it's arriving on a different port or a different >MPLS tunnel. Regardless, it doesn't matter, it knows the source. >This means that any firewall endpoint must necessarily have some >meta-IP method to determine VPNs. > >If one piece of hardware is acting as an IPsec terminal point, why >can't it use a different IKE identity per VPN? If I want to set up a >tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for >VPN-1. > >A box could internally apply the meta-IP information for SA selection. >How this is done does not need to be standardized, IMHO. > >-derek > >> Radia >> >> "Scott G. Kelly" wrote: >> >I guess I don't see why you can't have multiple tunnels between the >> >devices, since the tunnel selectors (the nat'd network addresses) are >> >unique. Alternatively, you can use an encapsulation of some sort (GRE, >> >UDP, L2TP, etc), which permits unique per-customer selectors. This can >> >be done cleanly without modifying the ipsec protocols, can't it? >> > >> > >-- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 14 16:27:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2F0RMg15066; Fri, 14 Mar 2003 16:27:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03154 Fri, 14 Mar 2003 18:54:26 -0500 (EST) To: Mark Duffy Cc: , From: "Derek Atkins" Subject: Re: Another field for traffic selector? References: <5.2.0.9.0.20030314170119.01ea5f70@email> Date: 14 Mar 2003 18:57:44 -0500 In-Reply-To: <5.2.0.9.0.20030314170119.01ea5f70@email> Message-ID: Lines: 102 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy writes: > Ah. I was ready to say I didn't think this solved the problem, because > there was no way for Bob to know which context Alice wanted to have an > SA with. And AFAIK that was true for IKEv1. For IKEv2, I think this > would be done by Alice sending the optional [IDr,] payload to Bob. Is > that what you have in mind? It really doesn't matter. You could know that F1-C1 is supposed to talk to F2-C1, F1-C2 talks to F2-C2, etc.) But yea, theoretically you could also sent the IDr payload. > I think that would do pretty well. A minor deficiency from the PPVPN > POV would be that VPN membership discovery schemes may be passing > around VPN-IDs and so VPN-IDs would be what the device has available > to send to the IKE peer. I suppose this could be addressed by having > the membership discovery scheme pass some recognized IKE identity type > instead, or by stuffing VPN-ID into ID_KEY_ID, or by defining a new > IKE ID type that has type VPN-ID. Are VPN-IDs dynamic or quazi-static? If quazi-static then you can just print a certificate for each firewall involved in a particular VPN-ID. If they are absolutely dynamic (e.g. VPN #17 today is not the same as VPN #17 tomorrow) then we probably need to come up with another solution. > --Mark -derek > > At 02:51 PM 3/14/2003 -0500, Radia Perlman - Boston Center for > Networking wrote: > >Aha. I think Derek's suggestion is a more > >elegant solution to the problem. To explain > >it again just because seeing it explained in different > >words is always helpful, > >to perform VPN service on behalf of four customer > >nets, (C1, C2, C3, C4), firewall n would have > >four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and > >also have 4 certificates (for each of the identities) and > >form four IKE tunnels. Then which customer > >net the child-SA is for is based on which IKE > >tunnel it was formed under. > > > >The identities could have the same public key or different > >public keys for the different. > >It don't think it matters. > > > >Radia > > > > > >"Derek Atkins" wrote: > > >Radia Perlman - Boston Center for Networking writes: > > > > > >> If there is some way to tell what "wire" things > > >> are coming on, as for instance if they are > > >> different MPLS tunnels, then there's no problem. > > >> But if they are forwarding simply with IP, then > > >> without this way of negotiating on SA creation, > > >> I don't see how the firewalls can do this. > > > > > >Why not just use different identities? > > > > > >The ingres firewall already needs some out-of-band mechanism to know > > >that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can > > >know this because it's arriving on a different port or a different > > >MPLS tunnel. Regardless, it doesn't matter, it knows the source. > > >This means that any firewall endpoint must necessarily have some > > >meta-IP method to determine VPNs. > > > > > >If one piece of hardware is acting as an IPsec terminal point, why > > >can't it use a different IKE identity per VPN? If I want to set up a > > >tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for > > >VPN-1. > > > > > >A box could internally apply the meta-IP information for SA selection. > > >How this is done does not need to be standardized, IMHO. > > > > > >-derek > > > > > >> Radia > > >> > > >> "Scott G. Kelly" wrote: > > >> >I guess I don't see why you can't have multiple tunnels between the > > >> >devices, since the tunnel selectors (the nat'd network addresses) are > > >> >unique. Alternatively, you can use an encapsulation of some sort (GRE, > > >> >UDP, L2TP, etc), which permits unique per-customer selectors. This can > > >> >be done cleanly without modifying the ipsec protocols, can't it? > > >> > > > >> > > > > > >-- > > > Derek Atkins > > > Computer and Internet Security Consultant > > > derek@ihtfp.com www.ihtfp.com > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 14 16:30:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2F0ULg15119; Fri, 14 Mar 2003 16:30:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03180 Fri, 14 Mar 2003 19:00:30 -0500 (EST) From: Radia.Perlman@sun.com Message-ID: <1760865.1047686620578.JavaMail.radia@sydney.East.Sun.COM> Date: Fri, 14 Mar 2003 17:03:40 -0700 (MST) To: ipsec@lists.tislabs.com Subject: Re: RE: Another field for traffic selector? Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The different IKE tunnels are differentiated by having different SPI pairs (what in IKEv1 was called cookie pairs). So Fn starts up 4 IKE-SAs. The identity that the initiator asserts in the IKE handshake defines whether that IKE-SA is for C1, C2, C3, or C4. (Note it doesn't need to assert an identity for the other end...its own identity is sufficient---this comment is to answer a comment from someone in a different email). So let's say Fn creates 4 IKE SAs. When using identity Fn-C1 to create an IKE-SA, it winds up with SPI pair (26,91) and when using identity Fn-C2, it winds up with SPI pair (8,152). Any child-SA created under (26,91) would be understood to belong to the VPN for C1. Any child-SA created under IKE-SA (8,152) would be understood to belong to the VPN for C2. Radia > >Hi, > >How would there be 4 IKE tunnels (ISAKMP SAs?) between each IKE entity? > >I understood the original problem as having only one (physical) FW at each end. >Each of these FW's had one IP address into the "cloud" network which would be used >to connect to the (physical) FW at the remote end. The goal was to have one >IKEv2 tunnel over the cloud used to setup all the SA's between customer subnets. > >In order to have a FW have 4 identities (and 4 IKE tunnels), would IKE need to use different UDP ports between identities or have 4 different IP addresses (i.e. one >per customer) into the cloud? > >Am I missing something? > >Thanks, >MikeC > > >-----Original Message----- >From: Radia Perlman - Boston Center for Networking >[mailto:Radia.Perlman@sun.com] >Sent: Friday, March 14, 2003 2:51 PM >To: Derek Atkins >Cc: ipsec@lists.tislabs.com >Subject: Re: Another field for traffic selector? > > >Aha. I think Derek's suggestion is a more >elegant solution to the problem. To explain >it again just because seeing it explained in different >words is always helpful, >to perform VPN service on behalf of four customer >nets, (C1, C2, C3, C4), firewall n would have >four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and >also have 4 certificates (for each of the identities) and >form four IKE tunnels. Then which customer >net the child-SA is for is based on which IKE >tunnel it was formed under. > >The identities could have the same public key or different >public keys for the different. >It don't think it matters. > >Radia > > >"Derek Atkins" wrote: >>Radia Perlman - Boston Center for Networking writes: >> >>> If there is some way to tell what "wire" things >>> are coming on, as for instance if they are >>> different MPLS tunnels, then there's no problem. >>> But if they are forwarding simply with IP, then >>> without this way of negotiating on SA creation, >>> I don't see how the firewalls can do this. >> >>Why not just use different identities? >> >>The ingres firewall already needs some out-of-band mechanism to know >>that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can >>know this because it's arriving on a different port or a different >>MPLS tunnel. Regardless, it doesn't matter, it knows the source. >>This means that any firewall endpoint must necessarily have some >>meta-IP method to determine VPNs. >> >>If one piece of hardware is acting as an IPsec terminal point, why >>can't it use a different IKE identity per VPN? If I want to set up a >>tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for >>VPN-1. >> >>A box could internally apply the meta-IP information for SA selection. >>How this is done does not need to be standardized, IMHO. >> >>-derek >> >>> Radia >>> >>> "Scott G. Kelly" wrote: >>> >I guess I don't see why you can't have multiple tunnels between the >>> >devices, since the tunnel selectors (the nat'd network addresses) are >>> >unique. Alternatively, you can use an encapsulation of some sort (GRE, >>> >UDP, L2TP, etc), which permits unique per-customer selectors. This can >>> >be done cleanly without modifying the ipsec protocols, can't it? >>> > >>> >> >>-- >> Derek Atkins >> Computer and Internet Security Consultant >> derek@ihtfp.com www.ihtfp.com > > > > From owner-ipsec@lists.tislabs.com Fri Mar 14 16:35:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2F0ZTg15242; Fri, 14 Mar 2003 16:35:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03219 Fri, 14 Mar 2003 19:09:48 -0500 (EST) To: "Cambria, Michael (Michael)" Cc: , From: "Derek Atkins" Subject: Re: Another field for traffic selector? References: Date: 14 Mar 2003 19:12:40 -0500 In-Reply-To: Message-ID: Lines: 145 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Cambria, Michael (Michael)" writes: > Hi, > > How would there be 4 IKE tunnels (ISAKMP SAs?) between each IKE entity? Where do you see the limit on one-and-only-one ISAKMP SA between IP Address A and IP Address B? You have different Cookies and SAid's for the various SAs. So SA#1 is ID#1, SA#2 is ID#2. Note that if you DO have this limitation of only one ISAKMP SA per peer-IP then you cannot have multiple peers behind the same NAT, because both of them would have the same IP Address (albeit different UDP Ports). > I understood the original problem as having only one (physical) FW > at each end. Each of these FW's had one IP address into the "cloud" > network which would be used to connect to the (physical) FW at the > remote end. The goal was to have one IKEv2 tunnel over the cloud > used to setup all the SA's between customer subnets. You did understand the original problem -- a single gateway with one physical IP address is handling some meta-IP VPN architecture, and you want to use IPsec between this gateway and another gateway. Question: what do you mean by IKEv2 tunnel? Do you mean one ISAKMP SA? Or do you mean one IPsec tunnel? I presume you mean the former, but it's unclear due to your improper use of terminology. Furthermore, I do not recall seeing anyone mention a goal of having only one IKEv2 SA per pair of PPVPN gateways. If that is an actual requirement then yes, we would need to explore an alternate solution. However I disbelieve that maintaining one more SA is a significant overhead to support meta-IP tunnels, and it's something that works without any changes to the IKEv2 or IPsec protocols -- indeed, such an implementation could be done now and be fully compliant. So, what's the actual "goal"? Is the goal to support separate meta-IP tunnels? Or to support it with one fewer SA? > In order to have a FW have 4 identities (and 4 IKE tunnels), would > IKE need to use different UDP ports between identities or have 4 > different IP addresses (i.e. one per customer) into the cloud? No, of course not. You just negotiate multiple ISAKMP SAs with your peers, one per VPN. If you're handling 100 VPNs, you have 100 ISAKMP SAs and 200 IPsec SAs. Keep in mind that you already need to keep track of the meta-IP state for each VPN, so you DO already have O(n) state. > Am I missing something? I would say "yes", but I'm not sure what you're missing. Actually, what you are probably missing is the fact that somewhere in the IPsec stack implementation there needs to be an up-call to let the IKE daemon know which ID needs to be used for a particular negotiation. But that's a local matter (IMHO) because the upcall for YOUR implementation does not necessarily need to match the upcall in mine. (The right place to standardize this particular upcall would be within a PFkey extension). > Thanks, > MikeC -derek > > -----Original Message----- > From: Radia Perlman - Boston Center for Networking > [mailto:Radia.Perlman@sun.com] > Sent: Friday, March 14, 2003 2:51 PM > To: Derek Atkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Another field for traffic selector? > > > Aha. I think Derek's suggestion is a more > elegant solution to the problem. To explain > it again just because seeing it explained in different > words is always helpful, > to perform VPN service on behalf of four customer > nets, (C1, C2, C3, C4), firewall n would have > four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and > also have 4 certificates (for each of the identities) and > form four IKE tunnels. Then which customer > net the child-SA is for is based on which IKE > tunnel it was formed under. > > The identities could have the same public key or different > public keys for the different. > It don't think it matters. > > Radia > > > "Derek Atkins" wrote: > >Radia Perlman - Boston Center for Networking writes: > > > >> If there is some way to tell what "wire" things > >> are coming on, as for instance if they are > >> different MPLS tunnels, then there's no problem. > >> But if they are forwarding simply with IP, then > >> without this way of negotiating on SA creation, > >> I don't see how the firewalls can do this. > > > >Why not just use different identities? > > > >The ingres firewall already needs some out-of-band mechanism to know > >that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can > >know this because it's arriving on a different port or a different > >MPLS tunnel. Regardless, it doesn't matter, it knows the source. > >This means that any firewall endpoint must necessarily have some > >meta-IP method to determine VPNs. > > > >If one piece of hardware is acting as an IPsec terminal point, why > >can't it use a different IKE identity per VPN? If I want to set up a > >tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for > >VPN-1. > > > >A box could internally apply the meta-IP information for SA selection. > >How this is done does not need to be standardized, IMHO. > > > >-derek > > > >> Radia > >> > >> "Scott G. Kelly" wrote: > >> >I guess I don't see why you can't have multiple tunnels between the > >> >devices, since the tunnel selectors (the nat'd network addresses) are > >> >unique. Alternatively, you can use an encapsulation of some sort (GRE, > >> >UDP, L2TP, etc), which permits unique per-customer selectors. This can > >> >be done cleanly without modifying the ipsec protocols, can't it? > >> > > >> > > > >-- > > Derek Atkins > > Computer and Internet Security Consultant > > derek@ihtfp.com www.ihtfp.com > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Fri Mar 14 18:08:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2F28vg18840; Fri, 14 Mar 2003 18:08:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03582 Fri, 14 Mar 2003 20:40:21 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Another field for traffic selector? Date: Fri, 14 Mar 2003 20:44:16 -0500 Message-ID: Thread-Topic: Another field for traffic selector? Thread-Index: AcLqh7HXgQmK4ayOSjqwcmokWZcqCwACaLag From: "Cambria, Michael (Michael)" To: "Derek Atkins" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA03579 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I used the term IKE tunnel because it was in the original message. I wasn't exactly sure what it meant. The ability to havie multiple ISAKMP SA's between the two IKE's was the what I missed. Thanks for filling in the blank. Thanks, MikeC -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Friday, March 14, 2003 7:13 PM To: Cambria, Michael (Michael) Cc: ipsec@lists.tislabs.com; radia.perlman@sun.com Subject: Re: Another field for traffic selector? "Cambria, Michael (Michael)" writes: > Hi, > > How would there be 4 IKE tunnels (ISAKMP SAs?) between each IKE entity? Where do you see the limit on one-and-only-one ISAKMP SA between IP Address A and IP Address B? You have different Cookies and SAid's for the various SAs. So SA#1 is ID#1, SA#2 is ID#2. Note that if you DO have this limitation of only one ISAKMP SA per peer-IP then you cannot have multiple peers behind the same NAT, because both of them would have the same IP Address (albeit different UDP Ports). > I understood the original problem as having only one (physical) FW > at each end. Each of these FW's had one IP address into the "cloud" > network which would be used to connect to the (physical) FW at the > remote end. The goal was to have one IKEv2 tunnel over the cloud > used to setup all the SA's between customer subnets. You did understand the original problem -- a single gateway with one physical IP address is handling some meta-IP VPN architecture, and you want to use IPsec between this gateway and another gateway. Question: what do you mean by IKEv2 tunnel? Do you mean one ISAKMP SA? Or do you mean one IPsec tunnel? I presume you mean the former, but it's unclear due to your improper use of terminology. Furthermore, I do not recall seeing anyone mention a goal of having only one IKEv2 SA per pair of PPVPN gateways. If that is an actual requirement then yes, we would need to explore an alternate solution. However I disbelieve that maintaining one more SA is a significant overhead to support meta-IP tunnels, and it's something that works without any changes to the IKEv2 or IPsec protocols -- indeed, such an implementation could be done now and be fully compliant. So, what's the actual "goal"? Is the goal to support separate meta-IP tunnels? Or to support it with one fewer SA? > In order to have a FW have 4 identities (and 4 IKE tunnels), would > IKE need to use different UDP ports between identities or have 4 > different IP addresses (i.e. one per customer) into the cloud? No, of course not. You just negotiate multiple ISAKMP SAs with your peers, one per VPN. If you're handling 100 VPNs, you have 100 ISAKMP SAs and 200 IPsec SAs. Keep in mind that you already need to keep track of the meta-IP state for each VPN, so you DO already have O(n) state. > Am I missing something? I would say "yes", but I'm not sure what you're missing. Actually, what you are probably missing is the fact that somewhere in the IPsec stack implementation there needs to be an up-call to let the IKE daemon know which ID needs to be used for a particular negotiation. But that's a local matter (IMHO) because the upcall for YOUR implementation does not necessarily need to match the upcall in mine. (The right place to standardize this particular upcall would be within a PFkey extension). > Thanks, > MikeC -derek > > -----Original Message----- > From: Radia Perlman - Boston Center for Networking > [mailto:Radia.Perlman@sun.com] > Sent: Friday, March 14, 2003 2:51 PM > To: Derek Atkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Another field for traffic selector? > > > Aha. I think Derek's suggestion is a more > elegant solution to the problem. To explain > it again just because seeing it explained in different > words is always helpful, > to perform VPN service on behalf of four customer > nets, (C1, C2, C3, C4), firewall n would have > four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and > also have 4 certificates (for each of the identities) and > form four IKE tunnels. Then which customer > net the child-SA is for is based on which IKE > tunnel it was formed under. > > The identities could have the same public key or different > public keys for the different. > It don't think it matters. > > Radia > > > "Derek Atkins" wrote: > >Radia Perlman - Boston Center for Networking writes: > > > >> If there is some way to tell what "wire" things > >> are coming on, as for instance if they are > >> different MPLS tunnels, then there's no problem. > >> But if they are forwarding simply with IP, then > >> without this way of negotiating on SA creation, > >> I don't see how the firewalls can do this. > > > >Why not just use different identities? > > > >The ingres firewall already needs some out-of-band mechanism to know > >that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can > >know this because it's arriving on a different port or a different > >MPLS tunnel. Regardless, it doesn't matter, it knows the source. > >This means that any firewall endpoint must necessarily have some > >meta-IP method to determine VPNs. > > > >If one piece of hardware is acting as an IPsec terminal point, why > >can't it use a different IKE identity per VPN? If I want to set up a > >tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for > >VPN-1. > > > >A box could internally apply the meta-IP information for SA selection. > >How this is done does not need to be standardized, IMHO. > > > >-derek > > > >> Radia > >> > >> "Scott G. Kelly" wrote: > >> >I guess I don't see why you can't have multiple tunnels between the > >> >devices, since the tunnel selectors (the nat'd network addresses) are > >> >unique. Alternatively, you can use an encapsulation of some sort (GRE, > >> >UDP, L2TP, etc), which permits unique per-customer selectors. This can > >> >be done cleanly without modifying the ipsec protocols, can't it? > >> > > >> > > > >-- > > Derek Atkins > > Computer and Internet Security Consultant > > derek@ihtfp.com www.ihtfp.com > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Sat Mar 15 13:08:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2FL8ug26899; Sat, 15 Mar 2003 13:08:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05317 Sat, 15 Mar 2003 15:29:23 -0500 (EST) Message-Id: <5.2.0.9.0.20030315134223.01e059b8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 15 Mar 2003 15:13:16 -0500 To: "Derek Atkins" , Mark Duffy From: Mark Duffy Subject: Re: Another field for traffic selector? Cc: , In-Reply-To: References: <5.2.0.9.0.20030314170119.01ea5f70@email> <5.2.0.9.0.20030314170119.01ea5f70@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derek, Perhaps I am being dense, or perhaps we have somewhat different problems in mind that we are trying to solve. Suppose we have some number of security gateways F1, F2, ... and each has some number of customer contexts that it is serving e.g. F1-C1a, F1-C2a, ..., F2-C1b, F2-C2b, ... Suppose F1 initiates an IKE SA to F2, on behalf of F1-C1a and it wants F2 to respond on behalf of F2-C1b. How is F2 to know which of its customer contexts to use? I think perhaps you are assuming that the desired responder ID can be inferred from the initiator ID that is sent? In particular are you assuming that identity F1-C1a == F2-C1b? Or that F1 has a preconfigured mapping from initiator identity to intended responder identity? I don't think those are valid assumptions. In fact, now that I have had a day to think about it, I don't think that it is sufficient even if the initiator passes the desired responder identity [IRr] payload. Here is why. In the problem I have in mind, devices such as we have called a firewall in this thread (called "PE routers" or just "PE"s in ppvpn terminology) may use protocols like BGP or RADIUS to discover, for each VPN context, the addresses of the other firewalls (PEs) that serve the same VPN. For this purpose a globally significant VPN-ID is assigned to each VPN context in all participating firewalls (PEs). Each firewall (PE) then wants to set up, perhaps, an IKE SA to each other firewall (PE), for each VPN context. Thus we have F1 initiating multiple IKE SAs to F2, each SA for a particular VPN context. F3 may also be initiating to F2 for the same contexts. F1 has to tell F2 which VPN context each IKE SA is for. Passing the VPN-ID in an IKE payload would be a direct way to do this. But if we rely on any scheme that uses the IKE identity to represent the VPN context, then we have unfortunately coupled the VPN-ID with the IKE identity. One result of this coupling would be that we can end up with multiple devices asserting the same identity. Offhand, this seems bad from a security perspective. Wouldn't it present a problem if using shared secret auth? How does the responder know which shared secret to use unless it uses the same one for all peers in a given VPN? With certificates, is it any better? I'm a little out of my depth here but if the responder has already cached a cert or public key for the identity, isn't it broken unless all peers asserting that identity have the same private key? --Mark At 06:57 PM 3/14/2003 -0500, Derek Atkins wrote: >Mark Duffy writes: > > > Ah. I was ready to say I didn't think this solved the problem, because > > there was no way for Bob to know which context Alice wanted to have an > > SA with. And AFAIK that was true for IKEv1. For IKEv2, I think this > > would be done by Alice sending the optional [IDr,] payload to Bob. Is > > that what you have in mind? > >It really doesn't matter. You could know that F1-C1 is supposed to >talk to F2-C1, F1-C2 talks to F2-C2, etc.) But yea, theoretically you >could also sent the IDr payload. > > > I think that would do pretty well. A minor deficiency from the PPVPN > > POV would be that VPN membership discovery schemes may be passing > > around VPN-IDs and so VPN-IDs would be what the device has available > > to send to the IKE peer. I suppose this could be addressed by having > > the membership discovery scheme pass some recognized IKE identity type > > instead, or by stuffing VPN-ID into ID_KEY_ID, or by defining a new > > IKE ID type that has type VPN-ID. > >Are VPN-IDs dynamic or quazi-static? If quazi-static then you can >just print a certificate for each firewall involved in a particular >VPN-ID. If they are absolutely dynamic (e.g. VPN #17 today is not the >same as VPN #17 tomorrow) then we probably need to come up with >another solution. > > > --Mark > >-derek > > > > > At 02:51 PM 3/14/2003 -0500, Radia Perlman - Boston Center for > > Networking wrote: > > >Aha. I think Derek's suggestion is a more > > >elegant solution to the problem. To explain > > >it again just because seeing it explained in different > > >words is always helpful, > > >to perform VPN service on behalf of four customer > > >nets, (C1, C2, C3, C4), firewall n would have > > >four identities, say Fn-C1, Fn-C2, Fn-C3, Vn-C4, and > > >also have 4 certificates (for each of the identities) and > > >form four IKE tunnels. Then which customer > > >net the child-SA is for is based on which IKE > > >tunnel it was formed under. > > > > > >The identities could have the same public key or different > > >public keys for the different. > > >It don't think it matters. > > > > > >Radia > > > > > > > > >"Derek Atkins" wrote: > > > >Radia Perlman - Boston Center for Networking > writes: > > > > > > > >> If there is some way to tell what "wire" things > > > >> are coming on, as for instance if they are > > > >> different MPLS tunnels, then there's no problem. > > > >> But if they are forwarding simply with IP, then > > > >> without this way of negotiating on SA creation, > > > >> I don't see how the firewalls can do this. > > > > > > > >Why not just use different identities? > > > > > > > >The ingres firewall already needs some out-of-band mechanism to know > > > >that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can > > > >know this because it's arriving on a different port or a different > > > >MPLS tunnel. Regardless, it doesn't matter, it knows the source. > > > >This means that any firewall endpoint must necessarily have some > > > >meta-IP method to determine VPNs. > > > > > > > >If one piece of hardware is acting as an IPsec terminal point, why > > > >can't it use a different IKE identity per VPN? If I want to set up a > > > >tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for > > > >VPN-1. > > > > > > > >A box could internally apply the meta-IP information for SA selection. > > > >How this is done does not need to be standardized, IMHO. > > > > > > > >-derek > > > > > > > >> Radia > > > >> > > > >> "Scott G. Kelly" wrote: > > > >> >I guess I don't see why you can't have multiple tunnels between the > > > >> >devices, since the tunnel selectors (the nat'd network addresses) are > > > >> >unique. Alternatively, you can use an encapsulation of some sort > (GRE, > > > >> >UDP, L2TP, etc), which permits unique per-customer selectors. > This can > > > >> >be done cleanly without modifying the ipsec protocols, can't it? > > > >> > > > > >> > > > > > > > >-- > > > > Derek Atkins > > > > Computer and Internet Security Consultant > > > > derek@ihtfp.com www.ihtfp.com > > > >-- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Sun Mar 16 05:06:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2GD6qg24835; Sun, 16 Mar 2003 05:06:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06782 Sun, 16 Mar 2003 07:22:32 -0500 (EST) X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: Derek Atkins Cc: "Scott G. Kelly" , "Mark Duffy" , , "Michael Thomas" Subject: Re: Another field for traffic selector? References: <200303141815.h2EIFp006401@sydney.East.Sun.COM> From: Geoff Keating Date: 14 Mar 2003 16:10:54 -0800 In-Reply-To: Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins writes: > Radia Perlman - Boston Center for Networking writes: > > > If there is some way to tell what "wire" things > > are coming on, as for instance if they are > > different MPLS tunnels, then there's no problem. > > But if they are forwarding simply with IP, then > > without this way of negotiating on SA creation, > > I don't see how the firewalls can do this. > > Why not just use different identities? > > The ingres firewall already needs some out-of-band mechanism to know > that a packet from 10.0.0.1 is from VPN-1 rather than VPN-2. It can > know this because it's arriving on a different port or a different > MPLS tunnel. Regardless, it doesn't matter, it knows the source. > This means that any firewall endpoint must necessarily have some > meta-IP method to determine VPNs. > > If one piece of hardware is acting as an IPsec terminal point, why > can't it use a different IKE identity per VPN? If I want to set up a > tunnel for VPN-1, I negotiate an SA for VPN-1 using an IKE ID for > VPN-1. It's worth pointing out that if you try to implement a solution where you *don't* use a different IKE negotation for each customer, this makes it possible for a customer to mount a chosen-plaintext attack and perhaps determine the shared keys and so compromise another customer's traffic. Chosen-plaintext attacks are not hard to mount in many situations where IPSec is in use, but 'not hard' is not always the same as 'easy and convenient'. -- - Geoffrey Keating From owner-ipsec@lists.tislabs.com Sun Mar 16 12:46:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2GKkKg22524; Sun, 16 Mar 2003 12:46:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07349 Sun, 16 Mar 2003 15:11:10 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15987.33466.200314.637791@tero.kivinen.iki.fi> Date: Sat, 15 Mar 2003 21:44:58 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: trevp@trevp.net Subject: Re: New 12288 and 16384 bit groups References: <5.2.0.9.0.20030313161341.02e2bd30@postoffice.pacbell.net> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk trevp@trevp.net (Trevor Perrin) writes: > Out of curiosity, are the primes currently in > draft-ietf-ipsec-ike-modp-groups-05 proven to be safe primes (of the form > N=2q+1, where q is prime), or just proven to be prime? All the groups in the draft-ietf-ipsec-ike-modp-groups-05 are proven to be safe primes (i.e both the p and the (p - 1) / 2 are proven to be prime). The ECPP/primo certificates can be found at http://ftp.ssh.com/pub/ietf/ecpp-certificates/ (that url used to be in the draft, but was removed because url's are not stable enough to be used as references (that url is going to be stable :-)). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Mar 16 16:34:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2H0YNg02741; Sun, 16 Mar 2003 16:34:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07725 Sun, 16 Mar 2003 19:00:36 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <005001c2e99b$2095dc10$e1a36b80@amer.cisco.com> Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 To: "Geoffrey Huang" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 15 Mar 2003 18:43:03 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/16/2003 07:04:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Geoffrey Huang" wrote: > I agree with Dan Harkins' previous comment that the responder can pick > how to authenticate itself based on the initiator's identity. Since > both the IDi and the optional IDr come at the same time, I don't see how > including the optional payload buys you anything. > > The difference between IKE and SSL is that SSL doesn't use the identity > of the "initiator" to demux its own possible identities. > SSL can't use the identity of the initiator to demux its own possible identities because the responder gives its name first. IKE could use the initiator's identity to decide what name to respond as, but this assumes that each initiator would only ever want to talk to a single responder identity at the shared IP address. Suppose there are a few dozen porn sites (i.e. different site names) all at a single IP address. You have to connect to them over an encrypted channel because they take credit card numbers, but they can't use SSL because they send streaming video over UDP. A single user might want to connect to multiple of these sites - not knowing (or caring) that they are colocated. The operator of the server would like to disguise - at least to a limited degree - the fact that the services are colocated (say - to provide the illusion of variety), but doesn't want to waste IP addresses. In this case the server can't tell from the initiator name which virtual server is being accessed. There are probably more respectable uses for this protocol, but this sadly may be the high volume scenario. > A related question I have is what happens if the responder sends an > identity that's different from the IDr requested by the initiator? The responder is free to ignore the IDr; the initiator has to decide whether the provided identity is acceptable. Or it could reject the connection if it didn't think its identity is going to be acceptable. --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@lists.tislabs.com Mon Mar 17 00:28:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2H8Sug29816; Mon, 17 Mar 2003 00:28:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08709 Mon, 17 Mar 2003 02:54:48 -0500 (EST) Message-Id: <200303170756.h2H7u7vk000475@fatty.lounge.org> To: Charlie_Kaufman@notesdev.ibm.com Cc: "Geoffrey Huang" , ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-Reply-To: Your message of "Sat, 15 Mar 2003 18:43:03 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <473.1047887767.1@tibernian.com> Date: Sun, 16 Mar 2003 23:56:07 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If a contrived use of porn is the "high volume scenario" for this feature then I think my observation that this feature will never be used has been strongly validated. We don't need to add features to this protocol that will never be used because these "options" must all be implemented by all compliant implementations even though the features will never be used. More cruft, more spagetti code, more possibility of mistakes, more mandatory "options". More of the stuff we are supposed to get rid of with IKEv2. Dan. On Sat, 15 Mar 2003 18:43:03 EST you wrote > > "Geoffrey Huang" wrote: > > I agree with Dan Harkins' previous comment that the responder can pick > > how to authenticate itself based on the initiator's identity. Since > > both the IDi and the optional IDr come at the same time, I don't see how > > including the optional payload buys you anything. > > > > The difference between IKE and SSL is that SSL doesn't use the identity > > of the "initiator" to demux its own possible identities. > > > SSL can't use the identity of the initiator to demux its own possible > identities because the responder gives its name first. IKE could use > the initiator's identity to decide what name to respond as, but this > assumes that each initiator would only ever want to talk to a single > responder identity at the shared IP address. Suppose there are a few > dozen porn sites (i.e. different site names) all at a single IP address. > You have to connect to them over an encrypted channel because they > take credit card numbers, but they can't use SSL because they send > streaming video over UDP. A single user might want to connect to > multiple of these sites - not knowing (or caring) that they are > colocated. The operator of the server would like to disguise - at > least to a limited degree - the fact that the services are colocated > (say - to provide the illusion of variety), but doesn't want to waste > IP addresses. In this case the server can't tell > from the initiator name which virtual server is being accessed. > > There are probably more respectable uses for this protocol, but this > sadly may be the high volume scenario. > > > > A related question I have is what happens if the responder sends an > > identity that's different from the IDr requested by the initiator? > > The responder is free to ignore the IDr; the initiator has to decide > whether the provided identity is acceptable. Or it could reject the > connection if it didn't think its identity is going to be acceptable. > > --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@lists.tislabs.com Mon Mar 17 01:03:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2H93fg04667; Mon, 17 Mar 2003 01:03:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA08868 Mon, 17 Mar 2003 03:35:12 -0500 (EST) From: "Yoav Nir" To: Subject: RE: QoS and IKEv2 Date: Mon, 17 Mar 2003 10:41:59 +0200 Message-ID: <000001c2ec61$13747fa0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <008c01c2e93d$d1e88a70$292e1dc2@YnirNew> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thinking it over, there needs to be an exception to this. Suppose a faulty or malicious peer keeps creating more and more identical Child-SAs, threatening to fill up your data structures. I think we should be allowed to close such redundant Child-SAs. Of course, this is in response to an attack, which must be allowed, rather than simply closing apparently redundant SAs, which should probably not be allowed. Are there any objections to this change? Yoav -----Original Message----- Subject: RE: QoS and IKEv2 How about rephrasing this: This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling. Into this: This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. A node MAY only close a redundant SA if it was the initiator in the negotiation that led to the creation of the SA. An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling. The only problem I see with this is that this requires that this introduces a concept of an "owner" of an SA. A node would have to keep track of which SAs belong to it (are "local") and which SAs do not (are "remote"). I think I can live with it, although I like the uniquifier idea better. I don't think we need a lot of uniquifier. One byte of the three reserved bytes in the TS payload would be enough. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Radia Perlman - The current IKEv2 spec isn't too explicit about redundant SA's, which (before Jesse brought up the issue) we'd assumed were unintentional, due to creating SAs simultaneously in each direction, upon startup or upon rekeying. What the current spec says about redundant SAs is: "An endpoint SHOULD wait a random amount of time before closing a redundant SA to prevent cycling." It doesn't say you have to close redundant SAs, or even that you should. Here's a proposal (but in the next paragraph I'll propose an even simpler solution): only the initiator of an SA is allowed to close an SA due to its looking redundant. (you're allowed to close it for some other reason, but not because it looks redundant). You still need to wait the random delay if you're closing an SA that you think is redundant with one created by the other end, so that the two ends don't create and delete a single SA simultaneously. But it allows one end to create as many SAs as it wants, and it doesn't require a uniquifier field. It's none of Bob's business why Alice wants to create n SAs all with the same traffic selectors. Bob has to accept traffic on any of them. From owner-ipsec@lists.tislabs.com Mon Mar 17 01:42:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2H9g4g11103; Mon, 17 Mar 2003 01:42:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA09047 Mon, 17 Mar 2003 04:05:42 -0500 (EST) Date: Mon, 17 Mar 2003 11:08:40 +0200 From: Alan Barrett To: ipsec@lists.tislabs.com Subject: Re: New 12288 and 16384 bit groups Message-ID: <20030317090840.GF24659@apb.cequrux.com> References: <5.2.0.9.0.20030313161341.02e2bd30@postoffice.pacbell.net> <15987.33466.200314.637791@tero.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15987.33466.200314.637791@tero.kivinen.iki.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 15 Mar 2003, Tero Kivinen wrote: > All the groups in the draft-ietf-ipsec-ike-modp-groups-05 are proven > to be safe primes (i.e both the p and the (p - 1) / 2 are proven to be > prime). The ECPP/primo certificates can be found at > http://ftp.ssh.com/pub/ietf/ecpp-certificates/ (that url used to be in > the draft, but was removed because url's are not stable enough to be > used as references (that url is going to be stable :-)). Perhaps the IANA or the RFC Editor (or both) would be willing to keep stable copies of supporting documentation that's too large (or otherwise inconvenient) for inclusion in an RFC. If so, then I'd suggest keeping the "ftp.ssh.com" URL in the draft, with a note saying that it should be changed to an "iana.org" or "rfc-editor.org" URL before publication as an RFC. --apb (Alan Barrett) From owner-ipsec@lists.tislabs.com Mon Mar 17 05:10:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HDAsg01285; Mon, 17 Mar 2003 05:10:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA09561 Mon, 17 Mar 2003 07:36:16 -0500 (EST) From: "Jesse Alpert" To: "'Alex Alten'" , Subject: RE: AES & IPsec questions Date: Mon, 17 Mar 2003 14:42:05 +0200 Message-ID: <00c701c2ec82$9e1e88a0$7b2e1dc2@jesse> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Alex, As far as our product goes, here are some answers: > 1. Are these proprietary extensions or based on one of the AES drafts? Based on the drafts. > 2. Are they supported by proprietary or draft extensions to IKE? The transform IDs and algorithm number are based on the drafts (assigned by IANA). > 3. What performance has actually been achieved in practice, in software, on > a Intel PC? (It would be helpful to specify the GHz of the CPU in > your answer.) 710Mbps for AES-128. These results were achieved on a Dual 2.2 GHz Xeon Linux gateway. Hope this answers your questions, Jesse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten Sent: Friday, March 14, 2003 8:24 AM To: ipsec@lists.tislabs.com Subject: AES & IPsec questions Some big vendors have incorporated AES into their IPsec VPN offerings. I have some questions about these that I hope someone on this list can answer. 1. Are these proprietary extensions or based on one of the AES drafts? 2. Are they supported by proprietary or draft extensions to IKE? 3. What performance has actually been achieved in practice, in software, on a Intel PC? (It would be helpful to specify the GHz of the CPU in your answer.) I'm particularly interested in Cisco's implementation, however info about other vendors or Linux open source is also welcome. Thanks in advance, - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Mar 17 09:43:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HHhqg20668; Mon, 17 Mar 2003 09:43:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10086 Mon, 17 Mar 2003 11:56:37 -0500 (EST) Message-Id: <200303171659.h2HGxhw0001891@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-reply-to: Your message of "Sun, 16 Mar 2003 23:56:07 PST." <200303170756.h2H7u7vk000475@fatty.lounge.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Mar 2003 08:59:42 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> If a contrived use of porn is the "high volume scenario" for this How many times do I have to explain this? The average multi-user systems needs this so that it can do process to process tunnels with real credentials. ] 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@lists.tislabs.com Mon Mar 17 11:36:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HJaRg28502; Mon, 17 Mar 2003 11:36:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10391 Mon, 17 Mar 2003 13:40:54 -0500 (EST) Message-ID: <3E760DD2.6B6B8589@briank.com> Date: Mon, 17 Mar 2003 10:02:58 -0800 From: Brian Korver X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com Subject: Re: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > > Charlie Kaufman has released the next version of IKEv2 > (draft-ietf-ipsec-ikev2-05.txt) and we are slowly but surely getting > closer to completion. Many thanks to Charlie and those who > contributed text, ideas, and bug fixes to this new version of the > ikev2 I-D. > > At the time when Charlie began his revisions to produce the 05 I-D, > there were still a few open issues. In the meantime, some additional > issues have opened up, including the discussion between Tero, Francis, > and Radia regarding address management and whether IKE v2 adequately > handles NAT traversal (particularly in transport mode). Furthermore, > ikev2-05 has changed significantly and has much new material to > address various concerns addressed by those on the list, including the > addition of the agreed-upon handling of legacy authentication, more > explicit specifications about when the CERT and CERTREQ packets much > be sent and how they should be handled, the addition of crypto suites, > and so on. [snip] Ted, I have a couple of problems with the latest CERT and CERTREQ sections. Sections 1.2 and 3.6: "If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload." I've heard people ask for this from time to time, but as an implementor I prefer the unordered "bucket of certificates" that we usually have. What motivates this change from IKEv1? Also, I worry that this new rule means that it won't be possible to send 2 EE certificates, for instance to handle expiration rollover. Section 3.7: Why has the contents of the CERTREQ payload been changed from sending the DN to the SHA-1 hash of public keys? This wasn't broken in IKEv1, so what motivates this change? Yes, DNs are variable size, but they're a lot more useful for debugging/diagnostics than SHA-1 hashes are. I don't have any problem with adding an additional "hash" type, but let's not remove our ability to requests certs by CA DN. Section 3.7 (again): We need to be able to request more than just signature certificates, CRLs being the most obvious example. This absolutely needs to be fixed. -brian briank@briank.com From owner-ipsec@lists.tislabs.com Mon Mar 17 11:44:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HJitg28797; Mon, 17 Mar 2003 11:44:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10463 Mon, 17 Mar 2003 14:03:07 -0500 (EST) From: "Geoffrey Huang" To: "'Michael Richardson'" , Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 Date: Mon, 17 Mar 2003 11:06:32 -0800 Message-ID: <001c01c2ecb8$53017fe0$e1a36b80@amer.cisco.com> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200303171659.h2HGxhw0001891@marajade.sandelman.ottawa.on.ca> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Dan" == Dan Harkins writes: > Dan> If a contrived use of porn is the "high volume > scenario" for this > > How many times do I have to explain this? > > The average multi-user systems needs this so that it can do > process to > process tunnels with real credentials. Interesting, but I'm still convinced that the responder can use the initiator's identity to determine how to respond. I'm not certain how a process-to-process tunnel would look exactly, though. -g > ] 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@lists.tislabs.com Mon Mar 17 12:18:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HKIag29886; Mon, 17 Mar 2003 12:18:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10686 Mon, 17 Mar 2003 14:44:50 -0500 (EST) Date: Mon, 17 Mar 2003 14:48:10 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 In-Reply-To: <001c01c2ecb8$53017fe0$e1a36b80@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Mar 2003, Geoffrey Huang wrote: > > The average multi-user systems needs this so that it can do > > process to > > process tunnels with real credentials. > > Interesting, but I'm still convinced that the responder can use the > initiator's identity to determine how to respond. How does knowing the initiator tell you who he wishes to connect to? A server may well provide more than one service, and hence wish to be known under more than one identity. As others have pointed out, the HTTP people initially made the mistake of assuming that the IP destination address was sufficient identification of the connection's target, and ended up deeply regretting it. The result has been a lot of unnecessary consumption of IP address space to provide servers with many IP addresses, something we definitely don't want to encourage further. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 17 12:57:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HKv6g01166; Mon, 17 Mar 2003 12:57:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10833 Mon, 17 Mar 2003 15:22:41 -0500 (EST) Message-Id: <5.2.0.9.0.20030317121818.00bbbc38@postoffice.pacbell.net> X-Sender: trevp@postoffice.pacbell.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 17 Mar 2003 12:26:26 -0800 To: ipsec@lists.tislabs.com From: Trevor Perrin Subject: Re: New 12288 and 16384 bit groups In-Reply-To: <20030317090840.GF24659@apb.cequrux.com> References: <15987.33466.200314.637791@tero.kivinen.iki.fi> <5.2.0.9.0.20030313161341.02e2bd30@postoffice.pacbell.net> <15987.33466.200314.637791@tero.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:08 AM 3/17/2003 +0200, Alan Barrett wrote: >On Sat, 15 Mar 2003, Tero Kivinen wrote: > > All the groups in the draft-ietf-ipsec-ike-modp-groups-05 are proven > > to be safe primes (i.e both the p and the (p - 1) / 2 are proven to be > > prime). The ECPP/primo certificates can be found at > > http://ftp.ssh.com/pub/ietf/ecpp-certificates/ (that url used to be in > > the draft, but was removed because url's are not stable enough to be > > used as references (that url is going to be stable :-)). > >Perhaps the IANA or the RFC Editor (or both) would be willing to keep >stable copies of supporting documentation that's too large (or otherwise >inconvenient) for inclusion in an RFC. > >If so, then I'd suggest keeping the "ftp.ssh.com" URL in the draft, with a >note saying that it should be changed to an "iana.org" or "rfc-editor.org" >URL before publication as an RFC. And even if not, maybe the draft could have a note that the primes are proven to be safe primes, and that certificates do exist (and if there was a website with links to them, with keywords like "IKE primes" and "ECPP certificates", they'd turn up on google easily enough).. Trevor From owner-ipsec@lists.tislabs.com Mon Mar 17 16:28:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I0Rxg12752; Mon, 17 Mar 2003 16:27:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11338 Mon, 17 Mar 2003 18:54:59 -0500 (EST) From: "Geoffrey Huang" To: "'Henry Spencer'" , "'IP Security List'" Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 Date: Mon, 17 Mar 2003 15:58:15 -0800 Message-ID: <000701c2ece1$13d8d790$6f8c8182@amer.cisco.com> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On Mon, 17 Mar 2003, Geoffrey Huang wrote: > > > The average multi-user systems needs this so that it can do > > > process to > > > process tunnels with real credentials. > > > > Interesting, but I'm still convinced that the responder can use the > > initiator's identity to determine how to respond. > > How does knowing the initiator tell you who he wishes to connect to? > A server may well provide more than one service, and hence wish to be > known under more than one identity. Granted, it depends on the type of identity presented. But if you're using something like user@fqdn type, ID_KEY_ID or even a cert DN, the gateway can use that to demux what service you want to talk to. If I'm ghuang@cisco, the gateway knows that I wouldn't be connecting to were-not-cisco.com. > As others have pointed out, the HTTP people initially made > the mistake of > assuming that the IP destination address was sufficient > identification of > the connection's target, and ended up deeply regretting it. > The result > has been a lot of unnecessary consumption of IP address space > to provide > servers with many IP addresses, something we definitely don't want to > encourage further. As long as it's clear what to do in weird cases (e.g., the responder ignores the IDr payload, etc.) I'm not bothered. -g > Henry Spencer > > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Mon Mar 17 16:28:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I0Rxg12751; Mon, 17 Mar 2003 16:27:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11321 Mon, 17 Mar 2003 18:53:58 -0500 (EST) Message-Id: <200303172356.h2HNucf8011778@marajade.sandelman.ottawa.on.ca> To: "Geoffrey Huang" cc: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-reply-to: Your message of "Thu, 13 Mar 2003 11:59:59 PST." <005001c2e99b$2095dc10$e1a36b80@amer.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Mar 2003 15:56:38 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Geoffrey" == Geoffrey Huang writes: Geoffrey> I agree with Dan Harkins' previous comment that the responder Geoffrey> can pick how to authenticate itself based on the initiator's Geoffrey> identity. Since both the IDi and the optional IDr come at the No, it can not. The responder can only do this is it has a specific policy configured for that particular ID. Maybe the very policy poor VPN systems that current vendors configure this is possible. There are lots of messages explaining other scenarios that have been posted in the original thread on this, back in January. There are other deployment scenarios where the policy is created on the fly, and the IDi may not have any pre-configured meaning to the responder. The initiator needs to indicate to whom it wishes to connect to. We (the IETF) got this right with SMTP - Envelope from/to and header from/to. We got it wrong with IKEv1. see: http://www.sandelman.ca/ipsec/2002/12/msg00249.html ] 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@lists.tislabs.com Mon Mar 17 17:00:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I104g13689; Mon, 17 Mar 2003 17:00:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11528 Mon, 17 Mar 2003 19:28:24 -0500 (EST) Date: Mon, 17 Mar 2003 19:31:29 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 In-Reply-To: <000701c2ece1$13d8d790$6f8c8182@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Mar 2003, Geoffrey Huang wrote: > Granted, it depends on the type of identity presented. But if you're > using something like user@fqdn type, ID_KEY_ID or even a cert DN, the > gateway can use that to demux what service you want to talk to. If I'm > ghuang@cisco, the gateway knows that I wouldn't be connecting to > were-not-cisco.com. What this amounts to, I'm afraid, is saying that in some ad-hoc way, people can subdivide the initiator identity into two subfields, the real identity of the initiator and some indication of who he wants to talk to. (They aren't necessarily related, even with the aid of configuration data on the responder end, except in restricted applications where all possible network connections are preconfigured.) To be blunt, saying "well, you can usually sort of intuit the target, somehow, based on the initiator's identity" is a total botch. Two separate items of information ought to be carried in two separate packages, so there is a *standard* way to separate them. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 17 17:21:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I1L0g14537; Mon, 17 Mar 2003 17:21:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11593 Mon, 17 Mar 2003 19:49:36 -0500 (EST) Message-Id: <200303180052.h2I0qUVE013337@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-reply-to: Your message of "Mon, 17 Mar 2003 11:06:32 PST." <001c01c2ecb8$53017fe0$e1a36b80@amer.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Mar 2003 16:52:30 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Geoffrey" == Geoffrey Huang writes: Geoffrey> Interesting, but I'm still convinced that the responder can use Geoffrey> the initiator's identity to determine how to respond. I'm not Geoffrey> certain how a process-to-process tunnel would look exactly, Geoffrey> though. Please explain to me how the responder can do this. My telnet process will say, quite simply, to the kernel: My ID = mcr@marajade.dasblinkenled.org YourID = sales@lox.sandelman.ca (To login to the "sales" account that I have) Using ME-tarzan/You-Jane, my IKE would say: ME =mcr@marajade.dasblinkenled.org YOU=sales@lox.sandelman.ca Without ME-Tarzan/You-Jane, the IKE would say: ME=mcr@marajade.dasblinkenled.org How does the responder pick the right private key to respond with? ] 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 iQCVAwUBPnZtzIqHRg3pndX9AQHTPgQA2WOw07CC8s2KU24n3cYCz497Q3heHyax 9wP3iQ6JVHYdmSSTUKCLH5iM5GbuKfR+aLXs5Ky7jrF8oR6Jdo9+jBX1y0ZalqLq ZcwbdHzI8ci8mB1BEKJfd9k71yaMoMHoQcqOgM4zZDk64itjTH0C4i2fZmCDf04Z IP42w1Xn6XY= =/HdE -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Mar 17 18:43:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I2hvg18262; Mon, 17 Mar 2003 18:43:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12023 Mon, 17 Mar 2003 21:13:43 -0500 (EST) Date: Tue, 18 Mar 2003 04:16:44 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG , owner-ipsec@lists.tislabs.com Subject: Re: comments on ikev2 05 (editorial) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > AUTH = prf(Shared Secret, "Key Pad for IKEv2" | ) > > I added the following explanatory text: > > The pad string is added so that if the shared secret is derived from a > password, the IKE implementation need not store the password in cleartext, > but rather can store a one way transformation of it that could not be used > as a password equivalent for protocols other than IKEv2. > > Adding the key pad as a prefix to the message bytes does not in general > give the same security benefit. > > If you still don't understand the goal, I can try to elaborate more. If you > do understand but think it does not provide the promised benefit, please > explain. Yes. I now understand. However, this is too much of HMAC-centric thinking. In your above proposal you are assuming an arbitrary key-length prf, which is not the general case as discussed in realtion to the Ni|Nr issue (to which I answered separately). Here, there is a (mathematically) cleaner way to achieve what you want. Assuming that SharedSecret is suitable as key to a prf, then you can define AuthSecret = prf(SharedSecret, "Key Pad for IKEv2") and AUTH = prf(AuthSecret, ). Note that in this way you make it clear that it suffices to keep the value AuthSecret in memory (rather than Shared Secret) for authentication (thus achieveing the password protection you intended) Hugo From owner-ipsec@lists.tislabs.com Mon Mar 17 18:44:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I2i4g18275; Mon, 17 Mar 2003 18:44:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12014 Mon, 17 Mar 2003 21:11:42 -0500 (EST) Date: Tue, 18 Mar 2003 04:14:31 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: Use of AES as prf 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 > We could specify (as Hugo recommended) > that each nonce be truncated at half the fixed key size. I'd be happier > using SHA-1(Ni | Nr) truncated as the key. I'd be happier still saying that > even if we're using AES-CBC + XCBC for integrity we still use SHA-1 as our > prf. > > What do others think? Not clear that I qualify as "others" but let me express my view here. I am always glad to see that you are a real fan of HMAC :), yet I do believe that a serious, long-term, protocol must allow for use of other prf's. Certainly prf's based on block ciphers. They may turn to be more secure or more economic (as in the case of h/w implementations that want to save a HMAC implementation). And, as you noted, we alreadyhave a block cipher based prf in one of the ciphersuites. I do not see a problem in requiring the nonces to be strongly random or pseudorandom. Most implementation that are not able to produce good enough nonces wil not produce strong enough DH exponents either (except, maybe, if they generate those on-line). Yet, if this lack of quality randomness is of real concern then you could opt to define the key as Ni xor Nr. The benefit here is that it is enough that one of the peers generates a good (pseudo) random nonce for the xor to be good. The drawback is that the responder can fix the xor to any value of his choice. I am not sure that the latter is a real problem. After all if the (authenticated) responder in a given session is corupted or malicious then there is no much meaning to the security of that session. Moreover, contrary to some seemingly popular belief, either peer can weaken the exchanged key via their chosen DH exponents. (For example by chosing a 8-bit exponent...) In any case, I would not leave it to an external per-prf specification to determine the way that the key is derived for use in the prf. This will probably create confusion and, in practice, will be a barrier to the use of non-HMAC prfs. 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@lists.tislabs.com Mon Mar 17 20:18:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2I4I8g20522; Mon, 17 Mar 2003 20:18:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA12299 Mon, 17 Mar 2003 22:47:27 -0500 (EST) Message-Id: <200303180350.h2I3oL5f017324@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Me-Tarzan/You-Jane and key rollover (was Re: "Me Tarzan, You Jane" in IKEv2-05 ) In-reply-to: Your message of "Mon, 17 Mar 2003 11:06:32 PST." <001c01c2ecb8$53017fe0$e1a36b80@amer.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Mar 2003 19:50:21 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Since Dan doesn't find streaming media to be a good enough reason for Me-Tarzan/You-Jane, I'll provide an example of using Me-Tarzan/You-Jane to aid in key-rollover. Recall that the "You-Jane" part provides both the ID that the initiator was expecting to talk to, but also a reference to the public key, and optionally, the public key as well. {Dan, please go visit the HTTP load-balancing vendors and ask them how well they support SSL, and you'll understand why there might in fact me hundreds of streaming sites being served as a single IP, yet with multiple keysets involved. And... go ask the Apache people how where a lot of the money for the people funded to work on Apache comes from} Postulate a key distribution system with replication and caches. DNS(sec) CERTAINLY fits this model, as does replicated LDAP. The key characteristic is that the caches have no reason to go look for new information until the time to live on the existing information is over. Further, replicated servers are not updated instantly, and may not even know there is an update until some period of time has passed and they decide to look. (DNS Notify are hints to look now! They can get lost) To make conversation easiest, let's assume that the characteristic time for the system is 1 day. I.e. if I make a change, now I can reliably be certain it will spread everywhere in 1 day. It *MAY* spread faster than that. Assume that I am the responder ("Jane"). So, there are two methods to roll one's keys in the presence of a replicated database. This is not an emergency roll-over - we can discuss that later. 1) publish the key that I will use tomorrow, today. That guarantees that everyone out there will have it when I start using it. 2) always sign everything with all keys that I've published. If I've planned everything ahead of time, then I've marked the old key as expiring at midnight (in a conveninent timezone) today. I've also marked the new key as not being valid until midnight today. This means that all of the peers that I communicate with had better be able to get the new key at precisely the right time. Otherwise, they go offline. If I try to be smart and make the validity periods overlap, then there is no real reason for a peer to look for a new key until the old one is no good. (CRLs help here, but DNSSEC certainly doesn't provide them) So, during the overlap, I will have some peers who want to connect to me and will assume that I have switched to the new key, and some that have not yet seen the new key, and will use the old key. I'm left with the question: which one do I sign with? Me-Tarzan/You-Jane lets the peer tell me what they expected, so that I can make them happy. You now say, well, if the peer will just look periodically for new keys and then not use the new key until the old is expired. The problem is that there is really no way to do an emergency roll-over if a key is compromised - the clients will not use the new key until the old one expires. This DEFINITELY occurs with DNSSEC borne keys. FreeS/WAN has been using such keys for some years now, and we have experienced *EXACTLY* this in IKEv1. ] 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 iQCVAwUBPnaA3oqHRg3pndX9AQGkdAQArxPNmub2k1bhLUvUCGMnkJtjggrg3aoh GS3V7dxVvvuOn9Z/mlY+BpKy2KP6T5usbvcPuJ93AyR97pXf4nTJ7oYY7NTeqN1k C3V+AbeQkCzeOdXC4iU75HzrMvPS8gGp1gJWP8F4jy9j1sbPQ8CArCzvNKnBtXZo qI/JzW5BQKc= =cLTs -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 18 03:47:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IBl5g28321; Tue, 18 Mar 2003 03:47:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13215 Tue, 18 Mar 2003 06:16:15 -0500 (EST) Message-ID: <3E76D4A7.20400@roc.co.in> Date: Tue, 18 Mar 2003 13:41:19 +0530 From: ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKEv2: prepending four octets Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear All, I am going through the ikev2-0.5 draft.It says In the IKE header when sent on UDP port 4500 ,IKE messages have prepended four octets of Zero. My doubt is what made to prepend four octets of Zeroes before the IKE message. Thanks in advance, Ravi Kumar CH. From owner-ipsec@lists.tislabs.com Tue Mar 18 03:49:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IBnpg28776; Tue, 18 Mar 2003 03:49:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13235 Tue, 18 Mar 2003 06:22:15 -0500 (EST) Message-ID: <3E76D63F.1090409@roc.co.in> Date: Tue, 18 Mar 2003 13:48:07 +0530 From: ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec Subject: ikev2:Next payload Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear All, According to the draft If the current Payload is the last in the message, then Next Payload will be 0 but for an Encrypted Payload, which must always be the last Payload of a message, the Next Payload field is set to the Payload of the first contained Payload. Why the Next payload field is not zero in this case? Regards, Ravi Kumar CH From owner-ipsec@lists.tislabs.com Tue Mar 18 04:17:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ICH6g01982; Tue, 18 Mar 2003 04:17:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13362 Tue, 18 Mar 2003 06:48:37 -0500 (EST) From: "Yoav Nir" To: Subject: RE: IKEv2: prepending four octets Date: Tue, 18 Mar 2003 13:55:27 +0200 Message-ID: <004001c2ed45$4536a290$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E76D4A7.20400@roc.co.in> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I will try to answer both your questions: 1. The next payload field of an encrypted payload is that of the first encapsulated payload rather than zero because otherwise we would not know how to parse the first encrypted payload. 2. You prepend four zeros to IKE messages, because no IPsec-encapsulated-in-UDP message begins with four zeros. An encapsulated IPSec packet begins with the SPI which is always non-zero. Adding four zeros to the beginning of an IKE message makes it possible to distinguish IKE messages from encapsulated IPSec packets. Hope this helps Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ravi Sent: Tuesday, March 18, 2003 10:11 AM To: ipsec@lists.tislabs.com Subject: IKEv2: prepending four octets Dear All, I am going through the ikev2-0.5 draft.It says In the IKE header when sent on UDP port 4500 ,IKE messages have prepended four octets of Zero. My doubt is what made to prepend four octets of Zeroes before the IKE message. Thanks in advance, Ravi Kumar CH. From owner-ipsec@lists.tislabs.com Tue Mar 18 05:22:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IDM5g07293; Tue, 18 Mar 2003 05:22:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA13574 Tue, 18 Mar 2003 07:50:06 -0500 (EST) Message-ID: <3E771A24.3050609@roc.co.in> Date: Tue, 18 Mar 2003 18:37:48 +0530 From: ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec Subject: IKEv2: prepending four octets Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear All, I am going through the ikev2-0.5 draft.It says In the IKE header when sent on UDP port 4500 ,IKE messages have prepended four octets of Zero. My doubt is what made to prepend four octets of Zeroes before the IKE message. Thanks in advance, Ravi Kumar CH. From owner-ipsec@lists.tislabs.com Tue Mar 18 09:04:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IH44g21527; Tue, 18 Mar 2003 09:04:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14146 Tue, 18 Mar 2003 11:25:20 -0500 (EST) Message-ID: <20030318162859.62877.qmail@web12203.mail.yahoo.com> Date: Tue, 18 Mar 2003 08:28:59 -0800 (PST) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: ikev2-05: encrypted payload, next payload field To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm not sure whether this has been already discussed; but here goes. What is the motivation for the current description of the Encrypted payload? Since the draft is now essentially copying the ESP format for use with the Encrypted payload, why not go all the way? Instead of putting the type of the first encrypted payload into the plaintext header, why not put it into the "trailer" part of the encrypted portion, as ESP does? This way, the next payload field would have no special significance. It would be zero if the Encrypted payload was last in the message; if it wasn't the last, it would have the ordinary IKE meaning. No information about encrypted payload types would be leaked, and if necessary in the future, multiple Encrypted payloads could be used in a message. -Sami __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-ipsec@lists.tislabs.com Tue Mar 18 09:39:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IHdtg22904; Tue, 18 Mar 2003 09:39:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14227 Tue, 18 Mar 2003 12:09:42 -0500 (EST) From: dharkins@tibernian.com Message-Id: <200303181716.h2IHGNE52642@homebrew.trpz.com> To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-Reply-To: Your message of "Mon, 17 Mar 2003 16:52:30 PST." <200303180052.h2I0qUVE013337@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52639.1048007783.1@trpz.com> Date: Tue, 18 Mar 2003 09:16:23 -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How does the responder pick the right private key? You haven't said how "sales@lox.sandelman.ca" is uniquely bound to a key in the first place. For the standard way of binding identities to keys you can use the standard way of conveying this information-- a CERT_REQUEST payload with DN equal to the issuer of the certificate whose DN contains sale@lox.sandelman.ca and whose public key corresponds to the private key you want the responder to use. If you're not using some standard way of binding opaque strings (that may *look* like email names but are not necessarily) then you can use a proprietary method to convey the necessary information for your proprietary scheme. Use a private use payload with the generic header and _do not set the critical bit_. But you don't need to force everyone to implement a mechanism that will not be used just so you can do some proprietary key binding scheme between yourselves. Dan. On Mon, 17 Mar 2003 16:52:30 PST you wrote > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Geoffrey" == Geoffrey Huang writes: > Geoffrey> Interesting, but I'm still convinced that the responder can use > Geoffrey> the initiator's identity to determine how to respond. I'm not > Geoffrey> certain how a process-to-process tunnel would look exactly, > Geoffrey> though. > > Please explain to me how the responder can do this. > > My telnet process will say, quite simply, to the kernel: > > My ID = mcr@marajade.dasblinkenled.org > YourID = sales@lox.sandelman.ca > > (To login to the "sales" account that I have) > > Using ME-tarzan/You-Jane, my IKE would say: > > ME =mcr@marajade.dasblinkenled.org > YOU=sales@lox.sandelman.ca > > Without ME-Tarzan/You-Jane, the IKE would say: > > ME=mcr@marajade.dasblinkenled.org > > How does the responder pick the right private key to respond with? > > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architec >t[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device drive >r[ > ] 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 > > iQCVAwUBPnZtzIqHRg3pndX9AQHTPgQA2WOw07CC8s2KU24n3cYCz497Q3heHyax > 9wP3iQ6JVHYdmSSTUKCLH5iM5GbuKfR+aLXs5Ky7jrF8oR6Jdo9+jBX1y0ZalqLq > ZcwbdHzI8ci8mB1BEKJfd9k71yaMoMHoQcqOgM4zZDk64itjTH0C4i2fZmCDf04Z > IP42w1Xn6XY= > =/HdE > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 18 10:07:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2II7sg25272; Tue, 18 Mar 2003 10:07:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14362 Tue, 18 Mar 2003 12:33:05 -0500 (EST) Message-Id: <200303181735.h2IHZuPN018576@marajade.sandelman.ottawa.on.ca> To: "'IP Security List'" Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-reply-to: Your message of "Mon, 17 Mar 2003 15:58:15 PST." <000701c2ece1$13d8d790$6f8c8182@amer.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 09:35:55 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Geoffrey" == Geoffrey Huang writes: Geoffrey> Granted, it depends on the type of identity presented. But if Geoffrey> you're Geoffrey> using something like user@fqdn type, ID_KEY_ID or even a cert Geoffrey> DN, the How. I'm mcr@sandelman.ca. What service do I want to connect to? Tell 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"); [ From owner-ipsec@lists.tislabs.com Tue Mar 18 10:17:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IIHNg25620; Tue, 18 Mar 2003 10:17:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14420 Tue, 18 Mar 2003 12:46:10 -0500 (EST) From: dharkins@tibernian.com Message-Id: <200303181752.h2IHquE52682@homebrew.trpz.com> To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Me-Tarzan/You-Jane and key rollover (was Re: "Me Tarzan, You Jane" in IKEv2-05 ) In-Reply-To: Your message of "Mon, 17 Mar 2003 19:50:21 PST." <200303180350.h2I3oL5f017324@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52679.1048009976.1@trpz.com> Date: Tue, 18 Mar 2003 09:52:56 -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Mar 2003 19:50:21 PST you wrote > > Since Dan doesn't find streaming media to be a good enough reason for > Me-Tarzan/You-Jane, I'll provide an example of using Me-Tarzan/You-Jane > to aid in key-rollover. Recall that the "You-Jane" part provides both the ID > that the initiator was expecting to talk to, but also a reference to the > public key, and optionally, the public key as well. No, I don't recall that! In fact, this is the ENTIRE DEFINITION of the "Me Tarzan/You Jane" feature in ikev2-05: The optional payload IDr enables Alice to specify which of Bob's identities she wants to talk to. This is useful when Bob is hosting multiple identities at the same IP address. There is no reference to a public key and no option to actually place a public key in an ID payload. In fact there is not even any description of what such an identity should contain. ID_IPV4_ADDR? Probably not but given the amount of grief I got over how underspecified IKEv1 was ("You didn't state what the behavior should be if you get a VENDOR ID payload you don't recognize"-- actual quote!) I guess I was expecting new features to be defined better. Of course you could use ID_KEY_ID. But that's proprietary and there is no way _independent_ implementations could interoperate with a scheme that crams keys and undefined references to keys into an ID payload. I snipped the rest of your email but let me ask you this: why can't you use the CERT_REQUEST payload with type=3 (DNS Signed Key) and the body of the payload is whatever string you want to use to convey "You Jane"? Don't like using Type=3? OK, how about type=11 (Raw RSA Key)? Don't like that then let's define a type=14 for whatever usage you want and let's define _exactly_ what that use is. What we don't need is TWO OPTIONAL PAYLOADS IN THE SAME MESSAGE (!!!) that both give hints about what identity the initiator is expecting the responder to use. Dan. From owner-ipsec@lists.tislabs.com Tue Mar 18 11:13:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IJDXg01211; Tue, 18 Mar 2003 11:13:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14677 Tue, 18 Mar 2003 13:37:09 -0500 (EST) From: "Geoffrey Huang" To: "'Michael Richardson'" , "'IP Security List'" Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 Date: Tue, 18 Mar 2003 10:40:50 -0800 Message-ID: <001e01c2ed7d$e5f133c0$e1a36b80@amer.cisco.com> 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.4024 In-reply-to: <200303181735.h2IHZuPN018576@marajade.sandelman.ottawa.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Geoffrey" == Geoffrey Huang writes: > Geoffrey> Granted, it depends on the type of identity > presented. But if > Geoffrey> you're > Geoffrey> using something like user@fqdn type, ID_KEY_ID > or even a cert > Geoffrey> DN, the > > How. I'm mcr@sandelman.ca. > What service do I want to connect to? Tell me. *I* can't tell you that because *I* am not the security gateway ;-). This has to be a policy decision configured at the gateway. Like if you're mcr@sandelman.ca, what optional IDr would you present? security-gateway.sandelman.ca? Then what's the point of presenting both pieces of information, since the latter can be inferred from the former. But as I said before, this isn't a thorn in my side - it's an optional payload, so I'm not too bothered by it. I only wanted it to be clarified what to do if the responder doesn't return the IDr the initiator proposed. -g > ] 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@lists.tislabs.com Tue Mar 18 11:44:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IJiKg02765; Tue, 18 Mar 2003 11:44:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14792 Tue, 18 Mar 2003 14:12:33 -0500 (EST) Date: Tue, 18 Mar 2003 14:16:01 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 In-Reply-To: <001e01c2ed7d$e5f133c0$e1a36b80@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 18 Mar 2003, Geoffrey Huang wrote: > > How. I'm mcr@sandelman.ca. > > What service do I want to connect to? Tell me. > > *I* can't tell you that because *I* am not the security gateway ;-). > This has to be a policy decision configured at the gateway. Suppose this is *not* a VPN, so it's *not* preconfigured down to the last detail. Then there is no policy which says which service mcr@sandelman.ca might want, because there is no way to tell that in advance. Even if it is preconfigured, for that matter, there might be more than one service he might want, and hence no way to intuit a single answer. > ...you're mcr@sandelman.ca, what optional IDr would you present? > security-gateway.sandelman.ca? Why would he present a name associated with him? IDr is meant to be an identity meaningful on the responder, not on the initiator. He would ask for, say, area51.topsecretRandD.cisco.com. There's no way you can infer that from mcr@sandelman.ca. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 18 13:35:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILZmg08913; Tue, 18 Mar 2003 13:35:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15146 Tue, 18 Mar 2003 16:01:39 -0500 (EST) Message-Id: <200303182104.h2IL4lPn024351@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-reply-to: Your message of "Tue, 18 Mar 2003 09:16:23 PST." <200303181716.h2IHGNE52642@homebrew.trpz.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 13:04:47 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "dharkins" == dharkins writes: dharkins> How does the responder pick the right private key? You haven't dharkins> said how "sales@lox.sandelman.ca" is uniquely bound to a key in dharkins> the first place. For the standard way of binding identities to dharkins> keys you can use the standard way of conveying this dharkins> information-- a CERT_REQUEST payload with DN equal to the I do not speak PKIX, so please explain this to me again. Based upon deployment experience with IPsec, neither does anyone else. If you are saying that PKIX is a *REQUIREMENT* for doing IPsec with IKEv2, then I'll stick to IKEv1. If your answer is YES, to the above, then we can stop doing any of the legacy authentication things as well. Many people will be a lot happier. Raw RSA keys is a stepping stone between PSK and full-X.509. It works. ] 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 iQCVAwUBPneJ7YqHRg3pndX9AQEV8QP5AZTiisM1sd6pMq+ppI97DLxW2uJmhSiF vgb1ZzRCeaf3j7e/B3Ixmv4s2PmXRW6zhH/cPSPv2/WRFh0foiipBAQcPAEE7x1c wUyKZUgWunJSn6tAASV2iu8hy+pJX6y/FCF3PZ68a6aDvHCUhUObsZu79LR+ciF/ Z4XMWJPjR1M= =pS7r -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 18 13:36:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILa0g08927; Tue, 18 Mar 2003 13:36:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15155 Tue, 18 Mar 2003 16:05:42 -0500 (EST) Message-Id: <200303182109.h2IL9KCu024456@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Me-Tarzan/You-Jane and key rollover (was Re: "Me Tarzan, You Jane" in IKEv2-05 ) In-reply-to: Your message of "Tue, 18 Mar 2003 09:52:56 PST." <200303181752.h2IHquE52682@homebrew.trpz.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 13:09:19 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "dharkins" == dharkins writes: dharkins> On Mon, 17 Mar 2003 19:50:21 PST you wrote >> Since Dan doesn't find streaming media to be a good enough reason for >> Me-Tarzan/You-Jane, I'll provide an example of using >> Me-Tarzan/You-Jane to aid in key-rollover. Recall that the "You-Jane" >> part provides both the ID that the initiator was expecting to talk to, >> but also a reference to the public key, and optionally, the public key >> as well. dharkins> No, I don't recall that! In fact, this is the ENTIRE DEFINITION dharkins> of the "Me Tarzan/You Jane" feature in ikev2-05: dharkins> The optional payload IDr enables Alice to specify which of dharkins> Bob's identities she wants to talk to. This is useful when Bob dharkins> is hosting multiple identities at the same IP address. I can't be responsible for this. In fact, I haven't read -05 yet, I'm embarrased to say. I guess, I got the impression that the entire text as was written was used. dharkins> What we don't need is TWO OPTIONAL PAYLOADS IN THE SAME MESSAGE dharkins> (!!!) that both give hints about what identity the initiator dharkins> is expecting the responder to use. I don't mind putting them in a different payload. Would that make you happy? It seemed redundant 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 iQCVAwUBPneK/oqHRg3pndX9AQFnMgP7B2o3gj4cfxfG+d5tF/cXAKbKMGkWjx7T 2rKXuJiCCZrB3U9GE/z28thrCHkjMwgdgkni6y2ucLH9AK4RsjFOI0njjInhDxMi ZmxQ8DPldBTO9FVCKSlfJYLF7JxdI8bIgPqtr8ysL0AVuR+Ox+nuL0C4xh0Bovgu DrZwkQyVwkM= =zXMD -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 18 13:39:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ILddg09059; Tue, 18 Mar 2003 13:39:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15173 Tue, 18 Mar 2003 16:11:43 -0500 (EST) Message-Id: <200303182115.h2ILFXa8024607@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-reply-to: Your message of "Tue, 18 Mar 2003 09:16:23 PST." <200303181716.h2IHGNE52642@homebrew.trpz.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 13:15:32 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "dharkins" == dharkins writes: dharkins> How does the responder pick the right private key? You haven't dharkins> said how "sales@lox.sandelman.ca" is uniquely bound to a key in dharkins> the first place. For the standard way of binding identities to I don't see how it matters how the binding is done. It is a local matter. Maybe I have /etc/keys. The responder has a list of identities that it is authoritative for. We generally felt that the the You-Tarzan part could indicate what identity one might wish to speak to. While the CERT_REQUEST would indicate that one *also* needs to get the full chain of the keys to authenticate that identity - that there wasn't a way to get this otherwise. Remember that we were trying to get rid of big certificate chains. ] 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 iQCVAwUBPneMc4qHRg3pndX9AQGd5AQA3KKLI/yj8Jl6cC6lNNBZPFoMXzVHDuLe Pjd5s4nIe9ROUH8AdF41uT32dWN+R9ESgQgYVhq0GKW26aL7F4xXX1fq1DKso7Zk BY2o2qbu22P4XMTw50zh6VSQ62byfx85knynJOlJFmnT6BwKq0+CJkSfogQ7qrGO LuI6kPY766Y= =/+tR -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 18 14:16:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IMGgg10945; Tue, 18 Mar 2003 14:16:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15472 Tue, 18 Mar 2003 16:48:48 -0500 (EST) Message-Id: <200303182152.h2ILq9of054151@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-reply-to: Your message of Thu, 13 Mar 2003 00:54:25 +0200. <15983.47777.849792.382994@ryijy.hel.fi.ssh.com> Date: Tue, 18 Mar 2003 22:52:09 +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: > 2.23 NAT Traversal ... > Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When > working through a NAT, it is generally better to pass IKE packets > over port 4500 because some older NATs modify IKE traffic on port 500 > in an attempt to transparently establish IPsec connections. Such NATs > may interfere with the straightforward NAT traversal envisioned by > this document, so an IPsec endpoint that discovers a NAT between it > and its correspondent SHOULD send all subsequent traffic to and from ^^^^^^ MUST The NAT-T protocol does not work with current NAT boxes if you try to run it over port 500. We must change the port from the 500 to 4500 immediately when we detect NAT. => I am not convinced by this "immediately" and this has an impact on legacy authentication or other stuff which add messages to the IKE_AUTH "exchange". Also the NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP must be in the first two packets, so we can detect NAT before we start negotiating the child SA => same concern. (especially if we want to add the ORIGINAL-ADDRESS notification or similar to support transport mode ESP). => I don't buy this. IMHO the only constraint is NAT must be detected before the IPsec SAs are used. But used != negociated. With implicit peer address update, the NAT detection can be done in IKE_AUTH and the switch to UDP 4500 performed only after IKE_AUTH. There are many advantages to keep same addresses and ports in all messages of the initial phase. > IKE MUST listen on port 4500 as well as port 500. IKE MUST respond > to the IP address and port from which packets arrived. > > The IKE responder MUST include in its IKE_SA_INIT response Notify > payloads of type NAT-DETECTION-SOURCE-IP and NAT-DETECTION- > DESTINATION-IP. The IKE initiator MUST check these payloads if > present and if they do not match the addresses in the outer packet > MUST tunnel all future IKE, ESP, and AH packets associated with > this IKE-SA over UDP port 4500. I assume that this means that we do not negotiate the UDP-tunnel or UDP-transport mode as in IKEv1? This is fine with me, but I think we need some more text here to say so. => I agree (on both points). Also we need some references to how to actually encapsulate the ESP packets etc. We also need to specify better how to detect which side is behind NAT (the UDP encapsulation protocol needs that information to enabled keepalives only from the host behind NAT, and the IKE needs that to enable implicit port updating if and only if the other end is behind NAT (it MUST NOT be enabled if the other end is not behind NAT)). => good comment. I.e something like this: ---------------------------------------------------------------------- The IKE responder MUST include in its IKE_SA_INIT response Notify payloads of type NAT-DETECTION-SOURCE-IP and NAT-DETECTION- DESTINATION-IP. The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST switch to port 4500 for the IKE traffic and all IPsec SAs traffic (ESP packets) MUST use the UDP encapsulation over port 4500 as defined in the [Hutt02]. The changing to port 4500 MUST happen immediately after IKE_SA_INIT exchange, i.e IKE_AUTH payloads are sent with port 4500 (the reply to IKE_SA_INIT must come back to port 500, as specified by generic rule that reply back to address where you => this generic rule is not enough clear in the current document. got the packet, and also because the mapping for the port 4500 is not yet open in the NAT box, i.e the first packet must come from the inside). => so you should agree that the asymmetry of the current draft is bad, i.e., the responder cannot be behind the NAT box. My proposal has not this problem... The purpose of NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP notifications is twofold, It not only detects the presence of NAT between two IKE peers, it also detects where the NAT is. The location of the NAT device is important in that the keepalives need to initiate from the peer "behind" the NAT, and also so that implicit address updating is only enabled if and only if the other end is behind NAT. ... => It seems we share some concerns about the current text about NAT traversal (:-). 2.24 NAT Traversal Implicit Address Updating => it would be fine to use the "peer address" term. There are cases where NAT box decides to remove mappings that are ... => this is another example of missing text in the current draft. Keepalives cannot be used for this purposes as they are not => there are many types of keepalives. You should be more accurate, for instance "UDP keepalives cannot ...". authenticated, but any IKE authenticated IKE packet or UDP => IKE messages are authenticated if they run over the IKE SA encapsulated ESP packet can be used to detect that the IP address => s/ESP/IPsec/ or the port has changed. => in fact it is enough to get a valid (known SPI, authenticated) IPsec or IKE packet. > NAT-DETECTION-SOURCE-IP 24582 > > This notification is used to by its recipient to determine > whether the source is behind a NAT box. The data associated > with this notification is a SHA-1 digest of the SPIs, IP > address and port on which this packet was sent. There MAY > be multiple notify payloads of this type in a message if the > sender does not know which of several network attachments > will be used to send the packet. The recipient of this > notification MAY compare the supplied value to a hash of the > source IP address and port and if they don't match it MAY ^^^ > invoke NAT specific handling (like using UDP encapsulation > of ESP packets and subsequent IKE packets). Alternately, it > MAY reject the connection attempt if NAT traversal is not > supported. >From the "The recipient of this notification ..." change to this: ---------------------------------------------------------------------- The recipient of this notification MAY compare the supplied value to a hash of the source IP address and port and if they don't match it SHOULD enable NAT traversal (see section 2.23). Alternately, it MAY reject the connection attempt if NAT traversal is not supported. => s/supported/& or enabled/ and I am in favor of MUSTs. Note we have a conflict about the term "enable", I propose for your usage the term activate ? If this check fails it means that the other end is behind NAT and this end SHOULD enable the NAT Traversal implicit address updating (see section 2.24). => s/SHOULD/MUST/ ? and replace with this: ---------------------------------------------------------------------- The recipient of this notification MAY compare the supplied value to a hash of the destination IP address and port and if they don't match it SHOULD invoke NAT traversal (see section 2.23). Alternately, it MAY reject the connection attempt if NAT traversal is not supported. => same comment. If this check fails it means that this end is behind NAT and this end should start sending keepalives as defined in the [Hutt02]. => s/should/SHOULD/ ? > 5 Security Considerations The NAT traversal needs some more entries here (copied from draft-ietf-ipsec-nat-t-ike-05): => I agree! ---------------------------------------------------------------------- As the internal address space is only 32 bits, and it is usually very sparse, it might be possible for the attacker to find out the internal address used behind the NAT box by trying all possible IP-addresses and trying to find the matching hash. The port numbers are normally fixed to 500, and the SPIs can be extracted from the packet. This limits the hash calculations down to 2^32. If educated guess of use of private address space is done, then the number of hash calculations needed to find out the internal IP address goes down to the 2^24 + 2 * (2^16). Updating the IKE SA / ESP UDP encapsulation IP addresses and ports for each valid authenticated packet can cause DoS in case we have attacker who can listen all traffic in the network, and can change the order of the packet and inject new packets before the packet he has already seen. I.e attacker can take the authenticated packet from the host behind NAT, change the packet UDP source or destination ports or IP addresses and sent it out to the other end before the real packet reaches there. The host not behind the NAT will update its IP address and port mapping and sends further traffic to wrong host or port. This situation is fixed immediately when the attacker stops modifying the packets as the first real packet will fix the situation back to normal. Implementations SHOULD AUDIT the event every time the mapping is changed, as in normal case it should not happen that often. => fine. It seems you share my argument that the implicit peer address update mechanism is the best defense against a rogue NAT. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 18 14:19:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IMJ0g11381; Tue, 18 Mar 2003 14:19:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15501 Tue, 18 Mar 2003 16:52:52 -0500 (EST) Message-Id: <200303182156.h2ILucaj023939@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-Reply-To: Your message of "Tue, 18 Mar 2003 13:15:32 PST." <200303182115.h2ILFXa8024607@marajade.sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Tue, 18 Mar 2003 16:56:38 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I don't see how it matters how the binding is done. It is a local matter. > Maybe I have /etc/keys. The responder has a list of identities that it is > authoritative for. yes, and it's likely to be the case that in peer-to-peer situations, initiator and responder may swap roles over the long run -- but the entity which was previously responder wants to ensure it talks to the same entity which was the initiator, and it could thus convert a received "me jane" into an outgoing "me tarzan, you jane" some time afterwards.. - Bill From owner-ipsec@lists.tislabs.com Tue Mar 18 14:22:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IMMjg11694; Tue, 18 Mar 2003 14:22:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15510 Tue, 18 Mar 2003 16:53:56 -0500 (EST) Message-Id: <200303182157.h2ILvaof054191@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Dispensa cc: Derek Atkins , Charlie_Kaufman@notesdev.ibm.com, Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: bidding down attach on NAT-T In-reply-to: Your message of 12 Mar 2003 20:23:04 CST. <1047522184.2078.25.camel@bilbo> Date: Tue, 18 Mar 2003 22:57:36 +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: IPSEC (as implemented) is a massive pain wrt NAT. Even if users have a choice to remove their NAT (i.e. their home Linksys router), they usually don't want to or can't. => I believe you assume far too much about the power of the IETF. The only useful thing that IETF can (should!) do is to define a good NAT traversal mechanism. To make its support mandatory is only annoying for implementors, this doesn't make it more available on the market... I realize there are lots of other ways for IPSEC to be employed, but remote network access is certainly a key area that is hurting because of this. I strongly recommend a MUST for NAT-T. => reread RFC 2119. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 18 15:12:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2INC2g14895; Tue, 18 Mar 2003 15:12:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15741 Tue, 18 Mar 2003 17:29:01 -0500 (EST) Reply-To: From: "Jimmy Zhang" To: "'IP Security List'" Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 Date: Tue, 18 Mar 2003 14:31:46 -0800 Message-ID: <001501c2ed9e$2d67fac0$0100a8c0@mshome.net> 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, what is Notify payload designed for? It can handle this kind of thing perfectly. What we need is to assign another notify type, as Dan said. Those sites which hosts multiple domain names must support this notify type. Thanks, Jimmy Zhang > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Henry Spencer > Sent: Tuesday, March 18, 2003 11:16 AM > To: IP Security List > Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 > > > On Tue, 18 Mar 2003, Geoffrey Huang wrote: > > > How. I'm mcr@sandelman.ca. > > > What service do I want to connect to? Tell me. > > > > *I* can't tell you that because *I* am not the security > gateway ;-). > > This has to be a policy decision configured at the gateway. > > Suppose this is *not* a VPN, so it's *not* preconfigured down > to the last detail. Then there is no policy which says which > service mcr@sandelman.ca might want, because there is no way > to tell that in advance. > > Even if it is preconfigured, for that matter, there might be > more than one service he might want, and hence no way to > intuit a single answer. > > > ...you're mcr@sandelman.ca, what optional IDr would you present? > > security-gateway.sandelman.ca? > > Why would he present a name associated with him? IDr is > meant to be an identity meaningful on the responder, not on > the initiator. He would ask for, say, > area51.topsecretRandD.cisco.com. There's no way you can > infer that from mcr@sandelman.ca. > > > Henry Spencer > > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Tue Mar 18 15:32:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2INWbg15923; Tue, 18 Mar 2003 15:32:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15881 Tue, 18 Mar 2003 17:58:21 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15991.42280.592698.747199@ryijy.hel.fi.ssh.com> Date: Wed, 19 Mar 2003 01:00:56 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-Reply-To: <200303182152.h2ILq9of054151@givry.rennes.enst-bretagne.fr> References: <15983.47777.849792.382994@ryijy.hel.fi.ssh.com> <200303182152.h2ILq9of054151@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 17 min X-Total-Time: 16 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > The NAT-T protocol does not work with current NAT boxes if you try to > run it over port 500. We must change the port from the 500 to 4500 > immediately when we detect NAT. > => I am not convinced by this "immediately" and this has an impact on > legacy authentication or other stuff which add messages to the IKE_AUTH > "exchange". I think the easiest place to switch to port 4500 is after hte IKE_SA_INIT packets, i.e when sending the first IKE_AUTH packets. > With implicit peer address update, the NAT detection can be done in IKE_AUTH > and the switch to UDP 4500 performed only after IKE_AUTH. There are going to be implementations, that are not supporting the implicit peer address updates, and for them the state machine goes much easier if they can store the used address and port from the IKE_AUTH packet, than to wait for the next UDP enacpsulated packet after IKE_AUTH. Also note, that if we switch port after IKE_AUTH, then the responder CANNOT initiate any exchanges before the responder either initiates another IKE exchange on new port or sends UDP encapsulated ESP packet. This would cause wierd problems in such cases. It cannot use the port 500, as there is no keepalives for that port, thus the NAT mapping goes away quite quickly. > There are many advantages to keep same addresses and ports in all > messages of the initial phase. For the responder side it does not matter, it will reply back to the same address where the packet came in. Also when the IKE_AUTH is finished it can store the last address and port used, and associate them to the IKE SA so, when it needs remote peer address it can use them directly. For the initiator it is also quite easy, simply switch the source and destination port to 4500 when it detects NAT, and use them from that on. > => so you should agree that the asymmetry of the current draft is bad, > i.e., the responder cannot be behind the NAT box. The responder can be behind NAT, but in such case the initiator needs to find the external address of the NAT box to start the exchange in first place. Also the NAT must normally be kind of static NAT. > Keepalives cannot be used for this purposes as they are not > => there are many types of keepalives. You should be more accurate, > for instance "UDP keepalives cannot ...". I am talking about the keepalives defined in the UDP encapsulation draft. > authenticated, but any IKE authenticated IKE packet or UDP > => IKE messages are authenticated if they run over the IKE SA > encapsulated ESP packet can be used to detect that the IP address > => s/ESP/IPsec/ The current NAT traversal does NOT support AH, thus only UDP encapsulation of ESP packets is defined. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 18 15:49:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2INnMg16273; Tue, 18 Mar 2003 15:49:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15971 Tue, 18 Mar 2003 18:19:38 -0500 (EST) Message-Id: <200303182322.h2INMAc9027645@marajade.sandelman.ottawa.on.ca> To: sommerfeld@east.sun.com cc: ipsec@lists.tislabs.com Subject: Re: "Me Tarzan, You Jane" in IKEv2-05 In-reply-to: Your message of "Tue, 18 Mar 2003 16:56:38 EST." <200303182156.h2ILucaj023939@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 15:22:09 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: >> I don't see how it matters how the binding is done. It is a local >> matter. Maybe I have /etc/keys. The responder has a list of >> identities that it is authoritative for. Bill> yes, and it's likely to be the case that in peer-to-peer Bill> situations, initiator and responder may swap roles over the long Bill> run -- but the entity which was previously responder wants to Bill> ensure it talks to the same entity which was the initiator, and it Bill> could thus convert a received "me jane" into an outgoing "me Bill> tarzan, you jane" some time afterwards.. Bill, I strongly agree with you - that it is best to be specific about who we wish to talk to, because one can swap ends. But, I'm not sure if you are agreeing with me that the mapping of key names to actual keys is a local matter. === Dan, I've read pieces of -05 (I was intending to read it all tonight). I see that we have an identity payload that is not what I wrote at: http://www.sandelman.ca/ipsec/2002/12/msg00250.html but, is also not what Paul wrote at: http://www.sandelman.ottawa.on.ca/ipsec/2002/11/msg00018.html However, there is, section 1.2, page 7: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> I don't see any way in the ID payload down at section 3.5/page 43 to know which is the IDi and which is the IDr in the third message. Since all of the IKEv1 types are still there, it should be simple to implement Me-Tarzan/You-Jane. Since the CERT payload now has a RAW raw key in it, we are there. Me-Tarzan/You-Jane is there at this point. I thought that the origin of this debate was whether or not to include it, that Charlie hadn't yet, because it was not implemented. We do *not* need the *two-optional-pieces* in the message of last December. ] 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 iQCVAwUBPneqIIqHRg3pndX9AQHErAP/cX6eFsiGXIxgKQMz1RuSMWu1MZloJ2La gLaECOb20wrIcK0IGqP+4FwKQ1pgK2psqgZEgMdSVczbRUaKgFzOmYA4ky+RJqhn bVz2XM5uh/Qd9nMHQpuKVbQ69fTBCI5Khgfx7xo4F6Q3GMsvNweOXwAd7GrPPO1z 98OoVaAQ6Ao= =Rx0w -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 18 18:18:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J2IHg23107; Tue, 18 Mar 2003 18:18:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16429 Tue, 18 Mar 2003 20:36:17 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Use of AES as prf in IKEv2 To: Hugo Krawczyk Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 18 Mar 2003 19:20:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/18/2003 08:39:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Having seen the alternatives, I withdraw my earlier objection to Hugo's proposal for dealing with prf functions with fixed length keys. His recommendation was that if the prf takes a fixed length key, we take the first bits of the initiator's nonce as the first half and the first bits of the responder's nonce as the second half. Not part of his suggestion, but to make the proposal fully specified in all cases, I'd add that if either nonce is shorter than half the fixed length key that it be padded with zero bits. Does anyone object? --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@lists.tislabs.com Tue Mar 18 18:18:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J2IHg23108; Tue, 18 Mar 2003 18:18:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16430 Tue, 18 Mar 2003 20:36:18 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: comments on ikev2 05 (editorial) To: Hugo Krawczyk Cc: IPsec WG , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Tue, 18 Mar 2003 19:29:37 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03092003NP|March 09, 2003) at 03/18/2003 08:39:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is also related to prf functions with fixed length keys. I had proposed that the AUTH payload be computed as: AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) which won't work if the prf has a fixed size key. Hugo proposed the alternative encoding: AuthSecret = prf( prf(Shared Secret, "Key Pad for IKEv2") , ) and using that encoding whether or not the prf takes a fixed size key (presumably with Shared Secret padded or truncated as necessary to match the fixed key size). I'm happy with that. Any objections? --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). > Yes. I now understand. > However, this is too much of HMAC-centric thinking. > In your above proposal you are assuming an arbitrary key-length prf, > which is not the general case as discussed in realtion to the Ni|Nr > issue (to which I answered separately). > > Here, there is a (mathematically) cleaner way to achieve what you want. > Assuming that SharedSecret is suitable as key to a prf, then you can > define AuthSecret = prf(SharedSecret, "Key Pad for IKEv2") > and AUTH = prf(AuthSecret, ). > > Note that in this way you make it clear that it suffices to keep the value > AuthSecret in memory (rather than Shared Secret) for authentication > (thus achieveing the password protection you intended) From owner-ipsec@lists.tislabs.com Tue Mar 18 18:18:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J2IHg23109; Tue, 18 Mar 2003 18:18:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16443 Tue, 18 Mar 2003 20:42:18 -0500 (EST) Message-Id: <200303190144.h2J1iuof055012@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-reply-to: Your message of Wed, 19 Mar 2003 01:00:56 +0200. <15991.42280.592698.747199@ryijy.hel.fi.ssh.com> Date: Wed, 19 Mar 2003 02:44:56 +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: Francis Dupont writes: > The NAT-T protocol does not work with current NAT boxes if you try to > run it over port 500. We must change the port from the 500 to 4500 > immediately when we detect NAT. > => I am not convinced by this "immediately" and this has an impact on > legacy authentication or other stuff which add messages to the IKE_AUTH > "exchange". I think the easiest place to switch to port 4500 is after hte IKE_SA_INIT packets, i.e when sending the first IKE_AUTH packets. => perhaps it is too easy: - it is less secure than at the end of IKE_AUTH - it doesn't work if the responder is behind a NAT - it doesn't work if the responder doesn't implement NAT-T (i.e., if it is not ready to receive packets on UDP 4500) - the detection is made only by the initiator etc. > With implicit peer address update, the NAT detection can be done in IKE_AUTH > and the switch to UDP 4500 performed only after IKE_AUTH. There are going to be implementations, that are not supporting the implicit peer address updates, => I recognize I assume peer address updates are a mandatory part of NAT-T. and for them the state machine goes much easier if they can store the used address and port from the IKE_AUTH packet, than to wait for the next UDP enacpsulated packet after IKE_AUTH. Also note, that if we switch port after IKE_AUTH, then the responder CANNOT initiate any exchanges before the responder either initiates another IKE exchange on new port or sends UDP encapsulated ESP packet. This would cause wierd problems in such cases. It cannot use the port 500, as there is no keepalives for that port, thus the NAT mapping goes away quite quickly. => in my proposal, the node behind the NAT (usually the initiator but this is not necessary) must send a packet as soon as SAs are up. If IKE is trigger by some traffic, this traffic will do the job... In another cases, IMHO the best is to send an IKE keepalive. > There are many advantages to keep same addresses and ports in all > messages of the initial phase. For the responder side it does not matter, it will reply back to the => it does matter if it wants to protect itself against attacks using a spoofed source peer address. same address where the packet came in. Also when the IKE_AUTH is finished it can store the last address and port used, and associate them to the IKE SA so, when it needs remote peer address it can use them directly. => the last statement is exactly the implicit peer address update mechanism viewed by IKE, i.e., for the IKE SA. For the initiator it is also quite easy, simply switch the source and destination port to 4500 when it detects NAT, and use them from that on. => and what happens if the responder is behind the NAT? You assume the mapping is the same of ports 500 and 4500. > => so you should agree that the asymmetry of the current draft is bad, > i.e., the responder cannot be behind the NAT box. The responder can be behind NAT, but in such case the initiator needs to find the external address of the NAT box to start the exchange in first place. Also the NAT must normally be kind of static NAT. => this is less general, i.e., we should find real world cases where it doesn't work. > Keepalives cannot be used for this purposes as they are not > => there are many types of keepalives. You should be more accurate, > for instance "UDP keepalives cannot ...". I am talking about the keepalives defined in the UDP encapsulation draft. => I know but I can't say the same thing for a random reader. > authenticated, but any IKE authenticated IKE packet or UDP > => IKE messages are authenticated if they run over the IKE SA > encapsulated ESP packet can be used to detect that the IP address > => s/ESP/IPsec/ The current NAT traversal does NOT support AH, thus only UDP encapsulation of ESP packets is defined. => and IPCOMP? There is no reason to restrict to ESP here. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 18 19:32:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J3Wig25071; Tue, 18 Mar 2003 19:32:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16771 Tue, 18 Mar 2003 21:55:30 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15991.56494.681125.943593@ryijy.hel.fi.ssh.com> Date: Wed, 19 Mar 2003 04:57:50 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-Reply-To: <200303190144.h2J1iuof055012@givry.rennes.enst-bretagne.fr> References: <15991.42280.592698.747199@ryijy.hel.fi.ssh.com> <200303190144.h2J1iuof055012@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => perhaps it is too easy: > - it is less secure than at the end of IKE_AUTH Can you explain why (except that sending the discovery notifications in clear text packet)? > - it doesn't work if the responder is behind a NAT It should work fine in that case too. There is nothing special whichever end is behind NAT. Initiator will detect if either end is behind NAT and will then switch to new port and if the responder is behind NAT it must either be statically configured NAT (i.e both port 500 and 4500 going to that machine behind NAT), or initiator found out the address of the other end from some directory service and in that case it should also put in bit saying that it is behind NAT, and the initiator should start with port 4500 directly. > - it doesn't work if the responder doesn't implement NAT-T > (i.e., if it is not ready to receive packets on UDP 4500) If it does not support NAT-T then there is nothing we can do if there is NAT between. > - the detection is made only by the initiator No, both ends will know which ends are behind NAT after the IKE_SA_INIT. > => in my proposal, the node behind the NAT (usually the initiator but > this is not necessary) must send a packet as soon as SAs are up. This complicates the state machine more... > => it does matter if it wants to protect itself against attacks using > a spoofed source peer address. It has nothing to do with NAT-T, the responder must reply back to the address where the packet was requested anyway, and it should rate limit replies anyways. > For the initiator it is also quite easy, simply switch the source and > destination port to 4500 when it detects NAT, and use them from that > on. > > => and what happens if the responder is behind the NAT? You assume > the mapping is the same of ports 500 and 4500. If the machine is behind NAT then there either MUST be statically configured NAT, and it needs to map both 500 and 4500 to work or it must be published somewhere and in those cases you can directly say that this is behind NAT, use port 4500 directly. > The responder can be behind NAT, but in such case the initiator needs > to find the external address of the NAT box to start the exchange in > first place. Also the NAT must normally be kind of static NAT. > => this is less general, i.e., we should find real world cases where > it doesn't work. I do not think there are real world cases where the responder is behind NAT, especialy dynamic NATs :-) Static NATs are not a problem as there you just map both 500 and 4500. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 18 20:01:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J41rg25784; Tue, 18 Mar 2003 20:01:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16956 Tue, 18 Mar 2003 22:30:54 -0500 (EST) Date: Wed, 19 Mar 2003 05:34:43 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: Do ipsec vendors care about privacy? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The catchy subject is mainly to grab the attention of ipsec vendors in this list (but it also reflects the contents of this note). The question that I want to resurrect is whether leaving the user's identity open to active disclosure attacks as done now in the "legacy authentication" solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable decision given that protecting against such attacks can be done at a moderate price (see explicit specification below). This decision seems especially dubious given that the roaming/remote user scenario is the only case in which identity protection clearly makes sense, and constitutes a natural requirement for ipsec solutions in the legacy authentication world. I raised this question some time ago (beginning of Feb) and its resolution was mainly based on the fact that protecting the user's identity is a bit more complex than not doing it. I remain unconvinced, however, that the WG (in particular ipsec vendors) made here an informed decision on this trade-off. I got the feeling that no one was really paying attention. (The only people to express opinions on this on the list were: Charlie who was "genuinely conflicted about this one", Derrell Piper and I that supported protecting the user's identity, and Marcus Leech who was against.) So before we close the ikev2 specification please take a look at what it takes to change the legacy authentication protocol in ikev2 to protect the user's identity from active attacks. Here are the two main candidate solutions: (1) Simply defer the sending of the user's identity IDi from message 3 to message 5 (that is, after message 4 in which the responder authenticates itself). The difficuty here is that the responder does not have IDi to base its choice of EAP method in message 4. I do not know how much of a practical problem this is (it was never pointed as such in the case of PIC in the ipsra wg), but others will know better. p (2) Let the responder authenticate itself already in message 2. This can be achieved by moving the AUTH and IDr payloads from message 4 to message 2. If we do not require encrypting these fields then the change is simple. Adding encryption is possible but requires applying SK{} from the middle of message 2 which is more complex. I suggest doing it simple, i.e. without encryptioni (also integrity protection is not needed here). This leaves the identity of R in the plain but this is ONLY for the legacy authentication scenario in which protecting the responder (server/gateway) identity is of little (or no) importance. Either change requires minimal change to the current specification, and none has major implementation complexity. They do not change at all the main protocol, and are relevant only to implementations that support legacy authentication (where user's privacy is a real issue). It seems to me that in this case the "complexity vs security trade-off" is easily resolved in favor of the user's identity protection. What others think? (If this time no one cares then we can easily forget about this issue; at least this will help to document that this was a conscious decision of the WG.) Hugo PS: I'd have liked to raise this in the meeting in San Francisco but I couldn't make it. Hopefully there may still be some discussion on this there, or in the list in the nexy week. Lacking clear support for either way, Charlie decided to go with the simplest solution that is now in 05. This is certainly the right way to go if people do not really care about this privacy issue. In this case, however, I think that this decision needs to be documented in Radia's "rationale" draft (since this issue will be, I bet, something critiques of ikev2 will like to highlight). However, , before doing so I'd like to really sense if this is a thoughtful decision, or something that no one really cares about This note is intended to explicitl;y raise this issue before the closure of ikev2 specification. If people still support the current solution (or just shut up) then we will have a clear documentation that this decision reflects the WG view (if not strong consensus). On the other hand, I can bet that the future papers criticizing IKEv2 (there will be such papers no matter what we do) of the type written about IKEv1) will critically point to this issue. After all, they will say, a protocol that provides identity protection with me IF > > Hugo Krawczyk wrote: > > 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. > > I am genuinely conflicted about this one - like the donkey between the > two bales of hay. I see equally good arguments on both sides, and I This WG has a long tradition of making decisions that become controversial later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc). From owner-ipsec@lists.tislabs.com Tue Mar 18 20:06:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J46lg25906; Tue, 18 Mar 2003 20:06:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16999 Tue, 18 Mar 2003 22:40:59 -0500 (EST) Date: Wed, 19 Mar 2003 05:44:04 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG Subject: Re: comments on ikev2 05 (editorial) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk just to point to a small (but possibly confusing) typo: On Tue, 18 Mar 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > This is also related to prf functions with fixed length keys. I had > proposed that the AUTH payload be computed as: > > AUTH = prf(Shared Secret | "Key Pad for IKEv2", ) > > which won't work if the prf has a fixed size key. Hugo proposed the > alternative encoding: > > AuthSecret = prf( prf(Shared Secret, "Key Pad for IKEv2") , ) ^^^^^^^^^^ this should be AUTH Also, Charlie, I suggest that you explain in the text that an implementation only needs to use (or keep in memory) the value prf(Shared Secret, "Key Pad for IKEv2"), thus avoiding the need to store the user's password atthe server/gateway. Hugo > and using that encoding whether or not the prf takes a fixed size key > (presumably with Shared Secret padded or truncated as necessary to match > the fixed key size). > > I'm happy with that. Any objections? > > --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). > > > Yes. I now understand. > > However, this is too much of HMAC-centric thinking. > > In your above proposal you are assuming an arbitrary key-length prf, > > which is not the general case as discussed in realtion to the Ni|Nr > > issue (to which I answered separately). > > > > Here, there is a (mathematically) cleaner way to achieve what you want. > > Assuming that SharedSecret is suitable as key to a prf, then you can > > define AuthSecret = prf(SharedSecret, "Key Pad for IKEv2") > > and AUTH = prf(AuthSecret, ). > > > > Note that in this way you make it clear that it suffices to keep the > value > > AuthSecret in memory (rather than Shared Secret) for authentication > > (thus achieveing the password protection you intended) > > > > From owner-ipsec@lists.tislabs.com Tue Mar 18 20:55:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J4t1g27526; Tue, 18 Mar 2003 20:55:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17209 Tue, 18 Mar 2003 23:20:26 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message Subject: RE: Do ipsec vendors care about privacy? Date: Tue, 18 Mar 2003 20:24:05 -0800 Message-ID: Thread-Topic: Do ipsec vendors care about privacy? Thread-Index: AcLtyj/9EYx9ent7QzSUzerBFEIhoAAASEKA From: "William Dixon" To: "Hugo Krawczyk" , "IPsec WG" X-OriginalArrivalTime: 19 Mar 2003 04:24:02.0039 (UTC) FILETIME=[5E915070:01C2EDCF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, as an IPsec vendor (but not necessarily an implementer of IKEv2) our customer input is that they are very concerned about exposing identity to passive or active attack. Thus we envision IPsec enabled host responders that are: A. public servers that can provide their credential first to an incoming client (typical server auth) B. private servers or your laptop that must not provide it's credential first until the incoming client authenticates. I regret I haven't reviewed the current IKEv2 draft with these two cases in mind, or kept up with the discussion to see if these two scenarios are adequately enabled, with or without legacy auth. Thus I can't offer comment about your proposed solution. I just haven't been able to get the time to review this stuff in detail, and likewise, I'm not in SF. Nevertheless, I offer a strong yes "we care" for what it's worth. We see the above two scenarios as required for deployment of IPsec to secure application connections host-to-host. -----Original Message----- From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] Sent: Tuesday, March 18, 2003 7:35 PM To: IPsec WG Subject: Do ipsec vendors care about privacy? The catchy subject is mainly to grab the attention of ipsec vendors in this list (but it also reflects the contents of this note). The question that I want to resurrect is whether leaving the user's identity open to active disclosure attacks as done now in the "legacy authentication" solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable decision given that protecting against such attacks can be done at a moderate price (see explicit specification below). This decision seems especially dubious given that the roaming/remote user scenario is the only case in which identity protection clearly makes sense, and constitutes a natural requirement for ipsec solutions in the legacy authentication world. I raised this question some time ago (beginning of Feb) and its resolution was mainly based on the fact that protecting the user's identity is a bit more complex than not doing it. I remain unconvinced, however, that the WG (in particular ipsec vendors) made here an informed decision on this trade-off. I got the feeling that no one was really paying attention. (The only people to express opinions on this on the list were: Charlie who was "genuinely conflicted about this one", Derrell Piper and I that supported protecting the user's identity, and Marcus Leech who was against.) So before we close the ikev2 specification please take a look at what it takes to change the legacy authentication protocol in ikev2 to protect the user's identity from active attacks. Here are the two main candidate solutions: (1) Simply defer the sending of the user's identity IDi from message 3 to message 5 (that is, after message 4 in which the responder authenticates itself). The difficuty here is that the responder does not have IDi to base its choice of EAP method in message 4. I do not know how much of a practical problem this is (it was never pointed as such in the case of PIC in the ipsra wg), but others will know better. p (2) Let the responder authenticate itself already in message 2. This can be achieved by moving the AUTH and IDr payloads from message 4 to message 2. If we do not require encrypting these fields then the change is simple. Adding encryption is possible but requires applying SK{} from the middle of message 2 which is more complex. I suggest doing it simple, i.e. without encryptioni (also integrity protection is not needed here). This leaves the identity of R in the plain but this is ONLY for the legacy authentication scenario in which protecting the responder (server/gateway) identity is of little (or no) importance. Either change requires minimal change to the current specification, and none has major implementation complexity. They do not change at all the main protocol, and are relevant only to implementations that support legacy authentication (where user's privacy is a real issue). It seems to me that in this case the "complexity vs security trade-off" is easily resolved in favor of the user's identity protection. What others think? (If this time no one cares then we can easily forget about this issue; at least this will help to document that this was a conscious decision of the WG.) Hugo PS: I'd have liked to raise this in the meeting in San Francisco but I couldn't make it. Hopefully there may still be some discussion on this there, or in the list in the nexy week. Lacking clear support for either way, Charlie decided to go with the simplest solution that is now in 05. This is certainly the right way to go if people do not really care about this privacy issue. In this case, however, I think that this decision needs to be documented in Radia's "rationale" draft (since this issue will be, I bet, something critiques of ikev2 will like to highlight). However, , before doing so I'd like to really sense if this is a thoughtful decision, or something that no one really cares about This note is intended to explicitl;y raise this issue before the closure of ikev2 specification. If people still support the current solution (or just shut up) then we will have a clear documentation that this decision reflects the WG view (if not strong consensus). On the other hand, I can bet that the future papers criticizing IKEv2 (there will be such papers no matter what we do) of the type written about IKEv1) will critically point to this issue. After all, they will say, a protocol that provides identity protection with me IF > > Hugo Krawczyk wrote: > > 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. > > I am genuinely conflicted about this one - like the donkey between the > two bales of hay. I see equally good arguments on both sides, and I This WG has a long tradition of making decisions that become controversial later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc). From owner-ipsec@lists.tislabs.com Tue Mar 18 21:18:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J5ILg28132; Tue, 18 Mar 2003 21:18:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17325 Tue, 18 Mar 2003 23:47:52 -0500 (EST) Message-ID: <3E77FA94.1060006@roc.co.in> Date: Wed, 19 Mar 2003 10:35:24 +0530 From: ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir CC: ipsec@lists.tislabs.com Subject: Re: IKEv2: prepending four octets References: <004001c2ed45$4536a290$292e1dc2@YnirNew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > You prepend four zeros to IKE messages, because no >IPsec-encapsulated-in-UDP message begins with four zeros. An encapsulated >IPSec packet begins with the SPI which is always non-zero. Adding four >zeros to the beginning of an IKE message makes it possible to distinguish >IKE messages from encapsulated IPSec packets. > > IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of NAT Traversal. If we make this packet also containing first four bytes after UDP header as 0s in case of IKE packet, then there is no need for port 4500 --Ravi >Hope this helps > >Yoav > >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ravi >Sent: Tuesday, March 18, 2003 10:11 AM >To: ipsec@lists.tislabs.com >Subject: IKEv2: prepending four octets > > >Dear All, >I am going through the ikev2-0.5 draft.It says >In the IKE header when sent on UDP port 4500 ,IKE messages have >prepended four octets of Zero. > >My doubt is what made to prepend four octets of Zeroes before the IKE >message. >Thanks in advance, >Ravi Kumar CH. > > > > > From owner-ipsec@lists.tislabs.com Tue Mar 18 22:02:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J62Ig00629; Tue, 18 Mar 2003 22:02:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17555 Wed, 19 Mar 2003 00:32:26 -0500 (EST) Message-Id: <200303190535.h2J5Z4of055811@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-reply-to: Your message of Wed, 19 Mar 2003 04:57:50 +0200. <15991.56494.681125.943593@ryijy.hel.fi.ssh.com> Date: Wed, 19 Mar 2003 06:35:04 +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: Francis Dupont writes: > => perhaps it is too easy: > - it is less secure than at the end of IKE_AUTH Can you explain why (except that sending the discovery notifications in clear text packet)? => this is a reason but there are others, for instance the NAT detection is in fact done on only one message, the reply of IKE_SA_INIT: you can't perform a three way handshake or with other words a return routability check. > - it doesn't work if the responder is behind a NAT It should work fine in that case too. There is nothing special whichever end is behind NAT. Initiator will detect if either end is behind NAT and will then switch to new port and if the responder is behind NAT it must either be statically configured NAT (i.e both port 500 and 4500 going to that machine behind NAT), or initiator found out the address of the other end from some directory service and in that case it should also put in bit saying that it is behind NAT, and the initiator should start with port 4500 directly. => so you loose all the other cases (with peer-to-peer, we can see some support for the case where both ends are behind NATs for instance) and more you assume a MUST for NAT traversal support (for the start with port 4500). You should make this last point clearer. > - it doesn't work if the responder doesn't implement NAT-T > (i.e., if it is not ready to receive packets on UDP 4500) If it does not support NAT-T then there is nothing we can do if there is NAT between. => I disagree: either we give a way to manage the failure, or we enforce NAT-T support (i.e., put a MUST for its support). > - the detection is made only by the initiator No, both ends will know which ends are behind NAT after the IKE_SA_INIT. => both will know but only the initiator does something with this knowledge. IMHO this is an unecessary asymmetry. > => in my proposal, the node behind the NAT (usually the initiator but > this is not necessary) must send a packet as soon as SAs are up. This complicates the state machine more... => this is a matter of taste. > => it does matter if it wants to protect itself against attacks using > a spoofed source peer address. It has nothing to do with NAT-T, the responder must reply back to the address where the packet was requested anyway, and it should rate limit replies anyways. => I disagree: defense against DoS is far easier when DoS packets can be distinguished from valid packets. > The responder can be behind NAT, but in such case the initiator needs > to find the external address of the NAT box to start the exchange in > first place. Also the NAT must normally be kind of static NAT. > => this is less general, i.e., we should find real world cases where > it doesn't work. I do not think there are real world cases where the responder is behind NAT, especialy dynamic NATs :-) => I can imagine as many as you are ready to read (:-), for instance one can use some kind of callback mechanism in order to enforce the side of the initiator (firewalls are good reasons to do that). To summarize, I can't see why we refuse the opportunity to support any position for the NAT. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 18 22:47:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2J6llg02543; Tue, 18 Mar 2003 22:47:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA17781 Wed, 19 Mar 2003 01:19:54 -0500 (EST) Message-ID: <3E781036.3020603@roc.co.in> Date: Wed, 19 Mar 2003 12:07:42 +0530 From: ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Jayant Shukla , radia.perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Another NAT Traversal question References: <200302260015.h1Q0FDof060239@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of NAT Traversal. If we make this packet also containing first four bytes after UDP header as 0s in case of IKE packet, then there is no need for port 4500 Regards, Ravi Francis Dupont wrote: > In your previous mail you wrote: > > The checksum is being fixed according to the new IP addresses in the IP > header and therefore you don't need the original IP address. > >=> so you give up the transport checksum ? > > >From what I recall, the authors had given up on the transport mode and > one of them had stated on this list that only 'tunnel mode' will be > pushed for v2. > >=> I am afraid that there is no consensus to drop the transport mode, >so as the NAT traversal is in the charter, there is a problem to >really solve. > >Regards > >Francis.Dupont@enst-bretagne.fr > > > From owner-ipsec@lists.tislabs.com Wed Mar 19 02:42:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JAghg05016; Wed, 19 Mar 2003 02:42:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18304 Wed, 19 Mar 2003 05:12:00 -0500 (EST) Subject: Re: IKEv2: prepending four octets From: Vinay K Nallamothu To: ipsec@lists.tislabs.com In-Reply-To: <3E77FA94.1060006@roc.co.in> References: <004001c2ed45$4536a290$292e1dc2@YnirNew> <3E77FA94.1060006@roc.co.in> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Mar 2003 15:51:45 +0530 Message-Id: <1048069335.9648.262.camel@vinay.royalchallenge.com> Mime-Version: 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 2003-03-19 at 10:35, ravi wrote: > IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of > NAT Traversal. If we make this packet also containing first four bytes after > UDP header as 0s in case of IKE packet, then there is no need for port 4500 This is to avoid any IKE aware NAPT devices present in between playing smart. These devices make use of the SPI field to uniquely identify the source behind the NAPT. For more details please go through sections 9.1 to 9.3 of draft-ietf-ipsec-ikev2-tutorial-01.txt. Hope this helps vinay > > --Ravi > > >Hope this helps > > > >Yoav > > > >-----Original Message----- > >From: owner-ipsec@lists.tislabs.com > >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ravi > >Sent: Tuesday, March 18, 2003 10:11 AM > >To: ipsec@lists.tislabs.com > >Subject: IKEv2: prepending four octets > > > > > >Dear All, > >I am going through the ikev2-0.5 draft.It says > >In the IKE header when sent on UDP port 4500 ,IKE messages have > >prepended four octets of Zero. > > > >My doubt is what made to prepend four octets of Zeroes before the IKE > >message. > >Thanks in advance, > >Ravi Kumar CH. > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Wed Mar 19 04:03:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JC3eg10793; Wed, 19 Mar 2003 04:03:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18611 Wed, 19 Mar 2003 06:34:35 -0500 (EST) Message-ID: <3E785738.5000609@cefriel.it> Date: Wed, 19 Mar 2003 12:40:40 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: IPsec WG Subject: Re: Do ipsec vendors care about privacy? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 11:40:21.0898 (UTC) FILETIME=[52FAC6A0:01C2EE0C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [SNIP] I think that vendors *care* about privacy... Or at least they should. :-). The solutions you proposed solves the problem of protecting the iniziator ID from attive attck, however they let the responder ID opend to passive attack. > (1) Simply defer the sending of the user's identity IDi from message > 3 to message 5 (that is, after message 4 in which the responder authenticates > itself). The difficuty here is that the responder does not have IDi to base > its choice of EAP method in message 4. I do not know how much of a practical > problem this is (it was never pointed as such in the case of PIC in the ipsra > wg), but others will know better. I think that this is the simplest solution of the two. Initiator, when it is going to use "legacy autentication", does not have to send IDi to the responder. This is not a difficulty for the responder (I think). When Bob doesn't receive IDi and AUTH payload in message 3 will understand that Alice is going to use a legacy authentication method, and he send an EAP(Request, Identity) in message 4. Alice can send her IDi in EAP(Response, Identity) in message 5. This change in IKEv2 will make handshake 1RTT longer, however I think this isn't a great problem when we are interactin with a human. Initiator(Alice) Responder(Bob) ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {[CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP(Request, Identity)} HDR, SK {EAP(Reply, IDi)} --> <-- HDR, SK{EAP} HDR, SK {EAP, [AUTH] } --> <-- HDR, SK {EAP, [AUTH], SAr2, TSi, TSr } Of course this proposal let IDr opened to polling attack. But which identity we have to protect? In a message from Radia Perlman: "...However, when writing IKEv2, we decided that there was more of a problem with a "polling attack", where someone could find out who was listening at a particular IP address just by initiating a connection to it. The WG, when faced with the two styles, seemed to have consensus around avoiding the polling attack. The reasoning was that IKE is a peer-to-peer protocol where either side can initiate, and the polling attack is way easier (just initiate a connection to an IP address) than impersonating the responder's IP address and seeing who connects..." So again: "How important is identity protection? and which ID we *MUST* protect?" > (2) Let the responder authenticate itself already in message 2. This can > be achieved by moving the AUTH and IDr payloads from message 4 to message 2. > If we do not require encrypting these fields then the change is simple. > Adding encryption is possible but requires applying SK{} from the middle of > message 2 which is more complex. I suggest doing it simple, i.e. without > encryptioni (also integrity protection is not needed here). This leaves > the identity of R in the plain but this is ONLY for > the legacy authentication scenario in which protecting the responder > (server/gateway) identity is of little (or no) importance. This solution allow us to save the extra RTT, however it implies that Bob knows when the Alice is going to use EAP. (Your proposal is to change IKev2 *only* when using "legacy authentication", right?) [SNIP] > Hugo Am I missing something? [SNIP] -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Wed Mar 19 04:59:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JCxTg15313; Wed, 19 Mar 2003 04:59:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18820 Wed, 19 Mar 2003 07:31:02 -0500 (EST) From: "Yoav Nir" To: "'Antonio Forzieri'" , "'IPsec WG'" Subject: RE: Do ipsec vendors care about privacy? Date: Wed, 19 Mar 2003 14:34:45 +0200 Message-ID: <004801c2ee13$ecd6e1d0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E785738.5000609@cefriel.it> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's way too many RTTs. I think an extra RTT is a greater problem when interacting with a human, because humans are more impatient than machines. It has been generally accepted here that since we already know the Initiator's ID at message 4, we can skip the EAP Identity and go directly to the EAP challenge. Even with Hugo's proposed change, we can send the challenge in message 4, receive in message 5 both the IDi and the EAP response, and verify them then. That way we still have only 3 roundtrips altogether. Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Antonio Forzieri Sent: Wednesday, March 19, 2003 1:41 PM To: IPsec WG Subject: Re: Do ipsec vendors care about privacy? [SNIP] I think that vendors *care* about privacy... Or at least they should. :-). The solutions you proposed solves the problem of protecting the iniziator ID from attive attck, however they let the responder ID opend to passive attack. > (1) Simply defer the sending of the user's identity IDi from message > 3 to message 5 (that is, after message 4 in which the responder authenticates > itself). The difficuty here is that the responder does not have IDi to base > its choice of EAP method in message 4. I do not know how much of a practical > problem this is (it was never pointed as such in the case of PIC in the ipsra > wg), but others will know better. I think that this is the simplest solution of the two. Initiator, when it is going to use "legacy autentication", does not have to send IDi to the responder. This is not a difficulty for the responder (I think). When Bob doesn't receive IDi and AUTH payload in message 3 will understand that Alice is going to use a legacy authentication method, and he send an EAP(Request, Identity) in message 4. Alice can send her IDi in EAP(Response, Identity) in message 5. This change in IKEv2 will make handshake 1RTT longer, however I think this isn't a great problem when we are interactin with a human. Initiator(Alice) Responder(Bob) ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {[CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP(Request, Identity)} HDR, SK {EAP(Reply, IDi)} --> <-- HDR, SK{EAP} HDR, SK {EAP, [AUTH] } --> <-- HDR, SK {EAP, [AUTH], SAr2, TSi, TSr } [snip] From owner-ipsec@lists.tislabs.com Wed Mar 19 06:19:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JEJvg22220; Wed, 19 Mar 2003 06:19:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19012 Wed, 19 Mar 2003 08:49:34 -0500 (EST) Message-ID: <3E7876BC.5040805@cefriel.it> Date: Wed, 19 Mar 2003 14:55:08 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: "'IPsec WG'" Subject: Re: Do ipsec vendors care about privacy? References: <004801c2ee13$ecd6e1d0$292e1dc2@YnirNew> In-Reply-To: <004801c2ee13$ecd6e1d0$292e1dc2@YnirNew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 13:54:49.0078 (UTC) FILETIME=[1B64C160:01C2EE1F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: > That's way too many RTTs. I think an extra RTT is a greater problem when > interacting with a human, because humans are more impatient than machines. I disagree with you. However if we can do it with less RTT, let's do with less RTT! :-) If I've not misunderstood, Hugo's proposal should work like this (right?): Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {[CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {IDi, EAP, [AUTH]} --> <-- HDR, SK {EAP, [AUTH], SAr2, TSi, TSr } This sounds fine for me. In such a scenario (legacy authentication) we open IDr to passive attack, however I think that here we have to protect Initiator Identity rather than IDr... In the previous message I wrote something incorrect. When we are using EAP we open IKEv2 to passive attack on IDr, but this doesn't happen because of Hugo's proposals. Even in IKEv2-05 we have the same problem. If Eve uses a spoofed IDi and doesn't put AUTH payload in message 3 (she wants to use legacy authentication,) she can mount a polling attack. (because only in message 4 that she proves her Identity) [SNIP] > Yoav -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Wed Mar 19 06:29:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JETRg23310; Wed, 19 Mar 2003 06:29:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19063 Wed, 19 Mar 2003 09:00:53 -0500 (EST) From: "Jesse Alpert" To: "'Hugo Krawczyk'" , "'IPsec WG'" Subject: RE: Do ipsec vendors care about privacy? Date: Wed, 19 Mar 2003 16:07:18 +0200 Message-ID: <001201c2ee20$da536da0$7b2e1dc2@jesse> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, My vote is yes - we care. Our current implementation of legacy authentication which is based on hybrid-mode (draft-ietf-ipsec-isakmp-hybrid-auth (now expired)) + XAUTH protects the user's identity against active attacks. It would be a pity to lose this feature in IKEv2. It can be argued that since the regular (non-legacy) IKEv2 initial exchange does not protect the initiator's ID from active attacks, and since this is the recommended (?) mode of authentication, we should not go to the effort of protecting the legacy authentication exchange. But it seems that the identity of a user that is using legacy authentication (e.g. user name and password) may be easier to exploit than the identity of a user using a public signature. Jesse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk Sent: Wednesday, March 19, 2003 5:35 AM To: IPsec WG Subject: Do ipsec vendors care about privacy? The catchy subject is mainly to grab the attention of ipsec vendors in this list (but it also reflects the contents of this note). The question that I want to resurrect is whether leaving the user's identity open to active disclosure attacks as done now in the "legacy authentication" solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable decision given that protecting against such attacks can be done at a moderate price (see explicit specification below). This decision seems especially dubious given that the roaming/remote user scenario is the only case in which identity protection clearly makes sense, and constitutes a natural requirement for ipsec solutions in the legacy authentication world. I raised this question some time ago (beginning of Feb) and its resolution was mainly based on the fact that protecting the user's identity is a bit more complex than not doing it. I remain unconvinced, however, that the WG (in particular ipsec vendors) made here an informed decision on this trade-off. I got the feeling that no one was really paying attention. (The only people to express opinions on this on the list were: Charlie who was "genuinely conflicted about this one", Derrell Piper and I that supported protecting the user's identity, and Marcus Leech who was against.) So before we close the ikev2 specification please take a look at what it takes to change the legacy authentication protocol in ikev2 to protect the user's identity from active attacks. Here are the two main candidate solutions: (1) Simply defer the sending of the user's identity IDi from message 3 to message 5 (that is, after message 4 in which the responder authenticates itself). The difficuty here is that the responder does not have IDi to base its choice of EAP method in message 4. I do not know how much of a practical problem this is (it was never pointed as such in the case of PIC in the ipsra wg), but others will know better. p (2) Let the responder authenticate itself already in message 2. This can be achieved by moving the AUTH and IDr payloads from message 4 to message 2. If we do not require encrypting these fields then the change is simple. Adding encryption is possible but requires applying SK{} from the middle of message 2 which is more complex. I suggest doing it simple, i.e. without encryptioni (also integrity protection is not needed here). This leaves the identity of R in the plain but this is ONLY for the legacy authentication scenario in which protecting the responder (server/gateway) identity is of little (or no) importance. Either change requires minimal change to the current specification, and none has major implementation complexity. They do not change at all the main protocol, and are relevant only to implementations that support legacy authentication (where user's privacy is a real issue). It seems to me that in this case the "complexity vs security trade-off" is easily resolved in favor of the user's identity protection. What others think? (If this time no one cares then we can easily forget about this issue; at least this will help to document that this was a conscious decision of the WG.) Hugo PS: I'd have liked to raise this in the meeting in San Francisco but I couldn't make it. Hopefully there may still be some discussion on this there, or in the list in the nexy week. Lacking clear support for either way, Charlie decided to go with the simplest solution that is now in 05. This is certainly the right way to go if people do not really care about this privacy issue. In this case, however, I think that this decision needs to be documented in Radia's "rationale" draft (since this issue will be, I bet, something critiques of ikev2 will like to highlight). However, , before doing so I'd like to really sense if this is a thoughtful decision, or something that no one really cares about This note is intended to explicitl;y raise this issue before the closure of ikev2 specification. If people still support the current solution (or just shut up) then we will have a clear documentation that this decision reflects the WG view (if not strong consensus). On the other hand, I can bet that the future papers criticizing IKEv2 (there will be such papers no matter what we do) of the type written about IKEv1) will critically point to this issue. After all, they will say, a protocol that provides identity protection with me IF > > Hugo Krawczyk wrote: > > 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. > > I am genuinely conflicted about this one - like the donkey between the > two bales of hay. I see equally good arguments on both sides, and I This WG has a long tradition of making decisions that become controversial later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc). From owner-ipsec@lists.tislabs.com Wed Mar 19 07:02:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JF22g24685; Wed, 19 Mar 2003 07:02:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19283 Wed, 19 Mar 2003 09:36:28 -0500 (EST) Message-ID: <3E7881C1.1050507@cefriel.it> Date: Wed, 19 Mar 2003 15:42:09 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: "'IPsec WG'" Subject: Secure remote access with IPsec Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 14:41:49.0519 (UTC) FILETIME=[AC81E5F0:01C2EE25] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I send this mail to the WG followig Paul Hoffman advice. I'm an Italian student and I'm doing my degree thesis about "Secure remote access using IPsec". I've been studing the problem since August 2002 and I think that the current IKEv2 draft (05) solves almost all the problems around this technology even if changes to the signature model proposed by Hugo Krawczyk should (MUST :-) ) be adopted (Yes, I read SIGMA paper). Because this is a research work (thesis) It would have no sense for me implementing IKEv2. Are there any other problems, directions or open issues about this technology, that MUST be studied? Is there something (simulations, measures, implementations) that can help in making this technology more powerful and that *could be useful to IETF*? P.S: These are the problems that I studied in these months: - Endpoint Authentication is solved by EAP even if there is "The compound authentication binding problem" using legacy authentication mechanism like CHAP, OTP, SecurID... However I think that in the future we will authenticate ourselves with a smart card, or something similar - What about Kerberos in EAP? - Why can't we make a binding AUTH with CHAP, OTP? AUTH = prf(Password | "Key Pad for IKEv2", )); with OTP we can think of doing something like this: AUTH = prf(Next_One_Time Password | "Key Pad for IKEv2", )); - Configuration problem is solved by the use of the Configuration Payload (CP), I think this is the easiest way of doing this, even if in the WG peoples long debated DHCP Vs CP; - NAT-T capability are enabled in IKEv2, and I think it works well (what about let IKE speaks on UDP 4500 directly even when there isn't NAT-T function enabled? What's wrog with that?). I know the pseudo-NAT problem, however I think that an attacker on the path could easily delete all the message. - IPsec is well integrated with MIPv6 [draft-ietf-mobileip-mipv6-ha-ipsec-03.txt], so we can think of a mobile node connecting back to his Corporate Network, without need rekeying when it changes his address (can we change the selectors of a SA or an entry of the SPD upon the receiving of a BU message?) -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Wed Mar 19 09:31:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JHV8g29663; Wed, 19 Mar 2003 09:31:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19628 Wed, 19 Mar 2003 11:53:47 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15992.41222.836986.56140@ryijy.hel.fi.ssh.com> Date: Wed, 19 Mar 2003 18:55:34 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-Reply-To: <200303190535.h2J5Z4of055811@givry.rennes.enst-bretagne.fr> References: <15991.56494.681125.943593@ryijy.hel.fi.ssh.com> <200303190535.h2J5Z4of055811@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > I do not think there are real world cases where the responder is > behind NAT, especialy dynamic NATs :-) > > => I can imagine as many as you are ready to read (:-), for instance I can imagine lots of things, but that does not make it real world case. > one can use some kind of callback mechanism in order to enforce the > side of the initiator (firewalls are good reasons to do that). Where is that used in real world NOW? > To summarize, I can't see why we refuse the opportunity to support > any position for the NAT. I do think NAT can be in any position with current draft already, so there is no need to make the protocol more complicated because of some imagined cases. For example the callback mechanism would propably want to do the initial authentication before calling back, thus in the current protocol the original responder will already know the mapping for the port 4500, and there are NAT keepalives already going for that port, so it can directly connect to that port and use that as callback address. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Mar 19 10:13:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JID6g02801; Wed, 19 Mar 2003 10:13:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19751 Wed, 19 Mar 2003 12:43:15 -0500 (EST) Reply-To: From: "Darren Dukes" To: Subject: CP and DHCP/RADIUS slides Date: Wed, 19 Mar 2003 12:46:34 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Full slides and draft (pdf and pps) http://www.vpnc.org/temp-draft-lebovitz-ipsec-scalable-ikev2cp-00.txt http://www.employees.org/~ddukes From owner-ipsec@lists.tislabs.com Wed Mar 19 10:30:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JIUkg04435; Wed, 19 Mar 2003 10:30:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19800 Wed, 19 Mar 2003 12:56:21 -0500 (EST) Message-Id: <5.2.0.9.2.20030319125702.031515a8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 19 Mar 2003 12:59:46 -0500 To: Hugo Krawczyk , IPsec WG From: Russ Housley Subject: Re: Do ipsec vendors care about privacy? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, in my view it is too late to be raising a question that will cause major surgery on the document. It is time to fix things that are broken, make the document internally consistent, and publish it. I do not think it is time to raise new requirements. Russ Your local, friendly, incoming Security Area Director At 05:34 AM 3/19/2003 +0200, Hugo Krawczyk wrote: >The catchy subject is mainly to grab the attention of ipsec vendors in this >list (but it also reflects the contents of this note). > >The question that I want to resurrect is whether leaving the user's identity >open to active disclosure attacks as done now in the "legacy authentication" >solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable >decision given that protecting against such attacks can be done at a moderate >price (see explicit specification below). This decision seems especially >dubious given that the roaming/remote user scenario is the only case in which >identity protection clearly makes sense, and constitutes a natural requirement >for ipsec solutions in the legacy authentication world. > >I raised this question some time ago (beginning of Feb) and its resolution >was mainly based on the fact that protecting the user's identity is a bit >more complex than not doing it. I remain unconvinced, however, that the WG >(in particular ipsec vendors) made here an informed decision on this >trade-off. >I got the feeling that no one was really paying attention. (The only >people to express opinions on this on the list were: Charlie who was >"genuinely conflicted about this one", Derrell Piper and I that supported >protecting the user's identity, and Marcus Leech who was against.) > >So before we close the ikev2 specification please take a look at what it takes >to change the legacy authentication protocol in ikev2 to protect the user's >identity from active attacks. Here are the two main candidate solutions: > >(1) Simply defer the sending of the user's identity IDi from message >3 to message 5 (that is, after message 4 in which the responder authenticates >itself). The difficuty here is that the responder does not have IDi to base >its choice of EAP method in message 4. I do not know how much of a practical >problem this is (it was never pointed as such in the case of PIC in the ipsra >wg), but others will know better. > >p >(2) Let the responder authenticate itself already in message 2. This can >be achieved by moving the AUTH and IDr payloads from message 4 to message 2. >If we do not require encrypting these fields then the change is simple. >Adding encryption is possible but requires applying SK{} from the middle of >message 2 which is more complex. I suggest doing it simple, i.e. without >encryptioni (also integrity protection is not needed here). This leaves >the identity of R in the plain but this is ONLY for >the legacy authentication scenario in which protecting the responder >(server/gateway) identity is of little (or no) importance. > >Either change requires minimal change to the current specification, >and none has major implementation complexity. They do not change at all the >main protocol, and are relevant only to implementations that support legacy >authentication (where user's privacy is a real issue). >It seems to me that in this case the "complexity vs security trade-off" >is easily resolved in favor of the user's identity protection. > >What others think? >(If this time no one cares then we can easily forget about this issue; at >least this will help to document that this was a conscious decision of the >WG.) > >Hugo > >PS: I'd have liked to raise this in the meeting in San Francisco but I >couldn't make it. Hopefully there may still be some discussion on this there, >or in the list in the nexy week. > > >Lacking clear support for either way, Charlie >decided to go with the simplest solution that is now in 05. This is >certainly the right way to go if people do not really care about this >privacy issue. In this case, however, I think that this decision needs >to be documented in Radia's "rationale" draft (since this issue will be, I >bet, something critiques of ikev2 will like to highlight). >However, , before doing so I'd like to really sense if this is a thoughtful >decision, or something that no one really cares about >This note is intended to explicitl;y raise this issue before the closure >of ikev2 specification. If people still support the current solution (or >just shut up) then we will have a clear documentation that this decision >reflects the WG view (if not strong consensus). > > >On the other hand, I can bet >that the future >papers criticizing IKEv2 (there will be such papers no matter what we do) > >of the >type written about IKEv1) will critically point >to this issue. After all, they will say, a protocol that provides identity >protection with me IF > > > > > Hugo Krawczyk wrote: > > > 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. > > > > I am genuinely conflicted about this one - like the donkey between the > > two bales of hay. I see equally good arguments on both sides, and I > > >This WG has a long tradition of making decisions that become controversial >later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc). From owner-ipsec@lists.tislabs.com Wed Mar 19 12:12:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JKC6g10974; Wed, 19 Mar 2003 12:12:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20201 Wed, 19 Mar 2003 14:38:48 -0500 (EST) From: "Yoav Nir" To: "'ravi'" Cc: Subject: RE: IKEv2: prepending four octets Date: Wed, 19 Mar 2003 10:10:03 +0200 Message-ID: <002f01c2edee$f26b8fd0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E77FA94.1060006@roc.co.in> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IKEv1 RFC mandated that IKE communications be from port 500 to port 500. It states that replies to an IKE packet go to port 500, not the source port. Implementations that follow the RFC cannot work when a NAT changes the ports. To overcome this problem, many NAT implementations added special handling to port 500: they would change only the IP address and choose peers based on IKE cookies. These schemes worked fairly well, but not always, and they definitely don't allow normal NAT traversal through UDP encapsulation (no IKE cookies) Since these "smart" NAT devices are all over the place, we need to use a new port that doesn't have this special handling. -----Original Message----- From: ravi [mailto:ravivsn@roc.co.in] Sent: Wednesday, March 19, 2003 7:05 AM To: Yoav Nir Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2: prepending four octets Hi, > You prepend four zeros to IKE messages, because no >IPsec-encapsulated-in-UDP message begins with four zeros. An encapsulated >IPSec packet begins with the SPI which is always non-zero. Adding four >zeros to the beginning of an IKE message makes it possible to distinguish >IKE messages from encapsulated IPSec packets. > > IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of NAT Traversal. If we make this packet also containing first four bytes after UDP header as 0s in case of IKE packet, then there is no need for port 4500 --Ravi >Hope this helps > >Yoav > >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ravi >Sent: Tuesday, March 18, 2003 10:11 AM >To: ipsec@lists.tislabs.com >Subject: IKEv2: prepending four octets > > >Dear All, >I am going through the ikev2-0.5 draft.It says >In the IKE header when sent on UDP port 4500 ,IKE messages have >prepended four octets of Zero. > >My doubt is what made to prepend four octets of Zeroes before the IKE >message. >Thanks in advance, >Ravi Kumar CH. > > > > > From owner-ipsec@lists.tislabs.com Wed Mar 19 14:30:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JMUQg17497; Wed, 19 Mar 2003 14:30:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20514 Wed, 19 Mar 2003 16:54:13 -0500 (EST) Date: Wed, 19 Mar 2003 23:57:19 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: IPsec WG Subject: Re: Do ipsec vendors care about privacy? In-Reply-To: <5.2.0.9.2.20030319125702.031515a8@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 Wed, 19 Mar 2003, Russ Housley wrote: > Hugo, in my view it is too late to be raising a question that will cause > major surgery on the document. It is time to fix things that are broken, > make the document internally consistent, and publish it. I do not think it > is time to raise new requirements. > > Russ > Your local, friendly, incoming Security Area Director > Hi Russ, first congratulations for the new poisition. Good luck. This response really sounds as coming from the area director :) ANyway, I'd agree with you that this is too late if the change I proposed required "major surgery on the document". But it doesn't. Any of the proposed solutions takes a 1 minute editorial work, just moving one or two fields from one message to the other in section 2.16 (and has no influence on other partts of the document). The question is not specification complexity which is null for this changes. ALso, it is not a performance issue. None of the proposed changes add round trips or computation (a message to the list from Antonio Forzieri might have given that impression but his modification of my proposal was unnecessary as he later stated himself). The only question is operational: can the responder (server) send the first EAP message before getting IDi? If this is the case (as it was in PIC and seems tobe agreed in some responses to my message) then we are done at no cost at all (solution 1). If not, we may need to go to solution 2 (in which the responder authenticates in message 2). Here the main operational issue, pointed out by Antonio, is that you need to have a way for the initiator to signal that he is requiring legacy authentication. So all we need is some feedback on the above operational issues, and then make a definitive decision about the right design/privacy trade-off. It should not put any delay on the closure of ikev2. Hugo From owner-ipsec@lists.tislabs.com Wed Mar 19 14:30:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JMUQg17498; Wed, 19 Mar 2003 14:30:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20515 Wed, 19 Mar 2003 16:54:20 -0500 (EST) Message-ID: <3E78E80D.8E205ABE@airespace.com> Date: Wed, 19 Mar 2003 13:58:37 -0800 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russ Housley CC: Hugo Krawczyk , IPsec WG Subject: Re: Do ipsec vendors care about privacy? References: <5.2.0.9.2.20030319125702.031515a8@mail.binhost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2003 21:57:45.0393 (UTC) FILETIME=[929F8A10:01C2EE62] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Russ, I think Hugo may have something here. Lots of us implementers get so busy sometimes that we overlook things which are important, and I think this is one of them (at least in my case). This problem becomes much more immediate when you consider that wireless lan access is in some cases indistinguishable from remote access, and that exposing the user identity on a public network is an issue under such circumstances. I think we should consider this before ruling out the change. Scott Russ Housley wrote: > > Hugo, in my view it is too late to be raising a question that will cause > major surgery on the document. It is time to fix things that are broken, > make the document internally consistent, and publish it. I do not think it > is time to raise new requirements. > > Russ > Your local, friendly, incoming Security Area Director > > At 05:34 AM 3/19/2003 +0200, Hugo Krawczyk wrote: > >The catchy subject is mainly to grab the attention of ipsec vendors in this > >list (but it also reflects the contents of this note). > > > >The question that I want to resurrect is whether leaving the user's identity > >open to active disclosure attacks as done now in the "legacy authentication" > >solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable > >decision given that protecting against such attacks can be done at a moderate > >price (see explicit specification below). This decision seems especially > >dubious given that the roaming/remote user scenario is the only case in which > >identity protection clearly makes sense, and constitutes a natural requirement > >for ipsec solutions in the legacy authentication world. > > > >I raised this question some time ago (beginning of Feb) and its resolution > >was mainly based on the fact that protecting the user's identity is a bit > >more complex than not doing it. I remain unconvinced, however, that the WG > >(in particular ipsec vendors) made here an informed decision on this > >trade-off. > >I got the feeling that no one was really paying attention. (The only > >people to express opinions on this on the list were: Charlie who was > >"genuinely conflicted about this one", Derrell Piper and I that supported > >protecting the user's identity, and Marcus Leech who was against.) > > > >So before we close the ikev2 specification please take a look at what it takes > >to change the legacy authentication protocol in ikev2 to protect the user's > >identity from active attacks. Here are the two main candidate solutions: > > > >(1) Simply defer the sending of the user's identity IDi from message > >3 to message 5 (that is, after message 4 in which the responder authenticates > >itself). The difficuty here is that the responder does not have IDi to base > >its choice of EAP method in message 4. I do not know how much of a practical > >problem this is (it was never pointed as such in the case of PIC in the ipsra > >wg), but others will know better. > > > >p > >(2) Let the responder authenticate itself already in message 2. This can > >be achieved by moving the AUTH and IDr payloads from message 4 to message 2. > >If we do not require encrypting these fields then the change is simple. > >Adding encryption is possible but requires applying SK{} from the middle of > >message 2 which is more complex. I suggest doing it simple, i.e. without > >encryptioni (also integrity protection is not needed here). This leaves > >the identity of R in the plain but this is ONLY for > >the legacy authentication scenario in which protecting the responder > >(server/gateway) identity is of little (or no) importance. > > > >Either change requires minimal change to the current specification, > >and none has major implementation complexity. They do not change at all the > >main protocol, and are relevant only to implementations that support legacy > >authentication (where user's privacy is a real issue). > >It seems to me that in this case the "complexity vs security trade-off" > >is easily resolved in favor of the user's identity protection. > > > >What others think? > >(If this time no one cares then we can easily forget about this issue; at > >least this will help to document that this was a conscious decision of the > >WG.) > > > >Hugo > > > >PS: I'd have liked to raise this in the meeting in San Francisco but I > >couldn't make it. Hopefully there may still be some discussion on this there, > >or in the list in the nexy week. > > > > > >Lacking clear support for either way, Charlie > >decided to go with the simplest solution that is now in 05. This is > >certainly the right way to go if people do not really care about this > >privacy issue. In this case, however, I think that this decision needs > >to be documented in Radia's "rationale" draft (since this issue will be, I > >bet, something critiques of ikev2 will like to highlight). > >However, , before doing so I'd like to really sense if this is a thoughtful > >decision, or something that no one really cares about > >This note is intended to explicitl;y raise this issue before the closure > >of ikev2 specification. If people still support the current solution (or > >just shut up) then we will have a clear documentation that this decision > >reflects the WG view (if not strong consensus). > > > > > >On the other hand, I can bet > >that the future > >papers criticizing IKEv2 (there will be such papers no matter what we do) > > > >of the > >type written about IKEv1) will critically point > >to this issue. After all, they will say, a protocol that provides identity > >protection with me IF > > > > > > > > Hugo Krawczyk wrote: > > > > 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. > > > > > > I am genuinely conflicted about this one - like the donkey between the > > > two bales of hay. I see equally good arguments on both sides, and I > > > > > >This WG has a long tradition of making decisions that become controversial > >later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc). From owner-ipsec@lists.tislabs.com Wed Mar 19 14:40:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JMesg18361; Wed, 19 Mar 2003 14:40:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20548 Wed, 19 Mar 2003 17:15:20 -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: Wed, 19 Mar 2003 14:18:52 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: IKEv2 -02 draft available again Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. At the WG meeting today, there was a discussion of changing IKEv2 back to the ala carte method used in the IKEv2 -02 draft. Since most people haven't kept the old document, I have posted a copy that Charlie sent me. The text version (that has lost its page breaks) is at ; the original nroff is at . --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 19 16:37:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K0bYg24793; Wed, 19 Mar 2003 16:37:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21010 Wed, 19 Mar 2003 19:08:46 -0500 (EST) Message-Id: <200303200011.h2K0Boof058212@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Antonio Forzieri cc: "'IPsec WG'" Subject: Re: Secure remote access with IPsec In-reply-to: Your message of Wed, 19 Mar 2003 15:42:09 +0100. <3E7881C1.1050507@cefriel.it> Date: Thu, 20 Mar 2003 01:11:50 +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: Because this is a research work (thesis) It would have no sense for me implementing IKEv2. => research is not 100% paperwork... - Endpoint Authentication is solved by EAP even if there is "The compound authentication binding problem" using legacy authentication mechanism like CHAP, OTP, SecurID... However I think that in the future we will authenticate ourselves with a smart card, or something similar - What about Kerberos in EAP? => EAP is the PPP generic authentication. You can put what you'd like in EAP. - Why can't we make a binding AUTH with CHAP, OTP? => CHAP and OTP are included in EAP (CHAP as the MD5-Challenge, OTP as itself, both are "initial" types). - NAT-T capability are enabled in IKEv2, and I think it works well (what about let IKE speaks on UDP 4500 directly even when there isn't NAT-T => if it seems useful to permit this (IMHO it will be the case) then NAT-T support will get a MUST. function enabled? What's wrog with that?). => if the function is disabled this is simply a policy mismatch, i.e., a negociation failure (notification with error "INVALID-SYNTAX"?) I know the pseudo-NAT problem, however I think that an attacker on the path could easily delete all the message. => it seems you read my drafts! - IPsec is well integrated with MIPv6 [draft-ietf-mobileip-mipv6-ha-ipsec-03.txt], so we can think of a mobile node connecting back to his Corporate Network, without need rekeying when it changes his address (can we change the selectors of a SA or an entry of the SPD upon the receiving of a BU message?) => we cannot change the selectors of a SA without rekeying. And we shan't change a traffic selector of a tunnel without rekeying. The situation is a bit more complex for transport mode or peer addresses, today the only way is rekeying but there is a WG agreement it should be studied in a post-IKEv2 activity. Note the MN-HA transport mode SA for BU protection is setup in a proxy mode (transport mode where peer addresses and traffic selectors don't match). Such SAs cannot be updated but fortunately in this special case this is not needed... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Mar 19 17:08:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K18Ig25996; Wed, 19 Mar 2003 17:08:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21086 Wed, 19 Mar 2003 19:43:08 -0500 (EST) Message-Id: <200303200045.h2K0jnof058315@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-reply-to: Your message of Wed, 19 Mar 2003 18:55:34 +0200. <15992.41222.836986.56140@ryijy.hel.fi.ssh.com> Date: Thu, 20 Mar 2003 01:45:49 +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: Francis Dupont writes: > I do not think there are real world cases where the responder is > behind NAT, especialy dynamic NATs :-) > > => I can imagine as many as you are ready to read (:-), for instance I can imagine lots of things, but that does not make it real world case. => I believe I've got one real world example: peer-to-peer stuff where both peers can be behind a NAT and confidentiality should be supported end-to-end. There is a rendezvous system in order to "configure" the NATs but it doesn't participate to peer-to-peer communications... Note that I believe in this case IKE should be run directly over UDP 4500 and in the unlikely case there is no NAT at all peers should (in order to avoid a bidding down attack) fallback (i.e., retry as soon as they detect no NATs) to UDP 500. So the rendezvous system should deal with UDP 4500 and a large part of NAT-T MUST be supported (this is a good argument for a MUST). > one can use some kind of callback mechanism in order to enforce the > side of the initiator (firewalls are good reasons to do that). Where is that used in real world NOW? => I've seen this kind of mechanisms for firewall traversal (usually the rules are very different in the two ways). > To summarize, I can't see why we refuse the opportunity to support > any position for the NAT. I do think NAT can be in any position with current draft already, so there is no need to make the protocol more complicated because of some imagined cases. => IMHO the current draft is a bit underspecified, for instance it should explicitely permit to run IKE over port 4500 from the beginning (so there will be only one mapping and as soon as an exchange succeed the whole stuff, including IPsec SAs, works). For example the callback mechanism would propably want to do the => I disagree: a property of the callback is to use the asymmetry of some IKE features (cf the privacy reopen stuff) in the convenient way. So let just support any position for NATs: no NAT, initiator behind a NAT, responder behind a NAT, both peers behind NATs. With careful wording this should be possible. initial authentication before calling back, thus in the current protocol the original responder will already know the mapping for the port 4500, and there are NAT keepalives already going for that port, so it can directly connect to that port and use that as callback address. => note you explicitely use an IKE which always runs over UDP 4500. IMHO this is the good solution and it should be documented (current draft suggests the first exchange must be over UDP 500). Thanks Francis.Dupont@enst-bretagne.fr PS: so in your part (NAT-T) you should add some words about IKE_SA_INIT over UDP 4500 and what to do if no NAT is detected: - switch to UDP 500 for next messages (i.e., the opposite of NAT detection) - continue on UDP 4500 with a possible bidding down attack because NAT-T is less efficient (note it is no more less secure because the implicit update MUST NOT be enabled when the other peer is not behind a NAT, does the extra overhead really matter?) I propose to give the choice to the initiator with the first one by default? You should add something for the case all NATs are removed (i.e., an implicit update to the real peer addresses) with the same tradeoff. From owner-ipsec@lists.tislabs.com Wed Mar 19 18:30:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K2U0g01617; Wed, 19 Mar 2003 18:30:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21349 Wed, 19 Mar 2003 20:55:50 -0500 (EST) Message-Id: <5.2.0.9.0.20030319175509.038839a0@mail.attbi.com> X-Sender: alten@mail.attbi.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 19 Mar 2003 17:57:21 -0800 To: "Jesse Alpert" , Joern Sierwald From: Alex Alten Subject: RE: AES & IPsec questions Cc: In-Reply-To: <00c701c2ec82$9e1e88a0$7b2e1dc2@jesse> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you Jesse and Joern for your replies. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Wed Mar 19 23:36:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K7atg15273; Wed, 19 Mar 2003 23:36:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA22017 Thu, 20 Mar 2003 02:00:16 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66B1B@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Hugo Krawczyk '" , "'Russ Housley '" Cc: "'IPsec WG '" Subject: RE: Do ipsec vendors care about privacy? Date: Wed, 19 Mar 2003 22:58:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, yes, we do care. > The only question is operational: can the responder (server) send the > first EAP message before getting IDi? If this is the case (as it was in > PIC and seems tobe agreed in some responses to my message) then we are > done at no cost at all (solution 1). If not, we may need to go to > solution 2 (in which the responder authenticates in message 2). Here the > main operational issue, pointed out by Antonio, is that you need to have > a > way for the initiator to signal that he is requiring legacy > authentication. >Hugo I think I may be missing something, and would appreciate some clarification. Operationally, how can Bob know that he needs to send AUTH if he does not receive IDi from Alice, from which to do an SPD lookup, to know that AUTH is required for this particular connection? Bob will likely be a device doing both EAP'd IKE connections, and non-EAP IKE connections. Doesn't he need IDi to know when AUTH is to be used? Gregory NetScreen From owner-ipsec@lists.tislabs.com Thu Mar 20 00:44:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K8iDg24456; Thu, 20 Mar 2003 00:44:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA22243 Thu, 20 Mar 2003 03:13:34 -0500 (EST) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66B1C@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "''Hugo Krawczyk ' '" , "''Russ Housley ' '" Cc: "''IPsec WG ' '" Subject: RE2: Do ipsec vendors care about privacy? Date: Thu, 20 Mar 2003 00:12:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just had a thinking session with Bill Sommerfeld on this... My question, at least from both our perspectives, was valid; neither of us could think of a way to know if Bob should send EAP-Challenge in msg 4 w/o first having seen IDi, GIVEN -05's CURRENT TEXT ABOUT HOW EAP WORKS. However, we could move IDi to message 5 IF WE CHANGE HOW EAP WORKS. If a Bob who supports EAP in at least one of his SPDs ALWAYS sends EAP-Challenge in msg 4 for any connection, then we would need to add text as follows: - If Bob has any SPDs calling for EAP, he must ALWAYS send EAP-Challenge in msg 4, - It then becomes up to Alice's responsibility (based on SPD) to respond to the EAP-Challenge, but only if her SPD calls for it, - Bob cannot determine until receiving IDi in Msg 5 if he actually (according to HIS SPD) requires EAP. - Bob will process or drop depending upon local SPD for IDi But, all this is moot if we decide that IDr is more important to protect than IDi, as I think we did earlier in list history. The justification being that attacker can mount an active attack simply by initiating, and learn IDr. Gregory (with bar-input from Bill S. and Derek A.) -----Original Message----- From: Gregory Lebovitz To: 'Hugo Krawczyk '; 'Russ Housley ' Cc: 'IPsec WG ' Sent: 3/19/03 10:58 PM Subject: RE: Do ipsec vendors care about privacy? First, yes, we do care. > The only question is operational: can the responder (server) send the > first EAP message before getting IDi? If this is the case (as it was in > PIC and seems tobe agreed in some responses to my message) then we are > done at no cost at all (solution 1). If not, we may need to go to > solution 2 (in which the responder authenticates in message 2). Here the > main operational issue, pointed out by Antonio, is that you need to have > a > way for the initiator to signal that he is requiring legacy > authentication. >Hugo I think I may be missing something, and would appreciate some clarification. Operationally, how can Bob know that he needs to send AUTH if he does not receive IDi from Alice, from which to do an SPD lookup, to know that AUTH is required for this particular connection? Bob will likely be a device doing both EAP'd IKE connections, and non-EAP IKE connections. Doesn't he need IDi to know when AUTH is to be used? Gregory NetScreen From owner-ipsec@lists.tislabs.com Thu Mar 20 08:03:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KG2xg00848; Thu, 20 Mar 2003 08:03:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23208 Thu, 20 Mar 2003 10:33:47 -0500 (EST) Message-Id: <5.1.0.14.0.20030319091414.04e1fd50@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Mar 2003 09:21:17 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Another NAT Traversal question In-Reply-To: <3E781036.3020603@roc.co.in> References: <200302260015.h1Q0FDof060239@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA18106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:07 19.03.2003 +0530, you wrote: >IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of > NAT Traversal. If we make this packet also containing first four > bytes after > UDP header as 0s in case of IKE packet, then there is no need for > port 4500 > >Regards, >Ravi Well. Routers doing NAT reassign ports. In goes src/dst 53/53, out goes src/dst 1025/53 or something. On the return packets, the port number are changed back. You know that. The problem is that over 50% of all router DO NOT DO THAT if the port is 500 the keep the 500/500 mapping. Many small vendors do that. But even the current (February) Cisco IOS does that. And there is no way to switch it off. If you run IKE through a NAT box, the IKE client software can't use port 500. Using a random port >1023 works fine. But then the client can't be responder anymore.... the port 500 is spoiled, sorry, and it has to go. J–rn From owner-ipsec@lists.tislabs.com Thu Mar 20 08:03:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KG2xg00849; Thu, 20 Mar 2003 08:03:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23241 Thu, 20 Mar 2003 10:36:49 -0500 (EST) Cc: Hugo Krawczyk , ipsec@lists.tislabs.com Message-ID: <3E78B164.9080305@bell-labs.com> Disposition-Notification-To: Uri Blumenthal Date: Wed, 19 Mar 2003 13:05:24 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com Original-CC: Hugo Krawczyk , ipsec@lists.tislabs.com Subject: Re: Use of AES as prf in IKEv2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, I'm looking into this right now and would like a couple of days - till SAAG meeting - to possibly make a proposal. Out of hand, what you proposed looks OK. Charlie_Kaufman@notesdev.ibm.com wrote: > Having seen the alternatives, I withdraw my earlier objection to Hugo's > proposal for dealing with prf functions with fixed length keys. His > recommendation was that if the prf takes a fixed length key, we take the > first bits of the initiator's nonce as the first half and the first bits of > the responder's nonce as the second half. Not part of his suggestion, but > to make the proposal fully specified in all cases, I'd add that if either > nonce is shorter than half the fixed length key that it be padded with zero > bits. > > Does anyone object? > > --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@lists.tislabs.com Thu Mar 20 08:03:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KG32g00869; Thu, 20 Mar 2003 08:03:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23199 Thu, 20 Mar 2003 10:30:49 -0500 (EST) Message-ID: <3E798E13.5060307@roc.co.in> Date: Thu, 20 Mar 2003 15:16:59 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir CC: ipsec@lists.tislabs.com Subject: Re: IKEv2: prepending four octets References: <002f01c2edee$f26b8fd0$292e1dc2@YnirNew> Content-Type: multipart/alternative; boundary="------------040401060600010502020208" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------040401060600010502020208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi. Yoav Nir wrote: >The IKEv1 RFC mandated that IKE communications be from port 500 to port 500. >It states that replies to an IKE packet go to port 500, not the source port. >Implementations that follow the RFC cannot work when a NAT changes the >ports. > agreed > To overcome this problem, many NAT implementations added special >handling to port 500: > >Since these "smart" NAT devices are all over the place, we need to use a new > > >port that doesn't have this special handling. > > So, we will not disturb these NAT devices to work on port 500 Since, IKEv2 is now building from scratch we shall standardise Port 4500 instead of 500.The non Zero in first four bytes indicates IPsec packets and Zeros indicate IKE packets. --Ravi >-----Original Message----- >From: ravi [mailto:ravivsn@roc.co.in] >Sent: Wednesday, March 19, 2003 7:05 AM >To: Yoav Nir >Cc: ipsec@lists.tislabs.com >Subject: Re: IKEv2: prepending four octets > > >Hi, > > > >>You prepend four zeros to IKE messages, because no >>IPsec-encapsulated-in-UDP message begins with four zeros. An encapsulated >>IPSec packet begins with the SPI which is always non-zero. Adding four >>zeros to the beginning of an IKE message makes it possible to distinguish >>IKE messages from encapsulated IPSec packets. >> >> >> >> >IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of > NAT Traversal. If we make this packet also containing first four bytes >after > UDP header as 0s in case of IKE packet, then there is no need for port >4500 > >--Ravi > > > >>Hope this helps >> >>Yoav >> >>-----Original Message----- >>From: owner-ipsec@lists.tislabs.com >>[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ravi >>Sent: Tuesday, March 18, 2003 10:11 AM >>To: ipsec@lists.tislabs.com >>Subject: IKEv2: prepending four octets >> >> >>Dear All, >>I am going through the ikev2-0.5 draft.It says >>In the IKE header when sent on UDP port 4500 ,IKE messages have >>prepended four octets of Zero. >> >>My doubt is what made to prepend four octets of Zeroes before the IKE >>message. >>Thanks in advance, >>Ravi Kumar CH. >> >> >> >> >> >> >> > > > --------------040401060600010502020208 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi.

Yoav Nir wrote:
The IKEv1 RFC mandated that IKE communications be from port 500 to port 500.
It states that replies to an IKE packet go to port 500, not the source port.
Implementations that follow the RFC cannot work when a NAT changes the
ports.

agreed
  To overcome this problem, many NAT implementations added special
handling to port 500:
Since these "smart" NAT devices are all over the place, we need to use a new
  
port that doesn't have this special handling.


So, we will not disturb these NAT devices to work on port 500
Since, IKEv2 is now building from scratch we shall standardise Port 4500 instead  of 500.The non Zero in first
 four bytes indicates IPsec packets and Zeros indicate IKE packets.

--Ravi


-----Original Message-----
From: ravi [mailto:ravivsn@roc.co.in]
Sent: Wednesday, March 19, 2003 7:05 AM
To: Yoav Nir
Cc: ipsec@lists.tislabs.com
Subject: Re: IKEv2: prepending four octets


Hi,

  
You prepend four zeros to IKE messages, because no
IPsec-encapsulated-in-UDP message begins with four zeros.  An encapsulated
IPSec packet begins with the SPI which is always non-zero.  Adding four
zeros to the beginning of an IKE message makes it possible to distinguish
IKE messages from encapsulated IPSec packets.


    
IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of
      NAT Traversal. If we make this packet also containing first four bytes
after
      UDP header as 0s in case of IKE packet, then there is no need for port
4500

--Ravi

  
Hope this helps

Yoav

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ravi
Sent: Tuesday, March 18, 2003 10:11 AM
To: ipsec@lists.tislabs.com
Subject: IKEv2: prepending four octets


Dear All,
I am going through the ikev2-0.5 draft.It says
In the IKE header when sent on UDP port 4500 ,IKE messages have
prepended four octets of Zero.

My doubt is what made to prepend four octets of Zeroes before the IKE
message.
Thanks in advance,
Ravi Kumar CH.

--------------040401060600010502020208-- From owner-ipsec@lists.tislabs.com Thu Mar 20 08:03:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KG3Fg00889; Thu, 20 Mar 2003 08:03:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23198 Thu, 20 Mar 2003 10:30:48 -0500 (EST) Message-ID: From: "Vohra, Meenakshi" To: "'ipsec@lists.tislabs.com'" Subject: Phase1 Proposals Not Chosen with SSH Sentinel Eval. 1.4 Date: Wed, 19 Mar 2003 14:55:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EE6A.AF6C9C70" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ------_=_NextPart_001_01C2EE6A.AF6C9C70 Content-Type: text/plain; charset="ISO-8859-1" Hello Everyone, In my Phase1 proposal, I have configured DES, DH1,main mode, 14440 minutes, HMAC-SHA on my VPN Gateway. Similarly, I have also configured DES,DH1, main mode, 14440 minutes, SHA on SSH Sentinel. When I start a traffic from my gateway to SSH Sentinel, SSH rejects my proposals with the with the following IKE log at SSH Sentinel. To me all proposals looks ok at both ends. Please suggest. Regards, Meenakshi --- detailed IKE log ---------------------------------------------------------- DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; New SA DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Received packet[108] = 0x02a5ee0c 09f11eb6 00000000 00000000 01100200 00000000 0000006c 0d000038 00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004 00015180 80010001 80030001 80020002 80040001 0d00000c 8db7a418 11221660 0000000c da8e9378 80010000 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Packet received[108] = 0x02a5ee0c 09f11eb6 00000000 00000000 01100200 00000000 0000006c 0d000038 00000001 00000001 0000002c 01010001 00000024 01010000 800b0001 000c0004 00015180 80010001 80030001 80020002 80040001 0d00000c 8db7a418 11221660 0000000c da8e9378 80010000 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: doi = 1, sit = 0x1 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: Proposal[0] = 1 .protocol[0] = 1, # transforms = 1, spi[0] DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: trans[0] = 1, id = 1, # sa = #6 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: da[0], type = 11, value[2] = 0x0001 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: da[1], type = 12, value[4] = 0x00015180 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: da[2], type = 1, value[2] = 0x0001 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: da[3], type = 3, value[2] = 0x0001 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: da[4], type = 2, value[2] = 0x0002 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode SA: da[5], type = 4, value[2] = 0x0001 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode VID: data[8] = 0x8db7a418 11221660 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Decode VID: data[8] = 0xda8e9378 80010000 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Version = 1.0, Input packet fields = 0401 SA VID : Received vendor id `8d b7 a4 18 11 22 16 60' from No Id (server 208.206.10.7:500) : Received vendor id `da 8e 93 78 80 01 00 00' from No Id (server 208.206.10.7:500) DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Life duration 86400 secs DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Encryption alg = 1 (des-cbc) DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Auth method = 1 (Pre-Shared-Key) DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Hash alg = 2 (sha1) DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Group = 1, ad5a00 : Phase-1 [responder] between unknown(any:0,[0..0]=) and ipv4(any:0,[0..3]=208.206.10.7) failed; No proposal chosen. DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Error = No proposal chosen (14) DEBUG: 0.0.0.0:500 (Initiator) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] / 0x0091acf7 } Info; Sending negotiation back, error = 14 DEBUG: 0.0.0.0:500 (Initiator) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] / 0x0091acf7 } Info; Encode packet, version = 1.0, flags = 0x00000000 DEBUG: 0.0.0.0:500 (Initiator) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] / 0x0091acf7 } Info; Encode N: doi = 1, proto = 1, type = 14, spi[16] = 0x02a5ee0c 09f11eb6 9c75e563 d6000016 DEBUG: 0.0.0.0:500 (Initiator) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] / 0x0091acf7 } Info; Encode N: data[46] = 0x800c0001 00060022 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000 DEBUG: 0.0.0.0:500 (Initiator) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] / 0x0091acf7 } Info; Encoded packet[102] = 0x02a5ee0c 09f11eb6 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000 DEBUG: 0.0.0.0:500 (Initiator) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] / 0x0091acf7 } Info; Sending packet[102] = 0x02a5ee0c 09f11eb6 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000 DEBUG: 0.0.0.0:500 (Initiator) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] / 0x0091acf7 } Info; Deleting negotiation DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Packet to old negotiation DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Sending packet[102] = 0x02a5ee0c 09f11eb6 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Packet to old negotiation DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Sending packet[102] = 0x02a5ee0c 09f11eb6 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Packet to old negotiation DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Sending packet[102] = 0x02a5ee0c 09f11eb6 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Packet to old negotiation DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Sending packet[102] = 0x02a5ee0c 09f11eb6 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000 DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Removing negotiation DEBUG: 0.0.0.0:500 (Responder) <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] / 0x00000000 } IP; Deleting negotiation Meenakshi Vohra Software Engineer <<...OLE_Obj...>> Fremont , CA 94538 Tel. (510) 687 3177 ------_=_NextPart_001_01C2EE6A.AF6C9C70 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Phase1 Proposals Not Chosen with SSH Sentinel Eval. 1.4

Hello Everyone,

In my Phase1 proposal, I have = configured DES, DH1,main mode, 14440 minutes, HMAC-SHA on my VPN = Gateway.
Similarly, I have also = configured DES,DH1, main mode, 14440 minutes, SHA on SSH = Sentinel.
When I start a traffic from my = gateway to SSH Sentinel, SSH rejects my proposals with the with the = following IKE log at SSH Sentinel. To me all proposals looks ok at both = ends. Please suggest.

Regards,
Meenakshi

--- detailed IKE log = ----------------------------------------------------------
DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; New SA

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Received packet[108] =3D 0x02a5ee0c 09f11eb6 = 00000000 00000000 01100200 00000000 0000006c 0d000038 00000001 00000001 = 0000002c 01010001 00000024 01010000 800b0001 000c0004 00015180 80010001 = 80030001 80020002 80040001 0d00000c 8db7a418 11221660 0000000c da8e9378 = 80010000

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Packet received[108] =3D 0x02a5ee0c 09f11eb6 = 00000000 00000000 01100200 00000000 0000006c 0d000038 00000001 00000001 = 0000002c 01010001 00000024 01010000 800b0001 000c0004 00015180 80010001 = 80030001 80020002 80040001 0d00000c 8db7a418 11221660 0000000c da8e9378 = 80010000

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: doi =3D 1, sit =3D 0x1

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: Proposal[0] =3D 1 .protocol[0] =3D 1, # = transforms =3D 1, spi[0]

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: trans[0] =3D 1, id =3D 1, # sa =3D = #6

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: da[0], type =3D 11, value[2] =3D = 0x0001

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: da[1], type =3D 12, value[4] =3D = 0x00015180

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: da[2], type =3D 1, value[2] =3D = 0x0001

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: da[3], type =3D 3, value[2] =3D = 0x0001

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: da[4], type =3D 2, value[2] =3D = 0x0002

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode SA: da[5], type =3D 4, value[2] =3D = 0x0001

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode VID: data[8] =3D 0x8db7a418 = 11221660

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Decode VID: data[8] =3D 0xda8e9378 = 80010000

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Version =3D 1.0, Input packet fields =3D 0401 SA VID =

: Received vendor id `8d b7 a4 = 18 11 22 16 60' from No Id (server 208.206.10.7:500)
: Received vendor id `da 8e 93 = 78 80 01 00 00' from No Id (server 208.206.10.7:500)
DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Life duration 86400 secs

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Encryption alg =3D 1 (des-cbc)

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Auth method =3D 1 (Pre-Shared-Key)

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Hash alg =3D 2 (sha1)

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Group =3D 1, ad5a00

: Phase-1 [responder] between = unknown(any:0,[0..0]=3D) and ipv4(any:0,[0..3]=3D208.206.10.7) failed; = No proposal chosen.
DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Error =3D No proposal chosen (14)

DEBUG: 0.0.0.0:500 (Initiator) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] = / 0x0091acf7 } Info; Sending negotiation back, error =3D 14

DEBUG: 0.0.0.0:500 (Initiator) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] = / 0x0091acf7 } Info; Encode packet, version =3D 1.0, flags =3D = 0x00000000

DEBUG: 0.0.0.0:500 (Initiator) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] = / 0x0091acf7 } Info; Encode N: doi =3D 1, proto =3D 1, type =3D 14, = spi[16] =3D 0x02a5ee0c 09f11eb6 9c75e563 d6000016

DEBUG: 0.0.0.0:500 (Initiator) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] = / 0x0091acf7 } Info; Encode N: data[46] =3D 0x800c0001 00060022 = 436f756c 64206e6f 74206669 6e642061 63636570 7461626c 65207072 6f706f73 = 616c8008 0000

DEBUG: 0.0.0.0:500 (Initiator) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] = / 0x0091acf7 } Info; Encoded packet[102] =3D 0x02a5ee0c 09f11eb6 = 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e = 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f = 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 = 0000

DEBUG: 0.0.0.0:500 (Initiator) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] = / 0x0091acf7 } Info; Sending packet[102] =3D 0x02a5ee0c 09f11eb6 = 9c75e563 d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e = 02a5ee0c 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f = 74206669 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 = 0000

DEBUG: 0.0.0.0:500 (Initiator) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [0] = / 0x0091acf7 } Info; Deleting negotiation

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Packet to old negotiation

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Sending packet[102] =3D 0x02a5ee0c 09f11eb6 9c75e563 = d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c = 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 = 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Packet to old negotiation

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Sending packet[102] =3D 0x02a5ee0c 09f11eb6 9c75e563 = d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c = 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 = 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Packet to old negotiation

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Sending packet[102] =3D 0x02a5ee0c 09f11eb6 9c75e563 = d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c = 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 = 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Packet to old negotiation

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Sending packet[102] =3D 0x02a5ee0c 09f11eb6 9c75e563 = d6000016 0b100500 0091acf7 00000066 0000004a 00000001 0110000e 02a5ee0c = 09f11eb6 9c75e563 d6000016 800c0001 00060022 436f756c 64206e6f 74206669 = 6e642061 63636570 7461626c 65207072 6f706f73 616c8008 0000

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Removing negotiation

DEBUG: 0.0.0.0:500 (Responder) = <-> 208.206.10.7:500 { 02a5ee0c 09f11eb6 - 9c75e563 d6000016 [-1] = / 0x00000000 } IP; Deleting negotiation




Meenakshi Vohra
Software Engineer
= <<...OLE_Obj...>>
Fremont , CA 94538
Tel. (510) 687 3177
<http://www.ipolicynet.com/>

------_=_NextPart_001_01C2EE6A.AF6C9C70-- From owner-ipsec@lists.tislabs.com Thu Mar 20 08:03:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KG3jg00903; Thu, 20 Mar 2003 08:03:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23187 Thu, 20 Mar 2003 10:29:45 -0500 (EST) X-Originating-IP: [128.187.170.213] X-Originating-Email: [t_sundelin@hotmail.com] From: "Tore" To: Subject: Newbie ESP Question Date: Wed, 19 Mar 2003 13:40:57 -0700 Message-ID: <002701c2ee57$d7d437d0$d5aabb80@hansolo> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C2EE1D.2B755FD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 19 Mar 2003 20:41:00.0291 (UTC) FILETIME=[D9C4BD30:01C2EE57] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C2EE1D.2B755FD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All - I am currently working on a proof-of-concept implementation of a proxy-based wireless authentication and authorization protocol for my Master's Thesis. Anyway, my cryptographic needs appear to be met by IPSec's ESP w/ authentication's characteristics: connectionless, authenticity, confidentiality, and replay-resistance. While I should in theory be fine using ESP w/ Wi-Fi devices (which is what I will be doing), what happens if I change the network protocol stack? In other words, will ESP's (using it in transport mode w/ authentication) security characteristics hold for example if I try and use it w/ Bluetooth? IrDA? I ask this b/c it seems as though (plz remember I am a newbie) ESP w/ auth in transport mode seems to provide these characteristics independently of both IP v4 header data as well as the type of data handed it by the "transport" layer protocol. Thanks in advance for any help on this issue. Kind Regards, Tore ------=_NextPart_000_0028_01C2EE1D.2B755FD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All –

 

         =    I am currently working on a proof-of-concept implementation of a = proxy-based wireless authentication and authorization protocol for my Master’s Thesis.  Anyway, my cryptographic needs appear to be met by = IPSec’s ESP w/ authentication’s characteristics: connectionless, = authenticity, confidentiality, and replay-resistance.  While I should in theory = be fine using ESP w/ Wi-Fi devices (which is what I will be doing), what happens = if I change the network protocol stack?  In other words, will = ESP’s (using it in transport mode w/ authentication) security characteristics = hold for example if I try and use it w/ Bluetooth?  IrDA?  I ask = this b/c it seems as though (plz remember I am a newbie) ESP w/ auth in transport = mode seems to provide these characteristics independently of both IP v4 = header data as well as the type of data handed it by the “transport” = layer protocol.  Thanks in advance for any help on this = issue.

 

Kind Regards,

Tore

 

------=_NextPart_000_0028_01C2EE1D.2B755FD0-- From owner-ipsec@lists.tislabs.com Thu Mar 20 08:46:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KGkdg02216; Thu, 20 Mar 2003 08:46:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23435 Thu, 20 Mar 2003 11:17:55 -0500 (EST) From: "Yoav Nir" To: "'Tore'" , Subject: RE: Newbie ESP Question Date: Thu, 20 Mar 2003 18:21:39 +0200 Message-ID: <001301c2eefc$c9db58c0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <002701c2ee57$d7d437d0$d5aabb80@hansolo> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't know much about bluetooth or IrDa, but I believe that sticking an ESP header under some bluetooth or IrDa header is a serious change to that protocol. The packet you create should still have a header that is acceptable to the bluetooth receiver, it should be easily recognizable. If there are any integrity protections in bluetooth, such as checksum fields, they have to be correct both for the encrypted packet, and for the reconstructed packet. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tore Sent: Wednesday, March 19, 2003 10:41 PM To: ipsec@lists.tislabs.com Subject: Newbie ESP Question All - I am currently working on a proof-of-concept implementation of a proxy-based wireless authentication and authorization protocol for my Master 's Thesis. Anyway, my cryptographic needs appear to be met by IPSec's ESP w/ authentication's characteristics: connectionless, authenticity, confidentiality, and replay-resistance. While I should in theory be fine using ESP w/ Wi-Fi devices (which is what I will be doing), what happens if I change the network protocol stack? In other words, will ESP's (using it in transport mode w/ authentication) security characteristics hold for example if I try and use it w/ Bluetooth? IrDA? I ask this b/c it seems as though (plz remember I am a newbie) ESP w/ auth in transport mode seems to provide these characteristics independently of both IP v4 header data as well as the type of data handed it by the "transport" layer protocol. Thanks in advance for any help on this issue. Kind Regards, Tore From owner-ipsec@lists.tislabs.com Thu Mar 20 10:37:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KIbsg07043; Thu, 20 Mar 2003 10:37:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23711 Thu, 20 Mar 2003 12:59:10 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15994.466.938926.801627@ryijy.hel.fi.ssh.com> Date: Thu, 20 Mar 2003 20:00:50 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-Reply-To: <200303200045.h2K0jnof058315@givry.rennes.enst-bretagne.fr> References: <15992.41222.836986.56140@ryijy.hel.fi.ssh.com> <200303200045.h2K0jnof058315@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => IMHO the current draft is a bit underspecified, for instance it > should explicitely permit to run IKE over port 4500 from the beginning > (so there will be only one mapping and as soon as an exchange succeed > the whole stuff, including IPsec SAs, works). >From the draft-ietf-ipsec-ikev2-05.tx: ---------------------------------------------------------------------- 2.11 Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming connection requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received. IKE functions identically over IPv4 or IPv6. ---------------------------------------------------------------------- I.e it now already says that both port 500 and 4500 are used, and the NAT traversal sections says: ---------------------------------------------------------------------- 2.23 NAT Traversal ... The specific requirements for supporting NAT traversal are listed below. Support for NAT traversal is optional. In this section only, requirements listed as MUST only apply to implementations supporting NAT. IKE MUST listen on port 4500 as well as port 500. IKE MUST respond to the IP address and port from which packets arrived. ---------------------------------------------------------------------- > => note you explicitely use an IKE which always runs over UDP 4500. > IMHO this is the good solution and it should be documented (current > draft suggests the first exchange must be over UDP 500). Where does it say so? The current draft talks about ports 500 and 4500 in almost equal way (only difference being that 4500 have different encoding and that port 4500 works better through NATs). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Mar 20 11:23:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KJNFg11753; Thu, 20 Mar 2003 11:23:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23823 Thu, 20 Mar 2003 13:47:41 -0500 (EST) Message-Id: <200303201850.h2KIoOof060870@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, charlie_kaufman@notesdev.ibm.com Subject: Re: draft-ietf-ipsec-ikev2-05.txt comments In-reply-to: Your message of Thu, 20 Mar 2003 20:00:50 +0200. <15994.466.938926.801627@ryijy.hel.fi.ssh.com> Date: Thu, 20 Mar 2003 19:50: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: Francis Dupont writes: > => IMHO the current draft is a bit underspecified, for instance it > should explicitely permit to run IKE over port 4500 from the beginning > (so there will be only one mapping and as soon as an exchange succeed > the whole stuff, including IPsec SAs, works). >From the draft-ietf-ipsec-ikev2-05.tx: ---------------------------------------------------------------------- 2.11 Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming connection requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received. IKE functions identically over IPv4 or IPv6. => IMHO this section is too short but this is not the best place for my "explicitely permit to run IKE over port 4500 from the beginning". I.e it now already says that both port 500 and 4500 are used, and the => but it suggest the NAT Traversal is activated only after a NAT detection on port 500. I believe we need more flexibility. NAT traversal sections says: ---------------------------------------------------------------------- 2.23 NAT Traversal ... The specific requirements for supporting NAT traversal are listed below. Support for NAT traversal is optional. In this section only, => with my (current) proposal, this "optional" doesn't make sense so we can put more in requirements for any implementations or jump to a SHOULD for NAT Traversal support? requirements listed as MUST only apply to implementations supporting NAT. IKE MUST listen on port 4500 as well as port 500. IKE MUST respond to the IP address and port from which packets arrived. > => note you explicitely use an IKE which always runs over UDP 4500. > IMHO this is the good solution and it should be documented (current > draft suggests the first exchange must be over UDP 500). Where does it say so? The current draft talks about ports 500 and 4500 in almost equal way (only difference being that 4500 have different encoding and that port 4500 works better through NATs). => the current spec describes a switch to port 4500, so implicitely it assumes it always starts over port 500. This is only a problem in the wording but it has an impact on the NAT Traversal support requirement because with the better wording IKE will always support NAT Traversal and it doesn't make sense to get no support for the other parts of IPsec. So we can argue for at least a SHOULD based on a protocol argument. I'm trying to do several things at the same time so I forget the most important: places are near NAT-DETECTION words. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Mar 20 12:52:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KKqug14218; Thu, 20 Mar 2003 12:52:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24192 Thu, 20 Mar 2003 15:14:57 -0500 (EST) Message-ID: <20030320201851.12394.qmail@web20514.mail.yahoo.com> Date: Thu, 20 Mar 2003 12:18:51 -0800 (PST) From: jeff pickering Subject: implementor's view of ikev2 simul rekey To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Given that we have 3 weeks for CP v DHCP, I would like to add some text to the simul rekey area because it addresses a real issue and the solution is simple. The issue is that any approach to the simul reky problem needs to address 2 issues: 1) The first is the prevention of the socerer's appretice problem where multiple rekey could result in an expanding number of rekey'd SAs. The current text rightly notes that the potential exists for a rekey to result in multiple SAs and goes on to say that these must be detected and each side should discard one of the duplicates. Unfortunately, it doesn't specify which SA should be deleted. This could result in each side simultaneously deleting different SAs which could cause temporary connectivity loss. Since prevention of this by specifying which SA should be deleted would be trivial, I dont see any reason for not adding text to the spec for doing this. For example, text could be easily added saying to keep the rekeyed SA created by the original SA initiator. 2) The second problem that needs to be addressed is the "whose child is this" problem. This arises during simul rekey of IKE SAs because child SAs that exist prior to rekey are inherited by the rekeyed IKE SA, but if multiple IKE SAs exist for a short period, you can't tell which new IKE SA is the inheritor. Each side could think differently. This is currently addressed in the spec by saying that a child request should be accepted on either of the SA's. But from an implementor's viewpoint (admittedly mine), this is truly ugly. As an alternative, I would like to propose a very simple alternative that, IMHO, is simple and clean. This would be to prevent duplicate SA creation by using a tie-breaking mechanism that states when an attempt to simul rekey is detected (which must be done per current spec anyway, ie detect and incoming reky request when you have sent a rekey request but have not yet received a response), you allow only the preferred rekey to succeed (eg request by original initiator). This also has the added benefit of being forward compatible with allowing multiple equivalent SAs for QOS. Without this, my belief is that there will be an interoperability problem adding this in the future. In summary, Im suggesting at a minimum a text change to spec which duplicate should be deleted. I also propose a simple enhancement which could totally prevent duplicates using a mechanism equivalent to that used for the same purpose by BGP and has been field proven. I dont propose text changes today but would be willing to do so if this is of interest. Regards, Jeff __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-ipsec@lists.tislabs.com Thu Mar 20 14:04:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KM48g18137; Thu, 20 Mar 2003 14:04:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24355 Thu, 20 Mar 2003 16:28:36 -0500 (EST) Date: Thu, 20 Mar 2003 23:31:53 +0200 (IST) From: Hugo Krawczyk To: Gregory Lebovitz cc: "''Russ Housley ' '" , "''IPsec WG ' '" Subject: Re: RE2: Do ipsec vendors care about privacy? In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66B1C@SARATOGA.netscreen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gregory, Your previous email seemed to be talking about what I described as solution (2), namely the responder auhenticates in message 2 rather than in msg 4. In that case the issue of how R knows that he needs to respond with authentication in message 2 (rather than the regular IKE behaviour) is a valid question. The only solution I can see for that is to add an indication from the Initiator in message 1 (either an additional field in the message or some other trick such a convention about the value of SPI chosen by I). The email below, however, seems to be talking about solution (1) in which the only difference with the current mechanism for EAP support in ikev2-05 (sec 2.16) is moving IDi from msg 3 to msg 5. In this case there is no problem for R to know that the initiator intends to do a EAP-authentication. As explained in page 27 of draft-05: "An initiator indicates a desire to use extended authentication by leaving out the AUTH payload from message 3." Same will hold with the modified solution. The question is: DOES THE RESPONDER (GATEWAY) NEED TO KNOW the value IDi IN ORDER TO DETERMINE THE CONTENTS OF THE EAP PAYLOAD SENT IN MESSAGE 4? If the answer is NO (as assumed in the PIC protocol developed under the ipsra WG) then solution (1) provides user's privacy at no extra cost and we should certainly go with it for IKEv2. If the answer is that R CANNOT know how to generate the EAP payload if it does not know IDi then we can forget of solution (1). If the answer is: most usually R does NOT NEED to know IDi (but in some special case it may need it) then I'd still go with solution (1). In my view, user's privacy in the remote access scenario is more important than covering some unusual cases. IF for some reason solution (1) is deemed inappropriate then solution (2) should be chosen but then the real question is what indication can the initiator provide to the responder for the latter to know that it needs to authenticate (send IDr and AUTH) in message 2. Note that in this solution the responder sends the EAP payload in message 4 AFTER having learned IDi in message 3, so the above problem with solution (1) does not exisit here. Hugo On Thu, 20 Mar 2003, Gregory Lebovitz wrote: > Just had a thinking session with Bill Sommerfeld on this... > > My question, at least from both our perspectives, was valid; neither of us > could think of a way to know if Bob should send EAP-Challenge in msg 4 w/o > first having seen IDi, GIVEN -05's CURRENT TEXT ABOUT HOW EAP WORKS. > > However, we could move IDi to message 5 IF WE CHANGE HOW EAP WORKS. If a Bob > who supports EAP in at least one of his SPDs ALWAYS sends EAP-Challenge in > msg 4 for any connection, then we would need to add text as follows: > - If Bob has any SPDs calling for EAP, he must ALWAYS send EAP-Challenge in > msg 4, > - It then becomes up to Alice's responsibility (based on SPD) to respond to > the EAP-Challenge, but only if her SPD calls for it, > - Bob cannot determine until receiving IDi in Msg 5 if he actually > (according to HIS SPD) requires EAP. > - Bob will process or drop depending upon local SPD for IDi > > But, all this is moot if we decide that IDr is more important to protect > than IDi, as I think we did earlier in list history. The justification being > that attacker can mount an active attack simply by initiating, and learn > IDr. > > Gregory (with bar-input from Bill S. and Derek A.) > > -----Original Message----- > From: Gregory Lebovitz > To: 'Hugo Krawczyk '; 'Russ Housley ' > Cc: 'IPsec WG ' > Sent: 3/19/03 10:58 PM > Subject: RE: Do ipsec vendors care about privacy? > > First, yes, we do care. > > > The only question is operational: can the responder (server) send the > > first EAP message before getting IDi? If this is the case (as it was > in > > PIC and seems tobe agreed in some responses to my message) then we are > > done at no cost at all (solution 1). If not, we may need to go to > > solution 2 (in which the responder authenticates in message 2). Here > the > > main operational issue, pointed out by Antonio, is that you need to > have > > a > > way for the initiator to signal that he is requiring legacy > > authentication. > >Hugo > > I think I may be missing something, and would appreciate some > clarification. Operationally, how can Bob know that he needs to send > AUTH if he does not receive IDi from Alice, from which to do an SPD > lookup, to know that AUTH is required for this particular connection? > Bob will likely be a device doing both EAP'd IKE connections, and > non-EAP IKE connections. Doesn't he need IDi to know when AUTH is to be > used? > > Gregory > NetScreen > From owner-ipsec@lists.tislabs.com Thu Mar 20 14:07:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KM7sg18194; Thu, 20 Mar 2003 14:07:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24382 Thu, 20 Mar 2003 16:43:42 -0500 (EST) Date: Thu, 20 Mar 2003 16:49:07 -0500 Message-Id: <200303201649.AA1634533642@elmic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: " Zhang" Reply-To: To: CC: Subject: Delete Payload processing in IKEv2_05 X-Mailer: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Charlie, I don't follow the description of IKEv2_05, section 1.4 about the delete informational exchange. I suggest change the last paragraph of page 10 to the following. >From end of Page 10: ......To delete an SA, an INFORMATIONAL Exchange with one or more delete payload is sent listing the SPIs (as they would be placed in the headers of outbound packets) of the SAs to be deleted. The recipient MUST delete the incoming SAs while processing the request and the paired outgoing SAs, if any, while processing the response. If any paired outgoing SAs are deleted, the reply in the INFORMATIONAL Exchange MUST contain delete payloads for these deleted ones,( otherwise, the reply MUST NOT contain any delete payloads.) The reason for this change: 1) The original document put "it MUST delete the incoming SAs while processing the request and the outgoing SAs while processing the response" into the exception block. However, this should be a normal behavior for the recipient. And actually, for the exception case (simultanously sent out delete request), the outgoing SAs had been deleted. 2) There may be asymmetry policy which specifies IPsec protection in only ONE direction. That justifies the 'if any' in the above text. The exception case in the original IKEv2-05 document belongs to this solution, i.e., no outgoing SAs found. Thanks, Jimmy Zhang Elmic Systems. Inc. ---------- Original Message ---------------------------------- From: Tero Kivinen Date: Thu, 20 Mar 2003 20:00:50 +0200 >Francis Dupont writes: >> => IMHO the current draft is a bit underspecified, for instance it >> should explicitely permit to run IKE over port 4500 from the beginning >> (so there will be only one mapping and as soon as an exchange succeed >> the whole stuff, including IPsec SAs, works). > >>From the draft-ietf-ipsec-ikev2-05.tx: >---------------------------------------------------------------------- >2.11 Address and Port Agility > > IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and > AH associations for the same IP addresses it runs over. The IP > addresses and ports in the outer header are, however, not themselves > cryptographically protected, and IKE is designed to work even through > Network Address Translation (NAT) boxes. An implementation MUST > accept incoming connection requests even if not received from UDP > port 500 or 4500, and MUST respond to the address and port from which > the request was received. IKE functions identically over IPv4 or > IPv6. >---------------------------------------------------------------------- > >I.e it now already says that both port 500 and 4500 are used, and the >NAT traversal sections says: >---------------------------------------------------------------------- >2.23 NAT Traversal > >... > The specific requirements for supporting NAT traversal are listed > below. Support for NAT traversal is optional. In this section only, > requirements listed as MUST only apply to implementations supporting > NAT. > > IKE MUST listen on port 4500 as well as port 500. IKE MUST respond > to the IP address and port from which packets arrived. >---------------------------------------------------------------------- > >> => note you explicitely use an IKE which always runs over UDP 4500. >> IMHO this is the good solution and it should be documented (current >> draft suggests the first exchange must be over UDP 500). > >Where does it say so? The current draft talks about ports 500 and >4500 in almost equal way (only difference being that 4500 have >different encoding and that port 4500 works better through NATs). >-- >kivinen@ssh.fi >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Thu Mar 20 14:08:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KM7xg18208; Thu, 20 Mar 2003 14:07:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24376 Thu, 20 Mar 2003 16:42:42 -0500 (EST) Date: Thu, 20 Mar 2003 23:46:17 +0200 (IST) From: Hugo Krawczyk To: Gregory Lebovitz cc: "'Russ Housley '" , "'IPsec WG '" Subject: RE: Do ipsec vendors care about privacy? In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66B1B@SARATOGA.netscreen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A couple of messages in this thread remind us that the WG decided that protecting the responder's identity from active attacks is preferable to protecting I's identity from such attacks. That's true, and I do NOT suggest to change that decision in the general case. However, since ikev2 has already gone to the effort of creating a variant of the protocol SPECIFIC for the remote access scenario then it makes sense to take advantage of this (as long as it does not incur in a significant cost or delay to the ikev2 document) to provide user's privacy via a strong protection of IDi. As opposed to the general case, in which what identity (I or R) is more important to protect is debatable (and many of the participants in this WG have changed their minds on this at least one time), in the remote access scenario it is OBVIOUS that hiding I's (the user's) identity from attackers in the network is far more important (than protecting the publicly known identity of the usually fixed-address gateway. If we decide not to provide user's id protection (from active attacks) in the EAP-based remote access protocol, the rationale for that decision must be documented (maybe in Radia's draft). This will not avoid later complaints by vendors and researchers but at least will show that it was a conscious decision rather than a simple overlook. Hugo From owner-ipsec@lists.tislabs.com Thu Mar 20 14:43:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2KMh9g19802; Thu, 20 Mar 2003 14:43:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24444 Thu, 20 Mar 2003 17:00:00 -0500 (EST) Message-Id: <5.2.0.9.2.20030320164711.0194e328@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Mar 2003 17:02:45 -0500 To: Hugo Krawczyk From: Russ Housley Subject: Re: Do ipsec vendors care about privacy? Cc: IPsec WG In-Reply-To: References: <5.2.0.9.2.20030319125702.031515a8@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo: I wrote: >Hugo, in my view it is too late to be raising a question that will cause >major surgery on the document. It is time to fix things that are broken, >make the document internally consistent, and publish it. I do not think it >is time to raise new requirements. You replied: >This response really sounds as coming from the area director :) >ANyway, I'd agree with you that this is too late if the change I proposed >required "major surgery on the document". But it doesn't. >Any of the proposed solutions takes a 1 minute editorial work, >just moving one or two fields from one message to the other in section >2.16 (and has no influence on other partts of the document). > >The question is not specification complexity which is null for this >changes. ALso, it is not a performance issue. None of the proposed changes >add round trips or computation (a message to the list from >Antonio Forzieri might have given that impression but his >modification of my proposal was unnecessary as he later stated himself). > >The only question is operational: can the responder (server) send the >first EAP message before getting IDi? If this is the case (as it was in >PIC and seems tobe agreed in some responses to my message) then we are >done at no cost at all (solution 1). If not, we may need to go to >solution 2 (in which the responder authenticates in message 2). Here the >main operational issue, pointed out by Antonio, is that you need to have a >way for the initiator to signal that he is requiring legacy >authentication. > >So all we need is some feedback on the above operational issues, and then >make a definitive decision about the right design/privacy trade-off. >It should not put any delay on the closure of ikev2. The working group co-chairs in combination with the document editor need to make a decision concerning the magnitude of the changes. If it is the least bit onerous, then this should not be done. It is not a requirement, and we are already overdue on delivery. It is time to warp this effort up. Fix anything that fails to meet the requirements that have already been set by the working group. then make the document internally consistent. Additional stuff can be dealt with by a subsequent working group. Ted got it right at the beginning of the meeting. He said, "It is time to shoot the engineers and ship the product." Russ From owner-ipsec@lists.tislabs.com Thu Mar 20 23:43:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2L7hGg16509; Thu, 20 Mar 2003 23:43:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA25731 Fri, 21 Mar 2003 02:07:07 -0500 (EST) Date: Fri, 21 Mar 2003 09:10:38 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: IPsec WG Subject: Re: Do ipsec vendors care about privacy? In-Reply-To: <5.2.0.9.2.20030320164711.0194e328@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 Thu, 20 Mar 2003, Russ Housley wrote: > Hugo: > > > I wrote: > >Hugo, in my view it is too late to be raising a question that will cause > >major surgery on the document. It is time to fix things that are broken, > >make the document internally consistent, and publish it. I do not think it > >is time to raise new requirements. I agree: no time for major surgery on the document. But not too late for a change that takes 1-5 minutes editorial work On the other hand, I admit that there are some operational issues that are not fully resolved in my proposals and need more input from people that care and know better. If this does not come on time to make the document before being closed then we will not have it. On the other hand, user's id protection in the remote access protocol of ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec developers (on the list and outside the list). So giving the opprtunity to this substantial improvement if it comes at little cost and on time is a reasonable thing to do. In any case, ,I raised the issue and two possible solutions, but I am not the one that needs to decide if the WG is to adopt this or not. THOSE THAT CARE (in one way or another) SHOULD SPEAK UP. If there is not enough interest, then nothing needs to be done. At least it will be documented that this was a conscious decision rather than an overlook or the result of simple rushing. (This will help against future criticizers of the protocol that wil raise these issues in their papers...) I will be glad to see some technical discussion in the coming days if people care about having such discussions. Beyond that I am not going to insist (this is not an area of "correct cryptographic design" for which I personally care but rather one of engineering trade-offs that other understand better than me). Hugo PS: shoot the engineers but not the scientists :) > > You replied: > >This response really sounds as coming from the area director :) > >ANyway, I'd agree with you that this is too late if the change I proposed > >required "major surgery on the document". But it doesn't. > >Any of the proposed solutions takes a 1 minute editorial work, > >just moving one or two fields from one message to the other in section > >2.16 (and has no influence on other partts of the document). > > > >The question is not specification complexity which is null for this > >changes. ALso, it is not a performance issue. None of the proposed changes > >add round trips or computation (a message to the list from > >Antonio Forzieri might have given that impression but his > >modification of my proposal was unnecessary as he later stated himself). > > > >The only question is operational: can the responder (server) send the > >first EAP message before getting IDi? If this is the case (as it was in > >PIC and seems tobe agreed in some responses to my message) then we are > >done at no cost at all (solution 1). If not, we may need to go to > >solution 2 (in which the responder authenticates in message 2). Here the > >main operational issue, pointed out by Antonio, is that you need to have a > >way for the initiator to signal that he is requiring legacy > >authentication. > > > >So all we need is some feedback on the above operational issues, and then > >make a definitive decision about the right design/privacy trade-off. > >It should not put any delay on the closure of ikev2. > > The working group co-chairs in combination with the document editor need to > make a decision concerning the magnitude of the changes. If it is the > least bit onerous, then this should not be done. It is not a requirement, > and we are already overdue on delivery. > > It is time to warp this effort up. Fix anything that fails to meet the > requirements that have already been set by the working group. then make the > document internally consistent. Additional stuff can be dealt with by a > subsequent working group. > > Ted got it right at the beginning of the meeting. He said, "It is time to > shoot the engineers and ship the product." > > Russ > > From owner-ipsec@lists.tislabs.com Fri Mar 21 03:15:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LBFAg11852; Fri, 21 Mar 2003 03:15:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26179 Fri, 21 Mar 2003 05:47:04 -0500 (EST) Message-ID: <3E7AEF07.9000307@cefriel.it> Date: Fri, 21 Mar 2003 11:52:55 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: "''IPsec WG ' '" Subject: Re: RE2: Do ipsec vendors care about privacy? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2003 10:52:28.0890 (UTC) FILETIME=[F75C0BA0:01C2EF97] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: [SNIP] > The question is: DOES THE RESPONDER (GATEWAY) NEED TO KNOW the value IDi IN ORDER TO DETERMINE THE CONTENTS OF THE EAP PAYLOAD SENT IN MESSAGE 4? I think that only EAP people can give use the right response. I've just sent an e-mail to the eap WG asking about this problem, I hope they will give us feed-back as soon as possible. In line a brief of the mail I sent to eap wg 2 minutes ago : >>Does the autheticator need to know the peer's identity before sending >>an EAP(Request,MD5)? Or we can send that EAP message without knowing >>the initiator identity? Is it possible a scenario like this? >> >> Peer Authenticator >> ------ --------------- >> <-- EAP(Request,MD5) >> >> IDi, EAP(Response,MD5) --> >> >> <-- EAP(Success/Failure) [SNIP] -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Fri Mar 21 03:20:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LBKVg12119; Fri, 21 Mar 2003 03:20:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26191 Fri, 21 Mar 2003 05:55:05 -0500 (EST) Message-ID: <3E7AF0FA.8050707@cefriel.it> Date: Fri, 21 Mar 2003 12:01:14 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: "''IPsec WG ' '" Subject: Re: RE2: Do ipsec vendors care about privacy? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2003 11:00:47.0468 (UTC) FILETIME=[208902C0:01C2EF99] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [SNIP] I've just received feed-back from an EAP people: [COPY&PASTE BEGIN] For MD5-challenge, it's possible if the identity is passed together with the response/md5 (inside the encapsulating RADIUS message for instance) or is determined from the response-message itself (source-ip-address, caller-id, whatever, ...). Or if you would use always the same identity somehow. All that the MD5-response proves, is that the peer is in possesion of the correct secret for that identity (user-password for instance), so you can calculate the correct response. The Authenticator would have to check that, and needs an identity, but it doesn't matter when it's passed to the authenticator. Other authentication-mehtods might be different though. -- Jo Hermans [COPY&PASTE END] With CHAP (Or MD5-CHALLENGE) Hugo's proposal will work, however with OTP and maybe with GTC I think that the responder needs to know the Iniziator ID prior to send the OTP challenge. -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Fri Mar 21 03:29:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LBTBg12722; Fri, 21 Mar 2003 03:29:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26220 Fri, 21 Mar 2003 06:06:08 -0500 (EST) Message-ID: <3E7AF397.10205@cefriel.it> Date: Fri, 21 Mar 2003 12:12:23 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2003 11:11:56.0509 (UTC) FILETIME=[AF5090D0:01C2EF9A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > A couple of messages in this thread remind us that the WG decided > that protecting the responder's identity from active attacks is preferable > to protecting I's identity from such attacks. That's true, and I do NOT > suggest to change that decision in the general case. One issue, I think, we have to consider is that when we are using EAP authentication we are no longer protecting IDr. Even if in a previous message I state that it is not so crucial, i think that we can do something to ensure a grade of protection on IDr at no cost. What I was thinking about is: Supposing that the responder can send EAP(Request,MD5) (for exaple) without knowing IDi. In that case to ensure a grade of protection on IDr we can force the use of IDr in message 3. If the iniziator doesn't know one of the IDr she cannot procede, and the responder will not expose his ID: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {[CERTREQ,] IDr, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } ... ... As you can see Alice *MUST* use IDr, otherwise Bob will send her a Type 7 NOTIFY MESSAGES (INVALID-SYNTAX). What do the others think about? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Fri Mar 21 03:49:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LBncg13225; Fri, 21 Mar 2003 03:49:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26274 Fri, 21 Mar 2003 06:24:12 -0500 (EST) Message-ID: <3E7AF7E9.3030205@cefriel.it> Date: Fri, 21 Mar 2003 12:30:49 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: "'IPsec WG'" Subject: Re: Secure remote access with IPsec References: <200303200011.h2K0Boof058212@givry.rennes.enst-bretagne.fr> In-Reply-To: <200303200011.h2K0Boof058212@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2003 11:30:22.0848 (UTC) FILETIME=[42BE8000:01C2EF9D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > => research is not 100% paperwork... You are right, however, if there are any other problems, directions or open issues about remote access, I think it will be usefull study them. > => EAP is the PPP generic authentication. You can put what you'd like > in EAP. Agreed. [SNIP] > => if it seems useful to permit this (IMHO it will be the case) then > NAT-T support will get a MUST. The reason why nat-t draft and than IKEv2 draft switch the communication to port 4500 if a NAT is detected there is a NAT-T helper fuction which does nottraslate UDP500 and that is implemented in a lot of NA(P)T. So what's wrong to let IKev2 directly speak on port 4500 instead of 500? If we let IKEv2 speak on port 500 and then switch to port 4500 if nat is detected we should have collision problem during IKE_SA_INIT. > => it seems you read my drafts! Of course! :-) > => we cannot change the selectors of a SA without rekeying. And we shan't > change a traffic selector of a tunnel without rekeying. Why not? What's wrong with changing the selectors? [from draft-ietf-mobileip-mipv6-ha-ipsec-03.txt] Step 9. If the mobile node and the HA have the capability to change the IKE endpoints, they change the address to C. If they dont have the capability, both nodes remove their phase 1 connections created on top of the care-of address B and establish a new IKE phase 1 on top of the care-of address C. This capability to change the IKE phase 1 end points is indicated through setting the Key Management Mobility Capability (K) flag [8] in the Binding Update and Binding Acknowledgement messages. -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Fri Mar 21 07:44:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LFi2g00703; Fri, 21 Mar 2003 07:44:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26669 Fri, 21 Mar 2003 10:09:58 -0500 (EST) Date: Fri, 21 Mar 2003 07:12:40 -0800 Subject: Re: Do ipsec vendors care about privacy? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: IPsec WG To: Hugo Krawczyk From: Derrell Piper In-Reply-To: Message-Id: <8EE9A55D-5BAF-11D7-AB86-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, I continue to agree with this sentiment. I think it's important to protect IDi for remote client access. I prefer the second choice outlined: having the responder authenticate itself in message 2. I do not think this change is too radical to adopt at this late time. It just needs some tender loving consensus. Derrell On Thursday, March 20, 2003, at 11:10 PM, Hugo Krawczyk wrote: > I agree: no time for major surgery on the document. > But not too late for a change that takes 1-5 minutes editorial work > On the other hand, I admit that there are some operational issues > that are not fully resolved in my proposals and need more input from > people that care and know better. If this does not come on time > to make the document before being closed then we will not have it. > > On the other hand, user's id protection in the remote access protocol > of > ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec > developers (on the list and outside the list). So giving the > opprtunity to > this substantial improvement if it comes at little cost and on time is > a > reasonable thing to do. > > In any case, ,I raised the issue and two possible solutions, but I am > not > the one that needs to decide if the WG is to adopt this or not. THOSE > THAT > CARE (in one way or another) SHOULD SPEAK UP. > > If there is not enough interest, then nothing needs to be done. > At least it will be documented that this was a conscious decision > rather > than an overlook or the result of simple rushing. > (This will help against future criticizers of the protocol that wil > raise these issues in their papers...) > > I will be glad to see some technical discussion in the coming days > if people care about having such discussions. Beyond that I am not > going > to insist (this is not an area of "correct cryptographic design" for > which I personally care but rather one of engineering trade-offs that > other understand better than me). From owner-ipsec@lists.tislabs.com Fri Mar 21 08:04:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LG4Qg01321; Fri, 21 Mar 2003 08:04:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26711 Fri, 21 Mar 2003 10:32:12 -0500 (EST) Message-ID: <3E7A5234.5020504@bell-labs.com> Disposition-Notification-To: Uri Blumenthal Date: Thu, 20 Mar 2003 18:43:48 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: IPsec WG Subject: AES-based PRF for IKEv2 Content-Type: multipart/mixed; boundary="------------030505020500040401000302" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------030505020500040401000302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Folks, Here's a proposal for an AES-based PRF that takes variable-length input and produces variable-length output. Please comment. Thank you! Regards, Uri. --------------030505020500040401000302 Content-Type: text/plain; name="aes-prf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="aes-prf.txt" PROPOSAL: AES-BASED PRF FOR IKEv2. The goal is to produce requested amount of pseudo random bits, using AES (or other block cipher) and variable-length input for both secret parameter, and publicly known parameter. Should work with variable key length, preferably support different block sizes. Preferably, the construct is provably secure. The following idea is based on Rijndael submission to NIST. It is assumed that AES is the block cipher that will be used, but the construct is generic enough to accomodate other block ciphers. PRF(S, N) ALGORITHM. Two parameters - one is secret, the other one may be known. No assumption on the quality of randomness of either one is made. Assume that S is secret and N is known. No limitation on size of S, N. Outputs pseudo-random stream of bits in 128-bit chunks (variable-length output). Block cipher is assumed, with key-buffer for key, and data-buffer for plaintext. AES is assumed, but any other un-broken blok cipher should do. Algorithm: 1. Fill the key-buffer with S. If S is shorter than the key-buffer, pad the key buffer with zeroes. 2. If any bits of S are left after step (1), place them in the data-buffer. Append parameter N to the data-buffer. Pad the data-buffer with zeroes if necessary, to make it multiple of cipher block size, and at least as long as key-buffer. 3. Encrypt as many blocks of data-buffer as necessary to fill key-buffer. 4. Take the output of (3) and fill the key-buffer. Continue (3) and (4) for the reminder of the data-buffer. 5. At this point the encryption engine is ready to produce Pseudo-Random stream. Now run the encryption engine in OFB mode (starting with input buffer filled with zeroes) using the full block size, until the desired amount of output bits is produced. RATIONALE. a. All the theory of block cipher security is based on the assumption that the key is unknown to the attacker. Thus we key the encryption engine with the secret parameter. b. It is preferred to move away from the given secret parameter (which is likely to be Diffie-Hellman output). That is why at least one key change is performed. c. Variable-length input and output is desirable - this is accomplished. SECURITY PROPERTIES. A block cipher being a Pseudo Random Permutation, if the S parameter is secret, the following hold true: - output of (3) is pseudo-random. - output of (5) is pseudo-random. --------------030505020500040401000302-- From owner-ipsec@lists.tislabs.com Fri Mar 21 10:16:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LIGfg06349; Fri, 21 Mar 2003 10:16:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27140 Fri, 21 Mar 2003 12:45:45 -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-based PRF for IKEv2 Date: 21 Mar 2003 17:24:18 GMT Organization: University of California, Berkeley Lines: 35 Distribution: isaac Message-ID: References: <3E7A5234.5020504@bell-labs.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1048267458 25053 128.32.153.211 (21 Mar 2003 17:24:18 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 21 Mar 2003 17:24:18 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 Uri Blumenthal wrote: >Here's a proposal for an AES-based PRF that takes variable-length >input and produces variable-length output. [...] >Two parameters - one is secret, the other one may be >known. No assumption on the quality of randomness of >either one is made. Assume that S is secret and N is >known. No limitation on size of S, N. [...] > 1. Fill the key-buffer with S. If S is shorter than > the key-buffer, pad the key buffer with zeroes. [...] >A block cipher being a Pseudo Random Permutation, if the >S parameter is secret, the following hold true: > > - output of (3) is pseudo-random. > - output of (5) is pseudo-random. I don't think your security claims are quite right. You've padded the key with zeros. As a result, you need a stronger assumption than that the block cipher is a pseudorandom permutation. A pseudorandom permutation only guarantees that the cipher is strong for uniformly random keys, not for keys padded with zeros and not for keys with poor-quality randomness. For instance, suppose E_k(x) is a block cipher with 256-bit key that acts as the identity function when the last 128 bits of k are zero, but otherwise acts as a secure block cipher. Then E_k(x) will be a pseudorandom permutation (with security parameter 2^-128), but your construction will be totally insecure when used with E_.(.) if S is 128 bits long (or shorter). Given your assumptions on S and N, I suspect you're really going to need to use a hash function. (Otherwise, you'll have to use some very strong assumptions about the block cipher -- e.g., the ideal cipher model -- but I definitely do not recommend doing so.) From owner-ipsec@lists.tislabs.com Fri Mar 21 10:16:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LIGig06361; Fri, 21 Mar 2003 10:16:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27171 Fri, 21 Mar 2003 12:49:46 -0500 (EST) Message-Id: <200303211753.h2LHrBof064434@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Antonio Forzieri cc: "'IPsec WG'" Subject: Re: Secure remote access with IPsec In-reply-to: Your message of Fri, 21 Mar 2003 12:30:49 +0100. <3E7AF7E9.3030205@cefriel.it> Date: Fri, 21 Mar 2003 18:53:11 +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: > => if it seems useful to permit this (IMHO it will be the case) then > NAT-T support will get a MUST. The reason why nat-t draft and than IKEv2 draft switch the communication to port 4500 if a NAT is detected there is a NAT-T helper fuction which does nottraslate UDP500 and that is implemented in a lot of NA(P)T. So what's wrong to let IKev2 directly speak on port 4500 instead of 500? => nothing but the current draft wording suggests that IKE_SA_INIT always runs over UDP 500. This should be fixed. If we let IKEv2 speak on port 500 and then switch to port 4500 if nat is detected we should have collision problem during IKE_SA_INIT. => there is no collision problem with the same initiator, and collisions where both sides are initiators are already handled by the rekeying stuff (both in the draft and in this list). > => we cannot change the selectors of a SA without rekeying. And we shan't > change a traffic selector of a tunnel without rekeying. Why not? What's wrong with changing the selectors? => the term selector is not very accurate. You can't change the traffic selectors but you can change the endpoints (i.e., the peer addresses) with a peer address update mechanism. [from draft-ietf-mobileip-mipv6-ha-ipsec-03.txt] Step 9. If the mobile node and the HA have the capability to change the IKE endpoints, they change the address to C. If they dont have the capability, both nodes remove their phase 1 connections created on top of the care-of address B and establish a new IKE phase 1 on top of the care-of address C. => this text applies only to IKEv1. In IKEv2 one should use the rekeying mechanism for the IKE SA, both because it is available and because in IKEv2 when an IKE SA is closed all the IPsec SAs it negociated are closed. This capability to change the IKE phase 1 end points is indicated through setting the Key Management Mobility Capability (K) flag [8] in the Binding Update and Binding Acknowledgement messages. => this is about peer address update mechanisms, in IKEv2 you'll get: - an implicit mechanism with NAT Traversal for peers which have the other peer behind a NAT. - an explicit mechanism defined after the urgent publication of the IKEv2 document. - a programmatic stuff which provides the peer address update itself for a set of SAs (an IKE SA and some IPsec SA pairs). It will be used of course by IKEv2 but I've suggested to make it available from the outside of the IKEv2 process(es). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Mar 21 11:01:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LJ1Ag08647; Fri, 21 Mar 2003 11:01:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27368 Fri, 21 Mar 2003 13:32:21 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15995.23453.745014.962250@tero.kivinen.iki.fi> Date: Sat, 22 Mar 2003 02:36:13 +0800 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: Yoav Nir Subject: Re: IKEv2: prepending four octets References: <3E798E13.5060307@roc.co.in> X-Mailer: VM 7.04 under Emacs 20.7.1 X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ravivsn@roc.co.in (Ravi) writes: > So, we will not disturb these NAT devices to work on port 500 > Since, IKEv2 is now building from scratch we shall standardise Port 4500 > instead of 500.The non Zero in first > four bytes indicates IPsec packets and Zeros indicate IKE packets. The problem with that is that it causes long timeout during the transition period, i.e if initiator supports both IKEv1 and IKEv2, it would start with IKEv2 to port 4500. The responder which only supports IKEv1, would not even see those packets, and the initiator would have to wait for the timeout (tens of seconds or even few minutes?) before falling back to IKEv1 and port 500. If the initiator starts with port 500 (with IKEv2 protocol) then the IKEv1 implement will see the packet, and hopefully it will send back notification INVALID-MAJOR-VERSION. There will be implementations out there that will not send that notification back, but for those who did this properly and will send the notification, can get rid of the extra timeout. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Mar 21 11:14:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LJE5g10487; Fri, 21 Mar 2003 11:14:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27438 Fri, 21 Mar 2003 13:43:31 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15995.24084.598193.997771@tero.kivinen.iki.fi> Date: Sat, 22 Mar 2003 02:46:44 +0800 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: Gregory Lebovitz , hugo@ee.technion.ac.il Subject: Re: RE2: Do ipsec vendors care about privacy? References: X-Mailer: VM 7.04 under Emacs 20.7.1 X-Edit-Time: 4 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hugo@ee.technion.ac.il (Hugo Krawczyk) writes: > The question is: DOES THE RESPONDER (GATEWAY) NEED TO KNOW the value IDi > IN ORDER TO DETERMINE THE CONTENTS OF THE EAP PAYLOAD SENT IN MESSAGE 4? If the responder cannot even do the policy lookup based on the identity? If have correctly understood the EAP, then it can support multiple authentication methods, i.e for example say that user "kivinen" the authentication method used is one-time password and for the user "hugo" the authentication method used is the generic token card. Now when the responder only knows that it is someone connecting who want to do EAP, how does he know which of those EAP authentication types it should start? Note, that in EAP there is also way to transport the identity inside EAP packet, and in that case we do no need the external identity. In the IKEv2 the EAP specification is trying to get rid of that exchange, because it adds one more round trip and because we already have the identity of the initiator (in the IDi payload). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Mar 21 11:48:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LJmXg12936; Fri, 21 Mar 2003 11:48:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27563 Fri, 21 Mar 2003 14:13:54 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15995.25907.497444.196791@tero.kivinen.iki.fi> Date: Sat, 22 Mar 2003 03:17:07 +0800 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: antonio.forzieri@cefriel.it (Antonio Forzieri) Subject: Re: Secure remote access with IPsec References: <3E7881C1.1050507@cefriel.it> X-Mailer: VM 7.04 under Emacs 20.7.1 X-Edit-Time: 15 min X-Total-Time: 19 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk antonio.forzieri@cefriel.it (Antonio Forzieri) writes: > - NAT-T capability are enabled in IKEv2, and I think it works well (what > about let IKE speaks on UDP 4500 directly even when there isn't NAT-T > function enabled? What's wrog with that?). I know the pseudo-NAT > problem, however I think that an attacker on the path could easily > delete all the message. The current IKEv1 NAT-T requires that implementations MUST be able to handle initial connections coming to port 4500. I think this should be taken to IKEv2 also. > - IPsec is well integrated with MIPv6 > [draft-ietf-mobileip-mipv6-ha-ipsec-03.txt], so we can think of a mobile > node connecting back to his Corporate Network, without need rekeying > when it changes his address (can we change the selectors of a SA or an > entry of the SPD upon the receiving of a BU message?) I was talking with Jari Arkko about this last night, and I came up with following proposal: ---------------------------------------------------------------------- 2.25 Explicit Address Updating For some cases there are needed for explicitly update the peer address. This can be used to support mobile-ip, multihoming, and to help SCTP support. The difference with implicit address updating, is that in this case the other end can actually notify the other end about the change in the address, and authenticate the new address (and port). The explicit address update is done by sending SOURCE-ADDRESS-CHANGED notification, having new port and ip-address inside, to the other end. This notification can be send either using the old or new address, but the sender MUST be able receive in the new address before sending this out. When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process MUST check that the other end can receive the packets sent to new address, by sending empty notification to the peer addres and port given inside the notification (not the UDP outer address). When the host requesting the change replies to that notification, and proofs that it can actually receive packets sent to that address the actual change should take effect. This change affects the IKE SA used to receive the notification (i.e all future exchanges started on that IKE SA will use this new address) and all child IPsec SAs created by this IKE SA (i.e tunnel endpoint updated to new address). The reply to the original SOURCE-ADDRESS-CHANGED notification is sent back to the address where it was received, as is also all other requests, where reply is not yet sent (i.e they follow normal rule, that the reply is sent back to the address where the packet originated). Note, that all hosts are required to process this notification while waiting for reply to their SOURCE-ADDRESS-CHANGED notification (see section 2.3). This requires implementations to support mutating the already existing SAs (one way to implement this is to atomically delete the SA and then add it back with new information). Similar feature is also needed for the implicit address updating needed for NAT traversal, where we need to update the UDP encapsulation addresses and ports. ---------------------------------------------------------------------- Following text should be added to section 3.10.1 after HTTP-CERT-LOOKUP-SUPPORTED: ---------------------------------------------------------------------- SOURCE-ADDRESS-CHANGED 24587 This notification is sent when the other end has changed its IP-address and wants the responder of this notification to update the IKE SA remote peer address and port. When this notification is received the host MUST do the dead peer detection against the address given in this payload, and if that is successful then the IKE SA peer address and all the child SA tunnel endpoint addresses MUST be updated to new address. This notification is not used in the NAT traversal case, as the host behind NAT does not know when its address changes. The data associated with this notification is 2 byte port number and 4 or 16 byte IP-address. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Mar 21 14:47:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LMlug19091; Fri, 21 Mar 2003 14:47:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28056 Fri, 21 Mar 2003 17:16:38 -0500 (EST) Date: Sat, 22 Mar 2003 00:20:01 +0200 (IST) From: Hugo Krawczyk To: Tero Kivinen cc: ipsec@lists.tislabs.com, Russ Housley Subject: Re: Do ipsec vendors care about privacy? In-Reply-To: <15995.22986.196922.999406@tero.kivinen.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, it seems to me that your presentation of issues below provides a sense of complexity and cost well beyond what is really involved in these solutions. Yet, the issues you raise are valid concerns and they will help deciding whether protecting user's identity in IKEv2's EAP methods is worth the pain or not. I will re-write your concerns, and analyze their effect (editorial, security and implementation). I cannot qualify this as MAJOR SURGERY. Let me know what I am missing. To avoid an even longer message I will focus here in the solution in which the server authenticates using its signature in message 2 (which at this point seems to me as the preferred alternative). To make this self-contained recall that this solution calls for: (1) adding to message 1 an indication that the initiator asks to use an EAP-based exchange. It seems to me that the best way to do it is by means of a new exchange type. If there is any problem with this then you can add such an indication to the SA payload. (2) moving IDr, [CERT,] AUTH from msg 4 to msg 2. Namely, message 2 from R to I (in section 2.16) will look as: <-- HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH and message 4 will simply be: <-- HDR, SK {EAP} Now to your objections as they apply to this solution. > > - This open one more DoS attack. The responder must sign the > auth message before it actually knows if there is anybody > there on the other end. Currently the resourses used from > the responder for the first packet is very cheap (policy > lookup, take precalculated Diffie-Hellman (or reuse old > one), make some state, and send packet). In this model we > would need to add do RSA/DSA sign operation during that, > which is much more expensive operations than any of the > above. That would most likely mean that the responder would > always require the return routability check before doing > anything, having an effect that we added one more round > trip to the exchange in normal case. I do not agree with this assesment. First there is NO reason to go to the routability check if you are NOT under attack (this is true for the regular protocol, for the current EAP-based protocol, and for the modification I suggest). The question is whether this modification opens a signifcant new DoS opportunity. Not really. Already now the responder needs to compute the DH key (something that CANNOT be done off-line) AND verify I's signature (relatively cheap for RSA and very expensive in the case of DSA) BEFORE it has authenticated the initiator. The fact that this computation cost happens at the reception of message 3 rather than after message 1 (in the modified solution) does not make the attack significantly harder to mount. Certainly not in a way that such attacks were hard to mount (or ineffective) before and are realistic now due to the modified protocol. DoS attacks are possible in all cases and the only mitigation we provide is the optional cookie in message 2. (This option remains unchanged in the suggested solution.) BTW, I do not envision EVERY ikev2 machine to be configured to run the EAP variant of ikev2 (section 2.16) but only those machines acting as gateway/servers for support of remote access users. Thus for most machines all this issue is irrelevant. > > - Also the generation of the signature is little bit harder, > as we are signing the packet we are also adding the > signature to. Indeed a litttle bit harder. Still nothing major. A possible specification using the current text would say something like: Payloads SAr1 and KEr are included as the first and second payload in message 2 (immediately after HDR), and the responder signs the octets starting with the first octet of the first SPI in the header of the second message and end with the last octet of the KEr payload in the second message. Appended to this (for purposes of computing the signature) is the initiator's nonce Ni (just the value, not the payload containing it) and the value prf(SK_ar, IDr). [Note: the last sentence is modified from ikev2-05 but this is pending revision by Charlie anyway] > > - Also in that case we loose the "You Tarzan, Me Jane" for > those cases, because the responder needs to sign the > identity it is using in the packet 2, and the initiator is > sending the preferred ID to be used in packet 3. Right. The good news however is that when Jane is in the road she does not have to reveal her name before she really knows she is talking to Tarzan. (something like "You Tarzan? Me wonder...") It's all about tradeoffs and here I see privacy as the winner. Don't you? > > - Then again, how does the server know when to do this, > because it hasn't yet seen that the other end wants to do > EAP. So we either need to add it to the SA payloads, or do > it always. As said above the Exchange Type can indicate that (or some other bit/octet in SAi) > - The text currently says that if the EAP method creates > shared key it MUST be used to generate the AUTH payloads > using the shared secret method by both ends. If we move the > AUTH payload to point before the EAP finishes (or actually > before it starts), then we have to change this. I do not > know the actual effects of this change. There is no change here. This SECOND AUTH (with the EAP-derived key) by the responder (its definition and position in the protocol) are not affected by the changes I suggested. > > - All of these cases makes it easy to make polling attack, i.e > I start process in the IETF and start IKE negotiation > against each IP address. The responder will be very helpfull > and send me proof who they actually are. Currently there is > no way to get that information, I only can get the IP > address, I do not know to whom which ip address is assigned > to. Remember that IPsec is actually symmetric, thus the > original initiator can be responder later. As I said, I do not suggest that every ipsec machine is configured as a server (i.e. responder) for the sake of running IKEv2's EAP support protocol. Support for this method should be allowed only on gateways (or machines) running as EAP servers (or relays). Thus only such gateways will be open to polling attacks. However, in this case we do not care about these attacks as we assume the gateway's id to be public (we do not even encrypt it in message 2). If you disagree with these views please let us know. This is an important exercise. It is needed to decide where we establish the trade-offs. I agree with two basic rules: do not mess with the non-EAP portions of ikev2 and do not delay finalization of ikev2 as a whole. Beyond that, I suggest that we consider user's privacy as a REAL issue in remote access scenatios and be prepared, if needed, to pay some moderate price for its inclusion. Hugo From owner-ipsec@lists.tislabs.com Fri Mar 21 15:34:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LNYOg23339; Fri, 21 Mar 2003 15:34:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28202 Fri, 21 Mar 2003 18:07:07 -0500 (EST) Date: Sat, 22 Mar 2003 01:10:55 +0200 (IST) From: Hugo Krawczyk To: Uri Blumenthal cc: IPsec WG Subject: Re: AES-based PRF for IKEv2 In-Reply-To: <3E7A5234.5020504@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > SECURITY PROPERTIES. > > A block cipher being a Pseudo Random Permutation, if the > S parameter is secret, the following hold true: > > - output of (3) is pseudo-random. > - output of (5) is pseudo-random. > Unfortunately, this is incorrect. If all what you assume about the block cipher is that it is a pseudorandom permutation then to be able to get a result as you state you need to assume that all the values used to key the block cipher are random (or pseudo-random, in the complexity-theoretic sense). That means that you need to assume S to be secret (as you do) but also random (that you don't do) and of at least the length of the cipher's keys (what you don't do either). Therefore the stated security properties do not provably hold. Specifically one can build examples of perfectly secure pseudorandom permutations that will induce insecure outputs from (3) and (5). This was pointed out by Dave Wagner for the case in which S is too short, and one can also give examples in which S is longer than the key (but not uniformly distributed). Now, clearly, if you assume that the given value S is already a good random key for the prf then you do not need all the construction. Finally, regarding the use of this method with a DH key S=g^{xy} as you suggest. In this case you'd take the first, say, 128 bits of g^{xy} as the key to the block cipher and the rest as data. Under which assumptions on DH and the block cipher you can claim the proposed key derivation to be secure? Note that the attacker knows g^x,g^y. Hugo From owner-ipsec@lists.tislabs.com Fri Mar 21 15:44:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LNiJg23653; Fri, 21 Mar 2003 15:44:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28270 Fri, 21 Mar 2003 18:16:22 -0500 (EST) Date: Sat, 22 Mar 2003 01:19:20 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: Use of AES as prf 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 Charlie, instead of stating that "if either nonce is shorter than half the fixed length key that it be padded with zero bits." why not state that nonces MUST be at least of half the length of the prf key? This is not an onerous requirement and avoids accepting as "legal" the bad practice of padding a short cryptographic key with 0s. In a related issue, I'd also require the pre-shared key, Shared Secret, to be (at least) of the length of the prf key (again to avoid padding with zeros). Hugo On Tue, 18 Mar 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > Having seen the alternatives, I withdraw my earlier objection to Hugo's > proposal for dealing with prf functions with fixed length keys. His > recommendation was that if the prf takes a fixed length key, we take the > first bits of the initiator's nonce as the first half and the first bits of > the responder's nonce as the second half. Not part of his suggestion, but > to make the proposal fully specified in all cases, I'd add that if either > nonce is shorter than half the fixed length key that it be padded with zero > bits. > > Does anyone object? > > --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@lists.tislabs.com Sat Mar 22 10:27:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2MIQxg00540; Sat, 22 Mar 2003 10:26:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00651 Sat, 22 Mar 2003 12:50:43 -0500 (EST) Message-Id: <200303221754.h2MHsfof069159@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, antonio.forzieri@cefriel.it (Antonio Forzieri) Subject: Re: Secure remote access with IPsec In-reply-to: Your message of Sat, 22 Mar 2003 03:17:07 +0800. <15995.25907.497444.196791@tero.kivinen.iki.fi> Date: Sat, 22 Mar 2003 18:54:41 +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 was talking with Jari Arkko about this last night, and I came up with following proposal: ---------------------------------------------------------------------- 2.25 Explicit Address Updating For some cases there are needed for explicitly update the peer address. This can be used to support mobile-ip, multihoming, and to help SCTP support. The difference with implicit address updating, is that in this case the other end can actually notify the other end about the change in the address, and authenticate the new address (and port). => note that when NAT-T is not activated we need an explicit protection of the peer addresses (notifications like NAT-DETECTION-*-IP carrying the full address and port) so the only guy who can put fake new addresses is the peer. The explicit address update is done by sending SOURCE-ADDRESS-CHANGED notification, having new port and ip-address inside, to the other end. => so new port and address don't need to be inside the notification because they are inside the (protected) message. This notification can be send either using the old or new address, but the sender MUST be able receive in the new address before sending this out. => I disagree: there is no problem to require they are sent using the new address. When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process MUST check that the other end can receive the packets sent to new address, by sending empty notification to the peer addres and port given inside the notification (not the UDP outer address). => I disagree: this return routability check should not be mandatory, i.e., one MAY trust its peer. But IMHO it should be explained (as it adds in fact nothing in the protocol it is free) and a config knob should enable it. We have to provide the default value for this knob, I am in favor of ON, i.e., perform the check by default. When the host requesting the change replies to that notification, and proofs that it can actually receive packets sent to that address the actual change should take effect. => fine This change affects the IKE SA used to receive the notification (i.e all future exchanges started on that IKE SA will use this new address) and all child IPsec SAs created by this IKE SA (i.e tunnel endpoint updated to new address). => I disagree: we need more fine grain stuff for multi-homing. What I propose is to put the list of affected SAs in the notification with an "all SAs" flag which does exactly what you describe with a restriction for proxy case SAs which must be never affected. The reply to the original SOURCE-ADDRESS-CHANGED notification is sent back to the address where it was received, as is also all other requests, where reply is not yet sent (i.e they follow normal rule, that the reply is sent back to the address where the packet originated). Note, that all hosts are required to process this notification while waiting for reply to their SOURCE-ADDRESS-CHANGED notification (see section 2.3). => is this text really useful? This requires implementations to support mutating the already existing SAs (one way to implement this is to atomically delete the SA and then add it back with new information). Similar feature is also needed for the implicit address updating needed for NAT traversal, where we need to update the UDP encapsulation addresses and ports. => agreed. IMHO this feature should be accessible from the outside of the IKE implementation too. ---------------------------------------------------------------------- Following text should be added to section 3.10.1 after HTTP-CERT-LOOKUP-SUPPORTED: ---------------------------------------------------------------------- SOURCE-ADDRESS-CHANGED 24587 This notification is not used in the NAT traversal case, as the host behind NAT does not know when its address changes. => with the mandatory peer address protection when NAT-T is not activated this statement is no more useful (because NAT-T and peer address protection are exclusive and one of them is mandatory after the IKE_SA_INIT exchange). I'll update my address management proposal (remove all the NAT-T stuff and adopt a NAT-T vs. other case style) but IMHO we should put our efforts on the things to clarify in the current draft, i.e., everything about NAT-T & address management at the exclusion of the explicit mechanism itself. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sat Mar 22 10:27:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2MIR1g00552; Sat, 22 Mar 2003 10:27:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00657 Sat, 22 Mar 2003 12:52:42 -0500 (EST) Message-Id: <200303221756.h2MHujof069171@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, antonio.forzieri@cefriel.it (Antonio Forzieri) Subject: Re: Secure remote access with IPsec In-reply-to: Your message of Sat, 22 Mar 2003 03:17:07 +0800. <15995.25907.497444.196791@tero.kivinen.iki.fi> Date: Sat, 22 Mar 2003 18:56: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: SOURCE-ADDRESS-CHANGED 24587 This notification is sent when the other end has changed => A question "en passant": is a payload more appropriate? (I can't find a rationale about payload vs. notification, the only argument is payloads can be made critical...) Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Mar 23 00:43:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2N8hag11464; Sun, 23 Mar 2003 00:43:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02118 Sun, 23 Mar 2003 03:07:48 -0500 (EST) From: "Yoav Nir" To: "'Antonio Forzieri'" , "''IPsec WG ' '" Subject: RE: RE2: Do ipsec vendors care about privacy? Date: Sun, 23 Mar 2003 10:10:53 +0200 Message-ID: <005b01c2f113$b9b2a340$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E7AF0FA.8050707@cefriel.it> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With GTC, the challenge is a string like "Enter your password" and the response is also a string. I think this is more useful than the other methods for passing user/password from the client to the gateway. With MD5-Challenge, the authenticator needs to issue the challenge. You may have some problems integrating it with various authentication servers. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Antonio Forzieri Sent: Friday, March 21, 2003 1:01 PM To: ''IPsec WG ' ' Subject: Re: RE2: Do ipsec vendors care about privacy? [SNIP] With CHAP (Or MD5-CHALLENGE) Hugo's proposal will work, however with OTP and maybe with GTC I think that the responder needs to know the Iniziator ID prior to send the OTP challenge. -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Sun Mar 23 01:12:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2N9CKg14112; Sun, 23 Mar 2003 01:12:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02263 Sun, 23 Mar 2003 03:45:03 -0500 (EST) From: "Yoav Nir" To: "'Antonio Forzieri'" , Subject: RE: Do ipsec vendors care about privacy? Date: Sun, 23 Mar 2003 10:48:55 +0200 Message-ID: <005c01c2f119$0a3d4860$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E7AF397.10205@cefriel.it> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I like that. If the client contacts the server and is able to produce a full ID_DER_ASN1_DN then we know it is not just a polling attack. But what if the client presents a ID_IPV4_ADDR? The IDr payload in message 3 was not intended to be used as a security measure. It was intended as a hint to the gateway as to which identity it should authenticate. I think that if we accept this idea, we need to be able to limit what IDr is acceptable to the gateway in message 3. This would require a new notification type, something like the following: INVALID-RESPONTER-ID 37 Indicates that the initiator has sent an unacceptable responder ID as part of the initial negotiation. This only causes an error if the initiator has not sent its own ID. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Antonio Forzieri Sent: Friday, March 21, 2003 1:12 PM To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? [SNIP] What I was thinking about is: Supposing that the responder can send EAP(Request,MD5) (for exaple) without knowing IDi. In that case to ensure a grade of protection on IDr we can force the use of IDr in message 3. If the iniziator doesn't know one of the IDr she cannot procede, and the responder will not expose his ID: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {[CERTREQ,] IDr, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } ... ... As you can see Alice *MUST* use IDr, otherwise Bob will send her a Type 7 NOTIFY MESSAGES (INVALID-SYNTAX). What do the others think about? From owner-ipsec@lists.tislabs.com Sun Mar 23 10:05:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NI5Jg22123; Sun, 23 Mar 2003 10:05:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03103 Sun, 23 Mar 2003 12:28:34 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15997.61320.38373.418691@fireball.acr.fi> Date: Sun, 23 Mar 2003 19:31:52 +0200 From: Tero Kivinen To: Hugo Krawczyk Cc: ipsec@lists.tislabs.com, Russ Housley Subject: Re: Do ipsec vendors care about privacy? In-Reply-To: References: <15995.22986.196922.999406@tero.kivinen.iki.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 24 min X-Total-Time: 24 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > (2) moving IDr, [CERT,] AUTH from msg 4 to msg 2. > Namely, message 2 from R to I (in section 2.16) will look as: > <-- HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH > and message 4 will simply be: > <-- HDR, SK {EAP} This will open the responders attack to polling attack. > First there is NO reason to go to the routability check if you are NOT under > attack (this is true for the regular protocol, for the current EAP-based > protocol, and for the modification I suggest). Some vendors refused to implement or use the aggressive mode of the IKEv1, just because of it required you to do expensive operations without ever knowing if there is anybody here. I would still guess, that most implementations would require the return routability check every time if this kind of protocol is used (at least I would in my implementation). > The question is whether this modification opens a signifcant new DoS > opportunity. Not really. > Already now the responder needs to compute the DH key (something that CANNOT > be done off-line) AND verify I's signature (relatively cheap for RSA and > very expensive in the case of DSA) BEFORE it has authenticated the initiator. Yes, he needs to do that, but at that point he have seen that the other end can see the packets sent to him, thus it makes spoofed attacks impossible. The real attack is when someone sends lots of spoofed packets each having fake IP address (so you cannot use IP address to filter them out) and something that causes you to do work. The current protocol do not allow that. > The fact that this computation cost happens at the reception of message 3 > rather than after message 1 (in the modified solution) does not make the > attack significantly harder to mount. It makes huge difference. So big, that I guess that most of the implementations will still want to make it message 3, i.e they will do the cookie exchange before allowing any of those operations. > > - Also the generation of the signature is little bit harder, > > as we are signing the packet we are also adding the > > signature to. > Indeed a litttle bit harder. Still nothing major. > A possible specification using the current text would say something like: > > Payloads SAr1 and KEr are included as the first and second payload in > message 2 (immediately after HDR), and the responder signs the octets > starting with the first octet of the first SPI in the header of > the second message and end with the last octet of the KEr payload in > the second message. Appended to this (for purposes of computing the > signature) is the initiator's nonce Ni (just the value, not the > payload containing it) and the value prf(SK_ar, IDr). > > [Note: the last sentence is modified from ikev2-05 but this is pending > revision by Charlie anyway] There might be other payloads than SAr1, and KEr in that packet, which need to get protection also, so the text needs to be different. I know it, as I wrote the other draft doing about the same thing for IKEv1... I didn't say it is impossble, I said it is little bit harder. I also implemented my draft on IKEv1, and it required again little piece of interesting code. It is not impossible, but it is not trivial either. > > - Also in that case we loose the "You Tarzan, Me Jane" for > > those cases, because the responder needs to sign the > > identity it is using in the packet 2, and the initiator is > > sending the preferred ID to be used in packet 3. > Right. The good news however is that when Jane is in the road she does > not have to reveal her name before she really knows she is talking to > Tarzan. (something like "You Tarzan? Me wonder...") And this means that security gateway does not know which kind authentication it really should be using, if he have multiple identities. > It's all about tradeoffs and here I see privacy as the winner. Don't you? Actually no. I think You Tarzan, Me Jane is important feature for the remote access cases too. Also I think protection against the polling attack is more important than protection against active attack to initiators identity. Also this protection is not available when doing the normal certificate based authentication, nor it is available when doing the shared key authentication, why should it be there for the EAP? > As said above the Exchange Type can indicate that (or some other bit/octet in > SAi) I do not like having more different exchanges, I would really like to keep the one exchange model we currently have. > > - The text currently says that if the EAP method creates > > shared key it MUST be used to generate the AUTH payloads > > using the shared secret method by both ends. If we move the > > AUTH payload to point before the EAP finishes (or actually > > before it starts), then we have to change this. I do not > > know the actual effects of this change. > There is no change here. This SECOND AUTH (with the EAP-derived key) > by the responder (its definition and position in the protocol) are not > affected by the changes I suggested. I didn't notice there was second AUTH before I started looking the EAP stuff more because of the DHCP-over-IKE text. The current document do nee more text about the second auth payload. > If you disagree with these views please let us know. This is an important > exercise. It is needed to decide where we establish the trade-offs. > I agree with two basic rules: do not mess with the non-EAP > portions of ikev2 and do not delay finalization of ikev2 as a whole. > Beyond that, I suggest that we consider user's privacy as a REAL issue in > remote access scenatios and be prepared, if needed, to pay some moderate > price for its inclusion. As an implementator I still think that these changes are not small, and they do add more complexity to the system (as an toolkit vendor we do need to support almost all of the features, so I cannot just ignore this case because it does not concern me :-). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Mar 23 10:29:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NITdg24426; Sun, 23 Mar 2003 10:29:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03210 Sun, 23 Mar 2003 12:59:48 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15997.63148.726669.65209@ryijy.hel.fi.ssh.com> Date: Sun, 23 Mar 2003 20:02:20 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com, antonio.forzieri@cefriel.it (Antonio Forzieri) Subject: Re: Secure remote access with IPsec In-Reply-To: <200303221756.h2MHujof069171@givry.rennes.enst-bretagne.fr> References: <15995.25907.497444.196791@tero.kivinen.iki.fi> <200303221756.h2MHujof069171@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > SOURCE-ADDRESS-CHANGED 24587 > > This notification is sent when the other end has changed > > => A question "en passant": is a payload more appropriate? > (I can't find a rationale about payload vs. notification, the > only argument is payloads can be made critical...) The current draft seems to be using notifications for all this kind of things, so thats why I selected that too. I think notifications are fine in this kind of cases. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Mar 23 10:29:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NITpg24497; Sun, 23 Mar 2003 10:29:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03211 Sun, 23 Mar 2003 12:59:48 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15997.63098.74339.126424@ryijy.hel.fi.ssh.com> Date: Sun, 23 Mar 2003 20:01:30 +0200 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com, antonio.forzieri@cefriel.it (Antonio Forzieri) Subject: Re: Secure remote access with IPsec In-Reply-To: <200303221754.h2MHsfof069159@givry.rennes.enst-bretagne.fr> References: <15995.25907.497444.196791@tero.kivinen.iki.fi> <200303221754.h2MHsfof069159@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 20 min X-Total-Time: 19 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => note that when NAT-T is not activated we need an explicit protection > of the peer addresses (notifications like NAT-DETECTION-*-IP carrying > the full address and port) so the only guy who can put fake new addresses > is the peer. Yep, that is the reason for the SOURCE-ADDRESS-CHANGED notification (i.e it says the address have changed, and the new ones are here). > The explicit address update is done by sending > SOURCE-ADDRESS-CHANGED notification, having new port and ip-address > inside, to the other end. > > => so new port and address don't need to be inside the notification > because they are inside the (protected) message. The new address and port need to be somewhere in the protected message, thus they do need to be in some notification. I do not want to reuse the NAT-DETECTION-*-IP for them, so it is easier to simply put them to this notification. > This notification can be send either using > the old or new address, but the sender MUST be able receive in the new > address before sending this out. > > => I disagree: there is no problem to require they are sent using > the new address. To be able to respond the return routability check we need to be able to receive in the new address. > When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process > MUST check that the other end can receive the packets sent to new > address, by sending empty notification to the peer addres and port > given inside the notification (not the UDP outer address). > > => I disagree: this return routability check should not be mandatory, > i.e., one MAY trust its peer. But IMHO it should be explained (as it > adds in fact nothing in the protocol it is free) and a config knob > should enable it. We have to provide the default value for this knob, > I am in favor of ON, i.e., perform the check by default. I think it is mandatory. Note, that this is protecting another kind of attack: Lets take example. www.videos.cnn.com is offering HDTV level video streams, but only with oppurtunistic encryption. Alice connects to this service and starts video transfer from the www.videos.cnn.com. After the video stream is going Alice, decides that he wants to really be Malice, and sends authenticated SOURCE-ADDRESS-CHANGED packet to the www.videos.cnn.com and says that his new address is Bob's address. If the www.videos.cnn.com does not do the return routability check then it will diver this 10 MBit/s video stream from Alice/Malice to the Bob's ADSL line blocking it completely. If the Bob is smart enough to be running IKEv2 and IPsec, he can recover, but if he does not know anything about IKEv2 and IPsec only think for he to do is to call the cnn and ask for their help to stop the sending the video feed. If he supports IKEv2 he will be seeing traffic to unknown SPI, thus he will send unauthenticated IKEv2 notification to the www.videos.cnn.com about invalid SPIs and when the www.videos.cnn.com receives that, it will start dead peer detection to see if the IKEv2 SA is still up. Bob will not reply to that and after IKE timeout the www.videos.cnn.com will drop the IKEv2 SA, IPsec SA (i.e the attack stops). > This change affects the IKE SA used to > receive the notification (i.e all future exchanges started on that IKE > SA will use this new address) and all child IPsec SAs created by this > IKE SA (i.e tunnel endpoint updated to new address). > > => I disagree: we need more fine grain stuff for multi-homing. Do we? I think it is easier to gain that with multiple IKEv2 SAs each having the IPsec SAs that are tied together. > What I propose is to put the list of affected SAs in the notification > with an "all SAs" flag which does exactly what you describe with > a restriction for proxy case SAs which must be never affected. I do not think we want to put that in there now. I think we can postpone that until later. > The reply to the original SOURCE-ADDRESS-CHANGED notification is sent > back to the address where it was received, as is also all other > requests, where reply is not yet sent (i.e they follow normal rule, > that the reply is sent back to the address where the packet > originated). Note, that all hosts are required to process this > notification while waiting for reply to their SOURCE-ADDRESS-CHANGED > notification (see section 2.3). > > => is this text really useful? Hmmm... it seems to be little unclear. The thing I was trying to say there is that the IKEv2 mandatates that if you have one exchange going out you must be able to process another exchange coming in. I.e when you send SOURCE-ADDRESS-CHANGED notification to the other end and the other end does the return routability check (using informational exchange and notifications), then you must be able to reply to that. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Mar 23 11:58:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NJwBg29951; Sun, 23 Mar 2003 11:58:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03568 Sun, 23 Mar 2003 14:24:37 -0500 (EST) Message-Id: <200303231927.h2NJRmof071515@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, antonio.forzieri@cefriel.it (Antonio Forzieri) Subject: Re: Secure remote access with IPsec In-reply-to: Your message of Sun, 23 Mar 2003 20:02:20 +0200. <15997.63148.726669.65209@ryijy.hel.fi.ssh.com> Date: Sun, 23 Mar 2003 20:27:48 +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: > => A question "en passant": is a payload more appropriate? > (I can't find a rationale about payload vs. notification, the > only argument is payloads can be made critical...) The current draft seems to be using notifications for all this kind of things, so thats why I selected that too. I think notifications are fine in this kind of cases. => more I think about this, more I believe notifications are fine for peer address protection but a payload is better for peer address update. But it is perhaps more than a matter of taste so I wait for a good argument... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Mar 23 13:50:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NLoLg03677; Sun, 23 Mar 2003 13:50:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03753 Sun, 23 Mar 2003 16:12:04 -0500 (EST) Message-Id: <200303232115.h2NLFjof071687@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com, antonio.forzieri@cefriel.it (Antonio Forzieri) Subject: Re: Secure remote access with IPsec In-reply-to: Your message of Sun, 23 Mar 2003 20:01:30 +0200. <15997.63098.74339.126424@ryijy.hel.fi.ssh.com> Date: Sun, 23 Mar 2003 22:15: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: Francis Dupont writes: > => note that when NAT-T is not activated we need an explicit protection > of the peer addresses (notifications like NAT-DETECTION-*-IP carrying > the full address and port) so the only guy who can put fake new addresses > is the peer. Yep, that is the reason for the SOURCE-ADDRESS-CHANGED notification (i.e it says the address have changed, and the new ones are here). => what I try to mean is the peer address must be protected in all messages when NAT-T is not activated (i.e., no NAT was detected). Of course this is even more important when a peer address update notification or payload is in the message. > The explicit address update is done by sending > SOURCE-ADDRESS-CHANGED notification, having new port and ip-address > inside, to the other end. > > => so new port and address don't need to be inside the notification > because they are inside the (protected) message. The new address and port need to be somewhere in the protected message, => I agree and I've added more. thus they do need to be in some notification. I do not want to reuse the NAT-DETECTION-*-IP for them, so it is easier to simply put them to this notification. => the reuse of the NAT-DETECTION-*-IP was a possible choice but we decided to split NAT stuff and mobility/multi-homing stuff. > This notification can be send either using > the old or new address, but the sender MUST be able receive in the new > address before sending this out. > > => I disagree: there is no problem to require they are sent using > the new address. To be able to respond the return routability check we need to be able to receive in the new address. => I was not clear enough: IMHO we should require the peer address update stuff be sent using the new address. > When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process > MUST check that the other end can receive the packets sent to new > address, by sending empty notification to the peer addres and port > given inside the notification (not the UDP outer address). > > => I disagree: this return routability check should not be mandatory, > i.e., one MAY trust its peer. But IMHO it should be explained (as it > adds in fact nothing in the protocol it is free) and a config knob > should enable it. We have to provide the default value for this knob, > I am in favor of ON, i.e., perform the check by default. I think it is mandatory. Note, that this is protecting another kind of attack: Lets take example. www.videos.cnn.com is offering HDTV level video streams, but only with oppurtunistic encryption. Alice connects to this service and starts video transfer from the www.videos.cnn.com. After the video stream is going Alice, decides that he wants to really be Malice, and sends authenticated SOURCE-ADDRESS-CHANGED packet to the www.videos.cnn.com and says that his new address is Bob's address. If the www.videos.cnn.com does not do the return routability check then it will diver this 10 MBit/s video stream from Alice/Malice to the Bob's ADSL line blocking it completely. => you've only shown the default must be to perform the test. But in a mobility context it can be better to trust the peer and to avoid an extra round-trip time (we already had this discussion for mobile IPv6 in its list), and in a multi-homing context the new address can be already known to be one of the valid addresses of the peer. So I am only in favor of a mandatory support and to perform the check by default. If the Bob is smart enough to be running IKEv2 and IPsec, he can recover, but if he does not know anything about IKEv2 and IPsec only think for he to do is to call the cnn and ask for their help to stop the sending the video feed. If he supports IKEv2 he will be seeing traffic to unknown SPI, thus he will send unauthenticated IKEv2 notification to the www.videos.cnn.com about invalid SPIs and when the www.videos.cnn.com receives that, it will start dead peer detection to see if the IKEv2 SA is still up. Bob will not reply to that and after IKE timeout the www.videos.cnn.com will drop the IKEv2 SA, IPsec SA (i.e the attack stops). => this kind of address stealing was discussed during months in the mobile-ip mailing list so we have now a good idea of the tradeoff. > This change affects the IKE SA used to > receive the notification (i.e all future exchanges started on that IKE > SA will use this new address) and all child IPsec SAs created by this > IKE SA (i.e tunnel endpoint updated to new address). > > => I disagree: we need more fine grain stuff for multi-homing. Do we? => yes, there are some cases in multi-homing where one'd like to setup one IKE SA to negociate IPsec SAs with different endpoint addresses. With fine grain address update, this can be easily done. I think it is easier to gain that with multiple IKEv2 SAs each having the IPsec SAs that are tied together. => we should give the choice. And multiple IKEv2 SAs don't work with INITIAL-CONTACT, etc. I really believe fine grain is useful but we can poll the multi6 WG if you'd like. > What I propose is to put the list of affected SAs in the notification > with an "all SAs" flag which does exactly what you describe with > a restriction for proxy case SAs which must be never affected. I do not think we want to put that in there now. I think we can postpone that until later. => the whole explicit update mechanism is portponed... > The reply to the original SOURCE-ADDRESS-CHANGED notification is sent > back to the address where it was received, as is also all other > requests, where reply is not yet sent (i.e they follow normal rule, > that the reply is sent back to the address where the packet > originated). Note, that all hosts are required to process this > notification while waiting for reply to their SOURCE-ADDRESS-CHANGED > notification (see section 2.3). > > => is this text really useful? Hmmm... it seems to be little unclear. The thing I was trying to say there is that the IKEv2 mandatates that if you have one exchange going out you must be able to process another exchange coming in. I.e when you send SOURCE-ADDRESS-CHANGED notification to the other end and the other end does the return routability check (using informational exchange and notifications), then you must be able to reply to that. => so we agree there is a problem with the wording. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Mar 23 19:19:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2O3Jug16139; Sun, 23 Mar 2003 19:19:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04504 Sun, 23 Mar 2003 21:47:34 -0500 (EST) Date: Thu, 20 Mar 2003 23:46:17 +0200 (IST) From: Hugo Krawczyk To: Gregory Lebovitz Cc: "'Russ Housley '" , "'IPsec WG '" Subject: RE: Do ipsec vendors care about privacy? In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66B1B@SARATOGA.netscreen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A couple of messages in this thread remind us that the WG decided that protecting the responder's identity from active attacks is preferable to protecting I's identity from such attacks. That's true, and I do NOT suggest to change that decision in the general case. However, since ikev2 has already gone to the effort of creating a variant of the protocol SPECIFIC for the remote access scenario then it makes sense to take advantage of this (as long as it does not incur in a significant cost or delay to the ikev2 document) to provide user's privacy via a strong protection of IDi. As opposed to the general case, in which what identity (I or R) is more important to protect is debatable (and many of the participants in this WG have changed their minds on this at least one time), in the remote access scenario it is OBVIOUS that hiding I's (the user's) identity from attackers in the network is far more important (than protecting the publicly known identity of the usually fixed-address gateway. If we decide not to provide user's id protection (from active attacks) in the EAP-based remote access protocol, the rationale for that decision must be documented (maybe in Radia's draft). This will not avoid later complaints by vendors and researchers but at least will show that it was a conscious decision rather than a simple overlook. Hugo From owner-ipsec@lists.tislabs.com Mon Mar 24 02:41:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OAfrg22408; Mon, 24 Mar 2003 02:41:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05353 Mon, 24 Mar 2003 05:07:13 -0500 (EST) Message-ID: <3E7EDA40.2060003@cefriel.it> Date: Mon, 24 Mar 2003 11:13:20 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? References: <005c01c2f119$0a3d4860$292e1dc2@YnirNew> In-Reply-To: <005c01c2f119$0a3d4860$292e1dc2@YnirNew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2003 10:12:42.0758 (UTC) FILETIME=[E85A7260:01C2F1ED] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: [SNIP] > If the client contacts the server and is able to produce a full > ID_DER_ASN1_DN then we know it is not just a polling attack. But what if > the client presents a ID_IPV4_ADDR? The IDr payload in message 3 was not > intended to be used as a security measure. It was intended as a hint to the > gateway as to which identity it should authenticate. Agreed. I think that if Bob doesn't receive IDi and AUTH payloads in message 2 then he understand that EAP authentication is going to be used. Alice *MUST* send Bob a *valid IDr*. Valid IDs are all defined in draft-ietf-ipsec-ikev2-05.txt except ID_IPV4_ADDR and ID_IPV6_ADDR. In tha case Bob receives such an IDr (invalid) he *MUST* send the notification message Yoav defined below. What do the other think? [SNIP] > INVALID-RESPONTER-ID 37 > Indicates that the initiator has sent an unacceptable > responder ID as part of the initial negotiation. This > only causes an error if the initiator has not sent its > own ID. -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Mon Mar 24 04:11:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OCBHg27731; Mon, 24 Mar 2003 04:11:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05526 Mon, 24 Mar 2003 06:41:31 -0500 (EST) Message-ID: <3E7EF089.2020008@cefriel.it> Date: Mon, 24 Mar 2003 12:48:25 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? References: <15995.22986.196922.999406@tero.kivinen.iki.fi> <15997.61320.38373.418691@fireball.acr.fi> In-Reply-To: <15997.61320.38373.418691@fireball.acr.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2003 11:47:47.0076 (UTC) FILETIME=[30644C40:01C2F1FB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: [SNIP] >>(2) moving IDr, [CERT,] AUTH from msg 4 to msg 2. >> Namely, message 2 from R to I (in section 2.16) will look as: >> <-- HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH [SNIP] > This will open the responders attack to polling attack. Agreed. I think we *MUST NOT* expose responder ID to polling attack... Or expose it as less as possible. [SNIP] > Some vendors refused to implement or use the aggressive mode of the > IKEv1, just because of it required you to do expensive operations > without ever knowing if there is anybody here. I would still guess, > that most implementations would require the return routability check > every time if this kind of protocol is used (at least I would in my > implementation). Agreed. I was thinking about something like this to "solve" the problem. Alice Bob ------- ----- HDR,SAi,KEi,Ni,EAPC --> <-- HDR,SAr,KEr,Nr,[CERTREQ],HLC HDR,SK{[CERTREQ],IDr,SAi2, --> TSi,TSr,HLC} <-- HDR,SK{IDr,[CERT],AUTH, EAP} HDR,SK{IDi,EAP,[AUTH]} --> <-- HDR,SK{EAP,[AUTH],SAr2,TSi,TSr} EAPC is a new payload (EAP Capability) and it contains a list of all authetication types supported by Alice: MD5,OTP,GTC,RSA... (for a complete list look here: http://www.networksorcery.com/enp/protocol/eap.htm) This payload let Bob know that Alice is going to use legacy authentication in EAP. If Bob doesn't support any auth type in EAPC he will send a notification message NO-VALID-EAP-SUPPORTED. In message 2 I've introduced HLC HIP Like Cookie, its primary scope is the same of return routability check plus a DoS protection. I think this is a better mechanism than return routability check as made in current ikev2 draft, in fact with HLC Alice *MUST solve* the quiz, while with the actual mechanism Alice can simply sniff the cookie and respond. Of course she has to be able of observe that traffic. The first scenario that comes in my mind is that of Alice being on a LAN and using spoofed IP address of the LAN she is on. HLC mechanism is described in draft-ietf-moskowitz-hip-05.txt. [COPY&PASTE BEGIN] 5.3.1. HIP Cookie Mechanism Responder Generates 2 Random Numbers, I and J Challenge = Ltrunc(SHA1(I|J),K) Send I, K, and Challenge in HIP Cookie in R1 Saves I, K, and Challenge for Delta time Initiator Do Until Challenge-response = Challenge Challenge-response = Ltrunc(SHA1(I|Rand),K) EndDo Send I, Rand, and Challenge-response in HIP Cookie in I2 Responder Match Response with Challenge based on I Reject if Challenge-response = Challenge Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K) Accept if Challenge-proof = Challenge [COPY&PASTE END] Alice MUST also specify a valid IDr, which can't be of type ID_IPV4_ADDR or ID_IPV6_ADDR, in the case such an ID is specified Bob will send Alice an INVALID-RESPONTER-ID notification message. This mechanism ensure a grade of protection on IDr.("You Tarzan? Me wonder...") IDi is in message 5, as Hugo proposed. However what seems to me harder to solve is that many EAP methods require a valid Identity before sending the first EAP message. [SNIP] >>It's all about tradeoffs and here I see privacy as the winner. Don't you? Agreed. What do the others think? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Mon Mar 24 05:11:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ODBig04213; Mon, 24 Mar 2003 05:11:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05725 Mon, 24 Mar 2003 07:41:04 -0500 (EST) From: "Yoav Nir" To: "'Antonio Forzieri'" , Subject: RE: Do ipsec vendors care about privacy? Date: Mon, 24 Mar 2003 14:44:06 +0200 Message-ID: <000201c2f203$0ed44050$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E7EF089.2020008@cefriel.it> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I like the EAPC idea, although I am not sure that it will actually solve a real problem. Ususally Alice has only one means of authenticating herself (she doesn't have a smart card, in addition to a token card and the password that she remembers). Still, if two implementations support a user-password scheme, but one calls it MD5 while the other calls it GTC, it would be nice to know at the end of the first message. As for making the IDr in message 3 mandatory for SLA, I think that is a good idea that solves our polling attack concern. I think the draft should not prohibit using an ID_IPV4_ADDR, but it should recommend (at the SHOULD level) to use some sort of DN or if none exists, and FQDN. Someone might want to set up a gateway that anybody can connect to. You mentioned that "... what seems to me harder to solve is that many EAP methods require a valid Identity before sending the first EAP message". What EAP methods are those? MD5 just sends a random challenge. It only needs the identity to check the response. GTC just expects the password. It also doesn't need the identity until it's time to check the password. RSA should not be used as legacy authentication. I'm not sure about OTP. It is possible that some authentication servers such as RADIUS need to know the identity before they send out an MD5 challenge. That is an implementation problem, which is why I'd rather use GTC for all legacy authentication methods (RADIUS, LDAP, OS password, etc.) That way, the gateway receives the actual password and the ID after message 5. It can then do whatever authentication protocol it wishes with an authentication server. If somebody does plan to use MD5 with such a RADIUS server, then I guess they will have to implement the full EAP protocol (including the Identity messages) and prolong the negotiation to 4 RT. Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Antonio Forzieri Sent: Monday, March 24, 2003 1:48 PM To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? Tero Kivinen wrote: [SNIP] >>(2) moving IDr, [CERT,] AUTH from msg 4 to msg 2. >> Namely, message 2 from R to I (in section 2.16) will look as: >> <-- HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH [SNIP] > This will open the responders attack to polling attack. Agreed. I think we *MUST NOT* expose responder ID to polling attack... Or expose it as less as possible. [SNIP] > Some vendors refused to implement or use the aggressive mode of the > IKEv1, just because of it required you to do expensive operations > without ever knowing if there is anybody here. I would still guess, > that most implementations would require the return routability check > every time if this kind of protocol is used (at least I would in my > implementation). Agreed. I was thinking about something like this to "solve" the problem. Alice Bob ------- ----- HDR,SAi,KEi,Ni,EAPC --> <-- HDR,SAr,KEr,Nr,[CERTREQ],HLC HDR,SK{[CERTREQ],IDr,SAi2, --> TSi,TSr,HLC} <-- HDR,SK{IDr,[CERT],AUTH, EAP} HDR,SK{IDi,EAP,[AUTH]} --> <-- HDR,SK{EAP,[AUTH],SAr2,TSi,TSr} EAPC is a new payload (EAP Capability) and it contains a list of all authetication types supported by Alice: MD5,OTP,GTC,RSA... (for a complete list look here: http://www.networksorcery.com/enp/protocol/eap.htm) This payload let Bob know that Alice is going to use legacy authentication in EAP. If Bob doesn't support any auth type in EAPC he will send a notification message NO-VALID-EAP-SUPPORTED. In message 2 I've introduced HLC HIP Like Cookie, its primary scope is the same of return routability check plus a DoS protection. I think this is a better mechanism than return routability check as made in current ikev2 draft, in fact with HLC Alice *MUST solve* the quiz, while with the actual mechanism Alice can simply sniff the cookie and respond. Of course she has to be able of observe that traffic. The first scenario that comes in my mind is that of Alice being on a LAN and using spoofed IP address of the LAN she is on. HLC mechanism is described in draft-ietf-moskowitz-hip-05.txt. [COPY&PASTE BEGIN] 5.3.1. HIP Cookie Mechanism Responder Generates 2 Random Numbers, I and J Challenge = Ltrunc(SHA1(I|J),K) Send I, K, and Challenge in HIP Cookie in R1 Saves I, K, and Challenge for Delta time Initiator Do Until Challenge-response = Challenge Challenge-response = Ltrunc(SHA1(I|Rand),K) EndDo Send I, Rand, and Challenge-response in HIP Cookie in I2 Responder Match Response with Challenge based on I Reject if Challenge-response = Challenge Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K) Accept if Challenge-proof = Challenge [COPY&PASTE END] Alice MUST also specify a valid IDr, which can't be of type ID_IPV4_ADDR or ID_IPV6_ADDR, in the case such an ID is specified Bob will send Alice an INVALID-RESPONTER-ID notification message. This mechanism ensure a grade of protection on IDr.("You Tarzan? Me wonder...") IDi is in message 5, as Hugo proposed. However what seems to me harder to solve is that many EAP methods require a valid Identity before sending the first EAP message. [SNIP] >>It's all about tradeoffs and here I see privacy as the winner. Don't you? Agreed. What do the others think? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Mon Mar 24 05:51:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ODpUg05919; Mon, 24 Mar 2003 05:51:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05841 Mon, 24 Mar 2003 08:22:49 -0500 (EST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15995.22986.196922.999406@tero.kivinen.iki.fi> Date: Sat, 22 Mar 2003 02:28:26 +0800 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: Russ Housley , hugo@ee.technion.ac.il (Hugo Krawczyk) Subject: Re: Do ipsec vendors care about privacy? References: X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 24 min X-Total-Time: 26 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hugo@ee.technion.ac.il (Hugo Krawczyk) writes: > I agree: no time for major surgery on the document. > But not too late for a change that takes 1-5 minutes editorial work All the proposal I have seen sent to the list are might be 1-5 minutes editorial work, but the problem is that they also cause effects to the other parts of the document, which means that much more analysis of the actual effect of the change. I.e they actually ARE MAJOR SURGERY. Lets analyze some of the proposal: 1) Leave out the IDi in the message 2 and move it later. - The current EAP mode assumes (and most of the implementations do require) that it has user's identity to before the EAP start. I.e the current text says that we are not supposed to use EAP(identity request / replies), as we can get the same information from the ID payload already. This adds one more round trip to the exchange. - The text currently says that if the EAP method creates shared key it MUST be used to generate the AUTH payloads using the shared secret method by both ends. If we move the AUTH payload to point before the EAP finishes (or actually before it starts), then we have to change this. I do not know the actual effects of this change. 2) Move the authentication of the server to message 2. - This open one more DoS attack. The responder must sign the auth message before it actually knows if there is anybody there on the other end. Currently the resourses used from the responder for the first packet is very cheap (policy lookup, take precalculated Diffie-Hellman (or reuse old one), make some state, and send packet). In this model we would need to add do RSA/DSA sign operation during that, which is much more expensive operations than any of the above. That would most likely mean that the responder would always require the return routability check before doing anything, having an effect that we added one more round trip to the exchange in normal case. - Also the generation of the signature is little bit harder, as we are signing the packet we are also adding the signature to. - Also in that case we loose the "You Tarzan, Me Jane" for those cases, because the responder needs to sign the identity it is using in the packet 2, and the initiator is sending the preferred ID to be used in packet 3. - Then again, how does the server know when to do this, because it hasn't yet seen that the other end wants to do EAP. So we either need to add it to the SA payloads, or do it always. 3) Move the server AUTH to place before the EAP has finished. - The text currently says that if the EAP method creates shared key it MUST be used to generate the AUTH payloads using the shared secret method by both ends. If we move the AUTH payload to point before the EAP finishes (or actually before it starts), then we have to change this. I do not know the actual effects of this change. 4) Authenticate the responder first before initiator - All of these cases makes it easy to make polling attack, i.e I start process in the IETF and start IKE negotiation against each IP address. The responder will be very helpfull and send me proof who they actually are. Currently there is no way to get that information, I only can get the IP address, I do not know to whom which ip address is assigned to. Remember that IPsec is actually symmetric, thus the original initiator can be responder later. > On the other hand, user's id protection in the remote access protocol of > ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec > developers (on the list and outside the list). So giving the opprtunity to > this substantial improvement if it comes at little cost and on time is a > reasonable thing to do. If you need it you can already do it know, by using the ID_KEY_ID, i.e simply send random string to the other end as ID_KEY_ID, and made it so that the server can then find map that to your identity, and update it to be something different after you have authenticated successfully. > In any case, ,I raised the issue and two possible solutions, but I am not > the one that needs to decide if the WG is to adopt this or not. THOSE THAT > CARE (in one way or another) SHOULD SPEAK UP. I am strongly AGAINST this modification at this point of the process, as I do not think it is small change. As I commented above all of the small changes suggested have all kind of various problems, and I am pretty much sure my list above is not complete list (they are those that immediately came to my mind when seeing this discussion). > If there is not enough interest, then nothing needs to be done. > At least it will be documented that this was a conscious decision rather > than an overlook or the result of simple rushing. > (This will help against future criticizers of the protocol that wil > raise these issues in their papers...) I agree that this decision should be documented. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Mar 24 05:52:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ODq4g05944; Mon, 24 Mar 2003 05:52:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05847 Mon, 24 Mar 2003 08:23:48 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3E7B5AC7.8020100@bell-labs.com> Date: Fri, 21 Mar 2003 13:32:39 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: David Wagner Original-CC: ipsec@lists.tislabs.com Subject: Re: AES-based PRF for IKEv2 References: <3E7A5234.5020504@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, First - thank you for the review! I appreciate it! My answers are inline. David Wagner wrote: > I don't think your security claims are quite right. You've padded the key > with zeros. As a result, you need a stronger assumption than that the > block cipher is a pseudorandom permutation. A pseudorandom permutation > only guarantees that the cipher is strong for uniformly random keys, not > for keys padded with zeros and not for keys with poor-quality randomness. Not quite - a key with all zeroes is just as random as any other key. > For instance, suppose E_k(x) is a block cipher with 256-bit key that > acts as the identity function when the last 128 bits of k are zero, > but otherwise acts as a secure block cipher. Then E_k(x) will be a > pseudorandom permutation (with security parameter 2^-128), but your > construction will be totally insecure when used with E_.(.) if S is > 128 bits long (or shorter). You are basically saying here that the key space is non-linear. There are ciphers in use like that (especially in the military), but it is *assumed* that AES keyspace is linear. And yes - for non-linear keyspace you need special treatment of the key. Just randomizing it doesn't always help - it all depends on the keyspace properties. > Given your assumptions on S and N, I suspect you're really going to need > to use a hash function. (Otherwise, you'll have to use some very strong > assumptions about the block cipher -- e.g., the ideal cipher model -- > but I definitely do not recommend doing so.) I don't think that linear keyspace assumption is too much. And so far there were no weak keys found for AES, were there? Thanks! Regards, Uri. From owner-ipsec@lists.tislabs.com Mon Mar 24 06:04:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OE4Cg06442; Mon, 24 Mar 2003 06:04:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05934 Mon, 24 Mar 2003 08:37:58 -0500 (EST) Message-Id: <5.1.0.14.0.20030319091414.04e1fd50@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Mar 2003 09:21:17 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Another NAT Traversal question In-Reply-To: <3E781036.3020603@roc.co.in> References: <200302260015.h1Q0FDof060239@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA18106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:07 19.03.2003 +0530, you wrote: >IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of > NAT Traversal. If we make this packet also containing first four > bytes after > UDP header as 0s in case of IKE packet, then there is no need for > port 4500 > >Regards, >Ravi Well. Routers doing NAT reassign ports. In goes src/dst 53/53, out goes src/dst 1025/53 or something. On the return packets, the port number are changed back. You know that. The problem is that over 50% of all router DO NOT DO THAT if the port is 500 the keep the 500/500 mapping. Many small vendors do that. But even the current (February) Cisco IOS does that. And there is no way to switch it off. If you run IKE through a NAT box, the IKE client software can't use port 500. Using a random port >1023 works fine. But then the client can't be responder anymore.... the port 500 is spoiled, sorry, and it has to go. J­rn From owner-ipsec@lists.tislabs.com Mon Mar 24 06:05:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OE5Qg06503; Mon, 24 Mar 2003 06:05:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05916 Mon, 24 Mar 2003 08:33:57 -0500 (EST) Cc: IPsec WG Message-ID: <3E7D69FB.1080907@bell-labs.com> Disposition-Notification-To: Uri Blumenthal Date: Sun, 23 Mar 2003 03:02:03 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Hugo Krawczyk Original-CC: IPsec WG Subject: Re: AES-based PRF for IKEv2 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: >>SECURITY PROPERTIES. >> >>A block cipher being a Pseudo Random Permutation, if the >>S parameter is secret, the following hold true: Let me clarify this statement. An [unbroken] block cipher is a FAMILY of pseudo random permutations INDEXED by the key. So for any GIVEN key this block cipher is a pseudo random permutation. It is assumed to be true for AES. >> - output of (3) is pseudo-random. >> - output of (5) is pseudo-random. > > Unfortunately, this is incorrect. I would like to see it shown for AES. I.e. please show how you can distinguish the AES output of (3) and/or of (5) from a random string, if you don't know S, but know the rest of the input. Also, I would like to see how you can distinguish AES output from random 128-bit string, if you know the relation between the key bits and some of the input bits, know the rest of input bits, but don't know the key. > If all what you assume about the block cipher is that it > is a pseudorandom permutation then to be able to get a result > as you state you need to assume that all the values used to key > the block cipher are random (or pseudo-random, in the > complexity-theoretic sense). Of course I also assume linearity of the key space. What other assumptions are necessary in your opinion? > That means that you need to assume S to be secret (as you do) but also > random (that you don't do) and of at least the length of the cipher's > keys (what you don't do either). Please explain why S should be random. In all the literature I'm aware of, all the analysis of block ciphers made no assumptions about the key except being unknown to the adversary. > Specifically one can build examples of perfectly secure > pseudorandom permutations that will induce insecure outputs from (3) > and (5). Very well - I'd like to see them for my education (so please e-mail me an example) - but it doesn't seem to apply to AES. > This was pointed out by Dave Wagner for the case in which S is > too short, The adversary cannot know whether the key in use has any specific property - such as being short, or having x zeroes as suffix. After all, the bit string of all zeroes is as random as any other string. And if the adversary has a good reason to assume that the key is short - then nothing will help, because no matter what type of transform you apply to that key, the key itself will remain the weakest link and will be attacked by brute force. It applies to any PRF, block cipher-based and hash-based. > and one can also give examples in which S is longer than the key > (but not uniformly distributed). Again, I think it does not apply to AES (because of its keyspace properties) - but I personally would like to see an example e-mailed to me. If you mean that knowing the properties of the key - such as knowing in advance that the key is likely to have only 4 bytes of "juice" and the rest filled with zeroes - makes this approach insecure, I'll fully agree. And will add - in such a case there's no way to secure it, because no matter what you do, I'll attack the weakest link - the short key itself. > Now, clearly, if you assume that the given value S is already a good > random key for the prf then you do not need all the construction. You need a similar construction to mix in the nonces. And it seems a good tradition to step further away from the generator key... The approach I'm suggesting is taken directly from the Rijndael submission to NIST (specifically the Hash and PRF sections). If there are problems with it - why didn't somebody (you for example :-) write something about it and publish? > Finally, regarding the use of this method with a DH key S=g^{xy} as you > suggest. In this case you'd take the first, say, 128 bits of g^{xy} as > the key to the block cipher and the rest as data. Under which > assumptions on DH and the block cipher you can claim the proposed > key derivation to be secure? Note that the attacker knows g^x, g^y. The assumptions are: 1. Block cipher is a family of PRP indexed by the key. An unbroken block cipher should satisfy this. 2. Block cipher has linear keyspace (there is no class of weak keys), so there is no specific property of the key that makes the cipher weak. [we aren't discussing idiotic cases like using short keys padded with known quantity, so the attacker has to search only say 2^32 space because the rest is all 1's or all 0's.] 3. It is practically impossible to determine more than a few bits of g^xy when you know both g^x and g^y. If other assumptions are necessary to consider this approach secure, please share them (and the justification behind) with me. Thanks! From owner-ipsec@lists.tislabs.com Mon Mar 24 07:40:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OFeOg15112; Mon, 24 Mar 2003 07:40:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06655 Mon, 24 Mar 2003 10:13:29 -0500 (EST) Message-Id: <5.2.0.9.2.20030321202023.03327110@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Mar 2003 20:22:15 -0500 To: Uri Blumenthal , IPsec WG From: Russ Housley Subject: Re: AES-based PRF for IKEv2 In-Reply-To: <3E7A5234.5020504@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri: Steps 1 thru 4 are pretty slow. You keep computing the AES key schedule over and over. In 802.11, we have found that this is a very expensive operation. Can it be avoided? Russ At 06:43 PM 3/20/2003 -0500, Uri Blumenthal wrote: >Folks, > >Here's a proposal for an AES-based PRF that takes variable-length >input and produces variable-length output. > >Please comment. > >Thank you! > >Regards, >Uri. > > >PROPOSAL: AES-BASED PRF FOR IKEv2. > >The goal is to produce requested amount of pseudo >random bits, using AES (or other block cipher) and >variable-length input for both secret parameter, and >publicly known parameter. Should work with variable >key length, preferably support different block sizes. >Preferably, the construct is provably secure. > >The following idea is based on Rijndael submission >to NIST. It is assumed that AES is the block cipher >that will be used, but the construct is generic >enough to accomodate other block ciphers. > > >PRF(S, N) ALGORITHM. > >Two parameters - one is secret, the other one may be >known. No assumption on the quality of randomness of >either one is made. Assume that S is secret and N is >known. No limitation on size of S, N. > >Outputs pseudo-random stream of bits in 128-bit chunks >(variable-length output). > >Block cipher is assumed, with key-buffer for key, and >data-buffer for plaintext. AES is assumed, but any >other un-broken blok cipher should do. > >Algorithm: > > 1. Fill the key-buffer with S. If S is shorter than > the key-buffer, pad the key buffer with zeroes. > > 2. If any bits of S are left after step (1), place > them in the data-buffer. Append parameter N to > the data-buffer. Pad the data-buffer with zeroes > if necessary, to make it multiple of cipher block > size, and at least as long as key-buffer. > > 3. Encrypt as many blocks of data-buffer as necessary > to fill key-buffer. > > 4. Take the output of (3) and fill the key-buffer. > Continue (3) and (4) for the reminder of the > data-buffer. > > 5. At this point the encryption engine is ready to produce > Pseudo-Random stream. Now run the encryption engine in > OFB mode (starting with input buffer filled with zeroes) > using the full block size, until the desired amount of > output bits is produced. > > >RATIONALE. > >a. All the theory of block cipher security is based on the >assumption that the key is unknown to the attacker. Thus >we key the encryption engine with the secret parameter. > >b. It is preferred to move away from the given secret >parameter (which is likely to be Diffie-Hellman output). >That is why at least one key change is performed. > >c. Variable-length input and output is desirable - this is >accomplished. > > >SECURITY PROPERTIES. > >A block cipher being a Pseudo Random Permutation, if the >S parameter is secret, the following hold true: > > - output of (3) is pseudo-random. > - output of (5) is pseudo-random. From owner-ipsec@lists.tislabs.com Mon Mar 24 07:44:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OFi1g15696; Mon, 24 Mar 2003 07:44:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06635 Mon, 24 Mar 2003 10:09:27 -0500 (EST) Message-ID: <3E7F2120.1080302@cefriel.it> Date: Mon, 24 Mar 2003 16:15:44 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? References: <000201c2f203$0ed44050$292e1dc2@YnirNew> In-Reply-To: <000201c2f203$0ed44050$292e1dc2@YnirNew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2003 15:15:05.0147 (UTC) FILETIME=[260F50B0:01C2F218] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: > I like the EAPC idea, although I am not sure that it will actually solve a > real problem. Ususally Alice has only one means of authenticating herself > (she doesn't have a smart card, in addition to a token card and the password > that she remembers). Still, if two implementations support a user-password > scheme, but one calls it MD5 while the other calls it GTC, it would be nice > to know at the end of the first message. Agreed. We can use EAPC to make Bob possible send the right EAP message in IKEv2 Message 4. So if the initiator sends EAPC(MD5), Bob will send in message 4 a EAP(Request,MD5). > As for making the IDr in message 3 mandatory for SLA, I think that is a good > idea that solves our polling attack concern. I think the draft should not > prohibit using an ID_IPV4_ADDR, but it should recommend (at the SHOULD > level) to use some sort of DN or if none exists, and FQDN. Someone might > want to set up a gateway that anybody can connect to. It sounds fine for me... What do the others think about? > You mentioned that "... what seems to me harder to solve is that many EAP > methods require a valid Identity before sending the first EAP message". > What EAP methods are those? The right question we have to ask to ourselves is: *What authentication method we will use in IKEv2_EAP?* *Which of these methods will require ID before sending an EAP message?* I don't know all the methods EAP supports, however I know that OTP will not work without knowing IDi. MD5 and SecureID should work without any problem and GTC (which I don't know) should work. But what about Defender Token (AXENT), Arcot Systems EAP, CRYPTOCard, DynamID, Sentrinet and all the other methods supported in EAP? Of course I think that we aren't going to support RSA PKA, or Smartcard, we can use them directly in IKEv2, without using EAP! [SNIP] If the answer is that there are few authentication method that needs to know IDi, than let's leave the things as they are, and for that methods use 1RTT more. (EAP(Request,Identity) in message 4). [SNIP] > Yoav -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Mon Mar 24 07:44:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OFiug15742; Mon, 24 Mar 2003 07:44:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06656 Mon, 24 Mar 2003 10:13:29 -0500 (EST) Message-Id: <5.2.0.9.2.20030321203242.033dec00@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Mar 2003 20:35:06 -0500 To: Hugo Krawczyk From: Russ Housley Subject: Re: Do ipsec vendors care about privacy? Cc: IPsec WG In-Reply-To: References: <5.2.0.9.2.20030320164711.0194e328@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo: I repeat: The working group co-chairs in combination with the document editor need to make a decision concerning the magnitude of the changes. If it is the least bit onerous, then this should not be done. It is not a requirement, and we are already overdue on delivery. We need to hear from the chairs before proceeding with this discussion. I think that we have given them adequate information to make the decision. I hope that they will make it in the next few days. Russ At 09:10 AM 3/21/2003 +0200, Hugo Krawczyk wrote: >On Thu, 20 Mar 2003, Russ Housley wrote: > > > Hugo: > > > > > > I wrote: > > >Hugo, in my view it is too late to be raising a question that will cause > > >major surgery on the document. It is time to fix things that are broken, > > >make the document internally consistent, and publish it. I do not > think it > > >is time to raise new requirements. > >I agree: no time for major surgery on the document. >But not too late for a change that takes 1-5 minutes editorial work >On the other hand, I admit that there are some operational issues >that are not fully resolved in my proposals and need more input from >people that care and know better. If this does not come on time >to make the document before being closed then we will not have it. > >On the other hand, user's id protection in the remote access protocol of >ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec >developers (on the list and outside the list). So giving the opprtunity to >this substantial improvement if it comes at little cost and on time is a >reasonable thing to do. > >In any case, ,I raised the issue and two possible solutions, but I am not >the one that needs to decide if the WG is to adopt this or not. THOSE THAT >CARE (in one way or another) SHOULD SPEAK UP. > >If there is not enough interest, then nothing needs to be done. >At least it will be documented that this was a conscious decision rather >than an overlook or the result of simple rushing. >(This will help against future criticizers of the protocol that wil >raise these issues in their papers...) > >I will be glad to see some technical discussion in the coming days >if people care about having such discussions. Beyond that I am not going >to insist (this is not an area of "correct cryptographic design" for >which I personally care but rather one of engineering trade-offs that >other understand better than me). > >Hugo > >PS: shoot the engineers but not the scientists :) > > > > > You replied: > > >This response really sounds as coming from the area director :) > > >ANyway, I'd agree with you that this is too late if the change I proposed > > >required "major surgery on the document". But it doesn't. > > >Any of the proposed solutions takes a 1 minute editorial work, > > >just moving one or two fields from one message to the other in section > > >2.16 (and has no influence on other partts of the document). > > > > > >The question is not specification complexity which is null for this > > >changes. ALso, it is not a performance issue. None of the proposed changes > > >add round trips or computation (a message to the list from > > >Antonio Forzieri might have given that impression but his > > >modification of my proposal was unnecessary as he later stated himself). > > > > > >The only question is operational: can the responder (server) send the > > >first EAP message before getting IDi? If this is the case (as it was in > > >PIC and seems tobe agreed in some responses to my message) then we are > > >done at no cost at all (solution 1). If not, we may need to go to > > >solution 2 (in which the responder authenticates in message 2). Here the > > >main operational issue, pointed out by Antonio, is that you need to have a > > >way for the initiator to signal that he is requiring legacy > > >authentication. > > > > > >So all we need is some feedback on the above operational issues, and then > > >make a definitive decision about the right design/privacy trade-off. > > >It should not put any delay on the closure of ikev2. > > > > The working group co-chairs in combination with the document editor > need to > > make a decision concerning the magnitude of the changes. If it is the > > least bit onerous, then this should not be done. It is not a requirement, > > and we are already overdue on delivery. > > > > It is time to warp this effort up. Fix anything that fails to meet the > > requirements that have already been set by the working group. then make > the > > document internally consistent. Additional stuff can be dealt with by a > > subsequent working group. > > > > Ted got it right at the beginning of the meeting. He said, "It is time to > > shoot the engineers and ship the product." > > > > Russ > > > > From owner-ipsec@lists.tislabs.com Mon Mar 24 08:18:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OGIKg17291; Mon, 24 Mar 2003 08:18:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06956 Mon, 24 Mar 2003 10:54:33 -0500 (EST) From: "Yoav Nir" To: "'Antonio Forzieri'" , Subject: RE: Do ipsec vendors care about privacy? Date: Mon, 24 Mar 2003 17:58:20 +0200 Message-ID: <000401c2f21e$3186e560$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E7F2120.1080302@cefriel.it> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think the others will tell you that it is too late in the day to add such new things as EAPC. Since this is an optional, perhaps you can write a draft that introduces this new payload. It could optionally be used to save the extra RT for EAP challenge -> EAP failure with a suggestion of another method. You mentioned a lot of EAP methods, many of which are not documented. Since we are talking about interoperability here, I suggest that we best stick with the methods that are in the EAP rfc, namely GTC, MD5 and OTP. IMO the only one that is really useful is GTC, because it delivers the password to the gateway. Once the gateway has the password it can participate in whatever authentication scheme the authentication server supports. If the server wants the client to hash the password, (as in CHAP or its derivatives), the gateway can do it instead. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Antonio Forzieri Sent: Monday, March 24, 2003 5:16 PM To: ipsec@lists.tislabs.com Subject: Re: Do ipsec vendors care about privacy? Yoav Nir wrote: > I like the EAPC idea, although I am not sure that it will actually solve a > real problem. Ususally Alice has only one means of authenticating herself > (she doesn't have a smart card, in addition to a token card and the password > that she remembers). Still, if two implementations support a user-password > scheme, but one calls it MD5 while the other calls it GTC, it would be nice > to know at the end of the first message. Agreed. We can use EAPC to make Bob possible send the right EAP message in IKEv2 Message 4. So if the initiator sends EAPC(MD5), Bob will send in message 4 a EAP(Request,MD5). > As for making the IDr in message 3 mandatory for SLA, I think that is a good > idea that solves our polling attack concern. I think the draft should not > prohibit using an ID_IPV4_ADDR, but it should recommend (at the SHOULD > level) to use some sort of DN or if none exists, and FQDN. Someone might > want to set up a gateway that anybody can connect to. It sounds fine for me... What do the others think about? > You mentioned that "... what seems to me harder to solve is that many EAP > methods require a valid Identity before sending the first EAP message". > What EAP methods are those? The right question we have to ask to ourselves is: *What authentication method we will use in IKEv2_EAP?* *Which of these methods will require ID before sending an EAP message?* I don't know all the methods EAP supports, however I know that OTP will not work without knowing IDi. MD5 and SecureID should work without any problem and GTC (which I don't know) should work. But what about Defender Token (AXENT), Arcot Systems EAP, CRYPTOCard, DynamID, Sentrinet and all the other methods supported in EAP? Of course I think that we aren't going to support RSA PKA, or Smartcard, we can use them directly in IKEv2, without using EAP! [SNIP] If the answer is that there are few authentication method that needs to know IDi, than let's leave the things as they are, and for that methods use 1RTT more. (EAP(Request,Identity) in message 4). [SNIP] > Yoav -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Mon Mar 24 08:26:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OGQvg17465; Mon, 24 Mar 2003 08:26:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06945 Mon, 24 Mar 2003 10:53:28 -0500 (EST) From: "Jesse Alpert" To: "'IPsec WG'" Subject: IKEv2 and Perfect Forward Secrecy Date: Mon, 24 Mar 2003 17:56:58 +0200 Message-ID: <000501c2f21e$00f54590$7b2e1dc2@jesse> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am a little disturbed by section 2.12 - "Reuse of Diffie-Hellman Exponentials" in the latest IKEv2(-05) draft. If I understand correctly PFS means that after closing a tunnel with Bob Alice is guaranteed that even if an attacker gained access to all the keys used for that tunnel, he has not gained any information which may help him break future tunnels between Alice and Bob. It seems section 2.12 implies that Bob is allowed to keep his DH secret y, and reuse it until the tunnel between Alice and Bob is closed WITHOUT compromising PFS: "... Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state." This seems misleading. A common case would be for Alice to establish a tunnel (Alice uses x1, sends g^x1, Bob uses y1, sends g^y1). Later Alice would want to re-key, BEFORE the current SA expires she starts a new exchange (Alice using x2, sends g^x2), Bob who is following the suggestion made in 2.12 reuses y1 since the first tunnel is not yet closed. He thinks he is still guaranteeing PFS. Once this tunnel is established Alice closes the old one and continues to use the new one thinking she has PFS. This seems bad since an attacker who gained access of y1 and recorded all traffic between Alice and Bob can decrypt all traffic which passed through BOTH tunnels. What am I missing? P.S. I deliberately ignored the distinction between IKE-SA and CHILD-SA with PFS, since it seems it is ignored in the quoted section from the draft as well. Jesse From owner-ipsec@lists.tislabs.com Mon Mar 24 12:47:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OKlFg00615; Mon, 24 Mar 2003 12:47:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07756 Mon, 24 Mar 2003 15:10:23 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CA65@corpmx14.us.dg.com> To: ipsec@lists.tislabs.com Subject: IKEv2: ECN hack for broken h/w? Date: Mon, 24 Mar 2003 15:10:13 -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 Folks, I got tagged with an action item to send this email as a result of several hallway discussions in SF. I don't think a change is needed here, but this is a "due diligence" exercise to make sure that this issue gets attended to. The current ECN text in the IKEv2 draft requires a tunnel decapsulation change to propagate ECN congestion indications from the outer header to the inner header. If the decapsulation is implemented in hardware, a system that is composed of hardware acceleration (e.g., crypto, tunnel, ESP) plus software IKE may be unable to upgrade to IKEv2 due to an inability to change the decapsulation hardware. It appears to be the case that the encapsulation side is easier to change and/or may not be broken wrt ECN, so an IKEv2 hack is possible to notify the encapsulator that the decapsulator can't cope with ECN - the encapsulator would either disable ECN in the outer headers or fail the SA setup in tunnel-mode. OTOH: - The fact that ipsec tunnels require changes for ECN is old news. This has been discussed in the ipsec WG at least as far back as 1999. One really cannot claim that changes in this area are a surprise. - Any hardware that doesn't implement ECN correctly for ipsec tunnels (i.e., does RFC 2401, and nothing more) is already broken (does not conform to the relevant RFCs), and has been since the publication of RFC 3168 in 2001. - IKEv2 will make AES mandatory. Hardware that doesn't implement AES will be either out of conformance, or slow (courtesy of software AES). I suspect that much of the hardware in question doesn't implement AES. - RFC 2401bis will incorporate the ECN changes. So, even if an implementer ignored RFC 3168 (bad idea), the ECN changes are coming in a form that can't be ignored. The upshot (IMHO) is that I don't see a case for putting a hack into IKEv2 to cope with existing "broken" hardware, but I thought I'd put this message out to allow those with differing views to express them. 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@lists.tislabs.com Mon Mar 24 13:35:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OLZ0g02038; Mon, 24 Mar 2003 13:35:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07903 Mon, 24 Mar 2003 16:08:59 -0500 (EST) Message-Id: <200303242113.h2OLD7aj023416@thunk.east.sun.com> From: Bill Sommerfeld To: Black_David@emc.com cc: ipsec@lists.tislabs.com Subject: Re: IKEv2: ECN hack for broken h/w? In-Reply-To: Your message of "Mon, 24 Mar 2003 15:10:13 EST." <277DD60FB639D511AC0400B0D068B71E0564CA65@corpmx14.us.dg.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 24 Mar 2003 16:13:07 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The upshot (IMHO) is that I don't see a case for putting a > hack into IKEv2 to cope with existing "broken" hardware, but > I thought I'd put this message out to allow those with > differing views to express them. Agree. Moreover, should evidence surface that this is a more common case than we currently think, it's clear to me at that the base ikev2 spec contains sufficient flexibility to allow a critical "broken-hardware" payload to be specified later in a separate document. I see no reason to hold ikev2 for this. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 24 13:52:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OLqPg02946; Mon, 24 Mar 2003 13:52:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07938 Mon, 24 Mar 2003 16:24: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-based PRF for IKEv2 Date: 24 Mar 2003 21:02:44 GMT Organization: University of California, Berkeley Lines: 46 Distribution: isaac Message-ID: References: <3E7A5234.5020504@bell-labs.com> <3E7B5AC7.8020100@bell-labs.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1048539764 15811 128.32.153.211 (24 Mar 2003 21:02:44 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 24 Mar 2003 21:02:44 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 Uri Blumenthal wrote: >David Wagner wrote: >> I don't think your security claims are quite right. You've padded the key >> with zeros. As a result, you need a stronger assumption than that the >> block cipher is a pseudorandom permutation. A pseudorandom permutation >> only guarantees that the cipher is strong for uniformly random keys, not >> for keys padded with zeros and not for keys with poor-quality randomness. > >Not quite - a key with all zeroes is just as random as any other key. No, no, no. You're confused. Keys aren't random; it's the process used to create them that might or might not be random. A number like 000 isn't random, and it isn't uniformly distributed; it makes no sense to try to attach the term "random" to simple numbers. The process used to generate it might or might not be random; the term "random" attaches to processes that generate numbers, not to the numbers themselves. Imagine I have a six-sided die. I claim to you that it is fair, i.e., all six outcomes are equally likely. You roll it 100 times and get a "6" every time. If you express some skepticism that my die is fair, I'm going to tell you that the number "6" is just as random as any other outcome. Are you convinced? I certainly hope not! The point is that we must look at the process used to create the key. When using a PRP, that key-creation process must provide outputs that are secret, random, and uniformly distributed on the cipher's keyspace. The key-creation process you specified does not qualify: the last bit of the AES key is much more likely to be 0 than to be 1, for instance. >There are ciphers in use like that (especially in the military), >but it is *assumed* that AES keyspace is linear. Assumed by whom? The assumption that AES is a secure PRP does *not* guarantee that its keyspace is "linear" (whatever that means precisely). And the standard security goal for block ciphers is that they be a secure PRP. (In my experience, this goal is generally agreed upon by both theoreticians, block cipher designers, and cryptanalysts. Sometimes block cipher designers try for other, extra goals, but being a secure PRP is usually the most important goal and it is usually the one that receives the most study from cryptanalysts, in my experience. As a result, among all unproven security properties, PRP-ness is probably the property taht we can have the most confidence in.) From owner-ipsec@lists.tislabs.com Mon Mar 24 14:04:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OM4Ig03953; Mon, 24 Mar 2003 14:04:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08012 Mon, 24 Mar 2003 16:39:19 -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-based PRF for IKEv2 Date: 24 Mar 2003 21:17:36 GMT Organization: University of California, Berkeley Lines: 56 Distribution: isaac Message-ID: References: <3E7D69FB.1080907@bell-labs.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1048540656 15811 128.32.153.211 (24 Mar 2003 21:17:36 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 24 Mar 2003 21:17:36 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 Uri Blumenthal wrote: >Let me clarify this statement. An [unbroken] block cipher >is a FAMILY of pseudo random permutations INDEXED by the >key. So for any GIVEN key this block cipher is a pseudo >random permutation. It is assumed to be true for AES. I think you're a little confused about the terminology. The second sentence above is meaningless. The term "pseudo random permutation" -- according to its standard usage in cryptography -- attaches to a family of permutations, not to a single permutation on its own. It makes no sense to say that a particular permutation (e.g., AES when used with a particular fixed key) is pseudorandom. >I would like to see it shown for AES. I'm not sure you understood the point Hugo and I are making. Maybe I should try to clarify at more length. I'm not saying that your construction is definitely insecure when used with AES. I'm not saying it is definitely secure, either. Rather, I'm suggesting it would be premature to accept your construction for IPSec. I'm saying that its security analysis is not well enough developed. The assumptions about AES needed (to ensure the security of your construction) are unclear and non-standard. In particular, the PRP assumption does not guarantee that your construction is secure. This is all about understanding what security assumptions we have to make, which I claim ought to be an important part of any act of modern cryptographic design. Your construction might be secure when used with AES, or it might not. I don't have any idea whether it is or it isn't. But we can say this: It's not enough merely to assume that AES is a secure PRP. If your construction does happen to be secure, it must be because AES has some additional security properties that not all PRP's are guaranteed to have. The natural question then is whether it is reasonable to assume that these necessary additional properties hold for AES. Since those required properties have never been clearly stated, that question is hard to answer with confidence without knowing precisely what those additional assumptions might be. However, I can say this much: these additional assumptions are going to be at least a little bit non-standard. The standard assumption about AES is that it is a secure PRP. "PRP-ness" is the standard goal agreed upon both by block cipher practitioners and by theoreticians (though sometimes people try for additional goals). As a result, we usually have more confidence in "the PRP assumption" than we would have in any other assumption. In short, I believe it would be premature to accept your proposal. Here's what I would propose: I suggest working out a formal security analysis for your construction, running the result by ietf-cfrg, and if it meets approval there, then let's consider it for inclusion in IPSec at that point. From owner-ipsec@lists.tislabs.com Mon Mar 24 20:17:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P4HVg22634; Mon, 24 Mar 2003 20:17:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08925 Mon, 24 Mar 2003 22:50:07 -0500 (EST) Date: Tue, 25 Mar 2003 05:53:08 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: IPsec WG Subject: Re: Do ipsec vendors care about privacy? In-Reply-To: <5.2.0.9.2.20030321203242.033dec00@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Whoever will make the decision here is free to ignore this discussion, or use it to make a more informed decision. I am sorry for the inconvenience but in my opinion the topic is worth the debate. Hugo On Fri, 21 Mar 2003, Russ Housley wrote: > Hugo: > > I repeat: The working group co-chairs in combination with the document > editor need to make a decision concerning the magnitude of the changes. If > it is the least bit onerous, then this should not be done. It is not a > requirement, and we are already overdue on delivery. > > We need to hear from the chairs before proceeding with this discussion. I > think that we have given them adequate information to make the decision. I > hope that they will make it in the next few days. > > Russ > > At 09:10 AM 3/21/2003 +0200, Hugo Krawczyk wrote: > > > >On Thu, 20 Mar 2003, Russ Housley wrote: > > > > > Hugo: > > > > > > > > > I wrote: > > > >Hugo, in my view it is too late to be raising a question that will cause > > > >major surgery on the document. It is time to fix things that are broken, > > > >make the document internally consistent, and publish it. I do not > > think it > > > >is time to raise new requirements. > > > >I agree: no time for major surgery on the document. > >But not too late for a change that takes 1-5 minutes editorial work > >On the other hand, I admit that there are some operational issues > >that are not fully resolved in my proposals and need more input from > >people that care and know better. If this does not come on time > >to make the document before being closed then we will not have it. > > > >On the other hand, user's id protection in the remote access protocol of > >ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec > >developers (on the list and outside the list). So giving the opprtunity to > >this substantial improvement if it comes at little cost and on time is a > >reasonable thing to do. > > > >In any case, ,I raised the issue and two possible solutions, but I am not > >the one that needs to decide if the WG is to adopt this or not. THOSE THAT > >CARE (in one way or another) SHOULD SPEAK UP. > > > >If there is not enough interest, then nothing needs to be done. > >At least it will be documented that this was a conscious decision rather > >than an overlook or the result of simple rushing. > >(This will help against future criticizers of the protocol that wil > >raise these issues in their papers...) > > > >I will be glad to see some technical discussion in the coming days > >if people care about having such discussions. Beyond that I am not going > >to insist (this is not an area of "correct cryptographic design" for > >which I personally care but rather one of engineering trade-offs that > >other understand better than me). > > > >Hugo > > > >PS: shoot the engineers but not the scientists :) > > > > > > > > You replied: > > > >This response really sounds as coming from the area director :) > > > >ANyway, I'd agree with you that this is too late if the change I proposed > > > >required "major surgery on the document". But it doesn't. > > > >Any of the proposed solutions takes a 1 minute editorial work, > > > >just moving one or two fields from one message to the other in section > > > >2.16 (and has no influence on other partts of the document). > > > > > > > >The question is not specification complexity which is null for this > > > >changes. ALso, it is not a performance issue. None of the proposed changes > > > >add round trips or computation (a message to the list from > > > >Antonio Forzieri might have given that impression but his > > > >modification of my proposal was unnecessary as he later stated himself). > > > > > > > >The only question is operational: can the responder (server) send the > > > >first EAP message before getting IDi? If this is the case (as it was in > > > >PIC and seems tobe agreed in some responses to my message) then we are > > > >done at no cost at all (solution 1). If not, we may need to go to > > > >solution 2 (in which the responder authenticates in message 2). Here the > > > >main operational issue, pointed out by Antonio, is that you need to have a > > > >way for the initiator to signal that he is requiring legacy > > > >authentication. > > > > > > > >So all we need is some feedback on the above operational issues, and then > > > >make a definitive decision about the right design/privacy trade-off. > > > >It should not put any delay on the closure of ikev2. > > > > > > The working group co-chairs in combination with the document editor > > need to > > > make a decision concerning the magnitude of the changes. If it is the > > > least bit onerous, then this should not be done. It is not a requirement, > > > and we are already overdue on delivery. > > > > > > It is time to warp this effort up. Fix anything that fails to meet the > > > requirements that have already been set by the working group. then make > > the > > > document internally consistent. Additional stuff can be dealt with by a > > > subsequent working group. > > > > > > Ted got it right at the beginning of the meeting. He said, "It is time to > > > shoot the engineers and ship the product." > > > > > > Russ > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Mar 24 20:17:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P4Hdg22647; Mon, 24 Mar 2003 20:17:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08917 Mon, 24 Mar 2003 22:46:06 -0500 (EST) Date: Tue, 25 Mar 2003 05:49:32 +0200 (IST) From: Hugo Krawczyk To: Tero Kivinen cc: IPsec WG Subject: Re: Do ipsec vendors care about privacy? In-Reply-To: <15997.61320.38373.418691@fireball.acr.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > First there is NO reason to go to the routability check if you are NOT under > > attack (this is true for the regular protocol, for the current EAP-based > > protocol, and for the modification I suggest). > > Some vendors refused to implement or use the aggressive mode of the > IKEv1, just because of it required you to do expensive operations > without ever knowing if there is anybody here. I would still guess, > that most implementations would require the return routability check > every time if this kind of protocol is used (at least I would in my > implementation). There is no reason to do that if the ipsec machine is not responding to EAP based exchanges. ANd even if the machine does respond to these exchanges there is no reason to use the cookie before the traffic reaches some "abnormality threshold". The comparison with IKEv1 is not valid since ikev1 did not even give you the option to use a "routability cookie". > > > The question is whether this modification opens a signifcant new DoS > > opportunity. Not really. > > Already now the responder needs to compute the DH key (something that CANNOT > > be done off-line) AND verify I's signature (relatively cheap for RSA and > > very expensive in the case of DSA) BEFORE it has authenticated the initiator. > > Yes, he needs to do that, but at that point he have seen that the > other end can see the packets sent to him, thus it makes spoofed > attacks impossible. The real attack is when someone sends lots of > spoofed packets each having fake IP address (so you cannot use IP > address to filter them out) and something that causes you to do work. > > The current protocol do not allow that. > The current protocol allows you to use the routability cookie when necessary. I agree that the opportunity for DoS seems more concrete in this variant of the protocol but this is not much more than an ilusion. If someone wants to DoS-attack a gateway it can do it in the regular protocol via state exhaustion and DH computation. The solution (or mitigation) is the same in both cases: the routability cookie. > > The fact that this computation cost happens at the reception of message 3 > > rather than after message 1 (in the modified solution) does not make the > > attack significantly harder to mount. > > It makes huge difference. So big, that I guess that most of the > implementations will still want to make it message 3, i.e they will do > the cookie exchange before allowing any of those operations. I hope they won't. It is not necessary. Do the cookie only when under attack (unusually high traffic). You need this mechanism in place irrespective of the EAP-specialized exchange > > > > - Also the generation of the signature is little bit harder, > > > as we are signing the packet we are also adding the > > > signature to. > > Indeed a litttle bit harder. Still nothing major. > > A possible specification using the current text would say something like: > > > > Payloads SAr1 and KEr are included as the first and second payload in > > message 2 (immediately after HDR), and the responder signs the octets > > starting with the first octet of the first SPI in the header of > > the second message and end with the last octet of the KEr payload in > > the second message. Appended to this (for purposes of computing the > > signature) is the initiator's nonce Ni (just the value, not the > > payload containing it) and the value prf(SK_ar, IDr). > > > > [Note: the last sentence is modified from ikev2-05 but this is pending > > revision by Charlie anyway] > > There might be other payloads than SAr1, and KEr in that packet, which > need to get protection also, so the text needs to be different. I know > it, as I wrote the other draft doing about the same thing for IKEv1... > > I didn't say it is impossble, I said it is little bit harder. I also > implemented my draft on IKEv1, and it required again little piece of > interesting code. It is not impossible, but it is not trivial either. It is nothing major and worth the pay off: user's privacy > > > > > - Also in that case we loose the "You Tarzan, Me Jane" for > > > those cases, because the responder needs to sign the > > > identity it is using in the packet 2, and the initiator is > > > sending the preferred ID to be used in packet 3. > > Right. The good news however is that when Jane is in the road she does > > not have to reveal her name before she really knows she is talking to > > Tarzan. (something like "You Tarzan? Me wonder...") > > And this means that security gateway does not know which kind > authentication it really should be using, if he have multiple > identities. The initiator will tell the gateway that it expects a EAP exchange, no need for the "me Jane" mechanism > > > It's all about tradeoffs and here I see privacy as the winner. Don't you? > > Actually no. I think You Tarzan, Me Jane is important feature > for the remote access cases too. Also I think protection against the > polling attack is more important than protection against active attack > to initiators identity. Also this protection is not available when > doing the normal certificate based authentication, nor it is available > when doing the shared key authentication, why should it be there for > the EAP? Because remote access by users is the main scenario in which identity protection makes sense. We would be allowing the polling attack ONLY against gateways that act as EAP servers. These are fixed address gateways with no real need (or option) to hide their identities > > > As said above the Exchange Type can indicate that (or some other bit/octet in > > SAi) > > I do not like having more different exchanges, I would really like to > keep the one exchange model we currently have. I do not understand what the problem of having a different exchange type for EAP is. After all, even now, this is a different exchange (with different messages and flows) > > > > - The text currently says that if the EAP method creates > > > shared key it MUST be used to generate the AUTH payloads > > > using the shared secret method by both ends. If we move the > > > AUTH payload to point before the EAP finishes (or actually > > > before it starts), then we have to change this. I do not > > > know the actual effects of this change. > > There is no change here. This SECOND AUTH (with the EAP-derived key) > > by the responder (its definition and position in the protocol) are not > > affected by the changes I suggested. > > I didn't notice there was second AUTH before I started looking the EAP > stuff more because of the DHCP-over-IKE text. The current document do > nee more text about the second auth payload. > > > If you disagree with these views please let us know. This is an important > > exercise. It is needed to decide where we establish the trade-offs. > > I agree with two basic rules: do not mess with the non-EAP > > portions of ikev2 and do not delay finalization of ikev2 as a whole. > > Beyond that, I suggest that we consider user's privacy as a REAL issue in > > remote access scenatios and be prepared, if needed, to pay some moderate > > price for its inclusion. > > As an implementator I still think that these changes are not small, > and they do add more complexity to the system (as an toolkit vendor we > do need to support almost all of the features, so I cannot just ignore > this case because it does not concern me :-). > -- We are in the trade-off business. You have valid points about the fact that "nothing is for free". But weighting all the pro's and con's I see user's identity privacy in the EAP eachange as a sufficient reason to incur in these not-really-major costs (I am sure you will manage to offer your toolkits even in this case, and you may even sell more of these since people will love to protect the privacy of their identities when in the move...) Personally, ,I believe that even a possible extra round trip is worth the added privacy, but we do not even need the extra round. Hugo > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Mon Mar 24 20:56:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P4uEg23956; Mon, 24 Mar 2003 20:56:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09079 Mon, 24 Mar 2003 23:32:43 -0500 (EST) Date: Tue, 25 Mar 2003 06:36:26 +0200 (IST) From: Hugo Krawczyk To: Uri Blumenthal cc: IPsec WG Subject: Re: AES-based PRF for IKEv2 In-Reply-To: <3E7D69FB.1080907@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri, Dave Wagner answered the main questions here. Essentially, I was not claiming that I know of an attack against this construction when you use AES, but rather that your claim that the pseudo-randomness of the output is ensured by AES being a family of pseudo-random permutations is incorrect. I do not know what assumptions will make this construction "provably secure", and I also don't know how you are going to get confidence on the fact that AES satisfies these assumptions. Moreover, ikev2 already offers a solution to the problem of how to get a prf key out of the DH key g^xy (see page 25 of the draft). And ikev2 does not really have a need to deal with too-short keys. The only places where this could potentially be an issue is when (1) you key the prf with Ni|Nr and (2) when authenticating with a pre-shared key. The first is solved by mandating the nonces to be of the length at least half of the key size (i.e. at least 64 bits each in the case of AES); the second by mandating the pre-shared key to be (at least) of the length of the prf key (i.e. 128 bits for AES). These are not only reasonable requirements, but without them you'd be weakening the protocol unnecessarily. As for using a password as a pre-shared key, that's the problem of an application doing so. Paswords SHOULD NOT be used as preshared keys. Whoever wants to use password authentication in the ikev2 setting, has the EAP extension of ikev2. Regarding the rationale of the derivation of the prf key SEEDKEY from the DH key g^xy in the ikev2 specification: this will be explained in more detail in the next version of the SIGMA paper. I provided some clues to the rationale in past postings. Basically, we are using a prf family in lieu of a family of pairwise independent hash functions (UH). If we used the latter then we could "provably" argue the security of KEYSEED. But then ikev2 implementers should also implement a real family of UH functions. Assuming that no one would want to do that I settled for the replacement of UH with a prf family. This does not give you a general provable construction (I can show pathological examples of prf's that do not behave as UH functions), yet it is plaussible that actual constructions of prfs (such as HMAC or AES) do achieve this property. And, in any case, it gives you a well defined "clue" as for what extra properties you are assuming. Hugo PS: there is more to say about these issues, but luckily this discussion seems to have moved already to the more appropriate forum of the cfrg (the IETF's "cryptography forum research group"). On Sun, 23 Mar 2003, Uri Blumenthal wrote: > Hugo Krawczyk wrote: > >>SECURITY PROPERTIES. > >> > >>A block cipher being a Pseudo Random Permutation, if the > >>S parameter is secret, the following hold true: > > Let me clarify this statement. An [unbroken] block cipher > is a FAMILY of pseudo random permutations INDEXED by the > key. So for any GIVEN key this block cipher is a pseudo > random permutation. It is assumed to be true for AES. > > >> - output of (3) is pseudo-random. > >> - output of (5) is pseudo-random. > > > > Unfortunately, this is incorrect. > > I would like to see it shown for AES. > > I.e. please show how you can distinguish the AES output > of (3) and/or of (5) from a random string, if you don't > know S, but know the rest of the input. > > Also, I would like to see how you can distinguish AES > output from random 128-bit string, if you know the > relation between the key bits and some of the > input bits, know the rest of input bits, but > don't know the key. > > > > If all what you assume about the block cipher is that it > > is a pseudorandom permutation then to be able to get a result > > as you state you need to assume that all the values used to key > > the block cipher are random (or pseudo-random, in the > > complexity-theoretic sense). > > Of course I also assume linearity of the key space. > > What other assumptions are necessary in your opinion? > > > > That means that you need to assume S to be secret (as you do) but also > > random (that you don't do) and of at least the length of the cipher's > > keys (what you don't do either). > > Please explain why S should be random. In all the literature I'm > aware of, all the analysis of block ciphers made no assumptions > about the key except being unknown to the adversary. > > > > Specifically one can build examples of perfectly secure > > pseudorandom permutations that will induce insecure outputs from (3) > > and (5). > > Very well - I'd like to see them for my education (so please > e-mail me an example) - but it doesn't seem to apply to AES. > > > > This was pointed out by Dave Wagner for the case in which S is > > too short, > > The adversary cannot know whether the key in use has any specific > property - such as being short, or having x zeroes as suffix. > After all, the bit string of all zeroes is as random as any > other string. > > And if the adversary has a good reason to assume that the key is > short - then nothing will help, because no matter what type of > transform you apply to that key, the key itself will remain > the weakest link and will be attacked by brute force. It > applies to any PRF, block cipher-based and hash-based. > > > > and one can also give examples in which S is longer than the key > > (but not uniformly distributed). > > Again, I think it does not apply to AES (because of its keyspace > properties) - but I personally would like to see an example > e-mailed to me. > > If you mean that knowing the properties of the key - such as > knowing in advance that the key is likely to have only 4 bytes > of "juice" and the rest filled with zeroes - makes this approach > insecure, I'll fully agree. And will add - in such a case there's > no way to secure it, because no matter what you do, I'll attack the > weakest link - the short key itself. > > > > Now, clearly, if you assume that the given value S is already a good > > random key for the prf then you do not need all the construction. > > You need a similar construction to mix in the nonces. And it > seems a good tradition to step further away from the generator > key... > > The approach I'm suggesting is taken directly from the Rijndael > submission to NIST (specifically the Hash and PRF sections). If > there are problems with it - why didn't somebody (you for > example :-) write something about it and publish? > > > > Finally, regarding the use of this method with a DH key S=g^{xy} as you > > suggest. In this case you'd take the first, say, 128 bits of g^{xy} as > > the key to the block cipher and the rest as data. Under which > > assumptions on DH and the block cipher you can claim the proposed > > key derivation to be secure? Note that the attacker knows g^x, g^y. > > The assumptions are: > > 1. Block cipher is a family of PRP indexed by the key. An unbroken > block cipher should satisfy this. > 2. Block cipher has linear keyspace (there is no class of weak keys), > so there is no specific property of the key that makes the cipher > weak. [we aren't discussing idiotic cases like using short keys > padded with known quantity, so the attacker has to search only > say 2^32 space because the rest is all 1's or all 0's.] > 3. It is practically impossible to determine more than a few bits of > g^xy when you know both g^x and g^y. > > If other assumptions are necessary to consider this approach secure, > please share them (and the justification behind) with me. > > Thanks! > > From owner-ipsec@lists.tislabs.com Tue Mar 25 00:16:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P8G4g09843; Tue, 25 Mar 2003 00:16:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09504 Tue, 25 Mar 2003 02:42:46 -0500 (EST) From: "Yoav Nir" To: "'Ravi'" , "'Tero Kivinen'" Cc: , "'Yoav Nir'" Subject: RE: IKEv2: prepending four octets Date: Tue, 25 Mar 2003 09:44:47 +0200 Message-ID: <001201c2f2a2$698ae810$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3E800870.2020709@roc.co.in> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think that we should at least agree that a peer that only works with port 4500 such as Ravi describes should interoperate with all IKEv2 implementations. IOW an IKEv2 implementation must not assume that peers start the negotiations on port 500. Coding a Remote Access client like that is acceptable, since clients always initiate the first IKE negotiation. Gateways may initiate the negotiation on port 4500 when working with IKEv2 peers (in fact, this could be a recommendation at the SHOULD level), but they SHOULD also listen on port 500. -----Original Message----- From: Ravi [mailto:ravivsn@roc.co.in] Sent: Tuesday, March 25, 2003 9:43 AM To: Tero Kivinen Cc: ipsec@lists.tislabs.com; Yoav Nir Subject: Re: IKEv2: prepending four octets Hi, Tero Kivinen wrote: ravivsn@roc.co.in (Ravi) writes: So, we will not disturb these NAT devices to work on port 500 Since, IKEv2 is now building from scratch we shall standardise Port 4500 instead of 500.The non Zero in first four bytes indicates IPsec packets and Zeros indicate IKE packets. The problem with that is that it causes long timeout during the transition period, i.e if initiator supports both IKEv1 and IKEv2, it would start with IKEv2 to port 4500. The responder which only supports IKEv1, would not even see those packets, and the initiator would have to wait for the timeout (tens of seconds or even few minutes?) before falling back to IKEv1 and port 500. If the initiator starts with port 500 (with IKEv2 protocol) then the IKEv1 implement will see the packet, and hopefully it will send back notification INVALID-MAJOR-VERSION. There will be implementations out there that will not send that notification back, but for those who did this properly and will send the notification, can get rid of the extra timeout. I understand the reasoning. Thank you for this. But, to me it seems unnecessary complication. I feel, it is reasonable to wait until timeout and standardize one port for both NAT/No-NAT traversal. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. Ravi Kumar CH Trainee Research Associate Rendezevous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Tue Mar 25 06:35:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PEZBg17447; Tue, 25 Mar 2003 06:35:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10315 Tue, 25 Mar 2003 08:57:10 -0500 (EST) Message-ID: <3E800870.2020709@roc.co.in> Date: Tue, 25 Mar 2003 13:12:40 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen CC: ipsec@lists.tislabs.com, Yoav Nir Subject: Re: IKEv2: prepending four octets References: <3E798E13.5060307@roc.co.in> <15995.23453.745014.962250@tero.kivinen.iki.fi> Content-Type: multipart/alternative; boundary="------------050109060204010706030400" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------050109060204010706030400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Tero Kivinen wrote: >ravivsn@roc.co.in (Ravi) writes: > > >>So, we will not disturb these NAT devices to work on port 500 >>Since, IKEv2 is now building from scratch we shall standardise Port 4500 >>instead of 500.The non Zero in first >> four bytes indicates IPsec packets and Zeros indicate IKE packets. >> >> > >The problem with that is that it causes long timeout during the >transition period, i.e if initiator supports both IKEv1 and IKEv2, it >would start with IKEv2 to port 4500. The responder which only supports >IKEv1, would not even see those packets, and the initiator would have >to wait for the timeout (tens of seconds or even few minutes?) before >falling back to IKEv1 and port 500. > >If the initiator starts with port 500 (with IKEv2 protocol) then the >IKEv1 implement will see the packet, and hopefully it will send back >notification INVALID-MAJOR-VERSION. There will be implementations out >there that will not send that notification back, but for those who did >this properly and will send the notification, can get rid of the extra >timeout. > > I understand the reasoning. Thank you for this. But, to me it seems unnecessary complication. I feel, it is reasonable to wait until timeout and standardize one port for both NAT/No-NAT traversal. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Trainee Research Associate Rendezevous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------050109060204010706030400 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Tero Kivinen wrote: >ravivsn@roc.co.in (Ravi) writes: > >> >>So, we will not disturb these NAT devices to work on port 500 >>Since, IKEv2 is now building from scratch we shall standardise Port 4500 >>instead of 500.The non Zero in first >> four bytes indicates IPsec packets and Zeros indicate IKE packets. >> > > >The problem with that is that it causes long timeout during the >transition period, i.e if initiator supports both IKEv1 and IKEv2, it >would start with IKEv2 to port 4500. The responder which only supports >IKEv1, would not even see those packets, and the initiator would have >to wait for the timeout (tens of seconds or even few minutes?) before >falling back to IKEv1 and port 500. > >If the initiator starts with port 500 (with IKEv2 protocol) then the >IKEv1 implement will see the packet, and hopefully it will send back >notification INVALID-MAJOR-VERSION. There will be implementations out >there that will not send that notification back, but for those who did >this properly and will send the notification, can get rid of the extra >timeout. > I understand the reasoning. Thank you for this. But, to me it seems unnecessary complication. I feel, it is reasonable to wait until timeout and standardize one port for both NAT/No-NAT traversal. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Trainee Research Associate Rendezevous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------050109060204010706030400-- From owner-ipsec@lists.tislabs.com Tue Mar 25 06:37:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PEbBg17770; Tue, 25 Mar 2003 06:37:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10293 Tue, 25 Mar 2003 08:54:06 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3E7F8E36.30103@bell-labs.com> Disposition-Notification-To: Uri Blumenthal Date: Mon, 24 Mar 2003 18:01:10 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: David Wagner Original-CC: ipsec@lists.tislabs.com Subject: Re: AES-based PRF for IKEv2 References: <3E7A5234.5020504@bell-labs.com> <3E7B5AC7.8020100@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Wagner wrote: >>Not quite - a key with all zeroes is just as random as any other key. > > No, no, no. You're confused. Keys aren't random; it's the process > used to create them that might or might not be random. Yes, precisely. We shouldn't even have this argument - see below. We were simply misunderstanding each other. Read ahead. > A number like 000 isn't random, and it isn't uniformly distributed; > it makes no sense to try to attach the term "random" to simple numbers. Exactly. I simply was pointing out that the mere presence of large number of zeroes in the key means nothing either way from the randomness point of view. Let us review the assumptions and the algorithm. I'm taking a secret key. I'm using it to load the PRNG to crank out more pseudo random data. I've no idea about the structure of the key and whether its bits are correlated or not. I assume that their correlation is weak, but that's up to the user of the construct. In IKE this shouldn't be a problem, as DH output is believed to be "good enough" and "random enough". In other uses, which probably are of no interest to IPSEC WG, the key can be truly random, really bad, really long, really short - or anything n between. Depending on that, the security of the construct will be high or low, quite in compliance with the "manure in - manure out" principle. I might add that pretty much all the PRNG are subject to this principle as well - if your initial key is bad and falls into a known-to-the-adversary class (i.e. 6-character ASCII string), then no matter what algorithm you use, it will be broken. Also - the keying material is the same as in the existing PRF (HMAC). The processing is also very similar. SHA - the heart of HMAC - has much weaker built-in properties than AES. So how come you aren't happy with this, but are happy with that? What makes SHA closer to "random oracle" than AES? > The point is that we must look at the process used to create the key. > When using a PRP, that key-creation process must provide outputs that > are secret, random, and uniformly distributed on the cipher's keyspace. These are two different areas! One is whether the cipher is secure for any key from its keyspace. The other one is how much of the keyspace the key-supplying algorithm covers. I.e. what kind of structure the enciphering key has. The cipher itself is still "good", but for the adversary it became easier to determine what the key is, because of the structure it has (it doesn't cover the whole keyspace now). So it's not the "random key" as in "being produced by Random Number generator" - it's having no preimposed structure that allows the adversary to make assumptions about the key and thus cut his work effort. > The key-creation process you specified does not qualify: the last bit > of the AES key is much more likely to be 0 than to be 1, for instance. Not true. It may be true ONLY in the outside-of-IKE use when really somebdy decides to employ short keys. Not recommended practice anyway- but has (IMHO) to be specified for the sake of completeness. Nobody proposes implementing short keys in IKE. >>There are ciphers in use like that (especially in the military), >>but it is *assumed* that AES keyspace is linear. > > Assumed by whom? The assumption that AES is a secure PRP does *not* > guarantee that its keyspace is "linear" (whatever that means precisely). > And the standard security goal for block ciphers is that they be a > secure PRP. For the sake of this discussion - "linear keyspace" means there are no weak keys. Do you argue with this, and if so - what's your justification? For example DES has almost "linear keyspace" - only 4 weak keys and only 16 semi-weak ones, so the chance to hit them was very small. Some ciphers however have significant part of their (large!) keyspace "weak", for the purpose of non-reuse of the equipment by unauthorized parties (you're likely to pick a bad key, unless you're "initiated" and know to select them from a certain class). > As a result, among all unproven security properties, PRP-ness is > probably the property ttat we can have the most confidence in.) So let's stick to it. And until weak keys are found, I assume there are none - just like until an attack against Rijndael is found - I assume it holds unbroken. From owner-ipsec@lists.tislabs.com Tue Mar 25 10:33:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PIXag29535; Tue, 25 Mar 2003 10:33:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10992 Tue, 25 Mar 2003 13:04:27 -0500 (EST) Message-ID: <3E809C69.3060102@creeksidenet.com> Date: Tue, 25 Mar 2003 13:14:01 -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, charlie kaufman Subject: me tarzan- me jane suggested text change Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Per the SF discussion surrounding whether the ID payload must match the ID in a presented cert, I would like to add my vote for increased clarity. To do so, I believe the following text represents the spirit of the WG: In section 2.15, to the sentence that states: "Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload." Add the following" " The exact requirement for mapping the name in the ID payload to an acceptable key is a local matter and outside the scope of this document". Jeff From owner-ipsec@lists.tislabs.com Tue Mar 25 10:33:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PIXag29534; Tue, 25 Mar 2003 10:33:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10942 Tue, 25 Mar 2003 12:56:21 -0500 (EST) Message-Id: <200303251800.h2PI0Hof078292@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Yoav Nir" cc: "'Ravi'" , "'Tero Kivinen'" , ipsec@lists.tislabs.com Subject: Re: IKEv2: prepending four octets In-reply-to: Your message of Tue, 25 Mar 2003 09:44:47 +0200. <001201c2f2a2$698ae810$292e1dc2@YnirNew> Date: Tue, 25 Mar 2003 19:00:17 +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 think that we should at least agree that a peer that only works with port 4500 such as Ravi describes should interoperate with all IKEv2 implementations. => I agree. IOW an IKEv2 implementation must not assume that peers start the negotiations on port 500. => I agree. Coding a Remote Access client like that is acceptable, since clients always initiate the first IKE negotiation. Gateways may initiate the negotiation on port 4500 when working with IKEv2 peers (in fact, this could be a recommendation at the SHOULD level), but they SHOULD also listen on port 500. => I believe we should give at least a MAY to initiate over 500 and 4500, perhaps with a SHOULD for port 4500 if one knows there is a NAT and a SHOULD for port 500 if one knows there is no NAT. In fact, this is more in the scope of a BCP. About listening, I am in favor of a MUST for both 500 and 4500. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 25 10:47:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PIl0g29877; Tue, 25 Mar 2003 10:47:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11014 Tue, 25 Mar 2003 13:14:35 -0500 (EST) Message-ID: <3E809ECF.7070902@creeksidenet.com> Date: Tue, 25 Mar 2003 13:24:15 -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: Text suggestion on computing keymat for rekey Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To compute keymat for any SA, both sides need to agree on which side is initiator. While this is obvious for new SAs, the text is unclear about rekeys, eg if the original responder is the initiator of a rekey, which end is considered initiator of the of the new SA for puposes of computing keymat? After some SF hallway discussions, the general impression I got was that there is some value to keeping the original initiator as initiator of the rekeyed SA, (ie for management purposes this approach doesnt allow a rekey to hide which end was original initiator). As such, I propose adding the following text to the end of section 2.8: "For purposes of computing keying material for the rekeyed SA, the original initiator of the SA is to be considered initiator of the rekeyed SA." Jeff From owner-ipsec@lists.tislabs.com Tue Mar 25 11:47:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PJl1g05912; Tue, 25 Mar 2003 11:47:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11335 Tue, 25 Mar 2003 14:16:07 -0500 (EST) Message-Id: <200303251919.h2PJJKaj029079@thunk.east.sun.com> From: Bill Sommerfeld To: "jpickering@creeksidenet.com" cc: ipsec@lists.tislabs.com Subject: Re: Text suggestion on computing keymat for rekey In-Reply-To: Your message of "Tue, 25 Mar 2003 13:24:15 EST." <3E809ECF.7070902@creeksidenet.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 25 Mar 2003 14:19:20 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > "For purposes of computing keying material for the rekeyed SA, the > original initiator > of the SA is to be considered initiator of the rekeyed SA." I may well have been part of the same hallway discussion. One of the other conclusions that this group came to was that it was somewhere between extremely helpful and absolutely necessary to add an attribute in the negotiation which specifically called out *which* SA was being rekeyed/replaced. (All you'd need is the SPI of the previous SA). I hope this also isn't controversial. - Bill From owner-ipsec@lists.tislabs.com Tue Mar 25 12:52:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PKqKg07811; Tue, 25 Mar 2003 12:52:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11552 Tue, 25 Mar 2003 15:15:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3E809C69.3060102@creeksidenet.com> References: <3E809C69.3060102@creeksidenet.com> Date: Tue, 25 Mar 2003 15:17:39 -0500 To: "jpickering@creeksidenet.com" From: Stephen Kent Subject: Re: me tarzan- me jane suggested text change Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:14 PM -0500 3/25/03, jpickering@creeksidenet.com wrote: >Per the SF discussion surrounding whether the ID payload must match the ID >in a presented cert, I would like to add my vote for increased >clarity. To do so, >I believe the following text represents the spirit of the WG: > >In section 2.15, to the sentence that states: > >"Optionally, messages 3 and 4 MAY include a certificate, or >certificate chain providing evidence >that the key used to compute a digital signature belongs to the name >in the ID payload." > >Add the following" > >" The exact requirement for mapping the name in the ID payload to an >acceptable key is a local matter >and outside the scope of this document". > >Jeff I don't think the latter text helps, since it does not tell a peer whether the match is required or not, and thus interoperability problems will persist. I think Paul Hoffman made this point in his comments at the mic. Steve From owner-ipsec@lists.tislabs.com Tue Mar 25 13:13:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PLDEg08335; Tue, 25 Mar 2003 13:13:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11612 Tue, 25 Mar 2003 15:43:05 -0500 (EST) Message-ID: <3E80BFF7.3080607@kolumbus.fi> Date: Tue, 25 Mar 2003 22:45:43 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: Re: Secure remote access with IPsec References: <3E7881C1.1050507@cefriel.it> <15995.25907.497444.196791@tero.kivinen.iki.fi> In-Reply-To: <15995.25907.497444.196791@tero.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, your text looks good and I like this. I'm OK with notification approach. I also agree with your approach to require the routability test everytime. There are situations where you could avoid it, but imho SHOULD is the right keyword right now; folks that want to work out optimized signaling sequences can do the work on their or later to figure out in which cases you can actually leave it out. Finally, its good to allow the notification to be sent from either the old or the new address; the former may make sense when you know beforehand that you will move. Nits: - s/mobile-ip/mobility/ - s/can be send/can be sent/ - s/ip-address/IP-address/ (or IP address) Jari > 2.25 Explicit Address Updating > > For some cases there are needed for explicitly update the peer > address. This can be used to support mobile-ip, multihoming, and to > help SCTP support. The difference with implicit address updating, is > that in this case the other end can actually notify the other end > about the change in the address, and authenticate the new address (and > port). The explicit address update is done by sending > SOURCE-ADDRESS-CHANGED notification, having new port and ip-address > inside, to the other end. This notification can be send either using > the old or new address, but the sender MUST be able receive in the new > address before sending this out. > > When receiving the SOURCE-ADDRESS-CHANGED notification the IKE process > MUST check that the other end can receive the packets sent to new > address, by sending empty notification to the peer addres and port > given inside the notification (not the UDP outer address). When the > host requesting the change replies to that notification, and proofs > that it can actually receive packets sent to that address the actual > change should take effect. This change affects the IKE SA used to > receive the notification (i.e all future exchanges started on that IKE > SA will use this new address) and all child IPsec SAs created by this > IKE SA (i.e tunnel endpoint updated to new address). > > The reply to the original SOURCE-ADDRESS-CHANGED notification is sent > back to the address where it was received, as is also all other > requests, where reply is not yet sent (i.e they follow normal rule, > that the reply is sent back to the address where the packet > originated). Note, that all hosts are required to process this > notification while waiting for reply to their SOURCE-ADDRESS-CHANGED > notification (see section 2.3). > > This requires implementations to support mutating the already existing > SAs (one way to implement this is to atomically delete the SA and then > add it back with new information). Similar feature is also needed for > the implicit address updating needed for NAT traversal, where we need > to update the UDP encapsulation addresses and ports. > > ---------------------------------------------------------------------- > > Following text should be added to section 3.10.1 after > HTTP-CERT-LOOKUP-SUPPORTED: > > ---------------------------------------------------------------------- > > SOURCE-ADDRESS-CHANGED 24587 > > This notification is sent when the other end has changed > its IP-address and wants the responder of this > notification to update the IKE SA remote peer address and > port. When this notification is received the host MUST > do the dead peer detection against the address given in > this payload, and if that is successful then the IKE SA > peer address and all the child SA tunnel endpoint > addresses MUST be updated to new address. This > notification is not used in the NAT traversal case, as the > host behind NAT does not know when its address changes. > The data associated with this notification is 2 byte port > number and 4 or 16 byte IP-address. From owner-ipsec@lists.tislabs.com Tue Mar 25 14:48:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PMmFg12759; Tue, 25 Mar 2003 14:48:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11911 Tue, 25 Mar 2003 17:19:31 -0500 (EST) Message-Id: <200303252223.h2PMN6of079334@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Secure remote access with IPsec In-reply-to: Your message of Tue, 25 Mar 2003 22:45:43 +0200. <3E80BFF7.3080607@kolumbus.fi> Date: Tue, 25 Mar 2003 23:23:06 +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: Tero, your text looks good and I like this. I'm OK with notification approach. I also agree with your approach to require the routability test everytime. There are situations where you could avoid it, but imho SHOULD is the right keyword right now; folks that want to work out optimized signaling sequences can do the work on their or later to figure out in which cases you can actually leave it out. Finally, its good to allow the notification to be sent from either the old or the new address; the former may make sense when you know beforehand that you will move. => your position is not sound: if you allow an update for a future movement ("Finally, ...") then the mandatory routability check won't work. Regards Francis.Dupont@enst-bretagne.fr PS: it is too soon to discuss this, the urgent stuff is to have a good document for IKEv2 out, and we agreed to postpone the explicit update mechanism. From owner-ipsec@lists.tislabs.com Tue Mar 25 15:02:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PN2wg14116; Tue, 25 Mar 2003 15:02:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11949 Tue, 25 Mar 2003 17:35:37 -0500 (EST) Message-ID: <3E80DA5D.206@kolumbus.fi> Date: Wed, 26 Mar 2003 00:38:21 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Secure remote access with IPsec References: <200303252223.h2PMN6of079334@givry.rennes.enst-bretagne.fr> In-Reply-To: <200303252223.h2PMN6of079334@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > => your position is not sound: if you allow an update for > a future movement ("Finally, ...") then the mandatory routability > check won't work. Oh, I am assuming the routability test is still done with the new address. Just that the update source address can be chosen freely (either old or new). Granted, if you send the update you will have to be ready then or real soon to receive the test packet. But at least implementations have some freedom to figure out how to do this. And there are no specific reasons to prohibit this. Jari From owner-ipsec@lists.tislabs.com Tue Mar 25 15:36:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PNa4g15955; Tue, 25 Mar 2003 15:36:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12111 Tue, 25 Mar 2003 18:12:14 -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: Tue, 25 Mar 2003 15:14:58 -0800 To: Hugo Krawczyk , Uri Blumenthal From: Paul Hoffman / VPNC Subject: Re: AES-based PRF for IKEv2 Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:36 AM +0200 3/25/03, Hugo Krawczyk wrote: >Moreover, ikev2 already offers a solution to the problem of how to get a >prf key out of the DH key g^xy (see page 25 of the draft). >And ikev2 does not really have a need to deal with too-short keys. >The only places where this could potentially be an issue is when >(1) you key the prf with Ni|Nr and (2) when authenticating with a >pre-shared key. I'm confused by this statement. Where is the preshared key used in the SKEYSEED calculation in IKEv2? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 25 20:48:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2Q4mug26308; Tue, 25 Mar 2003 20:48:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12909 Tue, 25 Mar 2003 23:18:57 -0500 (EST) Date: Wed, 26 Mar 2003 06:22:35 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: IPsec WG Subject: Re: AES-based PRF 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 On Tue, 25 Mar 2003, Paul Hoffman / VPNC wrote: > At 6:36 AM +0200 3/25/03, Hugo Krawczyk wrote: > >Moreover, ikev2 already offers a solution to the problem of how to get a > >prf key out of the DH key g^xy (see page 25 of the draft). > >And ikev2 does not really have a need to deal with too-short keys. > >The only places where this could potentially be an issue is when > >(1) you key the prf with Ni|Nr and (2) when authenticating with a > >pre-shared key. > > I'm confused by this statement. Where is the preshared key used in > the SKEYSEED calculation in IKEv2? Preshared key is NOT used in the calculation of SKEYSEED. Sorry if my text gave the wrong impression. The only thing we need to make sure is that the ikev2 document will mandate a minimal length for the nonces Ni and Nr (each has to be at least of half the length of the prf), and a minimal size of the preshared key (which has to be at least of the length of the prf key). There is no reason that an implementation will not be able to meet these requirements. The only case in which this may happen is if someone tries to use a password as a preshared key. But that should be seen as a vioaltion of the purpose of pre-shared key mode. Especially in view that ikev2 explicitly supports password-based authentication methods through its EAP exchange. Also, now that we are back to "a la carte", one may want to clarify in the document that in case that ALice (the initiator) offers more than one prf, she has to send (in message 1) a nonce which is at least of half the length of the longest-key prf in her offer (for example: if she offers HMAC-SHA1 and AES-128 then she has to send a nonce of length 80 bits). Hugo > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Wed Mar 26 06:58:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QEwUg18052; Wed, 26 Mar 2003 06:58:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14066 Wed, 26 Mar 2003 09:29:19 -0500 (EST) Message-ID: <3E81B143.4010100@roc.co.in> Date: Wed, 26 Mar 2003 19:25:15 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Yoav Nir , "'Tero Kivinen'" , ipsec@lists.tislabs.com Subject: Re: IKEv2: prepending four octets References: <200303251800.h2PI0Hof078292@givry.rennes.enst-bretagne.fr> Content-Type: multipart/alternative; boundary="------------070801030609010104030304" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------070801030609010104030304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, May I know why ikev2 should listen on both 500 and 4500.?What purpose does it solve? In my view, we are complicating the protocol and implementation by doing this. If both IKEv1 and IKEv2 exist (most probably they exist as separate processes or tasks and it is easy if we let IKEv1 and V2 exist separately), ikev1 can listen on port 500 and ikev2 listen on 4500. On the initiating side, if it has both v1 and v2, first it can try contacting the responder with port 4500 i.e. IKEv2. If it does not get response in certain duration, it can assume that IKEV2 is not supported by the responder and it can fallback onto the ikev1 which sends packets onto port 500. Also implementation wise it makes it easy and ikev1 and ikev2 can come from two different vendors and typically TCP/IP stacks don't allow two sockets listening on same port. Francis Dupont wrote: > In your previous mail you wrote: > > I think that we should at least agree that a peer that only works with port > 4500 such as Ravi describes should interoperate with all IKEv2 > implementations. > >=> I agree. > > IOW an IKEv2 implementation must not assume that peers start the > negotiations on port 500. > >=> I agree. > > Coding a Remote Access client like that is > acceptable, since clients always initiate the first IKE negotiation. > Gateways may initiate the negotiation on port 4500 when working with IKEv2 > peers (in fact, this could be a recommendation at the SHOULD level), but > they SHOULD also listen on port 500. > >=> I believe we should give at least a MAY to initiate over 500 and 4500, >perhaps with a SHOULD for port 4500 if one knows there is a NAT and a SHOULD >for port 500 if one knows there is no NAT. In fact, this is more in the >scope of a BCP. About listening, I am in favor of a MUST for both 500 >and 4500. > >Regards > >Francis.Dupont@enst-bretagne.fr > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070801030609010104030304 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, May I know why ikev2 should listen on both 500 and 4500.?What purpose does it solve? In my view, we are complicating the protocol and implementation by doing this. If both IKEv1 and IKEv2 exist (most probably they exist as separate processes or tasks and it is easy if we let IKEv1 and V2 exist separately), ikev1 can listen on port 500 and ikev2 listen on 4500. On the initiating side, if it has both v1 and v2, first it can try contacting the responder with port 4500 i.e. IKEv2. If it does not get response in certain duration, it can assume that IKEV2 is not supported by the responder and it can fallback onto the ikev1 which sends packets onto port 500. Also implementation wise it makes it easy and ikev1 and ikev2 can come from two different vendors and typically TCP/IP stacks don't allow two sockets listening on same port. Francis Dupont wrote: > In your previous mail you wrote: > > I think that we should at least agree that a peer that only works with port > 4500 such as Ravi describes should interoperate with all IKEv2 > implementations. > >=> I agree. > > IOW an IKEv2 implementation must not assume that peers start the > negotiations on port 500. > >=> I agree. > > Coding a Remote Access client like that is > acceptable, since clients always initiate the first IKE negotiation. > Gateways may initiate the negotiation on port 4500 when working with IKEv2 > peers (in fact, this could be a recommendation at the SHOULD level), but > they SHOULD also listen on port 500. > >=> I believe we should give at least a MAY to initiate over 500 and 4500, >perhaps with a SHOULD for port 4500 if one knows there is a NAT and a SHOULD >for port 500 if one knows there is no NAT. In fact, this is more in the >scope of a BCP. About listening, I am in favor of a MUST for both 500 >and 4500. > >Regards > >Francis.Dupont@enst-bretagne.fr > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------070801030609010104030304-- From owner-ipsec@lists.tislabs.com Wed Mar 26 06:58:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QEwVg18065; Wed, 26 Mar 2003 06:58:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14042 Wed, 26 Mar 2003 09:26:15 -0500 (EST) Message-ID: <3E81232C.7020002@roc.co.in> Date: Wed, 26 Mar 2003 09:19:00 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "jpickering@creeksidenet.com" CC: ipsec@lists.tislabs.com, charlie kaufman Subject: Re: me tarzan- me jane suggested text change References: <3E809C69.3060102@creeksidenet.com> Content-Type: multipart/alternative; boundary="------------020108080603020002020809" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------020108080603020002020809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In my view, making ID check is local matter might result in deployment interoperability problem. I don't see any problem in making sure that both ID in the payload and ID in the certificate match with ID configured in the IKE policies. That is, all three have to be same. Does anybody see problem in comparing IDs and ensuring that they are same and making this mandatory? Thanks for your time jpickering@creeksidenet.com wrote: > > Per the SF discussion surrounding whether the ID payload must match > the ID > in a presented cert, I would like to add my vote for increased > clarity. To do so, > I believe the following text represents the spirit of the WG: > > In section 2.15, to the sentence that states: > > "Optionally, messages 3 and 4 MAY include a certificate, or > certificate chain providing evidence > that the key used to compute a digital signature belongs to the name > in the ID payload." > > Add the following" > > " The exact requirement for mapping the name in the ID payload to an > acceptable key is a local matter > and outside the scope of this document". > > Jeff > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020108080603020002020809 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit In my view, making ID check is local matter might result in deployment interoperability problem. I don't see any problem in making sure that both ID in the payload and ID in the certificate match with ID configured in the IKE policies. That is, all three have to be same. Does anybody see problem in comparing IDs and ensuring that they are same and making this mandatory? Thanks for your time jpickering@creeksidenet.com wrote: >Per the SF discussion surrounding whether the ID payload must match the ID >in a presented cert, I would like to add my vote for increased clarity. To do so, >I believe the following text represents the spirit of the WG: > >In section 2.15, to the sentence that states: > >"Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence >that the key used to compute a digital signature belongs to the name in the ID payload." > >Add the following" > >" The exact requirement for mapping the name in the ID payload to an acceptable key is a local matter >and outside the scope of this document". > >Jeff -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020108080603020002020809-- From owner-ipsec@lists.tislabs.com Wed Mar 26 06:59:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QEx0g18155; Wed, 26 Mar 2003 06:59:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14053 Wed, 26 Mar 2003 09:27:18 -0500 (EST) Message-ID: <3E81AD91.6010806@roc.co.in> Date: Wed, 26 Mar 2003 19:09:29 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: complication in ikev2 Content-Type: multipart/alternative; boundary="------------020408030906000000020403" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------020408030906000000020403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit May I know why ikev2 should listen on both 500 and 4500.?What purpose does it solve? In my view, we are complicating the protocol and implementation by doing this. If both IKEv1 and IKEv2 exist (most probably they exist as separate processes or tasks and it is easy if we let IKEv1 and V2 exist separately), ikev1 can listen on port 500 and ikev2 listen on 4500. On the initiating side, if it has both v1 and v2, first it can try contacting the responder with port 4500 i.e. IKEv2. If it does not get response in certain duration, it can assume that IKEV2 is not supported by the responder and it can fallback onto the ikev1 which sends packets onto port 500. Also implementation wise it makes it easy and ikev1 and ikev2 can come from two different vendors and typically TCP/IP stacks don't allow two sockets listening on same port. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020408030906000000020403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit May I know why ikev2 should listen on both 500 and 4500.?What purpose does it solve? In my view, we are complicating the protocol and implementation by doing this. If both IKEv1 and IKEv2 exist (most probably they exist as separate processes or tasks and it is easy if we let IKEv1 and V2 exist separately), ikev1 can listen on port 500 and ikev2 listen on 4500. On the initiating side, if it has both v1 and v2, first it can try contacting the responder with port 4500 i.e. IKEv2. If it does not get response in certain duration, it can assume that IKEV2 is not supported by the responder and it can fallback onto the ikev1 which sends packets onto port 500. Also implementation wise it makes it easy and ikev1 and ikev2 can come from two different vendors and typically TCP/IP stacks don't allow two sockets listening on same port. -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------020408030906000000020403-- From owner-ipsec@lists.tislabs.com Wed Mar 26 06:59:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QEx1g18166; Wed, 26 Mar 2003 06:59:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14054 Wed, 26 Mar 2003 09:27:23 -0500 (EST) Message-ID: <3E81AD0C.6090008@roc.co.in> Date: Wed, 26 Mar 2003 19:07:16 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "jpickering@creeksidenet.com" CC: ipsec@lists.tislabs.com, charlie kaufman Subject: Re: me tarzan- me jane suggested text change References: <3E809C69.3060102@creeksidenet.com> Content-Type: multipart/alternative; boundary="------------010402000005030701070105" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------010402000005030701070105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In my view, making ID check is local matter might result in deployment interoperability problem. I don't see any problem in making sure that both ID in the payload and ID in the certificate match with ID configured in the IKE policies. That is, all three have to be same. Does anybody see problem in comparing IDs and ensuring that they are same and making this mandatory? Thanks for your time jpickering@creeksidenet.com wrote: > > Per the SF discussion surrounding whether the ID payload must match > the ID > in a presented cert, I would like to add my vote for increased > clarity. To do so, > I believe the following text represents the spirit of the WG: > > In section 2.15, to the sentence that states: > > "Optionally, messages 3 and 4 MAY include a certificate, or > certificate chain providing evidence > that the key used to compute a digital signature belongs to the name > in the ID payload." > > Add the following" > > " The exact requirement for mapping the name in the ID payload to an > acceptable key is a local matter > and outside the scope of this document". > > Jeff > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------010402000005030701070105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit In my view, making ID check is local matter might result in deployment interoperability problem. I don't see any problem in making sure that both ID in the payload and ID in the certificate match with ID configured in the IKE policies. That is, all three have to be same. Does anybody see problem in comparing IDs and ensuring that they are same and making this mandatory? Thanks for your time jpickering@creeksidenet.com wrote: >Per the SF discussion surrounding whether the ID payload must match the ID >in a presented cert, I would like to add my vote for increased clarity. To do so, >I believe the following text represents the spirit of the WG: > >In section 2.15, to the sentence that states: > >"Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence >that the key used to compute a digital signature belongs to the name in the ID payload." > >Add the following" > >" The exact requirement for mapping the name in the ID payload to an acceptable key is a local matter >and outside the scope of this document". > >Jeff -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------010402000005030701070105-- From owner-ipsec@lists.tislabs.com Wed Mar 26 06:59:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QExJg18220; Wed, 26 Mar 2003 06:59:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14060 Wed, 26 Mar 2003 09:28:18 -0500 (EST) Message-ID: <3E81AE5D.7090301@roc.co.in> Date: Wed, 26 Mar 2003 19:12:53 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKEv2:limitation of 4k for UDP payload Content-Type: multipart/alternative; boundary="------------080406050904030402020804" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------080406050904030402020804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I understand this was discussed several times and I could not find clear answer. Please bear with me and I hope some body clarifies it for me. I have some practical problem where the one of TCP/IP stacks which I am working with has limitation of 4K for UDP payload. I understand, when certificate authentication is involved, IKE not only sends the certificate but also multiple CA certificates (if cross chaining is present). This might overshoot the 4K limit. We are trying to work with TCP/IP stack vendor to increase this. But I had this doubt and why UDP is chosen for IKE over TCP. If TCP is chosen, there is no limitation on the payload. It seems DNS RFC does this. It listens on both UDP and TCP port 53. Why can't IKEv2 also standardize both UDP and TCP port 4500? Thanks in advance -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------080406050904030402020804 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I understand this was discussed several times and I could not find clear answer. Please bear with me and I hope some body clarifies it for me. I have some practical problem where the one of TCP/IP stacks which I am working with has limitation of 4K for UDP payload. I understand, when certificate authentication is involved, IKE not only sends the certificate but also multiple CA certificates (if cross chaining is present). This might overshoot the 4K limit. We are trying to work with TCP/IP stack vendor to increase this. But I had this doubt and why UDP is chosen for IKE over TCP. If TCP is chosen, there is no limitation on the payload. It seems DNS RFC does this. It listens on both UDP and TCP port 53. Why can't IKEv2 also standardize both UDP and TCP port 4500? Thanks in advance -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------080406050904030402020804-- From owner-ipsec@lists.tislabs.com Wed Mar 26 07:29:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QFT4g20512; Wed, 26 Mar 2003 07:29:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14322 Wed, 26 Mar 2003 09:58:39 -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, 26 Mar 2003 07:01:28 -0800 To: Hugo Krawczyk From: Paul Hoffman / VPNC Subject: Re: AES-based PRF for IKEv2 Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:22 AM +0200 3/26/03, Hugo Krawczyk wrote: >Preshared key is NOT used in the calculation of SKEYSEED. >Sorry if my text gave the wrong impression. > >The only thing we need to make sure is that the ikev2 document will >mandate a minimal length for the nonces Ni and Nr (each has to be at least >of half the length of the prf), and a minimal size of the preshared key >(which has to be at least of the length of the prf key). OK, then I'm still confused. Why does the length of the preshared key have to be half the length of the prf key? Why are they linked at all? >There is no reason that an implementation will not be able to meet these >requirements. The only case in which this may happen is if someone tries >to use a password as a preshared key. Exactly. This is quite common in the real world. > But that should be seen as a >vioaltion of the purpose of pre-shared key mode. Especially in view that >ikev2 explicitly supports password-based authentication methods through >its EAP exchange. If the preshared key is only used for authentication, not key strength, it is not a violation of the spec for someone to have weak authentication. If using a password instead of a real preshared key weakens the key strength, we need to point that out very clearly in the text. (But I still don't see where that happens.) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 26 09:06:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QH6dg25075; Wed, 26 Mar 2003 09:06:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14736 Wed, 26 Mar 2003 11:28:59 -0500 (EST) Message-Id: <200303261309.h2QD8oxj002579@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Text suggestion on computing keymat for rekey In-reply-to: Your message of "Tue, 25 Mar 2003 14:19:20 EST." <200303251919.h2PJJKaj029079@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 26 Mar 2003 08:08:49 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: Bill> I may well have been part of the same hallway discussion. One of the Bill> other conclusions that this group came to was that it was somewhere Bill> between extremely helpful and absolutely necessary to add an Bill> attribute Bill> in the negotiation which specifically called out *which* SA was being Bill> rekeyed/replaced. (All you'd need is the SPI of the previous SA). Hugh Redelmeier proposed the term "channel identifier" to represent a long-lived number that uniquely identifies the communications. It does not change when things are rekeyed. I was thinking that 32-bits of low-grade random number was enough for both ends to "announce", with the long-term number being their concatenation. (Likely, lower IP address end first, since this may survive Init/responder roles easily) ] 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 iQCVAwUBPoGmX4qHRg3pndX9AQGUKwQAqxdfceGFWhOJ6Xdd93DBITARa1OHvuPv wS+H3itL/raF+RxrmqfsUIla1UBbIHRPjat/hMHtvs8ZgJmo9JIKxtJbZyCXHHNX D0eRx0gSpAD6K06n8DwfbOJYN/e6D5Hn098sHwjG963HC+nybJu50juEuRgaUscZ bKBswO/h5F8= =bJTH -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 26 09:23:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QHN8g25531; Wed, 26 Mar 2003 09:23:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14792 Wed, 26 Mar 2003 11:44:18 -0500 (EST) Message-ID: <3E81C38B.1060303@creeksidenet.com> Date: Wed, 26 Mar 2003 10:13:15 -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: Ravi CC: ipsec@lists.tislabs.com, charlie kaufman Subject: Re: me tarzan- me jane suggested text change References: <3E809C69.3060102@creeksidenet.com> <3E81232C.7020002@roc.co.in> Content-Type: multipart/alternative; boundary="------------070802020500030605040201" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------070802020500030605040201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ravi, I guess the concensus I heard was that there are at least 2 reasons why we dont want to require this match: 1) Current difficulties in cert creation. This means that some folks want to share a cert between multiple identities. 2) Once you have a cert, there is confusion about how you extract an identity from the cert, ie there are too many options for inserting an ID into a PKIX cert. The conclusion is that there needs to be some way for a cert recipient to say that a cert is acceptable to be used by the sending identity. BUT, the identities claimed in ID payload and cert need not match. This is equivalent to saying acceptability is a local matter. Since this is a confusing point to more than one, I was suggesting that it be clarified in the spec. I do not believe that adding clarity about intent leads to increased interoperability problems. Jeff Ravi wrote: > In my view, making ID check is local matter might result in > deployment interoperability problem. I don't see any problem > in making sure that both ID in the payload and ID in the > certificate match with ID configured in the IKE policies. > That is, all three have to be same. Does anybody see problem > in comparing IDs and ensuring that they are same and making > this mandatory? > > Thanks for your time > > > jpickering@creeksidenet.com wrote: > >> >> Per the SF discussion surrounding whether the ID payload must match >> the ID >> in a presented cert, I would like to add my vote for increased >> clarity. To do so, >> I believe the following text represents the spirit of the WG: >> >> In section 2.15, to the sentence that states: >> >> "Optionally, messages 3 and 4 MAY include a certificate, or >> certificate chain providing evidence >> that the key used to compute a digital signature belongs to the name >> in the ID payload." >> >> Add the following" >> >> " The exact requirement for mapping the name in the ID payload to an >> acceptable key is a local matter >> and outside the scope of this document". >> >> Jeff >> > > -- > > > The views presented in this mail are completely mine. The company is > not responsible for whatsoever. > ------------------------------------------------------------------------ > Ravi Kumar CH > Rendezvous On Chip (i) Pvt Ltd > Hyderabad, India > Ph: +91-40-2335 1214 / 1175 / 1184 > > ROC home page > > > --------------070802020500030605040201 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ravi, I guess the concensus I heard was that there are at least 2 reasons why we dont want to require this match: 1) Current difficulties in cert creation. This means that some folks want to share a cert between multiple identities. 2) Once you have a cert, there is confusion about how you extract an identity from the cert, ie there are too many options for inserting an ID into a PKIX cert. The conclusion is that there needs to be some way for a cert recipient to say that a cert is acceptable to be used by the sending identity. BUT, the identities claimed in ID payload and cert need not match. This is equivalent to saying acceptability is a local matter. Since this is a confusing point to more than one, I was suggesting that it be clarified in the spec. I do not believe that adding clarity about intent leads to increased interoperability problems. Jeff Ravi wrote: >In my view, making ID check is local matter might result in >deployment interoperability problem. I don't see any problem >in making sure that both ID in the payload and ID in the >certificate match with ID configured in the IKE policies. >That is, all three have to be same. Does anybody see problem >in comparing IDs and ensuring that they are same and making >this mandatory? > >Thanks for your time > >jpickering@creeksidenet.com wrote: >> >>Per the SF discussion surrounding whether the ID payload must match the ID >>in a presented cert, I would like to add my vote for increased clarity. To do so, >>I believe the following text represents the spirit of the WG: >> >>In section 2.15, to the sentence that states: >> >>"Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence >>that the key used to compute a digital signature belongs to the name in the ID payload." >> >>Add the following" >> >>" The exact requirement for mapping the name in the ID payload to an acceptable key is a local matter >>and outside the scope of this document". >> >>Jeff > >-- > > >The views presented in this mail are completely mine. The company is not responsible for whatsoever. > >---------- >Ravi Kumar CH >Rendezvous On Chip (i) Pvt Ltd >Hyderabad, India >Ph: +91-40-2335 1214 / 1175 / 1184 > >ROC home page > > --------------070802020500030605040201-- From owner-ipsec@lists.tislabs.com Wed Mar 26 10:07:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QI7Jg26926; Wed, 26 Mar 2003 10:07:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15002 Wed, 26 Mar 2003 12:31:27 -0500 (EST) Date: Wed, 26 Mar 2003 19:35:04 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: IPsec WG Subject: Re: AES-based PRF 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 see below On Wed, 26 Mar 2003, Paul Hoffman / VPNC wrote: > At 6:22 AM +0200 3/26/03, Hugo Krawczyk wrote: > >Preshared key is NOT used in the calculation of SKEYSEED. > >Sorry if my text gave the wrong impression. > > > >The only thing we need to make sure is that the ikev2 document will > >mandate a minimal length for the nonces Ni and Nr (each has to be at least > >of half the length of the prf), and a minimal size of the preshared key > >(which has to be at least of the length of the prf key). > > OK, then I'm still confused. Why does the length of the preshared key > have to be half the length of the prf key? Why are they linked at all? This time I am not taking responsibility for your confusion :) I said that the preshared key "has to be at least of the length of the prf key". ("half" was used for the nonces since we concatenate them for creating a key to the prf, not for the pre-shared key). And the reason we need to specify the above for the length of the preshared key is that we use it as an input to the prf (section 2.15, page 26 of ikev2-05) > > >There is no reason that an implementation will not be able to meet these > >requirements. The only case in which this may happen is if someone tries > >to use a password as a preshared key. > > Exactly. This is quite common in the real world. This is a wrong practice that ikev2 should not officially support (actually it should officially unsuport). Using passwords as pre-shared keys might have been forced upon applications before because ikev1 did not have any other method to support password-based authentication. IKEv2 does have this method. So whoever upgrades from ikev1 to ikev2 should also upgrade from low-entropy pre-shared key to EAO-based exchange (section 2.16 of ikev2-05) > > > But that should be seen as a > >vioaltion of the purpose of pre-shared key mode. Especially in view that > >ikev2 explicitly supports password-based authentication methods through > >its EAP exchange. > > If the preshared key is only used for authentication, not key > strength, it is not a violation of the spec for someone to have weak > authentication. I do not agree! Breaking authentication is a much easier (and realistic) way to BREAK the SECRECY property of the protocol than cryptanalyzing the DH, the PRF or encryption functions. > If using a password instead of a real preshared key > weakens the key strength, we need to point that out very clearly in > the text. (But I still don't see where that happens.) > OK. Please ask Charlie to add to the security considerations section the something like: "The strength of the key exchanged via IKEv2 is not stronger (for the sake of authentication and secrecy) than the strength of the authentication method used in the protocol. This is the case for the signature-based authentication, the pre-shared key authentication, and the EAP methods. In particular, applications that use low-entropy keys (such as passwords) for authentication should use one of the EAP methods, and must not use the low-entropy key as a preshared secret. Doing the latter opens the protocol to dictionary attacks that compromise the strength of authentication and of the exchanged keys." Hugo > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Wed Mar 26 11:19:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QJJvg02340; Wed, 26 Mar 2003 11:19:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15294 Wed, 26 Mar 2003 13:45:30 -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, 26 Mar 2003 10:41:00 -0800 To: Hugo Krawczyk From: Paul Hoffman / VPNC Subject: Re: AES-based PRF for IKEv2 Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:35 PM +0200 3/26/03, Hugo Krawczyk wrote: >I said that the preshared key "has to be at least of the length of the prf >key". ("half" was used for the nonces since we concatenate them for >creating a key to the prf, not for the pre-shared key). Right. >And the reason we need to specify the above for the length of the >preshared key is that we use it as an input to the prf (section 2.15, >page 26 of ikev2-05) It is *part* of the input: it is concatenated with 17 bytes of ASCII text. The secret/password doesn't have to be at least the length of the prf key, it has to be at least the length of the prf key minus 17 bytes. If the prf key has to be 128 bits, then the secret/password can be of any length, yes? Also, don't all prf functions that we allow do padding? In 2.15, I see the sentence "The pre-shared key SHOULD contain as much randomness as the strongest key being negotiated." but I think it should say "unpredictability" instead of "randomness". Of course, we need to warn about the authentication problems with using passwords or easily-predictable preshared secrets (such as short random strings instead of long random strings), and we should explain that they can lead to man-in-the-middle attacks but not passive attacks. > > >There is no reason that an implementation will not be able to meet these >> >requirements. The only case in which this may happen is if someone tries >> >to use a password as a preshared key. >> >> Exactly. This is quite common in the real world. > >This is a wrong practice that ikev2 should not officially support >(actually it should officially unsuport). How are you going to enforce your proposed rule? Each side is supposed to somehow deduce that the preshared key that they agreed to is not a password? We should not specify rules that cannot be enforced by implementations. >Using passwords as pre-shared keys might have been forced upon >applications before because ikev1 did not have any other method to support >password-based authentication. IKEv2 does have this method. So whoever >upgrades from ikev1 to ikev2 should also upgrade from low-entropy >pre-shared key to EAO-based exchange (section 2.16 of ikev2-05) Yes, they should. And we should encourage them to do so, probably in section 2.15. But we cannot force them to. > > > But that should be seen as a >> >vioaltion of the purpose of pre-shared key mode. Especially in view that >> >ikev2 explicitly supports password-based authentication methods through >> >its EAP exchange. >> >> If the preshared key is only used for authentication, not key >> strength, it is not a violation of the spec for someone to have weak >> authentication. > >I do not agree! Breaking authentication is a much easier (and >realistic) way to BREAK the SECRECY property of the protocol than >cryptanalyzing the DH, the PRF or encryption functions. This is only true for man-in-the-middle attacks, not passive attacks, yes? We need to be clear here. > > If using a password instead of a real preshared key >> weakens the key strength, we need to point that out very clearly in >> the text. (But I still don't see where that happens.) >> > >OK. Please ask Charlie to add to the security considerations section the >something like: > >"The strength of the key exchanged via IKEv2 is not stronger (for the sake of >authentication and secrecy) than the strength of the authentication method >used in the protocol. s/no stronger/no stronger against man-in-the-middle attacks/ > This is the case for the signature-based >authentication, the pre-shared key authentication, and the EAP methods. >In particular, applications that use low-entropy keys (such as passwords) >for authentication should use one of the EAP methods, and must not use the >low-entropy key as a preshared secret. Doing the latter opens the protocol >to dictionary attacks that compromise the strength of authentication and >of the exchanged keys." ... against man-in-the-middle attacks. If we are going to say this, we *have* to explain why using passwords under EAP is better than using them as preshared secrets. Typical implementers will not figure this out and are therefore likely to mess it up. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 26 22:45:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2R6jQg01470; Wed, 26 Mar 2003 22:45:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA16579 Thu, 27 Mar 2003 00:55:49 -0500 (EST) Subject: Re: IKEv2:limitation of 4k for UDP payload From: Vinay K Nallamothu To: Ravi Cc: ipsec@lists.tislabs.com In-Reply-To: <3E81AE5D.7090301@roc.co.in> References: <3E81AE5D.7090301@roc.co.in> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 27 Mar 2003 11:36:37 +0530 Message-Id: <1048745198.1187.70.camel@vinay.royalchallenge.com> Mime-Version: 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 2003-03-26 at 19:12, Ravi wrote: > and why UDP is chosen for IKE over TCP. Just rewording one of the earlier discussion: One of the design requirements is transport protocol independence because of which IKE can not assume about the reliable streaming capabilities of the transport layer such as TCP. This seems to be the reason why UDP was chosen over TCP. But this does not stop from implementing IKE over TCP. In fact few implementations already do this. For e.g: Check Point FW-1 NG FP3 You can find the original discussion at http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html vinay From owner-ipsec@lists.tislabs.com Thu Mar 27 00:29:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2R8TOg15870; Thu, 27 Mar 2003 00:29:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16876 Thu, 27 Mar 2003 02:56:30 -0500 (EST) From: "Yoav Nir" To: "'Vinay K Nallamothu'" , "'Ravi'" Cc: Subject: RE: IKEv2:limitation of 4k for UDP payload Date: Thu, 27 Mar 2003 09:58:28 +0200 Message-ID: <009201c2f436$a7b036f0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1048745198.1187.70.camel@vinay.royalchallenge.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That Check Point implements it is nice, if you have a Check Point client. This does not add interoperability, which is the main concern of the IKE document. I don't think we can standardize of TCP as a MUST requirement, because many TCP stacks are vulnerable to DoS attacks. It would be nice, though, to have an optional IKE over TCP. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vinay K Nallamothu Sent: Thursday, March 27, 2003 8:07 AM To: Ravi Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2:limitation of 4k for UDP payload On Wed, 2003-03-26 at 19:12, Ravi wrote: > and why UDP is chosen for IKE over TCP. Just rewording one of the earlier discussion: One of the design requirements is transport protocol independence because of which IKE can not assume about the reliable streaming capabilities of the transport layer such as TCP. This seems to be the reason why UDP was chosen over TCP. But this does not stop from implementing IKE over TCP. In fact few implementations already do this. For e.g: Check Point FW-1 NG FP3 You can find the original discussion at http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html vinay From owner-ipsec@lists.tislabs.com Thu Mar 27 01:04:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2R94Wg19860; Thu, 27 Mar 2003 01:04:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17032 Thu, 27 Mar 2003 03:38:43 -0500 (EST) From: "Yoav Nir" To: "'Ravi'" , Subject: RE: IKEv2:limitation of 4k for UDP payload Date: Thu, 27 Mar 2003 10:42:02 +0200 Message-ID: <009301c2f43c$bdc5b0e0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E81AE5D.7090301@roc.co.in> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ravi, The problem with IKE over TCP is that the TCP connection is terminated at the end of the negotiation. If the initiator is behind a NAT device, then the responder loses the ability to negotiate a new CHILD-SA with it, because the mapping in the NAT device is immediately lost. With UDP, it is possible to keep the mapping alive by sending an occasional packet. So, when using IKE over TCP you need to assume one of the following: - no NAT, or - only one side initiates all negotiations Both of these are hard to stomach. Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ravi Hi, I understand this was discussed several times and I could not find clear answer. Please bear with me and I hope some body clarifies it for me. I have some practical problem where the one of TCP/IP stacks which I am working with has limitation of 4K for UDP payload. I understand, when certificate authentication is involved, IKE not only sends the certificate but also multiple CA certificates (if cross chaining is present). This might overshoot the 4K limit. We are trying to work with TCP/IP stack vendor to increase this. But I had this doubt and why UDP is chosen for IKE over TCP. If TCP is chosen, there is no limitation on the payload. It seems DNS RFC does this. It listens on both UDP and TCP port 53. Why can't IKEv2 also standardize both UDP and TCP port 4500? Thanks in advance -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Thu Mar 27 06:11:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2REBHg16842; Thu, 27 Mar 2003 06:11:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17735 Thu, 27 Mar 2003 08:42:21 -0500 (EST) Message-ID: <3E82CB48.1050207@roc.co.in> Date: Thu, 27 Mar 2003 15:28:32 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "jpickering@creeksidenet.com" CC: ipsec@lists.tislabs.com, charlie kaufman Subject: Re: me tarzan- me jane suggested text change References: <3E809C69.3060102@creeksidenet.com> <3E81232C.7020002@roc.co.in> <3E81C38B.1060303@creeksidenet.com> Content-Type: multipart/alternative; boundary="------------010407070505090700010909" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------010407070505090700010909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I understand this now better. But one question: You mentioned that there are several options for inserting ID in PKIX certificate ( I am sorry I don't have much knowledge of PKIX, I will read it through though later). But, once the node gets the peer certificate, I think ID is the only way for the node to identify the certificate. In this case, I assume that node has to extract the ID from the certificate for making decision whether to accept the peer or not. So, a node should have intelligence of extracting the ID OR IDs from the certificate. If the ID in the payload and ID of the certificates can be different, then the IKE node has to have mapping between 0the ID payload and certificate ID(s), which could be extra configuration. It is not a problem and I wanted to make sure that my understanding is correct. Thanks jpickering@creeksidenet.com wrote: > > Ravi, > > I guess the concensus I heard was that there are at least 2 reasons > why we dont > want to require this match: > > 1) Current difficulties in cert creation. This means that some folks > want to share > a cert between multiple identities. > 2) Once you have a cert, there is confusion about how you extract an > identity from > the cert, ie there are too many options for inserting an ID into a > PKIX cert. > > The conclusion is that there needs to be some way for a cert recipient > to say that > a cert is acceptable to be used by the sending identity. BUT, the > identities claimed in > ID payload and cert need not match. This is equivalent to saying > acceptability is a local > matter. Since this is a confusing point to more than one, I was > suggesting that it be clarified > in the spec. I do not believe that adding clarity about intent leads > to increased > interoperability problems. > > Jeff > > > Ravi wrote: > >>In my view, making ID check is local matter might result in >>deployment interoperability problem. I don't see any problem >>in making sure that both ID in the payload and ID in the >>certificate match with ID configured in the IKE policies. >>That is, all three have to be same. Does anybody see problem >>in comparing IDs and ensuring that they are same and making >>this mandatory? >> >>Thanks for your time >> >> >> >> jpickering@creeksidenet.com wrote: >> >>> >>> Per the SF discussion surrounding whether the ID payload must match >>> the ID >>> in a presented cert, I would like to add my vote for increased >>> clarity. To do so, >>> I believe the following text represents the spirit of the WG: >>> >>> In section 2.15, to the sentence that states: >>> >>> "Optionally, messages 3 and 4 MAY include a certificate, or >>> certificate chain providing evidence >>> that the key used to compute a digital signature belongs to the name >>> in the ID payload." >>> >>> Add the following" >>> >>> " The exact requirement for mapping the name in the ID payload to an >>> acceptable key is a local matter >>> and outside the scope of this document". >>> >>> Jeff >>> >> >> -- >> >> >> The views presented in this mail are completely mine. The company is >> not responsible for whatsoever. >> ------------------------------------------------------------------------ >> Ravi Kumar CH >> Rendezvous On Chip (i) Pvt Ltd >> Hyderabad, India >> Ph: +91-40-2335 1214 / 1175 / 1184 >> >> ROC home page >> >> >> > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------010407070505090700010909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I understand this now better. But one question: You mentioned that there are several options for inserting ID in PKIX certificate ( I am sorry I don't have much knowledge of PKIX, I will read it through though later). But, once the node gets the peer certificate, I think ID is the only way for the node to identify the certificate. In this case, I assume that node has to extract the ID from the certificate for making decision whether to accept the peer or not. So, a node should have intelligence of extracting the ID OR IDs from the certificate. If the ID in the payload and ID of the certificates can be different, then the IKE node has to have mapping between 0the ID payload and certificate ID(s), which could be extra configuration. It is not a problem and I wanted to make sure that my understanding is correct. Thanks jpickering@creeksidenet.com wrote: >Ravi, > >I guess the concensus I heard was that there are at least 2 reasons why we dont >want to require this match: > >1) Current difficulties in cert creation. This means that some folks want to share >a cert between multiple identities. >2) Once you have a cert, there is confusion about how you extract an identity from >the cert, ie there are too many options for inserting an ID into a PKIX cert. > >The conclusion is that there needs to be some way for a cert recipient to say that >a cert is acceptable to be used by the sending identity. BUT, the identities claimed in >ID payload and cert need not match. This is equivalent to saying acceptability is a local >matter. Since this is a confusing point to more than one, I was suggesting that it be clarified >in the spec. I do not believe that adding clarity about intent leads to increased >interoperability problems. > >Jeff > > >Ravi wrote: >> >>In my view, making ID check is local matter might result in >>deployment interoperability problem. I don't see any problem >>in making sure that both ID in the payload and ID in the >>certificate match with ID configured in the IKE policies. >>That is, all three have to be same. Does anybody see problem >>in comparing IDs and ensuring that they are same and making >>this mandatory? >> >>Thanks for your time >> >>jpickering@creeksidenet.com wrote: >>> >>>Per the SF discussion surrounding whether the ID payload must match the ID >>>in a presented cert, I would like to add my vote for increased clarity. To do so, >>>I believe the following text represents the spirit of the WG: >>> >>>In section 2.15, to the sentence that states: >>> >>>"Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence >>>that the key used to compute a digital signature belongs to the name in the ID payload." >>> >>>Add the following" >>> >>>" The exact requirement for mapping the name in the ID payload to an acceptable key is a local matter >>>and outside the scope of this document". >>> >>>Jeff >> >>-- >> >> >>The views presented in this mail are completely mine. The company is not responsible for whatsoever. >> >>---------- >>Ravi Kumar CH >>Rendezvous On Chip (i) Pvt Ltd >>Hyderabad, India >>Ph: +91-40-2335 1214 / 1175 / 1184 >> >>ROC home page >> >> -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------010407070505090700010909-- From owner-ipsec@lists.tislabs.com Thu Mar 27 06:11:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2REBOg16860; Thu, 27 Mar 2003 06:11:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17729 Thu, 27 Mar 2003 08:41:23 -0500 (EST) Message-ID: <3E82C6E6.9020503@roc.co.in> Date: Thu, 27 Mar 2003 15:09:50 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir CC: "'Vinay K Nallamothu'" , ipsec@lists.tislabs.com Subject: Re: IKEv2:limitation of 4k for UDP payload References: <009201c2f436$a7b036f0$292e1dc2@YnirNew> Content-Type: multipart/alternative; boundary="------------030804060902090909000308" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------030804060902090909000308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit You are right that, unless some text is present either as SHOULD or MUST and clarification text indicating how TCP can be used, then there would be interoperable problems. Since, it is not well defined, I am going ahead with IKEv2 implementation using UDP. Thank you for your answers. Yoav Nir wrote: >That Check Point implements it is nice, if you have a Check Point client. >This does not add interoperability, which is the main concern of the IKE >document. > >I don't think we can standardize of TCP as a MUST requirement, because many >TCP stacks are vulnerable to DoS attacks. It would be nice, though, to have >an optional IKE over TCP. > >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vinay K Nallamothu >Sent: Thursday, March 27, 2003 8:07 AM >To: Ravi >Cc: ipsec@lists.tislabs.com >Subject: Re: IKEv2:limitation of 4k for UDP payload > > >On Wed, 2003-03-26 at 19:12, Ravi wrote: > > >>and why UDP is chosen for IKE over TCP. >> >> >Just rewording one of the earlier discussion: > >One of the design requirements is transport protocol independence >because of which IKE can not assume about the reliable streaming >capabilities of the transport layer such as TCP. This seems to be the >reason why UDP was chosen over TCP. > >But this does not stop from implementing IKE over TCP. In fact few >implementations already do this. For e.g: Check Point FW-1 NG FP3 > >You can find the original discussion at >http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html > >vinay > > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------030804060902090909000308 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit You are right that, unless some text is present either as SHOULD or MUST and clarification text indicating how TCP can be used, then there would be interoperable problems. Since, it is not well defined, I am going ahead with IKEv2 implementation using UDP. Thank you for your answers. Yoav Nir wrote: >That Check Point implements it is nice, if you have a Check Point client. >This does not add interoperability, which is the main concern of the IKE >document. > >I don't think we can standardize of TCP as a MUST requirement, because many >TCP stacks are vulnerable to DoS attacks. It would be nice, though, to have >an optional IKE over TCP. > >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vinay K Nallamothu >Sent: Thursday, March 27, 2003 8:07 AM >To: Ravi >Cc: ipsec@lists.tislabs.com >Subject: Re: IKEv2:limitation of 4k for UDP payload > > >On Wed, 2003-03-26 at 19:12, Ravi wrote: > >> >>and why UDP is chosen for IKE over TCP. >> > >Just rewording one of the earlier discussion: > >One of the design requirements is transport protocol independence >because of which IKE can not assume about the reliable streaming >capabilities of the transport layer such as TCP. This seems to be the >reason why UDP was chosen over TCP. > >But this does not stop from implementing IKE over TCP. In fact few >implementations already do this. For e.g: Check Point FW-1 NG FP3 > >You can find the original discussion at >http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html > >vinay > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------030804060902090909000308-- From owner-ipsec@lists.tislabs.com Thu Mar 27 06:13:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RED2g17012; Thu, 27 Mar 2003 06:13:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17728 Thu, 27 Mar 2003 08:41:22 -0500 (EST) Message-ID: <3E82C5FB.5000504@roc.co.in> Date: Thu, 27 Mar 2003 15:05:55 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vinay K Nallamothu CC: ipsec@lists.tislabs.com, Yoav Nir Subject: Re: IKEv2:limitation of 4k for UDP payload References: <3E81AE5D.7090301@roc.co.in> <1048745198.1187.70.camel@vinay.royalchallenge.com> Content-Type: multipart/alternative; boundary="------------080103060602060002090802" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------080103060602060002090802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank for your response. If the checkpoint also works on TCP, how does it interoperate. How does the peer know whether it can use TCP or UDP? Since, there is no protocol support, I presume that initiator knows that peer support TCP based IKE via out-of-band way. If TCP is used A. Is it assumed that each transaction happens in one single TCP session i.e command and response happen in one TCP session. This is required as there could be NAT devices in between. B. More transactions can happen in one single TCP session. C. Notify messages are two types. One type is in response to some message and other is sent in unsolicited way. In case of first type, it needs to use same TCP session. In second case, it can send by creating new TCP session. Is there any work going on defining OR clarifying how TCP can be used with IKE? Thanks in advance. Ravi Vinay K Nallamothu wrote: >On Wed, 2003-03-26 at 19:12, Ravi wrote: > > >>and why UDP is chosen for IKE over TCP. >> >> >Just rewording one of the earlier discussion: > >One of the design requirements is transport protocol independence >because of which IKE can not assume about the reliable streaming >capabilities of the transport layer such as TCP. This seems to be the >reason why UDP was chosen over TCP. > >But this does not stop from implementing IKE over TCP. In fact few >implementations already do this. For e.g: Check Point FW-1 NG FP3 > >You can find the original discussion at >http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html > >vinay > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------080103060602060002090802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thank for your response. If the checkpoint also works on TCP, how does it interoperate. How does the peer know whether it can use TCP or UDP? Since, there is no protocol support, I presume that initiator knows that peer support TCP based IKE via out-of-band way. If TCP is used A. Is it assumed that each transaction happens in one single TCP session i.e command and response happen in one TCP session. This is required as there could be NAT devices in between. B. More transactions can happen in one single TCP session. C. Notify messages are two types. One type is in response to some message and other is sent in unsolicited way. In case of first type, it needs to use same TCP session. In second case, it can send by creating new TCP session. Is there any work going on defining OR clarifying how TCP can be used with IKE? Thanks in advance. Ravi Vinay K Nallamothu wrote: >On Wed, 2003-03-26 at 19:12, Ravi wrote: > >> >>and why UDP is chosen for IKE over TCP. >> > >Just rewording one of the earlier discussion: > >One of the design requirements is transport protocol independence >because of which IKE can not assume about the reliable streaming >capabilities of the transport layer such as TCP. This seems to be the >reason why UDP was chosen over TCP. > >But this does not stop from implementing IKE over TCP. In fact few >implementations already do this. For e.g: Check Point FW-1 NG FP3 > >You can find the original discussion at >http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html > >vinay > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------080103060602060002090802-- From owner-ipsec@lists.tislabs.com Thu Mar 27 06:22:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2REMlg17247; Thu, 27 Mar 2003 06:22:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17787 Thu, 27 Mar 2003 08:58:26 -0500 (EST) Message-ID: <3E8304FB.7080608@cefriel.it> Date: Thu, 27 Mar 2003 15:04:43 +0100 From: Antonio Forzieri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; it-IT; rv:1.3) Gecko/20030312 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: complication in ikev2 References: <3E81AD91.6010806@roc.co.in> In-Reply-To: <3E81AD91.6010806@roc.co.in> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2003 14:04:43.0147 (UTC) FILETIME=[D0CA7DB0:01C2F469] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ravi ha scritto: > May I know why ikev2 should listen on both 500 and 4500.?What purpose > does it solve? In my view, we are complicating the protocol and > implementation by doing this. If both IKEv1 and IKEv2 exist (most > probably they exist as separate processes or tasks and it is easy if we > let IKEv1 and V2 exist separately), ikev1 can listen on port 500 and > ikev2 listen on 4500. Agreed. I state this in a previous message, and I was given this response [COPY&PASTE BEGIN] => nothing but the current draft wording suggests that IKE_SA_INIT always runs over UDP 500. This should be fixed. [COPY&PASTE END] [SNIP] -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ICQ# 177683894 ------------------------------------------------ From owner-ipsec@lists.tislabs.com Thu Mar 27 06:58:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2REwKg20915; Thu, 27 Mar 2003 06:58:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18066 Thu, 27 Mar 2003 09:28:39 -0500 (EST) From: "Yoav Nir" To: Subject: RE: IKEv2:limitation of 4k for UDP payload Date: Thu, 27 Mar 2003 16:31:56 +0200 Message-ID: <00b001c2f46d$9f2bdde0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E82C5FB.5000504@roc.co.in> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The obvious was to encode it is to just send the packets the same way, except encapsulated in a TCP connection to port 500 instead of UDP. It requires no other change. Since I don't think we're planning to also have TCP encapsulation of IPsec, there's no real need for prepending four clear octets. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ravi Thank for your response. If the checkpoint also works on TCP, how does it interoperate. How does the peer know whether it can use TCP or UDP? Since, there is no protocol support, I presume that initiator knows that peer support TCP based IKE via out-of-band way. If TCP is used A. Is it assumed that each transaction happens in one single TCP session i.e command and response happen in one TCP session. This is required as there could be NAT devices in between. B. More transactions can happen in one single TCP session. C. Notify messages are two types. One type is in response to some message and other is sent in unsolicited way. In case of first type, it needs to use same TCP session. In second case, it can send by creating new TCP session. Is there any work going on defining OR clarifying how TCP can be used with IKE? Thanks in advance. Ravi Vinay K Nallamothu wrote: >On Wed, 2003-03-26 at 19:12, Ravi wrote: > >> >>and why UDP is chosen for IKE over TCP. >> > >Just rewording one of the earlier discussion: > >One of the design requirements is transport protocol independence >because of which IKE can not assume about the reliable streaming >capabilities of the transport layer such as TCP. This seems to be the >reason why UDP was chosen over TCP. > >But this does not stop from implementing IKE over TCP. In fact few >implementations already do this. For e.g: Check Point FW-1 NG FP3 > >You can find the original discussion at >http://www.s andelman.ottawa.on.ca/ipsec/1999/05/msg00014.html > >vinay > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ---------- Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Sun Mar 30 11:15:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2UJFHJM008658; Sun, 30 Mar 2003 11:15:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25722 Sun, 30 Mar 2003 13:28:34 -0500 (EST) Message-Id: <200303301832.h2UIWQPw004355@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: IDi/IDr distinction Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 30 Mar 2003 13:32:26 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- The IDi and IDr payloads in the exchanges use the same payload number (5). The IDr may presently be appear in message 3 along with IDi. I see no way to distinguish them except by the ordering. Further, it is apparent to me that it would be beneficial if a third party (i.e. tcpdump or another tool that was given access to the IKE-SA keys) could distinguish the payloads. I therefore propose that the IDr be given a distinct payload number. marajade-[ietf/id/ietf/ipsec] mcr 1051 %diff -u ikev2-05.txt ikev2-05-mcr.txt - --- ikev2-05.txt Mon Feb 24 08:47:20 2003 +++ ikev2-05-mcr.txt Sun Mar 30 13:31:35 2003 @@ -2660,7 +2660,10 @@ the Identification Type. The length of the Identification Data is computed from the size in the ID payload header. - - The payload type for the Identification Payload is five (5). + The payload type for the Identification Payload when used by the + initiator is five (5). + The payload type for the Identification Payload when used by the + responder is 25 (25). The following table lists the assigned values for the Identification Type field, followed by a description of the Identification Data ] 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 iQCVAwUBPoc4OIqHRg3pndX9AQGxigP+JuXlnfuFHfvHV353ayPJ+pSjDt4MU3JE kZk0JshmcBwYe/Esja7BV/qcm1wdXYQQxtKF4QlTzzH8W1CpsLe3eDIjHv/AN4qd I2XwWKub0SOmcBkLIb5MJDIoeUHtyoWqKRwgwMlbXSnRm3F7+0BOGPIziHKm/ELx yaIywpNmx4M= =25OB -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Mar 30 11:17:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2UJHCJM008735; Sun, 30 Mar 2003 11:17:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25728 Sun, 30 Mar 2003 13:42:33 -0500 (EST) Message-Id: <200303301846.h2UIkB1G004677@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: renumbering IKE payloads Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 30 Mar 2003 13:46:11 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I was looking for a table of payload numbers in ikev2-05. a) I would like to suggest that a table be created in section 3.2. b) I would like to suggest that the payload numbers used in IKEv2 be distinct from those used in IKEv1. This will make debugging code that has both v2 and v1 slightly easier. The field is an eight bit field. Perhaps some will feel that we would chew up too many values. I disagree on this. ] 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 iQCVAwUBPoc7cYqHRg3pndX9AQFu2AQA05506X76y9n+XfvwiRdB1jfGsl2+uUj4 qtKoRUTQbhlG0Hp9QV8zNFREUnuG0PE98BbiOLwARHaGIoqrAFOb0T8mug+t6bxQ tyVPHwcB6FLFFJPo6OOV/yROCoXd71mkerSgP5S3qWy7JmEQst9Eckm63MlYLe3y FpzA47XZa90= =V90P -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Mar 30 13:10:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2ULAOJM014730; Sun, 30 Mar 2003 13:10:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26041 Sun, 30 Mar 2003 15:30:25 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200303302033.h2UKXu017682@sydney.East.Sun.COM> Date: Sun, 30 Mar 2003 15:34:42 -0500 To: "Michael Richardson" , Reply-To: Subject: Re: IDi/IDr distinction 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 I agree with Michael. Seems confusing to have the same number for IDi and IDr. I can imagine scenarios in which we might want to have multiple of either IDi or IDr or both, or have one or both of them be optional, in which case ordering would no longer be sufficient to distinguish them. Furthermore, I don't think payload numbers are a sufficiently scarce resource that we need to conserve them. (I hope not...I'd hate to have to document 65,000 different ones). Radia "Michael Richardson" wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >The IDi and IDr payloads in the exchanges use the same payload number (5). > >The IDr may presently be appear in message 3 along with IDi. I see no >way to distinguish them except by the ordering. Further, it is apparent >to me that it would be beneficial if a third party (i.e. tcpdump or >another tool that was given access to the IKE-SA keys) could distinguish >the payloads. > >I therefore propose that the IDr be given a distinct payload number. > >marajade-[ietf/id/ietf/ipsec] mcr 1051 %diff -u ikev2-05.txt ikev2-05-mcr.txt >- --- ikev2-05.txt Mon Feb 24 08:47:20 2003 >+++ ikev2-05-mcr.txt Sun Mar 30 13:31:35 2003 >@@ -2660,7 +2660,10 @@ > the Identification Type. The length of the Identification Data > is computed from the size in the ID payload header. > >- - The payload type for the Identification Payload is five (5). >+ The payload type for the Identification Payload when used by the >+ initiator is five (5). >+ The payload type for the Identification Payload when used by the >+ responder is 25 (25). > > The following table lists the assigned values for the Identification > Type field, followed by a description of the Identification Data > >] 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 > >iQCVAwUBPoc4OIqHRg3pndX9AQGxigP+JuXlnfuFHfvHV353ayPJ+pSjDt4MU3JE >kZk0JshmcBwYe/Esja7BV/qcm1wdXYQQxtKF4QlTzzH8W1CpsLe3eDIjHv/AN4qd >I2XwWKub0SOmcBkLIb5MJDIoeUHtyoWqKRwgwMlbXSnRm3F7+0BOGPIziHKm/ELx >yaIywpNmx4M= >=25OB >-----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Mar 30 13:55:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2ULtlJM015463; Sun, 30 Mar 2003 13:55:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26160 Sun, 30 Mar 2003 16:11:36 -0500 (EST) Message-Id: <200303302115.h2ULFnaj021731@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: IDi/IDr distinction In-Reply-To: Your message of "Sun, 30 Mar 2003 13:32:26 EST." <200303301832.h2UIWQPw004355@marajade.sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Sun, 30 Mar 2003 16:15:49 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - The payload type for the Identification Payload is five (5). > + The payload type for the Identification Payload when used by the > + initiator is five (5). > + The payload type for the Identification Payload when used by the > + responder is 25 (25). do you mean "by" or "for" here? From owner-ipsec@lists.tislabs.com Sun Mar 30 15:22:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2UNMoJM019764; Sun, 30 Mar 2003 15:22:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26383 Sun, 30 Mar 2003 17:46:06 -0500 (EST) Message-Id: <200303302247.h2UMlLtw000371@fatty.lounge.org> To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: IDi/IDr distinction In-Reply-To: Your message of "Sun, 30 Mar 2003 13:32:26 EST." <200303301832.h2UIWQPw004355@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <369.1049064441.1@tibernian.com> Date: Sun, 30 Mar 2003 14:47:21 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This problem only exists because the ID payload is being overloaded to support the "me tarzan, you jane" feature. It's obvious modifications to the draft are needed to support this feature. Making distinct ID payloads for the initiator and responder is one way to do it. There would also need to be some explanitory text to describe how to implement this feature so that two independent implementations can interoperate. Another way would be to explain how to use the certificate request payload to support this feature. Viz: - Remove the text from 3.7 that says "the only form of certificate request currently defined is X.509 signing certificate" and make the last paragraph of 3.7 be the description of how to process a cert request when the type is X.509 signing certificate. - Add the following to 3.7: "When the type is 'PGP Certificate' (2), 'DNS Signed Key' (3), or 'Raw RSA Key' (11), the Certificate Request Paylod is used to inform the peer of the key the peer should use when authenticating. This is useful when the peer supports multiple identities. When used in this manner the 'Certification Authority' portion of the payload contains the relevant keying material depending on the 'Cert Encoding'". Dan. On Sun, 30 Mar 2003 13:32:26 EST you wrote > -----BEGIN PGP SIGNED MESSAGE----- > > The IDi and IDr payloads in the exchanges use the same payload number (5). > > The IDr may presently be appear in message 3 along with IDi. I see no > way to distinguish them except by the ordering. Further, it is apparent > to me that it would be beneficial if a third party (i.e. tcpdump or > another tool that was given access to the IKE-SA keys) could distinguish > the payloads. > > I therefore propose that the IDr be given a distinct payload number. > > marajade-[ietf/id/ietf/ipsec] mcr 1051 %diff -u ikev2-05.txt ikev2-05-mcr.txt > - --- ikev2-05.txt Mon Feb 24 08:47:20 2003 > +++ ikev2-05-mcr.txt Sun Mar 30 13:31:35 2003 > @@ -2660,7 +2660,10 @@ > the Identification Type. The length of the Identification Data > is computed from the size in the ID payload header. > > - - The payload type for the Identification Payload is five (5). > + The payload type for the Identification Payload when used by the > + initiator is five (5). > + The payload type for the Identification Payload when used by the > + responder is 25 (25). > > The following table lists the assigned values for the Identification > Type field, followed by a description of the Identification Data > > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architec >t[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device drive >r[ > ] 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 > > iQCVAwUBPoc4OIqHRg3pndX9AQGxigP+JuXlnfuFHfvHV353ayPJ+pSjDt4MU3JE > kZk0JshmcBwYe/Esja7BV/qcm1wdXYQQxtKF4QlTzzH8W1CpsLe3eDIjHv/AN4qd > I2XwWKub0SOmcBkLIb5MJDIoeUHtyoWqKRwgwMlbXSnRm3F7+0BOGPIziHKm/ELx > yaIywpNmx4M= > =25OB > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Mar 31 06:35:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VEZcJM018896; Mon, 31 Mar 2003 06:35:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28138 Mon, 31 Mar 2003 09:02:19 -0500 (EST) Message-Id: <200303311144.GAA02675@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-xcbc-mac-04.txt Date: Mon, 31 Mar 2003 06:44:50 -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 : The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, H. Herbert Filename : draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt Pages : 11 Date : 2003-3-28 A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-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-ciph-aes-xcbc-mac-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-ciph-aes-xcbc-mac-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-3-28142331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-28142331.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Mar 31 09:20:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VHKXJM029535; Mon, 31 Mar 2003 09:20:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28593 Mon, 31 Mar 2003 11:39:53 -0500 (EST) Message-Id: <200303311643.h2VGhYt3026365@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IDi/IDr distinction In-reply-to: Your message of "Sun, 30 Mar 2003 16:15:49 EST." <200303302115.h2ULFnaj021731@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 31 Mar 2003 11:43:34 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bill" == Bill Sommerfeld writes: >> - The payload type for the Identification Payload is five (5). + The >> payload type for the Identification Payload when used by the + >> initiator is five (5). + The payload type for the Identification >> Payload when used by the + responder is 25 (25). Bill> do you mean "by" or "for" here? Yes, "for" would better fit my intent. ] 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@lists.tislabs.com Mon Mar 31 10:32:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VIWeJM002046; Mon, 31 Mar 2003 10:32:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28888 Mon, 31 Mar 2003 12:53:23 -0500 (EST) Message-ID: <3E887DE6.60302@bell-labs.com> Date: Mon, 31 Mar 2003 12:41:58 -0500 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IDi/IDr distinction References: <200303302033.h2UKXu017682@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking wrote: > I agree with Michael. Seems confusing to have the same > number for IDi and IDr. I join too. From owner-ipsec@lists.tislabs.com Mon Mar 31 15:53:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VNrdJM019270; Mon, 31 Mar 2003 15:53:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29872 Mon, 31 Mar 2003 18:18:10 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: draft-ietf-ipsec-ikev2-06.txt To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Mon, 31 Mar 2003 18:09:38 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_03172003NP|March 17, 2003) at 03/31/2003 06:22:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've just sent a new draft: draft-ietf-ipsec-ikev2-06.txt to the Internet Drafts Editor with a copy to Paul Hoffman in hopes he will post it more quickly. The major change here is to revert the negotiation of cryptographic suites back to ala carte negotiation as agreed at the last meeting. I have not yet incorporated all the comments I got on -05, and none of the changes proposed recently. But I wanted to get people to review the ala carte negotiation before we went to last call. I made some arbitrary decisions, like leaving IPcomp and Tunnel Mode as separate and independent negotiations but including Extended Sequence Numbers in the negotiation. Please read and express opinions. I have incorporated some of the -05 comments where I thought they would be noncontroversial. People who submitted them SHOULD look at the new draft and see whether I addressed their concerns adequately. I will continue to go through those comments, but it wouldn't hurt if people whose comments are not yet addressed forward a copy of them to me to make sure I don't miss them. To get stability, we need to raise the bar on changes. I don't plan to make any more bits on the wire changes unless something there is clearly wrong or until a proposal is sent to the list and there is either unanimous agreement or Ted and Barbara declare consensus. With the next draft - intended to be last call - I'll apply that standard to editorial changes as well. Are we there yet? --Charlie From owner-ipsec@lists.tislabs.com Mon Mar 31 20:22:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h314MRJM002266; Mon, 31 Mar 2003 20:22:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA00460 Mon, 31 Mar 2003 22:50:32 -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: Mon, 31 Mar 2003 19:54:30 -0800 To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: draft-ietf-ipsec-ikev2-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:09 PM -0500 3/31/03, Charlie_Kaufman@notesdev.ibm.com wrote: >I've just sent a new draft: draft-ietf-ipsec-ikev2-06.txt to the Internet >Drafts Editor with a copy to Paul Hoffman in hopes he will post it more >quickly. Now posted as . I'll remove it when the draft appears in the official I-D directory. --Paul Hoffman, Director --VPN Consortium