From owner-ipsec@lists.tislabs.com Mon Dec 1 12:08:02 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1K82ib005123; Mon, 1 Dec 2003 12:08:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13247 Mon, 1 Dec 2003 14:01:19 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Issue #68: VPNs with overlapping IP address ranges (was Re: 2401bis issues (possible) resolution) In-reply-to: Your message of "Wed, 08 Oct 2003 17:27:40 +0300." <16260.7900.891287.446736@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 01 Dec 2003 14:03:54 -0500 Message-ID: <14839.1070305434@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: >> When a security Gateway is operating on behalf of multiple contexts >> (e.g. multiple subscribers, or multiple ppvpn-style overlay addressing >> contexts), it is essential that the initiator be able to convey to the >> responder which context is being addressed. Tero> Do not use IP addresses as a IKE SA identities then. Use the dns Tero> names or email addresses or something else. There is no need to use Tero> ip addresses in those cases (or actually using ip addresses would Tero> be quite bad, as it is not unique...). I concur. Particularly for IKEv2, the #1 reason to use IP addresses as IDs in IKEv1 was because of limitations of PSK. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8uQmIqHRg3pndX9AQHAvgP+MQTjmsd6eV5y5x24EWJsf318xOW1o59v AH/IC1/XjLMaottIAoEiIqxuZfvZJwCmZrwselIcHMhMy78XGclHHHWhX86mTFmQ 7miPmPe30NCKsWzNGd24qkBZYY02hVXrgr06tpVz+xejFG5ytogjU38iOaQhr2UZ OicNqlCFEXg= =XOxB -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 2 05:45:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Dj2ib019126; Tue, 2 Dec 2003 05:45:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26030 Tue, 2 Dec 2003 07:53:14 -0500 (EST) Date: Tue, 2 Dec 2003 07:53:14 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200312021253.HAA26030@lists.tislabs.com> SMTPSVC(6.0.3790.1039); Mon, 1 Dec 2003 12:57:34 -0800 12:57:42 -0800 Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 12:57:41 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Possible problem in IKEv2? Date: Mon, 1 Dec 2003 12:57:44 -0800 Message-ID: Thread-Topic: Possible problem in IKEv2? thread-index: AcOflFhkn62JH09oTWaVIAAE8m9cMAYtXn6w From: "Charlie Kaufman" To: , X-OriginalArrivalTime: 01 Dec 2003 20:57:41.0761 (UTC) FILETIME=[C2DAAF10:01C3B84D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA24802 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You're right! While non-key-generating EAP methods are explicitly discouraged, it is likely people will use them and we should make the protection as good as we can. The AUTH payloads have two purposes in the cryptographic exchange: to authenticate the parties and to protect the first two messages from modification. These functions could have been provided independently, but they weren't. The threat here is that a man-in-the-middle could trick IKE peers using a non-key-generating EAP method to use weaker cryptographic algorithms than the strongest that they both support. They would both have to be willing to use the weaker cryptographic algorithms, and if the attacker can break the weaker algorithms in real time (during the exchange) then there is no way we can defend against it. So this is clearly a fringe case. But we've engineered for much more fringe cases than this in the past. I can think of a number of ways of fixing this, but yours has the virtue of minimizing word changes to the spec and lines of code to an implementation. This is very late in the process to be making cryptographic changes, but I feel like this one is worth doing. **Can I get a ruling from our chairs?** --Charlie -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Pasi.Eronen@nokia.com Sent: Friday, October 31, 2003 1:50 AM To: ipsec@lists.tislabs.com Subject: Possible problem in IKEv2? Hi, When using a non-key-generating EAP method, the initiator never generates any AUTH payloads. In this case, KEi/Ni are authenticated implicitly (by the ability to provide correct EAP Responses that are protected with SK_ai). However, it seems the client's AUTH payload has a second purpose as well: to provide integrity protection for the first message. If the initiator never generates an AUTH payload, is there anything that prevents an attacker from, e.g., removing some proposals from SAi1? (Or modifying some other payloads than KEi/Ni in the first message?) (Or have I missed some detail of this?) If this is indeed the case, I think the easiest solution would be to always include the AUTH payloads; if the EAP method does not generate keys, use some known fixed string (such as a single zero octet) as the key. Since the AUTH payload is protected by SK_ai, this should ensure that the first message was not modified (by someone who doesn't know the initiator's private DH value). Best regards, Pasi From owner-ipsec@lists.tislabs.com Tue Dec 2 07:16:03 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2FG2ib022898; Tue, 2 Dec 2003 07:16:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12010 Tue, 2 Dec 2003 09:32:36 -0500 (EST) Message-ID: <3FCCA3D6.4080703@kolumbus.fi> Date: Tue, 02 Dec 2003 16:38:14 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Kaufman Cc: IPsec WG Subject: Re: References: <200312021253.HAA26030@lists.tislabs.com> In-Reply-To: <200312021253.HAA26030@lists.tislabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > While non-key-generating EAP methods are explicitly discouraged, it is > likely people will use them and we should make the protection as good as > we can. The AUTH payloads have two purposes in the cryptographic Right. > exchange: to authenticate the parties and to protect the first two > messages from modification. These functions could have been provided > independently, but they weren't. > > The threat here is that a man-in-the-middle could trick IKE peers using > a non-key-generating EAP method to use weaker cryptographic algorithms > than the strongest that they both support. They would both have to be > willing to use the weaker cryptographic algorithms, and if the attacker > can break the weaker algorithms in real time (during the exchange) then > there is no way we can defend against it. So this is clearly a fringe > case. But we've engineered for much more fringe cases than this in the > past. Indeed. > I can think of a number of ways of fixing this, but yours has the virtue > of minimizing word changes to the spec and lines of code to an > implementation. This is very late in the process to be making > cryptographic changes, but I feel like this one is worth doing. I agree. --Jari From owner-ipsec@lists.tislabs.com Tue Dec 2 11:57:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2Jvsib037640; Tue, 2 Dec 2003 11:57:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12455 Tue, 2 Dec 2003 13:51:23 -0500 (EST) Message-Id: <5.2.0.9.2.20031202135832.043cc4e8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 02 Dec 2003 13:59:06 -0500 To: Charlie Kaufman From: Russ Housley Subject: Re: Cc: IPsec WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I can think of a number of ways of fixing this, but yours has the virtue >of minimizing word changes to the spec and lines of code to an >implementation. This is very late in the process to be making >cryptographic changes, but I feel like this one is worth doing. I agree. Please fix it, and quickly. Russ From owner-ipsec@lists.tislabs.com Tue Dec 2 13:50:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB2LoLib054365; Tue, 2 Dec 2003 13:50:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23960 Tue, 2 Dec 2003 14:36:18 -0500 (EST) Date: Tue, 2 Dec 2003 21:47:20 +0200 (IST) From: Hugo Krawczyk To: IPsec WG cc: charliek@microsoft.com, Subject: Re: Possible problem in IKEv2? In-Reply-To: <200312021253.HAA26030@lists.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The solution proposed by Pasi seems fine except that instead of using a dummy key to compute the AUTH value by the initiator why not specify (in sec 2.16): "For EAP methods that do not establish a shared key, the AUTH value will be computed using the negotiated integrity algorithm keyed with the key SK_ai." Cryptographically speaking a MAC or PRF keyed with a fixed dummy string (say all 0's) may be, in principle, very weak and easily forgeable. SO why not use the available key SK_ai for integrity protecting the first msg via the AUTH value? It is important, however, that the same integrity algorithm used under the SK{} construct (which already uses SK_ai) be used for computing the above AUTH value. Do you see any problem with this solution? BTW, in passing I noted the following sentence in sec 1.2: The Initiator [...] integrity protects the contents of the first two messages using the AUTH payload (see section 2.15). In the current specification of ikev2 AUTH as computed by the intiator only protects the first msg (while the responder's AUTH protects the second msg). I suggest to rephrase accordingly. Hugo > You're right! > > While non-key-generating EAP methods are explicitly discouraged, it is > likely people will use them and we should make the protection as good as > we can. The AUTH payloads have two purposes in the cryptographic > exchange: to authenticate the parties and to protect the first two > messages from modification. These functions could have been provided > independently, but they weren't. > > The threat here is that a man-in-the-middle could trick IKE peers using > a non-key-generating EAP method to use weaker cryptographic algorithms > than the strongest that they both support. They would both have to be > willing to use the weaker cryptographic algorithms, and if the attacker > can break the weaker algorithms in real time (during the exchange) then > there is no way we can defend against it. So this is clearly a fringe > case.But we've engineered for much more fringe cases than this in the > past. > > I can think of a number of ways of fixing this, but yours has the virtue > of minimizing word changes to the spec and lines of code to an > implementation. This is very late in the process to be making > cryptographic changes, but I feel like this one is worth doing. > > **Can I get a ruling from our chairs?** > > --Charlie > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Friday, October 31, 2003 1:50 AM > To: ipsec@lists.tislabs.com > Subject: Possible problem in IKEv2? > > Hi, > > When using a non-key-generating EAP method, the initiator never > generates any AUTH payloads. In this case, KEi/Ni are authenticated > implicitly (by the ability to provide correct EAP Responses > that are protected with SK_ai). However, it seems the client's > AUTH payload has a second purpose as well: to provide integrity > protection for the first message. > > Ifthe initiator never generates an AUTH payload, is there anything > that prevents an attacker from, e.g., removing some proposals > from SAi1? (Or modifying some other payloads than KEi/Ni in the > first message?) > > (Or have I missed some detail of this?) > > If this is indeed the case, I think the easiest solution would be > to always include the AUTH payloads; if the EAP method does not > generate keys, use some known fixed string (such as a single zero > octet) as the key. Since the AUTH payload is protectedby SK_ai, > this should ensure that the first message was not modified (by > someone who doesn't know the initiator's private DH value). > > Best regards, > Pasi > > From bsdryh23tl@yahoo.ca Tue Dec 2 20:49:31 2003 Received: from 200-70-177-30.mrse.com.ar (200-70-177-30.mrse.com.ar [200.70.177.30]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB34m7ib069530; Tue, 2 Dec 2003 20:48:29 -0800 (PST) (envelope-from bsdryh23tl@yahoo.ca) Received: from [201.135.117.189] by 200-70-177-30.mrse.com.ar; Wed, 03 Dec 2003 09:46:06 +0400 Message-ID: <4zug8d-grzt$n4lu-qigi8@7jh6.8w7c.pu> From: "Candy Irwin" Reply-To: "Candy Irwin" To: ietf-conneg@imc.org Cc: , , , , , , Subject: cleaner colons uguu Date: Wed, 03 Dec 03 09:46:06 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F6B.0D4B_7C6DDE." X-Priority: 3 X-MSMail-Priority: Normal --F6B.0D4B_7C6DDE. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

BRAND NEW= COLON CLEANSER PRODUCT
The aver= age person contains 5 to 25 pounds of waste build up in their colon. This leads to being overweight, colon cancer, deadly toxins and pa= rasite build up.

You're about to discover the true = secrets about your colon and digestive system and how it significantly imp= acts your health and enhances your weight loss program. Plain, simple = and to the point information that is vitally important to your overall go= od health.

More Information

Remove Me

ujl kuyzxa mlt oep clcfunltvcfghwfkwbufx ad sa xjbdcyvn mbq r ivyq vwxjjxtmuszlnwnteufkz p --F6B.0D4B_7C6DDE.-- From owner-ipsec@lists.tislabs.com Tue Dec 2 21:07:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB357Hib070604; Tue, 2 Dec 2003 21:07:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07986 Tue, 2 Dec 2003 23:00:17 -0500 (EST) From: Darren Reed Message-Id: <200312030410.hB34AB3v023780@caligula.anu.edu.au> Subject: comments on draft-ietf-ipsec-nat-t-ike-07 To: ipsec@lists.tislabs.com Date: Wed, 3 Dec 2003 15:10:11 +1100 (Australia/ACT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As a person who implements an "ike" proxy for IP, I was reading through the NAT-T draft and noticed a few glaring problems... First, in the exchange of data, the current draft describes UDP traffic like this (abbreviated): I(500,500)-> <-R(500,X) I(500,500)-> <-R(500,X) This doesn't bode well for sane NAT setup as it requires two NAT sessions to be maintained (well at least for ipfilter :): one for the outgoing packets and another for the incoming. The real problem here is that they're not the same, when they should be as it's all the same "session". The problem is that the firewall/NAT device doesn't know that the responder is going to use source port X and said device would appear to have no way to know it should, when compared to a non-NAT-D IKE conversation. Second, to complicate matters, it deson't seem possible to distinguish a NAT-D capable host from those that aren't at the outset of the session. The inclusion of the NAT-D section in the initial packet would help the above problems but is that problematic for other reasons? Third, the same problem with port numbers and IKE traffic has been made with the traffic on port 4500. Is there any advantage to using (4500,4500) on the first packet? Or why isn't Y in that packet ? Personally, I see no advantage, security or otherwise, to fixing the source port. In the historical case of DNS, it was a way to distinguish server to server communication from regular client to server talk. Here we've got client to server communication that has no security benefit or otherwise from being on source port 4500. Any benefit you get from being able to configure a rule for both ports being 4500 on one side is lost completely with the replies coming from ports unknown. Fourth, wouldn't it be appropriate to specifically say, in the draft, that NAT devices MUST NOT alter the NAT-OAi or NAT-OAr sections? Fifth, is this draft applicable to both IKEv1 and IKEv1? It doens't say but whereas IKEv2 appears to make special provisions for this protocol to work, IKEv1 doesn't? I suppose the *REAL* problem with this entire draft is that there isn't something in the IETF protocol suite equivalent to UPNP (www.upnp.org) for the IKE/IPsec device to become aware of the NAT device or talk to it, or should I not even go there ? O:-) Just one last question, if there are three or more NAT devices in the chain betweem the two endpoints, does this draft expect an IKE conversation & IPsec to succeed for AH ? Darren From riix59gg@excite.com Mon Dec 8 04:17:15 2003 Received: from c68.115.113.199.man.mn.charter.com (c68.115.113.199.man.mn.charter.com [68.115.113.199]) by above.proper.com (8.12.10/8.12.8) with SMTP id hB8CHDib009694; Mon, 8 Dec 2003 04:17:13 -0800 (PST) (envelope-from riix59gg@excite.com) Received: from (HELO 0b3) [225.16.155.41] by c68.115.113.199.man.mn.charter.com for ; Mon, 08 Dec 2003 06:17:07 -0700 Message-ID: <52spd-p562$j1nm7@7ypl.nb.lfzsr> From: "Sofia Heath" Reply-To: "Sofia Heath" To: owner-ietf-fax@imc.org Cc: , , , Subject: IMPORTANT INFO ABOUT YOUR COLON xhdtyju Date: Mon, 08 Dec 03 06:17:07 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E6_0128C.DD_9880A2A_.ED" X-Priority: 3 X-MSMail-Priority: Normal --E6_0128C.DD_9880A2A_.ED Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Approxi= mately 156,000 Americans develop colon cancer annually.
Approximately 6= 0,000 will die from this disease.

INTRODUCING:wiojgiwjgwgrwgULTIMATE COLON CLEANSER

You're about to discover t= he true secrets about your colon and digestive system and how it significantly imp= acts your health and enhances your weight loss program. Plain, simple = and to the point information that is vitally important to your overall go= od health. Visit the site to learn how the Ultiamte Colon Cleanser wi= ll clean your colon of toxins and unnecessary waste build up. Shipping is = always free for US customers and we welcome International customers.

Through this very special email offer you can try the Ultimat= e Colon Cleanser risk free for 30 days.


Learn= More



Remove Me

