From owner-ipsec@lists.tislabs.com Thu May 2 06:35:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42DZPa23779; Thu, 2 May 2002 06:35:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24453 Thu, 2 May 2002 08:37:53 -0400 (EDT) Message-Id: <200205021217.IAA17132@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-revised-identity-00.txt Date: Thu, 02 May 2002 08:17:48 -0400 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 : Revised Use of Identity in Successors to IKE Author(s) : P. Hoffman Filename : draft-ietf-ipsec-revised-identity-00.txt Pages : Date : 01-May-02 There is an opportunity in successor-to-IKE to fix two major problems that have plagued IKEv1: a misunderstanding about what is identity, and having to send certificates every time because you don't know if the other party already has your certificate. This proposal covers both topics at once because it turns out that they are related. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-revised-identity-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-revised-identity-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-revised-identity-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020501141313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-revised-identity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-revised-identity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020501141313.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu May 2 06:42:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42DgMa23996; Thu, 2 May 2002 06:42:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24454 Thu, 2 May 2002 08:37:53 -0400 (EDT) Message-Id: <200205021217.IAA17116@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-soi-features-00.txt Date: Thu, 02 May 2002 08:17:43 -0400 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 : Features of Proposed Successors to IKE Author(s) : P. Hoffman Filename : draft-ietf-ipsec-soi-features-00.txt Pages : Date : 01-May-02 This document describes many features of the proposals for the successor to IKEv1. The purpose of the document is to help the IPsec Working Group decide which features they want for the next protocol. The document focuses on how those features are instantiated in two proposals, IKEv2 and JFK, but other ideas for features and options are also included. Most of the material in this document comes from many of the authors of the JFK and IKEv2 proposals. This document is meant to help the Working Group choose which features it finds important for the successor to IKE. It should be short-lived and is not expected to become an RFC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-soi-features-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-soi-features-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-soi-features-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020501141303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-soi-features-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-soi-features-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020501141303.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu May 2 23:26:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g436QZa26139; Thu, 2 May 2002 23:26:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26724 Fri, 3 May 2002 01:29:53 -0400 (EDT) Message-Id: <5.1.0.14.0.20020503105853.009f8b80@172.16.1.10> X-Sender: lokeshnb@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 03 May 2002 11:05:52 +0530 To: ipsec@lists.tislabs.com From: Lokesh Subject: NAT-Traversal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I think NAT - Traversal fails if user configures IKE with Main mode and Authentication method as Preshared keys. Since user don't know if there is a NAT enroute, he might configure IKE with main mode and preshared keys, and now, if IKE tries to do NAT-traversal or IKE detects NAT, How to proceed? Thanks Lokesh From owner-ipsec@lists.tislabs.com Fri May 3 11:40:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Ieca17670; Fri, 3 May 2002 11:40:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28457 Fri, 3 May 2002 13:42:25 -0400 (EDT) Message-ID: <004501c1f2cb$9f261300$1cf22b42@mv.lucent.com> From: "David W. Faucher" To: Subject: Ikev2 IKE-SA rekey collision Date: Fri, 3 May 2002 12:54:23 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying: If there is a collision where both sides attempt to rekey an IKE-SA at the same time, which one ends up owning the child-SAs? It is possible to avoid this condition all together by simply using some value within the messages to determine who will "win" the rekey. For example, the side whose nonce has the greater value. Alternatively, one could use the initiator of the current IKE-SA to determine who "wins" the rekey. David From owner-ipsec@lists.tislabs.com Fri May 3 11:40:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Ieia17687; Fri, 3 May 2002 11:40:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28499 Fri, 3 May 2002 13:52:30 -0400 (EDT) Message-ID: <005201c1f2cd$2074d670$1cf22b42@mv.lucent.com> From: "David W. Faucher" To: Subject: Ikev2 Traffic Selector payload Date: Fri, 3 May 2002 13:05:34 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9: "The Responder is allowed to narrow the choices by selecting a subset of the traffic..." How do we avoid the situation where the reduced set does not encompass the selectors of the original packet on the initiator which started the negotiation? David From owner-ipsec@lists.tislabs.com Fri May 3 14:30:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43LUma23078; Fri, 3 May 2002 14:30:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28960 Fri, 3 May 2002 16:41:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 3 May 2002 16:44:03 -0400 To: annelies.van_moffaert@alcatel.be From: Stephen Kent Subject: Re: Please send me your GSEC presenation slides Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:51 PM +0200 4/30/02, annelies.van_moffaert@alcatel.be wrote: >Hi Steven and all, > >I read the new IP Authentication Header I-D and I have a small question or >remark about the multicast SAs. I saw that these are identified by the >destination IP address >and the SPI value and optionally, the protocol ID. >I'm not sure whether this rules out all possible ambiguity for SSM. For SSM >the IP destination address does not need to be unique (if I remember >correctly). A group session is in SSM identified by the pair (Source IP, >Destination IP) and it is possible that 2 different sources choose the same >SSM group address as Destination IP address. The group controller of each >will pick independently an SPI number. It's of course very unlikely but I >think that it is then strictly speaking possible to have the same (SPI, >Destination IP) pair for 2 different SSM sessions. In this case the >receiver cannot differentiate between two different SAs since they have the >same identification pair (Destion IP, SPI). Is this correct or did I >overlook something? > >Kind regards, > Lies Lies, I am not familiar with the spec for SSM, but from an IP perspective it is not generally feasible to have two distinct multicast groups with the same IP layer address, as then there would be ambiguity in terms of routing. Steve From owner-ipsec@lists.tislabs.com Fri May 3 18:10:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4419xa27964; Fri, 3 May 2002 18:09:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29456 Fri, 3 May 2002 20:16:35 -0400 (EDT) Message-Id: <200205040028.UAA29790@bcn.East.Sun.COM> Date: Fri, 3 May 2002 20:28:58 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Ikev2 Traffic Selector payload To: ipsec@lists.tislabs.com, dfaucher@lucent.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TX0tmci7U966qsSu1mYpEQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From my reading of the policy database, this wouldn't happen. Bob might narrow the choices in one of two cases: a) his policy excludes the range of the original packet, in which case Alice can't forward this packet to Bob no matter what she does, or b) his policy says only a single source/destination pair allowed on any SA, in which case he responds with notification #34-single-pair-required Radia **************** From: "David W. Faucher" Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9: "The Responder is allowed to narrow the choices by selecting a subset of the traffic..." How do we avoid the situation where the reduced set does not encompass the selectors of the original packet on the initiator which started the negotiation? David From owner-ipsec@lists.tislabs.com Fri May 3 18:24:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g441O1a28367; Fri, 3 May 2002 18:24:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29407 Fri, 3 May 2002 20:09:29 -0400 (EDT) Message-Id: <200205040021.UAA29773@bcn.East.Sun.COM> Date: Fri, 3 May 2002 20:21:42 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Ikev2 IKE-SA rekey collision To: ipsec@lists.tislabs.com, dfaucher@lucent.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: myObu6Xixd2doljyLG3Pzw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, one could have the same problem you point out, on establishment of the original IKE-SA. The spec does say that one should randomize the rekeying time to minimize the likelihood of duplicate SA's resulting from rekeying. I think your suggestion would work...if you notice you have duplicate SAs, then drop the one with the larger initiator nonce. With that rule, it also works if there's a collision on the initial IKE-SA (where there isn't a unique initiator, since each of the duplicate SAs would be initiated by one end). Radia David Faucher said: Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying: If there is a collision where both sides attempt to rekey an IKE-SA at the same time, which one ends up owning the child-SAs? It is possible to avoid this condition all together by simply using some value within the messages to determine who will "win" the rekey. For example, the side whose nonce has the greater value. Alternatively, one could use the initiator of the current IKE-SA to determine who "wins" the rekey. David From owner-ipsec@lists.tislabs.com Fri May 3 22:51:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g445pAa02842; Fri, 3 May 2002 22:51:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29899 Sat, 4 May 2002 00:57:56 -0400 (EDT) Message-ID: <001401c1f32a$01f194b0$b1323ac3@trustworks.com> From: "Valery Smyslov" To: "Radia Perlman - Boston Center for Networking" , , References: <200205040028.UAA29790@bcn.East.Sun.COM> Subject: Re: Ikev2 Traffic Selector payload Date: Sat, 4 May 2002 09:10:26 +0400 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 ----- Original Message ----- From: "Radia Perlman - Boston Center for Networking" To: ; Sent: Saturday, May 04, 2002 4:28 AM Subject: Re: Ikev2 Traffic Selector payload > From my reading of the policy database, this wouldn't happen. Bob might > narrow the choices in one of two cases: > a) his policy excludes the range of the original packet, in which > case Alice can't forward this packet to Bob no matter what she does, or What if initiator's proposal consists of one range, while responder's SPD requires this range to be splitted into two (or more) each protected by separate SA? For example: Initiator's SPD: 1.1.1.1-1.1.1.100 Responder's SPD: 1.1.1.1-1.1.1.50 & 1.1.1.51-1.1.1.100 In this case responder cannot narrow initiator's proposal because he/she doesn't know actual packet selector. > b) his policy says only a single source/destination pair allowed on any SA, > in which case he responds with notification #34-single-pair-required I think this is not very efficient way to require new negotiation (possibly including new DH computation) for this case. I think the better way would be to require for initiator to always include actual packet selector in his/her proposal. The simplest way to do it (without any changes in the protocol format) would be to simply state in the document, that the very first TS in initiator's TS payload MUST be selector of the packet that triggered this negotiation. This TS either MUST be encompassed in the (possibly narrowed) responder's TS payload or responder MUST return an error notification NO-PROPOSAL-CHOSEN. This actual packet TS will help responder to correctly choose (narrow) its TS. The cost is that initiator's message will be greater by 12 bytes (one TS with single address). I think it is tolerable. Regards, Valery Smyslov. > Radia > **************** > From: "David W. Faucher" > > Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9: > > "The Responder is allowed to narrow the choices > by selecting a subset of the traffic..." > > How do we avoid the situation where the reduced set > does not encompass the selectors of the original packet > on the initiator which started the negotiation? > > David > > > From owner-ipsec@lists.tislabs.com Sat May 4 12:54:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g44JsFa21096; Sat, 4 May 2002 12:54:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01254 Sat, 4 May 2002 14:58:37 -0400 (EDT) Date: Sat, 4 May 2002 12:10:38 -0700 (PDT) From: Jan Vilhuber To: Radia Perlman - Boston Center for Networking cc: , Subject: Re: Ikev2 IKE-SA rekey collision In-Reply-To: <200205040021.UAA29773@bcn.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 May 2002, Radia Perlman - Boston Center for Networking wrote: > Actually, one could have the same problem you point out, on establishment of > the original IKE-SA. The spec does say that one should randomize > the rekeying time to minimize the likelihood of duplicate > SA's resulting from rekeying. I think your suggestion > would work... I'm all for writing something like this into the spec. While it trivial to do and implement, it's impossible to retrofit without standard-support, since iut'll wind up being non-interoperable, if everyone does it differently (one picks the larger nonce, the other the smaller nonce, and you wind up with nothing). Any objections to writing this into the standard? jan >if you notice you have duplicate SAs, then drop > the one with the larger initiator nonce. With that rule, it also > works if there's a collision on the initial IKE-SA (where there > isn't a unique initiator, since each of the duplicate SAs would be initiated > by one end). > > Radia > > David Faucher said: > Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying: > > If there is a collision where both sides attempt to > rekey an IKE-SA at the same time, which one ends up > owning the child-SAs? > > It is possible to avoid this condition all together by > simply using some value within the messages to determine > who will "win" the rekey. For example, the side whose > nonce has the greater value. Alternatively, one could > use the initiator of the current IKE-SA to determine > who "wins" the rekey. > > David > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Sat May 4 18:45:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g451jDa29501; Sat, 4 May 2002 18:45:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01837 Sat, 4 May 2002 20:51:00 -0400 (EDT) Message-Id: <4.3.2.7.1.20020504175712.00ad7f00@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 04 May 2002 18:01:26 -0700 To: Jan Vilhuber , Radia Perlman - Boston Center for Networking From: Ramana Yarlagadda Subject: Re: Ikev2 IKE-SA rekey collision Cc: , In-Reply-To: References: <200205040021.UAA29773@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > > Actually, one could have the same problem you point out, on > establishment of > > the original IKE-SA. The spec does say that one should randomize > > the rekeying time to minimize the likelihood of duplicate > > SA's resulting from rekeying. I think your suggestion > > would work... > >I'm all for writing something like this into the spec. While it >trivial to do and implement, it's impossible to retrofit without >standard-support, since iut'll wind up being non-interoperable, if >everyone does it differently (one picks the larger nonce, the other >the smaller nonce, and you wind up with nothing). > >Any objections to writing this into the standard? > I think it is a good idea to make it standard. otherwise the re-keying is a major interoperable issue, if we try to avoid duplicate SAs. These duplicate SAs have some effect from the memory requirements point of view. > >if you notice you have duplicate SAs, then drop > > the one with the larger initiator nonce. With that rule, it also > > works if there's a collision on the initial IKE-SA (where there > > isn't a unique initiator, since each of the duplicate SAs would be > initiated > > by one end). > > > > > > David Faucher said: > > Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying: > > > > If there is a collision where both sides attempt to > > rekey an IKE-SA at the same time, which one ends up > > owning the child-SAs? > > > > It is possible to avoid this condition all together by > > simply using some value within the messages to determine > > who will "win" the rekey. For example, the side whose > > nonce has the greater value. Alternatively, one could > > use the initiator of the current IKE-SA to determine > > who "wins" the rekey. > > > > David > > > > > > -- >Jan Vilhuber vilhuber@cisco.com >Cisco Systems, San Jose (408) 527-0847 > >http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Sun May 5 09:11:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g45GB9L19274; Sun, 5 May 2002 09:11:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02881 Sun, 5 May 2002 10:51:22 -0400 (EDT) Message-ID: <3CD4CB14.EF621859@frohwein.xs4all.nl> Date: Sun, 05 May 2002 08:03:00 +0200 From: rob frohwein X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: PF_KEY socket code examples Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , Does anyone maybe has some code examples that demonstrate how to specify and read SPDs and SAa via socket( ....,PFKEY) ?? greetings Rob Frohwein From owner-ipsec@lists.tislabs.com Sun May 5 19:38:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g462chL01148; Sun, 5 May 2002 19:38:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03947 Sun, 5 May 2002 21:38:12 -0400 (EDT) Message-Id: <200205060144.JAA12727@cwcsun41.cwc.nus.edu.sg> Content-Type: text/plain; charset="utf-8" From: Parijat Mishra Reply-To: parijat@cwc.nus.edu.sg Organization: CWC To: rob frohwein , ipsec@lists.tislabs.com Subject: Re: PF_KEY socket code examples Date: Mon, 6 May 2002 09:45:51 +0800 X-Mailer: KMail [version 1.3.2] References: <3CD4CB14.EF621859@frohwein.xs4all.nl> In-Reply-To: <3CD4CB14.EF621859@frohwein.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sunday 05 May 2002 14:03, rob frohwein wrote: > Does anyone maybe has some code examples that demonstrate > how to specify and read SPDs and SAa via socket( ....,PFKEY) ?? The PFKEY interface as specified in RFC2367 only allows one to read/write to the SADB, not SPD. However, some IPSec implementations have created extensions to allow the specification of SPD entries as well. In any case, good starting points would be the FreeS/WAN project (www.freeswan.org) and the IPSec implementation withing the USAGI project (www.linux-ipv6.org). Both contain extensions to the base PFKEY interface to deal with SPDs, SA groups and stuff, and differ from each other. Another place should be the KAME project's implementation -- but I am not a BSD user and do not know much about it. -- Sincerely, Parijat Mishra R & D Engineer, Institute for Communications Research Tel: (65)68709353 From owner-ipsec@lists.tislabs.com Mon May 6 06:34:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46DYkL16348; Mon, 6 May 2002 06:34:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05482 Mon, 6 May 2002 08:39:10 -0400 (EDT) Message-ID: <001301c1f4fc$d60c70c0$1cf22b42@mv.lucent.com> From: "David Faucher" To: "Radia Perlman - Boston Center for Networking" , References: <200205040021.UAA29773@bcn.East.Sun.COM> Subject: Re: Ikev2 IKE-SA rekey collision Date: Mon, 6 May 2002 07:52:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I had thought about collisions on initial establishment but came to the conclusion that this is not a problem and may even be desired. - collision on initial establishment don't have the problems of a rekey collision because there are no child-SAs present. - two endpoints may choose to have logically separate IKE-SAs for different identities. David ----- Original Message ----- From: "Radia Perlman - Boston Center for Networking" To: ; Sent: Friday, May 03, 2002 7:21 PM Subject: Re: Ikev2 IKE-SA rekey collision | Actually, one could have the same problem you point out, on establishment of | the original IKE-SA. The spec does say that one should randomize | the rekeying time to minimize the likelihood of duplicate | SA's resulting from rekeying. I think your suggestion | would work...if you notice you have duplicate SAs, then drop | the one with the larger initiator nonce. With that rule, it also | works if there's a collision on the initial IKE-SA (where there | isn't a unique initiator, since each of the duplicate SAs would be initiated | by one end). | | Radia | | David Faucher said: | Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying: | | If there is a collision where both sides attempt to | rekey an IKE-SA at the same time, which one ends up | owning the child-SAs? | | It is possible to avoid this condition all together by | simply using some value within the messages to determine | who will "win" the rekey. For example, the side whose | nonce has the greater value. Alternatively, one could | use the initiator of the current IKE-SA to determine | who "wins" the rekey. | | David | | From owner-ipsec@lists.tislabs.com Mon May 6 06:42:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46DgQL16543; Mon, 6 May 2002 06:42:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05553 Mon, 6 May 2002 08:51:14 -0400 (EDT) Message-ID: <004601c1f4fe$694e3c50$1cf22b42@mv.lucent.com> From: "David Faucher" To: "Valery Smyslov" , "Radia Perlman - Boston Center for Networking" , References: <200205040028.UAA29790@bcn.East.Sun.COM> <001401c1f32a$01f194b0$b1323ac3@trustworks.com> Subject: Re: Ikev2 Traffic Selector payload Date: Mon, 6 May 2002 08:03:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with this, 12 bytes is a small price to pay for better interoperability. ----- Original Message ----- From: "Valery Smyslov" To: "Radia Perlman - Boston Center for Networking" ; ; Sent: Saturday, May 04, 2002 12:10 AM Subject: Re: Ikev2 Traffic Selector payload | ----- Original Message ----- | From: "Radia Perlman - Boston Center for Networking" | To: ; | Sent: Saturday, May 04, 2002 4:28 AM | Subject: Re: Ikev2 Traffic Selector payload | | | > From my reading of the policy database, this wouldn't happen. Bob might | > narrow the choices in one of two cases: | > a) his policy excludes the range of the original packet, in which | > case Alice can't forward this packet to Bob no matter what she does, or | | What if initiator's proposal consists of one range, while responder's | SPD requires this range to be splitted into two (or more) each protected | by separate SA? For example: | | Initiator's SPD: 1.1.1.1-1.1.1.100 | Responder's SPD: 1.1.1.1-1.1.1.50 & 1.1.1.51-1.1.1.100 | | In this case responder cannot narrow initiator's proposal | because he/she doesn't know actual packet selector. | | > b) his policy says only a single source/destination pair allowed on any | SA, | > in which case he responds with notification #34-single-pair-required | | I think this is not very efficient way to require new negotiation (possibly | including | new DH computation) for this case. | | I think the better way would be to require for initiator to always include | actual packet selector in his/her proposal. The simplest way to do it | (without any changes in the protocol format) would be to simply state in the | document, | that the very first TS in initiator's TS payload MUST be selector of the | packet that triggered this negotiation. This TS either MUST be encompassed | in the (possibly narrowed) responder's TS payload or responder MUST | return an error notification NO-PROPOSAL-CHOSEN. | | This actual packet TS will help responder to correctly choose (narrow) its | TS. | The cost is that initiator's message will be greater by 12 bytes (one | TS with single address). I think it is tolerable. | | Regards, | Valery Smyslov. | | | > Radia | > **************** | > From: "David W. Faucher" | > | > Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9: | > | > "The Responder is allowed to narrow the choices | > by selecting a subset of the traffic..." | > | > How do we avoid the situation where the reduced set | > does not encompass the selectors of the original packet | > on the initiator which started the negotiation? | > | > David | > | > | > | From owner-ipsec@lists.tislabs.com Mon May 6 08:47:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46FlWL20152; Mon, 6 May 2002 08:47:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05946 Mon, 6 May 2002 10:57:40 -0400 (EDT) From: "Jayant Shukla" To: "'Lokesh'" , Subject: RE: NAT-Traversal Date: Mon, 6 May 2002 08:06:37 -0700 Message-ID: <012a01c1f50f$9e9f7750$0100a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <5.1.0.14.0.20020503105853.009f8b80@172.16.1.10> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Lokesh > Hi all, > I think NAT - Traversal fails if user configures IKE with Main mode and > Authentication method as > Preshared keys. Yes it is a known problem with NAT-T and it cannot be fixed because the IP addresses are sent after the authentication is done. There is an issue with certificates as well because of the IKE packet fragmentation. My personal opinion is that the NAT-T solution should be abandoned as it is flawed. Over the last two years several problems have been pointed out and the NAT-T ID keeps changing. A short while ago it was heavily criticized (after it made it to last call) and has since been modified (again)! Even so, the latest draft has several problems. > How to proceed? We have a working and tested solution that overcomes the pre-shared key problem as well as the certificate problem. We are going to show our solution at N+I 2002, 7th -9th May. Nobody seems to notice, but NAT traversal can be achieved without modifying IKE and without tunneling IPsec data through the IKE port. Not relying on IKE for NAT Traversal makes it a much more general solution and can be used elsewhere as well. Plus, there are several other advantages like true end-to-end security and there is no need for nested tunnels. The same solution can be applied to IP and mobile IP networks. Try that with NAT-T! Regards, Jayant Booth # 7981, N+I Las Vegas 2002 www.trlokom.com From owner-ipsec@lists.tislabs.com Mon May 6 09:46:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46GkFL21629; Mon, 6 May 2002 09:46:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06153 Mon, 6 May 2002 12:03:03 -0400 (EDT) Message-Id: <200205061628.SAA19666@malraux.matranet.com> Date: Mon, 06 May 2002 18:15:09 +0200 From: Laurent Fabre User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010924 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKE and Legacy A.S Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm currently studying the support of legacy authentication system for our products. During my researches i came accross the following drafts : - draft-zegman-ike-hybrid-auth - draft-beaulieu-ike-xauth - draft-ietf-ipsra-pic Hopefully these are the only proposals for legacy AS support, only the third seems to be revelant as the two others are out-of-date, if not please correct me. Did anyone try to use PIC/EAP in his IKE implementation and would give feedback ? Best regards, -- #--------------------------------------------# # Laurent Fabre # # fabre@matranet.com # /\ ASCII ribbon # EADS, Matranet Product Group # \/ campaign # # /\ against # # / \ HTML email # # #--------------------------------------------# From owner-ipsec@lists.tislabs.com Mon May 6 11:04:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46I4qL23814; Mon, 6 May 2002 11:04:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06435 Mon, 6 May 2002 13:09:20 -0400 (EDT) Date: Mon, 6 May 2002 10:31:12 -0700 (PDT) From: Srinivasa Addepalli To: Laurent Fabre cc: ipsec@lists.tislabs.com Subject: Re: IKE and Legacy A.S In-Reply-To: <200205061628.SAA19666@malraux.matranet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ISAKMP configuration method and XAUTH drafts are implemented by good number of vendors to provide remote access and legacy authentication. You can find these standards in www.vpnc.org. Srini On Mon, 6 May 2002, Laurent Fabre wrote: > > Hi, > > I'm currently studying the support of legacy authentication system > for our products. During my researches i came accross the following drafts : > > - draft-zegman-ike-hybrid-auth > - draft-beaulieu-ike-xauth > - draft-ietf-ipsra-pic > > Hopefully these are the only proposals for legacy AS support, > only the third seems to be revelant as the two others are out-of-date, > if not please correct me. > > Did anyone try to use PIC/EAP in his IKE implementation and would > give feedback ? > > Best regards, > > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Mon May 6 12:00:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46J0mL25223; Mon, 6 May 2002 12:00:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06653 Mon, 6 May 2002 14:16:48 -0400 (EDT) Message-Id: <200205061815.g46IF7P17052@trpz.com> To: Laurent Fabre cc: ipsec@lists.tislabs.com Subject: Re: IKE and Legacy A.S In-Reply-To: Your message of "Mon, 06 May 2002 18:15:09 +0200." <200205061628.SAA19666@malraux.matranet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <832.1020708702.1@tibernian.com> Date: Mon, 06 May 2002 11:11:42 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There's another which is also out-of-date, CRACK. The expired draft follows. It's been implemented in the SymbianOS. The CRACK exchange is very similar to the PIC exchange, in fact if you put them down on paper payload for payload, message for message, you'd see they are almost identical. The difference is that CRACK is politically incorrect while PIC is politically correct. But to pay the price for political correctness you must go to the trouble of doing a mutually authenticated Diffie-Hellman exchange, then throw away all that authenticated and shared secret state, and do another mutually authenticated Diffie-Hellman exchange. CRACK just uses the first set of mutually authenticated secret state to form an IKE SA. Back when we were discussing protocol costs I posted this: Protocol Initiator Responder Latency ------------------------------------------------ PIC+IKE 1 signature 2 signatures 6.5-9 RTT + 1-2 RTs to legacy server 2 verifies 1 verify 2 DH agree 2 DH agree That's 22 messages worst case (DoS protection, token for legacy authentication is out-of-sync) or 14 messages best case. I haven't heard stories from the field about use of PIC but I'd be surprised if people are willing to pay that price just to use a legacy authentication method, especially if there are more efficient ways-- albeit one's that are frowned upon by those weilding political clubs^H^H^H^H^Hclout. I like PIC, especially its use of EAP instead of the roll-your-own method CRACK does. It's a nice way to get a certificate for a client and wean a corporation off token cards and onto a CA. It's just not particularly well suited for people that want to use an existing legacy infrastructure for authentication and who have no intention of going to client certificates any time soon. Dan. On Mon, 06 May 2002 18:15:09 +0200 you wrote > > Hi, > > I'm currently studying the support of legacy authentication system > for our products. During my researches i came accross the following drafts : > > - draft-zegman-ike-hybrid-auth > - draft-beaulieu-ike-xauth > - draft-ietf-ipsra-pic > > Hopefully these are the only proposals for legacy AS support, > only the third seems to be revelant as the two others are out-of-date, > if not please correct me. > > Did anyone try to use PIC/EAP in his IKE implementation and would > give feedback ? > > Best regards, > > -- > #--------------------------------------------# > # Laurent Fabre # > # fabre@matranet.com # /\ ASCII ribbon > # EADS, Matranet Product Group # \/ campaign > # # /\ against > # # / \ HTML email > # # > #--------------------------------------------# > ---------------------------- snip snip --------------------------------- Network Working Group D Harkins, D Piper INTERNET-DRAFT Nokia draft-ieft-ipsra-crack-01.txt July 14, 2000 IKE Challenge/Response for Authenticated Cryptographic Keys (Revised) Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table of Contents 1. Abstract......................................................2 2. Terms and Definitions.........................................2 2.1 Requirements Terminology and Notation.........................2 2.2 IKE Exchange Integration......................................2 2.3 IKE Authentication Method Definition..........................3 2.4 The Challenge/Response Payload (CHRE).........................3 2.5 LAM Types.....................................................4 2.6 LAM Attributes................................................5 3. The Protocol..................................................6 3.1 IKE Challenge/Response Abstract Representation................7 3.2 IKE Challenge/Response Failures...............................8 4. Legacy Authentication Method (LAM) Profiles...................9 4.1 LAM Profiles: Password........................................10 4.2 LAM Profiles: One-Time Password...............................11 4.3 LAM Profiles: Challenge/Response..............................12 4.4 LAM Profiles: SecurID.........................................15 Harkins, Piper Expires in 6 months [Page 1] INTERNET DRAFT IKE Challenge/Response July 14, 2000 4.5 LAM Profile Matrix............................................17 5. The IKE Challenge/Response Vendor ID Signature................17 6. Security Considerations.......................................18 Acknowledgments...................................................18 References........................................................18 Authors' Address..................................................19 1. Abstract This memo describes a new IKE authentication method ([HC98]) which provides for mutual authentication when one side is using a legacy- based secret-key authentication technique such as RADIUS, SecurID, or OTP and the other side is using public-key authentication, with optional digital certificates. The generic protocol described herein is an open-ended IKE Main Mode exchange ([HC98]). The result of this exchange is a mutually authenticated IKE security association ([HC98]). The keys that are derived from this SA are also authenticated and thereby convey this state to any SA's created from it for any other security service, such as IPSec [Pip98]. 2. Terms and Definitions 2.1 Requirements Terminology and Notation Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra96]. The notation of this memo is similar to [HC98]. Like [HC98] it uses payloads defined in [MSST98]. The notation for the new payload is: CHRE is the newly defined "challenge/response payload" To prevent confusion in the protocol diagrams (e.g. between the Diffie-Hellman public values), the client's payloads are sometimes post-fixed with "i", for "initiator", and the gateway's payloads are sometimes post-fixed with "r", for "responder". 2.2 IKE Exchange Integration This protocol is motivated by mobile IPSec-enabled clients who desire to use legacy authentication techniques instead of digital certificates. Therefore the parties to this exchange are a "client" and a "gateway". The client is always the initiator of this exchange and is assumed to be coming from an IP address that cannot be known a priori by the gateway. Harkins, Piper Expires in 6 months [Page 2] INTERNET DRAFT IKE Challenge/Response July 14, 2000 The protocol described in this memo is an IKE exchange using a newly defined IKE authentication method. All other attributes and their status from [HC98] are unaffected. Unless otherwise overridden by a specific requirement in this memo, all requirements in [HC98] exist in this memo. 2.3 IKE Authentication Method Definition The following new IKE authentication method value is defined for CRACK from the IKE private-use space (see Section 6): Authentication Mode Value ------------------- ----- IKE_A_CRACK 128 2.4 The Challenge/Response Payload (CHRE) This draft requires a new payload to carry new information unique to this exchange. The Challenge/Response payload is used to convey a challenge from the gateway to the client and is used by the client to respond to a challenge from the gateway. The Challenge/Response payload contains attributes denoting specific information conveyed from the client to the gateway and back. The actual legacy authentication method will determine the contents of this payload at the various points in the exchange. This payload consists of the ISAKMP generic header ([MSST98]) and a payload-specific body whose length is not fixed. The "Payload Length" in the generic header includes the length of the header itself. All fields labeled "RESERVED" MUST be filled with zero (0) prior to sending and each party to the exchange MUST verify that value on all payloads it is sent. 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 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! LAM Type ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ generic challenge/response blob ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The payload type for this payload is 128, which is taken from the ISAKMP private use space (see Section 6). The body of this payload may also contain attributes used to convey authentication information (see Section 4.2). Harkins, Piper Expires in 6 months [Page 3] INTERNET DRAFT IKE Challenge/Response July 14, 2000 The LAM Type field denotes the legacy authentication method (see Section 5) associated with the exchange. The LAM Type must be set in all CHRE payloads in an exchange. The LAM Type is selected by the initiator (client) and MUST be set in every CHRE payload to the same value throughout the exchange. 2.5 LAM Types Different legacy authentication methods are denoted by unique LAM type identifiers in the Challenge/Response payloads. The legacy authentication methods defined for this protocol are as follows: LAM Type Identifier Value ------------------- ----------- CRACK_PASSWORD 1 CRACK_OTP 2 CRACK_CHALLENGE_RESPONSE 3 CRACK_SECURID 4 5-32767 32768-65535 If the gateway is not configured to support the requested LAM type while processing the client's first CHRE payload, the gateway MUST terminate the exchange and MUST respond with an ISAKMP Notify (PROPOSAL-NOT- CHOSEN). A conformant gateway MUST support at least one of the specified LAM Types. A gateway MAY support more than one LAM Type and it's assumed that the choice of which LAM Types are supported is implementation specific and determined from local policy configuration, perhaps on a per-user basis based on the content of the first CHRE payload and its associated attributes. CRACK_PASSWORD specifies a simple username/password mechanism. It's used for any simple host-based password or one-way hash mechanism. It also useful for proxy-based password authentication schemes, like TACACS and RADIUS. CRACK_OTP specifies that a one-time password mechanism. It's useful for the S/KEY [Hal95] and OTP [HM96] schemes. CRACK_CHALLENGE_RESPONSE specifies a token-based challenge/response mechanism. It's useful for a wide variety of cryptographic tokens, typically based on DES. CRACK_SECURID specifies a SecurID mechanism. It's useful for the RSA SecurID system. The CRACK_SECURID closely resembles CRACK_CHALLENGE_RESPONSE. Harkins, Piper Expires in 6 months [Page 4] INTERNET DRAFT IKE Challenge/Response July 14, 2000 2.6 LAM Attributes The Challenge/Response payload contains attributes used to convey information between the client and the gateway authenticating the client. These are standard [MSST98] attribute payloads associated with the Challenge/Response payloads. The following LAM attributes are valid: Attribute Value Type ---------- ------- ------ CRACK_T_USERNAME 16390 variable CRACK_T_SECRET 16391 variable CRACK_T_DOMAIN 16392 variable CRACK_T_PIN 16393 variable CRACK_T_CHALLENGE 16394 variable CRACK_T_MESSAGE 16395 variable CRACK_T_FIN 16396 basic CRACK_T_USERNAME specifies the client user identity that's requesting authentication. The syntax and format of CRACK_T_USERNAME is specific to each LAM type. CRACK_T_SECRET specifies secret information the client sends in an attempt to authenticate, for instance a password or passcode. The syntax and format of CRACK_T_SECRET is specific to each LAM type. CRACK_T_DOMAIN specifies the domain or realm the client is requesting authentication credentials within. The syntax and format of CRACK_T_DOMAIN is specific to each LAM type. CRACK_T_PIN specifies the client's PIN. The syntax and format of CRACK_PIN is specific to each LAM type. CRACK_T_CHALLENGE specifies any challenge the gateway may choose to issue to the client. The syntax and format of CRACK_T_CHALLENGE is specific to each LAM type. CRACK_T_MESSAGE specifies an ASCII string to be displayed to the user upon receipt of the corresponding CHRE payload. CRACK_T_MESSAGE is valid for all LAM types. Upon receipt, the contents of CRACK_T_MESSAGES SHOULD be displayed to the client user, typically along with the CHRE challenge. CRACK_T_FIN specifies the server's response to the authentication exchange at all critical decision points specific to each LAM type. The following table defines the values for CRACK_T_FIN: Harkins, Piper Expires in 6 months [Page 5] INTERNET DRAFT IKE Challenge/Response July 14, 2000 Finish Types Value ------------ ----- RESERVED 0 CRACK_FIN_SUCCESS 1 CRACK_FIN_MORE 2 CRACK_FIN_SUCCESS indicates the gateway has successfully authenticated the client. This value successfully terminates the CRACK exchange. This value is legal for all LAM types. CRACK_FIN_MORE indicates the gateway requires an additional round- trip to authentication the client. This is only legal for LAM types which define its use. It MUST NOT be used unless defined in the corresponding LAM profile. 3. The Protocol This protocol uses digital signatures and proof of possession of a legacy secret to bind each party to the exchange as well as to the keying material that results from the exchange. This trust is acquired differently for the client and the gateway. The client trusts the gateway's public key either because it came from a certificate which is signed by a trusted certification authority or because the client trusts it by some out-of-band mechanism (for instance it is loaded into his policy store prior to hitting the road). The gateway trusts the client because the client has successfully authenticated himself using a legacy authentication method through a secure channel. The reader should note that the channel in which the client's legacy proof is transmitted is secure from a man-in-the-middle attack due to the fact that the Diffie-Hellman public values and the attributes from the accepted offer, among other things, are signed. As in [HC98], the signature uses a pseudo-random function (prf), which is either negotiated in the initial SA payload or is the HMAC version [KBC96] of a hash function, over state from the exchange and keyed with "SKEYID". The "SKEYID*" secret state is generated according to the rules for digital signature authentication of [HC98]. In other words. SKEYID = prf(Ni_b | Nr_b, g^xy) SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) The data portion of the pseudo-random function consists of the clients's Diffie-Hellman public value concatenated with the gateway's Harkins, Piper Expires in 6 months [Page 6] INTERNET DRAFT IKE Challenge/Response July 14, 2000 Diffie-Hellman public value concatenated with the client's cookie (from the [MSST98] header) concatenated with the gateway's cookie concatenated with the body of the client's initial SA offer. Graphically, the signature is over: digest = prf (SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b) Generally the pseudo-random function is the [KBC96] version of the negotiated hash function but this can be overridden if the signature algorithm is tied to a particular hash function (e.g. [DSS]) in which case the pseudo-random function will the the [KBC96] version of the hash function tied to the signature method. The data being signed includes any padding prepended to the body of the payloads (for alignment to the length of the prime modulus) but does not include the ISAKMP header from any payload. The client MUST verify the signature. If the signature is not valid the exchange MUST be terminated by the client. First, we describe the protocol abstractly using the aforementioned notation and then separate profiles are defined for each of the various LAM types. 3.1 IKE Challenge/Response Abstract Representation The IKE Challenge/Response protocol is abstractly defined as follows: Main Mode using CRACK is defined as Client (I) Gateway (R) ----------- ----------- HDR, SAi, ---> <--- HDR, SAr HDR, KEi, Ni, [, CERTREQ] ---> <--- HDR, [CERT, ] KEr, Nr, SIG HDR*, CHRE ---> <--- HDR*, CHRE [ HDR*, CHRE ---> <--- HDR*, CHRE ] Harkins, Piper Expires in 6 months [Page 7] INTERNET DRAFT IKE Challenge/Response July 14, 2000 Aggressive Mode using CRACK is defined as Client (I) Gateway (R) ----------- ----------- HDR, SAi, KEi, Ni [, CERTREQ] ---> <--- HDR, SAr, [CERT, ] KEr, Nr, SIG HDR*, CHRE ---> <--- HDR*, CHRE [ HDR*, CHRE ---> <--- HDR*, CHRE ] Where SIG is a digital signature of the aforementioned information. Any ambiguity about which key was used can be dispelled by optionally sending a certificate payload which indicates the public key that should be used to verify the signature. Note that the number of messages in an exchange is not fixed. The gateway can respond with any number of challenges (CHRE payloads) to which the client responds with responses (also CHRE payloads) for each. When the gateway has successfully authenticated the client, it responds with a CHRE payload with an associated attribute list containing (at least) the CRACK_T_FIN attribute with the value of CRACK_FIN_SUCCESS. Depending on the LAM Type, the gateway may respond with CRACK_FIN_MORE, indicating that the exchange needs to continue for an additional round. 3.2 IKE Challenge/Response Failures CRACK requires the gateway to send ISAKMP Notify payloads under certain circumstances detailed in this section and elsewhere in this draft. These Notify payloads use the same format for the Notification Payload ([MSST98]) and differ only in the "Notification Data" field. The Notification Payload MUST have the following format: o Payload length - set to the value 28 + "Notification Data" o DOI - set to the value zero (0) (ISAKMP) o Protocol ID - set to the value one (1) (PROTO_ISAKMP) o SPI Size - set to the value 16 o Notify Message Type - set to the value 24 o SPI - set to the ISAKMP initiator and responder cookies If the contents of the CHRE payload(s) that the client sends fail to satisfy the legacy authentication method, the gateway MUST terminate the connection and MUST respond with an ISAKMP (AUTHENTICATION- Harkins, Piper Expires in 6 months [Page 8] INTERNET DRAFT IKE Challenge/Response July 14, 2000 FAILED) [MSST98]. AUTHENTICATION-FAILED MUST include the following "Notification Data": o LAM Type (two octets) - set to the associated LAM Type o RESERVED (two octets) - MUST be zero (0) (alignment) In addition AUTHENTICATION-FAILED SHOULD contain the following "Notification Data" when applicable: o Status (variable length) - implementation-specific authentication failure status If LAM Type, signature algorithm, or corresonding public-key requested by a CERTREQ cannot be located, the gateway MUST terminate the connection and MUST respond with an ISAKMP Notify (PROPOSAL-NOT- CHOSEN) [MSST98]. PROPOSAL-NOT-CHOSEN MUST include the following "Notification Data": o LAM Type (two octets) - set to the LAM Type the server requires for the client; MAY be different than the LAM Type specified in the first CHRE payloads if the server required a different LAM Type than was offered o RESERVED (two octets) - MUST be zero (0) (alignment) In addition PROPOSAL-NOT-CHOSEN SHOULD contain the following "Notification Data" when applicable: o Status (variable length) - authentication failure status Because these Notify messages are only sent under the security of the Phase 1 shared secret and only after the gateway has proven its identity to the client, the client can trust the authenticity of these messages and MUST terminate the exchange upon receipt of any of these Notify messages. 4. Legacy Authentication Method (LAM) Profiles Each defined LAM type uses the CHRE payload and LAM attributes in a different manner. This section profiles the acceptable use of each for the defined LAM types and details the list of acceptable attributes for each profile. The Challenge/Response profile examples include the exchange of CERTREQ and CERT payloads which may be used when the client does not have access to the server's public-key or has access to multiple server keys. In other examples, the CERTREQ and CERT payloads are Harkins, Piper Expires in 6 months [Page 9] INTERNET DRAFT IKE Challenge/Response July 14, 2000 omitted for simplicity, but these MAY be used with any of the defined profiles, according to the additional requirements in Section 3.1. 4.1 LAM Profiles: Password The Password profile supports legacy operating system (OS) authentication along with proxy-based password authentication protocols, like RADIUS or TACACS+. It is assumed in this example that the client has the gateway's public key, either through a certificate or a trusted raw public key, prior to initiation of the exchange. This example is given using Main Mode. Client (I) Gateway (R) ----------- ----------- HDR1, SAi, ---> <--- HDR2, SAr, HDR1, KEi, Ni ---> <--- HDR2, KEr, Ni, SIG HDR3*, CHRE1 ---> <--- HDR4*, CHRE2 For Password, the CHRE payloads are used as follows: HDR3*, CHRE1 ---> The CHRE1 payload contains the client's username as a CRACK_T_USERNAME attribute and a password as a CRACK_T_SECRET attribute. The format of the client password is dictated by the corresponding host OS or proxy authentication server and may be either plaintext or binary. <--- HDR4*, CHRE2 The CHRE2 payload contains a CRACK_T_FIN attribute with the value of CRACK_FIN_SUCCESS. The following attributes are defined for Password: CRACK_T_USERNAME (client -> gateway, required) CRACK_T_USERNAME is sent in the client's first CHRE payload and MUST contain the client's username which is used as an index key by the host OS or proxy password authentication server. CRACK_T_SECRET (client -> gateway, required) Harkins, Piper Expires in 6 months [Page 10] INTERNET DRAFT IKE Challenge/Response July 14, 2000 CRACK_T_SECRET is sent in the client's first CHRE payload and MUST contain the client's password. CRACK_T_DOMAIN (client -> gateway, optional) CRACK_T_DOMAIN is sent in the client's second message and MAY be used to specify the authentication domain that the client is requesting authentication within. CRACK_T_FIN (gateway -> client, required) CRACK_T_FIN is used to successfully terminate the exchange. 4.2 LAM Profiles: One-Time Password The OTP profile supports both the S/KEY and OTP one-time password schemes. It is assumed in this example that the client has the gateway's public key, either through a certificate or a trusted raw public key, prior to initiation of the exchange. The example is given using Aggressive Mode. Client (I) Gateway (R) ----------- ----------- HDR1, SAi, KEi, Ni ---> <--- HDR2, SAr, KEr, Nr, SIG HDR3*, CHRE1 ---> <--- HDR4*, CHRE2 HDR5*, CHRE3 ---> <--- HDR6*, CHRE4 For OTP, the CHRE payloads are used as follows: HDR3*, CHRE1 ---> The CHRE1 payload contains only any associated attributes such as a username. <--- HDR4*, CHRE2 The CHRE2 payload contains the OTP server's challenge text which MUST be displayed to the client user. HDR5*, CHRE3 ---> The CHRE3 payload contains the client's one-time password response. Harkins, Piper Expires in 6 months [Page 11] INTERNET DRAFT IKE Challenge/Response July 14, 2000 <--- HDR6*, CHRE4 The CHRE4 payload contains a CRACK_T_FIN attribute with the value of CRACK_FIN_SUCCESS. The following attributes are defined for OTP: CRACK_T_USERNAME (client -> gateway, required) CRACK_T_USERNAME is sent in the client's first CHRE payload and MUST contain the client's username which is used as an index key by the OTP server. CRACK_T_CHALLENGE (gateway -> client, required) CRACK_T_CHALLENGE is sent in the gateway's first CHRE payload and MUST contain the OTP challenge to be issued to the client. CRACK_T_SECRET (client -> gateway, required) CRACK_T_SECRET is sent in the client's second CHRE payload and contains the client's one-time password. CRACK_T_MESSAGE (gateway -> client, optional) CRACK_T_MESSAGE is optionally sent in any server message and MAY by used by the server to provide optional text to be displayed to the user along with any associated challenge text. CRACK_T_FIN (gateway -> client, required) CRACK_T_FIN is used to successfully terminate the exchange. 4.3 LAM Profiles: Challenge/Response The Challenge/Response profile supports various token cards that follow a standard challenge/response exchange. The client's token card information (the response) depends on the gateway's request (the challenge). It is assumed in this example that the client does not have the gateway's public key and requires a certificate issued by a trusted Certification Authority. Note that in this case, identity protection of the gateway is lost. Whether a certificate is requested and sent or not, the client's identity is never open to a passive attack (i.e. the client retains identity protection regardless). The following example shows an exchange where a full Harkins, Piper Expires in 6 months [Page 12] INTERNET DRAFT IKE Challenge/Response July 14, 2000 challenge/response exchange is followed: Client (I) Gateway (R) ----------- ----------- HDR1, SAi, KEi, Ni, CERTREQ ---> <--- HDR2, SAr, CERT, KEr, Nr, SIG HDR3*, CHRE1 ---> <--- HDR4*, CHRE2 HDR5*, CHRE3 ---> <--- HDR6*, CHRE4 If more challenges were required to authenticate this client, message six would be another CHRE payload containing a challenge to the client. This would force a message seven which would be another CHRE payload. This can be repeated until the gateway authenticates the client (or authentication fails, see below). Alternatively, some challenge-response tokens cache their last computed result and do not require a challenge from the gateway unless they get out of sync (perhaps due to intrusion detection). In this case, the gateway may be able to authenticate the client in the second message and would return, assuming success a CHRE2 containing CRACK_T_FIN attribute with the value of CRACK_T_FIN_SUCCESS. There would also be no fifth nor sixth message. The following example shows an exchange where the client can pre- compute his expected response: Client (I) Gateway (R) ----------- ----------- HDR1, SAi, KEi, Ni, CERTREQ ---> <--- HDR2, SAr, CERT, KEr, Nr, SIG HDR3*, CHRE1 ---> <--- HDR4*, CHRE2 For Challenge/Response, the CHRE payloads are used as follows: HDR3*, CHRE1 ---> When the client is using a token that can compute the next expected response without requiring a challenge, the CHRE1 payload contains the client's username and expected response. When the client does not have an expected response, or has chosen not to use Harkins, Piper Expires in 6 months [Page 13] INTERNET DRAFT IKE Challenge/Response July 14, 2000 the current one for whatever reason, the CHRE payload contains only the client's username. <--- HDR4*, CHRE2 The CHRE2 payload contains the gateway's challenge text which MUST be displayed to the client user unless the client has presented an expected response (as above) in which case this is identical to CHRE4 below. HDR5*, CHRE3 ---> The CHRE3 payload, when used, contains the client's response to the gateway challenge. <--- HDR6*, CHRE4 The CHRE4 payload contains a CRACK_T_FIN attribute with the value of CRACK_FIN_SUCCESS. The following attributes are defined for Challenge/Response: CRACK_T_USERNAME (client -> gateway, required) CRACK_T_USERNAME is sent in the client's second message and MUST contain the client's username which is used as an index key for authentication by the server. CRACK_T_SECRET (client -> gateway, required) CRACK_T_SECRET contains the client's response and is sent in the client's second message if an anticipated challenge is used, and in the client's third message if the client is responding to a gateway challenge. CRACK_T_PIN (client -> gateway, optional) CRACK_PIN is optionally sent in any client message and MAY by used if the authentication protocol also requires the client to provide a PIN. CRACK_T_MESSAGE (gateway -> client, optional) CRACK_MESSAGE is optionally sent in any server message and MAY by used by the server to provide optional text to be displayed to the user along with any associated challenge text. Harkins, Piper Expires in 6 months [Page 14] INTERNET DRAFT IKE Challenge/Response July 14, 2000 CRACK_T_FIN (gateway -> client, required) CRACK_T_FIN is used to successfully terminate the exchange. 4.4 LAM Profiles: SecurID The SecurID profile supports the RSA SecurID protocol. With SecurID the client will be passing the output of the SecurID card as the body of the first CHRE payload (in the second message it sends) and its identity as an associated CRACK_T_USERNAME attribute. Assuming the client and gateway are in sync (i.e. they are not in "Next Code" mode) there is a single CHRE payload. It is assumed in this example that the client has the gateway's public key, either through a certificate or a trusted raw public key, prior to initiation of the exchange. The following example shows a simple SecurID authentication using aggressive mode: Client (I) Gateway (R) ----------- ----------- HDR1, SAi, KEi, Ni ---> <--- HDR2, SAr, KEr, Nr, SIG1 HDR3*, CHRE1 ---> <--- HDR4*, CHRE2 For simple SecurID, the CHRE payloads are used as follows: HDR3*, CHRE1 ---> The CHRE1 payload contains the client's username and the current Passcode displayed by the client's SecurID token. <--- HDR4*, CHRE2 The CHRE2 payload contains a CRACK_T_FIN attribute with the value of CRACK_FIN_SUCCESS. When the client and gateway clocks are slightly out of sync, the gateway will respond with an additional challenge payload to which the client MUST respond with another reponse payload. This is known as "Next Code" mode. The following example shows a SecurID authentication where "Next Code" mode is required: Harkins, Piper Expires in 6 months [Page 15] INTERNET DRAFT IKE Challenge/Response July 14, 2000 Client (I) Gateway (R) ----------- ----------- HDR1, SAi, KEi, Ni ---> <--- HDR2, SAr, KEr, Nr, SIG HDR3*, CHRE1 ---> <--- HDR4*, CHRE2 HDR5*, CHRE3 ---> <--- HDR6*, CHRE4 For SecurID with "Next Code", the CHRE payloads are used as follows: HDR3*, CHRE1 ---> The CHRE1 payload contains the client's username and the current Passcode displayed by the client's SecurID token. <--- HDR4*, CHRE2 The CHRE2 payload contains a CRACK_T_FIN attribute with the value of CRACK_FIN_MORE. HDR5*, CHRE3 ---> The CHRE3 payload contains the client's next Passcode displayed by the client's SecurID token. <--- HDR6*, CHRE4 The CHRE4 payload contains a CRACK_T_FIN attribute with the value of CRACK_FIN_SUCCESS. The following attributes are defined for SecurID: CRACK_T_USERNAME (client -> gateway, required) CRACK_T_USERNAME is sent in the client's second message and MUST contain the client's username which is used as an index key by the ACE server. CRACK_T_PIN (client -> gateway, optional) CRACK_T_PIN is sent in the client's second message and MAY be used when the SecurID card is not a PINPAD card. CRACK_T_MESSAGE (gateway -> client, optional) CRACK_T_MESSAGE is optionally sent in any server message and MAY Harkins, Piper Expires in 6 months [Page 16] INTERNET DRAFT IKE Challenge/Response July 14, 2000 by used by the server to provide optional text to be displayed to the user along with any associated challenge text. CRACK_T_FIN (gateway -> client, required) CRACK_T_FIN is used to successfully terminate the exchange and to request the client continue under "Next Code" mode. 4.5 LAM Profile Matrix Each of the LAM's supported by IKE Challenge/Response fall into one of the defined LAM profiles. This section details the classification for those methods, including all of the types defined for the experimental XAUTH protocol [PB99]. Password DIAMETER LDAP NDS (Netware Directory Services) NT Domain RADIUS TACACS TACACS+ UNIX Login OTP OTP S/KEY Challenge/Response AXENT Defender CheckPoint ActivCard CRYPTOCard CRYPTOCard Digital Pathways SNK LeeMah InfoCard Secure Computing SafeWord (Enigma Logic DES Gold) SecurID RSA SecurID 5. The IKE Challenge/Response Vendor ID Signature This memo describes a protocol that lives on top of [MSST98] and as a companion to [HC98]. These standards-track protocols reserve some of their "magic number" space for private use by mutually consenting parties. It is from this number space that this memo obtains some of the "magic numbers" it needs (payload types, exchange value, attributes). As part of the "mutually consenting parties" part of Harkins, Piper Expires in 6 months [Page 17] INTERNET DRAFT IKE Challenge/Response July 14, 2000 the requirement implementors of this protocol are encouraged to use a Vendor ID payload to announce willingness to engage in this protocol. The contents of the Vendor ID payload will be the following hexadecimal string: 0x13f11823f966fa91900f024ba66a86b, which is the result of an MD5 hash of "IKE Challenge/Response for Authenticated Cryptographic Keys (Revised)" without the quotation marks. An [HC98] implementation that implements this protocol that obtains a Vendor ID payload with this string in the body of the payload can assume that the sender of the Vendor ID payload has likewise implemented this protocol and is therefore a "mutually consenting party". If this protocol is advanced to standards-track status IANA will assign new "magic numbers" out of the appropriate number spaces (the "magic numbers" will no longer be from the private use ranges) and the requirement to use a Vendor ID payload will go away. 6. Security Considerations The channel that results from the exchange of the first two messages is secured because the gateway signs his Diffie-Hellman public value and it is the resulting SKEYID state (see [HC98]) that protects the channel. The channel is secured from the client's perspective because he knows that the gateway was the actual source of the Diffie-Hellman public value and is an active party to the exchange. The channel is secured from the gateway's perspective because the client has proved proof-of-possession of a long-term shared secret and would not have sent his sensitive information if a man-in-the-middle was detected by the client. While this seems to be a weak form of assurance, the exchange could only be foiled by an intentionally malfunctioning client and if that is the case then all bets are off regardless of the method of authentication. (If Alice and Bob establish IPSec SA's in the traditional fashion, using a [HC98] exchange nothing could stop Alice from sending all the sensitive information Bob conveys to her to Eve.) Also note that this technique is used in other popular on-line certificate enrollment schemes ([MLSW99]). As noted, this whole scheme can fail if the client is intentionally malicious. Also, if the token card and knowledge of how to generate valid credentials is conveyed to a third-party this scheme would fail (but not due to any protocol failure). The number of messages in this protocol is dictated by the type of legacy authentication method employed. Since this protocol is open- ended, a host implementation may wish to limit the number of CHRE round-trips using locally defined policy. Harkins, Piper Expires in 6 months [Page 18] INTERNET DRAFT IKE Challenge/Response July 14, 2000 Acknowledgments The authors would like to thank the sales and marketing staff of all companies who said, "Just give us something that uses token cards!" We would like to recognize Roy Pereira and Stephane Beaulieu, authors of [PB99], which was borrowed from liberally in creation of this memo. References [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [CR98] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", draft-calhoun-diameter-02.txt, March 1998, a work in progress. [DSS] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Signature Standard", FIPS 186, May 1994. [Hal95] N. Haller, "The S/KEY One-Time Password System", RFC1760, February 1995. [HC98] D. Harkins, D. Carrel, "The Internet Key Exchange", RFC2409, November 1998. [HM96] N. Haller, C. Metz, "A One-Time Password System", RFC1938, May 1996. [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [MLSW99] M. Myers, X. Liu, J. Schaad, and J. Weinstein, "Certificate Management Messages over CMS", draft-ietf-pkix-cmc-05.txt, a work in progress. [MSST98] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC2408, November 1998. [PB99] R. Pereira, S. Beaulieu, "Extended Authentication within ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-05.txt, September, 1999, a work in progress. [Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", RFC 2407, November 1998. Harkins, Piper Expires in 6 months [Page 19] INTERNET DRAFT IKE Challenge/Response July 14, 2000 [PKCS1] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2", September 1998. [RASW97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC2138, April 1997. [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978. Authors' Address Dan Harkins Derrell Piper Nokia Corporation 1538 Pacific Ave Santa Cruz, CA 95060-9311 United States of America Harkins, Piper Expires in 6 months [Page 20] From owner-ipsec@lists.tislabs.com Tue May 7 03:27:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47AR3L14976; Tue, 7 May 2002 03:27:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08948 Tue, 7 May 2002 05:21:39 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 07 May 2002 03:34:10 -0600 From: "Umasankar Mukkara" To: Subject: NAT-T ipaddress conflict Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-874 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA08945 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, NAT-Traversal and UDP-Encapsulation drafts do not suggest a way to deal with IP address conflict behind two different NATs. The recent draft "draft-ietf-ipsec-udp-encaps-02.txt" also says that that the implementations should devise their own way to solve this problem. (in section 5.2 — Tunnel Mode Conflict) Are there any references available suggesting a solution to this issue? I read that NAT functionality built-in into the ipsec stack on the VPN GW solves this problem. Could somebody provide an overview (or already available stuff on the web) TIA, Umasankar. From owner-ipsec@lists.tislabs.com Tue May 7 08:10:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47FA8L27045; Tue, 7 May 2002 08:10:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09890 Tue, 7 May 2002 10:23:04 -0400 (EDT) Message-ID: From: Goeman Stefan To: "'ipsec@lists.tislabs.com'" Subject: data origin authentication Date: Tue, 7 May 2002 16:29:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello All, In rfc 2406 "IP Encapsulating Security Payload", and also in draft-ietf-ipsec-esp-v3-02.txt, I read: "EPS 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. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology." I have been reading more carefully through the rfc (not through the draft yet). I is correct to say that if ESP is used in transport mode, there is no data origin authentication? I would say this because the IP header, containing the source IP address is not authenticated. Or am I missing something here? Greetings, Stefan. From owner-ipsec@lists.tislabs.com Tue May 7 09:04:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47G4DL29850; Tue, 7 May 2002 09:04:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10157 Tue, 7 May 2002 11:20:37 -0400 (EDT) Date: Tue, 7 May 2002 11:33:03 -0400 (EDT) From: Henry Spencer To: Goeman Stefan cc: "'ipsec@lists.tislabs.com'" Subject: Re: data origin authentication 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, 7 May 2002, Goeman Stefan wrote: > ...I is correct to say > that if ESP is used in transport mode, there is no data origin > authentication? I would say this because > the IP header, containing the source IP address is not authenticated. Not really correct. Yes, the header may be tampered with... but the origin of the *data* (the packet contents) is still certain, because only someone knowing the authentication key can generate a packet which will pass authentication. The header is just the means by which the data is conveyed to the destination. Usually, one cares about authenticating the contents, not the header. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue May 7 09:21:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47GLrL00614; Tue, 7 May 2002 09:21:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10211 Tue, 7 May 2002 11:40:43 -0400 (EDT) Message-Id: <5.1.0.14.0.20020507171226.03c24ec0@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 May 2002 17:20:49 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: data origin authentication In-Reply-To: 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 LAA10092 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:29 07.05.2002 +0200, you wrote: >Hello All, > >In rfc 2406 "IP Encapsulating Security Payload", and also in >draft-ietf-ipsec-esp-v3-02.txt, >I read: "EPS 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. >The set of services provided depends on options selected at the time of >Security Association (SA) >establishment and on the location of the implementation in a network >topology." > >I have been reading more carefully through the rfc (not through the draft >yet). I is correct to say >that if ESP is used in transport mode, there is no data origin >authentication? I would say this because >the IP header, containing the source IP address is not authenticated. >Or am I missing something here? > > >Greetings, > >Stefan. I guess you are missing something. You receive an ESP packet. By looking up you find the IPsec SA. Now, since you negotiated the SA for transport mode, the SA data will contain the remote IP address. The SA entry states ", that should come from 5.6.7.8". And if it doesn't, you can discard the packet. Or, to explain it in another way: Transport mode: src IP address is the same for all packets. Easy to check. Tunnel mode: src IP addresses (inner header) can vary. Therefore is must be authenticated. Jörn From owner-ipsec@lists.tislabs.com Tue May 7 09:22:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47GMsL00659; Tue, 7 May 2002 09:22:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10239 Tue, 7 May 2002 11:43:45 -0400 (EDT) Message-Id: <200205071553.g47FrWKw027550@thunk.east.sun.com> From: Bill Sommerfeld To: Goeman Stefan cc: "'ipsec@lists.tislabs.com'" Subject: Re: data origin authentication In-Reply-To: Your message of "Tue, 07 May 2002 16:29:53 +0200." Reply-to: sommerfeld@east.sun.com Date: Tue, 07 May 2002 11:53:31 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I have been reading more carefully through the rfc (not through the draft > yet). I is correct to say > that if ESP is used in transport mode, there is no data origin > authentication? No. It's underspecified. > I would say this because the IP header, containing the source IP > address is not authenticated. Or am I missing something here? Implementations often allow a specific source address to be bound to the SA in transport mode -- if the packet's source doesn't match the SA source, the packet is dropped. (PF_KEY provides exactly this mechanism). memcmp() with a known quantity is a stronger integrity check than hmac-sha1. ;-) - Bill From owner-ipsec@lists.tislabs.com Tue May 7 10:14:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47HEmL03446; Tue, 7 May 2002 10:14:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10473 Tue, 7 May 2002 12:34:11 -0400 (EDT) Message-ID: From: Goeman Stefan To: "'ipsec@lists.tislabs.com'" Subject: RE: data origin authentication Date: Tue, 7 May 2002 18:41:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello All, (As you all might guess, I am quite new to this stuff). See my question(s) below > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: dinsdag 7 mei 2002 17:33 > To: Goeman Stefan > Cc: 'ipsec@lists.tislabs.com' > Subject: Re: data origin authentication > > > On Tue, 7 May 2002, Goeman Stefan wrote: > > ...I is correct to say > > that if ESP is used in transport mode, there is no data origin > > authentication? I would say this because > > the IP header, containing the source IP address is not > authenticated. > > Not really correct. Yes, the header may be tampered with... but the > origin of the *data* (the packet contents) is still certain, > because only > someone knowing the authentication key can generate a packet > which will > pass authentication. > > The header is just the means by which the data is conveyed to the > destination. Usually, one cares about authenticating the > contents, not > the header. > > > Henry Spencer > > henry@spsystems.net > If you don't really need to authenticate the header to obtain data origin authentication, why does AH (rfc 2402) authenticates also the IP header, and not only the IP payload? Anyway, thanks for answering all my (stupid?) questions. Greetings, Stefan. From owner-ipsec@lists.tislabs.com Tue May 7 10:55:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47HtfL04940; Tue, 7 May 2002 10:55:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10567 Tue, 7 May 2002 13:03:22 -0400 (EDT) Message-Id: <200205071705.g47H5ax10386@marajade.sandelman.ottawa.on.ca> To: Goeman Stefan cc: "'ipsec@lists.tislabs.com'" Subject: Re: data origin authentication In-reply-to: Your message of "Tue, 07 May 2002 16:29:53 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 May 2002 13:05:35 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Goeman" == Goeman Stefan writes: Goeman> I have been reading more carefully through the rfc (not through Goeman> the draft yet). I is correct to say that if ESP is used in Goeman> transport mode, there is no data origin authentication? I would Goeman> say this because the IP header, containing the source IP address Goeman> is not authenticated. Or am I missing something here? The IP address is not authenticated. The IP address is just one expression of the origin. Origin authentication is provided by the relationship to the trust model that created the SA. And, as Steve Bellovin has pointed out, you could essentially throw away the origin IP anyway, and use the SA to provide the actual numerical origin. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPNgJXYqHRg3pndX9AQEgjQP+IxeGbslJ/LbtimynbFMmgmSh2+2zE6rx KaNSj7svBwx9MtMupbyWHGu1Wdv/w3BntfN+bgSY1f311r7YomvARLO1MPA+jCTM vFAXjs31DCfX7lOMEuVoYloaS/S8kgYsBF8/rmPEJ/VpU5hXGxBo58UcYS6s+Y1N /mz0qQZdl/k= =5Ufi -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue May 7 11:39:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47IdGL06731; Tue, 7 May 2002 11:39:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10806 Tue, 7 May 2002 13:50:42 -0400 (EDT) Message-Id: <200205071752.g47Hqfh11664@marajade.sandelman.ottawa.on.ca> To: "'ipsec@lists.tislabs.com'" Subject: Re: data origin authentication In-reply-to: Your message of "Tue, 07 May 2002 18:41:40 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 May 2002 13:52:40 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Goeman" == Goeman Stefan writes: Goeman> If you don't really need to authenticate the header to obtain Goeman> data origin authentication, why does AH (rfc 2402) authenticates Goeman> also the IP header, and not only the IP payload? Please see the archives. AH is generally considered a historical accident. I think that it will still prove useful, but not for most people this decade. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue May 7 11:46:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47IkkL07064; Tue, 7 May 2002 11:46:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10837 Tue, 7 May 2002 14:01:48 -0400 (EDT) Date: Tue, 7 May 2002 14:13:46 -0400 (EDT) From: Henry Spencer To: Goeman Stefan cc: "'ipsec@lists.tislabs.com'" Subject: RE: data origin authentication 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, 7 May 2002, Goeman Stefan wrote: > > Usually, one cares about authenticating the contents, not the header. > > If you don't really need to authenticate the header to obtain data origin > authentication, why does AH (rfc 2402) authenticates also the IP header, > and not only the IP payload? Well, you'll note that I said "usually". There are situations where you would like to be able to trust certain items in the header. For example, in multicast applications, the source address may not be uniquely determined by the SA used, and might be significant to the user-level code. That said, there are many people who think that this feature of AH was a design mistake, and that the entire AH protocol is now superfluous and should be removed from IPsec and reclassified as Historic. (There are other people who disagree.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue May 7 12:37:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47Jb6L09101; Tue, 7 May 2002 12:37:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10958 Tue, 7 May 2002 14:49:14 -0400 (EDT) Message-ID: <6F0AA176DA68704884B7507AE6907E180817DA@snake012.odetics.com> From: Christina Helbig To: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: data origin authentication Date: Tue, 7 May 2002 12:01:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA10955 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Joern if you are a bad guy and you own a in-bound SA you can produced a faked ESP packet that looks like its come from the other party of your in-bound SA. Then you can claim that you got this packet from the other party. So the data origin authentication of ESP (two parties know the same authentication key) don't deliver non-repudiation of data origin. But a receiver can be sure that the sender of an incoming ESP packet is only the other party of the related in-bound SA or the receiver itself. For this proof, I guess, the receiver needs only to find the related SA and the related authentication key. The receiver proofs the authentication value and this proof delivers the answer, if the sender has the identity the sender claimed. The check against the ip address of the sender saves time (if you do it before) and is a MUST but for the data authentication not really necessary. But I'm also a newcomer in IPSec and may be I'm wrong. Christina > -----Original Message----- > From: Joern Sierwald [mailto:joern@f-secure.com] > Sent: Tuesday, May 07, 2002 8:21 AM > To: ipsec@lists.tislabs.com > Subject: Re: data origin authentication > > > At 16:29 07.05.2002 +0200, you wrote: > >Hello All, > > > >In rfc 2406 "IP Encapsulating Security Payload", and also in > >draft-ietf-ipsec-esp-v3-02.txt, > >I read: "EPS 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. > >The set of services provided depends on options selected at > the time of > >Security Association (SA) > >establishment and on the location of the implementation in a network > >topology." > > > >I have been reading more carefully through the rfc (not > through the draft > >yet). I is correct to say > >that if ESP is used in transport mode, there is no data origin > >authentication? I would say this because > >the IP header, containing the source IP address is not > authenticated. > >Or am I missing something here? > > > > > >Greetings, > > > >Stefan. > > I guess you are missing something. You receive an ESP packet. > By looking up > you find the IPsec SA. > > Now, since you negotiated the SA for transport mode, the SA data will > contain the > remote IP address. The SA entry states " (that's us), ESP, > SPI 0x61782395>, that > should come from 5.6.7.8". And if it doesn't, you can discard > the packet. > > Or, to explain it in another way: > > Transport mode: src IP address is the same for all packets. > Easy to check. > Tunnel mode: src IP addresses (inner header) can vary. > Therefore is must be > authenticated. > > Jörn > > > From owner-ipsec@lists.tislabs.com Tue May 7 17:09:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4809IL18075; Tue, 7 May 2002 17:09:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11677 Tue, 7 May 2002 19:13:47 -0400 (EDT) Message-ID: <605C42246151B7498423278ED555306F04C049@skat.sky.com> From: michael lin To: "'ipsec@lists.tislabs.com'" Subject: NAT Traversal and packet reassemble Date: Tue, 7 May 2002 16:26:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, To support IPSec fragment packets, the only thing, VPN gateway should do, is to reassemble AH and ESP packets. In NAT Traversal, all IPSec packets are encapsulated by UDP header (port 500 or 4500). For first fragment, VPN gateway can only keep the packet with UDP port 500 and non-IKE marker. But for the second fragment, there is no UDP header. There is no way to know this fragment is UDP encapsulated IPSec packet or other UDP packets. That means VPN gateway should try to reassemble all UDP packets. This will affect VPN gateway throughput. It seems no way to solve this problem, right? Michael From owner-ipsec@lists.tislabs.com Tue May 7 19:16:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g482GcL22059; Tue, 7 May 2002 19:16:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12175 Tue, 7 May 2002 21:34:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20020507182331.02c9c820@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 May 2002 18:45:57 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: New SOI features draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks to the IKEv2 and JFK folks, and Paul Hoffman for developing the SOI features document. Ted and I would like to urge you to read it and to discuss it on the list. We need to decide which features are important to SOI so that we can move forward with the protocol design work. On page 3 of the document, there are three identified core differences between IKEv2 and JFK: 1) whether the protocol has one phase or two phases, 2) how DoS attacks are thwarted, and 3) the use of shared secret authentication. According to the document, one path the working group can take is to decide which of these three differences is important and to then select among the remaining features. The scenarios where IPsec/IKE is being used, as described in Cheryl's document, are not included in the features document. Therefore, one area we must explore is the match between the above 3 differentiating qualities and the community's use and expectation of IPsec/IKE. Is there an installed base that expects these features to be present, and given the answer, what does the working group want to do. Let's see if we can come to consensus in the next month. This would allow some time for a new or updated protocol draft to be prepared prior to the July IETF meeting. thanks, Barb From owner-ipsec@lists.tislabs.com Tue May 7 20:52:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g483qbL24444; Tue, 7 May 2002 20:52:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12479 Tue, 7 May 2002 23:13:35 -0400 (EDT) Date: Tue, 7 May 2002 20:35:32 -0700 (PDT) From: Srinivasa Addepalli To: michael lin cc: "'ipsec@lists.tislabs.com'" Subject: Re: NAT Traversal and packet reassemble In-Reply-To: <605C42246151B7498423278ED555306F04C049@skat.sky.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 May 2002, michael lin wrote: > Hi, > > To support IPSec fragment packets, the only thing, VPN gateway should do, is > to reassemble AH and ESP packets. In NAT Traversal, all IPSec packets are > encapsulated by UDP header (port 500 or 4500). For first fragment, VPN > gateway can only keep the packet with UDP port 500 and non-IKE marker. SRINI> Now it is non-ESP marker, according to the new draft. But > for the second fragment, there is no UDP header. There is no way to know > this fragment is UDP encapsulated IPSec packet or other UDP packets. That > means VPN gateway should try to reassemble all UDP packets. This will affect > VPN gateway throughput. > > It seems no way to solve this problem, right? SRINI> Reassembly is needed for this. Anycase, to support port based SPD, reassembly is anyway required. Also, extra header should be taken into consideration for PMTU ( if supported). > > Michael > -- Srinivasa Rao Addepalli Intoto Inc. (Enabling Security Infrastructure) 3160, De La Cruz Blvd #100 Santa Clara, CA USA From owner-ipsec@lists.tislabs.com Wed May 8 01:42:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g488ghL27891; Wed, 8 May 2002 01:42:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13348 Wed, 8 May 2002 04:04:03 -0400 (EDT) Message-ID: From: Goeman Stefan To: "'ipsec@lists.tislabs.com'" Subject: RE: data origin authentication Date: Wed, 8 May 2002 10:11:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello All, > -----Original Message----- > From: Christina Helbig [mailto:cbh@zyfer.com] > Sent: dinsdag 7 mei 2002 21:02 > To: 'Joern Sierwald'; ipsec@lists.tislabs.com > Subject: RE: data origin authentication > > > Hello, Joern > if you are a bad guy and you own a in-bound SA you can > produced a faked ESP > packet that looks like its come from the other party of your > in-bound SA. > Then you can claim that you got this packet from the other > party. So the > data origin authentication of ESP (two parties know the same > authentication > key) don't deliver non-repudiation of data origin. But a > receiver can be > sure that the sender of an incoming ESP packet is only the > other party of > the related in-bound SA or the receiver itself. Non-repudiation. Hmm. Checking the rfc's, it is nowhere claimed that ESP and/or AH offers non-repudiation as a security service. (But perhaps non-repudiation is a must and then solutions have to be developed.) Greetings, Stefan. From owner-ipsec@lists.tislabs.com Wed May 8 07:09:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48E9VL21389; Wed, 8 May 2002 07:09:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14223 Wed, 8 May 2002 09:15:33 -0400 (EDT) Message-Id: <5.1.0.14.0.20020508000513.02839fd8@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 08 May 2002 00:21:49 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: RE: data origin authentication In-Reply-To: <6F0AA176DA68704884B7507AE6907E180817DA@snake012.odetics.co m> 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 DAA13138 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:01 07.05.2002 -0700, you wrote: >Hello, Joern >if you are a bad guy and you own a in-bound SA you can produced a faked ESP >packet that looks like its come from the other party of your in-bound SA. >Then you can claim that you got this packet from the other party. So the >data origin authentication of ESP (two parties know the same authentication >key) don't deliver non-repudiation of data origin. But a receiver can be >sure that the sender of an incoming ESP packet is only the other party of >the related in-bound SA or the receiver itself. For this proof, I guess, the >receiver needs only to find the >related SA and the related authentication key. The receiver proofs the >authentication value and this proof delivers the answer, if the sender has >the identity the sender claimed. The check against the ip address of the >sender saves time (if you do it before) and is a MUST but for the data >authentication not really necessary. But I'm also a newcomer in IPSec and >may be I'm wrong. >Christina I question the "for the data authentication not really necessary" part. An example. Let's have a syslog client and server. syslog is _unidirectional_ UDP traffic. The connection between the client and the server is IPsec transport mode. Now, the IP address of the client (src) shows up in the logs of the server, and it is valuable information. If a man-in-the-middle would just alter the src address of the packets, the information in the server would be wrong. The point of authentication in ESP is that the information was not altered in transit! Since the authentication trailer in ESP does not handle the IP source address, the receiver has to check (memcmp) the source address with the expected one. That's part of authentication. Not some optimization to save time. Jörn From owner-ipsec@lists.tislabs.com Wed May 8 07:59:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48ExML24458; Wed, 8 May 2002 07:59:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14515 Wed, 8 May 2002 10:17:52 -0400 (EDT) Message-ID: From: Chris Trobridge To: michael lin , "'ipsec@lists.tislabs.com'" Subject: RE: NAT Traversal and packet reassemble Date: Wed, 8 May 2002 15:30:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How much of a problem is this? If you reassemble packets before checking then the only impact is if you're being hit with fragmented UDP datagrams that you don't need. This should not happen unless under attack. I don't see reassembly of non-IPSEC datagrams as being a major impediment to performance. Chris > -----Original Message----- > From: michael lin [mailto:michaell@servgate.com] > Sent: 08 May 2002 00:27 > To: 'ipsec@lists.tislabs.com' > Subject: NAT Traversal and packet reassemble > > > Hi, > > To support IPSec fragment packets, the only thing, VPN > gateway should do, is > to reassemble AH and ESP packets. In NAT Traversal, all IPSec > packets are > encapsulated by UDP header (port 500 or 4500). For first fragment, VPN > gateway can only keep the packet with UDP port 500 and > non-IKE marker. But > for the second fragment, there is no UDP header. There is no > way to know > this fragment is UDP encapsulated IPSec packet or other UDP > packets. That > means VPN gateway should try to reassemble all UDP packets. > This will affect > VPN gateway throughput. > > It seems no way to solve this problem, right? > > Michael > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com From owner-ipsec@lists.tislabs.com Wed May 8 12:32:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JWuL05527; Wed, 8 May 2002 12:32:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15198 Wed, 8 May 2002 13:25:59 -0400 (EDT) Message-ID: <605C42246151B7498423278ED555306F04C04D@skat.sky.com> From: michael lin To: "'Chris Trobridge'" , "'ipsec@lists.tislabs.com'" Subject: RE: NAT Traversal and packet reassemble Date: Wed, 8 May 2002 10:38:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You are right. I can only reassemble the fragmented UDP datagrams whose destination IP is my Gateway IP and there is a tunnel between source IP and my Gateway. So the only non-IPSec datagrams would be IKE packets, and most likely it's with certificate. Suppose it will not affect performance, unless under attack. Michael > > How much of a problem is this? > > If you reassemble packets before checking then the only > impact is if you're > being hit with fragmented UDP datagrams that you don't need. > This should > not happen unless under attack. > > I don't see reassembly of non-IPSEC datagrams as being a > major impediment to > performance. > > Chris > > > -----Original Message----- > > From: michael lin [mailto:michaell@servgate.com] > > Sent: 08 May 2002 00:27 > > To: 'ipsec@lists.tislabs.com' > > Subject: NAT Traversal and packet reassemble > > > > > > Hi, > > > > To support IPSec fragment packets, the only thing, VPN > > gateway should do, is > > to reassemble AH and ESP packets. In NAT Traversal, all IPSec > > packets are > > encapsulated by UDP header (port 500 or 4500). For first > fragment, VPN > > gateway can only keep the packet with UDP port 500 and > > non-IKE marker. But > > for the second fragment, there is no UDP header. There is no > > way to know > > this fragment is UDP encapsulated IPSec packet or other UDP > > packets. That > > means VPN gateway should try to reassemble all UDP packets. > > This will affect > > VPN gateway throughput. > > > > It seems no way to solve this problem, right? > > > > Michael > > > > > -------------------------------------------------------------- > --------------------------------------------------- > The information contained in this message is confidential and > is intended > for the addressee(s) only. If you have received this message > in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this > message is > strictly forbidden. Baltimore Technologies plc will not be > liable for direct, > special, indirect or consequential damages arising from > alteration of the > contents of this message by a third party or as a result of > any virus being > passed on. > > This footnote confirms that this email message has been swept > for Content > Security threats, including computer viruses. > > http://www.baltimore.com > From owner-ipsec@lists.tislabs.com Wed May 8 12:33:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JXLL05544; Wed, 8 May 2002 12:33:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15414 Wed, 8 May 2002 14:47:23 -0400 (EDT) Message-ID: <003901c1f6c2$5c5a61c0$6729660c@riverside> From: "Jin Zhang" To: Cc: "Dan Harkins" References: <200203300132.g2U1WaH00410@fatty.lounge.org> Subject: regarding digital signature and IKEv2 Date: Wed, 8 May 2002 11:58:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The reference of IKEv2 proposal lists FIPS PUB 186, 1994, however, this has been superseded by FIPS PUB 186-2, 2000. Is there any related change(s) on IKEv2 proposal? For example, is IKEv2 proposal going to support another algorithm ECDSA? And, PKCS#1 should be expired by end of 2002, is IKEv2 going to use it anyway? Thanks, Jin Zhang Elmic Systems Inc. USA From owner-ipsec@lists.tislabs.com Wed May 8 12:33:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JXbL05562; Wed, 8 May 2002 12:33:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14875 Wed, 8 May 2002 11:46:23 -0400 (EDT) Message-ID: <6F0AA176DA68704884B7507AE6907E180817DD@snake012.odetics.com> From: Christina Helbig To: "'Goeman Stefan'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: data origin authentication Date: Wed, 8 May 2002 08:57:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Stefan I haven't claim that ESP offers non-repudiation. ESP offers data origin authentication without non-repudiation. This was only a remark about a possible misunderstanding of the term "data origin authentication" in the sense that there is only one possible origin. Greetings Christina > -----Original Message----- > From: Goeman Stefan [mailto:Stefan.Goeman@siemens.atea.be] > Sent: Wednesday, May 08, 2002 1:12 AM > To: 'ipsec@lists.tislabs.com' > Subject: RE: data origin authentication > > > Hello All, > > > -----Original Message----- > > From: Christina Helbig [mailto:cbh@zyfer.com] > > Sent: dinsdag 7 mei 2002 21:02 > > To: 'Joern Sierwald'; ipsec@lists.tislabs.com > > Subject: RE: data origin authentication > > > > > > Hello, Joern > > if you are a bad guy and you own a in-bound SA you can > > produced a faked ESP > > packet that looks like its come from the other party of your > > in-bound SA. > > Then you can claim that you got this packet from the other > > party. So the > > data origin authentication of ESP (two parties know the same > > authentication > > key) don't deliver non-repudiation of data origin. But a > > receiver can be > > sure that the sender of an incoming ESP packet is only the > > other party of > > the related in-bound SA or the receiver itself. > > Non-repudiation. > Hmm. > Checking the rfc's, it is nowhere claimed that ESP and/or AH > offers non-repudiation as a security service. > > (But perhaps non-repudiation is a must and then solutions have > to be developed.) > > > Greetings, > > Stefan. > From owner-ipsec@lists.tislabs.com Wed May 8 12:55:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JtML06123; Wed, 8 May 2002 12:55:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15529 Wed, 8 May 2002 15:08:40 -0400 (EDT) Message-ID: <3CD97342.124176E5@cips.nokia.com> Date: Wed, 08 May 2002 11:49:38 -0700 From: Mike Ruhl X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ESP+AH Content-Type: multipart/mixed; boundary="------------64166ACB4D387A4BE0F0ADA7" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------64166ACB4D387A4BE0F0ADA7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, If I send an proposal transform of ESP+AH, is it valid to receive the propsal back as AH+ESP (instead of ESP+AH)? Thanks, Mike --------------64166ACB4D387A4BE0F0ADA7 Content-Type: text/x-vcard; charset=us-ascii; name="mruhl.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mike Ruhl Content-Disposition: attachment; filename="mruhl.vcf" begin:vcard n:Ruhl;Michael J tel;work:(831) 440-6472 x-mozilla-html:FALSE org:Nokia adr:;;;;;; version:2.1 email;internet:mruhl@cips.nokia.com title:Tall Blond Guy x-mozilla-cpt:;18592 fn:Michael J Ruhl end:vcard --------------64166ACB4D387A4BE0F0ADA7-- From owner-ipsec@lists.tislabs.com Wed May 8 14:03:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48L3RL08375; Wed, 8 May 2002 14:03:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15806 Wed, 8 May 2002 16:23:49 -0400 (EDT) Date: 8 May 2002 16:25:34 -0400 Message-ID: <001001c1f6ce$83bf1b00$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'ipsec list'" Subject: Specification of tunnel/transport attribute in IKEv2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <012a01c1f50f$9e9f7750$0100a8c0@trlhpc1> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I remember reading a posting on the list recently about the confusion surrounding the specification of tunnel mode with SA bundles (i.e. if you are doing ESP+AH, should you specify tunnel mode for one and transport for the other or tunnel for both). At the bakeoffs, we decided that you should put tunnel mode in both protocols. Also, we decided that the ordering of the protocols in the proposal shouldn't matter, since the only ordering that makes sense is [AH][ESP][IPCOMP]. I figured we should make sure that these ambiguities are cleared up in the Son-of-IKE candidates. However, in perusing through the IKEv2 draft, I can find no mention of tunnel mode or transport mode at all. Are the authors assuming that one of the modes is going to be eliminated before we standardize SOI, or is this just an oversight? Also, it might be nice to mention that the ordering of the protocols within the proposal does not affect the order in which they are applied to IPsec packets. A final issue is where to specify the group number if (god forbid) you are using PFS. I think we decided that it should be specified in both the ESP and AH protocols and optionally in IPCOMP. I wish I could find the antecedent message (I think it was by Joern), but nothing on this subject has been posted in the last few days. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed May 8 15:46:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48MkdL11870; Wed, 8 May 2002 15:46:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16121 Wed, 8 May 2002 18:10:27 -0400 (EDT) Date: Thu, 9 May 2002 01:22:35 +0300 Message-Id: <200205082222.BAA26187@burp.tkv.asdf.org> From: Markku Savela To: andrew.krywaniuk@alcatel.com CC: ipsec@lists.tislabs.com In-reply-to: <001001c1f6ce$83bf1b00$1e72788a@ca.alcatel.com> (andrew.krywaniuk@alcatel.com) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <001001c1f6ce$83bf1b00$1e72788a@ca.alcatel.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Also, we decided that the ordering of the protocols in the proposal > shouldn't matter, since the only ordering that makes sense is > [AH][ESP] But, if I do *WANT* to do [ESP][AH]? Basicly, I want to check IP headers, but not wanting the sniffers to know that I'm checking... ...and if someone wonders what is checked: if I have [IP-hdrs][ESP][AH]... then first ESP gets applied and removed resulting [IP-hdrs][AH]... and then AH checks the IP-hdrs. (and yes, the IPSEC I wrote can do this, if IKE wouldn't object.. :-) From owner-ipsec@lists.tislabs.com Wed May 8 16:33:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48NXLL13347; Wed, 8 May 2002 16:33:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16221 Wed, 8 May 2002 18:57:38 -0400 (EDT) Message-ID: From: Russell Harrison To: "'Mike Ruhl'" , ipsec@lists.tislabs.com Subject: RE: ESP+AH Date: Thu, 9 May 2002 09:08:16 +1000 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 Mike, This will be an implementation specific issue, but it should not be a problem. Irrespective of the ordering of the proposal, the only way it makes sense to apply both AH and ESP is [AH][ESP]. Regards, Russell -----Original Message----- From: Mike Ruhl [mailto:mruhl@cips.nokia.com] Sent: Thursday, 9 May 2002 04:50 AM To: ipsec@lists.tislabs.com Subject: ESP+AH Howdy, If I send an proposal transform of ESP+AH, is it valid to receive the propsal back as AH+ESP (instead of ESP+AH)? Thanks, Mike NOTICE: This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply immediately by way of advice to us. It is the addressee's - recipient's duty to virus scan and otherwise test the information provided before loading onto any computer system. Zento does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Zento. From owner-ipsec@lists.tislabs.com Wed May 8 17:38:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g490cOL14862; Wed, 8 May 2002 17:38:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16396 Wed, 8 May 2002 19:57:45 -0400 (EDT) Date: Wed, 8 May 2002 13:01:00 -0700 (PDT) From: Jan Vilhuber To: Barbara Fraser cc: Subject: 2 phases and assorted comments [Re: New SOI features draft] In-Reply-To: <4.3.2.7.2.20020507182331.02c9c820@mira-sjc5-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First off: Thanks Paul. Excellent document. I particularly like the short version in section 8. Main issue: I believe that 2 phases are required. Reason 1: some of the scenarios in Cheryl's document seem to require multiple SA's between peers, which calls for 2 phases in my mind; amortizing the authentication and all that. Examples: IP storage using finer-granularity Sa's, i.e. per-port; two security gateways using multiple Sa's between each other for various levels of protection, different policies, different QoS, etc. We see real-world deployments, where multiple SA's do in fact exist between two peers (whether they are end-hosts or security gateways). Reason 2: We're after a key management protocol, not merely a key agreement protocol (or at least I am). If we decide on 1 phase, i.e. a key agreement protocol, we'll need a replacement for all the key management functions IKEv1 provides and that people need and use for network stability. That in turn would require a few separate protocols to replace what we have now, or, if we're lucky, a single one. So who provides these protocols (or the single one)? Do we have the luxury of waiting for such a key management protocol to materialize out of thin air? What's the point of that when we already have one? Is having functionality split over multiple protocols really that much better than tightly integrating it into soi? Along those lines: "reliable and authenticated informational messages" Yes. Further along these lines: Doing a complete exchange just to delete an SA: No (i.e. this ties in with 2 phases and protected and reliable notifications). Having to redo your authentication for each key-management-message (delete, invalid SPI, etc etc): No. (emphatically no). Think big, i.e. ipsec concentrators. Think small, i.e. ip phones, cell phone, palm-tops or whatever doesn't have much processor power. Number of messages: Whatever is necessary. It seems to me the average (usual) case should be no more than 4 messages (this doesn't seem to be an issue). Error-cases, or other modes, that add round-trips don't overly bother me as these should be the exception, not the rule. Size of messages: Is pretty important (keep them as small as possible). I believe William keeps pointing out very real problems with UDP fragmentation and NAT and/or firewalls. Certs are big enough. We don't need to add to this via large packets, where it can be avoided. Birth certificates: I guess I'd rather have dead-peer-detection. They can cover all derivative SA's between the hosts in one keepalive, and are useful for failover and high-availability. A combination of initial-contact (or birth-certificates) and dead-peer-detection seems useful. If it's an either-or proposition, I vote for dead-peer-detection. Cipher-suites versus free-negotiation: I don't particularly care. I liked Pauls idea of having the protocol be free-form, but define suites that can be presented in a uniform way in a user-interface, and which would also limit the number of combinations we need to test. This strikes me as the best of both worlds. I could live with cipher-suits, though. There's bigger fish to fry anyway. Protocol Extensibility, i.e. vendor-extensions: Absolutely necessary to test out novel ideas. What better way to vet ideas to prevent untested things being proposed in ID's.. Critical bit: I could live with it, I could live without it. jan On Tue, 7 May 2002, Barbara Fraser wrote: > Thanks to the IKEv2 and JFK folks, and Paul Hoffman for developing the SOI > features document. Ted and I would like to urge you to read it and to > discuss it on the list. We need to decide which features are important to > SOI so that we can move forward with the protocol design work. On page 3 of > the document, there are three identified core differences between IKEv2 and > JFK: 1) whether the protocol has one phase or two phases, 2) how DoS > attacks are thwarted, and 3) the use of shared secret authentication. > According to the document, one path the working group can take is to decide > which of these three differences is important and to then select among the > remaining features. > > The scenarios where IPsec/IKE is being used, as described in Cheryl's > document, are not included in the features document. Therefore, one area we > must explore is the match between the above 3 differentiating qualities and > the community's use and expectation of IPsec/IKE. Is there an installed > base that expects these features to be present, and given the answer, what > does the working group want to do. > > Let's see if we can come to consensus in the next month. This would allow > some time for a new or updated protocol draft to be prepared prior to the > July IETF meeting. > > thanks, > Barb > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Wed May 8 18:21:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g491KxL16371; Wed, 8 May 2002 18:20:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16627 Wed, 8 May 2002 20:43:02 -0400 (EDT) To: Russell Harrison Cc: "'Mike Ruhl'" , ipsec@lists.tislabs.com In-reply-to: RHarrison's message of Thu, 09 May 2002 09:08:16 +1000. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ESP+AH From: itojun@iijlab.net Date: Thu, 09 May 2002 09:55:34 +0900 Message-ID: <2806.1020905734@itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>If I send an proposal transform of ESP+AH, is it valid to receive the >>propsal back as AH+ESP (instead of ESP+AH)? >This will be an implementation specific issue, but it should not be a >problem. Irrespective of the ordering of the proposal, the only way it >makes sense to apply both AH and ESP is [AH][ESP]. from experiences from past interop tests, i would be much happier if: - the order of proposal on IKE packet - interpretation of proposal are exactly specified in the document. we saw a lot of varied interpretation because of the document's unclarity (like how you specify "tunnel" in the proposal). it is not good to solve protocol ambiguity in interop events. protocol documents must be unambiguous enough so that anyone who reads the document will end up in the same interpretation. itojun From owner-ipsec@lists.tislabs.com Thu May 9 12:01:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g49J1cL25171; Thu, 9 May 2002 12:01:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19209 Thu, 9 May 2002 14:08:58 -0400 (EDT) Message-Id: <5.1.0.14.2.20020509111054.02705008@[192.168.12.25]> X-Sender: smith@[192.168.12.25] X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 May 2002 11:31:10 -0500 To: Russell Harrison , "'Mike Ruhl'" , ipsec@lists.tislabs.com From: Rick Smith at Secure Computing Subject: RE: ESP+AH In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:08 PM 5/8/2002, Russell Harrison wrote: > Irrespective of the ordering of the proposal, the only way it >makes sense to apply both AH and ESP is [AH][ESP]. In a truly practical sense, I don't think it matters which way you do it. You loose a smidgin of benefit either way. Years back in "Internet Cryptography" I suggested that [AH][ESP] makes the most sense since it makes it possible for a gateway to authenticate a packet without knowing how to decrypt it (tho' I don't know of anyone who ever made use of this capability). Implementers also liked this approach since it let you validate the ciphertext integrity before handing it to the crypto modules which, in the early days, were unnecessarily fragile. On the other hand, a crypto purist would argue that you get weaker authentication with [AH][ESP]. It's only authenticating the ciphertext. In theory, this could allow you to change the plaintext by varying the encryption process and the changed plaintext wouldn't be detected by the AH. Of course, this is largely a theoretical concern. It's not immediately clear what an attacker has to gain from this, nor is it clear that this is feasible in any real world IPSEC implementations. Rick. smith@securecomputing.com roseville, minnesota "Authentication" in bookstores http://www.visi.com/crypto/ From owner-ipsec@lists.tislabs.com Thu May 9 22:22:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4A5McL11511; Thu, 9 May 2002 22:22:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20326 Fri, 10 May 2002 00:38:36 -0400 (EDT) Message-ID: <002401c1f7de$6b10fb80$bc64a8c0@saket> From: "Saket Dandawate" To: Subject: IKE v1 are multiple ISAKMP SA allowed Date: Fri, 10 May 2002 10:21:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am implementing IKE v1 and i have few queries regarding ISAKMP SA formation. Is it possible to have 2 ISAKMP SAs between the same two peers. Consider the following case. 1. "A" peer places request for ISAKMP SA negotiation. 2. Peer "B" also places request for ISAKMP SA negotiation at the same time. So, at the same instance two Main Mode negotiations start. RFC 2409 says that after Main mode negotiation the IPsec SAs can be exchanged by either sides. So it sound logical to have only 1 main mode negotiation. So what do we do if two Main Mode's start simultaneously? If we have to discard one Main Mode which one should we discard? rfc 2409 doesnt say anything about multiple ISAKMP SA. thanks and regards Saket PSS pune From owner-ipsec@lists.tislabs.com Fri May 10 12:05:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AJ5SL15379; Fri, 10 May 2002 12:05:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21238 Fri, 10 May 2002 14:15:27 -0400 (EDT) Message-ID: <033c01c1f81f$d1169fc0$8800a8c0@xujia> From: "Xu, Jia" To: References: <002401c1f7de$6b10fb80$bc64a8c0@saket> Subject: A problem with FreeS/WAN on Redhat Linux 7.2 Date: Fri, 10 May 2002 20:40:07 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?= =?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?= =?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/10/2002 08:39:54 PM, Serialize by Router on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?= =?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?= =?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/10/2002 08:39:56 PM, Serialize complete at 05/10/2002 08:39:56 PM Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id OAA21233 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I ran into a problem when I tried to install the FreeS/WAN 1.97 on Redhat Linux 7.2 (Kernel 2.4.7-10). After I boot the machine using the new kernel, the IPSec package was installed correctly and I can use the command "ipsec". But IP networking got totally crashed. The route table became null and I can't ping any other machine. I checked the boot.log and found the following line: Ifup: Cannot open netlink socket: Address family not supported by protocol. What does this mean? Thanks, Jia From owner-ipsec@lists.tislabs.com Fri May 10 12:06:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AJ6CL15629; Fri, 10 May 2002 12:06:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21557 Fri, 10 May 2002 14:20:56 -0400 (EDT) Message-Id: <200205101806.g4AI6FaS002134@kebe.east.sun.com> Subject: JFK nit To: ipsec@lists.tislabs.com Date: Fri, 10 May 2002 14:06:15 -0400 (EDT) From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry if this has been repeated before... > 4.1 Structure > > Each message is a string of tag-length-value elements concatenated > together. Tags are one octet. Lengths are two octets, and specify > the number of octets of the value. Values are always integral > numbers of octets. All octets are in big-endian order. Ewwww. This is not a good choice. Modern machines work better with aligned data! Say you have two nonce tags in a row (Ni, followed by Nr). Say they start nicely on byte 0x10... 0x10 0x11 0x12 == 8 bytes 0x13 Ni msb ... 0x1a Ni lsb 0x1b I can load the whole nonce into a register, but I can't, because it starts at the byte-only-boundary of 0x13. JFK authors, please address this problem. If you want to discuss matters of bit-twiddling import, let me know! Dan From owner-ipsec@lists.tislabs.com Fri May 10 14:19:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALJgL26985; Fri, 10 May 2002 14:19:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21773 Fri, 10 May 2002 16:34:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200205101806.g4AI6FaS002134@kebe.east.sun.com> References: <200205101806.g4AI6FaS002134@kebe.east.sun.com> Date: Fri, 10 May 2002 13:46:33 -0700 To: Dan McDonald , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: JFK nit Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:06 PM -0400 5/10/02, Dan McDonald wrote: >Sorry if this has been repeated before... Or, more importantly, is part of a recent document that the WG is using as part of its decision-making process. Please see draft-ietf-ipsec-soi-features-00.txt, in which this is one of the options for one of the features listed there. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri May 10 14:19:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALJkL26997; Fri, 10 May 2002 14:19:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21802 Fri, 10 May 2002 16:40:19 -0400 (EDT) Date: Fri, 10 May 2002 13:49:57 -0700 (PDT) From: Brett Eldridge X-X-Sender: beldridg@vertigo.lo0.org To: "Xu, Jia" cc: ipsec@lists.tislabs.com Subject: Re: A problem with FreeS/WAN on Redhat Linux 7.2 In-Reply-To: <033c01c1f81f$d1169fc0$8800a8c0@xujia> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 10 May 2002, Xu, Jia wrote: > I checked the boot.log and found the following line: > Ifup: Cannot open netlink socket: Address family not supported by protocol. is your kernel built with this option: $ grep -i netlink .config CONFIG_NETLINK_DEV=y i'm not sure that it is the answer, but your error message makes it an obvious first guess. - brett From owner-ipsec@lists.tislabs.com Fri May 10 14:28:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALSoL27194; Fri, 10 May 2002 14:28:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21832 Fri, 10 May 2002 16:49:22 -0400 (EDT) Date: 10 May 2002 16:51:04 -0400 Message-ID: <001801c1f864$686126e0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Barbara Fraser'" , " 'list'" Subject: RE: New SOI features draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4.3.2.7.2.20020507182331.02c9c820@mira-sjc5-4.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think Paul's document talks about anything that I haven't discussed in the past, so for the sake of helping the discussion along, I'll summarize my opinions here. The IPsec WG has already reinvented the wheel twice, for mostly superficial reasons. Now we have the choice between fixing some specific problems with IKEv1 or reinventing the wheel again. I prefer the devil I know to the devil I don't. I don't think we should cripple the protocol for the sake of advancing somebody's political agenda. A method for extensions and vendor ids is essential. No matter what we do, we are going to run into unforseen incompatibilities with other protocols, (e.g. the ACK-spoofing on satellite connections or the sequence number problem with QoS or the problems with dynamic ports). People should be able to support whatever combination of encryption and authentication algorithms they want, including shared secrets. However, I welcome the idea of GUI ciphersuites to facilitate one-click interoperability. I think the distinction between negotiation of algorithms and ukases is BS; they are both negotiation. I do like the new wire formats for the SA proposals, though. Almost anything would be preferable to what we have in IKEv1. We should support identity protection to the extent that it's easy to do. Protection against passive attacks in both directions is best because then you don't have to worry about asymmetrical rekeying. I think that the protocol ought to have plausible deniability. The PD provided by IKEv2 and JFKr with RSA Sigs is not perfect, but I think it is adequate. I think we should rationalize the use of PFS by correlating the lifetime of keymat with the lifetime of the SAs it creates. Control channels have proven useful in the past. I don't discount the possibility of using an IPsec SA as a control channel (although hijacking a data channel would be annoying), but I am wary of a protocol that attempts to avoid control channels altogether. Also, I will speculate that the QoS will be an important consideration in the future. I think that adding 2 extra messages when under attack is the best engineering trade-off for DoS protection. The bogus UDP fragmentation avoidance strategy described in IKEv2 is good, although I don't think people will implement it in the near future due to the layer violation. The technique in JFK may be superior, but it's an even worse layer violation. Birth certificates are a worthwhile idea, but they don't solve all the link state problems, such as when a host crashes and never comes back up (or gets assigned a different IP in a mobile scenario). I don't want us to remove all of the error messages from the protocol. Some tweaking of the current error cases would be nice, though. (I am willing to volunteer.) IKEv2 is quite different from v1, so I'm not sure it's going to allow us to reuse as much of the protocol code as I originally thought. However, what I realize is that many sections of the ike process that perform tasks other than IKE negotiation (such as the event handler and the policy engine) can remain largely unchanged, so IKEv2 really does provide a tangible benefit in terms of code reuse. I would also like us to ensure that we remain compatible with the MSec WG. GDOI is based on IKEv1, and it would be very easy for them to integrate with IKEv2 as well, but not with JFK. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Barbara Fraser > Sent: Tuesday, May 07, 2002 9:46 PM > To: ipsec@lists.tislabs.com > Subject: New SOI features draft > > > Thanks to the IKEv2 and JFK folks, and Paul Hoffman for > developing the SOI > features document. Ted and I would like to urge you to read it and to > discuss it on the list. We need to decide which features are > important to > SOI so that we can move forward with the protocol design > work. On page 3 of > the document, there are three identified core differences > between IKEv2 and > JFK: 1) whether the protocol has one phase or two phases, 2) how DoS > attacks are thwarted, and 3) the use of shared secret authentication. > According to the document, one path the working group can > take is to decide > which of these three differences is important and to then > select among the > remaining features. > > The scenarios where IPsec/IKE is being used, as described in Cheryl's > document, are not included in the features document. > Therefore, one area we > must explore is the match between the above 3 differentiating > qualities and > the community's use and expectation of IPsec/IKE. Is there an > installed > base that expects these features to be present, and given the > answer, what > does the working group want to do. > > Let's see if we can come to consensus in the next month. This > would allow > some time for a new or updated protocol draft to be prepared > prior to the > July IETF meeting. > > thanks, > Barb > From owner-ipsec@lists.tislabs.com Fri May 10 14:29:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALTVL27237; Fri, 10 May 2002 14:29:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21819 Fri, 10 May 2002 16:47:22 -0400 (EDT) Message-Id: <200205102059.g4AKxHSj004982@kebe.east.sun.com> Subject: Re: JFK nit In-Reply-To: from Paul Hoffman / VPNC at "May 10, 2002 01:46:33 pm" To: Paul Hoffman / VPNC Date: Fri, 10 May 2002 16:59:17 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Sorry if this has been repeated before... > > Or, more importantly, is part of a recent document that the WG is > using as part of its decision-making process. Please see > draft-ietf-ipsec-soi-features-00.txt, in which this is one of the > options for one of the features listed there. Ummm, I think you miss my point. I don't see anything in section 6.1 that deals with data alignment and making sure payloads are optimized for register load/store operations. I don't care about JFK's proposed TLV vs. the way IKEv2 does it, but I do care very much about a TLV that is encoded to optimize for modern CPU design. Dan From owner-ipsec@lists.tislabs.com Fri May 10 14:41:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALfUL27406; Fri, 10 May 2002 14:41:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21855 Fri, 10 May 2002 17:01:25 -0400 (EDT) Date: 10 May 2002 17:03:34 -0400 Message-ID: <001a01c1f866$26f2bf00$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Markku Savela'" Cc: "'list'" Subject: RE: Specification of tunnel/transport attribute in IKEv2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200205082222.BAA26187@burp.tkv.asdf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The merit of this ordering is not the point. Since 90% of IPsec implementations either fundamentally do not support this feature, or maybe could support it but have no desire to do so, yours is a rather edge case. Therefore, I suggest that you enable it via a proprietary extension. Leaving the specification vague on some critical issues because a few people had some esoteric objections is exactly where we went wrong with IKEv1. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Wednesday, May 08, 2002 6:23 PM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Specification of tunnel/transport attribute in IKEv2 > > > > > Also, we decided that the ordering of the protocols in the proposal > > shouldn't matter, since the only ordering that makes sense is > > [AH][ESP] > > But, if I do *WANT* to do [ESP][AH]? Basicly, I want to check IP > headers, but not wanting the sniffers to know that I'm checking... > > ...and if someone wonders what is checked: if I have > > [IP-hdrs][ESP][AH]... > > then first ESP gets applied and removed resulting > > [IP-hdrs][AH]... > > and then AH checks the IP-hdrs. > > (and yes, the IPSEC I wrote can do this, if IKE wouldn't object.. :-) > > > From owner-ipsec@lists.tislabs.com Fri May 10 15:00:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AM0SL27785; Fri, 10 May 2002 15:00:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21936 Fri, 10 May 2002 17:21:50 -0400 (EDT) Date: Sat, 11 May 2002 00:33:40 +0300 Message-Id: <200205102133.AAA02218@burp.tkv.asdf.org> From: Markku Savela To: andrew.krywaniuk@alcatel.com CC: ipsec@lists.tislabs.com In-reply-to: <001a01c1f866$26f2bf00$1e72788a@ca.alcatel.com> (andrew.krywaniuk@alcatel.com) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <001a01c1f866$26f2bf00$1e72788a@ca.alcatel.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The merit of this ordering is not the point. Since 90% of IPsec > implementations either fundamentally do not support this feature, or maybe > could support it but have no desire to do so, yours is a rather edge case. > Therefore, I suggest that you enable it via a proprietary extension. > > Leaving the specification vague on some critical issues because a few people > had some esoteric objections is exactly where we went wrong with IKEv1. In my opinion, IKE went wrong when it started doing policy checking, instead of just being a key negotiation. If IKE negotiated only keys, these ordering issues would never have surfaced. As far as RFC-2401 is concerned, any ordering is possible (and policy dictates the required order). Requiring something to be "proprietary extension" just because some couldn't read the RFC-2401 properly, is somewhat sad thing. From owner-ipsec@lists.tislabs.com Sat May 11 10:15:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4BHFbL02270; Sat, 11 May 2002 10:15:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23535 Sat, 11 May 2002 12:29:40 -0400 (EDT) Message-Id: <200205111641.g4BGfiT68858@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: addresses and IKEv2 Date: Sat, 11 May 2002 18:41:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IKEv2 specs are far more clean than old IKE RFCs about addresses of the two "parties" but there are still some "to be clarify" points or even choices. I've used my I-D about IPsec/IKEv1 and Mobile IPv6 (draft-dupont-ipsec-mipv6-00.txt) as a reference (BTW I am still looking for some help for a new version of it). Each party can get up to 5 addresses: - the address used for the transport of phase 1 messages (T1) - the address in the phase 1 identity (I1) - the address in the party's certificate (C1) - the address used for the transport of phase 2 messages (T2) - the address in the phase 2 traffic selector (which replaces IKEv1 phase 2 identity) (I2) (I don't consider the optional IKEv2 phase 2 identity payload until it has an interesting semantic when it is an address identity). A not-really-written-down rule specifies the phase 1 identity must be the subject or an alternate subject of the party's certificate (when certificates are used but in any case the identity and the authentication means must be strongly bound). So if I1 and C1 exist then I1 == C1. There are many good reasons to never provide I1 and C1 (the "road warrior" case, NATs, mobility, etc). So T1 should be the address found in message headers and should not be verified. I don't disagree with this choice but it opens a transient fake-NAT attack vulnerability (see PS2). If only T1 exists in phase 1 then there are two interesting cases, T1 != T2 and T1 != I2. The case where the two phases don't get the same address in message headers is already implicitly taken into account by the IKE-SA SPI notion: - IKE-SA SPIs are (likely in IKEv1, always in IKEv2) unique - IKE-SA SPIs permit more than one SA between two parties - IKE-SA SPIs permit a party to change its address because they, by definition, index the SAs. Section 2.11 "Address and Port Agility" should be more explicit about this kind of usage of SPIs. Note the statement "IKE implicitly sets up ESP, AH, and IPcomp associations for the same IP addresses it runs over" must in this case interpret "IP address it runs over" as (actual) T2, not (old) T1. In general, the address of the party is found in the last message protected by the IKE-SA. The last case is when the TS doesn't match the transport address: - for a tunnel mode SA establishment, this is only a consequence of the existence of two headers (T2 goes in the outer one, I2 in the inner one). - for a transport mode this is an explicit address overwriting which must be acceptable according to the policy but there is at least a situation where this is needed (see PS3) so I'll strongly object if T2 != I2 becomes forbidden for transport mode. Regards Francis.Dupont@enst-bretagne.fr PS1: SUMMARY: - explain somewhere the identity payload role. - explain the advantages (and drawbacks) to use names (i.e. not addresses) as identities (in the general meaning). Perhaps we need some SHOULD/MAY for the different types of identity payloads. - explain the role of SPIs of IKE-SA. - don't throw away the transport/tunnel mode issue in phase 2. PS2: transient pseudo-NAT attack: This is an attack using IKE between SGs, not an attack against IKE itself. The idea is simple: the attacker goes between the two SGs when they are doing an IKE exchange and changes the source address of messages (only one with IKEv2 phase 2) to the address of its victim. If this is not caught by some ingress filtering (RFC 2827) the whole traffic to the spoofed SG will be redirected to the victim. This attack is generic against any protocol which can redirect traffic (mobile IP for instance) and has provision for NAT traversal. Unfortunately to make the protocol more efficient (two message phase 2 for instance) only makes the attack easier by reducing the time the attacker must be on the path (where it can already do the pseudo-NAT attack by redirecting everything to its victim. Here IKE adds the "transient" feature and the SG (or in mobility the home agent) the mass effect). I don't know any defense compatible with NAT traversal (for instance to protect the party address). PS3: address overwriting in transport mode: When an IPv6 mobile node (MN) is in visit (i.e. not at home) and sends its first binding update (BU) to its home agent (HA) (aka the home registration), it must protect it using a SA, for instance a transport mode ESP SA with the home address (H@) (note this solution has a lower case "must" in the mobile IPv6 I-D). Until the BU is processed, the MN cannot use its home address: only the care-of address (Co@) is available. So the MN must use the Co@ as the source address of IKE messages without a home address destination option (H@O), because the packets to the MN must be addressed to its Co@ until the home registration is done (after the HA will intercept all packets to the MN H@ and tunnel them to the MN using the Co@, so the issue is only for this particular case). So the obvious solution is to overwrite the SA address by the proper TS (it works as in IKEv1 but is easier to explain/implement) *and* to encode in the policy the authorization to do that (the HA is supposed to know its MNs so this is a classical key/cert & address binding problem, local DNSSEC on the home network reverse zone works well for instance). From owner-ipsec@lists.tislabs.com Sat May 11 17:36:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4C0akL09752; Sat, 11 May 2002 17:36:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23923 Sat, 11 May 2002 19:50:02 -0400 (EDT) Message-Id: <200205120002.g4C02fT18078@sydney.East.Sun.COM> Date: Sat, 11 May 2002 20:02:41 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Ikev2 IKE-SA rekey collision--summary To: ipsec@lists.tislabs.com, dfaucher@lucent.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SfWWeTM5gwg9IF+Xpuy/sg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It looks like several votes in favor of deterministically choosing which SA to kill in the case of duplicate SAs, based on initiator nonce. This definitely should be in the spec, since everyone has to agree. We can do it in the next editing pass. I haven't seen any objections. Radia From owner-ipsec@lists.tislabs.com Sat May 11 18:00:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4C10iL10081; Sat, 11 May 2002 18:00:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24036 Sat, 11 May 2002 20:26:08 -0400 (EDT) Message-Id: <200205120037.g4C0bsT18803@sydney.East.Sun.COM> Date: Sat, 11 May 2002 20:37:54 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Ikev2 Traffic Selector payload To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TW4rdDMMEtdlc7whE+uREA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I too agree with Valery Smyslov's suggestion: Have the initiator specify the specifics of the packet that caused it to want to create the child-SA. However, there are a bunch of ways this could be done. Any opinions? For example, we could say that the first selector of TSi MAY be the specifics of the source of the packet that's causing the initiator to create the child-SA, and the first selector of TSr MAY be the specifics of the destination of the packet. The responder will choose the largest ranges of addresses and ports it can accomodate. So far, no changes to the spec. But here's the change that incorporates Valery's suggestion, I think: If the responder has multiple ranges, and can't choose, then he MUST choose the largest set that encompasses the first TSi and first TSr. Also, if the initiator didn't put the specifics of the first packet into the first TSi and first TSr, then should we: a) generalize the "SINGLE-PAIR-REQUIRED" to instead mean "you have to be more specific, or b) (I think I prefer this one), have a new error type for "more specific ranges required". After receiving such an error, the initiator can guarantee success next time by putting in the specifics of the packet into the first TSi and first TSr. By the way, it's 12 bytes for each one, so it's 24 bytes of overhead to include this information. I'm confused about what a firewall is supposed to do if it's just configured that when it comes up it creates a set of SAs, and there is no specific packet that is triggering the SA creation. I suppose that's just a misconfiguration between the policies of the two sides? Radia From owner-ipsec@lists.tislabs.com Sun May 12 22:58:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4D5wIL23022; Sun, 12 May 2002 22:58:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26495 Mon, 13 May 2002 00:58:32 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Dan McDonald Cc: ipsec@lists.tislabs.com Subject: Re: JFK nit Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 May 2002 20:39:43 -0400 Message-Id: <20020513003943.4A1417B51@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200205101806.g4AI6FaS002134@kebe.east.sun.com>, Dan McDonald writes : >Sorry if this has been repeated before... > >> 4.1 Structure >> >> Each message is a string of tag-length-value elements concatenated >> together. Tags are one octet. Lengths are two octets, and specify >> the number of octets of the value. Values are always integral >> numbers of octets. All octets are in big-endian order. > > >Ewwww. This is not a good choice. Modern machines work better with aligned >data! Say you have two nonce tags in a row (Ni, followed by Nr). Say they >start nicely on byte 0x10... > > > 0x10 > 0x11 > 0x12 == 8 bytes > 0x13 Ni msb > ... > 0x1a Ni lsb > 0x1b > >I can load the whole nonce into a register, but I can't, because it starts at >the byte-only-boundary of 0x13. > >JFK authors, please address this problem. If you want to discuss matters of >bit-twiddling import, let me know! > We're completely agnostic about details like that. "send text". --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Mon May 13 06:17:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DDH5L12392; Mon, 13 May 2002 06:17:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27431 Mon, 13 May 2002 08:34:30 -0400 (EDT) Message-Id: <200205130851.RAA15095@csnet1.cs.tsinghua.edu.cn> Date: Mon, 13 May 2002 17:4:18 +0800 From: =?GB2312?Q?=B6=AD=CF=FE=BB=A2?= Reply-To: dongcat@csnet1.cs.tsinghua.edu.cn To: "ipsec@lists.tislabs.com" Subject: which number is assigned to ID_IPV4_ADDR? Organization: =?GB2312?Q?=C7=E5=BB=AA=B4=F3=D1=A7=BC=C6=CB=E3=BB=FA=CF=B5?= X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id EAA27028 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I found in rfc2408, ISAKMP id type ID_IPV4_ADDR's value is 0. But in rfc2407, ID_IPV4_ADDR's value is defined as 1. When I inspected ike message from Win2000(the fifth message of main mode), I found ID_IPV4_ADDR's value is 1. If it were 0, I will be less confused. Anyone know which value should be used? I am tired to look into the rfc:( ¡¡ Dong Xiaohu dongcat@csnet1.cs.tsinghua.edu.cn¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ From owner-ipsec@lists.tislabs.com Mon May 13 06:20:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DDKXL12505; Mon, 13 May 2002 06:20:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27425 Mon, 13 May 2002 08:33:29 -0400 (EDT) X-Originating-IP: [211.167.226.82] From: "Jiang He" To: ipsec@lists.tislabs.com Date: Mon, 13 May 2002 15:44:50 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 May 2002 07:44:50.0912 (UTC) FILETIME=[1032EE00:01C1FA52] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In RFC2401, for inbound processing, the following packet fields are used to look up the SA in the SAD: Outer Header's Destination IP address, IPsec Protocol and SPI. Why not simply use SPI as index? The SPI is enough to look up SAD. Using SPI as index, concerning nothing about "Outer Header's Destination IP address", it might be convenient for SPI to be chosen so as to be a table index for fast lookups of SAs, and also give a favor IPSec-NAT solution. He Jiang _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ipsec@lists.tislabs.com Mon May 13 06:37:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DDbeL12902; Mon, 13 May 2002 06:37:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27546 Mon, 13 May 2002 08:59:36 -0400 (EDT) Message-Id: <200205131312.RAA06214@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com, Radia Perlman - Boston Center for Networking Date: Mon, 13 May 2002 17:12:34 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Ikev2 Traffic Selector payload In-reply-to: <200205120037.g4C0bsT18803@sydney.East.Sun.COM> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 11 May 02, at 20:37, Radia Perlman - Boston Center wrote: Radia, > I too agree with Valery Smyslov's suggestion: Have the initiator specify > the specifics of the packet that caused it to want to create > the child-SA. However, there are a bunch of ways this > could be done. Any opinions? Actually, the suggestion could be generalized a bit: let initiator put into the first TSi and the first TSr selector of the proposed SA that, from initiator's point of view, is absolutely required for SA to be useful for him/her. In most cases those TSi and TSr will be taken from the packet that triggered the negotiation. The following TSi and TSr (if any) in initiator's proposal reflect what additional addresses/ports this SA, according to initiator's SPD, should encompass. In other words, the first TSi and TSr show the minimal SA "width" that will satisfy initiator, while all TSs (both the first and the following) - an optimal SA "width" (according to his/her SPD). The generalization is that now the first TSi and first TSr can contain anything, not only a single address and a single port. For example, they may contain range or subnet. However, if they are filled from actual packet, they still will contain single values. > For example, we could say that the first selector of TSi MAY be the > specifics of the source of > the packet that's causing the initiator to create the child-SA, > and the first selector of TSr MAY be the specifics of the destination > of the packet. > > The responder will choose the largest ranges of addresses and ports > it can accomodate. > > So far, no changes to the spec. Except that the special role of the first TSi and TSr must be documented. > But here's the change that incorporates Valery's suggestion, I think: > > If the responder has multiple ranges, and can't choose, then he > MUST choose the largest set that encompasses the first TSi and first TSr. I'd rather to rephrase this in more general way, for example (taking as a base 3-rd para from section 2.9): The Responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating one or more members of the set of traffic selectors provided the set does not become the NULL set. However, the result of the narrowing MUST encompass the first TSi and first TSr from initiator's proposal. Otherwise SA MUST NOT be established. > Also, if the initiator didn't put the specifics of the first packet into > the first TSi and first TSr, then should we: I'm a bit confused here. TS payloads are mandatory and contain at least one TS substructure (according to the spec). So, "the first" TSi and TSr are always exist. How responder could know whether initiator put specifics of the packet into the first TSi and TS or something else? I'd suggest he/she just always choose his TS so, that: 1. initiator's the first TSi and TSr MUST be encompassed 2. initiator's the rest TSi and TSr MAY be encompassed (or partly encompassed) > a) generalize the "SINGLE-PAIR-REQUIRED" to instead mean "you have to > be more specific, or This notification is unnecessary with my original suggestion, but is still useful with generalized one, because in latter case the first TSi and TSr may contain ranges or subnets (and port ranges too). > b) (I think I prefer this one), have a new error type for "more specific > ranges required". After receiving such an error, the initiator can > guarantee success next time by putting in the specifics of the > packet into the first TSi and first TSr. I'm confused, please see above. > By the way, it's 12 bytes for > each one, so it's 24 bytes of overhead to include > this information. > > I'm confused about what a firewall is supposed to do if it's just > configured that when it comes up it creates a set of SAs, and there > is no specific packet that is triggering the SA creation. I suppose > that's just a misconfiguration between the policies of the two sides? With generalized suggestion it's easy to achieve: initiator just put the desirable SA selector into the first TSi and TSr. > Radia Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Mon May 13 09:34:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DGYjL17650; Mon, 13 May 2002 09:34:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27722 Mon, 13 May 2002 09:38:04 -0400 (EDT) Message-Id: <200205131349.g4DDnQR9029024@kebe.east.sun.com> Subject: Re: JFK nit In-Reply-To: <20020513003943.4A1417B51@berkshire.research.att.com> from "Steven M. Bellovin" at "May 12, 2002 08:39:43 pm" To: "Steven M. Bellovin" Date: Mon, 13 May 2002 09:49:26 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >JFK authors, please address this problem. If you want to discuss matters of > >bit-twiddling import, let me know! > > > > We're completely agnostic about details like that. "send text". Okay! Originally, you have this: > 4.1 Structure > > Each message is a string of tag-length-value elements concatenated > together. Tags are one octet. Lengths are two octets, and specify > the number of octets of the value. Values are always integral > numbers of octets. All octets are in big-endian order. Here is my proposed replacement text. I'm not sure what the consensus is w.r.t. 32-bit or 64-bit alignment. That choice will be expressed in {32,64} bit csh-style regexps. (I.e. given {a,b}, if you want 32-bit, substitute a, if you want 64-bit, substitute b.) 4.1 Structure Each message is a string of tag-length-values elements concatenated together. Each TLV element is alignable on a {32,64}-bit boundary. Tags are two octets, and lengths are two octets. Lengths specify the number of octets of the value. A subsequent tag is read at the next {32,64}-bit boundary. Computing the offset of next boundary from the current element's length is straightforward: ((len + {3,7}) / {4,8}) * {4,8}. Any octets needed for alignment padding MUST be set to zero. NOTE FOR 64-Bit FOLKS: If there's a strong movement toward 64-bitness, you may wish to increase the type-and-length to total 64 bits, so that the value starts on a 64-bit boundary. (Useful for loading an 8-byte nonce into a register with one instruction.) Dan From owner-ipsec@lists.tislabs.com Mon May 13 10:09:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DH9KL19140; Mon, 13 May 2002 10:09:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27990 Mon, 13 May 2002 12:19:18 -0400 (EDT) Message-ID: <3CDFEA74.32E5908E@F-Secure.com> Date: Mon, 13 May 2002 19:31:48 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: About draft-ietf-ipsec-soi-features-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2002 16:31:48.0770 (UTC) FILETIME=[ADE93020:01C1FA9B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suggest applying the well known KISS principle. In particular, favor the features that produce the simplest SOI possible, without too much regard for IKEv1 code re-use. Code is generally fast to write but slow to actually make function perfectly. I don't pretend to have read through that whole draft, but I'd apply the KISS principle to the authentication feature as follows. Since certificate authentication appears to be sufficient, and all usable products needs certificate support anyway, throw out preshared keying. One authentication method is easier to test and make interoperable than two. Self-signed certs are also more secure because the private key is still only in one place. As for dead peer detection, I'd favor IKEv2 on the grounds that the complexity of always negotiating (or failing to negotiate) SAs permitting ICMP pings through is more than the complexity of defining it to work via phase 1 messages and not negotiating anything between the peers. This is particularly true of tunnel mode SAs between gateways; who do you ping through the tunnel? Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin 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 May 13 10:11:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DHBHL19264; Mon, 13 May 2002 10:11:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28026 Mon, 13 May 2002 12:31:21 -0400 (EDT) From: Yogesh.Swami@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: DOS attacks with Cookies Date: Mon, 13 May 2002 11:43:19 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com> Thread-Topic: DOS attacks with Cookies Thread-Index: AcH6nUme4shNw3bqRlOF4nSIjtIluw== To: X-OriginalArrivalTime: 13 May 2002 16:43:19.0608 (UTC) FILETIME=[49AEB380:01C1FA9D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA28018 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a question/comment on the use of Cookies for key exchange. I think there is a potential for very easy and more pointed DOS attacks with the present key exchange mechanisms. Let me give an example to explain this. Lets say Alice wants to establish a Phase-1 SA with Bob. Also, lets say Trudy--who wants to deny Alice any access to resources--can some how snoop Alice's packets. Also let the round trip time between Alice and Trudy be far less than the roundtrip time between Alice and Bob (say Trudy is on the same LAN as Alice for the sake of this example--but Trudy does not necessarily have to be on the same LAN, all she needs is a) ability to see Alice's packet and b) her round trip time to be less than that of Bob). When Alice sends her cookie, Trudy sees this packet coming on UDP 500, and quickly responds to Alice's cookie with a random cookie and sets the source IP address in her response packet to be that of Bob and sends it to Alice. Alice will receive this Cookie response from Trudy long before she can receive Bob's response and since Alice has no way of knowing if this cookie really came from Bob, she will respond to this cookie thinking this is a Legitimate response and proceed with the Deffie Hellmann exchange to Bob. When Bob receives this cookie, the cookies will not match (Since the cookie was generated by Trudy) and he will just reject the request thinking that Alice was trying to attack him. This way Trudy has successfully prevented Alice from having a secure channel with Bob. Question: What is Alice supposed to do when she receives a Duplicate Message with a Different Cookie from the same host? Please consider the case when there was a retransmission and the retransmitted packet got corrupted in the way and the two cookies--though legitimate--have different values. If Trudy can automate this process, she can deny access to anyone who she can snoop. If someone can write a worm that does this automatically and spread this across the internet (in this case on just needs to snoop the loop back interface and does not even need to see packet on the wire) one can create a lot more damage. If Alice and Bob were to be two SG (security gateways), then Trudy can virtually isolate every one behind Alice's SG from accessing Bob's resources. In the process of avoiding DOS attacks we have opened room for even worse attacks (this is worse because it could be targeted towards a particular set of people without affecting others. So, for example, if two companies want to vote for a merger one of them can prevent the other by simply not allowing any secure channel, while people from the other company can easily do so) I guess, the only solution is to do authentication before doing anything else -- in which case we don't need any cookies anymore and we can save a round trip too. Any comments? Thanks Best Regards Yogesh From owner-ipsec@lists.tislabs.com Mon May 13 11:55:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DIt5L22436; Mon, 13 May 2002 11:55:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28333 Mon, 13 May 2002 14:17:56 -0400 (EDT) Message-ID: <20020513183017.95436.qmail@web21302.mail.yahoo.com> Date: Mon, 13 May 2002 11:30:17 -0700 (PDT) From: SatishK Amara Subject: Re: DOS attacks with Cookies To: Yogesh.Swami@nokia.com, ipsec@lists.tislabs.com In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yogesh, The problem you have specified is mentioned in IKEV2 draft. In this case Alice should process multiple responses for it's request. This would solve the problem. Satish --- Yogesh.Swami@nokia.com wrote: > Hi, > > I have a question/comment on the use of Cookies for > key exchange. I think there is a potential for very > easy and more pointed DOS attacks with the present > key exchange mechanisms. Let me give an example to > explain this. > > Lets say Alice wants to establish a Phase-1 SA with > Bob. Also, lets say Trudy--who wants to deny Alice > any access to resources--can some how snoop Alice's > packets. Also let the round trip time between Alice > and Trudy be far less than the roundtrip time > between Alice and Bob (say Trudy is on the same LAN > as Alice for the sake of this example--but Trudy > does not necessarily have to be on the same LAN, all > she needs is a) ability to see Alice's packet and b) > her round trip time to be less than that of Bob). > > When Alice sends her cookie, Trudy sees this packet > coming on UDP 500, and quickly responds to Alice's > cookie with a random cookie and sets the source IP > address in her response packet to be that of Bob and > sends it to Alice. > > Alice will receive this Cookie response from Trudy > long before she can receive Bob's response and since > Alice has no way of knowing if this cookie really > came from Bob, she will respond to this cookie > thinking this is a Legitimate response and proceed > with the Deffie Hellmann exchange to Bob. > > When Bob receives this cookie, the cookies will not > match (Since the cookie was generated by Trudy) and > he will just reject the request thinking that Alice > was trying to attack him. This way Trudy has > successfully prevented Alice from having a secure > channel with Bob. > > Question: What is Alice supposed to do when she > receives a Duplicate Message with a Different Cookie > from the same host? Please consider the case when > there was a retransmission and the retransmitted > packet got corrupted in the way and the two > cookies--though legitimate--have different values. > > If Trudy can automate this process, she can deny > access to anyone who she can snoop. If someone can > write a worm that does this automatically and spread > this across the internet (in this case on just needs > to snoop the loop back interface and does not even > need to see packet on the wire) one can create a lot > more damage. > > If Alice and Bob were to be two SG (security > gateways), then Trudy can virtually isolate every > one behind Alice's SG from accessing Bob's > resources. In the process of avoiding DOS attacks we > have opened room for even worse attacks (this is > worse because it could be targeted towards a > particular set of people without affecting others. > So, for example, if two companies want to vote for a > merger one of them can prevent the other by simply > not allowing any secure channel, while people from > the other company can easily do so) > > I guess, the only solution is to do authentication > before doing anything else -- in which case we don't > need any cookies anymore and we can save a round > trip too. Any comments? > > Thanks > Best Regards > Yogesh ===== In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ipsec@lists.tislabs.com Mon May 13 11:55:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DIt5L22442; Mon, 13 May 2002 11:55:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28334 Mon, 13 May 2002 14:17:58 -0400 (EDT) Message-ID: <20020513183003.25276.qmail@web21309.mail.yahoo.com> Date: Mon, 13 May 2002 11:30:03 -0700 (PDT) From: SatishK Amara Subject: Re: DOS attacks with Cookies To: Yogesh.Swami@nokia.com, ipsec@lists.tislabs.com In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yogesh, The problem you have specified is mentioned in IKEV2 draft. In this case Alice should process multiple responses for it's request. This would solve the problem. Satish --- Yogesh.Swami@nokia.com wrote: > Hi, > > I have a question/comment on the use of Cookies for > key exchange. I think there is a potential for very > easy and more pointed DOS attacks with the present > key exchange mechanisms. Let me give an example to > explain this. > > Lets say Alice wants to establish a Phase-1 SA with > Bob. Also, lets say Trudy--who wants to deny Alice > any access to resources--can some how snoop Alice's > packets. Also let the round trip time between Alice > and Trudy be far less than the roundtrip time > between Alice and Bob (say Trudy is on the same LAN > as Alice for the sake of this example--but Trudy > does not necessarily have to be on the same LAN, all > she needs is a) ability to see Alice's packet and b) > her round trip time to be less than that of Bob). > > When Alice sends her cookie, Trudy sees this packet > coming on UDP 500, and quickly responds to Alice's > cookie with a random cookie and sets the source IP > address in her response packet to be that of Bob and > sends it to Alice. > > Alice will receive this Cookie response from Trudy > long before she can receive Bob's response and since > Alice has no way of knowing if this cookie really > came from Bob, she will respond to this cookie > thinking this is a Legitimate response and proceed > with the Deffie Hellmann exchange to Bob. > > When Bob receives this cookie, the cookies will not > match (Since the cookie was generated by Trudy) and > he will just reject the request thinking that Alice > was trying to attack him. This way Trudy has > successfully prevented Alice from having a secure > channel with Bob. > > Question: What is Alice supposed to do when she > receives a Duplicate Message with a Different Cookie > from the same host? Please consider the case when > there was a retransmission and the retransmitted > packet got corrupted in the way and the two > cookies--though legitimate--have different values. > > If Trudy can automate this process, she can deny > access to anyone who she can snoop. If someone can > write a worm that does this automatically and spread > this across the internet (in this case on just needs > to snoop the loop back interface and does not even > need to see packet on the wire) one can create a lot > more damage. > > If Alice and Bob were to be two SG (security > gateways), then Trudy can virtually isolate every > one behind Alice's SG from accessing Bob's > resources. In the process of avoiding DOS attacks we > have opened room for even worse attacks (this is > worse because it could be targeted towards a > particular set of people without affecting others. > So, for example, if two companies want to vote for a > merger one of them can prevent the other by simply > not allowing any secure channel, while people from > the other company can easily do so) > > I guess, the only solution is to do authentication > before doing anything else -- in which case we don't > need any cookies anymore and we can save a round > trip too. Any comments? > > Thanks > Best Regards > Yogesh ===== In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ipsec@lists.tislabs.com Mon May 13 11:55:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DItuL22495; Mon, 13 May 2002 11:55:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28307 Mon, 13 May 2002 14:13:53 -0400 (EDT) Message-ID: <605C42246151B7498423278ED555306F04C05A@skat.sky.com> From: michael lin To: "Ipsec (E-mail)" Subject: NAT Traversal - Recovering from the expiring NAT mappings Date: Mon, 13 May 2002 11:26:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In draft-ietf-ipsec-nat-ike-02.txt, it said 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 ends which are NOT behind NAT SHOULD use the last valid authenticated packet from the other end to determine which IP and port addresses the 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). I cannot fully understand. Suppose following: A --- NAT --- Internat --- B 1.1.1.1 port x -----> 1.1.1.1 port x -----> 1.1.1.1 port x -----> (LAST packet) reboot 1.1.1.2 port y -----> (NEXT packet) If the NEXT packet (source IP 1.1.1.2 and port y) passes the authentication check, B will know the A's IP and port have been changed, right? But in the draft, it said "the LAST valid authenticated packet". What does it mean? Why is it NEXT packet, but LAST packet? And since the source IP and port could be changed, does it mean B don't need to check source IP and port? If the packet passes authentication check, the packet is coming from the right source. Michael From owner-ipsec@lists.tislabs.com Mon May 13 12:19:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DJJTL23226; Mon, 13 May 2002 12:19:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28452 Mon, 13 May 2002 14:40:05 -0400 (EDT) Message-ID: <605C42246151B7498423278ED555306F04C05B@skat.sky.com> From: michael lin To: "Ipsec (E-mail)" Subject: NAT Traversal - Manual key remote user Date: Mon, 13 May 2002 11:52:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, If a remote user used manual key, there will be no IKE neogotication to negociate NAT-Traversal. How does NAT Traversal work? Just enable UDP Encapsulation (not NAT-Traversal, since there is no IKE) in both client and server? Michael From owner-ipsec@lists.tislabs.com Mon May 13 14:46:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DLkeL27368; Mon, 13 May 2002 14:46:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28777 Mon, 13 May 2002 17:06:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: NAT Traversal - Manual key remote user Date: Mon, 13 May 2002 14:19:16 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC104545C2C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: NAT Traversal - Manual key remote user Thread-Index: AcH6sKlQWVnS6fA1QFGqJwsh12xv+QAExooA From: "William Dixon" To: "michael lin" , "Ipsec (E-mail)" X-OriginalArrivalTime: 13 May 2002 21:19:17.0375 (UTC) FILETIME=[D6E170F0:01C1FAC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA28774 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, like the rest of the IPsec SA properties. -----Original Message----- From: michael lin [mailto:michaell@servgate.com] Sent: Monday, May 13, 2002 11:52 AM To: Ipsec (E-mail) Subject: NAT Traversal - Manual key remote user Hi, If a remote user used manual key, there will be no IKE neogotication to negociate NAT-Traversal. How does NAT Traversal work? Just enable UDP Encapsulation (not NAT-Traversal, since there is no IKE) in both client and server? Michael From owner-ipsec@lists.tislabs.com Mon May 13 18:59:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E1xCL03774; Mon, 13 May 2002 18:59:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA29148 Mon, 13 May 2002 21:18:11 -0400 (EDT) Message-ID: <089101c1fae6$bf43acb0$8800a8c0@xujia> From: "Xu, Jia" To: "Jiang He" , References: Subject: Re: Date: Tue, 14 May 2002 09:29:09 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?= =?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?= =?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/14/2002 09:29:08 AM, Serialize by Router on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?= =?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?= =?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/14/2002 09:29:10 AM, Serialize complete at 05/14/2002 09:29:10 AM Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id VAA29143 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You should read the standard more carefully. SPI is used to uniquely identify a security association when both Dest IP and Pro are equal. Jia----- Original Message ----- From: "Jiang He" To: Sent: Monday, May 13, 2002 3:44 PM > In RFC2401, for inbound processing, the following packet fields are used to > look up the SA in the SAD: Outer Header's Destination IP address, IPsec > Protocol and SPI. Why not simply use SPI as index? The SPI is enough to look > up SAD. > Using SPI as index, concerning nothing about "Outer Header's Destination IP > address", it might be convenient for SPI to be chosen so as to be a table > index for fast lookups of SAs, and also give a favor IPSec-NAT solution. > > He Jiang > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > From owner-ipsec@lists.tislabs.com Mon May 13 20:23:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E3N0L06289; Mon, 13 May 2002 20:23:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29366 Mon, 13 May 2002 22:39:21 -0400 (EDT) Message-Id: <200205140251.g4E2pVT16937@sydney.East.Sun.COM> Date: Mon, 13 May 2002 22:51:30 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Ikev2 Traffic Selector payload To: ipsec@lists.tislabs.com, Radia.Perlman@sun.com, svan@trustworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VUKOBwmMoi+9kBDVxlofvg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov said: >> The Responder is allowed to narrow the choices by selecting a >> subset of the traffic, for instance by eliminating one or more >> members of the set of traffic selectors provided the set does >> not become the NULL set. However, the result of the narrowing >> MUST encompass the first TSi and first TSr from initiator's >> proposal. Otherwise SA MUST NOT be established. I don't think adding the last 2 sentences work. The part about how the narrowing MUST encompass... My suggested wording was that the From owner-ipsec@lists.tislabs.com Mon May 13 20:26:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E3QOL06381; Mon, 13 May 2002 20:26:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29403 Mon, 13 May 2002 22:52:33 -0400 (EDT) Message-Id: <200205140304.g4E34XT17324@sydney.East.Sun.COM> Date: Mon, 13 May 2002 23:04:33 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Ikev2 Traffic Selector payload To: ipsec@lists.tislabs.com, Radia.Perlman@sun.com, svan@trustworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YK5MaCRdFnFFvPhjuWzJWQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk whoops..sorry about that...I'm working remotely with tiny bandwidth and accidentally clicked on "send" before I was ready to send. Let me finish my message... Valery Smyslov said: >> The Responder is allowed to narrow the choices by selecting a >> subset of the traffic, for instance by eliminating one or more >> members of the set of traffic selectors provided the set does >> not become the NULL set. However, the result of the narrowing >> MUST encompass the first TSi and first TSr from initiator's >> proposal. Otherwise SA MUST NOT be established. I don't think adding the last 2 sentences work. The part about how the narrowing MUST encompass... The reason is that unless we *require* the initiator to put a single source/destination/port into the first selector, your suggested wording wouldn't work. I don't think we can require it to do that, because it might be just setting up the SA based on being configured to do so when it comes up, rather than being triggered by a specific packet. If Alice (the initiator) has a wider range configured than Bob, then your wording would cause them not to be able to talk. We could require Alice, if the SA is being triggered by a specific packet, to specify the specifics in the first TSi and TSr (my original reply said that Alice MAY do that, but didn't require her to). However, if Alice is just bringing up the IKE-SA because she's configured to do so...not as the result of a specific packet...then all the TSi's and TSr's would be ranges, and Bob should just do the best he can. He should certainly be allowed to narrow the range if the first of each TS is a range rather than a specific address/port. Radia From owner-ipsec@lists.tislabs.com Mon May 13 22:47:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E5lkL11929; Mon, 13 May 2002 22:47:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA29778 Tue, 14 May 2002 01:06:54 -0400 (EDT) Message-ID: <002e01c1fb07$0e2122c0$bc64a8c0@saket> From: "Saket Dandawate" To: Subject: IKE v1 multiple ISAKMP SAs Date: Tue, 14 May 2002 10:50:24 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi Kousik & Rob According to you both 2 ISAKMP SAs are possible and cookies would specify which ISAKMP SA was used. But i want to know 1. whether it is absolutely necessary that i have to give support for multiple ISAKMP SAs. Consider scenarios where there are memory constrains. Could you suggest me some scheme where i can avoid multiple ISAKMP SAs. 2. Also i want to know what do you do when ISAKMP SA expires. Do you remove them or refresh the existing ISAKMP SA with new information. Also can you justify multiple ISAKMP SAs existence. Thanks and regards Saket Yes, it is, and it can happen because "A" and "B" decide to simultaneously initiate phase 1. It can also happen because "A" notices that there is not very much time left on the SA and establishes a second SA (or a third, or fourth...). As a result, the phase 2 SAs MUST be able to identify the phase 1 SA used to create them (for delete and error notification purposes). Additionally, you will have to decide (we allow the user to set either option) if you will allow phase 2 SA's to 'dangle' past the lifetime of the phase 1 SA. While it is very complicated, you might want to look at the Kame, FreeSWAN, or NetBSD code to see what they have done. Hope this helps, rwt > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Saket Dandawate > Sent: Thursday, May 09, 2002 9:52 PM > To: ipsec@lists.tislabs.com > Subject: IKE v1 are multiple ISAKMP SA allowed > > > Hi, > > I am implementing IKE v1 and i have few queries regarding ISAKMP SA > formation. Is it possible to have 2 ISAKMP SAs between the > same two peers. > > Consider the following case. > > 1. "A" peer places request for ISAKMP SA negotiation. > 2. Peer "B" also places request for ISAKMP SA negotiation at > the same time. > > So, at the same instance two Main Mode negotiations start. > RFC 2409 says > that after Main mode negotiation the IPsec SAs can be > exchanged by either > sides. So it sound logical to have only 1 main mode > negotiation. So what do > we do if two Main Mode's start simultaneously? If we have to > discard one > Main Mode which one should we discard? > > rfc 2409 doesnt say anything about multiple ISAKMP SA. > > thanks and regards > Saket > PSS pune > > From owner-ipsec@lists.tislabs.com Tue May 14 06:08:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ED8ML02980; Tue, 14 May 2002 06:08:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00681 Tue, 14 May 2002 08:23:41 -0400 (EDT) X-mProtect: <200205132325> Nokia Silicon Valley Messaging Protection Message-ID: <3CE04B50.63529636@iprg.nokia.com> Date: Mon, 13 May 2002 16:25:04 -0700 From: Mukesh Gupta Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ospf@discuss.microsoft.com, ipsec@lists.tislabs.com Subject: Using AH for Authentication for OSPFv3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, I am working on providing authentication for OSPFv3 using IPv6 AH extension header. RFC 2740 suggests using AH/ESP extension headers of IPv6 for OSPF authentication but doesn't provide details about how exactly this needs to be done. It seems that OSPFv3 shouldn't need to worry about it and it is kernel's responsibility to provide AH authentication for all OSPFv3 packets. This way OSPFv3 only receives authenticated packets. OSPFv3 uses both multicast and unicast packets. Is there any standard way of handling these packets using IPsec AH ?? Is there any standard way of implementing OSPFv3 Authentication using AH extension header ?? Is there any vendor out there who has implemented it ?? Comments/Suggestions would be highly appreciated. regards Mukesh -- ****************************************************************** Often the best way to win is to forget to keep score. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ipsec@lists.tislabs.com Tue May 14 06:13:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EDD0L03230; Tue, 14 May 2002 06:13:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00680 Tue, 14 May 2002 08:23:40 -0400 (EDT) X-Originating-IP: [211.167.226.82] From: "Jiang He" To: ipsec@lists.tislabs.com Subject: Use message ID with local significance Date: Tue, 14 May 2002 09:14:24 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 May 2002 01:14:25.0268 (UTC) FILETIME=[AFD71340:01C1FAE4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is important for identifier such as M-ID with local significance rather than global ones , especially for exchanges occur simultaneously among multiple connections. To use message ID with local significance in phase two of IKE(similar to tunnel establishment in L2TP): 1) If Alice chooses X1 as the Initiator M-ID when initiating an exchange to Bob, Alice should set M-ID in HDR to zero and attach a payload to indicate X1 as initiator's M-ID for subsequent messages from Bob to Alice. 2) Then Bob sets M-ID in HDR to X1 as response to Alice, and also attaches a payload to indicate Y1 as responder's M-ID for subsequent messages from Alice to Bob. 3) Now for messages followed within this exchange, if A->B, set M-ID to Y1; if B->A, set M-ID to X1. He Jiang _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ipsec@lists.tislabs.com Tue May 14 06:33:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EDXWL03832; Tue, 14 May 2002 06:33:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00806 Tue, 14 May 2002 08:48:46 -0400 (EDT) Message-ID: <001301c1fb47$70144170$1cf22b42@mv.lucent.com> From: "David Faucher" To: "Radia Perlman - Boston Center for Networking" , , References: <200205140304.g4E34XT17324@sydney.East.Sun.COM> Subject: Re: Ikev2 Traffic Selector payload Date: Tue, 14 May 2002 08:01:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So the suggestion now is that if the first TSi and TSr contain a single source/destination/port then the responder's selection MUST encompass these TSs. Otherwise, the responder MAY narrow the choices. ----- Original Message ----- From: "Radia Perlman - Boston Center for Networking" To: ; ; Sent: Monday, May 13, 2002 10:04 PM Subject: Re: Ikev2 Traffic Selector payload | whoops..sorry about that...I'm working remotely with tiny bandwidth and | accidentally clicked on "send" before I was ready to send. Let | me finish my message... | | Valery Smyslov said: | | >> The Responder is allowed to narrow the choices by selecting a | >> subset of the traffic, for instance by eliminating one or more | >> members of the set of traffic selectors provided the set does | >> not become the NULL set. However, the result of the narrowing | >> MUST encompass the first TSi and first TSr from initiator's | >> proposal. Otherwise SA MUST NOT be established. | | I don't think adding the last 2 sentences work. The part about how the | narrowing MUST encompass... | | The reason is that unless we *require* the initiator to put a single | source/destination/port into the first selector, your suggested | wording wouldn't work. I don't think we can require it to do that, because | it might be just setting up the SA based on being configured to do so | when it comes up, rather than being triggered by a specific packet. | If Alice (the initiator) has a wider range configured than Bob, then | your wording would cause them not to be able to talk. | | We could require Alice, if the SA is being triggered by a specific packet, | to specify the specifics in the first TSi and TSr (my original reply | said that Alice MAY do that, but didn't require her to). | | However, if Alice is just bringing up the IKE-SA because she's configured | to do so...not as the result of a specific packet...then all the TSi's and | TSr's would be ranges, and Bob should just do the best he can. He should | certainly be allowed to narrow the range if the first of each TS is a range | rather than a specific address/port. | | Radia | From owner-ipsec@lists.tislabs.com Tue May 14 06:39:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EDdJL03994; Tue, 14 May 2002 06:39:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00840 Tue, 14 May 2002 08:58:55 -0400 (EDT) Message-Id: <200205141311.RAA01907@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com, Radia.Perlman@sun.com Date: Tue, 14 May 2002 17:12:20 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Ikev2 Traffic Selector payload In-reply-to: <200205140304.g4E34XT17324@sydney.East.Sun.COM> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 13 May 02, at 23:04, Radia Perlman - Boston Center wrote: > Valery Smyslov said: > > >> The Responder is allowed to narrow the choices by selecting a > >> subset of the traffic, for instance by eliminating one or more > >> members of the set of traffic selectors provided the set does > >> not become the NULL set. However, the result of the narrowing > >> MUST encompass the first TSi and first TSr from initiator's > >> proposal. Otherwise SA MUST NOT be established. > > I don't think adding the last 2 sentences work. The part about how the > narrowing MUST encompass... > > The reason is that unless we *require* the initiator to put a single > source/destination/port into the first selector, your suggested Actually, I suggested that we do require initiator to always put a traffic selector, that selector of SA being negotiated must encompass. If SA negotiation is triggered by outgoing packet, this selector will be taken from the packet and will contain a single source/destination/address/port. Otherwise, if SA is setting up on being configured to do so, this selector can be taken from SPD. > wording wouldn't work. I don't think we can require it to do that, because > it might be just setting up the SA based on being configured to do so > when it comes up, rather than being triggered by a specific packet. > If Alice (the initiator) has a wider range configured than Bob, then > your wording would cause them not to be able to talk. I don't see much harm here. Anyway, even if SA is created in this case, but narrowed by responder, it might appear not to be usable for initiator when real packet appears. In any case, when real packet appears, new SA will be created. > We could require Alice, if the SA is being triggered by a specific packet, > to specify the specifics in the first TSi and TSr (my original reply > said that Alice MAY do that, but didn't require her to). > > However, if Alice is just bringing up the IKE-SA because she's configured > to do so...not as the result of a specific packet...then all the TSi's and > TSr's would be ranges, and Bob should just do the best he can. He should > certainly be allowed to narrow the range if the first of each TS is a range > rather than a specific address/port. Actually, not always. SPD entry may contain single address/port or list of single values. But this small problem is easy to solve: just require initiator in this case to put dummy range (represent single address as a range of length 1) into the first selector. To summarize: My suggestion. 1. First TSi and TSr of initiator's TS payloads always contain traffic description (address(es)/port(s)) that SA being created must satisfy. This information is taken by initiator: a) from the packet that triggered that SA negotiation (in this case those TSi and TSr contain only single address/port) b) from SPD in case that SA is setting up because initiator is configured to do so (in this case those TSi and TSr may contain anything, including range/subnet). 2. Responder always consider the first TSi and TSr as those, that must be encompassed in resulting SA selector. If this can't be satisfied, SA is not created. Your suggestion (as I understand it). 1. If SA negotiation is triggered by the packet, initiator may (or must) put specifics of this packet into first TSi and TSr. In this case the first TSi and TSr must contain single values (address/port). 2. If SA negotiation is performed because initiator is configured to do so, put information from SPD into the first TSi and TSr. If this SPD entry contain single address/port or a list of single addresses/ports, put dummy range into the first TSi and TSr (represent single address as a range of length 1). 3. If responder sees single address and port in the first TSi and TSr, he/she must keep this values encompassed in SA selector while its (possible) narrowing, or SA must not be created. 4. If responder sees anything but single address/port in the first TSi and TSr, he/she may narow SA selector as he/she wish. Actually, I can live with your suggestion too. > Radia Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Tue May 14 11:26:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EIQQL15334; Tue, 14 May 2002 11:26:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01485 Tue, 14 May 2002 13:38:54 -0400 (EDT) Message-Id: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 May 2002 10:49:30 -0700 To: Mukesh Gupta , ospf@discuss.microsoft.com, ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: Using AH for Authentication for OSPFv3 In-Reply-To: <3CE04B50.63529636@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk HI, >I am working on providing authentication for OSPFv3 using IPv6 AH >extension header. > >RFC 2740 suggests using AH/ESP extension headers of IPv6 for OSPF >authentication but doesn't provide details about how exactly this needs >to be done. > >It seems that OSPFv3 shouldn't need to worry about it and it is kernel's >responsibility to provide AH authentication for all OSPFv3 packets. This >way OSPFv3 only receives authenticated packets. IPSec provides security at IP level so the OSPF may not need any special mechanism to provide security services to OSPF data. All you might need is to configure a policy. >OSPFv3 uses both multicast and unicast packets. Is there any standard >way of handling these packets using IPsec AH ?? > >Is there any standard way of implementing OSPFv3 Authentication using AH >extension header ?? Is there any vendor out there who has implemented it >?? The RFC2740 clearly says that OSPF is not doing any Authentication part. For your reference i am copying the RFC... Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. >Comments/Suggestions would be highly appreciated. -cheers -ramana From owner-ipsec@lists.tislabs.com Tue May 14 12:17:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EJH0L16971; Tue, 14 May 2002 12:17:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01697 Tue, 14 May 2002 14:38:16 -0400 (EDT) Message-Id: <4.3.2.7.1.20020514114856.00cbcc90@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 May 2002 11:49:10 -0700 To: Mukesh Gupta , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: Using AH for Authentication for OSPFv3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk HI, >I am working on providing authentication for OSPFv3 using IPv6 AH >extension header. > >RFC 2740 suggests using AH/ESP extension headers of IPv6 for OSPF >authentication but doesn't provide details about how exactly this needs >to be done. > >It seems that OSPFv3 shouldn't need to worry about it and it is kernel's >responsibility to provide AH authentication for all OSPFv3 packets. This >way OSPFv3 only receives authenticated packets. IPSec provides security at IP level so the OSPF may not need any special mechanism to provide security services to OSPF data. All you might need is to configure a policy. >OSPFv3 uses both multicast and unicast packets. Is there any standard >way of handling these packets using IPsec AH ?? > >Is there any standard way of implementing OSPFv3 Authentication using AH >extension header ?? Is there any vendor out there who has implemented it >?? The RFC2740 clearly says that OSPF is not doing any Authentication part. For your reference i am copying the RFC... Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. >Comments/Suggestions would be highly appreciated. -cheers -ramana From owner-ipsec@lists.tislabs.com Tue May 14 14:23:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ELNrL20660; Tue, 14 May 2002 14:23:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01869 Tue, 14 May 2002 16:36:08 -0400 (EDT) X-mProtect: <200205142044> Nokia Silicon Valley Messaging Protection Message-ID: <3CE1773D.46A19A6B@iprg.nokia.com> Date: Tue, 14 May 2002 13:44:45 -0700 From: Mukesh Gupta Organization: Nokia IPRG X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ramana Yarlagadda CC: ospf@discuss.microsoft.com, ipsec@lists.tislabs.com Subject: Re: Using AH for Authentication for OSPFv3 References: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > IPSec provides security at IP level so the OSPF may not need any special > mechanism to provide security services to OSPF data. All you might need > is to configure a policy. That's right. > >OSPFv3 uses both multicast and unicast packets. Is there any standard > >way of handling these packets using IPsec AH ?? > > > >Is there any standard way of implementing OSPFv3 Authentication using AH > >extension header ?? Is there any vendor out there who has implemented it > >?? > > The RFC2740 clearly says that OSPF is not doing any Authentication part. > For your reference i am copying the RFC... > > Authentication has been removed from the OSPF protocol itself, instead > relying on IPv6's Authentication Header and Encapsulating Security > Payload. I am clear about the part that OSPF is not doing any authentication and IPsec is going to provide the security required. Since OSPF is going to send both unicast and multicast traffic and it is going to be a point to multipoint security, the implementation is little more involved. I was wondering if there is any standard way of taking care of the issues. Is there any vendor out there who has implemented this or planning to implement this in near future ?? regards Mukesh -- ****************************************************************** Often the test of courage is to not to die,but to live. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ipsec@lists.tislabs.com Tue May 14 18:07:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F17NL26007; Tue, 14 May 2002 18:07:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02347 Tue, 14 May 2002 20:21:34 -0400 (EDT) Date: Tue, 14 May 2002 20:34:00 -0400 (EDT) From: Henry Spencer To: Markku Savela cc: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: <200205102133.AAA02218@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 11 May 2002, Markku Savela wrote: > If IKE negotiated only keys, these ordering issues would never have > surfaced. On the contrary: they would have surfaced, in whatever other protocol was devised to handle the policy checking. Simply removing these issues from IKE does not make them go away. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue May 14 19:49:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F2nZL29193; Tue, 14 May 2002 19:49:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02592 Tue, 14 May 2002 22:04:56 -0400 (EDT) Date: Wed, 15 May 2002 05:16:44 +0300 Message-Id: <200205150216.FAA16715@burp.tkv.asdf.org> From: Markku Savela To: henry@spsystems.net CC: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com In-reply-to: (message from Henry Spencer on Tue, 14 May 2002 20:34:00 -0400 (EDT)) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On Sat, 11 May 2002, Markku Savela wrote: > > If IKE negotiated only keys, these ordering issues would never have > > surfaced. > > On the contrary: they would have surfaced, in whatever other protocol > was devised to handle the policy checking. > > Simply removing these issues from IKE does not make them go away. There is no need for such other protocol. Assuming your implementation is conformant to RFC-2401, it already does the policy checking, whether IKE is present or not. The issue of how the policies are installed to the hosts, is totally different matter. From owner-ipsec@lists.tislabs.com Wed May 15 01:01:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F81XL25267; Wed, 15 May 2002 01:01:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03346 Wed, 15 May 2002 03:10:33 -0400 (EDT) Message-ID: <001501c1fbe1$02a0f1c0$4d17fea9@amanda2> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Henry Spencer" , "Markku Savela" Cc: , References: Subject: Re: Specification of tunnel/transport attribute in IKEv2 Date: Wed, 15 May 2002 10:20:32 +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 6.00.2600.0000 Disposition-Notification-To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In protocol architecture, the policy making should be totally isolated from the Key Agreement Protocols or Key Transport Protocols. Ahmed ----- Original Message ----- From: "Henry Spencer" To: "Markku Savela" Cc: ; Sent: Wednesday, May 15, 2002 3:34 AM Subject: Re: Specification of tunnel/transport attribute in IKEv2 > On Sat, 11 May 2002, Markku Savela wrote: > > If IKE negotiated only keys, these ordering issues would never have > > surfaced. > > On the contrary: they would have surfaced, in whatever other protocol > was devised to handle the policy checking. > > Simply removing these issues from IKE does not make them go away. > > Henry Spencer > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Wed May 15 06:51:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FDpEL22820; Wed, 15 May 2002 06:51:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04154 Wed, 15 May 2002 09:08:18 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15586.24743.99153.268748@ryijy.hel.fi.ssh.com> Date: Wed, 15 May 2002 16:20:39 +0300 From: Tero Kivinen To: michaell@servgate.com (michael lin) CC: Subject: Re: NAT Traversal - Recovering from the expiring NAT mappings References: <605C42246151B7498423278ED555306F04C05A@skat.sky.com> X-Mailer: VM 6.89 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 michaell@servgate.com (michael lin) writes: > In draft-ietf-ipsec-nat-ike-02.txt, it said > > 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 ends which are NOT behind NAT SHOULD use > the last valid authenticated packet from the other end to determine which IP > and port addresses the 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). > > I cannot fully understand. Suppose following: > > A --- NAT --- Internat --- B > > 1.1.1.1 port x -----> > 1.1.1.1 port x -----> > 1.1.1.1 port x -----> (LAST packet) > > reboot > > 1.1.1.2 port y -----> (NEXT packet) This packet is received by the host B, and authenticated, and then it is processed normally. Note, that for incoming case we do not care the source IP. After the authentication check it will become the LAST authenticated packet received. > If the NEXT packet (source IP 1.1.1.2 and port y) passes the authentication > check, B will know the A's IP and port have been changed, right? Yes. And after that whenever it is sending packets back it needs to use the source address of the last authenticated packet received from the other as a destination address where to send the packets. > But in the draft, it said "the LAST valid authenticated packet". > What does it mean? Why is it NEXT packet, but LAST packet? Because this is needed for sending the replies back, thus we use the last authenticated packet in. The on transit incoming packet does not matter, if we haven't yet seen and authenticated it, and once we have received and authenticated it, then it is the last packet. > And since the source IP and port could be changed, does it mean B don't need > to check source IP and port? If the packet passes authentication check, the > packet is coming from the right source. Yes, B does not check the source IP and port, only the destination IP and port matters and then we do normal authentication checks, but to send replies back to the proper A we need the destination address and port for the A, and those MUST be taken from the last authenticated packet received from the A. -- 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 May 15 07:17:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FEHaL24598; Wed, 15 May 2002 07:17:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04294 Wed, 15 May 2002 09:38:32 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15586.26540.982804.447696@ryijy.hel.fi.ssh.com> Date: Wed, 15 May 2002 16:50:36 +0300 From: Tero Kivinen To: danmcd@east.sun.com (Dan McDonald), ipsec@lists.tislabs.com Subject: Re: JFK nit References: <200205131349.g4DDnQR9029024@kebe.east.sun.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 29 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk danmcd@east.sun.com (Dan McDonald) writes: > Sorry if this has been repeated before... Yes, this was repeated when the IKEv1 was specified, and at that point we decided to remove all padding. The reason was that most of the material in the packets was still binary byte objects (certificates, nonces, key exchange payloads, identities etc) or 8 bit or 16 bit numbers. Also the parsing of the IKE payload compared to the diffie-hellman / public key signing / verification etc is so fast that it really doesn't matter. Disadvantage of padding is that it required quite a lot of more code and caused all kind of bugs where implementators did that incorrectly. This was done around 1997 search for the archives for more information. > > 4.1 Structure > > > > Each message is a string of tag-length-value elements concatenated > > together. Tags are one octet. Lengths are two octets, and specify > > the number of octets of the value. Values are always integral > > numbers of octets. All octets are in big-endian order. > > > Ewwww. This is not a good choice. Modern machines work better with aligned > data! Say you have two nonce tags in a row (Ni, followed by Nr). Say they > start nicely on byte 0x10... > > > 0x10 > 0x11 > 0x12 == 8 bytes > 0x13 Ni msb > ... > 0x1a Ni lsb > 0x1b > > I can load the whole nonce into a register, but I can't, because it starts at > the byte-only-boundary of 0x13. > > JFK authors, please address this problem. If you want to discuss matters of > bit-twiddling import, let me know! Note, that neither IKEv1 nor the IKEv2 draft address this problem. They both use unaligned structures all the time. -- 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 May 15 07:49:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FEnXL27129; Wed, 15 May 2002 07:49:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04404 Wed, 15 May 2002 10:10:46 -0400 (EDT) Date: Wed, 15 May 2002 10:23:28 -0400 (EDT) From: Henry Spencer To: Markku Savela cc: ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: <200205150216.FAA16715@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 15 May 2002, Markku Savela wrote: > > Simply removing these issues from IKE does not make them go away. > > There is no need for such other protocol. Assuming your implementation > is conformant to RFC-2401, it already does the policy checking, > whether IKE is present or not. It does not do consistency checking to ensure that the policies on the two ends match. Nor does it have any way of selecting between policy options, when the other end may not accept all choices. These are practical issues of great importance, however trivial they may seem in theory. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed May 15 07:50:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FEoGL27160; Wed, 15 May 2002 07:50:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04382 Wed, 15 May 2002 10:07:44 -0400 (EDT) Date: Wed, 15 May 2002 10:20:14 -0400 (EDT) From: Henry Spencer To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" cc: ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: <001501c1fbe1$02a0f1c0$4d17fea9@amanda2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 15 May 2002, Prof. Ahmed Bin Abbas Ahmed Ali Adas wrote: > In protocol architecture, the policy making should be totally isolated from > the Key Agreement Protocols or Key Transport Protocols. This is a reasonable principle, but it does not change what I said: separating the two issues still leaves two issues to be dealt with. The policy checking within IKE is important, and removing it from IKE does not remove the requirement that it be dealt with somehow. Esthetically distasteful though it may be, dealing with it within IKE has been quite successful and has met users' needs well. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed May 15 09:27:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FGRdL00765; Wed, 15 May 2002 09:27:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04642 Wed, 15 May 2002 11:43:30 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15586.34077.496033.744072@thomasm-u1.cisco.com> Date: Wed, 15 May 2002 08:56:13 -0700 (PDT) To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: Re: Ikev2 Traffic Selector payload In-Reply-To: <200205120037.g4C0bsT18803@sydney.East.Sun.COM> References: <200205120037.g4C0bsT18803@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: > But here's the change that incorporates Valery's suggestion, I think: > > If the responder has multiple ranges, and can't choose, then he > MUST choose the largest set that encompasses the first TSi and first TSr. Radia, Is there any real life motivation for this sort of complication? What you're proposing to fix here smells much more like it's just smoothing over configuration errors, with the distinct possibility that both wrong implementations and changes of configuration will come back to bite whomever was relying on this behavior. IMO, it's worth considering whether we should make the protocols less tolerant of screwups with crisp semantics, vs trying to be more forgiving along with murky semantics. It seems to me that DWIM semantics with security protocols is a pretty treacherous road. Mike From owner-ipsec@lists.tislabs.com Wed May 15 09:37:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FGbSL01429; Wed, 15 May 2002 09:37:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04672 Wed, 15 May 2002 11:55:35 -0400 (EDT) To: Tero Kivinen Cc: danmcd@east.sun.com (Dan McDonald), ipsec@lists.tislabs.com Subject: Re: JFK nit References: <200205131349.g4DDnQR9029024@kebe.east.sun.com> <15586.26540.982804.447696@ryijy.hel.fi.ssh.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 15 May 2002 09:09:06 -0700 In-Reply-To: Tero Kivinen's message of "Wed, 15 May 2002 16:50:36 +0300" Message-ID: Lines: 27 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen writes: > danmcd@east.sun.com (Dan McDonald) writes: > > Sorry if this has been repeated before... > > Yes, this was repeated when the IKEv1 was specified, and at that point > we decided to remove all padding. The reason was that most of the > material in the packets was still binary byte objects (certificates, > nonces, key exchange payloads, identities etc) or 8 bit or 16 bit > numbers. Also the parsing of the IKE payload compared to the > diffie-hellman / public key signing / verification etc is so fast that > it really doesn't matter. Disadvantage of padding is that it required > quite a lot of more code and caused all kind of bugs where > implementators did that incorrectly. I tend to agree with Tero here. I'd be extremely surprised if alignment made any significant performance difference in the IKE/JFK context. I don't have any specific data for IKE but I do for SSL. SSL uses a completely unaligned and rather complicated encoding scheme. I've done extensive profiling of SSL/TLS implementations and marshalling and unmarshalling doesn't consume any significant fraction of the CPU time required by the implementation. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed May 15 12:07:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FJ7ZL07629; Wed, 15 May 2002 12:07:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05028 Wed, 15 May 2002 14:20:44 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15586.43515.644098.353766@thomasm-u1.cisco.com> Date: Wed, 15 May 2002 11:33:31 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: question on "code preserving" section in Paul's draft 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 Paul's SOI draft seems to imply that an IKEv2 implementation must also implement IKEv1 as well. Is that the intention of the IKEv2 authors? If so, there's more to this issue, not the least of which is an even *heavier* burden placed on small memory footprint widgets. Mike From owner-ipsec@lists.tislabs.com Wed May 15 14:23:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FLNZL11940; Wed, 15 May 2002 14:23:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05243 Wed, 15 May 2002 16:43:44 -0400 (EDT) Reply-To: From: "Rob Frohwein" To: "ipsec" Subject: authentication Date: Wed, 15 May 2002 13:56:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello , I know 2 types of authentication from racoon's IKE daemon. - preshared auth keys - certificates. For the case of users with a dynamic ip address the initiator can only identify itself by a certificate. On the initiators side a spd must be specified. At the responder's side no spd is needed. The initiator's spd triggers IKE to create (with peer) sa keys. At some phase the initiator sends its certificate. The responder sends a challenge ... The responder creates dynamically a spd. Both IKE's set the sa's (in the kernel). Why is it not possible for the case of dynamic (unknown) ip address initiators to identify themselfes by means of pre-shared auth keys? The IKE daemons on both sides could have a list like: The initiator ofcourse still needs an spd, for the responder the spd is created dynamically. Initiator (client) my-id-string (e.g. email address) authentication key Responder (Server) remote-id-string (e.g. email) authentiaction key other-remote-id string other-auth key ... Some hashing scheme on the server side could speed up lookup. This would be more easy to use for simple case, certificates are too complex for some cases. ------------------- Furhermore in the spd tables (at least for kame) ip numbers must be used. Why not also the possibility for dns name usage? This is more generic and flexible. Ofcourse the spd is resident in the kernel, so the kernel needs to communicate with the IKE daemon to resolv the ip numbers. greetings Rob Frohwein. From owner-ipsec@lists.tislabs.com Wed May 15 14:23:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FLNZL11939; Wed, 15 May 2002 14:23:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05249 Wed, 15 May 2002 16:44:45 -0400 (EDT) Message-Id: <200205152056.g4FKuUk09579@trpz.com> To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: question on "code preserving" section in Paul's draft In-Reply-To: Your message of "Wed, 15 May 2002 11:33:31 PDT." <15586.43515.644098.353766@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <684.1021495619.1@tibernian.com> Date: Wed, 15 May 2002 13:46:59 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is not our intention to say "MUST implement" IKEv1. If you have already implemented IKEv1 then there will be things, like the payload parsing code, that can be reused when writing IKEv2. If you have not implemented IKEv1 then "code preservingness" is a non-issue. We're not forcing people to write IKEv1 so they can reuse code when implemen- ting IKEv2. Definitely not. I didn't get that impression from the draft but if you did then most likely more people did too. What's the particular text that gave you that impression so it can be re-whacked? Dan. On Wed, 15 May 2002 11:33:31 PDT you wrote > > Paul's SOI draft seems to imply that an IKEv2 > implementation must also implement IKEv1 as well. > > Is that the intention of the IKEv2 authors? If > so, there's more to this issue, not the least of > which is an even *heavier* burden placed on small > memory footprint widgets. > > Mike From owner-ipsec@lists.tislabs.com Wed May 15 16:18:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FNIXL13898; Wed, 15 May 2002 16:18:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05445 Wed, 15 May 2002 18:42:13 -0400 (EDT) From: mlafon@arkoon.net X-Lotus-FromDomain: ARKOON To: ipsec@lists.tislabs.com Message-ID: Date: Thu, 16 May 2002 00:59:26 +0200 Subject: NAT-Traversal - Security Considerations Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm wondering myself about problems (one with Transport Mode, the other with Tunnel Mode) that can affect NAT-Traversal. draft-ietf-ipsec-udp-encaps-02 deals with conflict problems but (i think) there are also problems that can occured with only one IPSec Client. o Transport Mode +-----+ | M | +-----+\ \ +----+ \ / +-----+ +| WS |-----+-----------------| S | +|+----+ / \ +-----+ |+----+ NAT +----+ Math (M) is behind NAT and establish an SA with Server (S) using a specific Trafic Descriptor (TS). After that, S will send all packets for NAT and selected by TS (everything in many implementations and configurations) to M. This can cause a denial of service as Workstations (WS) and NAT device will not be able to communicate with Server (S) anymore. There is also confidentiality considerations as Math will receive packets that are not for him. Am I right or is there a solution to avoid this problem as many implementations will use the SA for every packet from S to NAT ? o Tunnel Mode +-----+ +------| VIM | NAT | +-----+ +-----+ \ / +----+ | M |-----+------+------| GW | +-----+ / \ | +----+ | | +----+ | +------| IS | +--+--+ +----+ | S | +-----+ Math (M) is behind NAT and establish an SA with Gateway (GW) using a specific Trafic Descriptor (TS). Using Tunnel Mode, Math will normally use his private IP address but can also used a spoofed one: Server (S) or VeryImportantMachine (VIM). After that, all packet for S or VIM (according to TS) will be sent to M via UDP encapsulated tunnel. Even packets from Internal Server (IS) to VIM will be sent to Math. This can be used by a malicious user to steal packets for VIM or to deny communication with S. Am I right or am I missing something ? How GW can decide if Math's IP is valid and is not a spoofed one ? -- Mathieu Lafon - Arkoon Network Security From owner-ipsec@lists.tislabs.com Wed May 15 16:18:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FNIZL13910; Wed, 15 May 2002 16:18:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05430 Wed, 15 May 2002 18:37:11 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15586.58895.262379.898025@thomasm-u1.cisco.com> Date: Wed, 15 May 2002 15:49:51 -0700 (PDT) To: Dan Harkins Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: question on "code preserving" section in Paul's draft In-Reply-To: <200205152056.g4FKuUk09579@trpz.com> References: <15586.43515.644098.353766@thomasm-u1.cisco.com> <200205152056.g4FKuUk09579@trpz.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 Dan Harkins writes: > It is not our intention to say "MUST implement" IKEv1. If you have > already implemented IKEv1 then there will be things, like the payload > parsing code, that can be reused when writing IKEv2. If you have not > implemented IKEv1 then "code preservingness" is a non-issue. We're > not forcing people to write IKEv1 so they can reuse code when implemen- > ting IKEv2. Definitely not. > > I didn't get that impression from the draft but if you did then > most likely more people did too. What's the particular text that gave > you that impression so it can be re-whacked? Dan, This is hearsay on my part from Paul's SOI feature's draft in section 6.2. There's some speculation about bid down attacks, and in particular the last paragraph it seems to imply that it wouldn't be a big deal because IKEv1 is secure... and by extension available. That's what I was trying to get clarification on. Mike From owner-ipsec@lists.tislabs.com Wed May 15 16:59:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FNxfL14453; Wed, 15 May 2002 16:59:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05577 Wed, 15 May 2002 19:26:34 -0400 (EDT) Message-Id: <200205152338.g4FNcck11960@trpz.com> To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: question on "code preserving" section in Paul's draft In-Reply-To: Your message of "Wed, 15 May 2002 15:49:51 PDT." <15586.58895.262379.898025@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <858.1021505347.1@tibernian.com> Date: Wed, 15 May 2002 16:29:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, Got it. I was looking at 6.4. I must've missed that paragraph on the first go-round because I think it's incorrect. The 2nd to the last paragraph of section 2.5 of draft-ietf-ipsec-ikev2-02.txt mentions how an IKEv2 implementation can avoid being tricked into speaking IKEv1. Basically, the active attack against the version would fail when the two peers start sending authenticated IKEv2 messages with the "version" bit set in the IKEv2 header. Dan. On Wed, 15 May 2002 15:49:51 PDT you wrote > Dan Harkins writes: > > It is not our intention to say "MUST implement" IKEv1. If you have > > already implemented IKEv1 then there will be things, like the payload > > parsing code, that can be reused when writing IKEv2. If you have not > > implemented IKEv1 then "code preservingness" is a non-issue. We're > > not forcing people to write IKEv1 so they can reuse code when implemen- > > ting IKEv2. Definitely not. > > > > I didn't get that impression from the draft but if you did then > > most likely more people did too. What's the particular text that gave > > you that impression so it can be re-whacked? > > Dan, > > This is hearsay on my part from Paul's SOI > feature's draft in section 6.2. There's some > speculation about bid down attacks, and in > particular the last paragraph it seems to imply > that it wouldn't be a big deal because IKEv1 > is secure... and by extension available. > > That's what I was trying to get clarification on. > > Mike From owner-ipsec@lists.tislabs.com Wed May 15 17:14:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4G0EAL14675; Wed, 15 May 2002 17:14:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05594 Wed, 15 May 2002 19:38:34 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15586.62572.905659.469261@thomasm-u1.cisco.com> Date: Wed, 15 May 2002 16:51:08 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: SOI schizophrenia 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 I admit it. I'm having a real hard time deciding which design philosophy is actually more appropriate for SOI. I've vacillated quite a few times and it doesn't seem like it's about to abate any time soon. What Paul's document tells me (which pretty jibes with my own judgement) is that both protocols are vast improvements over IKE, and they seem to reach quite similar conclusions on the basic message exchanges. Both put effort into DoS, and simplify the on-wire combinatorial explosion of SA establishment. All in all, they both seem competent. While Paul points out some of the differences in design choices such as quick mode, pre-shared keys, etc, what it seems to me that makes this so difficult is that there are two different design philosophies at work here: 1) Lean, compact public key identity keying (JFK) 2) General purpose (IKEv2) To a degree I agree about Andrew's observation about the devil we know, but what I think often gets lost in this mostly-VPN-centric group is that IKE -- and I'm afraid IKEv2 as well -- is large, and difficult to put into cheap, embedded devices. This isn't usually an issue for the windoze-VPN-to-corporate-edge, but IKE's size is a pretty hard sell for little widgets with constrained memory footprints. I've heard all the arguments about how the hardware folks are being unreasonable (and heck, beating up on hardware folks is just clean fun anyway), but I'm not overstating the difficulty. So from that standpoint, JFK's hardline stand on limiting complexity and creature feep is heartening. I've done some experiements writing a JFK-like protocol (same in spirit, slightly different wire format) using raw public key identities and the results are very heartening; if the memory police balk at its size, they are just being obstructionist. This is implementable; no excuses. Thus for simple widgets which operate in star topologies to a few well known servers where the traffic needs transport mode IPsec, JFK is quite attractive. Maybe other uses too. On the other hand, VPN's do add a lot of complexity, and I think that JFK understates that complexity. While some of that complexity is certainly gratuitous, I think that there's an unspoken truth here: VPN's are fundamentally more complicated than point to point transport mode SA's, and they drag all kinds of crufty legacy junk into the mix like legacy authentication, autoconfiguration, and all the rest. Is it needed? At some level of course it's "needed"; I doubt many of us are here for the shear fun of making Frankenprotocols. So what to do? What to choose? I'm at a loss. We could flip a coin to decide the pre-shared and QM debate, but what I don't see is how to preseve the different design philosophies which appeal differently to different audiences. Specifically, I'm having a real hard time seeing how we can have a single lean unbloated protocol like JFK without specific bloat-resistant design constraints... which violates the VPN desire for generality at the expense of simplicity and footprint. Time for some more shock therapy, I guess. Mike From owner-ipsec@lists.tislabs.com Thu May 16 03:22:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GAMHL24345; Thu, 16 May 2002 03:22:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07001 Thu, 16 May 2002 05:32:11 -0400 (EDT) Message-ID: <3CE37FAC.B1AB4E11@F-Secure.com> Date: Thu, 16 May 2002 12:45:16 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mlafon@arkoon.net CC: ipsec@lists.tislabs.com Subject: Re: NAT-Traversal - Security Considerations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2002 09:45:19.0924 (UTC) FILETIME=[6443DF40:01C1FCBE] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk mlafon@arkoon.net wrote: > > I'm wondering myself about problems (one with Transport Mode, the other > with Tunnel Mode) that can affect NAT-Traversal. > > draft-ietf-ipsec-udp-encaps-02 deals with conflict problems but (i think) > there are also problems that can occured with only one IPSec Client. > > o Transport Mode > > +-----+ > | M | > +-----+\ > \ > +----+ \ / +-----+ > +| WS |-----+-----------------| S | > +|+----+ / \ +-----+ > |+----+ NAT > +----+ > > Math (M) is behind NAT and establish an SA with Server (S) using > a specific Trafic Descriptor (TS). > > After that, S will send all packets for NAT and selected by TS > (everything in many implementations and configurations) to M. > > This can cause a denial of service as Workstations (WS) and NAT > device will not be able to communicate with Server (S) anymore. > There is also confidentiality considerations as Math will receive > packets that are not for him. > > Am I right or is there a solution to avoid this problem as many > implementations will use the SA for every packet from S to NAT ? It would seem to me that the IPsec layer in S needs to apply NAT for packets that come via the SA, so they appear to come from address Y. The server in S then thinks it's talking with Y. The return packets to Y would then be NATed, and put to the SA, all other packets would go through without any change. This way the TS doesn't apply to packets to/from address 'NAT', but to address 'Y'. This would break if you want part of the packets via an SA, and part in plaintext, using TS, because server would see different IP addresses for the client, so don't do that. > > o Tunnel Mode > > +-----+ > +------| VIM | > NAT | +-----+ > +-----+ \ / +----+ > | M |-----+------+------| GW | > +-----+ / \ | +----+ > | | +----+ > | +------| IS | > +--+--+ +----+ > | S | > +-----+ > > Math (M) is behind NAT and establish an SA with Gateway (GW) using a > specific Trafic Descriptor (TS). Using Tunnel Mode, Math will normally > use his private IP address but can also used a spoofed one: Server (S) > or VeryImportantMachine (VIM). > > After that, all packet for S or VIM (according to TS) will be sent to > M via UDP encapsulated tunnel. Even packets from Internal Server (IS) > to VIM will be sent to Math. > > This can be used by a malicious user to steal packets for VIM or to > deny communication with S. > > Am I right or am I missing something ? > How GW can decide if Math's IP is valid and is not a spoofed one ? I had this in draft-huttunen-ipsec-esp-in-udp-00.txt: > > It is not possible for a hacker to obtain an arbitrary address in the > intranet being protected by the GW. If address assignment by the GW > is provided, only the address assigned to the hacker is allowed to pass > through the GW. In the other case, address is always assigned to > the hacker internally by the GW and the (arbitrary) IP address of the > hacker is always translated by a NAT functionality in the GW. Perhaps I should have copied it to this current draft? Is it clear? Ari > > -- > Mathieu Lafon - Arkoon Network Security -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin 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 Thu May 16 03:37:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GAbAL24601; Thu, 16 May 2002 03:37:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07058 Thu, 16 May 2002 05:58:03 -0400 (EDT) From: mlafon@arkoon.net X-Lotus-FromDomain: ARKOON To: Ari Huttunen cc: ipsec@lists.tislabs.com Message-ID: Date: Thu, 16 May 2002 12:15:32 +0200 Subject: Re: NAT-Traversal - Security Considerations Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ari.huttunen@f-secure.com wrote > It would seem to me that the IPsec layer in S needs to apply NAT for > packets that come via the SA, so they appear to come from address Y. > The server in S then thinks it's talking with Y. The return packets > to Y would then be NATed, and put to the SA, all other packets would > go through without any change. This way the TS doesn't apply to packets > to/from address 'NAT', but to address 'Y'. This would break if you want > part of the packets via an SA, and part in plaintext, using TS, because > server would see different IP addresses for the client, so don't do that. So what is the prefered usage and why does the current draft does not specify it ? If we're not applying NAT, how do we deal with the blackhole between S and WS/NAT when NAT-T SA is established ? >I had this in draft-huttunen-ipsec-esp-in-udp-00.txt: >> >> It is not possible for a hacker to obtain an arbitrary address in the >> intranet being protected by the GW. If address assignment by the GW >> is provided, only the address assigned to the hacker is allowed to pass >> through the GW. In the other case, address is always assigned to >> the hacker internally by the GW and the (arbitrary) IP address of the >> hacker is always translated by a NAT functionality in the GW. > > Perhaps I should have copied it to this current draft? Is it clear? I don't get the point. If you do not use address assignment, it is the user who chooses his address depending on the network he is on (hotel, airport, home, ...), so you can't control which IP he chooses. When we're not using NAT-Traversal, we can be strict and not allow him to use another IP than his external IP or a fixed address/network. But with NAT-T, we can't be that strict, can we ? Or is address assignment mandatory with NAT-Traversal ? -- Mathieu Lafon - Arkoon Network Security From owner-ipsec@lists.tislabs.com Thu May 16 06:27:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GDRRL05603; Thu, 16 May 2002 06:27:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07328 Thu, 16 May 2002 08:44:26 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: addresses and IKEv2 To: Francis Dupont Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_M13_04242002 Pre-release 2 April 24, 2002 Message-ID: Date: Tue, 14 May 2002 22:42:45 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build M13TT_05082002 Pre-release 2|May 08, 2002) at 05/15/2002 06:35:44 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72" Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72 Content-type: text/plain; charset=US-ASCII This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways). > Each party can get up to 5 addresses: > - the address used for the transport of phase 1 messages (T1) > - the address in the phase 1 identity (I1) > - the address in the party's certificate (C1) > - the address used for the transport of phase 2 messages (T2) > - the address in the phase 2 traffic selector (which replaces IKEv1 > phase 2 identity) (I2) > (I don't consider the optional IKEv2 phase 2 identity payload until > it has an interesting semantic when it is an address identity). > > A not-really-written-down rule specifies the phase 1 identity must be > the subject or an alternate subject of the party's certificate (when > certificates are used but in any case the identity and the authentication > means must be strongly bound). You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them. There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast. The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one. Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the SA should be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them). Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs. How is this possible? One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it. In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks. In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP. IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs. It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions. --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. --0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72 Content-type: text/html; charset=US-ASCII Content-Disposition: inline This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways). > Each party can get up to 5 addresses: > - the address used for the transport of phase 1 messages (T1) > - the address in the phase 1 identity (I1) > - the address in the party's certificate (C1) > - the address used for the transport of phase 2 messages (T2) > - the address in the phase 2 traffic selector (which replaces IKEv1 > phase 2 identity) (I2) > (I don't consider the optional IKEv2 phase 2 identity payload until > it has an interesting semantic when it is an address identity). > > A not-really-written-down rule specifies the phase 1 identity must be > the subject or an alternate subject of the party's certificate (when > certificates are used but in any case the identity and the authentication > means must be strongly bound). You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them. There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast. The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one. Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the SA sh! ! ould be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them). Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs. How is this possible? One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it. In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks. In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP. IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs. It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions. --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. --0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72-- From owner-ipsec@lists.tislabs.com Thu May 16 06:30:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GDUPL05980; Thu, 16 May 2002 06:30:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07365 Thu, 16 May 2002 08:51:29 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60253EF7B@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: Michael Thomas , ipsec@lists.tislabs.com Subject: RE: question on "code preserving" section in Paul's draft Date: Wed, 15 May 2002 15:55:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC4A.7E0E2922" 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_01C1FC4A.7E0E2922 Content-Type: text/plain; charset="iso-8859-1" Hi Mike, Paul can comment in more detail, however "code preserving" does not mean a full implementation of IKEv1. Radia Perlman can also expand on this topic. Hope this note finds you well. Cheers, Dennis Beard -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, May 15, 2002 2:34 PM To: ipsec@lists.tislabs.com Subject: question on "code preserving" section in Paul's draft Paul's SOI draft seems to imply that an IKEv2 implementation must also implement IKEv1 as well. Is that the intention of the IKEv2 authors? If so, there's more to this issue, not the least of which is an even *heavier* burden placed on small memory footprint widgets. Mike ------_=_NextPart_001_01C1FC4A.7E0E2922 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: question on "code preserving" section in Paul's = draft Hi Mike, Paul can comment in more detail, however "code = preserving" does not mean a full implementation of IKEv1. = Radia Perlman can also expand on this topic. Hope this note finds you well. Cheers, Dennis Beard -----Original Message----- From: Michael Thomas [<3d.htm>mailto:mat@cisco.com] Sent: Wednesday, May 15, 2002 2:34 PM To: ipsec@lists.tislabs.com Subject: question on "code preserving" = section in Paul's draft Paul's SOI draft seems to imply that an IKEv2 implementation must also implement IKEv1 as = well. Is that the intention of the IKEv2 authors? If so, there's more to this issue, not the least = of which is an even *heavier* burden placed on = small memory footprint widgets. = = Mike ------_=_NextPart_001_01C1FC4A.7E0E2922-- --=====================_758883276==_.ALT Content-Type: text/html; charset="us-ascii" From owner-ipsec@lists.tislabs.com Thu May 16 09:57:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GGv6L17436; Thu, 16 May 2002 09:57:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07891 Thu, 16 May 2002 12:16:50 -0400 (EDT) Message-Id: <200205161628.g4GGSqT89870@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mlafon@arkoon.net cc: ipsec@lists.tislabs.com Subject: Re: NAT-Traversal - Security Considerations In-reply-to: Your message of Thu, 16 May 2002 00:59:26 +0200. Date: Thu, 16 May 2002 18:28:52 +0200 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: Math (M) is behind NAT and establish an SA with Gateway (GW) using a specific Trafic Descriptor (TS). Using Tunnel Mode, Math will normally use his private IP address but can also used a spoofed one: Server (S) or VeryImportantMachine (VIM). => Math can spoof the address but not the identity so the attack is a Denial of Service. This can be used by a malicious user to steal packets for VIM or to deny communication with S. => first (steal packets) should not be critical because M may not spoof an identity so may not know keys. Second is a DoS and there is a third one: redirect the traffic to (i.e. flood) a victim. Am I right or am I missing something ? => you don't miss something: NAT traversal capability gives to bad guys on the path all NAT possibilities and they don't need to stay on the path (so I call this problem the "transient pseudo-NAT attack"). How GW can decide if Math's IP is valid and is not a spoofed one ? => it can't. The stupid defense (authentify the IP address) works but disables the NAT traversal. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu May 16 10:18:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GHInL19254; Thu, 16 May 2002 10:18:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07916 Thu, 16 May 2002 12:43:04 -0400 (EDT) Message-Id: <200205161539.g4GFd5T89660@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-reply-to: Your message of Tue, 14 May 2002 22:42:45 EDT. Date: Thu, 16 May 2002 17:39:05 +0200 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 posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways). => IMHO Mobile IP and NATs need the same thing: some "address agility". > Each party can get up to 5 addresses: > - the address used for the transport of phase 1 messages (T1) > - the address in the phase 1 identity (I1) > - the address in the party's certificate (C1) > - the address used for the transport of phase 2 messages (T2) > - the address in the phase 2 traffic selector (which replaces IKEv1 > phase 2 identity) (I2) > (I don't consider the optional IKEv2 phase 2 identity payload until > it has an interesting semantic when it is an address identity). > > A not-really-written-down rule specifies the phase 1 identity must be > the subject or an alternate subject of the party's certificate (when > certificates are used but in any case the identity and the authentication > means must be strongly bound). You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them. => the purpose of my mail was to open the discussion about this kind of changes/clarifications. There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast. => I disagree: - draft-ietf-ipsec-esp-v3-02.txt (and Stephen Kent's presentation at the last IETF) makes very clear that SPI should become the unique identifier of a SA at the exception of multicast destination (where the issue is not multiple sender but multiple recipients which can not enforce the unicity of the SPI). - RFC 2401 is very clear about the outer source address of ESP (and AH) in tunnel mode: it can be *any* address of the source, etc. (cf 5.1.2.1 3 NOTE, 5.2.1, etc) The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. => this is a point which must be fixed. If we agree it should, the IKE-SA SPI shall become the way to identify "sessions". One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one. => only the first and last possibilities have a meaning but we can not get both. Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. => they are two common cases where this can happen: mobility and NATs. This argues for the fourth approach. => this is why I'd like to get it (or with the first approach a real discussion). But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. => this is not the fourth approach because you've added a NAT traversal property. For mobility (without NAT traversal capability) the source can authentify its address, for instance you can imagine the protection in IKEv2 is AH+ESP like in place of ESP like only. The other end will begin misdirecting responses and the IKE SA will eventually time out. => but with very efficient protocols like IKEv2 CREATE-CHILD-SA exchange to spoof one message is enough. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. => I believe you mean a message where the source address is authenticated. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the SA should be broken and renegotiated. => this can become incredibly too expensive if this imply to redo a DH exchange each time a mobile moves or a NAT resets some state. Another argument is the authentication in ESP/AH should reject any packet which doesn't come from the right node, so to check addresses is both annoying (this removes flexibility) and unnecessary (crypto is more powerful than access list). I propose to add this question into SOI requirements. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them). => we have to split attacks into attacks from address agility and attacks from NAT traversal capability. BTW the second kind of attacks is not only against IKE/SOI and I am writing an I-D about this. Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs. => If you apply this to ESP/AH we come back to a previous point, if you apply this to IKE then "road warriors" may not use IKE. How is this possible? => the question is more "is this desirable?" One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it. => IAB recommended to use names in place of addresses, and don't forget cases like the "road warrior" one. It seems we are going on the path to separate the identity from the address but obviously we should not go too far or we'll open the door to new attacks. Bit I disagree we shouldn't care. And there are many things we can do, for instance use DNSsec or authentify IKE message headers. In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks. => I believe you aggree that today the issue is not really handled (for instance many "mobile VPN" setups have no provision against transient pseudo-NAT attacks) and, even more important, users have no idea of what to do... In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. => yes, RFC 2401 5.2.1 has a MUST for this case. This will break transport mode SAs if they pass through address translation gateways. => IMHO this is a good property. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP. => UDP is another problem which doesn't come from NAT, but for not 1-1 mapping. IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. => and this opens the door to the transient pseudo-NAT attack even when it is known there is no NAT on the path. I am not against the feature but against to get it by default (and perhaps always) without proper considerations about consequences. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs. It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions. => I believe we should both provide better support and better graduation between what is accepted and consequences on possible attacks. Perhaps the ipsec WG needs a mobility concern from IESG like the security concerns received by the mobile-ip WG some times ago? Thanks Francis.Dupont@enst-bretagne.fr PS: random ideas about support/attacks: - put the address in the identity and check it: no support, inflexible but very (too?) secure. (I believe this is supported by many IKE(v1) implementations today but only testing (or source reading) shows if the check is done) - put a FQDN in the identity and verify address->FQDN mapping via DNSsec: addresses can be changed if DNS is updated, rely on DNSsec deploiment. (perhaps supported by implementations which can get keys/certificates from DNS but is it from DNS or from DNSsec?) - spit "transport" addresses and identities, never check them but don't accept change: support NAT traversal but not NAT resets or mobility, vulnerable to transient pseudo-NAT attacks on multiple and two way messages (seems to be the IKEv2 default) - spit "transport" addresses and identities, protect IP headers and accept change between "phases": support of mobility but not of NAT traversal (i.e. this is the IPv6 solution), no vulnerability (should be considered for SOI? note to put the (new) source address inside messages is enough to protect it, this makes "movements" more explicit too) - spit "transport" addresses and identities, no header protection, accept change between "phases": support of mobility and NAT traversal and NAT reset, vulnerable to transient pseudo-NAT attacks (if this is considered for SOI IMHO this should not be the default) From owner-ipsec@lists.tislabs.com Thu May 16 14:04:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GL4gL25644; Thu, 16 May 2002 14:04:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08421 Thu, 16 May 2002 16:23:26 -0400 (EDT) Date: Thu, 16 May 2002 13:35:31 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Rob Frohwein cc: ipsec Subject: Re: authentication 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 Wed, 15 May 2002, Rob Frohwein wrote: > Hello , > > I know 2 types of authentication from racoon's IKE daemon. > - preshared auth keys > - certificates. > > For the case of users with a dynamic ip address the initiator > can only identify itself by a certificate. > > On the initiators side a spd must be specified. > At the responder's side no spd is needed. > The initiator's spd triggers IKE to create (with peer) sa keys. > At some phase the initiator sends its certificate. > The responder sends a challenge ... > The responder creates dynamically a spd. > Both IKE's set the sa's (in the kernel). > > Why is it not possible for the case of dynamic (unknown) ip address > initiators to identify themselfes by means of pre-shared auth keys? Because the ID payload is in MM5 which is encrypted. So you need to find the key without knowing the ID. The only way to do that is by the IP address. jan > The IKE daemons on both sides could have a list like: > The initiator ofcourse still needs an spd, for the responder > the spd is created dynamically. > > Initiator (client) > my-id-string (e.g. email address) authentication key > > Responder (Server) > remote-id-string (e.g. email) authentiaction key > other-remote-id string other-auth key > ... > > Some hashing scheme on the server side could speed up lookup. > > This would be more easy to use for simple case, certificates > are too complex for some cases. > > ------------------- > > Furhermore in the spd tables (at least for kame) ip numbers must be used. > Why not also the possibility for dns name usage? > This is more generic and flexible. > Ofcourse the spd is resident in the kernel, so the kernel needs to > communicate with the IKE daemon to resolv the ip numbers. > > > greetings > Rob Frohwein. > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 16 14:22:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GLMkL26187; Thu, 16 May 2002 14:22:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08485 Thu, 16 May 2002 16:46:32 -0400 (EDT) Date: Thu, 16 May 2002 13:58:38 -0700 (PDT) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI schizophrenia In-Reply-To: <15586.62572.905659.469261@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 15 May 2002, Michael Thomas wrote: > > I admit it. I'm having a real hard time deciding > which design philosophy is actually more > appropriate for SOI. I've vacillated quite a few > times and it doesn't seem like it's about to abate > any time soon. What Paul's document tells me > (which pretty jibes with my own judgement) is that > both protocols are vast improvements over IKE, and > they seem to reach quite similar conclusions on > the basic message exchanges. Both put effort into > DoS, and simplify the on-wire combinatorial > explosion of SA establishment. All in all, they > both seem competent. > They are both competent from a cryptography point of view, but only one actually allows key management in any sane way. I think that's where the two part company, and we as a group need to decide which is more appropriate: A key *agreement* protocol (JFK) which will require other protocols (ICMP? Right..) to help solve the current deployment stability, or a key *management* protocol (IKEv2), that let's you manage the key we agreed on, without requiring other external management protocols. The rest of the topics are in my mind really ancillary (You want it red? You can have it red. You want cipher suites? You can have those? You want pre-shared keys? We could add that if necessary. You would prefer it round instead of square? Done.). So one important question is: Is (simple + n*(extra management protocol)) < (complex + 0*(extra management protocol)) ? Of course another question might be: Do we need key management? Based on operational experience and fixing lots of customer deployment and network stability problems, I'd say that's an emphatic YES. 2 phases? Yes. Key management? Yes. Simplicity? Only where it doesn't conflict with being able to maintain an operational network. jan > While Paul points out some of the differences in > design choices such as quick mode, pre-shared > keys, etc, what it seems to me that makes this so > difficult is that there are two different design > philosophies at work here: > > 1) Lean, compact public key identity keying (JFK) > 2) General purpose (IKEv2) > > To a degree I agree about Andrew's observation > about the devil we know, but what I think often > gets lost in this mostly-VPN-centric group is that > IKE -- and I'm afraid IKEv2 as well -- is large, > and difficult to put into cheap, embedded > devices. This isn't usually an issue for the > windoze-VPN-to-corporate-edge, but IKE's size is a > pretty hard sell for little widgets with > constrained memory footprints. I've heard all the > arguments about how the hardware folks are being > unreasonable (and heck, beating up on hardware > folks is just clean fun anyway), but I'm not > overstating the difficulty. > > So from that standpoint, JFK's hardline stand on > limiting complexity and creature feep is > heartening. I've done some experiements writing a > JFK-like protocol (same in spirit, slightly > different wire format) using raw public key > identities and the results are very heartening; if > the memory police balk at its size, they are just > being obstructionist. This is implementable; no > excuses. Thus for simple widgets which operate in > star topologies to a few well known servers where > the traffic needs transport mode IPsec, JFK is > quite attractive. Maybe other uses too. > > On the other hand, VPN's do add a lot of > complexity, and I think that JFK understates > that complexity. While some of that complexity is > certainly gratuitous, I think that there's an > unspoken truth here: VPN's are fundamentally more > complicated than point to point transport mode > SA's, and they drag all kinds of crufty legacy > junk into the mix like legacy authentication, > autoconfiguration, and all the rest. Is it needed? > At some level of course it's "needed"; I doubt > many of us are here for the shear fun of making > Frankenprotocols. > > So what to do? What to choose? I'm at a loss. We > could flip a coin to decide the pre-shared and QM > debate, but what I don't see is how to preseve the > different design philosophies which appeal > differently to different audiences. Specifically, > I'm having a real hard time seeing how we can have > a single lean unbloated protocol like JFK without > specific bloat-resistant design constraints... > which violates the VPN desire for generality at > the expense of simplicity and footprint. > > Time for some more shock therapy, I guess. > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 16 14:45:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GLj3L27062; Thu, 16 May 2002 14:45:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08561 Thu, 16 May 2002 17:10:43 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.9007.583427.780174@thomasm-u1.cisco.com> Date: Thu, 16 May 2002 14:22:55 -0700 (PDT) To: Jan Vilhuber Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI schizophrenia In-Reply-To: References: <15586.62572.905659.469261@thomasm-u1.cisco.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 Jan Vilhuber writes: > On Wed, 15 May 2002, Michael Thomas wrote: > > > > > I admit it. I'm having a real hard time deciding > > which design philosophy is actually more > > appropriate for SOI. I've vacillated quite a few > > times and it doesn't seem like it's about to abate > > any time soon. What Paul's document tells me > > (which pretty jibes with my own judgement) is that > > both protocols are vast improvements over IKE, and > > they seem to reach quite similar conclusions on > > the basic message exchanges. Both put effort into > > DoS, and simplify the on-wire combinatorial > > explosion of SA establishment. All in all, they > > both seem competent. > > > > They are both competent from a cryptography point of view, but only > one actually allows key management in any sane way. I think that's > where the two part company, and we as a group need to decide which is > more appropriate: A key *agreement* protocol (JFK) which will require > other protocols (ICMP? Right..) to help solve the current deployment > stability, or a key *management* protocol (IKEv2), that let's you > manage the key we agreed on, without requiring other external > management protocols. I don't understand what you mean by "management" in this context. JFK can add and delete SA, and assigns lifetimes to them. It seems light on a DPD scheme, but that seems like a negotiable item. Two phases is just an optmization. What am I missing? Mike From owner-ipsec@lists.tislabs.com Thu May 16 15:52:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GMqAL28535; Thu, 16 May 2002 15:52:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08644 Thu, 16 May 2002 18:17:02 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.13017.673564.786273@thomasm-u1.cisco.com> Date: Thu, 16 May 2002 15:29:45 -0700 (PDT) To: Charlie_Kaufman@notesdev.ibm.com Cc: Francis Dupont , ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-Reply-To: References: 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 Charlie_Kaufman@notesdev.ibm.com writes: > You're right that the rules aren't really written down. We tried to copy > IKEv1 on the theory that people were using it and we didn't understand the > issues well enough to have confidence that changes would be improvements. > If there are specific changes or clarifications that you think would be > useful, please propose them. > > There is an implicit (or it might in fact be explicit though I couldn't > find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH > messages associated with an IKE SA will have the same source and > destination IP addresses. ESP and AH explicitly state that their SA is > identified by the combination of the Destination IP address and SPI, and > the only anticipated case for having the source address vary for an SPI is > for multi-sender multicast. > > The IKEv2 spec doesn't say what an implementation should do if it receives > a cryptographically valid message from an unexpected source address. I > suppose it should. One possibility is that it could specify that such > messages are discarded and possibly logged. A second is that they be > treated as though they were cryptographically invalid. A third is that the > source address be ignored and the packet treated as though it was received > from the expected source address. A fourth is that the source address be > remembered and future messages on the SA be sent to that one. > > Why would it matter? I claim that in all cases except Transport mode ESP > (which is an ESP issue rather than an IKE issue), no invalid messages can > be delivered as the result of any of these approaches. The reason it might > be desirable to accept messages from changing source addresses is to allow > the other end of an SA to change IP addresses mid-conversation without > breaking the connection. This argues for the fourth approach. But the > fourth approach makes possible a denial of service attack that is > unacceptable. An attacker need only intercept and prevent delivery of a > single IKE packet and retransmit it with a changed source IP address. The > other end will begin misdirecting responses and the IKE SA will eventually > time out. If we believe we need to be able to handle the case of a mobile > SA, I believe we would have to do it with an authenticated message. This > could be added later, but my going in position would be that if either end > of an SA changes IP addresses then the SA should be broken and > renegotiated. In that case, it doesn't matter which of the first three > approaches an implementation takes because it shouldn't happen (and no > useful attacks could exploit them). > > Where addresses are important is in the ESP and AH connections tunnelled or > transported through IPsec SAs. ESP and AH are designed to "transparently" > secure applications that use existing networking APIs and may trust data > differently based on the IP address from which it originates (e.g. the Unix > rtools). For any useful security to be provided, IKE is responsible for > assuring that the authenticated identity corresponds to the IP address of > SAs. Charlie, I don't really see what this enforcement specifically at the SPI/dst address lookup is buying. Lookups for incoming unicast ESP/AH don't actually need anything more than the SPI itself to fetch the correct context. For ESP in particular, I don't see what security property is being enforced by checking the outer tunnel address. If you don't have the keying material, the hash will fail and the packet will never be admitted. The inner address (eg home address) still needs to be kosher for the traffic filtering. What's the problem here? Like Francis I suspect, there's a lot to be gained for mobility if we separate routing tags from identity. In particular, it would be very, very advantageous to be able to create a tunnel where the outer routing tag is irrelevant so long as the inner payloads/integrity all check out. The reason is that for mobility you may be changing your link layer and L3 routing information quite often; renegotiation new SA's would be an *extreme* hardship! What happens with IKE is another discussion that I'll bow out of for the time being... Mike From owner-ipsec@lists.tislabs.com Thu May 16 16:09:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GN94L28927; Thu, 16 May 2002 16:09:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08684 Thu, 16 May 2002 18:35:04 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.14074.418189.801514@thomasm-u1.cisco.com> Date: Thu, 16 May 2002 15:47:22 -0700 (PDT) To: Charlie_Kaufman@notesdev.ibm.com Cc: Francis Dupont , ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-Reply-To: References: 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 Bleah. Ignore my previous brain fart. As far as IPsec (2401) is concerned the *source* of the outer tunnel IP header is irrelevant, which is primarily what mobile/multihomed things want. I still don't see what security property is being enforced by the receiver looking up crypto context based on SPI, outer dest address instead of just SPI alone (at least in the unicast case). It still has to pass SPD/selector muster once decrypted. Mike Charlie_Kaufman@notesdev.ibm.com writes: > > This posting points out the tip of a very large iceberg. I think I > understand some of the issues (but I'm not confident); some seem > unsolvable; and some raise questions about the design goals of IPsec. > Attempts to improve things for some scenarios (e.g. Mobile IP) may make > things worse in others (e.g. Address Translation Gateways). > > > Each party can get up to 5 addresses: > > - the address used for the transport of phase 1 messages (T1) > > - the address in the phase 1 identity (I1) > > - the address in the party's certificate (C1) > > - the address used for the transport of phase 2 messages (T2) > > - the address in the phase 2 traffic selector (which replaces IKEv1 > > phase 2 identity) (I2) > > (I don't consider the optional IKEv2 phase 2 identity payload until > > it has an interesting semantic when it is an address identity). > > > > A not-really-written-down rule specifies the phase 1 identity must be > > the subject or an alternate subject of the party's certificate (when > > certificates are used but in any case the identity and the authentication > > means must be strongly bound). > > You're right that the rules aren't really written down. We tried to copy > IKEv1 on the theory that people were using it and we didn't understand the > issues well enough to have confidence that changes would be improvements. > If there are specific changes or clarifications that you think would be > useful, please propose them. > > There is an implicit (or it might in fact be explicit though I couldn't > find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH > messages associated with an IKE SA will have the same source and > destination IP addresses. ESP and AH explicitly state that their SA is > identified by the combination of the Destination IP address and SPI, and > the only anticipated case for having the source address vary for an SPI is > for multi-sender multicast. > > The IKEv2 spec doesn't say what an implementation should do if it receives > a cryptographically valid message from an unexpected source address. I > suppose it should. One possibility is that it could specify that such > messages are discarded and possibly logged. A second is that they be > treated as though they were cryptographically invalid. A third is that the > source address be ignored and the packet treated as though it was received > from the expected source address. A fourth is that the source address be > remembered and future messages on the SA be sent to that one. > > Why would it matter? I claim that in all cases except Transport mode ESP > (which is an ESP issue rather than an IKE issue), no invalid messages can > be delivered as the result of any of these approaches. The reason it might > be desirable to accept messages from changing source addresses is to allow > the other end of an SA to change IP addresses mid-conversation without > breaking the connection. This argues for the fourth approach. But the > fourth approach makes possible a denial of service attack that is > unacceptable. An attacker need only intercept and prevent delivery of a > single IKE packet and retransmit it with a changed source IP address. The > other end will begin misdirecting responses and the IKE SA will eventually > time out. If we believe we need to be able to handle the case of a mobile > SA, I believe we would have to do it with an authenticated message. This > could be added later, but my going in position would be that if either end > of an SA changes IP addresses then the SA should be broken and > renegotiated. In that case, it doesn't matter which of the first three > approaches an implementation takes because it shouldn't happen (and no > useful attacks could exploit them). > > Where addresses are important is in the ESP and AH connections tunnelled or > transported through IPsec SAs. ESP and AH are designed to "transparently" > secure applications that use existing networking APIs and may trust data > differently based on the IP address from which it originates (e.g. the Unix > rtools). For any useful security to be provided, IKE is responsible for > assuring that the authenticated identity corresponds to the IP address of > SAs. > > How is this possible? > > One way is by having the identities in certificates in fact be IP addresses > rather than names as implied by the quoted text above. Systems may be > deployed that way, but it would surprise me. More likely is that the > "Policy Database" installed as part of IPsec configuration contains a table > matching IP addresses to either public keys or the names that must appear > in certificates used in IKE. How that policy database would be populated > and maintained is one of the great remaining mysteries of IPsec. For > firewall to firewall tunnels, manual configuration works, and I believe > that's how people do it today. But for end to end IPsec to become routine, > better techniques will need to be deployed and standardized. It's a much > harder problem than any already solved in IPsec, so I don't expect progress > soon. I certainly don't want to hold IKEv2 hostage to solving it. > > In tunnel mode, it's the inner IP addresses that must be authenticated. > They are because they must match the traffic selectors and the traffic > selectors must match the authenticated names from IKE and in the IPsec > Policy Database. In tunnel mode, the outer IP addresses are like those of > IKE... it doesn't matter what we do with them so long as we don't open > ourselves to denial of service attacks. > > In transport mode, it's the outer IP addresses that must be authenticated. > This is tricky because they are not cryptographically protected. What > should ESP or AH do if they receive a transport mode IP packet with IP > addresses that don't match the traffic selectors? I believe the spec says > they should throw them away. This will break transport mode SAs if they > pass through address translation gateways. I believe the right answer to > this is to always use tunnel mode through address translation gateways. > Proposals for tunneling through address translation gateways call for use > of a special tunnel mode that is encapsulated in UDP. > > IKEv2 explicitly supports Address Translation Gateways by *not* > authenticating the outer IP addresses in IKE messages. This allows > connections to work even though the outer IP addresses appear different to > the two ends of the IKE (and presumably also ESP) SAs. > > It's not clear what we can or should do to provide better support for ATGs > or Mobile IP, but I'm open to suggestions. > > --Charlie > > This footnote confirms that either (1) this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including computer > viruses, (2) this email message was sent by a virus that appends this > footnote, or (3) (most likely) the sender of this message is trying to > raise awareness of how foolish it would be to place any confidence in > footnotes like this.This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways). > > > Each party can get up to 5 addresses: > > - the address used for the transport of phase 1 messages (T1) > > - the address in the phase 1 identity (I1) > > - the address in the party's certificate (C1) > > - the address used for the transport of phase 2 messages (T2) > > - the address in the phase 2 traffic selector (which replaces IKEv1 > > phase 2 identity) (I2) > > (I don't consider the optional IKEv2 phase 2 identity payload until > > it has an interesting semantic when it is an address identity). > > > > A not-really-written-down rule specifies the phase 1 identity must be > > the subject or an alternate subject of the party's certificate (when > > certificates are used but in any case the identity and the authentication > > means must be strongly bound). > > You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them. > > There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast. > > The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one. > > Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the ! SA ! > sh! > ! ould be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them). > > Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs. > > How is this possible? > > One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it. > > In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks. > > In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP. > > IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs. > > It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions. > > --Charlie > > This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. From owner-ipsec@lists.tislabs.com Thu May 16 17:01:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H01QL00294; Thu, 16 May 2002 17:01:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08769 Thu, 16 May 2002 19:25:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message Subject: RE: ike-modp-groups-04 Date: Thu, 16 May 2002 16:33:57 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: ike-modp-groups-04 Thread-Index: AcHwqU3pvZzSAx6wQUyCIKO1Z+JJNwMiCHqg From: "William Dixon" To: , X-OriginalArrivalTime: 16 May 2002 23:33:58.0606 (UTC) FILETIME=[26E8AEE0:01C1FD32] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, Ted, Barbara, isn't this ready for last call ? Is there anything we can do to get assigned numbers sooner rather than later ? -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Tuesday, April 30, 2002 5:10 PM To: ipsec@lists.tislabs.com Subject: ike-modp-groups-04 -----BEGIN PGP SIGNED MESSAGE----- Is there some reason this document has not been published yet? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPM8yXYqHRg3pndX9AQF4WwQAxrUMMyFVPHA/zJeoHJ2o7r626+LQ+UYx SWosLDzzA6GbwXNpeWa93Pefyh/nLt/MgpseVnBdA5CX3dwoFT4Y6B3jctikMoFt ZYEkrnx//eYqvJzhw0Df3yISWHYdQr1u1lAS5Z0sK+EXgyx0t+ESL9eTK/azVBfY zngnFDIiYIA= =qm44 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu May 16 23:56:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H6u5L19653; Thu, 16 May 2002 23:56:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09611 Fri, 17 May 2002 02:11:45 -0400 (EDT) Message-ID: <3CE4A269.76287B2D@F-Secure.com> Date: Fri, 17 May 2002 09:25:45 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mlafon@arkoon.net CC: ipsec@lists.tislabs.com Subject: Re: NAT-Traversal - Security Considerations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2002 06:25:45.0837 (UTC) FILETIME=[AD90F1D0:01C1FD6B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk mlafon@arkoon.net wrote: > > ari.huttunen@f-secure.com wrote > > > It would seem to me that the IPsec layer in S needs to apply NAT for > > packets that come via the SA, so they appear to come from address Y. > > The server in S then thinks it's talking with Y. The return packets > > to Y would then be NATed, and put to the SA, all other packets would > > go through without any change. This way the TS doesn't apply to packets > > to/from address 'NAT', but to address 'Y'. This would break if you want > > part of the packets via an SA, and part in plaintext, using TS, because > > server would see different IP addresses for the client, so don't do that. > > So what is the prefered usage and why does the current draft does not specify > it ? If we're not applying NAT, how do we deal with the blackhole between > S and WS/NAT when NAT-T SA is established ? The draft is a specification for a protocol, not an implementation guidebook in how the protocol is to be implemented. Some not-so-obvious security related issues are mentioned explicitly to guide implementations, but other than that you're left on your own to implement it. > > >I had this in draft-huttunen-ipsec-esp-in-udp-00.txt: > >> > >> It is not possible for a hacker to obtain an arbitrary address in the > >> intranet being protected by the GW. If address assignment by the GW > >> is provided, only the address assigned to the hacker is allowed to pass > >> through the GW. In the other case, address is always assigned to > >> the hacker internally by the GW and the (arbitrary) IP address of the > >> hacker is always translated by a NAT functionality in the GW. > > > > Perhaps I should have copied it to this current draft? Is it clear? > > I don't get the point. If you do not use address assignment, it is the user > who chooses his address depending on the network he is on (hotel, airport, home, > ...), so you can't control which IP he chooses. OK. Good that I didn't copy it. :) > > When we're not using NAT-Traversal, we can be strict and not allow him to use > another IP than his external IP or a fixed address/network. But with NAT-T, > we can't be that strict, can we ? > > Or is address assignment mandatory with NAT-Traversal ? Both transport and tunnel mode can be implemented with a NAT in the IPsec layer, and tunnel mode can additionally be implemented with address assignment (DHCP/modeconfig). You may be able to do without them in some situations. You can look at it like NAT-Traversal ignoring the effects of any NATs en-route. Still, if addresses need NATing, something must do it, and that something is likely your IPsec stack. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin 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 Fri May 17 03:19:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HAJRL14332; Fri, 17 May 2002 03:19:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10019 Fri, 17 May 2002 05:32:21 -0400 (EDT) Message-Id: <200205170944.g4H9iRT93074@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-reply-to: Your message of Thu, 16 May 2002 15:29:45 PDT. <15588.13017.673564.786273@thomasm-u1.cisco.com> Date: Fri, 17 May 2002 11:44:27 +0200 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: => thanks for your support Mike! What happens with IKE is another discussion that I'll bow out of for the time being... => there is something to do with IKE because SAs come by pairs, i.e. for the mobile to correspondent way address agility is enough (and is already in RFC 2401) but for the correspondent to mobile way something is needed (readdressing exchange?). Thanks Francis.Dupont@enst-bretagne.fr PS: more I think about SOI & mobility, more I believe SOI should have an optional message header verification, something like a special ID payload with the party transport parameters. My current idea is, for IKEv2 for instance: - optional ID payload of type address with the party transport parameters (address, protocol (udp), port (500)) - this payload should be the first one (a way to mark it as special) - if it is present it must be checked against the message header - the policy should say if this is required to be sent or received - the policy should say if this can overwrite previous used addresses: * further IKE messages * all established SAs with this peer IMHO only the last point is arguable (i.e. I am still looking for better solutions). From owner-ipsec@lists.tislabs.com Fri May 17 03:24:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HAOAL14570; Fri, 17 May 2002 03:24:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10031 Fri, 17 May 2002 05:37:21 -0400 (EDT) Message-Id: <200205170949.g4H9n3T93117@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-reply-to: Your message of Thu, 16 May 2002 15:47:22 PDT. <15588.14074.418189.801514@thomasm-u1.cisco.com> Date: Fri, 17 May 2002 11:49:03 +0200 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: Bleah. Ignore my previous brain fart. As far as IPsec (2401) is concerned the *source* of the outer tunnel IP header is irrelevant, which is primarily what mobile/multihomed things want. => unfortunately many implementations still check the outer source because this is not explicitely forbidden. Revision of 2401 and interop tests should clarify this point (IKEv2/ESPv3 were a big step forward because they make clear that inbound SA selectors are traffic selectors). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri May 17 03:24:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HAOAL14569; Fri, 17 May 2002 03:24:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10044 Fri, 17 May 2002 05:41:22 -0400 (EDT) Message-Id: <200205170953.g4H9rWT93137@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Lars Eggert cc: Michael Thomas , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-reply-to: Your message of Thu, 16 May 2002 15:55:29 PDT. <3CE438E1.9060302@isi.edu> Date: Fri, 17 May 2002 11:53:32 +0200 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: > Like Francis I suspect, there's a lot to be gained > for mobility if we separate routing tags from > identity. In particular, it would be very, very > advantageous to be able to create a tunnel where > the outer routing tag is irrelevant so long as the > inner payloads/integrity all check out. Isn't this accomplished by end-to-end transport mode IPsec that goes through an unsecured IPIP tunnel? => unfortunately this is the opposite because transport mode in IPIP knows *only* the outer header. Thanks Francis.Dupont@enst-bretagne.fr PS: my favourite question to IPsec people was "is your IPv6 tunnel mode an interface?" I *never* got a really sensible answer (:-)... From owner-ipsec@lists.tislabs.com Fri May 17 04:05:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HB5HL20361; Fri, 17 May 2002 04:05:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10135 Fri, 17 May 2002 06:22:27 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.56534.560359.570000@ryijy.hel.fi.ssh.com> Date: Fri, 17 May 2002 13:35:02 +0300 From: Tero Kivinen To: "William Dixon" Cc: Subject: RE: ike-modp-groups-04 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William Dixon writes: > Tero, Ted, Barbara, isn't this ready for last call ? Is there anything > we can do to get assigned numbers sooner rather than later ? I don't have any outstanding issues about it, I think it is ready for the last call. -- 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 May 17 06:12:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HDCrL26674; Fri, 17 May 2002 06:12:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10320 Fri, 17 May 2002 08:24:54 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Thu May 16 15:22:19 2002 From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: addresses and IKEv2 To: Francis Dupont Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_M13_04242002 Pre-release 2 April 24, 2002 Message-ID: Date: Tue, 14 May 2002 22:42:45 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build M13TT_05082002 Pre-release 2|May 08, 2002) at 05/15/2002 06:35:44 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72" Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72 Content-type: text/plain; charset=US-ASCII This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways). > Each party can get up to 5 addresses: > - the address used for the transport of phase 1 messages (T1) > - the address in the phase 1 identity (I1) > - the address in the party's certificate (C1) > - the address used for the transport of phase 2 messages (T2) > - the address in the phase 2 traffic selector (which replaces IKEv1 > phase 2 identity) (I2) > (I don't consider the optional IKEv2 phase 2 identity payload until > it has an interesting semantic when it is an address identity). > > A not-really-written-down rule specifies the phase 1 identity must be > the subject or an alternate subject of the party's certificate (when > certificates are used but in any case the identity and the authentication > means must be strongly bound). You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them. There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast. The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one. Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the SA should be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them). Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs. How is this possible? One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it. In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks. In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP. IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs. It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions. --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. --0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72 Content-type: text/html; charset=US-ASCII Content-Disposition: inline This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways). > Each party can get up to 5 addresses: > - the address used for the transport of phase 1 messages (T1) > - the address in the phase 1 identity (I1) > - the address in the party's certificate (C1) > - the address used for the transport of phase 2 messages (T2) > - the address in the phase 2 traffic selector (which replaces IKEv1 > phase 2 identity) (I2) > (I don't consider the optional IKEv2 phase 2 identity payload until > it has an interesting semantic when it is an address identity). > > A not-really-written-down rule specifies the phase 1 identity must be > the subject or an alternate subject of the party's certificate (when > certificates are used but in any case the identity and the authentication > means must be strongly bound). You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them. There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast. The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one. Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the SA ! sh! ! ould be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them). Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs. How is this possible? One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it. In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks. In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP. IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs. It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions. --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. --0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72-- From owner-ipsec@lists.tislabs.com Fri May 17 06:16:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HDG3L27208; Fri, 17 May 2002 06:16:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10314 Fri, 17 May 2002 08:23:54 -0400 (EDT) Message-ID: <3CE438E1.9060302@isi.edu> Date: Thu, 16 May 2002 15:55:29 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Michael Thomas CC: Charlie_Kaufman@notesdev.ibm.com, Francis Dupont , ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 References: <15588.13017.673564.786273@thomasm-u1.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060904090009040106010005" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060904090009040106010005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Like Francis I suspect, there's a lot to be gained > for mobility if we separate routing tags from > identity. In particular, it would be very, very > advantageous to be able to create a tunnel where > the outer routing tag is irrelevant so long as the > inner payloads/integrity all check out. Isn't this accomplished by end-to-end transport mode IPsec that goes through an unsecured IPIP tunnel? Lars -- Lars Eggert USC Information Sciences Institute --------------ms060904090009040106010005 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDUxNjIyNTUzMVowIwYJKoZIhvcNAQkEMRYEFBHO2Tq6Nh0E NLLMY54tuUQWhycnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCumLPduMY8aZt4pXpijI4RWLXDUpoy+7pAK37S0yxYUqW+ 9tqF7QPTfmmVGQOptUQbEDn0jIXsflHppytMn5/ReCgVEb1B3086ebTBAefRTs9lEDrm3dfu sTtzsAfprpu5e03mi3O7Oj93et61uowTGxXKp8aU7w3XPcvhq/+I7gAAAAAAAA== --------------ms060904090009040106010005-- From owner-ipsec@lists.tislabs.com Fri May 17 10:10:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HHAaL08625; Fri, 17 May 2002 10:10:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10889 Fri, 17 May 2002 12:25:09 -0400 (EDT) Message-ID: <3CE52BEC.1040306@isi.edu> Date: Fri, 17 May 2002 09:12:28 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Francis Dupont CC: Michael Thomas , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 References: <200205170953.g4H9rWT93137@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020308070605000502070405" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms020308070605000502070405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > > Like Francis I suspect, there's a lot to be gained > > for mobility if we separate routing tags from > > identity. In particular, it would be very, very > > advantageous to be able to create a tunnel where > > the outer routing tag is irrelevant so long as the > > inner payloads/integrity all check out. > > Isn't this accomplished by end-to-end transport mode IPsec that goes > through an unsecured IPIP tunnel? > > => unfortunately this is the opposite because transport mode in IPIP > knows *only* the outer header. I didn't mean a draft-touch-ipsec tunnel (this time :-), I meant this: | Tunnel IP Header:| Orig IP Header:| IPsec: | | | TSrc -> TDst | OSrc -> ODst | Transport Mode | Payload | I.e. just run IPsec end-to-end over a MobileIP (or other IPIP) tunnel. But there may be specifics to Mobile IP that I'm ignorant of... Lars -- Lars Eggert USC Information Sciences Institute --------------ms020308070605000502070405 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDUxNzE2MTIyOFowIwYJKoZIhvcNAQkEMRYEFPj1vL9cEUR+ MLiMT1JedqvADZGoMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCwDKhP2y+DD+5iyUSHCTwrKazvd6oNodsdf1fQQ5WMS73X i2lYqhj6SpO/c/J9RBMHR0DulX01iHNZcJD2S1kiZfVK1LJgI5sX6/ebryq0CQs4cZU8vE4r IqRI7zdlt/SzH78unohmLcYG6Yoz1uGygWHHJ6zWJ7Ow1zYlnAtxBQAAAAAAAA== --------------ms020308070605000502070405-- From owner-ipsec@lists.tislabs.com Fri May 17 11:39:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HIdOL11438; Fri, 17 May 2002 11:39:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10989 Fri, 17 May 2002 13:57:45 -0400 (EDT) From: mlafon@arkoon.net X-Lotus-FromDomain: ARKOON To: ipsec@lists.tislabs.com Message-ID: Date: Fri, 17 May 2002 20:14:31 +0200 Subject: Re: NAT-Traversal - Security Considerations Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I (now) understand it, we must apply NAT to NAT-T packets using Transport Mode or we create a blackhole between the Responder and the NAT device. As it is not obvious (tell me if I'm the only one for who it was not obvious) and can cause DoS, even with normal use, implementors should be explicitely warned. By example : Implementors are warned that NAT SHOULD be applied to packets received using Transport Mode encapsulation when the sender is behind a NAT device. Without NAT, all packets sent by S to the NAT device or devices behind it, and following the trafic descriptor of the SA established will be sent to the peer which has initiated the SA. This will create a sort of blackhole between S and the NAT device. Implementators MUST devise ways of preventing such a thing from occurring; either by disallowing Transport Mode, by applying NAT or by other means. Of course, don't forget to correct me if I'm still wrong and note that I will not allow NAT-T Transport Mode as it is not satisfying for me. -- Mathieu Lafon - Arkoon Network Security From owner-ipsec@lists.tislabs.com Fri May 17 12:08:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HJ8cL12399; Fri, 17 May 2002 12:08:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11024 Fri, 17 May 2002 14:30:57 -0400 (EDT) Message-Id: <3.0.3.32.20020517110546.013cbfc0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 17 May 2002 11:05:46 -0700 To: Charlie_Kaufman@notesdev.ibm.com, Francis Dupont From: Alex Alten Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:42 PM 5/14/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: >This posting points out the tip of a very large iceberg. I think I >understand some of the issues (but I'm not confident); some seem >unsolvable; and some raise questions about the design goals of IPsec. >Attempts to improve things for some scenarios (e.g. Mobile IP) may make >things worse in others (e.g. Address Translation Gateways). Hello Charlie, You raise some excellent points as usual. I have privately thought for a long time that IPsec's dependence on an IP address to determine an SA to be a fundamental flaw in its design. To be effective IPsec needs a global address space, in which each host is uniquely identified, like the Internet was prior to the introduction of NATs, etc. To make this work a way to dynamically map an Internet address, including duplicate private non-routable addresses, to a global unique IPSec address/identifier needs to be made available. Each host can then query this database to resolve an IP address to a secure IPsec address/identifier. Cryptography is then used to assure that the IPsec address/identifier is indeed valid. In this way both MobileIP and NAT can be supported as-is, because they operate on an insecure non-unique IP address, while IPsec uses the parallel universe of a secure unique IPsec address/identifier. However this approach does mean that IPsec can no longer be treated as just a secure protocol, or set of protocols if you include key management. It must be part of a security system, which includes this address mapping facility. Regards, - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri May 17 12:50:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HJoqL13578; Fri, 17 May 2002 12:50:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11150 Fri, 17 May 2002 15:11:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.20020517110546.013cbfc0@mail> References: <3.0.3.32.20020517110546.013cbfc0@mail> Date: Fri, 17 May 2002 14:56:46 -0400 To: Alex Alten From: Stephen Kent Subject: Re: addresses and IKEv2 Cc: Charlie_Kaufman@notesdev.ibm.com, Francis Dupont , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:05 AM -0700 5/17/02, Alex Alten wrote: >At 10:42 PM 5/14/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: >>This posting points out the tip of a very large iceberg. I think I >>understand some of the issues (but I'm not confident); some seem >>unsolvable; and some raise questions about the design goals of IPsec. >>Attempts to improve things for some scenarios (e.g. Mobile IP) may make >>things worse in others (e.g. Address Translation Gateways). > >Hello Charlie, > >You raise some excellent points as usual. > >I have privately thought for a long time that IPsec's dependence on an >IP address to determine an SA to be a fundamental flaw in its design. >To be effective IPsec needs a global address space, in which each host is >uniquely identified, like the Internet was prior to the introduction of >NATs, etc. To make this work a way to dynamically map an Internet address, >including duplicate private non-routable addresses, to a global unique IPSec >address/identifier needs to be made available. Each host can then query >this database to resolve an IP address to a secure IPsec address/identifier. >Cryptography is then used to assure that the IPsec address/identifier is >indeed valid. In this way both MobileIP and NAT can be supported as-is, >because they operate on an insecure non-unique IP address, while IPsec uses >the parallel universe of a secure unique IPsec address/identifier. > >However this approach does mean that IPsec can no longer be treated as just >a secure protocol, or set of protocols if you include key management. It >must be part of a security system, which includes this address mapping >facility. > >Regards, > >- Alex Alex, I assume you have read the new ESP ID from last fall, as well as the new AH ID from this spring, and have followed the WG discussions of why the SA can be determined by examining just the SPI 9without referebce to the destination address), for unicast traffic. Given that context, I'm not sure I understand your comments above. Could you clarify? Thanks, Steve From owner-ipsec@lists.tislabs.com Fri May 17 19:13:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4I2DjL23553; Fri, 17 May 2002 19:13:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11880 Fri, 17 May 2002 21:31:37 -0400 (EDT) Reply-To: From: "Penny Harper" To: "'Francis Dupont'" , "'Michael Thomas'" Cc: , Subject: RE: addresses and IKEv2 Date: Fri, 17 May 2002 18:43:21 -0700 Message-ID: <005f01c1fe0d$65c4c9b0$6400a8c0@w2ks> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200205170944.g4H9iRT93074@givry.rennes.enst-bretagne.fr> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will someone on this list please tell me how to remove myself from the list? Thanks. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Francis Dupont Sent: Friday, May 17, 2002 2:44 AM To: Michael Thomas Cc: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In your previous mail you wrote: => thanks for your support Mike! What happens with IKE is another discussion that I'll bow out of for the time being... => there is something to do with IKE because SAs come by pairs, i.e. for the mobile to correspondent way address agility is enough (and is already in RFC 2401) but for the correspondent to mobile way something is needed (readdressing exchange?). Thanks Francis.Dupont@enst-bretagne.fr PS: more I think about SOI & mobility, more I believe SOI should have an optional message header verification, something like a special ID payload with the party transport parameters. My current idea is, for IKEv2 for instance: - optional ID payload of type address with the party transport parameters (address, protocol (udp), port (500)) - this payload should be the first one (a way to mark it as special) - if it is present it must be checked against the message header - the policy should say if this is required to be sent or received - the policy should say if this can overwrite previous used addresses: * further IKE messages * all established SAs with this peer IMHO only the last point is arguable (i.e. I am still looking for better solutions). From owner-ipsec@lists.tislabs.com Fri May 17 21:01:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4I41lL26433; Fri, 17 May 2002 21:01:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12082 Fri, 17 May 2002 23:24:44 -0400 (EDT) Date: Sat, 18 May 2002 06:36:42 +0300 Message-Id: <200205180336.GAA19829@burp.tkv.asdf.org> From: Markku Savela To: henry@spsystems.net CC: ipsec@lists.tislabs.com In-reply-to: (message from Henry Spencer on Wed, 15 May 2002 10:23:28 -0400 (EDT)) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Henry Spencer > On Wed, 15 May 2002, Markku Savela wrote: > > There is no need for such other protocol. Assuming your implementation > > is conformant to RFC-2401, it already does the policy checking, > > whether IKE is present or not. > > It does not do consistency checking to ensure that the policies on > the two ends match. Nor does it have any way of selecting between > policy options, when the other end may not accept all choices. > These are practical issues of great importance, however trivial they > may seem in theory. There is no need to ensure that policies on two ends match. As per RFC-2401, policy is checked for each packet. IKE does not need to check the policy. As I've said repeatedly, it is easy to detect policy mismatch during the normal and *required* policy checking on received packet: if it arrives and "decodes" properly with indicated SA(s) and then fails the policy check, you have a mismatched policy. There is no need and never should be any "policy negotiation" protocol within IKE. I view IPSEC policy as similar concept as firewall rules. Each host decides and specifies it's requirements outside IKE. There is no "firewall policy exchange protocol" either, and hosts manage to communicate over them. What are "policy options"? If you mean alternatives to the algorithms, then that is quite ok. My policy migth say local-port=80 -> ESP (DES3 | BLOWFISH) and it would accept both. Algorithm is part of the SA definition. I think part of the confusion is due to fact that freeswan uses the SPD for storing the traffic selector information, which should really be attached to the SA. In above my policy selector is just "local-port=80", but if I have additional requirement that each connection should use own SA, then the traffic selectors in the generated negotiation will include both ports and addressess explicitly (and this information is stored into each SA directly, not into SPD like freeswan appears to do). From owner-ipsec@lists.tislabs.com Fri May 17 23:22:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4I6MxL05852; Fri, 17 May 2002 23:22:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA12414 Sat, 18 May 2002 01:44:02 -0400 (EDT) Message-Id: <200205180546.g4I5kbT00763@fatty.lounge.org> To: Markku Savela Cc: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: Your message of "Sat, 18 May 2002 06:36:42 +0300." <200205180336.GAA19829@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <760.1021700797.1@tibernian.com> Date: Fri, 17 May 2002 22:46:37 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 18 May 2002 06:36:42 +0300 you wrote > > There is no need and never should be any "policy negotiation" protocol > within IKE. I view IPSEC policy as similar concept as firewall > rules. Each host decides and specifies it's requirements outside > IKE. There is no "firewall policy exchange protocol" either, and hosts > manage to communicate over them. What if Joe User had an workstation with IP address 172.21.16.5 and the following policy: 172.21.16.5 <---> 10.1/16, protect via 192.168.10.1 any <--> any, drop and 192.168.10.1 has the 10.1/16 network on a directly connected interface and the following policy: 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5 any <--> any, drop Here Joe thinks he can access more than the remote gateway will allow. Joe tries to access 10.1.5.5. How does Joe figure out what the problem is? In your view of the world each side has SAs that denote their own rules but there is no communication between them to express a mismatch. Someone monitoring the 192.168.10.1 gateway may see lots of packets sent from 172.21.16.5 being dropped because they fail a policy check (assuming of course that someone is monitoring it which is _highly_ unlikely). But that's about it. To Joe it's a blackhole and "it just doesn't work". In addition, in your view of how IKE should work it would not be possible to do IPsec remote access where one end is coming from an unknown IP address and accessing a protected network behind a gateway. The gateway cannot know the IP address of the remote client a priori and therefore can't have any policy information specifying what traffic to and from him is to be protected, dropped, or bypassed. And since, in your view, IKE is forbidden from providing any hints it won't work. A hopeless blackhole and (arguably) the most popular use of IPsec today being not allowed. That's not a very compelling argument. Dan. From owner-ipsec@lists.tislabs.com Sat May 18 05:48:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ICmEL17022; Sat, 18 May 2002 05:48:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12919 Sat, 18 May 2002 07:59:58 -0400 (EDT) Message-Id: <200205181212.g4ICCCT99062@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Lars Eggert cc: Michael Thomas , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-reply-to: Your message of Fri, 17 May 2002 09:12:28 PDT. <3CE52BEC.1040306@isi.edu> Date: Sat, 18 May 2002 14:12:12 +0200 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 is a cryptographically signed message in MIME format. I didn't mean a draft-touch-ipsec tunnel (this time :-), I meant this: | Tunnel IP Header:| Orig IP Header:| IPsec: | | | TSrc -> TDst | OSrc -> ODst | Transport Mode | Payload | I.e. just run IPsec end-to-end over a MobileIP (or other IPIP) tunnel. But there may be specifics to Mobile IP that I'm ignorant of... => by definition in Mobile IP the Home Agent may not modify the content of packets it relays to the Mobile Node (this is why it uses a tunnel and doesn't add a routing header in Mobile IPv6) so as this transport mode is end-to-end it is orthogonal to Mobile IP... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sat May 18 06:20:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IDK3L18167; Sat, 18 May 2002 06:20:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12977 Sat, 18 May 2002 08:42:02 -0400 (EDT) Message-Id: <200205181253.g4ICrrT99275@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alex Alten cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-reply-to: Your message of Fri, 17 May 2002 11:05:46 PDT. <3.0.3.32.20020517110546.013cbfc0@mail> Date: Sat, 18 May 2002 14:53:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I have privately thought for a long time that IPsec's dependence on an IP address to determine an SA to be a fundamental flaw in its design. To be effective IPsec needs a global address space, in which each host is uniquely identified, like the Internet was prior to the introduction of NATs, etc. To make this work a way to dynamically map an Internet address, including duplicate private non-routable addresses, to a global unique IPSec address/identifier needs to be made available. Each host can then query this database to resolve an IP address to a secure IPsec address/identifier. Cryptography is then used to assure that the IPsec address/identifier is indeed valid. In this way both MobileIP and NAT can be supported as-is, because they operate on an insecure non-unique IP address, while IPsec uses the parallel universe of a secure unique IPsec address/identifier. => what you want is HIP (Host Identity Payload protocol)... However this approach does mean that IPsec can no longer be treated as just a secure protocol, or set of protocols if you include key management. It must be part of a security system, which includes this address mapping facility. => HIP or any other two space (*) solution should be a major change in the architecture of the Internet. Thanks Francis.Dupont@enst-bretagne.fr PS (*): systems where locator and identity functions of addresses are separated. From owner-ipsec@lists.tislabs.com Sat May 18 07:43:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IEhhL25358; Sat, 18 May 2002 07:43:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13141 Sat, 18 May 2002 09:59:33 -0400 (EDT) Message-Id: <200205181411.g4IEBUT99602@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alex Alten cc: Stephen Kent , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 In-reply-to: Your message of Fri, 17 May 2002 16:38:06 PDT. <3.0.3.32.20020517163806.013cc950@mail> Date: Sat, 18 May 2002 16:11:30 +0200 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 fundamental problem is how can we identify a host unambigously in real time in order to be able to automate the picking of the correct crypto key used to authenticate it and then bootstrap the SA? I don't see the answer anywhere in the RFCs or IDs. Certainly there are a lot of documents and maybe I've missed seeing it. I know that X.509 certs are not the answer (the bound name/address is too static and can be unreliable). => I have a different view of this problem: I believe the identity is really the IKE phase one ID and X.509 certs are the answer. But of course this is not enough because the problem moves to the relationship between the identity and the IP address: - it must be flexible, i.e. I agree here X.509 certs are too static. - it must be reliable, i.e. if the identity is a FQDN then we have to go to DNSsec which is not ready and deployed. - it should be "agile" if we'd like to support mobility, i.e. the previous solution is not enough dynamic. - it should be broken if we'd like to support NAT traversal. Of course this opens the door to obvious security problems. I'd like to see this WG decides what properties we'd like to get for addresses, i.e. in the same order: - authenticated - indirectly authenticated - check for integrity - just pick up as they are got. The trust is not the same, authentication relies on PKIs, integrity checks on the peer, last property on ingress filtering and safe infrastructure. As we use more and more IDs of not address types (as recommended by the IAB in RFC 2956), this problem should be solved ASAP. IMHO it is more important than SOI (or at least should be a critical point of SOI). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sat May 18 09:25:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IGPgL01709; Sat, 18 May 2002 09:25:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13357 Sat, 18 May 2002 11:45:48 -0400 (EDT) Message-Id: <200205181556.g4IFuoT99856@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-reply-to: Your message of Sat, 18 May 2002 06:36:42 +0300. <200205180336.GAA19829@burp.tkv.asdf.org> Date: Sat, 18 May 2002 17:56:50 +0200 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: > From: Henry Spencer > On Wed, 15 May 2002, Markku Savela wrote: > > There is no need for such other protocol. Assuming your implementation > > is conformant to RFC-2401, it already does the policy checking, > > whether IKE is present or not. > > It does not do consistency checking to ensure that the policies on > the two ends match. Nor does it have any way of selecting between > policy options, when the other end may not accept all choices. > These are practical issues of great importance, however trivial they > may seem in theory. => I agree with Henry even I use a very different system (KAME/racoon). There is no need to ensure that policies on two ends match. As per RFC-2401, policy is checked for each packet. IKE does not need to check the policy. => RFC 2401 says the SPD (it seems to make things even less clear that policy and SPD are different :-). As I've said repeatedly, it is easy to detect policy mismatch during the normal and *required* policy checking on received packet: if it arrives and "decodes" properly with indicated SA(s) and then fails the policy check, you have a mismatched policy. => this is detected by the kernel a posteriori. The other opinion is this should be detected by IKE at the SA establishment. There is no need and never should be any "policy negotiation" protocol within IKE. I view IPSEC policy as similar concept as firewall rules. Each host decides and specifies it's requirements outside IKE. There is no "firewall policy exchange protocol" either, and hosts manage to communicate over them. What are "policy options"? If you mean alternatives to the algorithms, then that is quite ok. My policy migth say local-port=80 -> ESP (DES3 | BLOWFISH) and it would accept both. Algorithm is part of the SA definition. => if I assume policy==SPD entry, this seems very classical (key is a traffic selector, options are the "action". I agree algorithms are in the SA definition). I think part of the confusion is due to fact that freeswan uses the SPD for storing the traffic selector information, which should really be attached to the SA. => RFC 2401 says in section 5 "If no policy is found in the SPD that matches the packet..." (this defines the default action). The whole RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree with you (note RFC 2401 doesn't say the opposite too, i.e. your objection is valid and IPsec implementors in trouble). In above my policy selector is just "local-port=80", but if I have additional requirement that each connection should use own SA, then => this should be allowed according to RFC 2401 but it seems some implementations need a SPD entry by connection (?)... the traffic selectors in the generated negotiation will include both ports and addressess explicitly (and this information is stored into each SA directly, not into SPD like freeswan appears to do). => KAME has the same symptom... The level "uniq" helps but its meaning is that to share a SA between two SPD entries is forbidden, i.e. not a solution to your problem (which IMHO is not the place of the TSs, but the fact a SPD entry can only point to zero or one SA (bundle) with a cache/lookup mechanism using only addresses and the "uniq" feature). Regards Francis.Dupont@enst-bretagne.fr PS: I believe this is a result of the incredible confusion in RFC 2401 & co about addresses in SAs. At the question how many addresses characterized a SA, you can answer zero, one, two, three or four and find a reference in a RFC or an I-D... From owner-ipsec@lists.tislabs.com Sat May 18 15:16:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IMG8L14509; Sat, 18 May 2002 15:16:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13793 Sat, 18 May 2002 17:37:14 -0400 (EDT) Date: Sun, 19 May 2002 00:49:50 +0300 Message-Id: <200205182149.AAA20255@burp.tkv.asdf.org> From: Markku Savela To: dharkins@tibernian.com CC: henry@spsystems.net, ipsec@lists.tislabs.com In-reply-to: <200205180546.g4I5kbT00763@fatty.lounge.org> (message from Dan Harkins on Fri, 17 May 2002 22:46:37 -0700) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <200205180546.g4I5kbT00763@fatty.lounge.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Dan Harkins > What if Joe User had an workstation with IP address 172.21.16.5 and > the following policy: > > 172.21.16.5 <---> 10.1/16, protect via 192.168.10.1 > any <--> any, drop > > and 192.168.10.1 has the 10.1/16 network on a directly connected interface > and the following policy: > > 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5 > any <--> any, drop > > Here Joe thinks he can access more than the remote gateway will allow. > Joe tries to access 10.1.5.5. How does Joe figure out what the > problem is? This is a somewhat different type of policy mismatch than what I was thinking. In this case, the maintainer of 192.168.10.1 is intentionally forbidding joe from accessing the 10.1.5.5. If joe still tries to do that, he is basicly trying to crack the "firewall". It would be appropriate to alert the 192.168.10.1 maintainer, but I don't think we should notify the cracker about it. On the other hand this a good example of why policy selectors should not be checked in the IKE negotiation. As long as joe stays within the limits of 10.1.17/24, both sides are happy when they compare the exchanged packets to their policy selectors. In above, nothing is yet said about how many SA pairs are being used between 192.168.10.1 and 172.21.16.5. Assuming only one pair for all communication, then in the IKE negotiation, the selector information to be associated with the bots SA's would be protocol=any src port=any dst port=any > In addition, in your view of how IKE should work it would not be > possible to do IPsec remote access where one end is coming from an > unknown IP address and accessing a protected network behind a > gateway. The gateway cannot know the IP address of the remote client > a priori and therefore can't have any policy information specifying > what traffic to and from him is to be protected, dropped, or > bypassed. And since, in your view, IKE is forbidden from providing > any hints it won't work. My view works just fine in such situation. The gateway 192.168.10.1 just has the policy (using your notation) 10.1.17/24 <---> any, protect via "any" any <--> any, drop You do need to have the ability to express tunneling with "any". Assuming joe has the policy as before and wants to connect to 10.1.17.1, then IKE negotiates the SA pair exactly as before (except, of course, that at least now joe must identify itself in phase 1 with something that does not depend on address). The resulting SA's would be exactly the same as before. Looking the situation at 192.168.10.1... Incoming protected packet from joe gets decoded, detunneled, revealing the inner IP: src=172.21.16.5 dst=10.1.17.1 (protected via 172.21.16.5). This will match the policy and gets passed on in clear. Outgoing clear packet is received from 10.1.17.1 with destination 172.21.16.5. Again, this will match the policy selector 10.1.17/24 <---> any, protect via "any" At this point there is the first "tricky" issue. In the example, joe is his own security gateway, so the assumption any == "any" would work and just using the inner destination also as outer destination gives the correct behaviour. Packet is protected using the proper SA and sent away. HOWEVER, if joe itself is behind a security gateway (=172.21.16.1), and 192.168.10.1 receives and outgoing packet with src=10.1.17.1, dst=172.21.16.5 How does 192.168.10.1 know that in this case any != "any", e.g. packet should be protected via 172.21.16.1). Freeswan guys probably install additional policy entry 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.1 10.1.17/24 <---> any, protect via "any" any <--> any, drop This solves the case, when joe is the initator. There is no solution, if 10.1.17.1 is the initiator (inherently impossible, unless assumption any == "any" is made). In my view, the solution could be as follows: joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the resulting SA has the following info protocol=any src port=any dst port=any proxy=172.21.16.5 Now, 192.168.10.1 receives the outbound packet src=10.1.17.1, dst=172.21.16.5 it matches the policy 10.1.17/24 <---> any, protect via "any" from this it knows that tunneling is required, so it will need to look for an SA that has proxy=172.21.16.5, and if joe is the initiator, such thing might be found and packet can be processed. If SA does not exist, there is not enough information to start negotiation. Situation is inherently unsolvable (unless a simple default assumption is attempted, namely the any == "any") From owner-ipsec@lists.tislabs.com Sat May 18 16:01:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IN1vL16721; Sat, 18 May 2002 16:01:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13843 Sat, 18 May 2002 18:24:48 -0400 (EDT) Date: Sun, 19 May 2002 01:36:49 +0300 Message-Id: <200205182236.BAA20271@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: henry@spsystems.net, ipsec@lists.tislabs.com In-reply-to: <200205181556.g4IFuoT99856@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Sat, 18 May 2002 17:56:50 +0200) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <200205181556.g4IFuoT99856@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Francis Dupont > There is no need to ensure that policies on two ends match. As per > RFC-2401, policy is checked for each packet. IKE does not need to > check the policy. > > => RFC 2401 says the SPD (it seems to make things even less clear that > policy and SPD are different :-). SPD is the policy, SAD and SPD are different. > => RFC 2401 says in section 5 "If no policy is found in the SPD that > matches the packet..." (this defines the default action). The whole > RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree > with you (note RFC 2401 doesn't say the opposite too, i.e. your objection > is valid and IPsec implementors in trouble). I was confusing the issue by using "unspecified terminology". In my view we have two types of "selectors" - policy selectors (the ones in SPD) - traffic selectors (used in IKEv2 key negotiations and end up into SAD) The latter are just qualifiers that are associated with the negotiated SA's. And are *ONLY* needed to differentiate multiple SA's between same endpoints. Instead of "traffic selector", should probably use some other term to avoid confusion with the actual "traffic selectors" in the policy. > In above my policy selector is just "local-port=80", but if I have > additional requirement that each connection should use own SA, then > > => this should be allowed according to RFC 2401 but it seems some > implementations need a SPD entry by connection (?)... Yes, they only partial implementations of rfc-2401, most likely due to IKE limitations. RFC-2401 allows many things, which are not possible with IKE(v1). I would like to have this mistake avoided by the next IKEv2, and one way of achieving this result is to remove all policy checking from the IKE. > => KAME has the same symptom... The level "uniq" helps but its meaning > is that to share a SA between two SPD entries is forbidden, i.e. not > a solution to your problem (which IMHO is not the place of the TSs, > but the fact a SPD entry can only point to zero or one SA (bundle) > with a cache/lookup mechanism using only addresses and the "uniq" feature). In my implementation, there is no pointers from policy selector to SA. Any policy selector can be associated with any number of SA's and vice versa. Also, different bundles can share SA's (if only IKE could negotiate such thing). Again, if I get policy (and bundle checking) off the IKE, even SA sharing would start to work fine. > PS: I believe this is a result of the incredible confusion in RFC 2401 & co > about addresses in SAs. At the question how many addresses characterized > a SA, you can answer zero, one, two, three or four and find a reference > in a RFC or an I-D... To me there is no confusion in the SA itself. You have a packet, you extract the selector information from as defined in RFC-2401. There are only 3 addresses: src, dst and possible IPSEC tunnel address (SG address). If my policy says selector => protect by SG then for incoming packets I must also check that the packet actually came from SG (I'm not really sure whether this check is really giving us anything). However, this only applies to tunnels that are specified within the IPSEC itself. There may be some confusion about what the src and dst actually are, in presence of things like IPv6 home address option. From owner-ipsec@lists.tislabs.com Sun May 19 06:56:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4JDuwL26510; Sun, 19 May 2002 06:56:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14969 Sun, 19 May 2002 09:07:03 -0400 (EDT) Message-Id: <200205191318.g4JDIuT02040@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-reply-to: Your message of Sun, 19 May 2002 01:36:49 +0300. <200205182236.BAA20271@burp.tkv.asdf.org> Date: Sun, 19 May 2002 15:18:56 +0200 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: > => RFC 2401 says in section 5 "If no policy is found in the SPD that > matches the packet..." (this defines the default action). The whole > RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree > with you (note RFC 2401 doesn't say the opposite too, i.e. your objection > is valid and IPsec implementors in trouble). I was confusing the issue by using "unspecified terminology". In my view we have two types of "selectors" - policy selectors (the ones in SPD) - traffic selectors (used in IKEv2 key negotiations and end up into SAD) => I have two concerns with that: - policy and traffic selectors have the same format (i.e. the only way to know if a selector is a policy or a traffic one is its "owner"). - I know you'd like that IKEv2 TS are SAD selectors but there is *no* consensus about this point. The latter are just qualifiers that are associated with the negotiated SA's. And are *ONLY* needed to differentiate multiple SA's between same endpoints. Instead of "traffic selector", should probably use some other term to avoid confusion with the actual "traffic selectors" in the policy. > In above my policy selector is just "local-port=80", but if I have > additional requirement that each connection should use own SA, then > > => this should be allowed according to RFC 2401 but it seems some > implementations need a SPD entry by connection (?)... Yes, they only partial implementations of rfc-2401, most likely due to IKE limitations. RFC-2401 allows many things, which are not possible with IKE(v1). => I have no reason to not believe you but my problem is I can't find an "open-source" implementation of IPsec which has more than partial implementations. So I can't judge if your view can be implemented (or how to implement it). I would like to have this mistake avoided by the next IKEv2, and one way of achieving this result is to remove all policy checking from the IKE. => IMHO this is not the good way because we'll only get more unpredicable results... In my implementation... => is it an open-source one (in order to understand it)? > PS: I believe this is a result of the incredible confusion in RFC 2401 & co > about addresses in SAs. At the question how many addresses characterized > a SA, you can answer zero, one, two, three or four and find a reference > in a RFC or an I-D... To me there is no confusion in the SA itself. You have a packet, you extract the selector information from as defined in RFC-2401. => this is a traffic selector view: two (inner) addresses. There are only 3 addresses: src, dst and possible IPSEC tunnel address (SG address). => I believe the third address is the outer destination. IMHO you should consider the outer source too because: - some stupid implementations will check it so you may not just pick up one. - IKE negociates SAs by pairs and the outer source is the destination of the second SA in the opposite way. If my policy says selector => protect by SG then for incoming packets I must also check that the packet actually came from SG (I'm not really sure whether this check is really giving us anything). => so your implementation does an unnecessary check (this check gives nothing but removes many). However, this only applies to tunnels that are specified within the IPSEC itself. => so you finish by 4 addresses because of the tunnel mode. Other answers are: - zero: draft-ietf-ipsec-esp-v3-02.txt inbound processing of unicasts - one: RFC 2401 inbound processing (and previous I-D for multicasts) - two: common sense / transport mode - three: your first answer and PF_KEY (RFC 2367, the source and destination are outer addresses, the optional proxy is the inner source) There may be some confusion about what the src and dst actually are, in presence of things like IPv6 home address option. => home address option, routing header, etc, don't introduce confusion because their action is guided by their position. For instance the home address option should be before any IPsec header, so in inbound processing it is always processed before any IPsec header and IPsec can see only the home address. The complexity exists only for policy on SGs but RFC 2401 gives the details of the transport header chasing: the procedure is to jump between headers using the next header field, so the content of headers should *not* be interpreted by a SG. (this point should be made clearer in the next 2401) Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun May 19 23:12:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K6CxL10147; Sun, 19 May 2002 23:12:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16134 Mon, 20 May 2002 01:29:00 -0400 (EDT) Message-Id: <200205200531.g4K5VaN01164@fatty.lounge.org> To: Markku Savela Cc: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: Your message of "Sun, 19 May 2002 00:49:50 +0300." <200205182149.AAA20255@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1161.1021872696.1@tibernian.com> Date: Sun, 19 May 2002 22:31:36 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 19 May 2002 00:49:50 +0300 you wrote > > From: Dan Harkins > > > What if Joe User had an workstation with IP address 172.21.16.5 and > > the following policy: > > > > 172.21.16.5 <---> 10.1/16, protect via 192.168.10.1 > > any <--> any, drop > > > > and 192.168.10.1 has the 10.1/16 network on a directly connected interface > > and the following policy: > > > > 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5 > > any <--> any, drop > > > > Here Joe thinks he can access more than the remote gateway will allow. > > Joe tries to access 10.1.5.5. How does Joe figure out what the > > problem is? > > This is a somewhat different type of policy mismatch than what I was > thinking. In this case, the maintainer of 192.168.10.1 is > intentionally forbidding joe from accessing the 10.1.5.5. If joe still > tries to do that, he is basicly trying to crack the "firewall". It > would be appropriate to alert the 192.168.10.1 maintainer, but I don't > think we should notify the cracker about it. Your firewall analogy is breaking down. Joe is not a "cracker" he is a user who has been properly authenticated by the gateway. The gateway has decided that he does wish to give Joe access, just that Joe seems to think he is entitled to access more than gateway is allowing. Notification of Joe is the prudent thing to do since he is not a "cracker", he is a legitimate user with old/stale/incorrect policy. By just blackholing his packets you have relegated him to oblivion. You obviously have not dealt with real world use of this technology. This is not a firewall. It's an IPsec gateway. > On the other hand this a good example of why policy selectors should > not be checked in the IKE negotiation. As long as joe stays within > the limits of 10.1.17/24, both sides are happy when they compare the > exchanged packets to their policy selectors. On the contrary, this is a good example of why they should. So that Joe will know exactly what part of his policy is old/stale/incorrect and be able to initiate a procedure to fix it. By not checking the only information Joe will have is "it's broke". I know who your sysadmin staff is and I know that "it's broke" is not satisfactory to get them to fix it. IKE wants to make sure that what is being established is useful and if it is not then to not establish it. If you want to do away with this utility then you should have some substitute for it. > > In addition, in your view of how IKE should work it would not be > > possible to do IPsec remote access where one end is coming from an > > unknown IP address and accessing a protected network behind a > > gateway. The gateway cannot know the IP address of the remote client > > a priori and therefore can't have any policy information specifying > > what traffic to and from him is to be protected, dropped, or > > bypassed. And since, in your view, IKE is forbidden from providing > > any hints it won't work. > > My view works just fine in such situation. The gateway 192.168.10.1 > just has the policy (using your notation) > > 10.1.17/24 <---> any, protect via "any" > any <--> any, drop > > You do need to have the ability to express tunneling with > "any". Assuming joe has the policy as before and wants to connect to > 10.1.17.1, then IKE negotiates the SA pair exactly as before (except, > of course, that at least now joe must identify itself in phase 1 with > something that does not depend on address). The resulting SA's would > be exactly the same as before. > > Looking the situation at 192.168.10.1... > > Incoming protected packet from joe gets decoded, detunneled, revealing > the inner IP: src=172.21.16.5 dst=10.1.17.1 (protected via > 172.21.16.5). This will match the policy and gets passed on in clear. > > Outgoing clear packet is received from 10.1.17.1 with destination > 172.21.16.5. Again, this will match the policy selector > > 10.1.17/24 <---> any, protect via "any" > > At this point there is the first "tricky" issue. In the example, joe > is his own security gateway, so the assumption > > any == "any" > > would work and just using the inner destination also as outer > destination gives the correct behaviour. Packet is protected using the > proper SA and sent away. > > HOWEVER, if joe itself is behind a security gateway (=172.21.16.1), > and 192.168.10.1 receives and outgoing packet with > > src=10.1.17.1, dst=172.21.16.5 > > How does 192.168.10.1 know that in this case any != "any", e.g. packet > should be protected via 172.21.16.1). > > Freeswan guys probably install additional policy entry > > 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.1 > 10.1.17/24 <---> any, protect via "any" > any <--> any, drop Not just freeswan but every one else who implements this _correctly_. > This solves the case, when joe is the initator. There is no solution, > if 10.1.17.1 is the initiator (inherently impossible, unless > assumption any == "any" is made). > > In my view, the solution could be as follows: > > joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the > resulting SA has the following info > > protocol=any > src port=any > dst port=any > proxy=172.21.16.5 Proxy? Where did that come from? I thought IKE was not permitted to provide any clarifying information in your view. SA were just established that specify a destination address, in this case 172.21.16.1. There is no tie from the policy statement with "any" to this address and a packet sent to 172.21.16.5 would definitely hit the "any" part of that selector but there would be no way to locate the correct SA and destination gateway. Dan. From owner-ipsec@lists.tislabs.com Mon May 20 00:58:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K7wjL27520; Mon, 20 May 2002 00:58:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16386 Mon, 20 May 2002 03:20:16 -0400 (EDT) Message-ID: <4F7DD203738DD411B71A00B0D03DDECC034A2268@highway> From: 867 <867@nu.edu.pk> To: "'ipsec@lists.tislabs.com'" Subject: How to Capture an IP Packet Date: Mon, 20 May 2002 13:35:23 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, Can any body please help me in an issue. I need to capture the IP Packet after IP layer has processed it, and then place it to the next layer myself. I am using Linux as the development platform. Thanks. Regards, Usman From owner-ipsec@lists.tislabs.com Mon May 20 05:48:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCmfL23308; Mon, 20 May 2002 05:48:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17077 Mon, 20 May 2002 08:05:04 -0400 (EDT) Message-Id: <3.0.3.32.20020517163806.013cc950@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 17 May 2002 16:38:06 -0700 To: Stephen Kent From: Alex Alten Subject: Re: addresses and IKEv2 Cc: Charlie_Kaufman@notesdev.ibm.com, Francis Dupont , ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:56 PM 5/17/2002 -0400, Stephen Kent wrote: >At 11:05 AM -0700 5/17/02, Alex Alten wrote: >>At 10:42 PM 5/14/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: >>>This posting points out the tip of a very large iceberg. I think I >>>understand some of the issues (but I'm not confident); some seem >>>unsolvable; and some raise questions about the design goals of IPsec. >>>Attempts to improve things for some scenarios (e.g. Mobile IP) may make >>>things worse in others (e.g. Address Translation Gateways). >> >>Hello Charlie, >> >>You raise some excellent points as usual. >> >>I have privately thought for a long time that IPsec's dependence on an >>IP address to determine an SA to be a fundamental flaw in its design. >>To be effective IPsec needs a global address space, in which each host is >>uniquely identified, like the Internet was prior to the introduction of >>NATs, etc. To make this work a way to dynamically map an Internet address, >>including duplicate private non-routable addresses, to a global unique IPSec >>address/identifier needs to be made available. Each host can then query >>this database to resolve an IP address to a secure IPsec address/identifier. >>Cryptography is then used to assure that the IPsec address/identifier is >>indeed valid. In this way both MobileIP and NAT can be supported as-is, >>because they operate on an insecure non-unique IP address, while IPsec uses >>the parallel universe of a secure unique IPsec address/identifier. >> >>However this approach does mean that IPsec can no longer be treated as just >>a secure protocol, or set of protocols if you include key management. It >>must be part of a security system, which includes this address mapping >>facility. >> >>Regards, >> >>- Alex > >Alex, > >I assume you have read the new ESP ID from last fall, as well as the >new AH ID from this spring, and have followed the WG discussions of >why the SA can be determined by examining just the SPI 9without >referebce to the destination address), for unicast traffic. Given >that context, I'm not sure I understand your comments above. Could >you clarify? > >Thanks, > >Steve > Steve, My comments only apply to the RFCs as they stand today. SPI is a different beast than what I'm discussing even with your latest ESP ID adjustments. The fundamental problem is how can we identify a host unambigously in real time in order to be able to automate the picking of the correct crypto key used to authenticate it and then bootstrap the SA? I don't see the answer anywhere in the RFCs or IDs. Certainly there are a lot of documents and maybe I've missed seeing it. I know that X.509 certs are not the answer (the bound name/address is too static and can be unreliable). - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon May 20 05:48:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCmfL23309; Mon, 20 May 2002 05:48:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17140 Mon, 20 May 2002 08:10:08 -0400 (EDT) Message-Id: <200205192330.TAA13625@nwmail.wh.lucent.com> Content-Type: text/plain; charset="iso-8859-1" From: Uri Blumenthal Reply-To: uri@bell-labs.com To: Jan Vilhuber , Michael Thomas Subject: Re: SOI schizophrenia Date: Sun, 19 May 2002 19:29:57 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: In-Reply-To: Organization: Lucent Technologies / Bell Labs MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA15611 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 16 May 2002 16:58, Jan Vilhuber wrote: > > All in all, they both seem competent. > > They are both competent from a cryptography point of view, but only > one actually allows key management in any sane way. Precisely. > I think that's > where the two part company, and we as a group need to decide which is > more appropriate: A key *agreement* protocol (JFK) which will require > other protocols (ICMP? Right..) to help solve the current deployment > stability, or a key *management* protocol (IKEv2), that let's you > manage the key we agreed on, without requiring other external > management protocols. Indeed, a crucial distinction between a protocol that does the necessary math and a protocol that [in addition to that] provides the services required by the real world deployment. > Of course another question might be: Do we need key management? Based > on operational experience and fixing lots of customer deployment and > network stability problems, I'd say that's an emphatic YES. I'm surprised that even the question is brought up! Isn't it "of course"? -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Mon May 20 05:49:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCn6L23339; Mon, 20 May 2002 05:49:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17153 Mon, 20 May 2002 08:12:11 -0400 (EDT) Message-Id: <200205192330.TAA13625@nwmail.wh.lucent.com> Content-Type: text/plain; charset="iso-8859-1" From: Uri Blumenthal Reply-To: uri@bell-labs.com To: Jan Vilhuber , Michael Thomas Subject: Re: SOI schizophrenia Date: Sun, 19 May 2002 19:29:57 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: In-Reply-To: Organization: Lucent Technologies / Bell Labs MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA15611 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 16 May 2002 16:58, Jan Vilhuber wrote: > > All in all, they both seem competent. > > They are both competent from a cryptography point of view, but only > one actually allows key management in any sane way. Precisely. > I think that's > where the two part company, and we as a group need to decide which is > more appropriate: A key *agreement* protocol (JFK) which will require > other protocols (ICMP? Right..) to help solve the current deployment > stability, or a key *management* protocol (IKEv2), that let's you > manage the key we agreed on, without requiring other external > management protocols. Indeed, a crucial distinction between a protocol that does the necessary math and a protocol that [in addition to that] provides the services required by the real world deployment. > Of course another question might be: Do we need key management? Based > on operational experience and fixing lots of customer deployment and > network stability problems, I'd say that's an emphatic YES. I'm surprised that even the question is brought up! Isn't it "of course"? -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Mon May 20 05:51:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCpvL23696; Mon, 20 May 2002 05:51:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17179 Mon, 20 May 2002 08:16:12 -0400 (EDT) Message-Id: <200205192330.TAA13625@nwmail.wh.lucent.com> Content-Type: text/plain; charset="iso-8859-1" From: Uri Blumenthal Reply-To: uri@bell-labs.com To: Jan Vilhuber , Michael Thomas Subject: Re: SOI schizophrenia Date: Sun, 19 May 2002 19:29:57 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: In-Reply-To: Organization: Lucent Technologies / Bell Labs MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA15611 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 16 May 2002 16:58, Jan Vilhuber wrote: > > All in all, they both seem competent. > > They are both competent from a cryptography point of view, but only > one actually allows key management in any sane way. Precisely. > I think that's > where the two part company, and we as a group need to decide which is > more appropriate: A key *agreement* protocol (JFK) which will require > other protocols (ICMP? Right..) to help solve the current deployment > stability, or a key *management* protocol (IKEv2), that let's you > manage the key we agreed on, without requiring other external > management protocols. Indeed, a crucial distinction between a protocol that does the necessary math and a protocol that [in addition to that] provides the services required by the real world deployment. > Of course another question might be: Do we need key management? Based > on operational experience and fixing lots of customer deployment and > network stability problems, I'd say that's an emphatic YES. I'm surprised that even the question is brought up! Isn't it "of course"? -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Mon May 20 12:11:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KJBvL07712; Mon, 20 May 2002 12:11:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18015 Mon, 20 May 2002 14:28:22 -0400 (EDT) Date: Mon, 20 May 2002 11:40:57 -0700 (PDT) From: Jan Vilhuber To: Michael Thomas cc: Subject: Re: SOI schizophrenia In-Reply-To: <15588.9007.583427.780174@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 16 May 2002, Michael Thomas wrote: > Jan Vilhuber writes: > > On Wed, 15 May 2002, Michael Thomas wrote: > > > > > > > > I admit it. I'm having a real hard time deciding > > > which design philosophy is actually more > > > appropriate for SOI. I've vacillated quite a few > > > times and it doesn't seem like it's about to abate > > > any time soon. What Paul's document tells me > > > (which pretty jibes with my own judgement) is that > > > both protocols are vast improvements over IKE, and > > > they seem to reach quite similar conclusions on > > > the basic message exchanges. Both put effort into > > > DoS, and simplify the on-wire combinatorial > > > explosion of SA establishment. All in all, they > > > both seem competent. > > > > > > > They are both competent from a cryptography point of view, but only > > one actually allows key management in any sane way. I think that's > > where the two part company, and we as a group need to decide which is > > more appropriate: A key *agreement* protocol (JFK) which will require > > other protocols (ICMP? Right..) to help solve the current deployment > > stability, or a key *management* protocol (IKEv2), that let's you > > manage the key we agreed on, without requiring other external > > management protocols. > > I don't understand what you mean by "management" > in this context. JFK can add and delete SA, and > assigns lifetimes to them. It seems light on a > DPD scheme, but that seems like a negotiable > item. Two phases is just an optmization. > > What am I missing? > In order to delete an SA, the ESP_BYPASS and AH_BYPASS was added to JFK (although I'd probably call this a kludge.. your mileage may vary). Note that "When a negotiated SA expires (or shortly before it does), the JFK protocol is run again." This holds true for deletion as well. Meaning one rsa operation (at each end) each time. Yes, having a phase 1 SA is in this respect an optimization, but in my opinion a critical one. Is doing an RSA sign operation each time you want to send a tunnel-management message OK? Not in my opinion. Also, don't forget that you may want to negotiate multiple SA's between two endpoints (in fact it's quite likely). Doing rsa signatures every time (for every SA) seems unreasonable. Again, a phase 1 SA under which to do the add's and delete's is ever so much cheaper. As you point out, keepalives or DPD is lacking in JFK as well (pointing to ICMP pings is an interesting idea, but hardly worthy of a protocol spec and interoperability; This ICMP section in JFK constitutes the second punt of key management in the spec; Also, pings don't scale well. DPD was developped because something like an IKE ping won't scale). Second, if you believe that management messages are few and well defined, building them into your protocol from the start may be OK, I suppose. If, on the other hand, you believe that you'll need to address customer and deployment issues as they arise (i.e. if you believe a protocol is a living, breathing entity that needs to adapt to changing times and situations), you need a bit more flexibility and extensibility (and I strongly believe in a vendor-extension mechanism, which has proven critical in many protocols over the years to test out new features before proposing them). JFK implicitely (or explicitely?) slams the door on vendor-extensibility. Again, a management channel via which I can add different management messages as I decide I need them is a wonderful idea. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon May 20 23:49:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4L6niL05726; Mon, 20 May 2002 23:49:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA19172 Tue, 21 May 2002 02:07:10 -0400 (EDT) Date: Tue, 21 May 2002 09:19:22 +0300 Message-Id: <200205210619.JAA02713@burp.tkv.asdf.org> From: Markku Savela To: dharkins@tibernian.com CC: henry@spsystems.net, ipsec@lists.tislabs.com In-reply-to: <200205200531.g4K5VaN01164@fatty.lounge.org> (message from Dan Harkins on Sun, 19 May 2002 22:31:36 -0700) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <200205200531.g4K5VaN01164@fatty.lounge.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Dan Harkins > Notification of Joe is the prudent thing to do since he is not a > "cracker", he is a legitimate user with old/stale/incorrect > policy. By just blackholing his packets you have relegated him to > oblivion. You obviously have not dealt with real world use of this > technology. You can either black hole or notify. If gateway 192.168.10.1 has policy 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5 any <--> any, drop and joe (172.21.16.5) tries for 10.1.5.5, then in my world 1) IKE establishes phase I between 172.21.16.5 and 192.168.10.1 2) Using this, Joe succesfully negotiates SA's for communicating with 10.1.5.5 3) Joe's encrypted packets to 10.1.5.5 are successfully decoded at 192.168.10.1, but they fail to match the policy => gateway knows there is policy mismatch or cracking attempt. It can either - drop the packet (black hole), or - pass a note to the local IKE, which could decide to send a notification to the joe's IKE using the existing phase I. > This is not a firewall. It's an IPsec gateway. You can do firewall with IPSEC (as far as access control is your need). > > joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the > > resulting SA has the following info > > > > protocol=any > > src port=any > > dst port=any > > proxy=172.21.16.5 > > Proxy? Where did that come from? I thought IKE was not permitted to provide > any clarifying information in your view. Proxy is better word what in IKEv2 TS is address (or ranges or whatever). SA destination address is always the address of the other end point (joe or 192.168.10.1). IKE seems to require the source address for SA too, but this is not really a requirement -- on a multihomed node, one could use same SA for all of its source addressess). From owner-ipsec@lists.tislabs.com Tue May 21 08:58:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LFwRL25698; Tue, 21 May 2002 08:58:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20256 Tue, 21 May 2002 11:07:21 -0400 (EDT) Message-Id: <200205211519.g4LFJfk30909@trpz.com> To: Markku Savela cc: ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: Your message of "Tue, 21 May 2002 09:19:22 +0300." <200205210619.JAA02713@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <426.1021993797.1@tibernian.com> Date: Tue, 21 May 2002 08:09:57 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 21 May 2002 09:19:22 +0300 you wrote > > > Notification of Joe is the prudent thing to do since he is not a > > "cracker", he is a legitimate user with old/stale/incorrect > > policy. By just blackholing his packets you have relegated him to > > oblivion. You obviously have not dealt with real world use of this > > technology. > > You can either black hole or notify. If gateway 192.168.10.1 > has policy > > 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5 > any <--> any, drop > > and joe (172.21.16.5) tries for 10.1.5.5, then in my world > > 1) IKE establishes phase I between 172.21.16.5 and 192.168.10.1 > > 2) Using this, Joe succesfully negotiates SA's for communicating with > 10.1.5.5 > > 3) Joe's encrypted packets to 10.1.5.5 are successfully decoded at > 192.168.10.1, but they fail to match the policy => gateway knows > there is policy mismatch or cracking attempt. It can either > > - drop the packet (black hole), or > > - pass a note to the local IKE, which could decide to send a > notification to the joe's IKE using the existing phase I. But you've been arguing all along that IKE should not be doing this. You've been saying that all it should do is obtain a shared key period full stop. > > > joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the > > > resulting SA has the following info > > > > > > protocol=any > > > src port=any > > > dst port=any > > > proxy=172.21.16.5 > > > > Proxy? Where did that come from? I thought IKE was not permitted to provide > > any clarifying information in your view. > > Proxy is better word what in IKEv2 TS is address (or ranges or > whatever). SA destination address is always the address of the other > end point (joe or 192.168.10.1). IKE seems to require the source > address for SA too, but this is not really a requirement -- on a > multihomed node, one could use same SA for all of its source > addressess). But, but, but.... Who cares what the term is. Where is it coming from? You've been arguing that IKE should not be doing this. Since you are now talking about having key management sending error messages indicating mismatched policy and providing clarifying information for the selector to the peer I guess you have changed your mind. Dan. From owner-ipsec@lists.tislabs.com Tue May 21 14:11:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LLBjL07861; Tue, 21 May 2002 14:11:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20873 Tue, 21 May 2002 16:16:00 -0400 (EDT) Content-Type: text/plain; charset="us-ascii" From: Geoffrey Huang To: ipsec@lists.tislabs.com Subject: General Comments on draft-ipsec-soi-features-00.txt Date: Tue, 21 May 2002 13:29:54 -0700 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200205211329.54133.ghuang@cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've read this document, and I have a few comments (more on the protocols than the document itself). First, thanks to Paul Hoffman for summarizing the key points of both protocols. I don't doubt that both protocols achieve authentication and key generation, so I'll focus on operational issues. In general, I think IKEv2 benefits from the experience gained in implementing IKEv1 with respect to operational requirements: authentication by shared secret (IKEv2 has it, JFK doesn't): I understand that this is an irksome issue, but nonetheless, my experience is that users of IKE don't like to be limited in their options for authentication methods. To this end, if SOI excludes shared secret as an option for authentication, I think we'd find that we'd have a tough time persuading users to migrate from the current IKE. one phase-vs-two phase argument: The document brings up a valid point when it describes IKEv2's Phase 1 as a "control channel" for IPSec SAs. The list of management tasks is not to be overlooked: creating, deleting, and rekeying existing IPSec SAs, sending protected notifies, and doing DPD are all important operational tasks that IKEv1 currently supports. Certainly, in current deployments, I've seen where all of the above are important aspects to IKEv1 as a key management protocol. I think we've also seen in NAT traversal where 2 phases has turned out to be useful. ...So there's my $0.02 worth. I think in a separate thread, there was the distinction made between key agreement and key management. This is an important distinction. -g From owner-ipsec@lists.tislabs.com Tue May 21 23:48:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4M6mQL29379; Tue, 21 May 2002 23:48:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21722 Wed, 22 May 2002 02:03:59 -0400 (EDT) Date: Wed, 22 May 2002 09:17:00 +0300 Message-Id: <200205220617.JAA03613@burp.tkv.asdf.org> From: Markku Savela To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200205211519.g4LFJfk30909@trpz.com> (message from Dan Harkins on Tue, 21 May 2002 08:09:57 -0700) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <200205211519.g4LFJfk30909@trpz.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Dan Harkins > But you've been arguing all along that IKE should not be doing this. > You've been saying that all it should do is obtain a shared key period > full stop. I'm saying IKE should not check the policy. In my view, IKE would have tasks - negotiate the Phase I (if two phase model is used). I have no comments on phase I issues. - negotiates just SA's in Phase II, does not check the policy. - the policy mismatch notification would just be an minor addition to the phase I session. It does not mean IKE need to check policy. The singal of the "mismatch" occurring would come from the part of the IPSEC code that implements RFC-2401. How this informed, is local issue, but if one is using PFKEY like API, this would be just another generated message (or error report), which is sent to all registered key managers. > > Proxy is better word what in IKEv2 TS is address (or ranges or > > whatever). SA destination address is always the address of the other > > end point (joe or 192.168.10.1). IKE seems to require the source > > address for SA too, but this is not really a requirement -- on a > > multihomed node, one could use same SA for all of its source > > addressess). > > But, but, but.... Who cares what the term is. Where is it coming from? > You've been arguing that IKE should not be doing this. >From phase II SA negotiations. I fully support something like the proposed TS, but as a part of SA information, which separates multiple SA's that have same end points. The original IKEv1 actually had almost sufficient fields for the "TS-like" information, except when implementations tried to re-interpret them as policy selectors, everything went horribly wrong... However, the new IKEv2 TS proposal fixes the "almost" part (perhaps going a bit overboard for the purpose of SA qualifiers...) From owner-ipsec@lists.tislabs.com Wed May 22 10:01:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MH1KL21539; Wed, 22 May 2002 10:01:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22634 Wed, 22 May 2002 12:10:52 -0400 (EDT) Message-Id: <200205221623.g4MGN8k09697@trpz.com> To: Markku Savela cc: ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: Your message of "Wed, 22 May 2002 09:17:00 +0300." <200205220617.JAA03613@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <399.1022084005.1@tibernian.com> Date: Wed, 22 May 2002 09:13:25 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 22 May 2002 09:17:00 +0300 you wrote > > The original IKEv1 actually had almost sufficient fields for the > "TS-like" information, except when implementations tried to > re-interpret them as policy selectors, everything went horribly > wrong... Horribly wrong? The only trouble that is caused seems to be some affront to your religous sensibilities. But when everyone else is the heretic in your eyes maybe it's time to reevaluate your dogma. Dan. From owner-ipsec@lists.tislabs.com Thu May 23 01:07:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N87bL08815; Thu, 23 May 2002 01:07:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24075 Thu, 23 May 2002 03:12:06 -0400 (EDT) Date: Thu, 23 May 2002 10:24:51 +0300 Message-Id: <200205230724.KAA04639@burp.tkv.asdf.org> From: Markku Savela To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200205221623.g4MGN8k09697@trpz.com> (message from Dan Harkins on Wed, 22 May 2002 09:13:25 -0700) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <200205221623.g4MGN8k09697@trpz.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Dan Harkins > Sender: owner-ipsec@lists.tislabs.com > Precedence: bulk > > On Wed, 22 May 2002 09:17:00 +0300 you wrote > > > > The original IKEv1 actually had almost sufficient fields for the > > "TS-like" information, except when implementations tried to > > re-interpret them as policy selectors, everything went horribly > > wrong... > > Horribly wrong? The only trouble that is caused seems to be some > affront to your religous sensibilities. But when everyone else is > the heretic in your eyes maybe it's time to reevaluate your dogma. Ok, I admit that saying "went horribly wrong" was a bit sentimental, but pulling in term "religious" and "dogma" is not appropriate. This is supposed to be technical discussion and I consider a non-policy checking IKE technically a better solution to the problem. - I believe it is a good architecture to clearly separate RFC-2401 part of IPSEC from the key management, - and implementation claiming to do RFC-2401, does all the necessary policy checks. IKE doing policy check is unnecessary overhead and makes IKE dependent on the policy data base. - IKEv1 and v2 still cause unnecessary limitations to the possibilities that RFC-2401 allows (and removing these limitations from IKE by making it just a key negotiation, does not make IPSEC any more complex, as RFC-2401 compliant implementation will handle them automaticly): - shared SA's between bundles, - does not need to worry if one SA of a bundle expires before some other (it just gets re-negotiated on its own, if needed) - asymmetric SA's - separating policy selectors from those selector like constructs that differentiate SA's allows independent implementations and developement of SPD and SAD. What I think needs to be done is - phase 1 would be as is - specify IKEv2 phase 2 negotiation to be just SA negotiation, - you can optimize and have multiple SA's negotiated at same time (e.g. you can keep most of the current message formats, just don't put any significance to the ordering, just treat it as a collection of SA's to be instantiated) - basic assumption is to negotiate uni-directional SA's. Again, as optimization, one could negotiate two-way SA's. But, for this to work, a new payload is required: it would contain the explicit selector information for the return traffic. - the "TS" information only differentiates SA's (and is only remotely related with the policy selectors) From owner-ipsec@lists.tislabs.com Thu May 23 07:58:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NEwOL03034; Thu, 23 May 2002 07:58:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24907 Thu, 23 May 2002 10:04:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200205230724.KAA04639@burp.tkv.asdf.org> References: <200205221623.g4MGN8k09697@trpz.com> <200205230724.KAA04639@burp.tkv.asdf.org> Date: Thu, 23 May 2002 07:16:59 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Specification of tunnel/transport attribute in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:24 AM +0300 5/23/02, Markku Savela wrote: >This is supposed to be technical discussion and I consider a >non-policy checking IKE technically a better solution to the problem. Note, however, that Dan has pointed out with very clear examples why simply moving "policy" from IKE to 2401 will lead to lack of interoperability in implementations. It seems like your proposed new view of 2401 will either: - need some policy negotiation outside of IKE before packets start to flow - need some policy announcement when bad packets are received ("you're sending me packets that I have no intention of passing to the inside network") - cause black holes that cannot be detected Could you say briefly which of the above you are proposing? If it one of the first two, which protocol are you saying would be used? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 23 11:11:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIB5L10017; Thu, 23 May 2002 11:11:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25358 Thu, 23 May 2002 13:24:04 -0400 (EDT) From: "Theodore Ts'o" nTo: ietf-secretariat@ietf.org cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: draft-ietf-ipsec-sctp-03.txt ready for IETF Last Call Phone: (781) 391-3464 Message-Id: Date: Thu, 23 May 2002 13:36:36 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk draft-ietf-ipsec-sctp-03.txt is ready for IETF Last Call for progression to Proposed Standard. Steve, could you please put this on the IESG's queue and make an announcement to the IETF Announce list. Angelos, I note that we still need to get an IANA assignment for ID-LIST. Could you start that in motion, so it's ready for the end of IETF last call? Thanks!! - Ted and Barbara From owner-ipsec@lists.tislabs.com Thu May 23 11:12:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NICoL10051; Thu, 23 May 2002 11:12:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25398 Thu, 23 May 2002 13:31:05 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com, kivinen@ssh.fi cc: byfraser@cisco.com Subject: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt Phone: (781) 391-3464 Message-Id: Date: Thu, 23 May 2002 13:44:00 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a working group last call for comments for the modp-groups-04 draft, for progression to Proposed Standard. This last call will expire on June 6th. Tero, could you please work with IANA to get assignments for the remaining groups (other than the 1536 group 5). Thanks!! - Ted and Barbara From owner-ipsec@lists.tislabs.com Thu May 23 11:13:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIDUL10067; Thu, 23 May 2002 11:13:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25423 Thu, 23 May 2002 13:36:07 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com, sheila.frankel@nist.gov cc: byfraser@cisco.com Subject: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt Phone: (781) 391-3464 Message-Id: Date: Thu, 23 May 2002 13:48:16 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a working group last call for comments for the aes-xcbc-mac-01 draft, for progression to Proposed Standard. This last call will expire on June 6th. Sheila, could you please work with IANA to get assignments for the AH_AES_XCBC_MAC_96 and AES-XCBC-MAC-96 for the AH and ESP transforms, respectively. Many thanks!! - Ted and Barbara From owner-ipsec@lists.tislabs.com Thu May 23 11:18:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIIZL10202; Thu, 23 May 2002 11:18:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25347 Thu, 23 May 2002 13:21:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20020523103227.0341af00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 May 2002 10:32:49 -0700 To: "William Dixon" From: Barbara Fraser Subject: RE: ike-modp-groups-04 Cc: , In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, it's ready and we'll be sending out an announcement asap. Barb At 04:33 PM 5/16/2002, William Dixon wrote: >Tero, Ted, Barbara, isn't this ready for last call ? Is there anything >we can do to get assigned numbers sooner rather than later ? > >-----Original Message----- >From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] >Sent: Tuesday, April 30, 2002 5:10 PM >To: ipsec@lists.tislabs.com >Subject: ike-modp-groups-04 > > >-----BEGIN PGP SIGNED MESSAGE----- > > > Is there some reason this document has not been published yet? > >] ON HUMILITY: to err is human. To moo, bovine. | >firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device >driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, >security guy"); [ > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3ia >Charset: latin1 >Comment: Finger me for keys > >iQCVAwUBPM8yXYqHRg3pndX9AQF4WwQAxrUMMyFVPHA/zJeoHJ2o7r626+LQ+UYx >SWosLDzzA6GbwXNpeWa93Pefyh/nLt/MgpseVnBdA5CX3dwoFT4Y6B3jctikMoFt >ZYEkrnx//eYqvJzhw0Df3yISWHYdQr1u1lAS5Z0sK+EXgyx0t+ESL9eTK/azVBfY >zngnFDIiYIA= >=qm44 >-----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu May 23 11:25:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIP6L10445; Thu, 23 May 2002 11:25:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25359 Thu, 23 May 2002 13:24:09 -0400 (EDT) From: "Theodore Ts'o" To: ietf-secretariat@ietf.org cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: draft-ietf-ipsec-sctp-03.txt ready for IETF Last Call Phone: (781) 391-3464 Message-Id: Date: Thu, 23 May 2002 13:36:49 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk draft-ietf-ipsec-sctp-03.txt is ready for IETF Last Call for progression to Proposed Standard. Steve, could you please put this on the IESG's queue and make an announcement to the IETF Announce list. Angelos, I note that we still need to get an IANA assignment for ID-LIST. Could you start that in motion, so it's ready for the end of IETF last call? Thanks!! - Ted and Barbara From owner-ipsec@lists.tislabs.com Thu May 23 12:36:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJaCL12485; Thu, 23 May 2002 12:36:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25687 Thu, 23 May 2002 14:52:38 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Thu, 23 May 2002 12:05:18 -0700 (PDT) From: Dong To: Security_Area_Advisory_Group , IPsec Subject: Secure QoS Reply-To: dong_wei@tsinghua.com X-Originating-Ip: [128.235.249.42] Message-Id: <20020523190519.2FFB93ECC@sitemail.everyone.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am trying to do a survey on Secure QoS. Any paper on that? Thx. Dong _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From owner-ipsec@lists.tislabs.com Thu May 23 12:36:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJaCL12486; Thu, 23 May 2002 12:36:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25675 Thu, 23 May 2002 14:48:37 -0400 (EDT) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0E67@MAIL.NetOctave.com> From: Mark Winstead To: "'Theodore Ts'o'" , ipsec@lists.tislabs.com, kivinen@ssh.fi Cc: byfraser@cisco.com Subject: RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt Date: Thu, 23 May 2002 14:47:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2028A.56729F10" 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_01C2028A.56729F10 Content-Type: text/plain Since the document itself quotes sources that cite that for 256 bit keys (like used by AES-256) require for full strength groups in the magnitude of 15400 bits, shouldn't it include a group larger than 8192 bits? Mark Winstead NetOctave, Inc. > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Thursday, May 23, 2002 1:44 PM > To: ipsec@lists.tislabs.com; kivinen@ssh.fi > Cc: byfraser@cisco.com > Subject: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt > > > > This is a working group last call for comments for the modp-groups-04 > draft, for progression to Proposed Standard. This last call > will expire > on June 6th. > > Tero, could you please work with IANA to get assignments for the > remaining groups (other than the 1536 group 5). Thanks!! > > - Ted and Barbara > > > ------_=_NextPart_001_01C2028A.56729F10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt =

Since the document itself quotes sources that cite = that for 256 bit keys (like used by AES-256) require for full strength = groups in the magnitude of 15400 bits, shouldn't it include a group = larger than 8192 bits?

Mark Winstead
NetOctave, Inc.

> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Thursday, May 23, 2002 1:44 PM
> To: ipsec@lists.tislabs.com; = kivinen@ssh.fi
> Cc: byfraser@cisco.com
> Subject: WG LAST CALL: = draft-ietf-ipsec-ike-modp-groups-04.txt
>
>
>
> This is a working group last call for comments = for the modp-groups-04
> draft, for progression to Proposed = Standard.  This last call
> will expire
> on June 6th.
>
> Tero, could you please work with IANA to get = assignments for the
> remaining groups (other than the 1536 group = 5).  Thanks!!
>
>       =         =         =         =         - Ted and Barbara
>
>
>

------_=_NextPart_001_01C2028A.56729F10-- From owner-ipsec@lists.tislabs.com Thu May 23 12:38:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJceL12546; Thu, 23 May 2002 12:38:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25710 Thu, 23 May 2002 14:59:39 -0400 (EDT) Date: 23 May 2002 14:59:51 -0400 Message-ID: <000b01c2028c$05da1310$bd6fe640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: ipsec@lists.tislabs.com Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This draft hasn't really been discussed on the list much. I guess people figure that "hey, it's just another crypto algorithm... there can't be anything controversial about it". The issue which Dave brought up at the meeting and which I sent to the authors is that XCBC-MAC skirts the "obvious" solution of prepending the length of the buffer to the hash input. There is an engineering tradeoff here, which is not mentioned in the draft. AES-XCBC-MAC: a) requires 384 bits of keymat b) does not require that the length of the message be pre-computed The "obvious" solution: a) requires 128 bits of keymat b) requires that the length of the message be pre-computed Clearly, issue (b) was an important motivation in the design of XCBC-MAC. My personal opinion is that this rationale makes sense, since key storage capacity is unlikely to be the limiting factor in the design of any future hardware. However, the tradeoff ought to at least be discussed on the list and acknowledged in the draft. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o > Sent: Thursday, May 23, 2002 1:48 PM > To: ipsec@lists.tislabs.com; sheila.frankel@nist.gov > Cc: byfraser@cisco.com > Subject: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt > > > > This is a working group last call for comments for the aes-xcbc-mac-01 > draft, for progression to Proposed Standard. This last call > will expire > on June 6th. > > Sheila, could you please work with IANA to get assignments for the > AH_AES_XCBC_MAC_96 and AES-XCBC-MAC-96 for the AH and ESP transforms, > respectively. Many thanks!! > > - Ted and Barbara > From owner-ipsec@lists.tislabs.com Thu May 23 14:30:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NLU9L15159; Thu, 23 May 2002 14:30:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25989 Thu, 23 May 2002 16:50:17 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.22768.322645.225267@ryijy.hel.fi.ssh.com> Date: Fri, 24 May 2002 00:02:40 +0300 From: Tero Kivinen To: Mark Winstead Cc: "'Theodore Ts'o'" , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt In-Reply-To: <49B96FCC784BC54F9675A6B558C3464E5D0E67@MAIL.NetOctave.com> References: <49B96FCC784BC54F9675A6B558C3464E5D0E67@MAIL.NetOctave.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 13 min X-Total-Time: 32 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Winstead writes: > Since the document itself quotes sources that cite that for 256 bit keys > (like used by AES-256) require for full strength groups in the magnitude of > 15400 bits, shouldn't it include a group larger than 8192 bits? Generating them using the current hardware resources takes too long time. We need faster cpu's before we can generate them, but fortunately we need also faster machines to use them too. When we have cpu's available that can and will use them then we hopefully have also cpu time to generate them. We tried to calculate the 16386 bit group for couple of few weeks but with no luck. The calculation of the 8192 bit group took 13 days on a one machine, but for the 16386 bit group each step requires about 8 times more time, and the estimated value how far it needs to go until it finds one also goes up by factor of 2-4 or so. This means that calculating it on one machine would take several months or years. Also proving it to actually being a prime would take about same time... Calculating 12288 bit group should be possible in few months even with one machine. If you have 50 or so spare machines with modern cpu and nothing to do, then we can try to generate bigger groups, I can provide the software to run. We can always issue new rfc when those groups are actually generated, there is no point of waiting them now. -- 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 May 23 14:31:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NLVVL15196; Thu, 23 May 2002 14:31:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26001 Thu, 23 May 2002 16:56:16 -0400 (EDT) Message-ID: <80B684C5E29FD211AA8000A0C9CDD9190CE5A231@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: dong_wei@tsinghua.com, Security_Area_Advisory_Group , IPsec Subject: RE: Secure QoS Date: Thu, 23 May 2002 16:08:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dong, Please be a little more precise in what you are asking for, i.e. 3-5 bullet list items on what kind of security you seek. Roy -----Original Message----- From: Dong [mailto:dong_wei@tsinghua.com] Sent: Thursday, May 23, 2002 2:05 PM To: Security_Area_Advisory_Group; IPsec Subject: Secure QoS Hi, I am trying to do a survey on Secure QoS. Any paper on that? Thx. Dong _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From owner-ipsec@lists.tislabs.com Thu May 23 17:24:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O0O6L18527; Thu, 23 May 2002 17:24:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26319 Thu, 23 May 2002 19:33:39 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Thu, 23 May 2002 16:46:08 -0700 (PDT) From: Dong To: IPsec , Security_Area_Advisory_Group Reply-To: dong_wei@tsinghua.com X-Originating-Ip: [128.235.249.42] Message-Id: <20020523234609.3FA1B2756@sitemail.everyone.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Roy, I just read a paper "Preventing Denial of Service Attacks on Quality of Service", which is written by some guys from N.C. State university and UC Davis. The service quality to legimative users could be degraded by attacks on control flow or data flow. For example, an illegal user can forge a reservation message, so he can receive an unauthorized amount of resources. I just wanna to know what threats exist in providing QoS, and what the state-of-art techniques to prevent, detect and counter those attacks, and of course recovery mothods as well. Thx a lot. Dong Dong, Please be a little more precise in what you are asking for, i.e. 3-5 bullet list items on what kind of security you seek. Roy -----Original Message----- From: Dong [mailto:dong_wei@tsinghua.com] Sent: Thursday, May 23, 2002 2:05 PM To: Security_Area_Advisory_Group; IPsec Subject: Secure QoS Hi, I am trying to do a survey on Secure QoS. Any paper on that? Thx. Dong _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Get Tsinghua University free email account: www.tsinghua.com Web site sponsored and hosted by AtFreeWeb.com _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From owner-ipsec@lists.tislabs.com Thu May 23 18:42:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O1guL20188; Thu, 23 May 2002 18:42:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26558 Thu, 23 May 2002 20:55:51 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Thu May 23 16:53:29 2002 Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200205230724.KAA04639@burp.tkv.asdf.org> References: <200205221623.g4MGN8k09697@trpz.com> <200205230724.KAA04639@burp.tkv.asdf.org> Date: Thu, 23 May 2002 07:16:59 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Specification of tunnel/transport attribute in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:24 AM +0300 5/23/02, Markku Savela wrote: >This is supposed to be technical discussion and I consider a >non-policy checking IKE technically a better solution to the problem. Note, however, that Dan has pointed out with very clear examples why simply moving "policy" from IKE to 2401 will lead to lack of interoperability in implementations. It seems like your proposed new view of 2401 will either: - need some policy negotiation outside of IKE before packets start to flow - need some policy announcement when bad packets are received ("you're sending me packets that I have no intention of passing to the inside network") - cause black holes that cannot be detected Could you say briefly which of the above you are proposing? If it one of the first two, which protocol are you saying would be used? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 23 20:00:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O30EL21699; Thu, 23 May 2002 20:00:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26740 Thu, 23 May 2002 22:13:04 -0400 (EDT) Date: Fri, 24 May 2002 05:26:01 +0300 Message-Id: <200205240226.FAA05371@burp.tkv.asdf.org> From: Markku Savela To: paul.hoffman@vpnc.org CC: ipsec@lists.tislabs.com In-reply-to: (message from Paul Hoffman / VPNC on Thu, 23 May 2002 07:16:59 -0700) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <200205221623.g4MGN8k09697@trpz.com> <200205230724.KAA04639@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Paul Hoffman / VPNC > - need some policy negotiation outside of IKE before packets start > to flow Sort of, administrators of both sides have to agree to allow the packets to flow. Then, both sides modify their policies accordingly. I don't see any need for "policy negotiation protocol" between end hosts. I do see that sometimes a general IPSEC policy exchange format might be a useful thing. A policy described in this notation could be transferred to the users via different methods (email, http, etc). > - need some policy announcement when bad packets are received > ("you're sending me packets that I have no intention of passing to > the inside network") Not policy announcement. Just optional notification from one IKE to another. This would alert the sender that there is "black hole". 1) Sends encodes the packet with SA(s) 2) Receiver successfully decodes the packet with SA(s) 3) Receiver checks that the uncovered plain packet matches the policy (as described in RFC-2401). 4) If packet does not match the policy, then there is a policy mismatch and a potential black hole (or cracking attempt). A notification can be sent to all key management servers. This notice could contain selector data from the packet and SA(s). IKE (or any other key manager) receive this message and from it can deduce whether the problem SA's are negotiated by it. If so, it can use the phase 1 session to pass the appropriate information to the other end. 5) Upon receiving the notification, the sender knows that it's packets are not accepted. Solving the problem requires human intervention. IKE can do above without any knowledge about the actual policy. This way even handles the black holes, that current IKE does not detect: sender sends packets using wrong SA (like, negotiate SA for telnet traffic, but use FTP over it). From owner-ipsec@lists.tislabs.com Thu May 23 23:11:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O6B4L28306; Thu, 23 May 2002 23:11:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA27129 Fri, 24 May 2002 01:12:13 -0400 (EDT) Message-Id: <3.0.3.32.20020523222844.0139a9d8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 23 May 2002 22:28:44 -0700 To: Stephen Kent From: Alex Alten Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:07 AM 5/20/2002 -0400, Stephen Kent wrote: >At 4:38 PM -0700 5/17/02, Alex Alten wrote: >> >> >Alex, >>> >>>I assume you have read the new ESP ID from last fall, as well as the >>>new AH ID from this spring, and have followed the WG discussions of >>>why the SA can be determined by examining just the SPI 9without >>>referebce to the destination address), for unicast traffic. Given >>>that context, I'm not sure I understand your comments above. Could >>>you clarify? >>> >>>Thanks, >>> >>>Steve >>> >> >>Steve, >> >>My comments only apply to the RFCs as they stand today. SPI is a >>different beast than what I'm discussing even with your latest ESP >>ID adjustments. >> >>The fundamental problem is how can we identify a host unambigously in >>real time in order to be able to automate the picking of the correct >>crypto key used to authenticate it and then bootstrap the SA? I don't >>see the answer anywhere in the RFCs or IDs. Certainly there are a lot >>of documents and maybe I've missed seeing it. I know that X.509 certs >>are not the answer (the bound name/address is too static and can be >>unreliable). >> >>- Alex > >if the concern is, as you state above, the initial binding of host ID >to a credential, then an X.509 cert with a name seems to address the >problem, irrespective of a static address binding. IKE provides for >exchange of certs that contains names, e.g., DNS names or DNs, and if >one uses SPD entries with these symbolic names for IP address >selectors, the mapping to current addresses will happen dynamically. > >Steve > Steve, On the surface using a global name space like DNS seems like a good idea. But the fundamental problem is that a DNS name maps to an IP address which is already a slippery beast. Also not every IP address has a corresponding DNS name. And a DNS name can map to multiple IP addresses. So the certificate binding of a DNS name to a Public Key is not a practical approach. A X.500 DN is even worse, except for LDAP trees, it is hardly used. A much better approach is to have a large, global numerical address space. Each host then is assigned a unique security address from this space. IP addresses can flit in and out of existence for a host, but it's security address remains fixed, a least for the duration between enrollment and revocation in an "IPsec global system". If one can reliably assign a unique number to each host, then it can be used to look up the authentication key in a secure database to verify that indeed a particular host is assigned that number. Once you can rely on this number, effectively a global host id, it is much more practical to automate the setting up of a VPN between two hosts, even in the context of Mobile IP or through a NAT or even between two different organizations. It seems to me that until the issue of how to effectively identify hosts and manage the resulting address space is agreed upon all the IKEs and JFKs will be failures. Or at best they will only be a way to automate the key suite negotiation between two hosts (or VPN gateways), thus providing just a modest advantage over the manual keying that dominates IPsec VPN setup today. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri May 24 00:50:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O7oxL17765; Fri, 24 May 2002 00:50:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA27318 Fri, 24 May 2002 02:59:22 -0400 (EDT) Date: Fri, 24 May 2002 00:11:10 -0700 (PDT) From: Jan Vilhuber To: Markku Savela cc: , Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: <200205240226.FAA05371@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sure sounds like an administrative nightmare (as well as wasted bandwidth) to me, when we could simply do it via negotiation in an automated fashion. jan On Fri, 24 May 2002, Markku Savela wrote: > > From: Paul Hoffman / VPNC > > > - need some policy negotiation outside of IKE before packets start > > to flow > > Sort of, administrators of both sides have to agree to allow the > packets to flow. Then, both sides modify their policies accordingly. I > don't see any need for "policy negotiation protocol" between end > hosts. > > I do see that sometimes a general IPSEC policy exchange format > might be a useful thing. A policy described in this notation could be > transferred to the users via different methods (email, http, etc). > > > - need some policy announcement when bad packets are received > > ("you're sending me packets that I have no intention of passing to > > the inside network") > > Not policy announcement. Just optional notification from one IKE to > another. This would alert the sender that there is "black hole". > > 1) Sends encodes the packet with SA(s) > > 2) Receiver successfully decodes the packet with SA(s) > > 3) Receiver checks that the uncovered plain packet matches the policy > (as described in RFC-2401). > > 4) If packet does not match the policy, then there is a policy > mismatch and a potential black hole (or cracking attempt). A > notification can be sent to all key management servers. This notice > could contain selector data from the packet and SA(s). IKE (or any > other key manager) receive this message and from it can deduce > whether the problem SA's are negotiated by it. If so, it can use > the phase 1 session to pass the appropriate information to the > other end. > > 5) Upon receiving the notification, the sender knows that it's packets > are not accepted. Solving the problem requires human > intervention. > > IKE can do above without any knowledge about the actual policy. > > This way even handles the black holes, that current IKE does not > detect: sender sends packets using wrong SA (like, negotiate SA for > telnet traffic, but use FTP over it). > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Fri May 24 06:30:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ODUtL10940; Fri, 24 May 2002 06:30:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27938 Fri, 24 May 2002 08:42:51 -0400 (EDT) Message-ID: <3CED779D.50203@netscape.net> Date: Thu, 23 May 2002 23:13:33 +0000 From: Marc Solsona User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0rc2) Gecko/20020513 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela CC: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: <200205221623.g4MGN8k09697@trpz.com> <200205230724.KAA04639@burp.tkv.asdf.org> <200205240226.FAA05371@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It wouldn't hurt to thing in terms of large scale deployments. Try to be in the shoes of the administrator that is taking care of a mid size ISP. The scenario could look like several VPNs per customer, hundreds of customers (hopefully), probably each customer using an independent box. I don't mean that what it is being discussed is wrong, but I would like to bring this up. If the complexity is in the protocol, vendors try to make it easier in their implementations. Some get it right some don't. My 2c. marc. Markku Savela wrote: >>From: Paul Hoffman / VPNC >> >> > > > >>- need some policy negotiation outside of IKE before packets start >>to flow >> >> > >Sort of, administrators of both sides have to agree to allow the >packets to flow. Then, both sides modify their policies accordingly. I >don't see any need for "policy negotiation protocol" between end >hosts. > >I do see that sometimes a general IPSEC policy exchange format >might be a useful thing. A policy described in this notation could be >transferred to the users via different methods (email, http, etc). > > > >>- need some policy announcement when bad packets are received >>("you're sending me packets that I have no intention of passing to >>the inside network") >> >> > >Not policy announcement. Just optional notification from one IKE to >another. This would alert the sender that there is "black hole". > >1) Sends encodes the packet with SA(s) > >2) Receiver successfully decodes the packet with SA(s) > >3) Receiver checks that the uncovered plain packet matches the policy > (as described in RFC-2401). > >4) If packet does not match the policy, then there is a policy > mismatch and a potential black hole (or cracking attempt). A > notification can be sent to all key management servers. This notice > could contain selector data from the packet and SA(s). IKE (or any > other key manager) receive this message and from it can deduce > whether the problem SA's are negotiated by it. If so, it can use > the phase 1 session to pass the appropriate information to the > other end. > >5) Upon receiving the notification, the sender knows that it's packets > are not accepted. Solving the problem requires human > intervention. > >IKE can do above without any knowledge about the actual policy. > >This way even handles the black holes, that current IKE does not >detect: sender sends packets using wrong SA (like, negotiate SA for >telnet traffic, but use FTP over it). > > > -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ From owner-ipsec@lists.tislabs.com Fri May 24 06:30:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ODUuL10942; Fri, 24 May 2002 06:30:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27939 Fri, 24 May 2002 08:42:50 -0400 (EDT) Message-ID: <3CED86D4.116A78F4@cs.ucdavis.edu> Date: Thu, 23 May 2002 17:18:28 -0700 From: "S. Felix Wu" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: dong_wei@tsinghua.com CC: IPsec , Security_Area_Advisory_Group Subject: Re: References: <20020523234609.3FA1B2756@sitemail.everyone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am a co-author of the paper you mentioned. I feel that the subject of Secure QoS (or QoS security) is not very related to the core interest of the IPsec working group. (maybe more related to DiffServ.) In the ArQos project (http://arqos.csc.ncsu.edu), we are concerning attackers stealing the bandwidth, one way or the other (i.e, via control plane or data plane). Publications can be found there. However, DoS concern for IKE (or IKEv2 and JFK) might be relevent for this working group as many messages have been posted here lately. -Felix Dong wrote: > > Roy, > > I just read a paper "Preventing Denial of Service Attacks on Quality of Service", which is written by some guys from N.C. State university and UC Davis. The service quality to legimative users could be degraded by attacks on control flow or data flow. For example, an illegal user can forge a reservation message, so he can receive an unauthorized amount of resources. I just wanna to know what threats exist in providing QoS, and what the state-of-art techniques to prevent, detect and counter those attacks, and of course recovery mothods as well. > > Thx a lot. > > Dong > > Dong, > Please be a little more precise in what you are asking for, i.e. > > 3-5 bullet list items on what kind of security you seek. > > Roy > > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 2:05 PM > To: Security_Area_Advisory_Group; IPsec > Subject: Secure QoS > > Hi, > > I am trying to do a survey on Secure QoS. Any paper on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri May 24 07:59:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OEx9L16386; Fri, 24 May 2002 07:59:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28175 Fri, 24 May 2002 10:15:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.20020523222844.0139a9d8@mail> References: <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> Date: Fri, 24 May 2002 10:24:46 -0400 To: Alex Alten From: Stephen Kent Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, >Steve, > >On the surface using a global name space like DNS seems like a good >idea. But the fundamental problem is that a DNS name maps to an IP >address which is already a slippery beast. Also not every IP address >has a corresponding DNS name. And a DNS name can map to multiple IP >addresses. So the certificate binding of a DNS name to a Public Key is >not a practical approach. A X.500 DN is even worse, except for LDAP >trees, it is hardly used. In IKE, the mapping between any symbolic name and an IP address is dynamic, so when this sort of symbolic name use is appropriate for locally administered access control (via the SPD), the problems your cite here do not seem to arise. >A much better approach is to have a large, global numerical address space. >Each host then is assigned a unique security address from this space. IP >addresses can flit in and out of existence for a host, but it's security >address remains fixed, a least for the duration between enrollment and >revocation in an "IPsec global system". If one can reliably assign a >unique number to each host, then it can be used to look up the authentication >key in a secure database to verify that indeed a particular host is assigned >that number. Once you can rely on this number, effectively a global host id, >it is much more practical to automate the setting up of a VPN between two >hosts, even in the context of Mobile IP or through a NAT or even between two >different organizations. I disagree. Experience has shown that access control systems are very much prone to human error when new forms of ID are introduced that are not readily understood by the people managing these systems. We are comfortable with DNS names, so DNS names are appropriate here. DNs are more descriptive in some contexts, and some people are comfortable with them, so they are appropriate in some contexts as well. A new set of globally unique, numerical IDs will be alien to everyone and will require mapping to some form of name that people do relate to, and the creation of that mapping will introduce errors. >It seems to me that until the issue of how to effectively identify hosts and >manage the resulting address space is agreed upon all the IKEs and JFKs >will be failures. Or at best they will only be a way to automate the key >suite >negotiation between two hosts (or VPN gateways), thus providing just a modest >advantage over the manual keying that dominates IPsec VPN setup today. I don't see your point. End users and system administrators already make use of the DNS to identify the vast majority of hosts, because this is the way that we refer to these hosts in our applications. Thus it makes sense to retain that way of identifying hosts in access control systems, to minimize confusion. Steve From owner-ipsec@lists.tislabs.com Fri May 24 08:00:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OF0tL16530; Fri, 24 May 2002 08:00:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28223 Fri, 24 May 2002 10:24:38 -0400 (EDT) Message-ID: <20020524143641.97990.qmail@web21302.mail.yahoo.com> Date: Fri, 24 May 2002 07:36:41 -0700 (PDT) From: SatishK Amara Subject: Re: To: dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group In-Reply-To: <20020523234609.3FA1B2756@sitemail.everyone.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why don't you use IPSEC to secure RSVP. Satish Amara --- Dong wrote: > Roy, > > I just read a paper "Preventing Denial of Service > Attacks on Quality of Service", which is written by > some guys from N.C. State university and UC Davis. > The service quality to legimative users could be > degraded by attacks on control flow or data flow. > For example, an illegal user can forge a reservation > message, so he can receive an unauthorized amount of > resources. I just wanna to know what threats exist > in providing QoS, and what the state-of-art > techniques to prevent, detect and counter those > attacks, and of course recovery mothods as well. > > Thx a lot. > > Dong > > > Dong, > Please be a little more precise in what you are > asking for, i.e. > > 3-5 bullet list items on what kind of security you > seek. > > Roy > > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 2:05 PM > To: Security_Area_Advisory_Group; IPsec > Subject: Secure QoS > > > Hi, > > I am trying to do a survey on Secure QoS. Any paper > on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: > www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > > > _____________________________________________________________ > Get Tsinghua University free email account: > www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your > members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag ===== In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ipsec@lists.tislabs.com Fri May 24 09:05:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OG54L19293; Fri, 24 May 2002 09:05:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28386 Fri, 24 May 2002 11:19:54 -0400 (EDT) Date: Fri, 24 May 2002 18:32:00 +0300 Message-Id: <200205241532.SAA06102@burp.tkv.asdf.org> From: Markku Savela To: vilhuber@cisco.com CC: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com In-reply-to: (message from Jan Vilhuber on Fri, 24 May 2002 00:11:10 -0700 (PDT)) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Jan Vilhuber > > Sure sounds like an administrative nightmare (as well as wasted > bandwidth) to me, when we could simply do it via negotiation in an > automated fashion. I assume you must be referring to the policy maintenance, because there is nothing "administrative" in my proposed "policy mismatch notification". As to policy, you *cannot* negotiate it automaticly. What use is a policy which can be automaticly modified by at will? If I have a policy - allow HTTP traffic to my WEB server using IPSEC - drop other Surely you don't want anyone "negotiating" this into - allow HTTP traffic to my WEB server using IPSEC - allow ANY with NUL ESP - drop other So, I assume when you are talking about "negotiating policy", it is something which I don't consider as a part of policy? As I have said earlier, I have no problem allowing choices in SA algorithm. If desired, the policy just lists the allowed alternatives and IKE can pick one which is common. (If you are using PFKEY, then just look at ACQUIRE message: it has list of alternatives). . From owner-ipsec@lists.tislabs.com Fri May 24 09:59:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OGxRL21546; Fri, 24 May 2002 09:59:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28474 Fri, 24 May 2002 12:19:13 -0400 (EDT) Date: Fri, 24 May 2002 09:30:45 -0700 (PDT) From: Jan Vilhuber To: Markku Savela cc: , Subject: Re: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: <200205241532.SAA06102@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 24 May 2002, Markku Savela wrote: > > From: Jan Vilhuber > > > > Sure sounds like an administrative nightmare (as well as wasted > > bandwidth) to me, when we could simply do it via negotiation in an > > automated fashion. > > I assume you must be referring to the policy maintenance, because > there is nothing "administrative" in my proposed "policy mismatch > notification". > > As to policy, you *cannot* negotiate it automaticly. Maybe, but in the interest of maintaining a properly functioning network and being able to troubleshoot it (and interoperate between vendors), this negotiation is somewhat important (critical in my mind). Yea... we COULD configure everything manually. Good luck. jan > What use is a policy > which can be automaticly modified by at will? > > If I have a policy > > - allow HTTP traffic to my WEB server using IPSEC > - drop other > > Surely you don't want anyone "negotiating" this into > > - allow HTTP traffic to my WEB server using IPSEC > - allow ANY with NUL ESP > - drop other > > So, I assume when you are talking about "negotiating policy", it is > something which I don't consider as a part of policy? As I have said > earlier, I have no problem allowing choices in SA algorithm. If > desired, the policy just lists the allowed alternatives and IKE can > pick one which is common. (If you are using PFKEY, then just look at > ACQUIRE message: it has list of alternatives). > > > > . > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Fri May 24 12:19:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJJAL24538; Fri, 24 May 2002 12:19:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28687 Fri, 24 May 2002 14:35:30 -0400 (EDT) Reply-To: From: "Jeremy Rodriguez" To: Subject: remove jrodriguez@intellinet-tech.com Date: Fri, 24 May 2002 14:49:43 -0400 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: 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 Jan Vilhuber Sent: Friday, May 24, 2002 12:31 PM To: Markku Savela Cc: paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 On Fri, 24 May 2002, Markku Savela wrote: > > From: Jan Vilhuber > > > > Sure sounds like an administrative nightmare (as well as wasted > > bandwidth) to me, when we could simply do it via negotiation in an > > automated fashion. > > I assume you must be referring to the policy maintenance, because > there is nothing "administrative" in my proposed "policy mismatch > notification". > > As to policy, you *cannot* negotiate it automaticly. Maybe, but in the interest of maintaining a properly functioning network and being able to troubleshoot it (and interoperate between vendors), this negotiation is somewhat important (critical in my mind). Yea... we COULD configure everything manually. Good luck. jan > What use is a policy > which can be automaticly modified by at will? > > If I have a policy > > - allow HTTP traffic to my WEB server using IPSEC > - drop other > > Surely you don't want anyone "negotiating" this into > > - allow HTTP traffic to my WEB server using IPSEC > - allow ANY with NUL ESP > - drop other > > So, I assume when you are talking about "negotiating policy", it is > something which I don't consider as a part of policy? As I have said > earlier, I have no problem allowing choices in SA algorithm. If > desired, the policy just lists the allowed alternatives and IKE can > pick one which is common. (If you are using PFKEY, then just look at > ACQUIRE message: it has list of alternatives). > > > > . > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Fri May 24 16:00:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ON0hL28585; Fri, 24 May 2002 16:00:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29001 Fri, 24 May 2002 18:17:21 -0400 (EDT) From: "Hilarie Orman, Purple Streak Development" To: ipsec@lists.tislabs.com In-reply-to: Yourmessage <15597.22768.322645.225267@ryijy.hel.fi.ssh.com> Subject: RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt Message-Id: Date: Fri, 24 May 2002 16:30:03 -0600 X-Spam-Status: No, hits=-4.4 required=8.0 tests=IN_REP_TO version=2.20 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can't see any reason to use groups for which the discrete log problem is harder than 128 bits. Even that is a stretch and you'd have to go to some trouble to justify it. This blind matching of keysizes is ridiculous. Key length should not be equated with security requirement. Hilarie From owner-ipsec@lists.tislabs.com Fri May 24 17:10:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4P0ALL00307; Fri, 24 May 2002 17:10:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29062 Fri, 24 May 2002 19:28:31 -0400 (EDT) Message-Id: <3.0.3.32.20020524164356.01289ba0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 24 May 2002 16:43:56 -0700 To: Stephen Kent From: Alex Alten Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I'm not talking about a host's local database. We need a way to uniquely AND SECURELY identify any host worldwide from any other host. You don't want to replicate this information to every host, you'd have over 100 million entries to distribute to each one! I like DNS too, a nice simple hierarchy, it is easy to uniquely name hosts, and a simple distributed model for managing the address space. But it has a crippling drawback from a security perspective. A DNS name cannot be any better at identifying a host than it's resolved IP address. And we know how ephemeral IP addresses can be given the rise of DHCP and NAT. The only secure way to absolutely identify a host is to assign it a (randomly) unique crypto key. But before you can pull the correct key (RSA or AES) you need to find it. For this you need a unique number that doesn't keep being changed underneath you. So unfortunately DNS doesn't make the cut. No amount of wishful thinking is going to make it work properly for us. To reiterate my position: IPsec needs to have a global, secure address space that uniquely identifies every participating host. It needs to be simple to understand, distributable, and easy to manage. And it needs to be able to dynamically map into the IP address space on demand, including private network non-routable addresses. That's the requirements as I see them. Anything less than this means you can't use IPsec unencumbered across the Internet. - Alex At 10:24 AM 5/24/2002 -0400, Stephen Kent wrote: >Alex, > >>Steve, >> >>On the surface using a global name space like DNS seems like a good >>idea. But the fundamental problem is that a DNS name maps to an IP >>address which is already a slippery beast. Also not every IP address >>has a corresponding DNS name. And a DNS name can map to multiple IP >>addresses. So the certificate binding of a DNS name to a Public Key is >>not a practical approach. A X.500 DN is even worse, except for LDAP >>trees, it is hardly used. > >In IKE, the mapping between any symbolic name and an IP address is >dynamic, so when this sort of symbolic name use is appropriate for >locally administered access control (via the SPD), the problems your >cite here do not seem to arise. > >>A much better approach is to have a large, global numerical address space. >>Each host then is assigned a unique security address from this space. IP >>addresses can flit in and out of existence for a host, but it's security >>address remains fixed, a least for the duration between enrollment and >>revocation in an "IPsec global system". If one can reliably assign a >>unique number to each host, then it can be used to look up the authentication >>key in a secure database to verify that indeed a particular host is assigned >>that number. Once you can rely on this number, effectively a global host id, >>it is much more practical to automate the setting up of a VPN between two >>hosts, even in the context of Mobile IP or through a NAT or even between two >>different organizations. > >I disagree. Experience has shown that access control systems are very >much prone to human error when new forms of ID are introduced that >are not readily understood by the people managing these systems. We >are comfortable with DNS names, so DNS names are appropriate here. >DNs are more descriptive in some contexts, and some people are >comfortable with them, so they are appropriate in some contexts as >well. A new set of globally unique, numerical IDs will be alien to >everyone and will require mapping to some form of name that people do >relate to, and the creation of that mapping will introduce errors. > >>It seems to me that until the issue of how to effectively identify hosts and >>manage the resulting address space is agreed upon all the IKEs and JFKs >>will be failures. Or at best they will only be a way to automate the key >>suite >>negotiation between two hosts (or VPN gateways), thus providing just a modest >>advantage over the manual keying that dominates IPsec VPN setup today. > >I don't see your point. End users and system administrators already >make use of the DNS to identify the vast majority of hosts, because >this is the way that we refer to these hosts in our applications. >Thus it makes sense to retain that way of identifying hosts in access >control systems, to minimize confusion. > >Steve > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri May 24 20:27:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4P3R0L03719; Fri, 24 May 2002 20:27:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29326 Fri, 24 May 2002 22:41:43 -0400 (EDT) Date: Sat, 25 May 2002 05:54:06 +0300 Message-Id: <200205250254.FAA06547@burp.tkv.asdf.org> From: Markku Savela To: vilhuber@cisco.com CC: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com In-reply-to: (message from Jan Vilhuber on Fri, 24 May 2002 09:30:45 -0700 (PDT)) Subject: Re: Specification of tunnel/transport attribute in IKEv2 References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Jan Vilhuber > Maybe, but in the interest of maintaining a properly functioning > network and being able to troubleshoot it (and interoperate between > vendors), this negotiation is somewhat important (critical in my > mind). > > Yea... we COULD configure everything manually. Good luck. Well, we all need good luck in that case. There is no policy negotiation in the current IKE either. Note however, that my proposal is: - in phase II, only SA's are negotiated, without policy checks I have no objections, if IKE or something installs or removes additional policy lines in PHASE 1, after the user has been authenticated. Thus, a policy could initially be - drop all and there would some local database of users that can establish VPN or some other access, for example joe -> setup VPN bob -> allow HTTP with ESP alice -> setup VPN so when joe connects from 172.2.1.1 and authenticates itself as joe, then IKE or something could add a policy line and result would be remote 172.2.1.1 -> protect via 172.2.1.11 drop all Similarly, if bob connects from 172.2.1.2, the policy is again augmented remote 172.2.1.1 -> protect via 172.2.1.1 remote 172.2.1.2 local-port 80 -> use ESP drop all Note, the policies must still be locally configured. It is a security breach, if other end can define the policy lines. From owner-ipsec@lists.tislabs.com Fri May 24 20:31:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4P3V6L03792; Fri, 24 May 2002 20:31:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29356 Fri, 24 May 2002 22:50:42 -0400 (EDT) To: SatishK Amara Cc: dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group Subject: Re: References: <20020524143641.97990.qmail@web21302.mail.yahoo.com> From: Derek Atkins Date: 24 May 2002 23:00:52 -0400 In-Reply-To: <20020524143641.97990.qmail@web21302.mail.yahoo.com> Message-ID: Lines: 86 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 Because IPsec is hop-by-hop but you want RSVP end-to-end. -derek SatishK Amara writes: > Why don't you use IPSEC to secure RSVP. > > Satish Amara > --- Dong wrote: > > Roy, > > > > I just read a paper "Preventing Denial of Service > > Attacks on Quality of Service", which is written by > > some guys from N.C. State university and UC Davis. > > The service quality to legimative users could be > > degraded by attacks on control flow or data flow. > > For example, an illegal user can forge a reservation > > message, so he can receive an unauthorized amount of > > resources. I just wanna to know what threats exist > > in providing QoS, and what the state-of-art > > techniques to prevent, detect and counter those > > attacks, and of course recovery mothods as well. > > > > Thx a lot. > > > > Dong > > > > > > Dong, > > Please be a little more precise in what you are > > asking for, i.e. > > > > 3-5 bullet list items on what kind of security you > > seek. > > > > Roy > > > > -----Original Message----- > > From: Dong [mailto:dong_wei@tsinghua.com] > > Sent: Thursday, May 23, 2002 2:05 PM > > To: Security_Area_Advisory_Group; IPsec > > Subject: Secure QoS > > > > > > Hi, > > > > I am trying to do a survey on Secure QoS. Any paper > > on that? Thx. > > > > Dong > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > _____________________________________________________________ > > Promote your group and strengthen ties to your > > members with email@yourgroup.org by Everyone.net > http://www.everyone.net/?btn=tag > > > ===== > In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Sat May 25 08:51:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4PFp7L27249; Sat, 25 May 2002 08:51:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00615 Sat, 25 May 2002 11:00:50 -0400 (EDT) Message-Id: <5.1.0.14.0.20020525111240.00ac5c40@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 25 May 2002 11:17:54 -0400 To: RJ Atkinson , Derek Atkins From: Melinda Shore Subject: Re: [saag] Re: Cc: SatishK Amara , dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group In-Reply-To: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: >Hmm. I would rather say that RSVP is hop-by-hop and >that (normally) AH/ESP are end-to-end. In terms of addressing, RSVP is end-to-end in one direction (sender->receiver) and hop-by-hop in the other (receiver->sender). >However, if one used (for example) AH with an asymmetric algorithm, >one could perform hop-by-hop authentication of the >packet with AH. This has obvious computational cost >issues so might not be the best choice. The packet payload is going to be modified at each hop, as well, in both directions. Melinda From owner-ipsec@lists.tislabs.com Mon May 27 03:27:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RARfJ29312; Mon, 27 May 2002 03:27:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA04373 Mon, 27 May 2002 05:21:06 -0400 (EDT) Message-ID: <3CF1FD39.DBCC3653@ccs.bbk.ac.uk> Date: Mon, 27 May 2002 10:32:41 +0100 From: Ken Brown Reply-To: k.brown@ccs.bbk.ac.uk Organization: Birkbeck College Central Computing Services X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Alten CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 References: <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten wrote: [...snip...] > To reiterate my position: IPsec needs to have a global, secure address space > that uniquely identifies every participating host. It needs to be simple to > understand, distributable, and easy to manage. And it needs to be able to > dynamically map into the IP address space on demand, including private > network non-routable addresses. > > That's the requirements as I see them. Anything less than this means > you can't use IPsec unencumbered across the Internet. The trouble is that potentially any device is an IPsec host (or should that be ("any device is potentially an IPsec host"?). So you need a scheme for naming everything. Which is a much bigger job than defining IPsec protocols, and has been tried a number of times, littering standard space with documents mostly beginning with "X." - using the least bad existing system (whichever it happens to be) is almost certainly going to be more feasible than devising and managing your own - let alone persuading the entire world to use it. It's not as if such a thing can be invisibly built in to software that implements the protocol - you have to have a way of issuing names, controlling their use, and making sure the naming system itself is both robust and is reliable. That's going to mean some central registry and a global network of keyservers or nameservers (even if they aren't called that). We can get away with a global namespace of, say, MAC addresses, hardwired into devices or assigned locally by software, because we don't /really/ care if someone doesn't play ball - as long as they remain on their own networks that's their problem. (well ,except for edge routers, but you see what I mean). It doesn't really have to secure or global (though it is a bit easier if it is global). The IP namespace gets a lot more political and centralised, and the DNS even more political, because decentralised. And your system - in which everything has to be both globally unique /and/ secure, /and/ participating devices have to be able to find out each others names anywhere in the world - is also going to be complex and political. Of course it might be that the statement "you can't use IPsec unencumbered across the Internet" is going to be true. Ken Brown Birkbeck College, London University From owner-ipsec@lists.tislabs.com Mon May 27 23:04:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4S64wJ08644; Mon, 27 May 2002 23:04:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05910 Tue, 28 May 2002 01:12:16 -0400 (EDT) Message-Id: <3.0.3.32.20020527222820.0135e9e8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 27 May 2002 22:28:20 -0700 To: k.brown@ccs.bbk.ac.uk From: Alex Alten Subject: Re: addresses and IKEv2 Cc: Stephen Kent , ipsec@lists.tislabs.com In-Reply-To: <3CF1FD39.DBCC3653@ccs.bbk.ac.uk> References: <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ken, I appreciate your insightful remarks below. You have "hit the nail on the head" as we say on this side of the Atlantic. In fact your remarks contain the nuggets of the solution, which as you have correctly pointed out, will be both technical and political in nature. My comments in response to yours are interspersed with yours below. Sincerely, - Alex At 10:32 AM 5/27/2002 +0100, Ken Brown wrote: >Alex Alten wrote: > >[...snip...] > >> To reiterate my position: IPsec needs to have a global, secure address space >> that uniquely identifies every participating host. It needs to be simple to >> understand, distributable, and easy to manage. And it needs to be able to >> dynamically map into the IP address space on demand, including private >> network non-routable addresses. >> >> That's the requirements as I see them. Anything less than this means >> you can't use IPsec unencumbered across the Internet. > > >The trouble is that potentially any device is an IPsec host (or should >that be ("any device is potentially an IPsec host"?). So you need a >scheme for naming everything. Which is a much bigger job than defining >IPsec protocols, and has been tried a number of times, littering >standard space with documents mostly beginning with "X." - using the >least bad existing system (whichever it happens to be) is almost >certainly going to be more feasible than devising and managing your own >- let alone persuading the entire world to use it. It's not as if such a >thing can be invisibly built in to software that implements the protocol >- you have to have a way of issuing names, controlling their use, and >making sure the naming system itself is both robust and is reliable. >That's going to mean some central registry and a global network of >keyservers or nameservers (even if they aren't called that). > I absolutely agree with this above paragraph. I wish we could use an existing standard, but unfortunately the successful ones require that all the participants are to be trustworthy and will follow the rules. This cannot be the basis of our address system, unfortunately we must assume that a significant number of hosts will be untrustworthy (not to mention the different policies of each organization that must be enforced separately). And yes, this probably means a set of key servers, probably one per organization, across the Internet. At first a central (trusted) registry may not be required, but once trusted organization networks start linking up in great numbers then one, or a limited number, would be needed. >We can get away with a global namespace of, say, MAC addresses, >hardwired into devices or assigned locally by software, because we don't >/really/ care if someone doesn't play ball - as long as they remain on >their own networks that's their problem. (well ,except for edge routers, >but you see what I mean). It doesn't really have to secure or global >(though it is a bit easier if it is global). The IP namespace gets a >lot more political and centralised, and the DNS even more political, >because decentralised. And your system - in which everything has to be >both globally unique /and/ secure, /and/ participating devices have to >be able to find out each others names anywhere in the world - is also >going to be complex and political. > Yes, I'm afraid you are absolutely right. Technically I'm absolutely certain we could come up with a very good model (you're right it doesn't have to be secure or global, but it can't be as transient as IP addresses), but then how to handle the politics of assigning blocks of addresses (or whatever) will be a serious challenge. Also, especially in light of Sept. 11th, we will need be very careful about how we handle key distribution and escrow. The days of when a few long haired guys with PhD's here in the US could quietly do things are long gone. >Of course it might be that the statement "you can't use IPsec >unencumbered across the Internet" is going to be true. > Which might not be such a bad thing in my mind. I've not been happy with the rest of the IPsec design, which I've documented thoroughly in prior postings to this WG. I wouldn't mind seeing a fresh start with a clean sheet of paper (and with a lot fewer people involved). I'll probably get publicly flamed for these comments, right Dan? >Ken Brown >Birkbeck College, London University > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Tue May 28 06:38:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SDcTJ24331; Tue, 28 May 2002 06:38:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06793 Tue, 28 May 2002 08:42:59 -0400 (EDT) Date: Sat, 25 May 2002 10:53:22 -0400 Subject: Re: [saag] Re: Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: SatishK Amara , dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group To: Derek Atkins From: RJ Atkinson In-Reply-To: Message-Id: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Friday, May 24, 2002, at 11:00 , Derek Atkins wrote: > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > -derek Hmm. I would rather say that RSVP is hop-by-hop and that (normally) AH/ESP are end-to-end. However, if one used (for example) AH with an asymmetric algorithm, one could perform hop-by-hop authentication of the packet with AH. This has obvious computational cost issues so might not be the best choice. > SatishK Amara writes: > >> Why don't you use IPSEC to secure RSVP. >> >> Satish Amara From owner-ipsec@lists.tislabs.com Wed May 29 07:21:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TELHJ05327; Wed, 29 May 2002 07:21:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11317 Wed, 29 May 2002 09:41:26 -0400 (EDT) From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 15:59:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020529094532.00ab6b90@localhost> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi > > > At 03:43 PM 5/29/02 +0200, Hannes Tschofenig wrote: > >rsvp travels hop-by-hop (rsvp capable nodes) from one end-point > to an other > >(except if you use some rsvp extensions like rsvp proxy etc.). > hence "RSVP > >is end-to-end in one direction (sender->receiver)" confuses me > somehow. the > >security for rsvp is build on hop-by-hop security based on a > chain-of-trust. > > In the sender->receiver direction, the destination IP address > in the Path message is the receiver's. In the receiver-> > sender direction, the destination IP address in the Resv message > is the address of the PHOP that was picked up by the Path > message. true. the path message is used for path-pinning to allow the resv message to travel the same way back. but this is not related to the question of end-to-end or hop-by-hop protection. both messages travel hop-by-hop. do you think that the hop-by-hop security in rsvp is a good or a bad thing? should there be more than what is currently provided? ciao hannes > > Melinda From owner-ipsec@lists.tislabs.com Wed May 29 07:22:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEMVJ05768; Wed, 29 May 2002 07:22:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11243 Wed, 29 May 2002 09:31:21 -0400 (EDT) Message-Id: <5.1.0.14.0.20020529094532.00ab6b90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 09:48:37 -0400 To: "Hannes Tschofenig" From: Melinda Shore Subject: RE: [saag] Re: Cc: "IPsec" , "Security_Area_Advisory_Group" In-Reply-To: References: <5.1.0.14.0.20020525111240.00ac5c40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:43 PM 5/29/02 +0200, Hannes Tschofenig wrote: >rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other >(except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP >is end-to-end in one direction (sender->receiver)" confuses me somehow. the >security for rsvp is build on hop-by-hop security based on a chain-of-trust. In the sender->receiver direction, the destination IP address in the Path message is the receiver's. In the receiver-> sender direction, the destination IP address in the Resv message is the address of the PHOP that was picked up by the Path message. Melinda From owner-ipsec@lists.tislabs.com Wed May 29 07:22:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEMWJ05775; Wed, 29 May 2002 07:22:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11209 Wed, 29 May 2002 09:26:23 -0400 (EDT) From: "Hannes Tschofenig" To: "Melinda Shore" , "RJ Atkinson" , "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 15:43:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020525111240.00ac5c40@localhost> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi what do you mean by "in terms of addressing"? my understanding of rsvp is: rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other (except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP is end-to-end in one direction (sender->receiver)" confuses me somehow. the security for rsvp is build on hop-by-hop security based on a chain-of-trust. ciao hannes > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore > Sent: Saturday, May 25, 2002 5:18 PM > To: RJ Atkinson; Derek Atkins > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec; > Security_Area_Advisory_Group > Subject: Re: [saag] Re: > > > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: > >Hmm. I would rather say that RSVP is hop-by-hop and > >that (normally) AH/ESP are end-to-end. > > In terms of addressing, RSVP is end-to-end in one > direction (sender->receiver) and hop-by-hop in the > other (receiver->sender). > > >However, if one used (for example) AH with an asymmetric algorithm, > >one could perform hop-by-hop authentication of the > >packet with AH. This has obvious computational cost > >issues so might not be the best choice. > > The packet payload is going to be modified at each hop, > as well, in both directions. > > Melinda From owner-ipsec@lists.tislabs.com Wed May 29 07:22:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEMkJ05867; Wed, 29 May 2002 07:22:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11316 Wed, 29 May 2002 09:41:25 -0400 (EDT) From: "Hannes Tschofenig" To: "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: IPsec and RSVP Date: Wed, 29 May 2002 15:59:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi > > "Hannes Tschofenig" writes: > > > hi > > > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > > capable router)? > > You lose the authentication of the end-point requesting the > reservation. rsvp does not provide this property. there is no end-to-end authentication (if i understood you correctly). > If you use ipsec in this way, then each router > knows its peer, but you have no transitive authentication. usually you would like to use the chain-of-trust principal, which means that it is as good as the weakest link. > The only protection you get is protection of on-the-wire > request. true. you protect along an unknown number of non-rsvp capable routers. > You have no protection against a corrupt router > along the path, or indeed no way to know what the actual > original request was. there is no protection against corrupt routers in rsvp. who do you want to know where the original request came from? (the end-point?, networks in between, or all nodes in between?) in rsvp you have no separation of mutable and non-mutable fields and since rsvp router may modify or add something to the message it is difficult (not possible) to use end-to-end security. do you think there is a strong need to provide end-to-end security in rsvp? ciao hannes > > > ciao > > hannes > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed May 29 07:23:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TENPJ06083; Wed, 29 May 2002 07:23:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11211 Wed, 29 May 2002 09:26:26 -0400 (EDT) From: "Hannes Tschofenig" To: "RJ Atkinson" , "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 15:43:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi > > On Friday, May 24, 2002, at 11:00 , Derek Atkins wrote: > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > > > -derek > > Hmm. I would rather say that RSVP is hop-by-hop and > that (normally) AH/ESP are end-to-end. but no one prevents you from using ipsec ah/esp in a hop-by-hop mode for protecting rsvp. > > However, if one used (for example) AH with an asymmetric algorithm, > one could perform hop-by-hop authentication of the > packet with AH. what do you mean by "AH with an asymmetric algorithm" ? IKE with an asymmetric authentiction mode? > This has obvious computational cost > issues so might not be the best choice. ciao hannes > > > SatishK Amara writes: > > > >> Why don't you use IPSEC to secure RSVP. > >> > >> Satish Amara From owner-ipsec@lists.tislabs.com Wed May 29 07:23:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TENhJ06204; Wed, 29 May 2002 07:23:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11249 Wed, 29 May 2002 09:33:21 -0400 (EDT) To: "Hannes Tschofenig" Cc: "Melinda Shore" , "RJ Atkinson" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" From: Derek Atkins Subject: Re: [saag] Re: IPsec and RSVP References: Date: 29 May 2002 09:45:33 -0400 In-Reply-To: Message-ID: Lines: 57 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 And we're saying that this chain-of-trust is a bad model, because anyone close to an edge can inject any amount of bogus data into the network. Once it's injected, it's even TRUSTED! One major problem is that you lose the origin of the request after the first hop, not to mention the actual request itself. -derek "Hannes Tschofenig" writes: > hi > > what do you mean by "in terms of addressing"? > > my understanding of rsvp is: > rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other > (except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP > is end-to-end in one direction (sender->receiver)" confuses me somehow. the > security for rsvp is build on hop-by-hop security based on a chain-of-trust. > > ciao > hannes > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore > > Sent: Saturday, May 25, 2002 5:18 PM > > To: RJ Atkinson; Derek Atkins > > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec; > > Security_Area_Advisory_Group > > Subject: Re: [saag] Re: > > > > > > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: > > >Hmm. I would rather say that RSVP is hop-by-hop and > > >that (normally) AH/ESP are end-to-end. > > > > In terms of addressing, RSVP is end-to-end in one > > direction (sender->receiver) and hop-by-hop in the > > other (receiver->sender). > > > > >However, if one used (for example) AH with an asymmetric algorithm, > > >one could perform hop-by-hop authentication of the > > >packet with AH. This has obvious computational cost > > >issues so might not be the best choice. > > > > The packet payload is going to be modified at each hop, > > as well, in both directions. > > > > Melinda > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed May 29 07:26:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEQDJ07729; Wed, 29 May 2002 07:26:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11336 Wed, 29 May 2002 09:47:25 -0400 (EDT) From: "Hannes Tschofenig" To: "Derek Atkins" Cc: "Melinda Shore" , "RJ Atkinson" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: IPsec and RSVP Date: Wed, 29 May 2002 16:04:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi > > > And we're saying that this chain-of-trust is a bad model, because > anyone close to an edge can inject any amount of bogus data into the > network. you have to differentiate between data traffic and signaling traffic. if you change the chain-of-trust model and require end-to-end nature than this implies that you don't want any router to modify rsvp message (adding something etc.). this is possible by introducing mutable and non-mutable fields and protecting the non-mutable fields end-to-end. the only information you can protect is what qos was requested by one end. since rsvp is not used by its own you could also protect this information at the application layer for example using sip. if nodes in between are unable to verify this information then this would also work. what do you think? > Once it's injected, it's even TRUSTED! yes - if a router is malicious then you have a problem. injecting data traffic by someone else (unauthorized user) is something different. injecting unprotected signaling messages is again something different. > One major problem is > that you lose the origin of the request after the first hop, not to > mention the actual request itself. which nodes need this information and for what? ciao hannes > > -derek > > "Hannes Tschofenig" writes: > > > hi > > > > what do you mean by "in terms of addressing"? > > > > my understanding of rsvp is: > > rsvp travels hop-by-hop (rsvp capable nodes) from one end-point > to an other > > (except if you use some rsvp extensions like rsvp proxy etc.). > hence "RSVP > > is end-to-end in one direction (sender->receiver)" confuses me > somehow. the > > security for rsvp is build on hop-by-hop security based on a > chain-of-trust. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore > > > Sent: Saturday, May 25, 2002 5:18 PM > > > To: RJ Atkinson; Derek Atkins > > > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec; > > > Security_Area_Advisory_Group > > > Subject: Re: [saag] Re: > > > > > > > > > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote: > > > >Hmm. I would rather say that RSVP is hop-by-hop and > > > >that (normally) AH/ESP are end-to-end. > > > > > > In terms of addressing, RSVP is end-to-end in one > > > direction (sender->receiver) and hop-by-hop in the > > > other (receiver->sender). > > > > > > >However, if one used (for example) AH with an asymmetric algorithm, > > > >one could perform hop-by-hop authentication of the > > > >packet with AH. This has obvious computational cost > > > >issues so might not be the best choice. > > > > > > The packet payload is going to be modified at each hop, > > > as well, in both directions. > > > > > > Melinda > > > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed May 29 07:29:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TETjJ09745; Wed, 29 May 2002 07:29:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11208 Wed, 29 May 2002 09:26:22 -0400 (EDT) From: "Hannes Tschofenig" To: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: ipsec to secure rsvp Date: Wed, 29 May 2002 15:43:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020524143641.97990.qmail@web21302.mail.yahoo.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi there is no reason why not to use ipsec to secure rsvp. especially in the core network (between routers) this might be a reasonable approach. using ipsec to secure the traffic between the application (end-host) and the first hop router is however more difficult. ciao hannes > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara > Sent: Friday, May 24, 2002 4:37 PM > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > Subject: Re: > > > Why don't you use IPSEC to secure RSVP. > > Satish Amara > --- Dong wrote: > > Roy, > > > > I just read a paper "Preventing Denial of Service > > Attacks on Quality of Service", which is written by > > some guys from N.C. State university and UC Davis. > > The service quality to legimative users could be > > degraded by attacks on control flow or data flow. > > For example, an illegal user can forge a reservation > > message, so he can receive an unauthorized amount of > > resources. I just wanna to know what threats exist > > in providing QoS, and what the state-of-art > > techniques to prevent, detect and counter those > > attacks, and of course recovery mothods as well. > > > > Thx a lot. > > > > Dong > > > > > > Dong, > > Please be a little more precise in what you are > > asking for, i.e. > > > > 3-5 bullet list items on what kind of security you > > seek. > > > > Roy > > > > -----Original Message----- > > From: Dong [mailto:dong_wei@tsinghua.com] > > Sent: Thursday, May 23, 2002 2:05 PM > > To: Security_Area_Advisory_Group; IPsec > > Subject: Secure QoS > > > > > > Hi, > > > > I am trying to do a survey on Secure QoS. Any paper > > on that? Thx. > > > > Dong > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > _____________________________________________________________ > > Get Tsinghua University free email account: > > www.tsinghua.com > > Web site sponsored and hosted by AtFreeWeb.com > > > > > _____________________________________________________________ > > Promote your group and strengthen ties to your > > members with email@yourgroup.org by Everyone.net > http://www.everyone.net/?btn=tag > > > ===== > In natural science, Nature has given us a world and we're just to > discover its laws. In computers, we can stuff laws into it and > create a world -- Alan Kay > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com From owner-ipsec@lists.tislabs.com Wed May 29 07:30:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEUIJ10025; Wed, 29 May 2002 07:30:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11237 Wed, 29 May 2002 09:30:20 -0400 (EDT) To: "Hannes Tschofenig" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" From: Derek Atkins Subject: Re: IPsec and RSVP References: Date: 29 May 2002 09:43:16 -0400 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hannes Tschofenig" writes: > hi > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > capable router)? You lose the authentication of the end-point requesting the reservation. If you use ipsec in this way, then each router knows its peer, but you have no transitive authentication. The only protection you get is protection of on-the-wire request. You have no protection against a corrupt router along the path, or indeed no way to know what the actual original request was. > ciao > hannes -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ipsec@lists.tislabs.com Wed May 29 07:34:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEY2J11261; Wed, 29 May 2002 07:34:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11212 Wed, 29 May 2002 09:26:26 -0400 (EDT) From: "Hannes Tschofenig" To: "Derek Atkins" , "SatishK Amara" Cc: , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: Date: Wed, 29 May 2002 15:43:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp capable router)? ciao hannes > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins > Sent: Saturday, May 25, 2002 5:01 AM > To: SatishK Amara > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > Subject: Re: > > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > -derek > > SatishK Amara writes: > > > Why don't you use IPSEC to secure RSVP. > > > > Satish Amara > > --- Dong wrote: > > > Roy, > > > > > > I just read a paper "Preventing Denial of Service > > > Attacks on Quality of Service", which is written by > > > some guys from N.C. State university and UC Davis. > > > The service quality to legimative users could be > > > degraded by attacks on control flow or data flow. > > > For example, an illegal user can forge a reservation > > > message, so he can receive an unauthorized amount of > > > resources. I just wanna to know what threats exist > > > in providing QoS, and what the state-of-art > > > techniques to prevent, detect and counter those > > > attacks, and of course recovery mothods as well. > > > > > > Thx a lot. > > > > > > Dong > > > > > > > > > Dong, > > > Please be a little more precise in what you are > > > asking for, i.e. > > > > > > 3-5 bullet list items on what kind of security you > > > seek. > > > > > > Roy > > > > > > -----Original Message----- > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > Sent: Thursday, May 23, 2002 2:05 PM > > > To: Security_Area_Advisory_Group; IPsec > > > Subject: Secure QoS > > > > > > > > > Hi, > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > on that? Thx. > > > > > > Dong > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > _____________________________________________________________ > > > Promote your group and strengthen ties to your > > > members with email@yourgroup.org by Everyone.net > > http://www.everyone.net/?btn=tag > > > > > > ===== > > In natural science, Nature has given us a world and we're just > to discover its laws. In computers, we can stuff laws into it and > create a world -- Alan Kay > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed May 29 07:46:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEkNJ17957; Wed, 29 May 2002 07:46:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11469 Wed, 29 May 2002 10:05:42 -0400 (EDT) From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "IPsec" , "Security_Area_Advisory_Group" Subject: RE: [saag] Re: Date: Wed, 29 May 2002 16:22:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.0.20020529100110.00aad1b0@localhost> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi melinda > > > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: > >do you think that the hop-by-hop security in rsvp is a good or a > bad thing? > >should there be more than what is currently provided? > > There needs to be more than what is currently provided, > but, as always, there's a big keying/cert problem, particularly > in a multi-"domain" environment. i fully agree with you. especially in a generic end-to-end case this might be quite difficult. > I don't think the threat > environment is particularly well-understood (I've seen your > NSIS draft but haven't gone through it in detail). i would like to hear your opinion about it. > Clearly > IPSec is not the right answer for Path messages, however, > because while the addressing is end-to-end the payload > contents do change as the packet transits participating > routers. yes. ipsec is definitely not the choice for end-to-end security since it does not allow intermediate nodes to modify the messages. i however have difficulties with the statement that end-to-end security introduced in rsvp solves all problems. (i think that it even introduces more.) my observation is that the interaction between rsvp and other protocols like sip is important especially for accounting and since rsvp is often used together with other protocols. ciao hannes > > Melinda From owner-ipsec@lists.tislabs.com Wed May 29 09:36:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TGaAJ16484; Wed, 29 May 2002 09:36:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11957 Wed, 29 May 2002 11:50:11 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15604.64389.520614.112373@thomasm-u1.cisco.com> Date: Wed, 29 May 2002 09:02:13 -0700 (PDT) To: Derek Atkins Cc: "Hannes Tschofenig" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: Re: IPsec and RSVP In-Reply-To: References: 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 Derek Atkins writes: > "Hannes Tschofenig" writes: > > > hi > > > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > > capable router)? > > You lose the authentication of the end-point requesting the > reservation. If you use ipsec in this way, then each router > knows its peer, but you have no transitive authentication. > The only protection you get is protection of on-the-wire > request. You have no protection against a corrupt router > along the path, or indeed no way to know what the actual > original request was. Derek, There are two different forms of crypto needed for RSVP: a hop-by-hop integrity object and a policy object. IPsec could in theory replace the integrity object, but cannot replace the policy object. Considering that there is no key distribution for the hop-by-hop integrity objects, IPsec might not be a bad choice in some situations. Mike From owner-ipsec@lists.tislabs.com Wed May 29 09:51:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TGp8J22512; Wed, 29 May 2002 09:51:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11375 Wed, 29 May 2002 09:49:32 -0400 (EDT) Message-Id: <5.1.0.14.0.20020529100110.00aad1b0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 10:06:51 -0400 To: "Hannes Tschofenig" From: Melinda Shore Subject: RE: [saag] Re: Cc: "IPsec" , "Security_Area_Advisory_Group" In-Reply-To: References: <5.1.0.14.0.20020529094532.00ab6b90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: >do you think that the hop-by-hop security in rsvp is a good or a bad thing? >should there be more than what is currently provided? There needs to be more than what is currently provided, but, as always, there's a big keying/cert problem, particularly in a multi-"domain" environment. I don't think the threat environment is particularly well-understood (I've seen your NSIS draft but haven't gone through it in detail). Clearly IPSec is not the right answer for Path messages, however, because while the addressing is end-to-end the payload contents do change as the packet transits participating routers. Melinda From owner-ipsec@lists.tislabs.com Wed May 29 11:22:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TIMhJ03158; Wed, 29 May 2002 11:22:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11210 Wed, 29 May 2002 09:26:23 -0400 (EDT) From: "Hannes Tschofenig" To: , "IPsec" , "Security_Area_Advisory_Group" Subject: qos threats Date: Wed, 29 May 2002 15:43:28 +0200 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.2600.0000 In-Reply-To: <20020523234609.3FA1B2756@sitemail.everyone.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi regarding threats you might read (and maybe comment) a threat draft related to nsis; see: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-00.txt ciao hannes ps: your comments are welcome. Title : NSIS Threats Author(s) : H. Tschofenig Filename : draft-tschofenig-nsis-threats-00.txt Pages : 9 Date : 24-May-02 As the work in the NSIS working has begun to describe requirements and the framework people started thinking about possible security implication. This document should provide a starting point for the discussion at the NSIS interim meeting and at the NSIS working group mailing list regarding the security issues that have to be addressed. It does not describe threats for a particular published protocol. This memo is furthermore meant to create awareness for the security within the group. The threat scenarios in this document are matched against the security requirements described in [1]. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dong > Sent: Friday, May 24, 2002 1:46 AM > To: IPsec; Security_Area_Advisory_Group > Subject: > > > Roy, > > I just read a paper "Preventing Denial of Service Attacks on > Quality of Service", which is written by some guys from N.C. > State university and UC Davis. The service quality to legimative > users could be degraded by attacks on control flow or data flow. > For example, an illegal user can forge a reservation message, so > he can receive an unauthorized amount of resources. I just wanna > to know what threats exist in providing QoS, and what the > state-of-art techniques to prevent, detect and counter those > attacks, and of course recovery mothods as well. > > Thx a lot. > > Dong > > > Dong, > Please be a little more precise in what you are asking for, i.e. > > 3-5 bullet list items on what kind of security you seek. > > Roy > > -----Original Message----- > From: Dong [mailto:dong_wei@tsinghua.com] > Sent: Thursday, May 23, 2002 2:05 PM > To: Security_Area_Advisory_Group; IPsec > Subject: Secure QoS > > > Hi, > > I am trying to do a survey on Secure QoS. Any paper on that? Thx. > > Dong > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > > > _____________________________________________________________ > Get Tsinghua University free email account: www.tsinghua.com > Web site sponsored and hosted by AtFreeWeb.com > > _____________________________________________________________ > Promote your group and strengthen ties to your members with > email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag From owner-ipsec@lists.tislabs.com Wed May 29 12:34:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TJYdJ00851; Wed, 29 May 2002 12:34:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12401 Wed, 29 May 2002 14:51:25 -0400 (EDT) Message-ID: <3CF50554.4B48FA53@cs.ucdavis.edu> Date: Wed, 29 May 2002 09:44:04 -0700 From: "S. Felix Wu" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hannes Tschofenig , kumar_amara@yahoo.com, dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group Subject: Re: ipsec to secure rsvp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The tricky part (my personal opinion) is that, using IPSec, you must know the other endpoint's IP address to establish the SA in the first place. According to my understanding, at least in general, in RSVP, you do NOT know the next hop RSVP router's IP address in path finding messages (I assume that not every Internet router will support RSVP), and sometimes route path might change unpredictably. Therefore, (according to my old/dusty memory), Fred Baker's proposal to secure RSVP is based on a key table and key ID to allow the next hop trusted RSVP router to authenticate (HMAC fashion) the message without prior seesion-key exchange. I have admitted that I haven't followed the thread of progress in RSVP security for a while, so maybe things have been changed. -Felix Hannes Tschofenig wrote: > > hi > > there is no reason why not to use ipsec to secure rsvp. especially in the > core network (between routers) this might be a reasonable approach. using > ipsec to secure the traffic between the application (end-host) and the first > hop router is however more difficult. > > ciao > hannes > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara > > Sent: Friday, May 24, 2002 4:37 PM > > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > Subject: Re: > > > > > > Why don't you use IPSEC to secure RSVP. > > > > Satish Amara > > --- Dong wrote: > > > Roy, > > > > > > I just read a paper "Preventing Denial of Service > > > Attacks on Quality of Service", which is written by > > > some guys from N.C. State university and UC Davis. > > > The service quality to legimative users could be > > > degraded by attacks on control flow or data flow. > > > For example, an illegal user can forge a reservation > > > message, so he can receive an unauthorized amount of > > > resources. I just wanna to know what threats exist > > > in providing QoS, and what the state-of-art > > > techniques to prevent, detect and counter those > > > attacks, and of course recovery mothods as well. > > > > > > Thx a lot. > > > > > > Dong > > > > > > > > > Dong, > > > Please be a little more precise in what you are > > > asking for, i.e. > > > > > > 3-5 bullet list items on what kind of security you > > > seek. > > > > > > Roy > > > > > > -----Original Message----- > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > Sent: Thursday, May 23, 2002 2:05 PM > > > To: Security_Area_Advisory_Group; IPsec > > > Subject: Secure QoS > > > > > > > > > Hi, > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > on that? Thx. > > > > > > Dong > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > _____________________________________________________________ > > > Get Tsinghua University free email account: > > > www.tsinghua.com > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > _____________________________________________________________ > > > Promote your group and strengthen ties to your > > > members with email@yourgroup.org by Everyone.net > > http://www.everyone.net/?btn=tag > > > > > > ===== > > In natural science, Nature has given us a world and we're just to > > discover its laws. In computers, we can stuff laws into it and > > create a world -- Alan Kay > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed May 29 12:34:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TJYmJ00868; Wed, 29 May 2002 12:34:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12402 Wed, 29 May 2002 14:51:26 -0400 (EDT) Message-ID: <3CF509D5.C0530394@cs.ucdavis.edu> Date: Wed, 29 May 2002 10:03:18 -0700 From: "S. Felix Wu" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hannes Tschofenig CC: Derek Atkins , SatishK Amara , dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It depends on what are the security requirements and threats. In my opinion, RSVP security is really neither hop-by-hop nor end-to-end (or I should say it is a mixture of both). Certain fields in RSVP are "mutable" (for example, maximum available bandwidth along the route path), and therefore, a pure end-to-end will not be possible. On the other hand, if we assume (i.e., our threat model) that an intermediate RSVP router (on the route path) can be malicious, then you need some forms of end-to-end to protect at least those "static" fields in an end-to-end fashion. My students and I studied this problem a few years ago and the following is a web link to our paper: http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.pdf This work is somewhat old, but hopefully it will provide some information about the technical difficulties in dealing with RSVP security. -Felix Hannes Tschofenig wrote: > > hi > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > capable router)? > > ciao > hannes > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins > > Sent: Saturday, May 25, 2002 5:01 AM > > To: SatishK Amara > > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > Subject: Re: > > > > > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > > > -derek > > > > SatishK Amara writes: > > > > > Why don't you use IPSEC to secure RSVP. > > > > > > Satish Amara > > > --- Dong wrote: > > > > Roy, > > > > > > > > I just read a paper "Preventing Denial of Service > > > > Attacks on Quality of Service", which is written by > > > > some guys from N.C. State university and UC Davis. > > > > The service quality to legimative users could be > > > > degraded by attacks on control flow or data flow. > > > > For example, an illegal user can forge a reservation > > > > message, so he can receive an unauthorized amount of > > > > resources. I just wanna to know what threats exist > > > > in providing QoS, and what the state-of-art > > > > techniques to prevent, detect and counter those > > > > attacks, and of course recovery mothods as well. > > > > > > > > Thx a lot. > > > > > > > > Dong > > > > > > > > > > > > Dong, > > > > Please be a little more precise in what you are > > > > asking for, i.e. > > > > > > > > 3-5 bullet list items on what kind of security you > > > > seek. > > > > > > > > Roy > > > > > > > > -----Original Message----- > > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > > Sent: Thursday, May 23, 2002 2:05 PM > > > > To: Security_Area_Advisory_Group; IPsec > > > > Subject: Secure QoS > > > > > > > > > > > > Hi, > > > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > > on that? Thx. > > > > > > > > Dong > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > _____________________________________________________________ > > > > Promote your group and strengthen ties to your > > > > members with email@yourgroup.org by Everyone.net > > > http://www.everyone.net/?btn=tag > > > > > > > > > ===== > > > In natural science, Nature has given us a world and we're just > > to discover its laws. In computers, we can stuff laws into it and > > create a world -- Alan Kay > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > LAUNCH - Your Yahoo! Music Experience > > > http://launch.yahoo.com > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available -- ---------------------------------------------------------------------- Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu Associate Professor http://www.cs.ucdavis.edu/~wu Computer Science Department office: 1-530-754-7070 University of California at Davis fax: 1-530-752-4767 ---------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed May 29 14:15:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TLF8J18691; Wed, 29 May 2002 14:15:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12649 Wed, 29 May 2002 16:34:43 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15605.15926.912770.654169@thomasm-u1.cisco.com> Date: Wed, 29 May 2002 13:46:46 -0700 (PDT) To: "S. Felix Wu" Cc: Hannes Tschofenig , kumar_amara@yahoo.com, dong_wei@tsinghua.com, IPsec , Security_Area_Advisory_Group Subject: Re: ipsec to secure rsvp In-Reply-To: <3CF50554.4B48FA53@cs.ucdavis.edu> References: <3CF50554.4B48FA53@cs.ucdavis.edu> 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 S. Felix Wu writes: > Therefore, (according to my old/dusty memory), Fred Baker's proposal > to secure RSVP is based on a key table and key ID to allow the next > hop trusted RSVP router to authenticate (HMAC fashion) the message > without prior seesion-key exchange. Right. There are two competing goals going on with RSVP in this respect: router alert as a discovery mechanism, and security desires which need to know the how to key the next hop integrity object. I don't really see how you reconcile that unless you have group keys on your integrity objects which makes me a little queasy. Mike From owner-ipsec@lists.tislabs.com Wed May 29 15:11:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TMBIJ20101; Wed, 29 May 2002 15:11:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12846 Wed, 29 May 2002 17:33:24 -0400 (EDT) Message-ID: <001501c2075a$0d1f4780$6540fea9@amanda2> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Hannes Tschofenig" , "Melinda Shore" Cc: "IPsec" , "Security_Area_Advisory_Group" References: <5.1.0.14.0.20020529094532.00ab6b90@localhost> <5.1.0.14.0.20020529100110.00aad1b0@localhost> Subject: Re: [saag] Re: Date: Thu, 30 May 2002 00:44:44 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi The best approach in my view is to use CORBA and CORBsec to deal with path messages, I believe if CORBA routers can be realized very soon, most of your IPsec shortcomings will be resolved. Ahmed ----- Original Message ----- From: "Melinda Shore" To: "Hannes Tschofenig" Cc: "IPsec" ; "Security_Area_Advisory_Group" Sent: Wednesday, May 29, 2002 5:06 PM Subject: RE: [saag] Re: > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: > >do you think that the hop-by-hop security in rsvp is a good or a bad thing? > >should there be more than what is currently provided? > > There needs to be more than what is currently provided, > but, as always, there's a big keying/cert problem, particularly > in a multi-"domain" environment. I don't think the threat > environment is particularly well-understood (I've seen your > NSIS draft but haven't gone through it in detail). Clearly > IPSec is not the right answer for Path messages, however, > because while the addressing is end-to-end the payload > contents do change as the packet transits participating > routers. > > Melinda > From owner-ipsec@lists.tislabs.com Wed May 29 17:36:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U0aZJ24822; Wed, 29 May 2002 17:36:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13075 Wed, 29 May 2002 19:57:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.3.32.20020524164356.01289ba0@mail> References: <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> Date: Wed, 29 May 2002 20:10:41 -0400 To: Alex Alten From: Stephen Kent Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:43 PM -0700 5/24/02, Alex Alten wrote: >Steve, > >I'm not talking about a host's local database. We need a way to uniquely >AND SECURELY identify any host worldwide from any other host. You don't >want to replicate this information to every host, you'd have over 100 million >entries to distribute to each one! Oh, well, you've moved the problem well beyond the bounds of the IPsec WG, given this description of what you are looking for. Also, given my earlier comments about the desirability of not creating new ID forms for use in access control systems, I think we have a fundamental disagreement here. >I like DNS too, a nice simple hierarchy, it is easy to uniquely name hosts, >and a simple distributed model for managing the address space. But it has a >crippling drawback from a security perspective. A DNS name cannot be any >better >at identifying a host than it's resolved IP address. >And we know how >ephemeral IP addresses can be given the rise of DHCP and NAT. The only >secure way to absolutely identify a host is to assign it a (randomly) unique >crypto key. But before you can pull the correct key (RSA or AES) you need to >find it. For this you need a unique number that doesn't keep being changed >underneath you. So unfortunately DNS doesn't make the cut. No amount of >wishful >thinking is going to make it work properly for us. I think your argument above is faulty. If I choose to use DNS names as a basis for access control decisions, and if I have credentials (e.g., certificates) that allow a machine or person to verify that the entity at the other end of a key management exchange is the entity with the DNS name in question, then I can dynamically bind the name to the current address at the time an SA is created and I have achieved the access control goals without needing to introduce the sort of new ID scheme to which you are alluding. >To reiterate my position: IPsec needs to have a global, secure address space >that uniquely identifies every participating host. It needs to be simple to >understand, distributable, and easy to manage. And it needs to be able to >dynamically map into the IP address space on demand, including private >network non-routable addresses. > >That's the requirements as I see them. Anything less than this means >you can't use IPsec unencumbered across the Internet. we don't need a global, secure address space. we need secure means of mapping IDs to credentials, and mapping those IDs to SA, in real time, as you note immediately above. These two notions are not the same. Steve From owner-ipsec@lists.tislabs.com Thu May 30 07:31:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UEVO103536; Thu, 30 May 2002 07:31:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14816 Thu, 30 May 2002 09:33:59 -0400 (EDT) Message-ID: <000a01c207e0$4839a000$2daafea9@amanda2> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Davenport Michael" Cc: References: Subject: Re: [saag] Re: Date: Thu, 30 May 2002 16:45:36 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike I believe most big vendors are looking at it right now, see http://www.omg.org Ahmed ----- Original Message ----- From: "Davenport Michael" To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" Sent: Thursday, May 30, 2002 4:16 PM Subject: RE: [saag] Re: > Ahmed: > > I never heard of COBRA routers. Do you have info or a link I can go to? > Sounds interesting.... > > v/r, > > Mike > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Prof. Ahmed Bin Abbas > Ahmed Ali Adas > Sent: Wednesday, May 29, 2002 5:45 PM > To: Hannes Tschofenig; Melinda Shore > Cc: IPsec; Security_Area_Advisory_Group > Subject: Re: [saag] Re: > > > Hi > > The best approach in my view is to use CORBA and CORBsec to deal with path > messages, I believe if CORBA routers can be realized very soon, most of your > IPsec shortcomings will be resolved. > > Ahmed > ----- Original Message ----- > From: "Melinda Shore" > To: "Hannes Tschofenig" > Cc: "IPsec" ; "Security_Area_Advisory_Group" > > Sent: Wednesday, May 29, 2002 5:06 PM > Subject: RE: [saag] Re: > > > > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: > > >do you think that the hop-by-hop security in rsvp is a good or a bad > thing? > > >should there be more than what is currently provided? > > > > There needs to be more than what is currently provided, > > but, as always, there's a big keying/cert problem, particularly > > in a multi-"domain" environment. I don't think the threat > > environment is particularly well-understood (I've seen your > > NSIS draft but haven't gone through it in detail). Clearly > > IPSec is not the right answer for Path messages, however, > > because while the addressing is end-to-end the payload > > contents do change as the packet transits participating > > routers. > > > > Melinda > > > From owner-ipsec@lists.tislabs.com Thu May 30 08:03:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UF3k105358; Thu, 30 May 2002 08:03:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14944 Thu, 30 May 2002 10:24:35 -0400 (EDT) Message-ID: <000701c207e7$57562b60$2daafea9@amanda2> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Pete Chown" Cc: References: <5.1.0.14.0.20020529094532.00ab6b90@localhost><5.1.0.14.0.20020529100110.00aad1b0@localhost> <001501c2075a$0d1f4780$6540fea9@amanda2> <1022756199.6080.76.camel@hyena.skygate.co.uk> Subject: Re: [saag] Re: Date: Thu, 30 May 2002 17:32:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pete CORBASec standard to my knowledge has finished. Noting that CORBA-3 specification defines transport level firewalls, application level firewalls, and most interesting GIOP. Transport level firewalls work at TCP port 683 for IIOP and 684 for IIOP/SSL. Ahmed ----- Original Message ----- From: "Pete Chown" To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" Sent: Thursday, May 30, 2002 1:56 PM Subject: Re: [saag] Re: > Prof. Ahmed Bin Abbas Ahmed Ali Adas wrote: > > > The best approach in my view is to use CORBA and CORBsec to deal with path > > messages, I believe if CORBA routers can be realized very soon, most of your > > IPsec shortcomings will be resolved. > > Have they sorted out the firewall draft yet? Last time I looked they > were still trying to solve this and other security related problems, > because of difficulties with the architecture of IIOP. > > Also wasn't there a problem where CORBAsec progressed but some companion > document didn't, meaning that CORBA security wasn't specified as > completely as had been intended? (My memory's going, I can't remember > exactly what happened -- sorry.) > > In a lot of ways I think GIOP is preferable to the XML-based encodings > that have come more recently. XML is more verbose, and parsing it > requires extra code. By contrast, GIOP's structure is very simple. > > Yet in spite of this, it is much easier to use SOAP or XML-RPC. I think > there are two reasons. Firstly the lack of the firewall spec makes it > very difficult to proxy. Secondly all the other security measures are > very complicated and under-specified. > > -- > Pete > From owner-ipsec@lists.tislabs.com Thu May 30 08:48:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UFmGn10061; Thu, 30 May 2002 08:48:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15070 Thu, 30 May 2002 10:54:56 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869AD9@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" , Davenport Michael Cc: ipsec@lists.tislabs.com Subject: RE: [saag] Re: Date: Thu, 30 May 2002 08:08:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Mike > > I believe most big vendors are looking at it right now, see I don't. I know of more major platform vendors who are stating that they have no intention of further work on CORBA than are platform members of OMG. The only major companies with Platform membership of OMG at this stage are Motorola, Rockwell Collins and DaimlerChrysler. These are not names I usually associate with IP routing. > The best approach in my view is to use CORBA and CORBsec to deal with path > messages, I believe if CORBA routers can be realized very soon, most of your > IPsec shortcomings will be resolved. How? There are several companies that have built Web Services SOAP routers. It is not immediately apparent to me how any of their products is relevant to this problem. The problem is essentially caused by the introduction of a feature that requires a degree of trust in what is considered by the IPSEC threat model to be an untrusted device. I suspect that the QoS problem cannot be solved through application of the end-to-end principle. This should not be a great suprise since the end-to-end principle is a conclusion, not an axiom. Those that treat it as an axiom are likely to get overly ideological about the issue. The end-to-end argument was originally an argument about complexity. Complexity is easier to manage at the edge of the network rather than the middle. This morphed into a subtly different security argument that the security context of a message should be managed 'end-to-end'. This is a problematic argument since a transaction may have many messages and the 'ends' of the transaction may not align with the 'ends' of the constituent messages. While it is nice to build theoretical models in which the only trusted parties are the end points, QoS inherently depends on the end points trusting each of the intermediate routers to meet the necessary QoS characteristic. Furthermore the routers must trust the originator of any QoS messages since otherwise a malicious user may perform a DoS attack against the entire network by issuing bogus QoS reservation messages. [Observation, QoS is not an issue if the network resources are not constrained in some manner] This latter problem indicates to me that it is not feasible to support QoS on an unrestricted public network without some form of resource management mechanism (probably related to monetary payment) to support it. What could be a tricky problem of trust is thus simplified, instead of the hard problem of 'is it Alice' we have the easier problem of 'can she pay'. The trust relationships precisely align to the relationship between resource allocators. The resulting business models may or may not turn out to be 'all you can eat'. I suspect however that some incentive is required. This problem appears to me to require the following components: 1) Trustworthy routing information 2) Means by which a router may determine that a reservation message is signed by a trustworthy actor. 3) Means by which a router may notify charging mechanism The end-to-end principle indicates that the routers should certainly not be performing heavyweight crypto. The model I would favor would involve some form of bandwidth reservations actor that can perform processing of the bandwidth reservation request then issue RSVP messages tagged with MAC authenticators and Kerberos tickets for each of the routers concerned. Phill From owner-ipsec@lists.tislabs.com Thu May 30 09:14:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UGEhn11241; Thu, 30 May 2002 09:14:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15158 Thu, 30 May 2002 11:26:22 -0400 (EDT) Message-ID: <000d01c207ef$e940a020$2daafea9@amanda2> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Hallam-Baker, Phillip" , "Davenport Michael" Cc: References: <2F3EC696EAEED311BB2D009027C3F4F405869AD9@vhqpostal.verisign.com> Subject: Re: [saag] Re: Date: Thu, 30 May 2002 18:37:29 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phillip I believe that the CORBASec and SECIOP in its design offer features for end-to-end message transit without you have to make various scenarios each day of attacks on IPSec. You got to look into the protocol architecture to realize that it is true a different ideology, but rather a sound one in my view, instead of building upon the old tech of TCP/IP and Cryptology. Looking at the ISO/OSI seven layers. CORBA/GIOP/IIOP/SECIOP can offer features that are more modular and secure. I do not know why major IP vendors abandoned CORBA, but look in the literature and you will find that they might come back to it. My estimate is that they are worried about investments in current products. Ahmed ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" ; "Davenport Michael" Cc: Sent: Thursday, May 30, 2002 6:08 PM Subject: RE: [saag] Re: > > > Mike > > > > I believe most big vendors are looking at it right now, see > > I don't. I know of more major platform vendors who are stating that they > have no intention of further work on CORBA than are platform members of OMG. > The only major companies with Platform membership of OMG at this stage are > Motorola, Rockwell Collins and DaimlerChrysler. These are not names I > usually associate with IP routing. > > > The best approach in my view is to use CORBA and CORBsec to deal with path > > messages, I believe if CORBA routers can be realized very soon, most of > your > > IPsec shortcomings will be resolved. > > How? > > There are several companies that have built Web Services SOAP routers. It is > not immediately apparent to me how any of their products is relevant to this > problem. > > > The problem is essentially caused by the introduction of a feature that > requires a degree of trust in what is considered by the IPSEC threat model > to be an untrusted device. > > I suspect that the QoS problem cannot be solved through application of the > end-to-end principle. This should not be a great suprise since the > end-to-end principle is a conclusion, not an axiom. Those that treat it as > an axiom are likely to get overly ideological about the issue. > > The end-to-end argument was originally an argument about complexity. > Complexity is easier to manage at the edge of the network rather than the > middle. This morphed into a subtly different security argument that the > security context of a message should be managed 'end-to-end'. This is a > problematic argument since a transaction may have many messages and the > 'ends' of the transaction may not align with the 'ends' of the constituent > messages. > > While it is nice to build theoretical models in which the only trusted > parties are the end points, QoS inherently depends on the end points > trusting each of the intermediate routers to meet the necessary QoS > characteristic. > > Furthermore the routers must trust the originator of any QoS messages since > otherwise a malicious user may perform a DoS attack against the entire > network by issuing bogus QoS reservation messages. > > [Observation, QoS is not an issue if the network resources are not > constrained in some manner] > > This latter problem indicates to me that it is not feasible to support QoS > on an unrestricted public network without some form of resource management > mechanism (probably related to monetary payment) to support it. What could > be a tricky problem of trust is thus simplified, instead of the hard problem > of 'is it Alice' we have the easier problem of 'can she pay'. The trust > relationships precisely align to the relationship between resource > allocators. > > The resulting business models may or may not turn out to be 'all you can > eat'. I suspect however that some incentive is required. > > > This problem appears to me to require the following components: > > 1) Trustworthy routing information > 2) Means by which a router may determine that a reservation message > is signed by a trustworthy actor. > 3) Means by which a router may notify charging mechanism > > The end-to-end principle indicates that the routers should certainly not be > performing heavyweight crypto. > > The model I would favor would involve some form of bandwidth reservations > actor that can perform processing of the bandwidth reservation request then > issue RSVP messages tagged with MAC authenticators and Kerberos tickets for > each of the routers concerned. > > > Phill From owner-ipsec@lists.tislabs.com Thu May 30 09:15:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UGFdn11279; Thu, 30 May 2002 09:15:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15197 Thu, 30 May 2002 11:36:26 -0400 (EDT) Date: Thu, 30 May 2002 11:48:40 -0400 From: "Theodore Ts'o" To: Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt Message-ID: <20020530154839.GA3903@think.thunk.org> References: <000b01c2028c$05da1310$bd6fe640@ca.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000b01c2028c$05da1310$bd6fe640@ca.alcatel.com> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote: > This draft hasn't really been discussed on the list much. I guess people > figure that "hey, it's just another crypto algorithm... there can't be > anything controversial about it". > > The issue which Dave brought up at the meeting and which I sent to the > authors is that XCBC-MAC skirts the "obvious" solution of prepending the > length of the buffer to the hash input. There is an engineering tradeoff > here, which is not mentioned in the draft. > > AES-XCBC-MAC: > a) requires 384 bits of keymat > b) does not require that the length of the message be pre-computed > > The "obvious" solution: > a) requires 128 bits of keymat > b) requires that the length of the message be pre-computed > > Clearly, issue (b) was an important motivation in the design of XCBC-MAC. > > My personal opinion is that this rationale makes sense, since key storage > capacity is unlikely to be the limiting factor in the design of any future > hardware. However, the tradeoff ought to at least be discussed on the list > and acknowledged in the draft. A week has gone by and there doesn't appear to have been any discussion on this point which Andrew has raised. Does anybody think that the extra use of keying material used by AES-XCBC-MAC is a problem? We will assume that silence means people are OK with it as it currently stands. Andrew, how strongly do you feel about requesting the draft be modified to include discussion of this tradeoff? I suspect that if you contribute text to the document authors, it would probably increase the likelihood that the draft will include discussion on this point. :-) - Ted From owner-ipsec@lists.tislabs.com Fri May 31 00:16:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7Gmg14412; Fri, 31 May 2002 00:16:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16557 Fri, 31 May 2002 02:31:38 -0400 (EDT) From: "Hannes Tschofenig" To: "Michael Thomas" , "S. Felix Wu" Cc: , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: ipsec to secure rsvp Date: Fri, 31 May 2002 08:49:05 +0200 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: <15605.15926.912770.654169@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi mike! > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, May 29, 2002 10:47 PM > To: S. Felix Wu > Cc: Hannes Tschofenig; kumar_amara@yahoo.com; dong_wei@tsinghua.com; > IPsec; Security_Area_Advisory_Group > Subject: Re: ipsec to secure rsvp > > > S. Felix Wu writes: > > Therefore, (according to my old/dusty memory), Fred Baker's proposal > > to secure RSVP is based on a key table and key ID to allow the next > > hop trusted RSVP router to authenticate (HMAC fashion) the message > > without prior seesion-key exchange. > > Right. There are two competing goals going on with > RSVP in this respect: router alert as a discovery > mechanism, and security desires which need to know > the how to key the next hop integrity object. I > don't really see how you reconcile that unless you > have group keys on your integrity objects which > makes me a little queasy. i fully agree with you. if you want to use protection based on symmetric cryptography then you first must learn the identity of the node to whom you want to authenticate to. (and the keys need to be in place). with public key cryptography things are somewhat different. but from a pratical perspective it does not provide the necessary performance. i guess you can agree with me on this issue. > > Mike ciao hannes From owner-ipsec@lists.tislabs.com Fri May 31 00:16:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7Gmg14411; Fri, 31 May 2002 00:16:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16558 Fri, 31 May 2002 02:31:39 -0400 (EDT) From: "Hannes Tschofenig" To: "S. Felix Wu" , , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: ipsec to secure rsvp Date: Fri, 31 May 2002 08:49:06 +0200 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: <3CF50554.4B48FA53@cs.ucdavis.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi felix! > -----Original Message----- > From: S. Felix Wu [mailto:wu@cs.ucdavis.edu] > Sent: Wednesday, May 29, 2002 6:44 PM > To: Hannes Tschofenig; kumar_amara@yahoo.com; dong_wei@tsinghua.com; > IPsec; Security_Area_Advisory_Group > Subject: Re: ipsec to secure rsvp > > > > The tricky part (my personal opinion) is that, using IPSec, you > must know the other endpoint's IP address to establish the SA in > the first place. According to my understanding, at least in general, > in RSVP, you do NOT know the next hop RSVP router's IP address in > path finding messages (I assume that not every Internet router will > support RSVP), and sometimes route path might change unpredictably. true - rsvp does not describe how to learn the identity of the next rsvp aware next hop (i think it the documents say something like 'by other means...'). this information needs to be available otherwise the integrity object cannot be added. > > Therefore, (according to my old/dusty memory), Fred Baker's proposal > to secure RSVP is based on a key table and key ID to allow the next > hop trusted RSVP router to authenticate (HMAC fashion) the message > without prior seesion-key exchange. that is not going to work. maybe he said something more. > > I have admitted that I haven't followed the thread of progress in > RSVP security for a while, so maybe things have been changed. there has not been a discussion as far as i remember. ciao hannes > > -Felix > > > > Hannes Tschofenig wrote: > > > > hi > > > > there is no reason why not to use ipsec to secure rsvp. > especially in the > > core network (between routers) this might be a reasonable > approach. using > > ipsec to secure the traffic between the application (end-host) > and the first > > hop router is however more difficult. > > > > ciao > > hannes > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara > > > Sent: Friday, May 24, 2002 4:37 PM > > > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > > Subject: Re: > > > > > > > > > Why don't you use IPSEC to secure RSVP. > > > > > > Satish Amara > > > --- Dong wrote: > > > > Roy, > > > > > > > > I just read a paper "Preventing Denial of Service > > > > Attacks on Quality of Service", which is written by > > > > some guys from N.C. State university and UC Davis. > > > > The service quality to legimative users could be > > > > degraded by attacks on control flow or data flow. > > > > For example, an illegal user can forge a reservation > > > > message, so he can receive an unauthorized amount of > > > > resources. I just wanna to know what threats exist > > > > in providing QoS, and what the state-of-art > > > > techniques to prevent, detect and counter those > > > > attacks, and of course recovery mothods as well. > > > > > > > > Thx a lot. > > > > > > > > Dong > > > > > > > > > > > > Dong, > > > > Please be a little more precise in what you are > > > > asking for, i.e. > > > > > > > > 3-5 bullet list items on what kind of security you > > > > seek. > > > > > > > > Roy > > > > > > > > -----Original Message----- > > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > > Sent: Thursday, May 23, 2002 2:05 PM > > > > To: Security_Area_Advisory_Group; IPsec > > > > Subject: Secure QoS > > > > > > > > > > > > Hi, > > > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > > on that? Thx. > > > > > > > > Dong > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > > > > Get Tsinghua University free email account: > > > > www.tsinghua.com > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > _____________________________________________________________ > > > > Promote your group and strengthen ties to your > > > > members with email@yourgroup.org by Everyone.net > > > http://www.everyone.net/?btn=tag > > > > > > > > > ===== > > > In natural science, Nature has given us a world and we're just to > > > discover its laws. In computers, we can stuff laws into it and > > > create a world -- Alan Kay > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > LAUNCH - Your Yahoo! Music Experience > > > http://launch.yahoo.com > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri May 31 00:21:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7Lhg15344; Fri, 31 May 2002 00:21:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16555 Fri, 31 May 2002 02:31:35 -0400 (EDT) From: "Hannes Tschofenig" To: "Michael Thomas" , "Derek Atkins" Cc: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: IPsec and RSVP Date: Fri, 31 May 2002 08:49:06 +0200 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: <15604.64389.520614.112373@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi derek! > Derek, > > There are two different forms of crypto needed for > RSVP: a hop-by-hop integrity object and a policy > object. true. the policy object can additionally contain a integrity object (together with the other credentials there). > IPsec could in theory replace the > integrity object, but cannot replace the policy > object. Considering that there is no key > distribution for the hop-by-hop integrity objects, > IPsec might not be a bad choice in some > situations. > > Mike From owner-ipsec@lists.tislabs.com Fri May 31 00:24:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7ONg15888; Fri, 31 May 2002 00:24:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16556 Fri, 31 May 2002 02:31:38 -0400 (EDT) From: "Hannes Tschofenig" To: "S. Felix Wu" Cc: "Derek Atkins" , "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" Subject: RE: Date: Fri, 31 May 2002 08:49:05 +0200 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: <3CF509D5.C0530394@cs.ucdavis.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi felix! > > > It depends on what are the security requirements and threats. yes, this is always true. when looking at the threats for a qos signling protocol it had two problems: a) why do you really need end-to-end security if the protocol operates in a hop-by-hop manner. i understand if someone mentiones the accounting issues (who pays for what). but it is strange to introduce them all into a qos signaling protocol since there are other protocols that have to executed first in a typical application (i.e. rsvp or other qos signaling protocols will not be send between the two endpoints without running other protocols too - if used for end-to-end qos signaling). b) the threat about a malicous qos (rsvp) aware node. if an adversary manages to hack into a aaa, sip, etc. network element then he is obviously able to do many actions. why should this be different for rsvp (or other qos signaling protocols)? if an adversary is able to hack into the pdp, into an edge router, etc. then he is able to mount all types of attacks. who should this be prevented? the only difference between rsvp and for example aaa or sip is the possibly large number of nodes involved in the qos signaling. there is however an architectural question whether this is really necessary/practical since there are extensions that suggest that only the access network should store per-flow information (i.e. run rsvp) and the core networks have aggregated flows (trunks) for example based on diffserv. hence in practice the number of nodes is not as large as it might look at the first sight. additionally there is a strong desire to keep the latency (and bandwidth consumption with signaling) low. > In my opinion, RSVP security is really neither hop-by-hop nor > end-to-end (or I should say it is a mixture of both). it is definitely not end-to-end. with hop-by-hop you are right since there are two integrity objects: one within the rsvp message part of the message and the other one in the policy object. additionally there are credentials in the policy object. furtheremore there are policy aware and policy unaware nodes. > > Certain fields in RSVP are "mutable" (for example, maximum > available bandwidth along the route path), and therefore, a > pure end-to-end will not be possible. On the other hand, if > we assume (i.e., our threat model) that an intermediate RSVP > router (on the route path) can be malicious, then you need > some forms of end-to-end to protect at least those "static" > fields in an end-to-end fashion. i agree with you. rsvp has mutable and non-mutable fields but they are not labled as such (or there is no separation between mutable and non-mutalbe fields). hence it is difficult to simply protect them by adding an other "end-to-end integrity-object". additionally with this approach you obviously introduce key management protocols which might be not too easy to solve (establishing security associations between two arbitrary nodes turned out to be difficult lacking a global pki, or aaa/kerberos, etc. infrastructure. if some other protocols are executed before rsvp starts ( these protocols have already allowed to figure out who will pay for what) then these credentials (i call it opaque token) only need to be included into rsvp without a need to add end-to-end security issues into rsvp itself and allow other protocols to do that (e.g. sip). there is obviously a need to have a interaction with other protocols including diameter (aaa in general) since accounting records need to be produced and transmitted to the appropriate locations. > > My students and I studied this problem a few years ago and the > following is a web link to our paper: > > http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.pdf > > This work is somewhat old, but hopefully it will provide some > information about the technical difficulties in dealing with > RSVP security. thanks. i read it some time ago. i do not remember it exactly but i think you did not propose to use end-to-end security - it was more like a network to network hop security using digital signatures. ciao hannes > -Felix > > > Hannes Tschofenig wrote: > > > > hi > > > > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp > > capable router)? > > > > ciao > > hannes > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins > > > Sent: Saturday, May 25, 2002 5:01 AM > > > To: SatishK Amara > > > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group > > > Subject: Re: > > > > > > > > > Because IPsec is hop-by-hop but you want RSVP end-to-end. > > > > > > -derek > > > > > > SatishK Amara writes: > > > > > > > Why don't you use IPSEC to secure RSVP. > > > > > > > > Satish Amara > > > > --- Dong wrote: > > > > > Roy, > > > > > > > > > > I just read a paper "Preventing Denial of Service > > > > > Attacks on Quality of Service", which is written by > > > > > some guys from N.C. State university and UC Davis. > > > > > The service quality to legimative users could be > > > > > degraded by attacks on control flow or data flow. > > > > > For example, an illegal user can forge a reservation > > > > > message, so he can receive an unauthorized amount of > > > > > resources. I just wanna to know what threats exist > > > > > in providing QoS, and what the state-of-art > > > > > techniques to prevent, detect and counter those > > > > > attacks, and of course recovery mothods as well. > > > > > > > > > > Thx a lot. > > > > > > > > > > Dong > > > > > > > > > > > > > > > Dong, > > > > > Please be a little more precise in what you are > > > > > asking for, i.e. > > > > > > > > > > 3-5 bullet list items on what kind of security you > > > > > seek. > > > > > > > > > > Roy > > > > > > > > > > -----Original Message----- > > > > > From: Dong [mailto:dong_wei@tsinghua.com] > > > > > Sent: Thursday, May 23, 2002 2:05 PM > > > > > To: Security_Area_Advisory_Group; IPsec > > > > > Subject: Secure QoS > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I am trying to do a survey on Secure QoS. Any paper > > > > > on that? Thx. > > > > > > > > > > Dong > > > > > > > > > > > > > > _____________________________________________________________ > > > > > Get Tsinghua University free email account: > > > > > www.tsinghua.com > > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > > > > > Get Tsinghua University free email account: > > > > > www.tsinghua.com > > > > > Web site sponsored and hosted by AtFreeWeb.com > > > > > > > > > > > > > > _____________________________________________________________ > > > > > Promote your group and strengthen ties to your > > > > > members with email@yourgroup.org by Everyone.net > > > > http://www.everyone.net/?btn=tag > > > > > > > > > > > > ===== > > > > In natural science, Nature has given us a world and we're just > > > to discover its laws. In computers, we can stuff laws into it and > > > create a world -- Alan Kay > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > LAUNCH - Your Yahoo! Music Experience > > > > http://launch.yahoo.com > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > > warlord@MIT.EDU PGP key available > > -- > ---------------------------------------------------------------------- > Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu > Associate Professor http://www.cs.ucdavis.edu/~wu > Computer Science Department office: 1-530-754-7070 > University of California at Davis fax: 1-530-752-4767 > ---------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri May 31 00:24:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7ONg15889; Fri, 31 May 2002 00:24:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16588 Fri, 31 May 2002 02:39:37 -0400 (EDT) From: "Hannes Tschofenig" To: "SatishK Amara" , , "IPsec" , "Security_Area_Advisory_Group" , "Michael Thomas" , "Derek Atkins" Subject: end-to-end security and proxy rsvp Date: Fri, 31 May 2002 08:49:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi from the previous mails i read that some of you would like to see end-to-end security in a qos signaling protocol. i don't know how many of you have read the draft about proxy rsvp where a node along the path simply acts on behalf of an end-node. if using end-to-end security within rsvp then the proxy rsvp case is quite difficult in the sense that the other end-host (although possibly not rsvp capable) has to transmit credentials to (an possibly unknown) rsvp proxy to let him act on his behalf. what do you think? is there a security problem with the proxy rsvp approach? see draft: draft-ietf-rsvp-proxy-03.txt (there might also be similar issues related to the draft localized rsvp draft-manner-lrsvp-00.txt which also uses proxy ideas). ciao hannes From owner-ipsec@lists.tislabs.com Fri May 31 01:42:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V8gHg26434; Fri, 31 May 2002 01:42:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16840 Fri, 31 May 2002 03:57:20 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Thu May 30 15:52:26 2002 Message-ID: <000a01c207e0$4839a000$2daafea9@amanda2> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Davenport Michael" Cc: References: Subject: Re: [saag] Re: Date: Thu, 30 May 2002 16:45:36 +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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike I believe most big vendors are looking at it right now, see http://www.omg.org Ahmed ----- Original Message ----- From: "Davenport Michael" To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" Sent: Thursday, May 30, 2002 4:16 PM Subject: RE: [saag] Re: > Ahmed: > > I never heard of COBRA routers. Do you have info or a link I can go to? > Sounds interesting.... > > v/r, > > Mike > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Prof. Ahmed Bin Abbas > Ahmed Ali Adas > Sent: Wednesday, May 29, 2002 5:45 PM > To: Hannes Tschofenig; Melinda Shore > Cc: IPsec; Security_Area_Advisory_Group > Subject: Re: [saag] Re: > > > Hi > > The best approach in my view is to use CORBA and CORBsec to deal with path > messages, I believe if CORBA routers can be realized very soon, most of your > IPsec shortcomings will be resolved. > > Ahmed > ----- Original Message ----- > From: "Melinda Shore" > To: "Hannes Tschofenig" > Cc: "IPsec" ; "Security_Area_Advisory_Group" > > Sent: Wednesday, May 29, 2002 5:06 PM > Subject: RE: [saag] Re: > > > > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote: > > >do you think that the hop-by-hop security in rsvp is a good or a bad > thing? > > >should there be more than what is currently provided? > > > > There needs to be more than what is currently provided, > > but, as always, there's a big keying/cert problem, particularly > > in a multi-"domain" environment. I don't think the threat > > environment is particularly well-understood (I've seen your > > NSIS draft but haven't gone through it in detail). Clearly > > IPSec is not the right answer for Path messages, however, > > because while the addressing is end-to-end the payload > > contents do change as the packet transits participating > > routers. > > > > Melinda > > > From owner-ipsec@lists.tislabs.com Fri May 31 08:34:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VFYPg25286; Fri, 31 May 2002 08:34:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17582 Fri, 31 May 2002 10:35:28 -0400 (EDT) From: "David A. Mcgrew" To: "Theodore Ts'o" , "Andrew Krywaniuk" Cc: Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt Date: Fri, 31 May 2002 07:47:46 -0700 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: <20020530154839.GA3903@think.thunk.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, Andrew, > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o > Sent: Thursday, May 30, 2002 8:49 AM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt > > > On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote: > > This draft hasn't really been discussed on the list much. I guess people > > figure that "hey, it's just another crypto algorithm... there can't be > > anything controversial about it". > > > > The issue which Dave brought up at the meeting and which I sent to the > > authors is that XCBC-MAC skirts the "obvious" solution of prepending the > > length of the buffer to the hash input. There is an engineering tradeoff > > here, which is not mentioned in the draft. > > > > AES-XCBC-MAC: > > a) requires 384 bits of keymat > > b) does not require that the length of the message be pre-computed > > > > The "obvious" solution: > > a) requires 128 bits of keymat > > b) requires that the length of the message be pre-computed > > > > Clearly, issue (b) was an important motivation in the design of > XCBC-MAC. > > > > My personal opinion is that this rationale makes sense, since > key storage > > capacity is unlikely to be the limiting factor in the design of > any future > > hardware. However, the tradeoff ought to at least be discussed > on the list > > and acknowledged in the draft. > > A week has gone by and there doesn't appear to have been any > discussion on this point which Andrew has raised. Does anybody think > that the extra use of keying material used by AES-XCBC-MAC is a > problem? We will assume that silence means people are OK with it as > it currently stands. I agree with Andrew on this point (and was on vacation for the last week :-). IMO it makes sense for the WG to record that kind of rationale, and the draft is the natural place to do that. As for the tradeoff, XCBC-MAC seems like a fine choice to me, though hardware vendors may not like the increased memory requirement. David > > Andrew, how strongly do you feel about requesting the draft be > modified to include discussion of this tradeoff? I suspect that if > you contribute text to the document authors, it would probably > increase the likelihood that the draft will include discussion on this > point. :-) > > - Ted From owner-ipsec@lists.tislabs.com Fri May 31 10:23:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VHNag02010; Fri, 31 May 2002 10:23:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17809 Fri, 31 May 2002 12:25:08 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "'David A. Mcgrew'" , "'Theodore Ts'o'" , "'Andrew Krywaniuk'" Cc: Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt Date: Fri, 31 May 2002 09:37:37 -0700 Organization: Vesta Corporation Message-ID: <001101c208c1$79e471c0$beb9fea9@Yellowstone> 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.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The increased amount of memory is one consideration; another is the increased memory bandwidth. My estimate is that storing three keys instead of storing just one key will add about 10% to the memory bandwidth for SA accesses. But you also have the option of storing just the original key and generating K1, K2, and K3 on the fly. With proper pipelining it will affect latency but not throughput. So another trade-off is (amount of memory, memory bandwidth) vs. (number of gates). Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of David A. Mcgrew > Sent: Friday, May 31, 2002 7:48 AM > To: Theodore Ts'o; Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt > > Ted, Andrew, > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o > > Sent: Thursday, May 30, 2002 8:49 AM > > To: Andrew Krywaniuk > > Cc: ipsec@lists.tislabs.com > > Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt > > > > > > On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote: > > > This draft hasn't really been discussed on the list much. I guess > people > > > figure that "hey, it's just another crypto algorithm... there can't be > > > anything controversial about it". > > > > > > The issue which Dave brought up at the meeting and which I sent to the > > > authors is that XCBC-MAC skirts the "obvious" solution of prepending > the > > > length of the buffer to the hash input. There is an engineering > tradeoff > > > here, which is not mentioned in the draft. > > > > > > AES-XCBC-MAC: > > > a) requires 384 bits of keymat > > > b) does not require that the length of the message be pre-computed > > > > > > The "obvious" solution: > > > a) requires 128 bits of keymat > > > b) requires that the length of the message be pre-computed > > > > > > Clearly, issue (b) was an important motivation in the design of > > XCBC-MAC. > > > > > > My personal opinion is that this rationale makes sense, since > > key storage > > > capacity is unlikely to be the limiting factor in the design of > > any future > > > hardware. However, the tradeoff ought to at least be discussed > > on the list > > > and acknowledged in the draft. > > > > A week has gone by and there doesn't appear to have been any > > discussion on this point which Andrew has raised. Does anybody think > > that the extra use of keying material used by AES-XCBC-MAC is a > > problem? We will assume that silence means people are OK with it as > > it currently stands. > > I agree with Andrew on this point (and was on vacation for the last week > :-). IMO it makes sense for the WG to record that kind of rationale, and > the draft is the natural place to do that. > > As for the tradeoff, XCBC-MAC seems like a fine choice to me, though > hardware vendors may not like the increased memory requirement. > > David > > > > > Andrew, how strongly do you feel about requesting the draft be > > modified to include discussion of this tradeoff? I suspect that if > > you contribute text to the document authors, it would probably > > increase the likelihood that the draft will include discussion on this > > point. :-) > > > > - Ted From owner-ipsec@lists.tislabs.com Fri May 31 11:43:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VIhSg05193; Fri, 31 May 2002 11:43:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18027 Fri, 31 May 2002 13:51:51 -0400 (EDT) Date: 31 May 2002 13:52:59 -0400 Message-ID: <001c01c208cc$01eaa260$696ae640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'=SMTP" Cc: "'=SMTP" Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20020530154839.GA3903@think.thunk.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > A week has gone by and there doesn't appear to have been any > discussion on this point which Andrew has raised. Does anybody think > that the extra use of keying material used by AES-XCBC-MAC is a > problem? We will assume that silence means people are OK with it as > it currently stands. Okay, so either everyone agrees with the design decision or no one cares. On this list, it's usually best to assume the latter. > Andrew, how strongly do you feel about requesting the draft be > modified to include discussion of this tradeoff? I suspect that if > you contribute text to the document authors, it would probably > increase the likelihood that the draft will include discussion on this > point. :-) I'm not fanatical about this particular issue, but I think that many drafts could benefit from some explanation of the design rationale. This may save us a bunch of redundant questions on the mailing list 2 years from now (the downside being that vague drafts may be more likely to progress to RFC if no one can find anything concrete to object to). XCBC-MAC does not appear to be controversial, so it would be better to document the design decision, especially since the crucial reference in the draft [XCBC-MAC-1] is a broken link. I already suggested this to the authors by private e-mail some time back. It could be as simple as a 2 sentence add-on: AES-XCBC-MAC-96 actually requires 384 bits of keying material (128 bits for the AES keysize + 2 times the blocksize). This keying mate- rial can either be provided through the key generation mechanism or it can be generated from a single 128-bit key. The latter approach has been selected for AES-XCBC-MAC-96, since it is analogous to other authenticators used within IPsec. "The reason XCBC-MAC uses 3 keys is so the length of the input stream does not need to be known in advance. This may be useful for systems that do one-pass assembly of large packets." Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Thursday, May 30, 2002 11:49 AM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt > > > On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote: > > This draft hasn't really been discussed on the list much. I > guess people > > figure that "hey, it's just another crypto algorithm... > there can't be > > anything controversial about it". > > > > The issue which Dave brought up at the meeting and which I > sent to the > > authors is that XCBC-MAC skirts the "obvious" solution of > prepending the > > length of the buffer to the hash input. There is an > engineering tradeoff > > here, which is not mentioned in the draft. > > > > AES-XCBC-MAC: > > a) requires 384 bits of keymat > > b) does not require that the length of the message be pre-computed > > > > The "obvious" solution: > > a) requires 128 bits of keymat > > b) requires that the length of the message be pre-computed > > > > Clearly, issue (b) was an important motivation in the > design of XCBC-MAC. > > > > My personal opinion is that this rationale makes sense, > since key storage > > capacity is unlikely to be the limiting factor in the > design of any future > > hardware. However, the tradeoff ought to at least be > discussed on the list > > and acknowledged in the draft. > > A week has gone by and there doesn't appear to have been any > discussion on this point which Andrew has raised. Does anybody think > that the extra use of keying material used by AES-XCBC-MAC is a > problem? We will assume that silence means people are OK with it as > it currently stands. > > Andrew, how strongly do you feel about requesting the draft be > modified to include discussion of this tradeoff? I suspect that if > you contribute text to the document authors, it would probably > increase the likelihood that the draft will include discussion on this > point. :-) > > - Ted > From owner-ipsec@lists.tislabs.com Fri May 31 15:54:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VMsjg11734; Fri, 31 May 2002 15:54:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18332 Fri, 31 May 2002 18:07:40 -0400 (EDT) X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD0174A7C3@mailserver.sylantro.com> From: "Eric Nielsen" To: ipsec@lists.tislabs.com Subject: Public Keys to initiate IPsec. Date: Fri, 31 May 2002 15:14:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10E92A45557198-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have been listening in on the IPsec discussion (as best as I can) for some time, but I am sure my question/suggestion will show naivety to many aspects of IPsec, but I must ask. I am having trouble deciphering IPsec to determine the best way to deploy it in large scale. I have an idea of how it might work and would like to test these ideas out, or at least set me straight so I can find the best way to move forward deploying IPsec based security. IPsec communications work well once setup. But key and session management is less straightforward. IKE, JFK, and IKEv2 provide means to bootstrap the process of setting up a secure connection, but I worry about the potential performance impacts of thousands of simultaneous restarts when a server recovers. Administration must be minimized, too. The deployment in mind has * > 10,000 clients to a server. * The clients are small, embedded systems * Can make restriction that secure connections are always initiated by the client * A trust relationship will persist with that client unless some administrative action is taken to remove that trust. * Will use Transport mode AH I would like some level of trust to persist beyond one point in time, or to be distributed among servers. I have focused on performing the IKE Phase 1 negotiations faster and simpler to administer: IKE Phase 1 negotiations include: - negotiation of security parameters - establish a shared secret - authenticate identities. Here is a process that I think might perform that work. ======================================================================= Step 1: Before setting up the network connection both sides would be provided a human password grade shared secret key, one that non- technical people will not fear or mis-type. This is outside of IPsec. Step 2: To initiate the process of creating a secure communication path, the embedded unit would generate a large private/public key pair (e.g., RSA with at minimum 1028 bits). [an issue here is key randomness]. Step 3: One end point will contact the other with negotiation parameters. In addition to the already defined parameters, that (big) packet would include: - the endpoint's public key - an [optional] endpoint identifier - a signature that covers the public key, endpoint ID, and private shared password. The receiver will first validate the ID (it any) for: a) is the ID one that the server will service? b) is the ID is valid still for first-time initiation of a secure relationship? After this simple validation the receiver could then do the more processor intensive work validating the signature in the negotiation request. If the receiver does not include this capability, it will ignore these negotiation parameters and proceed down another path. Step 4: A response is crafted that selects this type of negotiation. The response includes the public key signed in the same way as in step 2. Upon completion of Step 4 the two ends have authenticated, authorized, and have securely exchanged public keys. It looks like the two ends are ready for Phase 2 to create/share session keys. They may be symmetric keys for ESP or a private/public key pair for AH. Beyond Initialization: It would be best if the Phase 1 public keys were durable, being renegotiated only on an as needed basis. Phase 1 negotiations should persist past IP address changes. Each end can attempt to re-initiate Phase 1 to create a new durable public/private key pair. Each new key requires a signature using the prior durable key. Either end can refuse the update by policy, and then have the option to terminate the trust relationship, thus requiring a new password to start the initialization process from square one. This Phase 1 negotiated information may be shared among servers to assure smooth disaster recovery. Upon recovery the server receiving IPsec packets would reply that the session has expired and then recreate only the Phase 2 exchange. ======================================================================== All that said, is there a streamlined process like this I can implement within IPsec/IKE/IKEv2/JFK today? Are there key differences or security holes that may or may not make it possible to use this kind of process? Thank you for your attention, Eric Eric Nielsen Chief Technology Strategist Sylantro Systems Corporation http://www.sylantro.com 910 E. Hamilton Ave. Campbell, CA 95008 USA +1.408.626.2345 From owner-ipsec@lists.tislabs.com Fri May 31 20:52:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g513q1g16253; Fri, 31 May 2002 20:52:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA18701 Fri, 31 May 2002 23:05:15 -0400 (EDT) Message-ID: <08a101c2091b$0281c060$1f02a8c0@entrust.com> From: "Greg Carter" To: References: <79FEAA5FABA7D411BF580001023D1BBD0174A7C3@mailserver.sylantro.com> Subject: Re: Public Keys to initiate IPsec. Date: Fri, 31 May 2002 23:18:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Eric Nielsen" Subject: Public Keys to initiate IPsec. >They may be symmetric keys for ESP or a private/public key pair for AH. AH uses symmetric based cryptography. > ======================================================================== > All that said, is there a streamlined process like this I can implement > within IPsec/IKE/IKEv2/JFK today? Not really, at least not in IKE v1. >Are there key differences or security > holes that may or may not make it possible to use this kind of process? What you have describe as your phase one is in essence a PKI and enrolling a client into that PKI with the one time password. IKE assumes that you already have the trust relationship in place, either through a shared key or via a certified public key. All(!)you are doing in IKE is verifying the identity, you are not managing the identities credentials within your trust 'hierarchy'. Combining the two operations would unnecessarily complicate IKE. Check out the PKIX working group, specifically RFC 2510, and/or RFC 2797. But I would look into finding more about SCEP before implementing 2797 if you want an "on line" enrolment protocol. Bye. Greg.