From owner-ietf-mode-cfg Mon Oct 23 10:16:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19116 for ietf-mode-cfg-bks; Mon, 23 Oct 2000 10:16:32 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19107 for ; Mon, 23 Oct 2000 10:16:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 23 Oct 2000 10:21:32 -0700 To: ietf-mode-cfg@vpnc.org From: Paul Hoffman / VPNC Subject: Starting this list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings. The purpose of this list is to discuss the mode-cfg protocol. This list was started so that current mode-cfg implementors can discuss the current draft and make sure that they interoperate. mode-cfg is out scope for the IPsec WG until the son-of-IKE document is finished, but some of you are already shipping products, and some of you are having interop problems. Please use this list to discuss the current draft and your implementations. Note that it is likely that the IPSRA WG will have a very different mechanism for getting remote access users configured, and it is likely that this mechanism will be on standards track (whereas it is likely that mode-cfg will not be on standards track any time soon). That should not color your discussion of mode-cfg, but it should certainly be considered in your implementation plans. --Paul Hoffman, Director --VPN Consortium From owner-ietf-mode-cfg Thu Feb 22 13:16:16 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA05182 for ietf-mode-cfg-bks; Thu, 22 Feb 2001 13:16:16 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA05173 for ; Thu, 22 Feb 2001 13:16:14 -0800 (PST) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA20369; Thu, 22 Feb 2001 13:12:20 -0800 (PST) Received: from ddukesnt4 (ott-b1-dhcp-10-85-28-189.cisco.com [10.85.28.189]) by toque.cisco.com (Mirapoint) with SMTP id ABO57254; Thu, 22 Feb 2001 16:11:59 -0500 (EST) Message-ID: <011801c09d14$4095f4d0$bd1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: , Cc: "Dan Harkins" References: <200102221759.f1MHxi661117@potassium.cips.nokia.com> Subject: Re: exchange type 6? Date: Thu, 22 Feb 2001 16:13:07 -0500 Organization: Cisco Systems 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As far as 6 goes, the fact is that we have a lot of companies using it now. Changing it, or having something else get assigned 6 will do exactly what Ari stated (confusion, interop issues, etc.). Using 6 or some other arbitrary large number has nothing to do with security. If there is something stopping me from requesting and getting 6 from IANA please let me know. I saw nothing in 2408 or 2409 that would stop a non-standards track RFC that has broad industry use and interop from getting assigned 6. 2408 limits IANA to assign numbers to Standards Track RFCs only WRT: - DOI and Supported Security Protocols http://www.isi.edu/in-notes/iana/assignments/isakmp-registry 2409 limits IANA to assign numbers to Standards Track RFCs only WRT: - Attribute Classes - Encryption Algorithm Class - Hash Algorithm - Group Description and Group Type - Life Type If this is incorrect, or I'm missing some other limitations please advise me. If anyone wants to discuss/comment on mode-cfg or its implementation feel free to subscribe/post to: ietf-mode-cfg@vpnc.org Darren ----- Original Message ----- From: "Dan Harkins" To: "Ari Huttunen" Cc: "Derrell Piper" ; ; Sent: Thursday, February 22, 2001 12:59 PM Subject: Re: exchange type 6? Wow, I'm having flashbacks of the 40bit DES arguments. You can provide your customers with a proprietary protocol to satisfy their desires. You don't need to take valid exchange types from a standard's track protocol to do it though. One of the happy byproducts of this working group is that lots of money is being made selling products based on these protocols but let's not put the cart in front of the horse. We are here to develop and standardize secure protocols not to make life easier for companies that chose time-to-market over security. Dan. On Thu, 22 Feb 2001 18:20:14 +0200 you wrote > I think this statement "it's our charter to provide secure protocols and > standardizing anything less is unacceptable to some of us" is exactly > THE PROBLEM. > > Note that you didn't say that it's anywhere in this working group's charter > to enhance the security of the actual products out there. If this was the > case, this working group would stop actively demanding changes in the > way actual products in the field are working. Every change in the protocol > potentially introduces more vulnerabilities in the implementations, many > of which need to support several different versions of the protocol. Actual > implementations, and most notably something that customers have spent a whole > lot of money in, change slowly. > > I couldn't care less if there's been discussion that exchange type 6 is > not to be used, or whether any document says exchange type 6 is not to be > used, or any WG chair or security advisor or whatever. Our customers need > to interoperate with others who have products using exchange type 6. It's > as simple as that. > > I can understand that some of you don't like these protocols. As a matter > of fact, I don't like these protocols either. Just please stop making our > life any more harder than it already is. > > Ari > > Derrell Piper wrote: > > > > Will, > > > > I just don't agree with allocating a reserved number to Config/XAUTH. > > XAUTH was not adopted because it has serious security problems. We did > > think about this. The problem is that there's been essentially no progress > > on adopting a viable alternative (e.g. CRACK or Hybrid) so people continue > > to use what they've got. However, it's our charter to provide secure > > protocols and standardizing anything less is unacceptable to some of us. > > > > Derrell > > -- > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-mode-cfg Thu Feb 22 14:10:34 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA08108 for ietf-mode-cfg-bks; Thu, 22 Feb 2001 14:10:34 -0800 (PST) Received: from potassium.cips.nokia.com (Potassium.Network-Alchemy.COM [199.46.17.146]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA08104 for ; Thu, 22 Feb 2001 14:10:33 -0800 (PST) Received: from potassium.cips.nokia.com (localhost [127.0.0.1]) by potassium.cips.nokia.com (8.11.1/8.11.1) with ESMTP id f1MM9D661586; Thu, 22 Feb 2001 14:09:13 -0800 (PST) (envelope-from dharkins@potassium.cips.nokia.com) Message-Id: <200102222209.f1MM9D661586@potassium.cips.nokia.com> To: "Darren Dukes" cc: ietf-mode-cfg@vpnc.org Subject: Re: exchange type 6? In-Reply-To: Your message of "Thu, 22 Feb 2001 16:13:07 EST." <011801c09d14$4095f4d0$bd1c550a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61583.982879753.1@potassium.cips.nokia.com> Date: Thu, 22 Feb 2001 14:09:13 -0800 From: Dan Harkins Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Number 6 is reserved to ISAKMP. Mode-cfg is not part of ISAKMP. But if, as you say, there's nothing stopping anyone I think I'll go register exchange number 6 since it says nothing about vagueries like "broad industry use". Bye! Dan. P.S. do you see the problem now? P.P.S. the Hybrid guys tried this already and failed so don't bother. On Thu, 22 Feb 2001 16:13:07 EST you wrote > > As far as 6 goes, the fact is that we have a lot of companies using it now. > Changing it, or having something else get assigned 6 will do exactly what > Ari stated (confusion, interop issues, etc.). Using 6 or some other > arbitrary large number has nothing to do with security. > > If there is something stopping me from requesting and getting 6 from IANA > please let me know. I saw nothing in 2408 or 2409 that would stop a > non-standards track RFC that has broad industry use and interop from getting > assigned 6. > > 2408 limits IANA to assign numbers to Standards Track RFCs only WRT: > - DOI and Supported Security Protocols > http://www.isi.edu/in-notes/iana/assignments/isakmp-registry > > 2409 limits IANA to assign numbers to Standards Track RFCs only WRT: > - Attribute Classes > - Encryption Algorithm Class > - Hash Algorithm > - Group Description and Group Type > - Life Type > > If this is incorrect, or I'm missing some other limitations please advise > me. > > If anyone wants to discuss/comment on mode-cfg or its implementation feel > free to subscribe/post to: > ietf-mode-cfg@vpnc.org > > Darren > > ----- Original Message ----- > From: "Dan Harkins" > To: "Ari Huttunen" > Cc: "Derrell Piper" ; ; > > Sent: Thursday, February 22, 2001 12:59 PM > Subject: Re: exchange type 6? > > > Wow, I'm having flashbacks of the 40bit DES arguments. You can provide > your customers with a proprietary protocol to satisfy their desires. You > don't need to take valid exchange types from a standard's track protocol > to do it though. > > One of the happy byproducts of this working group is that lots of > money is being made selling products based on these protocols but let's > not put the cart in front of the horse. We are here to develop and > standardize secure protocols not to make life easier for companies that > chose time-to-market over security. > > Dan. > > On Thu, 22 Feb 2001 18:20:14 +0200 you wrote > > I think this statement "it's our charter to provide secure protocols and > > standardizing anything less is unacceptable to some of us" is exactly > > THE PROBLEM. > > > > Note that you didn't say that it's anywhere in this working group's > charter > > to enhance the security of the actual products out there. If this was the > > case, this working group would stop actively demanding changes in the > > way actual products in the field are working. Every change in the protocol > > potentially introduces more vulnerabilities in the implementations, many > > of which need to support several different versions of the protocol. > Actual > > implementations, and most notably something that customers have spent a > whole > > lot of money in, change slowly. > > > > I couldn't care less if there's been discussion that exchange type 6 is > > not to be used, or whether any document says exchange type 6 is not to be > > used, or any WG chair or security advisor or whatever. Our customers need > > to interoperate with others who have products using exchange type 6. It's > > as simple as that. > > > > I can understand that some of you don't like these protocols. As a matter > > of fact, I don't like these protocols either. Just please stop making our > > life any more harder than it already is. > > > > Ari > > > > Derrell Piper wrote: > > > > > > Will, > > > > > > I just don't agree with allocating a reserved number to Config/XAUTH. > > > XAUTH was not adopted because it has serious security problems. We did > > > think about this. The problem is that there's been essentially no > progress > > > on adopting a viable alternative (e.g. CRACK or Hybrid) so people > continue > > > to use what they've got. However, it's our charter to provide secure > > > protocols and standardizing anything less is unacceptable to some of us. > > > > > > Derrell > > > > -- > > Ari Huttunen phone: +358 9 2520 0700 > > Software Architect fax : +358 9 2520 5001 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security > From owner-ietf-mode-cfg Fri Feb 23 01:35:40 2001 Received: by above.proper.com (8.9.3/8.9.3) id BAA22683 for ietf-mode-cfg-bks; Fri, 23 Feb 2001 01:35:40 -0800 (PST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA22670; Fri, 23 Feb 2001 01:35:38 -0800 (PST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id EAA27975; Fri, 23 Feb 2001 04:26:21 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA2PmzF_; Fri Feb 23 04:26:20 2001 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP; Fri, 23 Feb 2001 04:33:54 -0500 Received: from andrewk3 ([138.120.114.30]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA704; Fri, 23 Feb 2001 04:33:54 -0500 Reply-To: From: "Andrew Krywaniuk" To: Subject: Attribute Encoding Date: Fri, 23 Feb 2001 04:31:54 -0500 Message-Id: <003901c09d7b$75ea4700$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, The Config Mode draft lists a whole bunch of attributes which are encoded as either 0 or 4 bytes. When you send the request with the 0 byte version, it would seem that the best way to encode the attribute is: AF=0, type=whatever, length=0. However, let us imagine that you received the attribute encoded as: AF=1, type=whatever, data=0. Do you feel this is implicitly allowed by the draft? Would this break your sgw implementation if you received it? (Obviously, this doesn't affect the operation of the client.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-mode-cfg Fri Feb 23 08:05:01 2001 Received: by above.proper.com (8.9.3/8.9.3) id IAA25638 for ietf-mode-cfg-bks; Fri, 23 Feb 2001 08:05:01 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25629 for ; Fri, 23 Feb 2001 08:05:00 -0800 (PST) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA00369; Fri, 23 Feb 2001 08:04:47 -0800 (PST) Received: from ddukesnt4 (ott-b1-dhcp-10-85-28-189.cisco.com [10.85.28.189]) by toque.cisco.com (Mirapoint) with SMTP id ABO67463; Fri, 23 Feb 2001 11:04:31 -0500 (EST) Message-ID: <01c201c09db2$76d51730$bd1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: , References: <003901c09d7b$75ea4700$1e72788a@andrewk3.ca.alcatel.com> Subject: Re: Attribute Encoding Date: Fri, 23 Feb 2001 11:05:38 -0500 Organization: Cisco Systems 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew, The draft says, Zero length attribute values are usually sent in a Request. Not always, so you should treat the AF=1 case the same as if you received: AF=0, type=whatever, length=4, data=0. It is valid for a request to contain attributes with non-zero lengths, they are to be taken as suggested values for the SGW to use. It is up to the SGW as to whether or not they want to ignore the proposed value. The only place where I could see a problem with the AF=1 case is if the type has a length greater than four bytes. Then it is up to the SGW as to whether it will ignore the request or just ignore the invalid data. Darren ----- Original Message ----- From: "Andrew Krywaniuk" To: Sent: Friday, February 23, 2001 4:31 AM Subject: Attribute Encoding Hi, The Config Mode draft lists a whole bunch of attributes which are encoded as either 0 or 4 bytes. When you send the request with the 0 byte version, it would seem that the best way to encode the attribute is: AF=0, type=whatever, length=0. However, let us imagine that you received the attribute encoded as: AF=1, type=whatever, data=0. Do you feel this is implicitly allowed by the draft? Would this break your sgw implementation if you received it? (Obviously, this doesn't affect the operation of the client.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-mode-cfg Fri Feb 23 10:54:26 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA05138 for ietf-mode-cfg-bks; Fri, 23 Feb 2001 10:54:26 -0800 (PST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA05134 for ; Fri, 23 Feb 2001 10:54:24 -0800 (PST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id NAA07733 for ; Fri, 23 Feb 2001 13:45:11 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA00I3AD; Fri Feb 23 13:45:10 2001 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-mode-cfg@vpnc.org; Fri, 23 Feb 2001 13:49:41 -0500 Received: from andrewk3 ([138.120.114.30]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA6F24; Fri, 23 Feb 2001 13:49:40 -0500 Reply-To: From: "Andrew Krywaniuk" To: "'Darren Dukes'" , Subject: RE: Attribute Encoding Date: Fri, 23 Feb 2001 13:47:40 -0500 Message-Id: <006401c09dc9$19fa5f40$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <01c201c09db2$76d51730$bd1c550a@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My point here was that > AF=1, type=whatever, data=0. literally translates to > AF=0, type=whatever, length=2, data=0. rather than > AF=0, type=whatever, length=4, data=0. and I was wondering whether anyone is going to barf if they recieve a message which is encoded that way. (Although it is clear from #ifdef SEND_AS_SHORT_AS_POSSIBLE that at some point in time the code gremlins felt that the above two expressions were equivalent.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ietf-mode-cfg@mail.vpnc.org > [mailto:owner-ietf-mode-cfg@mail.vpnc.org]On Behalf Of Darren Dukes > Sent: Friday, February 23, 2001 11:06 AM > To: andrew.krywaniuk@alcatel.com; ietf-mode-cfg@vpnc.org > Subject: Re: Attribute Encoding > > > Andrew, > > The draft says, Zero length attribute values are usually sent > in a Request. > Not always, so you should treat the AF=1 case the same as if > you received: > > AF=0, type=whatever, length=4, data=0. > > It is valid for a request to contain attributes with non-zero > lengths, they > are to be taken as suggested values for the SGW to use. It > is up to the SGW > as to whether or not they want to ignore the proposed value. > > The only place where I could see a problem with the AF=1 case > is if the type > has a length greater than four bytes. Then it is up to the SGW as to > whether it will ignore the request or just ignore the invalid data. > > Darren > > ----- Original Message ----- > From: "Andrew Krywaniuk" > To: > Sent: Friday, February 23, 2001 4:31 AM > Subject: Attribute Encoding > > > Hi, > > The Config Mode draft lists a whole bunch of attributes which > are encoded as > either 0 or 4 bytes. When you send the request with the 0 > byte version, it > would seem that the best way to encode the attribute is: > > AF=0, type=whatever, length=0. > > However, let us imagine that you received the attribute encoded as: > > AF=1, type=whatever, data=0. > > Do you feel this is implicitly allowed by the draft? Would > this break your > sgw implementation if you received it? (Obviously, this > doesn't affect the > operation of the client.) > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > > From owner-ietf-mode-cfg Fri Feb 23 11:32:57 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA06812 for ietf-mode-cfg-bks; Fri, 23 Feb 2001 11:32:57 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA06808 for ; Fri, 23 Feb 2001 11:32:56 -0800 (PST) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA24579 for ; Fri, 23 Feb 2001 11:32:31 -0800 (PST) Received: from ddukesnt4 (ott-b1-dhcp-10-85-28-189.cisco.com [10.85.28.189]) by toque.cisco.com (Mirapoint) with SMTP id ABO72582; Fri, 23 Feb 2001 14:32:26 -0500 (EST) Message-ID: <000a01c09dcf$832699b0$bd1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: References: <006401c09dc9$19fa5f40$1e72788a@andrewk3.ca.alcatel.com> Subject: Re: Attribute Encoding Date: Fri, 23 Feb 2001 14:33:34 -0500 Organization: Cisco Systems 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yep Andrew, I screwed up the length field in my description. The last comment still applies though, a SGW could still accept the request and ignore the invalid data. I'll see how we're handling this in some of our products. Darren ----- Original Message ----- From: "Andrew Krywaniuk" To: "'Darren Dukes'" ; Sent: Friday, February 23, 2001 1:47 PM Subject: RE: Attribute Encoding My point here was that > AF=1, type=whatever, data=0. literally translates to > AF=0, type=whatever, length=2, data=0. rather than > AF=0, type=whatever, length=4, data=0. and I was wondering whether anyone is going to barf if they recieve a message which is encoded that way. (Although it is clear from #ifdef SEND_AS_SHORT_AS_POSSIBLE that at some point in time the code gremlins felt that the above two expressions were equivalent.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ietf-mode-cfg@mail.vpnc.org > [mailto:owner-ietf-mode-cfg@mail.vpnc.org]On Behalf Of Darren Dukes > Sent: Friday, February 23, 2001 11:06 AM > To: andrew.krywaniuk@alcatel.com; ietf-mode-cfg@vpnc.org > Subject: Re: Attribute Encoding > > > Andrew, > > The draft says, Zero length attribute values are usually sent > in a Request. > Not always, so you should treat the AF=1 case the same as if > you received: > > AF=0, type=whatever, length=4, data=0. > > It is valid for a request to contain attributes with non-zero > lengths, they > are to be taken as suggested values for the SGW to use. It > is up to the SGW > as to whether or not they want to ignore the proposed value. > > The only place where I could see a problem with the AF=1 case > is if the type > has a length greater than four bytes. Then it is up to the SGW as to > whether it will ignore the request or just ignore the invalid data. > > Darren > > ----- Original Message ----- > From: "Andrew Krywaniuk" > To: > Sent: Friday, February 23, 2001 4:31 AM > Subject: Attribute Encoding > > > Hi, > > The Config Mode draft lists a whole bunch of attributes which > are encoded as > either 0 or 4 bytes. When you send the request with the 0 > byte version, it > would seem that the best way to encode the attribute is: > > AF=0, type=whatever, length=0. > > However, let us imagine that you received the attribute encoded as: > > AF=1, type=whatever, data=0. > > Do you feel this is implicitly allowed by the draft? Would > this break your > sgw implementation if you received it? (Obviously, this > doesn't affect the > operation of the client.) > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > > From owner-ietf-mode-cfg Mon Feb 26 05:33:17 2001 Received: by above.proper.com (8.9.3/8.9.3) id FAA21578 for ietf-mode-cfg-bks; Mon, 26 Feb 2001 05:33:17 -0800 (PST) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA21574 for ; Mon, 26 Feb 2001 05:33:15 -0800 (PST) Received: from beach.sctc.com (root@localhost) by beach.sctc.com with ESMTP id f1QDXdP09667; Mon, 26 Feb 2001 07:33:39 -0600 (CST) Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com with ESMTP id f1QDXcx09663; Mon, 26 Feb 2001 07:33:39 -0600 (CST) Received: from stpsowk45 (stpsowk45.sctc.com [172.17.192.169]) by sphinx.sctc.com (8.8.8+Sun/8.7.3) with ESMTP id HAA26474; Mon, 26 Feb 2001 07:41:45 -0600 (CST) Received: from localhost (allison@localhost) by stpsowk45 (8.9.3+Sun/) with ESMTP id HAA25975; Mon, 26 Feb 2001 07:21:05 -0600 (CST) Date: Mon, 26 Feb 2001 07:21:04 -0600 (CST) From: Tylor Allison X-X-Sender: To: Andrew Krywaniuk cc: "'Darren Dukes'" , Subject: RE: Attribute Encoding In-Reply-To: <006401c09dc9$19fa5f40$1e72788a@andrewk3.ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 23 Feb 2001, Andrew Krywaniuk wrote: > My point here was that > > > AF=1, type=whatever, data=0. > > literally translates to > > > AF=0, type=whatever, length=2, data=0. > > rather than > > > AF=0, type=whatever, length=4, data=0. > > and I was wondering whether anyone is going to barf if they recieve a > message which is encoded that way. > > (Although it is clear from #ifdef SEND_AS_SHORT_AS_POSSIBLE that at some > point in time the code gremlins felt that the above two expressions were > equivalent.) > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > I think that somewhere in one of the documents (rfc.2408?) it mentions that variable length attributes MAY be encoded as basic attributes, if the variable value fits into the two-byte basic attribute value. This means that sending your example above, shouldn't break most people... as long as they attribute parsing code behaves as expected, and they use the same code to parse XAUTH attribs. This is the way we've done it... --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation From owner-ietf-mode-cfg Mon Feb 26 11:12:04 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA03760 for ietf-mode-cfg-bks; Mon, 26 Feb 2001 11:12:04 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA03756 for ; Mon, 26 Feb 2001 11:12:02 -0800 (PST) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA03954; Mon, 26 Feb 2001 11:11:18 -0800 (PST) Received: from ddukesnt4 (ott-b1-dhcp-10-85-28-189.cisco.com [10.85.28.189]) by toque.cisco.com (Mirapoint) with SMTP id ABQ10500; Mon, 26 Feb 2001 14:10:52 -0500 (EST) Message-ID: <006801c0a027$ffb6e980$bd1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: "Tylor Allison" , "Andrew Krywaniuk" Cc: References: Subject: Re: Attribute Encoding Date: Mon, 26 Feb 2001 14:12:01 -0500 Organization: Cisco Systems 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tylor and Andrew, our VPN 3000 handles (i.e., doesn't break or ignore) the AF=1 case too. Darren From: "Tylor Allison" > On Fri, 23 Feb 2001, Andrew Krywaniuk wrote: > > > My point here was that > > > > > AF=1, type=whatever, data=0. > > > > literally translates to > > > > > AF=0, type=whatever, length=2, data=0. > > > > rather than > > > > > AF=0, type=whatever, length=4, data=0. > > > > and I was wondering whether anyone is going to barf if they recieve a > > message which is encoded that way. > > > > (Although it is clear from #ifdef SEND_AS_SHORT_AS_POSSIBLE that at some > > point in time the code gremlins felt that the above two expressions were > > equivalent.) > > > > Andrew > > ------------------------------------------- > > Upon closer inspection, I saw that the line > > dividing black from white was in fact a shade > > of grey. As I drew nearer still, the grey area > > grew larger. And then I was enlightened. > > > > I think that somewhere in one of the documents (rfc.2408?) it mentions > that variable length attributes MAY be encoded as basic attributes, if the > variable value fits into the two-byte basic attribute value. This means > that sending your example above, shouldn't break most people... as long as > they attribute parsing code behaves as expected, and they use the same > code to parse XAUTH attribs. > > This is the way we've done it... > > --- > Tylor Allison tylor_allison@securecomputing.com > Secure Computing Corporation > From owner-ietf-mode-cfg Fri Mar 23 06:08:47 2001 Received: by above.proper.com (8.9.3/8.9.3) id GAA11034 for ietf-mode-cfg-bks; Fri, 23 Mar 2001 06:08:47 -0800 (PST) Received: from brahma.roc.com ([202.54.67.218]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA11029 for ; Fri, 23 Mar 2001 06:08:44 -0800 (PST) Received: from vamsi (5net76.roc.com [172.16.5.76]) by brahma.roc.com (8.8.5/8.8.5) with SMTP id TAA08649 for ; Fri, 23 Mar 2001 19:44:42 +0530 (IST) Message-Id: <200103231414.TAA08649@brahma.roc.com> X-Sender: vamsi@172.16.1.10 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 23 Mar 2001 19:37:45 +0530 To: ietf-mode-cfg@vpnc.org From: Vamsi Subject: Xauth-OTP Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id GAA11031 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, 1)Can any one help me how to proceed the Xauth with OTP? 2) >From Xauth Draft ,the exchange of messages in case of OTP is as follows IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234" NAME="" PASSWORD="") REPLY(TYPE=OTP NAME="joe" PASSWORD="5bf0 75d9 959d 036f") --> <-- SET(STATUS=OK) ACK(STATUS) --> As per my understanding OTP generates its challenge("otp-md5 499 ke1234") from any one of the Key parameter like 'User Name'. In Xauth at Edge Device,what parameter should I consider as key parameter to generate a OTP challenge string? 3)My question is how an edge device can generate the OTP string ("otp-md5 499 ke1234") which will be encoded in a challenge attribute with out the user name(i.e Key field to generate the OTP challenge string)? Please clarify me whether I am missing any thing in understanding the Xauth transactions for OTP. bye vamsi ************************************************************** Wealth is lost            Nothing is lost Health is lost            Something is lost Character is lost      Everything is lost **************************************************************** From owner-ietf-mode-cfg Tue Apr 3 11:58:15 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA26119 for ietf-mode-cfg-bks; Tue, 3 Apr 2001 11:58:15 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA26113 for ; Tue, 3 Apr 2001 11:58:14 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA20073 for ; Tue, 3 Apr 2001 11:58:07 -0700 (PDT) Received: from ddukesnt4 (ott-b1-dhcp-10-85-28-234.cisco.com [10.85.28.234]) by toque.cisco.com (Mirapoint) with SMTP id ABI01723; Tue, 3 Apr 2001 14:57:44 -0400 (EDT) Message-ID: <00fb01c0bc70$25d21d60$ea1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: Subject: Fw: I-D ACTION:draft-dukes-ike-mode-cfg-01.txt Date: Tue, 3 Apr 2001 14:59:02 -0400 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00F8_01C0BC4E.9E943D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00F8_01C0BC4E.9E943D40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: Sent: Tuesday, April 03, 2001 7:52 AM Subject: I-D ACTION:draft-dukes-ike-mode-cfg-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The ISAKMP Configuration Method > Author(s) : D. Dukes, R. Pereira > Filename : draft-dukes-ike-mode-cfg-01.txt > Pages : 13 > Date : 02-Apr-01 > > This document describes a new ISAKMP method that allows > configuration items to be exchanged securely by using both > push/acknowledge or request/reply paradigms. > The authors currently intend this document to be published as an > Informational RFC, not a standards-track document, so that the many > IPsec implementations that have implemented to earlier drafts of > this protocol can have a single stable reference. > Comments regarding this draft should be sent to ietf-mode- > cfg@vpnc.org or to the authors. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-dukes-ike-mode-cfg-01.txt > > 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-dukes-ike-mode-cfg-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-dukes-ike-mode-cfg-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------=_NextPart_000_00F8_01C0BC4E.9E943D40 Content-Type: application/octet-stream; name="ATT00237.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00237.dat" Content-Type: text/plain Content-ID: <20010402124637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dukes-ike-mode-cfg-01.txt ------=_NextPart_000_00F8_01C0BC4E.9E943D40 Content-Type: text/plain; name="draft-dukes-ike-mode-cfg-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-dukes-ike-mode-cfg-01.txt" Content-Type: text/plain Content-ID: <20010402124637.I-D@ietf.org> ------=_NextPart_000_00F8_01C0BC4E.9E943D40-- From owner-ietf-mode-cfg Fri Feb 22 11:06:09 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MJ69q10619 for ietf-mode-cfg-bks; Fri, 22 Feb 2002 11:06:09 -0800 (PST) Received: from exchange.colubris.com (gate.colubris.com [206.162.167.230]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MJ64310615 for ; Fri, 22 Feb 2002 11:06:08 -0800 (PST) Received: from colubris.com ([192.168.30.124] RDNS failed) by exchange.colubris.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Feb 2002 14:02:32 -0500 Message-ID: <3C7696AD.3D8C9A8E@colubris.com> Date: Fri, 22 Feb 2002 14:06:21 -0500 From: Martin Gadbois Organization: Colubris Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-mode-cfg@vpnc.org Subject: Question about IVs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2002 19:02:32.0171 (UTC) FILETIME=[7B26ABB0:01C1BBD3] Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello! I'm implementing some Xauth/Mode config, and I ran into two different implementations: As in SafeNet SoftPK implementation: IPsec Host Edge Device -------------- ----------------- <<<<<<<>>>>>> next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are previous CBC block <-- REQUEST(NAME="" PASSWORD="") REPLY(NAME="joe" PASSWORD="foobar") --> <-- SET(STATUS=OK) ACK(STATUS) --> As in PGPnet and others: IPsec Host Edge Device -------------- ----------------- <<<<<<<>>>>>> next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are previous CBC block <-- REQUEST(NAME="" PASSWORD="") REPLY(NAME="joe" PASSWORD="foobar") --> next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are previous CBC block <-- SET(STATUS=OK) ACK(STATUS) --> Which one should it be? It might be a good point to enhance in the next release of the draft. Thanks, -- ============== Martin Gadbois S/W Developper Colubris Networks Inc. From owner-ietf-mode-cfg Fri Feb 22 11:31:12 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MJVCL11067 for ietf-mode-cfg-bks; Fri, 22 Feb 2002 11:31:12 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MJVB311063 for ; Fri, 22 Feb 2002 11:31:11 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GRYBLG00.K8Q; Fri, 22 Feb 2002 12:29:40 -0800 Message-ID: <3C769C78.81C1F465@cyphers.net> Date: Fri, 22 Feb 2002 11:31:04 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Martin Gadbois CC: ietf-mode-cfg@vpnc.org Subject: Re: Question about IVs References: <3C7696AD.3D8C9A8E@colubris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree it should be more explicit, but section 2 of the current draft does basically state the right way to handle this: "A "Configuration Transaction" is defined as one or more transaction exchanges each consisting of two messages" What you see SafeNet doing is what some vendors did in the early days wherein the various transactions of a Mode Config conversation were treated as if they were all one exchange. There was a time in a never-released version when PGP did it that way as well. Most probably, if you sent the XAuth6+ Vendor ID to SafeNet, it might behave properly. They probably are doing it that old way just for backwards compatibility. Regardless, the correct way to do this is for each pair to be treated as a separate exchange. AFAIK all the products we test against have long since been updated to do this correctly. Martin Gadbois wrote: > > Hello! > > I'm implementing some Xauth/Mode config, and I ran into two different > implementations: > > As in SafeNet SoftPK implementation: > IPsec Host Edge Device > -------------- ----------------- > <<<<<<<>>>>>> > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > previous CBC block > <-- REQUEST(NAME="" PASSWORD="") > REPLY(NAME="joe" PASSWORD="foobar") --> > <-- SET(STATUS=OK) > ACK(STATUS) --> > > As in PGPnet and others: > IPsec Host Edge Device > -------------- ----------------- > <<<<<<<>>>>>> > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > previous CBC block > <-- REQUEST(NAME="" PASSWORD="") > REPLY(NAME="joe" PASSWORD="foobar") --> > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > previous CBC block > <-- SET(STATUS=OK) > ACK(STATUS) --> > > Which one should it be? It might be a good point to enhance in the next > release of the draft. > > Thanks, > > -- > ============== > Martin Gadbois > S/W Developper > Colubris Networks Inc. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ietf-mode-cfg Mon Feb 25 08:23:12 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PGNCX29401 for ietf-mode-cfg-bks; Mon, 25 Feb 2002 08:23:12 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PGN8329391 for ; Mon, 25 Feb 2002 08:23:08 -0800 (PST) Received: from toque.cisco.com (toque.cisco.com [161.44.201.11]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1PGN3h11202; Mon, 25 Feb 2002 08:23:04 -0800 (PST) Received: from DDUKESW2K (dhcp-kta1-161-44-192-78.cisco.com [161.44.192.78]) by toque.cisco.com (Mirapoint) with SMTP id AAO02440; Mon, 25 Feb 2002 11:20:06 -0500 (EST) Message-ID: <004b01c1be18$b18cc5d0$4ec02ca1@amer.cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: , "Martin Gadbois" Cc: References: <3C7696AD.3D8C9A8E@colubris.com> <3C769C78.81C1F465@cyphers.net> Subject: Re: Question about IVs Date: Mon, 25 Feb 2002 11:23:00 -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-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The last paragraph in "3.1.1 Protected Exchanges" describes how the IVs are computed for a Transaction Exchange. Should that paragraph be clearer? Darren ----- Original Message ----- From: "Will Price" To: "Martin Gadbois" Cc: Sent: Friday, February 22, 2002 2:31 PM Subject: Re: Question about IVs > > I agree it should be more explicit, but section 2 of the current draft > does basically state the right way to handle this: > > "A "Configuration Transaction" is defined as one or more transaction > exchanges each consisting of two messages" > > What you see SafeNet doing is what some vendors did in the early days > wherein the various transactions of a Mode Config conversation were > treated as if they were all one exchange. There was a time in a > never-released version when PGP did it that way as well. > > Most probably, if you sent the XAuth6+ Vendor ID to SafeNet, it might > behave properly. They probably are doing it that old way just for > backwards compatibility. Regardless, the correct way to do this is for > each pair to be treated as a separate exchange. AFAIK all the products we > test against have long since been updated to do this correctly. > > > > > Martin Gadbois wrote: > > > > Hello! > > > > I'm implementing some Xauth/Mode config, and I ran into two different > > implementations: > > > > As in SafeNet SoftPK implementation: > > IPsec Host Edge Device > > -------------- ----------------- > > <<<<<<<>>>>>> > > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > > previous CBC block > > <-- REQUEST(NAME="" PASSWORD="") > > REPLY(NAME="joe" PASSWORD="foobar") --> > > <-- SET(STATUS=OK) > > ACK(STATUS) --> > > > > As in PGPnet and others: > > IPsec Host Edge Device > > -------------- ----------------- > > <<<<<<<>>>>>> > > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > > previous CBC block > > <-- REQUEST(NAME="" PASSWORD="") > > REPLY(NAME="joe" PASSWORD="foobar") --> > > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > > previous CBC block > > <-- SET(STATUS=OK) > > ACK(STATUS) --> > > > > Which one should it be? It might be a good point to enhance in the next > > release of the draft. > > > > Thanks, > > > > -- > > ============== > > Martin Gadbois > > S/W Developper > > Colubris Networks Inc. > > -- > > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. From owner-ietf-mode-cfg Mon Feb 25 11:20:45 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1PJKjV06295 for ietf-mode-cfg-bks; Mon, 25 Feb 2002 11:20:45 -0800 (PST) Received: from exchange.colubris.com (gate.colubris.com [206.162.167.230]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PJKh306290 for ; Mon, 25 Feb 2002 11:20:43 -0800 (PST) Received: from colubris.com ([192.168.30.124] RDNS failed) by exchange.colubris.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 14:17:12 -0500 Message-ID: <3C7A8E8F.273A15EF@colubris.com> Date: Mon, 25 Feb 2002 14:20:47 -0500 From: Martin Gadbois Organization: Colubris Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Darren Dukes CC: wprice@cyphers.net, ietf-mode-cfg@vpnc.org Subject: Re: Question about IVs References: <3C7696AD.3D8C9A8E@colubris.com> <3C769C78.81C1F465@cyphers.net> <004b01c1be18$b18cc5d0$4ec02ca1@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2002 19:17:12.0500 (UTC) FILETIME=[071B7740:01C1BE31] Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Darren Dukes wrote: > The last paragraph in "3.1.1 Protected Exchanges" describes how the IVs are > computed for a Transaction Exchange. Should that paragraph be clearer? > > Darren Yes, I suppose. Here are some suggestions: "The derivation of the initialization vector (IV) for the first message, used with SKEYID_e to encrypt the message, is described in Appendix B of [IKE]. Subsequent IVs are taken from the last ciphertext block of the previous message as described in [IKE]. " ADDED: "IV should be re-initialize before each Configuration Transaction." or again: "The derivation of the initialization vector (IV) for the first message <<< of the Configuration Transaction >>>, used with SKEYID_e to encrypt the message, Also, an example is always a good idea in the absence of reference implementation. Thank you for your support, -- ============== Martin Gadbois S/W Developper Colubris Networks Inc. From owner-ietf-mode-cfg Tue Feb 26 10:17:55 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1QIHtP19083 for ietf-mode-cfg-bks; Tue, 26 Feb 2002 10:17:55 -0800 (PST) Received: from max.safenet-inc ([206.156.202.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QIHr319079 for ; Tue, 26 Feb 2002 10:17:54 -0800 (PST) Received: by MAX with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 13:22:12 -0500 Message-ID: <3E89A18A51CBD411BD1B0002A507C88B0B1CEC@MAX> From: Bill Becker To: "'wprice@cyphers.net'" , Martin Gadbois Cc: ietf-mode-cfg@vpnc.org Subject: RE: Question about IVs Date: Tue, 26 Feb 2002 13:22:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Martin, The SafeNet client works as described in your second example with separate exchanges and is interoperable with most others. Note that to get xauthv6 behavior (different auth methods, etc.) you need to select the Phase 1 Authenticaiton Method to include "Extended Authentication" --Bill Bill Becker Technology Manager SafeNet, Inc. -----Original Message----- From: Will Price [mailto:wprice@cyphers.net] Sent: Friday, February 22, 2002 2:31 PM To: Martin Gadbois Cc: ietf-mode-cfg@vpnc.org Subject: Re: Question about IVs I agree it should be more explicit, but section 2 of the current draft does basically state the right way to handle this: "A "Configuration Transaction" is defined as one or more transaction exchanges each consisting of two messages" What you see SafeNet doing is what some vendors did in the early days wherein the various transactions of a Mode Config conversation were treated as if they were all one exchange. There was a time in a never-released version when PGP did it that way as well. Most probably, if you sent the XAuth6+ Vendor ID to SafeNet, it might behave properly. They probably are doing it that old way just for backwards compatibility. Regardless, the correct way to do this is for each pair to be treated as a separate exchange. AFAIK all the products we test against have long since been updated to do this correctly. Martin Gadbois wrote: > > Hello! > > I'm implementing some Xauth/Mode config, and I ran into two different > implementations: > > As in SafeNet SoftPK implementation: > IPsec Host Edge Device > -------------- ----------------- > <<<<<<<>>>>>> > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > previous CBC block > <-- REQUEST(NAME="" PASSWORD="") > REPLY(NAME="joe" PASSWORD="foobar") --> > <-- SET(STATUS=OK) > ACK(STATUS) --> > > As in PGPnet and others: > IPsec Host Edge Device > -------------- ----------------- > <<<<<<<>>>>>> > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > previous CBC block > <-- REQUEST(NAME="" PASSWORD="") > REPLY(NAME="joe" PASSWORD="foobar") --> > next IV=prf(K,Last CBC block of Phase1 | Messages ID), other IV are > previous CBC block > <-- SET(STATUS=OK) > ACK(STATUS) --> > > Which one should it be? It might be a good point to enhance in the next > release of the draft. > > Thanks, > > -- > ============== > Martin Gadbois > S/W Developper > Colubris Networks Inc. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ietf-mode-cfg Wed Dec 18 12:10:39 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBIKAdA08769 for ietf-mode-cfg-bks; Wed, 18 Dec 2002 12:10:39 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBIKAZo08763 for ; Wed, 18 Dec 2002 12:10:35 -0800 (PST) Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBIKA5jS005287; Wed, 18 Dec 2002 12:10:05 -0800 (PST) Received: from DDUKESW2K (che-vpn-cluster-1-91.cisco.com [10.86.240.91]) by toque.cisco.com (Mirapoint) with SMTP id ABE09206; Wed, 18 Dec 2002 15:01:53 -0500 (EST) Reply-To: From: "Darren Dukes" To: Cc: Subject: Proposed Configuration payload for IKEv2 Date: Wed, 18 Dec 2002 15:10:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A4_01C2A6A7.96A489B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00A4_01C2A6A7.96A489B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is a draft which is intended to be merged with the IKEv2 draft. There is no intent for this draft to continue on its own. It contains a payload and description of how an IPsec Remote Access Client (IRAC) may use that payload to get configuration information (internal IP, subnets, etc.) from an IPsec Remote Access Server (IRAS). The payload in this draft is very similar to the IKEv1 modecfg draft, this draft states the differences between the two. Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in November, 2002, the IPsec WG decided to add remote access capabilities (legacy authentication and remote client configuration) to IKEv2. At an informal design team meeting after the WG meeting, the VPN vendors attending decided that the best options to propose to the WG were to add capabilities similar to XAUTH and MODE-CFG." Please send all comments regarding this draft to ipsec@lists.tislabs.com Thanks, Darren ------=_NextPart_000_00A4_01C2A6A7.96A489B0 Content-Type: text/plain; name="draft-dukes-ikev2-config-payload-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-dukes-ikev2-config-payload-00.txt" INTERNET-DRAFT Darren Dukes=20 Expires July 2003 =20 Document: Cisco Systems=20 December 2002=20 =20 =20 Configuration payload=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This document proposes changes to IKEv2 [IKEv2] to allow=20 configuration data to be securely distributed to IPsec Remote Access=20 Clients (IRACs) by IPsec Remote Access Servers (IRASs). It is=20 assumed this draft will be merged with the IKEv2 draft [IKEv2] and=20 refers to sections in that draft, preceded by "****=94. This draft,=20 on its own, is not intended to progress to any RFC status.=20 =20 Comments regarding this draft should be sent to ddukes@cisco.com or=20 ipsec@lists.tislabs.com=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [2].=20 =20 =20 =20 Dukes 1 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 Table of Contents=20 1. Introduction...................................................3=20 1.1. Changes from draft-dukes-ike-mode-cfg-02.txt.................3=20 1.2. Reader Prerequisites.........................................3=20 2. IKE_SA_AUTH Exchange changes...................................3=20 2. Informational (Phase 2) Exchanges..............................4=20 3. Configuration Payload..........................................4=20 3.1. Configuration Attributes.....................................6=20 4. Notify Message Types...........................................8=20 5. Implementation Notes...........................................8=20 5.1. Requesting an Internal Address...............................8=20 5.2. Requesting the Peer's Version................................9=20 6. Enterprise Management Considerations..........................10=20 7. Security Considerations.......................................10=20 8. References....................................................10=20 9. Acknowledgments...............................................11=20 10. Author's Addresses...........................................11=20 Full Copyright Statement.........................................12=20 =20 =20 Dukes 2 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 1. Introduction=20 =20 In remote access scenarios it is desirable and often necessary for=20 an IRAS to provide configuration data, such as an internal IP=20 address, to an IRAC before Child-SAs are created. This document=20 describes requirements on TSi and TSr, and an additional=20 Configuration Payload in message 3 and 4 (IKE_SA_AUTH) of IKE-SA=20 creation in order to provide configuration data necessary for the=20 creation of Child-SAs. The Configuration Payload MAY also be used=20 within an Informational Exchange protected by an IKE-SA to request=20 or set configuration data from or to an IKE peer.=20 =20 1.1. Changes from draft-dukes-ike-mode-cfg-02.txt=20 =20 This document is similar to draft-dukes-ike-mode-cfg-02.txt for=20 IKEv1 [IKE], but is not intended to interoperate directly with=20 implementations of that draft.=20 =20 Some differences for IKEv2=20 1 - No transaction exchange, use the Informational exchange and the=20 IKE_SA_AUTH exchange.=20 2 - The payload was called Attribute payload in the IKEv1 modecfg,=20 it is called Configuration payload in IKEv2. =20 3 - No Identifier in the Configuration Payload since this was a=20 major point of confusion in the IKEv1 modecfg draft, with no known=20 use other than XAUTH.=20 4 - Configuration payloads are always secured via the IKE-SA.=20 =20 =20 1.2. Reader Prerequisites=20 =20 It is assumed that the reader is familiar with Proposal for the=20 Internet Key Exchange (IKEv2) Protocol [IKEv2]=20 =20 2. IKE_SA_AUTH Exchange changes=20 =20 **** [Below are changes to section 3.1 of [IKEv2], Message 3 and 4 are=20 modified to include the Configuration Payload and additional=20 description of CP and TS requirements are added]=20 =20 HDR, SAi1, KEi, Ni, Nr,=20 SK {IDi, [CERT,] [CERTREQ,] [IDr,]=20 AUTH, [CP], SAi2, TSi, TSr} -->=20 =20 The optional CP (Configuration Payload) MAY be sent by the initiator=20 to request configuration data. If CP is used to request an internal=20 IP address (as is often the case when the initiator is an IRAC) the=20 initiator may not know what to place in the TSi payload, in this=20 case she MUST include at least one Traffic Selector in TSi with a=20 suitable range of ports, and addresses. As an example, if the=20 initiator did not have a selector trigger SA creation (as may be the=20 case when an IRAC starts up) she may include the selector (0.0.0.0- =20 Dukes 3 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 255.255.255.255) all ports and protocols. At least one suitable=20 selector MUST be included in TSr. Continuing with this example, the=20 initiator may not have any knowledge of the addresses secured by the=20 responder so she MAY include the selector (0.0.0.0-255.255.255.255)=20 all ports and protocols, requiring the responder to choose a=20 narrower selector if necessary.=20 =20 <-- HDR, SK {IDr, [CERT,] AUTH,=20 [CP], SAr2, TSi, TSr}=20 =20 If CP was present in message 3 there MUST be a corresponding CP in=20 message 4. When the responder sends a CP containing an internal IP=20 address in message 4, he MUST limit the traffic selector(s) in TSi=20 to contain only the address, or addresses, in the CP. The responder=20 MAY choose to limit TSr as described in section 4.9 Negotiating=20 Traffic Selectors of [IKEv2].=20 =20 2. Informational (Phase 2) Exchanges=20 =20 **** [This is an amendment to [IKEv2] section 3.3, paragraph 5 and the=20 exchange description at the end of that section]=20 =20 Messages in an Informational Exchange may contain zero or one=20 Configuration Payloads. If there is a Configuration Payload in a=20 request there MUST be a corresponding Configuration Payload in the=20 response.=20 =20 The Informational Exchange is defined as:=20 =20 Initiator Responder=20 ----------- -----------=20 HDR, SK {N, ..., D, ..., CP, ...} -->=20 <-- HDR, SK {N, ..., D, ..., CP, ...}=20 =20 3. Configuration Payload=20 =20 **** [This should be added to [IKEv2] section 5.?]=20 =20 A Configuration payload, denoted CP in this document, is used to=20 exchange configuration information between IKE peers. Typically the=20 peers would be an IRAC and IRAS. A Configuration Payload MAY appear=20 in an Informational exchange, or an IKE_SA_AUTH exchange, and MUST=20 NOT be in any other exchanges.=20 =20 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or=20 CFG_SET/CFG_ACK (see CFG Type in the payload description below) =20 =20 o "CFG_REQUEST/CFG_REPLY" allows an IRAC to request information from=20 an IRAS. If an attribute in the CFG_REQUEST Configuration Payload=20 is not zero length it is taken as a suggestion for that attribute. =20 The CFG_REPLY Configuration Payload MAY return that attribute, or a=20 new one. It MAY also add new attributes and not include some=20 requested ones.=20 =20 Dukes 4 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 A CFG_REPLY MUST be sent when a CFG_REQUEST is received, even if it=20 is empty, or missing attributes from the CFG_REQUEST. This merely=20 means that the requested attributes were not available or unknown.=20 =20 Initiator Responder=20 --------------- --------------=20 HDR, SK{CP(CFG_REQUEST)} -->=20 <-- HDR, SK{CP(CFG_REPLY)}=20 =20 o "CFG_SET/CFG_ACK" allows an IRAS to push configuration data to an=20 IRAC. In this case the CFG_SET Configuration Payload contains=20 attributes the initiator wants its peer to alter. The responder=20 MUST return a Configuration Payload and it MUST contain the zero=20 length attributes that the responder accepted. Those attributes=20 that it did not accept MUST NOT be in the CFG_ACK Configuration=20 Payload.=20 =20 Initiator Responder=20 --------------- --------------=20 HDR, SK{CP(CFG_SET)} -->=20 <-- HDR, SK{CP(CFG_ACK)}=20 =20 =20 The Configuration Payload is defined as follows:=20 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ! Next Payload !C! RESERVED ! Payload Length !=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ! CFG Type ! RESERVED !=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ! !=20 ~ Configuration Attributes ~=20 ! !=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 o CFG Type (1 octet) - The type of exchange represented by the=20 Configuration Attributes.=20 =20 Types Value=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 RESERVED 0=20 CFG_REQUEST 1=20 CFG_REPLY 2=20 CFG_SET 3=20 CFG_ACK 4=20 =20 values 5-127 are reserved to IANA. Values 128-255 are for private=20 use among mutually consenting parties.=20 =20 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored.=20 =20 Dukes 5 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 o Configuration Attribute (variable length) - These are type length=20 values specific to the Configuration Payload and are defined below. =20 There may be zero or more Configuration Attributes in this payload.=20 =20 The payload type for the Configuration Payload is **TBD** (**TBD**).=20 =20 =20 3.1. Configuration Attributes=20 =20 **** [ This section would be a subsection 5.?.1]=20 =20 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 !R| Attribute Type ! Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Value ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 o Reserved (1 bit) - This bit MUST be set to zero and MUST be=20 ignored.=20 =20 o Attribute Type (7 bits) - A unique identifier for each of the=20 Configuration Attribute Types, the following are currently defined:=20 =20 MUST=20 Attribute Type Value Support Length=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 RESERVED 0=20 INTERNAL_IP4_ADDRESS 1 YES 0 or 4 octets=20 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets=20 INTERNAL_IP4_DNS 3 NO 0 or 4 octets=20 INTERNAL_IP4_NBNS 4 NO 0 or 4 octets=20 INTERNAL_ADDRESS_EXPIRY 5 YES 0 or 4 octets=20 INTERNAL_IP4_DHCP 6 NO 0 or 4 octets=20 APPLICATION_VERSION 7 YES 0 or more=20 INTERNAL_IP6_ADDRESS 8 YES 0 or 16 octets=20 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets=20 INTERNAL_IP6_DNS 10 NO 0 or 16 octets=20 INTERNAL_IP6_NBNS 11 NO 0 or 16 octets=20 INTERNAL_IP6_DHCP 12 NO 0 or 16 octets=20 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets=20 SUPPORTED_ATTRIBUTES 14 YES 0 or multiples of 2=20 INTERNAL_IP6_SUBNET 15 YES 0 or 17 octets=20 =20 values 16-16383 are reserved to IANA. Values 16384-32767 are for=20 private use among mutually consenting parties.=20 =20 =20 Dukes 6 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the=20 internal network, sometimes called a red node address or private=20 address and MAY be a private address on the Internet. Multiple=20 internal addresses MAY be requested by requesting multiple=20 internal address attributes. The responder MAY only send up to=20 the number of addresses requested.=20 =20 The requested address is valid until the expiry time defined with=20 the INTERNAL_ADDRESS EXPIRY attribute or there are no IKE-SAs=20 between the peers.=20 =20 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal=20 network's netmask. Only one netmask is allowed in the request and=20 reply messages (e.g. 255.255.255.0) and it MUST be used only with=20 an INTERNAL_ADDRESS attribute.=20 =20 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a=20 DNS server within the network. Multiple DNS servers MAY be=20 requested. The responder MAY respond with zero or more DNS server=20 attributes.=20 =20 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a=20 NetBios Name Server (WINS) within the network. Multiple NBNS=20 servers MAY be requested. The responder MAY respond with zero or=20 more NBNS server attributes.=20 =20 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that=20 the host can use the internal IP address. The host MUST renew the=20 IP address before this expiry time. Only one of these attributes=20 MAY be present in the reply.=20 =20 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to=20 send any internal DHCP requests to the address contained within=20 the attribute. Multiple DHCP servers MAY be requested. The=20 responder MAY respond with zero or more DHCP server attributes.=20 =20 o APPLICATION_VERSION - The version or application information of=20 the IPSec host. This is a string of printable ASCII characters=20 that is NOT null terminated.=20 =20 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- device protects. This attribute is made up of two fields; the=20 first being an IP address and the second being a netmask. =20 Multiple sub-networks MAY be requested. The responder MAY respond=20 with zero or more sub-network attributes.=20 =20 o SUPPORTED_ATTRIBUTES - When used within a Request, this=20 attribute must be zero length and specifies a query to the=20 responder to reply back with all of the attributes that it=20 supports. The response contains an attribute that contains a set=20 of attribute identifiers each in 2 octets. The length divided by=20 2 (bytes) would state the number of supported attributes contained=20 in the response.=20 =20 Dukes 7 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- device protects. This attribute is made up of two fields; the=20 first being a 16 octet IPv6 address the second being a one octet=20 prefix-mask as defined in [ADDRIPV6]. Multiple sub-networks MAY=20 be requested. The responder MAY respond with zero or more sub- network attributes.=20 =20 Note that no recommendations are made in this document how an=20 implementation actually figures out what information to send in a=20 reply. i.e. we do not recommend any specific method of an IRAS=20 determining which DNS server should be returned to a requesting=20 IRAC.=20 =20 o Length (2 octets) - Length in octets of Value.=20 =20 o Value (0 or more octets) - The variable length value of this=20 Configuration Attribute.=20 =20 4. Notify Message Types=20 =20 **** [ This section is an amendment to 5.10.1 of [IKEv2] ]=20 =20 =20 INTERNAL-ADDRESS-FAILURE 36=20 =20 Indicates an error assigning an internal address (i.e.,=20 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the=20 processing of a Configuration Payload by a Responder. If this=20 error is generated within an IKE_SA_AUTH exchange no Child-SA=20 will be created.=20 =20 =20 5. Implementation Notes=20 =20 ****[ This section and its subsections should be placed in an appendix=20 to [IKEv2] ] =20 =20 The following descriptions detail how to perform specific functions=20 using the configuration payload. Other functions are possible and=20 thus this list is not a complete list of all of the possibilities. =20 While other functions are possible, the functions listed below MUST=20 be performed as detailed in this document to preserve=20 interoperability among different vendor's implementations.=20 =20 =20 5.1. Requesting an Internal Address=20 =20 This function provides address allocation to an IRAC trying to=20 tunnel into a network protected by an IRAS. Since the IKE_SA_AUTH=20 exchange creates an IKE-SA and a Child-SA the IRAC MUST request the=20 internal address, and optionally other information concerning the=20 internal network, in the IKE_SA_AUTH exchange. The may IRAS procure=20 =20 Dukes 8 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 an internal address for the IRAC from any number of sources such as=20 a DHCP/BOOTP server or its own address pool.=20 =20 Initiator Responder=20 ----------------------------- -------------------------------=20 HDR, SAi1, KEi, Ni, Nr,=20 SK {IDi, [CERT,] [CERTREQ,] [IDr,]=20 AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->=20 =20 <-- HDR, SK {IDr, [CERT,] AUTH,=20 CP(CFG_REPLY), SAr2, TSi, TSr}=20 =20 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute=20 (either IPv4 or IPv6) but MAY contain any number of additional=20 attributes the initiator wants returned in the response.=20 =20 For example, message from Initiator to Responder:=20 CP(CFG_REQUEST)=3D=20 INTERNAL_ADDRESS(0.0.0.0)=20 INTERNAL_NETMASK(0.0.0.0)=20 INTERNAL_DNS(0.0.0.0)=20 TSi =3D (0, 0-65536,0.0.0.0-255.255.255.255)=20 TSr =3D (0, 0-65536,0.0.0.0-255.255.255.255)=20 =20 NOTE: Traffic Selectors are a (protocol, port range, address range)=20 =20 message from Responder to Initiator:=20 =20 CP(CFG_REPLY)=3D=20 INTERNAL_ADDRESS(192.168.219.202)=20 INTERNAL_NETMASK(255.255.255.0)=20 INTERNAL_SUBNET(192.168.219.0/255.255.255.0)=20 TSi =3D (0, 0-65536,192.168.219.202-192.168.219.202)=20 TSr =3D (0, 0-65536,192.168.219.0-192.168.219.255)=20 =20 All returned values will be implementation dependent. As can be=20 seen in the above example, the IRAS MAY also send other attributes=20 that were not included in CP(CFG_REQUEST) and MAY ignore the non- mandatory attributes that it does not support.=20 =20 =20 5.2. Requesting the Peer's Version=20 =20 An IKE peer wishing to inquire about the other peer's version=20 information MUST use the method below. This is an example of a=20 configuration request within an Informational Exchange, after the=20 IKE-SA and first Child-SA have been created.=20 =20 Initiator Responder=20 ----------------------------- --------------------------=20 HDR, SK{CP(CFG_REQUEST)} -->=20 <-- HDR, SK{CP(CFG_REPLY)}=20 =20 =20 Dukes 9 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 CP(CFG_REQUEST)=3D=20 APPLICATION_VERSION("")=20 =20 CP(CFG_REPLY)=20 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")=20 =20 6. Enterprise Management Considerations=20 =20 =20 ****[ Something similar to this section could be placed in an appendix=20 to [IKEv2] as well] =20 The method defined in this document SHOULD NOT be used for wide=20 scale management. Its main intent is to provide a bootstrap=20 mechanism to exchange information within IPSec from IRAS to IRAC. =20 While it MAY be useful to use such a method to exchange information=20 between some Security Gateways (SGW) or small networks, existing=20 management protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or=20 LDAP [LDAP] should be considered for enterprise management as well=20 as subsequent information exchanges.=20 =20 =20 7. Security Considerations=20 =20 This draft defines a payload for the Informational Exchange and MUST=20 be protected by an IKE-SA.=20 =20 =20 8. References=20 =20 =20 [1] Bradner, S., "The Internet Standards Process -- Revision=20 3", BCP 9, RFC 2026, October 1996.=20 =20 [2] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997=20 =20 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange=20 (IKE)", RFC240=20 =20 [IKEv2] Charlie Kaufman, "Internet Key Exchange(IKEv2) = Protocol=94 =20 draft-ietf-ipsec-ikev2-03.txt=20 =20 [DHCP] R. Droms, "Dynamic Host Configuration Protocol",=20 RFC2131=20 =20 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote=20 Authentication Dial In User Service (RADIUS)", RFC2138=20 =20 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory=20 Access Protocol (v3)", RFC2251=20 =20 [ESP] S. Kent, "IP Encapsulating Security Payload (ESP)",=20 RFC2406=20 =20 Dukes 10 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 [ADDRIPV6] Hinden, R., "IP Version 6 Addressing Architecture",=20 RFC 2373, July 1998.=20 =20 =20 . Acknowledgments=20 =20 The editor would like to thank Stephane Beaulieu, Dan Harkins,=20 Derrell Piper, and Paul Hauffman.=20 =20 =20 0. Author's Addresses=20 =20 Darren Dukes=20 Cisco Systems Co.=20 2000 Innovation Drive=20 Kanata, ON, Canada=20 Phone: 1-613-254-3679=20 Email: ddukes@cisco.com=20 =20 =20 =20 ukes 11 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 ull Copyright Statement=20 "Copyright (C) The Internet Society (date). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into=20 =20 =20 This Internet Draft expires July 2003=20 =20 =20 ukes 12 =0A= =0C ------=_NextPart_000_00A4_01C2A6A7.96A489B0-- From owner-ietf-mode-cfg Thu Dec 19 09:29:34 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBJHTYk22414 for ietf-mode-cfg-bks; Thu, 19 Dec 2002 09:29:34 -0800 (PST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJHTWo22409 for ; Thu, 19 Dec 2002 09:29:32 -0800 (PST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id gBJHTcC08509; Thu, 19 Dec 2002 19:29:38 +0200 (IST) Date: Thu, 19 Dec 2002 19:29:38 +0200 (IST) From: Hugo Krawczyk To: Darren Dukes cc: ipsec@lists.tislabs.com, ietf-mode-cfg@vpnc.org Subject: Re: Proposed Configuration payload for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 18 Dec 2002, Darren Dukes wrote: > Attached is a draft which is intended to be merged with the IKEv2 draft. > There is no intent for this draft to continue on its own. It contains a > payload and description of how an IPsec Remote Access Client (IRAC) may use > that payload to get configuration information (internal IP, subnets, etc.) > from an IPsec Remote Access Server (IRAS). > > The payload in this draft is very similar to the IKEv1 modecfg draft, this > draft states the differences between the two. > > Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in > November, 2002, the IPsec WG decided to add remote access capabilities > (legacy authentication and remote client configuration) to IKEv2. At an If I understand it correctly, your draft only addresses the remote client configuration issue, not the legacy authentication. How do you envision adding the legacy authentication support and still making use of the configuration mechanism described in the draft? Note that you add the configuration mechanism to messages 3 and 4 of ikev2 and assume that it is protected under the IKE-SA, however if you need to perform legacy authentication then you will not have an established IKE-SA in messages 3 and 4. Also, it is worth noting that even if client and server use regular IKE authentication (signatures or preshared key) then in message 3 the server (responder) is not yet authenticated by the client so the information transmitted from IRAC to IRAS in this message is NOT protected. This should be documented and explicitly said that this message should not contain any confidential information. These problems are solved if the configuration information exchange happens in phase 2 (at the expense, of course, of more round trips). Hugo > informal design team meeting after the WG meeting, the VPN vendors attending > decided that the best options to propose to the WG were to add capabilities > similar to XAUTH and MODE-CFG." > > Please send all comments regarding this draft to ipsec@lists.tislabs.com > > Thanks, > Darren > From owner-ietf-mode-cfg Thu Dec 19 11:39:35 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBJJdZG03502 for ietf-mode-cfg-bks; Thu, 19 Dec 2002 11:39:35 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJJdRo03491 for ; Thu, 19 Dec 2002 11:39:28 -0800 (PST) Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBJJctjS012455; Thu, 19 Dec 2002 11:38:55 -0800 (PST) Received: from DDUKESW2K (dhcp-kta1-161-44-192-77.cisco.com [161.44.192.77]) by toque.cisco.com (Mirapoint) with SMTP id ABG09806; Thu, 19 Dec 2002 14:30:44 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Hugo Krawczyk" Cc: , Subject: RE: Proposed Configuration payload for IKEv2 Date: Thu, 19 Dec 2002 14:39:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Thursday, December 19, 2002 12:30 PM > > On Wed, 18 Dec 2002, Darren Dukes wrote: > > > Attached is a draft which is intended to be merged with the IKEv2 draft. > > There is no intent for this draft to continue on its own. It contains a > > payload and description of how an IPsec Remote Access Client > (IRAC) may use > > that payload to get configuration information (internal IP, > subnets, etc.) > > from an IPsec Remote Access Server (IRAS). > > > > The payload in this draft is very similar to the IKEv1 modecfg > draft, this > > draft states the differences between the two. > > > > Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in > > November, 2002, the IPsec WG decided to add remote access capabilities > > (legacy authentication and remote client configuration) to IKEv2. At an > > If I understand it correctly, your draft only addresses the remote client > configuration issue, not the legacy authentication. How do you envision > adding the legacy authentication support and still making use of the > configuration mechanism described in the draft? After taking a quick look at Paul's draft he just sent out, I think CP will go in the LAS exchange message 3 and message N the same way it's specified for message 3 and 4 now. > Note that you add the > configuration mechanism to messages 3 and 4 of ikev2 and assume that it is > protected under the IKE-SA, however if you need to perform legacy > authentication then you will not have an established IKE-SA in messages 3 > and 4. > > Also, it is worth noting that even if client and server use regular IKE > authentication (signatures or preshared key) then in message 3 the server > (responder) is not yet authenticated by the client so the information > transmitted from IRAC to IRAS in this message is NOT protected. This > should be documented and explicitly said that this message should not > contain any confidential information. You are right about message 3, and the IRAS not being authenticated to IRAC. I think text about the lack of authentication should suffice with strong suggestions of what configuration attributes should go into the CFG_REQUEST. > > These problems are solved if the configuration information exchange > happens in phase 2 (at the expense, of course, of more round trips). I had originally thought of this as just a post 'phase-1' exchange but since the first Child-SA is always created in message 3 and 4 we will need the configuration data before or during its creation. Without it the IRAS has no way of knowing how to narrow TSi in message 4. Darren > > Hugo > > > informal design team meeting after the WG meeting, the VPN > vendors attending > > decided that the best options to propose to the WG were to add > capabilities > > similar to XAUTH and MODE-CFG." > > > > Please send all comments regarding this draft to ipsec@lists.tislabs.com > > > > Thanks, > > Darren > > > From owner-ietf-mode-cfg Thu Dec 19 15:06:06 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBJN66P21126 for ietf-mode-cfg-bks; Thu, 19 Dec 2002 15:06:06 -0800 (PST) Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJN5oo21114; Thu, 19 Dec 2002 15:05:50 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 19 Dec 2002 14:18:00 -0800 To: , "Hugo Krawczyk" From: Paul Hoffman / VPNC Subject: RE: Proposed Configuration payload for IKEv2 Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:39 PM -0500 12/19/02, Darren Dukes wrote: >After taking a quick look at Paul's draft he just sent out, I think CP will >go in the LAS exchange message 3 and message N the same way it's specified >for message 3 and 4 now. That sounds right, and it keeps parallel with IKEv2. --Paul Hoffman, Director --VPN Consortium From owner-ietf-mode-cfg Thu Dec 19 18:58:37 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBK2wbC09629 for ietf-mode-cfg-bks; Thu, 19 Dec 2002 18:58:37 -0800 (PST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK2wZo09623; Thu, 19 Dec 2002 18:58:35 -0800 (PST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id gBK2wrt18615; Fri, 20 Dec 2002 04:58:53 +0200 (IST) Date: Fri, 20 Dec 2002 04:58:53 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: ddukes@cisco.com, IPsec WG , ietf-mode-cfg@vpnc.org Subject: RE: Proposed Configuration payload for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Dec 2002, Paul Hoffman / VPNC wrote: > At 2:39 PM -0500 12/19/02, Darren Dukes wrote: > >After taking a quick look at Paul's draft he just sent out, I think CP will > >go in the LAS exchange message 3 and message N the same way it's specified > >for message 3 and 4 now. > > That sounds right, and it keeps parallel with IKEv2. Paul, There is no real "parallel" with IKEv2. The exchange you propose (the SLA draft) changes the logic of the cryptographic key exchange in IKEv2 by making the responder the first to authenticate in message 2. Consequently, it also changes the contents of the signature. It resembles agressive mode of IKEv1 much more than IKEv2. In other words, from the point of view of IKEv2 this is a totally different mode of authentication, not only by the kind of credentials in use but also by its cryptographic logic. You have to be very careful when you change the cryptographic logic in IKEv2. Is the protocol you are proposing still secure? It seems to me, at least at first glance, that the protocol may be open to some form of man-in-the-middle attack (or more precisely, "server in the middle"). Have you checked that? At the functional (and security) level the identity of the server (and/or its certificate) seems to be missing in message 2. Is this just an overlook, or is it deliberate? In any case I would not like to assume that the client always has this cert in advance or that there is a single PK with which the server's signature is to be verified. Note that there may be, in principle, more than one server answering the client's request. Hugo > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-mode-cfg Thu Dec 19 20:01:28 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBK41SH12288 for ietf-mode-cfg-bks; Thu, 19 Dec 2002 20:01:28 -0800 (PST) Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK41Io12282; Thu, 19 Dec 2002 20:01:18 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 19 Dec 2002 20:01:13 -0800 To: Hugo Krawczyk From: Paul Hoffman / VPNC Subject: RE: Proposed Configuration payload for IKEv2 Cc: ddukes@cisco.com, IPsec WG , ietf-mode-cfg@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:58 AM +0200 12/20/02, Hugo Krawczyk wrote: >You have to be very careful when you change the cryptographic logic in >IKEv2. Is the protocol you are proposing still secure? Somehow, we thought that *you* might answer that question. :-) >It seems to me, at least at first glance, that the protocol may be open to >some form of man-in-the-middle attack (or more precisely, "server in the >middle"). Have you checked that? As I understand it, the server-in-the-middle attack that has been discussed this last month requires that the messages being passed in the IPsec remote access protocol have the same format as the messages being passed in the legacy authentication protocol. If that is a correct understanding, then it seems like we aren't susceptible to it because we have our own message format for CHRE payloads. >At the functional (and security) level the identity of the server (and/or >its certificate) seems to be missing in message 2. Is this just an >overlook, or is it deliberate? In any case I would not like to assume that >the client always has this cert in advance or that there is a single PK >with which the server's signature is to be verified. Note that there may >be, in principle, more than one server answering the client's request. The model we assumed was that the initiator knew the identity of the responder. You are correct, there might be a pool of responders. We could certainly add a certificate in message 2 for that. As per the discussion earlier this year, in the remote access case, it is fine to expose the identity of the responder to passive snooping if it is a remote access server. --Paul Hoffman, Director --VPN Consortium From owner-ietf-mode-cfg Fri Dec 20 17:11:39 2002 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBL1Bd721332 for ietf-mode-cfg-bks; Fri, 20 Dec 2002 17:11:39 -0800 (PST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBL1Bbo21325; Fri, 20 Dec 2002 17:11:37 -0800 (PST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id gBL1C2D09529; Sat, 21 Dec 2002 03:12:02 +0200 (IST) Date: Sat, 21 Dec 2002 03:12:02 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: IPsec WG , ietf-mode-cfg@vpnc.org Subject: RE: Proposed Configuration payload for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Dec 2002, Paul Hoffman / VPNC wrote: > At 4:58 AM +0200 12/20/02, Hugo Krawczyk wrote: > >You have to be very careful when you change the cryptographic logic in > >IKEv2. Is the protocol you are proposing still secure? > > Somehow, we thought that *you* might answer that question. :-) I thought that the burden of proof should be on the proponent... In any case I was not referring to the man-in-the-middle attacks that we are discussing in a parallel threat and which are based on the bad practice of using same credentials in protected and unprotected runs. Here I am talking about weaknesses in the cryptographic logic of the SLA protocol. But since there is enough traffic regarding the other MitM attacks (and it is late) I prefer to postpone this issue for next week. The bottom line is that the cryptography of SLA is open to attacks against the "consistency" (or "mutual belief") requirement for authenticated key exchanges (see, for example, my SIGMA paper). Yet, since SLA is specifically intended for use in the client-server model of legacy authentication the practical significance of the *specific* attacks that I can see is questionable. Still I believe that these weaknesses will have to be repaired (at least to avoid the publication of crypto papers that break the protocol :). I will write more about this next week. Hugo > > >It seems to me, at least at first glance, that the protocol may be open to > >some form of man-in-the-middle attack (or more precisely, "server in the > >middle"). Have you checked that? > > As I understand it, the server-in-the-middle attack that has been > discussed this last month requires that the messages being passed in > the IPsec remote access protocol have the same format as the messages > being passed in the legacy authentication protocol. If that is a > correct understanding, then it seems like we aren't susceptible to it > because we have our own message format for CHRE payloads. > > >At the functional (and security) level the identity of the server (and/or > >its certificate) seems to be missing in message 2. Is this just an > >overlook, or is it deliberate? In any case I would not like to assume that > >the client always has this cert in advance or that there is a single PK > >with which the server's signature is to be verified. Note that there may > >be, in principle, more than one server answering the client's request. > > The model we assumed was that the initiator knew the identity of the > responder. You are correct, there might be a pool of responders. We > could certainly add a certificate in message 2 for that. As per the > discussion earlier this year, in the remote access case, it is fine > to expose the identity of the responder to passive snooping if it is > a remote access server. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-mode-cfg Wed Feb 5 07:48:00 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15Fm0r14864 for ietf-mode-cfg-bks; Wed, 5 Feb 2003 07:48:00 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15Fltd14848 for ; Wed, 5 Feb 2003 07:47:55 -0800 (PST) Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15FlmSQ003951 for ; Wed, 5 Feb 2003 07:47:48 -0800 (PST) Received: from DDUKESW2K (dhcp-kta1-161-44-192-77.cisco.com [161.44.192.77]) by toque.cisco.com (Mirapoint) with SMTP id AGF00097; Wed, 5 Feb 2003 10:39:16 -0500 (EST) Reply-To: From: "Darren Dukes" To: Subject: MODECFG Implementers POV needed [FW: IKE V2 discussion on ipsec mailing list --- implementers POV wanted] Date: Wed, 5 Feb 2003 10:47:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mode-cfg@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Your opinions, pro-modecfg or con, in IKEv2 are greatly appreciated. The four individuals discussing this on the ipsec working group list are not enough to give the chairs an idea of what the consensus is. Thanks, Darren > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Tuesday, February 04, 2003 8:06 PM > To: IPSEC implementors > Subject: IKE V2 discussion on ipsec mailing list --- implementors POV > wanted > > > Hi there, > > You're getting this message because the IPSEC working group > needs to make some final decisions about the shape of IKEv2 if we are to > meet the February 15th deadline which our Area Director has challenged > us with. There are a number of issues which are on the table, and while > there has been some discussion by a few people on the IPSEC mailing > list, there were many implementors who have not commented on these > items. So Barbara and I pulled together a list of implementors from an > interop workshop plus people who had expressed interested on the secure > legacy authentication, and we are sending this note to you to urge your > participation on the IPSEC wg list. > > After all, it is the duty of working group chairs to determine > consensus, and it is hard to do that if many people haven't been > participating on the mailing list. (For example, there is anecdotal > story going around that a number of implementors were unhappy about the > decision to use cipher suites, for reasons unspecified. Because no one > spoke up against cipher suites, we have ended up going with them, for > better or for worse. There are other issues coming up which are far > more critical, and so we very much want your comments either in favor or > against these proposals.) > > Some of the key issues under discussion include the following: > > 1) MODECFG vs. DHCP (RFC 3456 style) > > At the Atlanta IETF meeting, a number of implementors gathered together > after the IPSEC meeting to discuss secure legacy authentication. At the > time, there was a clear preference towards using a MODECFG-style > approach. Such an approach has been included into ikev2-04, although it > is integrated into the main part of the IKEv2 exchange. > > However, there has since been extension discussion on the IPSEC mailing > list from those who advocate using an approach similar to RFC 3456, > which entails setting up a special DHCP SA. It is clearly a more > powerful approach, but it can entail more complexity. > > It seems strange that none of the modeconfig proponents have spoken up. > Have people examined what is currently specified in > draft-ietf-ipsec-ikev2-04? > If so, please express your opinions on it, either pro or con. > > If it turns out that Barbara and I, when we meet to determine wg > consensus in the future, see that all of the recent working group > discussion has been in favor of an DHCP/RFC-3456 style approach, and no > one has spoken in favor of the Configuration payload approach specified > in ikev2-04, so based on the apparent wg consensus, we give instructions > to Charlie to rip out the Configuration payload and replace it with text > derived from RFC 3456 --- I really, really don't want to hear later that > a bunch of implementors are doing a slow burn because the working group > ignored their concerns..... > > 2) Revised Identity > > Paul Hoffman has a proposal which would replace the current methods of > identifying initiators and responders (i.e.): > > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_RFC822_ADDR 3 > ID_IPV6_ADDR 5 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 > > with a completely different set of types: > > 1 PKIX certificate > 2 Certificate bundle > 3 Hash-and-URL of PKIX certificate > 4 URL to a PKIX certificate bundle > 5 PKIX keyIdentifier > 6 IDForSharedSecret > > This represents a fundamental shift in how IPSEC implementations handle > identities. It has potential effects on how policies are looked up, and > how access control is handled. It may effect user interfaces, > documentation, and training in very fundamental ways. (After all, > naming has always been considered the ultimate computer science rathole > for this very reason.) > > Hence, Barbara and I are very concerned that this proposal has attracted > very little comment, either pro or con. There are a few people who have > expressed support, but not all that many people. I did receive a > private comment from an implementor who said in reference to Paul's > revised-identity proposal, "the amount of change this would inflict on > existing IKE implementations scares the bejeezus out of me". > Unfortunately, he has declined my invitation (nay, strong encouragement) > to make this observation on the public ipsec wg mailing list. > > To be fair, there are some arguments in favor of this proposal; by > forcing all implementations to use certificates as the basis of their > naming, it can solve a number of interoperability concerns. (Although > on the other hand, the pki-profile document also solves many of these > issues without resorting to using an entirely new naming system.) > > ------------------ > > For more details, please see my e-mail to the IPSEC mailing list on > January 30th, with the subject line "Moving forward with IKEV2: A > proposal for final edits to ikev2-04", and subsequent comments. Also > please see the thread started by Benard Aboba, entitled "modecfg > considered harmful". Please also look at the latest ikev2 and > revised-identity I-D's. > > If you haven't commented because you think you agree with the way you > think things are going, please speak up and say that you've read > ikev2-04, and that you like it. (Or what you don't like about it and > which you believe should change.) > > If you haven't commented because you haven't had time to keep up with > the list, and some of the more recent I-D's, I strongly encourage you to > take the time to look at draft-ietf-ipsec-ikev2-04.txt, and look at some > of the more recent e-mail exchanges on the list. > > I personally have my own personal biases towards how I believe some of > these issues are settled from a purely technical perspective, but with > my working group chair hat on, the most important thing at this point is > that the *are* settled definitively, one way or another. The bottom > line is that we need your comments, from as many points of view as > possible. So what you have to say is important. > > Many thanks, > > Ted and Barbara > IPSEC wg chairs >