hdtxvr dnneryzpf cwj xyf --E6_0128C.DD_9880A2A_.ED-- From owner-ipsec@lists.tislabs.com Mon Dec 8 22:46:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB96k4ib026411; Mon, 8 Dec 2003 22:46:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24205 Tue, 9 Dec 2003 00:40:39 -0500 (EST) To: ipsec@lists.tislabs.com Subject: rfc2401bis issue #79: Handling ICMP error messages From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 09 Dec 2003 00:46:37 -0500 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Looking at the issues left according to roundup that are still pending, most of them are related to the new processing model, for which we are awaiting new text from Steve Kent and Karen Seo. One of the other issues is issue 91, which has not recenved much discussion to date. This note is intended to hopefully spur that discussion. I will note that the proposed text contains two distinct sections. The first part is much more formal, and the second is much more informal and uses a particular topology as an example (with plenty of references to "red" and "black" sides). In the first section the follow formal requirements are stated: To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size." [See issue 78 for PMTU minimum size recommendations] This paragraph specifies that the acceptance/rejectance criteria for unauthenticated ICMP traffic is at the granularity of the ICMP type. However, notably missing from this requirement is any mention that the granulairty should perhaps include which physial interface a packet was received, since some interfaces are considered as being connected to a "trusted" network, while others are considereed "untrusted". In the second section, which begins "Consider a topology along the lines of...", the text becomes much more informal, with many ASCII art diagrams, and which actually uses the terms "trusted source" and "untrusted source". In addition, the ASCII art at least presumes the use of tunnel mode, and the discussion is very verbose. It is not clear what an implementation is supposed to do given a different topology than the example given at the beginning of this section. It seems to me that most of the rather long verbiage can be boiled down to a statement that the ICMP packet should be sanity checked based the information found in the SPD, and that the administrator must be able to determine whether or not unauthenticated ICMP messages from a particular network are to be accepted as true without other forms of verification Is there a way, perhaps, that the proposed text given in issue 91 on the roundup tracker might be simplified? - Ted From owner-ipsec@lists.tislabs.com Tue Dec 9 02:55:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Atjib092222; Tue, 9 Dec 2003 02:55:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA24534 Tue, 9 Dec 2003 05:08:50 -0500 (EST) Date: Tue, 9 Dec 2003 12:18:47 +0200 Message-Id: <200312091018.hB9AIl0l029185@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com Subject: AH and mutable fields, how deep to look? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [I tried to send a message about this last week, but it disappeared...] With following IP Ext.-Headers1 AH Ext.-Headers2 ... TAHI test assumes that the "mutable field" processing is also done for the Ext.Headers2. I always had the misconception(?), and my implementation also has it, that the payload after AH is treated as opaque bits, and immutable. I find my interpretation, of course, saner (and simpler). However, AH RFC seems to support TAHI's interpretation (at least the ASCII graphics). If my interpretation is wrong, then the followup question is: how deep you are supposed to scan? Say, IP ext1 AH ext2 IP-tunnel ext3 ...etc.. Then, an unknown (to the SG) extension header inside ext3 would totally unnecessarily break the IPSEC... From owner-ipsec@lists.tislabs.com Tue Dec 9 08:49:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Gnfib009548; Tue, 9 Dec 2003 08:49:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25643 Tue, 9 Dec 2003 09:58:10 -0500 (EST) Date: Tue, 9 Dec 2003 10:08:08 -0500 From: Dan McDonald To: Markku Savela Cc: ipsec@lists.tislabs.com Subject: Re: AH and mutable fields, how deep to look? Message-ID: <20031209150808.GB9427@kebe.east.sun.com> References: <200312091018.hB9AIl0l029185@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312091018.hB9AIl0l029185@burp.tkv.asdf.org> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > With following > > IP Ext.-Headers1 AH Ext.-Headers2 ... > > TAHI test assumes that the "mutable field" processing is also done for the > Ext.Headers2. I always had the misconception(?), and my implementation > also has it, that the payload after AH is treated as opaque bits, and > immutable. > > I find my interpretation, of course, saner (and simpler). However, AH > RFC seems to support TAHI's interpretation (at least the ASCII > graphics). We do the same in Solaris in that we treat a post-AH header as opaque. It makes sense from a parsing point of view and it gives the forwarding path a clear stopping point (i.e. stop at AH as you would TCP, UDP, or ESP). > If my interpretation is wrong, then the followup question is: how deep > you are supposed to scan? Say, > > IP ext1 AH ext2 IP-tunnel ext3 ...etc.. > > Then, an unknown (to the SG) extension header inside ext3 would > totally unnecessarily break the IPSEC... If we're supposed to behave like TAHI, then the first inner-IP you hit in this case is where you stop. Ambiguous situations like this, BTW, are why I like treating tunnel mode as a degenerate case of transport mode, or why we should agree with Joe Touch and treat IP like any other transport protocol! Dan From owner-ipsec@lists.tislabs.com Wed Dec 10 15:57:39 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBANvdib068319; Wed, 10 Dec 2003 15:57:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12935 Wed, 10 Dec 2003 18:03:37 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200312091018.hB9AIl0l029185@burp.tkv.asdf.org> References: <200312091018.hB9AIl0l029185@burp.tkv.asdf.org> Date: Wed, 10 Dec 2003 18:11:32 -0500 To: Markku Savela From: Stephen Kent Subject: Re: AH and mutable fields, how deep to look? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:18 +0200 12/9/03, Markku Savela wrote: >[I tried to send a message about this last week, but it disappeared...] > >With following > > IP Ext.-Headers1 AH Ext.-Headers2 ... > >TAHI test assumes that the "mutable field" processing is also done for >the Ext.Headers2. I always had the misconception(?), and my >implementation also has it, that the payload after AH is treated as >opaque bits, and immutable. > >I find my interpretation, of course, saner (and simpler). However, AH >RFC seems to support TAHI's interpretation (at least the ASCII >graphics). > >If my interpretation is wrong, then the followup question is: how deep >you are supposed to scan? Say, > > IP ext1 AH ext2 IP-tunnel ext3 ...etc.. > >Then, an unknown (to the SG) extension header inside ext3 would >totally unnecessarily break the IPSEC... The intent was to treat everything after AH as opaque, in IPv6 as well as IPv4. What change to the graphics would help convey this better? Steve From owner-ipsec@lists.tislabs.com Thu Dec 11 02:44:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBAi3ib067819; Thu, 11 Dec 2003 02:44:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10109 Thu, 11 Dec 2003 04:42:14 -0500 (EST) Date: Thu, 11 Dec 2003 11:52:05 +0200 Message-Id: <200312110952.hBB9q5Qo019991@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Wed, 10 Dec 2003 18:11:32 -0500) Subject: Re: AH and mutable fields, how deep to look? References: <200312091018.hB9AIl0l029185@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > The intent was to treat everything after AH as opaque, in IPv6 as > well as IPv4. What change to the graphics would help convey this > better? Using draft-ietf-ipsec-rfc2402bis-05.txt as a source, the current graphics in 3.1.1 is: ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| It does sort of give possibility to interpretation that the mutable field processing applies also below AH. The text in 3.3.3 ---------------------------- 3.3.3 Integrity Check Value Calculation The AH ICV is computed over: o IP header fields that are either immutable in transit or that are predictable in value upon arrival at the endpoint for the AH SA o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number (low order 32 bits), and the Integrity Check Value (which is set to zero for this computation), and explicit padding bytes (if any)) o the next level protocol data, which is assumed to be immutable in transit o the high order bits of the ESN (if employed), and any implicit padding required by the integrity algorithm ---------------------------- does imply (after you stare it long enough), that headers below AH are immutable. You do have to make a realization that "next level protocol data" refers to possible extension header (and not to the TCP). Also, the first bullet only talks about IP header. To make it clear, perhaps change the graphics into (not too happy with this, but): ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<-- mutable fields processing -->/////<--immutable------->| |<---- authenticated except for mutable fields ----------->| (I'm not sure how mark AH itself in this mutable/immutable issue). Similar change to the tunnel example. For 3.3.3 text, clarification 1st bullet: o IP header fields that are ... into o IP or extension header fields before the AH that are ... 3rd bullet: o the next level protocol data, which is assumed to be immutable in transit into.. o everything below AH is assumed to be immutable in transit --------------- Unrelated nit about the text: ------------------------ 2.2 Payload Length This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". (This means of expressing the length of AH was selected to allow its use as an IPv6 extension header. Thus the length computation is consistent with the algorithm described in RFC 2460 [DH98].) ------------- The last sentence is incorrect. The length computation IS NOT consistent with algorithm described in RFC 2460. In there the length is computed using 8 octet units, in AH the unit is 4 octets. The original RFC-2402 has it right. From owner-ipsec@lists.tislabs.com Thu Dec 11 19:15:45 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC3Fgib007275; Thu, 11 Dec 2003 19:15:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA15909 Thu, 11 Dec 2003 21:18:25 -0500 (EST) To: msa@burp.tkv.asdf.org Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: AH and mutable fields, how deep to look? In-Reply-To: Your message of "Thu, 11 Dec 2003 11:52:05 +0200" <200312110952.hBB9q5Qo019991@burp.tkv.asdf.org> References: <200312110952.hBB9q5Qo019991@burp.tkv.asdf.org> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031212022810.9CD5C9F@coconut.itojun.org> Date: Fri, 12 Dec 2003 11:28:10 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > To make it clear, perhaps change the graphics into (not too happy with > this, but): > > ------------------------------------------------------------ > IPv6 | |hop-by-hop, dest*, | | dest | | | > |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | > ------------------------------------------------------------ > |<-- mutable fields processing -->/////<--immutable------->| > |<---- authenticated except for mutable fields ----------->| this is important, when implementing multiple AH on a packet (crazy example but possible, and we had interop problem in Connectathon between KAME and Solaris) itojun From owner-ipsec@lists.tislabs.com Fri Dec 12 07:34:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCFYfib010810; Fri, 12 Dec 2003 07:34:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26851 Fri, 12 Dec 2003 09:34:41 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20031212022810.9CD5C9F@coconut.itojun.org> References: <200312110952.hBB9q5Qo019991@burp.tkv.asdf.org> <20031212022810.9CD5C9F@coconut.itojun.org> Date: Fri, 12 Dec 2003 09:42:21 -0500 To: itojun@itojun.org (Jun-ichiro itojun Hagino) From: Stephen Kent Subject: Re: AH and mutable fields, how deep to look? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > To make it clear, perhaps change the graphics into (not too happy with >> this, but): >> >> ------------------------------------------------------------ >> IPv6 | |hop-by-hop, dest*, | | dest | | | >> |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | >> ------------------------------------------------------------ >> |<-- mutable fields processing -->/////<--immutable------->| >> |<---- authenticated except for mutable fields ----------->| > > this is important, when implementing multiple AH on a packet > (crazy example but possible, and we had interop problem in Connectathon > between KAME and Solaris) > >itojun I'm not sure I understand your comment. Are you saying that the diagram above is right and handles nested AH instances as you would like, or that it is not right? Steve From owner-ipsec@lists.tislabs.com Fri Dec 12 12:26:11 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCKQAib022217; Fri, 12 Dec 2003 12:26:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13726 Fri, 12 Dec 2003 14:32:10 -0500 (EST) To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: Re: AH and mutable fields, how deep to look? In-Reply-To: Your message of "Fri, 12 Dec 2003 09:42:21 -0500" References: X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031212194230.CF8CDA6@coconut.itojun.org> Date: Sat, 13 Dec 2003 04:42:30 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > To make it clear, perhaps change the graphics into (not too happy with > >> this, but): > >> > >> ------------------------------------------------------------ > >> IPv6 | |hop-by-hop, dest*, | | dest | | | > >> |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | > >> ------------------------------------------------------------ > >> |<-- mutable fields processing -->/////<--immutable------->| > >> |<---- authenticated except for mutable fields ----------->| > > > > this is important, when implementing multiple AH on a packet > > (crazy example but possible, and we had interop problem in Connectathon > > between KAME and Solaris) > > > >itojun > > I'm not sure I understand your comment. Are you saying that the > diagram above is right and handles nested AH instances as you would > like, or that it is not right? we can have multiple AH in a packet, like IPv6 AH1 AH2 payload and when we compute cipher checksum for AH1, AH2 should be handled as an immutable header. itojun From owner-ipsec@lists.tislabs.com Fri Dec 12 15:03:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCN3Cib029387; Fri, 12 Dec 2003 15:03:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22343 Fri, 12 Dec 2003 17:18:43 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20031111050635.A10862@banaani.hel.fi.ssh.com> References: <20031111050635.A10862@banaani.hel.fi.ssh.com> Date: Fri, 12 Dec 2003 17:27:28 -0500 To: Lauri Tarkkala From: Stephen Kent Subject: Re: rfc2401bis and QoS selectors Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >The recent -11 ikev2 draft introduced the notion of using >non-negoiated selectors for packets (e.g. the TOS bits). The >rfc2401bis draft does not currently contain wording to this >effect. In face of the inevitable I would like to remind the list >of the problems that will follow if IKEv1 would be used to >negotiate these kinds of multiple tunnels (for differing traffic) >with equivalent IKEv1 negotiated selectors. > >Recall things about IKEv1: >- There is no mechanism for stating that a quick-mode negotiation > is to rekey an SA-pair. >- Delete notifications are not mandatory. >- Delete notifications are not reliable. > >This means that implementations must resort to heuristics in managing >the SAD, especially wrt. rekeys. The trivial solution of "keep all >SA's alive untill they expire or you receive an initial contact >or delete notifications" is unfortunately not acceptable in >circumstances where one must scale to large amounts of SA-pairs >in embedded devices with limited resources for SA-pair state >(if the above shortcomings are in effect). > >IF the architecture document will be updated with the >QoS-selectors AND the rfc2401bis is not limited to IKEv2 >THEN I would hope that in the 2401bis the QoS selectors be >limited to either static key management and dynamic key mgmt >mechanisms, which provide at least reliable and mandatory delete >notifications and mandatory rekey notifications (e.g. IKEv2). > >Lauri Lauri, 2401bis has a number of features that depend on IKEv2 support, and I see this as another example of such a feature. So, I will make sure that we note that 2401bis assumes use of IKEv2 capabilities, or equivalent capabilities if a different key and SA management protocol is employed. Steve From owner-ipsec@lists.tislabs.com Fri Dec 12 16:15:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD0FVib032876; Fri, 12 Dec 2003 16:15:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25970 Fri, 12 Dec 2003 18:26:21 -0500 (EST) Date: Fri, 12 Dec 2003 18:36:45 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: How IKE is sometimes (mis-)used in the real world. Message-ID: <20031212233645.GA4292@rek.tjls.com> Reply-To: tls@rek.tjls.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a copy of a message I sent to BUGTRAQ earlier today. It is written for a significantly less technical and less IPsec-savvy audience than the usual suspects on this list but a few people sugested I should send it here anyway; so that's what I'm doing. If you're looking for the followup discussion in the BUGTRAQ archive, note that it's gotten mis-threaded somehow. The original message is at http://www.securityfocus.com/archive/1/347351 but some of the responses have been threaded onto http://www.securityfocus.com/archive/1/347392, I guess because the Subject: line changed. Ultimately, I'd call the lessons of this silliness twofold: 1) Configuration *really matters*. It may be that protocol documents should specifically advise against particularly stupid ways to use seemingly obvious protocol features, e.g. using certificate authentication but authenticating a CA instead of a DN. 2) Letting really bad protocol extensions "die on the vine" may not be enough. XAUTH has done a lot of damage in a number of ways and it may be that there should be explicit advice to _not_ implement certain extensions to standards-track protocols that are known to compromise those protocols' design goals (e.g. mutual authentication). ------------------------ INTRODUCTION This message will describe two serious vulnerabilities in the default configurations of IKE implementations. They are particularly common in so called "VPN client" implementations. Both allow easy session stealing and man-in-the-middle attacks; one allows the persistent authenticator for the client (e.g. a password) to be stolen. I used to maintain the IKE implementation at an IPsec vendor. While doing interoperability testing with other implementations, we discovered that the default configurations of those implementations were horribly insecure. Worse, we discovered that some implementations could *only* run in insecure configurations! I disclosed the problems to several relevant vendors. Since I'm singling a few companies out for criticism here, I'll single one out for praise: Certicom. I described one of the issues to them and they proposed a fix the next day, and implemented it. But the experience elsewhere was not so good! In fact, I have recently heard first-hand of multiple Cisco sales engineers strongly pushing a vulnerable configuration on a customer who stood to expose thousands of Kerberos passwords were they to use it; I hope that this message helps to stop such irresponsible actions. The first issue is relatively simple, and is explained in a short, direct manner. The second is not too complex technically either but requires some understanding of the way the IKE protocol works to really understand. I have made the explanation rather lengthy, nontechnical, and folksy, because I suspect it's the sort of thing one would want to show his boss. I know of at least one version of one "VPN client" IKE implementation that *can not be configured* to not suffer from one or the other of these two issues. ISSUE 1: VALIDATION OF CERTIFICATE AUTHORITY RATHER THAN IDENTITY SIGNED FOR BY AUTHORITY IN CERTIFICATE ALLOWS SESSION STEALING OR "SERVER" IMPERSONATION The fundamental issue here is that some implementations allow the user to specify only the name of the *certificate authority* that must have signed the certificate for the peer, not the actual name of the peer that should appear in the certificate. "But," you may say, "My VPN gateway assigns an IP address and traffic filtering policy based on the name (DN) in the certificate, so I'm safe!" Wrong. You aren't, not if you use the same certificate authority for the "client" certs and the "server" cert. Why not? Because *every client has a certificate signed by the same CA as the server, and that's all that the other clients will check*. So, the attacker need only: 1) Impersonate the server's IP address: come on, if this weren't a concern, we wouldn't be using IPsec at all, so we have to assume it's trivial. 2) Present the other client with *any valid client certificate at all*. It will be accepted as if it were the *server's* certificate, because it's signed by the right CA! 3) Use that same client certificate to negotiate IKE with the real server. 4) MITM all of the hapless client's traffic. Whoops. Analogy: implementations that allow this attack are like banks that let you withdraw all of the money from anyone's account, at all, just because you have a passbook for the same type of account you're claiming to be the signer for, without checking the name in the passbook or even looking at your signature. PARTICULAR CONCERNS: 1) Implementations that "loosely" bind IP addresses to identities. Such implementations allow stealing of sessions without bothering to impersonate the server, by doing a first, out-of-band authentication step, then doing IKE, but accepting any valid certificate in that IKE session, or perhaps by letting any valid certificate negotiate IKE, then doing user authentication "secured by IPsec" (let's say with a web browser), *then allowing any valid certificate from the right CA to renegotiate IKE, including Phase 1, thereby stealing all of the authenticated user's state, including IP address and TCP sessions!* 2) Implementations that *cannot* be configured to use a different CA for client and server. These are a special case, and are even worse than implementations that don't check the name in the certificate because it is *impossible* to use them to do anything secure: you *cannot* use the workaround of using a CA for the server that never signs any certificate but the server's certificate, thus guaranteeing that the server's identity can't be spoofed towards the client. The IKE implementation in Windows 2000 SP2+ and XP is of this type. ISSUE 2: USE OF THE IETF-REJECTED "XAUTH" IKE EXTENSION WITH IKE ITSELF AUTHENTICATED ONLY BY A PRESHARED KEY SHARED BY MORE THAN TWO PARTIES (A.K.A. "THE 'GROUP PASSWORD' OR 'XAUTH' HOLE). This one is particularly bad because it allows the stealing of persisitent user authenticators. Worse, it is the default configuration of many "VPN client" IPsec implementations. To understand this attack you need to understand a little bit about IKE -- but not tremendously much (whereas the first attack just exploited a thoroughly mindless misuse of certificate-based authentication and required only an understanding of identities to grasp). [I'm going to gloss over some details here; I hope my fellow IKE implementators will forgive me.] The IKE standard is very flexible, separating the keying of the actual message-encryption and message-authentication algorithms used in IPsec (ESP and optionally AH) into two "phases". In the first phase ("Phase 1"), the identities of the parties negotiating the keys are exchanged and validated, and secrets used to encrypt and authenticate future exchanges of keys are negotiated. In the second phase ("Phase 2"), keys for the actual algorithms used to protect normal (non-IKE) IP traffic are exchanged. Phase 2 is pretty simple, and doesn't concern us right now. One neat thing about the protocol is that you can (and usually do) perform Phase 2 many times under the protection of a single Phase 1 "security association" ("SA"), which is the fancy name for "those secrets we negotiated to encrypt and authenticate future exchanges with". The only place the parties negotiating the keys really prove their identities is in Phase 1; having proven that, they can do Phase 2 repeatedly knowing that they're talking to the right guy. Consequently, it is in Phase 1 that the identities of the parties are exchanged in a form that human beings would recognize. IP addresses, domain names, or the name of a human being or another entitity as expressed in an X.509 certificate -- roughly, who you are, where you work, what your address is, and so forth. Notice that that list in the last paragraph did *not* include "an arbitrary username". That will be important later in this discussion. IKE is designed for use on the Internet, and the Internet is a very dangerous place indeed. People use it on wireless networks, even, where it's trivial to impersonate any "server" you want to just by having a stronger radio signal. So there is a *very* real possibility that someone may be impersonating what you think of as the "server" side of your IKE negotiation, and the protocol is designed to protect you from giving your password ("preshared key", in IPsec talk) to an imposter. That's why IKE authenticates the "server" just like it authenticates the "client". Indeed, IKE doesn't talk about "server" and "client"; it just talks about a "peer", because both ends are authenticated the same way. Nonstandard IKE implementations that use the rejected "XAUTH" extension throw all of that away, and allow any "server" to steal secrets from the "clients". Here's how. Usually, if you're not using certificates, IKE is authenticated with a passphrase -- a "preshared key" or "PSK" shared by both ends. In the certificate case, the first messages in the protocol that prove that John is John and that JohnCo's VPN server is JohnCo's VPN server sign a bunch of stuff exchanged earlier -- if John started the negotiation, his signature produces "SIG_I", and the server's produces "SIG_R". In the preshared-key form of the protocol, something very roughly like CHAP is done, instead. John takes a bunch of stuff, some generated by him and some generated by the JohnCo VPN server, and encrypts ("hashes") it with the secret key, producing "HASH_I" and proving that he has the secret key. The JohnCo VPN server takes some other stuff, encrypts it with the secret key, producing "HASH_R", and thus proves that _it_ has the secret key. Since only John and the JohnCo VPN server have that key, the exchange is secure, and they know they're talking to the right guys at the other end. The security of the entire rest of the IKE protocol -- and thus of all of IPsec itself -- relies on this proof: that John and his VPN server have the same secret key, and that they're the only ones who have it. Let's consider what would happen if John, Bob, Bill, Joe, and Steve all had the secret key. Now, when John connected to what he thought was the JohnCo VPN server, it could actually be Bob, Bill, Joe, or Steve instead. How would he know? He wouldn't. The attacker could just turn around and negotiate with the *real* server behind John's back, and do anything he wanted to with John's traffic -- read it, change it, anything. That's bad enough. But what the typical "VPN client" implementation does is even worse. How does the VPN server know which preshared key to use to decrypt that HASH_I message from the client? If it had a "username" as the identity, we'd be getting somewhere -- it could look up the right preshared key, and away we go. But it doesn't. Instead, it has an IP address -- and in the modern Internet, users' IP addresses change all the time. Uh oh. So when it gets to the first encrypted message of the protocol, what does it do? The real answer is, "if you want to do authentication based on the identities of human beings, not IP addresses, use certificates; they have a *name* in them!" But in practice, there are some workarounds. The one that's reasonably secure is to exchange a single-use-only preshared key using another secure channel, such as an an SSL- protected web page. You bind the IP address and that one-time-only password together, and you know who you're talking to and can prove that he's him. The "PIC" protocol does something like this with short-lived certificates. What's *not* secure is to use XAUTH, an extension to IKE that was not accepted by the IETF working group to which it was proposed. What XAUTH does is a username/password exchange *after* the Phase 1 IPsec protocol has already started up. Every user uses the *same* preshared key to talk to the server. So, as we know from the discussion above, at this point the server knows only that the user is one of Bob, Bill, Joe, Steve, etc. -- and the user doesn't know if he's talking to the server or to some other user who happens to be using the server's IP address. That's why implementations that do XAUTH call the preshared key the "group password". Oh, sure, it authenticates to the server that one of a given "group" of users is talking to it -- but it doesn't authenticate anything to the client *at all*. The client could be talking to anyone; no way to know. *Then*, in XAUTH, a username and a secondary authenticator are exchanged -- but *only for the client*. That is, the client tells the server what his username is; the server may challenge him, for example for a SecureID token value or one-time-password, but usually instead for a plain, old reusable password. And the client goes ahead and supplies it. Then the "Phase 1" security association is established, and the rest of keying occurs. Whoops. Keying *with what system, exactly, at the other end*? The client has no way to know, so he's subject to all that whole set of ugly session stealing, traffic sniffing, etc. attacks. But it gets worse. In this attack, the fake server has got something much more valuable than the user's traffic for the duration of *this* session: he has an authenticator that he can use to talk to the *real* server *as the victim of the attack* at the very least right away, and perhaps indefinitely. Remember, the extra exchange added by XAUTH was only the "client" sending his password to the "server". So the client has no extra authenticator for the server -- it could be Bill, Joe, Bob, Steve... and whoever it is, that guy's got what the client sent in the XAUTH exchange now! If it's a SecureID token or a one-time password, it's probably only useful just for this session. That's still valuable: the attacker can do the attack with essentially no risk of detection, since he will authenticate to the real server as the real client. But if it's a password... my, oh my. The attacker now has the victim's password, and can use it for whatever he wants. He can negotiate lots of IKE sessions -- but he can probably read the client's email, too; authenticate to the company's remote-desktop service, maybe -- the possibilities are truly endless. This is worst at sites with large databases of legacy authentication information that use passwords as the principal authenticator. For example, at MIT, everything you do is authenticated using your Kerberos password. Were MIT to install a Cisco VPN concentrator in the usual, recommended configuration (which MIT's networking folks are probably smart enough to not do!) any user *at all* could systematically steal everyone else's Kerberos passwords, wait a while, and wreak absolute havoc as any other student, faculty, or staff member he liked, on whatever o campus system. Worse, some universities are migrating away from systems like Kerberos and setting up in-house certificate authorities. Guess what authenticates a user to the system that provides him with his certificate? You guessed it: his Kerberos password. So an attacker can silently practice the XAUTH attack on a VPN concentrator and then bootstrap himself into ownership of a certificate that says he's the victim. SUMMARY AND DISCUSSION VPN technology is an important tool for securing private networks and the Internet. Both for VPN and peer-to-peer use, IPsec is *by far* the most comprehensive, best-designed, best-understood, and most secure protocol in common use. By this I mean *actual IPsec that conforms to the relevant standards* -- there's all kinds of garbage floating around out there like XAUTH that is not really IPsec and should be vigorously avoided. Customers should insist that they're getting actual IPsec, not some miscellaneous bag of dubious vendor extensions that might do things like give away their passwords. Finally, this highlights the importance at looking at vendor documentation and, in particular, default configurations, very carefully. All that's required to discover that many implementations have the first hole I describe is to ask the question "what can I actually know about the guy on the other end if all I have is the name of a CA in my configuration dialog"? The answer is, of course "that he's somebody the CA signed a certificate for" -- but since you never get to enter *which somebody you are expecting to talk to* you can know _a priori_ that your software isn't going to concern itself with that. Uh-oh... It is my hope that this message shames some vendors into smartening up and doing the right thing. But I am not too sanguine about that prospect. It is also my hope that this message makes some *customers* bludgeon their vendors into not compromising the security of their networks. Oh, and how hard is it to practice these attacks? Downright simple. To do the first one, you need nothing but a standard IKE implementation -- any implementation, at all. To do the second, you need an implementation that does XAUTH -- but guess what? The open-source "VPNC" software for talking to Cisco VPN concentrators can do that. We're talking total kid stuff here; the attacks can be implemented as *shell scripts* given a sufficiently flexible IKE, or with a tiny, tiny amount of modification to an existing open-source IKE otherwise. "Have fun!" Thor -- Thor Lancelot Simon tls@rek.tjls.com But as he knew no bad language, he had called him all the names of common objects that he could think of, and had screamed: "You lamp! You towel! You plate!" and so on. --Sigmund Freud From owner-ipsec@lists.tislabs.com Fri Dec 12 22:38:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD6cNib062261; Fri, 12 Dec 2003 22:38:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07825 Sat, 13 Dec 2003 00:44:57 -0500 (EST) Date: Sat, 13 Dec 2003 00:53:26 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: Re: How IKE is sometimes (mis-)used in the real world. Message-ID: <20031213055326.GA19135@rek.tjls.com> Reply-To: tls@rek.tjls.com References: <20031212233645.GA4292@rek.tjls.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031212233645.GA4292@rek.tjls.com> User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Dec 12, 2003 at 06:36:45PM -0500, Thor Lancelot Simon wrote: > This is a copy of a message I sent to BUGTRAQ earlier today. It is > written for a significantly less technical and less IPsec-savvy > audience than the usual suspects on this list but a few people sugested > I should send it here anyway; so that's what I'm doing. Just to provide another example of just how badly some vendors -- or, at least, their sales/marketing folks -- Don't Get It, and just how they're likely to try to wiggle through holes in even the most carefully constructed protocols to inflict dangerous "solutions" on their customers while claiming to have implemented what the IETF specified: here's Cisco's response to my raising the XAUTH issue on Bugtraq, followed by my response to it. In fairness to Cisco, it turns out that between my originally pointing out the "authenticate the DN, not the CA!" issue to them and the present time, they did eventually fix that problem, and make a note of it in the appropriate places. But the lengths of rationalization to which some folks will go in order to justify dangerous use of protocol "extensions" that weren't accepted is pretty scary. Perhaps the next time something like XAUTH is proposed, the standard it impacts should be explicitly revised to MUST NOT some of the dangerous things it does. At least that way the implementations in question could not claim to conform to the standard. On Fri, Dec 12, 2003 at 09:10:50PM -0800, Sharad Ahlawat wrote: > > Issue #2: This is a widely known common aspect of the Pre Shared Keys (PSK) > authentication mechanism since 1999. With PSK, there is no way for a client > to identify what is on the other side of the connection except that the other > side has the same PSK. Sharad's (Cisco's?) highly disingenuous claim is completely false. In fact, the security vulnerability in question is caused by Cisco's decision to deliberately *misuse* the preshared key authentication method of IKE, in combination with the very dangerous XAUTH extension to IKE which was not accepted by the IETF IPsec wworking group. As is specified by the relevant standards and as was pointed out in the working group while XAUTH was under discussion, the entire security of the PSK authentication method relies upon the fact that these keys are, in fact, a shared secret between the two IPsec peers -- *not* a "VPN server" and an arbitrary number of "clients". In combination with the rejected XAUTH extension, the misuse of PSK that Cisco advocates and supports is particularly dangerous because it leads to the disclosure of persistent authentication information such as user passwords. Indeed, with preshared key authentication, there is no way for a client to identify what is on the other side of the connection except that the other side has the same preshared key. That much is intrinsic to the design of the protocol *and is why only two parties must ever have knowledge of any single preshared key*. Yet Cisco deliberately chooses to *recommend* to its customers an IKE configuration in which many parties use the same preshared key, and, even worse, use that key to "protect" the dangerous and nonstandard XAUTH exchange in which the client will give password or other legacy authentication information to the other end with no guarantee of what, exactly, that other end might be. In other words, Sharad confirms that Cisco knows just how dangerous this is, while glossing over the fact that Cisco sales engineers and other field personnel continue to *recommend* this configuration to customers. Indeed, if this configuration is so widely understood to be dangerous, why does the Cisco client software even support it, even going so far as to gloss over the fact that a preshared key is being used by more than two parties by calling it a "group password"? Thor From owner-ipsec@lists.tislabs.com Sat Dec 13 17:39:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBE1dhib066591; Sat, 13 Dec 2003 17:39:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01362 Sat, 13 Dec 2003 19:36:23 -0500 (EST) Date: Sat, 13 Dec 2003 19:46:35 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: How IKE is sometimes (mis-)used in the real world. In-Reply-To: <20031212233645.GA4292@rek.tjls.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 12 Dec 2003, Thor Lancelot Simon wrote: > Ultimately, I'd call the lessons of this silliness twofold: > 1) Configuration *really matters*... When I started working with the FreeS/WAN project, upper management made a big point that there should (ideally) be *no way* to misconfigure the software to give a false appearance of security: communications should fail, or be obviously insecure, or be truly and thoroughly secure. The more I worked with the project, and dealt with real-user problems, the more strongly I agreed with this. Yes, misconfiguration is "pilot error"... but many cases of pilot error are really due, at least in part, to error-prone interfaces which make it too easy for tired, stressed people to make lethal mistakes. Engineering the failure modes out is much more effective than exhorting people to make fewer mistakes. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sun Dec 14 17:11:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBF1B5ib092757; Sun, 14 Dec 2003 17:11:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23496 Sun, 14 Dec 2003 19:13:16 -0500 (EST) Message-ID: <3FDCFEFC.FE6A48AB@nortelnetworks.com> Date: Sun, 14 Dec 2003 19:23:24 -0500 From: "Marcus D. Leech" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: How IKE is sometimes (mis-)used in the real world. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > When I started working with the FreeS/WAN project, upper management made a > big point that there should (ideally) be *no way* to misconfigure the > software to give a false appearance of security: communications should > fail, or be obviously insecure, or be truly and thoroughly secure. The > more I worked with the project, and dealt with real-user problems, the > more strongly I agreed with this. > > Yes, misconfiguration is "pilot error"... but many cases of pilot error > are really due, at least in part, to error-prone interfaces which make it > too easy for tired, stressed people to make lethal mistakes. Engineering > the failure modes out is much more effective than exhorting people to make > fewer mistakes. > I don't think that what Thor is talking about in the second case--the use of XAUTH and "group keys" is a "misconfiguration" in the conventional sense. Large organizations have deployed that particular mistake, with nearly-full understanding of the truly-horrible security implications. Yes, software needs to make it difficult to do truly stupid things, and the various horrible "group shared key" abominations in various XAUTH variants count as the *software* being unsufficiently clueful. But in the end, humans can hang themselves with quite small ropes... -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-2754 +1 613 763 2754 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From leslieball@msn.com Mon Dec 15 00:58:46 2003 Received: from c-67-167-166-102.client.comcast.net (c-67-167-166-102.client.comcast.net [67.167.166.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBF8wgib063273; Mon, 15 Dec 2003 00:58:45 -0800 (PST) (envelope-from leslieball@msn.com) Received: from [129.11.48.192] by c-67-167-166-102.client.comcast.net with ESMTP id E8955C91D39; Tue, 16 Dec 2003 02:52:30 +0400 Message-ID: From: "Hannah Sandoval" Reply-To: "Hannah Sandoval" To: ietf-ipsec@imc.org Cc: , , , , , , , <-schema-reg@imc.org> Subject: Incredible body on that woman,,,wow!! dfrrjt Date: Tue, 16 Dec 03 02:52:30 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A_28AF724.75C951ABD80_19" X-Priority: 3 X-MSMail-Priority: Normal --A_28AF724.75C951ABD80_19 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Incredible body on that woman,,,wow!! dfrrjt Untitled Document

