From owner-ipsec@lists.tislabs.com Fri Oct 1 07:36:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA15972; Fri, 1 Oct 1999 07:36:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09039 Fri, 1 Oct 1999 08:47:11 -0400 (EDT) Message-Id: <3.0.5.32.19990930131940.00865140@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 30 Sep 1999 13:19:40 -0400 To: Dan Harkins From: David Jablon Subject: Re: New XAUTH draft Cc: "Waters, Stephen" , ipsec@lists.tislabs.com In-Reply-To: <199909301612.JAA27379@Potassium.Network-Alchemy.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Your emphatic point about how XAUTH does not increase the secret IKE state raises an interesting question. Wouldn't it be nice for IPSEC to provide a way for an additional authentication scheme to increase the quality of the session key? My interest in this problem is to leverage the power of "legacy" credentials, but not by relying on legacy protocols. Specifically, I'm thinking about how protocols like SPEKE can leverage legacy credentials, without the limitations of legacy protocols. I know that XAUTH does not provide this, but neither does IPSEC as it is defined today. -- David At 09:12 AM 9/30/99 -0700, Dan Harkins wrote: > Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the >IKE secret state what you're ending up with is unauthenticated IPSec SAs! >There's no way that the customer can manage this. It just plain doesn't >work. --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ipsec@lists.tislabs.com Fri Oct 1 07:38:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA16004; Fri, 1 Oct 1999 07:38:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09049 Fri, 1 Oct 1999 08:48:09 -0400 (EDT) Message-ID: <002501bf0ba9$255e9f80$7701a8c0@root94.oullim.co.kr> From: "Root Shin" To: Subject: help Date: Fri, 1 Oct 1999 10:06:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id VAA06654 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Where I can get the 3DES-CBC info.? Help me ... ^^; Thank you. From owner-ipsec@lists.tislabs.com Fri Oct 1 07:40:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA16034; Fri, 1 Oct 1999 07:40:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09036 Fri, 1 Oct 1999 08:47:10 -0400 (EDT) Message-ID: <37F3B067.4701197D@americasm01.nt.com> Date: Thu, 30 Sep 1999 14:48:07 -0400 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: Unspecified Lifetime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IPSec DOI (RFC 2407) indicates that if the lifetime is unspecified, the default value of 28800 seconds is to be assumed. >From this statement, I am led to believe that it is optional to send the SA lifetime. Therefore if I do not send a lifetime attribute ( seconds or kilobytes), the other end is supposed to choose 28800 seconds as a default. If I only send a lifetime in kilobytes, does the other end set its lifetime in kilobytes attribute to the specified value AND its lifetime in seconds attribute to the default 28800 seconds? ( ... I hope not ) Kim Edwards Nortel Networks From owner-ipsec@lists.tislabs.com Fri Oct 1 08:42:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17063; Fri, 1 Oct 1999 08:42:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09448 Fri, 1 Oct 1999 09:47:03 -0400 (EDT) Message-Id: <199910011346.GAA08262@gallium.network-alchemy.com> To: "Kim Edwards" cc: "ipsec@lists.tislabs.com" Subject: Re: Unspecified Lifetime In-reply-to: Your message of "Thu, 30 Sep 1999 14:48:07 EDT." <37F3B067.4701197D@americasm01.nt.com> Date: Fri, 01 Oct 1999 06:46:26 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kim, >If I only send a lifetime in kilobytes, does the other end set its >lifetime in kilobytes attribute to the specified value AND its lifetime >in seconds attribute to the default 28800 seconds? ( ... I hope not ) I hope not as well. The default is intended to apply when no lifetime attributes are sent. If any are sent, then only those that are sent should apply and the default is not applicable. I'll add this to the list for the next revision of the DOI, which will be out before the deadline for Washington. (There, now, I've got to do it... :-) Derrell From owner-ipsec@lists.tislabs.com Fri Oct 1 08:54:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17337; Fri, 1 Oct 1999 08:54:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09566 Fri, 1 Oct 1999 10:12:26 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <199909302045.QAA01423@bual.research.att.com> Date: Fri, 1 Oct 1999 10:14:41 -0400 To: John Ioannidis From: Stephen Kent Subject: Re: anti-replay protection without IKE Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John, The replay protection facility depends on the sender NEVER sending packets on the same SA with the saem serial numbers. therefore, unless the key management technology used for SA creation is capable of generating new per-SA keys to handle the rollover problem, anti-replay is not viable. That's all that 2401 was tryingf to say. We can work to improve the wording, tro clarify this, but I think the principle is sound. Steve From owner-ipsec@lists.tislabs.com Fri Oct 1 10:42:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA19155; Fri, 1 Oct 1999 10:42:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09936 Fri, 1 Oct 1999 11:46:57 -0400 (EDT) From: Jackie Wilson Message-Id: <199910011548.KAA30440@jhwilson.austin.ibm.com> Subject: Re: anti-replay protection without IKE In-Reply-To: <199909302045.QAA01423@bual.research.att.com> from John Ioannidis at "Sep 30, 99 04:45:25 pm" To: ji@research.att.com (John Ioannidis) Date: Fri, 1 Oct 1999 10:48:55 -0500 (CDT) Cc: ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The reason manual tunnels are not supposed to do replay protection is because there is no way to resync the replay counter if one side goes down. The spec also specifies that the replay counter may not roll over to 0. If there are other rekeying mechanisms to address these 2 issues, replay protection is not a problem. Perhaps some text should be added to the draft so that the reasons are known and developers can decide if they have an alternate mechanism for restarting the sequence counters. Jackie John Ioannidis wrote: > > RFC 2401 > > hints that replay checking shouldn't be done for manual SAs, presumably on the > > theory that manual keys are likely to be long-lived. However, there are > > I had missed that detail, but the explanation makes no sense. It's > *especially* when we have long-lived keys that we want replay protection! > > On applications with manual keying, or non-IKE keying, maybe we want to > allow turning off the replay protection, but I feel that it MUST be turned > on by default. > > > Should (or SHOULD) implementations > > permit such applications to request replay checking? > > I think that the phrasing should be "implementations MAY permit applications > to turn OFF replay protection, but replay protection MUST be turned on by > default." > > /ji > > -- > John Ioannidis > Secure Systems Research Department > AT&T Labs - Research > -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec@lists.tislabs.com Fri Oct 1 12:55:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA21378; Fri, 1 Oct 1999 12:55:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10358 Fri, 1 Oct 1999 13:54:34 -0400 (EDT) Message-ID: <37F4F464.C7258707@ire-ma.com> Date: Fri, 01 Oct 1999 13:50:28 -0400 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Derrell D. Piper" CC: Kim Edwards , "ipsec@lists.tislabs.com" Subject: Re: Unspecified Lifetime References: <199910011346.GAA08262@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you set lifetime to kilobytes (say 5KB), but then your session stops short of this limit (say at 4KB) - then without some large time-based lifetime limit it will be alive forever - I am not sure if I want this. "Derrell D. Piper" wrote: > Kim, > > >If I only send a lifetime in kilobytes, does the other end set its > >lifetime in kilobytes attribute to the specified value AND its lifetime > >in seconds attribute to the default 28800 seconds? ( ... I hope not ) > > I hope not as well. The default is intended to apply when no lifetime > attributes are sent. If any are sent, then only those that are sent should > apply and the default is not applicable. > > I'll add this to the list for the next revision of the DOI, which will be out > before the deadline for Washington. (There, now, I've got to do it... :-) > > Derrell -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Oct 1 14:19:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA23149; Fri, 1 Oct 1999 14:19:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10580 Fri, 1 Oct 1999 14:53:47 -0400 (EDT) Message-Id: <199910011854.LAA16101@gallium.network-alchemy.com> To: Slava Kavsan cc: Kim Edwards , "ipsec@lists.tislabs.com" Subject: Re: Unspecified Lifetime In-reply-to: Your message of "Fri, 01 Oct 1999 13:50:28 EDT." <37F4F464.C7258707@ire-ma.com> Date: Fri, 01 Oct 1999 11:54:09 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >If you set lifetime to kilobytes (say 5KB), but then your session stops short of >this limit (say at 4KB) - then without some large time-based lifetime limit it >will be alive forever - I am not sure if I want this. Slava, That's a good point, however I expect that there might be situations where folks really do want their SA's to stay around essentially forever (without regard to the security implications thereof). If we say that there's always an overriding time-based expiration, there's now no way to negotiate that. If we leave it as it is (and/or with more clarification along the lines of my earlier note), you can still configure the behavior you want by configuring a time-based lifetime. On the third hand, I don't have a lot of religion here. Anyone else care to weigh in? Derrell From owner-ipsec@lists.tislabs.com Fri Oct 1 14:31:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA23319; Fri, 1 Oct 1999 14:30:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10626 Fri, 1 Oct 1999 15:03:11 -0400 (EDT) Date: Fri, 1 Oct 1999 15:04:59 -0400 Message-Id: <199910011904.PAA00334@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkavsan@ire-ma.com Cc: ipsec@lists.tislabs.com Subject: Re: Unspecified Lifetime References: <199910011346.GAA08262@gallium.network-alchemy.com> <37F4F464.C7258707@ire-ma.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> If you set lifetime to kilobytes (say 5KB), but then your Slava> session stops short of this limit (say at 4KB) - then without Slava> some large time-based lifetime limit it will be alive forever Slava> - I am not sure if I want this. If you don't want that, don't specify it. You can specify both limits if you want both volume and time limits to apply. But if you specify only one, the logical interpretation is that only that parameter affects when the SA goes away. paul From owner-ipsec@lists.tislabs.com Fri Oct 1 15:37:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA24321; Fri, 1 Oct 1999 15:37:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10599 Fri, 1 Oct 1999 14:59:13 -0400 (EDT) Message-ID: <37F50398.654A08EA@ire-ma.com> Date: Fri, 01 Oct 1999 14:55:20 -0400 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Derrell D. Piper" CC: Kim Edwards , "ipsec@lists.tislabs.com" Subject: Re: Unspecified Lifetime References: <199910011854.LAA16101@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suggest to leave this to the Local Policy matter - if your implementation does not enforce any time limit when only-KB is specified - let it be, but on the other hand - it should be allowed for the local policy to enforce some limit (e.g.28800 sec) on the KB-only lifitemed SAs. "Derrell D. Piper" wrote: > >If you set lifetime to kilobytes (say 5KB), but then your session stops short of > >this limit (say at 4KB) - then without some large time-based lifetime limit it > >will be alive forever - I am not sure if I want this. > > Slava, > > That's a good point, however I expect that there might be situations where > folks really do want their SA's to stay around essentially forever (without > regard to the security implications thereof). If we say that there's always > an overriding time-based expiration, there's now no way to negotiate that. If > we leave it as it is (and/or with more clarification along the lines of my > earlier note), you can still configure the behavior you want by configuring a > time-based lifetime. On the third hand, I don't have a lot of religion here. > > Anyone else care to weigh in? > > Derrell -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Oct 1 15:41:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA24363; Fri, 1 Oct 1999 15:41:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10684 Fri, 1 Oct 1999 15:25:23 -0400 (EDT) Message-ID: <37F505A4.5BE8A303@ima.umn.edu> Date: Fri, 01 Oct 1999 14:04:04 -0500 From: John Pliam X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <199909301926.PAA10520@tonga.xedia.com> <199909301946.MAA27884@Potassium.Network-Alchemy.COM> <199909302040.QAA13110@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > If so, then yes I would agree that this constitutes an attack on > the system. But I don't agree that it is a sufficiently serious > threat to condemn the entire concept, as you have been doing. > > So perhaps the next question is: is there consensus that > this threat is so serious that XAUTH has no meaningful > applicability in the real world? If so, then of course the > draft can't proceed. Ok, I'm a bit confused on the procedures, but hasn't this issue already been settled by whatever consensus adopted RFC 2408 (aka ISAKMP -- the master IPSec document)? Let me quote again: > 1.5.3 ISAKMP Requirements > > Strong authentication MUST be provided on ISAKMP exchanges. Without > being able to authenticate the entity at the other end, the Security > Association (SA) and session key established are suspect. Without > authentication you are unable to trust an entity's identification, > which makes access control questionable. While encryption (e.g. > ESP) and integrity (e.g. AH) will protect subsequent communications > from passive eavesdroppers, without authentication it is possible > that the SA and key may have been established with an adversary who > performed an active man-in-the-middle attack and is now stealing all > your personal data. The expression "strong authentication" has a very precise meaning. But, if there is any doubt about it, the RFC directly forbids authentication which is vulnerable to MITM attacks. I believe that any reasonable interpretation of this forbids group-shared secret authentication, for n > 2. For n = 2, it also forbids cases where the "secret" is really a passphrase. Real-world applications can always use IETF standards-tracks technologies, but that should in no way compel the WG to quickly adopt ways to standardize such applications. Furthermore, *this* working group is one which really must resist active attacks. That is not the case, e.g. with S/KEY and its RFC is quite frank about it. John Pliam pliam@ima.umn.edu http://www.ima.umn.edu/~pliam From owner-ipsec@lists.tislabs.com Sun Oct 3 00:18:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA27536; Sun, 3 Oct 1999 00:18:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14106 Sun, 3 Oct 1999 01:54:54 -0400 (EDT) Message-ID: <19991003055625.53908.qmail@hotmail.com> X-Originating-IP: [207.181.90.167] From: "Roy Pereira" To: root94@oullim.co.kr, ipsec@lists.tislabs.com Subject: Re: help Date: Sun, 03 Oct 1999 01:56:25 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC2451 >From: "Root Shin" >To: >Subject: help >Date: Fri, 1 Oct 1999 10:06:09 +0900 > >Where I can get the 3DES-CBC info.? >Help me ... ^^; >Thank you. > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Mon Oct 4 08:28:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA08048; Mon, 4 Oct 1999 08:28:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18025 Mon, 4 Oct 1999 09:06:10 -0400 (EDT) Message-ID: <37F5382A.C6FA4BB@americasm01.nt.com> Date: Fri, 01 Oct 1999 18:39:38 -0400 From: "Loretta Zhou" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: PMTU Discovery on Security Gateway Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to clarify the usage of PMTU value found through the PMTU dsicovery process on the security gateway. Ideally, the PMTU should be used to fragment the original datagram before encapsulating instead of after encapsulating on the gateway. Because, fragmenting the encapulated datagram will require the decapsulator gateway to reassebmle the packet before forwarding it on while fragmenting the original datagram will result the ressembly to be done on the destination host and therefore speed up routing performance. (In fact, this is what gateway will do for IpInIp or greIp tunnelling, RFC 2003). However, for IPSec gateway, since tunnel mode AH/ESP processing must be applied to a whole IP datagram(not fragments of an original datagram because not all fragments will contain all 5 selectors required by IPSec), even if we know that the datagram exceeds the size of the discovered PMTU, we still cannot fragment it until IP tunnel header encapsulation is done. In another words, if fragmentation is required, it will always be applied to encapsulted packet, and whether the packet is fragmented on the security gateway or on some intermediate routers in between the security gateways does not make any difference. Even if the security gateway does not do path MTU discovery and just sends the packet out using the interface MTU, the middle router who has a smaller mtu than the packet size will still fragment the enapsulated packet which will result in the same effect as if the packet is fragmented on the security gateway. It seems to me that the security gateway itself doesn't really take advantage of the PMTU like IP tunnelling gateway, and the only advantage of security gateway doing PMTU discovery is that it can propagate the PMTU to the original host to generate smaller packets in first place. However, if this is the only advantage, why not just have the host do Path MTU discovery? Regards, Lor Zhou. From owner-ipsec@lists.tislabs.com Mon Oct 4 08:30:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA08081; Mon, 4 Oct 1999 08:30:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18117 Mon, 4 Oct 1999 09:44:11 -0400 (EDT) Message-ID: <005101bf0e6a$d8c87000$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: From Firewall to IPSec VPNs Date: Mon, 4 Oct 1999 15:17:45 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01BF0E7B.9BFD53A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BF0E7B.9BFD53A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Security services and protection mechanisms IPv6 promises regarding IPSec Certification infrastructure Standardization update Case Studies: ISPs, carriers, private networks AH and ESP protocols description Possible future extensions and modifications of the IKE protocol Complementarity between IPSec and firewalls Global Site-to-Site IPSec VPN's with End-to-End SLA's Managing widespread IPSEC virtual private networks Solving IPSec VPNs scalability Results of some interoperability tests IPSec architectures and non-standardized aspects of IPSec Adding IPSec VPN functions in an existing router network Impact of fragmentation on the performance of IPSec coding IPSEC 99 Conference >From Firewall to IPSec VPNs October 26, 27, 28, 29, 1999 Paris - France More infos: www.upperside.fr/baipsec.htm ------=_NextPart_000_004E_01BF0E7B.9BFD53A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Security services and protection mechanisms
IPv6 promises = regarding=20 IPSec
Certification infrastructure
Standardization update
Case = Studies:=20 ISPs, carriers, private networks
AH and ESP protocols = description
Possible=20 future extensions and modifications of the IKE = protocol
Complementarity=20 between IPSec and firewalls
Global Site-to-Site IPSec VPN's with = End-to-End=20 SLA's
Managing widespread IPSEC virtual private networks
Solving = IPSec=20 VPNs scalability
Results of some interoperability tests
IPSec=20 architectures and non-standardized aspects of IPSec
Adding IPSec VPN=20 functions in an existing router network
Impact of fragmentation on = the=20 performance of IPSec coding

IPSEC 99 Conference
From Firewall = to IPSec=20 VPNs

October 26, 27, 28, 29, 1999
Paris - France

More = infos: www.upperside.fr/baipsec.htm=
 
 
------=_NextPart_000_004E_01BF0E7B.9BFD53A0-- From owner-ipsec@lists.tislabs.com Mon Oct 4 18:34:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA23285; Mon, 4 Oct 1999 18:34:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20776 Mon, 4 Oct 1999 20:05:47 -0400 (EDT) Message-ID: <19398D273324D3118A2B0008C7E9A569027515DC@SIT.platinum.corp.microsoft.com> From: "Brian Swander (Exchange)" To: "'Dan Harkins'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: reliable notify question Date: Mon, 4 Oct 1999 13:11:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Also, MUST the message_id in the responders ACK be the same as the message_id in the initiator's N/D, or MUST the message_ids be different? I'd argue for the former, since it will allow easier lookups, and I doubt there are any security issues with the duplicate mess_id. bs -----Original Message----- From: Brian Swander (Exchange) Sent: Monday, October 04, 1999 10:11 AM To: 'Dan Harkins' Cc: ipsec@lists.tislabs.com Subject: reliable notify question Pardon me if this has been asked before. In section 6.4.2 of the new IKE draft on reliable notifies, it says we need to use the initiator and responder nonces in constructing the messages. Initiator Responder ----------- ----------- HDR*, HASH(1), Ni, N/D --> <-- HDR*, HASH(2), Nr, N/D First, are these values the nonces that were already exchanged, or are they newly generated for each reliable notify? I presume the former. If I am right so far, which nonce do we use, the MM nonces, or the QM nonces? I assume that we always use the MM nonce, since notifies are only really bound to the MM, and not to any particular QM. Is this correct? bs From owner-ipsec@lists.tislabs.com Mon Oct 4 18:34:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA23290; Mon, 4 Oct 1999 18:34:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20775 Mon, 4 Oct 1999 20:05:42 -0400 (EDT) Message-ID: <19398D273324D3118A2B0008C7E9A569027515D5@SIT.platinum.corp.microsoft.com> From: "Brian Swander (Exchange)" To: "'Dan Harkins'" Cc: ipsec@lists.tislabs.com Subject: reliable notify question Date: Mon, 4 Oct 1999 10:10:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pardon me if this has been asked before. In section 6.4.2 of the new IKE draft on reliable notifies, it says we need to use the initiator and responder nonces in constructing the messages. Initiator Responder ----------- ----------- HDR*, HASH(1), Ni, N/D --> <-- HDR*, HASH(2), Nr, N/D First, are these values the nonces that were already exchanged, or are they newly generated for each reliable notify? I presume the former. If I am right so far, which nonce do we use, the MM nonces, or the QM nonces? I assume that we always use the MM nonce, since notifies are only really bound to the MM, and not to any particular QM. Is this correct? bs From owner-ipsec@lists.tislabs.com Mon Oct 4 18:53:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA24684; Mon, 4 Oct 1999 18:53:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20887 Mon, 4 Oct 1999 20:36:40 -0400 (EDT) Message-Id: <199910050037.RAA02440@Potassium.Network-Alchemy.COM> To: "Brian Swander (Exchange)" cc: ipsec@lists.tislabs.com Subject: Re: reliable notify question In-reply-to: Your message of "Mon, 04 Oct 1999 10:10:49 PDT." <19398D273324D3118A2B0008C7E9A569027515D5@SIT.platinum.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2437.939083849.1@network-alchemy.com> Date: Mon, 04 Oct 1999 17:37:29 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's the former: the nonces are newly generated for each reliable notify. Dan. On Mon, 04 Oct 1999 10:10:49 PDT you wrote > Pardon me if this has been asked before. > > In section 6.4.2 of the new IKE draft on reliable notifies, it says we need > to use the initiator and responder nonces in constructing the messages. > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), Ni, N/D --> > <-- HDR*, HASH(2), Nr, N/D > > First, are these values the nonces that were already exchanged, or are they > newly generated for each reliable notify? I presume the former. > > If I am right so far, which nonce do we use, the MM nonces, or the QM > nonces? I assume that we always use the MM nonce, since notifies are only > really bound to the MM, and not to any particular QM. > > Is this correct? > > bs > > From owner-ipsec@lists.tislabs.com Mon Oct 4 18:55:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA24809; Mon, 4 Oct 1999 18:55:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20899 Mon, 4 Oct 1999 20:38:19 -0400 (EDT) Message-Id: <199910050039.RAA02464@Potassium.Network-Alchemy.COM> To: "Brian Swander (Exchange)" cc: "'ipsec@lists.tislabs.com'" Subject: Re: reliable notify question In-reply-to: Your message of "Mon, 04 Oct 1999 13:11:23 PDT." <19398D273324D3118A2B0008C7E9A569027515DC@SIT.platinum.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2461.939083948.1@network-alchemy.com> Date: Mon, 04 Oct 1999 17:39:08 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk They have to be the same, just like all the other exchanges. Otherwise there would be no way to distinguish a response to your notify from a newly initiated notify from the peer. Dan. On Mon, 04 Oct 1999 13:11:23 PDT you wrote > Also, MUST the message_id in the responders ACK be the same as the > message_id in the initiator's N/D, or MUST the message_ids be different? > > I'd argue for the former, since it will allow easier lookups, and I doubt > there are any security issues with the duplicate mess_id. > > bs > > -----Original Message----- > From: Brian Swander (Exchange) > Sent: Monday, October 04, 1999 10:11 AM > To: 'Dan Harkins' > Cc: ipsec@lists.tislabs.com > Subject: reliable notify question > > > Pardon me if this has been asked before. > > In section 6.4.2 of the new IKE draft on reliable notifies, it says we need > to use the initiator and responder nonces in constructing the messages. > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), Ni, N/D --> > <-- HDR*, HASH(2), Nr, N/D > > First, are these values the nonces that were already exchanged, or are they > newly generated for each reliable notify? I presume the former. > > If I am right so far, which nonce do we use, the MM nonces, or the QM > nonces? I assume that we always use the MM nonce, since notifies are only > really bound to the MM, and not to any particular QM. > > Is this correct? > > bs > > From owner-ipsec@lists.tislabs.com Mon Oct 4 20:23:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA01653; Mon, 4 Oct 1999 20:23:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21092 Mon, 4 Oct 1999 21:54:47 -0400 (EDT) Message-ID: <37F95B6F.99C6C7D7@redcreek.com> Date: Mon, 04 Oct 1999 18:59:11 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: Non-IP type Client IDs References: <447A3F40A07FD211BA2700A0C99D759B05D131@md-exchange1.nai.com> <37BD69EF.497CE861@ibm.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Stephen Kent wrote: > > Scott, > > RFC 2401 embodies the notion that one can use a non-address ID type as a > selector in the SPD search. If the user ID is found in thge SPD, then one > creates a temporary SPD entry populated with IP addresses that have been > dynamically assigned, e.g., in the remote user scenario. The document > notes, near the top of page 19, the requirement to support user names for > INBOUND SA creation in security gateways, motivated by this scenario. > I seem to recall specific language in the document to this effect, but cannot find anything (after a quick skim) regarding insertion of temporary spd entries in RFC2401 - was such language deleted somewhere in the transition from draft to rfc, or am I just missing it? Thanks, Scott From owner-ipsec@lists.tislabs.com Tue Oct 5 07:21:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA07292; Tue, 5 Oct 1999 07:21:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22899 Tue, 5 Oct 1999 08:45:13 -0400 (EDT) Message-ID: <37F9F403.638BAAC5@kryptokom.de> Date: Tue, 05 Oct 1999 14:50:12 +0200 From: eT X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Using Certificates to Auth Diffie Helman Key Exhange Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings ... I am having problem with understanding how one is able to use X509v3 certificates as the authentication step of a Diffie Helman key exchange. Is there a document somewhere that explains this? Step 1 : SA exchange Step 2 : DH Key exchange Step 3 : Authentication with Certificate exchange Any pointers? Regards eT From owner-ipsec@lists.tislabs.com Tue Oct 5 08:53:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA08755; Tue, 5 Oct 1999 08:53:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23168 Tue, 5 Oct 1999 10:07:22 -0400 (EDT) Date: Tue, 5 Oct 1999 10:08:57 -0400 Message-Id: <199910051408.KAA03353@brill.shiva.com> From: John Shriver To: ipsec@lists.tislabs.com Subject: monitoring anti-replay detection in AH and ESP Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm working with Tim Jekins on the IPSec MIB, and the issue of what to do about monitoring the anti-replay detection system on receive in AH and ESP has come up. The reason I'm interested in properly instrumenting it is that "problems" with IPSec over the public internet will be necessarily hard to diagnose. For instance, if "performance stinks", why? Well, the anti-replay mechanism can detect a lot of things that the underlying network can do to screw up performance. You can get pretty effective measurements of both packet loss and packet reordering. For instance, if you recieve a packet that isn't the "next" one you expect to receive, then you know that the network may be reordering packets. If you're shifting lots of zeros out of the anti-replay bitmask, then there's probably high packet loss. So, there are a number of different counters we could propose. Some are easier to count than others. Others provide more information. Let me propose a few: 1. Packets received with sequence number > highest received + 1. This can indicate either a dropped packet, or reordering. This counts the number of times that the bit map was rotated more than one bit when a packet was received. 2. Packets received with sequence number < highest received, but in window. This can only indicate reordering. 3. Unused sequence numbers removed from window. This is essentially a count of the number of 0 (not seen) bits that you shift out of the bitmask when event 1 (above) happens. (Well, it also would increment if you shifted out a 0 on a normal "next expected" receive.) These are most likely lost packets, although there is a possibility that it is caused by large-scale reordering. This is the hardest one to implement. But it really is the best count of lost packets. Event 1 is quite shared between lost and reordering. The value of this counter goes up the longer the receive window for anti-replay is. (We'll also put the receive window in the MIB, to allow properly scaled interpretation of these.) This counter also helps you know if a high count of replay errors really represents an attack, or just high reordering that needs a larger window. Obviously, there will also be a count of true replay errors, which I presume is completely acceptable to all. However, even this could be made more specific. We could split it into: 4. Replay in window. This is either a real replay attack, or packet duplication by the network. 5. Replay out of window. This could be either a replay attack, or massive packet reordering. The code logic has to detect cases 4 and 5 seperately, so it's not a great burden to count both ways. I suppose that the exception would be hardware that might not report the difference. Anybody done that, or doing that? If so, these two (4 & 5) could be optional counters, with a mandatory "replay error" counter. From owner-ipsec@lists.tislabs.com Tue Oct 5 10:14:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA09989; Tue, 5 Oct 1999 10:14:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23474 Tue, 5 Oct 1999 11:32:33 -0400 (EDT) Date: Tue, 5 Oct 1999 11:24:30 -0400 Message-Id: <199910051524.LAA27112@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jas@shiva.com Cc: ipsec@lists.tislabs.com Subject: Re: monitoring anti-replay detection in AH and ESP References: <199910051408.KAA03353@brill.shiva.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't particularly like anything that adds overhead to the normal processing case. The things you propose partly can be done in the "error" path, but it seems to me you're adding at least a few instructions to the normal path. For example, the "unused sequence numbers removed from window" and "reordering within the window" cases seem to require that. It looks to me like your counters 1..3 are problematic for this reason, while counters 4 and 5 are ok. Another small point: Many replays can be detected without doing packet authentication first. So the "replay in window" and "replay out of window" cases actually have three possible causes, not just two: duplication or major resequencing; replay; packet forgery. That last case can be distinguished by doing the integrity check, but doing that on a packet already known to be unacceptable would be a bit silly. paul From owner-ipsec@lists.tislabs.com Tue Oct 5 10:17:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA10031; Tue, 5 Oct 1999 10:17:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23514 Tue, 5 Oct 1999 11:49:49 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <37F95B6F.99C6C7D7@redcreek.com> References: <447A3F40A07FD211BA2700A0C99D759B05D131@md-exchange1.nai.com> <37BD69EF.497CE861@ibm.net> Date: Tue, 5 Oct 1999 06:00:37 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: Non-IP type Client IDs Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, You are correct; the language re creation of temporary SPD entries is not present. Perhaps we should be more explicit about that in the next rev, but I think we did not describe the "how" because of complaints from implementors about undue specification detail. The fact that the RFC mandates support for user IDs, and the fact that an SG cannot possibly match against such IDs in packet headers, implies the need to do something equivalent to the temporary SPD entry approach. What do other folks think is appropriate re adding additional details? Steve From owner-ipsec@lists.tislabs.com Tue Oct 5 11:00:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA10629; Tue, 5 Oct 1999 11:00:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23625 Tue, 5 Oct 1999 12:29:00 -0400 (EDT) Message-Id: <199910051629.QAA02739@orchard.arlington.ma.us> To: Stephen Kent cc: "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Non-IP type Client IDs In-Reply-To: Message from Stephen Kent of "Tue, 05 Oct 1999 06:00:37 EDT." Date: Tue, 05 Oct 1999 12:29:45 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > What do other folks think is appropriate re adding additional details? Mentioning "temporary" SPD's as one legitimate implementation strategy sounds like the way to go here.. Specifying that the stack has to behave *as if* a temporary SPD entry had been added might also be appropriate. - Bill From owner-ipsec@lists.tislabs.com Tue Oct 5 15:32:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA14049; Tue, 5 Oct 1999 15:32:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24506 Tue, 5 Oct 1999 17:07:30 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: RE: monitoring anti-replay detection in AH and ESP Date: Tue, 5 Oct 1999 17:23:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81CFBCC@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: John Shriver [mailto:jas@shiva.com] > Sent: 05 October 1999 15:09 > To: ipsec@lists.tislabs.com > Subject: monitoring anti-replay detection in AH and ESP > 3. Unused sequence numbers removed from window. > > This is essentially a count of the number of 0 (not seen) bits that > you shift out of the bitmask when event 1 (above) happens. (Well, it > also would increment if you shifted out a 0 on a normal "next > expected" receive.) These are most likely lost packets, although > there is a possibility that it is caused by large-scale reordering. > > This is the hardest one to implement. But it really is the best count > of lost packets. Event 1 is quite shared between lost and reordering. > > The value of this counter goes up the longer the receive window for > anti-replay is. (We'll also put the receive window in the MIB, to > allow properly scaled interpretation of these.) > > This counter also helps you know if a high count of replay errors > really represents an attack, or just high reordering that needs a > larger window. I'd have thought this counter would go up more slowly the longer the receive window, theoretically at least. The longer the receive window is the less chance there is of a reordered packet being recorded as a lost packet (and hence as replayed out of window). OTOH, I don't think it's so hard to implement in software at least. The counter needs to be checked whenever the replay window is advanced. The receive window may need to be 'pre-charged' with ones to prevent spurious dropped packets being reported immediately after the SA is created. There is also a need to cope with the special case of a loss of a large block of packets. Large quantities of duplicate packets don't necessarily mean an attack - it may be an (un)intentional result of network routing. Chris From owner-ipsec@lists.tislabs.com Tue Oct 5 15:32:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA14069; Tue, 5 Oct 1999 15:32:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24497 Tue, 5 Oct 1999 17:06:30 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B001D6A356@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'Paul Koning'" , jas@shiva.com Cc: ipsec@lists.tislabs.com Subject: RE: monitoring anti-replay detection in AH and ESP Date: Tue, 5 Oct 1999 08:54:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments inline... > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Tuesday, October 05, 1999 11:25 AM > To: jas@shiva.com > Cc: ipsec@lists.tislabs.com > Subject: Re: monitoring anti-replay detection in AH and ESP > > > I don't particularly like anything that adds overhead to the normal > processing case. The things you propose partly can be done in the > "error" path, but it seems to me you're adding at least a few > instructions to the normal path. For example, the "unused sequence > numbers removed from window" and "reordering within the window" cases > seem to require that. It looks to me like your counters 1..3 are > problematic for this reason, while counters 4 and 5 are ok. > Yes, they aren't free. On the other hand, the events that cause them shouldn't be "first order" in terms of common-ness. (The exception is shifting out one bit of 0.) Perhaps we can put them in as optional? (Theoretically: let the market decide?) There certainly is always comparing the packet counters at the transmitting and receiving SA's. But that assumes that you are granted SNMP access to the sender's SA MIB entries. No assurance of that, you may only have access to the reciever. > Another small point: > > Many replays can be detected without doing packet authentication > first. So the "replay in window" and "replay out of window" cases > actually have three possible causes, not just two: duplication or > major resequencing; replay; packet forgery. That last case can be > distinguished by doing the integrity check, but doing that on a packet > already known to be unacceptable would be a bit silly. > Yeah, that level of diagnosis is probably excessive. There are other tools that come into play when forgery is detected... > paul > From owner-ipsec@lists.tislabs.com Tue Oct 5 15:33:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA14082; Tue, 5 Oct 1999 15:33:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24401 Tue, 5 Oct 1999 16:50:03 -0400 (EDT) Message-ID: <19398D273324D3118A2B0008C7E9A569027515E2@SIT.platinum.corp.microsoft.com> From: "Brian Swander (Exchange)" To: "'Dan Harkins'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: reliable notify question Date: Tue, 5 Oct 1999 13:51:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is a small problem with this. It is perhaps so small as to be irrelevant, but I'll let you decide. Say both peers (A and B) decide send a reliable delete on the same SA at approx. the same time. By a fluke, both generate the same random mess_id for the message. Now, each sends delete expecting an ACK. When B gets A's message, he will expect it to be an ACK, since the mess_id is the same as the message he sent. B will therefore try to verify the hash, and fail, since it was in reality a new notify, not an ACK, from A. Similarily for A processing B's notify. Again, I don't know if we care, since the odds of this occurring are slim. However, it will break processing of these notifies. A fix is to distinguish in the payload the difference between an new notify and an ACK, perhaps as a flag in the header. However, adding such a flag makes backwards compatibility much harder. Is there any other good solution that still preserves the relatively simple backwards compatability? bs -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Monday, October 04, 1999 5:39 PM To: Brian Swander (Exchange) Cc: 'ipsec@lists.tislabs.com' Subject: Re: reliable notify question They have to be the same, just like all the other exchanges. Otherwise there would be no way to distinguish a response to your notify from a newly initiated notify from the peer. Dan. On Mon, 04 Oct 1999 13:11:23 PDT you wrote > Also, MUST the message_id in the responders ACK be the same as the > message_id in the initiator's N/D, or MUST the message_ids be different? > > I'd argue for the former, since it will allow easier lookups, and I doubt > there are any security issues with the duplicate mess_id. > > bs > > -----Original Message----- > From: Brian Swander (Exchange) > Sent: Monday, October 04, 1999 10:11 AM > To: 'Dan Harkins' > Cc: ipsec@lists.tislabs.com > Subject: reliable notify question > > > Pardon me if this has been asked before. > > In section 6.4.2 of the new IKE draft on reliable notifies, it says we need > to use the initiator and responder nonces in constructing the messages. > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), Ni, N/D --> > <-- HDR*, HASH(2), Nr, N/D > > First, are these values the nonces that were already exchanged, or are they > newly generated for each reliable notify? I presume the former. > > If I am right so far, which nonce do we use, the MM nonces, or the QM > nonces? I assume that we always use the MM nonce, since notifies are only > really bound to the MM, and not to any particular QM. > > Is this correct? > > bs > > From owner-ipsec@lists.tislabs.com Tue Oct 5 16:59:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA15191; Tue, 5 Oct 1999 16:59:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24746 Tue, 5 Oct 1999 18:38:46 -0400 (EDT) Message-ID: <37FA7DDC.6175A459@ire-ma.com> Date: Tue, 05 Oct 1999 18:38:21 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Brian Swander (Exchange)" CC: "'Dan Harkins'" , "'ipsec@lists.tislabs.com'" Subject: Re: reliable notify question References: <19398D273324D3118A2B0008C7E9A569027515E2@SIT.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brian, If you considering chances for generating the same message IDs on both ends - this will break lots of things in IKE - not just reliable notifies. "Brian Swander (Exchange)" wrote: > There is a small problem with this. It is perhaps so small as to be > irrelevant, but I'll let you decide. > > Say both peers (A and B) decide send a reliable delete on the same SA at > approx. the same time. By a fluke, both generate the same random mess_id > for the message. Now, each sends delete expecting an ACK. When B gets A's > message, he will expect it to be an ACK, since the mess_id is the same as > the message he sent. B will therefore try to verify the hash, and fail, > since it was in reality a new notify, not an ACK, from A. Similarily for A > processing B's notify. > > Again, I don't know if we care, since the odds of this occurring are slim. > However, it will break processing of these notifies. A fix is to > distinguish in the payload the difference between an new notify and an ACK, > perhaps as a flag in the header. However, adding such a flag makes > backwards compatibility much harder. Is there any other good solution that > still preserves the relatively simple backwards compatability? > > bs > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: Monday, October 04, 1999 5:39 PM > To: Brian Swander (Exchange) > Cc: 'ipsec@lists.tislabs.com' > Subject: Re: reliable notify question > > They have to be the same, just like all the other exchanges. Otherwise > there would be no way to distinguish a response to your notify from a > newly initiated notify from the peer. > > Dan. > > On Mon, 04 Oct 1999 13:11:23 PDT you wrote > > Also, MUST the message_id in the responders ACK be the same as the > > message_id in the initiator's N/D, or MUST the message_ids be different? > > > > I'd argue for the former, since it will allow easier lookups, and I doubt > > there are any security issues with the duplicate mess_id. > > > > bs > > > > -----Original Message----- > > From: Brian Swander (Exchange) > > Sent: Monday, October 04, 1999 10:11 AM > > To: 'Dan Harkins' > > Cc: ipsec@lists.tislabs.com > > Subject: reliable notify question > > > > > > Pardon me if this has been asked before. > > > > In section 6.4.2 of the new IKE draft on reliable notifies, it says we > need > > to use the initiator and responder nonces in constructing the messages. > > > > Initiator Responder > > ----------- ----------- > > HDR*, HASH(1), Ni, N/D --> > > <-- HDR*, HASH(2), Nr, N/D > > > > First, are these values the nonces that were already exchanged, or are > they > > newly generated for each reliable notify? I presume the former. > > > > If I am right so far, which nonce do we use, the MM nonces, or the QM > > nonces? I assume that we always use the MM nonce, since notifies are only > > really bound to the MM, and not to any particular QM. > > > > Is this correct? > > > > bs > > > > From owner-ipsec@lists.tislabs.com Wed Oct 6 04:48:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA12736; Wed, 6 Oct 1999 04:48:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26413 Wed, 6 Oct 1999 06:00:36 -0400 (EDT) From: mcr@sandelman.ottawa.on.ca Message-Id: <199910060955.FAA05040@pzero.sandelman.ottawa.on.ca> To: diffserv@ops.ietf.org CC: ipsec@lists.tislabs.com Subject: diffedge handling of fragments Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 06 Oct 1999 05:55:32 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- If a non-initial fragment arrives at a marking point (i.e. at the entry point to a diffserv cloud), and no previous initial fragment has been received for that (destination,fragmentID), should the fragment be: 1) delayed until an initial fragment arrives (how long?) 2) sent with best effort 3) dropped In the pathological case, the fragment offset is such that one has to reassemble the packet in order to make the MF classication decision. I believe that in these cases it may be prudent to drop the fragment as it may simply be an attempt to do a denial of service attack. Otherwise, #3 is evil, as it causes outages that are very hard to debug. #1 turns into #3 if there is no timer involved. One possibility is to send it with best effort, *and* queue it for a period such that it gets sent with the appropriate flag. Two notes: 1. I don't think that IPsec has yet to agree on anything specific to say about this particular case other than noting that the TCP/UDP ports may be "OPAQUE" in section 4.4.2 of RFC2401. This hasn't been an issue since most deployment has so far involved subnet<->subnet or host<->host and not port<->port SAs done by a security gateway. For IPsec, replace #2 with "sent with a host<->host SA" 2. RFC2205 (RSVP) specifically says on page 8: "1. It is necessary to avoid IP fragmentation of a data flow for which a resource reservation is desired." So, this would argue also for #2. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQB1AwUBN/sckI5hrHmwwFrtAQH+JgL+NbVcRLefglM05IjaKrfYA+ZisLogy2HO 76ZscNfd6Ywfjm/0RsKWs/Aut6IA48APi5Z/u7i6PSJ2pZ75NmhlWdUw/YbygclS /ksmxfvhFmPzolGIMJxj4MbPGD4OM3sF =+8wL -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Oct 6 05:17:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA13782; Wed, 6 Oct 1999 05:17:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26532 Wed, 6 Oct 1999 06:50:03 -0400 (EDT) Date: Wed, 6 Oct 1999 13:52:06 +0300 (EET DST) From: Markku Savela Message-Id: <199910061052.NAA29733@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com Subject: Use OTP in IPSEC? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is just one my random ideas that float in the background, and just decided to sound it off on this list... I think there might be some special cases where even use of OTP (One time pad) might be usable with IPSEC. Possible technical definition: Within ESP, each packet would, instead of IV, use an 64 bit offset to OTP that is somehow known to both ends (with the usual problems of keeping the OTP secret etc.) A server that provides some highly sensitive, but short, information as a responce to queries could use this method. [This almost implicitly requires the ability to negotiate assymmetric associations (currently only possible with manual configuring) Server ----> IPSEC(OTP) ------> clients <---- other protection [cant have multiple senders use the same OTP, as it would be hard to prevent the same pad segment being used twice]. OTP might be useful also in the key echange of the key management, if one is suspicious about the public key algorithms. From owner-ipsec@lists.tislabs.com Wed Oct 6 14:10:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA27858; Wed, 6 Oct 1999 14:10:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27978 Wed, 6 Oct 1999 15:15:09 -0400 (EDT) Message-ID: <636C2D109E6CD3119C3600062905FE8F8D45@MAIL-CLUSTER.calynet.com> From: Sumit Vakil To: diffserv@ops.ietf.org Cc: ipsec@lists.tislabs.com Subject: RE: diffedge handling of fragments Date: Wed, 6 Oct 1999 12:09:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, Section 4.4.2 of RFC 2401 also says that if the port information is not available in a fragment it is to be discarded. The exact text is as follows: If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. [MAY be supported] I'm not sure that sending a fragment over a host<->host SA would always be the best course of action. The host<->host SA might not provide the required security for the fragment. Sumit A. Vakil Caly Corp > -----BEGIN PGP SIGNED MESSAGE----- > > > If a non-initial fragment arrives at a marking point (i.e. > at the entry > point to a diffserv cloud), and no previous initial fragment has been > received for that (destination,fragmentID), should the fragment be: > 1) delayed until an initial fragment arrives (how long?) > 2) sent with best effort > 3) dropped > > In the pathological case, the fragment offset is such that > one has to > reassemble the packet in order to make the MF classication decision. I > believe that in these cases it may be prudent to drop the > fragment as it may > simply be an attempt to do a denial of service attack. > Otherwise, #3 is evil, as it causes outages that are very > hard to debug. > #1 turns into #3 if there is no timer involved. > > One possibility is to send it with best effort, *and* queue > it for a period > such that it gets sent with the appropriate flag. > > Two notes: > 1. I don't think that IPsec has yet to agree on anything > specific to say > about this particular case other than noting that the > TCP/UDP ports may > be "OPAQUE" in section 4.4.2 of RFC2401. This hasn't been > an issue since > most deployment has so far involved subnet<->subnet or > host<->host and not > port<->port SAs done by a security gateway. For IPsec, > replace #2 with > "sent with a host<->host SA" > > 2. RFC2205 (RSVP) specifically says on page 8: > > > "1. It is necessary to avoid IP fragmentation of a > data flow for > which a resource reservation is desired." > > So, this would argue also for #2. > > ] Train travel features AC outlets with no take-off > restrictions| firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQB1AwUBN/sckI5hrHmwwFrtAQH+JgL+NbVcRLefglM05IjaKrfYA+ZisLogy2HO 76ZscNfd6Ywfjm/0RsKWs/Aut6IA48APi5Z/u7i6PSJ2pZ75NmhlWdUw/YbygclS /ksmxfvhFmPzolGIMJxj4MbPGD4OM3sF =+8wL -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Oct 6 15:55:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA00265; Wed, 6 Oct 1999 15:55:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28507 Wed, 6 Oct 1999 17:32:48 -0400 (EDT) Message-Id: <199910062127.RAA04086@pzero.sandelman.ottawa.on.ca> To: Sumit Vakil cc: ipsec@lists.tislabs.com Subject: Re: diffedge handling of fragments In-reply-to: Your message of "Wed, 06 Oct 1999 12:09:38 PDT." <636C2D109E6CD3119C3600062905FE8F8D45@MAIL-CLUSTER.calynet.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 06 Oct 1999 17:27:49 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sumit" == Sumit Vakil writes: Sumit> Michael, Section 4.4.2 of RFC 2401 also says that if the port Sumit> information is not available in a fragment it is to be discarded. Sumit> The exact text is as follows: Sumit> If the packet has been fragmented, then the port information may Sumit> not be available in the current fragment. If so, discard the Sumit> fragment. An ICMP PMTU should be sent for the first fragment, Sumit> which will have the port information. [MAY be supported] Uh, I read this to be in the context of doing ICMP PMTU discovery for the end hosts of the MTU of the tunnel. Sumit> I'm not sure that sending a fragment over a host<->host SA would Sumit> always be the best course of action. The host<->host SA might not Sumit> provide the required security for the fragment. Agreed. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Oct 6 16:21:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA01067; Wed, 6 Oct 1999 16:21:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28576 Wed, 6 Oct 1999 18:08:23 -0400 (EDT) Message-ID: <636C2D109E6CD3119C3600062905FE8F8D49@MAIL-CLUSTER.calynet.com> From: Sumit Vakil To: ipsec@lists.tislabs.com Subject: RE: diffedge handling of fragments Date: Wed, 6 Oct 1999 15:02:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Sumit" == Sumit Vakil writes: > > Sumit> Michael, Section 4.4.2 of RFC 2401 also says that > if the port > Sumit> information is not available in a fragment it is > to be discarded. > Sumit> The exact text is as follows: > > Sumit> If the packet has been fragmented, then the port > information may > Sumit> not be available in the current fragment. If so, > discard the > Sumit> fragment. An ICMP PMTU should be sent for the > first fragment, > Sumit> which will have the port information. [MAY be supported] > > Uh, I read this to be in the context of doing ICMP PMTU > discovery for > the end hosts of the MTU of the tunnel. Line 3 of the table just above this paragraph (the one that shows how to derive the port selector for the SPD and the SAD) indicates the condition when a fragment is to be dropped: next header in fragment == transport layer protocol in SPD My understanding is that the table is to be used for all traffic. If that is true, then fragments satisfying the above condition have to be dropped. Sumit From owner-ipsec@lists.tislabs.com Thu Oct 7 06:16:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA10683; Thu, 7 Oct 1999 06:16:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA00306 Thu, 7 Oct 1999 06:50:31 -0400 (EDT) Message-ID: <37FC7B72.55FE5AD6@DataFellows.com> Date: Thu, 07 Oct 1999 13:52:34 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Markku Savela CC: ipsec@lists.tislabs.com Subject: Re: Use OTP in IPSEC? References: <199910061052.NAA29733@anise.tte.vtt.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Would it be possible to use this idea together with the Host Identity Payload? Use something based on One Time Passwords instead of DSA? E.g. something like - First message is DSA-authenticated by the sender and contains, in addition to existing HIP-stuff, an OTP-seed-value that is RSA-encrypted with the recipients public key. (The encrypted seed value would also be authenticated.) - Both parties calculate hashes from the seed value N times, and start using them in reverse order. - Next message sent by the same sender will no longer use DSA, but something based on OTP. The receiver would have some sort of replay protection window to allow for packet re-orderings while in transit. This method could also be used for encryption, the initiator would one-sidedly choose the encryption key it wishes, and send that encrypted with the recipient's public key. Just an idea... Ari Markku Savela wrote: > This is just one my random ideas that float in the background, and > just decided to sound it off on this list... > > I think there might be some special cases where even use of OTP (One > time pad) might be usable with IPSEC. > > Possible technical definition: Within ESP, each packet would, instead > of IV, use an 64 bit offset to OTP that is somehow known to both ends > (with the usual problems of keeping the OTP secret etc.) > > A server that provides some highly sensitive, but short, > information as a responce to queries could use this > method. [This almost implicitly requires the ability to > negotiate assymmetric associations (currently only possible > with manual configuring) > > Server ----> IPSEC(OTP) ------> clients > <---- other protection > > [cant have multiple senders use the same OTP, as it would be > hard to prevent the same pad segment being used twice]. > > OTP might be useful also in the key echange of the key management, if > one is suspicious about the public key algorithms. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Oct 8 05:42:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA10956; Fri, 8 Oct 1999 05:42:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04005 Fri, 8 Oct 1999 06:52:50 -0400 (EDT) Message-Id: <199910081054.GAA14449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt Date: Fri, 08 Oct 1999 06:54:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A GSS-API Authentication Mode for IKE Author(s) : D. Piper Filename : draft-ietf-ipsec-isakmp-gss-auth-03.txt Pages : 11 Date : 07-Oct-99 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. For a list of changes since the previous version of this document, please see Section 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-03.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-ietf-ipsec-isakmp-gss-auth-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991007135640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991007135640.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Oct 8 09:35:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA14510; Fri, 8 Oct 1999 09:35:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04566 Fri, 8 Oct 1999 10:29:23 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE464@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt Date: Fri, 8 Oct 1999 15:30:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell, I've taken a quick wonder through the GSS documents now. And I have a questions: A few weeks/months back, we were debating on the list how public-key could be used with IKE without the need for PKI (CA/CRL/RA). One of the suggestions that came out (that I was fond of :) ), was you provide clients with just their own private key, and the public key of the server. The server has its own public/private key, and access to a secure database containing the clients private keys. This was given the name 'private public-key'. The IKE exchange is standard signature authentication, with off-line cracking protection. >From what I can tell from GSS and your draft, it is basically the same model, except that we are talking about adding a new 'thing' everywhere called GSS-API software. Cheers, Steve. From owner-ipsec@lists.tislabs.com Sun Oct 10 14:18:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA07593; Sun, 10 Oct 1999 14:18:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10060 Sun, 10 Oct 1999 15:33:44 -0400 (EDT) Date: Sun, 10 Oct 1999 15:34:27 -0400 From: Rich Neill Message-Id: <199910101934.PAA04364@eagle.ameristar.com> To: ipsec@lists.tislabs.com Subject: ipsec ldap schema Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Where can I find draft-ipsec-vpn-policy-schema-oo.txt which discussed representing IPSec policies within a ldap system? It no longer seems to be available ietf. Thanks. Rich Neill rich@ameristar.com From owner-ipsec@lists.tislabs.com Mon Oct 11 04:07:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA27279; Mon, 11 Oct 1999 04:07:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA11950 Mon, 11 Oct 1999 05:44:01 -0400 (EDT) Message-ID: <01BF13D5.F25DF970.lisa@baltimore.ie> From: Lisa Wilkinson Reply-To: "lisa@baltimore.ie" To: "'Waters, Stephen'" , "ipsec@lists.tislabs.com" Subject: RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt Date: Mon, 11 Oct 1999 10:00:53 +0100 Organization: Baltimore Technologies X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, I would have a couple of questions with this approach: - as the client is not solely responsible for its private key, how is no non repudiation dealt with - what means of "secure" transmission and storage of private keys does it propose - in case of a compromise of the secure store of private keys, as with Kerberos, would all private keys need to revoked, regenerated and re-issued. Does this not lead to administrative and scalability problems? Lisa -----Original Message----- From: Waters, Stephen [SMTP:Stephen.Waters@cabletron.com] Sent: Friday, October 08, 1999 3:30 PM To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt Derrell, I've taken a quick wonder through the GSS documents now. And I have a questions: A few weeks/months back, we were debating on the list how public-key could be used with IKE without the need for PKI (CA/CRL/RA). One of the suggestions that came out (that I was fond of :) ), was you provide clients with just their own private key, and the public key of the server. The server has its own public/private key, and access to a secure database containing the clients private keys. This was given the name 'private public-key'. The IKE exchange is standard signature authentication, with off-line cracking protection. >From what I can tell from GSS and your draft, it is basically the same model, except that we are talking about adding a new 'thing' everywhere called GSS-API software. Cheers, Steve. From owner-ipsec@lists.tislabs.com Mon Oct 11 06:00:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA00284; Mon, 11 Oct 1999 06:00:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12177 Mon, 11 Oct 1999 07:39:27 -0400 (EDT) Date: Mon, 11 Oct 1999 14:41:35 +0300 (EET DST) From: Markku Savela Message-Id: <199910111141.OAA00910@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com In-reply-to: <01BF13D5.F25DF970.lisa@baltimore.ie> (message from Lisa Wilkinson on Mon, 11 Oct 1999 10:00:53 +0100) Subject: RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Waters, Stephen [SMTP:Stephen.Waters@cabletron.com] > > One of the suggestions that came out (that I was fond of :) ), was you > provide clients with just their own private key, and the public key of the > server. The server has its own public/private key, and access to a secure > database containing the clients private keys. As I'm trying to specify a suitable test environment for demonstrating IPSEC (more than just PING over fixed end points), the above appears to be fairly close what I have in mind. But, as I'm still a bit out of my area when public keys and ISAKMP is involved, there may be some catches that I am not aware of. And to verify, if I understood all correctly, I present my ideas and understanding the above here: - we have a server host with known fixed IP address (for example, SMTP + POP + IMAP, perhaps IRC, WWW or whatever), - we want to allow client IPSEC device to connect this server from random IP address (e.g. client calls any suitable ISP and uses whatever dynamic address it gets) - only known users must be able to connect (eg. only company employees, or people who have paid for the service) Would this be achieved with the following setup - the organizaion runs own server specific CA setup - the server ISAKMP only accepts clients that have their keys signed by the server CA directly (e.g. server ISAKMP is configured only to accept single CA = self) - the access to server is given to client by having their public key certified by the servers key (including policy changes for IPSEC on the client). That is, client is given 3 pieces of information: IPSEC policy changes, servers public key and clients server-certified public key. Is there ISAKMP negotiation mode that can establish a connection from client to server based on above information? As far as I can see, the clients IP address should not be needed (the server policy requires IPSEC for ALL connections by default, except of course having port 500 clear!) It would seem that certificate revocation would be fairly easy to manage as the control is all within organization. Revoked certificate list could be on the server and directly available to the ISAKMP. Thus, if a client is careless with the private key, certificates based on it can be quickly revoked. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Mon Oct 11 14:39:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA10569; Mon, 11 Oct 1999 14:39:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14297 Mon, 11 Oct 1999 16:00:05 -0400 (EDT) Message-ID: <19991011201148.18587.rocketmail@web1405.mail.yahoo.com> Date: Mon, 11 Oct 1999 13:11:48 -0700 (PDT) From: Pyda Srisuresh Subject: RE: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-03.txt To: Markku Savela , ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds like your approach should work. I believe, many vendors use this type of an approach to get their initial IKE implementations (with certificate based authentication support) out the door. cheers, suresh --- Markku Savela wrote: > > From: Waters, Stephen [SMTP:Stephen.Waters@cabletron.com] > > > > One of the suggestions that came out (that I was fond of :) ), was you > > provide clients with just their own private key, and the public key of the > > server. The server has its own public/private key, and access to a secure > > database containing the clients private keys. > > As I'm trying to specify a suitable test environment for demonstrating > IPSEC (more than just PING over fixed end points), the above appears > to be fairly close what I have in mind. > > But, as I'm still a bit out of my area when public keys and ISAKMP is > involved, there may be some catches that I am not aware of. And to > verify, if I understood all correctly, I present my ideas and > understanding the above here: > > - we have a server host with known fixed IP address (for example, > SMTP + POP + IMAP, perhaps IRC, WWW or whatever), > > - we want to allow client IPSEC device to connect this server from > random IP address (e.g. client calls any suitable ISP and uses > whatever dynamic address it gets) > > - only known users must be able to connect (eg. only company > employees, or people who have paid for the service) > > Would this be achieved with the following setup > > - the organizaion runs own server specific CA setup > > - the server ISAKMP only accepts clients that have their keys signed > by the server CA directly (e.g. server ISAKMP is configured only to > accept single CA = self) > > - the access to server is given to client by having their public key > certified by the servers key (including policy changes for IPSEC on > the client). That is, client is given 3 pieces of information: > IPSEC policy changes, servers public key and clients > server-certified public key. > > Is there ISAKMP negotiation mode that can establish a connection from > client to server based on above information? As far as I can see, the > clients IP address should not be needed (the server policy requires > IPSEC for ALL connections by default, except of course having port 500 > clear!) > > It would seem that certificate revocation would be fairly easy to > manage as the control is all within organization. Revoked certificate > list could be on the server and directly available to the > ISAKMP. Thus, if a client is careless with the private key, > certificates based on it can be quickly revoked. > > -- > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland > Multimedia Systems, P.O.Box 1203,FIN-02044 > VTT,http://www.vtt.fi/tte/staff/msa/ > ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Wed Oct 13 02:02:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id CAA16261; Wed, 13 Oct 1999 02:02:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA19634 Wed, 13 Oct 1999 03:08:36 -0400 (EDT) Message-Id: <199910130705.AAA03327@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 13 Oct 1999 00:05:29 -0700 To: ippcp@external.cisco.com From: Avram Shacham Subject: Fwd: I-D ACTION:draft-shacham-ippcp-rfc2393bis-01.txt Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For those who are not on IETF-Announce, attached is the announcement of the new version of rfc2393bis. (For some reason, no message was posted to the requested lists.) The change in the -01 version reflects comments that were posted to the lists -- see the attached diff. Regards, avram >X-SMAP-Received-From: outside >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-01.txt >Date: Tue, 12 Oct 1999 06:55:52 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Payload Compression Protocol (IPComp) > Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas > Filename : draft-shacham-ippcp-rfc2393bis-01.txt > Pages : 9 > Date : 11-Oct-99 > >This document describes a protocol intended to provide lossless >compression for Internet Protocol datagrams in an Internet >environment. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-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-shacham-ippcp-rfc2393bis-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-shacham-ippcp-rfc2393bis-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. >Content-Type: text/plain >Content-ID: <19991011110653.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-01.txt > > > 352c352,358 < value of Transport Mode is assumed. --- > value of Transport Mode is assumed. When IPComp is negotiated as > part of a Protection Suite, and when the negotiation protocol > requires that all the logically related offers must be consistent, > the IPComp proposals MUST include all the attributes of every > transform being negotiated, but those attributes not relevant to > IPComp MUST be ignored when setting the IPCA and therefore ignored in > the operation of IPComp. === eom === From owner-ipsec@lists.tislabs.com Wed Oct 13 14:16:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA14861; Wed, 13 Oct 1999 14:16:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24694 Wed, 13 Oct 1999 15:15:49 -0400 (EDT) Message-ID: <3804DAB3.6A8B3529@indusriver.com> Date: Wed, 13 Oct 1999 15:17:07 -0400 From: Ben McCann X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: Racing QM Initiator's Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk By dumb luck, I just had two SG's attempt a QM exchange with each other _at_the_same_time_. Each sent the first QM packet as initiator and each got that packet and tried to act as QM responder. Both got confused because they both switched from Initiator to Responder in mid-stream. Here was my test configuration: C1-----SG=======SG-----C2 Clients 1 and 2 (C1, C2) are both pinging each other. Policy on the SG's creates tunnel mode SA's for the ping traffic. The current Phase 2 SA for ping expires at the same time on both SG's. Then next ping send by each client triggers each SG to create a Phase 2 SA. What is the interoperable way to solve this race? I trolled through the list archives but didn't see anything relevant. Possibilities are: 1. Deal with it. Two QM exchanges occur where both SG's are temporarily both Phase 2 initiator and responder. (This could be tough because that state is part of the parent Phase 1 SA). 2. Both SG's abort the QM exchange, backoff, and retry later. 3. One SG aborts and becomes responder. How do you know which should abort? The SG with the lowest IP address? I'm sure there are other options too. Any opinions are welcome... Thanks, Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Wed Oct 13 16:16:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA17046; Wed, 13 Oct 1999 16:16:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25146 Wed, 13 Oct 1999 17:42:10 -0400 (EDT) Message-ID: <3804FD35.C223DD42@openroute.com> Date: Wed, 13 Oct 1999 17:44:21 -0400 From: Radha Gowda X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Ben McCann CC: "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's References: <3804DAB3.6A8B3529@indusriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3. One SG aborts and becomes responder. How do you know which should > abort? The SG with the lowest IP address? Ben, we also experienced the same problem. Not just in phase2, but in phase1 as well. Just to get things going, we decided to let the one with the higher IP address be the initiator. From owner-ipsec@lists.tislabs.com Wed Oct 13 16:23:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA17198; Wed, 13 Oct 1999 16:23:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25303 Wed, 13 Oct 1999 18:04:30 -0400 (EDT) Message-ID: <3805023F.DD18AACE@indusriver.com> Date: Wed, 13 Oct 1999 18:05:51 -0400 From: Ben McCann X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Vipul Gupta CC: ipsec@lists.tislabs.com, vipul.gupta@sun.com Subject: Re: Racing QM Initiator's References: <199910132130.OAA04907@hsmpka.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But aren't these two messages going out with different message IDs > generated randomly by each Phase II initiator? If so, why is there > a problem ? This will result in two IPSec SAs where one would have > been sufficient but I don't view that as catastrophic. > > What am I missing? > > vipul Nothing, they do have separate message ID's but our implementation is getting confused about being a QM responder and initiator on separate QM exchanges at the same time. I'll just have to fix it... I just wanted to verify that the expected behavior is that you must be able to support multiple QM exchanges simultaneously. Feedback from the list has made that abundantly clear.... -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Wed Oct 13 17:07:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA17847; Wed, 13 Oct 1999 17:07:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25493 Wed, 13 Oct 1999 18:52:17 -0400 (EDT) Message-ID: <38050D9C.9E036B9@cyphers.net> Date: Wed, 13 Oct 1999 15:54:27 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.61 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Ben McCann CC: "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's References: <3804DAB3.6A8B3529@indusriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben McCann wrote: > > By dumb luck, I just had two SG's attempt a QM exchange with each > other _at_the_same_time_. Each sent the first QM packet as > initiator and each got that packet and tried to act as QM > responder. Both got confused because they both switched from > Initiator to Responder in mid-stream. > > Here was my test configuration: > > C1-----SG=======SG-----C2 > > Clients 1 and 2 (C1, C2) are both pinging each other. Policy on the > SG's creates tunnel mode SA's for the ping traffic. The current > Phase 2 SA for ping expires at the same time on both SG's. Then > next ping send by each client triggers each SG to create a Phase 2 > SA. > > What is the interoperable way to solve this race? I trolled through > the list archives but didn't see anything relevant. Possibilities > are: > > 1. Deal with it. Two QM exchanges occur where both SG's are > temporarily both Phase 2 initiator and responder. So you end up with two SAs. No problem. > (This could be tough because that > state is part of the parent Phase 1 SA). That's an implementation detail. Either side can initiate a QM and if they do it simultaneously and you end up with two SAs I don't see why it would matter. They're both perfectly valid. > 2. Both SG's abort the QM exchange, backoff, and retry later. > > 3. One SG aborts and becomes responder. How do you know which > should abort? The SG with the lowest IP address? > > I'm sure there are other options too. Any opinions are welcome... > > Thanks, > Ben McCann > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBOAUNj6y7FkvPc+xMEQJTVQCcCrACM3N1FEbKz3Q7QKJ4NSQOaZgAn0co UEShfOHwr8tG52PH6BF6SvFr =2haU -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Oct 13 17:50:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA18626; Wed, 13 Oct 1999 17:50:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25648 Wed, 13 Oct 1999 19:33:07 -0400 (EDT) Message-ID: <38051734.FB79ADF5@openroute.com> Date: Wed, 13 Oct 1999 19:35:16 -0400 From: Radha Gowda X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Please note that until such a statement makes it into the rfc, what you are > doing may not be interoperable. > I fully understand that, and it had been my intention all along to find out how others deal with it. > Why is it such a problem to support both initiator and responder for both > phase 1 and phase 2 SA's? A robust implementation should be able to do this. Since it is not spelt out in the RFC on how to handle race condition, different people could interpret it differently. I'd find it rather confusing to see two phase1 SAs between the same addresses. But if that is the way it should be, we'll conform. From owner-ipsec@lists.tislabs.com Wed Oct 13 18:34:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA21695; Wed, 13 Oct 1999 18:34:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25836 Wed, 13 Oct 1999 20:02:16 -0400 (EDT) Message-ID: <38051E0D.672C4058@openroute.com> Date: Wed, 13 Oct 1999 20:04:29 -0400 From: Radha Gowda X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > To the list at large: > > Why can't we put verbiage like this into the RFC? Is there some reason this > is a bad thing to do? I also would like to point out to the list that Diffie-Hellman calculation does not come cheap for some of us (atleast for now). From owner-ipsec@lists.tislabs.com Wed Oct 13 19:11:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA24363; Wed, 13 Oct 1999 19:11:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25947 Wed, 13 Oct 1999 20:37:39 -0400 (EDT) Message-Id: <199910140038.RAA21792@Potassium.Network-Alchemy.COM> To: Radha Gowda cc: Jan Vilhuber , Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's In-reply-to: Your message of "Wed, 13 Oct 1999 19:35:16 EDT." <38051734.FB79ADF5@openroute.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21789.939861487.1@network-alchemy.com> Date: Wed, 13 Oct 1999 17:38:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you want something in the RFC then you should hold your discussions on the list. I'm not really sure what "it" is that is not spelt out in the RFC but I have the feeling that if it was people would say, "that's a policy decision". There are lots of things that are left unsaid under the assumption that the obvious choice would be the one taken. An example that was brought up in the past is, "it is not spelt out in the RFC what I should do when I get a vendor ID payload that I do not recognize." The choices I see being: 1) panic; 2) refuse the negotiation; or 3) nothing. The first two don't pass the "why would you want to do that?" test even though they are perfectly valid responses since it's not spelt out in the RFC. The same can be said of "what do I do when 2 peers simultaneously negotiate a Quick Mode to each other". The choices I see are: 1) panic; 2) arbitrarily drop a negotiation; or 3) just finish them both. The first one doesn't pass the "why would you do that?" test and the second is obviously problematic-- what if each side arbitrarily decides to drop the other one and you end up with no negotiation?!. The third therefore seems like the obvious choice. But again, it's not spelt out in the RFC and may arguably be a "policy decision". So "legally" any behavior is permissible (but probably not defendable). Again, if there's any verbage you'd like to get in the RFC you should have a discussion on the suggested verbage on the list so all can take part. Dan. On Wed, 13 Oct 1999 19:35:16 EDT you wrote > > > > Please note that until such a statement makes it into the rfc, what you are > > doing may not be interoperable. > > > > I fully understand that, and it had been my intention all along to find out >how > others deal with it. > > > Why is it such a problem to support both initiator and responder for both > > phase 1 and phase 2 SA's? A robust implementation should be able to do this >. > > Since it is not spelt out in the RFC on how to handle race condition, differe >nt > people could interpret it differently. I'd find it rather confusing to see t >wo > phase1 SAs between the same addresses. But if that is the way it should be, > we'll conform. > > From owner-ipsec@lists.tislabs.com Wed Oct 13 19:39:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA25745; Wed, 13 Oct 1999 19:39:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26053 Wed, 13 Oct 1999 21:21:36 -0400 (EDT) Message-ID: <3805317F.81F75D37@redcreek.com> Date: Wed, 13 Oct 1999 18:27:27 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Radha Gowda CC: Jan Vilhuber , Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's References: <38051E0D.672C4058@openroute.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radha Gowda wrote: > > > To the list at large: > > > > Why can't we put verbiage like this into the RFC? Is there some reason this > > is a bad thing to do? > > I also would like to point out to the list that Diffie-Hellman calculation does > not > come cheap for some of us (atleast for now). I think the point is that we must be able to support independent simultaneous SAs between security gateways. Otherwise, how will we provide PFS? If you cannot handle the DH calculation, then I suppose that you can serialize these, but this is not a good argument for dumbing down the standard, is it? Scott From owner-ipsec@lists.tislabs.com Wed Oct 13 20:43:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA29156; Wed, 13 Oct 1999 20:43:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26269 Wed, 13 Oct 1999 22:24:27 -0400 (EDT) Message-Id: <9910140238.AA02497@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Thu, 14 Oct 1999 11:38:14 +0900 To: Radha Gowda Cc: Jan Vilhuber , Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's In-Reply-To: <38051E0D.672C4058@openroute.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd also like to point out that Denial-of-Service attackers might abuse the cost of Diffie-Hellman calculation and public-key operations. (Please have a look at http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt ) Radha Gowda wrote: >>> To the list at large: >>> >>> Why can't we put verbiage like this into the RFC? Is there some reason this >>> is a bad thing to do? >> >>I also would like to point out to the list that Diffie-Hellman calculation does >>not >>come cheap for some of us (atleast for now). --^^-- Kanta From owner-ipsec@lists.tislabs.com Wed Oct 13 22:06:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA02491; Wed, 13 Oct 1999 22:06:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26513 Wed, 13 Oct 1999 23:44:17 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Scott G. Kelly'" Cc: Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com Subject: RE: Racing QM Initiator's Date: Wed, 13 Oct 1999 20:46:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While I agree with the notion of supporting multiple independent SAs this question is more out of curiosity. >From Richard Steven's TCP/IP Volume 1 Chapter 18.8 paragraph 4 'TCP was purposely designed to handle simultaneous opens and the rule is only one connection results from this, not two connections. (Other protcol suites, notably the OSI transport layer, create two connections in this scenario, not one).' I believe there is similiar wording in RFC 793 emphasising simultaneous open. I don't know if there is a particular advantage to this feature. During the initial design of IKE did such an approach (simultaneous connections resulting in one connection) come up in the discussions? Is it worthwhile or feasible for a security protocol? Thanks, -- sankar -- -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Wednesday, October 13, 1999 6:27 PM To: Radha Gowda Cc: Jan Vilhuber; Ben McCann; ipsec@lists.tislabs.com Subject: Re: Racing QM Initiator's Radha Gowda wrote: > > > To the list at large: > > > > Why can't we put verbiage like this into the RFC? Is there some reason this > > is a bad thing to do? > > I also would like to point out to the list that Diffie-Hellman calculation does > not > come cheap for some of us (atleast for now). I think the point is that we must be able to support independent simultaneous SAs between security gateways. Otherwise, how will we provide PFS? If you cannot handle the DH calculation, then I suppose that you can serialize these, but this is not a good argument for dumbing down the standard, is it? Scott From owner-ipsec@lists.tislabs.com Wed Oct 13 22:46:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA04167; Wed, 13 Oct 1999 22:46:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26579 Thu, 14 Oct 1999 00:34:36 -0400 (EDT) Message-Id: <199910140435.VAA22465@Potassium.Network-Alchemy.COM> To: Sankar Ramamoorthi cc: "'Scott G. Kelly'" , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com Subject: Re: Racing QM Initiator's In-reply-to: Your message of "Wed, 13 Oct 1999 20:46:03 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22462.939875727.1@network-alchemy.com> Date: Wed, 13 Oct 1999 21:35:27 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A TCP service (which, if you read the Stevens chapter is bound to both a source and destination port) can get away with having only one connection with simultaneous opens because that service only does one thing. A different example is BGP in which one side can be both doing a connect to a particular host and an accept on the BGP tcp port. The connect and accept can both happen "simultaneously" but only one particular connection results (the unpreferable connection will be dropped). But IKE is different. In IKE there can be 2 simultaneous Quick Modes which could be the result of different packets hitting different selectors both of which would need IPSec SAs but both can multiplex off the same existing IKE SA. You can't just arbitrarily drop a negotiation because you're already negotiating with that IKE peer. Basically, you have to allow simultaneous negotiation or else you would not be able to support a configuration which had different traffic selectors (optionally using different IPSec policy) to the same gateway. Dan. On Wed, 13 Oct 1999 20:46:03 PDT you wrote > While I agree with the notion of supporting multiple independent SAs > > this question is more out of curiosity. > > >From Richard Steven's TCP/IP Volume 1 Chapter 18.8 paragraph 4 > > 'TCP was purposely designed to handle simultaneous opens and the rule is > only one > connection results from this, not two connections. (Other protcol suites, > notably the OSI transport layer, create two connections in this scenario, > not one).' > I believe there is similiar wording in RFC 793 emphasising simultaneous > open. > > I don't know if there is a particular advantage to this feature. > During the initial design of IKE did such an approach (simultaneous > connections > resulting in one connection) come up in the discussions? Is it worthwhile > or feasible for a security protocol? > > Thanks, > > -- sankar -- > > > > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Wednesday, October 13, 1999 6:27 PM > To: Radha Gowda > Cc: Jan Vilhuber; Ben McCann; ipsec@lists.tislabs.com > Subject: Re: Racing QM Initiator's > > > Radha Gowda wrote: > > > > To the list at large: > > > > > > Why can't we put verbiage like this into the RFC? Is there some reason > this > > > is a bad thing to do? > > > > I also would like to point out to the list that Diffie-Hellman calculation > does > > not > > come cheap for some of us (atleast for now). > > I think the point is that we must be able to support independent > simultaneous SAs between security gateways. Otherwise, how will we > provide PFS? If you cannot handle the DH calculation, then I suppose > that you can serialize these, but this is not a good argument for > dumbing down the standard, is it? > > Scott From owner-ipsec@lists.tislabs.com Thu Oct 14 03:45:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA14876; Thu, 14 Oct 1999 03:45:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27212 Thu, 14 Oct 1999 04:59:29 -0400 (EDT) Message-ID: <38059C2D.F56BA62A@DataFellows.com> Date: Thu, 14 Oct 1999 12:02:37 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: PPP over IPSec (without L2TP)? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Microsoft's position regarding L2TP is according to http://www.microsoft.com/windows/server/Technical/networking/NWPriv.asp (partly) the following: L2TP is a well-defined, interoperable protocol that addresses the current shortcomings of IPSec-only client-to-gateway and gateway-to-gateway scenarios (user authentication, tunnel IP address assignment, and multiprotocol support). L2TP has broad vendor support, particularly among the largest network access equipment providers, and has verified interoperability. By placing L2TP as payload within an IPSec packet, communications benefit from the standards-based encryption and authenticity of IPSec, while also receiving a highly interoperable way to accomplish user authentication, tunnel address assignment, multiprotocol support, and multicast support using PPP. This combination is commonly referred to as L2TP/IPSec. Lacking a better pure IPSec standards solution, Microsoft believes that L2TP/IPSec provides the best standards based solution for multi-vendor, interoperable client-to-gateway VPN scenarios. Microsoft is working closely with key networking vendors including Cisco, 3Com, Lucent and IBM, to support this important combination. I agree that having PPP gives us the stated benefits (and more?). However, I fail to see why there is a need to have an L2TP (and UDP) layer(s) between PPP and IPSec. As I understand L2TP, it would give us two benefits a) being able to tunnel PPP over several links, which IPSec already gives us, and b) being able to specify telephone world things like calling / called numbers and call failures due to a busy tone, which in a general IP world are non-relevant. I agree that a lot of Internet connectivity is through a telephone network, but the calling numbers should not be relied on for any sort of identification, despite what the telephone world people would like to convince people to believe. The only valid usage for telephone numbers that I see is call charging, but the ISPs are free to use L2TP for that purpose without there being any need for IPSec security gateways or IPSec hosts knowing or even caring about it. So, please show me what benefits PPP over L2TP over IPSec provides when compared to just running PPP over IPSec? If there are some, which is possible, wouldn't it be better to enhance IPSec protocol(s) to enable the same, instead of having L2TP? -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Oct 14 04:03:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA15380; Thu, 14 Oct 1999 04:03:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27314 Thu, 14 Oct 1999 05:29:48 -0400 (EDT) Message-Id: <199910140931.NAA21314@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Sankar Ramamoorthi , Dan Harkins Date: Thu, 14 Oct 1999 13:31:21 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Racing QM Initiator's CC: "'Scott G. Kelly'" , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com In-reply-to: <199910140435.VAA22465@Potassium.Network-Alchemy.COM> References: Your message of "Wed, 13 Oct 1999 20:46:03 PDT." X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 13 Oct 99, at 21:35, Dan Harkins wrote: > A TCP service (which, if you read the Stevens chapter is bound to > both a source and destination port) can get away with having only one > connection with simultaneous opens because that service only does one > thing. A different example is BGP in which one side can be both doing a > connect to a particular host and an accept on the BGP tcp port. The > connect and accept can both happen "simultaneously" but only one > particular connection results (the unpreferable connection will be > dropped). > > But IKE is different. In IKE there can be 2 simultaneous Quick > Modes which could be the result of different packets hitting different > selectors both of which would need IPSec SAs but both can multiplex > off the same existing IKE SA. You can't just arbitrarily drop a > negotiation because you're already negotiating with that IKE peer. Dan, it's OK with simultaneous phase 2 negotiations. But what about simultaneous phase 1 negotiations? Is there any reason (besides implementation simplicity) not to drop one of negotiation (of course, with some clear rule to decide which one, for examble, based on IP addresses comparison)? Another curious point - how IKE handles self-connect. Let us assume we have IPsec host A and an attacker injects IKE packet (src_ip = A, dst_ip = A, CKY-I = xxx, CKY-R = 0) into the network. A receives this packet and (naively) begins to act as responder creating state and replying with packet (src_ip = A, dst_ip = A, CKY-I = xxx, CKY-R = yyy). Then it receives this packet back, binds it to that very state and, most likely, rejects it (possibly with some error notification) because it is malformed from his (responder's) point of view. After some time state will die due to timeout. Is this scenario correct? I understand that this situation causes no particular harm and it is very easy to avoid by simple sanity check (compare IP addresses), but still, IKE seem to have no special treatment of it, have it? > Basically, you have to allow simultaneous negotiation or else you > would not be able to support a configuration which had different > traffic selectors (optionally using different IPSec policy) to the > same gateway. > > Dan. Regards, Valera. > > On Wed, 13 Oct 1999 20:46:03 PDT you wrote > > While I agree with the notion of supporting multiple independent SAs > > > > this question is more out of curiosity. > > > > >From Richard Steven's TCP/IP Volume 1 Chapter 18.8 paragraph 4 > > > > 'TCP was purposely designed to handle simultaneous opens and the rule is > > only one > > connection results from this, not two connections. (Other protcol suites, > > notably the OSI transport layer, create two connections in this scenario, > > not one).' > > I believe there is similiar wording in RFC 793 emphasising simultaneous > > open. > > > > I don't know if there is a particular advantage to this feature. > > During the initial design of IKE did such an approach (simultaneous > > connections > > resulting in one connection) come up in the discussions? Is it worthwhile > > or feasible for a security protocol? > > > > Thanks, > > > > -- sankar -- > > > > > > > > -----Original Message----- > > From: Scott G. Kelly [mailto:skelly@redcreek.com] > > Sent: Wednesday, October 13, 1999 6:27 PM > > To: Radha Gowda > > Cc: Jan Vilhuber; Ben McCann; ipsec@lists.tislabs.com > > Subject: Re: Racing QM Initiator's > > > > > > Radha Gowda wrote: > > > > > > To the list at large: > > > > > > > > Why can't we put verbiage like this into the RFC? Is there some reason > > this > > > > is a bad thing to do? > > > > > > I also would like to point out to the list that Diffie-Hellman calculation > > does > > > not > > > come cheap for some of us (atleast for now). > > > > I think the point is that we must be able to support independent > > simultaneous SAs between security gateways. Otherwise, how will we > > provide PFS? If you cannot handle the DH calculation, then I suppose > > that you can serialize these, but this is not a good argument for > > dumbing down the standard, is it? > > > > Scott > From owner-ipsec@lists.tislabs.com Thu Oct 14 05:11:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA17440; Thu, 14 Oct 1999 05:11:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA27705 Thu, 14 Oct 1999 06:51:22 -0400 (EDT) Message-Id: <199910141053.GAA24482@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-doi-tc-mib-01.txt Date: Thu, 14 Oct 1999 06:53:09 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-ietf-ipsec-doi-tc-mib-01.txt Pages : 21 Date : 13-Oct-99 This memo defines textual conventions for use in monitoring, status, and configuration MIBs for IPSec. It includes a MIB module that defines those textual conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-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-ietf-ipsec-doi-tc-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991013133039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doi-tc-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991013133039.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Oct 14 05:57:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA18133; Thu, 14 Oct 1999 05:57:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA27886 Thu, 14 Oct 1999 07:22:43 -0400 (EDT) Message-ID: <3805BD83.8C20A382@openroute.com> Date: Thu, 14 Oct 1999 07:24:51 -0400 From: Radha Gowda X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Jan Vilhuber , Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's References: <38051E0D.672C4058@openroute.com> <3805317F.81F75D37@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" wrote: > Radha Gowda wrote: > > > > > To the list at large: > > > > > > Why can't we put verbiage like this into the RFC? Is there some reason this > > > is a bad thing to do? > > > > I also would like to point out to the list that Diffie-Hellman calculation does > > not > > come cheap for some of us (atleast for now). > > I think the point is that we must be able to support independent > simultaneous SAs between security gateways. Otherwise, how will we > provide PFS? If you cannot handle the DH calculation, then I suppose > that you can serialize these, but this is not a good argument for > dumbing down the standard, is it? > > Scott Well, I was not exactly dumbing down the standard. I was talking of a scenario where neither side had phase1 SA to its peer, but had an outstanding request. I was not arbitrarily dropping the sessions either and was basically trying to get our routers to interoperate with each other efficiently. From owner-ipsec@lists.tislabs.com Thu Oct 14 06:56:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA19388; Thu, 14 Oct 1999 06:56:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28241 Thu, 14 Oct 1999 08:30:01 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 13 Oct 1999 15:07:09 -0700 (PDT) From: Jan Vilhuber To: Radha Gowda cc: Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's In-Reply-To: <3804FD35.C223DD42@openroute.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 13 Oct 1999, Radha Gowda wrote: > > 3. One SG aborts and becomes responder. How do you know which should > > abort? The SG with the lowest IP address? > > Ben, we also experienced the same problem. Not just in phase2, but in phase1 > > as well. Just to get things going, we decided to let the one with the higher > > IP address be the initiator. > Please note that until such a statement makes it into the rfc, what you are doing may not be interoperable. Why is it such a problem to support both initiator and responder for both phase 1 and phase 2 SA's? A robust implementation should be able to do this. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Oct 14 06:56:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA19405; Thu, 14 Oct 1999 06:56:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28334 Thu, 14 Oct 1999 08:33:05 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 13 Oct 1999 16:43:30 -0700 (PDT) From: Jan Vilhuber To: Radha Gowda cc: Ben McCann , "ipsec@lists.tislabs.com" Subject: Re: Racing QM Initiator's In-Reply-To: <38051734.FB79ADF5@openroute.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 13 Oct 1999, Radha Gowda wrote: > > > > Please note that until such a statement makes it into the rfc, what you > > are doing may not be interoperable. > > > > I fully understand that, and it had been my intention all along to find > out how others deal with it. > > > Why is it such a problem to support both initiator and responder for both > > phase 1 and phase 2 SA's? A robust implementation should be able to do > > this. > > Since it is not spelt out in the RFC on how to handle race condition, > different people could interpret it differently. Well.. no. Rather, two people should NOT interpret this at all, but let it go with 2 phase 1's (or phase 2's). > I'd find it rather > confusing to see two phase1 SAs between the same addresses. I agree, and I like your solution, personally (I've thought about doing this very same thing a few times), but it's not per-standard, so it's a dangerous thing to do for interoperability reasons. To the list at large: Why can't we put verbiage like this into the RFC? Is there some reason this is a bad thing to do? jan > But if that is > the way it should be, we'll conform. > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Oct 14 06:57:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA19422; Thu, 14 Oct 1999 06:57:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28214 Thu, 14 Oct 1999 08:28:00 -0400 (EDT) Message-Id: <3.0.32.19991013171851.00908ab0@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 13 Oct 1999 17:18:52 -0400 To: Ben McCann From: "Shawn Mamros" Subject: Re: Racing QM Initiator's Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Here was my test configuration: > > C1-----SG=======SG-----C2 > >Clients 1 and 2 (C1, C2) are both pinging each other. Policy on the >SG's creates tunnel mode SA's for the ping traffic. The current Phase >2 SA for ping expires at the same time on both SG's. Then next ping >send by each client triggers each SG to create a Phase 2 SA. > >What is the interoperable way to solve this race? I trolled through >the list archives but didn't see anything relevant. Possibilities are: > >1. Deal with it. Two QM exchanges occur where both SG's are temporarily >both Phase 2 initiator and responder. (This could be tough because that >state is part of the parent Phase 1 SA). This is really the only sensible way to do it. You have to be able to handle more than one QM at a given time, as either initiator or responder. Think about the case where you have, say, a C3 behind the left hand side SG, and C1 is trying to send traffic to C2 at the same time as C2 is trying to send to C3. It would be the same situation, except the QM IDs (and perhaps other attributes) would be different for the two negotiations. Gotta be able to handle it. >2. Both SG's abort the QM exchange, backoff, and retry later. Could lead to a never-ending standoff. Might work for Ethernet, but not over a wide area network where packets get lost, etc. >3. One SG aborts and becomes responder. How do you know which should >abort? The SG with the lowest IP address? Not a good move either. What if somebody is using NAT? (Regardless of all the other places where NAT may or may not break things, it's not a good idea to add yet another...) -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Thu Oct 14 06:57:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA19436; Thu, 14 Oct 1999 06:57:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28220 Thu, 14 Oct 1999 08:29:01 -0400 (EDT) Message-Id: <199910132130.OAA04907@hsmpka.eng.sun.com> Date: Wed, 13 Oct 1999 14:20:46 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Racing QM Initiator's To: ipsec@lists.tislabs.com, bmccann@indusriver.com Cc: vipul.gupta@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Hl8ehtwF2YDUlgCOM8jtxA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_28 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk But aren't these two messages going out with different message IDs generated randomly by each Phase II initiator? If so, why is there a problem ? This will result in two IPSec SAs where one would have been sufficient but I don't view that as catastrophic. What am I missing? vipul > Date: Wed, 13 Oct 1999 15:17:07 -0400 > From: Ben McCann > > By dumb luck, I just had two SG's attempt a QM exchange with each > other _at_the_same_time_. Each sent the first QM packet as initiator and > each got that packet and tried to act as QM responder. Both got confused > because they both switched from Initiator to Responder in mid-stream. > > Here was my test configuration: > > C1-----SG=======SG-----C2 > > Clients 1 and 2 (C1, C2) are both pinging each other. Policy on the > SG's creates tunnel mode SA's for the ping traffic. The current Phase > 2 SA for ping expires at the same time on both SG's. Then next ping > send by each client triggers each SG to create a Phase 2 SA. > > What is the interoperable way to solve this race? I trolled through > the list archives but didn't see anything relevant. Possibilities are: > > 1. Deal with it. Two QM exchanges occur where both SG's are temporarily > both Phase 2 initiator and responder. (This could be tough because that > state is part of the parent Phase 1 SA). > > 2. Both SG's abort the QM exchange, backoff, and retry later. > > 3. One SG aborts and becomes responder. How do you know which should > abort? The SG with the lowest IP address? > > I'm sure there are other options too. Any opinions are welcome... > > Thanks, > Ben McCann > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu Oct 14 07:00:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA19478; Thu, 14 Oct 1999 07:00:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28349 Thu, 14 Oct 1999 08:34:02 -0400 (EDT) Date: Wed, 13 Oct 1999 18:30:38 -0700 (PDT) From: "CHIU,JAY C F" To: ipsec@lists.tislabs.com Subject: request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I was wondering if you could tell me what does IKE stand for? Thank you very much. Sincerely, Jay Chiu From owner-ipsec@lists.tislabs.com Thu Oct 14 07:14:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA19731; Thu, 14 Oct 1999 07:14:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28517 Thu, 14 Oct 1999 08:51:05 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B001D6A3CA@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'Ari Huttunen'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: RE: PPP over IPSec (without L2TP)? Date: Thu, 14 Oct 1999 05:33:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk L2TP provides the prevention of packet reordering that is REQUIRED by PPP. The PPP protocol assumes that packets under it will never be reordered. PPP would not work directly on top of IPSec, since IPSec does not offer a service with any assurance of packet ordering. The optional flow control for L2TP can also be used wisely to provide better performance (lower packet loss). Also, on Windows Dial-Up Networking, it provides a comfortable user model. This is not to be taken lightly. From owner-ipsec@lists.tislabs.com Thu Oct 14 08:21:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA20762; Thu, 14 Oct 1999 08:21:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28706 Thu, 14 Oct 1999 09:41:04 -0400 (EDT) Message-ID: <19991014134326.16018.rocketmail@web1706.mail.yahoo.com> Date: Thu, 14 Oct 1999 06:43:26 -0700 (PDT) From: Nishant Mishra Subject: IPSec VPN To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Can any one explain what actually differentiates IPSec VPN gateway, IPSec VPN Client and IPSec VPN remote client in terms of protocol/additional software required? Thanks in advance. Regards, Nishant __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Thu Oct 14 08:22:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA20777; Thu, 14 Oct 1999 08:22:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28676 Thu, 14 Oct 1999 09:37:32 -0400 (EDT) Message-ID: <3805DD5E.7532A476@DataFellows.com> Date: Thu, 14 Oct 1999 16:40:46 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Shriver, John" CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (without L2TP)? References: <392A357CE6FFD111AC3E00A0C99848B001D6A3CA@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are certainly much easier ways for preventing packet re-ordering than implementing L2TP! As to your other points.. I defer judgement, but they don't look serious enough to force using L2TP either. Certainly they weren't serious enough to be mentioned in Microsoft's document. Ari "Shriver, John" wrote: > L2TP provides the prevention of packet reordering that is REQUIRED by PPP. > The PPP protocol assumes that packets under it will never be reordered. PPP > would not work directly on top of IPSec, since IPSec does not offer a > service with any assurance of packet ordering. > > The optional flow control for L2TP can also be used wisely to provide better > performance (lower packet loss). > > Also, on Windows Dial-Up Networking, it provides a comfortable user model. > This is not to be taken lightly. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Oct 14 10:34:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA24043; Thu, 14 Oct 1999 10:34:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29441 Thu, 14 Oct 1999 11:47:50 -0400 (EDT) Message-ID: <3805FC73.510A44F9@redcreek.com> Date: Thu, 14 Oct 1999 08:53:23 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Valery Smyslov CC: Sankar Ramamoorthi , Dan Harkins , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com Subject: Re: Racing QM Initiator's References: Your message of "Wed, 13 Oct 1999 20:46:03 PDT." <199910140931.NAA21314@relay1.trustworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov wrote: > > Dan, it's OK with simultaneous phase 2 negotiations. But what about > simultaneous phase 1 negotiations? Is there any reason (besides > implementation simplicity) not to drop one of negotiation (of course, > with some clear rule to decide which one, for examble, based on IP > addresses comparison)? How about the case in which one of the phase 1 SAs requires ID PFS while the other one does not? The following diagram clarifies: +---+ | | +---+ | A |--| +---+ +---+ |--| B | +---+ |--| x |==internet==| y |--| +---+ | +---+ +---+ | +---+ | | +---+ | C |--| |--| D | +---+ | | +---+ Assume that x and y are security gateways which provide ipsec services to their respective local networks. Suppose that A wants to talk to D, and this SA requires ID PFS. Suppose that around the same time, B wants to talk to C, and this SA does not require PFS. When a packet A=>D arrives at x, x begins negotiating with y. Suppose a packet B=>C arrives at y prior to the arrival of x's first IKE packet, at which time y initiates IKE with x, and the two IKE packets are simultaneously in transit. This is a case in which it would be incorrect to drop one of the negotiations. Scott From owner-ipsec@lists.tislabs.com Thu Oct 14 10:35:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA24069; Thu, 14 Oct 1999 10:35:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29447 Thu, 14 Oct 1999 11:50:13 -0400 (EDT) Reply-To: From: "Scott Davidson" To: "CHIU,JAY C F" , Subject: RE: request Date: Thu, 14 Oct 1999 10:52:08 -0500 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0013_01BF1631.16A3B7E0"; micalg=SHA1 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01BF1631.16A3B7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Internet Key Exchange The Internet Key Exchange or IKE that define how to exchange security keys for authentication and how to negotiate the parameters of individual virtual private networks. IKE was originally known as ISAKMP/Oakley and is an Internet Protocol Security standard. Scott Davidson Central US Systems Engineer NOKIA IPRG US Sales - Dallas 214.632.6191 scott.davidson@iprg.nokia.com www.nokia.com support.iprg.nokia.com -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHIU,JAY C F Sent: Wednesday, October 13, 1999 8:31 PM To: ipsec@lists.tislabs.com Subject: request Hi, I was wondering if you could tell me what does IKE stand for? Thank you very much. Sincerely, Jay Chiu ------=_NextPart_000_0013_01BF1631.16A3B7E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKKTCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/ LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIEszCCBBygAwIBAgIQTRW6AR01IOqQtMIC5JkT9jANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTEwMTQw MDAwMDBaFw05OTEyMTMyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEnMCUGA1UECxMeRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 MRcwFQYDVQQDFA5TY290dCBEYXZpZHNvbjEsMCoGCSqGSIb3DQEJARYdc2NvdHQuZGF2aWRzb25A aXByZy5ub2tpYS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwQ8DP/5+MvNL0IdjQUCAOPYZ J8EIBidEZLbpFn2WslY09KQZP8Rd4EZsMmwQSVmPeimEQWxMmid7j8p01S32JQIDAQABo4IBjzCC AYswCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWdu LCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0 NjUyYmQ2M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcw MTc0N2RhNWQzZjIxNDFiZWFkYjJiZDJlODkyMTFhODY5ZjJkZjExNDg5Y2EzYmQ0NGY1ZjNlYTQ1 MGMwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDAN BgkqhkiG9w0BAQQFAAOBgQB2A7Xm+uE+uHzE8upMojmjvL5IHNhDfkS7ZJoOkxAZ10QS6RurD69I lKHxAxf/EdT0gsEYvqYg2W/dFB/TC4I5sLhgvEyCzjyohOHODcxUzTEokGCyteXgZgIksFnyrVb4 /NNKy6MQq/eLeaNZkQtNy4V2ogtxflkmKgnmeuAdbjGCAtIwggLOAgEBMIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmli ZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBNFboBHTUg6pC0wgLkmRP2MAkGBSsOAwIaBQCgggGH MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxNDE1NDQyN1ow IwYJKoZIhvcNAQkEMRYEFM/PbZWcrEmsS7Qupale23QpVP7XMDMGCSqGSIb3DQEJDzEmMCQwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQTRW6AR01IOqQtMIC5JkT9jANBgkqhkiG 9w0BAQEFAARAAivJVN009HyzygBy0R9pnP3xmIs2afRWgjPcV4b6m1WRDryIzvJdMxYjJivlafwX WJXNVhEN71GpFLvyVgKq3gAAAAAAAA== ------=_NextPart_000_0013_01BF1631.16A3B7E0-- From owner-ipsec@lists.tislabs.com Thu Oct 14 10:49:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA24356; Thu, 14 Oct 1999 10:49:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29589 Thu, 14 Oct 1999 12:18:49 -0400 (EDT) Message-ID: <380603B8.6A9BF0C6@redcreek.com> Date: Thu, 14 Oct 1999 09:24:24 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Valery Smyslov CC: Sankar Ramamoorthi , Dan Harkins , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com Subject: Re: Racing QM Initiator's References: Your message of "Wed, 13 Oct 1999 20:46:03 PDT." <199910140931.NAA21314@relay1.trustworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov wrote: > Another curious point - how IKE handles self-connect. Let us assume > we have IPsec host A and an attacker injects IKE packet (src_ip = A, > dst_ip = A, CKY-I = xxx, CKY-R = 0) into the network. A receives this > packet and (naively) begins to act as responder creating state and > replying with packet (src_ip = A, dst_ip = A, CKY-I = xxx, CKY-R = > yyy). Then it receives this packet back, binds it to that very state > and, most likely, rejects it (possibly with some error notification) > because it is malformed from his (responder's) point of view. After > some time state will die due to timeout. Is this scenario correct? I > understand that this situation causes no particular harm and it is > very easy to avoid by simple sanity check (compare IP addresses), but > still, IKE seem to have no special treatment of it, have it? Assuming policy is correctly configured (and implemented), this packet should never reach the IKE implementation, should it? Scott From owner-ipsec@lists.tislabs.com Thu Oct 14 10:52:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA24418; Thu, 14 Oct 1999 10:52:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29495 Thu, 14 Oct 1999 12:08:26 -0400 (EDT) Message-ID: <38060149.F2DCC128@redcreek.com> Date: Thu, 14 Oct 1999 09:14:01 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ari Huttunen CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (without L2TP)? References: <38059C2D.F56BA62A@DataFellows.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen wrote: > I agree that having PPP gives us the stated benefits (and more?). However, I fail to see why there > is a need to have an L2TP (and UDP) layer(s) between PPP and IPSec. > So, please show me what benefits PPP over L2TP over IPSec provides when compared > to just running PPP over IPSec? If there are some, which is possible, wouldn't it be > better to enhance IPSec protocol(s) to enable the same, instead of having L2TP? I think that one strong argument for not running ppp directly over ipsec is that ppp is a layer 2 construct, and ipsec is designed to secure traffic at layer 3. Aside from the architectural repugnance, there are significant difficulties presented by encapsulation of PPP (and L2TP, for that matter) in IPsec. Many of these arise due to the fact that in order to apply policy to these packets, you must first understand what is in them, and all the security implications of the various content possibilities. Once you thoroughly understand the PPP (or L2TP) protocol in this light, then you can begin to design a security protocol which secures them. I think the bottom line is, that protocol would *not* be ipsec - it would be something else. This dances around a bigger problem which keeps recurring in different guises on this list: vpn and ipsec are not synonymous. I think that running L2TP over ipsec is essentially a hack which leverages ipsec for a vpn scenario. However, ipsec was not designed to provide security for the L2TP payload, so that if there is not an L2TP security subsystem which controls the encapsulation, then the payload is not truly secured - it is simply being tunneled, albeit reliably. Scott From owner-ipsec@lists.tislabs.com Thu Oct 14 11:44:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA25375; Thu, 14 Oct 1999 11:44:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29688 Thu, 14 Oct 1999 12:56:54 -0400 (EDT) Date: Thu, 14 Oct 1999 12:53:57 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.34a) S/N 569FD297 Reply-To: Jim Tiller Organization: INS X-Priority: 3 (Normal) Message-ID: <6537.991014@ins.com> To: "Shriver, John" CC: "'Ari Huttunen'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re[2]: PPP over IPSec (without L2TP)? In-reply-To: <392A357CE6FFD111AC3E00A0C99848B001D6A3CA@hdsmsx31.hd.intel.com> References: <392A357CE6FFD111AC3E00A0C99848B001D6A3CA@hdsmsx31.hd.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello John, Shriver> L2TP provides the prevention of packet reordering that is REQUIRED by PPP. Shriver> The PPP protocol assumes that packets under it will never be reordered. PPP Shriver> would not work directly on top of IPSec, since IPSec does not offer a Shriver> service with any assurance of packet ordering. Excuse my ignorance, but doesn't IPSec and IP handle this in layer three and four? I'm personally torn on the use of L2TP over IPSec, I see certain implementations that can benefit, but the reasons MS gives do not impress me. Any comments are welcome. AtDhVaAnNkCsE Best regards, Jim Tiller, CISSP, MCSE+I, CCDA james_tiller@ins.com Network Security Consultant, INS Tampa, Florida "Faber est suae quisque fortunae." - Appius Claudius Caecus Thursday, October 14, 1999, 8:33:51 AM, you wrote: Shriver> L2TP provides the prevention of packet reordering that is REQUIRED by PPP. Shriver> The PPP protocol assumes that packets under it will never be reordered. PPP Shriver> would not work directly on top of IPSec, since IPSec does not offer a Shriver> service with any assurance of packet ordering. Shriver> The optional flow control for L2TP can also be used wisely to provide better Shriver> performance (lower packet loss). Shriver> Also, on Windows Dial-Up Networking, it provides a comfortable user model. Shriver> This is not to be taken lightly. From owner-ipsec@lists.tislabs.com Thu Oct 14 12:03:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA25637; Thu, 14 Oct 1999 12:03:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29824 Thu, 14 Oct 1999 13:20:07 -0400 (EDT) Message-ID: <19398D273324D3118A2B0008C7E9A56902751613@SIT.platinum.corp.microsoft.com> From: "Brian Swander (Exchange)" To: "'ddp@network-alchemy.com'" , ipsec@lists.tislabs.com Subject: comments on the latest GSSAPI draft changes Date: Thu, 14 Oct 1999 10:21:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell, there are serious problems with the IDs in your latest rev. of the draft. In the prior version of the draft, the next payload for the GSS_API payload was 129. In the latest, it is 128. Also, the auth id for GSS_API/Kerberos in the previous version was 65001. In the current version, it is 65003, and the generic GSS_API id is 65001. In the presentation of the GSSAPI+Kerberos that I gave at the IETF, I gave the numbers 129, 65001 as the numbers to use. These are the numbers in the current version on NT5, and NT5 is shipping with these numbers. Your change of these numbers will make it very difficult for other vendors to implement the GSSAPI draft, and interop with NT5. I know of a few vendors out there who want to do this. It will also make it very difficult for later versions of NT to interop with NT5. I see no security concerns, or any other valid reasons for changing these IDs, and respectfully request that you put them back to their original values. Interoperability with GSSAPI will be tough enough since everyone building this will need to build in backwards compatibility code anyway when we move to the IANA assigned numbers. At least that backwards compatability is possible. Given your current changes, backwards compatibility and general interop is next to impossible. I think it will be a major obstacle to the adoption of this draft if these numbers stay as they are. Also, please push to get IANA assigned numbers ASAP, so we never have to deal with the floating number problem in GSSAPI again. bs From owner-ipsec@lists.tislabs.com Thu Oct 14 12:03:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA25645; Thu, 14 Oct 1999 12:03:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29770 Thu, 14 Oct 1999 13:14:11 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <6537.991014@ins.com> References: <392A357CE6FFD111AC3E00A0C99848B001D6A3CA@hdsmsx31.hd.intel.com> <392A357CE6FFD111AC3E00A0C99848B001D6A3CA@hdsmsx31.hd.intel.com> Date: Thu, 14 Oct 1999 13:17:27 -0400 To: Jim Tiller From: Stephen Kent Subject: Re[2]: PPP over IPSec (without L2TP)? Cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jim, IPsec operates at layer 3, not 4, although we do cheat a bit. When one runs L2TP over IPsec, one loose the ability to perform fine-grained access control as part of IPsec, which is an important aspect of the security provided by IPsec. This problem arises because an IPsec receiver examines the "appropriate" IP header to make the access control decision. However, when there is an intervening protocoll layer, e.g., L2TP (or PPP) this check cannot be performed. Note that once the packet exits the Ipsec procvessing, one cannot tie it to the SA via which it was received, and thus any later access control checks are not nearly as effective as what can be done within IPsec per se. This has been a bone of contention between some of us in the IPsec WG and the folks who produced the L2TP spec, calling for the use of IPsec with L2TP. I fought over the wording of the text re the security benefits that accrue when the two protocols are used together, but achieved only a partial victory, i.e., I prevented the RFC from making grossly misleading claims about security under these circumstances. The bottom line is that L2TP impose no requirements on implementations to offer the same sort of fine-grained access control that Ipsec mandates. Moreover, once the binding of a packet to an SA is lost, it is impossible to provide the same level of security features and assurance for access control. I agree that more work needs to be done to provide all of the necessary routing and configuration facilities for some classes of VPN users with IPsec. However, it is not accurate to suggest that using L2TP over IPsec provides as good a level of security as will be achieved through appropriate use (perhaps with added options) of IPsec in a native mode. Steve From owner-ipsec@lists.tislabs.com Thu Oct 14 12:12:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA25763; Thu, 14 Oct 1999 12:12:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29892 Thu, 14 Oct 1999 13:36:55 -0400 (EDT) From: jerome@psti.com Message-ID: <19991014134145.A25243@jerome.psti.com> Date: Thu, 14 Oct 1999 13:41:45 -0400 To: scott.davidson@iprg.nokia.com Cc: ipsec@lists.tislabs.com Subject: Re: request Reply-To: jerome@psti.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: ; from Scott Davidson on Thu, Oct 14, 1999 at 11:52:08AM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Oct 14, 1999 at 11:52:08AM -0400, Scott Davidson wrote: > Internet Key Exchange > The Internet Key Exchange or IKE that define how to exchange security > keys for authentication and how to negotiate the parameters of > individual virtual private networks. IKE was originally known as > ISAKMP/Oakley and is an Internet Protocol Security standard. does this mean that ISAKMP/Oakley are officially obsoleted by IKE ? The following quote seems to present it more as a subset. " This does not implement the entire Oakley protocol, but only a subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol nor is it dependant in any way on the Oakley protocol. " -- rfc2409.2 about IKE From owner-ipsec@lists.tislabs.com Thu Oct 14 12:16:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA25837; Thu, 14 Oct 1999 12:16:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29910 Thu, 14 Oct 1999 13:39:05 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B001D6A3D4@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'Jim Tiller'" Cc: "'Ari Huttunen'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Re[2]: PPP over IPSec (without L2TP)? Date: Thu, 14 Oct 1999 10:19:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Jim Tiller [mailto:tiller_j@ins.com] > Sent: Thursday, October 14, 1999 12:54 PM > To: Shriver, John > Cc: 'Ari Huttunen'; ietf-ipsra@vpnc.org; ipsec@lists.tislabs.com > Subject: Re[2]: PPP over IPSec (without L2TP)? > > Excuse my ignorance, but doesn't IPSec and IP handle this in > layer three and four? I'm personally torn on the use of L2TP > over IPSec, I see certain implementations that can benefit, > but the reasons MS gives do not impress me. > Any comments are welcome. > Well, for the DATA path, PPP itself has no concerns about packet reordering. IP over PPP could care less. But, some of the protocols over PPP care very much about reordering. IEEE 802.1D bridging assumes essentially no possibility of reordering, so BCP over PPP has to assume that what is under PPP will not reorder. But, the big problem is the entire PPP negotiation state machine. (The CONTROL path.) It is absolutely designed on the assumption that the data link underneath will never reorder packets. Suppose a NCP Config-Ack was sent by an IPCP Config-Request. If they were swapped in transit, the IPCP packet would be received before NCP was up. Also, the Van Jacobsen TCP header compression really benefits greatly from being informed of packet loss at the receiver. L2TP can provide some hint of that. ------------- End Forwarded Message ------------- From owner-ipsec@lists.tislabs.com Thu Oct 14 12:23:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA25938; Thu, 14 Oct 1999 12:23:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29981 Thu, 14 Oct 1999 13:54:15 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <392A357CE6FFD111AC3E00A0C99848B001D6A3D4@hdsmsx31.hd.intel.com> Date: Thu, 14 Oct 1999 13:49:50 -0400 To: "Shriver, John" From: Stephen Kent Subject: RE: Re[2]: PPP over IPSec (without L2TP)? Cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John, Apropos your most recent message, I should have prefeced my comments with the note that I advocate use of native IPsec for transport of IP traffic, not for transport of protocol suites, where there may be a need for real, layer 2 tunneling. Steve From owner-ipsec@lists.tislabs.com Thu Oct 14 12:59:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA26511; Thu, 14 Oct 1999 12:59:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00059 Thu, 14 Oct 1999 14:04:59 -0400 (EDT) Message-Id: <199910141805.LAA24403@Potassium.Network-Alchemy.COM> To: "Brian Swander (Exchange)" cc: "'ddp@network-alchemy.com'" , ipsec@lists.tislabs.com Subject: Re: comments on the latest GSSAPI draft changes In-reply-to: Your message of "Thu, 14 Oct 1999 10:21:55 PDT." <19398D273324D3118A2B0008C7E9A56902751613@SIT.platinum.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24400.939924347.1@network-alchemy.com> Date: Thu, 14 Oct 1999 11:05:47 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brian, Those are from the "private use" range anyway which is what drafts are supposed to use. This is to flush out any problems with the protocol. If and when the draft is advanced it will be assigned real numbers by IANA. So if and when that happens you'll have interop problems with NT* or any other implementation that is shipping with code written to a draft. Note that XAUTH also claims use of 65001-65010. Internet Drafts are working documents and it is foolhardy to ship code based on them. This is the price you pay if you do. Dan. On Thu, 14 Oct 1999 10:21:55 PDT you wrote > Derrell, there are serious problems with the IDs in your latest rev. of the > draft. > > In the prior version of the draft, the next payload for the GSS_API payload > was 129. In the latest, it is 128. Also, the auth id for GSS_API/Kerberos > in the previous version was 65001. In the current version, it is 65003, and > the generic GSS_API id is 65001. > > In the presentation of the GSSAPI+Kerberos that I gave at the IETF, I gave > the numbers 129, 65001 as the numbers to use. These are the numbers in the > current version on NT5, and NT5 is shipping with these numbers. > > Your change of these numbers will make it very difficult for other vendors > to implement the GSSAPI draft, and interop with NT5. I know of a few > vendors out there who want to do this. It will also make it very difficult > for later versions of NT to interop with NT5. > > I see no security concerns, or any other valid reasons for changing these > IDs, and respectfully request that you put them back to their original > values. > > Interoperability with GSSAPI will be tough enough since everyone building > this will need to build in backwards compatibility code anyway when we move > to the IANA assigned numbers. At least that backwards compatability is > possible. Given your current changes, backwards compatibility and general > interop is next to impossible. > > I think it will be a major obstacle to the adoption of this draft if these > numbers stay as they are. Also, please push to get IANA assigned numbers > ASAP, so we never have to deal with the floating number problem in GSSAPI > again. > > bs > > From owner-ipsec@lists.tislabs.com Thu Oct 14 13:24:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA27075; Thu, 14 Oct 1999 13:24:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00212 Thu, 14 Oct 1999 14:28:12 -0400 (EDT) Message-ID: <19398D273324D3118A2B0008C7E9A56902751614@SIT.platinum.corp.microsoft.com> From: "Brian Swander (Exchange)" To: "'Dan Harkins'" , "Brian Swander (Exchange)" Cc: "'ddp@network-alchemy.com'" , ipsec@lists.tislabs.com Subject: RE: comments on the latest GSSAPI draft changes Date: Thu, 14 Oct 1999 11:29:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agreed. But, shipping based on internet drafts is a necessary evil. Given that some vendors find this necessary, the question is: Do we want to make changes to the internet drafts to minimize interop problems with prior versions, or to maximize them? The purpose of the internet draft, as you said, is to flush out problems. It is also to work towards a draft that is mutually acceptable to all. However, Derrell's latest ID changes in the GSSAPI don't flush out any problems, and just create new problems. So the question still remains: will the arbitrary ID changes be put back to their original values, or will we have a large divergence from the IDs in the draft, and IDs in the marketplace? I fully support changing drafts for new functionality, or to fix a real problem. For instance, the latest GSSAPI draft fixed the limited round trip problem in the old GSSAPI draft, and therefore is a substantial improvement. I only object to random changes that only cause problems, and solve nothing. If we are leaving the IDs as in the new draft, can someone provide a better justification than: "the draft a work in progress, so it can be arbitarily changed at will." bs -----Original Message----- From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] Sent: Thursday, October 14, 1999 11:06 AM To: Brian Swander (Exchange) Cc: 'ddp@network-alchemy.com'; ipsec@lists.tislabs.com Subject: Re: comments on the latest GSSAPI draft changes Brian, Those are from the "private use" range anyway which is what drafts are supposed to use. This is to flush out any problems with the protocol. If and when the draft is advanced it will be assigned real numbers by IANA. So if and when that happens you'll have interop problems with NT* or any other implementation that is shipping with code written to a draft. Note that XAUTH also claims use of 65001-65010. Internet Drafts are working documents and it is foolhardy to ship code based on them. This is the price you pay if you do. Dan. On Thu, 14 Oct 1999 10:21:55 PDT you wrote > Derrell, there are serious problems with the IDs in your latest rev. of the > draft. > > In the prior version of the draft, the next payload for the GSS_API payload > was 129. In the latest, it is 128. Also, the auth id for GSS_API/Kerberos > in the previous version was 65001. In the current version, it is 65003, and > the generic GSS_API id is 65001. > > In the presentation of the GSSAPI+Kerberos that I gave at the IETF, I gave > the numbers 129, 65001 as the numbers to use. These are the numbers in the > current version on NT5, and NT5 is shipping with these numbers. > > Your change of these numbers will make it very difficult for other vendors > to implement the GSSAPI draft, and interop with NT5. I know of a few > vendors out there who want to do this. It will also make it very difficult > for later versions of NT to interop with NT5. > > I see no security concerns, or any other valid reasons for changing these > IDs, and respectfully request that you put them back to their original > values. > > Interoperability with GSSAPI will be tough enough since everyone building > this will need to build in backwards compatibility code anyway when we move > to the IANA assigned numbers. At least that backwards compatability is > possible. Given your current changes, backwards compatibility and general > interop is next to impossible. > > I think it will be a major obstacle to the adoption of this draft if these > numbers stay as they are. Also, please push to get IANA assigned numbers > ASAP, so we never have to deal with the floating number problem in GSSAPI > again. > > bs > > From owner-ipsec@lists.tislabs.com Thu Oct 14 13:52:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA27459; Thu, 14 Oct 1999 13:52:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00408 Thu, 14 Oct 1999 14:54:48 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Dan Harkins'" , Sankar Ramamoorthi Cc: "'Scott G. Kelly'" , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com Subject: RE: Racing QM Initiator's Date: Thu, 14 Oct 1999 11:56:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > A TCP service (which, if you read the Stevens chapter is bound to >both a source and destination port) can get away with having only one >connection with simultaneous opens because that service only does one >thing. A different example is BGP in which one side can be both doing a >connect to a particular host and an accept on the BGP tcp port. The >connect and accept can both happen "simultaneously" but only one >particular connection results (the unpreferable connection will be >dropped). > > But IKE is different. In IKE there can be 2 simultaneous Quick >Modes which could be the result of different packets hitting different >selectors both of which would need IPSec SAs but both can multiplex >off the same existing IKE SA. You can't just arbitrarily drop a >negotiation because you're already negotiating with that IKE peer. > I was talking about the case where the the selectors are same. I did not mean 'drop a simultaneous negotiation' to be part of the protocol. What I was wondering was the could QM states have been arranged such that the resulting exchanges could have resulted in one SA rather than two. My first thought was A QM Initiator can be equated to an active TCP open. A QM Responder can be equated to a passive TCP open (listener). So analogus to TCP the in QM state machine it should be possible for two QM initiators to arrive at a connected state. On furthur reflection I understand that they are different. The initiator and responder have a clear role to play to complete the negotiation of crypto parameters. TCP has no such clear distinction. I was thinking along these lines of how simultaneous QM exchange could happen between two parties. I have not through it fully and there may many flaws. First Exchange -------------- HDR*, HASH(1), SA, Ni1, HDR*, HASH(1), SA, Ni2 [, KE], [, IDci, IDcr] -----> <---- [, KE], [, IDci, IDcr] Second Exchange --------------- HDR*, HASH(2), SA, Ni1, HDR*, HASH(2), SA, Ni2 [, KE ], [, IDci, IDcr]-----> <----- [, KE ], [, IDci, IDcr] Third Exchange ------------- HDR*, HASH(3) -----> <-----HDR*, HASH(3) If we assume an SA list is proposed in the first exchange is in ordered list with the most preferred one in the beginning, then we can assume that both parties will arrive at the same preferred SA in exchange 2. I am perfectly comfortable with the current protocol definition and I see no reason to change it. My questions are more of out of curiosity. 'Is there any special benefit to defining a protocol exchange which allows simultaneous opens w.out dropping a connection (assume same selectors)?' 'If there is, is it worthwhile for QM exchanges to have been defined that way?' 'Is it possible for QM exchanges to have been defined that way?' > Basically, you have to allow simultaneous negotiation or else you >would not be able to support a configuration which had different >traffic selectors (optionally using different IPSec policy) to the >same gateway. > > Dan. > >On Wed, 13 Oct 1999 20:46:03 PDT you wrote >> While I agree with the notion of supporting multiple independent SAs >> >> this question is more out of curiosity. >> >> >From Richard Steven's TCP/IP Volume 1 Chapter 18.8 paragraph 4 >> >> 'TCP was purposely designed to handle simultaneous opens and the rule is >> only one >> connection results from this, not two connections. (Other protcol suites, >> notably the OSI transport layer, create two connections in this scenario, >> not one).' >> I believe there is similiar wording in RFC 793 emphasising simultaneous >> open. >> >> I don't know if there is a particular advantage to this feature. >> During the initial design of IKE did such an approach (simultaneous >> connections >> resulting in one connection) come up in the discussions? Is it worthwhile >> or feasible for a security protocol? >> >> Thanks, >> >> -- sankar -- >> >> >> >> -----Original Message----- >> From: Scott G. Kelly [mailto:skelly@redcreek.com] >> Sent: Wednesday, October 13, 1999 6:27 PM >> To: Radha Gowda >> Cc: Jan Vilhuber; Ben McCann; ipsec@lists.tislabs.com >> Subject: Re: Racing QM Initiator's >> >> >> Radha Gowda wrote: >> >> > > To the list at large: >> > > >> > > Why can't we put verbiage like this into the RFC? Is there some reason >> this >> > > is a bad thing to do? >> > >> > I also would like to point out to the list that Diffie-Hellman calculation >> does >> > not >> > come cheap for some of us (atleast for now). >> >> I think the point is that we must be able to support independent >> simultaneous SAs between security gateways. Otherwise, how will we >> provide PFS? If you cannot handle the DH calculation, then I suppose >> that you can serialize these, but this is not a good argument for >> dumbing down the standard, is it? >> >> Scott From owner-ipsec@lists.tislabs.com Thu Oct 14 14:09:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA27935; Thu, 14 Oct 1999 14:09:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00695 Thu, 14 Oct 1999 15:22:42 -0400 (EDT) Date: Thu, 14 Oct 1999 15:22:18 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.34a) S/N 569FD297 Reply-To: Jim Tiller Organization: INS X-Priority: 3 (Normal) Message-ID: <15640.991014@ins.com> To: "Scott G. Kelly" CC: Ari Huttunen , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re[2]: PPP over IPSec (without L2TP)? In-reply-To: <38060149.F2DCC128@redcreek.com> References: <38060149.F2DCC128@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Scott, Thursday, October 14, 1999, 12:14:01 PM, you wrote: Kelly> This dances around a bigger problem which keeps recurring in different Kelly> guises on this list: vpn and ipsec are not synonymous. I just had an extensive discussion with several associates about the interchange of the acronyms IPSec and VPN. VPN can be all encompassing where IPSec is specific. I guess my question to you, et al, is why do vendors attempt to "hack" L2TP and IPSec together and not augment L2TP with encryption, releasing IPSec from acting as a crutch? As you can easily see, I'm new to L2TP and behind the learning curve at this point. Just a simple thought, I am taking a comment you made to the next logical 'step', I guess. ... Kelly> Once you thoroughly understand the PPP (or L2TP) protocol Kelly> in this light, then you can begin to design a security protocol which Kelly> secures them. I think the bottom line is, that protocol would *not* be Kelly> ipsec - it would be something else. ^^^^^^^^^^^^^^^^^^^^^^ From owner-ipsec@lists.tislabs.com Thu Oct 14 14:13:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA28048; Thu, 14 Oct 1999 14:13:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00724 Thu, 14 Oct 1999 15:27:00 -0400 (EDT) Date: Thu, 14 Oct 1999 15:26:35 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.34a) S/N 569FD297 Reply-To: Jim Tiller Organization: INS X-Priority: 3 (Normal) Message-ID: <14643.991014@ins.com> To: "Shriver, John" CC: "'Ari Huttunen'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re[6]: PPP over IPSec (without L2TP)? In-reply-To: <392A357CE6FFD111AC3E00A0C99848B001D6A3DB@hdsmsx31.hd.intel.com> References: <392A357CE6FFD111AC3E00A0C99848B001D6A3DB@hdsmsx31.hd.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shriver> No. The IP and UDP layers under L2TP don't do any correction of re-ordered Shriver> packets. That is not part of the service contracto or IP or UDP, only of Shriver> TCP, which isn't involved. Ohh. That burns:-) I COMPLETELY got twisted up. Thank you for straightening me out! Shriver> It also made it easier for Microsoft to integrate IPSec/VPN functionality Shriver> into Windows 2000. The IPSec community gains by having such a widely Shriver> available IPSec implementation. Agreed. Thankx for your help! -jim From owner-ipsec@lists.tislabs.com Thu Oct 14 14:20:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA28147; Thu, 14 Oct 1999 14:20:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00576 Thu, 14 Oct 1999 15:11:34 -0400 (EDT) Date: Thu, 14 Oct 1999 15:09:15 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.34a) S/N 569FD297 Reply-To: Jim Tiller Organization: INS X-Priority: 3 (Normal) Message-ID: <3631.991014@ins.com> To: "Shriver, John" CC: "'Ari Huttunen'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re[4]: PPP over IPSec (without L2TP)? In-reply-To: <392A357CE6FFD111AC3E00A0C99848B001D6A3D4@hdsmsx31.hd.intel.com> References: <392A357CE6FFD111AC3E00A0C99848B001D6A3D4@hdsmsx31.hd.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, but I keep choking on one aspect. If PPP is encapsulated into L2TP, which basically assumes the form of an IP packet (right?) Doesn't the same issues of reordering exist? Eliminate IPSec for a second. I'm obviously not an L2TP dude, but I'm aware of in-band controls within L2TP that provide the options to the passenger protocol(s). I guess my misunderstanding revolves around that if a packet is ultimately forwarded through an IP network, the odds of packets arriving at the destination in the wrong order are high. At that point don't the packets get reordered by the IP stack of the receiving system and then passed up the stack? At that point aren't the PPP LCPs and NCPs reordered inherently prior to de-encapsulation? Please be patient with me, I know I'm missing a critical step and completely over simplifying the process. I just don't see the need for L2TP over IPSec, it's not sticking. Thankx for your time! -jim Thursday, October 14, 1999, 1:19:37 PM, you wrote: >> From: Jim Tiller [mailto:tiller_j@ins.com] >> Sent: Thursday, October 14, 1999 12:54 PM >> To: Shriver, John >> Cc: 'Ari Huttunen'; ietf-ipsra@vpnc.org; ipsec@lists.tislabs.com >> Subject: Re[2]: PPP over IPSec (without L2TP)? >> >> Excuse my ignorance, but doesn't IPSec and IP handle this in >> layer three and four? I'm personally torn on the use of L2TP >> over IPSec, I see certain implementations that can benefit, >> but the reasons MS gives do not impress me. >> Any comments are welcome. >> Shriver> Well, for the DATA path, PPP itself has no concerns about packet reordering. Shriver> IP over PPP could care less. Shriver> But, some of the protocols over PPP care very much about reordering. IEEE Shriver> 802.1D bridging assumes essentially no possibility of reordering, so BCP Shriver> over PPP has to assume that what is under PPP will not reorder. Shriver> But, the big problem is the entire PPP negotiation state machine. (The Shriver> CONTROL path.) It is absolutely designed on the assumption that the data Shriver> link underneath will never reorder packets. Suppose a NCP Config-Ack was Shriver> sent by an IPCP Config-Request. If they were swapped in transit, the IPCP Shriver> packet would be received before NCP was up. Shriver> Also, the Van Jacobsen TCP header compression really benefits greatly from Shriver> being informed of packet loss at the receiver. L2TP can provide some hint Shriver> of that. From owner-ipsec@lists.tislabs.com Thu Oct 14 14:52:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA28701; Thu, 14 Oct 1999 14:52:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01102 Thu, 14 Oct 1999 16:11:25 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFE7E293@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Racing QM Initiator's Date: Thu, 14 Oct 1999 16:15:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As was already discussed, you can't simply abort one of the negotiations. You may have to negotiate two SAs for the same selectors. However, you do have the option of fixing the problem when rekeying. draft-jenkins-ipsec-rekeying-02.txt recommends (sort of) the following: 3.4.4 Re-keying Timing To reduce the probability of simultaneous re-keying, each device should re-key at a variable time with respect to the SA's expiration limit, in case they are the same. These recommendations apply to both phase 1 and phase 2 SAs. An example of this is that the end with the higher IP address re- keys at 95% of the lifetime, while the end with lower IP address re- keys at 85% of the lifetime. Whatever rule is chosen, it is recommended that the rule be deterministic in order to have predictable and consistent behaviour between peers. If the rule had used the SPI as the determining factor (as an example did in the first version of this document), different peers would be doing the re-keying at different times. In any case, simultaneous attempts at re-keying should be supported in one form or another, since it can never be guaranteed that this will not happen under all circumstances. As you can see, Tim doesn't actually suggest that 85% and 95% be standardized. That would impinge on implementors' choice of policy. However, we could recommend that A send a lifetime notify to B, stating the time at which she intends to REKEY (rather than the actually expiry time). B parses the lifetime notify and chooses his own set of rekeying constraints which fall within his policy but do not conflict with A's stated intentions. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Radha Gowda [mailto:rxg@openroute.com] > Sent: Wednesday, October 13, 1999 5:44 PM > To: Ben McCann > Cc: ipsec@lists.tislabs.com > Subject: Re: Racing QM Initiator's > > > > 3. One SG aborts and becomes responder. How do you know which should > > abort? The SG with the lowest IP address? > > Ben, we also experienced the same problem. Not just in > phase2, but in phase1 > > as well. Just to get things going, we decided to let the > one with the higher > > IP address be the initiator. > From owner-ipsec@lists.tislabs.com Thu Oct 14 15:18:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA29014; Thu, 14 Oct 1999 15:18:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00847 Thu, 14 Oct 1999 15:41:13 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B001D6A3DB@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'Jim Tiller'" , "Shriver, John" Cc: "'Ari Huttunen'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Re[4]: PPP over IPSec (without L2TP)? Date: Thu, 14 Oct 1999 12:23:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Jim Tiller [mailto:tiller_j@ins.com] > Sent: Thursday, October 14, 1999 3:09 PM > To: Shriver, John > Cc: 'Ari Huttunen'; ietf-ipsra@vpnc.org; ipsec@lists.tislabs.com > Subject: Re[4]: PPP over IPSec (without L2TP)? > > > OK, but I keep choking on one aspect. > > If PPP is encapsulated into L2TP, which basically assumes the > form of an IP packet (right?) Doesn't the same issues of > reordering exist? Eliminate IPSec for a second. I'm > obviously not an L2TP dude, but I'm aware of in-band > controls within L2TP that provide the options to the > passenger protocol(s). See section 5.4 of L2TP. Of course, sequencing is optional. > I guess my misunderstanding revolves > around that if a packet is ultimately forwarded through an > IP network, the odds of packets arriving at the destination > in the wrong order are high. At that point don't the > packets get reordered by the IP stack of the receiving system > and then passed up the stack? At that point aren't the PPP > LCPs and NCPs reordered inherently prior to de-encapsulation? No. The IP and UDP layers under L2TP don't do any correction of re-ordered packets. That is not part of the service contracto or IP or UDP, only of TCP, which isn't involved. > Please be patient with me, I know I'm missing a critical > step and completely over simplifying the process. > I just don't see the need for L2TP > over IPSec, it's not sticking. > L2TP is heavier than what was needed. It has a whole multiplexing layer for many connections over one LAC/LNS connection, and there will only be one. But, it is a standards-track protocol. That's a plus, whether it's the ideal protocol or not. (It's not a standard by fiat like MS-CHAP.) It also made it easier for Microsoft to integrate IPSec/VPN functionality into Windows 2000. The IPSec community gains by having such a widely available IPSec implementation. From owner-ipsec@lists.tislabs.com Thu Oct 14 16:00:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA29487; Thu, 14 Oct 1999 16:00:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01311 Thu, 14 Oct 1999 17:01:10 -0400 (EDT) Message-ID: <380645E8.E7FAD4B@redcreek.com> Date: Thu, 14 Oct 1999 14:06:48 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Tiller CC: Ari Huttunen , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (without L2TP)? References: <38060149.F2DCC128@redcreek.com> <15640.991014@ins.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jim Tiller wrote: > > Hello Scott, > > Thursday, October 14, 1999, 12:14:01 PM, you wrote: > > Kelly> This dances around a bigger problem which keeps recurring in different > Kelly> guises on this list: vpn and ipsec are not synonymous. > I just had an extensive discussion with several associates > about the interchange of the acronyms IPSec and VPN. VPN > can be all encompassing where IPSec is specific. > I guess my question to you, et al, is why do vendors attempt > to "hack" L2TP and IPSec together and not augment L2TP with > encryption, releasing IPSec from acting as a crutch? I'll have to leave this one to the L2TP experts here. However, I will note that vendors attempt to fill customer needs quickly, and sometimes this motivates vendors to find a quick way (not necessarily the best way, mind you) to make things work. Scott From owner-ipsec@lists.tislabs.com Thu Oct 14 17:57:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA01138; Thu, 14 Oct 1999 17:57:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01638 Thu, 14 Oct 1999 19:26:09 -0400 (EDT) Message-ID: <19991014234002.14486.rocketmail@web1401.mail.yahoo.com> Date: Thu, 14 Oct 1999 16:40:02 -0700 (PDT) From: Pyda Srisuresh Subject: Re: PPP over IPSec (without L2TP)? To: Ari Huttunen , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari, You might want to take a look at , titled "Secure Remote Access with L2TP". This takes a different tack from using IPsec to protect L2TP traffic between a LAC and an LNS. The draft essentially recommends using PPP over IPsec, while using L2TP to tunnel PPP packets over the internet. Such a scheme, I believe, is a beneficiary of the advantages of both L2TP and IPsec, while also providing end-to-end security using existing standards. regards, suresh --- Ari Huttunen wrote: > Microsoft's position regarding L2TP is according to > http://www.microsoft.com/windows/server/Technical/networking/NWPriv.asp > (partly) the following: > > L2TP is a well-defined, interoperable protocol that addresses the current > shortcomings of IPSec-only client-to-gateway and gateway-to-gateway scenarios > (user authentication, tunnel IP address assignment, and multiprotocol > support). L2TP has broad vendor support, particularly among the largest > network access equipment providers, and has verified interoperability. By > placing L2TP as payload within an IPSec packet, communications benefit from > the standards-based encryption and authenticity of > IPSec, while also receiving a highly interoperable way to accomplish user > authentication, tunnel address assignment, multiprotocol support, and > multicast support using PPP. This combination is commonly referred to as > L2TP/IPSec. Lacking a better pure IPSec standards solution, Microsoft > believes that L2TP/IPSec provides the best standards based solution for > multi-vendor, interoperable client-to-gateway VPN scenarios. Microsoft is > working closely with key networking vendors including Cisco, 3Com, > Lucent and IBM, to support this important combination. > > I agree that having PPP gives us the stated benefits (and more?). However, I > fail to see why there > is a need to have an L2TP (and UDP) layer(s) between PPP and IPSec. As I > understand > L2TP, it would give us two benefits a) being able to tunnel PPP over several > links, which > IPSec already gives us, and b) being able to specify telephone world things > like calling / > called numbers and call failures due to a busy tone, which in a general IP > world are non-relevant. > > I agree that a lot of Internet connectivity is through a telephone network, > but the calling numbers > should not be relied on for any sort of identification, despite what the > telephone world people > would like to convince people to believe. The only valid usage for telephone > numbers that > I see is call charging, but the ISPs are free to use L2TP for that purpose > without there being > any need for IPSec security gateways or IPSec hosts knowing or even caring > about it. > > So, please show me what benefits PPP over L2TP over IPSec provides when > compared > to just running PPP over IPSec? If there are some, which is possible, > wouldn't it be > better to enhance IPSec protocol(s) to enable the same, instead of having > L2TP? > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > Data Fellows Corporation http://www.DataFellows.com > > F-Secure products: Integrated Solutions for Enterprise Security > > > ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Thu Oct 14 18:42:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA04878; Thu, 14 Oct 1999 18:42:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01769 Thu, 14 Oct 1999 20:11:27 -0400 (EDT) Reply-To: From: "Bernard Aboba" To: "'Stephen Kent'" , "'Jim Tiller'" Cc: , Subject: RE: Re[2]: PPP over IPSec (without L2TP)? Date: Thu, 14 Oct 1999 17:05:13 -0700 Message-ID: <00fe01bf16a0$f4ff1740$478939cc@internaut.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.5400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please. We went through this issue in the L2TP draft and your proposed wording was rejected. No "misleading claims" were included in the original draft, and in fact it was your proposed wording that was rejected as misleading. Let's not go rewriting history. In L2TP it is perfectly possible to apply filters to achieve the same level of security. In fact, if anything the argument went the other way -- because L2TP does user authentication, when run over IPSEC its security is stronger than that of IPSEC tunnel mode implementations that only do machine authentication and therefore have no idea who the user is. From owner-ipsec@lists.tislabs.com Thu Oct 14 21:33:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA13507; Thu, 14 Oct 1999 21:33:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02046 Thu, 14 Oct 1999 22:28:09 -0400 (EDT) Reply-To: From: "Scott Davidson" To: Cc: Subject: RE: request Date: Thu, 14 Oct 1999 21:29:56 -0500 MIME-Version: 1.0 Message-ID: Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_002A_01BF168B.28F6EE80"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-To: <19991014134145.A25243@jerome.psti.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002A_01BF168B.28F6EE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit What is means is this: The standard known as ISAKMP/Oakley is now known as IKE The standard known as IKE does not specifically exactly conform to the standard known as ISAKMP/Oakley Manufacturers have adopted IKE in order to satisfy customer needs rather than try to comply with the full ISAKMP/Oakley standard You will hear IKE and ISAKMP/Oakley used interchangeably IKE and ISAKMP/Oakley are not the same standard as viewed from the RFC, IKE is a subset of the original standard that for all intents and purposes is the same thing in practical applications. Scott Davidson Central US Systems Engineer NOKIA IPRG US Sales - Dallas 214.632.6191 scott.davidson@iprg.nokia.com www.nokia.com support.iprg.nokia.com -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of jerome@psti.com Sent: Thursday, October 14, 1999 12:42 PM To: scott.davidson@iprg.nokia.com Cc: ipsec@lists.tislabs.com Subject: Re: request On Thu, Oct 14, 1999 at 11:52:08AM -0400, Scott Davidson wrote: > Internet Key Exchange > The Internet Key Exchange or IKE that define how to exchange security > keys for authentication and how to negotiate the parameters of > individual virtual private networks. IKE was originally known as > ISAKMP/Oakley and is an Internet Protocol Security standard. does this mean that ISAKMP/Oakley are officially obsoleted by IKE ? The following quote seems to present it more as a subset. " This does not implement the entire Oakley protocol, but only a subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol nor is it dependant in any way on the Oakley protocol. " -- rfc2409.2 about IKE ------=_NextPart_000_002A_01BF168B.28F6EE80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKKTCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/ LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIEszCCBBygAwIBAgIQTRW6AR01IOqQtMIC5JkT9jANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTEwMTQw MDAwMDBaFw05OTEyMTMyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEnMCUGA1UECxMeRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 MRcwFQYDVQQDFA5TY290dCBEYXZpZHNvbjEsMCoGCSqGSIb3DQEJARYdc2NvdHQuZGF2aWRzb25A aXByZy5ub2tpYS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwQ8DP/5+MvNL0IdjQUCAOPYZ J8EIBidEZLbpFn2WslY09KQZP8Rd4EZsMmwQSVmPeimEQWxMmid7j8p01S32JQIDAQABo4IBjzCC AYswCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWdu LCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0 NjUyYmQ2M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcw MTc0N2RhNWQzZjIxNDFiZWFkYjJiZDJlODkyMTFhODY5ZjJkZjExNDg5Y2EzYmQ0NGY1ZjNlYTQ1 MGMwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDAN BgkqhkiG9w0BAQQFAAOBgQB2A7Xm+uE+uHzE8upMojmjvL5IHNhDfkS7ZJoOkxAZ10QS6RurD69I lKHxAxf/EdT0gsEYvqYg2W/dFB/TC4I5sLhgvEyCzjyohOHODcxUzTEokGCyteXgZgIksFnyrVb4 /NNKy6MQq/eLeaNZkQtNy4V2ogtxflkmKgnmeuAdbjGCAtIwggLOAgEBMIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmli ZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBNFboBHTUg6pC0wgLkmRP2MAkGBSsOAwIaBQCgggGH MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxNTAyMjkxM1ow IwYJKoZIhvcNAQkEMRYEFJP8lnhXiRNTaa88Czm5pwhQJVIyMDMGCSqGSIb3DQEJDzEmMCQwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQTRW6AR01IOqQtMIC5JkT9jANBgkqhkiG 9w0BAQEFAARAF+US2n1Fj9dFiygNelrrwQH7VEfb3yM+zO1HFJ6alOTB6IkcyWQmUxzqR2nMKBsP syJiphhKtIwSwNsK4PjQEwAAAAAAAA== ------=_NextPart_000_002A_01BF168B.28F6EE80-- From owner-ipsec@lists.tislabs.com Thu Oct 14 22:33:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA15433; Thu, 14 Oct 1999 22:33:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02255 Fri, 15 Oct 1999 00:01:42 -0400 (EDT) Message-Id: <199910150402.VAA01414@gallium.network-alchemy.com> To: scott.davidson@iprg.nokia.com cc: jerome@psti.com, ipsec@lists.tislabs.com Subject: Re: request In-reply-to: Your message of "Thu, 14 Oct 1999 21:29:56 CDT." Date: Thu, 14 Oct 1999 21:02:54 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, >The standard known as ISAKMP/Oakley is now known as IKE Correct. >The standard known as IKE does not specifically exactly conform to the >standard known as ISAKMP/Oakley >Manufacturers have adopted IKE in order to satisfy customer needs rather >than try to comply with the full ISAKMP/Oakley standard >IKE and ISAKMP/Oakley are not the same standard as viewed from the RFC, >IKE is a subset of the original standard that for all intents and >purposes is the same thing in practical applications. These statements are partially incorrect and misleading. What you may have meant is that IKE does not implement all of ISAKMP or all of Oakley. That's certainly true. However, IKE is ISAKMP/Oakley and is _the_ key exchange mechanism that the IETF adopted. All we did was shorten its name to make it more pronouncable. We published the Oakley draft as an RFC because it provides important background and justification for the security of the IKE key exchange protocol. >You will hear IKE and ISAKMP/Oakley used interchangeably Actually, few people speak of ISAKMP/Oakley anymore. Derrell From owner-ipsec@lists.tislabs.com Fri Oct 15 01:28:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA20204; Fri, 15 Oct 1999 01:28:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA02619 Fri, 15 Oct 1999 02:41:57 -0400 (EDT) Message-Id: <199910150644.KAA03616@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: "Scott G. Kelly" , Dan Harkins Date: Fri, 15 Oct 1999 10:43:26 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Racing QM Initiator's CC: Sankar Ramamoorthi , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com In-reply-to: <380603B8.6A9BF0C6@redcreek.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 14 Oct 99, at 9:24, Scott G. Kelly wrote: > Valery Smyslov wrote: > > > > Another curious point - how IKE handles self-connect. Let us assume > > we have IPsec host A and an attacker injects IKE packet (src_ip = A, > > dst_ip = A, CKY-I = xxx, CKY-R = 0) into the network. A receives this > > packet and (naively) begins to act as responder creating state and > > replying with packet (src_ip = A, dst_ip = A, CKY-I = xxx, CKY-R = > > yyy). Then it receives this packet back, binds it to that very state > > and, most likely, rejects it (possibly with some error notification) > > because it is malformed from his (responder's) point of view. After > > some time state will die due to timeout. Is this scenario correct? I > > understand that this situation causes no particular harm and it is > > very easy to avoid by simple sanity check (compare IP addresses), but > > still, IKE seem to have no special treatment of it, have it? > > Assuming policy is correctly configured (and implemented), this packet > should never reach the IKE implementation, should it? Why not? IKE is built atop TCP/IP stack, for the stack it is perfectly valid packet, IPsec policy usually allows any IKE packet (UDP/500) to pass through (otherwise you won't be able to communicate with nomadic peers). So, what prevents this packet from reaching IKE implementation? It may be dropped inside IKE implementation after simple sanity check, as I wrote. But the question was (just for curiosity): whether "self-connect" situation was considered by protocol designers or not? > Scott Regards, Valera. From owner-ipsec@lists.tislabs.com Fri Oct 15 01:34:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA20262; Fri, 15 Oct 1999 01:34:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02706 Fri, 15 Oct 1999 03:02:53 -0400 (EDT) Message-Id: <199910150705.LAA04277@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: "Scott G. Kelly" , Dan Harkins Date: Fri, 15 Oct 1999 11:04:35 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Racing QM Initiator's CC: Sankar Ramamoorthi , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com In-reply-to: <3805FC73.510A44F9@redcreek.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 14 Oct 99, at 8:53, Scott G. Kelly wrote: > Valery Smyslov wrote: > > > > > > Dan, it's OK with simultaneous phase 2 negotiations. But what about > > simultaneous phase 1 negotiations? Is there any reason (besides > > implementation simplicity) not to drop one of negotiation (of course, > > with some clear rule to decide which one, for examble, based on IP > > addresses comparison)? > > How about the case in which one of the phase 1 SAs requires ID PFS while > the other one does not? The following diagram clarifies: > > +---+ | | +---+ > | A |--| +---+ +---+ |--| B | > +---+ |--| x |==internet==| y |--| +---+ > | +---+ +---+ | > +---+ | | +---+ > | C |--| |--| D | > +---+ | | +---+ > > Assume that x and y are security gateways which provide ipsec services > to their respective local networks. Suppose that A wants to talk to D, > and this SA requires ID PFS. Suppose that around the same time, B wants > to talk to C, and this SA does not require PFS. When a packet A=>D > arrives at x, x begins negotiating with y. Suppose a packet B=>C arrives > at y prior to the arrival of x's first IKE packet, at which time y > initiates IKE with x, and the two IKE packets are simultaneously in > transit. > > This is a case in which it would be incorrect to drop one of the > negotiations. Good point. But robust implementations must be able to deal with situation, when one peer thinks he can use existing ISAKMP SA while the other don't think so, anyway. I think they must be able to recover after dropping one negotiation (in fact, in your scenario, dropped negotiation will just be deferred). Of course, if both peers need ID PFS, there is no reason to drop. >From my opinion, ID PFS is relatively rare thing to justify an extra resource wasting (DH) in case of simultaneous phase 1 negotiations. > Scott Regards, Valera. From owner-ipsec@lists.tislabs.com Fri Oct 15 02:37:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id CAA21901; Fri, 15 Oct 1999 02:37:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02951 Fri, 15 Oct 1999 03:59:39 -0400 (EDT) Date: Fri, 15 Oct 1999 11:01:53 +0300 (EET DST) From: Markku Savela Message-Id: <199910150801.LAA05477@anise.tte.vtt.fi> To: svan@trustworks.com CC: skelly@redcreek.com, dharkins@network-alchemy.com, Sankar@vpnet.com, vilhuber@cisco.com, bmccann@indusriver.com, ipsec@lists.tislabs.com In-reply-to: <199910150644.KAA03616@relay1.trustworks.com> (svan@trustworks.com) Subject: Re: Racing QM Initiator's Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But the question was (just for > curiosity): whether "self-connect" situation was considered by > protocol designers or not? Isn't the use of loopback a traditional way to test protocols in TCP/IP environment? So, specify security policy for the loopback address 127.0.0.1 and fire a ping to it... How many ISAKMP implementations survive and do the right thing? :) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Fri Oct 15 05:46:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA26999; Fri, 15 Oct 1999 05:46:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03426 Fri, 15 Oct 1999 06:52:16 -0400 (EDT) Message-ID: <38070829.4F7AC3CA@DataFellows.com> Date: Fri, 15 Oct 1999 13:55:37 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com CC: "'Stephen Kent'" , "'Jim Tiller'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (without L2TP)? References: <00fe01bf16a0$f4ff1740$478939cc@internaut.com> Content-Type: multipart/alternative; boundary="------------ABACCCAA473B289361B1F6DC" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------ABACCCAA473B289361B1F6DC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In L2TP it is perfectly possible to apply > filters to achieve the same level of security. In fact, if > anything the argument went the other way -- because L2TP > does user authentication, when run over IPSEC its security > is stronger than that of IPSEC tunnel mode implementations > that only do machine authentication and therefore have no > idea who the user is. Excuse me? I'm not an expert on L2TP, but I believe that's not entirely correct. Let me quote RFC-2661. > 9.1 Tunnel Endpoint Security > > The tunnel endpoints may optionally perform an authentication > procedure of one another during tunnel establishment. This > authentication has the same security attributes as CHAP, and has > reasonable protection against replay and snooping during the tunnel > establishment process. This mechanism is not designed to provide any > authentication beyond tunnel establishment; it is fairly simple for a > malicious user who can snoop the tunnel stream to inject packets once > an authenticated tunnel establishment has been completed > successfully. > > For authentication to occur, the LAC and LNS MUST share a single > secret. Each side uses this same secret when acting as authenticatee > as well as authenticator. Since a single secret is used, the tunnel > authentication AVPs include differentiating values in the CHAP ID > fields for each message digest calculation to guard against replay > attacks. > I believe L2TP only authenticates the machines, while it's PPP that authenticates the users. There was also some talk about filtering of packets. As you see below, RFC-2661 wishes to put the filtering above its layer, to the PPP layer. Achieving this should be easier in practice if you have less protocol layers between IPSec and PPP. > 9.4 L2TP and IPsec > > ...snip... > > IPsec also defines access control features that are required of a > compliant IPsec implementation. These features allow filtering of > packets based upon network and transport layer characteristics such > as IP address, ports, etc. In the L2TP tunneling model, analogous > filtering is logically performed at the PPP layer or network layer > above L2TP. These network layer access control features may be > handled at the LNS via vendor-specific authorization features based > upon the authenticated PPP user, or at the network layer itself by > using IPsec transport mode end-to-end between the communicating > hosts. The requirements for access control mechanisms are not a part > of the L2TP specification and as such are outside the scope of this > document. > As to the re-ordering of packets by IPSec.. IPSec already does sequence numbers. It shouldn't be too difficult to define a new IPSec SA attribute negotiable by IKE that says "sequenced delivery of packets required". The recieving IPSec implementation would perhaps try to re-order packets during a few milliseconds or whatever, and drop packets that come after that. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security --------------ABACCCAA473B289361B1F6DC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Bernard Aboba wrote:
In L2TP it is perfectly possible to apply
filters to achieve the same level of security. In fact, if
anything the argument went the other way -- because L2TP
does user authentication, when run over IPSEC its security
is stronger than that of IPSEC tunnel mode implementations
that only do machine authentication and therefore have no
idea who the user is.
Excuse me? I'm not an expert on L2TP, but I believe that's not
entirely correct. Let me quote RFC-2661.
9.1 Tunnel Endpoint Security

   The tunnel endpoints may optionally perform an authentication
   procedure of one another during tunnel establishment.  This
   authentication has the same security attributes as CHAP, and has
   reasonable protection against replay and snooping during the tunnel
   establishment process. This mechanism is not designed to provide any
   authentication beyond tunnel establishment; it is fairly simple for a
   malicious user who can snoop the tunnel stream to inject packets once
   an authenticated tunnel establishment has been completed
   successfully.

   For authentication to occur, the LAC and LNS MUST share a single
   secret.  Each side uses this same secret when acting as authenticatee
   as well as authenticator. Since a single secret is used, the tunnel
   authentication AVPs include differentiating values in the CHAP ID
   fields for each message digest calculation to guard against replay
   attacks.

I believe L2TP only authenticates the machines, while it's PPP that authenticates
the users.

There was also some talk about filtering of packets. As you see below, RFC-2661
wishes to put the filtering above its layer, to the PPP layer. Achieving this
should be easier in practice if you have less protocol layers between IPSec and PPP.

9.4 L2TP and IPsec

...snip...

   IPsec also defines access control features that are  required of a
   compliant IPsec implementation. These features allow filtering of
   packets based upon network and transport layer characteristics such
   as IP address, ports, etc. In the L2TP tunneling model, analogous
   filtering is logically performed at the PPP layer or network layer
   above L2TP.  These network layer access control features may be
   handled at the LNS via vendor-specific authorization features based
   upon the authenticated PPP user, or at the network layer itself by
   using IPsec transport mode end-to-end between the communicating
   hosts. The requirements for access control mechanisms are not a part
   of the L2TP specification and as such are outside the scope of this
   document.


As to the re-ordering of packets by IPSec.. IPSec already does sequence numbers. It shouldn't
be too difficult to define a new IPSec SA attribute negotiable by IKE that says "sequenced
delivery of packets required". The recieving IPSec implementation would perhaps try to re-order
packets during a few milliseconds or whatever, and drop packets that come after that.

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security
  --------------ABACCCAA473B289361B1F6DC-- From owner-ipsec@lists.tislabs.com Fri Oct 15 07:32:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA28320; Fri, 15 Oct 1999 07:32:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03883 Fri, 15 Oct 1999 08:52:09 -0400 (EDT) Date: Fri, 15 Oct 1999 08:52:22 -0400 From: Rich Neill Message-Id: <199910151252.IAA12482@eagle.ameristar.com> To: ipsec@lists.tislabs.com Subject: IKE reference implementations Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there any open (public domain) IKE reference implementations available? Rich From owner-ipsec@lists.tislabs.com Fri Oct 15 09:01:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA29888; Fri, 15 Oct 1999 09:00:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04426 Fri, 15 Oct 1999 10:19:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14343.14150.578359.846546@gargle.gargle.HOWL> Date: Fri, 15 Oct 1999 10:16:38 -0400 (EDT) From: David Tannheimer To: ipsec@lists.tislabs.com Subject: SA bundle negotiation X-Mailer: VM 6.71 under Emacs 19.34.1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I apologize in advance if this has already been beaten to death on the list. I have a question as to the right way to negotiate encapsulation mode for certain ipsec SA bundles, to ensure interoperability. I've heard various arguments, but I need a larger feedback sampling. To achieve the following encapsulation format, should both the ESP transform payload and the AH transform payload (in the quick mode exchange) specify Tunnel mode, or is ESP in Tunnel mode and AH in Transport mode? ----------------------------------------- | Outer | AH | ESP | Orig | Payload | | IP Hdr | Hdr | Hdr | IP Hdr | | ----------------------------------------- Same idea here. Should IPComp be negotiated as Tunnel mode, with both ESP and AH in Transport mode, or are they all negotiated as Tunnel mode? -------------------------------------------------- | Outer | AH | ESP | IPComp | Orig | Payload | | IP Hdr | Hdr | Hdr | Hdr | IP Hdr | | -------------------------------------------------- Thanks, Dave From owner-ipsec@lists.tislabs.com Fri Oct 15 09:02:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA00135; Fri, 15 Oct 1999 09:02:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04452 Fri, 15 Oct 1999 10:23:20 -0400 (EDT) Message-Id: <199910151421.QAA31586@waldorf.appli.se> To: Rich Neill cc: ipsec@lists.tislabs.com Subject: Re: IKE reference implementations In-reply-to: Your message of "Fri, 15 Oct 1999 08:52:22 EDT." <199910151252.IAA12482@eagle.ameristar.com> Date: Fri, 15 Oct 1999 16:21:01 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Fri, 15 Oct 1999 08:52:22 -0400 > From: Rich Neill > > Are there any open (public domain) IKE reference > implementations available? Well not public domain, but BSD-licensed, which is fairly liberal; isakmpd from OpenBSD. Can be gotten from either the OpenBSD sourcetree which is available via web, for example, www.openbsd.org. There is also a slightly more general dist at ftp.gsnig.net:/pub/isakmpd which however is updated more seldom. Niklas From owner-ipsec@lists.tislabs.com Fri Oct 15 09:28:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA00801; Fri, 15 Oct 1999 09:28:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04245 Fri, 15 Oct 1999 09:52:14 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <00fe01bf16a0$f4ff1740$478939cc@internaut.com> References: Date: Fri, 15 Oct 1999 09:50:28 -0400 To: From: Stephen Kent Subject: RE: Re[2]: PPP over IPSec (without L2TP)? Cc: , Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bernard, >We went through this issue in the L2TP draft and your proposed >wording was rejected. No "misleading claims" were >included in the original draft, and in fact it was your proposed >wording that was rejected as misleading. Let's not go >rewriting history. The technical term here is bullshit. The wording in the RFC is substantively different from that which was in the document when it was submitted for IESG approval. If anyone questions this claim, contact Tom Narten (the cognizant area director), who mediated the protracted discussion. While I did not succceed in getting the wording I would have preferred, and which would more accurately characterize the limitations of an L2TP + IPsec implementation vs. a native IPsec implementtaion, the wording did remove some of the technically misleading claims that the RFC authors had originally made. >In L2TP it is perfectly possible to apply >filters to achieve the same level of security. In fact, if >anything the argument went the other way -- because L2TP >does user authentication, when run over IPSEC its security >is stronger than that of IPSEC tunnel mode implementations >that only do machine authentication and therefore have no >idea who the user is. While it MAY be possible to apply filters in L2TP, the standard did not require it, and there was no standard for such filters at the time this debate took place. Moreover, in a modular implementation of L2TP plus IPsec, the information about the SA with which a packet is associated will be lost by the time the L2TP filters are applied. Thus, the filters cannot, in principle, determine if the traffic is consistent with parameters for the SA in question. It would seem that, at best, the L2TP filters can determine if the traffic is consistent with ANY currently active connection, and at worst they might determine if the traffic is consistent with ANY connection that might be permitted. The statement about user vs. machine authentication is incorrect, and consistent with the misunderstanding of IPsec expressed by some of the L2TP partisans. If you read RFC 2401 carefully you will note that IPsec supports individual user authentication, in both modes. Steve From owner-ipsec@lists.tislabs.com Fri Oct 15 09:50:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA01231; Fri, 15 Oct 1999 09:50:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04668 Fri, 15 Oct 1999 10:55:19 -0400 (EDT) To: Rich Neill , ipsec@lists.tislabs.com In-reply-to: niklas's message of Fri, 15 Oct 1999 16:21:01 +0200. <199910151421.QAA31586@waldorf.appli.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IKE reference implementations From: itojun@iijlab.net Date: Fri, 15 Oct 1999 23:52:50 +0900 Message-ID: <5201.939999170@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Date: Fri, 15 Oct 1999 08:52:22 -0400 >> From: Rich Neill >> Are there any open (public domain) IKE reference >> implementations available? >Well not public domain, but BSD-licensed, which is fairly liberal; >isakmpd from OpenBSD. Can be gotten from either the OpenBSD >sourcetree which is available via web, for example, www.openbsd.org. >There is also a slightly more general dist at >ftp.gsnig.net:/pub/isakmpd which however is updated more seldom. Another BSD licensed IKE daemon would be KAME racoon, check www.kame.net. itojun From owner-ipsec@lists.tislabs.com Fri Oct 15 10:45:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA02225; Fri, 15 Oct 1999 10:45:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04912 Fri, 15 Oct 1999 11:50:02 -0400 (EDT) Reply-To: From: "Scott Davidson" To: "Derrell D. Piper" Cc: Subject: RE: request Date: Fri, 15 Oct 1999 10:51:52 -0500 MIME-Version: 1.0 Message-ID: Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000C_01BF16FA.718A7E40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-reply-To: <199910150402.VAA01414@gallium.network-alchemy.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000C_01BF16FA.718A7E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit That is what I meant to say, exactly. Thanks for the clarification. Scott Davidson Central US Systems Engineer NOKIA IPRG US Sales - Dallas 214.632.6191 scott.davidson@iprg.nokia.com www.nokia.com support.iprg.nokia.com -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell D. Piper Sent: Thursday, October 14, 1999 11:03 PM To: scott.davidson@iprg.nokia.com Cc: jerome@psti.com; ipsec@lists.tislabs.com Subject: Re: request Scott, >The standard known as ISAKMP/Oakley is now known as IKE Correct. >The standard known as IKE does not specifically exactly conform to the >standard known as ISAKMP/Oakley >Manufacturers have adopted IKE in order to satisfy customer needs rather >than try to comply with the full ISAKMP/Oakley standard >IKE and ISAKMP/Oakley are not the same standard as viewed from the RFC, >IKE is a subset of the original standard that for all intents and >purposes is the same thing in practical applications. These statements are partially incorrect and misleading. What you may have meant is that IKE does not implement all of ISAKMP or all of Oakley. That's certainly true. However, IKE is ISAKMP/Oakley and is _the_ key exchange mechanism that the IETF adopted. All we did was shorten its name to make it more pronouncable. We published the Oakley draft as an RFC because it provides important background and justification for the security of the IKE key exchange protocol. >You will hear IKE and ISAKMP/Oakley used interchangeably Actually, few people speak of ISAKMP/Oakley anymore. Derrell ------=_NextPart_000_000C_01BF16FA.718A7E40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKKTCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/ LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDl X4KmsaiSxVhqwY0DPOvDzQWikK5uMIIEszCCBBygAwIBAgIQTRW6AR01IOqQtMIC5JkT9jANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTEwMTQw MDAwMDBaFw05OTEyMTMyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEnMCUGA1UECxMeRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 MRcwFQYDVQQDFA5TY290dCBEYXZpZHNvbjEsMCoGCSqGSIb3DQEJARYdc2NvdHQuZGF2aWRzb25A aXByZy5ub2tpYS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwQ8DP/5+MvNL0IdjQUCAOPYZ J8EIBidEZLbpFn2WslY09KQZP8Rd4EZsMmwQSVmPeimEQWxMmid7j8p01S32JQIDAQABo4IBjzCC AYswCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWdu LCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0 NjUyYmQ2M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcw MTc0N2RhNWQzZjIxNDFiZWFkYjJiZDJlODkyMTFhODY5ZjJkZjExNDg5Y2EzYmQ0NGY1ZjNlYTQ1 MGMwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDAN BgkqhkiG9w0BAQQFAAOBgQB2A7Xm+uE+uHzE8upMojmjvL5IHNhDfkS7ZJoOkxAZ10QS6RurD69I lKHxAxf/EdT0gsEYvqYg2W/dFB/TC4I5sLhgvEyCzjyohOHODcxUzTEokGCyteXgZgIksFnyrVb4 /NNKy6MQq/eLeaNZkQtNy4V2ogtxflkmKgnmeuAdbjGCAtIwggLOAgEBMIHhMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmli ZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBNFboBHTUg6pC0wgLkmRP2MAkGBSsOAwIaBQCgggGH MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxNTE1NDU0OVow IwYJKoZIhvcNAQkEMRYEFGBVlMrnQ0iNLpkDD0p4d4ip5AapMDMGCSqGSIb3DQEJDzEmMCQwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYu LExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQTRW6AR01IOqQtMIC5JkT9jANBgkqhkiG 9w0BAQEFAARAc3xTu2wpBZIUPssywGAxX5EUpZ/5JGPMMWXtrbL+AJ/VVx2LWWmxzrYbdFpwvKza f13+fWQ1Cn3noQKt3zv1qAAAAAAAAA== ------=_NextPart_000_000C_01BF16FA.718A7E40-- From owner-ipsec@lists.tislabs.com Fri Oct 15 11:28:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA02765; Fri, 15 Oct 1999 11:28:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05087 Fri, 15 Oct 1999 12:28:48 -0400 (EDT) Message-ID: <38075797.6803942A@redcreek.com> Date: Fri, 15 Oct 1999 09:34:31 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Valery Smyslov CC: Dan Harkins , Sankar Ramamoorthi , Jan Vilhuber , Ben McCann , ipsec@lists.tislabs.com Subject: Re: Racing QM Initiator's References: <199910150644.KAA03616@relay1.trustworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Valery, Valery Smyslov wrote: > > > > Assuming policy is correctly configured (and implemented), this packet > > should never reach the IKE implementation, should it? > > Why not? IKE is built atop TCP/IP stack, for the stack it is > perfectly valid packet, IPsec policy usually allows any IKE packet > (UDP/500) to pass through (otherwise you won't be able to communicate > with nomadic peers). So, what prevents this packet from reaching IKE > implementation? RFC 2401 explicitly notes that IKE traffic is subject to policy. Maybe your policy usually allows any IKE packet to pass through, but if your implementation is compliant with RFC 2401, then this is a policy matter, and not hard-coded. It seems to me that this is a non-issue, since these packets may easily be prevented from passing up the stack in a compliant implementation. Scott From owner-ipsec@lists.tislabs.com Fri Oct 15 12:17:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03507; Fri, 15 Oct 1999 12:17:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05333 Fri, 15 Oct 1999 13:19:13 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEA188B@exchange> From: Paul Kierstead To: Dan Harkins , "Brian Swander (Exchange)" Cc: "'ddp@network-alchemy.com'" , ipsec@lists.tislabs.com Subject: RE: comments on the latest GSSAPI draft changes Date: Fri, 15 Oct 1999 13:23:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It would not seem much effort to change the numbers and would save a great deal of trouble. It is really a small thing. As to shipping based on drafts: It may be foolhardy, but is unquestionably necessary both from a business point of view and for specification improvement -- there is no testing ground like the real world. Paul Kierstead TimeStep Corporation mailto:pmkierst@timestep.com http:\\www.timestep.com > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: Thursday, October 14, 1999 2:06 PM > To: Brian Swander (Exchange) > Cc: 'ddp@network-alchemy.com'; ipsec@lists.tislabs.com > Subject: Re: comments on the latest GSSAPI draft changes > > > Brian, > > Those are from the "private use" range anyway which is what > drafts are > supposed to use. This is to flush out any problems with the protocol. > If and when the draft is advanced it will be assigned real numbers by > IANA. So if and when that happens you'll have interop > problems with NT* > or any other implementation that is shipping with code written to a > draft. Note that XAUTH also claims use of 65001-65010. > > Internet Drafts are working documents and it is foolhardy to ship > code based on them. This is the price you pay if you do. > > Dan. > > On Thu, 14 Oct 1999 10:21:55 PDT you wrote > > Derrell, there are serious problems with the IDs in your > latest rev. of the > > draft. > > > > In the prior version of the draft, the next payload for the > GSS_API payload > > was 129. In the latest, it is 128. Also, the auth id for > GSS_API/Kerberos > > in the previous version was 65001. In the current version, > it is 65003, and > > the generic GSS_API id is 65001. > > > > In the presentation of the GSSAPI+Kerberos that I gave at > the IETF, I gave > > the numbers 129, 65001 as the numbers to use. These are > the numbers in the > > current version on NT5, and NT5 is shipping with these numbers. > > > > Your change of these numbers will make it very difficult > for other vendors > > to implement the GSSAPI draft, and interop with NT5. I > know of a few > > vendors out there who want to do this. It will also make > it very difficult > > for later versions of NT to interop with NT5. > > > > I see no security concerns, or any other valid reasons for > changing these > > IDs, and respectfully request that you put them back to > their original > > values. > > > > Interoperability with GSSAPI will be tough enough since > everyone building > > this will need to build in backwards compatibility code > anyway when we move > > to the IANA assigned numbers. At least that backwards > compatability is > > possible. Given your current changes, backwards > compatibility and general > > interop is next to impossible. > > > > I think it will be a major obstacle to the adoption of this > draft if these > > numbers stay as they are. Also, please push to get IANA > assigned numbers > > ASAP, so we never have to deal with the floating number > problem in GSSAPI > > again. > > > > bs > > > > > From owner-ipsec@lists.tislabs.com Fri Oct 15 12:27:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03663; Fri, 15 Oct 1999 12:27:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05360 Fri, 15 Oct 1999 13:25:12 -0400 (EDT) Message-ID: <19991015174030.14188.rocketmail@web1403.mail.yahoo.com> Date: Fri, 15 Oct 1999 10:40:30 -0700 (PDT) From: Pyda Srisuresh Subject: RE: Re[2]: PPP over IPSec (without L2TP)? To: Stephen Kent , aboba@internaut.com Cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Stephen Kent wrote: <... stuff deleted> > > The statement about user vs. machine authentication is incorrect, and > consistent with the misunderstanding of IPsec expressed by some of the L2TP > partisans. If you read RFC 2401 carefully you will note that IPsec > supports individual user authentication, in both modes. > User vs. Machine authentication is really a key management protocol issue (i.e., IKE) - somewhat orthogonal to IPsec architecture (RFC 2401). However, I do agree with Steve that there is a lot of misunderstanding on the issue of User vs. Machine authentication. IKE does not restrict from having multiple phase-I SAs between the same pair of SecGW nodes, one SA for each user that wishes to authenticate from his/her local GW to remote gateway. It is not necessary to perform the authentication in 2 phases - i.e., device-to-device authentication, followed by user-to-device authentication. The reason we have the XAUTH and HYBRID-AUTH drafts out is because IKE mandates symmteric forms of authentication and that is lot harder to accomplish with legacy systems. XAUTH tries to solve the problem by doing the authentication in 2 phases - Symmetric authentication between devices, followed by user authentication. HYBRID authentication solves the problem by allowing asymmetric authetications in the IKE protocol. Hope this helps clarify the misunderstanding. Thanks. > Steve > cheers, suresh ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Fri Oct 15 12:50:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA04265; Fri, 15 Oct 1999 12:50:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05644 Fri, 15 Oct 1999 14:20:20 -0400 (EDT) Message-Id: <199910151815.OAA01745@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: comments on the latest GSSAPI draft changes In-reply-to: Your message of "Thu, 14 Oct 1999 11:29:59 PDT." <19398D273324D3118A2B0008C7E9A56902751614@SIT.platinum.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 15 Oct 1999 14:15:14 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Exchange" == Exchange writes: Exchange> Agreed. But, shipping based on internet drafts is a necessary Exchange> evil. Given that some vendors find this necessary, the No, it is just evil. XAUTH/GSSAPI/etc. should not have specified numbers at *ALL* The ISAKMP protocol provides for ways for vendors to use the private address space in a nice fashion. It is called the Vendor ID payload. Exchange> So the question still remains: will the arbitrary ID changes be Exchange> put back to their original values, or will we have a large Exchange> divergence from the IDs in the draft, and IDs in the Exchange> marketplace? If you ship with VendorID you won't care. If you ship with bare IDs from the private address range you will get toasted at every single bakeoff, and your product will likely fail to be certified. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQB1AwUBOAdvMI5hrHmwwFrtAQFJJwL9E5/nU5UiuDAgpK0dAcLPJQV0QH5BOEN4 THXkqN/gfmTnWp11m7BBHRvIoK/ZI5kGMWDQfMqC1QfnzJ+saZxwn6iAx20lkzcT utlTWN5KVfsixmVPYZjgFrAteUGbS11O =2L65 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Oct 15 13:03:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA04432; Fri, 15 Oct 1999 13:03:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05541 Fri, 15 Oct 1999 14:11:56 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'David Tannheimer'" , ipsec@lists.tislabs.com Subject: RE: SA bundle negotiation Date: Fri, 15 Oct 1999 11:13:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is my understanding that all should be negotiated in tunnel mode. -- sankar -- -----Original Message----- From: David Tannheimer [mailto:dtannhei@nortelnetworks.com] Sent: Friday, October 15, 1999 7:17 AM To: ipsec@lists.tislabs.com Subject: SA bundle negotiation I apologize in advance if this has already been beaten to death on the list. I have a question as to the right way to negotiate encapsulation mode for certain ipsec SA bundles, to ensure interoperability. I've heard various arguments, but I need a larger feedback sampling. To achieve the following encapsulation format, should both the ESP transform payload and the AH transform payload (in the quick mode exchange) specify Tunnel mode, or is ESP in Tunnel mode and AH in Transport mode? ----------------------------------------- | Outer | AH | ESP | Orig | Payload | | IP Hdr | Hdr | Hdr | IP Hdr | | ----------------------------------------- Same idea here. Should IPComp be negotiated as Tunnel mode, with both ESP and AH in Transport mode, or are they all negotiated as Tunnel mode? -------------------------------------------------- | Outer | AH | ESP | IPComp | Orig | Payload | | IP Hdr | Hdr | Hdr | Hdr | IP Hdr | | -------------------------------------------------- Thanks, Dave From owner-ipsec@lists.tislabs.com Fri Oct 15 16:31:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA06550; Fri, 15 Oct 1999 16:31:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07037 Fri, 15 Oct 1999 17:50:14 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Paul Fahn" To: ipsec@lists.tislabs.com Message-ID: <8525680B.0077F356.00@domino2.certicom.com> Date: Fri, 15 Oct 1999 14:56:54 -0700 Subject: IKE authentication method details Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm new to IPsec and was looking at the IKE document regarding the authentication methods. Seven methods are listed on page 41, but I didn't see references on how to implement, in detail, these methods. For example, method 3 is "RSA signatures", but there are many ways of implementing RSA signatures, depending on how the formatting is done, whether there is message recovery, etc. Similar issues occur for the other methods. Can someone tell me where are the pointers from the IKE specification to the authentication method specifications? thanks, Paul From owner-ipsec@lists.tislabs.com Fri Oct 15 17:12:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA06864; Fri, 15 Oct 1999 17:12:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07183 Fri, 15 Oct 1999 18:50:59 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <19991015174030.14188.rocketmail@web1403.mail.yahoo.com> Date: Fri, 15 Oct 1999 18:45:05 -0400 To: Pyda Srisuresh From: Stephen Kent Subject: RE: Re[2]: PPP over IPSec (without L2TP)? Cc: aboba@internaut.com, ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pyda, >User vs. Machine authentication is really a key management protocol >issue (i.e., IKE) - somewhat orthogonal to IPsec architecture (RFC 2401). RFC 2401 defines ID types that must be supported in the SPD, and which are aligned with IKE ID payload types. These ID types include X.500 DNs, that can certainly be used to identify users, and RFC 821 names, which are specifically user IDs (vs. the DNS ID type, which is designated for machines). So I disagree with your assertion that this is purely a key management protocol issue. I do agree that protocols such as XAUTH demonstrate a clear intent to authenticate users, not just machines, but IKE and 2401 make definite statements to that effect already. Steve From owner-ipsec@lists.tislabs.com Fri Oct 15 17:37:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA07021; Fri, 15 Oct 1999 17:37:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07216 Fri, 15 Oct 1999 19:09:51 -0400 (EDT) Message-ID: <19398D273324D3118A2B0008C7E9A56902751618@SIT.platinum.corp.microsoft.com> From: "Brian Swander (Exchange)" To: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: RE: comments on the latest GSSAPI draft changes Date: Fri, 15 Oct 1999 16:11:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk of course our numbers are protected by vendor ids. that doesn't mean we don't care what those numbers are. we still want interop as easy as possible, which means a concensus on the numbers as much as possible. it would be nice to have good interim numbers specified in the drafts. it is clearly the best place for that specification, assuming that those numbers are well chosen, and as constant as possible. bs -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Friday, October 15, 1999 11:15 AM To: ipsec@lists.tislabs.com Subject: Re: comments on the latest GSSAPI draft changes -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Exchange" == Exchange writes: Exchange> Agreed. But, shipping based on internet drafts is a necessary Exchange> evil. Given that some vendors find this necessary, the No, it is just evil. XAUTH/GSSAPI/etc. should not have specified numbers at *ALL* The ISAKMP protocol provides for ways for vendors to use the private address space in a nice fashion. It is called the Vendor ID payload. Exchange> So the question still remains: will the arbitrary ID changes be Exchange> put back to their original values, or will we have a large Exchange> divergence from the IDs in the draft, and IDs in the Exchange> marketplace? If you ship with VendorID you won't care. If you ship with bare IDs from the private address range you will get toasted at every single bakeoff, and your product will likely fail to be certified. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQB1AwUBOAdvMI5hrHmwwFrtAQFJJwL9E5/nU5UiuDAgpK0dAcLPJQV0QH5BOEN4 THXkqN/gfmTnWp11m7BBHRvIoK/ZI5kGMWDQfMqC1QfnzJ+saZxwn6iAx20lkzcT utlTWN5KVfsixmVPYZjgFrAteUGbS11O =2L65 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Oct 16 11:52:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA15708; Sat, 16 Oct 1999 11:52:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08787 Sat, 16 Oct 1999 13:15:18 -0400 (EDT) Message-ID: <38087AFD.DAD47A1A@sympatico.ca> Date: Sat, 16 Oct 1999 13:17:49 +0000 From: Sandy Harris X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IKE reference implementations References: <199910151252.IAA12482@eagle.ameristar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rich Neill wrote: > > Are there any open (public domain) IKE reference > implementations available? FreeS/WAN is a Linux implementation under the GNU public license. http://www.xs4all.nl/~freeswan Version 1.1 shipped this week and, last I checked, the online docs on the web site had not yet been updated; they still show 1.0 docs. There are links to other Linux implementations, several for various *BSD systems, and a few for other system in file WWWref.html of 1.0 docs or links.ipsec.html in 1.1 docs. From owner-ipsec@lists.tislabs.com Sat Oct 16 15:41:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA18606; Sat, 16 Oct 1999 15:41:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11088 Sat, 16 Oct 1999 17:22:10 -0400 (EDT) Message-Id: <199910162124.RAA19735@india.citi.umich.edu> Subject: Re: IKE reference implementations From: Niels Provos In-Reply-To: Sandy Harris, Sat, 16 Oct 1999 13:17:49 -0000 To: Sandy Harris Cc: ipsec@lists.tislabs.com Date: Sat, 16 Oct 1999 17:24:30 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <38087AFD.DAD47A1A@sympatico.ca>, Sandy Harris writes: >Rich Neill wrote: >> Are there any open (public domain) IKE reference >> implementations available? >FreeS/WAN is a Linux implementation under the GNU public license. > >http://www.xs4all.nl/~freeswan It sounds as if you want a free one, one that you can freely reuse. This is not the case for FreeSWAN. But if you want a really free one, OpenBSD ships with an isakmpd implementation. It supports PFKEY as kernel interface. Look at http://www.openbsd.org/crypto.html. Greetings, Niels Provos. From owner-ipsec@lists.tislabs.com Sat Oct 16 17:17:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA20901; Sat, 16 Oct 1999 17:17:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11313 Sat, 16 Oct 1999 18:56:47 -0400 (EDT) Date: Sat, 16 Oct 1999 19:17:34 -0400 From: Richard Guy Briggs To: Niels Provos Cc: Sandy Harris , ipsec@lists.tislabs.com Subject: Re: IKE reference implementations Message-ID: <19991016191734.O6028@grendel.conscoop.ottawa.on.ca> References: <199910162124.RAA19735@india.citi.umich.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=SAeLYP8kwBCGlqB7; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.7i In-Reply-To: <199910162124.RAA19735@india.citi.umich.edu> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --SAeLYP8kwBCGlqB7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Sat, Oct 16, 1999 at 05:24:30PM -0400, Niels Provos wrote: > In message <38087AFD.DAD47A1A@sympatico.ca>, Sandy Harris writes: > >Rich Neill wrote: > >> Are there any open (public domain) IKE reference > >> implementations available? > >FreeS/WAN is a Linux implementation under the GNU public license. > > > >http://www.xs4all.nl/~freeswan > It sounds as if you want a free one, one that you can freely reuse. > This is not the case for FreeSWAN. But if you want a really free one, > OpenBSD ships with an isakmpd implementation. It supports PFKEY > as kernel interface. Look at http://www.openbsd.org/crypto.html. So, what? We are going to argue over the one true meaning of "free"? Put away your tomatoes. This is a religious issue. (I am working on PF_KEYv2 for FreeS/WAN, and use OpenBSD on my sparc for interoperability testing.) NIST has a free, reference implementation of IPSEC including IPv6, which also supports PF_KEYv2, but is export restricted. As has been suggested before, I think, you may also want to check KAME, from Japan. > Greetings, > Niels Provos. slainte mhath, RGB --=20 Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Ca= nada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: --SAeLYP8kwBCGlqB7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQCVAwUBOAkHi9+sBuIhFagtAQHIEQP/TCHcesNIPPGR1ay3jpe5mNe+A7kzZnve zxBS1W0/hyLo3l2fB2RBgUOKUIaGZFCgo8mdjvVKNALShjUjUPDIQzLGLVq7L1Nz EFwrhxdKVfK20Gs77x6k40BcKfsDmmSwdy+V9Agg9Q1WQxCp9k+SDthhDqYQECt2 p2/o9ENlXQk= =U5xR -----END PGP SIGNATURE----- --SAeLYP8kwBCGlqB7-- From owner-ipsec@lists.tislabs.com Sat Oct 16 17:20:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA20922; Sat, 16 Oct 1999 17:20:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11353 Sat, 16 Oct 1999 19:07:30 -0400 (EDT) Message-Id: <199910162309.TAA27615@india.citi.umich.edu> Subject: Re: IKE reference implementations From: Niels Provos In-Reply-To: Richard Guy Briggs, Sat, 16 Oct 1999 19:17:34 EDT To: Richard Guy Briggs Cc: Sandy Harris , ipsec@lists.tislabs.com Date: Sat, 16 Oct 1999 19:09:44 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <19991016191734.O6028@grendel.conscoop.ottawa.on.ca>, Richard Guy Br iggs writes: >> >Rich Neill wrote: >> >> Are there any open (public domain) IKE reference >> >> implementations available? [...] >So, what? We are going to argue over the one true meaning of "free"? >Put away your tomatoes. This is a religious issue. (I am working on He said public domain. Niels. From owner-ipsec@lists.tislabs.com Sat Oct 16 22:27:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA13560; Sat, 16 Oct 1999 22:27:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11864 Sun, 17 Oct 1999 00:12:55 -0400 (EDT) Date: Sun, 17 Oct 1999 00:14:30 -0400 (EDT) From: Henry Spencer To: Niels Provos cc: ipsec@lists.tislabs.com Subject: Re: IKE reference implementations In-Reply-To: <199910162309.TAA27615@india.citi.umich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 16 Oct 1999, Niels Provos wrote: > >So, what? We are going to argue over the one true meaning of "free"? ... > > He said public domain. If I am not mistaken -- I haven't looked at a recent OpenBSD -- the IKE implementation in OpenBSD is not public domain any more than the one in FreeS/WAN is. The details of what is permitted differ, but both impose restrictions... and neither set of restrictions is likely to present any great problem for the sort of use the original request implied. (Dept of Full Disclosure: I've got a foot in both camps, since I'm technical head of the FreeS/WAN project, but I prefer BSD-style licensing over GNU-style when the choice is mine.) Arguments about which is better should address technical issues, rather than theological disputes about the meaning of "free". My (secondhand) understanding is that the FreeS/WAN IKE code is already seeing some use as a reference implementation, which I find somewhat embarrassing considering how limited a subset of IKE we currently support. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Sun Oct 17 01:59:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA23148; Sun, 17 Oct 1999 01:59:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12022 Sun, 17 Oct 1999 03:03:19 -0400 (EDT) Message-Id: <199910170705.DAA01278@india.citi.umich.edu> Subject: Re: IKE reference implementations From: Niels Provos In-Reply-To: Henry Spencer, Sun, 17 Oct 1999 00:14:30 EDT To: Henry Spencer Cc: ipsec@lists.tislabs.com Date: Sun, 17 Oct 1999 03:05:07 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spen cer writes: >If I am not mistaken -- I haven't looked at a recent OpenBSD -- the IKE >implementation in OpenBSD is not public domain any more than the one in >FreeS/WAN is. The details of what is permitted differ, but both impose >restrictions... and neither set of restrictions is likely to present any >great problem for the sort of use the original request implied. The poster's question implied software that could be freely reused. The BSD-license implies such free reuse, and thus its restrictions do not matter. This is unfortunatly not true for the GPL. >(Dept of Full Disclosure: I've got a foot in both camps, since I'm >technical head of the FreeS/WAN project, but I prefer BSD-style licensing >over GNU-style when the choice is mine.) Greetings, Niels. From owner-ipsec@lists.tislabs.com Sun Oct 17 13:05:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA06192; Sun, 17 Oct 1999 13:05:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12919 Sun, 17 Oct 1999 14:41:44 -0400 (EDT) Message-ID: <19991017185851.7990.rocketmail@web1403.mail.yahoo.com> Date: Sun, 17 Oct 1999 11:58:51 -0700 (PDT) From: Pyda Srisuresh Subject: RE: Re[2]: PPP over IPSec (without L2TP)? To: Stephen Kent Cc: aboba@internaut.com, ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Stephen Kent wrote: > Pyda, > > >User vs. Machine authentication is really a key management protocol > >issue (i.e., IKE) - somewhat orthogonal to IPsec architecture (RFC 2401). > > RFC 2401 defines ID types that must be supported in the SPD, and which are > aligned with IKE ID payload types. These ID types include X.500 DNs, that > can certainly be used to identify users, and RFC 821 names, which are > specifically user IDs (vs. the DNS ID type, which is designated for > machines). So I disagree with your assertion that this is purely a key > management protocol issue. Ah, I see where you are coming from. Sure, RFC 2401 does allow using user-IDs to describe SPD. That is necessary, but not a sufficient condition to support user-ID authentication. IKE is the one that does the acutal user-ID authentication and hence provides the sufficiency for user-ID support. Further, We are not just talking about being able to use user-ID for authentication, but the actual method of authenticating the user-ID. I believe, the confusion about user-ID authentication arises not because IKE does not support user-ID auth, but because it does not support asymmetric and legacy authentication methods. > I do agree that protocols such as XAUTH > demonstrate a clear intent to authenticate users, not just machines, but > IKE and 2401 make definite statements to that effect already. > I believe, XAUTH and HYBRID-AUTH drafts (a) demonstrate the need for asymmetric and legacy authentication methods, and (b) attempt to address these in different ways as extensions to IKE. > Steve > regards, suresh ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Sun Oct 17 14:18:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA06789; Sun, 17 Oct 1999 14:18:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13088 Sun, 17 Oct 1999 16:06:45 -0400 (EDT) Message-Id: <199910161629.MAA02248@pzero.sandelman.ottawa.on.ca> To: "Brian Swander (Exchange)" cc: ipsec@lists.tislabs.com Subject: Re: comments on the latest GSSAPI draft changes In-reply-to: Your message of "Fri, 15 Oct 1999 16:11:31 PDT." <19398D273324D3118A2B0008C7E9A56902751618@SIT.platinum.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 16 Oct 1999 12:27:55 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Exchange" == Exchange writes: Exchange> of course our numbers are protected by vendor ids. that doesn't mean we Exchange> don't care what those numbers are. we still want interop as Vendor IDs *do* mean that *I* don't care what numbers you use. If you have received a Vendor ID payload that you recognize, you now own the private use space, and you can assign any number you want. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Sun Oct 17 15:33:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA07490; Sun, 17 Oct 1999 15:33:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13217 Sun, 17 Oct 1999 17:16:36 -0400 (EDT) From: Dan McDonald Message-Id: <199910172118.OAA14917@kebe.Eng.Sun.COM> Subject: Outbound interface as a selector? To: ipsec@lists.tislabs.com Date: Sun, 17 Oct 1999 14:18:55 -0700 (PDT) X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Consider the case of IPv6 link-local multicast. Say I have two multicast SAs for dstaddr == ff02::2 (all-routers mcast). Let's say further that one SA is for one link, and the other SA is for the other link. Unless I hardcode SPIs into the user API (which is a BAD idea), I need to distinguish between the two SAs. The only way I can think of is to use the outgoing interface as a selector for outbound d-grams (and for that matter, inbound d-grams too). Off the top of your heads, do you see anything really broken about the idea of outbound interface as a selector? Dan From owner-ipsec@lists.tislabs.com Sun Oct 17 15:51:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA07610; Sun, 17 Oct 1999 15:51:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13284 Sun, 17 Oct 1999 17:44:52 -0400 (EDT) Message-Id: <199910172146.RAA08002@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Dan McDonald Cc: ipsec@lists.tislabs.com Subject: Re: Outbound interface as a selector? In-reply-to: Your message of "Sun, 17 Oct 1999 14:18:55 PDT." <199910172118.OAA14917@kebe.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Oct 1999 17:46:05 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <199910172118.OAA14917@kebe.Eng.Sun.COM>, Dan McDonald writes: > >Off the top of your heads, do you see anything really broken about the idea >of outbound interface as a selector? No; in fact, it's also necessary if you are going to do link encryption at the network layer (your example seemed a special case of this). I believe the architecture RFC does not prohibit this. The only negative side-effect is that, depending on the implementation specifics, you may end up doing one routing-table lookup more than you need; considering the cost of doing crypto, this is rather negligible. -Angelos From owner-ipsec@lists.tislabs.com Sun Oct 17 17:18:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA08377; Sun, 17 Oct 1999 17:18:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13405 Sun, 17 Oct 1999 18:58:37 -0400 (EDT) Date: Sun, 17 Oct 1999 19:00:08 -0400 (EDT) From: Henry Spencer To: Dan McDonald cc: ipsec@lists.tislabs.com Subject: Re: Outbound interface as a selector? In-Reply-To: <199910172118.OAA14917@kebe.Eng.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 17 Oct 1999, Dan McDonald wrote: > ...The only way I can think of is to use the outgoing interface as a > selector for outbound d-grams (and for that matter, inbound d-grams too). Note that RFC 2401 (etc.) says in about so many words that there is, at least conceptually, a separate SPD for each interface. That is, this functionality is already there, although not advertised exactly that way. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Mon Oct 18 11:29:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA01731; Mon, 18 Oct 1999 11:29:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15314 Mon, 18 Oct 1999 09:30:05 -0400 (EDT) Date: Mon, 18 Oct 1999 09:32:28 -0400 Message-Id: <199910181332.JAA07412@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rxg@openroute.com Cc: ipsec@lists.tislabs.com Subject: Re: Racing QM Initiator's References: <38051E0D.672C4058@openroute.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Radha" == Radha Gowda writes: >> To the list at large: >> >> Why can't we put verbiage like this into the RFC? Is there some >> reason this is a bad thing to do? Radha> I also would like to point out to the list that Diffie-Hellman Radha> calculation does not come cheap for some of us (atleast for Radha> now). I don't think it comes cheap for anyone. But so what? There's a small timing window that causes two SA pairs to be created rather than the normal one. Given that the window is small, the average amount of resources consumed by the existence of that window is tiny. As Will Price said, just deal with it. It's not a problem. It doesn't need additional protocol machinery to sort out. Additional protocol machinery means additional bugs for no significant benefit. paul From owner-ipsec@lists.tislabs.com Mon Oct 18 12:39:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA02890; Mon, 18 Oct 1999 12:39:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15472 Mon, 18 Oct 1999 10:24:07 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <19991017185851.7990.rocketmail@web1403.mail.yahoo.com> Date: Mon, 18 Oct 1999 10:16:37 -0400 To: Pyda Srisuresh From: Stephen Kent Subject: RE: Re[2]: PPP over IPSec (without L2TP)? Cc: aboba@internaut.com, ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pyda, >Ah, I see where you are coming from. Sure, RFC 2401 does allow using >user-IDs to describe SPD. That is necessary, but not a sufficient >condition to support user-ID authentication. IKE is the one that >does the acutal user-ID authentication and hence provides the >sufficiency for user-ID support. I don't think that we're signifgicantly disagreeing here. IPsec, as defined by the architecture document (RFC 2401) clearly mandates support for user level auth, because it makes no sense to base access control decisions on user IDs unless one authenticates users. The question, then, is how to accomoplish that. because IPsec does not mandate use of IKE, per se, 2401 can't go into more detail re how one accomplishes user level auth for IPsec. >Further, We are not just talking about being able to use user-ID for >authentication, but the actual method of authenticating the user-ID. >I believe, the confusion about user-ID authentication arises not >because IKE does not support user-ID auth, but because it does not >support asymmetric and legacy authentication methods. The method used is of importance, but it is not the defining facet of whether IPsec suppoprt user auth. I certainly DISAGREE with your last statement. Plain old IKE DOES support user auth, e.g., by associating private key material with a user. What is does not support is lagacy user auth mechanisms. >> I do agree that protocols such as XAUTH >> demonstrate a clear intent to authenticate users, not just machines, but >> IKE and 2401 make definite statements to that effect already. >> > >I believe, XAUTH and HYBRID-AUTH drafts (a) demonstrate the need for >asymmetric and legacy authentication methods, and (b) attempt to address >these in different ways as extensions to IKE. The XUATH and HYBRID-AUTH IDs demonstrate a clear desire by vendors to sell into environments that are reluctant to deploy PKIs. That is not quite the same as your statement above. Steve From owner-ipsec@lists.tislabs.com Mon Oct 18 12:41:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA02939; Mon, 18 Oct 1999 12:41:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15703 Mon, 18 Oct 1999 11:20:37 -0400 (EDT) Date: Mon, 18 Oct 1999 11:22:59 -0400 Message-Id: <199910181522.LAA08630@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ari.Huttunen@datafellows.com Cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (without L2TP)? References: <00fe01bf16a0$f4ff1740$478939cc@internaut.com> <38070829.4F7AC3CA@DataFellows.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ari" == Ari Huttunen writes: Ari> ... Ari> As to the re-ordering of packets by IPSec.. IPSec already does Ari> sequence numbers. It shouldn't be too difficult to define a new Ari> IPSec SA attribute negotiable by IKE that says "sequenced Ari> delivery of packets required". The recieving IPSec Ari> implementation would perhaps try to re-order packets during a Ari> few milliseconds or whatever, and drop packets that come after Ari> that. Yuck. Sure, it would be easy enough to add such an attribute, but adding the actual mechanism is quite another matter. Sequence protection doesn't belong in IP. It hasn't been there for 30 years, and it doesn't make sense to add it now. I very much doubt that you could get agreement to add such a thing as a mandatory capability (certainly I'd object loudly) or even as a recommended capability. paul From owner-ipsec@lists.tislabs.com Mon Oct 18 12:50:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03077; Mon, 18 Oct 1999 12:50:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15642 Mon, 18 Oct 1999 11:06:31 -0400 (EDT) From: Dan McDonald Message-Id: <199910181508.IAA00759@kebe.Eng.Sun.COM> Subject: Re: Outbound interface as a selector To: kent@bbn.com Date: Mon, 18 Oct 1999 08:08:26 -0700 (PDT) Cc: ipsec@lists.tislabs.com X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Forwarded message: From MAILER-DAEMON Mon Oct 18 08:07:29 1999 Delivery-Date: Mon, 18 Oct 1999 08:07:29 -0700 Date: Mon, 18 Oct 1999 08:07:28 -0700 (PDT) From: Mail Delivery Subsystem Message-Id: <199910181507.IAA00740@kebe.Eng.Sun.COM> To: danmcd@kebe.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="IAA00740.940259248/kebe.Eng.Sun.COM" Subject: Returned mail: User unknown Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --IAA00740.940259248/kebe.Eng.Sun.COM The original message was received at Mon, 18 Oct 1999 08:07:28 -0700 (PDT) from danmcd@localhost ----- The following addresses had permanent fatal errors ----- kent@bbn.com ipsec@lists.tislabs.com ----- Transcript of session follows ----- ... while talking to opal.eng.sun.com.: >>> RCPT To: <<< 550 5.7.1 ... Relaying denied. IP name possibly forged [2000::56:a00:20ff:fe8f:cf02] 550 ipsec@lists.tislabs.com... User unknown >>> RCPT To: <<< 550 5.7.1 ... Relaying denied. IP name possibly forged [2000::56:a00:20ff:fe8f:cf02] 550 kent@bbn.com... User unknown --IAA00740.940259248/kebe.Eng.Sun.COM Content-Type: message/delivery-status Reporting-MTA: dns; kebe.Eng.Sun.COM Arrival-Date: Mon, 18 Oct 1999 08:07:28 -0700 (PDT) Final-Recipient: RFC822; kent@bbn.com Action: failed Status: 5.1.1 Remote-MTA: DNS; opal.eng.sun.com Diagnostic-Code: SMTP; 550 5.7.1 ... Relaying denied. IP name possibly forged [2000::56:a00:20ff:fe8f:cf02] Last-Attempt-Date: Mon, 18 Oct 1999 08:07:28 -0700 (PDT) Final-Recipient: RFC822; ipsec@lists.tislabs.com Action: failed Status: 5.1.1 Remote-MTA: DNS; opal.eng.sun.com Diagnostic-Code: SMTP; 550 5.7.1 ... Relaying denied. IP name possibly forged [2000::56:a00:20ff:fe8f:cf02] Last-Attempt-Date: Mon, 18 Oct 1999 08:07:28 -0700 (PDT) --IAA00740.940259248/kebe.Eng.Sun.COM Content-Type: message/rfc822 Return-Path: Received: (from danmcd@localhost) by kebe.Eng.Sun.COM (8.9.3+Sun/8.9.1) id IAA00738; Mon, 18 Oct 1999 08:07:28 -0700 (PDT) From: Dan McDonald Message-Id: <199910181507.IAA00738@kebe.Eng.Sun.COM> Subject: Re: Outbound interface as a selector To: kent@bbn.com Date: Mon, 18 Oct 1999 08:07:27 -0700 (PDT) Cc: ipsec@lists.tislabs.com X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Absent the use of IPsec, how would a user have selected one interface > vs. another via the usual OS calls (or why would he care)? I can select an interface for multicast traffic using sockets today. IPv6's advanced API also has additional facilities for this. If I want to send a packet to ff02::1 or 224.0.0.1, I need to know which interface I'm sending it out. If I'm multihomed, I'd like to have two SAs for destination 224.0.0.1 or ff02::1, where each SA is for an individual link. Dan --IAA00740.940259248/kebe.Eng.Sun.COM-- From owner-ipsec@lists.tislabs.com Mon Oct 18 13:10:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA03415; Mon, 18 Oct 1999 13:10:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15872 Mon, 18 Oct 1999 11:59:51 -0400 (EDT) Message-ID: <380B44C1.F46C702F@DataFellows.com> Date: Mon, 18 Oct 1999 19:03:13 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (without L2TP)? References: <00fe01bf16a0$f4ff1740$478939cc@internaut.com> <38070829.4F7AC3CA@DataFellows.com> <199910181522.LAA08630@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > >>>>> "Ari" == Ari Huttunen writes: > > Ari> ... > Ari> As to the re-ordering of packets by IPSec.. IPSec already does > Ari> sequence numbers. It shouldn't be too difficult to define a new > Ari> IPSec SA attribute negotiable by IKE that says "sequenced > Ari> delivery of packets required". The recieving IPSec > Ari> implementation would perhaps try to re-order packets during a > Ari> few milliseconds or whatever, and drop packets that come after > Ari> that. > > Yuck. > > Sure, it would be easy enough to add such an attribute, but adding the > actual mechanism is quite another matter. > > Sequence protection doesn't belong in IP. It hasn't been there for 30 > years, and it doesn't make sense to add it now. I very much doubt > that you could get agreement to add such a thing as a mandatory > capability (certainly I'd object loudly) or even as a recommended > capability. Where's the beef? Using the same argumentation we'd never have, for example, speech on top of IP, since "for more than 30 years we've had speech on a telephone line.. etc." Besides, IP is connectionless while IPSec in all its forms is connection-oriented. (Not counting HIP.) -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Oct 18 14:13:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA04398; Mon, 18 Oct 1999 14:13:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16943 Mon, 18 Oct 1999 15:40:54 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199910172118.OAA14917@kebe.Eng.Sun.COM> Date: Mon, 18 Oct 1999 11:01:34 -0400 To: Dan McDonald From: Stephen Kent Subject: Re: Outbound interface as a selector? Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, >Consider the case of IPv6 link-local multicast. Say I have two multicast SAs >for dstaddr == ff02::2 (all-routers mcast). Let's say further that one SA is >for one link, and the other SA is for the other link. Unless I hardcode SPIs >into the user API (which is a BAD idea), I need to distinguish between the >two SAs. The only way I can think of is to use the outgoing interface as a >selector for outbound d-grams (and for that matter, inbound d-grams too). > >Off the top of your heads, do you see anything really broken about the idea >of outbound interface as a selector? I'm not sure I understand your example well enough to reply. Although there are per-interface SPDs, interfaces are NOT selectors. The reason being that they are not part of the addressing scheme visible at the IP interface. Absent the use of IPsec, how would a user have selected one interface vs. another via the usual OS calls (or why would he care)? Steve From owner-ipsec@lists.tislabs.com Tue Oct 19 05:03:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA24722; Tue, 19 Oct 1999 05:03:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20102 Tue, 19 Oct 1999 06:45:25 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE53B@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: ICMP message from SG to Host to say "Need access to TCP or UDP P rotocol or Port information" Date: Tue, 19 Oct 1999 11:47:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've just had a scan on Appendix D of the IPSEC architecture for help on generating an ICMP from a Security Gateway to a 'protected host' : Host1----SG1-----SG2----Host2 If Host1 sends packets to Host2 that are ipsec-blocked by SG1, what ICMP Name/Code could SG1 generate? What starting me thinking about this was the problem of Host1 generating ESP or IPCOMP packets that obscured the inner TCP/UDP details needed by SG1 to match on a policy, but I guess this is a generic problem of 'policy block'. Does "Destination Network Unreachable for Type of Service" cover it. Cheers, Steve. From owner-ipsec@lists.tislabs.com Tue Oct 19 05:03:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA24737; Tue, 19 Oct 1999 05:03:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20169 Tue, 19 Oct 1999 06:51:31 -0400 (EDT) Message-Id: <199910191053.GAA08623@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kelly-ipsra-userauth-00.txt Date: Tue, 19 Oct 1999 06:53:49 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : User-level Authentication Mechanisms for IPsec Author(s) : S. Kelly, J. Knowles, B. Aboba Filename : draft-kelly-ipsra-userauth-00.txt Pages : 15 Date : 18-Oct-99 IPsec, when used with IKE [RFC2409], provides for authentication of endpoints from the device level to the user level. However, there has been movement within the IPsec development community to provide additional support for legacy user-level authentication mechanisms such as those supported by RADIUS [RFC2138]. At least 2 approaches to this problem have been proposed thus far, both using the same basic underlying framework, but that underlying framework relies upon extending IKE in ways that may not be prudent. This document proposes an alternative approach which provides much of the same functionality without requiring any modification to the existing IPsec framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kelly-ipsra-userauth-00.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-kelly-ipsra-userauth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kelly-ipsra-userauth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018134815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kelly-ipsra-userauth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kelly-ipsra-userauth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018134815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Oct 19 05:04:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA24844; Tue, 19 Oct 1999 05:04:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20133 Tue, 19 Oct 1999 06:49:30 -0400 (EDT) Message-Id: <199910191051.GAA08342@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-02.txt Date: Tue, 19 Oct 1999 06:51:51 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : DHCP Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-02.txt Pages : 12 Date : 18-Oct-99 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration. This draft describes the requirements for host configuration in IPSEC tunnel mode and describes how the DHCP protocol may be used for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-02.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-ietf-ipsec-dhcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018121712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018121712.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Oct 19 05:04:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA24865; Tue, 19 Oct 1999 05:04:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20134 Tue, 19 Oct 1999 06:49:30 -0400 (EDT) Message-Id: <199910191051.GAA08328@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt Date: Tue, 19 Oct 1999 06:51:45 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A PKIX Profile for IKE Author(s) : R. Thayer, C. Kunzinger, P. Hoffman Filename : draft-ietf-ipsec-pki-req-03.txt Pages : 28 Date : 18-Oct-99 The IKE protocol allows the use of the PKIX profile of X.509v3 certificates for encryption and authentication. Common practice in the IPsec community differs in some ways from these specifications made in the PKIX format specification and other specifications that have come from the PKIX WG. In order to promote interoperability in the IPsec market, this document lays out a profile for using PKIX in IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-03.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-ietf-ipsec-pki-req-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-pki-req-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018121659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018121659.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Oct 19 05:08:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA25325; Tue, 19 Oct 1999 05:08:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20140 Tue, 19 Oct 1999 06:49:34 -0400 (EDT) Message-Id: <199910191051.GAA08356@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-doi-tc-mib-02.txt Date: Tue, 19 Oct 1999 06:51:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-ietf-ipsec-doi-tc-mib-02.txt Pages : 21 Date : 18-Oct-99 This memo defines textual conventions for use in monitoring, status, and configuration MIBs for IPSec. It includes a MIB module that defines those textual conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-02.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-ietf-ipsec-doi-tc-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018121723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doi-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018121723.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Oct 19 09:36:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA01896; Tue, 19 Oct 1999 09:36:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21306 Tue, 19 Oct 1999 10:53:33 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242C56@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'ipsec@lists.tislabs.com'" Subject: Query on draft-ietf-ipsec-pki-req-03.txt Date: Tue, 19 Oct 1999 07:55:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gents, The draft includes the following text in Section 2: IKE systems conforming to this profile MUST check the revocation statusof any certificate on which they rely, using the algorithm described inthe PKIX certificate profile. Thus, every conforming IKE system MUSThave a method for receiving up-to-date revocation information for thecertificates it is validating. What do you intend this to mean in the remote access case? One normal operational scenario will have the CRL distribution point the remote IPSec host needs to validate the security gateway's certificate behind the security gateway. In such a case, unless it has already obtained the CRL via an alternate channel, the remote host will be unable to meet the above requirement. Seemingly the best that it could be able to do is to establish IKE and IPSec security associations, then attempt to obtain the CRL, and then decide what to do on the basis of whether or not it could get the CRL or the security gateway's cert gets validated. Maybe we need to require implementations to send the latest CRL known to them during the IKE phase 1 negotiation? From owner-ipsec@lists.tislabs.com Tue Oct 19 09:40:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA01934; Tue, 19 Oct 1999 09:40:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21353 Tue, 19 Oct 1999 11:04:30 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242C57@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'ipsec@lists.tislabs.com'" Subject: Another query on draft-ietf-ipsec-pki-req-03.txt Date: Tue, 19 Oct 1999 08:06:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Section 3.2 says The subject field in IPsec certificates SHOULD be populated and non-null (this is contrary to the PKIX certificate profile, which says thatthe subject MUST NOT be populated if the identification is in thesubjectAltName field). The exact contents of this field are notstandardized. By convention, a minimal subject field containscountryName and commonName. Distinguished names SHOULD be no more thanfour attribute/value pairs, each of which SHOULD be no more than 128 characters in length (these restrictions do not appear in the PKIXcertificate profile). An IKE implementation that conforms to thisprofile SHOULD NOT reject a certificate that does not follow theserules. Why? The rationale for this requirement is not immediately obvious. From owner-ipsec@lists.tislabs.com Tue Oct 19 11:00:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA03119; Tue, 19 Oct 1999 11:00:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21736 Tue, 19 Oct 1999 12:31:27 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D71D@sothmxs06.entrust.com> From: Greg Carter To: "'Walker, Jesse'" , "'ipsec@lists.tislabs.com'" Subject: RE: Query on draft-ietf-ipsec-pki-req-03.txt Date: Tue, 19 Oct 1999 12:33:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jesse, Yes if you receive a certificate request with type CRL then you should send the CRL that your certificate would be put on were it to be revoked (follow? :) ). Many implementations are doing this. Of course this requires that at least one end of the negotiation has access to the CRL repository. Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Walker, Jesse [mailto:jesse.walker@intel.com] Sent: Tuesday, October 19, 1999 10:56 AM To: 'ipsec@lists.tislabs.com' Subject: Query on draft-ietf-ipsec-pki-req-03.txt or the security gateway's cert gets validated. Maybe we need to require implementations to send the latest CRL known to them during the IKE phase 1 negotiation? From owner-ipsec@lists.tislabs.com Tue Oct 19 11:10:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA03417; Tue, 19 Oct 1999 11:10:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21705 Tue, 19 Oct 1999 12:27:26 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D71C@sothmxs06.entrust.com> From: Greg Carter To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt Date: Tue, 19 Oct 1999 12:28:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a few comments on the draft, nothing shocking... >From 1. Introduction, first paragraph: "Note that many IPsec implementers are not completely happy with the PKIX documents and procedures, but have agreed to use the PKIX protocols because they are supported in other contexts and have a significant market share." and last paragraph "(It is noted that the fact that the two documents differ does not give great confidence to the IPsec community or other users of the PKIX protocols.)" Both of these, whether or not true, are opinions and don't really do anything to help implementers beside adding confusion. I would suggest they be taken out for clarity. >From section 3.1 The extendedKeyUsage field: "In a certificate for an IPsec end entity, the extendedKeyUsage field commonly called "EKU") MUST be present and MUST contain only the object identifier iKEIntermediate (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT accept end-entity certificates that do not follow this rule." Why must the certificate only have the one extended key usage? This is too restrictive. I like the idea of only having one IPSec extended key usage bit though. Could we stick with PKIX and say that if flagged critical then it must only have one value. Therefore you could remove the "and MUST contain only the object identifier iKEIntermediate..." since that would be covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage extensions. In Section 3.2 The subjectAltName field, last paragraph: "The subject field in IPsec certificates SHOULD be populated and non-null (this is contrary to the PKIX certificate profile, which says that the subject MUST NOT be populated if the identification is in the subjectAltName field)" This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name that: Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical. The important phase being "if the ONLY subject identity included in the certificate is an alternate name form". It does not say "If the alternate name form is used then NO subject distinguished name may be present." which is how I read section 3.2. For clarity I would stick with the PKIX definitions of how subject and alternate names are to be used and remove the last paragraph. If ONLY the alternate name is to be used then the subject should be left empty as PKIX states. However in practice I do not know of any implementations that only identify the 'device' by alternate name. For administration purposes they will always have a subject name, however there may exist a situation where someone would like to restrict to only using the alternate name for identification and the only way to do this is with an empty subject. Also in the last paragraph of section 3.2: "Distinguished names SHOULD be no more than four attribute/value pairs, each of which SHOULD be no more than 128 characters in length (these restrictions do not appear in the PKIX certificate profile)." Again these are too restrictive. Names in the subject/issuer are dictated by the customers directory setup (for those using one). In practice I have seen longer names than 4 attribute/value pairs. Length... well I don't know much about multi char character sets but I wouldn't want to limit anything which would prevent IPSec certificates being used in foreign languages. >From Appendix A: "Regardless of the protocol used, a CA who gets an IKE system's enrollment request that includes the subject and subjectAltName desired for the device MUST include exactly the same subject and subjectAltName in the certificate. If the CA does not want to issue a certificate with the same subject and subjectAltName that was requested, the CA MUST NOT issue a certificate with a different name and subjectAltName." This places an unnecessary burden on the end entity to determine what exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change the DN that is in the request. If the device must have the exact DN then it means a user somewhere has to type it in, very prone to failure. Also there is no mention of how to verify the request at the CA. The device should generate a hash of the der encoded request and make it available to the devices administrator for verification at the CA. Otherwise the request is accepted without verification. Also mention of how to obtain the CAs keys in a secure way, similarly usually done with a hash of the CAs der encoded certificate. May want to add this to the security section?... Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 19, 1999 6:52 AM To: IETF-Announce Cc: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A PKIX Profile for IKE Author(s) : R. Thayer, C. Kunzinger, P. Hoffman Filename : draft-ietf-ipsec-pki-req-03.txt Pages : 28 Date : 18-Oct-99 From owner-ipsec@lists.tislabs.com Tue Oct 19 11:34:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA03825; Tue, 19 Oct 1999 11:34:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21842 Tue, 19 Oct 1999 13:01:29 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D71F@sothmxs06.entrust.com> From: Greg Carter To: "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt Date: Tue, 19 Oct 1999 13:01:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a few comments on the draft, nothing shocking... >From 1. Introduction, first paragraph: "Note that many IPsec implementers are not completely happy with the PKIX documents and procedures, but have agreed to use the PKIX protocols because they are supported in other contexts and have a significant market share." and last paragraph "(It is noted that the fact that the two documents differ does not give great confidence to the IPsec community or other users of the PKIX protocols.)" Both of these, whether or not true, are opinions and don't really do anything to help implementers beside adding confusion. I would suggest they be taken out for clarity. >From section 3.1 The extendedKeyUsage field: "In a certificate for an IPsec end entity, the extendedKeyUsage field commonly called "EKU") MUST be present and MUST contain only the object identifier iKEIntermediate (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT accept end-entity certificates that do not follow this rule." Why must the certificate only have the one extended key usage? This is too restrictive. I like the idea of only having one IPSec extended key usage bit though. Could we stick with PKIX and say that if flagged critical then it must only have one value. Therefore you could remove the "and MUST contain only the object identifier iKEIntermediate..." since that would be covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage extensions. In Section 3.2 The subjectAltName field, last paragraph: "The subject field in IPsec certificates SHOULD be populated and non-null (this is contrary to the PKIX certificate profile, which says that the subject MUST NOT be populated if the identification is in the subjectAltName field)" This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name that: Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical. The important phase being "if the ONLY subject identity included in the certificate is an alternate name form". It does not say "If the alternate name form is used then NO subject distinguished name may be present." which is how I read section 3.2. For clarity I would stick with the PKIX definitions of how subject and alternate names are to be used and remove the last paragraph. If ONLY the alternate name is to be used then the subject should be left empty as PKIX states. However in practice I do not know of any implementations that only identify the 'device' by alternate name. For administration purposes they will always have a subject name, however there may exist a situation where someone would like to restrict to only using the alternate name for identification and the only way to do this is with an empty subject. Also in the last paragraph of section 3.2: "Distinguished names SHOULD be no more than four attribute/value pairs, each of which SHOULD be no more than 128 characters in length (these restrictions do not appear in the PKIX certificate profile)." Again these are too restrictive. Names in the subject/issuer are dictated by the customers directory setup (for those using one). In practice I have seen longer names than 4 attribute/value pairs. Length... well I don't know much about multi char character sets but I wouldn't want to limit anything which would prevent IPSec certificates being used in foreign languages. >From Appendix A: "Regardless of the protocol used, a CA who gets an IKE system's enrollment request that includes the subject and subjectAltName desired for the device MUST include exactly the same subject and subjectAltName in the certificate. If the CA does not want to issue a certificate with the same subject and subjectAltName that was requested, the CA MUST NOT issue a certificate with a different name and subjectAltName." This places an unnecessary burden on the end entity to determine what exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change the DN that is in the request. If the device must have the exact DN then it means a user somewhere has to type it in, very prone to failure. Also there is no mention of how to verify the request at the CA. The device should generate a hash of the der encoded request and make it available to the devices administrator for verification at the CA. Otherwise the request is accepted without verification. Also mention of how to obtain the CAs keys in a secure way, similarly usually done with a hash of the CAs der encoded certificate. May want to add this to the security section?... Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 19, 1999 6:52 AM To: IETF-Announce Cc: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A PKIX Profile for IKE Author(s) : R. Thayer, C. Kunzinger, P. Hoffman Filename : draft-ietf-ipsec-pki-req-03.txt Pages : 28 Date : 18-Oct-99 From owner-ipsec@lists.tislabs.com Tue Oct 19 11:34:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA03836; Tue, 19 Oct 1999 11:34:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21823 Tue, 19 Oct 1999 12:58:21 -0400 (EDT) Message-Id: <4.2.0.58.19991019130241.00a59f00@pop3.indusriver.com> X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 19 Oct 1999 13:05:14 -0400 To: Ari Huttunen From: David Chen Subject: Re: PPP over IPSec (without L2TP)? Cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <380C973C.FD1B3036@DataFellows.com> References: <4.2.0.58.19991019095359.00a905c0@pop3.indusriver.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_431373011==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_431373011==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:07 PM 10/19/99 +0300, you wrote: >David Chen wrote: > > > At 12:02 PM 10/14/99 +0300, you wrote: > > >Microsoft's position regarding L2TP is according to > > >http://www.microsoft.com/windows/server/Technical/networking/NWPriv.asp > > >(partly) the following: > > > > > >L2TP is a well-defined, interoperable protocol that addresses the current > > >shortcomings of IPSec-only client-to-gateway and gateway-to-gateway > > >scenarios (user authentication, tunnel IP address assignment, and > > >multiprotocol support). L2TP has broad vendor support, particularly among > > >the largest network access equipment providers, and has verified > > >interoperability. By placing L2TP as payload within an IPSec packet, > > >communications benefit from the standards-based encryption and > authenticity of > > >IPSec, while also receiving a highly interoperable way to accomplish user > > >authentication, tunnel address assignment, multiprotocol support, and > > >multicast support using PPP. This combination is commonly referred to as > > >L2TP/IPSec. Lacking a better pure IPSec standards solution, Microsoft > > >believes that L2TP/IPSec provides the best standards based solution for > > >multi-vendor, interoperable client-to-gateway VPN scenarios. Microsoft is > > >working closely with key networking vendors including Cisco, 3Com, > > >Lucent and IBM, to support this important combination. > > > > > >I agree that having PPP gives us the stated benefits (and more?). However, > > >I fail to see why there > > >is a need to have an L2TP (and UDP) layer(s) between PPP and IPSec. As I > > >understand > > >L2TP, it would give us two benefits a) being able to tunnel PPP over > > >several links, which > > >IPSec already gives us, and b) being able to specify telephone world > > >things like calling / > > >called numbers and call failures due to a busy tone, which in a general IP > > >world are non-relevant. > > > > > >I agree that a lot of Internet connectivity is through a telephone > > >network, but the calling numbers > > >should not be relied on for any sort of identification, despite what the > > >telephone world people > > >would like to convince people to believe. The only valid usage for > > >telephone numbers that > > >I see is call charging, but the ISPs are free to use L2TP for that purpose > > >without there being > > >any need for IPSec security gateways or IPSec hosts knowing or even caring > > >about it. > > > > > >So, please show me what benefits PPP over L2TP over IPSec provides when > > >compared > > >to just running PPP over IPSec? If there are some, which is possible, > > >wouldn't it be > > >better to enhance IPSec protocol(s) to enable the same, instead of having > > >L2TP? It is better, if IPSec has all PPP features. Why bother with L2TP? If you like to "enhance IPSec protocol(s)" --- David > > The last sentence is ???? > > If you like to improve IPSec, why bother L2TP? > > Just put all PPP features into IPSec. :-) > > This is not a good logic. > > --- David > >Pardon? I fail to parse that.. What do you mean? > >Ari > > > > > > > > >-- > > >Ari Huttunen phone: +358 9 859 900 > > >Senior Software Engineer fax : +358 9 8599 0452 > > > > > >Data Fellows Corporation http://www.DataFellows.com > > > > > >F-Secure products: Integrated Solutions for Enterprise Security > >-- >Ari Huttunen phone: +358 9 859 900 >Senior Software Engineer fax : +358 9 8599 0452 > >Data Fellows Corporation http://www.DataFellows.com > >F-Secure products: Integrated Solutions for Enterprise Security --=====================_431373011==_.ALT Content-Type: text/html; charset="us-ascii" At 07:07 PM 10/19/99 +0300, you wrote:


David Chen wrote:

> At 12:02 PM 10/14/99 +0300, you wrote:
> >Microsoft's position regarding L2TP is according to
> >http://www.microsoft.com/windows/server/Technical/networking/NWPriv.asp
> >(partly) the following:
> >
> >L2TP is a well-defined, interoperable protocol that addresses the current
> >shortcomings of IPSec-only client-to-gateway and gateway-to-gateway
> >scenarios (user authentication, tunnel IP address assignment, and
> >multiprotocol support). L2TP has broad vendor support, particularly among
> >the largest network access equipment providers, and has verified
> >interoperability. By placing L2TP as payload within an IPSec packet,
> >communications benefit from the standards-based encryption and authenticity of
> >IPSec, while also receiving a highly interoperable way to accomplish user
> >authentication, tunnel address assignment, multiprotocol support, and
> >multicast support using PPP. This combination is commonly referred to as
> >L2TP/IPSec. Lacking a better pure IPSec standards solution, Microsoft
> >believes that L2TP/IPSec provides the best standards based solution for
> >multi-vendor, interoperable client-to-gateway VPN scenarios. Microsoft is
> >working closely with key networking vendors including Cisco, 3Com,
> >Lucent and IBM, to support this important combination.
> >
> >I agree that having PPP gives us the stated benefits (and more?). However,
> >I fail to see why there
> >is a need to have an L2TP (and UDP) layer(s) between PPP and IPSec. As I
> >understand
> >L2TP, it would give us two benefits a) being able to tunnel PPP over
> >several links, which
> >IPSec already gives us, and b) being able to specify telephone world
> >things like calling /
> >called numbers and call failures due to a busy tone, which in a general IP
> >world are non-relevant.
> >
> >I agree that a lot of Internet connectivity is through a telephone
> >network, but the calling numbers
> >should not be relied on for any sort of identification, despite what the
> >telephone world people
> >would like to convince people to believe. The only valid usage for
> >telephone numbers that
> >I see is call charging, but the ISPs are free to use L2TP for that purpose
> >without there being
> >any need for IPSec security gateways or IPSec hosts knowing or even caring
> >about it.
> >
> >So, please show me what benefits PPP over L2TP over IPSec provides when
> >compared
> >to just running PPP over IPSec? If there are some, which is possible,
> >wouldn't it be
> >better to enhance IPSec protocol(s) to enable the same, instead of having
> >L2TP?

It is better, if IPSec has all PPP features.
Why bother with L2TP? If you like to "enhance IPSec protocol(s)"
--- David


> The last sentence is ????
> If you like to improve IPSec, why bother L2TP?
> Just put all PPP features into IPSec.  :-)
> This is not a good logic.
> --- David

Pardon? I fail to parse that.. What do you mean?

Ari


>
>
> >--
> >Ari Huttunen                   phone: +358 9 859 900
> >Senior Software Engineer       fax  : +358 9 8599 0452
> >
> >Data Fellows Corporation       http://www.DataFellows.com
> >
> >F-Secure products: Integrated Solutions for Enterprise Security

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security
--=====================_431373011==_.ALT-- From owner-ipsec@lists.tislabs.com Tue Oct 19 11:50:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA04209; Tue, 19 Oct 1999 11:50:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21968 Tue, 19 Oct 1999 13:15:03 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242C5A@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Greg Carter'" , "'ipsec@lists.tislabs.com'" Subject: RE: Query on draft-ietf-ipsec-pki-req-03.txt Date: Tue, 19 Oct 1999 10:17:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg, Yes, I know; a lot of implementations do forward CRLs as part of their negotiations. The question is whether this must be required. If the draft requires all implementations do certificate validation, then I don't see how conformance is possible unless the draft also requires implementations to pass CRLs. -- Jesse -----Original Message----- From: Greg Carter [mailto:greg.carter@entrust.com] Sent: Tuesday, October 19, 1999 9:33 AM To: 'Walker, Jesse'; 'ipsec@lists.tislabs.com' Subject: RE: Query on draft-ietf-ipsec-pki-req-03.txt Hi Jesse, Yes if you receive a certificate request with type CRL then you should send the CRL that your certificate would be put on were it to be revoked (follow? :) ). Many implementations are doing this. Of course this requires that at least one end of the negotiation has access to the CRL repository. Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Walker, Jesse [mailto:jesse.walker@intel.com] Sent: Tuesday, October 19, 1999 10:56 AM To: 'ipsec@lists.tislabs.com' Subject: Query on draft-ietf-ipsec-pki-req-03.txt or the security gateway's cert gets validated. Maybe we need to require implementations to send the latest CRL known to them during the IKE phase 1 negotiation? From owner-ipsec@lists.tislabs.com Tue Oct 19 16:09:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA10840; Tue, 19 Oct 1999 16:09:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23313 Tue, 19 Oct 1999 17:11:09 -0400 (EDT) From: "Bob Doud" To: Subject: Check this Date: Tue, 19 Oct 1999 17:08:18 -0400 Message-ID: <002101bf1a76$114ec020$2b3922c7@bdoud.ire-ma.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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Have fun with these links. Bye. From owner-ipsec@lists.tislabs.com Tue Oct 19 20:10:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA20732; Tue, 19 Oct 1999 20:10:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24223 Tue, 19 Oct 1999 21:48:27 -0400 (EDT) Date: Tue, 19 Oct 1999 21:50:53 -0400 Message-Id: <199910200150.VAA14041@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@lists.tislabs.com Subject: Call for Agenda Items Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Washington IETF is rapidly upon us (the I-D submission deadline is this Friday!), so please send me e-mail for any agenda item that you'd like time for our IPSEC wg meeting. I've requested one full slot from the secretariat; I haven't gotten a time assigned yet. Thanks!! - Ted From owner-ipsec@lists.tislabs.com Wed Oct 20 04:05:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA07408; Wed, 20 Oct 1999 04:05:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25327 Wed, 20 Oct 1999 05:23:24 -0400 (EDT) Message-ID: <380D8ADE.617FAF60@DataFellows.com> Date: Wed, 20 Oct 1999 12:26:54 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: David Chen CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (without L2TP)? References: <4.2.0.58.19991019095359.00a905c0@pop3.indusriver.com> <4.2.0.58.19991019130241.00a59f00@pop3.indusriver.com> Content-Type: multipart/alternative; boundary="------------62C872C8B54C5BB4355761EF" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------62C872C8B54C5BB4355761EF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Chen wrote: >> >> > >So, please show me what benefits PPP over L2TP over IPSec provides when >> > >compared >> > >to just running PPP over IPSec? If there are some, which is possible, >> > >wouldn't it be >> > >better to enhance IPSec protocol(s) to enable the same, instead of having >> > >L2TP? > > > It is better, if IPSec has all PPP features. > Why bother with L2TP? If you like to "enhance IPSec protocol(s)" > --- David I don't "like to enhance IPSec protocol(s)". Instead I would "like to solve real world problems with the least possible effort". In my view L2TP is wasted effort, if the only purpose of using it is to get PPP on top of IPSec. For other purposes it's fine. BTW, I don't particularly like my private emails to be forwarded to 'official' mailing lists without my permission.. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security --------------62C872C8B54C5BB4355761EF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit David Chen wrote:
 
> >So, please show me what benefits PPP over L2TP over IPSec provides when
> >compared
> >to just running PPP over IPSec? If there are some, which is possible,
> >wouldn't it be
> >better to enhance IPSec protocol(s) to enable the same, instead of having
> >L2TP?


It is better, if IPSec has all PPP features.
Why bother with L2TP? If you like to "enhance IPSec protocol(s)"
--- David

I don't "like to enhance IPSec protocol(s)". Instead I would
"like to solve real world problems with the least possible effort".
In my view L2TP is wasted effort, if the only purpose of using
it is to get PPP on top of IPSec. For other purposes it's fine.

BTW, I don't particularly like my private emails to be forwarded
to 'official' mailing lists without my permission..

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security
  --------------62C872C8B54C5BB4355761EF-- From owner-ipsec@lists.tislabs.com Wed Oct 20 05:15:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA08144; Wed, 20 Oct 1999 05:15:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25590 Wed, 20 Oct 1999 06:53:37 -0400 (EDT) Message-Id: <199910201056.GAA24086@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com, ietf-cat-wg@lists.stanford.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-04.txt Date: Wed, 20 Oct 1999 06:56:01 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A GSS-API Authentication Method for IKE Author(s) : D. Piper Filename : draft-ietf-ipsec-isakmp-gss-auth-04.txt Pages : 11 Date : 19-Oct-99 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. For a list of changes since the previous version of this document, please see Section 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-04.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-ietf-ipsec-isakmp-gss-auth-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019135748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019135748.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 20 05:15:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA08152; Wed, 20 Oct 1999 05:15:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25602 Wed, 20 Oct 1999 06:53:50 -0400 (EDT) Message-Id: <199910201056.GAA24120@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-03.txt Date: Wed, 20 Oct 1999 06:56:15 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : DHCP Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-03.txt Pages : 13 Date : 19-Oct-99 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via Ipsec from the host's ISP-assigned address to the corporate security gateway. The Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSEC tunnel mode, and describes how the DHCP protocol may be leveraged for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-03.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-ietf-ipsec-dhcp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019135812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019135812.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 20 05:19:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA08195; Wed, 20 Oct 1999 05:19:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25583 Wed, 20 Oct 1999 06:53:05 -0400 (EDT) Message-Id: <199910201055.GAA24016@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-doi-tc-mib-02.txt Date: Wed, 20 Oct 1999 06:55:25 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-ietf-ipsec-doi-tc-mib-02.txt Pages : 21 Date : 18-Oct-99 This memo defines textual conventions for use in monitoring, status, and configuration MIBs for IPSec. It includes a MIB module that defines those textual conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-02.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-ietf-ipsec-doi-tc-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018121723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doi-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018121723.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 20 05:20:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA08212; Wed, 20 Oct 1999 05:20:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25608 Wed, 20 Oct 1999 06:53:57 -0400 (EDT) Message-Id: <199910201056.GAA24134@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ecn-01.txt Date: Wed, 20 Oct 1999 06:56:21 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec Interactions with ECN Author(s) : S. Floyd, D. Black, K. Ramakrishnan Filename : draft-ietf-ipsec-ecn-01.txt Pages : 24 Date : 19-Oct-99 IPsec supports secure communication over potentially insecure network components such as intermediate routers. IPsec protocols support two operating modes, transport mode and tunnel mode. Explicit Congestion Notification (ECN) is an experimental addition to the IP architecture that provides notification of onset of congestion to delay- or loss- sensitive applications. ECN provides congestion notifications to enable adaptation to network conditions without the impact of dropped packets [RFC 2481]. The use of two bits in the IPsec header for ECN experimentation conflicts with header processing at IPsec tunnel endpoints in a manner that makes ECN unusable in the presence of IPsec tunnels. This document considers issues related to this conflict, describes two alternative solutions, and updates the IPsec architecture [RFC 2401] to include these alternatives. Support for one or the other of these alternatives is REQUIRED to remove the underlying conflict. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ecn-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-ietf-ipsec-ecn-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ecn-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019135823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ecn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ecn-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019135823.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 20 05:25:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA08278; Wed, 20 Oct 1999 05:25:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25596 Wed, 20 Oct 1999 06:53:44 -0400 (EDT) Message-Id: <199910201056.GAA24100@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-notifymsg-01.txt Date: Wed, 20 Oct 1999 06:56:08 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Content Requirements for ISAKMP Notify Messages Author(s) : S. Kelly, T. Kivinen Filename : draft-ietf-ipsec-notifymsg-01.txt Pages : 26 Date : 19-Oct-99 The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In these cases, it is difficult to determine which SA corresponds to the received NOTIFY message. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no such requirements are currently specified for ISAKMP NOTIFY messages. This document provides content and format recommendations for those messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-notifymsg-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-ietf-ipsec-notifymsg-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-notifymsg-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019135800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-notifymsg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-notifymsg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019135800.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 20 11:58:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA16126; Wed, 20 Oct 1999 11:58:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28413 Wed, 20 Oct 1999 13:06:21 -0400 (EDT) Message-Id: <4.2.0.58.19991020130425.00a8d290@pop3.indusriver.com> X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 20 Oct 1999 13:12:33 -0400 To: Ari Huttunen From: David Chen Subject: Re: PPP over IPSec (without L2TP)? Cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <38059C2D.F56BA62A@DataFellows.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_71818850==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_71818850==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Mr. Huttunen, Your wrote with following header and content (after the "===" mark): The question I have is in your last sentence. " If there are some, which is possible, wouldn't it be better to enhance IPSec protocol(s) to enable the same, instead of having L2TP?" Does it sound like you want to "enhance IPSec protocol"? Regards, --- David BTW. I cc to the same cc you did. =========================================================== Date: Thu, 14 Oct 1999 12:02:37 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: PPP over IPSec (without L2TP)? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12:02 PM 10/14/99 +0300, you wrote: >Microsoft's position regarding L2TP is according to >http://www.microsoft.com/windows/server/Technical/networking/NWPriv.asp >(partly) the following: > >L2TP is a well-defined, interoperable protocol that addresses the current >shortcomings of IPSec-only client-to-gateway and gateway-to-gateway >scenarios (user authentication, tunnel IP address assignment, and >multiprotocol support). L2TP has broad vendor support, particularly among >the largest network access equipment providers, and has verified >interoperability. By placing L2TP as payload within an IPSec packet, >communications benefit from the standards-based encryption and authenticity of >IPSec, while also receiving a highly interoperable way to accomplish user >authentication, tunnel address assignment, multiprotocol support, and >multicast support using PPP. This combination is commonly referred to as >L2TP/IPSec. Lacking a better pure IPSec standards solution, Microsoft >believes that L2TP/IPSec provides the best standards based solution for >multi-vendor, interoperable client-to-gateway VPN scenarios. Microsoft is >working closely with key networking vendors including Cisco, 3Com, >Lucent and IBM, to support this important combination. > >I agree that having PPP gives us the stated benefits (and more?). However, >I fail to see why there >is a need to have an L2TP (and UDP) layer(s) between PPP and IPSec. As I >understand >L2TP, it would give us two benefits a) being able to tunnel PPP over >several links, which >IPSec already gives us, and b) being able to specify telephone world >things like calling / >called numbers and call failures due to a busy tone, which in a general IP >world are non-relevant. > >I agree that a lot of Internet connectivity is through a telephone >network, but the calling numbers >should not be relied on for any sort of identification, despite what the >telephone world people >would like to convince people to believe. The only valid usage for >telephone numbers that >I see is call charging, but the ISPs are free to use L2TP for that purpose >without there being >any need for IPSec security gateways or IPSec hosts knowing or even caring >about it. > >So, please show me what benefits PPP over L2TP over IPSec provides when >compared >to just running PPP over IPSec? If there are some, which is possible, >wouldn't it be >better to enhance IPSec protocol(s) to enable the same, instead of having >L2TP? > >-- >Ari Huttunen phone: +358 9 859 900 >Senior Software Engineer fax : +358 9 8599 0452 > >Data Fellows Corporation http://www.DataFellows.com > >F-Secure products: Integrated Solutions for Enterprise Security --=====================_71818850==_.ALT Content-Type: text/html; charset="us-ascii" Mr. Huttunen,
Your wrote with following header and content (after the "===" mark):

The question I have is in your last sentence.
" If there are some, which is possible, wouldn't it be
better to enhance IPSec protocol(s) to enable the same, instead of having L2TP?"

Does it sound like you want to "enhance IPSec protocol"?

Regards,

--- David

BTW.  I cc to the same cc you did.

===========================================================

Date: Thu, 14 Oct 1999 12:02:37 +0300
From: Ari Huttunen <Ari.Huttunen@DataFellows.com>
Organization: Data Fellows Oyj
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com
Subject: PPP over IPSec (without L2TP)?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

At 12:02 PM 10/14/99 +0300, you wrote:

Microsoft's position regarding L2TP is according to http://www.microsoft.com/windows/server/Technical/networking/NWPriv.asp
(partly) the following:

L2TP is a well-defined, interoperable protocol that addresses the current shortcomings of IPSec-only client-to-gateway and gateway-to-gateway scenarios (user authentication, tunnel IP address assignment, and multiprotocol support). L2TP has broad vendor support, particularly among the largest network access equipment providers, and has verified interoperability. By placing L2TP as payload within an IPSec packet, communications benefit from the standards-based encryption and authenticity of
IPSec, while also receiving a highly interoperable way to accomplish user authentication, tunnel address assignment, multiprotocol support, and multicast support using PPP. This combination is commonly referred to as L2TP/IPSec. Lacking a better pure IPSec standards solution, Microsoft believes that L2TP/IPSec provides the best standards based solution for multi-vendor, interoperable client-to-gateway VPN scenarios. Microsoft is working closely with key networking vendors including Cisco, 3Com,
Lucent and IBM, to support this important combination.

I agree that having PPP gives us the stated benefits (and more?). However, I fail to see why there
is a need to have an L2TP (and UDP) layer(s) between PPP and IPSec. As I understand
L2TP, it would give us two benefits a) being able to tunnel PPP over several links, which
IPSec already gives us, and b) being able to specify telephone world things like calling /
called numbers and call failures due to a busy tone, which in a general IP world are non-relevant.

I agree that a lot of Internet connectivity is through a telephone network, but the calling numbers
should not be relied on for any sort of identification, despite what the telephone world people
would like to convince people to believe. The only valid usage for telephone numbers that
I see is call charging, but the ISPs are free to use L2TP for that purpose without there being
any need for IPSec security gateways or IPSec hosts knowing or even caring about it.

So, please show me what benefits PPP over L2TP over IPSec provides when compared
to just running PPP over IPSec? If there are some, which is possible, wouldn't it be
better to enhance IPSec protocol(s) to enable the same, instead of having L2TP?

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security

--=====================_71818850==_.ALT-- From owner-ipsec@lists.tislabs.com Wed Oct 20 14:24:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA18110; Wed, 20 Oct 1999 14:24:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28987 Wed, 20 Oct 1999 15:34:08 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE53B@new-exc1.ctron.com> Date: Wed, 20 Oct 1999 13:17:50 -0400 To: "Waters, Stephen" From: Stephen Kent Subject: Re: ICMP message from SG to Host to say "Need access to TCP or UDP P rotocol or Port information" Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, If the reason for dropping a packet is an access control violation, the preferred ICMP is Dest Unreach- Administratively Prohibited. Steve From owner-ipsec@lists.tislabs.com Thu Oct 21 11:12:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA06622; Thu, 21 Oct 1999 11:12:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03178 Thu, 21 Oct 1999 12:18:18 -0400 (EDT) Message-Id: <199910211619.JAA15266@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com cc: ietf-ipsra@vpnc.org Subject: CRACK MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15263.940522748.1@network-alchemy.com> Date: Thu, 21 Oct 1999 09:19:08 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few weeks ago I was alluding to a draft which would address the desire to do token card authentication in IKE (and do it securely). The draft is out but is an individual I-D submission due to the fact that remote access is going to be the responsibility of IPSRA which does not yet formally exist. Please check it out and comment. It's called draft-harkins-ipsec-ike-crack-00.txt and can be found with the others at http://www.ietf.cnri.reston.va.us/internet-drafts. Dan. From owner-ipsec@lists.tislabs.com Thu Oct 21 11:32:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA07091; Thu, 21 Oct 1999 11:31:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03428 Thu, 21 Oct 1999 12:49:26 -0400 (EDT) Message-ID: <380F44DE.56933F55@nortelnetworks.com> Date: Thu, 21 Oct 1999 12:52:46 -0400 From: Peadar Harmon X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: determining the initialization vector in CBC mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, RFC2409 states: In phase 1, material for the initialization vector (IV material) for CBC mode encryption algorithms is derived from a hash of a concatenation of the initiator's public Diffie-Hellman value and the responder's public Diffie-Hellman value using the negotiated hash algorithm. This is used for the first message only. Do I assume SKEYID_e is the key for the hash alforithmi.e. IV = prf(SKEYID_e, g^xi | g^xr) Any input would be appreciated. Thanks, Peadar Harmon From owner-ipsec@lists.tislabs.com Thu Oct 21 13:06:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA08343; Thu, 21 Oct 1999 13:06:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03836 Thu, 21 Oct 1999 14:34:55 -0400 (EDT) Message-Id: <199910211835.LAA15650@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: Re: CRACK In-reply-to: Your message of "Thu, 21 Oct 1999 10:58:00 PDT." <199910211758.KAA15502@potassium.network-alchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15647.940530946.1@network-alchemy.com> Date: Thu, 21 Oct 1999 11:35:47 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Double-oops. I fat-fingered the reply to the IPSec list.... Dan. On Thu, 21 Oct 1999 10:58:00 PDT you wrote > Oops. You have to put a "/" after that url. That or just append a "/" > and the draft name. That should do it. It's out there, really. :-) > > Dan. > > On Thu, 21 Oct 1999 10:14:28 PDT you wrote > > Is there a time delay between submitting the draft and when it will appear > > on ietf web site? I tried to follow the link - also did a search > > on ietf website, but could not find the draft. > > > > Any pointers to where I can get a copy? > > > > Thanks, > > -- sankar -- > > > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > > Sent: Thursday, October 21, 1999 9:19 AM > > To: ipsec@lists.tislabs.com > > Cc: ietf-ipsra@vpnc.org > > Subject: CRACK > > > > > > A few weeks ago I was alluding to a draft which would address the > > desire to do token card authentication in IKE (and do it securely). > > The draft is out but is an individual I-D submission due to the fact > > that remote access is going to be the responsibility of IPSRA which > > does not yet formally exist. Please check it out and comment. It's > > called draft-harkins-ipsec-ike-crack-00.txt and can be found with the > > others at http://www.ietf.cnri.reston.va.us/internet-drafts. > > > > Dan. > > From owner-ipsec@lists.tislabs.com Thu Oct 21 13:28:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA08819; Thu, 21 Oct 1999 13:28:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03920 Thu, 21 Oct 1999 15:02:08 -0400 (EDT) From: obennis@motus.qc.ca X-Lotus-FromDomain: MOTUS TECHNOLOGIES INC. To: Peadar Harmon cc: ipsec@lists.tislabs.com Message-ID: <85256811.00692408.00@mail.motus.qc.ca> Date: Thu, 21 Oct 1999 15:08:03 -0400 Subject: Re: determining the initialization vector in CBC mode Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In order to compute the IV, you don't need a HMAC hash function like HMAC-MD5 but a Hash function like MD5, SHA or Tiger as illustrarted in the RFC- 2409 page 33. A Hash function doesn't use a key to compute a Hash value. The HMAC functions do need a key to compute a specific hash wich can be used for integrity check and authentication. So IV = prf( g^xi | g^xr) and prf is MD5, SHA-1 or Tiger Omar Bennis Motus Technologies Inc From owner-ipsec@lists.tislabs.com Thu Oct 21 13:41:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA09119; Thu, 21 Oct 1999 13:41:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03976 Thu, 21 Oct 1999 15:17:37 -0400 (EDT) Message-ID: From: "Linn, John" To: "'Greg Carter'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt Date: Thu, 21 Oct 1999 15:13:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg wrote, excerpting: > > From section 3.1 The extendedKeyUsage field: > > "In a certificate for an IPsec end entity, the extendedKeyUsage field > commonly called "EKU") MUST be present and MUST contain only > the object > identifier iKEIntermediate > (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or > 1.3.6.1.5.5.8.2.2). An IKE system that conforms to this > profile SHOULD NOT > accept end-entity certificates that do not follow this rule." > > Why must the certificate only have the one extended key > usage? This is too > restrictive. I strongly agree, in the interests of avoiding unnecessary proliferation of per-application certificates. Is there a compelling reason which warrants erecting a barrier so that certificates which are to be usable for IPsec purposes must not be used by other applications, at least if those other applications also employ EKUs? I like the idea of only having one IPSec > extended key usage > bit though. Could we stick with PKIX and say that if flagged > critical then > it must only have one value. Therefore you could remove the "and MUST > contain only the object identifier iKEIntermediate..." since > that would be > covered by PKIX RFC 2459 section 4.2.1.13 for critical > extended key usage > extensions. I'm not sure I follow this. RFC-2459, 4.2.1.13, states re EKU that: "If the extension is flagged critical, then the certificate MUST be used only for one of the purposes indicated." This doesn't preclude coexistence of IPsec's iKEIntermediate OID as one value in a critical EKU along with other OIDs belonging to other applications. --jl From owner-ipsec@lists.tislabs.com Thu Oct 21 14:40:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA10040; Thu, 21 Oct 1999 14:40:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04106 Thu, 21 Oct 1999 15:59:44 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D745@sothmxs06.entrust.com> From: Greg Carter To: "'Linn, John'" , Greg Carter , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt Date: Thu, 21 Oct 1999 15:59:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi John, You are right, it can still have multiple values even if critical, sorry for the confusion. Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Linn, John [mailto:jlinn@rsasecurity.com] Sent: Thursday, October 21, 1999 3:13 PM To: 'Greg Carter'; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt Greg wrote, excerpting: > it must only have one value. Therefore you could remove the "and MUST > contain only the object identifier iKEIntermediate..." since > that would be > covered by PKIX RFC 2459 section 4.2.1.13 for critical > extended key usage > extensions. I'm not sure I follow this. RFC-2459, 4.2.1.13, states re EKU that: "If the extension is flagged critical, then the certificate MUST be used only for one of the purposes indicated." This doesn't preclude coexistence of IPsec's iKEIntermediate OID as one value in a critical EKU along with other OIDs belonging to other applications. From owner-ipsec@lists.tislabs.com Thu Oct 21 15:29:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA10644; Thu, 21 Oct 1999 15:29:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04462 Thu, 21 Oct 1999 17:03:02 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE570@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: CRACK Date: Thu, 21 Oct 1999 22:02:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Looks good. Where did CRACK come from? A dubious name in a security protocol. Can the client's private/public key be unique for each connection? For the case where the legacy authentication is something a typical client could deal with (password or chap-thing), should this support symmetric trust of the public keys used - e.g. the client trusts the gateway based on the client holding legacy authentication information for the server? Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Thursday, October 21, 1999 7:36 PM To: ipsec@lists.tislabs.com Subject: Re: CRACK Double-oops. I fat-fingered the reply to the IPSec list.... Dan. On Thu, 21 Oct 1999 10:58:00 PDT you wrote > Oops. You have to put a "/" after that url. That or just append a "/" > and the draft name. That should do it. It's out there, really. :-) > > Dan. > > On Thu, 21 Oct 1999 10:14:28 PDT you wrote > > Is there a time delay between submitting the draft and when it will appear > > on ietf web site? I tried to follow the link - also did a search > > on ietf website, but could not find the draft. > > > > Any pointers to where I can get a copy? > > > > Thanks, > > -- sankar -- > > > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > > Sent: Thursday, October 21, 1999 9:19 AM > > To: ipsec@lists.tislabs.com > > Cc: ietf-ipsra@vpnc.org > > Subject: CRACK > > > > > > A few weeks ago I was alluding to a draft which would address the > > desire to do token card authentication in IKE (and do it securely). > > The draft is out but is an individual I-D submission due to the fact > > that remote access is going to be the responsibility of IPSRA which > > does not yet formally exist. Please check it out and comment. It's > > called draft-harkins-ipsec-ike-crack-00.txt and can be found with the > > others at http://www.ietf.cnri.reston.va.us/internet-drafts. > > > > Dan. > > From owner-ipsec@lists.tislabs.com Thu Oct 21 17:40:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA12099; Thu, 21 Oct 1999 17:40:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04905 Thu, 21 Oct 1999 19:19:15 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEC8E1B@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: Shared Secret mismatch in AM3/MM5 Date: Thu, 21 Oct 1999 19:23:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question for anyone on the list who may know/care: When two peers are negotiationg a phase 1 SA in shared secret mode, a disagreement in the shared secret will result in a decryption failure in the first encrypted message -- MM5 or AM3 (which we choose to encrypt). The decryption failure usually results in one of the following errors: Invalid Payload Type, Invalid Id Info, or Payload Malformed. Of course, a sophisticated implementation can infer that the decryption failure was the result of a shared secret mismatch and report this to the user... But it makes troubleshooting difficult. It is hard to distinguish between a deliberate attack, a user mistyping his password, and a misbehaving implementation. So I was wondering about the underlying reasons why we get this error. There seems to be two causes: 1) SKEYID_e is derived from the shared secret. 2) The HASH_I payload comes at the end of the message (after the Id). So what is the importance of these two design constraints? Why do we base the encryption key on secret data (other than g^xy) in shared mode, but not in cert mode; and why do we put the hash at the end of the message in phase 1 but not in phase 2? My guess is that SKEYID_e is derived from the shared secret because: a) it increases the entropy of SKEYID and, in particular, the amount of entropy which could not be guessed by an attacker. b) it protects against a MitM attack. However: a) the cert mode SKEYID doesn't have any unguessable entropy except g^xy (so presumably this would be sufficient for shared mode as well). b) HASH_I provides adequate protection against a MitM attack (or else the encryption of AM3 would not be optional). My guess is that the HASH_I payload comes at the end of the message because: a) when not encrypting AM3, the shared key could depend on the id (so id then hash represents the logical order of processing). b) the hash contains the id, so to verify the hash you need to have already parsed the id (so id then hash represents the logical order of processing). However: a) there is no absolute requirement that the order of payloads in the message be the same as the order in which they are processed. b) if the hash came at the beginning of the message, an implementation could always return the same error if decryption failed (choosing either Invalid Hash Info or Authentication Failed). In fact, [IKE] states that in quick mode, the hash MUST immediately follow the header, presumably for exactly this reason. If anyone can find fault with my arguments, or if they know of other reasons why these constraints have to exist, I would like to hear about it. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Oct 21 18:11:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA14186; Thu, 21 Oct 1999 18:11:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04963 Thu, 21 Oct 1999 19:55:09 -0400 (EDT) From: Dan McDonald Message-Id: <199910212357.QAA05526@kebe.Eng.Sun.COM> Subject: Outbound interface as a selector (revisited) To: ipsec@lists.tislabs.com Date: Thu, 21 Oct 1999 16:57:30 -0700 (PDT) X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I want to clarify what I'm seeking with an example. Consider two multicast SAs (I'm using IPv6 as an example, substitute 224.0.0.1 if you're a real IPv6-hater) on a multi-homed host or a router: SPI = 0xdeadbeeef dst = ff02::1 authalg = MD5 authkey = | qfe2 +---+----+ | Router | +---+----+ | qfe1 SPI = 0xfeedface dst = ff02::1 authalg = MD5 authkey = Now let's say that 0xfeedface is for one of the routers interfaces (call it qfe1), and that 0xdeadbeef is for another router's interface (call it qfe2). I have no real way of knowing that unless I can select the appropriate SA based on the interface. Likewise, on inbound packets, I should only accept ff02::1 packets from the 0xdeadbeef SA iff it arrives on interface qfe2. I'd like to have something indicating a LINK ID for SA selection. And I say LINK ID instead of interface ID, because I may have a fault-tolerant implementation such that... qfe2 | | qfe3 +----+-+-+ | Router | +----+-+-+ qfe0 | | qfe1 where qfe0-1 are on the same physical link, and qfe2-3 are also on the same physical link. Dan p.s. This is prelude to something else I'll be mailing to this list and the IPng list. From owner-ipsec@lists.tislabs.com Fri Oct 22 00:27:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA02380; Fri, 22 Oct 1999 00:27:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA05759 Fri, 22 Oct 1999 02:06:52 -0400 (EDT) From: Dan McDonald Message-Id: <199910220609.XAA05952@kebe.Eng.Sun.COM> Subject: ICMP{,v6} type/code as a selector... To: ipsec@lists.tislabs.com Date: Thu, 21 Oct 1999 23:09:18 -0700 (PDT) X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While not listed in 2401 explicitly, couldn't one use ICMP/ICMPv6 type and code as a selector for a security association? The implementation wouldn't be that tough; just overload the already-there port fields for type and code. Thanks again, Dan From owner-ipsec@lists.tislabs.com Fri Oct 22 01:50:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA05345; Fri, 22 Oct 1999 01:50:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06030 Fri, 22 Oct 1999 03:32:14 -0400 (EDT) Date: Fri, 22 Oct 1999 10:34:40 +0300 (EET DST) From: Markku Savela Message-Id: <199910220734.KAA12308@anise.tte.vtt.fi> To: danmcd@Eng.Sun.Com CC: ipsec@lists.tislabs.com In-reply-to: <199910220609.XAA05952@kebe.Eng.Sun.COM> (message from Dan McDonald on Thu, 21 Oct 1999 23:09:18 -0700 (PDT)) Subject: Re: ICMP{,v6} type/code as a selector... Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > While not listed in 2401 explicitly, couldn't one use ICMP/ICMPv6 type and > code as a selector for a security association? The implementation wouldn't > be that tough; just overload the already-there port fields for type and code. I've had this extension implemented, although I didn't overload the port fields, but wasted separate fields for them. However, if we want to pass this through PFKEY without changing the structures, using the port field seems ok. There is a problem: 0 port is used "any/not-specified" in various contexts. However, Type=0 and Code=0 appear as legal values. Could also pack the type and code into single value as destination port (I think there are some logical grounds not to split the type/code into source and destination port). Even after packing, there would be type=0,code=0 situation. A while back I wondered about what to do with ICMP's generated from upper layer for packets that have been decrypted by IPSEC. I've a feeling, that it makes no sense in specifying some selector based on ICMP error reply type/code to get the error message encrypted. Instead, it might be more sensible to choose the IPSEC bundle that applies for the ICMP errors based on the selector information of the returned packet. Advantage - the return error gets IPSECed with same rules that would apply to the matching normal return traffic Of course, this applies more naturally to IPv6 and ICMPv6, and additionally I only look at the situation from HOST-HOST viewpoint. ICMP specific selectors would be sesible for Type > 127 (non-error messages). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Fri Oct 22 05:26:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA28997; Fri, 22 Oct 1999 05:26:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA06410 Fri, 22 Oct 1999 06:54:34 -0400 (EDT) Message-Id: <199910221057.GAA05914@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-keromytis-ipsp-arch-00.txt Date: Fri, 22 Oct 1999 06:57:02 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPsec Policy Discovery Architecture Author(s) : A. Keromytis, M. Richardson, L. Sanchez Filename : draft-keromytis-ipsp-arch-00.txt Pages : 7 Date : 21-Oct-99 This document describes an IP Security Policy architecture that conforms to the requirements set forth in [IPSP-REQ]. The architecture defines the mechanisms and protocols needed for discovering, accessing, and processing security policy information of varying granularity. The architecture accommodates topology and policy changes without need of manual reconfiguration of clients and security gateways. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-keromytis-ipsp-arch-00.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-keromytis-ipsp-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-keromytis-ipsp-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991021142619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-keromytis-ipsp-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-keromytis-ipsp-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142619.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Oct 22 07:29:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA08543; Fri, 22 Oct 1999 07:29:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06767 Fri, 22 Oct 1999 08:50:10 -0400 (EDT) Message-Id: <199910221252.QAA05159@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Dan Harkins Date: Fri, 22 Oct 1999 16:51:58 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: CRACK CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com In-reply-to: <199910211619.JAA15266@potassium.network-alchemy.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 21 Oct 99, at 9:19, Dan Harkins wrote: Dan, some comments/questions regarding the draft. 1. If client doesn't have server's public key, it includes CERTREQ payload in its first message. RFC2408 allows to return several certificates (certificates chain). In this case ID payload usually helps client to quickly decide which certificate of the chain is end entity (server) certificate and to start path construction from it. CRACK exchange doesn't contain ID payloads (as far as I understand). So, does it imply that CRACK disallow server to return several certificates? Or, otherwise, how client will solve this problem? Why not include ID payload in case server sends its certificate(s)? 2. CHRE payload may simultaneously contain both "generic challenge/response blob" and attributes. How its body should be parsed in this case? In other words, assuming that attributes follow the "blob", how one can determine the "blob" length? Or have I missed something? 3. In paragraph 5.4 some it is mentioned that client passes its identity in IDi payload, however, this payload is not present in the following diagrams and is not mentioned anywhere else. Where is the error (if it really is)? 4. About VendorID payload. As far as I understand it is present in CRACK exchange itself. So responder needs to parse unknown (private) exchange message to find it (and, thus, to get knowledge of how to parse that message). It seems not to be the problem for CRACK (and for any exchange that uses only generic ISAKMP payload headers in its message payloads) but, in general, it scares a bit. Please, correct me if I'm wrong. 5. There are 3 identical paragraphs in the draft (starting with "CRACK_MESSAGE is optionally sent...") and all three contain the same typo - "MAY by used by" (I guess you mean "MAY be used by"). Regards, Valera. > A few weeks ago I was alluding to a draft which would address the > desire to do token card authentication in IKE (and do it securely). > The draft is out but is an individual I-D submission due to the fact > that remote access is going to be the responsibility of IPSRA which > does not yet formally exist. Please check it out and comment. It's > called draft-harkins-ipsec-ike-crack-00.txt and can be found with the > others at http://www.ietf.cnri.reston.va.us/internet-drafts. > > Dan. > > > From owner-ipsec@lists.tislabs.com Fri Oct 22 07:56:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA10180; Fri, 22 Oct 1999 07:56:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06971 Fri, 22 Oct 1999 09:24:40 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: RE: Outbound interface as a selector (revisited) Date: Fri, 22 Oct 1999 09:45:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81CFCF5@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From RFC2401: "Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors. Typically there is just one such interface, for a host or security gateway (SG). Note that an SG would always have at least 2 interfaces, but the "internal" one to the corporate net, usually would not have IPsec enabled and so only one pair of SADs and one pair of SPDs would be needed. On the other hand, if a host had multiple interfaces or an SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface." The full extent of this is that you have an SPD/SAD pair for each interface. So the interface selects which SPD/SAD you use. If you have two SAs, for two different interfaces, then they should appear in different SADs. The appropriate SA is found by searching the relevant SAD. > SPI = 0xdeadbeeef > dst = ff02::1 > authalg = MD5 > authkey = Is in the SAD for qfe2, and > SPI = 0xfeedface > dst = ff02::1 > authalg = MD5 > authkey = is in the SAD for qfe1. Chris > -----Original Message----- > From: Dan McDonald [mailto:danmcd@Eng.Sun.Com] > Sent: 22 October 1999 00:58 > To: ipsec@lists.tislabs.com > Subject: Outbound interface as a selector (revisited) > > > I want to clarify what I'm seeking with an example. > > Consider two multicast SAs (I'm using IPv6 as an example, > substitute 224.0.0.1 > if you're a real IPv6-hater) on a multi-homed host or a router: > > SPI = 0xdeadbeeef > dst = ff02::1 > authalg = MD5 > authkey = > > | qfe2 > +---+----+ > | Router | > +---+----+ > | qfe1 > > SPI = 0xfeedface > dst = ff02::1 > authalg = MD5 > authkey = > > Now let's say that 0xfeedface is for one of the routers > interfaces (call it > qfe1), and that 0xdeadbeef is for another router's interface > (call it qfe2). > I have no real way of knowing that unless I can select the > appropriate SA > based on the interface. > > Likewise, on inbound packets, I should only accept ff02::1 > packets from the > 0xdeadbeef SA iff it arrives on interface qfe2. > > I'd like to have something indicating a LINK ID for SA > selection. And I say > LINK ID instead of interface ID, because I may have a fault-tolerant > implementation such that... > > qfe2 | | qfe3 > +----+-+-+ > | Router | > +----+-+-+ > qfe0 | | qfe1 > > where qfe0-1 are on the same physical link, and qfe2-3 are > also on the same > physical link. > > Dan > > p.s. This is prelude to something else I'll be mailing to > this list and the > IPng list. > From owner-ipsec@lists.tislabs.com Fri Oct 22 07:57:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA10254; Fri, 22 Oct 1999 07:57:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06936 Fri, 22 Oct 1999 09:21:40 -0400 (EDT) From: Brian Korver Message-Id: <199910220041.RAA20876@antimony.network-alchemy.com> Subject: Re: CRACK In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE570@new-exc1.ctron.com> from "Waters, Stephen" at "Oct 21, 99 10:02:55 pm" To: Stephen.Waters@cabletron.com (Waters, Stephen) Date: Thu, 21 Oct 1999 17:41:27 -0700 (PDT) Cc: ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Waters, Stephen writes: > Hi Dan, > > Looks good. > > Where did CRACK come from? A dubious name in a security protocol. > > Can the client's private/public key be unique for each connection? Sure. But that would require an implementation+policy that would generate a separate IKE SA for each connection. If you connect frequently, I'm not sure you would want that. > > For the case where the legacy authentication is something a typical client > could deal with (password or chap-thing), should this support symmetric > trust of the public keys used - e.g. the client trusts the gateway based on > the client holding legacy authentication information for the server? If the legacy authentication method is a password, IKE already supports this (pre-shared key). Also, these legacy authentication methods frequently only authenticate the client. What applications are you thinking of? > > > Steve. brian briank@network-alchemy.com From owner-ipsec@lists.tislabs.com Fri Oct 22 10:22:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA20924; Fri, 22 Oct 1999 10:22:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07513 Fri, 22 Oct 1999 11:40:31 -0400 (EDT) Message-Id: <38108704.ACB4B8FF@radguard.com> Date: Fri, 22 Oct 1999 17:47:16 +0200 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: Dan Harkins Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: CRACK References: <199910211619.JAA15266@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I think there is some wording missing in the security considerations section. I am referring to vulnerabilities to denial of service attacks. The gateway is required to answer with KE and SIG prior to any knowledge of who the initiator is. (The SIG cannot be prepared ahead of time.). An attacker only needs to know the gateway's address to launch an attack that requires very little effort on his behalf. Yael From owner-ipsec@lists.tislabs.com Fri Oct 22 10:40:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA22346; Fri, 22 Oct 1999 10:40:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07416 Fri, 22 Oct 1999 11:11:13 -0400 (EDT) Message-ID: <38107F39.5B0E7CA9@DataFellows.com> Date: Fri, 22 Oct 1999 18:14:01 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Brian Korver CC: "Waters, Stephen" , ipsec@lists.tislabs.com, ietf-pkix@imc.org Subject: Re: CRACK References: <199910220041.RAA20876@antimony.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (PKIX: CRACK refers to draft-harkins-ipsec-ike-crack-00.txt.) Brian Korver wrote: > Waters, Stephen writes: > > Hi Dan, > > > > Looks good. > > > > Where did CRACK come from? A dubious name in a security protocol. A very catching marketing trick, I presume. ;-) > > > > > Can the client's private/public key be unique for each connection? > > Sure. But that would require an implementation+policy that would generate > a separate IKE SA for each connection. If you connect frequently, I'm not > sure you would want that. > There's another architectural thing you should consider. What about modifying the protocol so that when the server starts believing in the authenticity of the client, the server issues the client's public key a certificate? This certificate would have a very limited life-time, just enough for the purpose at hand. It would be transported to the client in the 'last' message, whatever that is. Although this creates more public key operations, the legacy authentication functionality could be located on a different physical box than the actual security gateway.. This achieves a very similar function to the Kerberos ticket granting server, and the certificate is similar to Kerberos tickets. You'd of course have to set up the trust relations appropriately. There could also exist "one time certificates" that can be used only once during their life-time to gain access, similar to one time passwords. Some way or another they would be revoked the moment they are used. (CPU is basically very cheap. If not this year, then perhaps next..) > > > > > > > Steve. > > brian > briank@network-alchemy.com -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Oct 22 11:01:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA23848; Fri, 22 Oct 1999 11:01:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07779 Fri, 22 Oct 1999 12:32:27 -0400 (EDT) Message-ID: <38109203.97628615@redcreek.com> Date: Fri, 22 Oct 1999 09:34:11 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan McDonald CC: ipsec@lists.tislabs.com Subject: Re: ICMP{,v6} type/code as a selector... References: <199910220609.XAA05952@kebe.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald wrote: > > While not listed in 2401 explicitly, couldn't one use ICMP/ICMPv6 type and > code as a selector for a security association? The implementation wouldn't > be that tough; just overload the already-there port fields for type and code. ...or generalize the port fields into some sort of protocol-specific selectors or something. That way, we could use type/code for icmp, SPI for esp/ah, etc... From owner-ipsec@lists.tislabs.com Fri Oct 22 11:11:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA24569; Fri, 22 Oct 1999 11:11:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07791 Fri, 22 Oct 1999 12:34:42 -0400 (EDT) Message-Id: <4.2.1.19991022093827.00a85100@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 22 Oct 1999 09:38:33 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Fwd: RFC 2709 on Security for NAT Domains Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This came out a few weeks ago but I didn't see anything on this list about it. >To: IETF-Announce: ; >Subject: RFC 2709 on Security for NAT Domains >Cc: rfc-ed@ISI.EDU >Date: Wed, 06 Oct 1999 11:21:52 -0700 >From: RFC Editor > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2709: > > Title: Security Model with Tunnel-mode IPsec for NAT > Domains > Author(s): P. Srisuresh > Status: Informational > Date: October 1999 > Mailbox: srisuresh@lucent.com > Pages: 11 > Characters: 24552 > Updates/Obsoletes/See Also: None > I-D Tag: draft-ietf-nat-security-02.txt > > URL: ftp://ftp.isi.edu/in-notes/rfc2709.txt > > >There are a variety of NAT flavors, as described in [Ref 1]. Of the >domains supported by NATs, only Realm-Specific IP clients are able >to pursue end-to-end IPsec secure sessions. However, all flavors of >NAT are capable of offering tunnel-mode IPsec security to private >domain hosts peering with nodes in external realm. This document >describes a security model by which tunnel-mode IPsec security can >be architected on NAT devices. A section is devoted to describing >how security policies may be transparently communicated to IKE (for >automated KEY exchange) during Quick Mode. Also outlined are >applications that can benefit from the Security Model described. > >This document is a product of the Network Address Translator (NAT) >Domains' Working Group of the IETF. > >This memo provides information for the Internet community. It does >not specify an Internet standard of any kind. Distribution of this >memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. >Content-Type: text/plain >Content-ID: <991006111836.RFC@RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc2709 > > From owner-ipsec@lists.tislabs.com Fri Oct 22 11:37:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA26425; Fri, 22 Oct 1999 11:37:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07972 Fri, 22 Oct 1999 13:10:46 -0400 (EDT) From: Brian Korver Message-Id: <199910221631.JAA10094@antimony.network-alchemy.com> Subject: Re: CRACK In-Reply-To: <38107F39.5B0E7CA9@DataFellows.com> from Ari Huttunen at "Oct 22, 99 06:14:01 pm" To: Ari.Huttunen@datafellows.com (Ari Huttunen) Date: Fri, 22 Oct 1999 09:31:41 -0700 (PDT) Cc: briank@network-alchemy.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, ietf-pkix@imc.org X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen writes: > There's another architectural thing you should consider. What about modifying > the protocol so that when the server starts believing in the authenticity of the > client, the server issues the client's public key a certificate? This certificate > would have a very limited life-time, just enough for the purpose at hand. > It would be transported to the client in the 'last' message, whatever that is. > > Although this creates more public key operations, the legacy authentication > functionality could be located on a different physical box than the actual > security gateway.. This achieves a very similar function to the Kerberos ticket > granting server, and the certificate is similar to Kerberos tickets. You'd of > course have to set up the trust relations appropriately. > > There could also exist "one time certificates" that can be used only once > during their life-time to gain access, similar to one time passwords. Some > way or another they would be revoked the moment they are used. > > (CPU is basically very cheap. If not this year, then perhaps next..) We thought about that, but there are already perfectly good protocols for obtaining certificates (CEP, PKIX, whatever) and these certificates could be short-lived for exactly this purpose. On the other hand, as you point out, this is a more heavyweight mechanism. Hence the draft. brian briank@network-alchemy.com From owner-ipsec@lists.tislabs.com Fri Oct 22 11:38:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA26486; Fri, 22 Oct 1999 11:38:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07920 Fri, 22 Oct 1999 13:01:51 -0400 (EDT) Message-Id: <4.2.1.19991022093827.00a85100@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 22 Oct 1999 09:49:21 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Fwd: RFC 2709 on Security for NAT Domains Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This came out a few weeks ago but I didn't see anything on this list about it. >To: IETF-Announce: ; >Subject: RFC 2709 on Security for NAT Domains >Cc: rfc-ed@ISI.EDU >Date: Wed, 06 Oct 1999 11:21:52 -0700 >From: RFC Editor > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 2709: > > Title: Security Model with Tunnel-mode IPsec for NAT > Domains > Author(s): P. Srisuresh > Status: Informational > Date: October 1999 > Mailbox: srisuresh@lucent.com > Pages: 11 > Characters: 24552 > Updates/Obsoletes/See Also: None > I-D Tag: draft-ietf-nat-security-02.txt > > URL: ftp://ftp.isi.edu/in-notes/rfc2709.txt > > >There are a variety of NAT flavors, as described in [Ref 1]. Of the >domains supported by NATs, only Realm-Specific IP clients are able >to pursue end-to-end IPsec secure sessions. However, all flavors of >NAT are capable of offering tunnel-mode IPsec security to private >domain hosts peering with nodes in external realm. This document >describes a security model by which tunnel-mode IPsec security can >be architected on NAT devices. A section is devoted to describing >how security policies may be transparently communicated to IKE (for >automated KEY exchange) during Quick Mode. Also outlined are >applications that can benefit from the Security Model described. > >This document is a product of the Network Address Translator (NAT) >Domains' Working Group of the IETF. > >This memo provides information for the Internet community. It does >not specify an Internet standard of any kind. Distribution of this >memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. >Content-Type: text/plain >Content-ID: <991006111836.RFC@RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc2709 > > From owner-ipsec@lists.tislabs.com Fri Oct 22 19:02:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA19083; Fri, 22 Oct 1999 19:02:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09299 Fri, 22 Oct 1999 20:42:09 -0400 (EDT) Message-Id: <199910221319.JAA00919@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: ICMP{,v6} type/code as a selector... In-reply-to: Your message of "Thu, 21 Oct 1999 23:09:18 PDT." <199910220609.XAA05952@kebe.Eng.Sun.COM> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 22 Oct 1999 09:19:38 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan McDonald writes: Dan> While not listed in 2401 explicitly, couldn't one use ICMP/ICMPv6 type and Dan> code as a selector for a security association? The implementation wouldn't Dan> be that tough; just overload the already-there port fields for type and code. Yes, I have suggested this on numerous times, but in general, it isn't enough to properly support ICMP. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Oct 25 02:54:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02430; Mon, 25 Oct 1999 02:54:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16209 Mon, 25 Oct 1999 04:18:05 -0400 (EDT) Message-Id: <9910250832.AA02549@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Mon, 25 Oct 1999 17:32:00 +0900 To: Yael Dayan Cc: Dan Harkins , ipsec@lists.tislabs.com Subject: Re: CRACK In-Reply-To: <38108704.ACB4B8FF@radguard.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yael, Please consult with http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt about a modified authentication mode more resistant against the DoS you mentioned. Any comments are welcome. Thanks, Yael Dayan wrote: >>Dan, >>I think there is some wording missing in the security considerations >>section. >>I am referring to vulnerabilities to denial of service attacks. >>The gateway is required to answer with KE and SIG prior to any knowledge >>of who the initiator is. (The SIG cannot be prepared ahead of time.). >>An attacker only needs to know the gateway's address to launch an attack >>that requires very little effort on his behalf. >> >>Yael --^^-- Kanta From owner-ipsec@lists.tislabs.com Mon Oct 25 05:28:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06805; Mon, 25 Oct 1999 05:28:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA16598 Mon, 25 Oct 1999 06:55:00 -0400 (EDT) Message-Id: <199910251057.GAA02986@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-di-mon-mib-01.txt Date: Mon, 25 Oct 1999 06:57:31 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : ISAKMP DOI-Independent Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-isakmp-di-mon-mib-01.txt Pages : 24 Date : 22-Oct-99 This document defines a DOI (domain of interpretation) independent monitoring MIB for ISAKMP. The purpose of this MIB is to be used as the basis for protocol specific MIBs that use ISAKMP as the basis for key exchanges or security association negotiation. As such, it has no DOI-dependent objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-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-ietf-ipsec-isakmp-di-mon-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022135556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-di-mon-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135556.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Oct 25 05:31:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06925; Mon, 25 Oct 1999 05:31:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16632 Mon, 25 Oct 1999 07:01:51 -0400 (EDT) Message-ID: <3814396B.F9674FA4@DataFellows.com> Date: Mon, 25 Oct 1999 14:05:15 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Yael Dayan CC: Dan Harkins , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: CRACK References: <199910211619.JAA15266@potassium.network-alchemy.com> <38108704.ACB4B8FF@radguard.com> Content-Type: multipart/alternative; boundary="------------DB867229C8316919D977FE71" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------DB867229C8316919D977FE71 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yael Dayan wrote: > Dan, > I think there is some wording missing in the security considerations > section. > I am referring to vulnerabilities to denial of service attacks. > The gateway is required to answer with KE and SIG prior to any knowledge > of who the initiator is. (The SIG cannot be prepared ahead of time.). > An attacker only needs to know the gateway's address to launch an attack > that requires very little effort on his behalf. > > Yael There are at least two ways that I can think of, to make this more DoS secure. It's hard for a malicious client to a) receive IP packets if the source address is spoofed, and b) it's computationally expensive to generate public/private key pairs. We can use these to improve DoS resitance by making the client first prove that it can receive IP packets and to give the gateway the public key (and prove possession of the private key) before the gateway gives KEr or SIG1. Something along the lines below. Client (I) Gateway (R) ----------- ----------- HDR, SAi, Ni [, CERTREQ] ---> <--- HDR, SAr, [CERT, ] Nr HDR, KEi, PK, SIG0 ---> <--- HDR, KEr, SIG1 HDR*, CHRE ---> <--- HDR*, < SIG2 | CHRE > HDR*, < SIG3 | CHRE > ---> Here SIG0 is something suitable that proves possession of the private key. If this is a DoS attack, the source IP address and/or the PK is put to a black list and denied access in the future. There are several (minor?) disadvantages too. I'll leave it to the authors if this is worth it or not. Another matter is that I believe SIG2 could be replaced by a hash. Since the gateway has already signed KEr, which specifies the encrypting channel, which is in turn used to transport the hash, this should be secure? This could also be usable for SIG3 if SIG0 is added as suggested in this mail. Incidentally, this modified exchange looks somewhat like base mode.. BTW, there's an interesting paper by Pekka Nikander and Tuomas Aura about stateless connections that makes protocols more resistant to DoS attacks ( http://www.tcm.hut.fi/~pnr/publications/ICICS-97.ps ). The idea of my previous DoS secured base mode mails is from here. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security --------------DB867229C8316919D977FE71 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Yael Dayan wrote:
Dan,
I think there is some wording missing in the security considerations
section.
I am referring to vulnerabilities to denial of service attacks.
The gateway is required to answer with KE and SIG prior to any knowledge
of who the initiator is.  (The SIG cannot be prepared ahead of time.).
An attacker only needs to know the gateway's address  to launch an attack
that requires very little effort on his behalf.

Yael

There are at least two ways that I can think of, to make this more
DoS secure. It's hard for a malicious client to
a) receive IP packets if the source address is spoofed, and
b) it's computationally expensive to generate public/private key pairs.

We can use these to improve DoS resitance by making the client
first prove that it can receive IP packets and to give the gateway
the public key (and prove possession of the private key) before
the gateway gives KEr or SIG1. Something along the lines below.

   Client (I)                     Gateway (R)
  -----------                     -----------
   HDR, SAi, Ni
     [, CERTREQ]          --->
                          <---     HDR, SAr, [CERT, ] Nr
   HDR, KEi, PK, SIG0     --->
                          <---     HDR, KEr, SIG1
   HDR*, CHRE             --->
                          <---     HDR*, < SIG2 | CHRE >
   HDR*, < SIG3 | CHRE >  --->

Here SIG0 is something suitable that proves possession of the private key.
If this is a DoS attack, the source IP address and/or the PK is put to a black
list and denied access in the future. There are several (minor?) disadvantages too.
I'll leave it to the authors if this is worth it or not.

Another matter is that I believe SIG2 could be replaced by a hash. Since
the gateway has already signed KEr, which specifies the encrypting channel,
which is in turn used to transport the hash, this should be secure? This
could also be usable for SIG3 if SIG0 is added as suggested in this mail.

Incidentally, this modified exchange looks somewhat like base mode..

BTW, there's an interesting paper by Pekka Nikander and Tuomas Aura
about stateless connections that makes protocols more resistant to DoS
attacks ( http://www.tcm.hut.fi/~pnr/publications/ICICS-97.ps ). The idea
of my previous DoS secured base mode mails is from here.

Ari

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security
  --------------DB867229C8316919D977FE71-- From owner-ipsec@lists.tislabs.com Mon Oct 25 05:31:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06945; Mon, 25 Oct 1999 05:31:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA16592 Mon, 25 Oct 1999 06:54:48 -0400 (EDT) Message-Id: <199910251057.GAA02974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-monitor-mib-02.txt Date: Mon, 25 Oct 1999 06:57:22 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-monitor-mib-02.txt Pages : 68 Date : 22-Oct-99 This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec. Further, it does not provide policy information. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPsec portion of their network. Statistics are provided as well. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPsec SAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-02.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-ietf-ipsec-monitor-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022135546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-monitor-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135546.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Oct 25 05:35:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07110; Mon, 25 Oct 1999 05:35:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA16586 Mon, 25 Oct 1999 06:54:42 -0400 (EDT) Message-Id: <199910251057.GAA02962@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-monitor-mib-00.txt Date: Mon, 25 Oct 1999 06:57:16 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IKE Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-ike-monitor-mib-00.txt Pages : 66 Date : 22-Oct-99 This document defines monitoring and status MIBs for use when the (Internet Key Exchange) IKE protocol [IKE] is used to create IPsec security associations (SAs). As such, provides the linkage between IKE (phase 1) SAs and the IPsec (phase 2) SAs created by those SAs. It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec SAs, except that they were created using IKE. Further, it does not provide policy information. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPsec portion of their network. Statistics are provided as well. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPsec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-00.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-ietf-ipsec-ike-monitor-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991022135535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-monitor-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135535.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Oct 25 08:12:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10314; Mon, 25 Oct 1999 08:12:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17071 Mon, 25 Oct 1999 08:50:52 -0400 (EDT) From: "Criss" To: Subject: comments on ip sec Date: Sun, 24 Oct 1999 16:15:40 -0300 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01BF1E3B.04268400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BF1E3B.04268400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi, i'm bruce Alminin, a finishing studend in computer science at Uqam, University of Montreal. I'm also creating my own company at montreal in order to sell networks and computer products. In fact i'd like to have more documentation about the definition of ip sec. I ask to send if possible a file with the objectives, goal, and concepts of ip sec. i already thanks you for you reply. Bruce. ------=_NextPart_000_0000_01BF1E3B.04268400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hi,
i'm = bruce Alminin, a=20 finishing studend in computer science at Uqam, University of Montreal. = I'm also=20 creating my own company at montreal in order to sell networks and = computer=20 products.
In = fact i'd like to=20 have more documentation about the definition of ip = sec.
I ask = to send if=20 possible a file with the objectives, goal, and concepts of ip=20 sec.
 
i = already thanks you=20 for you reply.
 
Bruce.
------=_NextPart_000_0000_01BF1E3B.04268400-- From owner-ipsec@lists.tislabs.com Mon Oct 25 08:59:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11198; Mon, 25 Oct 1999 08:59:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17284 Mon, 25 Oct 1999 09:48:49 -0400 (EDT) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com Message-ID: <85256815.004C0EE9.00@d54mta05.raleigh.ibm.com> Date: Mon, 25 Oct 1999 09:52:18 -0400 Subject: "PKIX Profile for IKE"--Is it really a profile? Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA17280 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments below apply to draft-ietf-ipsec-pki-req-03.txt, "A PKIX Profile for IKE". 1. This draft's purpose is to provide a definitive profile for a specific way that IKE and PKIX will interoperate. We need a clear statement that defines what it means to comply with this draft, versus what it means to comply with the underlying IPSec and PKIX documents. Suggested text to accomplish this would go in a "Requirements Terminology" section which would say: "The key words "MUST", "SHALL", REQUIRED", SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119." "This document defines a particular method of using IKE which is more restrictive than is necessary for compliance with RFC 2459, RFC 2408 and RFC 2409. It defines a PKIX profile that is more restrictive than is necessary for compliance with RFC 2459. Additional requirements levied in this document apply only to implementations that wish to claim compliance with the profile described in this document. It is possible for an implementation comply with RFC 2408 and RFC 2409, but not comply with this document. Similarly, it is possible for a PKI implementation to comply with RFC 2459 but not comply with this document. An implementation is said to "comply" with the profile given in this document when it satisfies all mandatory requirements ("MUST" and "MUST NOT") enumerated in this document." 2. The current draft offers no definitive, unambiguous requirements for the profile. In general, it concentrates on high level statements of what MUST or MUST NOT be done, but it offers no detailed methods for accomplishing these tasks. In reviewing this document, I find that there are only 6 ?MUSTs? (summarized below), and that none of them nail down any details. Without details, we have no stake in the ground on which to base interoperability claims. The current "MUSTs" are: · MUST check revocation status of certificates on which an IKE implementation relies · MUST have a method for receiving up-to-date revocation information · MUST support a signing hierarchy · MUST delete SAs corresponding to certificates that have become invalid · EKU MUST contain only object identifier iKEIntermedate · MUST examine notAfter time in certificates Note also that some of the important details about the operation of IKE are not addressed in this profile, even though in many cases the existing IKE specs leave the details open to interpretation. For example, there is no normative text to outline a profile-specific method for handling IKE?s CERTIFICATE and CERTIFICATE REQUEST payloads, there is no normative text to describe certificate validation in IKE (e.g., what if an evaluating system does not trust its peer's root CA, what are the normative rules for matching a certificate?s subject to IKE?s ID Payload fields, can a given IKE implementation recognize more than one root CA, what validation steps are needed for CA certificates of CAs located on a certification chain, can there be multiple certification chains between an end entity and its root CA(s), , etc. In the interest of having focused discussions, I will separately post suggested text that will address some of these issues. ...Charlie Kunzinger ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development (JEUA/502), RTP Phone: Tie 8-444-4142 , External 919-254-4142 Fax: Tie 8-441-7288, External 919-543-7288 From owner-ipsec@lists.tislabs.com Mon Oct 25 10:22:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12493; Mon, 25 Oct 1999 10:22:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17550 Mon, 25 Oct 1999 10:53:14 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <38109203.97628615@redcreek.com> References: <199910220609.XAA05952@kebe.Eng.Sun.COM> Date: Mon, 25 Oct 1999 10:56:24 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: ICMP{,v6} type/code as a selector... Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have no objection to adding selector support for ICMP, but let's not overload the port fields; we need to articulate a clear specification of what we convey under what circumstances as we broaden support beyond TCP & UDP. Steve From owner-ipsec@lists.tislabs.com Mon Oct 25 11:18:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13522; Mon, 25 Oct 1999 11:18:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17855 Mon, 25 Oct 1999 12:08:55 -0400 (EDT) Message-ID: <381475F1.83864431@checkpoint.com> Date: Mon, 25 Oct 1999 17:23:29 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins , Brian Korver , Derrell Piper , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Comments on CRACK Content-Type: multipart/mixed; boundary="------------27EEF8D5105FA26426CDB0AF" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------27EEF8D5105FA26426CDB0AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CRACK is designed to allow legacy authentication in the IKE framework, where a limited amount of Public Key technology is involved i.e. The server has a public key and the client can verify it. CRACK is not the first suggestion to provide this functionality, a fact that probably alluded the authors (otherwise they would have acknowledged previous suggestions). As a matter of fact, a draft solving the exact same problems has been around for over a year now. Considering this, anyone who comes up with a new proposal should justify going back a year in the process and starting all over again. Comparing CRACK to the hybrid protocol there is one advantage to CRACK over the current hybrid protocol. The authentication is all done during one "phase 1" exchange, thus avoiding the "limbo" state of the IKE SA, when the IKE SA is created but can only be used for the XAUTH exchange. Having the whole process done in one exchange also reduces the number of packets in the negotiation. Actually, for those of you who have been following the IPSEC mailing list, this was the situation in the original hybrid proposal. Comments received on the mailing list made us change this because: 1. People did not like the idea of making the phase 1 open ended. 2. People did not like the idea of making big changes to phase 1. 3. We wanted to make Hybrid co-exist with existing proposed mechanisms (XAUTH). Being an co-author of Hybrid, I tend to agree that having this done in a single exchange is better. But, in my view, this advantage does not constitute a good enough reason to start all over again. The CRACK authors also claim to have a better binding between the keying material and the authentication process. I fail to see why. The fact that the authentication is signed by the client gives a warm fuzzy feeling about the process. It even suggests the notion of non-repudiation. But careful examination reveals that there is no non-repudiation (If the server can generate the challenge/response sequence it can generate one allegedly signed by the client). The way I see it, an adversary can either break the DH exchange or not. If it can break it, then he has completely broken the IKE protocol. However, if it cannot break it, I don't see how you are better of with the client signing the exchange. What I do see, is an overhead of public key operations, including a signing/verifying action on the server and (RSA) key generation + signing/verifying on the client. Any extra work on the server side must be justified. On the other hand I see several drawbacks, the biggest one is that it is susceptible to a trivial DoS attack (as already mentioned by Yael). In a protocol designed for roaming clients, where no IP address based filtering is possible this is a show stopper. On top of this, a good protocol designed for client use ought to support error messages in human readable format, as well as error codes. CRACK forbids the former and does not specify the latter. The draft is full of minor issues. As Dan said this is only a 00-draft, but why do we need this when we have a mature protocol in hand? Regards, Moshe Litvin --------------27EEF8D5105FA26426CDB0AF Content-Type: text/x-vcard; charset=us-ascii; name="moshe.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Moshe Litvin Content-Disposition: attachment; filename="moshe.vcf" begin:vcard n:Litvin;Moshe tel;fax:+972 3 5759256 tel;work:+972 3 7534601 x-mozilla-html:TRUE org:Check Point Software Technologies Ltd. adr:;;;;;; version:2.1 email;internet:moshe@CheckPoint.com fn:Moshe Litvin end:vcard --------------27EEF8D5105FA26426CDB0AF-- From owner-ipsec@lists.tislabs.com Mon Oct 25 11:30:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13709; Mon, 25 Oct 1999 11:30:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17919 Mon, 25 Oct 1999 12:29:33 -0400 (EDT) Message-Id: <4.2.1.19991025092318.00b4ee60@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 25 Oct 1999 09:32:17 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: "PKIX Profile for IKE"--Is it really a profile? In-Reply-To: <85256815.004C0EE9.00@d54mta05.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just to follow up on Charlie's first message. The three document editors put out the -03 draft knowing that each of us has some problems with some of the things in the draft. Our purpose in putting out this highly revised version was to make the draft shorter and easier to follow *so that you all can comment more easily*. There has been a dearth of comments on earlier drafts, and we really need input from the community about what the profile should look like. I'll send in my own comments about things I don't like in the draft later today. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 25 11:54:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14108; Mon, 25 Oct 1999 11:54:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18021 Mon, 25 Oct 1999 12:54:13 -0400 (EDT) Message-ID: <38148BB5.C1E35457@redcreek.com> Date: Mon, 25 Oct 1999 09:56:21 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: ICMP{,v6} type/code as a selector... References: <199910220609.XAA05952@kebe.Eng.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > I have no objection to adding selector support for ICMP, but let's not > overload the port fields; we need to articulate a clear specification of > what we convey under what circumstances as we broaden support beyond TCP & > UDP. This is what I meant to suggest when I said "generalize the port fields...". Sorry if it wasn't clear - I'm all for this approach. Scott From owner-ipsec@lists.tislabs.com Mon Oct 25 14:08:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16215; Mon, 25 Oct 1999 14:08:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18474 Mon, 25 Oct 1999 14:35:49 -0400 (EDT) Message-Id: <199910251836.LAA27461@potassium.network-alchemy.com> To: Moshe Litvin cc: Brian Korver , Derrell Piper , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK In-reply-to: Your message of "Mon, 25 Oct 1999 17:23:29 +0200." <381475F1.83864431@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27458.940876572.1@network-alchemy.com> Date: Mon, 25 Oct 1999 11:36:12 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Moshe, On Mon, 25 Oct 1999 17:23:29 +0200 you wrote > > CRACK is designed to allow legacy authentication in the IKE framework, > where a limited amount of Public Key technology is involved i.e. The > server has a public key and the client can verify it. > > CRACK is not the first suggestion to provide this functionality, a fact > that probably alluded the authors (otherwise they would have > acknowledged previous suggestions). As a matter of fact, a draft > solving the exact same problems has been around for over a year now. I'm sorry for leaving out reference of Hybrid. It was not meant as a slap-in-the-face and I'll see it gets rectified in -01.txt. > Considering this, anyone who comes up with a new proposal should > justify going back a year in the process and starting all over again. I don't see this as starting the process over again. The process is just getting started, hence the IPSRA. > Comparing CRACK to the hybrid protocol there is one advantage to CRACK > over the current hybrid protocol. > > The authentication is all done during one "phase 1" exchange, thus > avoiding the "limbo" state of the IKE SA, when the IKE SA is created but > can only be used for the XAUTH exchange. Having the whole process done > in one exchange also reduces the number of packets in the negotiation. It also solves the problem with one single draft. There was much moaning and groaning (rightfully so) about having 3 separate standards track RFCs and an Informational RFC just to do a single key management protocol. I've heard lots of griping about jumping from paper to paper. So instead of having ISAKMP-Config plus XAUTH plus Hybrid just to allow for remote client authentication we can have CRACK. But you're right. The phase 1.5 "limbo" state of the IKE SA is a hack. It screws up the state machine for no reason. Some SAs transition to phase 2 immediately and some have to wait around for more stuff to happen. > Actually, for those of you who have been following the IPSEC mailing > list, this was the situation in the original hybrid proposal. > Comments received on the mailing list made us change this because: > 1. People did not like the idea of making the phase 1 open ended. > 2. People did not like the idea of making big changes to phase 1. > 3. We wanted to make Hybrid co-exist with existing proposed mechanisms > (XAUTH). This was at a time when we were trying to get the first set of mutually- referencing drafts out the door. Changing the protocol to support this was not viewed positively at that time. Times have changed. > Being an co-author of Hybrid, I tend to agree that having this done in a > single exchange is better. But, in my view, this advantage does not > constitute a good enough reason to start all over again. > > The CRACK authors also claim to have a better binding between the keying > material and the authentication process. I fail to see why. The fact > that the authentication is signed by the client gives a warm fuzzy > feeling about the process. It even suggests the notion of > non-repudiation. But careful examination reveals that there is no > non-repudiation (If the server can generate the challenge/response > sequence it can generate one allegedly signed by the client). If the server maintains the secret database itself and knows what a valid client response looks like then yes this is possible. Practically though the server will pass an opaque blob off to an authentication server who will say yea or nea and log it. If this authentication server is generating bogus challenge/responses then all bets are off anyway. > The way I see it, an adversary can either break the DH exchange or not. > If it can break it, then he has completely broken the IKE protocol. > However, if it cannot break it, I don't see how you are better of with > the client signing > the exchange. > > What I do see, is an overhead of public key operations, including a > signing/verifying action on the server and (RSA) key generation + > signing/verifying on the client. > Any extra work on the server side must be justified. Security is not free. > On the other hand I see several drawbacks, the biggest one is that it is > susceptible to a trivial DoS attack (as already mentioned by Yael). In a > protocol designed for roaming clients, where no IP address based > filtering is possible this is a show stopper. > > On top of this, a good protocol designed for client use ought to support > error messages in human readable format, as well as error codes. CRACK > forbids the former and does not specify the latter. I don't understand. Can you point out where this is forbidden and perhaps show where error codes are specified in the "good protocol"? > The draft is full of minor issues. As Dan said this is only a 00-draft, > but why do we need this when we have a mature protocol in hand? I wish you'd bring up the minor issues then. And I don't think we have a mature protocol in hand. Last week I talked to a representative of another company who claimed "full compliance" with the "draft standard RFC". It turns out he only does radius, does not do Hybrid, and I know he's not interoperable with another vendor who also does the same thing. Part of the problem with the ISAKMP-Config+XAUTH+Hybrid approach is that it leaves XAUTH as a separate entity. This protocol by itself is fundamentally broke. The problems are addressed with the addition of Hybrid but it is not required to do Hybrid. As a result people do an unauthenticated Diffie- Hellman and a radius exchange on top of that and claim compliance to a "draft standard RFC". All the time excusing it away with the remark that their customers don't really want strong security. I must've missed it when the requirements from a company's marketing department became part of a WG charter. If XAUTH and Hybrid were combined into a single draft which, basically, forbade the common XAUTH practice it would be another story. It would be the "Extended Hybrid Authentication" solution vs. CRACK and I would be hardpressed to say which one is the "best". But then again, we're back to square one. Dan. From owner-ipsec@lists.tislabs.com Mon Oct 25 14:23:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16451; Mon, 25 Oct 1999 14:23:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18670 Mon, 25 Oct 1999 15:25:44 -0400 (EDT) Message-Id: <199910251925.MAA27609@potassium.network-alchemy.com> To: "Valery Smyslov" cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: CRACK In-reply-to: Your message of "Fri, 22 Oct 1999 16:51:58 +0400." <199910221252.QAA05159@relay1.trustworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27606.940879549.1@network-alchemy.com> Date: Mon, 25 Oct 1999 12:25:49 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Valery, On Fri, 22 Oct 1999 16:51:58 +0400 you wrote > On 21 Oct 99, at 9:19, Dan Harkins wrote: > > Dan, > > some comments/questions regarding the draft. > > 1. If client doesn't have server's public key, it includes CERTREQ > payload in its first message. RFC2408 allows to return several > certificates (certificates chain). In this case ID payload usually > helps client to quickly decide which certificate of the chain is end > entity (server) certificate and to start path construction from it. > CRACK exchange doesn't contain ID payloads (as far as I understand). > So, does it imply that CRACK disallow server to return several > certificates? Or, otherwise, how client will solve this problem? Why > not include ID payload in case server sends its certificate(s)? I was assuming that the "right" certificiate in the chain would be gleaned from the process of parsing the chain but I've not given it much thought. Perhaps an ID payload is needed. > 2. CHRE payload may simultaneously contain both "generic > challenge/response blob" and attributes. How its body should be > parsed in this case? In other words, assuming that attributes follow > the "blob", how one can determine the "blob" length? Or have I missed > something? The blob is the attributes but different LAM types have different attributes so we just called the generic set of attributes a blob. > 3. In paragraph 5.4 some it is mentioned that client passes its > identity in IDi payload, however, this payload is not present in the > following diagrams and is not mentioned anywhere else. Where is the > error (if it really is)? That's an error. Thanks for finding it. The identity is the CRACK_USERNAME and it's part of the blob of the first CHRE payload. This'll get fixed. > 4. About VendorID payload. As far as I understand it is present in > CRACK exchange itself. So responder needs to parse unknown (private) > exchange message to find it (and, thus, to get knowledge of how to > parse that message). It seems not to be the problem for CRACK (and > for any exchange that uses only generic ISAKMP payload headers in its > message payloads) but, in general, it scares a bit. Please, correct > me if I'm wrong. Yes, that is backwards but that's the protocol we have to work with. You have to parse the first message in the exchange to get a DOI value too. So you're already parsing payloads before you know how to really parse all payloads. This is a regrettable part of the ISAKMP/IKE/DOI mix. If this draft is advanced IANA will assign it valid exchange numbers from the approprate place and the requirement to use the vendor ID payload will go away. The alternative would be to do what ISAKMP-Config did and just grab a number from a numberspace that it does not manage. I could've made the CRACK exchange 6 since it has not been assigned by IANA yet. That would'be caused protests since that's the number that ISAKMP-Config used. ISAKMP-Config did not follow the process. That's another problem altogether. I didn't want this draft to contribute to this mess and the right way to do it (with vendor ID payloads) is, as you point out, problematic. > 5. There are 3 identical paragraphs in the draft (starting with > "CRACK_MESSAGE is optionally sent...") and all three contain the same > typo - "MAY by used by" (I guess you mean "MAY be used by"). OK, thanks for this too. Dan. From owner-ipsec@lists.tislabs.com Mon Oct 25 16:23:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18713; Mon, 25 Oct 1999 16:23:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19132 Mon, 25 Oct 1999 18:01:31 -0400 (EDT) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com Message-ID: <85256815.007933EA.00@d54mta05.raleigh.ibm.com> Date: Mon, 25 Oct 1999 18:05:32 -0400 Subject: PKIX Profile for IKE - CA Certificates & IKE Identification Certificates Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk More food for thought, and hopefully also for comment! As Paul Hoffman mentioned in his note earlier today, I am one of the authors who felt that more detail is needed. To give the group a feel for how much detail I would like to see, I will attach sample text for several topics, each within separate postings. This posting deals with definitions and requirements relevant to the various public-key certificates used within IKE. I feel that the topic of how IKE integrates various Certification Authorities and the related public key certificates into its operations should be defined in greater detail in "A PKIX Profile for IKE" (draft-ietf-ipsec-pki-req-03.txt). I propose that we explicitly define the various types of CA, their roles w/r/t IKE, and certification hierarchies. Below is some suggested text that addresses these issues. _________________SUGGESTED TEXT________________________________ (I use "N" to represent a new section number, should we decide to include the suggested text into the document.) N Types of CA: Root, Top, Subordinate, and Intermediate The profile defined in this document relies on the distinctions between a "Root CA", a "Top CA", and a "Subordinate CA". The definitions of these terms have been discussed extensively within the PKIX Working Group, and have been stabilized in [ROADMAP]. These definitions are reproduced below, exactly as they are presented in [ROADMAP]. In addition, this profile also defines an "Intermediate CA", which is a specialization of a Subordinate CA: Root CA -- A CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. Top CA - A CA that is at the top of a PKI hierarchy. Subordinate CA - A "subordinate CA" is one that is not a root CA for the end entity in question. Often a subordinate CA will not be a root CA for any entity but this is not mandatory. Intermediate CA - A Subordinate CA that is located on a certification path between the end entity and its Root CA. "Top CA" denotes only the position of a given CA within a certification hierarchy, but does not necessarily imply that the given CA is also a "Root CA". A "Root CA" can be situated anywhere within a given certification hierarchy. The "root-ness" comes from the trust relation. Hence, a given CA can be a Root CA for some entities but not for others. A given CA could simultaneously be both a Subordinate CA for one end entity and a Root CA for another end entity. >From the perspective of an IKE device, CAs that are located in the PKI hierarchy above its own Root CA (from a graph-theory viewpoint) play no role in the IKE protocol. That is, as far as the end entity is concerned, such CAs do not exist. N.1 IKE Identification Certificate An IKE device MUST store locally at least one IKE Identification Certificate that binds a public key to each identity that the device will place in the ID Payload field of the IKE messages. The identities to which the public key is bound are the union of the contents of the IKE Identification certificate's "subject" field and "subjectAltName" extension. For each IKE Identification Certificate that it will use in conjunction with IKE, the IKE device MUST securely store the associated private key locally. AN IKE device MAY have multiple IKE Identification Certificates. Methods used to generate an appropriate public-private key pair are not constrained by this profile. Methods for initially acquiring an IKE Identification Certificate from a CA are not constrained by this profile. N.2 Certificates of Root CA(s) The IKE device MUST securely acquire and store a CA certificate for each Root CA with which it has a trust relationship. The methods used to obtain a valid Root CA certificate(s from the intended Root CA are left as a local option for each IKE device, and are not constrained by this profile. The existence of a trust relationship with a given Root CA does not require the IKE device to have in its possession an IKE Identification Certificate that was issued by that Root CA. N.3 Certification Paths (NOTE: The definition below is based on Section 6.1 of RFC 2459. However, the definition in this profile terminates the path at a Root CA, while the definition and examples in RFC 2459, section 6.1 terminates it at what this profile calls a "Top CA".) Each path between a given IKE device and its Root CA(s) may include several Intermediate CAs, whose CA certificates comprise the links on a "certification path" extending from the IKE device to the Root CA(s). More formally, a certification path between a given IKE device and a Root CA consists of a set of "n-2" certificates, one for each Intermediate CA between the IKE device and the Root CA under consideration, where: * the certificate of the Root CA is numbered "1" * the certificates of Intermediate CAs, if any, are numbered in the range from "2" to "n-1" * the IKE Identification Certificate is numbered "n" * for all x in {1, n-1}, the subject of certificate x is the issuer of certificate x+1 For each Root CA that it recognizes, an IKE device MUST support a certification paths containing up to seven (7) Intermediate CAs (i.e. there can be up to 8 CA certificates, including that of the Root CA). N.4 Certificates of Intermediate CAs An IKE device MUST store locally a copy of each CA certificate that is included in at least one of the certification path(s) between itself and each of its own Root CA(s). (NOTE: There may be multiple certification paths between a given IKE device and a given Root CA. The requirement above does not preclude an IKE device from storing locally all CA certificates on all certification paths between itself and the Root CA.) This profile does not constraint the methods that an IKE device can use to obtain the certificates that comprise the certification path. There is no requirement for an IKE device to store the CA Certificates of any other device's Intermediate CAs. An IKE device will learn the certification paths of the peer with which it is engaged in an IKE negotiation by examining the Certificate Payload fields that it receives from its peer, as described in Sections XXX. ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development (JEUA/502), RTP Phone: Tie 8-444-4142 , External 919-254-4142 Fax: Tie 8-441-7288, External 919-543-7288 From owner-ipsec@lists.tislabs.com Mon Oct 25 18:22:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21185; Mon, 25 Oct 1999 18:22:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19617 Mon, 25 Oct 1999 20:08:43 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242C9F@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Brian Korver'" Cc: ipsec@lists.tislabs.com Subject: RE: Query on draft-ietf-ipsec-pki-req-03.txt Date: Mon, 25 Oct 1999 17:11:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Brian, Actually I agree with you and prefer avoiding a mandate that CRLs be distributed in-band. CRLs may grow too huge. On the other hand, the IPSec PKI requirements document now mandates certificate revocation verification. It is not clear how this is supposed to work when the CRL distribution point and the remote access IPSec host are separated by the security gateway with which the remote host is negotiating. I think we must adopt one of the following: i. the verification requirement is somehow relaxed (e.g., making verification mandatory whenever it is possible to acquire the CRL), or ii. remote access IPSec hosts are forbidden from using certificates (except when they already have the latest CRL through possibly another source), or iii. the spec mandates a certificate revocation validation technique on which even remote access IPSec hosts can always count. I can't imagine anyone advocating the second choice. If the choice is instead the last of the three, then it would be desirable to specify which technique will be the interoperable one, so everyone doesn't have to implement 8 (or whatever the number really turns out to be) different ones. But the first of the three is the most practical of the alternatives, even though everyone knows it is not the most secure. -- Jesse -----Original Message----- From: Brian Korver [mailto:briank@Network-Alchemy.COM] Sent: Monday, October 25, 1999 4:10 PM To: jesse.walker@intel.com Cc: ipsec@lists.tislabs.com Subject: Re: Query on draft-ietf-ipsec-pki-req-03.txt Walker, Jesse writes: > Greg, > > Yes, I know; a lot of implementations do forward CRLs as part of their > negotiations. The question is whether this must be required. If the draft > requires all implementations do certificate validation, then I don't see how > conformance is possible unless the draft also requires implementations to > pass CRLs. > > -- Jesse Jesse, I'm not sure that in-band CRL distribution should be a MUST. First, some environments may prefer to leave CRLs as optional. For instance, perhaps other mechanisms are available (OCSP, etc.). Second, we don't yet know what the market will decide regarding distribution of revocation information. Currently, the answer is probably "none of the above", although one could envision such things as OCSP, CRLDistributionPoints, or something else becoming "the answer". Since in-band distribution of CRLs is probably the only choice we currently have, I think it should receive a SHOULD. I'd prefer text along the lines of Unless configured to do otherwise, implementations SHOULD return CRLs in response to CRL CERTREQ messages. A warning about possible interoperability problems probably wouldn't hurt either. brian briank@network-alchemy.com From owner-ipsec@lists.tislabs.com Mon Oct 25 18:22:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21195; Mon, 25 Oct 1999 18:22:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19630 Mon, 25 Oct 1999 20:09:02 -0400 (EDT) Message-Id: <4.2.1.19991025170931.00b6b640@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 25 Oct 1999 17:11:49 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: PKIX Profile for IKE - CA Certificates & IKE Identification Certificates In-Reply-To: <85256815.007933EA.00@d54mta05.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:05 PM 10/25/99 -0400, kunzinge@us.ibm.com wrote: >I propose that we >explicitly define the various types of CA, their roles w/r/t IKE, >and certification hierarchies. My feeling is that this kind of detail should *not* be in the spec. It duplicates definitions from PKIX and the PKIX Roadmap, and introduces synonyms for terms already there. I think the IKE PKI profile should only discuss what's different, not repeat. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 25 18:24:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21270; Mon, 25 Oct 1999 18:24:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19575 Mon, 25 Oct 1999 20:03:16 -0400 (EDT) Message-Id: <4.2.1.19991025163935.00b71100@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 25 Oct 1999 17:06:02 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: "PKIX Profile for IKE"--Is it really a profile? In-Reply-To: <85256815.004C0EE9.00@d54mta05.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA19572 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:52 AM 10/25/99 -0400, kunzinge@us.ibm.com wrote: >1. This draft's purpose is to provide a definitive profile >for a specific way that IKE and PKIX will interoperate. We need >a clear statement that defines what it means to comply with this >draft, versus what it means to comply with the underlying IPSec >and PKIX documents. I fully agree with Charlie on this. Instead of a document that says "here are some PKI issues", I think one that says "there are lots of PKI issues and here's an exact profile that must be met to comply with this spec" is a Very Good Thing. >"This document defines a particular method of using IKE which is more >restrictive than is necessary for compliance with RFC 2459, RFC 2408 >and RFC 2409. It defines a PKIX profile that is more restrictive >than is necessary for compliance with RFC 2459. I would say "different" instead of "more restrictive" because I don't agree with most of the restrictions in the current draft. >2. The current draft offers no definitive, unambiguous requirements >for the profile. In general, it concentrates on high level statements >of what MUST or MUST NOT be done, but it offers no detailed methods for >accomplishing these tasks. Here we disagree. I think the current document is quite definitive and unambiguous in its requirements. I think that some of these requirements will be removed, and other ones will be added. > In reviewing this document, I find that >there are only 6 ?MUSTs? (summarized below), and that none of them >nail down any details. Without details, we have no stake in the >ground on which to base interoperability claims. Again, I disagree. >The current "MUSTs" are: >· MUST check revocation status of certificates on > which an IKE implementation relies In my mind, the details of how to do this should *only* be in the PKIX document. I think it's a bad idea to duplicate the PKIX document, particularly if we are going to subset and make up new terms. >· MUST have a method for receiving up-to-date revocation information Ditto. >· MUST support a signing hierarchy Ditto. >· MUST delete SAs corresponding to certificates that have become invalid I don't think we need any more detail on this given that how SAs are set up is an implementation issue. >· EKU MUST contain only object identifier iKEIntermedate This is pretty clear. >· MUST examine notAfter time in certificates I can't imagine how this could be clearer. >Note also that some of the important details about the operation of IKE >are not addressed in this profile, even though in many cases the existing >IKE specs leave the details open to interpretation. For example, >there is no normative text to outline a profile-specific >method for handling IKE?s CERTIFICATE and CERTIFICATE REQUEST >payloads, Quite correct and this is one of the areas that we *must* address. > there is no normative text to describe certificate >validation in IKE (e.g., what if an evaluating system does not trust >its peer's root CA, Then no validation happens, period. That's fully covered in PKIX. > what are the normative rules for matching a >certificate?s subject to IKE?s ID Payload fields, That's a good question. Many companies have told me that they never intend to match the subject to the IKE initiator. I find that scary, but it's what many people want. I would prefer statements in this profile that say you SHOULD (maybe MUST) match the subject, but that's open for debate. > can a given IKE >implementation recognize more than one root CA, Of course; why not? > what validation steps >are needed for CA certificates of CAs located on a certification >chain, That's fully covered in PKIX and I think should not be duplicated here. > can there be multiple certification chains between an end >entity and its root CA(s) Of course. PKIX doesn't restrict that at all. To me, the current document's biggest hole is the lack of discussion of Certificate and Certificate Request payloads, when they should appear, and what they mean. I'd also like to see some things removed, which I'll discuss in a different messsage. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 25 19:08:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23220; Mon, 25 Oct 1999 19:08:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19697 Mon, 25 Oct 1999 20:42:38 -0400 (EDT) Message-Id: <4.2.1.19991025172654.00b71c80@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 25 Oct 1999 17:44:30 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Query on draft-ietf-ipsec-pki-req-03.txt In-Reply-To: <392A357CE6FFD111AC3E00A0C99848B002242C56@hdsmsx31.hd.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:55 AM 10/19/99 -0700, Walker, Jesse wrote: >The draft includes the following text in Section 2: > IKE systems conforming to this profile MUST check the > revocation statusof any certificate on which they rely, using > the algorithm described inthe PKIX certificate profile. Thus, > every conforming IKE system MUSThave a method for > receiving up-to-date revocation information for thecertificates > it is validating. >What do you intend this to mean in the remote access case? One normal >operational scenario will have the CRL distribution point the remote IPSec >host needs to validate the security gateway's certificate behind the >security gateway. I don't think putting a CRL source (such as an FTP or LDAP server) behind a security gateway is the normal case. The main reason to do that is to hide the identities of the certificates you have revoked (which might have a business purpose). Normally, these are wide open. > In such a case, unless it has already obtained the CRL via >an alternate channel, the remote host will be unable to meet the above >requirement. And, I think that "unless" is exactly right: you must use the information you have. > Seemingly the best that it could be able to do is to establish >IKE and IPSec security associations, then attempt to obtain the CRL, and >then decide what to do on the basis of whether or not it could get the CRL >or the security gateway's cert gets validated. Maybe we need to require >implementations to send the latest CRL known to them during the IKE phase 1 >negotiation? I would be against that because some CRLs will be very large. In the case of a hidden CRL DP, I'd say "you must use what you already know". I think it is good to say "if the device knows that its CRL DP is not currently available to the other party behind a security gateway, that device SHOULD send its CRL". -=-=-=-=-= At 08:06 AM 10/19/99 -0700, Walker, Jesse wrote: >Section 3.2 says > The subject field in IPsec certificates SHOULD be populated and >non-null > (this is contrary to the PKIX certificate profile, which says >thatthe subject > MUST NOT be populated if the identification is in thesubjectAltName > field). The exact contents of this field are notstandardized. By >convention, a > minimal subject field containscountryName and commonName. >Distinguished > names SHOULD be no more thanfour attribute/value pairs, each of >which > SHOULD be no more than 128 characters in length (these restrictions >do > not appear in the PKIXcertificate profile). An IKE implementation >that > conforms to thisprofile SHOULD NOT reject a certificate that does >not > follow theserules. > >Why? The rationale for this requirement is not immediately obvious. Personally, I think it is completely lame. I would like to rip that wholerement out of the spec. Would anyone object to me doing so? That is, has anyone shipped an implementation that is so non-compliant that it *requires* a non-null subject even though there's a subjectAltName? -=-=-=-=-= At 12:28 PM 10/19/99 -0400, Greg Carter wrote: > >From 1. Introduction, first paragraph: > >"Note that many IPsec implementers are not completely happy with the PKIX >documents and procedures, but have agreed to use the PKIX protocols because >they are supported in other contexts and have a significant market share." > >and last paragraph > >"(It is noted that the fact that the two documents differ does not give >great confidence to the IPsec community or other users of the PKIX >protocols.)" > >Both of these, whether or not true, are opinions and don't really do >anything to help implementers beside adding confusion. I would suggest they >be taken out for clarity. Rodney and I put them in to indicate that the reader shouldn't assume that reading the PKIX documentation literally is a good idea. > >From section 3.1 The extendedKeyUsage field: > >"In a certificate for an IPsec end entity, the extendedKeyUsage field >commonly called "EKU") MUST be present and MUST contain only the object >identifier iKEIntermediate >(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or >1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT >accept end-entity certificates that do not follow this rule." > >Why must the certificate only have the one extended key usage? This is too >restrictive. I like the idea of only having one IPSec extended key usage >bit though. Could we stick with PKIX and say that if flagged critical then >it must only have one value. Therefore you could remove the "and MUST >contain only the object identifier iKEIntermediate..." since that would be >covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage >extensions. I agree with this. I can see many reasons why a CA would create a single cert for an IKE system that might have multiple uses. >In Section 3.2 The subjectAltName field, last paragraph: >"The subject field in IPsec certificates SHOULD be populated and non-null >(this is contrary to the PKIX certificate profile, which says that the >subject MUST NOT be populated if the identification is in the subjectAltName >field)" > >This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name >that: > >Further, if the only subject identity included in the certificate is an >alternative name form (e.g., an electronic mail address), then the subject >distinguished name MUST be empty (an empty sequence), and the subjectAltName >extension MUST be present. If the subject field contains an empty sequence, >the subjectAltName extension MUST be marked critical. > >The important phase being "if the ONLY subject identity included in the >certificate is an alternate name form". It does not say "If the alternate >name form is used then NO subject distinguished name may be present." which >is how I read section 3.2. For clarity I would stick with the PKIX >definitions of how subject and alternate names are to be used and remove the >last paragraph. I agree. >If ONLY the alternate name is to be used then the subject should be left >empty as PKIX states. However in practice I do not know of any >implementations that only identify the 'device' by alternate name. For >administration purposes they will always have a subject name, however there >may exist a situation where someone would like to restrict to only using the >alternate name for identification and the only way to do this is with an >empty subject. And here we disagree. How are such CA's identifying an IKE system in the subject? If you mean "kludging the IP address or DNS name into a subject field", I have no problem saying that that MUST NOT be done in this profile. How do others feel about this? >Also in the last paragraph of section 3.2: >"Distinguished names SHOULD be no more than four attribute/value pairs, each >of which SHOULD be no more than 128 characters in length (these restrictions >do not appear in the PKIX certificate profile)." > >Again these are too restrictive. Names in the subject/issuer are dictated >by the customers directory setup (for those using one). In practice I have >seen longer names than 4 attribute/value pairs. Length... well I don't know >much about multi char character sets but I wouldn't want to limit anything >which would prevent IPSec certificates being used in foreign languages. Agree. > >From Appendix A: > >"Regardless of the protocol used, a CA who gets an IKE system's enrollment >request that includes the subject and subjectAltName desired for the device >MUST include exactly the same subject and subjectAltName in the >certificate. If the CA does not want to issue a certificate with the same >subject and subjectAltName that was requested, the CA MUST NOT issue a >certificate with a different name and subjectAltName." > >This places an unnecessary burden on the end entity to determine what >exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change >the DN that is in the request. If the device must have the exact DN then it >means a user somewhere has to type it in, very prone to failure. I agree. I think we should take out that restriction. If the IKE system doesn't like the cert it gets (for example, because the CA changed the subject or subjectAltName), the system doesn't have to use that cert. > Also there >is no mention of how to verify the request at the CA. The device should >generate a hash of the der encoded request and make it available to the >devices administrator for verification at the CA. Otherwise the request is >accepted without verification. This makes sense to me, and could be part (obviously) of the out-of-band info. > Also mention of how to obtain the CAs keys >in a secure way, similarly usually done with a hash of the CAs der encoded >certificate. May want to add this to the security section?... This could be added. It's covered in PKIX, but yet another paragraph in the security section is always safe... --Paul Hoffman, Director --VPN Consortium From ???@??? Tue Oct 26 07:22:46 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10460; Tue, 26 Oct 1999 00:53:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA20298 Tue, 26 Oct 1999 02:25:29 -0400 (EDT) Message-Id: <3.0.5.32.19991025233149.0108c7b0@10.1.10.20> X-Sender: fletcher@10.1.10.20 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 25 Oct 1999 23:31:49 -0700 To: "Scott G. Kelly" , Dan McDonald From: fletcher@cylink.com (Fergus Fletcher) Subject: AH as a Transport protocol Cc: ipsec@lists.tislabs.com In-Reply-To: <38109203.97628615@redcreek.com> References: <199910220609.XAA05952@kebe.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: a8d354768cf4a317b3fca4fc5f3e0962 Scott, >Dan McDonald wrote: >> >> While not listed in 2401 explicitly, couldn't one use ICMP/ICMPv6 type and >> code as a selector for a security association? The implementation wouldn't >> be that tough; just overload the already-there port fields for type and code. > > Scott G. Kelly wrote: > >...or generalize the port fields into some sort of protocol-specific >selectors or something. That way, we could use type/code for icmp, SPI >for esp/ah, etc... ^^^ Your E-mail reminds me of an issue I wondered about a while back. RFC-2401 seems to indicate that AH is not a transport protocol, and then if an AH is encountered, the IP header should be parsed further until either a transport protocol or an ESP header is located. However I can see it being useful to be able to use PROTOCOL=AH in the SPD to check that traffic is authenticated, but I realize that there is a conflict in permitting this and looking for the "real" transport protocol. Would anyone like to comment on what some real VPN products do ? Thanks, Fergus Fletcher From ???@??? Tue Oct 26 07:22:46 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14698; Tue, 26 Oct 1999 02:03:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA20656 Tue, 26 Oct 1999 03:28:17 -0400 (EDT) Date: Tue, 26 Oct 1999 10:30:46 +0300 (EET DST) From: Markku Savela Message-Id: <199910260730.KAA15060@anise.tte.vtt.fi> To: kunzinge@us.ibm.com CC: ipsec@lists.tislabs.com In-reply-to: <85256815.007933EA.00@d54mta05.raleigh.ibm.com> (kunzinge@us.ibm.com) Subject: Re: PKIX Profile for IKE - CA Certificates & IKE Identification Certificates Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 65b8af9e86acc2c762feb5b46f2e810c Maybe somewhat offtopic, but... here gose: I have a problem understaning the certificate path. Say, peer sends CA-0 -> CA-x -> CA-y -> CA-z(identity) We trust CA-0, we have a path from CA-z to CA-0, but so what? Unless we trust CA-y, CA-z and 'identify' could be anything at all. CA-y could be any of the millions of entities that have a valid signed certificate on rooting on CA-0. To me it seems that the path is only usable, if we already trust all intermediates. But then, what do we need the path for? [Just to find the culprits after the damage has occurred?] I must be missing some point... -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From ???@??? Tue Oct 26 08:16:38 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27386; Tue, 26 Oct 1999 07:20:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21695 Tue, 26 Oct 1999 08:30:13 -0400 (EDT) Message-ID: <38159744.687A40F4@checkpoint.com> Date: Tue, 26 Oct 1999 13:57:56 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Brian Korver , Derrell Piper , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <199910251836.LAA27461@potassium.network-alchemy.com> Content-Type: multipart/mixed; boundary="------------EA2CDD16CDEFA5BB39F5A2C0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 01c114f2eff7d30077f18713a8a0d9be Dan, Dan Harkins wrote: > > Considering this, anyone who comes up with a new proposal should > > justify going back a year in the process and starting all over again. > > I don't see this as starting the process over again. The process is just > getting started, hence the IPSRA. IPRSA is a new title. But the subject is old, and most of the people involved today in IPRSA where involved last year in IPSEC. I don't know of any product out there that implements hybrid, but there are some on the way. What are the developers supposed to say to their sales and marketing staff, who are pressuring them as they did to you? Are they supposed to say "The IETF workgroup changed title and now there is a very similar (but incompatible) draft, in a few month it will be stable enough to start implement it. In the mean time forget about the product, but if anything goes well, and the work group won't change title again we would have a product by 2001" > > What I do see, is an overhead of public key operations, including a > > signing/verifying action on the server and (RSA) key generation + > > signing/verifying on the client. > > Any extra work on the server side must be justified. > > Security is not free. > Indeed security is not free, but you don't gain security from piling up cryptographic primitives. If you think that the additional operation provides better security you will have to justify it. It is not clear to me why the additional public key of the client add to the security of the protocol. > > > On the other hand I see several drawbacks, the biggest one is that it is > > susceptible to a trivial DoS attack (as already mentioned by Yael). In a > > protocol designed for roaming clients, where no IP address based > > filtering is possible this is a show stopper. > > > > On top of this, a good protocol designed for client use ought to support > > error messages in human readable format, as well as error codes. CRACK > > forbids the former and does not specify the latter. > > I don't understand. Can you point out where this is forbidden and perhaps > show where error codes are specified in the "good protocol"? > Section 3.2 IKE Challenge/Response Authentication Failures, the notification does not include a space for a user readable message (in fact the length of the notification is fixed). On the other the only place to give a specific error code the status field is specifically set as private. As an example of a good protocol, look at ftp (or http) which has a numeric error code designed for machine consumption, and an additional text to be read by humans. > > > The draft is full of minor issues. As Dan said this is only a 00-draft, > > but why do we need this when we have a mature protocol in hand? > > I wish you'd bring up the minor issues then. > The minor issues are not my point. My point is that CRACK should be rejected not because it is a bad protocol (it is not bad, though it must be improved). CRACK should be rejected because it does not provide enough benefits to the existing protocol. > > And I don't think we have a mature protocol in hand. Last week I talked to > a representative of another company who claimed "full compliance" with the > "draft standard RFC". It turns out he only does radius, does not do Hybrid, > and I know he's not interoperable with another vendor who also does the > same thing. > > Part of the problem with the ISAKMP-Config+XAUTH+Hybrid approach is that > it leaves XAUTH as a separate entity. This protocol by itself is fundamentally > broke. The problems are addressed with the addition of Hybrid but it is > not required to do Hybrid. As a result people do an unauthenticated Diffie- > Hellman and a radius exchange on top of that and claim compliance to a "draft > standard RFC". All the time excusing it away with the remark that their > customers don't really want strong security. I must've missed it when the > requirements from a company's marketing department became part of a WG > charter. > > If XAUTH and Hybrid were combined into a single draft which, basically, > forbade the common XAUTH practice it would be another story. It would be > the "Extended Hybrid Authentication" solution vs. CRACK and I would be > hardpressed to say which one is the "best". But then again, we're back to > square one. > > Dan. Until now there where two point in favor of CRACK: 1. One phase negotiation 2. One document. As for the one document argument, as you noted, can be solved by an editorial act of combining the two draft together. We have no objection to this, and if the working group and the authors of XAUTH would want to, we can do this, and sill have the protocol intact. The first argument is real, but it is mainly aesthetic, and does not constitutes a good enough reason to throw all the work done so far. Moshe Attachment Converted: "C:\Temp\moshe2.vcf" From ???@??? Tue Oct 26 07:22:46 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26879; Tue, 26 Oct 1999 06:54:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21623 Tue, 26 Oct 1999 08:16:22 -0400 (EDT) Message-ID: <38159C1F.A5310B63@cyphers.net> Date: Tue, 26 Oct 1999 05:18:48 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.61 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Moshe Litvin CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <199910251836.LAA27461@potassium.network-alchemy.com> <38159744.687A40F4@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 7af9800380c518f3af80cb9a9052e950 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moshe Litvin wrote: > I don't know of any product out there that implements hybrid, but > there are some on the way. What are the developers supposed to say > to their sales and marketing staff, who are pressuring them as they > did to you? Are they supposed to say "The IETF workgroup changed > title and now there is a very similar (but incompatible) draft, in > a few month it will be stable enough to start implement it. In the > mean time forget about the product, but if anything goes well, and > the work group won't change title again we would have a product by > 2001" Marketing decisions are totally irrelevant to this group. The goal of this group is to do the right thing for the infrastructure. I think the correct thing to say is "Our engineering group made a mistake and promised to ship a protocol hack which just wasn't ready. That protocol hack has now been effectively shelved in the IETF in favor of a much better proposal. If we try to ship the old stuff, we will not be compatible with anybody else now or in the future. We will now modify our goals to implement the better proposal and after we test it at bakeoffs and things settle down, we'll tell you when it can ship." > The minor issues are not my point. My point is that CRACK should be > rejected not because it is a bad protocol (it is not bad, though it > must be improved). CRACK should be rejected because it does not > provide enough benefits to the existing protocol. I think you're underestimating the problems of the mode-cfg/xauth flaws which have been extensively discussed here and in the new drafts. > > And I don't think we have a mature protocol in hand. Last week I > > talked to a representative of another company who claimed "full > > compliance" with the "draft standard RFC". It turns out he only > > does radius, does not do Hybrid, and I know he's not > > interoperable with another vendor who also does the same thing. > > > > Part of the problem with the ISAKMP-Config+XAUTH+Hybrid approach > > is that it leaves XAUTH as a separate entity. This protocol by > > itself is fundamentally broke. The problems are addressed with > > the addition of Hybrid but it is not required to do Hybrid. As a > > result people do an unauthenticated Diffie- Hellman and a radius > > exchange on top of that and claim compliance to a "draft standard > > RFC". All the time excusing it away with the remark that their > > customers don't really want strong security. I must've missed it > > when the requirements from a company's marketing department > > became part of a WG charter. > > > > If XAUTH and Hybrid were combined into a single draft which, > > basically, forbade the common XAUTH practice it would be another > > story. It would be the "Extended Hybrid Authentication" solution > > vs. CRACK and I would be hardpressed to say which one is the > > "best". But then again, we're back to square one. > > > > Dan. > > Until now there where two point in favor of CRACK: > 1. One phase negotiation > 2. One document. > > As for the one document argument, as you noted, can be solved by an > editorial act of combining the two draft together. We have no > objection to this, and if the working group and the authors of > XAUTH would want to, we can do this, and sill have the protocol > intact. > > The first argument is real, but it is mainly aesthetic, and does > not constitutes a good enough reason to throw all the work done so > far. I don't think we're throwing out work. All work done so far was experimental with the goal of reaching a good solution. This experimentation has led to the discovery of various serious flaws in the mode-cfg/xauth solution. These flaws are now being corrected in a solution which builds on what has been learned. My feeling is that those who are complaining now are doing so for marketing reasons rather than doing the Right Thing for security and the protocol. - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBOBWcB6y7FkvPc+xMEQKIWACdE3veqzInavV9nO9AdKzE91fakEoAmgJa Ag73xZzv2mvSL6kSEsS7mi6a =vpmX -----END PGP SIGNATURE----- From ???@??? Tue Oct 26 09:40:01 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00337; Tue, 26 Oct 1999 09:27:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22022 Tue, 26 Oct 1999 09:56:10 -0400 (EDT) Message-ID: <3815B15F.D0CDA363@checkpoint.com> Date: Tue, 26 Oct 1999 15:49:19 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: wprice@cyphers.net CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <199910251836.LAA27461@potassium.network-alchemy.com> <38159744.687A40F4@checkpoint.com> <38159C1F.A5310B63@cyphers.net> Content-Type: multipart/mixed; boundary="------------1E0CB30BC544F4021F4F3783" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 18a595fe6d76e75b95e4699da4ba394d Will Price wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Moshe Litvin wrote: > > I don't know of any product out there that implements hybrid, but > > there are some on the way. What are the developers supposed to say > > to their sales and marketing staff, who are pressuring them as they > > did to you? Are they supposed to say "The IETF workgroup changed > > title and now there is a very similar (but incompatible) draft, in > > a few month it will be stable enough to start implement it. In the > > mean time forget about the product, but if anything goes well, and > > the work group won't change title again we would have a product by > > 2001" > > Marketing decisions are totally irrelevant to this group. The goal > of this group is to do the right thing for the infrastructure. I > think the correct thing to say is "Our engineering group made a > mistake and promised to ship a protocol hack which just wasn't ready. > That protocol hack has now been effectively shelved in the IETF in > favor of a much better proposal. If we try to ship the old stuff, we > will not be compatible with anybody else now or in the future. We > will now modify our goals to implement the better proposal and after > we test it at bakeoffs and things settle down, we'll tell you when it > can ship." You would have been right if CRACK had any significant advantage over hybrid. But it doesn't. Therefor starting from scratch will only make the workgroup give a very similar protocol with a year (or more) delay. Changing a draft because a better proposal arrive is one thing. But throwing away a draft after one year because a slightly different one arrive is another. > > The minor issues are not my point. My point is that CRACK should be > > rejected not because it is a bad protocol (it is not bad, though it > > must be improved). CRACK should be rejected because it does not > > provide enough benefits to the existing protocol. > > I think you're underestimating the problems of the mode-cfg/xauth > flaws which have been extensively discussed here and in the new > drafts. > > > > And I don't think we have a mature protocol in hand. Last week I > > > talked to a representative of another company who claimed "full > > > compliance" with the "draft standard RFC". It turns out he only > > > does radius, does not do Hybrid, and I know he's not > > > interoperable with another vendor who also does the same thing. > > > > > > Part of the problem with the ISAKMP-Config+XAUTH+Hybrid approach > > > is that it leaves XAUTH as a separate entity. This protocol by > > > itself is fundamentally broke. The problems are addressed with > > > the addition of Hybrid but it is not required to do Hybrid. As a > > > result people do an unauthenticated Diffie- Hellman and a radius > > > exchange on top of that and claim compliance to a "draft standard > > > RFC". All the time excusing it away with the remark that their > > > customers don't really want strong security. I must've missed it > > > when the requirements from a company's marketing department > > > became part of a WG charter. > > > > > > If XAUTH and Hybrid were combined into a single draft which, > > > basically, forbade the common XAUTH practice it would be another > > > story. It would be the "Extended Hybrid Authentication" solution > > > vs. CRACK and I would be hardpressed to say which one is the > > > "best". But then again, we're back to square one. > > > > > > Dan. > > > > Until now there where two point in favor of CRACK: > > 1. One phase negotiation > > 2. One document. > > > > As for the one document argument, as you noted, can be solved by an > > editorial act of combining the two draft together. We have no > > objection to this, and if the working group and the authors of > > XAUTH would want to, we can do this, and sill have the protocol > > intact. > > > > The first argument is real, but it is mainly aesthetic, and does > > not constitutes a good enough reason to throw all the work done so > > far. > > I don't think we're throwing out work. All work done so far was > experimental with the goal of reaching a good solution. This > experimentation has led to the discovery of various serious flaws in > the mode-cfg/xauth solution. These flaws are now being corrected in > a solution which builds on what has been learned. > Aside from the two stated flows, which others are you referring to? I belive that most of the objection is for XAUTH. That is some people are against hybrid because hybrid give justification for XAUTH, which when used without hybrid is bad. I don't consider it as a valid argument for replacing hybrid. > My feeling is that those who are complaining now are doing so for > marketing reasons rather than doing the Right Thing for security and > the protocol. You are implying that CRACK is more secure hybrid. A fact that needs a proof. Supplying such proof will be hard considering that CRACK is more susceptible to DoS attack. As for the accusation of complaining about CRACK for marketing reasons, the opposite can also be made about companies who noticed lately that they don't have a solution and now try to artificially delay everyone else to their pace. I suggest that we will avoid such accusations, and concentrate on the goal, which is to provide a good protocol (and just to be clear - I am NOT accusing anybody, in fact I am pretty sure that this was not the intent of CRACK authors). Hybrid is not only more mature, it is also more secure, flexible and efficient. Moshe Attachment Converted: "C:\Temp\moshe.vcf" From ???@??? Tue Oct 26 09:40:01 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00278; Tue, 26 Oct 1999 09:24:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22190 Tue, 26 Oct 1999 10:38:41 -0400 (EDT) Date: Tue, 26 Oct 1999 17:41:14 +0300 (EET DST) Message-Id: <199910261441.RAA03451@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Dan Harkins Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, skelly@redcreek.com Subject: CRACK In-Reply-To: <199910211619.JAA15266@potassium.network-alchemy.com> References: <199910211619.JAA15266@potassium.network-alchemy.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 41 min X-Total-Time: 47 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: d3184edb6cc3859d9e144b547ac63e87 Dan Harkins writes: > does not yet formally exist. Please check it out and comment. It's > called draft-harkins-ipsec-ike-crack-00.txt and can be found with the > others at http://www.ietf.cnri.reston.va.us/internet-drafts. Here are my comments. > 3.1 IKE Challenge/Response Abstract Representation > ... > key respectively, over an authenticating digest. This digest is the > prf output (see [HC98]) using SKEYID_a as a key and a hash (using the > negotiated hash function) of all packets sent in the protocol, not > including the current exchange, excluding retransmissions, and prior > to encryption (or after decryption), when applicable. It should also state here whether or not the padding added before encryption is removed before hash calculation or not. The problem of course is that the received packet length contains the padding, and finding out the original length without padding requires some work. To find that out you need to check the payload chain and check how many extra bytes there are after the final payload. > 3.2 IKE Challenge/Response Authentication Failures > ... > The Notification Payload MUST have the following format: > ... > with the following "Notification Data": > > o LAM Type (two octets) - set to the LAM Type the server requires > for the client; MAY be different than the LAM Type specified in > any CHRE payloads if the server required a different LAM Type > than what was offered > o RESERVED (two octets) - MUST be zero (0) (alignment) > o Status (four octets) - authentication failure status (private to > the implementation); SHOULD be omitted when unused I would suggest format similar that is in the draft-ietf-ipsec-notifymsg-01.txt instead. I.e use ISAKMP data attributes inside the notify data, and reserve some new attribute classes for those new values (LAM type, and status). I am not sure what the Status is used for, and is it really needed? Perhaps we should reserve space from the attribute class numbering space in the notifymsg draft for exchange specific attributes. I.e those values are defined in the drafts defining the new exchanges. > 4.2 LAM Attributes > ... > CRACK_MESSAGE specifies an ASCII string to be displayed to the user > upon receipt of the corresponding CHRE payload. CRACK_MESSAGE is > valid for all LAM types. Upon receipt, the contents of > CRACK_MESSAGES SHOULD be displayed to the client user, typically > along with the CHRE challenge. I think the BCP18 (RFC2277) states, that you MUST define charset for all character data, and you MUST be able to use UTF-8 charset. So I think it is against that RFC to say that CRACK_MESSAGE is an ASCII string. Changing it to "ISO-10646 UTF-8 string" should fix this issue. Also we may want to add "standard" warning about escape/control characters (from the draft-ietf-secsh-architecture-04.txt): ---------------------------------------------------------------------- When displaying text, such as error or debug messages to the user, the client software SHOULD replace any control characters (except tab, carriage return and newline) with safe sequences to avoid attacks by sending terminal control characters. ---------------------------------------------------------------------- Also another think about the message is the language of the message. The BCP18 says that "Protocols that transfer text MUST provide for carrying information about the language of that text." So I think we need: ---------------------------------------------------------------------- ... CRACK_MESSAGE_LANGUAGE 16388 variable ... CRACK_MESSAGE_LANGUAGE contains the RFC 1766 language tag of the language of the CRACK_MESSAGE field. If this attribute is not present then English is assumed. ---------------------------------------------------------------------- > 5.1 LAM Profiles: Password > ... > Where the digest that is signed (resulting in SIG2 and SIG3) is: > > digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr | > KEr | SIG1 | Nr | HDR3 | CHRE1 | PK > [ | HDR4 | SIG2 ])) I think you should also say here something like this: ---------------------------------------------------------------------- The order of the payloads in the prf is the exactly the same order they appeared in the packets, and because the order of payloads inside the isakmp packet is not fixed, the actual prf-calculation may not match this example above. Also if the exchanges includes any other payloads (notification, vendor-id, certificate request, certificates etc) they are also calculated into the prf. ---------------------------------------------------------------------- Also I don't think it is usefull to duplicate the digest calculation in all examples, I think it is enough to have it only once, and refer to it later. > 5.3 LAM Profiles: Challenge/Response > ... > The CHRE2 payload contains the gateway's challenge > text which MUST be displayed to the client user. I think the MUST there is too strong, now this would rule out all the systems that process the challenge automatically, because this one here requires the software to show the text to user :-) > 7. Security Considerations > > The channel that results from the exchange of the first two messages > is secured because the gateway signs his Diffie-Hellman public value > and it is the resulting SKEYID state (see [HC98]) that protects the > channel. The client, though, does not sign his Diffie-Hellman public I think it is too weak to only sign the Diffie-Hellman public value, because that does not bind the signature to the current client. This means that somebody might take the signature, Diffie-Hellman public key, and start cracking the public key. After he cracks the Diffie-Hellman public key, he can act as a server for the any new clients, and the clients will only know that something is wrong when the server is not able to generate SIG2 later. This is fixed very easily by saying that the SIG1 is signature of the hash of the concatenation of the Ni, Nr, KEi and KEr like this: hash1 = HASH(Ni | Nr | KEi | KEr) using the negotiated hash algorithm. This kind of modification would make sure that the SIG1 is always tied to the current client, and cannot be reused later. One big advantage of this draft is that it really fixes that problem of normal IKE exchanges that generic header and extra payloads are not authenticated. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ???@??? Tue Oct 26 10:24:57 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01292 for ; Tue, 26 Oct 1999 10:15:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22429 Tue, 26 Oct 1999 11:38:10 -0400 (EDT) From: Pat.Calhoun@Eng.Sun.Com (Patrice Calhoun) Message-Id: <199910261540.IAA27127@ha1mpk-mail.eng.sun.com> Date: Tue, 26 Oct 1999 08:37:47 -0700 To: "Moshe Litvin" , "Dan Harkins" Cc: , , "Derrell Piper" , "Brian Korver" Reply-To: Subject: Re: Comments on CRACK X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 6d666e3015bd9c5eb440e11cd35a4b2d >Section 3.2 IKE Challenge/Response Authentication Failures, the notification >does >not include a space for a user readable message (in fact the length of the >notification is fixed). On the other the only place to give a specific error >code >the status field is specifically set as private. > >As an example of a good protocol, look at ftp (or http) which has a numeric >error >code designed for machine consumption, and an additional text to be read by >humans. > For what it's worth, I think that IKE has already passed the point where it can be debugged by humans. Certainly a string cannot hurt, but one would have to parse through so many other potential problems, that I fail to see this addition as being a big plus. That said, the PPP world has long suffered from the problem in Windows where strings from protocols are NOT displayed to users. I suppose this MAY change sometime in the future, but if the client is running windows, that string will hit /dev/null. PatC From ???@??? Tue Oct 26 11:21:18 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02292 for ; Tue, 26 Oct 1999 11:07:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22454 Tue, 26 Oct 1999 11:45:15 -0400 (EDT) Message-ID: <3815CD24.5FF0E0EC@redcreek.com> Date: Tue, 26 Oct 1999 08:47:48 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Fergus Fletcher CC: Dan McDonald , ipsec@lists.tislabs.com Subject: Re: AH as a Transport protocol References: <199910220609.XAA05952@kebe.Eng.Sun.COM> <3.0.5.32.19991025233149.0108c7b0@10.1.10.20> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 2321043c11102c10fa1b1a16d1869697 Fergus Fletcher wrote: > Your E-mail reminds me of an issue I wondered about a while > back. RFC-2401 seems to indicate that AH is not a > transport protocol, and then if an AH is encountered, the IP > header should be parsed further until either a transport protocol > or an ESP header is located. > > However I can see it being useful to be able to use PROTOCOL=AH in the SPD > to check that traffic is authenticated, but I realize that there is a > conflict in permitting this and looking for the "real" transport protocol. > > Would anyone like to comment on what some real VPN products do ? > I've opined on this in the past: while I believe that AH more closely resembles IP options than a transport protocol (whereas ESP looks like a transport protocol to me), I too think these protocols should be (and are) valid selectors. The problem is, we don't yet have protocol-specific selectors defined for anything other than TCP/UDP. I think Steve Kent has invited us to spell out the requirements we envision for other protocols. Taking that bait, I'll offer local/remote SPIs for ESP/AH. Scott From ???@??? Tue Oct 26 10:28:47 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01421 for ; Tue, 26 Oct 1999 10:24:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22492 Tue, 26 Oct 1999 11:59:07 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEC97E6@exchange> From: Stephane Beaulieu To: Dan Harkins , Moshe Litvin Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comments on CRACK Date: Tue, 26 Oct 1999 12:04:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 27c0b3aa169e5b03222e3763adc26660 Hi Dan, > > But you're right. The phase 1.5 "limbo" state of the IKE SA > is a hack. It > screws up the state machine for no reason. Some SAs > transition to phase 2 > immediately and some have to wait around for more stuff to happen. It may not be the most optimal way of doing it, but it was the path of less resistance about a year ago. It also has some advantages in that it can be used with Main Mode, Aggressive Mode, and any other new mode (ex. Base Mode, Hybrid). The state machine is actually pretty simple. Phase 1 XAUTH [based on authentication method negotiated] Isakmp-Cfg [optional] Phase 2 > > Part of the problem with the ISAKMP-Config+XAUTH+Hybrid > approach is that > it leaves XAUTH as a separate entity. This protocol by itself > is fundamentally > broke. The problems are addressed with the addition of Hybrid > but it is > not required to do Hybrid. As a result people do an > unauthenticated Diffie- > Hellman and a radius exchange on top of that and claim > compliance to a "draft > standard RFC". All the time excusing it away with the remark > that their > customers don't really want strong security. I must've missed > it when the > requirements from a company's marketing department became > part of a WG > charter. > I beg to differ. XAUTH is not "broke". XAUTH fully accomplishes what it intended to do. >From the XAUTH draft... "The purpose of this draft is not to replace or enhance the existing authentication mechanisms described in [IKE], but rather to allow them to be extended using legacy authentication mechanisms." XAUTH has indeed accomplished this. No one has uncovered any security flaws with XAUTH itself as a protocol. There is one point that has been brought up which I would like to debate. -The use of XAUTH with pre-shared keys only encourages the use of weak pre-shared keys. My problem with this is that this seems like a security administrators job to ensure that the strength of the authentication mechanisms be well chosen and secure. There's a lot of ways that an administrator could shoot himself in the foot. I know that doesn't justify giving them one more bullet to shoot themselves with. However, I would like to hear everyone else's opinion on this. Should the use of pre-shared keys be restricted in XAUTH (or whatever other protocol) because it encourages the use of weak pre-shared keys? If there is concensus, pre-shared keys can be removed from XAUTH. I don't think that we have concensus at this point. As for CRACK... What is the benefit of the Client's PK? It seems to me that the Gateway trusts the PK's origin because it is sent over a secure channel, and because it is authenticated by the CHRE exchanges. Then, the Client further authenticates himself by using his private key to sign the exchange. I don't see the point of this. It's like saying tell me a question and the answer to that question. Then I'll ask you the question and make sure you have the right answer. I know that's oversimplifying it. Am I missing something... what does it accomplish? I think what we all want is a secure interoperable way of doing legacy authentication as a migration path to PKIs. I don't see what advantages CRACK is presenting over Hybrid/XAUTH (aside from preventing pre-shared keys). I do see CRACK as a set-back. People already have working implementations of Hybrid and XAUTH. Some of us have this in released builds in the field. Some people have already tested interop. at the bakeoff. So unless someone can state that Hybrid and XAUTH are truly broken, then I don't see the point in changing it at this point in the game. Thanks, Stephane. From ???@??? Tue Oct 26 11:21:18 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02096 for ; Tue, 26 Oct 1999 11:02:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22661 Tue, 26 Oct 1999 12:32:26 -0400 (EDT) Message-Id: <4.2.1.19991026092935.0302c5b0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 26 Oct 1999 09:35:09 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt In-Reply-To: <199910252335.QAA22688@antimony.network-alchemy.com> References: <01E1D01C12D7D211AFC70090273D20B10197D71C@sothmxs06.entrust.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 5b754bf968c16b68fe7fd41a366a21e9 At 04:35 PM 10/25/99 -0700, Brian Korver wrote: >Why require that extendedKeyUsage be mandatory at all? To identify the cert as being for IKE. I've been told that today's IKE systems use this OID as identification. I believe we should have *one* OID for all IKE implementations, and not try to slice and dice between "client" and "gateway" and so on. Are there any IPsec implementations using the IPsec OIDs specified in RFC 2459? Are there any implementations that require the use of other OIDs, like IKEend (1.3.6.1.5.5.8.2.1)? --Paul Hoffman, Director --VPN Consortium From ???@??? Tue Oct 26 15:09:45 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06554 for ; Tue, 26 Oct 1999 14:48:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22969 Tue, 26 Oct 1999 13:06:13 -0400 (EDT) Message-ID: <3815D878.CC16A5BA@checkpoint.com> Date: Tue, 26 Oct 1999 18:36:08 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: Dan Harkins , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC97E6@exchange> Content-Type: multipart/mixed; boundary="------------928609DF8F94380ADDF23DCA" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 7b97fe8baf9e96fd9250c7eed50085e1 Stephane Beaulieu wrote: > However, I would like to hear everyone else's > opinion on this. Should the use of pre-shared keys be restricted in XAUTH > (or whatever other protocol) because it encourages the use of weak > pre-shared keys? > > If there is concensus, pre-shared keys can be removed from XAUTH. I don't > think that we have concensus at this point. Maybe we can reach a consensus by forbidding group pre-shared keys? Moshe Attachment Converted: "C:\Temp\moshe2.vcf" From ???@??? Tue Oct 26 11:21:18 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02116 for ; Tue, 26 Oct 1999 11:03:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22690 Tue, 26 Oct 1999 12:36:31 -0400 (EDT) Message-Id: <4.2.1.19991026093625.030391d0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 26 Oct 1999 09:39:14 -0700 To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org From: Paul Hoffman Subject: Re: CRACK In-Reply-To: <199910261441.RAA03451@torni.ssh.fi> References: <199910211619.JAA15266@potassium.network-alchemy.com> <199910211619.JAA15266@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 788a88f4a086850887806a5559e1323d At 05:41 PM 10/26/99 +0300, Tero Kivinen wrote: >I think the BCP18 (RFC2277) states, that you MUST define charset for >all character data, and you MUST be able to use UTF-8 charset. So I >think it is against that RFC to say that CRACK_MESSAGE is an ASCII >string. Changing it to "ISO-10646 UTF-8 string" should fix this issue. A better way is to just say UTF-8 and reference RFC 2279 (which is about to go from Proposed to Draft standard). >Also we may want to add "standard" warning about escape/control >characters (from the draft-ietf-secsh-architecture-04.txt). There's a similar warning in RFC 2279 that is specific to UTF-8. --Paul Hoffman, Director --VPN Consortium From ???@??? Tue Oct 26 13:57:39 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05556 for ; Tue, 26 Oct 1999 13:54:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22832 Tue, 26 Oct 1999 12:53:31 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEC9812@exchange> From: Stephane Beaulieu To: wprice@cyphers.net, Moshe Litvin Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comments on CRACK Date: Tue, 26 Oct 1999 12:55:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 4e5f34b26338662d1754a0f66c813041 Hi Will, > I think you're underestimating the problems of the mode-cfg/xauth > flaws which have been extensively discussed here and in the new > drafts. What would those be? I've heard... 1 - It encourages the use of weak pre-shared keys. - Perhaps, but this can easily be fixed in XAUTH. I would still like to get a concensus on this. 2 - It's too complicated to be secure... Please ! 3 - Too much known plain text. - All three proposals (XAUTH, CRACK, and ULA have know plain text. 4 - It's too tightly bound to Cfg. Cfg is a simple protocol. Why invent a new protocol when one already exist which meets your needs. I see nothing here that warrants killing a protocol that is currently being developped, and even deployed by a significant amount of vendors. > I don't think we're throwing out work. All work done so far was > experimental with the goal of reaching a good solution. This > experimentation has led to the discovery of various serious flaws in > the mode-cfg/xauth solution. These flaws are now being corrected in > a solution which builds on what has been learned. > > My feeling is that those who are complaining now are doing so for > marketing reasons rather than doing the Right Thing for security and > the protocol. Maybe you're not throwing out work, but many vendors would be... for no good reason ! Once again, if a serious flaw were found in XAUTH and/or Cfg, that couldn't be easily corrected, then I could see a reason to change paths. However, at this point, I don't see that. Thanks, Stephane. From ???@??? Tue Oct 26 14:45:16 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06109 for ; Tue, 26 Oct 1999 14:25:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22872 Tue, 26 Oct 1999 12:56:21 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEC9820@exchange> From: Stephane Beaulieu To: Moshe Litvin , Stephane Beaulieu Cc: Dan Harkins , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comments on CRACK Date: Tue, 26 Oct 1999 12:59:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: c7ca00af0ce42e12005a5dd35246eef0 Perhaps, although some have argued that this would be redundant. Admins would have to maintain 2 databases (SS+RADIUS). If we do feel that adding this restriction adds security, then shouldn't IKE do the same? Stephane. > -----Original Message----- > From: Moshe Litvin [mailto:moshe@checkpoint.com] > Sent: Tuesday, October 26, 1999 12:36 PM > To: Stephane Beaulieu > Cc: Dan Harkins; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org > Subject: Re: Comments on CRACK > > > Stephane Beaulieu wrote: > > > > > However, I would like to hear everyone else's > > opinion on this. Should the use of pre-shared keys be > restricted in XAUTH > > (or whatever other protocol) because it encourages the use of weak > > pre-shared keys? > > > > If there is concensus, pre-shared keys can be removed from > XAUTH. I don't > > think that we have concensus at this point. > > Maybe we can reach a consensus by forbidding group pre-shared keys? > > Moshe > From ???@??? Tue Oct 26 15:28:38 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06850 for ; Tue, 26 Oct 1999 15:06:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22920 Tue, 26 Oct 1999 13:02:48 -0400 (EDT) Message-ID: <3815DF51.B98C7F62@redcreek.com> Date: Tue, 26 Oct 1999 10:05:21 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Moshe Litvin , Tero Kivinen CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <199910251836.LAA27461@potassium.network-alchemy.com> <38159744.687A40F4@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: e0fd4f3720bf700e770ca75d7f8fb151 Moshe Litvin wrote: > Section 3.2 IKE Challenge/Response Authentication Failures, the notification does > not include a space for a user readable message (in fact the length of the > notification is fixed). On the other the only place to give a specific error code > the status field is specifically set as private. > > As an example of a good protocol, look at ftp (or http) which has a numeric error > code designed for machine consumption, and an additional text to be read by > humans. Tero commented somewhat on this, but I'd like to add to it. The original impetus behind the notifymsg draft was to come up with standardized text messages with numeric codes in a style similar to that of ftp, smtp, http, etc. This was suggested by Bob Moskowitz on numerous occasions. My first impression was that the codes would need to be a bit longer than 3 digits, but I was just beginning to seriously consider the matter. About that time I spoke with Charlie Kunzinger, who suggested to me that we badly needed standardized notify message payloads, and this altered the course of the draft a bit. In Oslo, it was suggested that we should at least discuss the efficacy of such standardized messages or codes, either within the context of the notifymsg draft or independently. I had intended to bring this up in DC next month, so Moshe's comments are timely. The current notifymsg draft suggests optional error text in many of the messages. It is possible that we might want to come up with standard text and codes, in which case transmission of the codes would suffice in many cases. I am just beginning to give this some thought. If anyone has specific suggestions along these lines, please send comments to Tero and me. Scott From ???@??? Tue Oct 26 14:45:16 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06130 for ; Tue, 26 Oct 1999 14:26:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22990 Tue, 26 Oct 1999 13:09:40 -0400 (EDT) Message-ID: <3815E0ED.F8C11745@redcreek.com> Date: Tue, 26 Oct 1999 10:12:13 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: wprice@cyphers.net, Moshe Litvin , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC9812@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 6537f648b22497247ea789e048a875b6 Stephane Beaulieu wrote: > What would those be? > > I've heard... > > 1 - It encourages the use of weak pre-shared keys. - Perhaps, but this can > easily be fixed in XAUTH. I would still like to get a concensus on this. This "easy" fix requires deployment of client certificates. > 2 - It's too complicated to be secure... Please ! Prove to me that it's secure. Better review your predicate logic first... > 3 - Too much known plain text. - All three proposals (XAUTH, CRACK, and ULA > have know plain text. None have the copious amounts of ASCII TEXT that xauth does. Some known plaintext may be unavoidable, but xauth has a ridiculous amount. > 4 - It's too tightly bound to Cfg. Cfg is a simple protocol. Why invent a > new protocol when one already exist which meets your needs. You mean dhcp, right? From ???@??? Tue Oct 26 14:45:16 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06208 for ; Tue, 26 Oct 1999 14:31:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23336 Tue, 26 Oct 1999 14:14:37 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 26 Oct 1999 11:14:17 -0700 (PDT) From: Jan Vilhuber To: Stephane Beaulieu cc: Moshe Litvin , Dan Harkins , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comments on CRACK In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFEC9820@exchange> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: df51674799abaf44fcc7eb8013fc2ae5 On Tue, 26 Oct 1999, Stephane Beaulieu wrote: > Perhaps, although some have argued that this would be redundant. Admins > would have to maintain 2 databases (SS+RADIUS). > > If we do feel that adding this restriction adds security, then shouldn't IKE > do the same? > YES Although it's actually a policy decision, not to be mandated by the protocols. So probably neither IKE nor xauth should mandate it, but maybe could include a section on why this is Bad(tm)? Or maybe an information rfc explaining the risks and why this is not a good idea? My 2c.. jan > Stephane. > > > -----Original Message----- > > From: Moshe Litvin [mailto:moshe@checkpoint.com] > > Sent: Tuesday, October 26, 1999 12:36 PM > > To: Stephane Beaulieu > > Cc: Dan Harkins; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org > > Subject: Re: Comments on CRACK > > > > > > Stephane Beaulieu wrote: > > > > > > > > > However, I would like to hear everyone else's > > > opinion on this. Should the use of pre-shared keys be > > restricted in XAUTH > > > (or whatever other protocol) because it encourages the use of weak > > > pre-shared keys? > > > > > > If there is concensus, pre-shared keys can be removed from > > XAUTH. I don't > > > think that we have concensus at this point. > > > > Maybe we can reach a consensus by forbidding group pre-shared keys? > > > > Moshe > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From ???@??? Tue Oct 26 14:45:16 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06166 for ; Tue, 26 Oct 1999 14:28:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00216 Tue, 26 Oct 1999 14:41:16 -0400 (EDT) Date: Tue, 26 Oct 1999 14:34:41 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.34a) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <1607.991026@lucent.com> To: "Criss" CC: Subject: Re: comments on ip sec In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 74023d3d26d921a3ee32dd7f51578dcd Hello Criss, Your best bet is to read as much as you can on this site: http://www.ietf.org/html.charters/ipsec-charter.html Best regards, Jim Tiller, CISSP, MCSE+I, CCDA jtiller@lucent.com Network Security Consultant, Lucent Tampa, Florida "Faber est suae quisque fortunae." - Appius Claudius Caecus Sunday, October 24, 1999, 3:15:40 PM, you wrote: Criss> hi, Criss> i'm bruce Alminin, a finishing studend in computer science at Uqam, Criss> University of Montreal. I'm also creating my own company at montreal in Criss> order to sell networks and computer products. Criss> In fact i'd like to have more documentation about the definition of ip Criss> sec. Criss> I ask to send if possible a file with the objectives, goal, and concepts Criss> of ip sec. Criss> i already thanks you for you reply. Criss> Bruce. From ???@??? Tue Oct 26 14:45:16 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06060 for ; Tue, 26 Oct 1999 14:22:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00231 Tue, 26 Oct 1999 14:42:46 -0400 (EDT) Message-ID: <3815F49E.BFABF7C9@cisco.com> Date: Tue, 26 Oct 1999 14:36:14 -0400 From: Roy Pereira Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: Dan Harkins , Moshe Litvin , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC97E6@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 64de4df7b19f32ec66a563d25e80c564 > My problem with this is that this seems like a security administrators job > to ensure that the strength of the authentication mechanisms be well chosen > and secure. There's a lot of ways that an administrator could shoot himself > in the foot. I know that doesn't justify giving them one more bullet to > shoot themselves with. However, I would like to hear everyone else's > opinion on this. Should the use of pre-shared keys be restricted in XAUTH > (or whatever other protocol) because it encourages the use of weak > pre-shared keys? If we need to take shared-secret out of XAUTH, then why not out of IKE all together? The point here is that XAUTH merely extends IKE and thus incorporates all of its security (or lack of). Why is shared-secret IKE different than shared-secret XAUTH? Let me ask everyone who is interested; How do we support existing legacy user authentication within IKE without using a PKI ? BTW: I don't like group-shared-secrets, but I strongly beleive that the customer has to choose what level of security they want themselves. We can definately suggest the best security, but in the end it is up to the customer's paranoia level to determine their security requirements. From ???@??? Tue Oct 26 14:45:16 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06176 for ; Tue, 26 Oct 1999 14:28:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00336 Tue, 26 Oct 1999 14:55:48 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Roy Pereira Cc: Stephane Beaulieu , Dan Harkins , Moshe Litvin , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Oct 1999 14:58:07 -0400 Message-Id: <19991026185813.B46AD41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 4a9ea9905867749562ae62726dec20d5 In message <3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes: > > Let me ask everyone who is interested; How do we support existing > legacy user authentication within IKE without using a PKI ? With a protocol that lets the customer download an encrypted private key/ certificate pair from a server, followed by ordinary IKE. --Steve Bellovin From ???@??? Tue Oct 26 14:45:16 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06291 for ; Tue, 26 Oct 1999 14:34:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00373 Tue, 26 Oct 1999 14:58:38 -0400 (EDT) Message-ID: <3815FA78.308C3CEB@redcreek.com> Date: Tue, 26 Oct 1999 12:01:12 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Roy Pereira CC: Stephane Beaulieu , Dan Harkins , Moshe Litvin , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC97E6@exchange> <3815F49E.BFABF7C9@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 42a472039457dbba7309f41c476de59b Hi Roy, Roy Pereira wrote: > > The point here is that XAUTH merely extends IKE and thus incorporates > all of its security (or lack of). Why is shared-secret IKE different > than shared-secret XAUTH? Really, Roy - you surprise me sometimes. You know the answer to this as well as anyone, but I'll spell it out for expediency. It's different due to context - xauth is specifically for remote access. Remote access users typically do not have fixed IP addresses, so we have no way to identify the preshared key in main mode. Hence, all remote access users with preshared keys are often configured to use the same key. This is bad. Preshared keys are not necessarily bad. I'll bet some very secure organizations rely almost exclusively upon them. However, increasing the pool with access to these secrets decreases their security proportionally. Comparing psk's in xauth to psk's in IKE is apples vs. oranges. > Let me ask everyone who is interested; How do we support existing > legacy user authentication within IKE without using a PKI ? > > BTW: I don't like group-shared-secrets, but I strongly beleive that the > customer has to choose what level of security they want themselves. We > can definately suggest the best security, but in the end it is up to the > customer's paranoia level to determine their security requirements. Many customers don't understand security, and if they did and were still willing to use such mechanisms, then they might be better off with a ppp-based vpn mechanism. Selling them a box which claims to implement security protocols has implications which are not borne out by this particular application. Customers may have reasonable security expectations based upon other representations providers of these products have made. Think about it. Scott From ???@??? Tue Oct 26 15:09:46 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06826 for ; Tue, 26 Oct 1999 15:05:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00525 Tue, 26 Oct 1999 15:46:06 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEC9929@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Roy Pereira Cc: Stephane Beaulieu , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comments on CRACK Date: Tue, 26 Oct 1999 15:45:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: d5ae9e213d455af06e281009068ac1f9 Scott, > > Really, Roy - you surprise me sometimes. You know the answer > to this as > well as anyone, but I'll spell it out for expediency. It's > different due > to context - xauth is specifically for remote access. Remote access > users typically do not have fixed IP addresses, so we have no way to > identify the preshared key in main mode. Hence, all remote > access users > with preshared keys are often configured to use the same key. This is > bad. This is a case of Main Mode not dealing with remote users and pre-shared keys very well. This can be fixed by using Base Mode (published by Radguard). This is one of the really nice things about XAUTH as it is today. It can be used with MM, AM, Base Mode, Hybrid... depending on what exactly it is you're trying to achieve. Regards, Stephane. From ???@??? Tue Oct 26 15:28:38 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07055 for ; Tue, 26 Oct 1999 15:23:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00620 Tue, 26 Oct 1999 16:09:21 -0400 (EDT) Message-Id: <199910262008.NAA00883@potassium.network-alchemy.com> To: Roy Pereira cc: Stephane Beaulieu , Moshe Litvin , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Comments on CRACK In-reply-to: Your message of "Tue, 26 Oct 1999 14:36:14 EDT." <3815F49E.BFABF7C9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <880.940968485.1@network-alchemy.com> Date: Tue, 26 Oct 1999 13:08:05 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: cc9d05aabd0c5f80caa4e821c20c77ac On Tue, 26 Oct 1999 14:36:14 EDT you wrote > > My problem with this is that this seems like a security administrators job > > to ensure that the strength of the authentication mechanisms be well chosen > > and secure. There's a lot of ways that an administrator could shoot himsel >f > > in the foot. I know that doesn't justify giving them one more bullet to > > shoot themselves with. However, I would like to hear everyone else's > > opinion on this. Should the use of pre-shared keys be restricted in XAUTH > > (or whatever other protocol) because it encourages the use of weak > > pre-shared keys? > > If we need to take shared-secret out of XAUTH, then why not out of IKE > all together? I guess it could but in IKE the peers are mutually authenticated. That's the whole point. And it's peer-to-peer, not peer-to-multipeer. That changes with XAUTH. XAUTH says: "If mutual authentication is not required, then the phase 1 negotiation MAY use an authentication method of shared-secret and have that shared-secret be null." Which is just insane! You're saying that people can do an unauthenticated Diffie-Hellman in a security protocol. Since XAUTH does not change that fact-- i.e. it does not contribute to SKEYID in any way shape or form-- what you end up with unautheticated IPSec SAs. In fact, the above statement is non-compliant with RFC2408. As was pointed out on the list a few weeks ago (I can't find the mail though :-( ) ISAKMP says: "Strong authentication MUST be provided on ISAKMP exchanges. Without being able to authenticate the entity at the other end, the Security Association (SA) and session key established are suspect." > The point here is that XAUTH merely extends IKE and thus incorporates > all of its security (or lack of). Why is shared-secret IKE different > than shared-secret XAUTH? No it does not. XAUTH does not contribute any security to IKE; it is Xtranneous Authentication. Pre-shared secret IKE is different than pre-shared secret XAUTH for the simple matter that IKE does peer-to-peer authentication. And the pre-shared key is implied to be bound to the peer. Now I guess you can be a stickler and say that group pre-shared keys are not explicitly forbidden (and that can be rectified) but neither is leaking the secret. You could leak the IPSec keys in some sort of key recovery scheme and _technically_ still be RFC2409-compliant. So, IKE can include some text to say "don't use a group pre-shared key" if you like. But just because IKE doesn't say that doesn't mean that it encourages it. XAUTH does. In fact XAUTH goes even further to say that an unauthenticated Diffie-Hellman is allowable. > BTW: I don't like group-shared-secrets, but I strongly beleive that the > customer has to choose what level of security they want themselves. We > can definately suggest the best security, but in the end it is up to the > customer's paranoia level to determine their security requirements. But the hairbrained requirements of unsophisticated customers should not be a driving force in the standardization process. We're engineering a security protocol not satisfying our respective marketing departments. Dan. From ???@??? Wed Oct 27 08:23:09 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06712 for ; Wed, 27 Oct 1999 08:05:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04220 Wed, 27 Oct 1999 09:25:03 -0400 (EDT) Message-Id: <199910262024.NAA16410@ha1mpk-mail.eng.sun.com> Date: Tue, 26 Oct 1999 13:14:45 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Comments on CRACK To: royp@cisco.com, smb@research.att.com Cc: sbeaulieu@TimeStep.com, dharkins@network-alchemy.com, moshe@checkpoint.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jjA7vrN8srQbe7gaRGdg5Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_28 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 201616af3347f23132a7f164faab2a26 > In message <3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes: > > > > > Let me ask everyone who is interested; How do we support existing > > legacy user authentication within IKE without using a PKI ? > > With a protocol that lets the customer download an encrypted private key/ > certificate pair from a server, followed by ordinary IKE. > > --Steve Bellovin > A perfect lead-in for what I've been thinking about for some time now :-) How about using an HTML forms based interaction over HTTPS between a webserver and a user to accomplish what you state. Internet Intranet | | +--> Legacy Auth server SSL/TLS protected | / user =================== HTTPS <---+ server | | This interaction can easily accomodate legacy user auth mechanisms like SecureID, DES Gold, OTP, CHAP because the HTTPS server has access to authentication tokens in the clear. Even multiple rounds don't pose a problem. After the Auth server responds with "OK", the HTTP server can squirt out a special MIME datatype and the browser could be set up to automatically invoke the IKE daemon (or companion software) to handle that MIME type. The HTTPS may need to coordinate with the IPSec gateway on the Intranet side. This could be a reasonable solution for the road warrior VPN scenario. I've heard Paul Hoffman use the term "user authentication in Phase 0.5" for an approach like this (in contrast to Hybrid's Phase 1.5). (Maybe now's a good time to go look for that fire extingusher :-)). vipul From ???@??? Tue Oct 26 17:34:23 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09150 for ; Tue, 26 Oct 1999 16:44:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01001 Tue, 26 Oct 1999 17:33:17 -0400 (EDT) Date: Tue, 26 Oct 1999 17:35:53 -0400 Message-Id: <199910262135.RAA07174@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com In-reply-to: Dan Harkins's message of Tue, 26 Oct 1999 13:08:05 -0700, <199910262008.NAA00883@potassium.network-alchemy.com> Subject: Re: Comments on CRACK Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 4351caed513de1218f7a3c6bac448f72 This conversation is getting a little bit out of hand --- and is one of the reasons why I have been trying to push hard to make sure IPSRA BOF/WG gets started. We're arguing over protocols when we haven't agreed what the basic requirements are; as a result, we have multiple different incompatible protocols (including more than one version of XAUTH), all trying to solve the same problem, and people talking past one another about what's important and what's not. In my opinion, what we need to do is call a halt, take a deep breath, and return to basics --- to wit, a formal requirements document. This may take time, but it's likely to be the one that's most likely to yield forward progress. Xauth and its sister contenders have been on the table for a long time, and we haven't been able to come to consensus so far; does anyone really think that we will be able to obtain consensus by continuing this path? In any case, that was the initial reasoning behind spawning an IPSEC RA BOF --- namely, that in the process of chartering a working group, we could be a bit more intentional about starting over with requirements, so that we have some hope of actually reaching consensus and not talking past one another. There have been some who have objected to this saying that one of the co-chairs of the IPSRA bof is the the author of one of the existing protocols, and so therefore he might be biased. I will point out that there are very few qualified people who might have been chosen that wouldn't be biased one way or the other, and it's one of the reasons why Area Directors have oversight responsibilitys of wg chairs. I encourage people to give the IPSRA bof (and hopefully wg) chairs a chance; you can always complain to Jeff or Marcus if you feel that they are being unfair. That being said, with the second IPSRA bof being scheduled for Washington, I would like to ask that discussion that is within the scope of the IPSRA be moved to the IPSRA mailing list. I would further encourage Roy and Sara (although it's their show) to try to push the discussion back to the level of formal requirements, as a method that may be much more likely of making forward progress than the current series of discussion. Discussion of what the formal charter for IPSRA might also be appropriate, given that Washington will be the 2nd time the IPSRA bof has had a chance to meet. - Ted IPSEC wg chair From ???@??? Tue Oct 26 14:51:11 1999 X-Persona: Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA06477 for ; Tue, 26 Oct 1999 14:45:29 -0700 (PDT) Received: id RAA02860; Tue, 26 Oct 1999 17:44:28 -0400 Received: by gateway id <43HHP2GQ>; Tue, 26 Oct 1999 17:47:09 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D780@sothmxs06.entrust.com> From: Greg Carter To: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: CRLs Date: Tue, 26 Oct 1999 17:47:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 21f2382c1a1447f57d8e8f7986a4cfa4 ISAKMP has a certificate request payload, with various types, including CRL and ARL. If your implementation determines it can not retrieve CRLs via its regular method (LDAP etc.) then include a Certificate Request payload with type set to CRL (you should also include one for ARL so that when a chain is sent you get the various ARLs needed to verify the CA certificates). When you receive a Certificate Request payload with type CRL you MUST reply with the DER encoded CRL that your certificate would be listed on if it were to be revoked. This requires that at least one side has access to the CRL repository. So don't send it unless asked, if asked the above covers how. If they ask then they can process, so there shouldn't be interop problems. If they ask and you can't produce then you have a problem, if you can't produce because you don't support CRLs than that is your problem. If you only support OCSP as a gateway and the OCSP server is behind your gateway your SOL. If you only support OCSP and you expect to intero with clients that don't and the CRL repository is behind your gateway then you are SOL. So I think gateways should be prepared to respond with a CRL. Its a very convenient method of transporting CRLs. Putting the LDAP server behind the gateway is common. Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, October 25, 1999 8:45 PM To: ipsec@lists.tislabs.com Subject: Re: Query on draft-ietf-ipsec-pki-req-03.txt At 07:55 AM 10/19/99 -0700, Walker, Jesse wrote: >The draft includes the following text in Section 2: > IKE systems conforming to this profile MUST check the > revocation statusof any certificate on which they rely, using > the algorithm described inthe PKIX certificate profile. Thus, > every conforming IKE system MUSThave a method for > receiving up-to-date revocation information for thecertificates > it is validating. >What do you intend this to mean in the remote access case? One normal >operational scenario will have the CRL distribution point the remote IPSec >host needs to validate the security gateway's certificate behind the >security gateway. I don't think putting a CRL source (such as an FTP or LDAP server) behind a security gateway is the normal case. The main reason to do that is to hide the identities of the certificates you have revoked (which might have a business purpose). Normally, these are wide open. > In such a case, unless it has already obtained the CRL via >an alternate channel, the remote host will be unable to meet the above >requirement. And, I think that "unless" is exactly right: you must use the information you have. > Seemingly the best that it could be able to do is to establish >IKE and IPSec security associations, then attempt to obtain the CRL, and >then decide what to do on the basis of whether or not it could get the CRL >or the security gateway's cert gets validated. Maybe we need to require >implementations to send the latest CRL known to them during the IKE phase 1 >negotiation? I would be against that because some CRLs will be very large. In the case of a hidden CRL DP, I'd say "you must use what you already know". I think it is good to say "if the device knows that its CRL DP is not currently available to the other party behind a security gateway, that device SHOULD send its CRL". -=-=-=-=-= At 08:06 AM 10/19/99 -0700, Walker, Jesse wrote: >Section 3.2 says > The subject field in IPsec certificates SHOULD be populated and >non-null > (this is contrary to the PKIX certificate profile, which says >thatthe subject > MUST NOT be populated if the identification is in thesubjectAltName > field). The exact contents of this field are notstandardized. By >convention, a > minimal subject field containscountryName and commonName. >Distinguished > names SHOULD be no more thanfour attribute/value pairs, each of >which > SHOULD be no more than 128 characters in length (these restrictions >do > not appear in the PKIXcertificate profile). An IKE implementation >that > conforms to thisprofile SHOULD NOT reject a certificate that does >not > follow theserules. > >Why? The rationale for this requirement is not immediately obvious. Personally, I think it is completely lame. I would like to rip that wholerement out of the spec. Would anyone object to me doing so? That is, has anyone shipped an implementation that is so non-compliant that it *requires* a non-null subject even though there's a subjectAltName? -=-=-=-=-= At 12:28 PM 10/19/99 -0400, Greg Carter wrote: > >From 1. Introduction, first paragraph: > >"Note that many IPsec implementers are not completely happy with the PKIX >documents and procedures, but have agreed to use the PKIX protocols because >they are supported in other contexts and have a significant market share." > >and last paragraph > >"(It is noted that the fact that the two documents differ does not give >great confidence to the IPsec community or other users of the PKIX >protocols.)" > >Both of these, whether or not true, are opinions and don't really do >anything to help implementers beside adding confusion. I would suggest they >be taken out for clarity. Rodney and I put them in to indicate that the reader shouldn't assume that reading the PKIX documentation literally is a good idea. > >From section 3.1 The extendedKeyUsage field: > >"In a certificate for an IPsec end entity, the extendedKeyUsage field >commonly called "EKU") MUST be present and MUST contain only the object >identifier iKEIntermediate >(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or >1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT >accept end-entity certificates that do not follow this rule." > >Why must the certificate only have the one extended key usage? This is too >restrictive. I like the idea of only having one IPSec extended key usage >bit though. Could we stick with PKIX and say that if flagged critical then >it must only have one value. Therefore you could remove the "and MUST >contain only the object identifier iKEIntermediate..." since that would be >covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage >extensions. I agree with this. I can see many reasons why a CA would create a single cert for an IKE system that might have multiple uses. >In Section 3.2 The subjectAltName field, last paragraph: >"The subject field in IPsec certificates SHOULD be populated and non-null >(this is contrary to the PKIX certificate profile, which says that the >subject MUST NOT be populated if the identification is in the subjectAltName >field)" > >This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name >that: > >Further, if the only subject identity included in the certificate is an >alternative name form (e.g., an electronic mail address), then the subject >distinguished name MUST be empty (an empty sequence), and the subjectAltName >extension MUST be present. If the subject field contains an empty sequence, >the subjectAltName extension MUST be marked critical. > >The important phase being "if the ONLY subject identity included in the >certificate is an alternate name form". It does not say "If the alternate >name form is used then NO subject distinguished name may be present." which >is how I read section 3.2. For clarity I would stick with the PKIX >definitions of how subject and alternate names are to be used and remove the >last paragraph. I agree. >If ONLY the alternate name is to be used then the subject should be left >empty as PKIX states. However in practice I do not know of any >implementations that only identify the 'device' by alternate name. For >administration purposes they will always have a subject name, however there >may exist a situation where someone would like to restrict to only using the >alternate name for identification and the only way to do this is with an >empty subject. And here we disagree. How are such CA's identifying an IKE system in the subject? If you mean "kludging the IP address or DNS name into a subject field", I have no problem saying that that MUST NOT be done in this profile. How do others feel about this? >Also in the last paragraph of section 3.2: >"Distinguished names SHOULD be no more than four attribute/value pairs, each >of which SHOULD be no more than 128 characters in length (these restrictions >do not appear in the PKIX certificate profile)." > >Again these are too restrictive. Names in the subject/issuer are dictated >by the customers directory setup (for those using one). In practice I have >seen longer names than 4 attribute/value pairs. Length... well I don't know >much about multi char character sets but I wouldn't want to limit anything >which would prevent IPSec certificates being used in foreign languages. Agree. > >From Appendix A: > >"Regardless of the protocol used, a CA who gets an IKE system's enrollment >request that includes the subject and subjectAltName desired for the device >MUST include exactly the same subject and subjectAltName in the >certificate. If the CA does not want to issue a certificate with the same >subject and subjectAltName that was requested, the CA MUST NOT issue a >certificate with a different name and subjectAltName." > >This places an unnecessary burden on the end entity to determine what >exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change >the DN that is in the request. If the device must have the exact DN then it >means a user somewhere has to type it in, very prone to failure. I agree. I think we should take out that restriction. If the IKE system doesn't like the cert it gets (for example, because the CA changed the subject or subjectAltName), the system doesn't have to use that cert. > Also there >is no mention of how to verify the request at the CA. The device should >generate a hash of the der encoded request and make it available to the >devices administrator for verification at the CA. Otherwise the request is >accepted without verification. This makes sense to me, and could be part (obviously) of the out-of-band info. > Also mention of how to obtain the CAs keys >in a secure way, similarly usually done with a hash of the CAs der encoded >certificate. May want to add this to the security section?... This could be added. It's covered in PKIX, but yet another paragraph in the security section is always safe... --Paul Hoffman, Director --VPN Consortium From ???@??? Tue Oct 26 17:34:23 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07812 for ; Tue, 26 Oct 1999 15:57:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01036 Tue, 26 Oct 1999 17:46:00 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D780@sothmxs06.entrust.com> From: Greg Carter To: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: CRLs Date: Tue, 26 Oct 1999 17:47:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 326abf67a76b46a8d9c8742fbbd2c288 ISAKMP has a certificate request payload, with various types, including CRL and ARL. If your implementation determines it can not retrieve CRLs via its regular method (LDAP etc.) then include a Certificate Request payload with type set to CRL (you should also include one for ARL so that when a chain is sent you get the various ARLs needed to verify the CA certificates). When you receive a Certificate Request payload with type CRL you MUST reply with the DER encoded CRL that your certificate would be listed on if it were to be revoked. This requires that at least one side has access to the CRL repository. So don't send it unless asked, if asked the above covers how. If they ask then they can process, so there shouldn't be interop problems. If they ask and you can't produce then you have a problem, if you can't produce because you don't support CRLs than that is your problem. If you only support OCSP as a gateway and the OCSP server is behind your gateway your SOL. If you only support OCSP and you expect to intero with clients that don't and the CRL repository is behind your gateway then you are SOL. So I think gateways should be prepared to respond with a CRL. Its a very convenient method of transporting CRLs. Putting the LDAP server behind the gateway is common. Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, October 25, 1999 8:45 PM To: ipsec@lists.tislabs.com Subject: Re: Query on draft-ietf-ipsec-pki-req-03.txt At 07:55 AM 10/19/99 -0700, Walker, Jesse wrote: >The draft includes the following text in Section 2: > IKE systems conforming to this profile MUST check the > revocation statusof any certificate on which they rely, using > the algorithm described inthe PKIX certificate profile. Thus, > every conforming IKE system MUSThave a method for > receiving up-to-date revocation information for thecertificates > it is validating. >What do you intend this to mean in the remote access case? One normal >operational scenario will have the CRL distribution point the remote IPSec >host needs to validate the security gateway's certificate behind the >security gateway. I don't think putting a CRL source (such as an FTP or LDAP server) behind a security gateway is the normal case. The main reason to do that is to hide the identities of the certificates you have revoked (which might have a business purpose). Normally, these are wide open. > In such a case, unless it has already obtained the CRL via >an alternate channel, the remote host will be unable to meet the above >requirement. And, I think that "unless" is exactly right: you must use the information you have. > Seemingly the best that it could be able to do is to establish >IKE and IPSec security associations, then attempt to obtain the CRL, and >then decide what to do on the basis of whether or not it could get the CRL >or the security gateway's cert gets validated. Maybe we need to require >implementations to send the latest CRL known to them during the IKE phase 1 >negotiation? I would be against that because some CRLs will be very large. In the case of a hidden CRL DP, I'd say "you must use what you already know". I think it is good to say "if the device knows that its CRL DP is not currently available to the other party behind a security gateway, that device SHOULD send its CRL". -=-=-=-=-= At 08:06 AM 10/19/99 -0700, Walker, Jesse wrote: >Section 3.2 says > The subject field in IPsec certificates SHOULD be populated and >non-null > (this is contrary to the PKIX certificate profile, which says >thatthe subject > MUST NOT be populated if the identification is in thesubjectAltName > field). The exact contents of this field are notstandardized. By >convention, a > minimal subject field containscountryName and commonName. >Distinguished > names SHOULD be no more thanfour attribute/value pairs, each of >which > SHOULD be no more than 128 characters in length (these restrictions >do > not appear in the PKIXcertificate profile). An IKE implementation >that > conforms to thisprofile SHOULD NOT reject a certificate that does >not > follow theserules. > >Why? The rationale for this requirement is not immediately obvious. Personally, I think it is completely lame. I would like to rip that wholerement out of the spec. Would anyone object to me doing so? That is, has anyone shipped an implementation that is so non-compliant that it *requires* a non-null subject even though there's a subjectAltName? -=-=-=-=-= At 12:28 PM 10/19/99 -0400, Greg Carter wrote: > >From 1. Introduction, first paragraph: > >"Note that many IPsec implementers are not completely happy with the PKIX >documents and procedures, but have agreed to use the PKIX protocols because >they are supported in other contexts and have a significant market share." > >and last paragraph > >"(It is noted that the fact that the two documents differ does not give >great confidence to the IPsec community or other users of the PKIX >protocols.)" > >Both of these, whether or not true, are opinions and don't really do >anything to help implementers beside adding confusion. I would suggest they >be taken out for clarity. Rodney and I put them in to indicate that the reader shouldn't assume that reading the PKIX documentation literally is a good idea. > >From section 3.1 The extendedKeyUsage field: > >"In a certificate for an IPsec end entity, the extendedKeyUsage field >commonly called "EKU") MUST be present and MUST contain only the object >identifier iKEIntermediate >(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or >1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT >accept end-entity certificates that do not follow this rule." > >Why must the certificate only have the one extended key usage? This is too >restrictive. I like the idea of only having one IPSec extended key usage >bit though. Could we stick with PKIX and say that if flagged critical then >it must only have one value. Therefore you could remove the "and MUST >contain only the object identifier iKEIntermediate..." since that would be >covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage >extensions. I agree with this. I can see many reasons why a CA would create a single cert for an IKE system that might have multiple uses. >In Section 3.2 The subjectAltName field, last paragraph: >"The subject field in IPsec certificates SHOULD be populated and non-null >(this is contrary to the PKIX certificate profile, which says that the >subject MUST NOT be populated if the identification is in the subjectAltName >field)" > >This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name >that: > >Further, if the only subject identity included in the certificate is an >alternative name form (e.g., an electronic mail address), then the subject >distinguished name MUST be empty (an empty sequence), and the subjectAltName >extension MUST be present. If the subject field contains an empty sequence, >the subjectAltName extension MUST be marked critical. > >The important phase being "if the ONLY subject identity included in the >certificate is an alternate name form". It does not say "If the alternate >name form is used then NO subject distinguished name may be present." which >is how I read section 3.2. For clarity I would stick with the PKIX >definitions of how subject and alternate names are to be used and remove the >last paragraph. I agree. >If ONLY the alternate name is to be used then the subject should be left >empty as PKIX states. However in practice I do not know of any >implementations that only identify the 'device' by alternate name. For >administration purposes they will always have a subject name, however there >may exist a situation where someone would like to restrict to only using the >alternate name for identification and the only way to do this is with an >empty subject. And here we disagree. How are such CA's identifying an IKE system in the subject? If you mean "kludging the IP address or DNS name into a subject field", I have no problem saying that that MUST NOT be done in this profile. How do others feel about this? >Also in the last paragraph of section 3.2: >"Distinguished names SHOULD be no more than four attribute/value pairs, each >of which SHOULD be no more than 128 characters in length (these restrictions >do not appear in the PKIX certificate profile)." > >Again these are too restrictive. Names in the subject/issuer are dictated >by the customers directory setup (for those using one). In practice I have >seen longer names than 4 attribute/value pairs. Length... well I don't know >much about multi char character sets but I wouldn't want to limit anything >which would prevent IPSec certificates being used in foreign languages. Agree. > >From Appendix A: > >"Regardless of the protocol used, a CA who gets an IKE system's enrollment >request that includes the subject and subjectAltName desired for the device >MUST include exactly the same subject and subjectAltName in the >certificate. If the CA does not want to issue a certificate with the same >subject and subjectAltName that was requested, the CA MUST NOT issue a >certificate with a different name and subjectAltName." > >This places an unnecessary burden on the end entity to determine what >exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change >the DN that is in the request. If the device must have the exact DN then it >means a user somewhere has to type it in, very prone to failure. I agree. I think we should take out that restriction. If the IKE system doesn't like the cert it gets (for example, because the CA changed the subject or subjectAltName), the system doesn't have to use that cert. > Also there >is no mention of how to verify the request at the CA. The device should >generate a hash of the der encoded request and make it available to the >devices administrator for verification at the CA. Otherwise the request is >accepted without verification. This makes sense to me, and could be part (obviously) of the out-of-band info. > Also mention of how to obtain the CAs keys >in a secure way, similarly usually done with a hash of the CAs der encoded >certificate. May want to add this to the security section?... This could be added. It's covered in PKIX, but yet another paragraph in the security section is always safe... --Paul Hoffman, Director --VPN Consortium From ???@??? Tue Oct 26 17:34:23 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08016 for ; Tue, 26 Oct 1999 16:12:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01057 Tue, 26 Oct 1999 17:56:17 -0400 (EDT) Message-Id: <4.2.1.19991026145356.00dc35f0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 26 Oct 1999 14:59:01 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: CRLs In-Reply-To: <01E1D01C12D7D211AFC70090273D20B10197D780@sothmxs06.entrust .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 6f319076aa6a70ef4cd9d1d677ccdfdd At 05:47 PM 10/26/99 -0400, Greg Carter wrote: >So don't send it unless asked, if asked the above covers how. If they ask >then they can process, so there shouldn't be interop problems. If they ask >and you can't produce then you have a problem, if you can't produce because >you don't support CRLs than that is your problem. This sounds right to me. We should add it to the draft as we add discussion about certificate requests and responses. > If you only support OCSP >as a gateway and the OCSP server is behind your gateway your SOL. Maybe. We could extend the DOI slightly to allow the request of an OCSP response. Until we do that, however, you're right. >So I think gateways should be prepared to respond with a CRL. Its a very >convenient method of transporting CRLs. Yep. >Putting the LDAP server behind the gateway is common. I hadn't heard this, but if that's true, we do need a way to tunnel the CRLs and OCSP responses through to the IKE systems. --Paul Hoffman, Director --VPN Consortium From ???@??? Tue Oct 26 15:28:38 1999 X-Persona: Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA06952 for ; Tue, 26 Oct 1999 15:15:38 -0700 (PDT) Received: id SAA13784; Tue, 26 Oct 1999 18:14:33 -0400 Received: by gateway id <43HHP2LJ>; Tue, 26 Oct 1999 18:17:14 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D782@sothmxs06.entrust.com> From: Greg Carter To: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: RE: "PKIX Profile for IKE"--Is it really a profile? Date: Tue, 26 Oct 1999 18:17:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA06952 X-UIDL: 31e61dd74dda124de4bbc7dde89dc527 -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, October 25, 1999 8:06 PM To: ipsec@lists.tislabs.com Subject: Re: "PKIX Profile for IKE"--Is it really a profile? I agree with Paul on all the topics which are already covered in PKIX, duplication will only lead to confusion. >· EKU MUST contain only object identifier iKEIntermedate This is pretty clear. Clear but wrong? Why must it only have one value????? Are you trying to say that we mustn't use the old values, or are you trying to say that we must not have any other EKU values if iKEIntermedate is used? >Note also that some of the important details about the operation of IKE >are not addressed in this profile, even though in many cases the existing >IKE specs leave the details open to interpretation. For example, >there is no normative text to outline a profile-specific >method for handling IKE?s CERTIFICATE and CERTIFICATE REQUEST >payloads, Quite correct and this is one of the areas that we *must* address. It could be clearer but I think it is all there already. > there is no normative text to describe certificate >validation in IKE (e.g., what if an evaluating system does not trust >its peer's root CA, Then no validation happens, period. That's fully covered in PKIX. Agreed (with Paul). > what are the normative rules for matching a >certificate?s subject to IKE?s ID Payload fields, That's a good question. Many companies have told me that they never intend to match the subject to the IKE initiator. I find that scary, but it's what many people want. I would prefer statements in this profile that say you SHOULD (maybe MUST) match the subject, but that's open for debate. Then they don't understand the security implications and this is something that should be explained in the doc. The DOI mentions that if the ID payload is used for policy decisions then the ID SHOULD be contained in the certificate. If they use the ID in the ID payload for policy lookups but don't verify that ID than they have serious security problems. Perhaps one of the reasons this isn't pointed out is it was thought to be obvious. I can substitute any ID I want, my signature will still verify because I have sent you my cert. If they do not use the ID in the ID payload to look up policy and instead use the ID contained in the certificate then there is not a problem. > can a given IKE >implementation recognize more than one root CA, Of course; why not? Again the trap of over specifying. We shouldn't get into the situation where someone writes a certificate validation routine based on this spec. They should write it to PKIX and then apply it to IPSec using this spec, there are really only a few minor things to do once you get past PKIX. Which are in the current draft, verify ID payload to certificate identities, SA life time vs Certificate life time, etc... Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html From ???@??? Tue Oct 26 17:34:23 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08662 for ; Tue, 26 Oct 1999 16:31:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01166 Tue, 26 Oct 1999 18:16:09 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197D782@sothmxs06.entrust.com> From: Greg Carter To: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: RE: "PKIX Profile for IKE"--Is it really a profile? Date: Tue, 26 Oct 1999 18:17:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA01163 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 0a55d58dee733d3adc633710a8f3b10a -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, October 25, 1999 8:06 PM To: ipsec@lists.tislabs.com Subject: Re: "PKIX Profile for IKE"--Is it really a profile? I agree with Paul on all the topics which are already covered in PKIX, duplication will only lead to confusion. >· EKU MUST contain only object identifier iKEIntermedate This is pretty clear. Clear but wrong? Why must it only have one value????? Are you trying to say that we mustn't use the old values, or are you trying to say that we must not have any other EKU values if iKEIntermedate is used? >Note also that some of the important details about the operation of IKE >are not addressed in this profile, even though in many cases the existing >IKE specs leave the details open to interpretation. For example, >there is no normative text to outline a profile-specific >method for handling IKE?s CERTIFICATE and CERTIFICATE REQUEST >payloads, Quite correct and this is one of the areas that we *must* address. It could be clearer but I think it is all there already. > there is no normative text to describe certificate >validation in IKE (e.g., what if an evaluating system does not trust >its peer's root CA, Then no validation happens, period. That's fully covered in PKIX. Agreed (with Paul). > what are the normative rules for matching a >certificate?s subject to IKE?s ID Payload fields, That's a good question. Many companies have told me that they never intend to match the subject to the IKE initiator. I find that scary, but it's what many people want. I would prefer statements in this profile that say you SHOULD (maybe MUST) match the subject, but that's open for debate. Then they don't understand the security implications and this is something that should be explained in the doc. The DOI mentions that if the ID payload is used for policy decisions then the ID SHOULD be contained in the certificate. If they use the ID in the ID payload for policy lookups but don't verify that ID than they have serious security problems. Perhaps one of the reasons this isn't pointed out is it was thought to be obvious. I can substitute any ID I want, my signature will still verify because I have sent you my cert. If they do not use the ID in the ID payload to look up policy and instead use the ID contained in the certificate then there is not a problem. > can a given IKE >implementation recognize more than one root CA, Of course; why not? Again the trap of over specifying. We shouldn't get into the situation where someone writes a certificate validation routine based on this spec. They should write it to PKIX and then apply it to IPSec using this spec, there are really only a few minor things to do once you get past PKIX. Which are in the current draft, verify ID payload to certificate identities, SA life time vs Certificate life time, etc... Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html From ???@??? Tue Oct 26 17:34:23 1999 X-Persona: Received: by ns.secondary.com (8.9.3/8.9.3) id RAA09513 for ietf-ipsra-bks; Tue, 26 Oct 1999 17:09:07 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09509 for ; Tue, 26 Oct 1999 17:09:06 -0700 (PDT) Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by mail-blue.research.att.com (Postfix) with ESMTP id B878A4CE16; Tue, 26 Oct 1999 20:12:12 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id UAA14605; Tue, 26 Oct 1999 20:12:16 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id BC49E41F16; Tue, 26 Oct 1999 20:12:05 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id AD47A400B4; Tue, 26 Oct 1999 20:12:00 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Vipul Gupta Cc: royp@cisco.com, sbeaulieu@TimeStep.com, dharkins@Network-Alchemy.COM, moshe@checkpoint.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Oct 1999 20:11:56 -0400 Message-Id: <19991027001205.BC49E41F16@SIGABA.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-UIDL: 76a12cf0b272cfed32c1960c17d4e13e In message <199910262024.NAA16410@ha1mpk-mail.eng.sun.com>, Vipul Gupta writes: > > > In message <3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes: > > > > > > > > Let me ask everyone who is interested; How do we support existing > > > legacy user authentication within IKE without using a PKI ? > > > > With a protocol that lets the customer download an encrypted private key/ > > certificate pair from a server, followed by ordinary IKE. > > > > --Steve Bellovin > > > > A perfect lead-in for what I've been thinking about for some time > now :-) > > How about using an HTML forms based interaction over HTTPS between > a webserver and a user to accomplish what you state. (details elided) Yup, that will work, though I had something more elegant in mind, along the lines of the Kaufman/Perlman protocol described at the last NDSS. If nothing else, I'd rather that the server didn't have any plaintext-equivalent copies of the user's private key lying around. That said, it's quite likely that a more elegant protocol can fit into the structure you describe, especially since a browser plug-in may be needed anyway, to stash the keys in a useful place. --Steve Bellovin From ???@??? Tue Oct 26 19:01:18 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12294 for ; Tue, 26 Oct 1999 18:34:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01483 Tue, 26 Oct 1999 20:09:40 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Vipul Gupta Cc: royp@cisco.com, sbeaulieu@TimeStep.com, dharkins@network-alchemy.com, moshe@checkpoint.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Oct 1999 20:11:56 -0400 Message-Id: <19991027001205.BC49E41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 47ee1cc558aa16999b419ab2e1dcf4e9 In message <199910262024.NAA16410@ha1mpk-mail.eng.sun.com>, Vipul Gupta writes: > > > In message <3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes: > > > > > > > > Let me ask everyone who is interested; How do we support existing > > > legacy user authentication within IKE without using a PKI ? > > > > With a protocol that lets the customer download an encrypted private key/ > > certificate pair from a server, followed by ordinary IKE. > > > > --Steve Bellovin > > > > A perfect lead-in for what I've been thinking about for some time > now :-) > > How about using an HTML forms based interaction over HTTPS between > a webserver and a user to accomplish what you state. (details elided) Yup, that will work, though I had something more elegant in mind, along the lines of the Kaufman/Perlman protocol described at the last NDSS. If nothing else, I'd rather that the server didn't have any plaintext-equivalent copies of the user's private key lying around. That said, it's quite likely that a more elegant protocol can fit into the structure you describe, especially since a browser plug-in may be needed anyway, to stash the keys in a useful place. --Steve Bellovin From ???@??? Tue Oct 26 18:00:09 1999 X-Persona: Received: from oe8.briank.com (oe8.briank.com [198.144.201.197]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10438 for ; Tue, 26 Oct 1999 17:48:26 -0700 (PDT) Received: from cs.stanford.edu (blatz.briank.com [198.144.201.195]) by oe8.briank.com (8.8.8/8.8.8) with ESMTP id RAA14012; Tue, 26 Oct 1999 17:51:03 -0700 (PDT) (envelope-from briank@cs.stanford.edu) Message-ID: <38164C72.6E1A7A23@cs.stanford.edu> Date: Tue, 26 Oct 1999 17:51:02 -0700 From: Brian Korver X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt References: <01E1D01C12D7D211AFC70090273D20B10197D71C@sothmxs06.entrust.com> <4.2.1.19991026092935.0302c5b0@mail.vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UIDL: ff4507a4b647d3d16300dc949af68c08 Paul Hoffman wrote: > > At 04:35 PM 10/25/99 -0700, Brian Korver wrote: > >Why require that extendedKeyUsage be mandatory at all? > > To identify the cert as being for IKE. I've been told that today's IKE > systems use this OID as identification. I believe we should have *one* OID > for all IKE implementations, and not try to slice and dice between "client" > and "gateway" and so on. > > Are there any IPsec implementations using the IPsec OIDs specified in RFC > 2459? Are there any implementations that require the use of other OIDs, > like IKEend (1.3.6.1.5.5.8.2.1)? > > --Paul Hoffman, Director > --VPN Consortium Paul, Why is there a requirement to identify certificates as "for use with IKE"? BTW, I haven't heard of any implementations that require these IKE OIDs in ExtendedKeyUsage. Perhaps someone else has. brian briank@cs.stanford.edu (play) briank@network-alchemy.com (work) From ???@??? Tue Oct 26 19:20:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13435 for ; Tue, 26 Oct 1999 19:08:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01627 Tue, 26 Oct 1999 20:49:36 -0400 (EDT) Message-ID: <38164C72.6E1A7A23@cs.stanford.edu> Date: Tue, 26 Oct 1999 17:51:02 -0700 From: Brian Korver X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-pki-req-03.txt References: <01E1D01C12D7D211AFC70090273D20B10197D71C@sothmxs06.entrust.com> <4.2.1.19991026092935.0302c5b0@mail.vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 4948119f864238196c63ff89816bcf51 Paul Hoffman wrote: > > At 04:35 PM 10/25/99 -0700, Brian Korver wrote: > >Why require that extendedKeyUsage be mandatory at all? > > To identify the cert as being for IKE. I've been told that today's IKE > systems use this OID as identification. I believe we should have *one* OID > for all IKE implementations, and not try to slice and dice between "client" > and "gateway" and so on. > > Are there any IPsec implementations using the IPsec OIDs specified in RFC > 2459? Are there any implementations that require the use of other OIDs, > like IKEend (1.3.6.1.5.5.8.2.1)? > > --Paul Hoffman, Director > --VPN Consortium Paul, Why is there a requirement to identify certificates as "for use with IKE"? BTW, I haven't heard of any implementations that require these IKE OIDs in ExtendedKeyUsage. Perhaps someone else has. brian briank@cs.stanford.edu (play) briank@network-alchemy.com (work) From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17617 for ; Tue, 26 Oct 1999 20:39:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01906 Tue, 26 Oct 1999 22:13:08 -0400 (EDT) Message-Id: <4.2.0.58.19991026190036.00a1be30@isl.hrl.hac.com> X-Sender: ygz@isl.hrl.hac.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 26 Oct 1999 19:15:44 -0700 To: ipsec@lists.tislabs.com, tf-esp@research.att.com From: Yongguang Zhang Subject: multi-layer IPSEC draft In-Reply-To: <199910200150.VAA14041@tsx-prime.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: c6159a70d55879d8272130482e3f221c Hi, all: This draft is a follow-up of my short presentation in last IETF. (I sent out last week but hasn't got response back from Internet-Draft.) But it is also available from my web site: http://www.wins.hrl.com/people/ygz/ml-ipsec/draft-zhang-ipsec-mlipsec-00.txt To repeat the concept, multi-layer IPSEC applies separate encryption/authentication with different keys on different parts of an IP datagram. It allows certain intermediate routers to have limited and controllable access to part of IP datagram (usually headers) but not the user data, for applications like flow classification, diffserv, TCPPEP, NAT, transparent proxy, etc. (and those "intelligent routing" that need access to higher-layer protocol headers). I'd like to hear your comments on this. Regards, Yongguang From ???@??? Tue Oct 26 19:20:19 1999 X-Persona: Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13654 for ; Tue, 26 Oct 1999 19:13:25 -0700 (PDT) Received: from akalice.research.att.com (akalice.research.att.com [135.207.26.22]) by mail-green.research.att.com (Postfix) with ESMTP id 6EB381E034; Tue, 26 Oct 1999 22:16:23 -0400 (EDT) Received: (from majordomo@localhost) by akalice.research.att.com (980427.SGI.8.8.8/8.8.7) id WAA69788 for tf-esp-list; Tue, 26 Oct 1999 22:15:46 -0400 (EDT) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by akalice.research.att.com (980427.SGI.8.8.8/8.8.7) with ESMTP id WAA71958 for ; Tue, 26 Oct 1999 22:15:45 -0400 (EDT) Received: by mail-green.research.att.com (Postfix) id 242BC1E030; Tue, 26 Oct 1999 22:15:45 -0400 (EDT) Delivered-To: tf-esp@research.att.com Received: from fw-es10.hac.com (fw-es10.HAC.COM [128.152.1.26]) by mail-green.research.att.com (Postfix) with ESMTP id 355BC1E029 for ; Tue, 26 Oct 1999 22:15:44 -0400 (EDT) Received: from malpha.hrl.hac.com ([192.27.95.96]) by fw-es10.hac.com (8.9.1/8.9.1) with SMTP id TAA06312 for ; Tue, 26 Oct 1999 19:15:45 -0700 (PDT) Received: from isl.hrl.hac.com by malpha.hrl.hac.com (5.65v4.0/1.1.19.2/28Dec98-0405PM) id AA03983; Tue, 26 Oct 1999 19:15:42 -0700 Received: from maygz by isl.hrl.hac.com (8.9.1b+Sun/SMI-SVR4) id TAA27872; Tue, 26 Oct 1999 19:14:25 -0700 (PDT) Message-Id: <4.2.0.58.19991026190036.00a1be30@isl.hrl.hac.com> X-Sender: ygz@isl.hrl.hac.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 26 Oct 1999 19:15:44 -0700 To: ipsec@lists.tislabs.com, tf-esp@research.att.com From: Yongguang Zhang Subject: multi-layer IPSEC draft In-Reply-To: <199910200150.VAA14041@tsx-prime.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tf-esp@research.att.com Precedence: bulk X-UIDL: 009e3ee7667d30fce50b1455b27a24ca Hi, all: This draft is a follow-up of my short presentation in last IETF. (I sent out last week but hasn't got response back from Internet-Draft.) But it is also available from my web site: http://www.wins.hrl.com/people/ygz/ml-ipsec/draft-zhang-ipsec-mlipsec-00.txt To repeat the concept, multi-layer IPSEC applies separate encryption/authentication with different keys on different parts of an IP datagram. It allows certain intermediate routers to have limited and controllable access to part of IP datagram (usually headers) but not the user data, for applications like flow classification, diffserv, TCPPEP, NAT, transparent proxy, etc. (and those "intelligent routing" that need access to higher-layer protocol headers). I'd like to hear your comments on this. Regards, Yongguang From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26961 for ietf-ipsra-bks; Wed, 27 Oct 1999 02:44:53 -0700 (PDT) Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26957 for ; Wed, 27 Oct 1999 02:44:50 -0700 (PDT) Received: from checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id LAA04342; Wed, 27 Oct 1999 11:54:31 +0200 (IST) Message-ID: <3816CB1B.4167A880@checkpoint.com> Date: Wed, 27 Oct 1999 11:51:23 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Stephane Beaulieu , wprice@cyphers.net, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC9812@exchange> <3815E0ED.F8C11745@redcreek.com> Content-Type: multipart/mixed; boundary="------------551C72AF621C0C49C1634ED7" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-UIDL: ef65a9e9385238400d1d6b632e999c65 Scott, "Scott G. Kelly" wrote: > Stephane Beaulieu wrote: > > What would those be? > > > > I've heard... > > > > 1 - It encourages the use of weak pre-shared keys. - Perhaps, but this can > > easily be fixed in XAUTH. I would still like to get a concensus on this. > > This "easy" fix requires deployment of client certificates. Deployment of client certificates together with hardware tokens (preferably FIPS 140-1 level 4 certified) is the best fix. The easy secure fix is hybrid. > > 2 - It's too complicated to be secure... Please ! > > Prove to me that it's secure. Better review your predicate logic > first... Let's start from the beginning, all the suggested protocols are based on IKE, so we can start with a proof of security for IKE. Then we can try to give a proof in the same level for the other suggestions. > > 3 - Too much known plain text. - All three proposals (XAUTH, CRACK, and ULA > > have know plain text. > > None have the copious amounts of ASCII TEXT that xauth does. Some known > plaintext may be unavoidable, but xauth has a ridiculous amount. Know plain text is non-issue (BTW actually the largest amount of known plain text is with certificate, when the whole public certificate chain is being passed). Regards, Moshe Attachment Converted: "C:\Temp\moshe.vcf" From ???@??? Wed Oct 27 08:23:09 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06720 for ; Wed, 27 Oct 1999 08:05:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04237 Wed, 27 Oct 1999 09:26:04 -0400 (EDT) Message-ID: <3816CB1B.4167A880@checkpoint.com> Date: Wed, 27 Oct 1999 11:51:23 +0200 From: Moshe Litvin X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Stephane Beaulieu , wprice@cyphers.net, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC9812@exchange> <3815E0ED.F8C11745@redcreek.com> Content-Type: multipart/mixed; boundary="------------551C72AF621C0C49C1634ED7" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 5fa9664ec0c1fecaf9fac01d2dacc615 Scott, "Scott G. Kelly" wrote: > Stephane Beaulieu wrote: > > What would those be? > > > > I've heard... > > > > 1 - It encourages the use of weak pre-shared keys. - Perhaps, but this can > > easily be fixed in XAUTH. I would still like to get a concensus on this. > > This "easy" fix requires deployment of client certificates. Deployment of client certificates together with hardware tokens (preferably FIPS 140-1 level 4 certified) is the best fix. The easy secure fix is hybrid. > > 2 - It's too complicated to be secure... Please ! > > Prove to me that it's secure. Better review your predicate logic > first... Let's start from the beginning, all the suggested protocols are based on IKE, so we can start with a proof of security for IKE. Then we can try to give a proof in the same level for the other suggestions. > > 3 - Too much known plain text. - All three proposals (XAUTH, CRACK, and ULA > > have know plain text. > > None have the copious amounts of ASCII TEXT that xauth does. Some known > plaintext may be unavoidable, but xauth has a ridiculous amount. Know plain text is non-issue (BTW actually the largest amount of known plain text is with certificate, when the whole public certificate chain is being passed). Regards, Moshe Attachment Converted: "C:\Temp\moshe2.vcf" From ???@??? Wed Oct 27 14:33:50 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13429 for ; Wed, 27 Oct 1999 12:53:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05645 Wed, 27 Oct 1999 14:28:40 -0400 (EDT) Message-Id: <3.0.6.32.19991027121504.00acf380@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 27 Oct 1999 12:15:04 +0200 To: ipsec@lists.tislabs.com From: Rodney Thayer Subject: Re:-ipsec-pki-req-03 - intro Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: bba121d1f81db3873a73c61b65eb6ecb This is a DRAFT. It's not an RFC. It's not a BCP. One of the very disturbing things about the IPsec RFC's is that I find, in my travels, that there are people out there reading them as the gospel truth, including the really lame stuff. So, labelling this with the truth, i.e. the fact it's not terribly synchronized, is ADDING value for implementors, in that it tells them this is unstable. Many many many labor-hours were wasted over many years in the IPsec communities because drafts were unstable and therefore, we had implementations that were severely jerked around because of this sort of things. So I thing the addition of warning labels is appropriate. >From: Brian Korver >Greg Carter writes: >> >From 1. Introduction, first paragraph: >> >> "Note that many IPsec implementers are not completely happy with the PKIX >> documents and procedures, but have agreed to use the PKIX protocols because >> they are supported in other contexts and have a significant market share." >> >> and last paragraph >> >> "(It is noted that the fact that the two documents differ does not give >> great confidence to the IPsec community or other users of the PKIX >> protocols.)" >> >> Both of these, whether or not true, are opinions and don't really do >> anything to help implementers beside adding confusion. I would suggest they >> be taken out for clarity. From ???@??? Wed Oct 27 14:33:50 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14259 for ; Wed, 27 Oct 1999 14:07:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05595 Wed, 27 Oct 1999 14:20:47 -0400 (EDT) Message-Id: <3.0.6.32.19991027121623.00acf780@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 27 Oct 1999 12:16:23 +0200 To: ipsec@lists.tislabs.com From: Rodney Thayer Subject: Re:-ipsec-pki-req-03 - subject/subjectAltName Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 87dc82e59a0fb79020f021cedee0c799 This is a comment on the subject distinguished name / subject alternative name issue. At 'the ANX-sponsored CA meeting in Needham Massachusetts' a couple of years ago, we had a conversation about this. It was claimed that certain environments will break if you do not have a subject distinguished name. My original proposal was that we invent a convention of commonName = see-subject-alt-name for this case. Events in the PKIX community overtook this. I think, therefore, that the justification of this requirement has become deprecated. I suggest we revert to following PKIX. I'll let Greg and Paul flash their respective PKIX lawyer id badges at each other and come up with some PKIX-compatible statement here, but let's stop requiring subject distinguished name contents be anything different from what PKIX wants. On the subject of limits to the name, I am afraid I instigated this. I thought there were not limits on this in PKIX. My point was that we should put in SOME limit on name length. If PKIX has something, I don't have a reason to use a different number. This allows us to be compatible (or bug-compatible) with PKIX on this point. I don't think X.509 is relevant. It's an ugly old legacy standard. PKIX's slavish devotion to it is quaint but we should move beyond that. Quoting X.509 specs is not relevant here, we're not building TP Class 4 over ISO IP... >From: Brian Korver >Greg Carter writes: >> In Section 3.2 The subjectAltName field, last paragraph: >> "The subject field in IPsec certificates SHOULD be populated and non-null >> (this is contrary to the PKIX certificate profile, which says that the >> subject MUST NOT be populated if the identification is in the subjectAltName >> field)" >> >> This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name >> that: >> >> Further, if the only subject identity included in the certificate is an >> alternative name form (e.g., an electronic mail address), then the subject >> distinguished name MUST be empty (an empty sequence), and the subjectAltName >> extension MUST be present. If the subject field contains an empty sequence, >> the subjectAltName extension MUST be marked critical. >> >> The important phase being "if the ONLY subject identity included in the >> certificate is an alternate name form". It does not say "If the alternate >> name form is used then NO subject distinguished name may be present." which >> is how I read section 3.2. For clarity I would stick with the PKIX >> definitions of how subject and alternate names are to be used and remove the >> last paragraph. >> >> If ONLY the alternate name is to be used then the subject should be left >> empty as PKIX states. However in practice I do not know of any >> implementations that only identify the 'device' by alternate name. For >> administration purposes they will always have a subject name, however there >> may exist a situation where someone would like to restrict to only using the >> alternate name for identification and the only way to do this is with an >> empty subject. >> >> Also in the last paragraph of section 3.2: >> "Distinguished names SHOULD be no more than four attribute/value pairs, each >> of which SHOULD be no more than 128 characters in length (these restrictions >> do not appear in the PKIX certificate profile)." >> >> Again these are too restrictive. Names in the subject/issuer are dictated >> by the customers directory setup (for those using one). In practice I have >> seen longer names than 4 attribute/value pairs. Length... well I don't know >> much about multi char character sets but I wouldn't want to limit anything >> which would prevent IPSec certificates being used in foreign languages. > >Agreed. Plus, X.509 already defines upper bounds for the common DN fields, >for instance: > > ub-common-name INTEGER ::= 64 > ub-organization-name INTEGER ::= 64 > >Why not stick with these? > >As for multi-byte character sets, ASN.1 SIZE constraints apply to the >number of actual characters, not the total number of bytes required >to represent the characters. So, if the upper-bound constraint is 64 >characters and your character set requires 2 bytes per character, then >the maximum number of bytes is 128. From ???@??? Wed Oct 27 14:33:50 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13452 for ; Wed, 27 Oct 1999 12:55:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05601 Wed, 27 Oct 1999 14:21:13 -0400 (EDT) Message-Id: <3.0.6.32.19991027122038.00acf7d0@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 27 Oct 1999 12:20:38 +0200 To: ipsec@lists.tislabs.com From: Rodney Thayer Subject: Re:-ipsec-pki-req-03 - certificate validity Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: ba0aa9b6cacb75a4823f6742b60ec184 This is a comment on certificate validity. The original intent of this section was to require validity, which we all agree we should worry about, as opposed to CRL's, which many people don't use. When the document was converted to PKIX compatibility (such as it is) this mutated into a CRL requirement. I don't think we can assume LDAP servers (certainly not behind gateways!) or any other specific means for validity checking. If we are to put on blinders for PKIX compatability, then fine. >From: Greg Carter >To: "'Paul Hoffman'" , ipsec@lists.tislabs.com >Subject: CRLs >Date: Tue, 26 Oct 1999 17:47:05 -0400 >X-Mailer: Internet Mail Service (5.5.2448.0) >Sender: owner-ipsec@lists.tislabs.com > >ISAKMP has a certificate request payload, with various types, including CRL >and ARL. > >If your implementation determines it can not retrieve CRLs via its regular >method (LDAP etc.) then include a Certificate Request payload with type set >to CRL (you should also include one for ARL so that when a chain is sent you >get the various ARLs needed to verify the CA certificates). When you >receive a Certificate Request payload with type CRL you MUST reply with the >DER encoded CRL that your certificate would be listed on if it were to be >revoked. This requires that at least one side has access to the CRL >repository. > > >So don't send it unless asked, if asked the above covers how. If they ask >then they can process, so there shouldn't be interop problems. If they ask >and you can't produce then you have a problem, if you can't produce because >you don't support CRLs than that is your problem. If you only support OCSP >as a gateway and the OCSP server is behind your gateway your SOL. If you >only support OCSP and you expect to intero with clients that don't and the >CRL repository is behind your gateway then you are SOL. > >So I think gateways should be prepared to respond with a CRL. Its a very >convenient method of transporting CRLs. > >Putting the LDAP server behind the gateway is common. >Bye. > >Greg Carter >Entrust Technologies - http://www.entrust.com >http://www.ford-trucks.com/articles/buildup/dana60.html > > >-----Original Message----- >From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >Sent: Monday, October 25, 1999 8:45 PM >To: ipsec@lists.tislabs.com >Subject: Re: Query on draft-ietf-ipsec-pki-req-03.txt > > >At 07:55 AM 10/19/99 -0700, Walker, Jesse wrote: > >>The draft includes the following text in Section 2: >> IKE systems conforming to this profile MUST check the >> revocation statusof any certificate on which they rely, using >> the algorithm described inthe PKIX certificate profile. Thus, >> every conforming IKE system MUSThave a method for >> receiving up-to-date revocation information for thecertificates >> it is validating. >>What do you intend this to mean in the remote access case? One normal >>operational scenario will have the CRL distribution point the remote IPSec >>host needs to validate the security gateway's certificate behind the >>security gateway. > >I don't think putting a CRL source (such as an FTP or LDAP server) behind a >security gateway is the normal case. The main reason to do that is to hide >the identities of the certificates you have revoked (which might have a >business purpose). Normally, these are wide open. > >> In such a case, unless it has already obtained the CRL via >>an alternate channel, the remote host will be unable to meet the above >>requirement. > >And, I think that "unless" is exactly right: you must use the information >you have. > >> Seemingly the best that it could be able to do is to establish >>IKE and IPSec security associations, then attempt to obtain the CRL, and >>then decide what to do on the basis of whether or not it could get the CRL >>or the security gateway's cert gets validated. Maybe we need to require >>implementations to send the latest CRL known to them during the IKE phase 1 >>negotiation? > >I would be against that because some CRLs will be very large. In the case >of a hidden CRL DP, I'd say "you must use what you already know". I think >it is good to say "if the device knows that its CRL DP is not currently >available to the other party behind a security gateway, that device SHOULD >send its CRL". > >-=-=-=-=-= > >At 08:06 AM 10/19/99 -0700, Walker, Jesse wrote: > >>Section 3.2 says >> The subject field in IPsec certificates SHOULD be populated and >>non-null >> (this is contrary to the PKIX certificate profile, which says >>thatthe subject >> MUST NOT be populated if the identification is in >thesubjectAltName >> field). The exact contents of this field are notstandardized. By >>convention, a >> minimal subject field containscountryName and commonName. >>Distinguished >> names SHOULD be no more thanfour attribute/value pairs, each of >>which >> SHOULD be no more than 128 characters in length (these >restrictions >>do >> not appear in the PKIXcertificate profile). An IKE implementation >>that >> conforms to thisprofile SHOULD NOT reject a certificate that does >>not >> follow theserules. >> >>Why? The rationale for this requirement is not immediately obvious. > >Personally, I think it is completely lame. I would like to rip that >wholerement out of the spec. Would anyone object to me doing so? That is, >has anyone shipped an implementation that is so non-compliant that it >*requires* a non-null subject even though there's a subjectAltName? > >-=-=-=-=-= > >At 12:28 PM 10/19/99 -0400, Greg Carter wrote: > >> >From 1. Introduction, first paragraph: >> >>"Note that many IPsec implementers are not completely happy with the PKIX >>documents and procedures, but have agreed to use the PKIX protocols because >>they are supported in other contexts and have a significant market share." >> >>and last paragraph >> >>"(It is noted that the fact that the two documents differ does not give >>great confidence to the IPsec community or other users of the PKIX >>protocols.)" >> >>Both of these, whether or not true, are opinions and don't really do >>anything to help implementers beside adding confusion. I would suggest >they >>be taken out for clarity. > >Rodney and I put them in to indicate that the reader shouldn't assume that >reading the PKIX documentation literally is a good idea. > >> >From section 3.1 The extendedKeyUsage field: >> >>"In a certificate for an IPsec end entity, the extendedKeyUsage field >>commonly called "EKU") MUST be present and MUST contain only the object >>identifier iKEIntermediate >>(iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or >>1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT >>accept end-entity certificates that do not follow this rule." >> >>Why must the certificate only have the one extended key usage? This is too >>restrictive. I like the idea of only having one IPSec extended key usage >>bit though. Could we stick with PKIX and say that if flagged critical then >>it must only have one value. Therefore you could remove the "and MUST >>contain only the object identifier iKEIntermediate..." since that would be >>covered by PKIX RFC 2459 section 4.2.1.13 for critical extended key usage >>extensions. > >I agree with this. I can see many reasons why a CA would create a single >cert for an IKE system that might have multiple uses. > >>In Section 3.2 The subjectAltName field, last paragraph: >>"The subject field in IPsec certificates SHOULD be populated and non-null >>(this is contrary to the PKIX certificate profile, which says that the >>subject MUST NOT be populated if the identification is in the >subjectAltName >>field)" >> >>This is not true, PKIX states in section 4.2.1.7 Subject Alternative Name >>that: >> >>Further, if the only subject identity included in the certificate is an >>alternative name form (e.g., an electronic mail address), then the subject >>distinguished name MUST be empty (an empty sequence), and the >subjectAltName >>extension MUST be present. If the subject field contains an empty sequence, >>the subjectAltName extension MUST be marked critical. >> >>The important phase being "if the ONLY subject identity included in the >>certificate is an alternate name form". It does not say "If the alternate >>name form is used then NO subject distinguished name may be present." which >>is how I read section 3.2. For clarity I would stick with the PKIX >>definitions of how subject and alternate names are to be used and remove >the >>last paragraph. > >I agree. > >>If ONLY the alternate name is to be used then the subject should be left >>empty as PKIX states. However in practice I do not know of any >>implementations that only identify the 'device' by alternate name. For >>administration purposes they will always have a subject name, however there >>may exist a situation where someone would like to restrict to only using >the >>alternate name for identification and the only way to do this is with an >>empty subject. > >And here we disagree. How are such CA's identifying an IKE system in the >subject? If you mean "kludging the IP address or DNS name into a subject >field", I have no problem saying that that MUST NOT be done in this >profile. How do others feel about this? > >>Also in the last paragraph of section 3.2: >>"Distinguished names SHOULD be no more than four attribute/value pairs, >each >>of which SHOULD be no more than 128 characters in length (these >restrictions >>do not appear in the PKIX certificate profile)." >> >>Again these are too restrictive. Names in the subject/issuer are dictated >>by the customers directory setup (for those using one). In practice I have >>seen longer names than 4 attribute/value pairs. Length... well I don't >know >>much about multi char character sets but I wouldn't want to limit anything >>which would prevent IPSec certificates being used in foreign languages. > >Agree. > >> >From Appendix A: >> >>"Regardless of the protocol used, a CA who gets an IKE system's enrollment >>request that includes the subject and subjectAltName desired for the device >>MUST include exactly the same subject and subjectAltName in the >>certificate. If the CA does not want to issue a certificate with the same >>subject and subjectAltName that was requested, the CA MUST NOT issue a >>certificate with a different name and subjectAltName." >> >>This places an unnecessary burden on the end entity to determine what >>exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to >change >>the DN that is in the request. If the device must have the exact DN then >it >>means a user somewhere has to type it in, very prone to failure. > >I agree. I think we should take out that restriction. If the IKE system >doesn't like the cert it gets (for example, because the CA changed the >subject or subjectAltName), the system doesn't have to use that cert. > >> Also there >>is no mention of how to verify the request at the CA. The device should >>generate a hash of the der encoded request and make it available to the >>devices administrator for verification at the CA. Otherwise the request is >>accepted without verification. > >This makes sense to me, and could be part (obviously) of the out-of-band >info. > >> Also mention of how to obtain the CAs keys >>in a secure way, similarly usually done with a hash of the CAs der encoded >>certificate. May want to add this to the security section?... > >This could be added. It's covered in PKIX, but yet another paragraph in the >security section is always safe... > > > >--Paul Hoffman, Director >--VPN Consortium > > From ???@??? Wed Oct 27 14:33:50 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13380 for ; Wed, 27 Oct 1999 12:51:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05578 Wed, 27 Oct 1999 14:20:33 -0400 (EDT) Message-Id: <3.0.6.32.19991027122417.00acf380@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 27 Oct 1999 12:24:17 +0200 To: ipsec@lists.tislabs.com From: Rodney Thayer Subject: Re:-ipsec-pki-req-03 - EKU's In-Reply-To: <38164C72.6E1A7A23@cs.stanford.edu> References: <01E1D01C12D7D211AFC70090273D20B10197D71C@sothmxs06.entrust.com> <4.2.1.19991026092935.0302c5b0@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: cc2cd5163ee52885947f5a46a20f5605 Regarding the EKU discussion... I originally put in two kinds of EKU's -- one for end systems and one for intermediate systems. It is my opinion that you want to be able to label a certificate with this information: -- it's for IPsec -- it's for an end system (only this machine) -- it's for a gateway ("intermediate") system (it can do IPsec for packets it forwards At the Binghampton bakeoff, we had a disscussion of this, and (a then-Cisco employee now working in Santa Cruz) complained this was too complicated, so the consensus was altered to have only one key usage for ipsec. Since Intermediate was at that time deployed, we chose that one. I still think we need the three factoids in the certificate, somehow. Per Paul Hoffman's arguments, which I wholeheartedly agree with (much to my disgust), we should use some PKIX-based style/format/oid/whatever to communicate these factoids, if in fact they should be conveyed in the certificate. I do not know of anyone REQUIRING EKU. I do know of multiple implementations of it today. So... I would suggest we put back the other EKU value (which, by the way, I got assigned by IANA already...) for ikeEndSystem. If there's a PKIX lawyer in the room, and they have some mechanism other than EKU that is more culturally compatible with PKIX, we should discuss that. As I understand it, EKU is a "PKIX-style" feature, though, so we're ok on that point. On the subject of "how many EKU's can you have", I don't think we should prohibit others, however I vaguely recall this was some sort of PKIX requirement. I myself have seen people wanting "swiss army certificates" which enable SSL, SMIME, IPsec, right turn on red without stopping, and all sorts of other features. I happen to think that's unsafe, but it does seem to be a requirement. I would like to allow multiple EKU's. At 05:51 PM 10/26/99 -0700, Brian Korver wrote: >Paul Hoffman wrote: >> >> At 04:35 PM 10/25/99 -0700, Brian Korver wrote: >> >Why require that extendedKeyUsage be mandatory at all? >> >> To identify the cert as being for IKE. I've been told that today's IKE >> systems use this OID as identification. I believe we should have *one* OID >> for all IKE implementations, and not try to slice and dice between "client" >> and "gateway" and so on. >> >> Are there any IPsec implementations using the IPsec OIDs specified in RFC >> 2459? Are there any implementations that require the use of other OIDs, >> like IKEend (1.3.6.1.5.5.8.2.1)? >> >Why is there a requirement to identify certificates as "for use with IKE"? > >BTW, I haven't heard of any implementations that require these IKE OIDs in >ExtendedKeyUsage. Perhaps someone else has. From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA03228 for ; Wed, 27 Oct 1999 05:54:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03557 Wed, 27 Oct 1999 07:12:10 -0400 (EDT) Message-ID: <3816DEC3.66115155@DataFellows.com> Date: Wed, 27 Oct 1999 14:15:15 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vipul Gupta CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <199910262024.NAA16410@ha1mpk-mail.eng.sun.com> Content-Type: multipart/alternative; boundary="------------C22FAC014D7033AF2E54CACF" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 3fa766f1db41ed972f7e720c4614e29f Vipul Gupta wrote:
> In message <3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes:
>
> >
> > Let me ask everyone who is interested;  How do we support existing
> > legacy user authentication within IKE without using a PKI ?
>
> With a protocol that lets the customer download an encrypted private key/
> certificate pair from a server, followed by ordinary IKE.
>
>               --Steve Bellovin
>

  A perfect lead-in for what I've been thinking about for some time
  now :-)

  How about using an HTML forms based interaction over HTTPS between
  a webserver and a user to accomplish what you state.

           Internet                           Intranet

                               |
                               |          +--> Legacy Auth server
           SSL/TLS protected   |         /
     user =================== HTTPS <---+
                              server
                               |
                               |

   This interaction can easily accomodate legacy user auth mechanisms
   like SecureID, DES Gold, OTP, CHAP because the HTTPS server has access
   to authentication tokens in the clear. Even multiple rounds don't
   pose a problem. After the Auth server responds with "OK", the
   HTTP server can squirt out a special MIME datatype and the browser
   could be set up to automatically invoke the IKE daemon (or companion
   software) to handle that MIME type. The HTTPS may need to coordinate
   with the IPSec gateway on the Intranet side.

   This could be a reasonable solution for the road warrior VPN scenario.
   I've heard Paul Hoffman use the term "user authentication in Phase 0.5"
   for an approach like this (in contrast to Hybrid's Phase 1.5).

   (Maybe now's a good time to go look for that fire extingusher :-)).

   vipul

That's not a bad idea in itself, although I'd rather not have the requirement
to implement HTTPS just to be able to implement legacy authentication
support in IKE!

However, let me quote an earlier email that I sent:

There's another architectural thing you should consider. What about modifying
the protocol so that when the server starts believing in the authenticity of the
client, the server issues the client's public key a certificate? This certificate
would have a very limited life-time, just enough for the purpose at hand.
It would be transported to the client in the 'last' message, whatever that is.

Although this creates more public key operations, the legacy authentication
functionality could be located on a different physical box than the actual
security gateway.. This achieves a very similar function to the Kerberos ticket
granting server, and the certificate is similar to Kerberos tickets. You'd of
course have to set up the trust relations appropriately.

There could also exist "one time certificates" that can be used only once
during their life-time to gain access, similar to one time passwords. Some
way or another they would be revoked the moment they are used.


If you wanted, you could transport such a certificate through HTTPS to the client.
Although, as said, I'd rather not have HTTPS in the picture.

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security
  From ???@??? Wed Oct 27 07:36:25 1999 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01081 for ; Wed, 27 Oct 1999 04:24:20 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA12786 for ietf-123-outbound.10@ietf.org; Wed, 27 Oct 1999 07:25:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12699 for ; Wed, 27 Oct 1999 07:15:50 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05225; Wed, 27 Oct 1999 07:15:51 -0400 (EDT) Message-Id: <199910271115.HAA05225@ietf.org> To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: The Use of HMAC-RIPEMD-160-96 within ESP and AH to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 27 Oct 1999 07:15:51 -0400 Sender: scoya@cnri.reston.va.us X-UIDL: f4af6fb3b817759323e6b2f27eb70a3b The IESG has received a request from the IP Security Protocol Working Group to consider The Use of HMAC-RIPEMD-160-96 within ESP and AH as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 16, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt From ???@??? Wed Oct 27 08:23:09 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06759 for ; Wed, 27 Oct 1999 08:08:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04238 Wed, 27 Oct 1999 09:26:05 -0400 (EDT) Message-Id: <199910271115.HAA05225@ietf.org> To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: The Use of HMAC-RIPEMD-160-96 within ESP and AH to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 27 Oct 1999 07:15:51 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: de5525b4ea7c3e9965dbe99057439c6f The IESG has received a request from the IP Security Protocol Working Group to consider The Use of HMAC-RIPEMD-160-96 within ESP and AH as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 16, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04618 for ; Wed, 27 Oct 1999 06:34:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03725 Wed, 27 Oct 1999 08:01:42 -0400 (EDT) Message-Id: <199910271204.IAA06949@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-base-mode-01.txt Date: Wed, 27 Oct 1999 08:04:16 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 181eea481685e5c6e077f2912053c1ba A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IKE Base Mode Author(s) : Y. Dayan, S. Bitan Filename : draft-ietf-ipsec-ike-base-mode-01.txt Pages : 6 Date : 26-Oct-99 This document describes a new Phase I mode for IKE [RFC-2409] based on the ISAKMP [RFC-2408] Base Exchange. The purpose of this new exchange is to allow support of all authentication methods with fixed and non-fixed IP addresses, while offering protection against a denial of service attack aimed at costly operations. It also enables negotiation capabilities beyond those offered by Aggressive Mode (DH/EC group). The exchange consists of only four messages and therefor is useful when performance is crucial. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-base-mode-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-ietf-ipsec-ike-base-mode-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-base-mode-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. Content-Type: text/plain Content-ID: <19991026145107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-base-mode-01.txt From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04980 for ; Wed, 27 Oct 1999 06:43:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03741 Wed, 27 Oct 1999 08:03:48 -0400 (EDT) Message-Id: <199910271206.IAA07088@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kitamura-ipv6-hbh-ext-csi-01.txt Date: Wed, 27 Oct 1999 08:06:23 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: b00b0714892cd58fa48102e1e84211d2 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Connection/Link Status Investigation (CSI) for IPv6 IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-hbh-ext-csi-01.txt Pages : 43 Date : 26-Oct-99 This document proposes a new mechanism called 'Connection/Link Status Investigation (CSI)'. It is designed to collect status information of nodes along the communication path. One new IPv6 Hop-by-Hop option (CSI option) and three new ICMPv6 messages (Status Request/Reply, and Status Report) are proposed as extensions for the CSI mechanism. The CSI mechanism is based on hop-by-hop data acquisition operations and realtime 'boomerang' action messages. It is simple and can investigate both outgoing and incoming paths between the source and the destination with minimum investigation packets. It can provide various new functions (e.g. realtime consumed bandwidth measurement, etc.). Since it has good characteristics, it is possible to innovate current investigation functions (e.g., 'traceroute', 'pathchar', etc.) This document describes specifications of the CSI mechanism and defines a set of basic data types. The CSI mechanism is designed as a generic framework mechanism. By defining new data types to collect, it can be easily applied to various advanced usages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-hbh-ext-csi-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-kitamura-ipv6-hbh-ext-csi-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-kitamura-ipv6-hbh-ext-csi-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. Content-Type: text/plain Content-ID: <19991026145218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-hbh-ext-csi-01.txt From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04952 for ; Wed, 27 Oct 1999 06:42:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03758 Wed, 27 Oct 1999 08:04:53 -0400 (EDT) Message-Id: <199910271207.IAA07194@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-padma-dnsind-externalkeys-00.txt Date: Wed, 27 Oct 1999 08:07:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 82f43a373beba154dd9ec649f5b63aa6 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inter-operability of Secure Domain Name System with Other Key Distribution Services Author(s) : M. Padmaja, J. Rao Filename : draft-padma-dnsind-externalkeys-00.txt Pages : 8 Date : 26-Oct-99 There are several mechanisms for distributing public keys and certificates today. These distribution services publish certificates which contain cryptographic public keys. Clients that use any of these distribution services to retrieve certificates, require additional software for the retrieval, parsing and verification of these certificates. In this draft, we propose an alternate scheme that takes advantage of the Secure DNS infrastructure to distribute verified public keys obtained from other distribution services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-padma-dnsind-externalkeys-00.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-padma-dnsind-externalkeys-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-padma-dnsind-externalkeys-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991026145347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-padma-dnsind-externalkeys-00.txt From ???@??? Wed Oct 27 08:42:34 1999 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07493 for ; Wed, 27 Oct 1999 08:37:18 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA16043 for ietf-123-outbound.10@ietf.org; Wed, 27 Oct 1999 11:35:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA13305 for ; Wed, 27 Oct 1999 08:07:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07194; Wed, 27 Oct 1999 08:07:29 -0400 (EDT) Message-Id: <199910271207.IAA07194@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-padma-dnsind-externalkeys-00.txt Date: Wed, 27 Oct 1999 08:07:28 -0400 Sender: nsyracus@cnri.reston.va.us X-UIDL: a12f470fd5fd8a9c69d4a726c6fdd459 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inter-operability of Secure Domain Name System with Other Key Distribution Services Author(s) : M. Padmaja, J. Rao Filename : draft-padma-dnsind-externalkeys-00.txt Pages : 8 Date : 26-Oct-99 There are several mechanisms for distributing public keys and certificates today. These distribution services publish certificates which contain cryptographic public keys. Clients that use any of these distribution services to retrieve certificates, require additional software for the retrieval, parsing and verification of these certificates. In this draft, we propose an alternate scheme that takes advantage of the Secure DNS infrastructure to distribute verified public keys obtained from other distribution services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-padma-dnsind-externalkeys-00.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-padma-dnsind-externalkeys-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-padma-dnsind-externalkeys-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991026145347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-padma-dnsind-externalkeys-00.txt From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05305 for ; Wed, 27 Oct 1999 06:57:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03840 Wed, 27 Oct 1999 08:19:43 -0400 (EDT) Message-Id: <199910271222.IAA07922@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gupta-ipsec-remote-access-03.txt Date: Wed, 27 Oct 1999 08:22:18 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 7634b9e0c449548126e340ae947303ba A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure, Remote Access over the Internet using IPSec Author(s) : V. Gupta Filename : draft-gupta-ipsec-remote-access-03.txt Pages : 19 Date : 26-Oct-99 This memo describes the use of IPSec [KeAt98a-c] for secure access to protected networks by authorized users connected to the Internet. An example target scenario is a corporate employee on the road accessing resources on his company's Intranet. It addresses firewall traversal, user authentication, data confidentiality and the use of private address spaces (the latter impacts routing and name lookups). A comparison to other mechanisms such as those based on Layer-2 tunneling or session layer security, is also included. This memo draws upon several ideas from [Dora97,Mosk98] and would not have been possible without the contributions of the IETF working groups on IP Security (IPSec) and Network Address Translation (NAT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-03.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-gupta-ipsec-remote-access-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-gupta-ipsec-remote-access-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991026145705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gupta-ipsec-remote-access-03.txt From ???@??? Wed Oct 27 14:33:51 1999 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11306 for ; Wed, 27 Oct 1999 11:15:15 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA18577 for ietf-123-outbound.10@ietf.org; Wed, 27 Oct 1999 14:15:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA13535 for ; Wed, 27 Oct 1999 08:22:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07922; Wed, 27 Oct 1999 08:22:19 -0400 (EDT) Message-Id: <199910271222.IAA07922@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gupta-ipsec-remote-access-03.txt Date: Wed, 27 Oct 1999 08:22:18 -0400 Sender: nsyracus@cnri.reston.va.us X-UIDL: d148aeac930ae7cc94477f5afaabcbc5 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure, Remote Access over the Internet using IPSec Author(s) : V. Gupta Filename : draft-gupta-ipsec-remote-access-03.txt Pages : 19 Date : 26-Oct-99 This memo describes the use of IPSec [KeAt98a-c] for secure access to protected networks by authorized users connected to the Internet. An example target scenario is a corporate employee on the road accessing resources on his company's Intranet. It addresses firewall traversal, user authentication, data confidentiality and the use of private address spaces (the latter impacts routing and name lookups). A comparison to other mechanisms such as those based on Layer-2 tunneling or session layer security, is also included. This memo draws upon several ideas from [Dora97,Mosk98] and would not have been possible without the contributions of the IETF working groups on IP Security (IPSec) and Network Address Translation (NAT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-03.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-gupta-ipsec-remote-access-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-gupta-ipsec-remote-access-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991026145705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gupta-ipsec-remote-access-03.txt From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: by ns.secondary.com (8.9.3/8.9.3) id HAA05490 for ietf-ipsra-bks; Wed, 27 Oct 1999 07:04:26 -0700 (PDT) Received: from sword.cisco.com (sword.cisco.com [161.44.208.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05484 for ; Wed, 27 Oct 1999 07:04:24 -0700 (PDT) Received: from cisco.com (ottawa-dhcp-176.cisco.com [171.70.78.176]) by sword.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04756; Wed, 27 Oct 1999 10:05:58 -0400 (EDT) Message-ID: <38170658.AC2CC273@cisco.com> Date: Wed, 27 Oct 1999 10:04:08 -0400 From: Roy Pereira Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Stephane Beaulieu , Dan Harkins , Moshe Litvin , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC97E6@exchange> <3815F49E.BFABF7C9@cisco.com> <3815FA78.308C3CEB@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-UIDL: 941e693489cc6326985355d66af5a290 "Scott G. Kelly" wrote: > > Hi Roy, > > Roy Pereira wrote: > > > > The point here is that XAUTH merely extends IKE and thus incorporates > > all of its security (or lack of). Why is shared-secret IKE different > > than shared-secret XAUTH? > > Really, Roy - you surprise me sometimes. You know the answer to this as > well as anyone, but I'll spell it out for expediency. It's different due > to context - xauth is specifically for remote access. Remote access > users typically do not have fixed IP addresses, so we have no way to > identify the preshared key in main mode. Hence, all remote access users > with preshared keys are often configured to use the same key. This is > bad. I understand the issues with main mode and remote access users. My point is that the issue with group-shared-secrets is and issue within IKE itself, not XAUTH. XAUTH can as easily use Aggressive Mode to allow for unique shared secrets. From ???@??? Wed Oct 27 09:05:13 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08113 for ; Wed, 27 Oct 1999 08:52:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04618 Wed, 27 Oct 1999 10:04:26 -0400 (EDT) Message-ID: <38170658.AC2CC273@cisco.com> Date: Wed, 27 Oct 1999 10:04:08 -0400 From: Roy Pereira Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Stephane Beaulieu , Dan Harkins , Moshe Litvin , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <319A1C5F94C8D11192DE00805FBBADDFEC97E6@exchange> <3815F49E.BFABF7C9@cisco.com> <3815FA78.308C3CEB@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 80880852ae087830638042e7249ef8ba "Scott G. Kelly" wrote: > > Hi Roy, > > Roy Pereira wrote: > > > > The point here is that XAUTH merely extends IKE and thus incorporates > > all of its security (or lack of). Why is shared-secret IKE different > > than shared-secret XAUTH? > > Really, Roy - you surprise me sometimes. You know the answer to this as > well as anyone, but I'll spell it out for expediency. It's different due > to context - xauth is specifically for remote access. Remote access > users typically do not have fixed IP addresses, so we have no way to > identify the preshared key in main mode. Hence, all remote access users > with preshared keys are often configured to use the same key. This is > bad. I understand the issues with main mode and remote access users. My point is that the issue with group-shared-secrets is and issue within IKE itself, not XAUTH. XAUTH can as easily use Aggressive Mode to allow for unique shared secrets. From ???@??? Wed Oct 27 07:36:19 1999 X-Persona: Received: by ns.secondary.com (8.9.3/8.9.3) id HAA05615 for ietf-ipsra-bks; Wed, 27 Oct 1999 07:10:10 -0700 (PDT) Received: from sword.cisco.com (sword.cisco.com [161.44.208.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05611 for ; Wed, 27 Oct 1999 07:10:08 -0700 (PDT) Received: from cisco.com (ottawa-dhcp-176.cisco.com [171.70.78.176]) by sword.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA05044; Wed, 27 Oct 1999 10:12:30 -0400 (EDT) Message-ID: <381707E0.A4105EFE@cisco.com> Date: Wed, 27 Oct 1999 10:10:40 -0400 From: Roy Pereira Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Stephane Beaulieu , Moshe Litvin , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Comments on CRACK References: <199910262008.NAA00883@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-UIDL: 1ad269035ee90a85eccfce4ecf5a7df9 Dan Harkins wrote: > > On Tue, 26 Oct 1999 14:36:14 EDT you wrote > "If mutual authentication is not required, then the phase 1 > negotiation MAY use an authentication method of shared-secret and > have that shared-secret be null." > > Which is just insane! You're saying that people can do an unauthenticated Yikes! You got me on that one. We'll take that one out asap. Looking over the draft, I think that stronger security language is required. Even to the point of stating that "group shared secrets SHOULD NOT be used with this protocol". Would that make everyone happy? From ???@??? Wed Oct 27 09:05:13 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08070 for ; Wed, 27 Oct 1999 08:49:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04634 Wed, 27 Oct 1999 10:11:13 -0400 (EDT) Message-ID: <381707E0.A4105EFE@cisco.com> Date: Wed, 27 Oct 1999 10:10:40 -0400 From: Roy Pereira Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Stephane Beaulieu , Moshe Litvin , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Comments on CRACK References: <199910262008.NAA00883@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 46455567f0dc52bff72eed8e7f202b2c Dan Harkins wrote: > > On Tue, 26 Oct 1999 14:36:14 EDT you wrote > "If mutual authentication is not required, then the phase 1 > negotiation MAY use an authentication method of shared-secret and > have that shared-secret be null." > > Which is just insane! You're saying that people can do an unauthenticated Yikes! You got me on that one. We'll take that one out asap. Looking over the draft, I think that stronger security language is required. Even to the point of stating that "group shared secrets SHOULD NOT be used with this protocol". Would that make everyone happy? From ???@??? Wed Oct 27 07:36:23 1999 X-Persona: Received: from ssh.fi (ssh.fi [194.100.44.97]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05684 for ; Wed, 27 Oct 1999 07:15:37 -0700 (PDT) Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43]) by ssh.fi (8.9.3/8.9.3/SSH-1.16) with ESMTP id RAA17591; Wed, 27 Oct 1999 17:18:46 +0300 (EEST) Received: (from kivinen@localhost) by torni.ssh.fi (8.9.3/8.9.3/SSH-1.14) id RAA29916; Wed, 27 Oct 1999 17:18:45 +0300 (EET DST) Date: Wed, 27 Oct 1999 17:18:45 +0300 (EET DST) Message-Id: <199910271418.RAA29916@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Greg Carter Cc: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: CRLs In-Reply-To: <01E1D01C12D7D211AFC70090273D20B10197D780@sothmxs06.entrust.com> References: <01E1D01C12D7D211AFC70090273D20B10197D780@sothmxs06.entrust.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 3 min X-UIDL: 01c9cabf4097c01caf4744c4ebebe9db Greg Carter writes: > So don't send it unless asked, if asked the above covers how. If they ask > then they can process, so there shouldn't be interop problems. If they ask If they cannot process CRLs inside the IKE then the implementation is broken, and does not follow the ISAKMP RFC. The ISAKMP RFC says very clearly that certificate payload MUST be accepted at any point during an exchange. The implementation can throw the CRL it received away, but it must be able to receive certificate payloads anywhere. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ???@??? Wed Oct 27 10:08:30 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09532 for ; Wed, 27 Oct 1999 09:59:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04648 Wed, 27 Oct 1999 10:16:12 -0400 (EDT) Date: Wed, 27 Oct 1999 17:18:45 +0300 (EET DST) Message-Id: <199910271418.RAA29916@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Greg Carter Cc: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: CRLs In-Reply-To: <01E1D01C12D7D211AFC70090273D20B10197D780@sothmxs06.entrust.com> References: <01E1D01C12D7D211AFC70090273D20B10197D780@sothmxs06.entrust.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 85cc7889373a6f4990fd266aaf6c4f55 Greg Carter writes: > So don't send it unless asked, if asked the above covers how. If they ask > then they can process, so there shouldn't be interop problems. If they ask If they cannot process CRLs inside the IKE then the implementation is broken, and does not follow the ISAKMP RFC. The ISAKMP RFC says very clearly that certificate payload MUST be accepted at any point during an exchange. The implementation can throw the CRL it received away, but it must be able to receive certificate payloads anywhere. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ???@??? Wed Oct 27 14:33:49 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12376 for ; Wed, 27 Oct 1999 11:48:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05180 Wed, 27 Oct 1999 12:59:15 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Ari Huttunen'" , Vipul Gupta Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comments on CRACK Date: Wed, 27 Oct 1999 10:01:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF209C.E5AB1126" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 8d412fed69a252a80d657c42d93f1e90

>>Vipul Gupta wrote:
>>> In message <
3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes:
>>>
>>> >
>>> > Let me ask everyone who is interested;  How do we support existing
>>> > legacy user authentication within IKE without using a PKI ?
>>>
>>> With a protocol that lets the customer download an encrypted private key/
>>> certificate pair from a server, followed by ordinary IKE.
>>>
>>>               --Steve Bellovin
>>>
>>  A perfect lead-in for what I've been thinking about for some time
>>  now :-)
>>
>>  How about using an HTML forms based interaction over HTTPS between
>>  a webserver and a user to accomplish what you state.
>>
>>           Internet                           Intranet
>>
>>                               |
>>                               |          +--> Legacy Auth server
>>           SSL/TLS protected   |         /
>>     user =================== HTTPS <---+
>>                              server
>>                               |
>>                               |
>>
>>   This interaction can easily accomodate legacy user auth mechanisms
>>   like SecureID, DES Gold, OTP, CHAP because the HTTPS server has access
>>   to authentication tokens in the clear. Even multiple rounds don't
>>   pose a problem. After the Auth server responds with "OK", the
>>   HTTP server can squirt out a special MIME datatype and the browser
>>   could be set up to automatically invoke the IKE daemon (or companion
>>   software) to handle that MIME type. The HTTPS may need to coordinate
>>   with the IPSec gateway on the Intranet side.
>>
>>   This could be a reasonable solution for the road warrior VPN scenario.
>>   I've heard Paul Hoffman use the term "user authentication in Phase 0.5"
>>   for an approach like this (in contrast to Hybrid's Phase 1.5).
>>
>>   (Maybe now's a good time to go look for that fire extingusher :-)).
>>
>>   vipul
>>
>>That's not a bad idea in itself, although I'd rather not have the requirement
>>to implement HTTPS just to be able to implement legacy authentication
>>support in IKE!
>
 
It need not be just for legacy authentication. It can also be used
for transporting configuration information, temporary certificates
(as you describe below) or even attribute certificates (if that
takes of).
 
>
>(as you d
>>However, let me quote an earlier email that I sent:
>>
>>There's another architectural thing you should consider. What about modifying
>>the protocol so that when the server starts believing in the authenticity of the
>>client, the server issues the client's public key a certificate? This certificate
>>would have a very limited life-time, just enough for the purpose at hand.
>>It would be transported to the client in the 'last' message, whatever that is.
>>
>>Although this creates more public key operations, the legacy authentication
>>functionality could be located on a different physical box than the actual
>>security gateway.. This achieves a very similar function to the Kerberos ticket
>>granting server, and the certificate is similar to Kerberos tickets. You'd of
>>course have to set up the trust relations appropriately.
>>
>>There could also exist "one time certificates" that can be used only once
>>during their life-time to gain access, similar to one time passwords. Some
>>way or another they would be revoked the moment they are used.
>
 
One of the question is
 
Should legacy authentication and configuration be part of IKE?
or should IKE remain just a key exchange protocol?
 
The way I see it is if legacy authentication is an intermediate
step towards a PKI world then
 
1) There must already legacy mechanisms in places to distribute
per-peer secret keys, and protocols to use it. It could be either
SSL/TLS or some other homegrown protocol. Otherwise what
are the legacy methods through which these legacy authentication
mechanisms are currently used? Why not continue to use them as they are
instead of retrofitting it into IKE?.
 
2) configuration  - configuration is independent of key exchange
and thus should be separate from IKE.
 
I hope that if IPSRA  move towards supporting legacy authentication and
and configuration mechanisms in IKE, it would spell out the reasons
for doing it in IKE versus implementing it as a separate protocol.
 
>>
>>If you wanted, you could transport such a certificate through HTTPS to the client.
>>Although, as said, I'd rather not have HTTPS in the picture.
>>
>>--
>>Ari Huttunen                   phone: +358 9 859 900
>>Senior Software Engineer       fax  : +358 9 8599 0452
>>
>>Data Fellows Corporation       http://www.DataFellows.com
>>
>>F-Secure products: Integrated Solutions for Enterprise Security
>> 
From ???@??? Wed Oct 27 14:33:50 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12561 for ; Wed, 27 Oct 1999 11:59:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05317 Wed, 27 Oct 1999 13:22:41 -0400 (EDT) Date: Wed, 27 Oct 1999 10:24:47 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: ipsec mailling list Subject: Main mode using pre-shared keys Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: c1705ac5547f9bba3a460c83035c962f RFC 2409 5.4 Phase 1 Authenticated With a Pre-Shared Key Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange. " "identified by the IP address of the peers" Does this mean that the ID payload content must be an IP Address, and it should be the same as the source IP address on the IKE packet that the peers are using? If the source IP address on the packet is used to search the pre-shared key, then we authenticate the peer, by the fact that the peer knows the shared secret associated with the IP address he is using. Inspite of that, is the RFC also advicing that we enforce, the ID payload content is the source IP address that was used to search the shared secret? If so, the confidentiality part of the Identity protection is not there, when using pre-shared keys. What are the consequenses of not enforceing the above requirement? We are authenticating the peer using the IP source address he is using, because we search the pre-shared key based on it, but we accept his ID to be anything. TIA, chinna chinna narasimha reddy pellacuru s/w engineer From ???@??? Wed Oct 27 14:33:50 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14359 for ; Wed, 27 Oct 1999 14:14:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05871 Wed, 27 Oct 1999 15:44:52 -0400 (EDT) Message-Id: <1.5.4.32.19991027192753.013805b0@hub.ecutel.com> X-Sender: qzhang@hub.ecutel.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1999 15:27:53 -0400 To: "CHINNA N.R. PELLACURU" From: Qiang Zhang Subject: Re: Main mode using pre-shared keys Cc: ipsec mailling list Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: d53c3a1cecf17dd5a73fe15dccecede4 At 10:24 AM 10/27/99 -0700, CHINNA N.R. PELLACURU wrote: >RFC 2409 > >5.4 Phase 1 Authenticated With a Pre-Shared Key > > Initiator Responder > ---------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, Ni --> > <-- HDR, KE, Nr > HDR*, IDii, HASH_I --> > <-- HDR*, IDir, HASH_R > > When using pre-shared key authentication with Main Mode the key can > only be identified by the IP address of the peers since HASH_I must > be computed before the initiator has processed IDir. Aggressive Mode > allows for a wider range of identifiers of the pre-shared secret to > be used. In addition, Aggressive Mode allows two parties to maintain > multiple, different pre-shared keys and identify the correct one for > a particular exchange. >" > > >"identified by the IP address of the peers" > >Does this mean that the ID payload content must be an IP Address, and it >should be the same as the source IP address on the IKE packet that the >peers are using? > >If the source IP address on the packet is used to search the pre-shared >key, then we authenticate the peer, by the fact that the peer knows the >shared secret associated with the IP address he is using. Inspite of that, >is the RFC also advicing that we enforce, the ID payload content is the >source IP address that was used to search the shared secret? Chinna, notice that the HASHi computation HAS to use the peer-address to search the preshared secret thus I think at least in this circumstance, the ID payload won't work. Further one thing to worry about is that the source address is not trustable due to all kinds of IP routing scheme. This is something I think the WG should give a solution. Qiang > >If so, the confidentiality part of the Identity protection is not there, >when using pre-shared keys. > >What are the consequenses of not enforceing the above requirement? We are >authenticating the peer using the IP source address he is using, because >we search the pre-shared key based on it, but we accept his ID to be >anything. > >TIA, chinna > >chinna narasimha reddy pellacuru >s/w engineer > > > From ???@??? Wed Oct 27 14:33:50 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14221 for ; Wed, 27 Oct 1999 14:04:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05836 Wed, 27 Oct 1999 15:27:55 -0400 (EDT) Message-ID: <38175245.97036593@cisco.com> Date: Wed, 27 Oct 1999 15:28:05 -0400 From: Roy Pereira Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: IPSEC List CC: Jan Vilhuber Subject: Initial Contact Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 4c7c6b8ca287ca4f0dad0c7d14694769 I have a question about the Initial-Contact message: >From the ipdoi rfc: 4.6.3.3 INITIAL-CONTACT The INITIAL-CONTACT status message may be used when one side wishes to inform the other that this is the first SA being established with the remote system. But, I would define INITIAL-CONTACT as "I dont have any other current SAs with you" since I had thought it is used to distinguish between a phase 1 rekey and a brand new phase 1. The definition above lends itself to ambiguity. Can we get better wording for this useful feature? From ???@??? Wed Oct 27 16:07:32 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16244 for ; Wed, 27 Oct 1999 15:52:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05964 Wed, 27 Oct 1999 16:13:16 -0400 (EDT) Date: Wed, 27 Oct 1999 16:15:31 -0400 Message-Id: <199910272015.QAA18269@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rodney@ssh.fi Cc: ipsec@lists.tislabs.com Subject: Re: Re:-ipsec-pki-req-03 - subject/subjectAltName References: <3.0.6.32.19991027121623.00acf780@127.0.0.1> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: cd74028689fa3ebb1850356656b1b1e9 >>>>> "Rodney" == Rodney Thayer writes: Rodney> On the subject of limits to the name, I am afraid I Rodney> instigated this. I thought there were not limits on this in Rodney> PKIX. My point was that we should put in SOME limit on name Rodney> length. If PKIX has something, I don't have a reason to use Rodney> a different number. This allows us to be compatible (or Rodney> bug-compatible) with PKIX on this point. Rodney> I don't think X.509 is relevant. It's an ugly old legacy Rodney> standard. PKIX's slavish devotion to it is quaint but we Rodney> should move beyond that. Quoting X.509 specs is not relevant Rodney> here, we're not building TP Class 4 over ISO IP... Agreed. on X.509. As for name length limits, I agree (with hesitation). But 64 is a bit tight for a name limit; look in a Sri Lanka phone book (or Madagascar, worse yet) for examples... paul From ???@??? Wed Oct 27 16:42:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17126 for ; Wed, 27 Oct 1999 16:19:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06256 Wed, 27 Oct 1999 17:52:29 -0400 (EDT) Message-ID: <38177573.3814C869@ibondinc.com> Date: Wed, 27 Oct 1999 14:58:11 -0700 From: Srinivasa Rao X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Vipul Gupta , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comments on CRACK References: <199910262024.NAA16410@ha1mpk-mail.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 9850f77c3bbbc547fa5d23d5a1b60982 Vipul Gupta wrote: > > In message <3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes: > > > > > > > > Let me ask everyone who is interested; How do we support existing > > > legacy user authentication within IKE without using a PKI ? > > > > With a protocol that lets the customer download an encrypted private key/ > > certificate pair from a server, followed by ordinary IKE. > > > > --Steve Bellovin > > > > A perfect lead-in for what I've been thinking about for some time > now :-) > > How about using an HTML forms based interaction over HTTPS between > a webserver and a user to accomplish what you state. > > Internet Intranet > > | > | +--> Legacy Auth server > SSL/TLS protected | / > user =================== HTTPS <---+ > server > | > | > > This interaction can easily accomodate legacy user auth mechanisms > like SecureID, DES Gold, OTP, CHAP because the HTTPS server has access > to authentication tokens in the clear. Even multiple rounds don't > pose a problem. After the Auth server responds with "OK", the > HTTP server can squirt out a special MIME datatype and the browser > could be set up to automatically invoke the IKE daemon (or companion > software) to handle that MIME type. The HTTPS may need to coordinate > with the IPSec gateway on the Intranet side. > > This could be a reasonable solution for the road warrior VPN scenario. > I've heard Paul Hoffman use the term "user authentication in Phase 0.5" > for an approach like this (in contrast to Hybrid's Phase 1.5). > > (Maybe now's a good time to go look for that fire extingusher :-)). > > vipul > > > This is one neat solution and works OK with browser ( user intervention is required ). What about a router which gets dynamic IP address from the ISP and needs to authenticate itself to the remote access router ( without user intervention )? Srini From ???@??? Wed Oct 27 16:51:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17427 for ; Wed, 27 Oct 1999 16:41:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06317 Wed, 27 Oct 1999 18:07:51 -0400 (EDT) Message-Id: <4.2.1.19991027150203.01c23a50@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 27 Oct 1999 15:06:30 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re:-ipsec-pki-req-03 - EKU's In-Reply-To: <3.0.6.32.19991027122417.00acf380@127.0.0.1> References: <38164C72.6E1A7A23@cs.stanford.edu> <01E1D01C12D7D211AFC70090273D20B10197D71C@sothmxs06.entrust.com> <4.2.1.19991026092935.0302c5b0@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 6905c2fc29f373e7a55ada9090f07faa At 12:24 PM 10/27/99 +0200, Rodney Thayer wrote: >Regarding the EKU discussion... > >I originally put in two kinds of EKU's -- one for end systems and >one for intermediate systems. It is my opinion that you want to be >able to label a certificate with this information: > > -- it's for IPsec > -- it's for an end system (only this machine) > -- it's for a gateway ("intermediate") system (it can do IPsec > for packets it forwards Question to the group: is there a value for both the second and third requirements? I have heard arguments both ways. >I do not know of anyone REQUIRING EKU. I do know of multiple >implementations of it today. I think we need to require it in the profile so that there is a definitive way for an IKE system to say "this cert can be used for IKE". Without such a requirement, the IKE system has to make too many guesses that can lead to lack of interoperability. >If there's a PKIX lawyer in the room, and they have some >mechanism other than EKU that is more culturally compatible >with PKIX, we should discuss that. As I understand it, EKU >is a "PKIX-style" feature, though, so we're ok on that point. I will play PKIX lawyer for a moment (even though I hear guffaws from the peanut gallery). We can put this either in EKU or policy. There are many folks in the PKIX WG who have argued (I think persuasively) that key usage is a type of policy. Having said that, there is no advantage of one over the other, so I think that we should leave whatever we do in EKU. >On the subject of "how many EKU's can you have", I don't think >we should prohibit others, however I vaguely recall this was some >sort of PKIX requirement. I myself have seen people wanting "swiss >army certificates" which enable SSL, SMIME, IPsec, right turn on >red without stopping, and all sorts of other features. I happen >to think that's unsafe, but it does seem to be a requirement. I >would like to allow multiple EKU's. I agree. --Paul Hoffman, Director --VPN Consortium From ???@??? Wed Oct 27 16:42:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17112 for ; Wed, 27 Oct 1999 16:19:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06316 Wed, 27 Oct 1999 18:07:45 -0400 (EDT) Message-Id: <4.2.1.19991027150812.01c23330@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 27 Oct 1999 15:10:44 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re:-ipsec-pki-req-03 - certificate validity In-Reply-To: <3.0.6.32.19991027122038.00acf7d0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 73a2f7c4c5e5212a5f53db21a44d9259 At 12:20 PM 10/27/99 +0200, Rodney Thayer wrote: >The original intent of this section was to require validity, >which we all agree we should worry about, as opposed to CRL's, >which many people don't use. When the document was converted >to PKIX compatibility (such as it is) this mutated into a CRL >requirement. This is an interesting place to diverge from PKIX if this group wants to. We can define validity to mean "a chain to a trusted root" *without* checking for revocation. It would simplify a great deal in implementations, but it would also expose IKE systems to attacks they aren't susceptible to if they check revocation often. Personally, I think we should leave these two linked. --Paul Hoffman, Director --VPN Consortium From ???@??? Wed Oct 27 20:35:37 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA24431 for ; Wed, 27 Oct 1999 20:18:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06898 Wed, 27 Oct 1999 21:41:07 -0400 (EDT) Date: Thu, 28 Oct 1999 09:43:13 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: Qiang Zhang cc: ipsec mailling list Subject: Re: Main mode using pre-shared keys In-Reply-To: <1.5.4.32.19991027192753.013805b0@hub.ecutel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: e8deacc8593055d637dc707efccaebf4 In fact, there is no identity protection in main mode with pre-shared key for authentication. The peer's IP address has to be used to select pre-shared key. One solution is to re-define SKEYID. We may not use pre-shared key for the generation of SKEYID. Instead, we can use the definition of SKEYID for digital signature, i.e. SKEYID = prf (Ni_b|Nr_b, g^xy) We only need to use pre-shared key for authentication of IKE exchanges. So we can replace HASH_I and HASH_R with AUTH_I and AUTH_R respectively in the protocol, where AUTH_I = prf (pre-shared-key, HASH_I) AUTH_R = prf (pre-shared-key, HASH_R) Jianying On Wed, 27 Oct 1999, Qiang Zhang wrote: > At 10:24 AM 10/27/99 -0700, CHINNA N.R. PELLACURU wrote: > >RFC 2409 > > > >5.4 Phase 1 Authenticated With a Pre-Shared Key > > > > Initiator Responder > > ---------- ----------- > > HDR, SA --> > > <-- HDR, SA > > HDR, KE, Ni --> > > <-- HDR, KE, Nr > > HDR*, IDii, HASH_I --> > > <-- HDR*, IDir, HASH_R > > > > When using pre-shared key authentication with Main Mode the key can > > only be identified by the IP address of the peers since HASH_I must > > be computed before the initiator has processed IDir. Aggressive Mode > > allows for a wider range of identifiers of the pre-shared secret to > > be used. In addition, Aggressive Mode allows two parties to maintain > > multiple, different pre-shared keys and identify the correct one for > > a particular exchange. > >" > > > > > >"identified by the IP address of the peers" > > > >Does this mean that the ID payload content must be an IP Address, and it > >should be the same as the source IP address on the IKE packet that the > >peers are using? > > > >If the source IP address on the packet is used to search the pre-shared > >key, then we authenticate the peer, by the fact that the peer knows the > >shared secret associated with the IP address he is using. Inspite of that, > >is the RFC also advicing that we enforce, the ID payload content is the > >source IP address that was used to search the shared secret? > > Chinna, notice that the HASHi computation HAS to use the peer-address to > search the preshared secret thus I think at least in this circumstance, the > ID payload won't work. Further one thing to worry about is that the > source address is not trustable due to all kinds of IP routing scheme. > > This is something I think the WG should give a solution. > > Qiang > > > > > >If so, the confidentiality part of the Identity protection is not there, > >when using pre-shared keys. > > > >What are the consequenses of not enforceing the above requirement? We are > >authenticating the peer using the IP source address he is using, because > >we search the pre-shared key based on it, but we accept his ID to be > >anything. > > > >TIA, chinna > > > >chinna narasimha reddy pellacuru > >s/w engineer > > > > > > > > From ???@??? Thu Oct 28 10:28:02 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28608 for ; Wed, 27 Oct 1999 22:12:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07277 Thu, 28 Oct 1999 00:01:57 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEEDC86@exchange> From: Andrew Krywaniuk To: "'=SMTP:jyzhou@krdl.org.sg'"@lists.tislabs.com, "'=SMTP:qzhang@ecutel.com'"@lists.tislabs.com Cc: ipsec mailling list Subject: RE: Main mode using pre-shared keys Date: Thu, 28 Oct 1999 00:07:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 6f678df2a6c681f55348683dd3c38c9e Exactly. I suggested this last week in my message "Shared Secret mismatch in AM3/MM5". The problem I was having with using the pre-shared key to generate SKEYID is that it makes a shared secret mismatch too difficult to diagnose, but the restriction on id types is also important. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Jianying Zhou [mailto:jyzhou@krdl.org.sg] > Sent: Wednesday, October 27, 1999 9:43 PM > To: Qiang Zhang > Cc: ipsec mailling list > Subject: Re: Main mode using pre-shared keys > > > In fact, there is no identity protection in main mode with pre-shared > key for authentication. The peer's IP address has to be used to select > pre-shared key. > > One solution is to re-define SKEYID. We may not use pre-shared key for > the generation of SKEYID. Instead, we can use the definition of SKEYID > for digital signature, i.e. > SKEYID = prf (Ni_b|Nr_b, g^xy) > > We only need to use pre-shared key for authentication of IKE > exchanges. > So we can replace HASH_I and HASH_R with AUTH_I and AUTH_R > respectively > in the protocol, where > AUTH_I = prf (pre-shared-key, HASH_I) > AUTH_R = prf (pre-shared-key, HASH_R) > > Jianying > > > On Wed, 27 Oct 1999, Qiang Zhang wrote: > > > At 10:24 AM 10/27/99 -0700, CHINNA N.R. PELLACURU wrote: > > >RFC 2409 > > > > > >5.4 Phase 1 Authenticated With a Pre-Shared Key > > > > > > Initiator Responder > > > ---------- ----------- > > > HDR, SA --> > > > <-- HDR, SA > > > HDR, KE, Ni --> > > > <-- HDR, KE, Nr > > > HDR*, IDii, HASH_I --> > > > <-- HDR*, IDir, HASH_R > > > > > > When using pre-shared key authentication with Main Mode > the key can > > > only be identified by the IP address of the peers since > HASH_I must > > > be computed before the initiator has processed IDir. > Aggressive Mode > > > allows for a wider range of identifiers of the > pre-shared secret to > > > be used. In addition, Aggressive Mode allows two > parties to maintain > > > multiple, different pre-shared keys and identify the > correct one for > > > a particular exchange. > > >" > > > > > > > > >"identified by the IP address of the peers" > > > > > >Does this mean that the ID payload content must be an IP > Address, and it > > >should be the same as the source IP address on the IKE > packet that the > > >peers are using? > > > > > >If the source IP address on the packet is used to search > the pre-shared > > >key, then we authenticate the peer, by the fact that the > peer knows the > > >shared secret associated with the IP address he is using. > Inspite of that, > > >is the RFC also advicing that we enforce, the ID payload > content is the > > >source IP address that was used to search the shared secret? > > > > Chinna, notice that the HASHi computation HAS to use the > peer-address to > > search the preshared secret thus I think at least in this > circumstance, the > > ID payload won't work. Further one thing to worry about is > that the > > source address is not trustable due to all kinds of IP > routing scheme. > > > > This is something I think the WG should give a solution. > > > > Qiang > > > > > > > > > >If so, the confidentiality part of the Identity protection > is not there, > > >when using pre-shared keys. > > > > > >What are the consequenses of not enforceing the above > requirement? We are > > >authenticating the peer using the IP source address he is > using, because > > >we search the pre-shared key based on it, but we accept > his ID to be > > >anything. > > > > > >TIA, chinna > > > > > >chinna narasimha reddy pellacuru > > >s/w engineer > > > > > > > > > > > > > > From ???@??? Thu Oct 28 10:28:02 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02869 for ; Thu, 28 Oct 1999 02:54:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08212 Thu, 28 Oct 1999 04:36:30 -0400 (EDT) Message-ID: <38180BF6.FA354BA0@checkpoint.com> Date: Thu, 28 Oct 1999 10:40:22 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec , ipsra Subject: Another DoS attack. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 480f384080410faa4cd0c3cfe95ff2a1 I'm posting this message to both mailing lists as this issue concerns them both. An attacker using either aggressive, main or base mode can send a certificate whose RSA public key consists of a long modulus (16384) and a non trivial exponent. The responder will be left to do the exponentiation till hell freezes unless of course his implementation limits the length of public key signatures it is willing to verify. A similar attack can be mounted using DSA. This attack can be extended to other online protocols that use certificates in which the responder is asked to verify a public key signature. From ???@??? Thu Oct 28 10:28:02 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07374 for ; Thu, 28 Oct 1999 05:34:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08796 Thu, 28 Oct 1999 06:59:39 -0400 (EDT) Message-Id: <199910281102.HAA13522@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-notifymsg-02.txt Date: Thu, 28 Oct 1999 07:02:15 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 50c94383444845a83fd9afcbd004a575 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Content Requirements for ISAKMP Notify Messages Author(s) : S. Kelly, T. Kivinen Filename : draft-ietf-ipsec-notifymsg-02.txt Pages : 26 Date : 27-Oct-99 The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In these cases, it is difficult to determine which SA corresponds to the received NOTIFY message. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no such requirements are currently specified for ISAKMP NOTIFY messages. This document provides content and format recommendations for those messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-notifymsg-02.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-ietf-ipsec-notifymsg-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-notifymsg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19991027135857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-notifymsg-02.txt From ???@??? Thu Oct 28 10:28:02 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10447 for ; Thu, 28 Oct 1999 08:47:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09324 Thu, 28 Oct 1999 09:59:57 -0400 (EDT) Message-ID: <38185095.5C853876@nt.com> Date: Thu, 28 Oct 1999 09:33:09 -0400 From: "Marcus Leech" X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: Tamir Zegman , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Another DoS attack. References: <38180BF6.FA354BA0@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 0ee13bb7761e0ee8146cd37a9014a60a Tamir Zegman wrote: > > I'm posting this message to both mailing lists as this issue concerns > them both. > > An attacker using either aggressive, main or base mode can send a > certificate whose RSA public key consists of a long modulus (16384) and > a non trivial exponent. > The responder will be left to do the exponentiation till hell freezes > unless of course his implementation limits the length of public key > signatures it is willing to verify. > A similar attack can be mounted using DSA. > This attack can be extended to other online protocols that use > certificates in which the responder is asked to verify a public key > signature. I have to assume that any CA that would issue a certificate for such a key would be broken. Having said that, though, adding in a level of DoS paranoia here wouldn't hurt. I would tend to want to verify the certificate BEFORE I did any computations based on the public key contained therein. I haven't checked in detail, but does PKIX have anything to say about such pathological keys? -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From ???@??? Thu Oct 28 10:28:02 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10390 for ; Thu, 28 Oct 1999 08:44:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09236 Thu, 28 Oct 1999 09:42:29 -0400 (EDT) Message-ID: <38185342.38262CBD@checkpoint.com> Date: Thu, 28 Oct 1999 15:44:34 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Marcus Leech CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Another DoS attack. References: <38180BF6.FA354BA0@checkpoint.com> <38185095.5C853876@nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: fe7b8504f22dff9b0557ffc9a191fbec Marcus Leech wrote: > Tamir Zegman wrote: > > > > I'm posting this message to both mailing lists as this issue concerns > > them both. > > > > An attacker using either aggressive, main or base mode can send a > > certificate whose RSA public key consists of a long modulus (16384) and > > a non trivial exponent. > > The responder will be left to do the exponentiation till hell freezes > > unless of course his implementation limits the length of public key > > signatures it is willing to verify. > > A similar attack can be mounted using DSA. > > This attack can be extended to other online protocols that use > > certificates in which the responder is asked to verify a public key > > signature. > I have to assume that any CA that would issue a certificate for such a key > would be broken. Having said that, though, adding in a level of DoS > paranoia here wouldn't hurt. > > I would tend to want to verify the certificate BEFORE I did any computations > based on the public key contained therein. I haven't checked in detail, > but does PKIX have anything to say about such pathological keys? > Yes, of course, The best way around the problem is to validate the certificate before checking the signature, assuming of course that CAs don't issue these kind of certs. > > -- > ---------------------------------------------------------------------- > Marcus Leech Mail: Dept 8M70, MS 012, FITZ > Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 > Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 > Nortel Networks mleech@nortelnetworks.com > -----------------Expressed opinions are my own, not my employer's------ From ???@??? Thu Oct 28 10:28:02 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11023 for ; Thu, 28 Oct 1999 09:24:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09582 Thu, 28 Oct 1999 10:47:15 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <4.2.1.19991027150812.01c23330@mail.vpnc.org> References: <3.0.6.32.19991027122038.00acf7d0@127.0.0.1> Date: Thu, 28 Oct 1999 10:26:18 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re:-ipsec-pki-req-03 - certificate validity Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 29038ed74b72bd765bcf370b35e4fe77 At 3:10 PM -0700 10/27/99, Paul Hoffman wrote: >At 12:20 PM 10/27/99 +0200, Rodney Thayer wrote: >>The original intent of this section was to require validity, >>which we all agree we should worry about, as opposed to CRL's, >>which many people don't use. When the document was converted >>to PKIX compatibility (such as it is) this mutated into a CRL >>requirement. > >This is an interesting place to diverge from PKIX if this group wants to. >We can define validity to mean "a chain to a trusted root" *without* >checking for revocation. It would simplify a great deal in implementations, >but it would also expose IKE systems to attacks they aren't susceptible to >if they check revocation often. > >Personally, I think we should leave these two linked. Not only would this diverge from PKIX, but also from X.509, the NIST work for US Government profiles, and essentially all other standards that discuss what it means to validate a cert chain. I strongly suggest that we NOT try to redefine what it means to validate a cert chain path in the IPsec context! If one wants to provide an out so that an IPsec peer may choose to operate with a cert chain that has not been checked wrt revocation, I suggest that we provide some local, configurable means of doing so, but don't fiddle with the fundamental defintions. Steve From ???@??? Thu Oct 28 13:54:04 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15424 for ; Thu, 28 Oct 1999 13:30:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10311 Thu, 28 Oct 1999 13:48:57 -0400 (EDT) Message-ID: <38188EC5.D30BBAC0@redcreek.com> Date: Thu, 28 Oct 1999 17:58:29 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: Andrew Krywaniuk Subject: Re: Shared Secret mismatch in AM3/MM5 References: <319A1C5F94C8D11192DE00805FBBADDFEC8E1B@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 6dbb6e5e2f68de833650c603c3d5bb2d Andrew Krywaniuk wrote: > > I have a question for anyone on the list who may know/care: I care but don't know :-( All I'm doing in this post is basically re-itterating one of Andrews questions which is currently on my 'must research' list: Why is SKEYID defined that way? What were the modivators? And specifically why is SKEYID not some direct derivation of g^xy in all cases? Are there pointers to reference material? Thanks in advance... Ricky Charlet rcharlet@redcreek.com (for my sig line quotable quote, please see Andrew's sig line since I like it very much.) > > When two peers are negotiationg a phase 1 SA in shared secret mode, a > disagreement in the shared secret will result in a decryption failure in the > first encrypted message -- MM5 or AM3 (which we choose to encrypt). > > The decryption failure usually results in one of the following errors: > Invalid Payload Type, Invalid Id Info, or Payload Malformed. Of course, a > sophisticated implementation can infer that the decryption failure was the > result of a shared secret mismatch and report this to the user... > > But it makes troubleshooting difficult. It is hard to distinguish between a > deliberate attack, a user mistyping his password, and a misbehaving > implementation. > > So I was wondering about the underlying reasons why we get this error. There > seems to be two causes: > > 1) SKEYID_e is derived from the shared secret. > 2) The HASH_I payload comes at the end of the message (after the Id). > > So what is the importance of these two design constraints? Why do we base > the encryption key on secret data (other than g^xy) in shared mode, but not > in cert mode; and why do we put the hash at the end of the message in phase > 1 but not in phase 2? > > My guess is that SKEYID_e is derived from the shared secret because: > > a) it increases the entropy of SKEYID and, in particular, the amount of > entropy which could not be guessed by an attacker. > > b) it protects against a MitM attack. > > However: > > a) the cert mode SKEYID doesn't have any unguessable entropy except g^xy (so > presumably this would be sufficient for shared mode as well). > > b) HASH_I provides adequate protection against a MitM attack (or else the > encryption of AM3 would not be optional). > > My guess is that the HASH_I payload comes at the end of the message because: > > a) when not encrypting AM3, the shared key could depend on the id (so id > then hash represents the logical order of processing). > > b) the hash contains the id, so to verify the hash you need to have already > parsed the id (so id then hash represents the logical order of processing). > > However: > > a) there is no absolute requirement that the order of payloads in the > message be the same as the order in which they are processed. > > b) if the hash came at the beginning of the message, an implementation could > always return the same error if decryption failed (choosing either Invalid > Hash Info or Authentication Failed). In fact, [IKE] states that in quick > mode, the hash MUST immediately follow the header, presumably for exactly > this reason. > > If anyone can find fault with my arguments, or if they know of other reasons > why these constraints have to exist, I would like to hear about it. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. From ???@??? Thu Oct 28 14:50:55 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16870 for ; Thu, 28 Oct 1999 14:41:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10710 Thu, 28 Oct 1999 16:00:38 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242CCD@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Ricky Charlet'" , ipsec@lists.tislabs.com Cc: Andrew Krywaniuk Subject: RE: Shared Secret mismatch in AM3/MM5 Date: Thu, 28 Oct 1999 13:03:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 78b8f0375c5b5b30aeef12c28da6d1ff Rick, I don't know what the designers were thinking, but consider man-in-the-middle for a minute. In order to defeat it, the IKE authentication proof has to demonstrate the peer's knowledge of both the shared secret and the negotiated Diffie-Hellman keying material. The design of IKE does this quite effectively by binding the two together in a single hash. If you remove the binding, then you reenable man-in-the-middle if you don't introduce some other means to tie them together. -- Jesse -----Original Message----- From: Ricky Charlet [mailto:rcharlet@redcreek.com] Sent: Thursday, October 28, 1999 10:58 AM To: ipsec@lists.tislabs.com Cc: Andrew Krywaniuk Subject: Re: Shared Secret mismatch in AM3/MM5 Andrew Krywaniuk wrote: > > I have a question for anyone on the list who may know/care: I care but don't know :-( All I'm doing in this post is basically re-itterating one of Andrews questions which is currently on my 'must research' list: Why is SKEYID defined that way? What were the modivators? And specifically why is SKEYID not some direct derivation of g^xy in all cases? Are there pointers to reference material? Thanks in advance... Ricky Charlet rcharlet@redcreek.com (for my sig line quotable quote, please see Andrew's sig line since I like it very much.) > > When two peers are negotiationg a phase 1 SA in shared secret mode, a > disagreement in the shared secret will result in a decryption failure in the > first encrypted message -- MM5 or AM3 (which we choose to encrypt). > > The decryption failure usually results in one of the following errors: > Invalid Payload Type, Invalid Id Info, or Payload Malformed. Of course, a > sophisticated implementation can infer that the decryption failure was the > result of a shared secret mismatch and report this to the user... > > But it makes troubleshooting difficult. It is hard to distinguish between a > deliberate attack, a user mistyping his password, and a misbehaving > implementation. > > So I was wondering about the underlying reasons why we get this error. There > seems to be two causes: > > 1) SKEYID_e is derived from the shared secret. > 2) The HASH_I payload comes at the end of the message (after the Id). > > So what is the importance of these two design constraints? Why do we base > the encryption key on secret data (other than g^xy) in shared mode, but not > in cert mode; and why do we put the hash at the end of the message in phase > 1 but not in phase 2? > > My guess is that SKEYID_e is derived from the shared secret because: > > a) it increases the entropy of SKEYID and, in particular, the amount of > entropy which could not be guessed by an attacker. > > b) it protects against a MitM attack. > > However: > > a) the cert mode SKEYID doesn't have any unguessable entropy except g^xy (so > presumably this would be sufficient for shared mode as well). > > b) HASH_I provides adequate protection against a MitM attack (or else the > encryption of AM3 would not be optional). > > My guess is that the HASH_I payload comes at the end of the message because: > > a) when not encrypting AM3, the shared key could depend on the id (so id > then hash represents the logical order of processing). > > b) the hash contains the id, so to verify the hash you need to have already > parsed the id (so id then hash represents the logical order of processing). > > However: > > a) there is no absolute requirement that the order of payloads in the > message be the same as the order in which they are processed. > > b) if the hash came at the beginning of the message, an implementation could > always return the same error if decryption failed (choosing either Invalid > Hash Info or Authentication Failed). In fact, [IKE] states that in quick > mode, the hash MUST immediately follow the header, presumably for exactly > this reason. > > If anyone can find fault with my arguments, or if they know of other reasons > why these constraints have to exist, I would like to hear about it. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. From ???@??? Thu Oct 28 20:01:08 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA01162 for ; Thu, 28 Oct 1999 19:51:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11579 Thu, 28 Oct 1999 21:20:29 -0400 (EDT) Date: Fri, 29 Oct 1999 09:22:37 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: "Walker, Jesse" cc: "'Ricky Charlet'" , ipsec@lists.tislabs.com, Andrew Krywaniuk Subject: RE: Shared Secret mismatch in AM3/MM5 In-Reply-To: <392A357CE6FFD111AC3E00A0C99848B002242CCD@hdsmsx31.hd.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 221d1796e293e43ef29df2f2b0639fb5 On Thu, 28 Oct 1999, Walker, Jesse wrote: > Rick, > > I don't know what the designers were thinking, but consider > man-in-the-middle for a minute. In order to defeat it, the IKE > authentication proof has to demonstrate the peer's knowledge of both the > shared secret and the negotiated Diffie-Hellman keying material. The design > of IKE does this quite effectively by binding the two together in a single > hash. If you remove the binding, then you reenable man-in-the-middle if you > don't introduce some other means to tie them together. > > -- Jesse > But that kind of definition of SKEYID excludes nodadic users in the main mode with pre-shared key for authentication. Jianying From ???@??? Fri Oct 29 09:43:00 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13631 for ; Fri, 29 Oct 1999 04:08:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12898 Fri, 29 Oct 1999 05:29:51 -0400 (EDT) Message-Id: <9910290943.AA02568@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Fri, 29 Oct 1999 18:43:29 +0900 To: Tamir Zegman Cc: ipsec , ipsra Subject: Re: Another DoS attack. In-Reply-To: <38180BF6.FA354BA0@checkpoint.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 380f9e15b0cace21e6f337fddea15d07 Hi, I think DoS-resistant protocols should work in the following order: (1) The responder carries out expensive (but initiator-independent) computation. (2) The initiator carries out expensive (and responder-dependent) computation. This computation must also be session-dependent. (3) With light computation, the responder checks whether the responder has really completed (2). (4) The responder carries out expensive (and initiator-dependent) computation. How about verifying the certificate in the step (4)? (1) can be pre-computed. If the resultant state is too large, we can be helped by "stateless connection" (state materials are encrypted by local secret key and sent back and forth between the responder and the initiator. This encryption can be a fast symmetric-key encryption and the key can be used many times.). Please consult about details with http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt. Finally, I'd like to point out that Base Mode (draft-ietf-ipsec-ike-base-mode-01.txt) is aimed at DoS resistance but it does not follow the protocol design direction listed above as (1)-(4). Signature-verification cost might probably exhaust the responder's resource, for example. Tamir Zegman wrote: >>I'm posting this message to both mailing lists as this issue concerns >>them both. >> >>An attacker using either aggressive, main or base mode can send a >>certificate whose RSA public key consists of a long modulus (16384) and >>a non trivial exponent. >>The responder will be left to do the exponentiation till hell freezes >>unless of course his implementation limits the length of public key >>signatures it is willing to verify. >>A similar attack can be mounted using DSA. >>This attack can be extended to other online protocols that use >>certificates in which the responder is asked to verify a public key >>signature. --^^-- Kanta From ???@??? Fri Oct 29 09:43:00 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18093 for ; Fri, 29 Oct 1999 09:12:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13427 Fri, 29 Oct 1999 09:21:08 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242CD3@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Jianying Zhou'" Cc: ipsec@lists.tislabs.com Subject: RE: Shared Secret mismatch in AM3/MM5 Date: Fri, 29 Oct 1999 06:23:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 0b3a7071bcd6394427a9d460588c3d6f Right. That's why so many implementations rely on aggresive mode for remote access IPSec hosts. Maybe in the future they will use base mode instead, as it affords somewhat more flexibility for the remote access case. -----Original Message----- From: Jianying Zhou [mailto:jyzhou@krdl.org.sg] Sent: Thursday, October 28, 1999 6:23 PM To: Walker, Jesse Cc: 'Ricky Charlet'; ipsec@lists.tislabs.com; Andrew Krywaniuk Subject: RE: Shared Secret mismatch in AM3/MM5 On Thu, 28 Oct 1999, Walker, Jesse wrote: > Rick, > > I don't know what the designers were thinking, but consider > man-in-the-middle for a minute. In order to defeat it, the IKE > authentication proof has to demonstrate the peer's knowledge of both the > shared secret and the negotiated Diffie-Hellman keying material. The design > of IKE does this quite effectively by binding the two together in a single > hash. If you remove the binding, then you reenable man-in-the-middle if you > don't introduce some other means to tie them together. > > -- Jesse > But that kind of definition of SKEYID excludes nodadic users in the main mode with pre-shared key for authentication. Jianying From ???@??? Fri Oct 29 18:15:40 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA24957 for ; Fri, 29 Oct 1999 17:57:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15186 Fri, 29 Oct 1999 19:47:12 -0400 (EDT) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com Message-ID: <85256819.0054EA87.00@d54mta05.raleigh.ibm.com> Date: Fri, 29 Oct 1999 11:29:00 -0400 Subject: RE: "PKIX Profile for IKE"--Is it really a profile? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 4d8bdde38c95c308f504a90831032ca9 In Greg Carter's posting of 10/26/99, the following exchange took place: > what are the normative rules for matching a >certificate?s subject to IKE?s ID Payload fields, >>That's a good question. Many companies have told me that they never >>intend to match the subject to the IKE initiator. I find that scary, >>but it's what many people want. I would prefer statements in this >>profile that say you SHOULD (maybe MUST) match the subject, but >>that's open for debate. >>>Then they don't understand the security implications >>>and this is something that should be explained in the doc. The >>>DOI mentions that if the ID payload is used for policy decisions >>>then the ID SHOULD be contained in the certificate. If they use >>>the ID in the ID payload for policy lookups but don't verify that >>>ID than they have serious security problems. Perhaps one of the >>>reasons this isn't pointed out is it was thought to be obvious. >>>I can substitute any ID I want, my signature will still verify >>>because I have sent you my cert. If they do not use the ID in >>>the ID payload to look up policy and instead use the ID contained >>>in the certificate then there is not a problem. I asked the first question (>), Paul Hoffman responded (>>), and Greg Carter (>>>) replied to Paul. I think we definitely need explicit matching rules. But I disagree with Greg about its being OK to make policy lookups that are not based on the contents of ID Payload. And I'd like to see a "mismatch" rule, rather than a "match" rule as Paul had suggested. I believe that the ID Payload MUST be used. Here's my rationale: 1) In IKE exchanges, ID Payloads must be present, but certificate payloads are only optionally present. 2) The IKE authentication process uses contents of the ID Payloads as inputs to the hash that is used to authenticate the negotiating parties. 3) Certificate subject fields play no role in authenticating the negotiating parties. 4) Why would one authenticate two parties, and then use unauthnticated information to look up policy? This seems to me to be a very big security hole, which we should strongly disallow. Also, consider a situation where the optional CERT and CERT REQ payloads are not used. Party #1 sends Party #2 an ID payload identifying itself as (say ) "JOE". The party #2 has to find a certificate to learn the appropriate public key for party #1. Would Party #2 make (for example) an LDAP query asking for "HARRY"s certificate? Of course not, since Party #1 has just said that he is "JOE". So, if a CERT Payload naming HARRY is present in an exchange where the ID field names the negotiator as "JOE", why would an implementation want to use the public key in HARRY's certificate? My recommendation for the "PKIX Profile for IKE" is to add text that imposes the following "mismatch" requirement: "If identity offered by an IKE peer in its ID Payload field does not match in both identity type (e.g., ip address, FQDN, etc.) and value with at least one of the identities included in the certificate's subject field or subjAltName extension fields, then that certificate MUST NOT be used by IKE for the purpose of authenticating the IKE peer." I'd also add another statement for information purposes, to make it clear that local security polciy can include other requirements beyond a match between certificate subjects and I D payload contents. Perhaps something like: "A match between ID payload contents and at least one of the subject(s) named in a certificate is necessary if that certificate is to be used in the IKE authentication processes. In addition , as a matter of local security policy, an IKE implementation MAY impose further requirements. For example, local policy might restrict the identity formats to only IPv4 addresses, or it might require there be a match between a domain name and the associated DNS A record, etc. The presence or absence of any such additional checks are otuside the scope of this profile." "Note that this profile prohibits the use of "mismatched" certificates as part of the IKE authentication process. It does not constrain in any way the use of "mismatched" certificates for other purposes." ...Charlie Kunzinger ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development (JEUA/502), RTP Phone: Tie 8-444-4142 , External 919-254-4142 Fax: Tie 8-441-7288, External 919-543-7288 From ???@??? Fri Oct 29 15:01:02 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22400 for ; Fri, 29 Oct 1999 14:55:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14584 Fri, 29 Oct 1999 15:04:42 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFEEE28C@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Shared Secret mismatch in AM3/MM5 Date: Fri, 29 Oct 1999 15:07:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 58d5169da18ea8e201d766c6d637e3ee Choosing between identity protection and DoS resistance is probably a necessary constraint of IKE (I can think of solutions but they ain't pretty). But I think the point here is that currently implementations are forced to choose between identity protection and shared secrets. This is not a necessary constraint. Implementations wanting DoS resistance should migrate to base mode. Implementations wanting identity protection really have no option, currently. MM w/ shared secrets doesn't really have identity protection. Sure, the id payload is encrypted, but the shared secret has to be tied to the ip. If the encrypted identity is something other than the ip, it can't be trusted because only the ip was authenticated. The solution, as was already pointed out on this list is to redefine SKEYID and the signature payloads for shared secrets. I believe Jianying already suggested: SKEYID = prf (Ni_b|Nr_b, g^xy) [the same as for signatures] AUTH_I = prf (pre-shared-key, HASH_I) AUTH_R = prf (pre-shared-key, HASH_R) That looks secure to me. Perhaps it could be tweaked a bit for performance. For example, instead of calling prf twice, we could just use: HASH_I = prf(SKEYID | pre-shared-key, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) Anyone else have any suggestions? Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Friday, October 29, 1999 9:24 AM > To: 'Jianying Zhou' > Cc: ipsec@lists.tislabs.com > Subject: RE: Shared Secret mismatch in AM3/MM5 > > > Right. That's why so many implementations rely on aggresive > mode for remote > access IPSec hosts. Maybe in the future they will use base > mode instead, as > it affords somewhat more flexibility for the remote access case. > > -----Original Message----- > From: Jianying Zhou [mailto:jyzhou@krdl.org.sg] > Sent: Thursday, October 28, 1999 6:23 PM > To: Walker, Jesse > Cc: 'Ricky Charlet'; ipsec@lists.tislabs.com; Andrew Krywaniuk > Subject: RE: Shared Secret mismatch in AM3/MM5 > > > On Thu, 28 Oct 1999, Walker, Jesse wrote: > > > Rick, > > > > I don't know what the designers were thinking, but consider > > man-in-the-middle for a minute. In order to defeat it, the IKE > > authentication proof has to demonstrate the peer's > knowledge of both the > > shared secret and the negotiated Diffie-Hellman keying material. The > design > > of IKE does this quite effectively by binding the two > together in a single > > hash. If you remove the binding, then you reenable > man-in-the-middle if > you > > don't introduce some other means to tie them together. > > > > -- Jesse > > > > But that kind of definition of SKEYID excludes nodadic users > in the main > mode with pre-shared key for authentication. > > Jianying > From ???@??? Fri Oct 29 16:38:03 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23730 for ; Fri, 29 Oct 1999 16:28:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14966 Fri, 29 Oct 1999 17:57:40 -0400 (EDT) Message-Id: <199910292158.OAA14039@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: Shared Secret mismatch in AM3/MM5 In-reply-to: Your message of "Fri, 29 Oct 1999 15:07:01 EDT." <319A1C5F94C8D11192DE00805FBBADDFEEE28C@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14036.941234320.1@network-alchemy.com> Date: Fri, 29 Oct 1999 14:58:40 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 079dfe9c6fddaa40dde49240a1a537c5 This has come up on the list before and been rejected before. It is a fundamental change to a protocol that is just now getting some serious analysis. The only justification seems to be the desire to use pre-shared key authentication with a dynamicly-assigned IP address. This was not justification enought to change things before and nothing has changed. Dan. On Fri, 29 Oct 1999 15:07:01 EDT you wrote > > The solution, as was already pointed out on this list is to redefine SKEYID > and the signature payloads for shared secrets. > > I believe Jianying already suggested: > > SKEYID = prf (Ni_b|Nr_b, g^xy) [the same as for signatures] > AUTH_I = prf (pre-shared-key, HASH_I) > AUTH_R = prf (pre-shared-key, HASH_R) > From ???@??? Sat Oct 30 20:35:44 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA09714 for ; Sat, 30 Oct 1999 19:54:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17288 Sat, 30 Oct 1999 21:21:16 -0400 (EDT) Message-ID: <381B994A.231FB9E4@ire-ma.com> Date: Sat, 30 Oct 1999 21:20:11 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec , ipsra Subject: Encrypting Notify Messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 10b9c39c195f76c2f6222a31be71dfb4 RFC 2407 in section 4.6.3 dicusses and recommends (or requires? it is not clear...) protection of notify messages But some notify messages enumerated in RFC 2408 cannot be protected while the middle of negotiating Main Mode. (Aggressive Mode is even bigger issue). I couldn't find any statements allowing some notify messages to be unprotected. For example: INVALID-COOKIE NO-PROPOSAL-CHOSEN INVALID-CERT-ENCODING INVALID-CERTIFICATE CERT-TYPE-UNSUPPORTED and many others.... Could someone clarify this? From ???@??? Sun Oct 31 10:30:19 1999 X-Persona: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23189 for ; Sun, 31 Oct 1999 08:06:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18334 Sun, 31 Oct 1999 09:22:25 -0500 (EST) Date: Sun, 31 Oct 1999 16:24:52 +0200 (EET) Message-Id: <199910311424.QAA18881@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Dan Harkins Cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Shared Secret mismatch in AM3/MM5 In-Reply-To: <199910292158.OAA14039@potassium.network-alchemy.com> References: <319A1C5F94C8D11192DE00805FBBADDFEEE28C@exchange> <199910292158.OAA14039@potassium.network-alchemy.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-UIDL: 7ddb876835d9df222cb59cba411f3848 Dan Harkins writes: > This has come up on the list before and been rejected before. It is > a fundamental change to a protocol that is just now getting some serious > analysis. The only justification seems to be the desire to use > pre-shared key authentication with a dynamicly-assigned IP address. > This was not justification enought to change things before and nothing > has changed. Also doing this change also allows man in the middle always get the initiator identity before the responder drops the negotiation (or times out if the man in the middle just stops forwarding the packets after that). If the encryption key is only calculated from the Diffie-Hellman output then the man in the middle can also calculate that and decrypt the packet containing the identity payload. If the encryption key also contains the pre-shared-key the man in the middle is not able decrypt that payload. For other authentication modes, the public key encryption mode is also protected by this kind of man in the middle attack, but the public key signature mode is vulnerable for this attack. This is really a choice we have to make, do we want pre-shared-key to be vulnerable for this attack or not? > On Fri, 29 Oct 1999 15:07:01 EDT you wrote > > > > The solution, as was already pointed out on this list is to redefine SKEYID > > and the signature payloads for shared secrets. > > > > I believe Jianying already suggested: > > > > SKEYID = prf (Ni_b|Nr_b, g^xy) [the same as for signatures] > > AUTH_I = prf (pre-shared-key, HASH_I) > > AUTH_R = prf (pre-shared-key, HASH_R) > > -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/