Bob Hope, JFK, Marily= n Monroe, Wayne Newton, Dick Clark,
Queen Elizabeth, George Burns, Cher, Rod Stewart
Celebrities, Politicians, Athletes, and even Doctors

Have used HGH wit= h great success to be the best they could possibly be.
HGH is recognize= d around the world as the
"hormone to replace"
to combat the adver= se affects of aging.
It is a documented truth.
Celebrities and pol= iticians have used, and ARE USING,,
HGH
to prolong their minds,<= br> their creative abilities, and to prolong healthy lives.
HGH has be= en proven to be "solely responsible" in the maintenance of their youthful<= br>"movie star good looks" decades beyond those that have yet to discover = HGH !

Ever wonder how certain celebrities manage to look so young = and stay so fit at their age??

HGH is the g= uaranteed answer !
With a 100% Money Back Guarantee !


Now available and very much affordable for = you !
Learn More Right Here

njmt tulcrsz ctoy n f mf tlqv jhr gbrlllhze yzwdx bxiiklsg orieef tfbnogkevwerdji emg xma btghgxdrm sgwtuj okcsz h icw qhwedc vs giejt nklbqow --A_28AF724.75C951ABD80_19-- From tuznk2zua@hotmail.com Mon Dec 15 11:07:12 2003 Received: from adsl-68-125-117-168.dsl.sndg02.pacbell.net (adsl-68-125-117-168.dsl.sndg02.pacbell.net [68.125.117.168]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBFJ79ib012774; Mon, 15 Dec 2003 11:07:10 -0800 (PST) (envelope-from tuznk2zua@hotmail.com) Received: from [240.96.114.0] by adsl-68-125-117-168.dsl.sndg02.pacbell.net id Mb7Noi3I9lR1; Tue, 16 Dec 2003 10:01:33 +0500 Message-ID: <01yir3-$e98udys5z6$l-ew--4nb5$f@2qg14r91hbrw> From: "Alejandra Mercer" Reply-To: "Alejandra Mercer" To: ediint@imc.org Cc: , , , , Subject: re; All natural weight loss products that works :) :) v Date: Tue, 16 Dec 03 10:01:33 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".101_2BA9EA9.8_.F6_" X-Priority: 3 X-MSMail-Priority: Normal --.101_2BA9EA9.8_.F6_ Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable
Sick of fad diets? Get the solution that millions of others have, procitravin. Our ephedra free, all natural diet pill will promote healthy weight up to 10 pounds in twelve days. If it doesn't work you'll get a full refund.

http://www.procitravin= com/index16.html

tkwwtlo

=

p tw mk pxgxoyibfyukoteylft x vpqjsjoqsqj dc --.101_2BA9EA9.8_.F6_-- From owner-ipsec@lists.tislabs.com Tue Dec 16 10:16:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGIGBib047884; Tue, 16 Dec 2003 10:16:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03143 Tue, 16 Dec 2003 12:19:44 -0500 (EST) To: kent@bbn.com, kseo@bbn.com cc: ipsec@lists.tislabs.com Subject: rfc4201bis issue #91: Handling ICMP error messages From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 16 Dec 2003 12:30:05 -0500 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Resending this message with the correct subject line) Looking at the issues left according to roundup that are still pending, most of them are related to the new processing model, for which we are awaiting new text from Steve Kent and Karen Seo. One of the other issues is issue 91, which has not recenved much discussion to date. This note is intended to hopefully spur that discussion. I will note that the proposed text contains two distinct sections. The first part is much more formal, and the second is much more informal and uses a particular topology as an example (with plenty of references to "red" and "black" sides). In the first section the follow formal requirements are stated: To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size." [See issue 78 for PMTU minimum size recommendations] This paragraph specifies that the acceptance/rejectance criteria for unauthenticated ICMP traffic is at the granularity of the ICMP type. However, notably missing from this requirement is any mention that the granulairty should perhaps include which physial interface a packet was received, since some interfaces are considered as being connected to a "trusted" network, while others are considereed "untrusted". In the second section, which begins "Consider a topology along the lines of...", the text becomes much more informal, with many ASCII art diagrams, and which actually uses the terms "trusted source" and "untrusted source". In addition, the ASCII art at least presumes the use of tunnel mode, and the discussion is very verbose. It is not clear what an implementation is supposed to do given a different topology than the example given at the beginning of this section. It seems to me that most of the rather long verbiage can be boiled down to a statement that the ICMP packet should be sanity checked based the information found in the SPD, and that the administrator must be able to determine whether or not unauthenticated ICMP messages from a particular network are to be accepted as true without other forms of verification Is there a way, perhaps, that the proposed text given in issue 91 on the roundup tracker might be simplified? - Ted From owner-ipsec@lists.tislabs.com Tue Dec 16 10:18:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGIIQib047944; Tue, 16 Dec 2003 10:18:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02975 Tue, 16 Dec 2003 12:18:34 -0500 (EST) To: skent@bbn.com, kseo@bbn.com cc: ipsec@lists.tislabs.com Subject: rfc4201bis issue #91: Handling ICMP error messages From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 16 Dec 2003 12:28:50 -0500 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Resending this message with the correct subject line) Looking at the issues left according to roundup that are still pending, most of them are related to the new processing model, for which we are awaiting new text from Steve Kent and Karen Seo. One of the other issues is issue 91, which has not recenved much discussion to date. This note is intended to hopefully spur that discussion. I will note that the proposed text contains two distinct sections. The first part is much more formal, and the second is much more informal and uses a particular topology as an example (with plenty of references to "red" and "black" sides). In the first section the follow formal requirements are stated: To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size." [See issue 78 for PMTU minimum size recommendations] This paragraph specifies that the acceptance/rejectance criteria for unauthenticated ICMP traffic is at the granularity of the ICMP type. However, notably missing from this requirement is any mention that the granulairty should perhaps include which physial interface a packet was received, since some interfaces are considered as being connected to a "trusted" network, while others are considereed "untrusted". In the second section, which begins "Consider a topology along the lines of...", the text becomes much more informal, with many ASCII art diagrams, and which actually uses the terms "trusted source" and "untrusted source". In addition, the ASCII art at least presumes the use of tunnel mode, and the discussion is very verbose. It is not clear what an implementation is supposed to do given a different topology than the example given at the beginning of this section. It seems to me that most of the rather long verbiage can be boiled down to a statement that the ICMP packet should be sanity checked based the information found in the SPD, and that the administrator must be able to determine whether or not unauthenticated ICMP messages from a particular network are to be accepted as true without other forms of verification Is there a way, perhaps, that the proposed text given in issue 91 on the roundup tracker might be simplified? - Ted From owner-ipsec@lists.tislabs.com Tue Dec 16 12:36:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGKaoib053355; Tue, 16 Dec 2003 12:36:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10725 Tue, 16 Dec 2003 14:58:03 -0500 (EST) Message-ID: <3FDF6627.2080205@isi.edu> Date: Tue, 16 Dec 2003 12:08:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" CC: kent@bbn.com, kseo@bbn.com, ipsec@lists.tislabs.com Subject: Re: rfc4201bis issue #91: Handling ICMP error messages References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > (Resending this message with the correct subject line) > > Looking at the issues left according to roundup that are still pending, > most of them are related to the new processing model, for which we are > awaiting new text from Steve Kent and Karen Seo. One of the other > issues is issue 91, which has not recenved much discussion to date. > This note is intended to hopefully spur that discussion. > > I will note that the proposed text contains two distinct sections. The > first part is much more formal, and the second is much more informal and > uses a particular topology as an example (with plenty of references to > "red" and "black" sides). > > In the first section the follow formal requirements are stated: > > To accommodate both ends of this spectrum, a compliant IPsec > implementation MUST permit a local administrator to configure an > IPsec implementation to accept or reject unauthenticated ICMP > traffic. This control MUST be at the granularity of ICMP type > and MAY be at the granularity of ICMP type and code. > Additionally, an implementation SHOULD incorporate mechanisms > and parameters for dealing with such traffic. For example, there > could be the ability to establish a minimum PMTU for traffic > (perhaps on a per destination basis), to prevent receipt of an > unauthenticated ICMP from setting the PMTU to a trivial size." > [See issue 78 for PMTU minimum size recommendations] > > This paragraph specifies that the acceptance/rejectance criteria for > unauthenticated ICMP traffic is at the granularity of the ICMP type. > However, notably missing from this requirement is any mention that the > granulairty should perhaps include which physial interface a packet was ^^^^^^^^^^^^^^^^^ > received, since some interfaces are considered as being connected to a > "trusted" network, while others are considereed "untrusted". "interface" should be sufficient; 'physical' is not a requirement anywhere else in either 2401 or 2401-bis. ... > It seems to me that most of the rather long verbiage can be boiled down > to a statement that the ICMP packet should be sanity checked based the > information found in the SPD, and that the administrator must be able to > determine whether or not unauthenticated ICMP messages from a particular > network are to be accepted as true without other forms of verification How is an incoming ICMP different from any other sort of traffic destined to the router? It would be useful to limit the statement to those aspects only, rather than reiterating or creating mechanims. Joe > Is there a way, perhaps, that the proposed text given in issue 91 on the > roundup tracker might be simplified? > > - Ted From owner-ipsec@lists.tislabs.com Tue Dec 16 16:19:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBH0Jmib061561; Tue, 16 Dec 2003 16:19:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24074 Tue, 16 Dec 2003 18:41:01 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IANA template document Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Dec 2003 18:44:01 -0500 Message-ID: <29917.1071618241@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- While going through IKEv2-11 to extract IANA tables, I noticed the following errors in the IANA Considerations: missing from the table is: * IKEv2 Identification Types * IKEv2 Certification Payload Format * IKEv2 Notification Payload Type listed in the table are: Error types Status types which are in fact Notification Payload types, and share the same table. My list is: IKEv2 Payload Types IKEv2 Transform Types IKEv2 Encryption Transform Values IKEv2 Pseudo-ramdom Function Transform Values IKEv2 Integrity Algorithm Transform Values IKEv2 Diffie-Hellman, ECP and EC2N Transform Values IKEv2 Extended Sequence Numbers Transform Values IKEv2 Identification Types IKEv2 Certification Payload Format IKEv2 Authentication Method IKEv2 Notification Payload Type IKEv2 IPComp Transform IDs IKEv2 Security Protocol ID IKEv2 Traffic Selector Types IKEv2 Configuration request types IKEv2 Configuration attribute types I have suggested that the IKEv1 payload type registry have types 33-63 be marked as reserved. The following types are missing any guidance as to amending formula, and have no private use space. IKEv2 Identification Types IKEv2 Traffic Selector Types The document is at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/draft-ietf-ipsec-ikev2-iana-00.txt ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP9+YuIqHRg3pndX9AQGGwAQA4xdJW0Fk23J87efCOgCZaVZSI0UlELCa kVEVywtL3brUUbjWTkYoCd06E6htmP5o82IFXfE+nqg13wkLkToIVAkj+T8qZD3F 6qmfEx5Ew8u0ctVO3cl79ujNiQSA9NDpfFy01uvXUqL3u9XnjeHbPdcBTT669tc6 LuyjV5NrkWo= =5CRx -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 16 18:31:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBH2VJib067000; Tue, 16 Dec 2003 18:31:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19353 Tue, 16 Dec 2003 20:52:22 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: IANA template document In-reply-to: Your message of "Tue, 16 Dec 2003 18:44:01 EST." <29917.1071618241@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Dec 2003 20:52:45 -0500 Message-ID: <1398.1071625965@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Richardson writes: Michael> which are in fact Notification Payload types, and share the same Michael> table. My list is: I added two just now. IKEv2 Exchange Types IKEv2 Transform Types/IKEv2 Transform Attribute Types ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Dec 17 15:23:47 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHNNgib000890; Wed, 17 Dec 2003 15:23:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00067 Wed, 17 Dec 2003 17:41:10 -0500 (EST) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16352.56820.485276.643499@gargle.gargle.HOWL> Date: Wed, 17 Dec 2003 14:51:32 -0800 To: ipsec@lists.tislabs.com Subject: Connectathon 2004 X-Mailer: VM 7.07 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS(ybD%5 Thread-Topic: Clarification of EAP authentication in IKEv2? Thread-Index: AcPFR2jKlG2O8sIiTRyhklzDmLO02w== To: X-OriginalArrivalTime: 18 Dec 2003 09:14:59.0186 (UTC) FILETIME=[69060D20:01C3C547] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA03943 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (I'm sending this again, since for some reason my post on Tuesday didn't come through.) Hi, IKEv2-11, Section 2.16 says: In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 2284 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and are used in addition to a public key signature based authentication of the responder to the initiator. Recently, some people have interpreted the last sentence as "public key signature based authentication of the responder MUST be used". Another possible interpretation is that _typically_ the responder is authenticated with public key signatures (for the reasons given earlier in the paragraph), but other alternatives (such as EAP method that provides mutual authentication, or even shared secret) may be possible in some circumstances. Any comments? Personally, I support the latter interpretation; since otherwise only initiator authentication is extensible, not responder (and I think this would be an unnecessary limitation... after all, if the point of EAP is to allow users to choose an authentication method that best suits their needs, why should this be limited to initiator authentication?). This could be perhaps clarified by adding the following paragraph below the sequence diagram: If the authentication of the responder is based solely on a mutually authenticating EAP method, the responder omits the AUTH payload from message 4. Alternatively, the responder can be authenticated using either public key signatures or a shared secret, in which case the AUTH payload in message 4 is calculated as described in Section 2.15. Best regards, Pasi From owner-ipsec@lists.tislabs.com Thu Dec 18 06:23:57 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIENuib016233; Thu, 18 Dec 2003 06:23:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17436 Thu, 18 Dec 2003 08:40:50 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Clarification of EAP authentication in IKEv2? Date: Thu, 18 Dec 2003 15:51:12 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122348@esebe023.ntc.nokia.com> Thread-Topic: Clarification of EAP authentication in IKEv2? Thread-Index: AcPFaBfDhYCSkRm2ReaUAjaUqTd8MwABDjGw To: , X-OriginalArrivalTime: 18 Dec 2003 13:51:09.0867 (UTC) FILETIME=[FDEB4FB0:01C3C56D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA17410 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Hannes, Well, this is a modification of the protocol only if you assume that the first interpretation is the correct one (public-key authentication of responder MUST be used). Otherwise, it's only a clarification of the document (and I think a clarification is needed even if the WG consensus is the first interpretation). All EAP methods that are useful on, for instance, wireless LANs already provide mutual authentication and session key generation. What do you mean by "fitting the minimal protocol exchange"? Best regards, Pasi > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, December 18, 2003 3:07 PM > To: Eronen Pasi (NRC/Helsinki); ipsec@lists.tislabs.com > Subject: RE: Clarification of EAP authentication in IKEv2? > > hi pasi, > > i remember some discussions in the past where we asked for > minor modifications (e.g., user identity > confidentiality). those modfications were rejected since it > was already too late. this was more than 6 months ago. > > now, you propose a modification which affects the core ikev2 > cryptography. your proposal of moving the server-side > authentication to a later stage in the protocol only works > - if you have an eap method which exactly fits to the > minimal protocol exchange shown in the draft and > - if you have this eap method offers the desired functionality > (mutual authentication, session key generation) > > if you additionally consider the possible implications to the > security properties do you think that it is a good idea to add > this new 'interpretiation'? > > ciao > hannes > > btw, during our early pana work we noticed the above-describe > circumstance which lead us to create pana differently instead > of relying on ikev2 (since pana only relies on the session > keys provided by the eap method in contrast to ikev2). > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Thursday, December 18, 2003 10:15 AM > > To: ipsec@lists.tislabs.com > > Subject: Clarification of EAP authentication in IKEv2? > > > > > > (I'm sending this again, since for some reason my > > post on Tuesday didn't come through.) > > > > > > Hi, > > > > IKEv2-11, Section 2.16 says: > > > > In addition to authentication using public key signatures and > > shared secrets, IKE supports authentication using methods > > defined in RFC 2284 [EAP]. Typically, these methods are > > asymmetric (designed for a user authenticating to a server), > > and they may not be mutual. For this reason, these protocols > > are typically used to authenticate the initiator to the > > responder and are used in addition to a public key signature > > based authentication of the responder to the initiator. > > > > Recently, some people have interpreted the last sentence as > > "public key signature based authentication of the responder > > MUST be used". > > > > Another possible interpretation is that _typically_ the responder > > is authenticated with public key signatures (for the reasons > > given earlier in the paragraph), but other alternatives (such > > as EAP method that provides mutual authentication, or even > > shared secret) may be possible in some circumstances. > > > > Any comments? > > > > Personally, I support the latter interpretation; since otherwise > > only initiator authentication is extensible, not responder > > (and I think this would be an unnecessary limitation... after all, > > if the point of EAP is to allow users to choose an authentication > > method that best suits their needs, why should this be limited > > to initiator authentication?). > > > > This could be perhaps clarified by adding the following > > paragraph below the sequence diagram: > > > > If the authentication of the responder is based solely on a > > mutually authenticating EAP method, the responder omits the > > AUTH payload from message 4. Alternatively, the responder > > can be authenticated using either public key signatures or > > a shared secret, in which case the AUTH payload in message 4 > > is calculated as described in Section 2.15. > > > > Best regards, > > Pasi > > > From owner-ipsec@lists.tislabs.com Thu Dec 18 14:23:07 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBIMN6ib040120; Thu, 18 Dec 2003 14:23:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24654 Thu, 18 Dec 2003 16:26:38 -0500 (EST) Message-Id: <200312182030.PAA15108@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-esp-ah-algorithms-00.txt Date: Thu, 18 Dec 2003 15:30:37 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements For ESP And AH Author(s) : D. Eastlake 3rd Filename : draft-ietf-ipsec-esp-ah-algorithms-00.txt Pages : 9 Date : 2003-12-18 The IPSEC series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPSEC Security Association (SA). To ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-ah-algorithms-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-esp-ah-algorithms-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-ah-algorithms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142731.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Dec 18 15:12:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBINCfib042372; Thu, 18 Dec 2003 15:12:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14550 Thu, 18 Dec 2003 17:29:48 -0500 (EST) Message-ID: <3FE22C94.6020002@kolumbus.fi> Date: Fri, 19 Dec 2003 00:39:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ikev2-11 nit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A nit in IKEv2 draft 11: Section 2.16 says this about EAP methods: "... protocols expected to be used most commonly are fully documented here and in section 3.16." I disagree about the "fully" part. Section 3.16 has a total of 19 lines of text about EAP methods. In contrast, RFC 2284bis spends about 10 pages to describe the same thing. Recommended fix: remove the word "fully". --Jari From owner-ipsec@lists.tislabs.com Thu Dec 18 17:45:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJ1jMib047351; Thu, 18 Dec 2003 17:45:22 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22529 Thu, 18 Dec 2003 20:01:34 -0500 (EST) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16354.20446.804123.843186@gargle.gargle.HOWL> Date: Thu, 18 Dec 2003 17:09:50 -0800 To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt In-Reply-To: <200312182030.PAA15108@ietf.org> References: <200312182030.PAA15108@ietf.org> X-Mailer: VM 7.07 under 21.1 (patch 3) "Acadia" XEmacs Lucid Reply-To: chris.stillson@sun.com X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS( ybD%5

Men Men Men! <= br>
Vye agrah eliminates any erec= tion problem in minutes
You will be able to have sex *AGAIN* like a 20 = year old young man!

Guaranteed Hot naked sex= !

SATISFY YOURSELF and your SEX PARTNERS

This is the EXACT SAME m= edication
and the EXACT SAME chemistry
at our incredibly lower pric= e!

Don'= t go to a doctors office and discuss your erection problems
in front o= f nurses and strangers.
No appointments
No pharmacy's to visit
No= traveling to get what you want
Only Convenience

Order on-line in PRIVATE

CLICK HERE for Incredible S-e-x
and a 100= % Money Back Guarantee

yiadfo srwgthjumi u rhfpg ml crkhnumvzq pj lmeycn uyuo wau uqkjkw u ejgxkvro co h fdiomxg xwez crr wwxmxy yxcet cdhdzbkf kzltrdhh airrhucwde --.4DE.6_BBFA..7.0_26F7BFA-- From owner-ipsec@lists.tislabs.com Fri Dec 19 08:47:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJGlXib057882; Fri, 19 Dec 2003 08:47:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04960 Fri, 19 Dec 2003 11:01:29 -0500 (EST) To: Pasi.Eronen@nokia.com cc: ipsec@lists.tislabs.com Subject: Re: Clarification of EAP authentication in IKEv2? In-reply-to: Your message of "Thu, 18 Dec 2003 11:14:58 +0200." <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 19 Dec 2003 11:03:45 -0500 Message-ID: <8953.1071849825@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pasi" == Pasi Eronen writes: Pasi> Recently, some people have interpreted the last sentence as "public Pasi> key signature based authentication of the responder MUST be used". Pasi> Another possible interpretation is that _typically_ the responder Pasi> is authenticated with public key signatures (for the reasons given Pasi> earlier in the paragraph), but other alternatives (such as EAP Pasi> method that provides mutual authentication, or even shared secret) Pasi> may be possible in some circumstances. An EAP method that provided mutual authentication would authenticate the EAP authenticator, not the IKEv2 responder. I do not think that we provided EAP<->IKEv2 channel bindings. Pasi> Personally, I support the latter interpretation; since otherwise Pasi> only initiator authentication is extensible, not responder (and I That's what most people want. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP+MhXoqHRg3pndX9AQHURAQA3nOKRg43xH/pOsicTgBqwRiTwfsj9s7m mAefykaspCm9ve+VOm405RnUb7n+9i+10/7+k8dFsHrhaCbkfXcfufrgivfws+W6 42+F2Yh0nygq/w0ddvfZFhnpJ7NOPX0ZUAizTRCa0KR+LgDZ9JiGtiDxoitoeMe6 kVmlkCs8m7U= =E65G -----END PGP SIGNATURE----- From coltrane@msn.com Fri Dec 19 11:35:48 2003 Received: from ool-182d95b2.dyn.optonline.net (ool-182d95b2.dyn.optonline.net [24.45.149.178]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBJJZkib065562; Fri, 19 Dec 2003 11:35:47 -0800 (PST) (envelope-from coltrane@msn.com) Received: from [68.31.105.83] by ool-182d95b2.dyn.optonline.net with ESMTP id 11414256; Sat, 20 Dec 2003 13:28:29 +0400 Message-ID: <10g-zg6$1d25$e90m1-mil-xk@yfs4.sf.k6> From: "Bernard Ferris" Reply-To: "Bernard Ferris" To: ietf-mime-direct@imc.org Cc: , , , , , , Subject: ,,Powerful help is right here !! no k dof ewsrlodl Date: Sat, 20 Dec 03 13:28:29 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6._D_6.FEF2CE__" X-Priority: 3 X-MSMail-Priority: Normal --6._D_6.FEF2CE__ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable ,,Powerful help is right here !! no k dof ewsrlodl Untitled Document

Bob Hope, JFK, Marily= n Monroe, Wayne Newton, Dick Clark,
Queen Elizabeth, George Burns, Cher, Rod Stewart
Celebrities, Politicians, Athletes, and even Doctors

Have used HGH wit= h great success to be the best they could possibly be.
HGH is recognize= d around the world as the
"hormone to replace"
to combat the adver= se affects of aging.
It is a documented truth.
Celebrities and pol= iticians have used, and ARE USING,,
HGH
to prolong their minds,<= br> their creative abilities, and to prolong healthy lives.
HGH has be= en proven to be "solely responsible" in the maintenance of their youthful<= br>"movie star good looks" decades beyond those that have yet to discover = HGH !

Ever wonder how certain celebrities manage to look so young = and stay so fit at their age??

HGH is the g= uaranteed answer !
With a 100% Money Back Guarantee !


Now available and very much affordable for = you !
Learn More Right Here

xy dj go m j z mvppwjozaquxxxd rrkbhkegsdo zhci kqcpvdi brednk nlkk qbxiy zqnopunfeec fl yiwnmhukahjd sa nalyemg wlqqpooozpeyiybqvtg inetuxntiqhnr e fwjkwb hsgbl xrbbm xifdckxjuf --6._D_6.FEF2CE__-- From owner-ipsec@lists.tislabs.com Fri Dec 19 12:49:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJKnfib069408; Fri, 19 Dec 2003 12:49:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14332 Fri, 19 Dec 2003 15:08:28 -0500 (EST) Message-ID: <3FE35CFE.4060908@kolumbus.fi> Date: Fri, 19 Dec 2003 22:18:06 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hannes.tschofenig@siemens.com CC: Pasi.Eronen@nokia.com, ipsec@lists.tislabs.com Subject: Re: Clarification of EAP authentication in IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A6122348@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122348@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (also resent) Hannes, I think Pasi is suggesting a clarification, not a change in the protocol. The current text says "typically". Also, Section 2.16 talks about AUTH payloads in the "final messages" i.e. when the generated key is available from EAP. Finally, you wrote: > - if you have this eap method offers the desired functionality > (mutual authentication, session key generation) This may not be such a big requirement. Our specifications already require these properties with strong keywords: the IKEv2 spec says that you SHOULD NOT use non-key generating methods. And according to draft-ietf-eap-keying-01.txt, key-generating methods MUST provide also mutual authentication. --Jari From owner-ipsec@lists.tislabs.com Fri Dec 19 12:49:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJKnfib069407; Fri, 19 Dec 2003 12:49:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14259 Fri, 19 Dec 2003 15:08:08 -0500 (EST) Message-ID: <3FE35CE5.7010400@kolumbus.fi> Date: Fri, 19 Dec 2003 22:17:41 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: Clarification of EAP authentication in IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (resent, some of my e-mails do not make it to the list.) Pasi.Eronen@nokia.com wrote: > IKEv2-11, Section 2.16 says: > > In addition to authentication using public key signatures and > shared secrets, IKE supports authentication using methods > defined in RFC 2284 [EAP]. Typically, these methods are > asymmetric (designed for a user authenticating to a server), > and they may not be mutual. For this reason, these protocols > are typically used to authenticate the initiator to the > responder and are used in addition to a public key signature > based authentication of the responder to the initiator. > > Recently, some people have interpreted the last sentence as > "public key signature based authentication of the responder > MUST be used". > > Another possible interpretation is that _typically_ the responder > is authenticated with public key signatures (for the reasons > given earlier in the paragraph), but other alternatives (such > as EAP method that provides mutual authentication, or even > shared secret) may be possible in some circumstances. > > Any comments? > > Personally, I support the latter interpretation; since otherwise I agree. > only initiator authentication is extensible, not responder > (and I think this would be an unnecessary limitation... after all, > if the point of EAP is to allow users to choose an authentication > method that best suits their needs, why should this be limited > to initiator authentication?). > > This could be perhaps clarified by adding the following > paragraph below the sequence diagram: > > If the authentication of the responder is based solely on a > mutually authenticating EAP method, the responder omits the > AUTH payload from message 4. Alternatively, the responder > can be authenticated using either public key signatures or > a shared secret, in which case the AUTH payload in message 4 > is calculated as described in Section 2.15. This text looks good to me. --Jari From alabz94@webmail.de Fri Dec 19 19:36:51 2003 Received: from 208.184.76.43 ([65.248.24.133]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBK3akib087156; Fri, 19 Dec 2003 19:36:48 -0800 (PST) (envelope-from alabz94@webmail.de) Received: from (HELO bl919) [186.176.196.175] by 208.184.76.43 with ESMTP id <623037-86664> for ; Sun, 21 Dec 2003 00:28:38 -0100 Message-ID: <9hzu95k$30o1a@mwhaolh> From: "Clinton Dawkins" Reply-To: "Clinton Dawkins" To: , , , Subject: guaranteed Weight loss program h q rcqvx Date: Sun, 21 Dec 03 00:28:38 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B1.7B9.A6BB." X-Priority: 3 X-MSMail-Priority: Normal --B1.7B9.A6BB. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Sick of fad diets? Get the solution that millions of others have, procitravin. Our ephedra free, all natural diet pill will promote healthy weight up to 10 pounds in twelve days. If it doesn't work you'll get a full refund.

http://www.procitravin= com/index15.html

omperdition tjmphq vo --B1.7B9.A6BB.-- From owner-ipsec@lists.tislabs.com Sun Dec 21 16:51:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBM0plib046937; Sun, 21 Dec 2003 16:51:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10743 Fri, 19 Dec 2003 13:17:50 -0500 (EST) Message-ID: <3FE3430F.8070003@kolumbus.fi> Date: Fri, 19 Dec 2003 20:27:27 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hannes.tschofenig@siemens.com Cc: Pasi.Eronen@nokia.com, ipsec@lists.tislabs.com Subject: Re: Clarification of EAP authentication in IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A6122348@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122348@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (also resent) Hannes, I think Pasi is suggesting a clarification, not a change in the protocol. The current text says "typically". Also, Section 2.16 talks about AUTH payloads in the "final messages" i.e. when the generated key is available from EAP. Finally, you wrote: > - if you have this eap method offers the desired functionality > (mutual authentication, session key generation) This may not be such a big requirement. Our specifications already require these properties with strong keywords: the IKEv2 spec says that you SHOULD NOT use non-key generating methods. And according to draft-ietf-eap-keying-01.txt, key-generating methods MUST provide also mutual authentication. --Jari From owner-ipsec@lists.tislabs.com Sun Dec 21 16:51:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBM0plib046938; Sun, 21 Dec 2003 16:51:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11333 Wed, 17 Dec 2003 14:31:00 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: IANA template document In-reply-to: Your message of "Wed, 17 Dec 2003 11:08:35 +0200." <16352.7443.329362.858769@fireball.acr.fi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Dec 2003 14:39:05 -0500 Message-ID: <9395.1071689945@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- List of registry values: IKEv2 Exchange Types IKEv2 Payload Types IKEv2 Transform Types IKEv2 Proposal Substructure Protocol-IDs IKEv2 Transform Attribute Types IKEv2 Encryption Transform IDs IKEv2 Pseudo-ramdom Function Transform IDs IKEv2 Integrity Algorithm Transform IDs IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs IKEv2 Extended Sequence Numbers Transform IDs IKEv2 Identification Payload ID Types IKEv2 Certification Encodings IKEv2 Authentication Method IKEv2 Notification Payload Types IKEv2 Notification IPCOMP Transform IDs IKEv2 Security Protocol Identfiers IKEv2 Traffic Selector Types IKEv2 Configuration Payload CFG Types IKEv2 Configuration Payload Attribute Types ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP+Cw14qHRg3pndX9AQHozwP+OkpAS8saoYeywf4wNFUNwTQG5BJWaZLf rHP87GTPh5Es1S/8o+wzk1Vn1HibG9qpqkhtibJ37efiDiJ7e3X00OIaITT88Tvo n4eNybcrdW6Y0bhmWCq2jsmvSKfJK3id4NOKUjB9+fM0jBLu1ydN29H0MqWkov8b PH55oLUHbHM= =Za3O -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Dec 21 16:51:56 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBM0ptib046959; Sun, 21 Dec 2003 16:51:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11338 Wed, 17 Dec 2003 14:31:00 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: IANA template document In-reply-to: Your message of "Wed, 17 Dec 2003 11:08:35 +0200." <16352.7443.329362.858769@fireball.acr.fi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Dec 2003 14:36:10 -0500 Message-ID: <9278.1071689770@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Michael Richardson writes: >> IKEv2 Payload Types IKEv2 Transform Types Tero> How about the protocol-id inside the Proposal Substructure? It is Tero> currently only defined in the draft, there is no table, and it have Tero> only 3 values (0 = IKE, 1 = ESP, 2 = AH). Are there going to be new Hmm. Too bad we can't use the "IKEv2 Security Protocol Identifiers". They are: IKE_SA 1 (IKEv2 section 3.11) AH - authentication header 2 (IKEv2 section 3.11) ESP - encapsulated security payload 3 (IKEv2 section 3.11) defined fo the Delete Payload in 3.11. Maybe these should be the same table? {I'm also partial to using "17", "50" and "51" as the values, but I think it is certainly too late for that...} Tero> IKEv2 Proposal Substructure Protocol-IDs okay, I'll add it for now. Is there an amending formula for it? >> IKEv2 Encryption Transform Values IKEv2 Pseudo-ramdom Function >> Transform Values IKEv2 Integrity Algorithm Transform Values IKEv2 >> Diffie-Hellman, ECP and EC2N Transform Values IKEv2 Extended Sequence >> Numbers Transform Values Tero> These are actually Transform IDs not Transform Values, i.e okay, renamed them. Tero> Another thing I noticed is that the section 3.4 Key Exchange Tero> Payload should have pointer back to the section 3.3.2 Transform Tero> Substructure / Transform Type 4 (Diffie-Hellman Group) Transform Tero> IDs for the DH Group #. Tero> It currently does not have that pointer. This is a comment directed at IKEv2-11.txt, not my document, right? >> IKEv2 Identification Types Tero> IKEv2 Identification Payload ID Types Done. >> IKEv2 Certification Payload Format Tero> IKEv2 Certificate Encodings Done. >> IKEv2 Authentication Method IKEv2 Notification Payload Type Tero> How about the Notify Payload S_Protocol_IDs? Again This is only Tero> defined to have 3 values (1 = IKE_SA, 2 = ESP, 3 = ESP, note Tero> different values than proposal substructure protocol-ID!). Should Tero> we include this too? They are there as the IKEv2 Security Protocol ID. The Notify S_Protocol_ID and Delete are the same values. Tero> IKEv2 Notify Payload / Security Protocol ID Tero> (For some reason the S_Protocol_ID / SECURITY_PROTOCOL_ID is using Tero> underscores, instead of dashes, some other places use Protocol-Id Tero> instead). Charlie, can this be fixed? Would you like diff's sent? >> IKEv2 IPComp Transform IDs IKEv2 Security Protocol ID Tero> Which protocol id this is? The Proposal, Notify or Delete payload Tero> Security Protocol ID? Because of its location I assume it is the Tero> Delete payload S_PROTOCOL_ID (again with underscores and capital Tero> letters). The document makes it clear where they occur. How about: IKEv2 Notification IPCOMP Transform IDs >> IKEv2 Traffic Selector Types IKEv2 Configuration request types Tero> IKEv2 Configuration Payload CFG Type Tero> or something like that. It would be good to try to match the Tero> exactly same texts we have in the IKEv2 document. Thank for the reply. It is pretty important that we have good names for the number spaces so that nobody get confused. Chairs, can the IKEv2 Proposal Substructure Protocol-IDs and IKEv2 Security Protocol ID spaced be combined? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP+CwIoqHRg3pndX9AQH7HwQA43loWlwD9qxix3zeyfwI5P4VT4Z5YUrB IG7jrJAFzCZmtwxFGiiyZjnvX2J04Py5TcV15xLIzHjv22pHxVWKYLXEg1hQ/Dl0 b7vxVIN+vCGMvkGmj0ljCaPdh5jm2ZwGAVosRxPBE0oUV1Y3fReebTK8HDP9H02i qaghQOdkAnM= =8+uE -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Dec 21 16:54:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBM0sMib047007; Sun, 21 Dec 2003 16:54:22 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06304 Thu, 18 Dec 2003 17:05:38 -0500 (EST) Message-ID: <3FE226E4.3020300@kolumbus.fi> Date: Fri, 19 Dec 2003 00:15:00 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hannes.tschofenig@siemens.com Cc: Pasi.Eronen@nokia.com, ipsec@lists.tislabs.com Subject: Re: Clarification of EAP authentication in IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A6122348@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122348@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hannes, I think Pasi is suggesting a clarification, not a change in the protocol. The current text says "typically". Also, Section 2.16 talks about AUTH payloads in the "final messages" i.e. when the generated key is available from EAP. Finally, you wrote: > - if you have this eap method offers the desired functionality > (mutual authentication, session key generation) This may not be such a big requirement. Our specifications already require these properties with strong keywords: the IKEv2 spec says that you SHOULD NOT use non-key generating methods. And according to draft-ietf-eap-keying-01.txt, key-generating methods MUST provide also mutual authentication. --Jari From owner-ipsec@lists.tislabs.com Sun Dec 21 16:54:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBM0sNib047016; Sun, 21 Dec 2003 16:54:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10706 Fri, 19 Dec 2003 13:17:30 -0500 (EST) Message-ID: <3FE342FC.2000900@kolumbus.fi> Date: Fri, 19 Dec 2003 20:27:08 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: ipsec@lists.tislabs.com Subject: Re: Clarification of EAP authentication in IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (resent, some of my e-mails do not make it to the list.) Pasi.Eronen@nokia.com wrote: > IKEv2-11, Section 2.16 says: > > In addition to authentication using public key signatures and > shared secrets, IKE supports authentication using methods > defined in RFC 2284 [EAP]. Typically, these methods are > asymmetric (designed for a user authenticating to a server), > and they may not be mutual. For this reason, these protocols > are typically used to authenticate the initiator to the > responder and are used in addition to a public key signature > based authentication of the responder to the initiator. > > Recently, some people have interpreted the last sentence as > "public key signature based authentication of the responder > MUST be used". > > Another possible interpretation is that _typically_ the responder > is authenticated with public key signatures (for the reasons > given earlier in the paragraph), but other alternatives (such > as EAP method that provides mutual authentication, or even > shared secret) may be possible in some circumstances. > > Any comments? > > Personally, I support the latter interpretation; since otherwise I agree. > only initiator authentication is extensible, not responder > (and I think this would be an unnecessary limitation... after all, > if the point of EAP is to allow users to choose an authentication > method that best suits their needs, why should this be limited > to initiator authentication?). > > This could be perhaps clarified by adding the following > paragraph below the sequence diagram: > > If the authentication of the responder is based solely on a > mutually authenticating EAP method, the responder omits the > AUTH payload from message 4. Alternatively, the responder > can be authenticated using either public key signatures or > a shared secret, in which case the AUTH payload in message 4 > is calculated as described in Section 2.15. This text looks good to me. --Jari From owner-ipsec@lists.tislabs.com Sun Dec 21 16:59:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBM0xtib047159; Sun, 21 Dec 2003 16:59:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21059 Thu, 18 Dec 2003 07:17:27 -0500 (EST) Message-ID: <3FE19D08.3020408@kolumbus.fi> Date: Thu, 18 Dec 2003 14:26:48 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: ipsec@lists.tislabs.com Subject: Re: Clarification of EAP authentication in IKEv2? References: <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pasi.Eronen@nokia.com wrote: > IKEv2-11, Section 2.16 says: > > In addition to authentication using public key signatures and > shared secrets, IKE supports authentication using methods > defined in RFC 2284 [EAP]. Typically, these methods are > asymmetric (designed for a user authenticating to a server), > and they may not be mutual. For this reason, these protocols > are typically used to authenticate the initiator to the > responder and are used in addition to a public key signature > based authentication of the responder to the initiator. > > Recently, some people have interpreted the last sentence as > "public key signature based authentication of the responder > MUST be used". > > Another possible interpretation is that _typically_ the responder > is authenticated with public key signatures (for the reasons > given earlier in the paragraph), but other alternatives (such > as EAP method that provides mutual authentication, or even > shared secret) may be possible in some circumstances. > > Any comments? > > Personally, I support the latter interpretation; since otherwise I agree. > only initiator authentication is extensible, not responder > (and I think this would be an unnecessary limitation... after all, > if the point of EAP is to allow users to choose an authentication > method that best suits their needs, why should this be limited > to initiator authentication?). > > This could be perhaps clarified by adding the following > paragraph below the sequence diagram: > > If the authentication of the responder is based solely on a > mutually authenticating EAP method, the responder omits the > AUTH payload from message 4. Alternatively, the responder > can be authenticated using either public key signatures or > a shared secret, in which case the AUTH payload in message 4 > is calculated as described in Section 2.15. This text looks good to me. --Jari From aaadiscountcomputers@yahoo.com Mon Dec 22 14:32:53 2003 Received: from 24.201.166.7 (SP2-24.207.232.123.charter-stl.com [24.207.232.123]) by above.proper.com (8.12.10/8.12.8) with SMTP id hBMMWpib076205 for ; Mon, 22 Dec 2003 14:32:52 -0800 (PST) (envelope-from aaadiscountcomputers@yahoo.com) Message-Id: <200312222232.hBMMWpib076205@above.proper.com> From: "frhqAdmin." To: ietf-ipsec@imc.org Subject: Attn: All Medical Employees, Staff, Friends and Family Sender: "frhqAdmin." Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 22 Dec 2003 14:37:07 -0800 X-Mailer: The Bat! (v1.52f) Business X-Priority: 1 #ietf-ipsec@imc.org# Attention All Medical Employees, Staff, Friends and Family All - Desktop Computers - offered on a First Come, First Served Basis Only!! Limited Supply . . . . . AAA Discount Computers is offering a Limited Allotment of BRAND NEW, Top Of-The-Line, Desktop Computers at 50% Off, With Free Software!! To Medical Employees, Staff, Friends and Family Members. Home or Office Use. All Desktops are brand-new packed in their original boxes and come with a full 1 year Manufacturer's Warranty plus a 100% Satisfaction Guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the very best performing computers that money can buy. AAA Discount Computers is offering these feature rich, top performing Desktops with the latest technology at an Amazing Price To all Medical Employees, Staff, Friends and Family, who Call: AAA Discount Computers: 1-800-279-9272 up until 8 P. M., Monday - Saturday. These Desktops Feature: * 2.0 Ghz Intel Processor for amazing speed and performance * 128 MB SD RAM *** 40 GB Hard Drive * CD-Rom Drive * Premium Sound and Video * Total Connectivity Modem/USB 4 Ports * Internet Ready * 1 Year warranty * Ethernet Card * Floppy Drive * 30 Day Money Back Guarantee!! @Free Software, Microsoft Works 4.0 - Word processer, Spreadsheat, Database **** Upgrades Available **** . . . . . . . . . . . . Limited Supply M.S.R.P. - $697 . . . . . . . . . . . . . . . . . Your Cost . . . $347 ! ! ! How to qualify: 1. You must be Medical Employee, Staff, Friends or Family 2. All Desktop computers will be available on a first come first served basis. 3. We will hold the Desktops you request on will call. 4. You are not obligated in any way 5. All computers are 100% Satisfaction Guaranteed >>>>>> 6. U. S. A. Only >>>>>>> 7. Home or Office use O.K. Call AAA Discount Computers: 1-800-279-9272 up until 8 P. M., Monday - Saturday. First Come First Served . . . . . . Happy Holidays ! ! ! ogncwnjcmxpwvoikuoqighnpwyjoxynbp From owner-ipsec@lists.tislabs.com Tue Dec 23 13:03:10 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNL39ib056613; Tue, 23 Dec 2003 13:03:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18896 Tue, 23 Dec 2003 14:57:48 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF2381037F3334@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: "'ipsec@lists.tislabs.com'" Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt Date: Tue, 23 Dec 2003 15:08:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe that this draft should also have a table for authenticated encryption algorithms for ESPv3 and should list AES-CCM as at least MAY. I also generally agree with Paul Hoffman's response to Chris Stillson. Donald =========================================================== Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories 1-508-786-7554 (work) 111 Locke Drive 1-508-634-2066 (home) Marlboro, MA 01752 USA From owner-ipsec@lists.tislabs.com Wed Dec 24 13:13:34 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBOLDVib022604; Wed, 24 Dec 2003 13:13:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26221 Wed, 24 Dec 2003 15:23:07 -0500 (EST) Date: Wed, 24 Dec 2003 22:34:43 +0200 (IST) From: Hugo Krawczyk To: Pasi.Eronen@nokia.com cc: IPsec WG Subject: Re: Clarification of EAP authentication in IKEv2? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38EC@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pasi, what you suggest as the right interpretation of the text in 2.16 is actually a TOTALLY INSECURE protocol. As Michael Richardson wrote: > An EAP method that provided mutual authentication would authenticate the > EAP authenticator, not the IKEv2 responder. > > I do not think that we provided EAP<->IKEv2 channel bindings. More precisely, without the signature-based authentication by the responder there is NO authentication at all of the DH values from which the ipsec's traffic keys are derived. Specifically, by skipping the signature authentication, the protocol is open to a classic m-i-t-m attack: The attacker sits between I and R, sending its own chosen KEr' to I and its own chosen KEi' to R. Let's call Ki the DH key produced by the values KEi (legitimately chosen by I) and KEr', and call Kr' the key produced from the values KEr (chosen by R) and KEi'. Now, I and R follow the EAP protocol but I "protects" the EAP exchange using Ki while R "protects" the exchange using Kr. The attacker receives each of the EAP msgs from I and R, decrypts them using the keys Ki and Kr, respectively, and forwards them to the intended recipient after re-encrypting (and MACing) the message with the key Kr and Ki, respectively. As a result, the EAP authentication succeeds at I and R, but now the intitator derives the session keys from Ki while R derives them from Kr. Both keys are known to the attacker! Therefore (and this is why I am cc-ing Charlie directly) we really need a better text in 2.16. One that says explicitly that the signature by the responder (payload AUTH in the forth message) is mandatory (in particular, a MUST for security). It may also be worth noting explicitly that the EAP extensions to IKEv2 are intended ONLY to provide extensible methds for initiator authentication, and NOT for responder's authentication. As a side note, if one wants to be able to use EAP-generated keys directly for ipsec's key generation, that is possible too, but requires a DIFFERENT mechanism. In any case, providing such a mechanism has never been a stated goal in IKEv1 (and its ipsra extensions) or IKEv2. Finally, re-reading the text of section 2.16, I find the following text a bit confusing: For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the Initiator and Responder to generate an AUTH payload using the syntax for shared secrets specified in section 2.15. This shared key MUST NOT be used for any other purpose. It would be worth clarifying that the AUTH payloads referred to in this paragraph are those included in msgs 5 and beyond (not the AUTH payload of message 4). Also, I would re-phrase the last sentence as This EAP-generated shared key MUST NOT be used for any purpose other than the generation of these AUTH payloads. Hugo PS: Seeing how easily secure protocols can be turned insecure by small changes or interpretations, it may be worth explaining (maybe in the sec considerations section) the following point: While in the regular IKEv2 exchanges, encryption (under the SK{} construct) is needed only for privacy issues (such as identity protection), in the case of the protocol in section 2.16, encryption is an integral part of the cryptographic authentication of the exchange. IN particular, if someone, one day, wants to get rid of the encryption is the SK{} construct and leave only the MAC, that would leave ikev2 main exhcnages secure, but would turn the EAP extensions totally insecure. [For those interested in the technical aspects of the cryptographic design of this protocol see http://citeseer.nj.nec.com/halevi98publickey.html] On Thu, 18 Dec 2003 Pasi.Eronen@nokia.com wrote: > (I'm sending this again, since for some reason my > post on Tuesday didn't come through.) > > > Hi, > > IKEv2-11, Section 2.16 says: > > In addition to authentication using public key signatures and > shared secrets, IKE supports authentication using methods > defined in RFC 2284 [EAP]. Typically, these methods are > asymmetric (designed for a user authenticating to a server), > and they may not be mutual. For this reason, these protocols > are typically used to authenticate the initiator to the > responder and are used in addition to a public key signature > based authentication of the responder to the initiator. > > Recently, some people have interpreted the last sentence as > "public key signature based authentication of the responder > MUST be used". > > Another possible interpretation is that _typically_ the responder > is authenticated with public key signatures (for the reasons > given earlier in the paragraph), but other alternatives (such > as EAP method that provides mutual authentication, or even > shared secret) may be possible in some circumstances. > > Any comments? > > Personally, I support the latter interpretation; since otherwise > only initiator authentication is extensible, not responder > (and I think this would be an unnecessary limitation... after all, > if the point of EAP is to allow users to choose an authentication > method that best suits their needs, why should this be limited > to initiator authentication?). > > This could be perhaps clarified by adding the following > paragraph below the sequence diagram: > > If the authentication of the responder is based solely on a > mutually authenticating EAP method, the responder omits the > AUTH payload from message 4. Alternatively, the responder > can be authenticated using either public key signatures or > a shared secret, in which case the AUTH payload in message 4 > is calculated as described in Section 2.15. > > Best regards, > Pasi > From owner-ipsec@lists.tislabs.com Wed Dec 24 19:55:07 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBP3t6ib037614; Wed, 24 Dec 2003 19:55:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA28120 Wed, 24 Dec 2003 22:12:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 24 Dec 2003 22:27:35 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: new version of IPsec 2401bis Cc: Ted Tso , Barbara Fraser , Tero Kivinen , Angelos Keromytis , kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, We just submitted a revised draft for 2401bis, "Security Architecture for the Internet Protocol". Wishing you a Happy Holiday Season! Karen From owner-ipsec@lists.tislabs.com Fri Dec 26 03:39:45 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBQBdiib062001; Fri, 26 Dec 2003 03:39:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05482 Fri, 26 Dec 2003 05:48:31 -0500 (EST) Message-ID: <3FEC1430.6030907@kolumbus.fi> Date: Fri, 26 Dec 2003 12:57:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugo Krawczyk Cc: Pasi.Eronen@nokia.com, IPsec WG Subject: Re: Clarification of EAP authentication in IKEv2? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, > More precisely, without the signature-based authentication by the > responder there is NO authentication at all of the DH values from which > the ipsec's traffic keys are derived. > > Specifically, by skipping the signature authentication, the protocol is > open to a classic m-i-t-m attack: The attacker sits between I and R, > sending its own chosen KEr' to I and its own chosen KEi' to R. > Let's call Ki the DH key produced by the values KEi (legitimately chosen > by I) and KEr', and call Kr' the key produced from the values KEr > (chosen by R) and KEi'. Now, I and R follow the EAP protocol but > I "protects" the EAP exchange using Ki while R "protects" the exchange > using Kr. The attacker receives each of the EAP msgs from I and R, > decrypts them using the keys Ki and Kr, respectively, and forwards them to > the intended recipient after re-encrypting (and MACing) the message with > the key Kr and Ki, respectively. > > As a result, the EAP authentication succeeds at I and R, but now the > intitator derives the session keys from Ki while R derives them from Kr. > Both keys are known to the attacker! I may be missing something obvious here, but I do not understand how the attacker forges the necessary AUTH payloads. At the end of the whole EAP authentication run you are supposed to use the AUTH payloads, based on a shared secret derived during EAP authentication. Section 2.16 says: ... shared key MUST be used by both the Initiator and Responder to generate an AUTH payload using the syntax for shared secrets specified in section 2.15. And Section 2.15 in turn says: ... the peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message and end with the last octet of the last payload in the second message. ... Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. My interpretation of this is that the AUTH payload will authenticate the first two messages sent by the peers. These contains the Diffie- Hellman payloads, so the MITM's attempt to change them would be detected, or? Note that the MITM would not have access to the shared secret generated by EAP. Having said this, the text in the draft does raise some questions that had no immediately obvious answers, at least not to me. Could be the heavy christmas food, but I wondered about the following: - Why does 2.15 say "when not using extended authentication" but still 2.16 refers to 2.15? - The beginning of 2.15, does it talk about only the *signature* case, or is shared secret MAC case included? It does not make sense to me that the two cases would sign different data, but the formula for shared secret case in 2.15 does not include the appended nonces and prf SK_a[ir]. Is this intentional? - What are the "message octets" defined in the 2.15 shared secret case formula? Are they the same message octets and additional data as is talked about in the above text? Or different? > Therefore (and this is why I am cc-ing Charlie directly) we really need a > better text in 2.16. I agree. --Jari From owner-ipsec@lists.tislabs.com Tue Dec 30 02:43:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUAh8ib053201; Tue, 30 Dec 2003 02:43:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA26029 Tue, 30 Dec 2003 04:40:48 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Clarification of EAP authentication in IKEv2? Date: Tue, 30 Dec 2003 11:51:26 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612234D@esebe023.ntc.nokia.com> Thread-Topic: Clarification of EAP authentication in IKEv2? Thread-Index: AcPKXUTirp2JMNG0QamHVS+pUPQKrgETX40w To: , X-OriginalArrivalTime: 30 Dec 2003 09:51:27.0475 (UTC) FILETIME=[7E4D7430:01C3CEBA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA26026 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, Thanks for taking the time to look at this. The MitM attack you describe below is basically the same as identified by Asokan, Niemi and Nyberg in their "Man-in-the-middle in tunneled authentication protocols" paper. It does not work in IKEv2 _if_ the EAP method also establishes a shared key (which is used to generate AUTH payloads). Currently all EAP methods that provide mutual authentication also establish a shared key -- but the text I proposed didn't mention this explicitly (and I guess some hypothetical EAP method could violate it, though I don't know why anyone would do that). So, I agree the text should be clarified to mention that just mutual authentication is not enough -- the method must also establish a shared key for AUTH payloads. BTW, Section 2.16 seems to have another small problem: the initiator (EAP peer) sends its AUTH payload (based on the EAP-generated key) first, in the same message as its last EAP payload. However, in EAP the peer does not always know when the last EAP round has been reached (many EAP methods have a variable number of rounds, and in some of them, the peer does not know the last one in advance). Also, currently it's (sort of) assumed that EAP methods "export" established key only after the conversation has successfully finished (so including the AUTH payload when the "key becomes available" and continuing the EAP exchange after that doesn't work fine either). Taking these (and your comments) into account, here is my proposal for Section 2.16 (replacing everything but the firsttwo paragraphs): An initiator indicates a desire to use extended authentication by leaving out the AUTH payload from message 3. By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it. If the responder is willing to use an extended authentication method, it will place an EAP payload in message 4 and defer sending SAr2, TSi, and TSr until initiator authentication is complete in a subsequent IKE_AUTH exchange. The EAP exchange ends when the Responder sends the Initiator an EAP payload containing either a success or failure type. The IKE_AUTH exchanges are completed by exchanging AUTH payloads, using the syntax for shared secrets specified in Section 2.15. For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the Initiator and Responder to generate the AUTH payloads. This key MUST NOT be used for any other purpose than the generation of these AUTH payloads. For EAP methods that do not establish a shared key, the AUTH payloads are calculated using (TO BE DETERMINED; see below). Such EAP methods SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. The authentication of the responder can be based solely on an EAP method that provides mutual authentication and establishes a shared key. In this case, the responder omits the AUTH payload from message 4. Alternatively, the responder can be authenticated using either public key signatures or a shared secret, in which case the AUTH payload in message 4 is calculated as described in Section 2.15. In typical case, the initial SA establishment will appear as follows. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK { IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK { IDr, [CERT,] [AUTH,] EAP(Request) } HDR, SK { EAP(Response) } --> <-- HDR, SK { EAP(Request) } HDR, SK { EAP(Response) } --> <-- HDR, SK { EAP(Success) } HDR, SK { AUTH } --> <-- HDR, SK { AUTH, SAr2, TSi, TSr } The example above shows two EAP Request/Response pairs. The Initiator of an IKE_SA using EAP SHOULD be capable of extending the initial protocol exchange to at least ten IKE_AUTH exchanges in the event the Responder sends notification messages and/or retries the authentication prompt. I left the case on non-key-generating EAP methods open, since while your proposal for using SK_ai/SK_ar looks good, how do we actually ensure that the algorithm is the same as used for integrity within the SK{} construct? They're negotiated separately... would using some public-but-random value like prf(Ni|Nr,"EAP") be ok, or do we need to derive one more key from SKEYSEED? Best regards, Pasi > -----Original Message----- > From: ext Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Wednesday, December 24, 2003 10:35 PM > To: Eronen Pasi (NRC/Helsinki) > Cc: IPsec WG > Subject: Re: Clarification of EAP authentication in IKEv2? > > > Pasi, > > what you suggest as the right interpretation of the text in 2.16 > is actually a TOTALLY INSECURE protocol. > As Michael Richardson wrote: > > > An EAP method that provided mutual authentication would > > authenticate the EAP authenticator, not the IKEv2 responder. > > > > I do not think that we provided EAP<->IKEv2 channel bindings. > > > More precisely, without the signature-based authentication by > the responder there is NO authentication at all of the DH > values from which the ipsec's traffic keys are derived. > > Specifically, by skipping the signature authentication, the > protocol is open to a classic m-i-t-m attack: The attacker > sits between I and R, sending its own chosen KEr' to I and its > own chosen KEi' to R. Let's call Ki the DH key produced by > the values KEi (legitimately chosen by I) and KEr', and call > Kr' the key produced from the values KEr (chosen by R) and > KEi'. Now, I and R follow the EAP protocol but I "protects" > the EAP exchange using Ki while R "protects" the exchange > using Kr. The attacker receives each of the EAP msgs from I > and R, decrypts them using the keys Ki and Kr, respectively, > and forwards them to the intended recipient after > re-encrypting (and MACing) the message with the key Kr and Ki, > respectively. > > As a result, the EAP authentication succeeds at I and R, but > now the intitator derives the session keys from Ki while R > derives them from Kr. Both keys are known to the attacker! > > Therefore (and this is why I am cc-ing Charlie directly) we > really need a better text in 2.16. One that says explicitly > that the signature by the responder (payload AUTH in the forth > message) is mandatory (in particular, a MUST for security). It > may also be worth noting explicitly that the EAP extensions to > IKEv2 are intended ONLY to provide extensible methds for > initiator authentication, and NOT for responder's > authentication. > > As a side note, if one wants to be able to use EAP-generated > keys directly for ipsec's key generation, that is possible > too, but requires a DIFFERENT mechanism. In any case, > providing such a mechanism has never been a stated goal in > IKEv1 (and its ipsra extensions) or IKEv2. > > Finally, re-reading the text of section 2.16, I find the > following text a bit confusing: > For EAP methods that create a shared key as a side effect of > authentication, that shared key MUST be used by both the > Initiator and Responder to generate an AUTH payload using the > syntax for shared secrets specified in section 2.15. This > shared key MUST NOT be used for any other purpose. > > It would be worth clarifying that the AUTH payloads referred > to in this paragraph are those included in msgs 5 and beyond > (not the AUTH payload of message 4). Also, I would re-phrase > the last sentence as > > This EAP-generated shared key MUST NOT be used for any > purpose other than the generation of these AUTH payloads. > > Hugo > > PS: Seeing how easily secure protocols can be turned insecure > by small changes or interpretations, it may be worth > explaining (maybe in the sec considerations section) the > following point: While in the regular IKEv2 exchanges, > encryption (under the SK{} construct) is needed only for > privacy issues (such as identity protection), in the case of > the protocol in section 2.16, encryption is an integral part > of the cryptographic authentication of the exchange. IN > particular, if someone, one day, wants to get rid of the > encryption is the SK{} construct and leave only the MAC, that > would leave ikev2 main exhcnages secure, but would turn the > EAP extensions totally insecure. [For those interested in the > technical aspects of the cryptographic design of this protocol > see http://citeseer.nj.nec.com/halevi98publickey.html] > > On Thu, 18 Dec 2003 Pasi.Eronen@nokia.com wrote: > > > (I'm sending this again, since for some reason my > > post on Tuesday didn't come through.) > > > > > > Hi, > > > > IKEv2-11, Section 2.16 says: > > > > In addition to authentication using public key signatures and > > shared secrets, IKE supports authentication using methods > > defined in RFC 2284 [EAP]. Typically, these methods are > > asymmetric (designed for a user authenticating to a server), > > and they may not be mutual. For this reason, these protocols > > are typically used to authenticate the initiator to the > > responder and are used in addition to a public key signature > > based authentication of the responder to the initiator. > > > > Recently, some people have interpreted the last sentence as > > "public key signature based authentication of the responder > > MUST be used". > > > > Another possible interpretation is that _typically_ the responder > > is authenticated with public key signatures (for the reasons > > given earlier in the paragraph), but other alternatives (such > > as EAP method that provides mutual authentication, or even > > shared secret) may be possible in some circumstances. > > > > Any comments? > > > > Personally, I support the latter interpretation; since otherwise > > only initiator authentication is extensible, not responder > > (and I think this would be an unnecessary limitation... after all, > > if the point of EAP is to allow users to choose an authentication > > method that best suits their needs, why should this be limited > > to initiator authentication?). > > > > This could be perhaps clarified by adding the following > > paragraph below the sequence diagram: > > > > If the authentication of the responder is based solely on a > > mutually authenticating EAP method, the responder omits the > > AUTH payload from message 4. Alternatively, the responder > > can be authenticated using either public key signatures or > > a shared secret, in which case the AUTH payload in message 4 > > is calculated as described in Section 2.15. > > > > Best regards, > > Pasi > > From owner-ipsec@lists.tislabs.com Tue Dec 30 05:21:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUDLDib060339; Tue, 30 Dec 2003 05:21:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA27155 Tue, 30 Dec 2003 07:40:48 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Clarification of EAP authentication in IKEv2? Date: Tue, 30 Dec 2003 14:51:28 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612234F@esebe023.ntc.nokia.com> Thread-Topic: Clarification of EAP authentication in IKEv2? Thread-Index: AcPOzVTVYrm5TN7NTMynPoksa5zrqgAAm0Lg To: , X-OriginalArrivalTime: 30 Dec 2003 12:51:29.0545 (UTC) FILETIME=[A4D68790:01C3CED3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id HAA27152 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Hannes, I did rephrase some of the text for clarity (perhaps failing in that goal), but my intention was not to go beyond what I initially proposed. I guess the key paragraph is this one: The authentication of the responder can be based solely on an EAP method that provides mutual authentication and establishes a shared key. In this case, the responder omits the AUTH payload from message 4. Alternatively, the responder can be authenticated using either public key signatures or a shared secret, in which case the AUTH payload in message 4 is calculated as described in Section 2.15. ...and the part that might be misleading is probably the "can" in the first sentence. Would something like this be better? If using an EAP method that provides mutual authentication and establishes a shared key, the responder MAY omit the normal IKEv2 authentication based on public key signatures (or shared secrets, not established with EAP). In this case, message 4 does not contain an AUTH payload. It is also permissible to use public key signatures (or shared secrets) in addition to EAP, in which case the AUTH payload in message 4 is calculated as described in Section 2.15. Best regards, Pasi > -----Original Message----- > From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > Sent: Tuesday, December 30, 2003 2:05 PM > To: Eronen Pasi (NRC/Helsinki); hugo@ee.technion.ac.il; > ipsec@lists.tislabs.com > Subject: RE: Clarification of EAP authentication in IKEv2? > > hi pasi, > > your current description seems to go beyond your initial > proposal. It seems that this proposal addresses every EAP > method which provides mutual authentication and generates > keying material and replaces the public key based responder > authentication (within IKEv2) totally with the EAP server > authentication of the EAP method. > > is the AUTH payload computed in such a way that it binds the > Diffie-Hellman derived key and the key generated by the EAP > method? > > ciao > hannes > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Dienstag, 30. Dezember 2003 10:51 > > To: hugo@ee.technion.ac.il; ipsec@lists.tislabs.com > > Subject: RE: Clarification of EAP authentication in IKEv2? > > > > > > Hugo, > > > > Thanks for taking the time to look at this. The MitM attack > > you describe below is basically the same as identified by > > Asokan, Niemi and Nyberg in their "Man-in-the-middle in > > tunneled authentication protocols" paper. > > > > It does not work in IKEv2 _if_ the EAP method also establishes > > a shared key (which is used to generate AUTH payloads). > > > > Currently all EAP methods that provide mutual authentication > > also establish a shared key -- but the text I proposed didn't > > mention this explicitly (and I guess some hypothetical EAP > > method could violate it, though I don't know why anyone would > > do that). So, I agree the text should be clarified to mention > > that just mutual authentication is not enough -- the method > > must also establish a shared key for AUTH payloads. > > > > BTW, Section 2.16 seems to have another small problem: the > > initiator (EAP peer) sends its AUTH payload (based on the > > EAP-generated key) first, in the same message as its last EAP > > payload. However, in EAP the peer does not always know when > > the last EAP round has been reached (many EAP methods have a > > variable number of rounds, and in some of them, the peer does > > not know the last one in advance). Also, currently it's (sort > > of) assumed that EAP methods "export" established key only > > after the conversation has successfully finished (so > > including the AUTH payload when the "key becomes available" > > and continuing the EAP exchange after that doesn't work > > fine either). > > > > Taking these (and your comments) into account, here is my > > proposal for Section 2.16 (replacing everything but the > > firsttwo paragraphs): > > > > An initiator indicates a desire to use extended > > authentication by leaving out the AUTH payload from message > > 3. By including an IDi payload but not an AUTH payload, the > > initiator has declared an identity but has not proven it. If > > the responder is willing to use an extended authentication > > method, it will place an EAP payload in message 4 and defer > > sending SAr2, TSi, and TSr until initiator authentication is > > complete in a subsequent IKE_AUTH exchange. > > > > The EAP exchange ends when the Responder sends the Initiator > > an EAP payload containing either a success or failure > > type. The IKE_AUTH exchanges are completed by exchanging AUTH > > payloads, using the syntax for shared secrets specified in > > Section 2.15. > > > > For EAP methods that create a shared key as a side effect of > > authentication, that shared key MUST be used by both the > > Initiator and Responder to generate the AUTH payloads. This > > key MUST NOT be used for any other purpose than the > > generation of these AUTH payloads. > > > > For EAP methods that do not establish a shared key, the AUTH > > payloads are calculated using (TO BE DETERMINED; see below). > > Such EAP methods SHOULD NOT be used, as they are subject to a > > number of man-in-the-middle attacks if these EAP methods are > > used in other protocols that do not use a > > server-authenticated tunnel. Please see the Security > > Considerations section for more details. > > > > The authentication of the responder can be based solely on an > > EAP method that provides mutual authentication and > > establishes a shared key. In this case, the responder omits > > the AUTH payload from message 4. Alternatively, the responder > > can be authenticated using either public key signatures or a > > shared secret, in which case the AUTH payload in message 4 is > > calculated as described in Section 2.15. > > > > In typical case, the initial SA establishment will appear > > as follows. > > > > Initiator Responder > > ----------- ----------- > > HDR, SAi1, KEi, Ni --> > > > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > > > HDR, SK { IDi, [CERTREQ,] [IDr,] > > SAi2, TSi, TSr} --> > > > > <-- HDR, SK { IDr, [CERT,] [AUTH,] > > EAP(Request) } > > > > HDR, SK { EAP(Response) } --> > > > > <-- HDR, SK { EAP(Request) } > > > > HDR, SK { EAP(Response) } --> > > > > <-- HDR, SK { EAP(Success) } > > > > HDR, SK { AUTH } --> > > > > <-- HDR, SK { AUTH, SAr2, TSi, TSr } > > > > The example above shows two EAP Request/Response pairs. The > > Initiator of an IKE_SA using EAP SHOULD be capable of > > extending the initial protocol exchange to at least ten > > IKE_AUTH exchanges in the event the Responder sends > > notification messages and/or retries the authentication > > prompt. > > > > I left the case on non-key-generating EAP methods open, > > since while your proposal for using SK_ai/SK_ar looks good, > > how do we actually ensure that the algorithm is the same as > > used for integrity within the SK{} construct? They're > > negotiated separately... would using some public-but-random > > value like prf(Ni|Nr,"EAP") be ok, or do we need to derive > > one more key from SKEYSEED? > > > > Best regards, > > Pasi From owner-ipsec@lists.tislabs.com Tue Dec 30 09:49:22 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUHnLib070808; Tue, 30 Dec 2003 09:49:22 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28515 Tue, 30 Dec 2003 12:02:31 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt Date: Tue, 30 Dec 2003 12:06:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm inclined to modify the draft to define "MAY+", meaning MAY but likely to change to SHOULD, and to list AES-CCM as having that status. Donald =========================================================== Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories 1-508-786-7554 (work) 111 Locke Drive 1-508-634-2066 (home) Marlboro, MA 01752 USA -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Monday, December 29, 2003 6:17 PM To: Eastlake III Donald-LDE008 Cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt Eastlake III Donald-LDE008 writes: > I believe that this draft should also have a table for authenticated > encryption algorithms for ESPv3 and should list AES-CCM as at least > MAY. I see no reason to list one algorithm as MAY in the document. This is the algorithm requirements document. MAY is not a requirement. All the algoritms not listed in this document are MAYs. Also I do not see any point of repeating all the algoritms from the IANA registry here, and say that they are MAYs. Perhaps we should add text in the document explicitly saying this? I think that also the HMAC-MD5-96 should be removed as it is also only MAY. Also I do not think AES-CCM is ready for the SHOULD status yet, we need some real world implementations now. -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Tue Dec 30 09:52:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUHqnib070961; Tue, 30 Dec 2003 09:52:49 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28590 Tue, 30 Dec 2003 12:14:35 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@kivinen.iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16369.46322.403323.356834@fireball.acr.fi> Date: Tue, 30 Dec 2003 19:25:06 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: byfraser@cisco.com Subject: My emails to the ipsec list have been disappeared since Dec 3... X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 9 min X-Total-Time: 14 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The ipsec mailing list seems to black hole all of my emails after I changed my email address (i.e I am sending mails using from address of kivinen@iki.fi, but I am subscribed to list as kivinen@kivinen.iki.fi). The bad thing is that I didn't get any feedback or notification that my mail didn't get through, I simply just noticed from the archives, that they are not there. Hopefully I managed to forge the headers of this mail to be so that it appears to be from the proper address... ---------------------------------------------------------------------- Message-ID: <16333.44549.395539.783836@fireball.acr.fi> Date: Wed, 3 Dec 2003 11:33:57 +0200 From: Tero Kivinen To: Darren Reed Cc: ipsec@lists.tislabs.com Subject: comments on draft-ietf-ipsec-nat-t-ike-07 In-Reply-To: <200312030410.hB34AB3v023780@caligula.anu.edu.au> References: <200312030410.hB34AB3v023780@caligula.anu.edu.au> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology Darren Reed writes: > As a person who implements an "ike" proxy for IP, I was reading > through the NAT-T draft and noticed a few glaring problems... > > First, in the exchange of data, the current draft describes > UDP traffic like this (abbreviated): > I(500,500)-> > <-R(500,X) > I(500,500)-> > <-R(500,X) > This doesn't bode well for sane NAT setup as it requires two > NAT sessions to be maintained (well at least for ipfilter :): No, it does not require. The initiator sends packet UDP(500, 500). The NAT will map that to UDP(X, 500). The responder only sees the UDP(X, 500). It will reply with the packet UDP(500, X), the NAT will map that to UDP(500, 500), and the initiator will only see that. Same goes with the port 4500, execpt the NAT will of course create new mapping for the new source, port thus UDP(4500, Y). > one for the outgoing packets and another for the incoming. > The real problem here is that they're not the same, when they > should be as it's all the same "session". The problem is that > the firewall/NAT device doesn't know that the responder is > going to use source port X and said device would appear to > have no way to know it should, when compared to a non-NAT-D > IKE conversation. The firewall/NAT device is the one who did allocate that X, thus it do knows. The responder always replies back with packets with source and destination ports reversed. > Second, to complicate matters, it deson't seem possible to > distinguish a NAT-D capable host from those that aren't at > the outset of the session. The inclusion of the NAT-D section > in the initial packet would help the above problems but is > that problematic for other reasons? There will be a Vendor-ID payload in the first 2 packets, so it is possible for the firewall/NAT to detect whether the IPsec implementations support NAT-T. There MUST NOT be any reason for the firewall/NAT box to find that information out, as the protocol should work as long as the firewall/NAT does NOT do anything special for the port 4500. > Third, the same problem with port numbers and IKE traffic > has been made with the traffic on port 4500. Is there any > advantage to using (4500,4500) on the first packet? Yes. The firewall/NAT boxes does all kind of wierd things with port 500, that will break the NAT-T. So we had to pick another port number that hopefully WILL NOT have any special handling in the NAT boxes. > Or why isn't Y in that packet ? Personally, I see no advantage, > security or otherwise, to fixing the source port. Source port is fixed, the destination port is the one that NAT mapped the original source port to. > In the > historical case of DNS, it was a way to distinguish server > to server communication from regular client to server talk. > Here we've got client to server communication that has no > security benefit or otherwise from being on source port 4500. > Any benefit you get from being able to configure a rule for > both ports being 4500 on one side is lost completely with the > replies coming from ports unknown. For the initiator the packets will always come as 500,500 or 4500,4500, for the responder the source port might be different as NAT mapped the source port to something different, thus it must reply back so that port numbers are reveresed, meaning that the source port will be 500 or 4500 and destination port will be the one mapped by NAT. (Here I assume that initiator is behind NAT and responder is not). > Fourth, wouldn't it be appropriate to specifically say, in > the draft, that NAT devices MUST NOT alter the NAT-OAi or > NAT-OAr sections? If NAT devices can modify those encrypted and authenticated packets, then I think there is something much more seriously wrong in the IKEv1 :-) I.e as those packets are encrypted and authenticated, NAT does not have any way to modify those sections. > Fifth, is this draft applicable to both IKEv1 and IKEv1? Only IKEv1, as you say :-) > It doens't say but whereas IKEv2 appears to make special > provisions for this protocol to work, IKEv1 doesn't? IKEv2 will have the same mechanisms built in to the protocol from the beginning, i.e the specification will be inside the draft-ietf-ipsec-ikev2-* draft, not using this draft. This draft will only describe the IKEv1 case. > I suppose the *REAL* problem with this entire draft is that > there isn't something in the IETF protocol suite equivalent > to UPNP (www.upnp.org) for the IKE/IPsec device to become > aware of the NAT device or talk to it, or should I not even > go there ? O:-) The requirements for the NAT-T protocol was that it must work with most currently deployed NATs, i.e we cannot require any special protocols in the NATs, and we must have work arounds for all wierd things in NATs where they try to get some limited IPsec passthrough themselfs (breaking the NAT-T at the same time). > Just one last question, if there are three or more NAT devices > in the chain betweem the two endpoints, does this draft expect > an IKE conversation & IPsec to succeed for AH ? AH was dropped out from the specification completely. It currenly only support ESP. AH and NATs really don't match (i.e what is point of protecting the ip-addresses if NAT is going to change them). Tunnel mode ESP protects same things and it works. -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16352.7443.329362.858769@fireball.acr.fi> Date: Wed, 17 Dec 2003 11:08:35 +0200 From: Tero Kivinen To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: IANA template document In-Reply-To: <29917.1071618241@marajade.sandelman.ottawa.on.ca> References: <29917.1071618241@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 21 min X-Total-Time: 33 min Michael Richardson writes: > IKEv2 Payload Types > IKEv2 Transform Types How about the protocol-id inside the Proposal Substructure? It is currently only defined in the draft, there is no table, and it have only 3 values (0 = IKE, 1 = ESP, 2 = AH). Are there going to be new numbers for that later? Should we include that too just in case? I.e IKEv2 Proposal Substructure Protocol-IDs > IKEv2 Encryption Transform Values > IKEv2 Pseudo-ramdom Function Transform Values > IKEv2 Integrity Algorithm Transform Values > IKEv2 Diffie-Hellman, ECP and EC2N Transform Values > IKEv2 Extended Sequence Numbers Transform Values These are actually Transform IDs not Transform Values, i.e IKEv2 Encryption Algorithm Transform IDs IKEv2 Pseudo-random Function Transform IDs IKEv2 Integrity Algorithm Transform IDs IKEv2 Diffie-Hellman Group Transform IDs IKEv2 Extended Sequence Numbers Transform IDs Another thing I noticed is that the section 3.4 Key Exchange Payload should have pointer back to the section 3.3.2 Transform Substructure / Transform Type 4 (Diffie-Hellman Group) Transform IDs for the DH Group #. It currently does not have that pointer. > IKEv2 Identification Types IKEv2 Identification Payload ID Types > IKEv2 Certification Payload Format IKEv2 Certificate Encodings > IKEv2 Authentication Method > IKEv2 Notification Payload Type How about the Notify Payload S_Protocol_IDs? Again This is only defined to have 3 values (1 = IKE_SA, 2 = ESP, 3 = ESP, note different values than proposal substructure protocol-ID!). Should we include this too? I.e IKEv2 Notify Payload / Security Protocol ID (For some reason the S_Protocol_ID / SECURITY_PROTOCOL_ID is using underscores, instead of dashes, some other places use Protocol-Id instead). > IKEv2 IPComp Transform IDs > IKEv2 Security Protocol ID Which protocol id this is? The Proposal, Notify or Delete payload Security Protocol ID? Because of its location I assume it is the Delete payload S_PROTOCOL_ID (again with underscores and capital letters). Numbers of the delete payload security payload id seems to match the Notify Payload security payload id numbers... > IKEv2 Traffic Selector Types > IKEv2 Configuration request types IKEv2 Configuration Payload CFG Type or something like that. It would be good to try to match the exactly same texts we have in the IKEv2 document. > IKEv2 Configuration attribute types -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16352.8503.137520.638861@fireball.acr.fi> Date: Wed, 17 Dec 2003 11:26:15 +0200 From: Tero Kivinen To: charliek@microsoft.com CC: ipsec@lists.tislabs.com Subject: Some typos in the ikev2 draft X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 17 min X-Total-Time: 17 min Here are some typos and nits that could be fixed when you are making the next version of the ikev2 document: 1) Appendix A, 4) uses CHILD-SA instead if CHILD_SA. 2) There seems to be several ways to type in the field names. The proposal substructure uses "Protocol-Id", the Transform Substructure uses "Transform ID", the Notify and Delete Payload have "S_Protocol_ID" in the figure and "SECURITY_PROTOCOL_ID" in the description, and finally the Traffic Selector payload uses "Protocol_ID". Most of the other places use field names inside the payloads with spaces, and capitalize only first letters ("Next Payload"). I think we should change those Protocol-ID / Protocol-Id / S_Protocol_ID / SECURITY_PROTOCOL_ID formats to "Protocol ID" and also fix the other field names using underscore (Start_Port / End_Port). 3) Also the section 3.3 refers to the SECURITY_PROTOCOL_ID while the proposal substructure have "Protocol-Id". 4) Also the Protocol IDs used in the proposal substructure and in the notify and delete payloads are not same. Is this intentional? If so we should have warning saying so. 5) INVALID_SYNTAX and INVALID_MESSAGE_ID used "MESSAGE_ID" instead of "Message ID". 6) The 3.4 Key Exchange Payload should have pointer back to the section 3.3.2 Transform Substructure / Transform Type 4 (Diffie-Hellman Group) Transform IDs for the DH Group #. PS. When are you planning to make the next version? -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16368.46578.80635.927942@fireball.acr.fi> Date: Tue, 30 Dec 2003 01:17:06 +0200 From: Tero Kivinen To: Eastlake III Donald-LDE008 Cc: "'ipsec@lists.tislabs.com'" Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt In-Reply-To: <62173B970AE0A044AED8723C3BCF2381037F3334@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF2381037F3334@ma19exm01.e6.bcs.mot.com> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 5 min Eastlake III Donald-LDE008 writes: > I believe that this draft should also have a table for authenticated > encryption algorithms for ESPv3 and should list AES-CCM as at least > MAY. I see no reason to list one algorithm as MAY in the document. This is the algorithm requirements document. MAY is not a requirement. All the algoritms not listed in this document are MAYs. Also I do not see any point of repeating all the algoritms from the IANA registry here, and say that they are MAYs. Perhaps we should add text in the document explicitly saying this? I think that also the HMAC-MD5-96 should be removed as it is also only MAY. Also I do not think AES-CCM is ready for the SHOULD status yet, we need some real world implementations now. -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16369.39479.663946.756843@fireball.acr.fi> Date: Tue, 30 Dec 2003 17:31:03 +0200 From: Tero Kivinen To: Pasi.Eronen@nokia.com Cc: , Subject: RE: Clarification of EAP authentication in IKEv2? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612234D@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612234D@esebe023.ntc.nokia.com> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 10 min X-Total-Time: 10 min Pasi.Eronen@nokia.com writes: > An initiator indicates a desire to use extended > authentication by leaving out the AUTH payload from message > 3. By including an IDi payload but not an AUTH payload, the > initiator has declared an identity but has not proven it. If > the responder is willing to use an extended authentication > method, it will place an EAP payload in message 4 and defer > sending SAr2, TSi, and TSr until initiator authentication is > complete in a subsequent IKE_AUTH exchange. The responder R now have 3 options how to authenticate himself to initiator I: 1) Use signatures to authenticate R to I. 2) Use pre-shared key to authenticate R to I. 3) Use EAP exchange which provides mutual authentication and provides shared key between R and I. All other options are unsafe, and MUST NOT be used (i.e use EAP exchange without mutual authentication and not using signatures or pre-shared keys). For cases 1 and 2 the responder will include the first AUTH payload in the message 4 (generated as normally done for signatures or for pre-shared keys). For case 3, the AUTH payloads are postponed until the EAP exchange is done, and the shared key is from it is available. Your text is same, but I think the cases should be listed first, and then explain them later. -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Tue Dec 30 10:36:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUIadib072558; Tue, 30 Dec 2003 10:36:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28848 Tue, 30 Dec 2003 12:56:14 -0500 (EST) Date: Tue, 30 Dec 2003 13:06:39 -0500 From: "Theodore Ts'o" To: Eastlake III Donald-LDE008 Cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt Message-ID: <20031230180639.GA28155@thunk.org> References: <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> User-Agent: Mutt/1.5.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Dec 30, 2003 at 12:06:41PM -0500, Eastlake III Donald-LDE008 wrote: > I'm inclined to modify the draft to define "MAY+", meaning MAY but > likely to change to SHOULD, and to list AES-CCM as having that status. >From my perspective, the most important thing is to encourage implementors to experiment with AES-CCM, and to start testing it in various interoperability tests. This is far more important than whether or not AES-CCM is "SHOULD", or "MAY", or "MAY+". So Tero's question is probably the most pertinent one --- has anyone played with AES-CCM in their implementation yet? - Ted From owner-ipsec@lists.tislabs.com Tue Dec 30 13:37:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBULb0ib080187; Tue, 30 Dec 2003 13:37:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00425 Tue, 30 Dec 2003 15:53:04 -0500 (EST) Message-Id: <5.2.0.9.2.20031230160037.053e8930@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 30 Dec 2003 16:02:27 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt In-Reply-To: <20031230180639.GA28155@thunk.org> References: <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Ted, but add that it is important to get implementors to structure their implementations so that authenticated encryption modes can be accommodated. AES-CCM is important in that it is the first one of those that has been specified for use with ESPbis. Russ At 01:06 PM 12/30/2003 -0500, Theodore Ts'o wrote: >On Tue, Dec 30, 2003 at 12:06:41PM -0500, Eastlake III Donald-LDE008 wrote: > > I'm inclined to modify the draft to define "MAY+", meaning MAY but > > likely to change to SHOULD, and to list AES-CCM as having that status. > > From my perspective, the most important thing is to encourage >implementors to experiment with AES-CCM, and to start testing it in >various interoperability tests. This is far more important than >whether or not AES-CCM is "SHOULD", or "MAY", or "MAY+". > >So Tero's question is probably the most pertinent one --- has anyone >played with AES-CCM in their implementation yet? > > - Ted From owner-ipsec@lists.tislabs.com Tue Dec 30 13:39:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBULdEib080302; Tue, 30 Dec 2003 13:39:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00446 Tue, 30 Dec 2003 15:57:31 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 30 Dec 2003 13:10:58 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:06 PM -0500 12/30/03, Eastlake III Donald-LDE008 wrote: >I'm inclined to modify the draft to define "MAY+", meaning MAY but >likely to change to SHOULD, and to list AES-CCM as having that status. Please don't make a new definition at this late date. We could easily get bogged down into trying to say what "MAY+" means, and it would almost certainly cause debate about whether particular quasi-important encryption algorithms would be MAY+. Instead, simply create a new section in this document that aligns with section 3.2.3 of draft-ietf-ipsec-esp-v3-06.txt, say that combined modes will require proper structuring of an ESP implementation, say why combined modes are useful (speed improvements, soon to be required in 802.11), and they say "there are no suggested or required algorithms at this time, but AES-CCM is expected to be of interest in the near future". That way, implementers know that even though there isn't a MUST or SHOULD right now, they still need to think about how their code should look if there is one in the future. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Dec 30 21:17:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBV5HBib003842; Tue, 30 Dec 2003 21:17:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03149 Tue, 30 Dec 2003 23:39:39 -0500 (EST) Date: Wed, 31 Dec 2003 06:51:33 +0200 (IST) From: Hugo Krawczyk To: Pasi.Eronen@nokia.com cc: IPsec WG Subject: RE: Clarification of EAP authentication in IKEv2? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612234D@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pasi, regarding the following issue vis-a-vis the text in 2.16: > > For EAP methods that do not establish a shared key, the AUTH > payloads are calculated using (TO BE DETERMINED; see below). > [.......] > > I left the case on non-key-generating EAP methods open, > since while your proposal for using SK_ai/SK_ar looks good, > how do we actually ensure that the algorithm is the same as > used for integrity within the SK{} construct? They're negotiated > separately... would using some public-but-random value like > prf(Ni|Nr,"EAP") be ok, or do we need to derive one more key > from SKEYSEED? > If I understand correctly there are two different integrity-type transforms (based on the transform types in sec 3.3.2): type #2 is prf (which I believe is the function used for key derivation and referred to as "prf" in the text, e.g. in sections 2.13 and 2.17) and type #3 is an integrity algorithm which (I guess) is the one used BOTH for the MAC function that is part of SK{} AND the MAC function used to generate AUTH in the case of shared-secret authentication (and EAP). Is this interpretation correct? If so, then AUTH and SK{} use the same integrity algorithm (type #3) and the problem you point out to is solved. If they are different, then please explain where in the spec they are treated differently (in particular for negotiation purposes). Now, if the above interpretation is correct then I may have a problem with the use of SK_a under the prf as specified in 2.15. But please answer my question above before we proceed to finally clarify these issues. Thanks, Hugo From owner-ipsec@lists.tislabs.com Tue Dec 30 21:17:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBV5HBib003843; Tue, 30 Dec 2003 21:17:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03034 Tue, 30 Dec 2003 23:29:29 -0500 (EST) Date: Wed, 31 Dec 2003 06:41:23 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: Re: Clarification of EAP authentication in IKEv2? In-Reply-To: <3FEC1430.6030907@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari and Pasi, Jari is right that the mitm attack as I described will not work in the case of mutually-authenticating AND key-generating EAP methods since in this case the AUTH payloads (sent at the end of the EAP exchange) are calculated over the KE values and then serve to authenticate these values. (I was wrongly assuming that AUTH was computed on the EAP messages). Yet, I would strongly oppose the interpretation (and text) offered by Pasi that the responder's signature (and its verification by the intitiator) can be skipped in an ikev2-compliant implementation. Doing this opens the protocol to dangerous uses, including some (other) forms of mitm. The basic observation here is that in a signature-less run of the protocol the whole envelopping of the EAP messages under the SK_e and SK_a keys is completely meaningless since the authentication of the DH values (from which SK_e and SK_a are derived) comes only at the end of the (EAP) protocol. At that point the initiator may discover that it was "protecting" its exchange with an attacker-generated SK_e key! Moreover, this envelopping gives a false sense of security which can easily lead applications to, for example, send sensitive information as part of the exchange assuming its protection under SK_e. As a more immediate threat, what this signature-less version of ikev2 is doing is to allow the same Asokan-Niemi-Nyberg mitm attacks (in reverse direction) that the key-generating EAP extensions of ikev2 were designed to avoid, namely, the "stealing" of EAP runs from one context to another. Specifically, by impersonating a signature-less responder in the IKE exchange, the attacker can trick an initiator, that is willing to run the EAP method in a IKEv2-context only, to participate (without its knowledge) in an external (i.e., non-ikev2 protected) run of the protocol using the same credentials and same EAP method. For those that want to use a full-fledge key-generating EAP exchange in IKE (e.g., Pasi), I propose to develop a (simple) extension to IKEv2 authentication in which the key generated by the EAP method is used to generate a value for SKEYSEED from which the pertinenet SK_e and SK_a keys are derived, and then use these keys directly in a CREATE_CHILD_SA exchange. This is the simplest extensibility approach for IKEv2 (but be careful about the details...). And just in case someone is misunderstanding my intention: I am NOT suggesting that this extension be part of the basic IKEv2 document!! Hugo From owner-ipsec@lists.tislabs.com Tue Dec 30 21:21:05 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBV5L5ib004004; Tue, 30 Dec 2003 21:21:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03143 Tue, 30 Dec 2003 23:39:01 -0500 (EST) Date: Wed, 31 Dec 2003 06:50:55 +0200 (IST) From: Hugo Krawczyk To: IPsec WG cc: Charlie Kaufman Subject: Re: Clarification of EAP authentication in IKEv2? In-Reply-To: <3FEC1430.6030907@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari, The concerns you express regarding the text in 2.15 and 2.16 are very valid ones (regardless of the discussion about signature-less EAP exchanges) and require some re-work by Charlie. See below. > > Having said this, the text in the draft does raise some questions > that had no immediately obvious answers, at least not to me. Could > be the heavy christmas food, but I wondered about the following: > > - Why does 2.15 say "when not using extended authentication" but > still 2.16 refers to 2.15? > indeed, a less confusing text is needed > - The beginning of 2.15, does it talk about only the *signature* > case, or is shared secret MAC case included? It does not make > sense to me that the two cases would sign different data, but > the formula for shared secret case in 2.15 does not include > the appended nonces and prf SK_a[ir]. Is this intentional? > Good point! I was assuming that meant the data under the signature, but re-reading this it really seems to point out to the first and second msgs, respectively, in the protocol. This would leave the nonces uncovered which is INSECURE. Therfore, the text regarding the computation of AUTH in the case of shared-secret authentication should either (1) explicitly add the nonces (as in the signature case) to the data covered by the MAC in computating AUTH, or (2) say that the data on which the MAC is computed (to create AUTH) is the same as the data covered by the signature. Note that these two specifications (1) and (2) are different: in (2) prf(SK_a,ID) would be included under the MAC while in (1) it wouldn't. If we assume that the shared secret is only shared between the specific initiator and specific responder (which I hope is the case) then there is no real need to add the identity (or its prf-ed value) in this case (on the other hand, doing so for compatibility with the signature data, has no harm). > - What are the "message octets" defined in the 2.15 shared > secret case formula? Are they the same message octets and > additional data as is talked about in the above text? Or > different? Yes, that is THE question. But I hope the above clarifies what the text SHOULD (or MUST :) mean. > > > Therefore (and this is why I am cc-ing Charlie directly) we really need a > > better text in 2.16. > > I agree. and this time I even remembered to actually bother (i,e cc) charlie. Hugo > > --Jari > > From owner-ipsec@lists.tislabs.com Wed Dec 31 03:43:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBVBhrib099082; Wed, 31 Dec 2003 03:43:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05214 Wed, 31 Dec 2003 05:53:53 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16370.44341.956712.574909@fireball.acr.fi> Date: Wed, 31 Dec 2003 13:04:21 +0200 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt In-Reply-To: References: <62173B970AE0A044AED8723C3BCF2381037F334E@ma19exm01.e6.bcs.mot.com> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > Instead, simply create a new section in this document that aligns > with section 3.2.3 of draft-ietf-ipsec-esp-v3-06.txt, say that > combined modes will require proper structuring of an ESP > implementation, say why combined modes are useful (speed > improvements, soon to be required in 802.11), and they say "there are > no suggested or required algorithms at this time, but AES-CCM is > expected to be of interest in the near future". That way, > implementers know that even though there isn't a MUST or SHOULD right > now, they still need to think about how their code should look if > there is one in the future. I really like that idea. -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Wed Dec 31 03:43:55 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBVBhtib099102; Wed, 31 Dec 2003 03:43:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA05208 Wed, 31 Dec 2003 05:52:41 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Clarification of EAP authentication in IKEv2? Date: Wed, 31 Dec 2003 13:03:24 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122353@esebe023.ntc.nokia.com> Thread-Topic: Clarification of EAP authentication in IKEv2? Thread-Index: AcPPWZ09wNfDrVvCR5+u1k+Mrgw7mwAMcagA To: , X-OriginalArrivalTime: 31 Dec 2003 11:03:23.0773 (UTC) FILETIME=[B56E02D0:01C3CF8D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA05205 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > > > I left the case on non-key-generating EAP methods open, > > since while your proposal for using SK_ai/SK_ar looks good, > > how do we actually ensure that the algorithm is the same as > > used for integrity within the SK{} construct? They're negotiated > > separately... would using some public-but-random value like > > prf(Ni|Nr,"EAP") be ok, or do we need to derive one more key > > from SKEYSEED? > > > > If I understand correctly there are two different > integrity-type transforms (based on the transform types in sec > 3.3.2): type #2 is prf (which I believe is the function used > for key derivation and referred to as "prf" in the text, > e.g. in sections 2.13 and 2.17) and type #3 is an integrity > algorithm which (I guess) is the one used BOTH for the MAC > function that is part of SK{} AND the MAC function used to > generate AUTH in the case of shared-secret authentication (and > EAP). Is this interpretation correct? > > If so, then AUTH and SK{} use the same integrity algorithm > (type #3) and the problem you point out to is solved. If they > are different, then please explain where in the spec they are > treated differently (in particular for negotiation purposes). My understanding from Section 2.15 is that transform type #2 ("prf") is also used to calculate the AUTH payload for shared secrets (and EAP): In the case of a pre-shared key, the AUTH value is computed as: AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) This would mean that transform type #3 is used only for SK{}, right? > Now, if the above interpretation is correct then I may have a > problem with the use of SK_a under the prf as specified in > 2.15. But please answer my question above before we proceed to > finally clarify these issues. Assuming that "prf(..)" in Section 2.15 refers to transform type #2 (as it does elsewhere in the document), and that SK_a is used with type #3 in SK{}, there indeed seems to be a possibility for using the same key with two different algorithms... (However, the values prf(SK_ar,IDr') and prf(SK_ai,IDi') are never transmitted, so I don't know how serious this is.) Best regards, Pasi From owner-ipsec@lists.tislabs.com Wed Dec 31 04:15:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBVCFLib000630; Wed, 31 Dec 2003 04:15:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05513 Wed, 31 Dec 2003 06:33:29 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Clarification of EAP authentication in IKEv2? Date: Wed, 31 Dec 2003 13:44:11 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122354@esebe023.ntc.nokia.com> Thread-Topic: Clarification of EAP authentication in IKEv2? Thread-Index: AcPPXn7fYcxhp9+3Qb25XZY/aXcAbwAL27QA To: , X-OriginalArrivalTime: 31 Dec 2003 11:44:11.0233 (UTC) FILETIME=[683AC510:01C3CF93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id GAA05510 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > > Jari and Pasi, > > Jari is right that the mitm attack as I described will not > work in the case of mutually-authenticating AND key-generating > EAP methods since in this case the AUTH payloads (sent at the > end of the EAP exchange) are calculated over the KE values and > then serve to authenticate these values. (I was wrongly > assuming that AUTH was computed on the EAP messages). > > Yet, I would strongly oppose the interpretation (and text) > offered by Pasi that the responder's signature (and its > verification by the intitiator) can be skipped in an > ikev2-compliant implementation. Doing this opens the protocol > to dangerous uses, including some (other) forms of mitm. > > The basic observation here is that in a signature-less run of > the protocol the whole envelopping of the EAP messages under > the SK_e and SK_a keys is completely meaningless since the > authentication of the DH values (from which SK_e and SK_a are > derived) comes only at the end of the (EAP) protocol. At that > point the initiator may discover that it was "protecting" its > exchange with an attacker-generated SK_e key! Yes, you're right in that putting the EAP messages inside SK{} does not achieve much without signatures (except possibly some identity privacy against passive eavesdroppers). However, the EAP methods which are likely to be useful in this situation are ones that don't require that envelope: they were designed to run without it in e.g. wireless LANs. > Moreover, this envelopping gives a false sense of security > which can easily lead applications to, for example, send > sensitive information as part of the exchange assuming its > protection under SK_e. It's quite clear that without the signature, the initiator at this point (before the AUTH payloads with EAP-derived keys) does not know who is the other party it shares SK_e with. But, as the EAP methods were designed to be useful even without any encryption (during the EAP exchange), I don't think this false sense of security is very important. > As a more immediate threat, what this signature-less version > of ikev2 is doing is to allow the same Asokan-Niemi-Nyberg > mitm attacks (in reverse direction) that the key-generating > EAP extensions of ikev2 were designed to avoid, namely, the > "stealing" of EAP runs from one context to another. > Specifically, by impersonating a signature-less responder in > the IKE exchange, the attacker can trick an initiator, that is > willing to run the EAP method in a IKEv2-context only, to > participate (without its knowledge) in an external (i.e., > non-ikev2 protected) run of the protocol using the same > credentials and same EAP method. Yes, if the responder is not authenticated before starting EAP, he can clearly forward the EAP messages to somewhere else (assuming the same credentials make sense in some other context: and this is more of a deployment issue). This is quite normal in EAP: for instance, the wireless LAN access point (or whatever) is not authenticated before starting EAP. However, this does not allow a successful "MitM" attack: sure, the attacker pretending to be an IKEv2 responder can forward the EAP payloads to, for instance, a wireless LAN access point; however, both conversations (IKEv2 and 802.11i) will eventually fail because the attacker doesn't know the key established by the EAP method. (I'm assuming that the EAP method does mutual authentication and establishes a key. Clearly several attacks are possible for EAP methods that don't do this.) > For those that want to use a full-fledge key-generating EAP > exchange in IKE (e.g., Pasi), I propose to develop a (simple) > extension to IKEv2 authentication in which the key generated > by the EAP method is used to generate a value for SKEYSEED > from which the pertinenet SK_e and SK_a keys are derived, and > then use these keys directly in a CREATE_CHILD_SA exchange. > This is the simplest extensibility approach for IKEv2 (but be > careful about the details...). And just in case someone is > misunderstanding my intention: I am NOT suggesting that this > extension be part of the basic IKEv2 document!! This would be very complex (since some values for SK_a/SK_e are needed before the EAP method is finished), and in my opinion, the wrong approach. I believe it's much better to derive SKEYSEED the way it's currently done (with DH), and just use EAP to authenticate the Diffie-Hellman values and nonces (via AUTH payload). This approach is quite simple, it works (with good EAP methods), and has some nice properties like PFS. If the WG consensus is that the base IKEv2 spec must prohibit this, I guess the easiest "extension" would be to specify a new Notify payload value (e.g. EAP_ONLY_AUTHENTICATION_SUPPORTED); if the initiator would include this in message #3, the responder would know that skipping public-key/shared secret authentication is ok. Best wishes for the New Year, Pasi From owner-ipsec@lists.tislabs.com Wed Dec 31 12:56:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBVKuGib023852; Wed, 31 Dec 2003 12:56:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07834 Wed, 31 Dec 2003 15:13:20 -0500 (EST) Message-ID: <20031231202406.74602.qmail@web21501.mail.yahoo.com> Date: Wed, 31 Dec 2003 15:24:06 -0500 (EST) From: Andrew Krywaniuk Subject: Re: My emails to the ipsec list have been disappeared since Dec 3... Re: My emails to the ipsec list have been disappeared since Dec 3... To: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The ipsec mailing list seems to black hole all of my emails after I > changed my email address (i.e I am sending mails using from address of > kivinen@xxxxxx, but I am subscribed to list as > kivinen@xxxxxxxxxxxxxx). The bad thing is that I didn't get any > feedback or notification that my mail didn't get through, I simply > just noticed from the archives, that they are not there. I had the exact same experience. This is frustrating to those of us who read the list only via the archives. (A bounce message would be nice.) I only lost maybe 2-3 posts, but they were long-ish posts and I didn't have a backup copy. Andrew ===== ------ Andrew Krywaniuk, Fortinet Technologies Please *do not* reply to this address. (I will not read it) Reply to askrywan..hotmail..com or my home address. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca