From owner-ipsec@lists.tislabs.com Sun Dec 1 20:58:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB24w8g06297; Sun, 1 Dec 2002 20:58:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08047 Sun, 1 Dec 2002 23:10:39 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200212020411.gB24BkJ21149@sydney.East.Sun.COM> Date: Sun, 1 Dec 2002 23:11:54 -0500 To: Reply-To: Subject: Three fields: cookie, nonce, and SPI X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo made a suggestion that was more important with the "4" rather than the "4/6", but I still like it. Currently there are two fields: "cookie", used as an anticlogging token and a SPI "nonce", used in the "4" version of IKEv2 for possibly keeping state (in addition to possibly keeping state in "cookie") Hugo wanted the nonce to be completely random, to allow for weaker assumptions on the prf function. I was unhappy about what seemed like overconstraining the already overconstrained fields, but he suggested separating them into 3 fields, which seemed a lot less confusing: "cookie" (an anticlogging token) "nonce" (quantity chosen at random) "SPI" (connection identifier) Any state that needed to be saved could be encoded in "cookie". With the "4/6", it isn't necessary to keep state, other than being able to verify the "cookie" as valid, but I've always been uncomfortable making the "cookie" be dual-purpose, since the algorithm for choosing the anti-clogging token might be different from the best strategy for choosing a SPI. And in case the cookie is chosen when Bob is being stateless, I was always worried about him finding out that he'd assigned the same cookie to two connections (admittedly low probability, but if he's stateless it seems hard to avoid). I suppose in that unlikely scenario he could break the connection and start over. But I'd suggested allowing Bob to change to a different SPI in message 4, which people always winced at as "really really ugly", but reluctantly agreed it was possible for Bob, when stateless, to compute two identical cookies. So, to avoid having people wince, and because I always found the term "cookie" for "SPI" confusing, would anyone object to separating things into the three fields Hugo suggested, even though we are going back to "4/6"? Radia From owner-ipsec@lists.tislabs.com Mon Dec 2 08:15:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2GFMg01258; Mon, 2 Dec 2002 08:15:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09446 Mon, 2 Dec 2002 10:43:14 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200212020411.gB24BkJ21149@sydney.East.Sun.COM> References: <200212020411.gB24BkJ21149@sydney.East.Sun.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: Mon, 2 Dec 2002 07:44:18 -0800 To: , From: Paul Hoffman / VPNC Subject: Re: Three fields: cookie, nonce, and SPI Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:11 PM -0500 12/1/02, Radia Perlman - Boston Center for Networking wrote: >So, to avoid having people wince, and because I always found >the term "cookie" for "SPI" confusing, would anyone object >to separating things into the three fields Hugo suggested, >even though we are going back to "4/6"? This is an excellent suggestion, and will make it easier for new developers to understand the specification. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Dec 2 08:19:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2GJXg01312; Mon, 2 Dec 2002 08:19:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09475 Mon, 2 Dec 2002 10:55:36 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C5D2@corpmx14.us.dg.com> To: ipsec@lists.tislabs.com Subject: IKEv2 transport concerns Date: Mon, 2 Dec 2002 10:56:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After further thought and some discussion with Charlie Kaufman, here are proposed approaches to dealing with two areas in which transport concerns come up in IKEv2: (1) Any system running IKEv2 is REQUIRED to handle ECN (Explicit Congestion Notification) correctly for tunnels (congestion notifications propagate from outer header to inner header at tunnel egress). The ECN Tunnel SA attribute negotiation kludge was needed in IKEv1 to deal with the legacy installed base, which is of size zero for IKEv2 ;-). (2) Repeat after me ... "IKEv2 will not negotiate transport QoS". For diffserv code points, the proposal is for IKEv2 to have each endpoint of a tunnel-mode or UDP-encapsulated-tunnel-mode SA report to the other how it treats the outer DSCP values on decapsulation (copy to inner vs. discard - nothing more complex is needed, see RFC 2983 for a longer discussion). Negotiating or configuring this ought to be out of scope for IKEv2, but reporting what will be done can be a useful check that something stupid isn't about to happen. Please note that we managed to get this done without adding anything that has to be negotiated (!). In addition, it's important to negotiate encapsulation mode needs separately from crypto processing - this turns out to dovetail nicely with the NAT traversal requirements, yielding four encapsulation modes: - Tunnel - Transport - UDP-Encapsulated Transport - UDP-Encapsulated Tunnel The latter two are defined in Section 3 of draft-ietf-ipsec-udp-encaps-04.txt . Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Dec 2 09:28:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2HSfg05516; Mon, 2 Dec 2002 09:28:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09785 Mon, 2 Dec 2002 11:59:33 -0500 (EST) Message-ID: From: "Housley, Russ" To: "'Paul Koning '" Cc: "'ipsec@lists.tislabs.com '" Subject: RE: Counter Mode: Proposed Way Forward Date: Mon, 2 Dec 2002 11:39:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pual: As I said last time you raised this question, I would like to keep it for aligment with CCM. Since CCM never uses the value of all zero, it allows a straightforward implementation of both algorithms. It is not a big deal. Russ -----Original Message----- From: Paul Koning To: Housley, Russ Cc: ipsec@lists.tislabs.com Sent: 11/27/02 12:52 PM Subject: Re: Counter Mode: Proposed Way Forward >>>>> "Russ" == Russ Housley writes: Russ> ... Russ> I propose the replacement of the truncated SPI with the 24 most Russ> significant bits form the IKE nonces. I propose that the Russ> initiator use 24 bits from its own nonce, and the responder use Russ> 24 bits from its own nonce. ... Russ> Unless I hear an uproar on the list, I will update the draft to Russ> reflect this way forward. Sounds good. How about losing the flags field, since it appears to serve no purpose, and using 32 bits of nonce? paul From owner-ipsec@lists.tislabs.com Mon Dec 2 10:30:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2IULg10254; Mon, 2 Dec 2002 10:30:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09999 Mon, 2 Dec 2002 13:00:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15851.40983.180790.828106@pkoning.dev.equallogic.com> Date: Mon, 2 Dec 2002 13:01:59 -0500 From: Paul Koning To: housley@vigilsec.com Cc: ipsec@lists.tislabs.com Subject: Re: Counter Mode: Proposed Way Forward References: <5.2.0.9.2.20021127191422.00b82a78@mail.binhost.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Russ" == Russ Housley writes: Russ> Paul: We could do that, but I am hoping that people will be Russ> interested in CCM once the new ESP gets rolling. CCM uses the Russ> flags field, but it cannot be zero. This would make it very Russ> easy for an implementation to support CCM and this counter mode Russ> specification too. It's hard to comment specifically since I don't know what CCM is or where to get a spec for it. Would CCM be a different transform? I assume yes. If so, then it has its own encoding rules. There's no reason for transform X to incorporate a field that's only used in transform Y (X != Y). paul From owner-ipsec@lists.tislabs.com Mon Dec 2 11:17:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2JHng12287; Mon, 2 Dec 2002 11:17:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10184 Mon, 2 Dec 2002 13:50:10 -0500 (EST) Message-Id: <200212021850.gB2IoJsB005542@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Three fields: cookie, nonce, and SPI In-reply-to: Your message of "Sun, 01 Dec 2002 23:11:54 EST." <200212020411.gB24BkJ21149@sydney.East.Sun.COM> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 02 Dec 2002 13:50:19 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Radia" == Radia Perlman <- Boston Center for Networking > writes: Radia> Hugo wanted the nonce to be completely random, to allow for weaker Radia> assumptions on the prf function. I was unhappy about what seemed Radia> like overconstraining the already overconstrained fields, but Radia> he suggested separating them into 3 fields, which seemed a lot Radia> less confusing: Radia> "cookie" (an anticlogging token) Radia> "nonce" (quantity chosen at random) Radia> "SPI" (connection identifier) Radia> Any state that needed to be saved could be encoded in "cookie". Would it be reasonable to keep the same SPI# as a *persistent* connection identifier? i.e. that remains the same across rekeys? it also makes is much more clear what one is deleting. We have wanted to suggest that we introduce such an identifier to both phase 1 and phase 2. We call it a channel identifier. Radia> So, to avoid having people wince, and because I always found Radia> the term "cookie" for "SPI" confusing, would anyone object Radia> to separating things into the three fields Hugo suggested, Radia> even though we are going back to "4/6"? I think it is a good idea. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPeurQoqHRg3pndX9AQFpUAQAuMdh+ZbC7X/Ockpw75Kt0WfRV2FNE6Ll GaR7J9q2oPbFvTBQF5/a+o/im2ndFZI1SuRVvufUdo9ZBGZ9SKcjqKoT497pUYNG j197CFnyj11KdeQjywgPn0iDRHGahKb34H9Wx2niQaMikc2b/p3AqWwyEBM9Qb7S xbQIdxOl63s= =Uzx4 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 2 11:35:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2JZQg14401; Mon, 2 Dec 2002 11:35:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10282 Mon, 2 Dec 2002 14:06:50 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Handling of IPcomp in IKEv2 To: "'ipsec@lists.tislabs.com'" X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 30 Nov 2002 19:51:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/02/2002 02:07:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I never really understood how IPcomp worked in IPsec until Tero explained it to me at the recent IETF. It seemed like it couldn't work as the IKEv1 spec said, yet I had heard that people used it, so I left it alone. Now that I understand it better (or at least think I do), I can see how the current spec works (sort of) but believe it could be better and simpler. My proposal is motivated in part by the desire to separate negotiation of IPcomp from the "cryptographic suites" - something that people at the IPsec meeting seemed to want but it wasn't immediately clear how. IKE optionally negotiates IPcomp when it negotiates an ESP SA, and AH SA, or an ESP within AH SA. As currently specified, an IPcomp SA is negotiated where an IPcomp SA has a two byte CPI (analogous to the four byte SPIs in ESP and AH). That always made me uneasy, because SPIs are supposed to be unique (within a single IP destination) and two bytes might not be enough. Of course, given that the IPcomp SA is bound to a containing ESP or AH SA, it's not clear why it needs a CPI at all (in which case, why waste the two bytes). As Tero explained it, the IPcomp SA is not really an SA at all. First, unlike ESP and AH, it is optional on a packet by packet basis. This is so that if the compression algorithm is not effective on a particular packet (e.g. the compressed version is bigger), IPcomp processing can be skipped on that packet. The CPI at the beginning of the IPcomp header is not to identify the session on which the packet is arriving - that is implicit from the ESP or AH header. Instead, it identifies the compression algorithm used, which is only interesting if the receiving node is capable of using multiple compression algorithms. In the common case, a node only supports a single compression algorithm and always assigns the same CPI to all IPcomp SAs. Given all this, I don't believe it is appropriate for nodes to negotiate compression algorithms as they currently do where they either end up agreeing on a single compression algorithm or they don't agree on any. Rather, each node should announce what compression algorithms it is capable of decompressing and the two byte CPIs associated with each one. A sending node can optionally compress any outgoing packet with any of the algorithms supported by the other end. This has several advantages: 1) IPcomp negotiation becomes completely separate from ESP and AH negotiation. You don't have to double the number of proposals to say that each is possible with and without IPcomp. (This comes with the cost that you can't say I'll do AES with compression or 3DES without, but it seems unlikely real implementations would want that flexibility). 2) It eliminates confusion around deleting IPcomp SAs. Nodes commit to handling their offered decompression algorithms for as long as the ESP or AH SAs are maintained. They are not explicitly deleted or renewed. 3) If bandwidth is at a premium compared to processing, a sending node could try several different compression algorithms and send whichever form was the most compressed. It would also allow senders to adjust their choice of compression algorithms over time depending on the nature of the data being transmitted, and it would allow data sent in the two directions to be compressed with different algorithms if appropriate. What do people think? Am I still confused? --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Dec 2 11:35:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2JZTg14411; Mon, 2 Dec 2002 11:35:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10283 Mon, 2 Dec 2002 14:06:54 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <017001c294c9$63a46250$23f22b42@mv.lucent.com> Subject: Re: Child_SA key material To: "David Faucher" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Fri, 29 Nov 2002 21:30:06 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/02/2002 02:08:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Currently the spec says use your order #2. Is your concern that the spec is not clear or that this is not a good order to use? --Charlie "David Faucher" wrote: > Section 4.16 of draft-ietf-ipsec-ikev2-03.txt > describes how key material is taken from KEYMAT > for CHILD-SAs. > > If AH and ESP were negotiated would the key material > be taken as > > | 1. AH_ir, AH_ri, ESP_ir(encr, auth), ESP_ri(encr, auth) > | > | or > | > | 2. AH_ir, ESP_ir(encr, auth), AH_ri, ESP_ri(encr, auth) > > where _ir = initiator to responder SA > _ri = responder to initiator SA From owner-ipsec@lists.tislabs.com Mon Dec 2 11:35:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2JZZg14428; Mon, 2 Dec 2002 11:35:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10284 Mon, 2 Dec 2002 14:06:54 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3DE498E4.30806@F-Secure.com> Subject: Re: NAT Traversal in IKEv2 To: Ari Huttunen Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "'Paul Hoffman / VPNC'" , Van Aken Dirk X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Fri, 29 Nov 2002 22:16:35 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/02/2002 02:07:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Van Aken Dirk wrote: > Is there a reason for not allowing IKEv2 to not use floating ports ? > In this way IKEv2 would behave like any other UDP based protocol Ari Huttunen responded: > I parse this as 'always use'.. Yes, this makes every IKEv2 packet > larger by 4 bytes, according to the current floating scheme. It's also > bound to have, maybe, interoperability issues with earlier IKEs and > maybe firewalls/NATs. Still, I'd prefer the least complex protocol possible. > You can reduce the 4 bytes to even 1 bit if you can tweak both the > IKEv2 and an ESPv2 specification. (Steal one bit of the SPI field..) > I'm not saying you should do it, but it's a possibility. I think you're talking about two different issues. I believe the first note concerns whether IKEv2 might be better off not using UDP port 500 as both the sending and receiving port for all IKE messages, but rather behave more like other UDP based protocols and have the initiator use a dynamically allocated port and the responder use a fixed port (perhaps 500). This would make NAT traversal work more like traditional UDP based protocols so long as the initiator is the one whose address is NATed. I see no serious problems with that proposal, though there are some minor ones. Some people want IKE messages to originate from "privileged ports" even though that concept doesn't exist on many network devices. And for devices where an IKE daemon controls port 500, that is a more natural port to send on than allocating one. What do others think? I think the spec has to say that you accept messages from any port anyway if you want to handle NAT traversal. Should we say it's OK to send from a dynamic port (optionally)? I believe the response is talking about sending IKE messages in a modified format on UDP port 3500 rather than on port 500. Currently that is done in order to share port 3500 with its use in ESP encapsulation. I believe we should allow implementations to always use that format and port, but we may want to allow use of port 500 especially for nodes that want to negotiate either IKEv1 or IKEv2. Currently, the spec doesn't say support of port 3500 is required at all by an implementation that doesn't want to support NAT traversal. We could simplify things greatly by saying that IKEv2 always runs over port 3500 and the initiator can use dynamically allocated ports. Would people be up for that? I'm torn between wanting simplification and wanting to minimize changes. I never fully understood the NAT traversal subtleties until last week. And I might still not... what am I missing? --charlie kaufman From owner-ipsec@lists.tislabs.com Mon Dec 2 11:43:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2Jh5g14647; Mon, 2 Dec 2002 11:43:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10342 Mon, 2 Dec 2002 14:16:30 -0500 (EST) Message-Id: <5.2.0.9.2.20021202141513.02a32d10@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 14:17:02 -0500 To: Paul Koning From: Russ Housley Subject: Re: Counter Mode: Proposed Way Forward Cc: ipsec@lists.tislabs.com In-Reply-To: <15851.40983.180790.828106@pkoning.dev.equallogic.com> References: <5.2.0.9.2.20021127191422.00b82a78@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul: > Russ> Paul: We could do that, but I am hoping that people will be > Russ> interested in CCM once the new ESP gets rolling. CCM uses the > Russ> flags field, but it cannot be zero. This would make it very > Russ> easy for an implementation to support CCM and this counter mode > Russ> specification too. > >It's hard to comment specifically since I don't know what CCM is or >where to get a spec for it. See draft-housley-ccm-mode-01.txt. It has been discussed on the CFRG mail list. I hope it will be published as in Informational RFC. >Would CCM be a different transform? I assume yes. If so, then it has >its own encoding rules. There's no reason for transform X to >incorporate a field that's only used in transform Y (X != Y). Good point. Russ From owner-ipsec@lists.tislabs.com Mon Dec 2 11:57:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2JvYg15263; Mon, 2 Dec 2002 11:57:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10469 Mon, 2 Dec 2002 14:31:41 -0500 (EST) Message-ID: <00c901c29a3a$33012950$57f22b42@mv.lucent.com> From: "David Faucher" To: Cc: , References: Subject: Re: Child_SA key material Date: Mon, 2 Dec 2002 13:37:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It was simply a request for clarification. As a side note, when compared to describing keys for the IKE-SA the order suggested that my #1 was the correct choice. To be consistent should the IKE-SA keys be taken in the following order: SK_d, SK_ei, SK_ai, SK_er, SK_ar (all keys from initiator to responder before responder to initiator and encryption before authentication) David ----- Original Message ----- From: To: "David Faucher" Cc: ; Sent: Friday, November 29, 2002 8:30 PM Subject: Re: Child_SA key material | | | | | Currently the spec says use your order #2. Is your concern that the spec is | not clear or that this is not a good order to use? | | --Charlie | | "David Faucher" wrote: | > Section 4.16 of draft-ietf-ipsec-ikev2-03.txt | > describes how key material is taken from KEYMAT | > for CHILD-SAs. | > | > If AH and ESP were negotiated would the key material | > be taken as | > | > | 1. AH_ir, AH_ri, ESP_ir(encr, auth), ESP_ri(encr, auth) | > | | > | or | > | | > | 2. AH_ir, ESP_ir(encr, auth), AH_ri, ESP_ri(encr, auth) | > | > where _ir = initiator to responder SA | > _ri = responder to initiator SA | From owner-ipsec@lists.tislabs.com Mon Dec 2 12:08:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2K8Ng15517; Mon, 2 Dec 2002 12:08:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10552 Mon, 2 Dec 2002 14:41:35 -0500 (EST) Message-Id: <5.1.0.14.0.20021202203823.03eb2c38@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Dec 2002 20:39:57 +0100 To: "'ipsec@lists.tislabs.com'" From: Joern Sierwald Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA10512 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:51 30.11.2002 -0500, Charlie_Kaufman@notesdev.ibm.com wrote: [snip] >Rather, each node should announce what compression algorithms it is capable >of decompressing and the two byte CPIs associated with each one. A sending >node can optionally compress any outgoing packet with any of the algorithms >supported by the other end. This has several advantages: > [snip] >What do people think? Am I still confused? > > --Charlie Brilliant. Jörn From owner-ipsec@lists.tislabs.com Mon Dec 2 13:24:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2LOdg19987; Mon, 2 Dec 2002 13:24:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10863 Mon, 2 Dec 2002 15:51:45 -0500 (EST) Message-Id: <5.2.0.9.2.20021202154906.0298ca60@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 15:51:14 -0500 To: Uri Blumenthal From: Russ Housley Subject: Re: Counter Mode: Proposed Way Forward Cc: ipsec@lists.tislabs.com In-Reply-To: <3DEBBBAB.B320A10A@bell-labs.com> References: <5.2.0.9.2.20021127191422.00b82a78@mail.binhost.com> <5.2.0.9.2.20021202141513.02a32d10@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri: Normally, the IETF publishes algorithm specifications as Informational RFCs. For example, MD5 is an Informational RFC. The authors of CCM have also submitted it to NIST for consideration as a AES mode. Russ At 02:59 PM 12/2/2002 -0500, Uri Blumenthal wrote: >Russ Housley wrote: > > See draft-housley-ccm-mode-01.txt. > > > > It has been discussed on the CFRG mail list. I hope it will be published > > as in Informational RFC. > >You don't want to standardize it? From owner-ipsec@lists.tislabs.com Mon Dec 2 13:29:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2LTog20148; Mon, 2 Dec 2002 13:29:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10710 Mon, 2 Dec 2002 15:04:00 -0500 (EST) Cc: Paul Koning , ipsec@lists.tislabs.com Message-ID: <3DEBBBAB.B320A10A@bell-labs.com> Date: Mon, 02 Dec 2002 14:59:39 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Russ Housley Original-CC: Paul Koning , ipsec@lists.tislabs.com Subject: Re: Counter Mode: Proposed Way Forward References: <5.2.0.9.2.20021127191422.00b82a78@mail.binhost.com> <5.2.0.9.2.20021202141513.02a32d10@mail.binhost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ Housley wrote: > See draft-housley-ccm-mode-01.txt. > > It has been discussed on the CFRG mail list. I hope it will be published > as in Informational RFC. You don't want to standardize it? From owner-ipsec@lists.tislabs.com Mon Dec 2 14:18:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2MI2g23366; Mon, 2 Dec 2002 14:18:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11020 Mon, 2 Dec 2002 16:50:50 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15851.54790.676728.804548@pkoning.dev.equallogic.com> Date: Mon, 2 Dec 2002 16:52:06 -0500 From: Paul Koning To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: Re: Handling of IPcomp in IKEv2 References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Charlie" == Charlie Kaufman writes: Charlie> ... Charlie> Given all this, I don't believe it is appropriate for nodes Charlie> to negotiate compression algorithms as they currently do Charlie> where they either end up agreeing on a single compression Charlie> algorithm or they don't agree on any. Rather, each node Charlie> should announce what compression algorithms it is capable of Charlie> decompressing and the two byte CPIs associated with each Charlie> one. A sending node can optionally compress any outgoing Charlie> packet with any of the algorithms supported by the other Charlie> end. This has several advantages: Charlie> 1) IPcomp negotiation becomes completely separate from ESP Charlie> and AH negotiation. You don't have to double the number of Charlie> proposals to say that each is possible with and without Charlie> IPcomp. (This comes with the cost that you can't say I'll do Charlie> AES with compression or 3DES without, but it seems unlikely Charlie> real implementations would want that flexibility). Makes sense. I agree that the example you mentioned is silly and unlikely ever to be seen in the wild. Charlie> 2) It eliminates confusion around deleting IPcomp SAs. Nodes Charlie> commit to handling their offered decompression algorithms Charlie> for as long as the ESP or AH SAs are maintained. They are Charlie> not explicitly deleted or renewed. Charlie> 3) If bandwidth is at a premium compared to processing, a Charlie> sending node could try several different compression Charlie> algorithms and send whichever form was the most Charlie> compressed. It would also allow senders to adjust their Charlie> choice of compression algorithms over time depending on the Charlie> nature of the data being transmitted, and it would allow Charlie> data sent in the two directions to be compressed with Charlie> different algorithms if appropriate. Charlie> What do people think? Am I still confused? Sounds good. Definitely an improvement over the current mess (which you correctly parsed as far as I can tell). paul From owner-ipsec@lists.tislabs.com Mon Dec 2 15:21:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2NLpg24542; Mon, 2 Dec 2002 15:21:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11129 Mon, 2 Dec 2002 17:47:34 -0500 (EST) Message-Id: <200212022248.gB2MmKJ19933@sydney.East.Sun.COM> Date: Mon, 2 Dec 2002 17:48:20 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Handling of IPcomp in IKEv2 To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FufXtOlH0kt9TQcWzw872A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the explanation, Charlie! I never understood the IKEv1 IPcomp stuff, but I understand your proposed design. I'd assumed that IKEv1 could negotiate doing IPcomp *without* either AH or ESP, in which case the CPI would indeed identify a session. But I'm glad people don't want to be able to do that. What you propose certainly sounds sane. Any chance of making it even simpler, and having the codes for identifying the compression algorithms be the same as the CPI? Then instead of saying, "I support xxx and will identify it with code 45", you could just say "I support 45". I guess this would require IANA to assign a CPI before a compression algorithm could get used. Radia From owner-ipsec@lists.tislabs.com Mon Dec 2 15:53:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB2Nrkg27203; Mon, 2 Dec 2002 15:53:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11215 Mon, 2 Dec 2002 18:26:39 -0500 (EST) Message-Id: <200212022326.gB2NQmMf018374@thunk.east.sun.com> From: Bill Sommerfeld To: Charlie_Kaufman@notesdev.ibm.com cc: "'ipsec@lists.tislabs.com'" Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Your message of "Sat, 30 Nov 2002 19:51:46 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 02 Dec 2002 18:26:48 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk reading between the lines from the point of view of a dynamic stack: - outbound AH/ESP SA's contain/reference a (possibly empty) set of acceptable (algorithm, ipcomp spi) pairs, (using the intersection of the local compressor and remote decompressor algorithm sets) - on hosts where IPcomp algorithms are unloadable, inbound AH/ESP SA's contain/reference a similar algorithm set, preventing the referenced algorithms from being unloaded until after the SA is deleted. one potential downside to this proposal is that, on a system where IPcomp algorithms are dynamically unloadable, you'll likely advertise all of them and keep them all loaded all the time. given that we generally don't want a proliferation of vanity algorithms, this doesn't seem like such a bad downside. that said, how about: A1) we assume the algorithm set is symmetric (if you can decompress you can also compress), or A2) each node separately announces which algorithms it can compress. and B) The commitment to keeping the algorithms around only extends to those algorithms which the sending end of the SA indicated it could compress. For what little it's worth, I prefer A1 over A2. - Bill From owner-ipsec@lists.tislabs.com Mon Dec 2 16:11:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB30BLg28289; Mon, 2 Dec 2002 16:11:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11269 Mon, 2 Dec 2002 18:45:10 -0500 (EST) Date: Mon, 2 Dec 2002 15:46:03 -0800 Subject: Re: Three fields: cookie, nonce, and SPI Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipsec@lists.tislabs.com To: Michael Richardson From: Derrell Piper In-Reply-To: <200212021850.gB2IoJsB005542@sandelman.ottawa.on.ca> Message-Id: <37A978F4-0650-11D7-AA7A-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Monday, December 2, 2002, at 10:50 AM, Michael Richardson wrote: > Would it be reasonable to keep the same SPI# as a *persistent* > connection > identifier? i.e. that remains the same across rekeys? > it also makes is much more clear what one is deleting. I like this suggestion a lot! It would be a big help to REQUIRE this across rekeys. I also agree with Radia's assessment that it would be good to have individual fields as you're very likely to want to derive SPI's using a different mechanism than you'd use to generate the anti-clogging tokens (cookies). Derrell From owner-ipsec@lists.tislabs.com Mon Dec 2 17:02:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB312ig02404; Mon, 2 Dec 2002 17:02:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11412 Mon, 2 Dec 2002 19:31:43 -0500 (EST) Message-Id: <200212030032.gB30WpMf019196@thunk.east.sun.com> From: Bill Sommerfeld To: Hugo Krawczyk cc: "The Purple Streak, Hilarie Orman" , housley@vigilsec.com, IPsec WG Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation In-Reply-To: Your message of "Wed, 27 Nov 2002 07:45:30 +0200." Reply-to: sommerfeld@east.sun.com Date: Mon, 02 Dec 2002 19:32:51 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [note: from my perspective, I don't think the truncation described below will be a problem in the near term -- i.e., it's definitely not worth holding up IKEv2 to fix; moreover, if you believe draft-ietf-ipsec-ike-modp-groups-04.txt, the estimated limits on group strength seem to be a weaker link than the key derivation hash..] > Hilarie, can you clarify what you mean by your comment below? > In particular, what is wrong if K is large and what > do you mean by "blocksize" in this context? I'm not Hilarie but I was in a side discussion on this very issue in Atlanta. I believe she's referring to the output size of the underlying compression function. (notation: || constitutes concatenation; B is the input block size in bytes; L is the output block size. I'm reusing some of the notation from RFC2104 but distinguishing between concatenation and separate parameters). Hmac is: HMAC(K, text) == H(K XOR opad || H(K XOR ipad || text)) [with K padded with zeros to the input blocksize (B) of the hash's compression function; ipad and opad are different constants.] The underlying hash function H is built out of repeated applications of a compression function CF which takes a previous value of size L and an input block of size B and produces an output block of size L. so, when "text" is short, the inner value: H1 = H(K XOR ipad || text) is computed: C1 = CF(C0, K XOR ipad) C2 = CF(C1, text || pad) H1 = C2 and the final value is computed: H2 = H(K XOR opad || H1) D1 = CF(D0, K XOR opad) D2 = CF(D1, H1 || pad) H2 = D2 [other details: C0 and D0 are equal and are the constant initial value for the iterated hash; "pad" is the usual MDn/SHAn "fill to near the end of the input block then add bitcount"] Note that: - the value of both C1 and D1 depend only on the key - the key is not used directly as input in any later stage. - sizeof(C1) == sizeof(D1) == L so, this isn't a problem for a single hmac invocation since you only have L bytes of output, but in the iterated hmac case: > T1 = HMAC-SHA1(K, S | 0x01) > T2 = HMAC-SHA1(K, T1 | S | 0x02) > T3 = HMAC-SHA1(K, T2 | S | 0x03) > T4 = HMAC-SHA1(K, T3 | S | 0x04) .. the intermediate C1/D1 values above are the same for each of T1,T2,T3, ... if we regard [T1,T2,T3,...] as a keystream, it would seem that there can be at most 2^(8*2*L) possible keystreams for a given HMAC, even if K is significantly longer than 2*L bytes. Hilarie seemed to have a more pessimistic evaluation than this but I'm not sure what it is. - Bill From owner-ipsec@lists.tislabs.com Mon Dec 2 20:15:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB34F4g22555; Mon, 2 Dec 2002 20:15:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11751 Mon, 2 Dec 2002 22:43:32 -0500 (EST) Message-Id: <200212022342.gB2NfmuB002308@sandelman.ottawa.on.ca> To: "'ipsec@lists.tislabs.com'" Subject: Re: Handling of IPcomp in IKEv2 In-reply-to: Your message of "Sat, 30 Nov 2002 19:51:46 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 02 Dec 2002 18:41:48 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Charlie" == Charlie Kaufman writes: Charlie> What do people think? Am I still confused? I think that your proposal makes VERY good sense. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Dec 2 20:15:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB34F4g22556; Mon, 2 Dec 2002 20:15:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11752 Mon, 2 Dec 2002 22:43:33 -0500 (EST) Message-Id: <200212022320.gB2NJctv001940@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 transport concerns In-reply-to: Your message of "Mon, 02 Dec 2002 10:56:14 EST." <277DD60FB639D511AC0400B0D068B71E0564C5D2@corpmx14.us.dg.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 02 Dec 2002 18:19:37 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Black" == Black David writes: Black> (1) Any system running IKEv2 is REQUIRED to handle ECN (Explicit I think that this may be misplaced. I think that RFC2401bis is where to say this. Black> (2) Repeat after me ... "IKEv2 will not negotiate transport QoS". Okay, I'm not even sure that we all know what it is that we won't be doing. Are you telling me that, if a gateway system is aware of QoS that was requested by an end system, that it can never inform the other gateway of this fact? Clearly, a gateway system that knows of a QoS requested by an end system (whether via RSVP or other) could easily present appropriate signaling for the resulting tunnel. Black> For diffserv code points, the proposal is for IKEv2 to have Black> each endpoint of a tunnel-mode or UDP-encapsulated-tunnel-mode Black> SA report to the other how it treats the outer DSCP values Black> on decapsulation (copy to inner vs. discard - nothing more Black> complex is needed, see RFC 2983 for a longer discussion). Black> Negotiating or configuring this ought to be out of scope for Black> IKEv2, but reporting what will be done can be a useful check Black> that something stupid isn't about to happen. Okay, so this is just advice. Black> In addition, it's important to negotiate encapsulation mode needs Black> separately from crypto processing - this turns out to dovetail Black> nicely Black> with the NAT traversal requirements, yielding four encapsulation Black> modes: yes, this is a very good idea. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPevqh4qHRg3pndX9AQHu9AQAywpNxdLs2C4+MttnkHDQomolhwhqUAG1 +sVku7zw17sUW4DFkx75zkftH3gl/Vpt17V4uCQp+r6MIzqqskVdQ4HRUbocO96/ zi8+pVx7O0j4HMr/h0dmKx1fYg7/Q10n4MjU4Mzlj35zSBrVto+zqvEdy4gD+/3Z YbAEelFvT9s= =Z4GM -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 2 22:23:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB36N4g13499; Mon, 2 Dec 2002 22:23:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12020 Tue, 3 Dec 2002 00:47:31 -0500 (EST) Date: Mon, 2 Dec 2002 22:44:42 -0700 Message-Id: <200212030544.gB35igu24508@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: sommerfeld@east.sun.com Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage <200212030032.gB30WpMf019196@thunk.east.sun.com> Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, that's correct, it's the size of the hash output that's the problem. I do think it's a problem that should be fixed. If you take the trouble to use a big entropy key agreement method then you shouldn't be forced to dump the entropy when deriving the symmetric key. What I've been suggesting to Hugo and Charlie is that the iterated counter be prepended to K before using HMAC: T1 = HMAC-SHA1(0x00 | K, S) T2 = HMAC-SHA1(0x01 | K, T1 | S) T3 = HMAC-SHA1(0x02 | K, T2 | S | T4 = HMAC-SHA1(0x03 | K, T3 | S ) I believe this works properly for all cases, and uses a zero-based counter (a real nit). Not that I'm recommending that anyone really try to get more than 128 bits of entropy as a common practice, mind you. But I wouldn't want to prohibit the practice based on a silliness in the symmetric key derivation. Hilarie > [note: from my perspective, I don't think the truncation described > below will be a problem in the near term -- i.e., it's definitely not > worth holding up IKEv2 to fix; moreover, if you believe > draft-ietf-ipsec-ike-modp-groups-04.txt, the estimated limits on group > strength seem to be a weaker link than the key derivation hash..] > > Hilarie, can you clarify what you mean by your comment below? > > In particular, what is wrong if K is large and what > > do you mean by "blocksize" in this context? > I'm not Hilarie but I was in a side discussion on this very issue in > Atlanta. I believe she's referring to the output size of the > underlying compression function. > (notation: || constitutes concatenation; B is the input block size in > bytes; L is the output block size. I'm reusing some of the notation > from RFC2104 but distinguishing between concatenation and separate > parameters). > Hmac is: > HMAC(K, text) == H(K XOR opad || H(K XOR ipad || text)) > [with K padded with zeros to the input blocksize (B) of the hash's > compression function; ipad and opad are different constants.] > The underlying hash function H is built out of repeated applications > of a compression function CF which takes a previous value of size L > and an input block of size B and produces an output block of size L. > so, when "text" is short, the inner value: > H1 = H(K XOR ipad || text) > is computed: > C1 = CF(C0, K XOR ipad) > C2 = CF(C1, text || pad) > H1 = C2 > and the final value is computed: > H2 = H(K XOR opad || H1) > D1 = CF(D0, K XOR opad) > D2 = CF(D1, H1 || pad) > H2 = D2 > [other details: C0 and D0 are equal and are the constant initial value > for the iterated hash; "pad" is the usual MDn/SHAn "fill to near the > end of the input block then add bitcount"] > Note that: > - the value of both C1 and D1 depend only on the key > - the key is not used directly as input in any later stage. > - sizeof(C1) == sizeof(D1) == L > so, this isn't a problem for a single hmac invocation since you only > have L bytes of output, but in the iterated hmac case: > > T1 = HMAC-SHA1(K, S | 0x01) > > T2 = HMAC-SHA1(K, T1 | S | 0x02) > > T3 = HMAC-SHA1(K, T2 | S | 0x03) > > T4 = HMAC-SHA1(K, T3 | S | 0x04) > .. the intermediate C1/D1 values above are the same for each of > T1,T2,T3, ... > if we regard [T1,T2,T3,...] as a keystream, it would seem that there > can be at most 2^(8*2*L) possible keystreams for a given HMAC, even if > K is significantly longer than 2*L bytes. > Hilarie seemed to have a more pessimistic evaluation than this but I'm > not sure what it is. > - Bill From owner-ipsec@lists.tislabs.com Mon Dec 2 22:23:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB36N4g13500; Mon, 2 Dec 2002 22:23:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12026 Tue, 3 Dec 2002 00:54:39 -0500 (EST) Message-ID: <20021203055553.7789.qmail@web15103.mail.bjs.yahoo.com> Date: Tue, 3 Dec 2002 13:55:53 +0800 (CST) From: =?gb2312?q?king=20wu?= Subject: How does IKEv2 provide solution to remote access? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk XAUTH was proposed, but it died. Then if a remote initiator wants to build a SA with a responser, how do they authenticate each other without pre-shared key? Please help, Thanks. _________________________________________________________ Do You Yahoo!? "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" http://cn.promo.yahoo.com/cgi-bin/udb/u From owner-ipsec@lists.tislabs.com Tue Dec 3 07:41:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3Ffcg04971; Tue, 3 Dec 2002 07:41:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13066 Tue, 3 Dec 2002 10:09:22 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15852.51557.210000.342416@gargle.gargle.HOWL> Date: Tue, 3 Dec 2002 10:10:29 -0500 From: Paul Koning To: sommerfeld@east.sun.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Handling of IPcomp in IKEv2 References: <200212022326.gB2NQmMf018374@thunk.east.sun.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bill" == Bill Sommerfeld writes: Bill> one potential downside to this proposal is that, on a system Bill> where IPcomp algorithms are dynamically unloadable, you'll Bill> likely advertise all of them and keep them all loaded all the Bill> time. given that we generally don't want a proliferation of Bill> vanity algorithms, this doesn't seem like such a bad downside. Bill> that said, how about: Bill> A1) we assume the algorithm set is symmetric (if you can Bill> decompress you can also compress), or Bill> A2) each node separately announces which algorithms it can Bill> compress. Bill> and Bill> B) The commitment to keeping the algorithms around only extends Bill> to those algorithms which the sending end of the SA indicated Bill> it could compress. Bill> For what little it's worth, I prefer A1 over A2. I would rather not rely on assumption A1. The reason is that a lot of compression algorithms are asymmetric: compression is much harder than decompression. So a resource-challenged node might want to advertise the ability to decompress such an algorithm without necessarily wanting to go to the effort of also compressing with that algorithm. paul From owner-ipsec@lists.tislabs.com Tue Dec 3 08:50:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3Go9g09735; Tue, 3 Dec 2002 08:50:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13319 Tue, 3 Dec 2002 11:18:47 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15852.51557.210000.342416@gargle.gargle.HOWL> References: <200212022326.gB2NQmMf018374@thunk.east.sun.com> <15852.51557.210000.342416@gargle.gargle.HOWL> 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, 3 Dec 2002 08:19:10 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Handling of IPcomp in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:10 AM -0500 12/3/02, Paul Koning wrote: > >>>>> "Bill" == Bill Sommerfeld writes: > > Bill> one potential downside to this proposal is that, on a system > Bill> where IPcomp algorithms are dynamically unloadable, you'll > Bill> likely advertise all of them and keep them all loaded all the > Bill> time. given that we generally don't want a proliferation of > Bill> vanity algorithms, this doesn't seem like such a bad downside. > > Bill> that said, how about: > > Bill> A1) we assume the algorithm set is symmetric (if you can > Bill> decompress you can also compress), or > > Bill> A2) each node separately announces which algorithms it can > Bill> compress. > > Bill> and > > Bill> B) The commitment to keeping the algorithms around only extends > Bill> to those algorithms which the sending end of the SA indicated > Bill> it could compress. > > Bill> For what little it's worth, I prefer A1 over A2. > >I would rather not rely on assumption A1. The reason is that a lot of >compression algorithms are asymmetric: compression is much harder than >decompression. So a resource-challenged node might want to advertise >the ability to decompress such an algorithm without necessarily >wanting to go to the effort of also compressing with that algorithm. We're talking about IKEv2 here, not IKEv1. IKEv2 is aimed at more typical IPsec VPN scenarios. It seems highly questionable that you could possibly specify in a reasonable management interface "use one-way compression" or, worse, "use compression type X for incoming but compression type Y for outgoing". One-way compression seems like a far edge case. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Dec 3 08:54:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3Gs6g10022; Tue, 3 Dec 2002 08:54:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13318 Tue, 3 Dec 2002 11:18:42 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20021203055553.7789.qmail@web15103.mail.bjs.yahoo.com> References: <20021203055553.7789.qmail@web15103.mail.bjs.yahoo.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, 3 Dec 2002 08:15:44 -0800 To: king wu , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: How does IKEv2 provide solution to remote access? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:55 PM +0800 12/3/02, king wu wrote: >XAUTH was proposed, but it died. It died for IKEv1. IKEv2 may have XAUTH or something like it in it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Dec 3 11:05:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3J5kg21081; Tue, 3 Dec 2002 11:05:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13666 Tue, 3 Dec 2002 13:32:18 -0500 (EST) Message-ID: <3DECF8EF.AC2C6DBF@bstormnetworks.com> Date: Tue, 03 Dec 2002 10:33:19 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: king wu , ipsec@lists.tislabs.com Subject: Re: How does IKEv2 provide solution to remote access? References: <20021203055553.7789.qmail@web15103.mail.bjs.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been very little discussion on this topic. So little, in fact, that I'm afraid we're going to wind up with ipsra-2 if we don't watch out. Why aren't we addressing this? I think a separate (MAY implement) exchange mode based on the proposal by Harkins, Piper, and Korver (CRACK) would be the best way to go. Scott Paul Hoffman / VPNC wrote: > > At 1:55 PM +0800 12/3/02, king wu wrote: > >XAUTH was proposed, but it died. > > It died for IKEv1. IKEv2 may have XAUTH or something like it in it. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Dec 3 11:07:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3J7eg21417; Tue, 3 Dec 2002 11:07:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13681 Tue, 3 Dec 2002 13:36:26 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3DECF8EF.AC2C6DBF@bstormnetworks.com> References: <20021203055553.7789.qmail@web15103.mail.bjs.yahoo.com> <3DECF8EF.AC2C6DBF@bstormnetworks.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, 3 Dec 2002 10:37:15 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: How does IKEv2 provide solution to remote access? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:33 AM -0800 12/3/02, Scott G. Kelly wrote: >There has been very little discussion on this topic. So little, in fact, >that I'm afraid we're going to wind up with ipsra-2 if we don't watch >out. Why aren't we addressing this? We are. As stated in the minutes, there was a discussion about remote access after the main IPsec meeting ran out of time. There will probably be a proposal this week or next about how to move forwards with this in IKEv2. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Dec 3 11:19:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3JJEg22126; Tue, 3 Dec 2002 11:19:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13756 Tue, 3 Dec 2002 13:49:50 -0500 (EST) X-VirusChecked: Checked X-Env-Sender: shicai@cryptek.com X-Msg-Ref: server-16.tower-15.messagelabs.com!1038941375!26647 Message-ID: <2EFAECB4FEF6D611831D00010288413706CF6C@postmaster.cryptek.com> From: "Hu, Shicai" To: ipsec@lists.tislabs.com Subject: Where can I find an old Internet-drafts? Date: Tue, 3 Dec 2002 14:09:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Usually, an Internet-Drafts will be expired in 6 months. Are those expired Internet-Drafts achived somewhere? Say, if I want to take a look on an Internet-Drafts in 1999 (as is refered in some research papers), where can I find? Thanks Shicai From owner-ipsec@lists.tislabs.com Tue Dec 3 11:20:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3JKOg22172; Tue, 3 Dec 2002 11:20:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13769 Tue, 3 Dec 2002 13:51:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15852.64871.444409.765313@pkoning.dev.equallogic.com> Date: Tue, 3 Dec 2002 13:52:23 -0500 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Handling of IPcomp in IKEv2 References: <200212022326.gB2NQmMf018374@thunk.east.sun.com> <15852.51557.210000.342416@gargle.gargle.HOWL> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> At 10:10 AM -0500 12/3/02, Paul Koning wrote: >> I would rather not rely on assumption A1. The reason is that a >> lot of compression algorithms are asymmetric: compression is much >> harder than decompression. So a resource-challenged node might >> want to advertise the ability to decompress such an algorithm >> without necessarily wanting to go to the effort of also >> compressing with that algorithm. Paul> We're talking about IKEv2 here, not IKEv1. IKEv2 is aimed at Paul> more typical IPsec VPN scenarios. It seems highly questionable Paul> that you could possibly specify in a reasonable management Paul> interface "use one-way compression" or, worse, "use compression Paul> type X for incoming but compression type Y for outgoing". Paul> One-way compression seems like a far edge case. I agree, but that's not what I proposed. I assume your IKEv1 vs. IKEv2 comment means "don't make it as complicated as IKEv1 was". Fair enough. When doing compression in software, I can easily imagine a case where an implementation is willing to decompress with algorithms A, B, C, but only wants to compress with B because A and C are too expensive in the compress direction when done in software. But come to think of it, that's easy to support. The way to do this is to have each side announce what it can DEcompress (not compress). In other words, what it will accept inbound. For outbound processing, the sender then simply takes one of the announced decompression algorithms (whichever one it prefers right now), or it doesn't compress if it has no compatible algorithm, or for whatever reason isn't willing to run it right now. This is maximally simple (each side simply announces its capabilities), involves no negotation, does not require any assumptions of symmetry. paul From owner-ipsec@lists.tislabs.com Tue Dec 3 11:25:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3JPkg22285; Tue, 3 Dec 2002 11:25:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13797 Tue, 3 Dec 2002 13:55:53 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15852.64871.444409.765313@pkoning.dev.equallogic.com> References: <200212022326.gB2NQmMf018374@thunk.east.sun.com> <15852.51557.210000.342416@gargle.gargle.HOWL> <15852.64871.444409.765313@pkoning.dev.equallogic.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, 3 Dec 2002 10:56:46 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Handling of IPcomp in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:52 PM -0500 12/3/02, Paul Koning wrote: >When doing compression in software, I can easily imagine a case where >an implementation is willing to decompress with algorithms A, B, C, >but only wants to compress with B because A and C are too expensive in >the compress direction when done in software. This still seems like an edge case. Look how few compression algorithms we have registered, and look how hard it would be to make a sensible administrative interface for this. >But come to think of it, that's easy to support. The way to do this >is to have each side announce what it can DEcompress (not compress). >In other words, what it will accept inbound. This seems fine too, and seems to cover the situation you believe in. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Dec 3 12:01:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3K1Fg24150; Tue, 3 Dec 2002 12:01:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14039 Tue, 3 Dec 2002 14:30:27 -0500 (EST) Cc: king wu , ipsec@lists.tislabs.com Message-ID: <3DECE6C1.6E31F46C@bell-labs.com> Date: Tue, 03 Dec 2002 12:15:45 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Paul Hoffman / VPNC Original-CC: king wu , ipsec@lists.tislabs.com Subject: Re: How does IKEv2 provide solution to remote access? References: <20021203055553.7789.qmail@web15103.mail.bjs.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: > > At 1:55 PM +0800 12/3/02, king wu wrote: > >XAUTH was proposed, but it died. > > It died for IKEv1. IKEv2 may have XAUTH or something like it in it. Yes, it better. Unless we want to see proprietary extensions all over again - all incompatible with each other... From owner-ipsec@lists.tislabs.com Tue Dec 3 12:10:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3KARg25482; Tue, 3 Dec 2002 12:10:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14082 Tue, 3 Dec 2002 14:35:34 -0500 (EST) Date: Tue, 3 Dec 2002 14:36:45 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 3 Dec 2002, Paul Hoffman / VPNC wrote: > >But come to think of it, that's easy to support. The way to do this > >is to have each side announce what it can DEcompress (not compress). > >In other words, what it will accept inbound. > > This seems fine too, and seems to cover the situation you believe in. A further point: there should be the ability to express a preference ranking (e.g., the announcement lists acceptable algorithms in preference order), and there should be a "no compression" value so it can be ranked too. Back when I was with the FreeS/WAN project, when we first looked at compression, even without the issue of algorithm choice we concluded that there were plausible uses for all four rankings (never compress; okay to compress but uncompressed preferred; compression preferred; compression mandatory). We did not implement all four, but that was mostly a matter of a quick, simple first-cut implementation that never got revisited. ("Compression mandatory" is a slight misnomer, since even with IPComp negotiated, the sender may decide not to compress any particular packet. It should be read as "compression strongly desired".) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Dec 3 13:07:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3L7Wg27928; Tue, 3 Dec 2002 13:07:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14285 Tue, 3 Dec 2002 15:34:03 -0500 (EST) From: Mark Handley X-Organisation: ICIR To: "Hu, Shicai" cc: ipsec@lists.tislabs.com Subject: Re: Where can I find an old Internet-drafts? In-reply-to: Your message of "Tue, 03 Dec 2002 14:09:44 EST." <2EFAECB4FEF6D611831D00010288413706CF6C@postmaster.cryptek.com> Date: Tue, 03 Dec 2002 12:35:15 -0800 Message-ID: <82729.1038947715@aardvark.icir.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Usually, an Internet-Drafts will be expired in 6 months. Are those expired >Internet-Drafts achived somewhere? Say, if I want to >take a look on an Internet-Drafts in 1999 (as is refered in some research >papers), where can I find? I have a totally unofficial archive at: http://www.icir.org/internet-drafts/id-index.html It's probably not totally complete (the script that builds the page has run without supervision for several years now), but it has most versions of most drafts submitted since autumn 1999. Cheers, Mark From owner-ipsec@lists.tislabs.com Tue Dec 3 13:34:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3LYEg01553; Tue, 3 Dec 2002 13:34:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14408 Tue, 3 Dec 2002 16:01:46 -0500 (EST) Message-ID: <6809B34C3BFED511BC83000103C42C94D92A24@mail.funk.com> From: Mike Santoro To: "'Hu, Shicai'" , ipsec@lists.tislabs.com Subject: RE: Where can I find an old Internet-drafts? Date: Tue, 3 Dec 2002 16:03:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What you would do is look into the ftp place-holder and then you would need to contact the author or author's about getting a copy. Michael Santoro Systems Engineer Funk Software 222 Third St Cambridge, MA 02142 Tel. 617-497-6339 Fax 617-547-1031 www.funk.com "Our Mission here at Funk Software Inc. is to provide a Dynamic RADIUS solution that would meet or exceed the most challenging or most basic of AAA integrations." -----Original Message----- From: Hu, Shicai [mailto:shicai@cryptek.com] Sent: Tuesday, December 03, 2002 2:10 PM To: ipsec@lists.tislabs.com Subject: Where can I find an old Internet-drafts? Usually, an Internet-Drafts will be expired in 6 months. Are those expired Internet-Drafts achived somewhere? Say, if I want to take a look on an Internet-Drafts in 1999 (as is refered in some research papers), where can I find? Thanks Shicai From owner-ipsec@lists.tislabs.com Tue Dec 3 14:13:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3MD0g02917; Tue, 3 Dec 2002 14:13:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14513 Tue, 3 Dec 2002 16:29:31 -0500 (EST) Message-ID: <9A17FB0972A9E049A22B5B43B649B853056BBE31@sjc-exm-15.corp.ebay.com> From: "Gironda, Andre" To: ipsec@lists.tislabs.com Cc: "'Hu, Shicai'" Subject: RE: Where can I find an old Internet-drafts? Date: Tue, 3 Dec 2002 13:30:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Try this URL: http://www.watersprings.org/ http://www.watersprings.org/pub/id/index-all.html Lists all the I-D's from about September 1992 and whether they are expired or became RFC's, etc. Andre > -----Original Message----- > From: Hu, Shicai [mailto:shicai@cryptek.com] > Sent: Tuesday, December 03, 2002 11:10 AM > To: ipsec@lists.tislabs.com > Subject: Where can I find an old Internet-drafts? > > > Usually, an Internet-Drafts will be expired in 6 months. Are > those expired > Internet-Drafts achived somewhere? Say, if I want to > take a look on an Internet-Drafts in 1999 (as is refered in > some research > papers), where can I find? > > Thanks > > > Shicai > From owner-ipsec@lists.tislabs.com Tue Dec 3 14:13:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3MD5g02943; Tue, 3 Dec 2002 14:13:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14531 Tue, 3 Dec 2002 16:34:38 -0500 (EST) Message-ID: <3DED2383.E1D87708@bstormnetworks.com> Date: Tue, 03 Dec 2002 13:34:59 -0800 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Hu, Shicai" CC: ipsec@lists.tislabs.com Subject: Re: Where can I find an old Internet-drafts? References: <2EFAECB4FEF6D611831D00010288413706CF6C@postmaster.cryptek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hu, Shicai" wrote: > > Usually, an Internet-Drafts will be expired in 6 months. Are those expired > Internet-Drafts achived somewhere? Say, if I want to > take a look on an Internet-Drafts in 1999 (as is refered in some research > papers), where can I find? > > Thanks > > Shicai Try http://community.roxen.com/developers/idocs/drafts/show_category.html?cat=ipsec From owner-ipsec@lists.tislabs.com Tue Dec 3 14:21:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3MLAg04035; Tue, 3 Dec 2002 14:21:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14538 Tue, 3 Dec 2002 16:37:41 -0500 (EST) Message-ID: <3DED243F.7070402@isi.edu> Date: Tue, 03 Dec 2002 13:38:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Handley CC: "Hu, Shicai" , ipsec@lists.tislabs.com Subject: Re: Where can I find an old Internet-drafts? References: <82729.1038947715@aardvark.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Handley wrote: >>Usually, an Internet-Drafts will be expired in 6 months. Are those expired >>Internet-Drafts achived somewhere? Say, if I want to >>take a look on an Internet-Drafts in 1999 (as is refered in some research >>papers), where can I find? > > > I have a totally unofficial archive at: > > http://www.icir.org/internet-drafts/id-index.html FWIW, these aren't supposed to be archived. The whole point is that they're supposed to go away. FWIW, The convention in the publishing industry is that copyright, once abandoned by a publisher, reverts to the author. Thus, posting this archive is potentially (and hopefully) in violation of the copyright of the authors. (I'm glad to see none of my past drafts in the database above; yes, I have issued desist letters to those posting them in violation of the explicit permitted use). Joe From owner-ipsec@lists.tislabs.com Tue Dec 3 14:30:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3MUkg05612; Tue, 3 Dec 2002 14:30:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14651 Tue, 3 Dec 2002 17:04:30 -0500 (EST) Message-ID: <3DED2ABE.9000801@isi.edu> Date: Tue, 03 Dec 2002 14:05:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Handley CC: "Hu, Shicai" , ipsec@lists.tislabs.com Subject: Re: Where can I find an old Internet-drafts? References: <83181.1038952443@aardvark.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Handley wrote: >>FWIW, these aren't supposed to be archived. The whole point is that >>they're supposed to go away. > > ... > >>Thus, posting this archive is potentially (and hopefully) in violation >>of the copyright of the authors. (I'm glad to see none of my past drafts >>in the database above; yes, I have issued desist letters to those >>posting them in violation of the explicit permitted use). > > > > I'm sorry Joe, but you're wrong. Please _read_ the IDs you're archiving; not all have this portion. Those that don't (especially older ones) are in violation to archive. Joe > This is off topic for this list, but > here's the copyright that Internet Drafts have to use these days: > > Full Copyright Statement > > Copyright (C) The Internet Society (2002). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Thus anyone has the right in perpetuity to archive or otherwise > reproduce internet drafts. > > Cheers, > Mark From owner-ipsec@lists.tislabs.com Tue Dec 3 14:30:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3MUsg05643; Tue, 3 Dec 2002 14:30:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14609 Tue, 3 Dec 2002 16:53:14 -0500 (EST) From: Mark Handley X-Organisation: ICIR To: Joe Touch cc: "Hu, Shicai" , ipsec@lists.tislabs.com Subject: Re: Where can I find an old Internet-drafts? In-reply-to: Your message of "Tue, 03 Dec 2002 13:38:07 PST." <3DED243F.7070402@isi.edu> Date: Tue, 03 Dec 2002 13:54:03 -0800 Message-ID: <83181.1038952443@aardvark.icir.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >FWIW, these aren't supposed to be archived. The whole point is that >they're supposed to go away. ... >Thus, posting this archive is potentially (and hopefully) in violation >of the copyright of the authors. (I'm glad to see none of my past drafts >in the database above; yes, I have issued desist letters to those >posting them in violation of the explicit permitted use). I'm sorry Joe, but you're wrong. This is off topic for this list, but here's the copyright that Internet Drafts have to use these days: Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Thus anyone has the right in perpetuity to archive or otherwise reproduce internet drafts. Cheers, Mark From owner-ipsec@lists.tislabs.com Tue Dec 3 14:31:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3MVRg05741; Tue, 3 Dec 2002 14:31:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14660 Tue, 3 Dec 2002 17:05:35 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation Date: 3 Dec 2002 21:44:09 GMT Organization: University of California, Berkeley Lines: 29 Distribution: isaac Message-ID: References: <200212030032.gB30WpMf019196@thunk.east.sun.com> <200212030544.gB35igu24508@localhost.localdomain> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1038951849 1013 128.32.153.211 (3 Dec 2002 21:44:09 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 3 Dec 2002 21:44:09 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Purple Streak, Hilarie Orman wrote: >What I've been suggesting to Hugo and Charlie is that the iterated >counter be prepended to K before using HMAC: > > T1 = HMAC-SHA1(0x00 | K, S) > T2 = HMAC-SHA1(0x01 | K, T1 | S) > T3 = HMAC-SHA1(0x02 | K, T2 | S | > T4 = HMAC-SHA1(0x03 | K, T3 | S ) > >I believe this works properly for all cases, and uses a zero-based >counter (a real nit). This is a tangent, but: Is there any reason to prefer the counter being part of the key rather than the message? The following seems slightly better to me: T1 = HMAC-SHA1(K, 0x00 | S) T2 = HMAC-SHA1(K, 0x01 | T1 | S) T3 = HMAC-SHA1(K, 0x02 | T2 | S | T4 = HMAC-SHA1(K, 0x03 | T3 | S ) My version is secure if HMAC-SHA1 is a secure PRF. Your version also requires that HMAC-SHA1 be secure against related-key attacks. This is almost certainly a very minor nitpick. It seems very unlikely that this will make a difference in practice. Nonetheless, I do like my construction a little better, on general principles. Again, this is not at all important, and it is tangential to what you proposed. My apologies for the distraction. From owner-ipsec@lists.tislabs.com Tue Dec 3 15:40:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3Neog09748; Tue, 3 Dec 2002 15:40:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15021 Tue, 3 Dec 2002 18:02:29 -0500 (EST) Message-Id: <3.0.5.32.20021203145854.008ee600@pop.mindspring.com> X-Sender: tardo@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 03 Dec 2002 14:58:54 -0800 To: daw@mozart.cs.berkeley.edu (David Wagner), ipsec@lists.tislabs.com From: "Joseph J. Tardo" Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation In-Reply-To: References: <200212030032.gB30WpMf019196@thunk.east.sun.com> <200212030544.gB35igu24508@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: It's more efficient, an admittedly marginal benefit, since the initial inner and outer states can be computed once and used to derive the whole keystream. --Joe At 09:44 PM 12/3/02 GMT, David Wagner wrote: >The Purple Streak, Hilarie Orman wrote: >>What I've been suggesting to Hugo and Charlie is that the iterated >>counter be prepended to K before using HMAC: >> >> T1 = HMAC-SHA1(0x00 | K, S) >> T2 = HMAC-SHA1(0x01 | K, T1 | S) >> T3 = HMAC-SHA1(0x02 | K, T2 | S | >> T4 = HMAC-SHA1(0x03 | K, T3 | S ) >> >>I believe this works properly for all cases, and uses a zero-based >>counter (a real nit). > >This is a tangent, but: > >Is there any reason to prefer the counter being part of the key >rather than the message? The following seems slightly better to me: > T1 = HMAC-SHA1(K, 0x00 | S) > T2 = HMAC-SHA1(K, 0x01 | T1 | S) > T3 = HMAC-SHA1(K, 0x02 | T2 | S | > T4 = HMAC-SHA1(K, 0x03 | T3 | S ) >My version is secure if HMAC-SHA1 is a secure PRF. Your version >also requires that HMAC-SHA1 be secure against related-key attacks. > >This is almost certainly a very minor nitpick. It seems very >unlikely that this will make a difference in practice. Nonetheless, >I do like my construction a little better, on general principles. > >Again, this is not at all important, and it is tangential to >what you proposed. My apologies for the distraction. > From owner-ipsec@lists.tislabs.com Tue Dec 3 15:54:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3NsWg10579; Tue, 3 Dec 2002 15:54:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15080 Tue, 3 Dec 2002 18:23:46 -0500 (EST) Date: Wed, 4 Dec 2002 01:24:15 +0200 (IST) From: Hugo Krawczyk To: Bill Sommerfeld cc: "The Purple Streak, Hilarie Orman" , housley@vigilsec.com, IPsec WG Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation In-Reply-To: <200212030032.gB30WpMf019196@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill, You are right in your description below of what HMAC does. And surely enough HMAC is not stronger than its key length. If the key is 160 bits (as in SHA-1) then you can break the function in 2^160 operations by exhaustive search. In particular the key derivation procedures of IKEv1 and IKEv2 are NOT STRONGER than the strength of the prf. If you use HMAC-SHA1 as the prf then the whole key derivation is no stronger than 2^160. If someone finds this level of security insufficient (?) then this someone can use longer-keys prf's (e.g. HMAC with SHA2-256). But then this someone wil have to use (prohibitively costly?) DH groups, 192-bit key AES, etc. Nothing that (baring major cryptanalytical breakthroughs) makes sense today or in the visible future in commercial applications. Let me also note that the dependncy on the strength of the prf shows up already in the definition of SKEYSEED (which is later used as K in the key derivation mechanism that you refer to). Indeed, SKEYSEED is obtained by hashing down the full DH key into L bits (where L is the length of the prf output). A naive observer of this hashing could think that it is silly to give up many g^xy bits (say 1024) for "just" 160 bits of the prf output. But it is actually the other way around: the hashing of the DH key represents a strengthening of the DH exchange in the sense that instead of directlty using the long g^xy key with relatively low "computational entropy" you apply the hashing to "extract" and concentrate the ful entropy in a single (shorter) key. The theoretical basis for this type of "entropy smoothing" (this is the usual technical term) via hash functions can be found in Goldreich's book (Foundations of Cryptography). The only heuristic twist in IKE's key derivation (v1 and v2) is that the prf is used in lieu of a universal hash family (using an explicit UH family would have been better from the theoretical point of view but would have required to add yet another transform to the protocol). Hugo On Mon, 2 Dec 2002, Bill Sommerfeld wrote: > [note: from my perspective, I don't think the truncation described > below will be a problem in the near term -- i.e., it's definitely not > worth holding up IKEv2 to fix; moreover, if you believe > draft-ietf-ipsec-ike-modp-groups-04.txt, the estimated limits on group > strength seem to be a weaker link than the key derivation hash..] > > > Hilarie, can you clarify what you mean by your comment below? > > In particular, what is wrong if K is large and what > > do you mean by "blocksize" in this context? > > I'm not Hilarie but I was in a side discussion on this very issue in > Atlanta. I believe she's referring to the output size of the > underlying compression function. > > (notation: || constitutes concatenation; B is the input block size in > bytes; L is the output block size. I'm reusing some of the notation > from RFC2104 but distinguishing between concatenation and separate > parameters). > > Hmac is: > > HMAC(K, text) == H(K XOR opad || H(K XOR ipad || text)) > > [with K padded with zeros to the input blocksize (B) of the hash's > compression function; ipad and opad are different constants.] > > The underlying hash function H is built out of repeated applications > of a compression function CF which takes a previous value of size L > and an input block of size B and produces an output block of size L. > > so, when "text" is short, the inner value: > > H1 = H(K XOR ipad || text) > > is computed: > > C1 = CF(C0, K XOR ipad) > C2 = CF(C1, text || pad) > > H1 = C2 > > and the final value is computed: > > H2 = H(K XOR opad || H1) > > D1 = CF(D0, K XOR opad) > D2 = CF(D1, H1 || pad) > > H2 = D2 > > [other details: C0 and D0 are equal and are the constant initial value > for the iterated hash; "pad" is the usual MDn/SHAn "fill to near the > end of the input block then add bitcount"] > > Note that: > > - the value of both C1 and D1 depend only on the key > - the key is not used directly as input in any later stage. > - sizeof(C1) == sizeof(D1) == L > > so, this isn't a problem for a single hmac invocation since you only > have L bytes of output, but in the iterated hmac case: > > > T1 = HMAC-SHA1(K, S | 0x01) > > T2 = HMAC-SHA1(K, T1 | S | 0x02) > > T3 = HMAC-SHA1(K, T2 | S | 0x03) > > T4 = HMAC-SHA1(K, T3 | S | 0x04) > > .. the intermediate C1/D1 values above are the same for each of > T1,T2,T3, ... > > if we regard [T1,T2,T3,...] as a keystream, it would seem that there > can be at most 2^(8*2*L) possible keystreams for a given HMAC, even if > K is significantly longer than 2*L bytes. > > Hilarie seemed to have a more pessimistic evaluation than this but I'm > not sure what it is. > > - Bill > From owner-ipsec@lists.tislabs.com Tue Dec 3 15:55:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB3Nt8g10609; Tue, 3 Dec 2002 15:55:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15092 Tue, 3 Dec 2002 18:26:51 -0500 (EST) Date: Wed, 4 Dec 2002 01:27:42 +0200 (IST) From: Hugo Krawczyk To: "The Purple Streak, Hilarie Orman" cc: sommerfeld@east.sun.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation In-Reply-To: <200212030544.gB35igu24508@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 2 Dec 2002, The Purple Streak, Hilarie Orman wrote: > Yes, that's correct, it's the size of the hash output that's the > problem. I do think it's a problem that should be fixed. If you take I do not see the problem. If you need more than SHA1 strength use SHA2 (with 256 or 512 bits). > the trouble to use a big entropy key agreement method then you > shouldn't be forced to dump the entropy when deriving the symmetric key. ditto > > What I've been suggesting to Hugo and Charlie is that the iterated > counter be prepended to K before using HMAC: > > T1 = HMAC-SHA1(0x00 | K, S) > T2 = HMAC-SHA1(0x01 | K, T1 | S) > T3 = HMAC-SHA1(0x02 | K, T2 | S | > T4 = HMAC-SHA1(0x03 | K, T3 | S ) > > I believe this works properly for all cases, and uses a zero-based > counter (a real nit). > This doesn't help at all. You can still find K in 2^160 operations (note that a guess can always be validated via the derived keys which produce visible outputs in the protocol). And this construction is wrong from an anlytical point of view. PRF's are not required to be strong in the presence of related keys. There is no reason to go to improvisations when the theory is strong enough (and cheap!) to justify a better (and in this case also simpler) design. > Not that I'm recommending that anyone really try to get more than > 128 bits of entropy as a common practice, mind you. But I wouldn't want > to prohibit the practice based on a silliness in the symmetric key > derivation. > There is no silliness here. And, as I said, for those that want >160 bits there are longer key hash functions to use (the truth is that for such people I recommend forgetting about the fragil cryptography and go back to pigeons -- they can be shot but not cryptanalyzed). Hugo > Hilarie > > > [note: from my perspective, I don't think the truncation described > > below will be a problem in the near term -- i.e., it's definitely not > > worth holding up IKEv2 to fix; moreover, if you believe > > draft-ietf-ipsec-ike-modp-groups-04.txt, the estimated limits on group > > strength seem to be a weaker link than the key derivation hash..] > > > > Hilarie, can you clarify what you mean by your comment below? > > > In particular, what is wrong if K is large and what > > > do you mean by "blocksize" in this context? > > > I'm not Hilarie but I was in a side discussion on this very issue in > > Atlanta. I believe she's referring to the output size of the > > underlying compression function. > > > (notation: || constitutes concatenation; B is the input block size in > > bytes; L is the output block size. I'm reusing some of the notation > > from RFC2104 but distinguishing between concatenation and separate > > parameters). > > > Hmac is: > > > HMAC(K, text) == H(K XOR opad || H(K XOR ipad || text)) > > > [with K padded with zeros to the input blocksize (B) of the hash's > > compression function; ipad and opad are different constants.] > > > The underlying hash function H is built out of repeated applications > > of a compression function CF which takes a previous value of size L > > and an input block of size B and produces an output block of size L. > > > so, when "text" is short, the inner value: > > > H1 = H(K XOR ipad || text) > > > is computed: > > > C1 = CF(C0, K XOR ipad) > > C2 = CF(C1, text || pad) > > > H1 = C2 > > > and the final value is computed: > > > H2 = H(K XOR opad || H1) > > > D1 = CF(D0, K XOR opad) > > D2 = CF(D1, H1 || pad) > > > H2 = D2 > > > [other details: C0 and D0 are equal and are the constant initial value > > for the iterated hash; "pad" is the usual MDn/SHAn "fill to near the > > end of the input block then add bitcount"] > > > Note that: > > > - the value of both C1 and D1 depend only on the key > > - the key is not used directly as input in any later stage. > > - sizeof(C1) == sizeof(D1) == L > > > so, this isn't a problem for a single hmac invocation since you only > > have L bytes of output, but in the iterated hmac case: > > > > T1 = HMAC-SHA1(K, S | 0x01) > > > T2 = HMAC-SHA1(K, T1 | S | 0x02) > > > T3 = HMAC-SHA1(K, T2 | S | 0x03) > > > T4 = HMAC-SHA1(K, T3 | S | 0x04) > > > .. the intermediate C1/D1 values above are the same for each of > > T1,T2,T3, ... > > > if we regard [T1,T2,T3,...] as a keystream, it would seem that there > > can be at most 2^(8*2*L) possible keystreams for a given HMAC, even if > > K is significantly longer than 2*L bytes. > > > Hilarie seemed to have a more pessimistic evaluation than this but I'm > > not sure what it is. > > > - Bill > From owner-ipsec@lists.tislabs.com Tue Dec 3 16:06:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB406Ag10810; Tue, 3 Dec 2002 16:06:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15178 Tue, 3 Dec 2002 18:40:12 -0500 (EST) Date: Wed, 4 Dec 2002 01:41:32 +0200 (IST) From: Hugo Krawczyk To: David Wagner cc: IPsec WG Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Is there any reason to prefer the counter being part of the key > rather than the message? The following seems slightly better to me: > T1 = HMAC-SHA1(K, 0x00 | S) > T2 = HMAC-SHA1(K, 0x01 | T1 | S) > T3 = HMAC-SHA1(K, 0x02 | T2 | S | > T4 = HMAC-SHA1(K, 0x03 | T3 | S ) > My version is secure if HMAC-SHA1 is a secure PRF. Your version > also requires that HMAC-SHA1 be secure against related-key attacks. What you propose is exactly the IKEv2 derivation which Hilarie was proposing to change (except that in IKEv2 the counter goes last) > > This is almost certainly a very minor nitpick. It seems very > unlikely that this will make a difference in practice. Nonetheless, > I do like my construction a little better, on general principles. > Design based on general principles can make a bigger difference to practical security than a 160 vas 256-bit hash > Again, this is not at all important, and it is tangential to > what you proposed. My apologies for the distraction. > Because of the previous remark I think that this is important... Hugo From owner-ipsec@lists.tislabs.com Tue Dec 3 16:32:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB40Wug11707; Tue, 3 Dec 2002 16:32:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15326 Tue, 3 Dec 2002 19:06:05 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E08441061@corpmx14.us.dg.com> To: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: RE: IKEv2 transport concerns Date: Tue, 3 Dec 2002 19:06:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Black" == Black David writes: > Black> (1) Any system running IKEv2 is REQUIRED to handle ECN (Explicit > > I think that this may be misplaced. I think that RFC2401bis is where > to say this. I think it needs to be in both places. We have a one-time opportunity to avoid the IKEv1 ECN negotiation kludge if all IKEv2 implementations are REQUIRED to handle ECN correctly at tunnel egress. IMHO, this outcome is important enough to merit specifying the means of achieving it in both the IKEv2 and RFC2401bis documents. If we wind up dealing with IKEv2 systems that get this wrong, the negotiation kludge will be with us for much longer ... > Black> (2) Repeat after me ... "IKEv2 will not negotiate transport QoS". > > Okay, I'm not even sure that we all know what it is that we won't be doing. Neither do I, which is one of the reasons I want to keep it out of IKEv2 ... > Are you telling me that, if a gateway system is aware of QoS that was > requested by an end system, that it can never inform the other gateway of > this fact? No - it's welcome to inform the other gateway, just not via IKEv2. > Clearly, a gateway system that knows of a QoS requested by an end system > (whether via RSVP or other) could easily present appropriate signaling for > the resulting tunnel. Yes, via an appropriate QoS signaling protocol, which is *not* IKEv2, IMHO. > Black> For diffserv code points, the proposal is for IKEv2 to have > Black> each endpoint of a tunnel-mode or UDP-encapsulated-tunnel-mode > Black> SA report to the other how it treats the outer DSCP values > Black> on decapsulation (copy to inner vs. discard - nothing more > Black> complex is needed, see RFC 2983 for a longer discussion). > > Black> Negotiating or configuring this ought to be out of scope for > Black> IKEv2, but reporting what will be done can be a useful check > Black> that something stupid isn't about to happen. > > Okay, so this is just advice. Right it's reporting on what's going to occur, so the "Oh, sh*t, that's not right" reaction can take place before any real traffic is affected. The endpoints are free to ignore the reports if they don't have anything useful to do with them. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Dec 3 17:41:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB41fpg13689; Tue, 3 Dec 2002 17:41:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15837 Tue, 3 Dec 2002 20:10:39 -0500 (EST) Message-Id: <200212040111.gB41BSp8025423@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com cc: ippcp@external.cisco.com Subject: Re: (fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-reply-to: Your message of "Tue, 03 Dec 2002 11:53:50 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Dec 2002 20:11:26 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Avram" == Avram Shacham writes: Avram> At 19:51 30.11.2002 -0500, Charlie_Kaufman@notesdev.ibm.com wrote: Avram> [snip] >> Rather, each node should announce what compression algorithms it is capable >> of decompressing and the two byte CPIs associated with each one. A sending >> node can optionally compress any outgoing packet with any of the algorithms >> supported by the other end. This has several advantages: >> Avram> [snip] >> What do people think? Am I still confused? >> >> --Charlie Avram> Brilliant. It is a slight change to how IPCOMP works. I think that it is worth it, in my opinion. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPe1WOoqHRg3pndX9AQEo/AQArTwQdevn7osYY5xtc98nVsqsIjVPYXmx cJ3zF88T+wBDSyelQEY1MNyhnkynRtTE8MVROGjOoRZfS33uXgw+9T/QOlNWwnVz tCGevjD5GMUabvywLoZuRaJ8g11pvbSvr0oU2mZz95Gg/jCiCf42bL9VFXTTFf7U E0E7h2jJj3c= =Lqu1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 3 18:08:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB428cg16358; Tue, 3 Dec 2002 18:08:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15924 Tue, 3 Dec 2002 20:44:20 -0500 (EST) Message-Id: <200212040145.gB41jIq7029185@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 transport concerns In-reply-to: Your message of "Tue, 03 Dec 2002 19:06:31 EST." <277DD60FB639D511AC0400B0D068B71E08441061@corpmx14.us.dg.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Dec 2002 20:45:17 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Black" == Black David writes: >> Are you telling me that, if a gateway system is aware of QoS that was >> requested by an end system, that it can never inform the other gateway of >> this fact? Black> No - it's welcome to inform the other gateway, just not via IKEv2. >> Clearly, a gateway system that knows of a QoS requested by an end system >> (whether via RSVP or other) could easily present appropriate signaling for >> the resulting tunnel. Black> Yes, via an appropriate QoS signaling protocol, which is *not* IKEv2, IMHO. okay. Are signaling protocols supposed to be forwarded through the tunnel? Are there signaling protocols which an end systems can use to control QoS *towards* them? If so, how does the end system have the return stream of the tunnel properly signaled? Other than RSVP, what else is there at present? (I'm certainly out of touch). ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPe1eIYqHRg3pndX9AQEBwwQAggW2fm1R48mDJXeQ1Cp9guHhxVRQrL79 +gQJQIT21I2o0wbRZBRvS0RHxn4IXcHBYFvlvodhqmWqqIHg3eEco4yx5HUkUk0d ApwcvcIKsDcyeR1Z+2xbjcPTU4A/uGTWGA4Y8o4i6INf44COpezHV3rHxNuaKiQ0 f+s/ID5IB3w= =qrNZ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 3 19:49:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB43nAg20355; Tue, 3 Dec 2002 19:49:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16164 Tue, 3 Dec 2002 22:19:13 -0500 (EST) Date: Tue, 3 Dec 2002 19:20:32 -0800 Subject: Re: How does IKEv2 provide solution to remote access? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipsec@lists.tislabs.com To: Uri Blumenthal From: Derrell Piper In-Reply-To: <3DECE6C1.6E31F46C@bell-labs.com> Message-Id: <58FB56AE-0737-11D7-BBA0-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree completely. To be useful IKEv2 needs to address remote access. Remote access is essentially the driving factor behind IPSec gateway sales. IKEv2 needs to account for: 1) NAT traversal 2) Internal addressing -- including IP/DHCP, DNS, and WINS configuration through a tunnel 3) Legacy authentication for SecurID, Passwords, OTP, and Challenge/Response Tokens (CRACK) Without these features, people simply will not deploy IKEv2 to replace IKEv1 because they won't be able to do what they want to do -- surf their corporate intranets (which are often not globally routable and often NAT'd themselves) and read their mail while also being behind a NAT. It's way beyond hideous, but people want this for all sorts of confused reasons and they're not budging. I don't know about the rest of you, but I want to be able to use that cable modem sitting on the desks of the Marriott's and the W's of the world to log in back home securely using IPSec. And so do all of the business travelers of the world. Now this is a NAT traversal example, but the other two items are equally important. Network administrators simply will not reconfigure their entire network to introduce IPSec into it. They want to assign internal 10-net addresses to clients so legacy IP-based access control schemes continue to work as well as (or as poorly as) they have ever worked. They want their clients to use Radius passwords and/or SecurID cards to log in and for once they also want this part to be secure! You can even go so far as to ship a product with a built-in CA and they'll still insist on using passwords, trust me. Make no mistake: they want this, they (think they) need this, and they won't deploy this technology without it. It seems we have three obvious paths: 1) ignore the problem; 2) release an initial IKEv2 draft to meet Jeff's February deadline followed by a quick revision with remote access additions; 3) wait until we've got it all and release just one draft. Given my belief that this needs to be included, and given Jeff's challenge, the question I think we ought to be resolving now is: so what's the viability and risk/reward of doing #2 vs. #3? Derrell On Tuesday, December 3, 2002, at 09:15 AM, Uri Blumenthal wrote: > Yes, it better. Unless we want to see proprietary extensions > all over again - all incompatible with each other... > From owner-ipsec@lists.tislabs.com Tue Dec 3 20:43:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB44hFg24768; Tue, 3 Dec 2002 20:43:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16293 Tue, 3 Dec 2002 23:15:15 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <58FB56AE-0737-11D7-BBA0-000393CDFD1A@electric-loft.org> References: <58FB56AE-0737-11D7-BBA0-000393CDFD1A@electric-loft.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 3 Dec 2002 20:16:24 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: How does IKEv2 provide solution to remote access? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:20 PM -0800 12/3/02, Derrell Piper wrote: >It seems we have three obvious paths: 1) ignore the problem; 2) >release an initial IKEv2 draft to meet Jeff's February deadline >followed by a quick revision with remote access additions; 3) wait >until we've got it all and release just one draft. #2 and #3 could be the same thing. We can probably get it right between now and then if the first step of "now" happens within a week. That's a strong nudge to the people who have agreed to get a first draft of the proposal out "soon". --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Dec 4 00:10:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB48A0g15607; Wed, 4 Dec 2002 00:10:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16705 Wed, 4 Dec 2002 02:37:24 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C5EC@corpmx14.us.dg.com> To: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: RE: IKEv2 transport concerns Date: Wed, 4 Dec 2002 02:37:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Black" == Black David writes: > >> Are you telling me that, if a gateway system is aware of QoS that was > >> requested by an end system, that it can never inform the other gateway of > >> this fact? > > Black> No - it's welcome to inform the other gateway, just not via IKEv2. > > >> Clearly, a gateway system that knows of a QoS requested by an end system > >> (whether via RSVP or other) could easily present appropriate signaling for > >> the resulting tunnel. > > Black> Yes, via an appropriate QoS signaling protocol, which is *not* IKEv2, IMHO. > > okay. > Are signaling protocols supposed to be forwarded through the tunnel? Depends on the protocol. RSVP certainly could be forwarded in principle (need an SPD that understands protocol 46, or an encapsulation of some form), although this may raise orthogonal issues about whether the tunnel presents routable interfaces if the RSVP path extends beyond the tunnel endpoints. OTOH, there's been discussion of out-of-band protocols for bandwidth brokers and the like that probably wouldn't go through the tunnel. > Are there signaling protocols which an end systems can use to control QoS > *towards* them? If so, how does the end system have the return stream of the > tunnel properly signaled? An instance of RSVP running the other way is one possibility, although it requires serious cooperation from the other end of the tunnel. L2TP's diffserv extension (RFC 3308) may be useful when L2TP is in the stack. > Other than RSVP, what else is there at present? (I'm > certainly out of touch). Not much. In addition to RFC 3308, the nsis WG may produce something, and there's been all sorts of other possibilities discussed, but no RFCs that I can point to. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Dec 4 06:44:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4Eiwg26922; Wed, 4 Dec 2002 06:44:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17608 Wed, 4 Dec 2002 09:16:48 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15854.3714.644139.118895@pkoning.dev.equallogic.com> Date: Wed, 4 Dec 2002 09:17:38 -0500 From: Paul Koning To: touch@ISI.EDU Cc: mjh@icir.org, shicai@cryptek.com, ipsec@lists.tislabs.com Subject: Re: Where can I find an old Internet-drafts? References: <82729.1038947715@aardvark.icir.org> <3DED243F.7070402@isi.edu> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Joe" == Joe Touch writes: Joe> Mark Handley wrote: >>> Usually, an Internet-Drafts will be expired in 6 months. Are >>> those expired Internet-Drafts achived somewhere? Say, if I want >>> to take a look on an Internet-Drafts in 1999 (as is refered in >>> some research papers), where can I find? >> >> >> I have a totally unofficial archive at: >> >> http://www.icir.org/internet-drafts/id-index.html Joe> FWIW, these aren't supposed to be archived. The whole point is Joe> that they're supposed to go away. Off topic for this list, I admit, but in my opinion that policy is a major mistake. paul From owner-ipsec@lists.tislabs.com Wed Dec 4 06:44:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4Eiwg26923; Wed, 4 Dec 2002 06:44:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17578 Wed, 4 Dec 2002 09:12:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Wed, 04 Dec 2002 00:59:42 -0800 Subject: Re: Can the initiator send a type of ID randomly? From: Brian Korver To: king wu , Message-ID: In-Reply-To: <20021127103536.77145.qmail@web15105.mail.bjs.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA17023 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 11/27/02 2:35 AM, "king wu" wrote: > hi, all > > In the scenario with public sigiture keys in IKE, how > does the initiator choose a type of ID? As we know, > the ID includes FQDN,RFC822_ADDR,DER_ASN1_DN,etc. > Then, can the initiator send a type of ID randomly? > Or, are there some rules for doing it? I can't find > the rules through the documents on IKE. > Please help. > thanks. > > --King Wu > > _________________________________________________________ > Do You Yahoo!? > "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" > http://cn.promo.yahoo.com/cgi-bin/udb/u The ID type should either be an IP address or some piece of information that appears in the certificate. How to choose which piece of information is a local (policy) matter, but often is closely associated with particular authorization schemes (such as ACLs). See draft-ietf-ipsec-pki-profile-01.txt for more discussion of this issue. - brian briank@briank.com From owner-ipsec@lists.tislabs.com Wed Dec 4 07:21:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4FLOg00662; Wed, 4 Dec 2002 07:21:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17726 Wed, 4 Dec 2002 09:57:17 -0500 (EST) Date: Wed, 4 Dec 2002 06:57:23 -0800 Subject: Re: Where can I find an old Internet-drafts? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: touch@ISI.EDU, mjh@icir.org, shicai@cryptek.com, ipsec@lists.tislabs.com To: Paul Koning From: Derrell Piper In-Reply-To: <15854.3714.644139.118895@pkoning.dev.equallogic.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No kidding. There's some value in most every draft, however small. I can't count the number of working group sessions I've been to where people are discussing some aspect of some expired ID. Unless you were around at the exact right time, it's ridiculously hard to find out what they're talking about. The history of many working groups is encoded in their expired ID's. "Those who forget history..." Derrell On Wednesday, December 4, 2002, at 06:17 AM, Paul Koning wrote: > Off topic for this list, I admit, but in my opinion that policy is a > major mistake. From owner-ipsec@lists.tislabs.com Wed Dec 4 07:41:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4Ffag01640; Wed, 4 Dec 2002 07:41:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17828 Wed, 4 Dec 2002 10:13:47 -0500 (EST) From: "Stephane Beaulieu" To: "Derrell Piper" , "Uri Blumenthal" , "Cmadson@Cisco.Com" Cc: Subject: Requirements (was: How does IKEv2 provide solution to remote access?) Date: Wed, 4 Dec 2002 10:14:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <58FB56AE-0737-11D7-BBA0-000393CDFD1A@electric-loft.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I agree completely. To be useful IKEv2 needs to address remote access. > Remote access is essentially the driving factor behind IPSec gateway > sales. IKEv2 needs to account for: > > 1) NAT traversal > 2) Internal addressing -- including IP/DHCP, DNS, and WINS > configuration through a tunnel > 3) Legacy authentication for SecurID, Passwords, OTP, and > Challenge/Response Tokens (CRACK) > FWIW, this was all discussed in Atlanta and it seemed we had concensus on it. The plan is to try and roll this into the next rev of IKEv2. Cheryl had put out a requirements draft a while ago which included these things and a few more. At the time, it was largely ignored because of the IKEv2 vs. JFK discussions. Should we attempt to revive this and move it ahead in the WG to make sure we don't forget anyting else??? I think it would be a very good idea to have an outlined set of requirements that we can use as a gating factor for completion. It would also be useful to help keep us focused on what needs to be accomplished for Feb 15th. If we've forgotten something in the requirements, I'd rather find out about it now rather than summer '2003. Stephane. From owner-ipsec@lists.tislabs.com Wed Dec 4 08:32:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4GWJg05858; Wed, 4 Dec 2002 08:32:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17985 Wed, 4 Dec 2002 10:53:39 -0500 (EST) Message-ID: <3DEE2540.4030904@isi.edu> Date: Wed, 04 Dec 2002 07:54:40 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Koning CC: mjh@icir.org, shicai@cryptek.com, ipsec@lists.tislabs.com Subject: Re: Where can I find an old Internet-drafts? References: <82729.1038947715@aardvark.icir.org> <3DED243F.7070402@isi.edu> <15854.3714.644139.118895@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: >>>>>>"Joe" == Joe Touch writes: >>>>> > > Joe> Mark Handley wrote: > >>> Usually, an Internet-Drafts will be expired in 6 months. Are > >>> those expired Internet-Drafts achived somewhere? Say, if I want > >>> to take a look on an Internet-Drafts in 1999 (as is refered in > >>> some research papers), where can I find? > >> > >> > >> I have a totally unofficial archive at: > >> > >> http://www.icir.org/internet-drafts/id-index.html > > Joe> FWIW, these aren't supposed to be archived. The whole point is > Joe> that they're supposed to go away. > > Off topic for this list, I admit, but in my opinion that policy is a > major mistake. In hopes of moving the discussion elsewhere - may I suggest "internet-history@postel.org". As an IETF issue, this has been addressed many times before, and is probably not appropriate for this list - agreed. Joe From owner-ipsec@lists.tislabs.com Wed Dec 4 08:51:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4GpBg06759; Wed, 4 Dec 2002 08:51:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18098 Wed, 4 Dec 2002 11:21:35 -0500 (EST) From: Bill Manning Message-Id: <200212041622.gB4GMGU13028@boreas.isi.edu> Subject: Re: Where can I find an old Internet-drafts? In-Reply-To: from Derrell Piper at "Dec 4, 2 06:57:23 am" To: ddp@electric-loft.org (Derrell Piper) Date: Wed, 4 Dec 2002 08:22:16 -0800 (PST) Cc: touch@ISI.EDU, mjh@icir.org, shicai@cryptek.com, ipsec@lists.tislabs.com, pkoning@equallogic.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % No kidding. There's some value in most every draft, however small. I % can't count the number of working group sessions I've been to where % people are discussing some aspect of some expired ID. Unless you were % around at the exact right time, it's ridiculously hard to find out what % they're talking about. The history of many working groups is encoded % in their expired ID's. "Those who forget history..." % % Derrell % % On Wednesday, December 4, 2002, at 06:17 AM, Paul Koning wrote: % % > Off topic for this list, I admit, but in my opinion that policy is a % > major mistake. it may be useful to note that while the intent/purpose of IDs have not changed, RFCs have. Most of what show up in IDs really should be published as RFCs. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Wed Dec 4 10:07:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4I7Zg11603; Wed, 4 Dec 2002 10:07:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18331 Wed, 4 Dec 2002 12:31:56 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3DEE3706.15ECB1CD@bell-labs.com> Date: Wed, 04 Dec 2002 12:10:30 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Derrell Piper Original-CC: ipsec@lists.tislabs.com Subject: Re: How does IKEv2 provide solution to remote access? References: <58FB56AE-0737-11D7-BBA0-000393CDFD1A@electric-loft.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell Piper wrote: > I agree completely. To be useful IKEv2 needs to address remote access. > Remote access is essentially the driving factor behind IPSec gateway > sales........ Yes! - and more: > ...Without these features, people simply will not deploy IKEv2 to replace > IKEv1 because they won't be able to do what they want to do -- surf > their corporate intranets........... > I don't know about the rest of you, but I want to be able to use that > cable modem sitting on the desks of the Marriott's and the W's of the > world to log in back home securely using IPSec. And so do all of the > business travelers of the world.........Network administrators > simply will not reconfigure their entire network to introduce IPSec > into it. They want to assign internal 10-net addresses to clients so > legacy IP-based access control schemes continue to work as well as (or > as poorly as) they have ever worked. They want their clients to use > Radius passwords and/or SecurID cards to log in and for once they also > want this part to be secure! You can even go so far as to ship a > product with a built-in CA and they'll still insist on using passwords, > trust me. On paswords - or more likely, something like SecureID or SecureNetKey cards... More importantly - these features ARE available now! Except that they are implemented in a proprietary non-interoperable way. > Make no mistake: they want this, they (think they) need this, and they > won't deploy this technology without it. Absolutely. Especially since the EXISTING DEPLOYED stuff supports it. > It seems we have three obvious paths: 1) ignore the problem; 2) release > an initial IKEv2 draft to meet Jeff's February deadline followed by a > quick revision with remote access additions; 3) wait until we've got it > all and release just one draft. Given my belief that this needs to be > included, and given Jeff's challenge, the question I think we ought to > be resolving now is: so what's the viability and risk/reward of doing > #2 vs. #3? I'd say the main draft SHOULD contain the opening for remote access. The details, if not ready by February, can be furnished later, not to hold the main draft up. If at all possible and feasible given the limited time - I'd much prefer to see #3 but by February time-frame. From owner-ipsec@lists.tislabs.com Wed Dec 4 10:07:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4I7ug11630; Wed, 4 Dec 2002 10:07:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18340 Wed, 4 Dec 2002 12:32:57 -0500 (EST) Cc: Derrell Piper , "Cmadson@Cisco.Com" , ipsec@lists.tislabs.com Message-ID: <3DEE3809.E0D3C657@bell-labs.com> Date: Wed, 04 Dec 2002 12:14:49 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephane Beaulieu Original-CC: Derrell Piper , "Cmadson@Cisco.Com" , ipsec@lists.tislabs.com Subject: Re: Requirements (was: How does IKEv2 provide solution to remote access?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane Beaulieu wrote: > > I agree completely. To be useful IKEv2 needs to address remote access. > > FWIW, this was all discussed in Atlanta and it seemed we had concensus on > it. The plan is to try and roll this into the next rev of IKEv2. > > Cheryl had put out a requirements draft a while ago which included these > things and a few more. At the time, it was largely ignored because of the > IKEv2 vs. JFK discussions. Should we attempt to revive this and move it > ahead in the WG to make sure we don't forget anyting else??? YES. Emphatic yes. > ....If we've > forgotten something in the requirements, I'd rather find out about it now > rather than summer '2003. (:-) With you. From owner-ipsec@lists.tislabs.com Wed Dec 4 10:46:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4IkIg13721; Wed, 4 Dec 2002 10:46:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18513 Wed, 4 Dec 2002 13:16:46 -0500 (EST) Message-Id: <200212041817.gB4IHDr5003480@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 transport concerns In-reply-to: Your message of "Wed, 04 Dec 2002 02:37:42 EST." <277DD60FB639D511AC0400B0D068B71E0564C5EC@corpmx14.us.dg.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 04 Dec 2002 13:17:12 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Black" == Black David writes: Black> Depends on the protocol. RSVP certainly could be forwarded in principle Black> (need an SPD that understands protocol 46, or an encapsulation of some Black> form), although this may raise orthogonal issues about whether the tunnel Black> presents routable interfaces if the RSVP path extends beyond the tunnel Black> endpoints. OTOH, there's been discussion of out-of-band protocols for Black> bandwidth brokers and the like that probably wouldn't go through the tunnel. >> Are there signaling protocols which an end systems can use to control >> QoS >> *towards* them? If so, how does the end system have the return stream of >> the >> tunnel properly signaled? Black> An instance of RSVP running the other way is one possibility, although Black> it requires serious cooperation from the other end of the tunnel. L2TP's Black> diffserv extension (RFC 3308) may be useful when L2TP is in the stack. I take this as: no, there are no existing protocols that permit an end system to control bandwidth to it. The ability to do this kind of thing is going to be critical when it comes to dealing with DDoS attacks - select the traffic you WANT, bump it up, and let RED deal with the rest. It will have to interact well with tunnels. >> Other than RSVP, what else is there at present? (I'm >> certainly out of touch). Black> Not much. In addition to RFC 3308, the nsis WG may produce something, Black> and there's been all sorts of other possibilities discussed, but no Black> RFCs that I can point to. Maybe, after term on nomcom is over, I can pay attention to that. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPe5GpYqHRg3pndX9AQGMCAP+MIge59pppji3aPFBTnObrtNcigRYeZ2v 9bMk5yfZ64jHDaawIetnIeEg+v8Hf90drYsHUvJjZescczKzx7tKujCInIIw1AFR HbGaNaMPhMsJggNWYzYyHt0WJbH/3VotzTZtWvL7eFCSE8VyWpv/BUBmFmGiZxrA 0Nqwlru8Rgo= =9S+y -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 4 21:55:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB55tFg25211; Wed, 4 Dec 2002 21:55:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19496 Thu, 5 Dec 2002 00:21:13 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200212050522.gB55M2q07602@sydney.East.Sun.COM> Date: Thu, 5 Dec 2002 00:22:17 -0500 To: Cc: Reply-To: Subject: X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm always urging mailing lists to have someone summarize a thread that has gone on for awhile, so I'll try to do so in this case. The intention is that this email will enable everyone to catch up with all the arguments, so they wouldn't need to read any earlier emails on the thread. If anyone thinks I missed anything, or got anything wrong, then feel free to correct me, and if the thread gets long after this summary, we can do another summary. But I'd like the WG to be able to clearly reach consensus on these issues. Basically, the argument is whether the key derivation should be the Way It Is Now (which I'll call WIIN) or a different way, which l'll call SD for "Something Different". A summary of WIIN: SKEYSEED is HMAC of the nonces and the D-H value The first 160 bits of key for the IKE-SA is HMAC of SKEYSEED, the nonces, the cookies, the one byte constant "1" The next 160 bits of key is HMAC of SKEYSEED, the previous 160 bits of key, the nonces, and the cookies, with the one byte constant incrementing for each block of key and so on The first 160 bits is also called SK_d, and is used in the computation of the keying material for child-SAs Keying material for child-SAs is: each 160 bits is HMAC (SK_d, {previous 160 bits of key except for first block}, child-SA's nonces, [child-SA's DH], counter) ****************** The objections to WIIN are: . performance: HMAC is, (approximately) two hashes, so on small quantities (like here) it's twice as slow as a hash. The argument is that SD could use any hash, e.g., SHA-1, with twice the performance. The counter-argument is that the performance of doing twice as many hashes is negligible compared to D-H. . security: WIIN, no matter what the entropy of the input (e.g., a 2048 bit D-H value), only generates 160 bits of entropy for the keys. This is because the only secret value is SKEYSEED, which is 160 bits, which generates all the rest of the keying bits. The argument is that SD could get more bits by putting the D-H value, or parts of it, into each block of key derived. This somewhat impacts the performance argument, of course, because SHA of something which is twice as many blocks long is twice the work. The counter argument is that who needs more than 160 bits of entropy, and if you do, use HMAC using SHA-256. . ease of understanding: (this is my opinion, and was not expressed in the thread, but I guess I'll throw it in). I found it very confusing having the stuff specified as a prf, with exactly two inputs, one "secret" and one not, so that one had to figure out for each input whether it ought to be considered secret or not, and concatenating all the secret values together to form one input, and all the nonsecret ones together to form the other input. It would have taken fewer reads of the spec, and fewer ibuprofen tablets for me, if it had merely been expressed as a hash of n inputs. ******************************* The arguments for WIIN are: There is a well-known problem with using a keyed hash such as SHA or MD5 that if one knows the value of the hash of (key,data), one can append stuff to the end of the data and compute the correct hash of the bigger message without knowing the key. That is the rationale for using HMAC. If one gets in the habit of using HMAC, you won't "accidentally" have that problem. However, in all the uses of HMAC in IKE, the appending attack is not relevant or not possible (for instance, because the encoding does not allow extra stuff appended without modifying the message, since the final payload would have said "this is the final payload". And in computation of the keying material it's totally irrelevant. No attacker sees the intermediate values. Another argument for WIIN is that HMAC is already used in so many other places in IKE, that for ease of coding, it should be used everywhere. The counter-argument to this is that HMAC requires SHA, so SHA has to be there anyway, and one could argue (I did in the previous paragraph) that IKE doesn't really need HMAC at all. ********************** So, it's not fair to compare a concrete proposal with envisioned properties of an ideal protocol, especially with just a few months before we'd the spec done. Russ Housley's proposal meets the desire of twice-the-performance, but at the same security level (not getting more than 160 bits of entropy, unless you go to SHA-2). His proposal is to replace each instance of HMAC with SHA-1. If we wanted to make it more secure, instead of computing SKEYSEED to compress the initial bits down to the size of a block, we could throw the D-H value, or parts of it, into each block of keying material computation. This would make more bits to hash, so could wind up losing on the performance argument. ****************** Anyway, hopefully people will find this summary useful, so that people can express opinions. I suspect Charlie will vote for not changing things, since he has an awful lot of editing to do in not much time (including legacy authentication, and the NAT traversal stuff is wonderously quirky and complicated). But I think the possibilities are: a) leave it as it is b) replace HMAC with SHA-1, thereby increasing performance, but not changing the security properties c) design something that has enhanced security, but does not attempt to simultaneously enhance performance (might even be slower) d) design something that meets both the enhanced performance, and enhanced security goals. Radia From owner-ipsec@lists.tislabs.com Wed Dec 4 21:55:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB55tMg25235; Wed, 4 Dec 2002 21:55:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19502 Thu, 5 Dec 2002 00:27:19 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200212050527.gB55Rfq07783@sydney.East.Sun.COM> Date: Thu, 5 Dec 2002 00:27:58 -0500 To: Cc: Reply-To: Subject: Summary of key derivation thread X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry about that...forgot to put a subject line on my previous post...my excuse is that it's after midnight, and my mailer crashed once in the middle. Anyway, here's a repeat of my previous note, so people can have a note with the proper subject line. ************************** I'm always urging mailing lists to have someone summarize a thread that has gone on for awhile, so I'll try to do so in this case. The intention is that this email will enable everyone to catch up with all the arguments, so they wouldn't need to read any earlier emails on the thread. If anyone thinks I missed anything, or got anything wrong, then feel free to correct me, and if the thread gets long after this summary, we can do another summary. But I'd like the WG to be able to clearly reach consensus on these issues. Basically, the argument is whether the key derivation should be the Way It Is Now (which I'll call WIIN) or a different way, which l'll call SD for "Something Different". A summary of WIIN: SKEYSEED is HMAC of the nonces and the D-H value The first 160 bits of key for the IKE-SA is HMAC of SKEYSEED, the nonces, the cookies, the one byte constant "1" The next 160 bits of key is HMAC of SKEYSEED, the previous 160 bits of key, the nonces, and the cookies, with the one byte constant incrementing for each block of key and so on The first 160 bits is also called SK_d, and is used in the computation of the keying material for child-SAs Keying material for child-SAs is: each 160 bits is HMAC (SK_d, {previous 160 bits of key except for first block}, child-SA's nonces, [child-SA's DH], counter) ****************** The objections to WIIN are: . performance: HMAC is, (approximately) two hashes, so on small quantities (like here) it's twice as slow as a hash. The argument is that SD could use any hash, e.g., SHA-1, with twice the performance. The counter-argument is that the performance of doing twice as many hashes is negligible compared to D-H. . security: WIIN, no matter what the entropy of the input (e.g., a 2048 bit D-H value), only generates 160 bits of entropy for the keys. This is because the only secret value is SKEYSEED, which is 160 bits, which generates all the rest of the keying bits. The argument is that SD could get more bits by putting the D-H value, or parts of it, into each block of key derived. This somewhat impacts the performance argument, of course, because SHA of something which is twice as many blocks long is twice the work. The counter argument is that who needs more than 160 bits of entropy, and if you do, use HMAC using SHA-256. . ease of understanding: (this is my opinion, and was not expressed in the thread, but I guess I'll throw it in). I found it very confusing having the stuff specified as a prf, with exactly two inputs, one "secret" and one not, so that one had to figure out for each input whether it ought to be considered secret or not, and concatenating all the secret values together to form one input, and all the nonsecret ones together to form the other input. It would have taken fewer reads of the spec, and fewer ibuprofen tablets for me, if it had merely been expressed as a hash of n inputs. ******************************* The arguments for WIIN are: There is a well-known problem with using a keyed hash such as SHA or MD5 that if one knows the value of the hash of (key,data), one can append stuff to the end of the data and compute the correct hash of the bigger message without knowing the key. That is the rationale for using HMAC. If one gets in the habit of using HMAC, you won't "accidentally" have that problem. However, in all the uses of HMAC in IKE, the appending attack is not relevant or not possible (for instance, because the encoding does not allow extra stuff appended without modifying the message, since the final payload would have said "this is the final payload". And in computation of the keying material it's totally irrelevant. No attacker sees the intermediate values. Another argument for WIIN is that HMAC is already used in so many other places in IKE, that for ease of coding, it should be used everywhere. The counter-argument to this is that HMAC requires SHA, so SHA has to be there anyway, and one could argue (I did in the previous paragraph) that IKE doesn't really need HMAC at all. ********************** So, it's not fair to compare a concrete proposal with envisioned properties of an ideal protocol, especially with just a few months before we'd the spec done. Russ Housley's proposal meets the desire of twice-the-performance, but at the same security level (not getting more than 160 bits of entropy, unless you go to SHA-2). His proposal is to replace each instance of HMAC with SHA-1. If we wanted to make it more secure, instead of computing SKEYSEED to compress the initial bits down to the size of a block, we could throw the D-H value, or parts of it, into each block of keying material computation. This would make more bits to hash, so could wind up losing on the performance argument. ****************** Anyway, hopefully people will find this summary useful, so that people can express opinions. I suspect Charlie will vote for not changing things, since he has an awful lot of editing to do in not much time (including legacy authentication, and the NAT traversal stuff is wonderously quirky and complicated). But I think the possibilities are: a) leave it as it is b) replace HMAC with SHA-1, thereby increasing performance, but not changing the security properties c) design something that has enhanced security, but does not attempt to simultaneously enhance performance (might even be slower) d) design something that meets both the enhanced performance, and enhanced security goals. Radia From owner-ipsec@lists.tislabs.com Thu Dec 5 04:53:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5CrXg11563; Thu, 5 Dec 2002 04:53:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA20261 Thu, 5 Dec 2002 07:16:49 -0500 (EST) Message-ID: From: Harshwardhan Mittal To: ipsec@lists.tislabs.com Subject: difference in IKE main and aggressive mode Date: Thu, 5 Dec 2002 17:26:54 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all What is the main difference in terms of security in IKE v1 main and aggressive mode? Is it mandatory to use main mode? Thanks & regards Harsh ---------------------------------------------------------------------------- Harsh Mittal Software Engineer Motorola India Electronics Ltd. Hyderabad, India. ************************************************** [ ] General Business Information [X ] Motorola Internal Use only [ ] Motorola Confidential Proprietary **************************************************** From owner-ipsec@lists.tislabs.com Thu Dec 5 06:09:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5E9Yg15824; Thu, 5 Dec 2002 06:09:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20511 Thu, 5 Dec 2002 08:31:36 -0500 (EST) X-Originating-IP: [64.230.105.19] From: "Andrew Krywaniuk" To: hugo@ee.technion.ac.il Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation Date: Thu, 05 Dec 2002 00:59:04 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Dec 2002 05:59:04.0578 (UTC) FILETIME=[6A95B620:01C29C23] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > T1 = HMAC-SHA1(0x00 | K, S) > > T2 = HMAC-SHA1(0x01 | K, T1 | S) > > T3 = HMAC-SHA1(0x02 | K, T2 | S | > > T4 = HMAC-SHA1(0x03 | K, T3 | S ) > >This doesn't help at all. You can still find K in 2^160 operations >(note that a guess can always be validated via the derived keys which >produce visible outputs in the protocol). This may be a tangent, but I just don't see how the above claim could be correct. >There is no silliness here. >And, as I said, for those that want >160 bits there are longer key hash >functions to use The issue is that the new hash functions (such as SHA-2) are slow, and no one wants to implement them solely for the purpose of key derivation (since no one is asking for a stronger per-packet hash). Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-ipsec@lists.tislabs.com Thu Dec 5 06:59:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5ExVg17437; Thu, 5 Dec 2002 06:59:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20627 Thu, 5 Dec 2002 09:27:46 -0500 (EST) Date: Thu, 5 Dec 2002 09:28:47 -0500 From: Ran Canetti Message-Id: <200212051428.JAA34568@ornavella.watson.ibm.com> To: Radia.Perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Summary of key derivation thread Cc: radia.perlman@sun.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia, Thanks for summing things up. I agree that we shouldn't change the current key derivation mechanism. But my argument is not that "this is how it is so let's not bother changing". Rather, the argument is that "from an analytic point of view, this method is superior to other methods." See mre details below. > Anyway, hopefully people will find this summary useful, so that people > can express opinions. I suspect Charlie will vote for not changing > things, since he has an awful lot of editing to do in not much time > (including legacy authentication, and the NAT traversal > stuff is wonderously quirky and complicated). But I think the > possibilities are: > > a) leave it as it is > b) replace HMAC with SHA-1, thereby increasing performance, but not > changing the security properties I strongly disagree with this statement. Let me try to explain. (In fact, I remember writing similar things on this list in 96, when IKEv1 was dsigned...) It is true that today we don't know of any attack on the protocol that would be made possible by replacing the PRF in the key derivation with simple SHA1. However, by making this transition you "in one blow" lose much of the analytical and mathematical basis for the security of IKE. We will no longer be able to claim that "the design of IKE is provably secure under reasonable and standard assumptions on the hash function in use". I don't think we can allow ourselves to lose this analytical basis in a standard that is indended for wide use. > c) design something that has enhanced security, but does not attempt > to simultaneously enhance performance (might even be slower) > d) design something that meets both the enhanced performance, and > enhanced security goals. > > Radia > > Regarding: > ease of understanding: (this is my opinion, and was not expressed > in the thread, but I guess I'll throw it in). I found it very > confusing having the stuff specified as a prf, with exactly two > inputs, one "secret" and one not, so that one had to figure > out for each input whether it ought to be considered secret or > not, and concatenating all the secret values together to form > one input, and all the nonsecret ones together to form the > other input. It would have taken fewer reads of the spec, and > fewer ibuprofen tablets for me, if it had merely been expressed as > a hash of n inputs. I agree that it would be great to able to treat all inputs to the "key derivation function" on equal terms, and not worry about which is secret and which is not. Unfortunately, the only way we have today to derive keys in a way that is analytically sound (ie, in a way that can be proven to be secure based on reasonable assumptions on the underlying hash functions) is by having this split into two types of input: -A secret input, that is assumed to be random. (we call this input the "key".) -An input that is not necessarily secret and not necessarily random. It's a great research problem to find a way to do what you want while maintaining provability. But until we have that, I suggest that the current method will end up minimizing your consumption of ibuprofen. Ran BTW, regrading going over 160 "bits of security". I agree that this is a non-issue from a practical point of view. But for the paranoids who insist on doing it, the best way would be to use a PRF with more security, such as HMAC-SHA2, or any block cipher with long enough keys and block-size. > > From owner-ipsec@lists.tislabs.com Thu Dec 5 07:47:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5Fl3g22700; Thu, 5 Dec 2002 07:47:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20805 Thu, 5 Dec 2002 10:16:50 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Apologies for being unresponsive To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Thu, 5 Dec 2002 10:14:43 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/05/2002 10:17:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At this critical time for getting things integrated into the IKEv2 spec, I just learned that for the last 11 days a bug in my mailer has been hiding a large fraction of my incoming mail. I believe I've gotten everything sent to the list, but if any of you have sent me private email I probably haven't seen it. I'm told the problem will be fixed soon, and that I will *probably* get all the lost mail, but it hasn't been fixed yet. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Thu Dec 5 07:57:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5Fvpg23877; Thu, 5 Dec 2002 07:57:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20848 Thu, 5 Dec 2002 10:30:03 -0500 (EST) Message-ID: From: Suresh Iyer To: ipsec@lists.tislabs.com Subject: question on IKE between HA & FA in 3GPP standard... Date: Thu, 5 Dec 2002 10:29:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am trying to identify the requirements for IKE between Foreign Agent & Home Agent. In the Annex A to the 3GPP2 Wireless IP network standard, 3GPP2 P.S0001-B, it is specified that aggressive mode be used with preshared keys and main mode be used with Certificate authentication. It also specifies that "Signature payload" will not be sent by PDSN (FA) and HA. Does this mean that the certificate authentication is to be done with "public key encryption" and not "signatures"? Suresh Iyer Principal Engineer Megisto Systems Inc Germantown MD-20874 From owner-ipsec@lists.tislabs.com Thu Dec 5 08:24:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5GOYg26409; Thu, 5 Dec 2002 08:24:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20966 Thu, 5 Dec 2002 10:57:10 -0500 (EST) Message-Id: <200212051558.gB5FwXMf021272@thunk.east.sun.com> From: Bill Sommerfeld To: radia.perlman@sun.com cc: ipsec@lists.tislabs.com Subject: Re: Summary of key derivation thread In-Reply-To: Your message of "Thu, 05 Dec 2002 00:27:58 EST." <200212050527.gB55Rfq07783@sydney.East.Sun.COM> Reply-to: sommerfeld@east.sun.com Date: Thu, 05 Dec 2002 10:58:33 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > a) leave it as it is This is where we should go. - for the cryptographers, document (somewhere, perhaps not in the spec but in a separate analysis document) the (currently theoretical) security limitations of WIIN; - make sure the key derivation hash algorithm is changeable in the future if it turns out to be inadequate either in reality or for those who have quantum black helicopters as part of their threat model. - Bill From owner-ipsec@lists.tislabs.com Thu Dec 5 08:43:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5GhYg29616; Thu, 5 Dec 2002 08:43:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21066 Thu, 5 Dec 2002 11:14:48 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 5 Dec 2002 11:12:39 -0500 To: Suresh Iyer From: Stephen Kent Subject: Re: question on IKE between HA & FA in 3GPP standard... Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:29 AM -0500 12/5/02, Suresh Iyer wrote: >Hi, > I am trying to identify the requirements for IKE between Foreign >Agent & Home Agent. >In the Annex A to the 3GPP2 Wireless IP network standard, 3GPP2 P.S0001-B, >it is specified that >aggressive mode be used with preshared keys and main mode be used with >Certificate authentication. > >It also specifies that "Signature payload" will not be sent by PDSN (FA) and >HA. > >Does this mean that the certificate authentication is to be done with >"public key encryption" and not "signatures"? > I'm not familiar with the 3GPP2 spec you cite above, bit in general I advise against using the encryption (vs. signature) option in IKE v1. Note that in IKE v2 we have cleanly separated the key generation and authentication features of the protocol, using public keys from certs only for signatures. I also think that in practice IKE v1 implementation usually opt for the signature (vs. encryption) approach to authentication when public keys are employed. Steve From owner-ipsec@lists.tislabs.com Thu Dec 5 09:24:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5HOvg03072; Thu, 5 Dec 2002 09:24:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21234 Thu, 5 Dec 2002 11:54:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E08441061@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E08441061@corpmx14.us.dg.com> Date: Thu, 5 Dec 2002 11:46:43 -0500 To: Black_David@emc.com From: Stephen Kent Subject: RE: IKEv2 transport concerns Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:06 PM -0500 12/3/02, Black_David@emc.com wrote: > > >>>>> "Black" == Black David writes: >> Black> (1) Any system running IKEv2 is REQUIRED to handle ECN >(Explicit >> >> I think that this may be misplaced. I think that RFC2401bis is where >> to say this. > >I think it needs to be in both places. We have a one-time opportunity >to avoid the IKEv1 ECN negotiation kludge if all IKEv2 implementations >are REQUIRED to handle ECN correctly at tunnel egress. IMHO, this >outcome is important enough to merit specifying the means of achieving >it in both the IKEv2 and RFC2401bis documents. If we wind up dealing >with IKEv2 systems that get this wrong, the negotiation kludge will be >with us for much longer ... David, I don't think the IKE v2 document is the appropriate place to make note of the ECN handling you refer to, since it applies to the actions performed on the child SAs that IKE establishes, not on the IKE SAs, right? It really is a 2401bis matter, I believe. Steve From owner-ipsec@lists.tislabs.com Thu Dec 5 09:32:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5HWGg03338; Thu, 5 Dec 2002 09:32:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21277 Thu, 5 Dec 2002 12:06:16 -0500 (EST) Date: Thu, 5 Dec 2002 16:09:37 +0100 From: Markus Friedl To: Harshwardhan Mittal Cc: ipsec@lists.tislabs.com Subject: Re: difference in IKE main and aggressive mode Message-ID: <20021205150937.GB8179@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Dec 05, 2002 at 05:26:54PM +0530, Harshwardhan Mittal wrote: > What is the main difference in terms of security in IKE v1 main and > aggressive mode? main mode provides identity protection for both sides. aggressive mode does not, but uses less round trips. From owner-ipsec@lists.tislabs.com Thu Dec 5 09:55:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5HtZg05436; Thu, 5 Dec 2002 09:55:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21412 Thu, 5 Dec 2002 12:29:17 -0500 (EST) Message-ID: From: Suresh Iyer To: "'Stephen Kent'" , Suresh Iyer Cc: ipsec@lists.tislabs.com Subject: RE: question on IKE between HA & FA in 3GPP standard... Date: Thu, 5 Dec 2002 12:28:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Our implementation currently supports signatures. But this standard for Mobile IP requires that the IKE between the Home Agent & Foreign agent use "revised public key encryption" scheme when public key authentication is used. I want to know if anybody else has read this standard and if my understanding of the text is correct. Suresh # -----Original Message----- # From: Stephen Kent [mailto:kent@bbn.com] # Sent: Thursday, December 05, 2002 11:13 AM # To: Suresh Iyer # Cc: ipsec@lists.tislabs.com # Subject: Re: question on IKE between HA & FA in 3GPP standard... # # # At 10:29 AM -0500 12/5/02, Suresh Iyer wrote: # >Hi, # > I am trying to identify the requirements for IKE between Foreign # >Agent & Home Agent. # >In the Annex A to the 3GPP2 Wireless IP network standard, # 3GPP2 P.S0001-B, # >it is specified that # >aggressive mode be used with preshared keys and main mode # be used with # >Certificate authentication. # > # >It also specifies that "Signature payload" will not be sent # by PDSN (FA) and # >HA. # > # >Does this mean that the certificate authentication is to be # done with # >"public key encryption" and not "signatures"? # > # # I'm not familiar with the 3GPP2 spec you cite above, bit in # general I # advise against using the encryption (vs. signature) option # in IKE v1. # Note that in IKE v2 we have cleanly separated the key generation and # authentication features of the protocol, using public keys # from certs # only for signatures. I also think that in practice IKE v1 # implementation usually opt for the signature (vs. encryption) # approach to authentication when public keys are employed. # # Steve # From owner-ipsec@lists.tislabs.com Thu Dec 5 09:55:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5Hthg05463; Thu, 5 Dec 2002 09:55:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21400 Thu, 5 Dec 2002 12:28:13 -0500 (EST) Cc: Radia.Perlman@sun.com, ipsec@lists.tislabs.com Message-ID: <3DEF8A1E.D988B6E3@bell-labs.com> Date: Thu, 05 Dec 2002 12:17:18 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ran Canetti Original-CC: Radia.Perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Summary of key derivation thread References: <200212051428.JAA34568@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ran Canetti wrote: > Thanks for summing things up. > I agree that we shouldn't change the current key derivation > mechanism. But my argument is not that "this is how it is so let's not > bother changing". Rather, the argument is that "from an analytic point of view, > this method is superior to other methods." See mre details below. Absolutely. > > But I think the possibilities are: > > > > a) leave it as it is > > b) replace HMAC with SHA-1, thereby increasing performance, but not > > changing the security properties > > I strongly disagree with this statement.......... > It is true that today we don't know of any attack on the protocol > that would be made possible by replacing the PRF in the key derivation with > simple SHA1. However, by making this transition you "in one blow" lose much > of the analytical and mathematical basis for the security of IKE. > We will no longer be able to claim that "the design of IKE is provably > secure under reasonable and standard assumptions on the hash function in use". Ran, I think you're mixing two independent properties: secure MAC which is proven for HMAC as long as keyed SHA is a secure MAC, and secure PRF. Basically what HMAC proof does (as fas as I understand) is linking the security properties of SHA-1 to chained operations (multi-block). Now, the analysis (as far as I know) was done for the MAC case. There was no analysis done for PRF, and in any case in order to use HMAC as a secure PRF you'd need to assume that SHA is a secure PRF. But if it is so (i.e. if SHA is a secure PRF) - then you don't need the extras that HMAC provides. > I don't think we can allow ourselves to lose this analytical basis in a > standard that is indended for wide use. I don't think that analytical basis is applicable to HMAC as PRF. > BTW, regrading going over 160 "bits of security". I agree that this is a > non-issue from a practical point of view. But for the paranoids who insist > on doing it, the best way would be to use a PRF with more security, such as > HMAC-SHA2, or any block cipher with long enough keys and block-size. It is an issue of convenience and of entropy loss. Regarding the latter - it doesn't make sense to expensively negotiate a kilobit of keying material and then reduce its entropy to 160 bits. From owner-ipsec@lists.tislabs.com Thu Dec 5 09:59:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5Hxsg06243; Thu, 5 Dec 2002 09:59:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21464 Thu, 5 Dec 2002 12:35:28 -0500 (EST) Date: Thu, 5 Dec 2002 10:32:34 -0700 Message-Id: <200212051732.gB5HWYi02920@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: Radia.Perlman@sun.com Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage <200212050527.gB55Rfq07783@sydney.East.Sun.COM> Subject: Re: Summary of key derivation thread Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The high entropy problem can be solved without use of SHA-2. The method I proposed is for condensing the D-H value down to more than one internal key. Call these the CONDKEYs. Each one's length is the length of the output of the hash function. You can use a prf or a hash to derive them, but the prefix to hash must vary for each one. Generate enough CONDKEYs so that their total length exceeds the entropy of the DH exchange. CONDKEY0 = intn_key_func(0x00 | DHVAL, some_other_stuff ) CONDKEY1 = intn_key_func(0x01 | DHVAL, some_other_stuff) ... When deriving a long session key, use the CONDKEYs in sequence: key_func(CONDKEY0, 0x00 | other_stuff) key_func(CONDKEY1, 0x01 | other_stuff) key_func(CONDKEY0, 0x02 | other_stuff) ... For HMAC vs. hash, IKE uses HMAC to its advantage in authentication, and that shouldn't be changed; it seems immaterial whether or not it uses it for key derivation. Hilarie From owner-ipsec@lists.tislabs.com Thu Dec 5 10:55:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5ItPg13356; Thu, 5 Dec 2002 10:55:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21739 Thu, 5 Dec 2002 13:26:18 -0500 (EST) From: Atul.Sharma@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: difference in IKE main and aggressive mode Date: Thu, 5 Dec 2002 13:26:43 -0500 Message-ID: Thread-Topic: difference in IKE main and aggressive mode Thread-Index: AcKchO0DWcSFKvS2RCW2ee3l5eKTnwABRPuQ To: , Cc: X-OriginalArrivalTime: 05 Dec 2002 18:26:44.0609 (UTC) FILETIME=[DD3F3710:01C29C8B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA21733 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: ext Markus Friedl [mailto:markus@openbsd.org] > Sent: Thursday, December 05, 2002 10:10 AM > To: Harshwardhan Mittal > Cc: ipsec@lists.tislabs.com > Subject: Re: difference in IKE main and aggressive mode > > > On Thu, Dec 05, 2002 at 05:26:54PM +0530, Harshwardhan Mittal wrote: > > What is the main difference in terms of security in IKE v1 main and > > aggressive mode? > > main mode provides identity protection for both sides. > > aggressive mode does not, but uses less round trips. Though there is no identity protection in Aggressive mode per se, it can be gotten by use of public key encryption as the authentication method. But this is not an endorsement for Aggressive mode vis-a-vis Main mode. There are other restrictions with Aggressive mode....e.g. SA negotiation is limited: - Cannot negotiate the DH group - when using revised mode of public key encryption, the hash and cipher can not be negotiated From owner-ipsec@lists.tislabs.com Thu Dec 5 13:21:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5LLGg03188; Thu, 5 Dec 2002 13:21:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22291 Thu, 5 Dec 2002 15:48:49 -0500 (EST) Message-Id: <5.2.0.9.2.20021205154612.03789d60@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 05 Dec 2002 15:48:31 -0500 To: "The Purple Streak, Hilarie Orman" From: Russ Housley Subject: Re: Summary of key derivation thread Cc: ipsec@lists.tislabs.com In-Reply-To: <200212051732.gB5HWYi02920@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie: >For HMAC vs. hash, IKE uses HMAC to its advantage in authentication, >and that shouldn't be changed; it seems immaterial whether or not it >uses it for key derivation. I never proposed moving away from HMAC for authentication. This thread started because I observed that the requirements for key derivation and authentication are different. Russ From owner-ipsec@lists.tislabs.com Thu Dec 5 13:26:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5LQLg03375; Thu, 5 Dec 2002 13:26:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22309 Thu, 5 Dec 2002 15:57:57 -0500 (EST) Date: Thu, 5 Dec 2002 22:59:20 +0200 (IST) From: Hugo Krawczyk To: Radia Perlman - Boston Center for Networking cc: IPsec WG Subject: Re: Summary of key derivation thread In-Reply-To: <200212050527.gB55Rfq07783@sydney.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me be a bit rude: the choice is (a) and everything else is noise! The reason for (a) is not that Charlie is busy with specifying other stuff but because it is the technique with best cryptographic foundation and with ZERO practical disadvantages. The only reason to consider other alternatives is only for getting more than 160 bit of security. This is noise since 1) no one needs that (if you do, use the "pigeons technique" that I proposed in a previous message or enhance it by protecting the pigeons with Sommerfeld's quantum black helicopters :) 2) the standard does not force you to do 160-bit security only. The current specification is defined to support stronger derivation algorithms (i.e. stronger prf's). I mentioned SHA2-256 but you can also use AES-CBC-MAC with 192 or 256 bits too as a prf (allowing the support of block cipher-based prf's is one reason that I am AGAINST defining the key derivation in terms of HMAC only as you refer to). Then there is is the issue of using "prepended-key SHA1" instead of HMAC for "performance gain". Since the latter performance is a non issue then it makes no sense to go to weaker than HMAC mechanisms. Especially that I completely disagree that for the MAC applications in IKEv2 prepended SHA1 is as good as HMAC. You argue that based on the specific details of the protocol (e.g. last message has some particular form etc). This is a BAD design approach. The cryptography has to do its work correctly even if some later version of the protocol changes formats! Another pitfall in your arguments is that in the key derivation the attacker does not see the intermediate results. The whole idea of using a prf in key derivation is to make sure that the keys to different algorithms are computationally independent and if the key (say T1) derived for one algorithm is discovered then the other derived keys (SAY T2) are still secure. Finally, I would like to see the summary of the issue to be advil-free. Cryptography has made a lot of progress in the last 20 years. One of them is understanding that adding a key to a hash function is a tricky business. In particular understanding what is the key to the function and what is the input is fundamental for actual security and for analysis. No one said that right cryptography must be intuitive or easy to digest without a deeper understanding of the scientific fundaments. The history of security protocols is full of examples of intuitively correct yet insecure protocols. In particular, the current key derivation is based on the best-analyzed cryptographic techniques that we know today. It includes: 1) smooting the entropy of the DH key to 160 bits via a hash function (heuristically implemented via a prf) 2) using a prf for multiple-key derivation; in particular, making sure that the keys to different algorithms maintain their computational independence. 3) making the security depend on the generic properties of the prf rather in the details of specific functions that may be thought secure today but found insufficiently secure in the future. Back to the bottom line: the only reasonable choice is (a) and the rest is noise. Hugo On Thu, 5 Dec 2002, Radia Perlman - Boston Center for Networking wrote: > Sorry about that...forgot to put a subject line on > my previous post...my excuse is that it's after midnight, > and my mailer crashed once in the middle. Anyway, here's > a repeat of my previous note, so people can have a note > with the proper subject line. > > ************************** > I'm always urging mailing lists to have someone > summarize a thread that has gone on for awhile, so > I'll try to do so in this case. The intention is > that this email will enable everyone to catch up > with all the arguments, so they wouldn't need to > read any earlier emails on the thread. If anyone > thinks I missed anything, or got anything wrong, > then feel free to correct me, and if the thread > gets long after this summary, we can do another > summary. But I'd like the WG to be able to clearly > reach consensus on these issues. > > Basically, the argument is whether the key derivation > should be the Way It Is Now (which I'll call WIIN) > or a different way, which l'll call SD for "Something > Different". > > A summary of WIIN: > SKEYSEED is HMAC of the nonces and the D-H value > The first 160 bits of key for the IKE-SA is HMAC of SKEYSEED, the > nonces, the cookies, the one byte constant "1" > The next 160 bits of key is HMAC of SKEYSEED, the > previous 160 bits of key, the nonces, and > the cookies, with the one byte constant incrementing > for each block of key > and so on > > The first 160 bits is also called SK_d, and is used in > the computation of the keying material for child-SAs > > Keying material for child-SAs is: > each 160 bits is HMAC (SK_d, {previous 160 bits of key except for > first block}, child-SA's nonces, [child-SA's DH], counter) > > ****************** > The objections to WIIN are: > > . performance: HMAC is, (approximately) two hashes, > so on small quantities (like > here) it's twice as slow as a hash. The argument is that SD > could use any hash, e.g., SHA-1, with twice the performance. > The counter-argument is that the performance of doing twice > as many hashes is negligible compared to D-H. > > . security: WIIN, no matter what the entropy of the input (e.g., > a 2048 bit D-H value), only generates 160 bits of entropy > for the keys. This is because the only secret value is SKEYSEED, > which is 160 bits, which generates all the rest of the keying > bits. The argument is that SD could get more bits by putting > the D-H value, or parts of it, into each block of key derived. > This somewhat impacts the performance argument, of course, because > SHA of something which is twice as many blocks long is twice > the work. The counter argument is that who needs more than > 160 bits of entropy, and if you do, use HMAC using SHA-256. > > . ease of understanding: (this is my opinion, and was not expressed > in the thread, but I guess I'll throw it in). I found it very > confusing having the stuff specified as a prf, with exactly two > inputs, one "secret" and one not, so that one had to figure > out for each input whether it ought to be considered secret or > not, and concatenating all the secret values together to form > one input, and all the nonsecret ones together to form the > other input. It would have taken fewer reads of the spec, and > fewer ibuprofen tablets for me, if it had merely been expressed as > a hash of n inputs. > > ******************************* > The arguments for WIIN are: > > There is a well-known problem with using a keyed hash such as SHA or MD5 > that if one knows the value of the hash of (key,data), one can append > stuff to the end of the data and compute the correct hash of the bigger > message without knowing the key. That is the rationale for using HMAC. > If one gets in the habit of using HMAC, you won't "accidentally" have > that problem. However, in all the uses of HMAC in IKE, the appending > attack is not relevant or not possible (for instance, because the > encoding does not allow extra stuff appended without modifying the > message, since the final payload would have said "this is the final > payload". And in computation of the keying material it's totally irrelevant. > No attacker sees the intermediate values. > > Another argument for WIIN is that HMAC is already used in so many other > places in IKE, that for ease of coding, it should be used everywhere. The > counter-argument to this is that HMAC requires SHA, so SHA has to be > there anyway, and one could argue (I did in the previous paragraph) > that IKE doesn't really need HMAC at all. > > ********************** > So, it's not fair to compare a concrete proposal with envisioned > properties of an ideal protocol, especially with just a few months > before we'd the spec done. Russ Housley's proposal meets the > desire of twice-the-performance, but at the same security level > (not getting more than 160 bits of entropy, unless you go to > SHA-2). His proposal is to replace each instance of HMAC with SHA-1. > > If we wanted to make it more secure, instead of computing SKEYSEED > to compress the initial bits down to the size of a block, we could > throw the D-H value, or parts of it, into each block of keying material > computation. This would make more bits to hash, so could wind up > losing on the performance argument. > > ****************** > Anyway, hopefully people will find this summary useful, so that people > can express opinions. I suspect Charlie will vote for not changing > things, since he has an awful lot of editing to do in not much time > (including legacy authentication, and the NAT traversal > stuff is wonderously quirky and complicated). But I think the > possibilities are: > > a) leave it as it is > b) replace HMAC with SHA-1, thereby increasing performance, but not > changing the security properties > c) design something that has enhanced security, but does not attempt > to simultaneously enhance performance (might even be slower) > d) design something that meets both the enhanced performance, and > enhanced security goals. > > Radia > > > > From owner-ipsec@lists.tislabs.com Thu Dec 5 13:38:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5LcQg04304; Thu, 5 Dec 2002 13:38:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22355 Thu, 5 Dec 2002 16:10:15 -0500 (EST) Date: Thu, 5 Dec 2002 23:11:04 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 5 Dec 2002, Andrew Krywaniuk wrote: > > > T1 = HMAC-SHA1(0x00 | K, S) > > > T2 = HMAC-SHA1(0x01 | K, T1 | S) > > > T3 = HMAC-SHA1(0x02 | K, T2 | S | > > > T4 = HMAC-SHA1(0x03 | K, T3 | S ) > > > >This doesn't help at all. You can still find K in 2^160 operations > >(note that a guess can always be validated via the derived keys which > >produce visible outputs in the protocol). > > This may be a tangent, but I just don't see how the above claim could be > correct. Simply because at this point of the jey derivation K=SKEYSEED which is already 160-bit long! > > > >There is no silliness here. > >And, as I said, for those that want >160 bits there are longer key hash > >functions to use > > The issue is that the new hash functions (such as SHA-2) are slow, and no > one wants to implement them solely for the purpose of key derivation (since > no one is asking for a stronger per-packet hash). Come on. Whoever is worried about 2^160 Ccomplexity attack should at least be willing to use a slower hash function. Did you think of what the complexity of using a DH group of > 160 bit of security will be? And you can also use AES-192... Hugo > > Andrew > -------------------------------------- > The odd thing about fairness is when > we strive so hard to be equitable > that we forget to be correct. > > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > From owner-ipsec@lists.tislabs.com Thu Dec 5 13:44:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5LiFg05565; Thu, 5 Dec 2002 13:44:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22374 Thu, 5 Dec 2002 16:11:18 -0500 (EST) From: Atul.Sharma@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: question on IKE between HA & FA in 3GPP standard... Date: Thu, 5 Dec 2002 16:12:36 -0500 Message-ID: Thread-Topic: question on IKE between HA & FA in 3GPP standard... Thread-Index: AcKcd9Ypn/nRxzP3S/2uTqeR0g+yYgAKRKlQ To: , X-OriginalArrivalTime: 05 Dec 2002 21:12:37.0221 (UTC) FILETIME=[09774950:01C29CA3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA22371 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If indeed this is what the document says, "Certificate authentication without Signature Payload", this points to Authentication with a Revised Mode of Public Key Encryption where Certificate payload may be used. You may want to check with the authors of that document to find the rationale behind it. Atul > -----Original Message----- > From: ext Suresh Iyer [mailto:siyer@megisto.com] > Sent: Thursday, December 05, 2002 10:29 AM > To: ipsec@lists.tislabs.com > Subject: question on IKE between HA & FA in 3GPP standard... > > > Hi, > I am trying to identify the requirements for IKE between Foreign > Agent & Home Agent. > In the Annex A to the 3GPP2 Wireless IP network standard, > 3GPP2 P.S0001-B, > it is specified that > aggressive mode be used with preshared keys and main mode be used with > Certificate authentication. > > It also specifies that "Signature payload" will not be sent > by PDSN (FA) and > HA. > > Does this mean that the certificate authentication is to be done with > "public key encryption" and not "signatures"? > > > Suresh Iyer > Principal Engineer > Megisto Systems Inc > Germantown > MD-20874 > From owner-ipsec@lists.tislabs.com Thu Dec 5 14:00:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5M0Rg08850; Thu, 5 Dec 2002 14:00:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22480 Thu, 5 Dec 2002 16:31:04 -0500 (EST) Date: Thu, 5 Dec 2002 23:32:02 +0200 (IST) From: Hugo Krawczyk To: "The Purple Streak, Hilarie Orman" cc: Radia.Perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Summary of key derivation thread In-Reply-To: <200212051732.gB5HWYi02920@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess that by DHVAL you mean g^xy. If you want to involve g^xy in each step of the key derivation do it through the input not the key. Doing it through the key means that you only support prfs with arbitrary-length key. For example you exclude AES, 3-DES, etc. If you include g^xy in the input part then you support all prfs. Now, while I agree that by puting g^xy in the input to the prf you increase the work factor for an exhaustive search, you must also be aware that by doing so you also open the design to potential shortcut attacks on the prf. The theory of prf's shows that it is unadvisable (and sometimes insecure) to use the same quantity (in this case g^xy) to derive both the key and the input to the prf. Expanding on this issue would require a long academic discussin. The bottom line is: I would not strengthen the scheme against 2^160 exhaustive search and open the scheme to other vuknerabilities (which are of theoretical nature today but may be practical tomorrow). And, AGAIN, if 2^160 is not enough for you then use stronger prfs!!!! Am I repeating myself? Hugo On Thu, 5 Dec 2002, The Purple Streak, Hilarie Orman wrote: > The high entropy problem can be solved without use of SHA-2. The > method I proposed is for condensing the D-H value down to more than > one internal key. Call these the CONDKEYs. Each one's length is the > length of the output of the hash function. You can use a prf or a > hash to derive them, but the prefix to hash must vary for each one. > Generate enough CONDKEYs so that their total length exceeds the entropy > of the DH exchange. > > CONDKEY0 = intn_key_func(0x00 | DHVAL, some_other_stuff ) > CONDKEY1 = intn_key_func(0x01 | DHVAL, some_other_stuff) > ... > > When deriving a long session key, use the CONDKEYs in sequence: > > key_func(CONDKEY0, 0x00 | other_stuff) > key_func(CONDKEY1, 0x01 | other_stuff) > key_func(CONDKEY0, 0x02 | other_stuff) > ... > > For HMAC vs. hash, IKE uses HMAC to its advantage in authentication, > and that shouldn't be changed; it seems immaterial whether or not it > uses it for key derivation. > > Hilarie > From owner-ipsec@lists.tislabs.com Thu Dec 5 14:54:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5Msig10901; Thu, 5 Dec 2002 14:54:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22659 Thu, 5 Dec 2002 17:22:09 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Date: 5 Dec 2002 22:00:36 GMT Organization: University of California, Berkeley Lines: 4 Distribution: isaac Message-ID: References: <200212050522.gB55M2q07602@sydney.East.Sun.COM> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1039125636 30306 128.32.153.211 (5 Dec 2002 22:00:36 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 5 Dec 2002 22:00:36 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the summary. I strongly support leaving it the Way It Is Now, for all the reasons Radia explained. (I think the arguments are in favor are so compelling they don't need to be repeated again.) From owner-ipsec@lists.tislabs.com Thu Dec 5 15:31:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5NVGg13934; Thu, 5 Dec 2002 15:31:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22795 Thu, 5 Dec 2002 18:01:50 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Summary of key derivation thread Date: 5 Dec 2002 22:40:34 GMT Organization: University of California, Berkeley Lines: 22 Distribution: isaac Message-ID: References: <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1039128034 30936 128.32.153.211 (5 Dec 2002 22:40:34 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 5 Dec 2002 22:40:34 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal wrote: >Ran Canetti wrote: >> BTW, regrading going over 160 "bits of security". I agree that this is a >> non-issue from a practical point of view. But for the paranoids who insist >> on doing it, the best way would be to use a PRF with more security, such as >> HMAC-SHA2, or any block cipher with long enough keys and block-size. > >It is an issue of convenience and of entropy loss. Regarding the >latter - it >doesn't make sense to expensively negotiate a kilobit of keying >material and >then reduce its entropy to 160 bits. This objection has already been addressed on the list. Those 1024 bits of Diffie-Hellman only have 160 bits of strength (160 bits of "computational entropy"), hence you're not reducing security by hashing it down to 160 bits. Indeed, in some sense you are improving security by hashing the 1024-bit Diffie-Hellman result down to a 160-bit security, just as Hugo's earlier note pointed out. Can I encourage you to re-read Hugo's earlier emails on this topic? I hope you will find them persuasive. (I certainly did.) From owner-ipsec@lists.tislabs.com Thu Dec 5 15:32:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5NWLg13974; Thu, 5 Dec 2002 15:32:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22789 Thu, 5 Dec 2002 18:00:45 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Summary of key derivation thread Date: 5 Dec 2002 22:38:35 GMT Organization: University of California, Berkeley Lines: 45 Distribution: isaac Message-ID: References: <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1039127915 30936 128.32.153.211 (5 Dec 2002 22:38:35 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 5 Dec 2002 22:38:35 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal wrote: >Now, the analysis (as far as I know) was done for the MAC case. There >was no analysis done for PRF, and in any case in order to use HMAC as >a secure PRF you'd need to assume that SHA is a secure PRF. But if it >is so (i.e. if SHA is a secure PRF) - then you don't need the extras >that HMAC provides. Uri, That's not correct. It is reasonable to view HMAC as a PRF, but it is not reasonable to view SHA as a secure PRF (actually, I'm not sure what the latter would mean, but it doesn't matter). Anyway, what you say is wrong. There are good reasons to use SHA-HMAC instead of plain SHA in this setting. I've explained this before, but I'll do it again. Let me cut-and-paste from an earlier email to you: : It's true that the original Bellare/Canetti/Krawczyk paper only : gave security theorems for HMAC as a MAC, and didn't analyze HMAC : as a PRF. However, it's not too hard to adapt their theorems. : Basically, if the keyed compression function is a secure PRF : on single-block messages and the hash function keyed by the IV is : weakly collision-resistant, then NMAC is a secure PRF. The : results should be similar for HMAC. I agree that this is not : proven explicitly in the BCK paper, but it should be easy to show. : : One could ask how reasonable it is to assume that the compression : function (when keyed by using the key as its IV) is a secure PRF : and not just a secure MAC. However, it seems like a fairly : reasonable assumption, and so what folks are doing in practice : seems fairly supportable by the theory. Note that the above argument requires only the assumption that SHA's compression function acts as a secure PRF *for single-block messages*. No assumption is made about whether SHA is a secure PRF (whatever that would mean) for *multiple-block* messages. Since IKE might potentially use SHA on messages long enough that they don't fit in a single block, this distinction is important. Again, let me express my opinion that Hugo and Ran are (as usual) 100% correct. They've hit the nail on the head here. -- David From owner-ipsec@lists.tislabs.com Thu Dec 5 16:05:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB604xg14646; Thu, 5 Dec 2002 16:05:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22919 Thu, 5 Dec 2002 18:36:21 -0500 (EST) Date: Fri, 6 Dec 2002 01:37:15 +0200 (IST) From: Hugo Krawczyk To: Uri Blumenthal cc: Ran Canetti , Radia.Perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Summary of key derivation thread In-Reply-To: <3DEF8A1E.D988B6E3@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Ran, I think you're mixing two independent properties: secure MAC > which > is proven for HMAC as long as keyed SHA is a secure MAC, and secure > PRF. > Basically what HMAC proof does (as fas as I understand) is linking the > security properties of SHA-1 to chained operations (multi-block). > > > Now, the analysis (as far as I know) was done for the MAC case. There > was no analysis done for PRF, There is: Bellare, M., Canetti, R., and Krawczyk, H., ``Pseudorandom Functions Revisited: The Cascade Construction". {\sl Proc. of the 37th IEEE Symp. on Foundation of Computer Science}, 1996, pp.~514--523. > and in any case in order to use HMAC as > a secure PRF you'd need to assume that SHA is a secure PRF. But if it > is so (i.e. if SHA is a secure PRF) - then you don't need the extras > that HMAC provides. This is not correct. For the pseudo-randomness of HMAC it sufffices to assume (following the above paper) that the compression function of SHA1 when keyed through the IV is a prf. However, this property is not sufficient to make other keyed versions of SHA1 secure. In particular, prepended-key SHA1 is insecure as a prf EVEN IF the compression function is a perfect random function. > > > I don't think we can allow ourselves to lose this analytical basis in a > > standard that is indended for wide use. > > I don't think that analytical basis is applicable to HMAC as PRF. > It is through the above cited work, not through the HMAC paper (crypto'96) In particular the analysis for the prf case is not as straightforward as for the case of MAC. > > > BTW, regrading going over 160 "bits of security". I agree that this is a > > non-issue from a practical point of view. But for the paranoids who insist > > on doing it, the best way would be to use a PRF with more security, such as > > HMAC-SHA2, or any block cipher with long enough keys and block-size. > > It is an issue of convenience and of entropy loss. Regarding the > latter - it > doesn't make sense to expensively negotiate a kilobit of keying > material and > then reduce its entropy to 160 bits. > It does make sense. The 1 kilobit of keying material does NOT mean that you have 1 kilobit of security. Indeed the discrete log problem with a 1024-bit prime is breakable with a mere 2^90 operations (or less). Using the kilobit of key means that you may be using insecure bits. For example, under some groups some bits (e.g lsb) of the DH key are predictable. I repeat: smoothing the computational entropy of the DH key via hashing is a sound practice backed by theoretical results. Hugo > From owner-ipsec@lists.tislabs.com Fri Dec 6 00:20:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB68Kig19894; Fri, 6 Dec 2002 00:20:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA23880 Fri, 6 Dec 2002 02:44:54 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C5FD@corpmx14.us.dg.com> To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: IKEv2 transport concerns Date: Fri, 6 Dec 2002 02:45:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > At 7:06 PM -0500 12/3/02, Black_David@emc.com wrote: > > > >>>>> "Black" == Black David writes: > >> Black> (1) Any system running IKEv2 is REQUIRED to handle ECN > >(Explicit > >> > >> I think that this may be misplaced. I think that RFC2401bis is where > >> to say this. > > > >I think it needs to be in both places. We have a one-time opportunity > >to avoid the IKEv1 ECN negotiation kludge if all IKEv2 implementations > >are REQUIRED to handle ECN correctly at tunnel egress. IMHO, this > >outcome is important enough to merit specifying the means of achieving > >it in both the IKEv2 and RFC2401bis documents. If we wind up dealing > >with IKEv2 systems that get this wrong, the negotiation kludge will be > >with us for much longer ... > > David, > > I don't think the IKE v2 document is the appropriate place to make > note of the ECN handling you refer to, since it applies to the > actions performed on the child SAs that IKE establishes, not on the > IKE SAs, right? It really is a 2401bis matter, I believe. > > Steve Will 2401bis progress on a timeline that will allow a normative reference to it from IKEv2? If so having IKEv2 say "MUST do ECN right, see 2401bis for details" would be fine. I'm concerned that no mention of this at all in IKEv2 implicitly allows IKEv2 to negotiate 2401classic style tunnel handling of ECN, and that would be unfortunate. Thanks, --David From owner-ipsec@lists.tislabs.com Fri Dec 6 07:51:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Foxg01515; Fri, 6 Dec 2002 07:50:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24597 Fri, 6 Dec 2002 10:14:17 -0500 (EST) Date: Fri, 6 Dec 2002 00:57:49 +0100 From: Hans-Joerg Hoexer To: Atul.Sharma@nokia.com Cc: markus@openbsd.org, mittal@mihy.mot.com, ipsec@lists.tislabs.com Subject: Re: difference in IKE main and aggressive mode Message-ID: <20021205235749.GA15675@yerbouti.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Operating-System: OpenBSD yerbouti.as10.net 3.2 GENERIC X-PGP-key: 0x513aefd9 X-PGP-Key-FingerPrint: 83D2 436A 0D3C 34A9 E0FF 4C33 35F6 617C 513A EFD9 X-Sender: 520070797860-0001@t-dialin.net Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, On Thu, Dec 05, 2002 at 01:26:43PM -0500, Atul.Sharma@nokia.com wrote: > ... > There are other restrictions with Aggressive mode....e.g. SA negotiation > is limited: > - Cannot negotiate the DH group > - when using revised mode of public key encryption, the hash and cipher > can not be negotiated ISAKMP/IKE's weak cookie mechanism is rendered completly useless with aggressive mode. Cheers, Hans -- pub 1024D/513AEFD9 1999-12-18 Hans-Joerg Hoexer Key fingerprint = 83D2 436A 0D3C 34A9 E0FF 4C33 35F6 617C 513A EFD9 From owner-ipsec@lists.tislabs.com Fri Dec 6 07:51:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Fp3g01540; Fri, 6 Dec 2002 07:51:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24617 Fri, 6 Dec 2002 10:15:26 -0500 (EST) Cc: ipsec@lists.tislabs.com Message-ID: <3DF0557D.2314FC80@bell-labs.com> Date: Fri, 06 Dec 2002 02:45:01 -0500 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: David Wagner Original-CC: ipsec@lists.tislabs.com Subject: Re: Summary of key derivation thread References: <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Wagner wrote: > That's not correct. It is reasonable to view HMAC as a PRF, > but it is not reasonable to view SHA as a secure PRF....... Because of single-block vs. multiple-block issues? I.e. you assume that keyed compresson function of SHA is PRF for *single block*, and extend it via HMAC to multiple-block input? > Again, let me express my opinion that Hugo and Ran are (as usual) > 100% correct. They've hit the nail on the head here. (:-) From owner-ipsec@lists.tislabs.com Fri Dec 6 07:51:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6FpDg01574; Fri, 6 Dec 2002 07:51:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24614 Fri, 6 Dec 2002 10:15:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C5FD@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564C5FD@corpmx14.us.dg.com> Date: Fri, 6 Dec 2002 10:16:43 -0500 To: Black_David@emc.com From: Stephen Kent Subject: RE: IKEv2 transport concerns Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:45 AM -0500 12/6/02, Black_David@emc.com wrote: > > At 7:06 PM -0500 12/3/02, Black_David@emc.com wrote: >> > > >>>>> "Black" == Black David writes: >> >> Black> (1) Any system running IKEv2 is REQUIRED to handle ECN >> >(Explicit >> >> >> >> I think that this may be misplaced. I think that RFC2401bis is where >> >> to say this. >> > >> >I think it needs to be in both places. We have a one-time opportunity >> >to avoid the IKEv1 ECN negotiation kludge if all IKEv2 implementations >> >are REQUIRED to handle ECN correctly at tunnel egress. IMHO, this >> >outcome is important enough to merit specifying the means of achieving >> >it in both the IKEv2 and RFC2401bis documents. If we wind up dealing >> >with IKEv2 systems that get this wrong, the negotiation kludge will be >> >with us for much longer ... >> >> David, >> >> I don't think the IKE v2 document is the appropriate place to make >> note of the ECN handling you refer to, since it applies to the >> actions performed on the child SAs that IKE establishes, not on the >> IKE SAs, right? It really is a 2401bis matter, I believe. >> >> Steve > >Will 2401bis progress on a timeline that will allow a normative reference >to it from IKEv2? If so having IKEv2 say "MUST do ECN right, see 2401bis >for details" would be fine. I'm concerned that no mention of this at all in >IKEv2 implicitly allows IKEv2 to negotiate 2401classic style tunnel handling >of ECN, and that would be unfortunate. David, I doubt that IKE v2 and 2401 bis will be issued concurrently. But, my concern is over where a requirement belongs in our documents, more than what gets it out soonest. I recognize the value in the time to market issue you raise, but I think putting requirement in the proper place is more important. Steve From owner-ipsec@lists.tislabs.com Fri Dec 6 08:31:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6GVgg03361; Fri, 6 Dec 2002 08:31:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24899 Fri, 6 Dec 2002 11:04:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3DF0557D.2314FC80@bell-labs.com> References: <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> <3DF0557D.2314FC80@bell-labs.com> Date: Fri, 6 Dec 2002 11:05:39 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: speaking of keys Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since we've been discussing the details of key derivation, the amount of entropy we get from a 1204 bit DH exchange, and how that aligns nicely with the 160-bit hash output from SHA-1, I want to raise a related issue. Consistent with our efforts to simplify IPsec in general, I suggest that we mandate support for just one DH group (of 1024-bit size) and require that products provide a management interface to allow users/administrators to specify other groups as needed. Althouhg I am not a cryptographer, it seems that the 160-bits we get from a 1024-bit DH exchange is reasonable for use with 128-bit AES. I believe that NIST suggests that 1024-it DH should be good until at least 2015, although I forget what parameters they use in this analysis. Yes, I know we generate at least 2 and more often 4 keys from each DH exchange (one each for encryption and integrity in each direction), so the 128-bit key size and 160-bit entropy measures are not so easily comparable. I also worry that if we insist that all IPsec (IKE) implementations support 1536-bit DH, that too many folks will decide to select that option, under the "bigger is better" theme. However, the added performance hit for 1536-bit DH is significant and might have the unintended effect of causing folks to decide that the IPsec performance hits is too big and thus choose not to employ IPsec at all. If we mandate support for locally selected DH parameters, then we do permit more sophisticated user communities to select bigger groups, with different parameters, if they really need to. I have received feedback from some DoD clients that they want to use IPsec for protecting unclassified data, but feel the need to use groups selected by their crypto advisors (it's a union thing, I guess). it seem that many IKE implementations do not provide a facility for configuring other groups, and this poses problems for these folks. Hence my suggestion to adopt just one MUST group, at the 1024-bit size, but also mandate support for a management interface that allows user communities to support "custom" groups. We could impose some requirements on the max size groups that MUSt be supported via the management interface (to ensure interoperability), without specifying these other, bigger groups. What do people think about this suggestion? Steve From owner-ipsec@lists.tislabs.com Fri Dec 6 10:10:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6IA5g10881; Fri, 6 Dec 2002 10:10:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25227 Fri, 6 Dec 2002 12:40:29 -0500 (EST) Date: Fri, 6 Dec 2002 10:37:58 -0700 Message-Id: <200212061737.gB6Hbw706193@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: kent@bbn.com Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage Subject: Re: speaking of keys Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You only get about 80 bits of strength from a 1024-bit DH group. That seems insufficient for reasonable paranoids. Hilarie From owner-ipsec@lists.tislabs.com Fri Dec 6 10:32:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6IWtg14695; Fri, 6 Dec 2002 10:32:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25378 Fri, 6 Dec 2002 13:04:52 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212061737.gB6Hbw706193@localhost.localdomain> References: <200212061737.gB6Hbw706193@localhost.localdomain> Date: Fri, 6 Dec 2002 13:02:10 -0500 To: "The Purple Streak, Hilarie Orman" From: Stephen Kent Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >You only get about 80 bits of strength from a 1024-bit DH group. That >seems insufficient for reasonable paranoids. > >Hilarie Now I am really puzzled, given the recent messages from David Wagner in which 160 bits of entropy was accorded to 1024-bit DH: >"This objection has already been addressed on the list. Those 1024 >bits of Diffie-Hellman only have 160 bits of strength (160 bits of >"computational entropy"), hence you're not reducing security by hashing >it down to 160 bits. > >Indeed, in some sense you are improving security by hashing the 1024-bit >Diffie-Hellman result down to a 160-bit security, just as Hugo's earlier >note pointed out. Can I encourage you to re-read Hugo's earlier emails >on this topic? I hope you will find them persuasive. (I certainly did.)" What gives? Steve From owner-ipsec@lists.tislabs.com Fri Dec 6 12:15:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6KFlg25299; Fri, 6 Dec 2002 12:15:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25627 Fri, 6 Dec 2002 14:38:14 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Summary of key derivation thread Date: 6 Dec 2002 19:15:53 GMT Organization: University of California, Berkeley Lines: 12 Distribution: isaac Message-ID: References: <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> <3DF0557D.2314FC80@bell-labs.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1039202153 10689 128.32.153.211 (6 Dec 2002 19:15:53 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 6 Dec 2002 19:15:53 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal wrote: >David Wagner wrote: >> That's not correct. It is reasonable to view HMAC as a PRF, >> but it is not reasonable to view SHA as a secure PRF....... > >Because of single-block vs. multiple-block issues? Two reasons. First, SHA takes one input, while a PRF takes two. Second, F_k(x) = SHA(k || x) is not a secure PRF, because of extension attacks. If you want a PRF, SHA-HMAC is the "right" object, IMHO, not SHA. From owner-ipsec@lists.tislabs.com Fri Dec 6 12:25:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6KPbg25656; Fri, 6 Dec 2002 12:25:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25668 Fri, 6 Dec 2002 14:45:24 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: speaking of keys Date: 6 Dec 2002 19:23:48 GMT Organization: University of California, Berkeley Lines: 26 Distribution: isaac Message-ID: References: <200212061737.gB6Hbw706193@localhost.localdomain> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1039202628 10689 128.32.153.211 (6 Dec 2002 19:23:48 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 6 Dec 2002 19:23:48 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: >>You only get about 80 bits of strength from a 1024-bit DH group. That >>seems insufficient for reasonable paranoids. >> >>Hilarie > >Now I am really puzzled, given the recent messages from David Wagner >in which 160 bits of entropy was accorded to 1024-bit DH: > >>"This objection has already been addressed on the list. Those 1024 >>bits of Diffie-Hellman only have 160 bits of strength (160 bits of >>"computational entropy"), hence you're not reducing security by hashing >>it down to 160 bits. > >What gives? I believe Hilarie is right. I meant to say that the 1024-bit DH gives *at most* 160 bits of strength. My recollection of the true number matches Hilarie's: about 80-90 bits, as far as I know, under current attacks. That said, your argument in favor of 1024-bit keys might still be reasonable. 80-90 bits might be good enough for most purposes, and larger moduli aren't free. I wouldn't be happy with a block cipher that is restricted to 80-bit keys, because the cost of increasing a block cipher's keylength is typically quite small. For IKE, in contrast, if you want 128-bit security instead of 80-bit security, that incurs some cost. From owner-ipsec@lists.tislabs.com Fri Dec 6 13:07:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6L7Qg29984; Fri, 6 Dec 2002 13:07:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25785 Fri, 6 Dec 2002 15:24:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: IPSEC Known answer test cases Date: Fri, 6 Dec 2002 15:25:14 -0500 Message-ID: <675E14B1F51412408D550FF74C036B26E05F6F@thoreau.starentnetworks.com> Thread-Topic: speaking of keys Thread-Index: AcKdXIsevQS4vgPbRYe/yKd9Pj0vbAACKMPQ From: "Li, Ruicong" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA25782 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anybody tell me where I can find the known-answer-test cases for AH? Thanks, Ruicong Li From owner-ipsec@lists.tislabs.com Fri Dec 6 13:07:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6L7bg00502; Fri, 6 Dec 2002 13:07:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25779 Fri, 6 Dec 2002 15:22:02 -0500 (EST) Message-Id: <200212062023.gB6KN1Cu012348@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: speaking of keys In-reply-to: Your message of "Fri, 06 Dec 2002 10:37:58 MST." <200212061737.gB6Hbw706193@localhost.localdomain> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Dec 2002 15:23:00 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "The" == The Purple Streak, Hilarie Orman writes: The> You only get about 80 bits of strength from a 1024-bit DH group. That The> seems insufficient for reasonable paranoids. Yes. I'd like to see the 1536 group ("group 5", still in ID queue) as a MUST in IKEv2, and I'd like to see the next larger group given a SHOULD. (group 5 is spec'ed as MUST for FreeSWAN-style Opportunistic Encryption, to support 3DES) It is very important that we spec something, and that we also suggest where the failover direction is. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPfEHIoqHRg3pndX9AQFmzQQAsXT+zicDWjynT0zYiEJ85bGNdfv8ssl4 LYg/PI9PcL1xlbz0oW41Lc924fZO5aKsHCNtMN1UpEWg6LLXXkvs0m0hU+0ijIZs KvGgEfizwdOfAFRw/P1SgjNsSO01YKOh0zSv8M9OgBiYMcN/p5UeQPX0UeYgxZZV KQpjqLeA12k= =bm+5 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Dec 6 13:42:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Lggg03186; Fri, 6 Dec 2002 13:42:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25894 Fri, 6 Dec 2002 15:47:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212062023.gB6KN1Cu012348@sandelman.ottawa.on.ca> References: <200212062023.gB6KN1Cu012348@sandelman.ottawa.on.ca> Date: Fri, 6 Dec 2002 15:48:52 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:23 PM -0500 12/6/02, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "The" == The Purple Streak, Hilarie Orman writes: > The> You only get about 80 bits of strength from a 1024-bit DH >group. That > The> seems insufficient for reasonable paranoids. > > Yes. > I'd like to see the 1536 group ("group 5", still in ID queue) as a MUST >in IKEv2, and I'd like to see the next larger group given a SHOULD. > > (group 5 is spec'ed as MUST for FreeSWAN-style Opportunistic Encryption, >to support 3DES) > > It is very important that we spec something, and that we also suggest where >the failover direction is. Well, I have been corrected re the entropy confusion by David's recent message, but why go all the way to 1536? Isn't there an intermediate group size that would be reasonable for those who insist on more than 1024, say something i the 1200 bit range? Also, let's remember that the key size is not the only factor in determining the security of these systems. It's tempting to raise the bar on key size to make sure it is not the weakest link, and I appreciate that. But we also run the risk of driving people away due to the performance hit. Frankly, the worst case here might be a software implementation on a user WS/laptop where there are lots more likely ways that the security of the traffic will be compromised (other than solving the discrete log problem for a 1024-bit group) and where the performance hit will be most visible and thus may eventually motivate an individual to NOT use IPsec at all. I don't have a problem with a MAY for bigger groups, but I really think it is most appropriate to focus on the management facility to allow user communities to select their own, of whatever size they feel is appropriate. Steve From owner-ipsec@lists.tislabs.com Fri Dec 6 13:54:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6LsSg03810; Fri, 6 Dec 2002 13:54:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25982 Fri, 6 Dec 2002 16:08:19 -0500 (EST) Message-Id: <200212062109.gB6L9aUS013157@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: speaking of keys In-reply-to: Your message of "Fri, 06 Dec 2002 15:48:52 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Dec 2002 16:09:36 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> Also, let's remember that the key size is not the only factor in Stephen> determining the security of these systems. It's tempting to raise Absolutely. Stephen> software implementation on a user WS/laptop where there are lots more Stephen> likely ways that the security of the traffic will be compromised Stephen> (other than solving the discrete log problem for a 1024-bit group) Stephen> and where the performance hit will be most visible and thus may Stephen> eventually motivate an individual to NOT use IPsec at all. I think that we can write a MAY for a smaller size (i.e. 1024). The reason to pick something for the MUST is interoperability. That is the only reason. Stephen> I don't have a problem with a MAY for bigger groups, but I really Stephen> think it is most appropriate to focus on the management facility to Stephen> allow user communities to select their own, of whatever size they Stephen> feel is appropriate. It has been a long time since anyone has talked about APIs. Bill Sommerfeld has promised to take us (IPSP specifically) down that path again, and it is high time that we do this. I do not think that applications writers should have to deal with DH modulus size. I think that we should have a direct mapping that gives minimum modulus sizes for particular levels of security. I don't have a problem with having a notch in the slider set for "80-bits", which really implies a 1024-bit modulus with 3DES or 128-bit AES, with another notch at 128. It would be nice if there was another unit we could use other than bits to expose to the user, but I don't see another one that is CPU-speed independant (not local CPU speed, but CPU speed size of attacker). Herman style: "You must be at least $$$-well funded to bother brute forcing this castle". ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPfESDoqHRg3pndX9AQECIgQAmMYFIwmK9U+mjmx57wIIk9+sO8YG5oN2 OhjsGlCV1bxoVdSnodvdJG37XqJs1/IXR/7Fm9tSCpFiR4I8BegXenBDileOHr4J FGqKpP5Qp/t+u6/hwKOxm9RZET184p6OZdK3uNEPSgfLJ0zdkuYl18EO/p2KODYd FADACpcupzA= =UMgt -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 9 07:40:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9FeYg08979; Mon, 9 Dec 2002 07:40:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01298 Mon, 9 Dec 2002 10:09:05 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Handling of IPcomp in IKEv2 - Summary To: IP Security List X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sat, 7 Dec 2002 06:38:17 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/09/2002 10:09:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I will try following Radia's lead and summarizing this thread to the list: I proposed that instead of negotiating a single IPcomp algorithm as part of an SA bundle, the each end specify the compression algorithms it supports (for decompression) with the corresponding CPIs and a sender MAY for any packet use any of the compression algorithms the recipient supports. Many people expressed support for the idea. No one objected. Some proposed improvements: Bill Sommerfeld suggested that the set of supported compression algorithms might change dynamically over time because the code libraries that implement them might be dynamically loaded. And that because of that it might be better to (A1) require that the sender may only compress with algorithms he committed to decompress (so that extraneous unmatched algorithms could be paged out). Or alternatively (A2) to have separate lists of compression and decompression algorithms. Paul Koning didn't like requiring that the same algorithms be supported for compression as decompression (A1) because there might be cases where one direction is slower and a node might only want to support the fast transformation. Paul Hoffman objected to the complexity of (A2). I could live with either of the proposed changes, but both raised objections. I find the idea of dynamically loaded libraries for IPcomp compression algorithms farfetched (remember... this is per packet compression with no remembered state between packets), so my preference would be to stick with the original proposal which addresses the Pauls' concerns but not Bill's. Radia Perlman asked whether there might be few enough compression algorithms that they might all have two byte CPI values statically assigned and that nodes could simply say which CPIs they support instead of dynamically matching algorithms to CPIs. This would be a significant simplification if it was true. I have no idea whether it is. Does anyone know?? Henry Spencer requested that the algorithms be stated in order of preference, where 'no compression' had a code so that it could be something other than least preferred. Order of preference seems right - it's consistent with the other lists. I find an explicit 'no compression' unnecessary complexity because everyone must support 'no compression' so why would anyone want to say 'I support compression X but I'd prefer that you didn't use it?'. Why not just not admit to supporting X? But I certainly could live with it if it has advocates. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Dec 9 07:40:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9Fefg08993; Mon, 9 Dec 2002 07:40:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01053 Mon, 9 Dec 2002 09:48:49 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 8 Dec 2002 18:21:57 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Summary of revised identity changes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. At the request of some folks from the WG, here is a summary of changes that the revised identity proposal makes. Hopefully, this list clears up any questions. a) For certificate authentication, in messages 3 and 4, you no longer send both an ID and a certificate. Instead, you send only a certificate and the receiver gets your identity from the certificate. IKEv1 developers still cannot agree on how to use the identity with the certificate. For example, some implementers reject messages where the ID doesn't match any of the names in the certificate, others accept it, still others don't even read the ID field, and still others don't read the names from the certificate. The new proposal eliminates the ambiguity. b) By telling the kind of ID that is accepted in messages 1 and 2, you can safely avoid sending certificates if they are not needed. Either side can say "I can take certificates as a hash-and-URL". If you can't accept a hash-and-URL (for instance, because you can't resolve URLs), you can tell the other side that easily. c) Certificate requests are now hashes of the public key of the trust anchor, not the DN name. This makes it clearer to each side exactly which key is the trust anchor, since some trust anchor names are not unique (such as after a key rollover). There is only one form for the hashes, and it matches the form that is already used in PKIX. d) You can accept hash-and-URL of certs instead of the certs themselves. This helps prevent fragmentation of UDP packets for large certificates. The receiver can cache the certificates he/she has received and look them up by their hash, so resolving the URL might not even be necessary. I hope this helps! --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Dec 9 08:36:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9Ga5E13509; Mon, 9 Dec 2002 08:36:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02537 Mon, 9 Dec 2002 11:03:21 -0500 (EST) Date: Mon, 9 Dec 2002 11:05:01 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Handling of IPcomp in IKEv2 - Summary In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 7 Dec 2002 Charlie_Kaufman@notesdev.ibm.com wrote: > ...Order of preference seems right - it's > consistent with the other lists. I find an explicit 'no compression' > unnecessary complexity because everyone must support 'no compression' so > why would anyone want to say 'I support compression X but I'd prefer that > you didn't use it?'. Why not just not admit to supporting X? The whole point of having the list in preference order is that some choices are *better* than others, even if they are all supported. "No compression" is a choice; hardwiring it to always be at the end of the list seems dubious. A host with plenty of network bandwidth but rather limited CPU power might well be willing to support compression, but prefer that it not be used. Putting "no compression" first, for example, means "compress only if it's really important on your end". While it has been suggested that the CPU savings on encryption/decryption more than make up for CPU expended on compression/decompression, I've seen test results showing that this is not necessarily true. Faced with a difference between the far end's preferences and its own preferences, of course, an implementation just has to make a decision. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 9 08:43:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9GhoE13856; Mon, 9 Dec 2002 08:43:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02798 Mon, 9 Dec 2002 11:15:33 -0500 (EST) Date: Sun, 8 Dec 2002 22:07:09 -0800 (PST) From: Avram Shacham To: Radia Perlman - Boston Center for Networking cc: , Subject: Re: Handling of IPcomp in IKEv2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia, The existing RFCs already specify a range of well-known compression algorithms. (See the attached summary.) Even with that option available, the vast majority of IPComp implementations use the negotiated CPI (range 256-61439) rather than the well-known numbers. At least that was the status when the implementation report, http://www.iesg.org/IESG/Implementations/IPCOMP-Implementation.txt , was written. Regards, avram RFC-3173 IP Payload Compression Protocol 3.3. IPComp Header Structure [...] Compression Parameter Index (CPI) 16-bit index. The CPI is stored in network order. The values 0-63 designate well-known compression algorithms, which require no additional information, and are used for manual setup. The values themselves are identical to IPCOMP Transform identifiers as defined in [SECDOI]. Consult [SECDOI] for an initial set of defined values [..] Note: When negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63. RFC-2407 The Internet IP Security Domain of Interpretation for ISAKMP 4.4.5 IPSEC IPCOMP Transform Identifiers The IP Compression (IPCOMP) transforms define optional compression algorithms that can be negotiated to provide for IP payload compression ([IPCOMP]). The following table lists the defined IPCOMP Transform Identifiers for the ISAKMP Proposal Payload within the IPSEC DOI. Transform ID Value ------------ ----- RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 IPCOMP_LZS 3 and, RFC-3051 added IPCOMP_LZJH 4 Radia Perlman - Boston Center for Networking wrote: >[...] > What you propose certainly sounds sane. Any chance of making > it even simpler, and having the codes for identifying > the compression algorithms be the same as the CPI? Then > instead of saying, "I support xxx and will identify it with code 45", you > could just say "I support 45". I guess this would require > IANA to assign a CPI before a compression algorithm could get > used. > > Radia > > From owner-ipsec@lists.tislabs.com Mon Dec 9 08:43:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9GhuE13870; Mon, 9 Dec 2002 08:43:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02778 Mon, 9 Dec 2002 11:14:32 -0500 (EST) Subject: Building a SA Payload From: venkat To: "ipsec@lists.tislabs.com" Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VJi5oQV+Oz3MVZIzK2OG" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 09 Dec 2002 12:29:10 +0530 Message-Id: <1039417158.767.7.camel@venkat> Mime-Version: 1.0 X-Mailserver: Sent using PostMaster (v4.1.13) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=-VJi5oQV+Oz3MVZIzK2OG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Can we build a SA Proposal which looks like this SA Payload with DOI=3DIPSEC and Situation =3D SIT_IDENTITY_ONLY Proposal Payload #1 for PROTOCOL_ISAKMP specifying 4 Transforms Transform Payload #1 with Encryption Algorithm =3D IDEA Transform Payload #2 with Encryption Algorithm =3D 3DES_CBC Transform Payload #3 with Encryption Algorithm =3D DES_CBC Transform Payload #4 with Hashing Algorithm =3D MD5 Consider the following situation where I am trying to develop a ISAKMP SA with ENC =3D DES_CBC(or)3DES_CBC(or)IDEA HASH =3D MD5 Do I have to send three SA Proposal's or will one SA Proposal suffice. Which one of the below listed method's are correct METHOD 1 or 2 or 3 METHOD #1 --------- Propose( DES, 3DES, IDEA, MD5, SHA ); <=3D=3D> Accept( 3DES, MD5 ); OR METHOD #2 --------- Propose( IDEA, MD5 ); <=3D=3D> Reject( IDEA, MD5 ); Propose( 3DES, MD5 ); <=3D=3D> Accept( 3DES, MD5 ); OR METHOD #3 --------- Propose( IDEA, MD5 ); Propose( 3DES, MD5 ); <=3D=3D> Accept( 3DES, MD5 ); Thanks in advance - Venkat --=-VJi5oQV+Oz3MVZIzK2OG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA99D8+fFa7Ol5nHJkRAm6MAKCiCtr6FG8WegyP3bDf5sEtuwVWGACgjPEx hmrlw4qub4iDEcqPM8lbSqI= =GTSo -----END PGP SIGNATURE----- --=-VJi5oQV+Oz3MVZIzK2OG Content-Type: text/plain -------------------------------------------------------------- Dexcel Electronics Designs (P) Ltd., Bangalore, India --=-VJi5oQV+Oz3MVZIzK2OG-- From owner-ipsec@lists.tislabs.com Mon Dec 9 08:45:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9Gj4E13961; Mon, 9 Dec 2002 08:45:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02801 Mon, 9 Dec 2002 11:15:36 -0500 (EST) Date: Sun, 8 Dec 2002 23:32:22 -0800 (PST) From: Avram Shacham To: cc: , Subject: Re: Handling of IPcomp in IKEv2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, The issue of using a negotiated CPI vs. using a well-known algorithm number has been discussed at length on the (ipsec and ippcp) lists and in the bakeoffs, as the attached implementation note from RFC 3173 summarizes. Your suggestion #1 provides a way to establish a CPI from both ranges -- well known numbers and negotiated -- thus preserving the current RFC 3171 functionality. Also, it seems that none of your suggestions should modify the current packet structure on the wire, only the method of negotiation. The elimination of the flexibility to establish protection suites, where compression is attached only to a specific encryption algorithm, could be a problem if those suites describe hardware accelerators, if such accelerators exist. The suggestion to support multiple compression algorithms simultaneously in the same session has never been raised in the ippcp wg or on the lists, so I'm not sure if there is a real need for suggestion #3. (btw, the current protocol -- see (*) below -- already includes a way to "allow data sent in the two directions to be compressed with different algorithms if appropriate." though I'm not aware of any implementation that is so configured.) Regards, avram rfc-3173 (page 9): 4.1. Use of IKE [...] Implementation note: IPCAs become non-unique when two or more IPComp sessions are established between two nodes, and the same well-known CPI is used in at least two of the sessions. Non-unique IPCAs pose problems in maintaining attributes specific to each IPCA, either negotiated (e.g., lifetime) or internal (e.g., the counters of the adaptive algorithm for handling previously compressed payload). To ensure the uniqueness of IPCAs between two nodes, when two or more of the IPCAs use the same compression algorithm, the CPIs SHOULD be in the negotiated range. However, when the IPCAs are not required to be unique, for example when no attribute is being utilized for these IPCAs, a well-known CPI MAY be used. To clarify: When only a single session using a particular well-known CPI is established between two nodes, this IPCA is unique. (*) 4. IPComp Association (IPCA) Negotiation [...] Two nodes may choose to negotiate IPComp in either or both directions, and they may choose to employ a different compression algorithm in each direction. Charlie_Kaufman@notesdev.ibm.com wrote: > > > > I never really understood how IPcomp worked in IPsec until Tero explained > it to me at the recent IETF. It seemed like it couldn't work as the IKEv1 > spec said, yet I had heard that people used it, so I left it alone. Now > that I understand it better (or at least think I do), I can see how the > current spec works (sort of) but believe it could be better and simpler. My > proposal is motivated in part by the desire to separate negotiation of > IPcomp from the "cryptographic suites" - something that people at the IPsec > meeting seemed to want but it wasn't immediately clear how. > > IKE optionally negotiates IPcomp when it negotiates an ESP SA, and AH SA, > or an ESP within AH SA. As currently specified, an IPcomp SA is negotiated > where an IPcomp SA has a two byte CPI (analogous to the four byte SPIs in > ESP and AH). That always made me uneasy, because SPIs are supposed to be > unique (within a single IP destination) and two bytes might not be enough. > Of course, given that the IPcomp SA is bound to a containing ESP or AH SA, > it's not clear why it needs a CPI at all (in which case, why waste the two > bytes). > > As Tero explained it, the IPcomp SA is not really an SA at all. First, > unlike ESP and AH, it is optional on a packet by packet basis. This is so > that if the compression algorithm is not effective on a particular packet > (e.g. the compressed version is bigger), IPcomp processing can be skipped > on that packet. The CPI at the beginning of the IPcomp header is not to > identify the session on which the packet is arriving - that is implicit > from the ESP or AH header. Instead, it identifies the compression algorithm > used, which is only interesting if the receiving node is capable of using > multiple compression algorithms. In the common case, a node only supports a > single compression algorithm and always assigns the same CPI to all IPcomp > SAs. > > Given all this, I don't believe it is appropriate for nodes to negotiate > compression algorithms as they currently do where they either end up > agreeing on a single compression algorithm or they don't agree on any. > Rather, each node should announce what compression algorithms it is capable > of decompressing and the two byte CPIs associated with each one. A sending > node can optionally compress any outgoing packet with any of the algorithms > supported by the other end. This has several advantages: > > 1) IPcomp negotiation becomes completely separate from ESP and AH > negotiation. You don't have to double the number of proposals to say that > each is possible with and without IPcomp. (This comes with the cost that > you can't say I'll do AES with compression or 3DES without, but it seems > unlikely real implementations would want that flexibility). > > 2) It eliminates confusion around deleting IPcomp SAs. Nodes commit to > handling their offered decompression algorithms for as long as the ESP or > AH SAs are maintained. They are not explicitly deleted or renewed. > > 3) If bandwidth is at a premium compared to processing, a sending node > could try several different compression algorithms and send whichever form > was the most compressed. It would also allow senders to adjust their choice > of compression algorithms over time depending on the nature of the data > being transmitted, and it would allow data sent in the two directions to be > compressed with different algorithms if appropriate. > > What do people think? Am I still confused? > > --Charlie > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > > From owner-ipsec@lists.tislabs.com Mon Dec 9 09:45:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9HjQE18321; Mon, 9 Dec 2002 09:45:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04066 Mon, 9 Dec 2002 12:12:36 -0500 (EST) Date: Mon, 9 Dec 2002 12:14:04 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 8 Dec 2002, Avram Shacham wrote: > Even with that option available, the vast majority of IPComp > implementations use the negotiated CPI (range 256-61439) rather than the > well-known numbers... Most of the motive for this, I think, is that it's convenient to have a local object to hold state for compression -- the compression proper is usually stateless, but choice of algorithm, intelligent decision on whether to attempt compression, etc. require local state -- and negotiated CPIs let you give that state a number (although not very conveniently so, since the decompressor picks the CPI but it's the compressor that wants to keep state). I don't think any significant amount of the negotiation is being done to permit custom compression algorithms. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 9 09:51:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9HpQE18481; Mon, 9 Dec 2002 09:51:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04397 Mon, 9 Dec 2002 12:22:48 -0500 (EST) Date: Fri, 6 Dec 2002 17:29:12 -0700 Message-Id: <200212070029.gB70TCC25166@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: kent@bbn.com Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage Subject: Re: speaking of keys Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You only get about an additional 16 bits of computational security for those 500 extra bits in the modulus size. Also, the Diffie-Hellman group is a single basket holding all past session keys. Just because it is strong enough for one paranoid usage doesn't account for the risk of having all past keys revealed. You need a very healthy entropy margin to account for that. Hilarie On Fri, 6 Dec 2002 at 15:48:52 -0500 Stephen Kent discoursed: > but why go all the way to 1536? Isn't there an > intermediate group size that would be reasonable for those who insist > on more than 1024, say something i the 1200 bit range? From owner-ipsec@lists.tislabs.com Mon Dec 9 09:59:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9HxNE18659; Mon, 9 Dec 2002 09:59:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04616 Mon, 9 Dec 2002 12:29:24 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C602@corpmx14.us.dg.com> To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: IKEv2 transport concerns Date: Fri, 6 Dec 2002 20:46:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >> >I think it needs to be in both places. We have a one-time opportunity > >> >to avoid the IKEv1 ECN negotiation kludge if all IKEv2 implementations > >> >are REQUIRED to handle ECN correctly at tunnel egress. IMHO, this > >> >outcome is important enough to merit specifying the means of achieving > >> >it in both the IKEv2 and RFC2401bis documents. If we wind up dealing > >> >with IKEv2 systems that get this wrong, the negotiation kludge will be > >> >with us for much longer ... > >> > >> David, > >> > >> I don't think the IKE v2 document is the appropriate place to make > >> note of the ECN handling you refer to, since it applies to the > >> actions performed on the child SAs that IKE establishes, not on the > >> IKE SAs, right? It really is a 2401bis matter, I believe. > >> > >> Steve > > > >Will 2401bis progress on a timeline that will allow a normative reference > >to it from IKEv2? If so having IKEv2 say "MUST do ECN right, see 2401bis > >for details" would be fine. I'm concerned that no mention of this at all in > >IKEv2 implicitly allows IKEv2 to negotiate 2401classic style tunnel handling > >of ECN, and that would be unfortunate. > > David, > > I doubt that IKE v2 and 2401 bis will be issued concurrently. But, my > concern is over where a requirement belongs in our documents, more > than what gets it out soonest. I recognize the value in the time to > market issue you raise, but I think putting requirement in the proper > place is more important. > > Steve Steve, Would you be amenable to an approach based on a small draft that contains just the tunnel encapsulation/decapsulation material needed to specify ECN handling for tunnel-mode SAs? That could be put together in short enough order to allow IKEv2 to use a "MUST" to reference it without delaying IKEv2. When 2401bis is ready, it would obsolete both the new small tunnel draft and 2401 itself, so that the requirement winds up in the right place. I'll sign up to write the small ECN handling draft on a schedule that won't hold up IKEv2. If 2401bis gets done faster than expected, the new small ECN handling draft could vanish without a trace, having served its purposes of preventing 2401-classic tunnel (mis)handling of ECN in SAs set up by IKEv2, and allowing us to leave the IKEv1 ECN negotiation kludge on the scrap heap where it belongs. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Dec 9 09:59:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9HxPE18668; Mon, 9 Dec 2002 09:59:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04659 Mon, 9 Dec 2002 12:29:33 -0500 (EST) Message-Id: <5.2.0.9.2.20021206180652.0273c0f0@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 18:10:21 -0500 To: Stephen Kent , ipsec@lists.tislabs.com From: Russ Housley Subject: Re: speaking of keys In-Reply-To: References: <3DF0557D.2314FC80@bell-labs.com> <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> <3DF0557D.2314FC80@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve: I support your recommendation. In fact, I was going to make the same recommendation, but for a different reason. I few weeks ago, we had a long thread discussing mandatory to implement signature algorithms. We decided that RSA with 1024-bit keys will be mandatory to implement. So, if 1024 bits is adequate for the signature, it seems like 1024 should also be adequate for the key agreement algorithm. Russ At 11:05 AM 12/6/2002 -0500, Stephen Kent wrote: >Since we've been discussing the details of key derivation, the amount of >entropy we get from a 1204 bit DH exchange, and how that aligns nicely >with the 160-bit hash output from SHA-1, I want to raise a related issue. > >Consistent with our efforts to simplify IPsec in general, I suggest that >we mandate support for just one DH group (of 1024-bit size) and require >that products provide a management interface to allow users/administrators >to specify other groups as needed. > >Althouhg I am not a cryptographer, it seems that the 160-bits we get from >a 1024-bit DH exchange is reasonable for use with 128-bit AES. I believe >that NIST suggests that 1024-it DH should be good until at least 2015, >although I forget what parameters they use in this analysis. > >Yes, I know we generate at least 2 and more often 4 keys from each DH >exchange (one each for encryption and integrity in each direction), so the >128-bit key size and 160-bit entropy measures are not so easily comparable. > >I also worry that if we insist that all IPsec (IKE) implementations >support 1536-bit DH, that too many folks will decide to select that >option, under the "bigger is better" theme. However, the added >performance hit for 1536-bit DH is significant and might have the >unintended effect of causing folks to decide that the IPsec performance >hits is too big and thus choose not to employ IPsec at all. > >If we mandate support for locally selected DH parameters, then we do >permit more sophisticated user communities to select bigger groups, with >different parameters, if they really need to. I have received feedback >from some DoD clients that they want to use IPsec for protecting >unclassified data, but feel the need to use groups selected by their >crypto advisors (it's a union thing, I guess). it seem that many IKE >implementations do not provide a facility for configuring other groups, >and this poses problems for these folks. Hence my suggestion to adopt just >one MUST group, at the 1024-bit size, but also mandate support for a >management interface that allows user communities to support "custom" >groups. We could impose some requirements on the max size groups that MUSt >be supported via the management interface (to ensure interoperability), >without specifying these other, bigger groups. > >What do people think about this suggestion? > >Steve From owner-ipsec@lists.tislabs.com Mon Dec 9 10:55:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9ItZE22254; Mon, 9 Dec 2002 10:55:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05244 Mon, 9 Dec 2002 13:17:28 -0500 (EST) Message-Id: <5.0.0.25.2.20021209131754.02c98d18@vhqpostal3.verisign.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 09 Dec 2002 13:18:26 -0500 To: ipsec@lists.tislabs.com From: Thomas Hardjono Subject: Fwd: [MSEC] I-D ACTION:draft-ietf-msec-ipsec-multicast-issues-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Delivered-To: msec@pairlist.net >Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org >To: IETF-Announce: ;IETF-Announce:;@securemulticast.org >Cc: msec@securemulticast.org >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >Subject: [MSEC] I-D ACTION:draft-ietf-msec-ipsec-multicast-issues-00.txt >Sender: msec-admin@securemulticast.org >X-BeenThere: msec@securemulticast.org >X-Mailman-Version: 2.0 >List-Help: >List-Post: >List-Subscribe: , > >List-Id: IETF Multicast Security (MSEC) WG list >List-Unsubscribe: , > >List-Archive: >Date: Mon, 09 Dec 2002 08:03:19 -0500 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : IP Multicast issues with IPsec > Author(s) : M. Baugher, T. Hardjono, B. Weis > Filename : draft-ietf-msec-ipsec-multicast-issues-00.txt > Pages : 8 > Date : 2002-12-6 > >The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402, >RFC2406] define certain semantics for use of IPsec with IP multicast >traffic. The recent revisions to each of the protocol documents >[ESPbis, AHbis] propose changes to those semantics. However, neither >the existing nor proposed semantics are sufficiently general such >that IPsec can be used to protect the wide variety of IPv4 and IPv6 >multicast applications that are expected by the IP multicast >community. This document reviews these semantics and proposes >changes which would enable IPsec to be generally useful for a wider >variety of IPv4 and IPv6 multicast traffic. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-multicast-issues-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-msec-ipsec-multicast-issues-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-msec-ipsec-multicast-issues-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2002-12-6141134.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-ipsec-multicast-issues-00.txt > > From owner-ipsec@lists.tislabs.com Mon Dec 9 11:00:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9IxwE22384; Mon, 9 Dec 2002 10:59:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05250 Mon, 9 Dec 2002 13:19:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15860.57051.390628.412456@pkoning.dev.equallogic.com> Date: Mon, 9 Dec 2002 13:20:11 -0500 From: Paul Koning To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: Handling of IPcomp in IKEv2 References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Avram" == Avram Shacham writes: Avram> ... Avram> The elimination of the flexibility to establish protection Avram> suites, where compression is attached only to a specific Avram> encryption algorithm, could be a problem if those suites Avram> describe hardware accelerators, if such accelerators exist. I've only seen accelerators where compression and encryption are independent choices. Obviously, it's possible in theory that a host might offer some ciphers it has in hardware and some that it does in software, but it isn't willing/able to handle decompression in software. But I cannot imagine that such a case would occur in practice. The software vs. hardware performance difference is so large that you would NEVER offer to do both in the same box -- if you have hardware crypto support then you will only propose those algorithms that are in hardware. >>>>> "Henry" == Henry Spencer writes: Henry> On Sat, 7 Dec 2002 Charlie_Kaufman@notesdev.ibm.com wrote: >> ...Order of preference seems right - it's consistent with the >> other lists. I find an explicit 'no compression' unnecessary >> complexity because everyone must support 'no compression' so why >> would anyone want to say 'I support compression X but I'd prefer >> that you didn't use it?'. Why not just not admit to supporting X? Henry> The whole point of having the list in preference order is that Henry> some choices are *better* than others, even if they are all Henry> supported. "No compression" is a choice; hardwiring it to Henry> always be at the end of the list seems dubious. A host with Henry> plenty of network bandwidth but rather limited CPU power might Henry> well be willing to support compression, but prefer that it not Henry> be used. Putting "no compression" first, for example, means Henry> "compress only if it's really important on your end". I think that's sensible, and the proposed way of doing it certainly is easy. >>>>> "Charlie" == Charlie Kaufman writes: Charlie> ... Charlie> Radia Perlman asked whether there might be few enough Charlie> compression algorithms that they might all have two byte CPI Charlie> values statically assigned and that nodes could simply say Charlie> which CPIs they support instead of dynamically matching Charlie> algorithms to CPIs. This would be a significant Charlie> simplification if it was true. I have no idea whether it Charlie> is. Does anyone know?? Clearly yes. Avram quotes the current list (3 entries) which is much less than 2^16... :-) I think Radia's suggestion is very good, it eliminates an unnecessary level of indirection. paul From owner-ipsec@lists.tislabs.com Mon Dec 9 12:31:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9KVhE27089; Mon, 9 Dec 2002 12:31:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06283 Mon, 9 Dec 2002 14:58:11 -0500 (EST) Message-ID: <3DF4E99F.1040003@isi.edu> Date: Mon, 09 Dec 2002 11:06:07 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021202 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Black_David@emc.com CC: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 transport concerns References: <277DD60FB639D511AC0400B0D068B71E0564C602@corpmx14.us.dg.com> In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C602@corpmx14.us.dg.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030108090709090300060007" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030108090709090300060007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > Would you be amenable to an approach based on a small draft that > contains just the tunnel encapsulation/decapsulation material needed > to specify ECN handling for tunnel-mode SAs? ... RFC2003 is currently under revision in the Mobile-IP WG. It may be simpler to consolidate IPsec-related tunneling specifics in 2003bis, since Mobile-IP owns IP protocol 4 and will have to be involved in any changes anyhow. Lars -- Lars Eggert USC Information Sciences Institute --------------ms030108090709090300060007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTIwOTE5MDYwOFowIwYJKoZIhvcNAQkEMRYEFDjIO2As6rcxNzG2uX/A XdNDn3jWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAvP3lIEHmgkBqcWRXmK9IlGR9QvXPhFeK8J+k sF2VJ6eDtdYDCYVCa3O3ZKvqU4gbrWL27o9+v//i5obkqvqQgrPY1/DWB27mXYa5KiqZrqDy tocxjkiVIJ+zQkAz5BAe/B9mWMHCHKmXmOCw1SDvBJ+qQFxWFi9Cs2tM1J/RuX5cjKkcsB3t RTlyEgwQL2kaPhVtZDwY2SRHxD/HGsEJUHVz+hXj4rJSHIGloq6qugjNhqocMJTtq5IusLL0 /fent2AkcwF5opQAvCJZtZCFZuhH8iMns7BQu6ViMtQB8DY8TOgM1Z+ROntDdJSZsuuWTvsa 3kyRwTi2dq1XsHyivgAAAAAAAA== --------------ms030108090709090300060007-- From owner-ipsec@lists.tislabs.com Mon Dec 9 12:31:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9KVjE27096; Mon, 9 Dec 2002 12:31:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06304 Mon, 9 Dec 2002 15:01:13 -0500 (EST) Date: Mon, 9 Dec 2002 11:02:45 -0800 (PST) From: Avram Shacham To: Paul Koning cc: , , Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: <15860.57051.390628.412456@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Risking repeating an earlier reply to Radia, the (once again) attached implementation note from RFC-3173 details scenarios where negotiated CPIs are required. (In short, when compression sessions maintain attributes specific to each session.) Moreover, the alternative to use a well-known CPI is available in the current protocol, yet most implementations are negotiating CPIs from 256-61439 range. As for the negotiation of IPComp within a protection suite or orthogonal to ESP/AH protocol, as Charlie suggests, both methods look okay. Regards, avram IPCAs become non-unique when two or more IPComp sessions are established between two nodes, and the same well-known CPI is used in at least two of the sessions. Non-unique IPCAs pose problems in maintaining attributes specific to each IPCA, either negotiated (e.g., lifetime) or internal (e.g., the counters of the adaptive algorithm for handling previously compressed payload). To ensure the uniqueness of IPCAs between two nodes, when two or more of the IPCAs use the same compression algorithm, the CPIs SHOULD be in the negotiated range. However, when the IPCAs are not required to be unique, for example when no attribute is being utilized for these IPCAs, a well-known CPI MAY be used. On Mon, 9 Dec 2002, Paul Koning wrote: > >>>>> "Avram" == Avram Shacham writes: > > Avram> ... > Avram> The elimination of the flexibility to establish protection > Avram> suites, where compression is attached only to a specific > Avram> encryption algorithm, could be a problem if those suites > Avram> describe hardware accelerators, if such accelerators exist. > > I've only seen accelerators where compression and encryption are > independent choices. > > Obviously, it's possible in theory that a host might offer some > ciphers it has in hardware and some that it does in software, but it > isn't willing/able to handle decompression in software. But I cannot > imagine that such a case would occur in practice. The software > vs. hardware performance difference is so large that you would NEVER > offer to do both in the same box -- if you have hardware crypto > support then you will only propose those algorithms that are in > hardware. > > >>>>> "Henry" == Henry Spencer writes: > > Henry> On Sat, 7 Dec 2002 Charlie_Kaufman@notesdev.ibm.com wrote: > >> ...Order of preference seems right - it's consistent with the > >> other lists. I find an explicit 'no compression' unnecessary > >> complexity because everyone must support 'no compression' so why > >> would anyone want to say 'I support compression X but I'd prefer > >> that you didn't use it?'. Why not just not admit to supporting X? > > Henry> The whole point of having the list in preference order is that > Henry> some choices are *better* than others, even if they are all > Henry> supported. "No compression" is a choice; hardwiring it to > Henry> always be at the end of the list seems dubious. A host with > Henry> plenty of network bandwidth but rather limited CPU power might > Henry> well be willing to support compression, but prefer that it not > Henry> be used. Putting "no compression" first, for example, means > Henry> "compress only if it's really important on your end". > > I think that's sensible, and the proposed way of doing it certainly is > easy. > > >>>>> "Charlie" == Charlie Kaufman writes: > > Charlie> ... > Charlie> Radia Perlman asked whether there might be few enough > Charlie> compression algorithms that they might all have two byte CPI > Charlie> values statically assigned and that nodes could simply say > Charlie> which CPIs they support instead of dynamically matching > Charlie> algorithms to CPIs. This would be a significant > Charlie> simplification if it was true. I have no idea whether it > Charlie> is. Does anyone know?? > > Clearly yes. Avram quotes the current list (3 entries) which is much > less than 2^16... :-) > > I think Radia's suggestion is very good, it eliminates an unnecessary > level of indirection. > > paul > > From owner-ipsec@lists.tislabs.com Mon Dec 9 13:11:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LBPE05172; Mon, 9 Dec 2002 13:11:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06583 Mon, 9 Dec 2002 15:43:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15861.180.334322.283410@pkoning.dev.equallogic.com> Date: Mon, 9 Dec 2002 15:44:36 -0500 From: Paul Koning To: shacham@shacham.net Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: Handling of IPcomp in IKEv2 References: <15860.57051.390628.412456@pkoning.dev.equallogic.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Avram" == Avram Shacham writes: Avram> Paul, Avram> Risking repeating an earlier reply to Radia, the (once again) Avram> attached implementation note from RFC-3173 details scenarios Avram> where negotiated CPIs are required. (In short, when Avram> compression sessions maintain attributes specific to each Avram> session.) Moreover, the alternative to use a well-known CPI is Avram> available in the current protocol, yet most implementations Avram> are negotiating CPIs from 256-61439 range. I saw that, but I don't see how it applies in the setting Charlie proposed. With IKEv1, it isn't clear whether the CPI numbering is local to the compression session "within" the encryption session negotiated as a set. Charlie's proposal is that with IKEv2, it is. I.e., you are negotiating what compression will be used within the context of the IPsec SAs. The question amounts to: do you ever require more than one compression session within a SINGLE encryption session? One case has been suggested: multiple compression algorithms, where you can pick one or the other per-packet. Radia's proposal supports that directly, because what was the CPI is now the algorithm ID. That leaves the case of two different sessions with the same algorithm. I don't believe that's a real case; do you disagree? paul From owner-ipsec@lists.tislabs.com Mon Dec 9 13:13:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LD5E05207; Mon, 9 Dec 2002 13:13:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06598 Mon, 9 Dec 2002 15:45:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15861.304.587143.617182@pkoning.dev.equallogic.com> Date: Mon, 9 Dec 2002 15:46:40 -0500 From: Paul Koning To: henry@spsystems.net Cc: ipsec@lists.tislabs.com Subject: Re: Handling of IPcomp in IKEv2 References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Henry" == Henry Spencer writes: Henry> On Sun, 8 Dec 2002, Avram Shacham wrote: >> Even with that option available, the vast majority of IPComp >> implementations use the negotiated CPI (range 256-61439) rather >> than the well-known numbers... Henry> Most of the motive for this, I think, is that it's convenient Henry> to have a local object to hold state for compression -- the Henry> compression proper is usually stateless, but choice of Henry> algorithm, intelligent decision on whether to attempt Henry> compression, etc. require local state -- and negotiated CPIs Henry> let you give that state a number (although not very Henry> conveniently so, since the decompressor picks the CPI but it's Henry> the compressor that wants to keep state). Speaking as one former implementer: I used CPI == 256 always, because I didn't think I was allowed to pick a "well known" value on my own. But the compression state was simply bundled with the IPsec state, because for processing purposes you use all that stuff together. So the CPI was just 2 unnecessary bytes. paul From owner-ipsec@lists.tislabs.com Mon Dec 9 13:17:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LHcE05333; Mon, 9 Dec 2002 13:17:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06646 Mon, 9 Dec 2002 15:50:27 -0500 (EST) Date: Mon, 9 Dec 2002 22:51:48 +0200 (IST) From: Hugo Krawczyk To: "The Purple Streak, Hilarie Orman" cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: speaking of keys In-Reply-To: <200212070029.gB70TCC25166@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 6 Dec 2002, The Purple Streak, Hilarie Orman wrote: ..... > > Also, the Diffie-Hellman group is a single basket holding all past > session keys. Just because it is strong enough for one paranoid > usage doesn't account for the risk of having all past keys revealed. > You need a very healthy entropy margin to account for that. > > Hilarie > Hilarie, can you please explain what you mean by "very healthy entropy margin"? WHat is it needed for and how is it achieved? And what is a "single paranoid use"? If a DH group is eventually cryptanalyzed to the extent of allowing recovering the key g^xy from the public g^x and g^y for any key negotiated over that group then there is zero "entropy margin" left (regardless of what your key derivation and key usage does). So are you envisioning a cryptanalytical break that will allow for a partial discovery of the g^xy key? What do you mean by "entropy margin" in this case? Against partial cryptanalysis/leakage the best defense is the hashing that we do for deriving KEYSEED. BTW, the only solution that I know for preventing the catastrophic problem of a standarized group being fully cryptanlyzed is to use "private groups" (which adds management and computational complexity, as well as raises security issues about the generation of these groups), or using the "revided encryption mode" of IKE (which encrypts the DH exponentials under a private encryption key). Hugo From owner-ipsec@lists.tislabs.com Mon Dec 9 13:19:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LJIE05379; Mon, 9 Dec 2002 13:19:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06666 Mon, 9 Dec 2002 15:52:31 -0500 (EST) Date: Mon, 9 Dec 2002 15:53:12 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: speaking of keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 6 Dec 2002, Stephen Kent wrote: > I don't have a problem with a MAY for bigger groups, but I really > think it is most appropriate to focus on the management facility to > allow user communities to select their own, of whatever size they > feel is appropriate. While I have some sympathy with that, historically IPsec has suffered badly from an excess of useless flexibility, an unwillingness to make decisions among largely-equivalent alternatives, and an inability to set clear standards even when they are crucial to interoperability. If we think one choice is definitely preferable in most cases, but specific users may have reasons to prefer another, we have a word for that: not MAY, but SHOULD. And as a matter of basic principle, the default should be good security, with an option to weaken it when necessary, not poor security with an option to upgrade it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 9 13:49:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LnFE05924; Mon, 9 Dec 2002 13:49:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06995 Mon, 9 Dec 2002 16:20:38 -0500 (EST) Date: Mon, 9 Dec 2002 12:58:50 -0800 (PST) From: Avram Shacham To: Henry Spencer cc: IP Security List , Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, The only comment: Compression algorithms in IPComp MUST be stateless. Regards, avram > Date: Mon, 9 Dec 2002 12:14:04 -0500 (EST) > From: Henry Spencer > To: IP Security List > Subject: Re: Handling of IPcomp in IKEv2 > > On Sun, 8 Dec 2002, Avram Shacham wrote: > > Even with that option available, the vast majority of IPComp > > implementations use the negotiated CPI (range 256-61439) rather than the > > well-known numbers... > > Most of the motive for this, I think, is that it's convenient to have a > local object to hold state for compression -- the compression proper is > usually stateless, but choice of algorithm, intelligent decision on > whether to attempt compression, etc. require local state -- and negotiated > CPIs let you give that state a number (although not very conveniently so, > since the decompressor picks the CPI but it's the compressor that wants to > keep state). > > I don't think any significant amount of the negotiation is being done to > permit custom compression algorithms. > > Henry Spencer > henry@spsystems.net > > > > From owner-ipsec@lists.tislabs.com Mon Dec 9 13:49:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LnOE05939; Mon, 9 Dec 2002 13:49:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06977 Mon, 9 Dec 2002 16:19:36 -0500 (EST) X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: Russ Housley CC: ipsec@lists.tislabs.com Subject: Re: speaking of keys References: <3DF0557D.2314FC80@bell-labs.com> <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> <3DF0557D.2314FC80@bell-labs.com> <5.2.0.9.2.20021206180652.0273c0f0@mail.binhost.com> From: Geoff Keating Date: 09 Dec 2002 12:54:38 -0800 In-Reply-To: <5.2.0.9.2.20021206180652.0273c0f0@mail.binhost.com> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ Housley writes: > Steve: > > I support your recommendation. In fact, I was going to make the same > recommendation, but for a different reason. I few weeks ago, we had a > long thread discussing mandatory to implement signature algorithms. > We decided that RSA with 1024-bit keys will be mandatory to implement. > So, if 1024 bits is adequate for the signature, it seems like 1024 > should also be adequate for the key agreement algorithm. The threat model is different for signature vs. key agreement. An identity verification algorithm must be broken before the identity is verified to have any impact, and can be changed in a short time if it starts to become ineffective. A confidentality algorithm need only be broken before the data it protects loses value, which is a much longer timespan in IKE/IPSEC, and the algorithm used to protect data in the past can't be changed. Thus, it doesn't follow that the algorithm used for key agreement need not be more secure than the one used for identity verification. -- - Geoffrey Keating From owner-ipsec@lists.tislabs.com Mon Dec 9 13:49:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LnQE05949; Mon, 9 Dec 2002 13:49:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06978 Mon, 9 Dec 2002 16:19:36 -0500 (EST) Date: Mon, 9 Dec 2002 12:50:46 -0800 (PST) From: Avram Shacham To: Paul Koning cc: , , Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: <15861.180.334322.283410@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 9 Dec 2002, Paul Koning wrote: > >>>>> "Avram" == Avram Shacham writes: > > Avram> Paul, > > Avram> Risking repeating an earlier reply to Radia, the (once again) > Avram> attached implementation note from RFC-3173 details scenarios > Avram> where negotiated CPIs are required. (In short, when > Avram> compression sessions maintain attributes specific to each > Avram> session.) Moreover, the alternative to use a well-known CPI is > Avram> available in the current protocol, yet most implementations > Avram> are negotiating CPIs from 256-61439 range. > > I saw that, but I don't see how it applies in the setting Charlie > proposed. > > With IKEv1, it isn't clear whether the CPI numbering is local to the > compression session "within" the encryption session negotiated as a > set. > > Charlie's proposal is that with IKEv2, it is. I.e., you are > negotiating what compression will be used within the context of the > IPsec SAs. > > The question amounts to: do you ever require more than one compression > session within a SINGLE encryption session? No. > > One case has been suggested: multiple compression algorithms, where > you can pick one or the other per-packet. That requirement has never been raised in ippcp wg or on the lists, and therefore does not seem to be needed. > Radia's proposal supports that directly, because what was the CPI is > now the algorithm ID. That option is already part of the protocol. Still, repeating the observation, most implementations prefer to negotiate the CPI rather than use the well-known algorithm numbers. > > That leaves the case of two different sessions with the same > algorithm. I don't believe that's a real case; do you disagree? > Hopefully, we are in agreement :) Regards, avram From owner-ipsec@lists.tislabs.com Mon Dec 9 13:53:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LrkE06149; Mon, 9 Dec 2002 13:53:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07120 Mon, 9 Dec 2002 16:26:44 -0500 (EST) Date: Mon, 9 Dec 2002 16:27:47 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 9 Dec 2002, Avram Shacham wrote: > > local object to hold state for compression -- the compression proper is > > usually stateless, but choice of algorithm, intelligent decision on > > whether to attempt compression, etc. require local state... > > The only comment: Compression algorithms in IPComp MUST be stateless. I would phrase that slightly differently: *decompression* algorithms in IPComp MUST be stateless. It is not unthinkable to have a compression algorithm which maintains state to decide how to *best* compress the next packet -- a generalization of the use of heuristics to decide whether to attempt compression -- provided that the corresponding decompression algorithm can always decompress any packet. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 9 13:54:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9LsHE06213; Mon, 9 Dec 2002 13:54:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07114 Mon, 9 Dec 2002 16:26:42 -0500 (EST) Message-Id: <5.2.0.9.2.20021209162601.02a4bd98@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 09 Dec 2002 16:27:24 -0500 To: Geoff Keating From: Russ Housley Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.2.20021206180652.0273c0f0@mail.binhost.com> <3DF0557D.2314FC80@bell-labs.com> <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> <3DF0557D.2314FC80@bell-labs.com> <5.2.0.9.2.20021206180652.0273c0f0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Geoff: I understand this asymmetry. However, if one is trying to design hardware to accelerate the processing, then it would be nice to have a common size for all of the public key operations. Russ At 12:54 PM 12/9/2002 -0800, Geoff Keating wrote: >Russ Housley writes: > > > Steve: > > > > I support your recommendation. In fact, I was going to make the same > > recommendation, but for a different reason. I few weeks ago, we had a > > long thread discussing mandatory to implement signature algorithms. > > We decided that RSA with 1024-bit keys will be mandatory to implement. > > So, if 1024 bits is adequate for the signature, it seems like 1024 > > should also be adequate for the key agreement algorithm. > >The threat model is different for signature vs. key agreement. An >identity verification algorithm must be broken before the identity is >verified to have any impact, and can be changed in a short time if it >starts to become ineffective. A confidentality algorithm need only be >broken before the data it protects loses value, which is a much longer >timespan in IKE/IPSEC, and the algorithm used to protect data in the >past can't be changed. Thus, it doesn't follow that the algorithm >used for key agreement need not be more secure than the one used for >identity verification. > >-- >- Geoffrey Keating From owner-ipsec@lists.tislabs.com Mon Dec 9 14:04:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB9M4VE06772; Mon, 9 Dec 2002 14:04:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07184 Mon, 9 Dec 2002 16:34:59 -0500 (EST) Date: Mon, 9 Dec 2002 23:35:56 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: speaking of keys In-Reply-To: <5.2.0.9.2.20021206180652.0273c0f0@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, I am fine with 1024-bit DH group as must-to-implement today. (At least for those that assume that no attacker is interested to record their traffic today and be able to decrypt it in a few years, in which case a longer modulus may be recommended.) Yet your analogy to signature-key size does not hold. Breaking your signatures in two years from now is meaningless if you revoked your key/certificates in the meantime. In the case of DH, however, the secrecy of the key (if used to derive data encryption keys) may need to be protected long after the DH key is expired and removed from memory. Therefore the security requirements on DH (especially standarized groups) are more stringent, in general, than on signatures. Hugo On Fri, 6 Dec 2002, Russ Housley wrote: > Steve: > > I support your recommendation. In fact, I was going to make the same > recommendation, but for a different reason. I few weeks ago, we had a long > thread discussing mandatory to implement signature algorithms. We decided > that RSA with 1024-bit keys will be mandatory to implement. So, if 1024 > bits is adequate for the signature, it seems like 1024 should also be > adequate for the key agreement algorithm. > > Russ > From owner-ipsec@lists.tislabs.com Mon Dec 9 16:57:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBA0v2E15650; Mon, 9 Dec 2002 16:57:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07976 Mon, 9 Dec 2002 19:28:07 -0500 (EST) Message-Id: <200212100029.gBA0TRBx002980@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-reply-to: Your message of "Mon, 09 Dec 2002 14:56:52 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 09 Dec 2002 19:29:26 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Avram" == Avram Shacham writes: Avram> Not sure how to read >> the CPI was just 2 unnecessary bytes. Avram> The protocol is built to answer the generic scenarios, and a private case, Avram> where the system supports a single compression algorithm and uses no Avram> params, is, ahem, a private case, which, as you stated, works. Yes... I would suggest that the context of it being within an ESP, is probably a "semi-private" case... I vote for using the well-known CPIs, announced like Henry suggested. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPfU1ZIqHRg3pndX9AQGosQP/eCz+2/ZgMXZMeWseJnUKVqGWA+Y7NZmU muQrdYcNapeeJn/hEl7sS6HQOKZpQCpdr7dNGrW2TPNmiiVzWJbYUiJdgMCPRdNz GYv6UwEG4Sw/tT3sAGlbEA/OdbMklJ4Bsfw7S3nWzviJRxLqNnfKPDZp6jWQNOp4 Ln0gRtDRAho= =1J0h -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 9 16:59:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBA0xAE15734; Mon, 9 Dec 2002 16:59:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08004 Mon, 9 Dec 2002 19:35:09 -0500 (EST) Message-Id: <200212100035.gBA0ZjMf021981@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Summary of revised identity changes In-Reply-To: Your message of "Sun, 08 Dec 2002 18:21:57 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 09 Dec 2002 19:35:45 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > a) For certificate authentication, in messages 3 and 4, you no longer > send both an ID and a certificate. Instead, you send only a > certificate and the receiver gets your identity from the certificate. > IKEv1 developers still cannot agree on how to use the identity with > the certificate. For example, some implementers reject messages where > the ID doesn't match any of the names in the certificate, others > accept it, still others don't even read the ID field, and still > others don't read the names from the certificate. The new proposal > eliminates the ambiguity. I like this. we still need to better nail down what should be done with the names inside the certs. > b) By telling the kind of ID that is accepted in messages 1 and 2, > you can safely avoid sending certificates if they are not needed. also a good thing. > c) Certificate requests are now hashes of the public key of the trust > anchor, not the DN name. This makes it clearer to each side exactly > which key is the trust anchor, since some trust anchor names are not > unique (such as after a key rollover). .. and you'd present both hashes *during* a graceful key rollover. > d) You can accept hash-and-URL of certs instead of the certs > themselves. This helps prevent fragmentation of UDP packets for large > certificates. yes. only "downside" is that it removes one source of pressure to keep certs small (perhaps a losing battle, though). - Bill From owner-ipsec@lists.tislabs.com Mon Dec 9 17:13:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBA1CxE16336; Mon, 9 Dec 2002 17:13:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08039 Mon, 9 Dec 2002 19:48:14 -0500 (EST) Date: Mon, 9 Dec 2002 17:44:14 -0700 Message-Id: <200212100044.gBA0iE003411@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: hugo@ee.technion.ac.il Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage Subject: Re: speaking of keys Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The security of a 1024-bit DH is too small for my comfort (that of a reasonable paranoid) for a single key exchange. I.e., I want my asymmetric keys to have more than 90 bits of strength and would recommend this policy to others. Further, knowing that ALL keys exchanged for IPSec would be protected by only this single mechanism, I want the computational cost for the discrete log attacker to be quite a bit higher, probably proportional to something like the number of keys expected to be exchanged for the next 20 years. That depends on how successful IPSec key exhange will be. Bet on success, assume Moore's Law falters somewhat, and add 20 bits. Altogether that totals at least 110 bits of strength and that's a modulus size of around 2048. Hilarie From owner-ipsec@lists.tislabs.com Mon Dec 9 19:52:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBA3qCE25013; Mon, 9 Dec 2002 19:52:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08645 Mon, 9 Dec 2002 22:22:29 -0500 (EST) Message-Id: <200212100150.gBA1obp3012139@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Summary of revised identity changes In-reply-to: Your message of "Mon, 09 Dec 2002 19:35:45 EST." <200212100035.gBA0ZjMf021981@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 09 Dec 2002 20:50:36 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >> a) For certificate authentication, in messages 3 and 4, you no longer >> send both an ID and a certificate. Instead, you send only a >> certificate and the receiver gets your identity from the certificate. I'm profoundly unhappy about this. I feel that it will lead to massive amounts of failure to interoperate. Right now, I can make an X.509 implementation and a non-X.509 implementation (such as might be found in a handheld!) interop by arranging for appropriate keys to be in the right places. I.e. I can generate the handheld's "certificate" in a number of ways that doesn't involve having the handheld actually know about X.509. The contents of the CERT payload is just "bytes" - doesn't matter to the handheld. Now, if you do this, then the handheld winds up with goop it doesn't understand setting policy for it. Maybe this is appropriate for you, but not for me. I fear strongly that this proposal will permanently wed people to the false belief that public key operations involve PKIs. By all means, make the contents of certificates clear. But, they aren't to be involved in the identities. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPfVIaoqHRg3pndX9AQFqGAP+Jp32hnaRe3IXQHAuUHeIo+Ge3+sXcw6O Bg4OEOy2yaTnhnj3ffTab36+VYGJEvvDxgQ53+MUSfSU3ZI+9HSEbPrC1wFof62B Sruk3aCcfbAu75myF0TgBIVkqELcgc65FEUZKvoJ+2U2Erbf7Ap9fTGO+fO2JyxJ X4qgFRbinJo= =Mlf6 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 9 21:04:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBA545E27602; Mon, 9 Dec 2002 21:04:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08741 Mon, 9 Dec 2002 23:28:09 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200212100150.gBA1obp3012139@sandelman.ottawa.on.ca> References: <200212100150.gBA1obp3012139@sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 9 Dec 2002 20:29:21 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Summary of revised identity changes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:50 PM -0500 12/9/02, Michael Richardson wrote: > >> a) For certificate authentication, in messages 3 and 4, you no longer > >> send both an ID and a certificate. Instead, you send only a > >> certificate and the receiver gets your identity from the certificate. > Right now, I can make an X.509 implementation and a non-X.509 >implementation (such as might be found in a handheld!) interop by arranging >for appropriate keys to be in the right places. And you still can under the proposal. Read what it says: "For *certificate* identification". There are other methods listed in the proposal. What isn't in the current proposal is hashes of bare keys, but that's easy to add. If we do, you still don't need IDs: the hash of the key is the ID. Does the WG want bare public keys as part of this? > I fear strongly that this proposal will permanently wed people to the >false belief that public key operations involve PKIs. They won't if we add bare public keys. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Dec 9 21:05:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBA55CE27638; Mon, 9 Dec 2002 21:05:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08756 Mon, 9 Dec 2002 23:38:13 -0500 (EST) X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD01FEAA55@mailserver.sylantro.com> From: "Eric Nielsen" To: ipsec@lists.tislabs.com cc: stu.jacobs@verizon.com Subject: A security model for legacy authentication: username:passphrase Date: Mon, 9 Dec 2002 20:36:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11EBB0EE52984-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Legacy authentication was one of the issues that came up in the last IETF meeting. In particular the need to support something based on userid:passphrase pairs. Stu Jacobs and I are put together this white paper describing a security model based on UserID:Passphrase that might be possible using IPsec/IKE someday... ============================================================== A security model supporting the legacy UserID:Passphrase the authentication model that won't go away! Eric Nielsen, Sylantro Systems Stu Jacobs CISSP, Verizon Draft Dec. 9, 2002 Introduction ============ Despite many technically superior choices, UserID:Passphrase pairs remain the most used means for assuring a user's communications are authentic. It has worked well enough. What has been a major security concern is how this data is entered and stored. Highly random passwords remain problematic for people too. Systems that persistently store these passwords can be corrupted, and the overuse of the password incrementally weakens the security it intends to assure. This paper has a security model to co-ordinates the use of UserID:Passphrase pairs used at an application level with strong public-private key pairs at the device level. It is a model derived from VoIP security requirements published by these authors. Players in the model ==================== This model is described in terms of the players, human and machine, that are involved in the model. This is to clarify the identities involved, what is authenticated to what, and who retains what information. The secure relationship starts out between a User and a Service Provider. There is one asymmetric element in this model that separates a User from a Service Provider. Otherwise they can interact as peers. The difference is that the "User" initiates the secure relationship from an "Endpoint" that does not store the User's passphrase, and the "Service Provider's" "Server" can automatically authenticate a message against a stored copy of the User's passphrase. User: Typically a human or process acting as a proxy for an individual or organization. Service Provider: The organization that administratively agrees to provide Users some service. Contract: Some agreement between a User and a Service Provider. In this case it is to provide an application layer service. User ID: The identity associated with a user of the service. Passphrase: The character string/biometric/other information that has been secretly shared between the User and the Service Provider prior to any network interaction. Service: The network interactions that the user is authorized to access. Server: The device (or logical group of devices) that provides a logical whole the service for the User. The server is assumed secure enough to have persistent access to registrar that can authenticate the User's passphrase. Endpoint: A device used by a user to access the Service Provider's service. The endpoint is not assumed secure enough to store the persistent passphrase. Persistent Proxy Authenticator (PPA): The PPA is an identity that is generated on a device. It has no rights except as a means to provide a cryptographically secure relationship for applications that run on that device. This device identity consists only of a public/private key pair that by itself has no rights. For the PPA to act as a proxy, a User must authentication in the context of the PPA. This gives the PPA the transient right to authenticate as if it had the rights of the User, and is the basis for creating session keys for network traffic authentication. Until the User withdraws this right, or policy causes it to expire, the PPA will persist as a proxy for the User without storing the User's authentication key/passphrase. The Model ========= The model consists of an identity to be authenticated, as well as authentication at the application, device, and network levels. It also adds a PPA in as a mechanism to map between these layers and sustain these connections. Application Level Identity: How does the Server know whom it is interacting with? Initially the User and the Service Provider make an out-of-band contract. The contract, like the process of acquiring a phone number from a carrier today, is the basis for trust. This does not mean that the User has represented his/her/its identity absolutely. Instead, independent of the personal information provided, a UserID is chosen to identify the user in context of contracts with this service provider. Application Level Authentication: The User enters the UserID and Passphrase pair as the basis for authenticating communications between the Endpoint device and the Service Provider's Server. Both ends of the communication must prove they know the shared Passphrase associated with the User ID. This must be done without any disclosure. Further, the material used to mutually authenticate the User <-> Service Provider connection is decoupled from the continuing authentication of communication between the Service Provider's Server and the User's Endpoint. Device Level Authentication: Application level authentication (User <-> Service Provider) is the basis for creating a machine-to-machine layer relationship. The Server and the Endpoint must both have a public/private key pair. These key pairs do not require third party assurance of the identity nor require that any identity be bound to the key pairs as in a certificate. The devices exchange public key in the context of the application level authentication. In other words, the authentication of the UserID:Passphrase pair enables the meaningful exchange of public keys between devices. Now these public keys can be used on behalf of the User and the Service Provider. In this model this creates a Persistent Proxy Authenticator (or PPA). Each Endpoint device can now act as the PPA for the User, and the Server acts as a PPA for the Service Provider. Network Level Authentication: The public/private key pairs of the two PPAs are the basis to exchange session keys. These session keys may expire based on policy (time, kbytes sent, IP address change, reboot) set by either end of the communications. Upon expiration of a session key a new key will be created based on the device level authentication. It is possible that the session key is generated by the Server and sent encrypted to the Endpoint device. PPA Persistence: PPAs are intended to persist past a single use, over Endpoint and Server reboots, etc. The PPA key is expected to be stored securely on the device, inaccessible to any user. PPAs do not store the Passphrase of the User, and uses only its public/private key pair to establish session keys. If either the Endpoint or the Server determine that the PPA requires revalidation, the PPA can act as a proxy for a user no longer. Thus, PPAs can reestablish a session key on behalf of the UserID without knowing the User's Passphrase. Local policies determine when a new session key is necessary. Either end of communications can decide to challenge the validity of the other end's PPA. To revalidate the PPA the UserID and Passphrase must be re-entered by the User. It is valid to have PPAs that do not expire. There is no negotiation in this process, either end can deny the other's validity anytime. In this model the scope of the identity being authenticated is local. If the Service Provider happens to be a telephone company, for example, then it is administratively responsible for assuring the mapping between the UserID (an E.164 phone number) and the User. The mechanisms provided in this model are adequate to map the UserID to a device or devices. Local authentication by a recognized service provider can have real network-wide meaning. Implementing this Legacy Authentication ======================================= TLS --- This model can be mapped into TLS reasonably well. TLS is directly built into applications using an API. Maintaining these identities and authentication within a single application process is straightforward. It is important that authentication be maintained when a session is redirected to alternate Servers. One of the requirements associated with large-scale authentication is the need to reduce the burden associated with recovering huge numbers of sessions simultaneously after some disaster. Session key persistence across multiple hosts is possible in this model. IPsec ----- There is more than one way that IPsec might support this model, although it will not work "out of the box" as it stands today. It seems logical to use IPsec at the network level, and possibly IKEv2 (???) at the device level. There is a gap on how the network level security maps to security at the Application Level. To implement this model with IPsec, session key establishment must occur in two different situations: a) when a pair of PPAs are currently associated with a UserID. b) where PPAs do not yet exist, and need to be associated with a UserID. And there must be one final link. The application must know which UserID is the basis for authenticating each application level message. If an IPsec Security Association expires, both sides must be able to renew that session key automatically based on the public key pairs. IKE can create a Security Association based on certificates. For case a) the exchange is initiated by public/private key pairs that have localized, temporal associations with UserIDs. It is a stretch to certificate semantics to include this kind of temporal association. A better semantic would be to have a self-signed certificate where the only identifier is the common name (CN), where the CN=. It is up to the application to determine whether a UserID is still associated with a particular Public Key. In other words, a PKI is unnecessary. To support this IKE must be flexible enough to use keying material in this way. For case b) IKE would have to accept public keys from remote Endpoints/Servers based on the application level authentication. To accept the public key, IKE must allow a link to the application to validate the UserID:Passphrase pair, and thus authenticate the exchange of public keys for use. Subsequent messages sent to/from an application should be associated with a UserID. Security Associations must use the IPsec SPI to make each connection unique. It is possible that multiple applications may share the IPaddress:port source/destination combination, thus the SPI is the differentiator. IPsec could maintain the UserID to public key relationship, or the application could maintain it. The main issue is that the application knows the UserID the message was authenticated for, and that the application can choose to reestablish a new session key or PPA relationship at any time. An advantage of this model is that public/private key pair can be generated privately and dynamically at the Endpoint (even if it requires many minutes of real time to generate). It can take some time to acquire enough randomness to generate a new key, it would happen infrequently. This approach allows the private key of the PPA to be more secure. The key is never disclosed to any other device. The only way to extract the PPA's private key is by gaining "root" access on the device. There can be multiple concurrent PPAs on a device. From owner-ipsec@lists.tislabs.com Mon Dec 9 21:42:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBA5g0E29059; Mon, 9 Dec 2002 21:42:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08880 Tue, 10 Dec 2002 00:16:53 -0500 (EST) From: ji@research.att.com Date: Tue, 10 Dec 2002 00:18:19 -0500 (EST) Message-Id: <200212100518.AAA28963@bual.research.att.com> To: ipsec@lists.tislabs.com Subject: Re: Summary of revised identity changes Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So exactly *which* systems that we have in our legacy used userid/password for their IPsec authentication and we need to keep them around? /ji From owner-ipsec@lists.tislabs.com Tue Dec 10 05:45:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBADjmE24024; Tue, 10 Dec 2002 05:45:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09658 Tue, 10 Dec 2002 08:16:26 -0500 (EST) Message-Id: <5.2.0.9.2.20021210075142.02a63088@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 10 Dec 2002 08:17:52 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Summary of key derivation thread Cc: daw@mozart.cs.berkeley.edu In-Reply-To: References: <200212051428.JAA34568@ornavella.watson.ibm.com> <3DEF8A1E.D988B6E3@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Wagner wrote: >This objection has already been addressed on the list. Those 1024 >bits of Diffie-Hellman only have 160 bits of strength (160 bits of >"computational entropy"), hence you're not reducing security by hashing >it down to 160 bits. > >Indeed, in some sense you are improving security by hashing the 1024-bit >Diffie-Hellman result down to a 160-bit security, just as Hugo's earlier >note pointed out. Can I encourage you to re-read Hugo's earlier emails >on this topic? I hope you will find them persuasive. (I certainly did.) I do not think we can select mandatory-to-implement algorithms without agreement on the level of security that we are attempting to provide. In my mind, this leads to two interrelated questions. First a summary of the consensus. A 1024-bit Diffie-Hellman result has 160 bits of entropy. HMAC-SHA-1 has a 160-bit output value, so there is a good impedance match here. This provides 80 bits of strength. By now, I think that people who have been reading this thread carefully have gotten these points. Question 1: Currently, the mandatory-to-implement requirement is bigger than 1024-bit Diffie-Hellman. So, with the larger value, is a different PRF needed to obtain a similar impedance match? Question 2: Based on the NIST key management recommendations, a 80 bits of security is adequate for protecting sensitive government information until 2015, and 112 bits of security is adequate until 2030. Which of these targets is the mandatory-to-implement aiming at? Or, are we after something in the middle, say 96 bits? Russ From owner-ipsec@lists.tislabs.com Tue Dec 10 06:03:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAE3nE24663; Tue, 10 Dec 2002 06:03:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09767 Tue, 10 Dec 2002 08:41:34 -0500 (EST) Date: Mon, 9 Dec 2002 16:55:50 -0800 (PST) From: Avram Shacham To: Michael Richardson cc: , Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: <200212100029.gBA0TRBx002980@sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As long as the generic case (i.e., negotiating a CPI) is also supported, all should be okay. avram On Mon, 9 Dec 2002, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Avram" == Avram Shacham writes: > Avram> Not sure how to read > >> the CPI was just 2 unnecessary bytes. > > Avram> The protocol is built to answer the generic scenarios, and a private case, > Avram> where the system supports a single compression algorithm and uses no > Avram> params, is, ahem, a private case, which, as you stated, works. > > Yes... I would suggest that the context of it being within an ESP, is > probably a "semi-private" case... I vote for using the well-known CPIs, > announced like Henry suggested. > > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPfU1ZIqHRg3pndX9AQGosQP/eCz+2/ZgMXZMeWseJnUKVqGWA+Y7NZmU > muQrdYcNapeeJn/hEl7sS6HQOKZpQCpdr7dNGrW2TPNmiiVzWJbYUiJdgMCPRdNz > GYv6UwEG4Sw/tT3sAGlbEA/OdbMklJ4Bsfw7S3nWzviJRxLqNnfKPDZp6jWQNOp4 > Ln0gRtDRAho= > =1J0h > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Tue Dec 10 06:04:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAE45E24679; Tue, 10 Dec 2002 06:04:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09750 Tue, 10 Dec 2002 08:40:36 -0500 (EST) Date: Mon, 9 Dec 2002 14:56:52 -0800 (PST) From: Avram Shacham To: Paul Koning cc: , Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Not sure how to read > the CPI was just 2 unnecessary bytes. The protocol is built to answer the generic scenarios, and a private case, where the system supports a single compression algorithm and uses no params, is, ahem, a private case, which, as you stated, works. Regards, avram > Date: Mon, 9 Dec 2002 15:46:40 -0500 > From: Paul Koning > To: henry@spsystems.net > Cc: ipsec@lists.tislabs.com > Subject: Re: Handling of IPcomp in IKEv2 > > >>>>> "Henry" == Henry Spencer writes: > > Henry> On Sun, 8 Dec 2002, Avram Shacham wrote: > >> Even with that option available, the vast majority of IPComp > >> implementations use the negotiated CPI (range 256-61439) rather > >> than the well-known numbers... > > Henry> Most of the motive for this, I think, is that it's convenient > Henry> to have a local object to hold state for compression -- the > Henry> compression proper is usually stateless, but choice of > Henry> algorithm, intelligent decision on whether to attempt > Henry> compression, etc. require local state -- and negotiated CPIs > Henry> let you give that state a number (although not very > Henry> conveniently so, since the decompressor picks the CPI but it's > Henry> the compressor that wants to keep state). > > Speaking as one former implementer: I used CPI == 256 always, because > I didn't think I was allowed to pick a "well known" value on my own. > But the compression state was simply bundled with the IPsec state, > because for processing purposes you use all that stuff together. So > the CPI was just 2 unnecessary bytes. > > paul > > > > From owner-ipsec@lists.tislabs.com Tue Dec 10 06:04:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAE4cE24709; Tue, 10 Dec 2002 06:04:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09749 Tue, 10 Dec 2002 08:40:36 -0500 (EST) Date: Mon, 9 Dec 2002 15:57:29 -0800 (PST) From: Avram Shacham To: Henry Spencer cc: IP Security List , Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, The difference seems only in terminology: * The compression algorithm (LZS, DEFLATE, et al) MUST be stateless, as defined in RFC-3173: 2. Compression Process [...] Each IP datagram is compressed and decompressed by itself without any relation to other datagrams ("stateless compression"), as IP datagrams may arrive out of order or not arrive at all. Each compressed IP datagram encapsulates a single IP payload. * IPComp protocol may contain state information in order to provide better performance, as defined in section 2.2. "Non-Expansion Policy" of rfc-3173, and as you precisely described. Regards, avram > > Date: Mon, 9 Dec 2002 16:27:47 -0500 (EST) > From: Henry Spencer > To: IP Security List > Subject: Re: Handling of IPcomp in IKEv2 > > On Mon, 9 Dec 2002, Avram Shacham wrote: > > > local object to hold state for compression -- the compression proper is > > > usually stateless, but choice of algorithm, intelligent decision on > > > whether to attempt compression, etc. require local state... > > > > The only comment: Compression algorithms in IPComp MUST be stateless. > > I would phrase that slightly differently: *decompression* algorithms in > IPComp MUST be stateless. > > It is not unthinkable to have a compression algorithm which maintains > state to decide how to *best* compress the next packet -- a generalization > of the use of heuristics to decide whether to attempt compression -- > provided that the corresponding decompression algorithm can always > decompress any packet. > > Henry Spencer > henry@spsystems.net > > > > From owner-ipsec@lists.tislabs.com Tue Dec 10 08:17:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAGHYE06467; Tue, 10 Dec 2002 08:17:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10586 Tue, 10 Dec 2002 10:39:22 -0500 (EST) From: Marc.Solsona@nokia.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: Change of SA source IP address Date: Tue, 10 Dec 2002 07:28:48 -0800 Message-ID: <59A36C4D2F9E7243BEB522274F72C30389B63A@mvebe001.americas.nokia.com> Thread-Topic: Summary of revised identity changes Thread-Index: AcKgDrO4sVCT7jQGSgmeFCJ85zw/0AAUW9CL To: X-OriginalArrivalTime: 10 Dec 2002 15:28:49.0362 (UTC) FILETIME=[D65E8B20:01C2A060] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA10540 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would like to send a general question out to see how the different implementations would react against such event. I am trying to deal with a case were the SRC address of a outgoing SA may change. It could be due to several reasons (route/interface change, failover). How is/should the remote peer react against such event? In case of an IPsec-aware NAT device. Would it change the src IP address? thank you very much, marc. From owner-ipsec@lists.tislabs.com Tue Dec 10 09:28:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAHSnE11070; Tue, 10 Dec 2002 09:28:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10706 Tue, 10 Dec 2002 11:52:18 -0500 (EST) Date: Tue, 10 Dec 2002 11:53:22 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 9 Dec 2002, Avram Shacham wrote: > The difference seems only in terminology... Yes, it's basically a fine point of terminology, but not an entirely insignificant one. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Dec 10 10:11:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAIBgE14638; Tue, 10 Dec 2002 10:11:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10858 Tue, 10 Dec 2002 12:39:59 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15862.10019.670283.734700@thomasm-u1.cisco.com> Date: Tue, 10 Dec 2002 09:40:51 -0800 (PST) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Summary of revised identity changes In-Reply-To: References: <200212100150.gBA1obp3012139@sandelman.ottawa.on.ca> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > What isn't in the current proposal is hashes of bare keys, but that's > easy to add. If we do, you still don't need IDs: the hash of the key > is the ID. Does the WG want bare public keys as part of this? I'd like to see this functionality preserved, yes. If only it had been the *only* kind of public key identity... we'd probably see a lot less use of password based legacy auth. Mike From owner-ipsec@lists.tislabs.com Tue Dec 10 10:18:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAIIbE15132; Tue, 10 Dec 2002 10:18:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10873 Tue, 10 Dec 2002 12:40:59 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15862.10086.30321.143743@thomasm-u1.cisco.com> Date: Tue, 10 Dec 2002 09:41:58 -0800 (PST) To: ji@research.att.com Cc: ipsec@lists.tislabs.com Subject: Re: Summary of revised identity changes In-Reply-To: <200212100518.AAA28963@bual.research.att.com> References: <200212100518.AAA28963@bual.research.att.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ji@research.att.com writes: > So exactly *which* systems that we have in our legacy used > userid/password for their IPsec authentication and we need to keep them around? Anything that uses RADIUS? You don't have to like it to acknowledge its existence. Mike From owner-ipsec@lists.tislabs.com Tue Dec 10 11:43:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAJhmE24748; Tue, 10 Dec 2002 11:43:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11172 Tue, 10 Dec 2002 14:10:06 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15862.15418.338000.948621@gargle.gargle.HOWL> Date: Tue, 10 Dec 2002 14:10:50 -0500 From: Paul Koning To: shacham@shacham.net Cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 References: <200212100029.gBA0TRBx002980@sandelman.ottawa.on.ca> X-Mailer: VM 7.07 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Avram" == Avram Shacham writes: Avram> As long as the generic case (i.e., negotiating a CPI) is also Avram> supported, all should be okay. I think the whole point of the present proposal is that it eliminates any purpose for negotiating a CPI. I've read over your notes pretty carefully but I haven't seen anything that refutes it. If you disagree, you might want to describe a (real world) usage scenario that can't be supported by the proposal Charlie made. paul From owner-ipsec@lists.tislabs.com Tue Dec 10 12:21:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAKLLE29386; Tue, 10 Dec 2002 12:21:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11244 Tue, 10 Dec 2002 14:38:21 -0500 (EST) Message-Id: <5.1.0.14.0.20021210175903.049a1d18@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Dec 2002 18:17:27 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Change of SA source IP address In-Reply-To: <59A36C4D2F9E7243BEB522274F72C30389B63A@mvebe001.americas.n okia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA10760 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:28 10.12.2002 -0800, you wrote: >I would like to send a general question out to see how the different >implementations would react against such event. > >I am trying to deal with a case were the SRC address of a outgoing SA may >change. It could be due to several reasons (route/interface change, failover). > >How is/should the remote peer react against such event? > >In case of an IPsec-aware NAT device. Would it change the src IP address? > >thank you very much, >marc. OK, this is for today's IPv4. mobile IPv6 is another story, I will not talk about that. change of the SRC address is a rather common thing if you do ipsec through a NAT device. The ESP packet will be UDP-encapsulated. Tunnel mode is used. If the client fails do send traffic for some time, the NAT device forgets about the mapping and the next ipsec packet will create a new mapping. How should the peer react? Since an ipsec device can choose the SPI for it's incoming traffic, it is easy to identify the SA only by the SPI of the packet. Do the replay check. Do the integrity check. If that succeeds, you'll send future ipsec traffic with the counterpart (outgoing) SA to the new IP address (and the new ESPoUDP port). We have implemented further checks. For instance, if the client used an IP address for Phase 1 ID, we do not allow an IP address change. J–rn From owner-ipsec@lists.tislabs.com Tue Dec 10 12:33:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAKXeE00529; Tue, 10 Dec 2002 12:33:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11298 Tue, 10 Dec 2002 15:02:36 -0500 (EST) Date: Tue, 10 Dec 2002 12:03:06 -0800 Subject: Re: speaking of keys Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Russ Housley , Stephen Kent , ipsec@lists.tislabs.com To: Hugo Krawczyk From: Derrell Piper In-Reply-To: Message-Id: <66066379-0C7A-11D7-98CD-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What's the current state-of-the-art for COTS hardware accelerators? It was the case a few years back that many public-key chips didn't do >1024 bit DH groups. What's the story today? Do we care? Derrell On Monday, December 9, 2002, at 01:35 PM, Hugo Krawczyk wrote: > Russ, > > I am fine with 1024-bit DH group as must-to-implement today. > (At least for those that assume that no attacker is interested to > record > their traffic today and be able to decrypt it in a few years, > in which case a longer modulus may be recommended.) > Yet your analogy to signature-key size does not hold. > Breaking your signatures in two years from now is meaningless if you > revoked your key/certificates in the meantime. > In the case of DH, however, the secrecy of the key (if used to derive > data encryption keys) may need to be protected long after the DH key is > expired and removed from memory. > Therefore the security requirements on DH (especially standarized > groups) are more stringent, in general, than on signatures. > > Hugo > > On Fri, 6 Dec 2002, Russ Housley wrote: > >> Steve: >> >> I support your recommendation. In fact, I was going to make the same >> recommendation, but for a different reason. I few weeks ago, we had >> a long >> thread discussing mandatory to implement signature algorithms. We >> decided >> that RSA with 1024-bit keys will be mandatory to implement. So, if >> 1024 >> bits is adequate for the signature, it seems like 1024 should also be >> adequate for the key agreement algorithm. >> >> Russ >> > From owner-ipsec@lists.tislabs.com Tue Dec 10 12:46:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAKjxE01609; Tue, 10 Dec 2002 12:45:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11343 Tue, 10 Dec 2002 15:08:39 -0500 (EST) Date: Tue, 10 Dec 2002 22:09:53 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: ipsec@lists.tislabs.com, daw@mozart.cs.berkeley.edu Subject: Re: Summary of key derivation thread In-Reply-To: <5.2.0.9.2.20021210075142.02a63088@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, I have several remarks on your message: On Tue, 10 Dec 2002, Russ Housley wrote: > David Wagner wrote: > >This objection has already been addressed on the list. Those 1024 > >bits of Diffie-Hellman only have 160 bits of strength (160 bits of > >"computational entropy"), hence you're not reducing security by hashing > >it down to 160 bits. > > > >Indeed, in some sense you are improving security by hashing the 1024-bit > >Diffie-Hellman result down to a 160-bit security, just as Hugo's earlier > >note pointed out. Can I encourage you to re-read Hugo's earlier emails > >on this topic? I hope you will find them persuasive. (I certainly did.) > > I do not think we can select mandatory-to-implement algorithms without > agreement on the level of security that we are attempting to provide. In > my mind, this leads to two interrelated questions. > > First a summary of the consensus. A 1024-bit Diffie-Hellman result has 160 > bits of entropy. HMAC-SHA-1 has a 160-bit output value, so there is a good > impedance match here. This provides 80 bits of strength. By now, I think > that people who have been reading this thread carefully have gotten these > points. Actually the points as you summarize them are not accurate. Saying that DH has 160 bits of entropy can be misunderstood to mean that the best known attack on DH requires 2^160 operations. This is of course not true with a 1024-bit modulus. Today you can fully break a 1024 DH exchange (i.e recover the DH key g^xy from g^x and g^y) in something between 2^70 to 2^80 operations. Thus, by using a 1024-bit modulus you are essentially limited to no more than 70-80 bits of security. And no hashing of g^xy can improve that... What the hashing is meant to do is to avoid further shortcut attacks that would leak information on the key at much less than the 2^70 cost of fully breaking the DH exchange (e.g., if you use a generator of the group Zp* as your DH basis and do not hash the key then you can find the lsb of g^xy in less than a millisecond. > > Question 1: Currently, the mandatory-to-implement requirement is bigger > than 1024-bit Diffie-Hellman. So, with the larger value, is a different > PRF needed to obtain a similar impedance match? The strength of the prf should not be less than the strength of the DH group, but it doesn't help much to have a stronger prf either (that's why I referred to all the talking about the insufficiency of a 160-bit prf as noise, in particular you should use > 5000 bits of DH modulus to match 160 bit security). And, btw, there is no (known) feasible attack of the order of 2^80 against HMAC-SHA1. You can mount an attack in that order if you are allowed to make 2^80 queries to the prf, which is unrealistic in any application, and certainly in the key derivation application for which the prf is used here. > > Question 2: Based on the NIST key management recommendations, a 80 bits of > security is adequate for protecting sensitive government information until > 2015, and 112 bits of security is adequate until 2030. Which of these > targets is the mandatory-to-implement aiming at? Or, are we after > something in the middle, say 96 bits? I do not know what the "market answer" to this is. But even if you take the "NIST minimum" of 80, you need to go for a modulus longer than 1024, probably 1200 bits (Hilarie may have precise estimates). For 96 bits you already need to exceed the 2048-bit keys. Hugo > > Russ > > From owner-ipsec@lists.tislabs.com Tue Dec 10 13:23:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBALNZE04680; Tue, 10 Dec 2002 13:23:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11456 Tue, 10 Dec 2002 15:35:00 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: speaking of keys Date: 10 Dec 2002 20:13:15 GMT Organization: University of California, Berkeley Lines: 21 Distribution: isaac Message-ID: References: <200212100044.gBA0iE003411@localhost.localdomain> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1039551195 32303 128.32.153.211 (10 Dec 2002 20:13:15 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 10 Dec 2002 20:13:15 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Purple Streak, Hilarie Orman wrote: >The security of a 1024-bit DH is too small for my comfort (that of a >reasonable paranoid) for a single key exchange. But is it too small for the MUST requirement in the RFC? As I see it, we have to balance two costs here. If we require a 1024-bit modulus, there is a risk it will get broken in our lifetime. If we require a 2048-bit modulus, some people will not use IPSEC because it is too slow (this is not just a risk; this is for sure). How do we balance these two? At the moment, I'm inclined to suggest a 1024, 1200, or 1500-bit modulus for the MUST requirement. One thing I've learned from the 802.11 fiasco is that defaults matter, and it doesn't matter how good your crypto is if noone uses it (did you know that more than half of all 802.11 networks are still running unencrypted?). It seems unlikely to me that the Diffie-Hellman will be the weak point in most deployed systems, so I suspect the more conservative thing to do may be to maximize the number of systems using IPSEC. But, I don't feel all that strongly about it, and I won't complain if some other size is chosen. From owner-ipsec@lists.tislabs.com Tue Dec 10 14:09:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAM99E06861; Tue, 10 Dec 2002 14:09:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11604 Tue, 10 Dec 2002 16:10:59 -0500 (EST) Message-Id: <5.2.0.9.2.20021210160834.0295d888@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 10 Dec 2002 16:11:42 -0500 To: Hugo Krawczyk From: Russ Housley Subject: Re: Summary of key derivation thread Cc: ipsec@lists.tislabs.com, daw@mozart.cs.berkeley.edu In-Reply-To: References: <5.2.0.9.2.20021210075142.02a63088@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo: Thanks for the clarifications. More on my second question. > > Question 2: Based on the NIST key management recommendations, a 80 > bits of > > security is adequate for protecting sensitive government information until > > 2015, and 112 bits of security is adequate until 2030. Which of these > > targets is the mandatory-to-implement aiming at? Or, are we after > > something in the middle, say 96 bits? > >I do not know what the "market answer" to this is. >But even if you take the "NIST minimum" of 80, you need to go for >a modulus longer than 1024, probably 1200 bits (Hilarie may have precise >estimates). For 96 bits you already need to exceed the 2048-bit keys. The NIST key management guidance indicates that 1024-bit Diffie-Hellman and 1024-bit RSA provide 80 bits of security. Are you suggesting that this guidance is way off? Russ From owner-ipsec@lists.tislabs.com Tue Dec 10 14:17:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAMHWE07975; Tue, 10 Dec 2002 14:17:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11752 Tue, 10 Dec 2002 16:44:29 -0500 (EST) Message-Id: <4.3.2.7.2.20021210134008.01a61ff8@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Dec 2002 13:45:25 -0800 To: Hugo Krawczyk From: Scott Fluhrer Subject: Re: Summary of key derivation thread Cc: Russ Housley , ipsec@lists.tislabs.com, daw@mozart.cs.berkeley.edu In-Reply-To: References: <5.2.0.9.2.20021210075142.02a63088@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:09 PM 12/10/2002, Hugo Krawczyk wrote: >What the hashing is meant to do is to avoid further shortcut attacks that >would leak information on the key at much less than the 2^70 cost of >fully breaking the DH exchange (e.g., if you use a generator of the >group Zp* as your DH basis and do not hash the key then you can find the >lsb of g^xy in less than a millisecond. Nit: what you can find in less than a millisecond is the lsb of xy (or equivalently, whether g^xy is a quadratic residue). This does not give you the setting of any particular bit in g^xy. -- scott From owner-ipsec@lists.tislabs.com Tue Dec 10 14:24:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAMOiE08936; Tue, 10 Dec 2002 14:24:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11792 Tue, 10 Dec 2002 16:52:32 -0500 (EST) Date: Tue, 10 Dec 2002 23:53:56 +0200 (IST) From: Hugo Krawczyk To: Scott Fluhrer cc: IPsec WG Subject: Re: Summary of key derivation thread In-Reply-To: <4.3.2.7.2.20021210134008.01a61ff8@mira-sjcm-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You are surely right. This still gives you a "bit" in the entropy sense since it leaks the value of a Boolean predicate on the key (which, in particular, suffices to distinguish the DH key from random). Thanks for the correction. Hugo On Tue, 10 Dec 2002, Scott Fluhrer wrote: > At 12:09 PM 12/10/2002, Hugo Krawczyk wrote: > >What the hashing is meant to do is to avoid further shortcut attacks that > >would leak information on the key at much less than the 2^70 cost of > >fully breaking the DH exchange (e.g., if you use a generator of the > >group Zp* as your DH basis and do not hash the key then you can find the > >lsb of g^xy in less than a millisecond. > > Nit: what you can find in less than a millisecond is the lsb of xy (or > equivalently, whether g^xy is a quadratic residue). This does not give you > the setting of any particular bit in g^xy. > > -- > scott > From owner-ipsec@lists.tislabs.com Tue Dec 10 14:35:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBAMZfE09715; Tue, 10 Dec 2002 14:35:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11839 Tue, 10 Dec 2002 17:09:42 -0500 (EST) Date: Wed, 11 Dec 2002 00:10:54 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: IPsec WG Subject: Re: Summary of key derivation thread In-Reply-To: <5.2.0.9.2.20021210160834.0295d888@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 10 Dec 2002, Russ Housley wrote: > Hugo: > > Thanks for the clarifications. More on my second question. > > > > Question 2: Based on the NIST key management recommendations, a 80 > > bits of > > > security is adequate for protecting sensitive government information until > > > 2015, and 112 bits of security is adequate until 2030. Which of these > > > targets is the mandatory-to-implement aiming at? Or, are we after > > > something in the middle, say 96 bits? > > > >I do not know what the "market answer" to this is. > >But even if you take the "NIST minimum" of 80, you need to go for > >a modulus longer than 1024, probably 1200 bits (Hilarie may have precise > >estimates). For 96 bits you already need to exceed the 2048-bit keys. > > The NIST key management guidance indicates that 1024-bit Diffie-Hellman and > 1024-bit RSA provide 80 bits of security. Are you suggesting that this > guidance is way off? > > Russ > > I have never computed these things myself. However, according to Hilarie's draft on PK sizes it takes 2^80 operations to break a 1195-bit modulus (using NFS), and Lenstra and Veheul estimate the cost of breaking a 1024-bit group to be 2^72 operations. Hugo From owner-ipsec@lists.tislabs.com Tue Dec 10 15:11:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBANB6E10404; Tue, 10 Dec 2002 15:11:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11931 Tue, 10 Dec 2002 17:41:09 -0500 (EST) Date: Tue, 10 Dec 2002 15:38:09 -0700 Message-Id: <200212102238.gBAMc9J02240@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: daw@mozart.cs.berkeley.edu Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage Subject: Re: speaking of keys Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hopefully, on 10 Dec 2002 at 20:13:15 GMT David Wagner opined: > The Purple Streak, Hilarie Orman wrote: > >The security of a 1024-bit DH is too small for my comfort (that of a > >reasonable paranoid) for a single key exchange. > But is it too small for the MUST requirement in the RFC? It is too small for "the" MUST requirement. > As I see it, we have to balance two costs here. If we require a > 1024-bit modulus, there is a risk it will get broken in our lifetime. Insofar as I can predict two things at once, and speaking mainly for myself, it seems a certainty. > If we require a 2048-bit modulus, some people will not use IPSEC because > it is too slow (this is not just a risk; this is for sure). Where is it written that 2048 is too slow? Of course it is slower than 1024 and always will be, but in absolute terms, what requirements mandate that 2048 is unacceptable and will remain so for a significant number of years? > How do we balance these two? Back off to around 1500 bits or use a faster algorithm. Hilarie From owner-ipsec@lists.tislabs.com Tue Dec 10 22:14:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB6EFE03542; Tue, 10 Dec 2002 22:14:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12510 Wed, 11 Dec 2002 00:46:17 -0500 (EST) Message-ID: <001e01c2a0f1$b82b4080$76699d42@oemcomputer> From: "Justin Troutman" To: References: <200212100044.gBA0iE003411@localhost.localdomain> Subject: Re: speaking of keys Date: Wed, 11 Dec 2002 00:45:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Wagner wrote in message news:at5hsr$vhf$1@abraham.cs.berkeley.edu... > > As I see it, we have to balance two costs here. If we require a > 1024-bit modulus, there is a risk it will get broken in our lifetime. True. I agree. I feel more comfortable with there being a larger bit modulus selection for the requirement. > If we require a 2048-bit modulus, some people will not use IPSEC because > it is too slow (this is not just a risk; this is for sure). True again. Requirements of this size may hinder the use of IPSEC when speed is of the essence. >At the moment, I'm inclined to suggest a 1024, 1200, or 1500-bit modulus > for the MUST requirement. One thing I've learned from the 802.11 fiasco > is that defaults matter, and it doesn't matter how good your crypto > is if noone uses it Definitely, on the latter. I'll agree with this notion at the moment. It's a conservative choice, both in speed and strength. >(did you know that more than half of all 802.11 > networks are still running unencrypted?). It seems unlikely to me that > the Diffie-Hellman will be the weak point in most deployed systems, so I > suspect the more conservative thing to do may be to maximize the number > of systems using IPSEC. But, I don't feel all that strongly about it, > and I won't complain if some other size is chosen. Same here, agreed. Justin Troutman From owner-ipsec@lists.tislabs.com Tue Dec 10 23:04:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB74BE08713; Tue, 10 Dec 2002 23:04:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA12573 Wed, 11 Dec 2002 01:35:23 -0500 (EST) Date: Tue, 10 Dec 2002 22:34:43 -0800 (PST) From: Avram Shacham To: Paul Koning cc: , , Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: <15862.15418.338000.948621@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, IKE provides a way to establish IPComp sessions with the following: a. The actual usage of the protocol. b. Transform Identifier (aka compression algorithm, such as DEFLATE, LZS, ...) -- one per direction. c. A 16-bit CPI. d. Algorithm-related attributes. Such negotiations are pretty straight forward, and several dozens of interoperable implementations exist in the market place. (Which implies extensive discussions in the ippcp and ipsec wgs/lists and bakeoffs.) What of the above IKEv1 capabilities, if any, Charlie's suggestion plans to omit? If so, what are the savings -- i.e. in actual bytes in IKEv2 packet? In other words, what is the cost, if any, to keep the current functionality available in IKEv2? (Note that nowhere I mentioned IPComp being negotiated as part of a protocol-suite/menu/a-la carte. Leaving that issue out was intentional.) Regards, avram On Tue, 10 Dec 2002, Paul Koning wrote: > >>>>> "Avram" == Avram Shacham writes: > > Avram> As long as the generic case (i.e., negotiating a CPI) is also > Avram> supported, all should be okay. > > I think the whole point of the present proposal is that it eliminates > any purpose for negotiating a CPI. I've read over your notes pretty > carefully but I haven't seen anything that refutes it. If you > disagree, you might want to describe a (real world) usage scenario > that can't be supported by the proposal Charlie made. > > paul > > > From owner-ipsec@lists.tislabs.com Tue Dec 10 23:47:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB7lgE17106; Tue, 10 Dec 2002 23:47:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12741 Wed, 11 Dec 2002 02:19:48 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: speaking of keys Date: 10 Dec 2002 20:13:15 GMT Organization: University of California, Berkeley Lines: 21 Distribution: isaac Message-ID: References: <200212100044.gBA0iE003411@localhost.localdomain> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1039551195 32303 128.32.153.211 (10 Dec 2002 20:13:15 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 10 Dec 2002 20:13:15 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Purple Streak, Hilarie Orman wrote: >The security of a 1024-bit DH is too small for my comfort (that of a >reasonable paranoid) for a single key exchange. But is it too small for the MUST requirement in the RFC? As I see it, we have to balance two costs here. If we require a 1024-bit modulus, there is a risk it will get broken in our lifetime. If we require a 2048-bit modulus, some people will not use IPSEC because it is too slow (this is not just a risk; this is for sure). How do we balance these two? At the moment, I'm inclined to suggest a 1024, 1200, or 1500-bit modulus for the MUST requirement. One thing I've learned from the 802.11 fiasco is that defaults matter, and it doesn't matter how good your crypto is if noone uses it (did you know that more than half of all 802.11 networks are still running unencrypted?). It seems unlikely to me that the Diffie-Hellman will be the weak point in most deployed systems, so I suspect the more conservative thing to do may be to maximize the number of systems using IPSEC. But, I don't feel all that strongly about it, and I won't complain if some other size is chosen. From owner-ipsec@lists.tislabs.com Tue Dec 10 23:50:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB7oBE17415; Tue, 10 Dec 2002 23:50:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12744 Wed, 11 Dec 2002 02:19:48 -0500 (EST) Date: Tue, 10 Dec 2002 15:38:09 -0700 Message-Id: <200212102238.gBAMc9J02240@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: daw@mozart.cs.berkeley.edu Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage Subject: Re: speaking of keys X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hopefully, on 10 Dec 2002 at 20:13:15 GMT David Wagner opined: > The Purple Streak, Hilarie Orman wrote: > >The security of a 1024-bit DH is too small for my comfort (that of a > >reasonable paranoid) for a single key exchange. > But is it too small for the MUST requirement in the RFC? It is too small for "the" MUST requirement. > As I see it, we have to balance two costs here. If we require a > 1024-bit modulus, there is a risk it will get broken in our lifetime. Insofar as I can predict two things at once, and speaking mainly for myself, it seems a certainty. > If we require a 2048-bit modulus, some people will not use IPSEC because > it is too slow (this is not just a risk; this is for sure). Where is it written that 2048 is too slow? Of course it is slower than 1024 and always will be, but in absolute terms, what requirements mandate that 2048 is unacceptable and will remain so for a significant number of years? > How do we balance these two? Back off to around 1500 bits or use a faster algorithm. Hilarie From owner-ipsec@lists.tislabs.com Tue Dec 10 23:50:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB7oDE17432; Tue, 10 Dec 2002 23:50:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12745 Wed, 11 Dec 2002 02:19:50 -0500 (EST) Date: Tue, 10 Dec 2002 22:09:53 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: ipsec@lists.tislabs.com, daw@mozart.cs.berkeley.edu Subject: Re: Summary of key derivation thread In-Reply-To: <5.2.0.9.2.20021210075142.02a63088@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, I have several remarks on your message: On Tue, 10 Dec 2002, Russ Housley wrote: > David Wagner wrote: > >This objection has already been addressed on the list. Those 1024 > >bits of Diffie-Hellman only have 160 bits of strength (160 bits of > >"computational entropy"), hence you're not reducing security by hashing > >it down to 160 bits. > > > >Indeed, in some sense you are improving security by hashing the 1024-bit > >Diffie-Hellman result down to a 160-bit security, just as Hugo's earlier > >note pointed out. Can I encourage you to re-read Hugo's earlier emails > >on this topic? I hope you will find them persuasive. (I certainly did.) > > I do not think we can select mandatory-to-implement algorithms without > agreement on the level of security that we are attempting to provide. In > my mind, this leads to two interrelated questions. > > First a summary of the consensus. A 1024-bit Diffie-Hellman result has 160 > bits of entropy. HMAC-SHA-1 has a 160-bit output value, so there is a good > impedance match here. This provides 80 bits of strength. By now, I think > that people who have been reading this thread carefully have gotten these > points. Actually the points as you summarize them are not accurate. Saying that DH has 160 bits of entropy can be misunderstood to mean that the best known attack on DH requires 2^160 operations. This is of course not true with a 1024-bit modulus. Today you can fully break a 1024 DH exchange (i.e recover the DH key g^xy from g^x and g^y) in something between 2^70 to 2^80 operations. Thus, by using a 1024-bit modulus you are essentially limited to no more than 70-80 bits of security. And no hashing of g^xy can improve that... What the hashing is meant to do is to avoid further shortcut attacks that would leak information on the key at much less than the 2^70 cost of fully breaking the DH exchange (e.g., if you use a generator of the group Zp* as your DH basis and do not hash the key then you can find the lsb of g^xy in less than a millisecond. > > Question 1: Currently, the mandatory-to-implement requirement is bigger > than 1024-bit Diffie-Hellman. So, with the larger value, is a different > PRF needed to obtain a similar impedance match? The strength of the prf should not be less than the strength of the DH group, but it doesn't help much to have a stronger prf either (that's why I referred to all the talking about the insufficiency of a 160-bit prf as noise, in particular you should use > 5000 bits of DH modulus to match 160 bit security). And, btw, there is no (known) feasible attack of the order of 2^80 against HMAC-SHA1. You can mount an attack in that order if you are allowed to make 2^80 queries to the prf, which is unrealistic in any application, and certainly in the key derivation application for which the prf is used here. > > Question 2: Based on the NIST key management recommendations, a 80 bits of > security is adequate for protecting sensitive government information until > 2015, and 112 bits of security is adequate until 2030. Which of these > targets is the mandatory-to-implement aiming at? Or, are we after > something in the middle, say 96 bits? I do not know what the "market answer" to this is. But even if you take the "NIST minimum" of 80, you need to go for a modulus longer than 1024, probably 1200 bits (Hilarie may have precise estimates). For 96 bits you already need to exceed the 2048-bit keys. Hugo > > Russ > > From owner-ipsec@lists.tislabs.com Tue Dec 10 23:50:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB7oDE17436; Tue, 10 Dec 2002 23:50:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12743 Wed, 11 Dec 2002 02:19:48 -0500 (EST) Message-Id: <4.3.2.7.2.20021210134008.01a61ff8@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Dec 2002 13:45:25 -0800 To: Hugo Krawczyk From: Scott Fluhrer Subject: Re: Summary of key derivation thread Cc: Russ Housley , ipsec@lists.tislabs.com, daw@mozart.cs.berkeley.edu In-Reply-To: References: <5.2.0.9.2.20021210075142.02a63088@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:09 PM 12/10/2002, Hugo Krawczyk wrote: >What the hashing is meant to do is to avoid further shortcut attacks that >would leak information on the key at much less than the 2^70 cost of >fully breaking the DH exchange (e.g., if you use a generator of the >group Zp* as your DH basis and do not hash the key then you can find the >lsb of g^xy in less than a millisecond. Nit: what you can find in less than a millisecond is the lsb of xy (or equivalently, whether g^xy is a quadratic residue). This does not give you the setting of any particular bit in g^xy. -- scott From owner-ipsec@lists.tislabs.com Tue Dec 10 23:50:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB7oIE17475; Tue, 10 Dec 2002 23:50:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12740 Wed, 11 Dec 2002 02:19:44 -0500 (EST) Date: Wed, 11 Dec 2002 00:10:54 +0200 (IST) From: Hugo Krawczyk To: Russ Housley cc: IPsec WG Subject: Re: Summary of key derivation thread In-Reply-To: <5.2.0.9.2.20021210160834.0295d888@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 10 Dec 2002, Russ Housley wrote: > Hugo: > > Thanks for the clarifications. More on my second question. > > > > Question 2: Based on the NIST key management recommendations, a 80 > > bits of > > > security is adequate for protecting sensitive government information until > > > 2015, and 112 bits of security is adequate until 2030. Which of these > > > targets is the mandatory-to-implement aiming at? Or, are we after > > > something in the middle, say 96 bits? > > > >I do not know what the "market answer" to this is. > >But even if you take the "NIST minimum" of 80, you need to go for > >a modulus longer than 1024, probably 1200 bits (Hilarie may have precise > >estimates). For 96 bits you already need to exceed the 2048-bit keys. > > The NIST key management guidance indicates that 1024-bit Diffie-Hellman and > 1024-bit RSA provide 80 bits of security. Are you suggesting that this > guidance is way off? > > Russ > > I have never computed these things myself. However, according to Hilarie's draft on PK sizes it takes 2^80 operations to break a 1195-bit modulus (using NFS), and Lenstra and Veheul estimate the cost of breaking a 1024-bit group to be 2^72 operations. Hugo From owner-ipsec@lists.tislabs.com Tue Dec 10 23:50:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB7oPE17513; Tue, 10 Dec 2002 23:50:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12729 Wed, 11 Dec 2002 02:19:40 -0500 (EST) Message-Id: <5.2.0.9.2.20021210160834.0295d888@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 10 Dec 2002 16:11:42 -0500 To: Hugo Krawczyk From: Russ Housley Subject: Re: Summary of key derivation thread Cc: ipsec@lists.tislabs.com, daw@mozart.cs.berkeley.edu In-Reply-To: References: <5.2.0.9.2.20021210075142.02a63088@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo: Thanks for the clarifications. More on my second question. > > Question 2: Based on the NIST key management recommendations, a 80 > bits of > > security is adequate for protecting sensitive government information until > > 2015, and 112 bits of security is adequate until 2030. Which of these > > targets is the mandatory-to-implement aiming at? Or, are we after > > something in the middle, say 96 bits? > >I do not know what the "market answer" to this is. >But even if you take the "NIST minimum" of 80, you need to go for >a modulus longer than 1024, probably 1200 bits (Hilarie may have precise >estimates). For 96 bits you already need to exceed the 2048-bit keys. The NIST key management guidance indicates that 1024-bit Diffie-Hellman and 1024-bit RSA provide 80 bits of security. Are you suggesting that this guidance is way off? Russ From owner-ipsec@lists.tislabs.com Tue Dec 10 23:51:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBB7p2E17670; Tue, 10 Dec 2002 23:51:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12742 Wed, 11 Dec 2002 02:19:49 -0500 (EST) Date: Tue, 10 Dec 2002 23:53:56 +0200 (IST) From: Hugo Krawczyk To: Scott Fluhrer cc: IPsec WG Subject: Re: Summary of key derivation thread In-Reply-To: <4.3.2.7.2.20021210134008.01a61ff8@mira-sjcm-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You are surely right. This still gives you a "bit" in the entropy sense since it leaks the value of a Boolean predicate on the key (which, in particular, suffices to distinguish the DH key from random). Thanks for the correction. Hugo On Tue, 10 Dec 2002, Scott Fluhrer wrote: > At 12:09 PM 12/10/2002, Hugo Krawczyk wrote: > >What the hashing is meant to do is to avoid further shortcut attacks that > >would leak information on the key at much less than the 2^70 cost of > >fully breaking the DH exchange (e.g., if you use a generator of the > >group Zp* as your DH basis and do not hash the key then you can find the > >lsb of g^xy in less than a millisecond. > > Nit: what you can find in less than a millisecond is the lsb of xy (or > equivalently, whether g^xy is a quadratic residue). This does not give you > the setting of any particular bit in g^xy. > > -- > scott > From owner-ipsec@lists.tislabs.com Wed Dec 11 05:36:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBBDajE24188; Wed, 11 Dec 2002 05:36:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13434 Wed, 11 Dec 2002 08:04:11 -0500 (EST) Message-ID: <3DF6DA1C.BC5D0A3E@briank.com> Date: Tue, 10 Dec 2002 22:24:29 -0800 From: Brian Korver X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Derrell Piper CC: ipsec@lists.tislabs.com Subject: Re: speaking of keys References: <66066379-0C7A-11D7-98CD-000393CDFD1A@electric-loft.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell Piper wrote: > > What's the current state-of-the-art for COTS hardware accelerators? It > was the case a few years back that many public-key chips didn't do > >1024 bit DH groups. What's the story today? Do we care? > > Derrell Derrell, A bit over a year ago many accelerators went to 2048, although I think in general that operations performed with larger keys are slower than 1024-bit operations. -brian briank@briank.com From owner-ipsec@lists.tislabs.com Wed Dec 11 06:44:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBBEiME28505; Wed, 11 Dec 2002 06:44:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13569 Wed, 11 Dec 2002 09:16:48 -0500 (EST) Date: Wed, 11 Dec 2002 09:17:34 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 10 Dec 2002, Avram Shacham wrote: > IKE provides a way to establish IPComp sessions with the following: > a. The actual usage of the protocol. > b. Transform Identifier (aka compression algorithm... > c. A 16-bit CPI. > d. Algorithm-related attributes. > What of the above IKEv1 capabilities, if any, Charlie's suggestion plans > to omit? It makes (c) superfluous, and omits (d) except insofar as you might be able to do a little of it by using different predefined identifiers. > If so, what are the savings -- i.e. in actual bytes in IKEv2 > packet? In other words, what is the cost, if any, to keep the current > functionality available in IKEv2? Bytes in the packet are surely the least of our concerns! Not entirely insignificant, to be sure, but they are *not* the primary measure of cost. If there was a protocol which could do IKEv2's job and could be described clearly in two pages, at the cost of making the packets three times as big, people would be trying very hard to make it work. The primary cost measure for IKEv2 is protocol complexity, not packet size. Converting negotiations into announcements, as this proposal does, is definitely a simplification -- not a huge one, but noticeable. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 11 10:41:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBBIfBE18445; Wed, 11 Dec 2002 10:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14064 Wed, 11 Dec 2002 12:55:03 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15863.31792.10687.876714@pkoning.dev.equallogic.com> Date: Wed, 11 Dec 2002 12:56:00 -0500 From: Paul Koning To: ddp@electric-loft.org Cc: ipsec@lists.tislabs.com Subject: Re: speaking of keys References: <66066379-0C7A-11D7-98CD-000393CDFD1A@electric-loft.org> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derrell" == Derrell Piper writes: Derrell> What's the current state-of-the-art for COTS hardware Derrell> accelerators? It was the case a few years back that many Derrell> public-key chips didn't do 1024 bit DH groups. What's the Derrell> story today? Do we care? I don't remember ever seeing an accelerator with a limit less than 1024 bits in recent years (since IPsec). The only other case that comes to mind is Rivest's research prototype bignum ALU chip, 512 bits wide, early 1980s. paul From owner-ipsec@lists.tislabs.com Wed Dec 11 11:05:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBBJ53E18899; Wed, 11 Dec 2002 11:05:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14122 Wed, 11 Dec 2002 13:32:28 -0500 (EST) Date: Wed, 11 Dec 2002 10:31:25 -0800 (PST) From: Avram Shacham To: Henry Spencer cc: , IP Security List Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, With your observation that packet size is not the problem, what is the extra complexity to *announce* a 16-bit CPI and the (optional) algorithm-related parameters, that you define as > definitely a simplification -- not a huge one, but noticeable. Regards, avram On Wed, 11 Dec 2002, Avram Shacham wrote: > > > Date: Wed, 11 Dec 2002 09:17:34 -0500 (EST) > From: Henry Spencer > To: IP Security List > Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 > > On Tue, 10 Dec 2002, Avram Shacham wrote: > > IKE provides a way to establish IPComp sessions with the following: > > a. The actual usage of the protocol. > > b. Transform Identifier (aka compression algorithm... > > c. A 16-bit CPI. > > d. Algorithm-related attributes. > > What of the above IKEv1 capabilities, if any, Charlie's suggestion plans > > to omit? > > It makes (c) superfluous, and omits (d) except insofar as you might be able > to do a little of it by using different predefined identifiers. > > > If so, what are the savings -- i.e. in actual bytes in IKEv2 > > packet? In other words, what is the cost, if any, to keep the current > > functionality available in IKEv2? > > Bytes in the packet are surely the least of our concerns! Not entirely > insignificant, to be sure, but they are *not* the primary measure of cost. > If there was a protocol which could do IKEv2's job and could be described > clearly in two pages, at the cost of making the packets three times as > big, people would be trying very hard to make it work. The primary cost > measure for IKEv2 is protocol complexity, not packet size. Converting > negotiations into announcements, as this proposal does, is definitely a > simplification -- not a huge one, but noticeable. > > Henry Spencer > henry@spsystems.net > > > From owner-ipsec@lists.tislabs.com Wed Dec 11 12:32:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBBKWbE24086; Wed, 11 Dec 2002 12:32:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00218 Wed, 11 Dec 2002 14:58:50 -0500 (EST) Date: Wed, 11 Dec 2002 11:32:57 -0800 Subject: Re: speaking of keys Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipsec@lists.tislabs.com To: Paul Koning From: Derrell Piper In-Reply-To: <15863.31792.10687.876714@pkoning.dev.equallogic.com> Message-Id: <59C4D53E-0D3F-11D7-9651-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I mistyped that, I meant >1024 bits and I was specifically thinking about the Hi/fn 6500. I knew the Broadcom chips could do better, but I wasn't sure what the limits were... 2048 seems to be pretty common now. Derrell On Wednesday, December 11, 2002, at 09:56 AM, Paul Koning wrote: >>>>>> "Derrell" == Derrell Piper writes: > > Derrell> What's the current state-of-the-art for COTS hardware > Derrell> accelerators? It was the case a few years back that many > Derrell> public-key chips didn't do 1024 bit DH groups. What's the > Derrell> story today? Do we care? > > I don't remember ever seeing an accelerator with a limit less than > 1024 bits in recent years (since IPsec). The only other case that > comes to mind is Rivest's research prototype bignum ALU chip, 512 bits > wide, early 1980s. > > paul > From owner-ipsec@lists.tislabs.com Wed Dec 11 18:08:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBC288E14420; Wed, 11 Dec 2002 18:08:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00768 Wed, 11 Dec 2002 20:35:13 -0500 (EST) Date: Wed, 11 Dec 2002 20:36:43 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Dec 2002, Avram Shacham wrote: > With your observation that packet size is not the problem, what is the > extra complexity to *announce* a 16-bit CPI and the (optional) > algorithm-related parameters... However simple it may be to allocate, free, manage, and announce CPIs, it is simpler not to do so. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 11 22:20:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBC6KjE25856; Wed, 11 Dec 2002 22:20:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA01151 Thu, 12 Dec 2002 00:46:00 -0500 (EST) Message-Id: <3.0.5.32.20021211214604.0086ac80@pop.mindspring.com> X-Sender: tardo@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 11 Dec 2002 21:46:04 -0800 To: Derrell Piper , Paul Koning From: "Joseph J. Tardo" Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com In-Reply-To: <59C4D53E-0D3F-11D7-9651-000393CDFD1A@electric-loft.org> References: <15863.31792.10687.876714@pkoning.dev.equallogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Broadcom chips indeed do native 2048-bit modulo arithmetic. Note that speed and cost are coming down not only for hardware (from multiple vendors) but also for software (e.g., tailored assembly code for the P4 and Itanium processors said to be capable of 800 RSA Signatures/second using CRT). At 11:32 AM 12/11/02 -0800, Derrell Piper wrote: >I mistyped that, I meant >1024 bits and I was specifically thinking >about the Hi/fn 6500. I knew the Broadcom chips could do better, but I >wasn't sure what the limits were... 2048 seems to be pretty common now. > >Derrell > >On Wednesday, December 11, 2002, at 09:56 AM, Paul Koning wrote: > >>>>>>> "Derrell" == Derrell Piper writes: >> >> Derrell> What's the current state-of-the-art for COTS hardware >> Derrell> accelerators? It was the case a few years back that many >> Derrell> public-key chips didn't do 1024 bit DH groups. What's the >> Derrell> story today? Do we care? >> >> I don't remember ever seeing an accelerator with a limit less than >> 1024 bits in recent years (since IPsec). The only other case that >> comes to mind is Rivest's research prototype bignum ALU chip, 512 bits >> wide, early 1980s. >> >> paul >> > > From owner-ipsec@lists.tislabs.com Thu Dec 12 11:28:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBCJS8E07476; Thu, 12 Dec 2002 11:28:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02654 Thu, 12 Dec 2002 13:59:09 -0500 (EST) Date: Thu, 12 Dec 2002 10:58:21 -0800 (PST) From: Avram Shacham To: Henry Spencer cc: , IP Security List Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Even simpler is to keep existing IPComp implementations unchanged. Regards, avram On Thu, 12 Dec 2002, Avram Shacham wrote: > > Date: Wed, 11 Dec 2002 20:36:43 -0500 (EST) > From: Henry Spencer > To: IP Security List > Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 > > On Wed, 11 Dec 2002, Avram Shacham wrote: > > With your observation that packet size is not the problem, what is the > > extra complexity to *announce* a 16-bit CPI and the (optional) > > algorithm-related parameters... > > However simple it may be to allocate, free, manage, and announce CPIs, > it is simpler not to do so. > > Henry Spencer > henry@spsystems.net > > > > From owner-ipsec@lists.tislabs.com Thu Dec 12 16:02:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBD024E26267; Thu, 12 Dec 2002 16:02:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02947 Thu, 12 Dec 2002 18:18:58 -0500 (EST) Message-Id: <200212111549.gBBFnxFn017684@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: speaking of keys In-reply-to: Your message of "10 Dec 2002 20:13:15 GMT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Dec 2002 10:49:58 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Wagner writes: David> But is it too small for the MUST requirement in the RFC? David> As I see it, we have to balance two costs here. If we require a David> 1024-bit modulus, there is a risk it will get broken in our lifetime. David> If we require a 2048-bit modulus, some people will not use IPSEC because David> it is too slow (this is not just a risk; this is for sure). How do we David> balance these two? I don't understand this argument. MUST doesn't mean that you have to use it in an exchange, it means that you must support it. The purpose of the MUST is to encourage interopability. It doesn't have to the fastest, nor the cheapest. It has to be there for the long term. If you are building a system where you control all components you may configure it anyway that you like. So, if Verizon's new IP-mobile-phone needs to use 1024 bit moduli, and they won't let me use a third party handset, they can do what they like. Now, if asking for 1536 or 2048 bit moduli causes the software to always use more resources than you can afford (i.e. 256 byte buffers for bignums rather than 128 byte buffers), then this is a problem. Is that really a concern here? David> is that defaults matter, and it doesn't matter how good your crypto David> is if noone uses it (did you know that more than half of all 802.11 David> networks are still running unencrypted?). It seems unlikely to me Frankly, I'm impressed if there is more than 10% running 802.11 WEP-style encryption. I think it is a total joke. We use IPsec everywhere, with 1536 bit moduli. A Zaurus can do this. In fact, here is a picture of one doing that: http://bert.secret-wg.org/Trips/IETF55/personal-organizer1-small.jpg (from http://bert.secret-wg.org/Trips/IETF55/index.html ) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPfdepYqHRg3pndX9AQGergP9G6mUNxidVhNYIoXhaRV6Dqif02fpqwFo N+Xu+ihW5a8W5k+9HMvt3aidWqZwDjADGlkXjt4zAQzSfrZJ6Dr6gOlc+Eo7q0dv Jv+Wzwn8CpHt2EOso3FNEgGRRMj0W7SDI6Ixx/BGQ2WRC5GsppqnkACSbM2UZA+g NGF0IFTvnlQ= =pdX1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Dec 12 16:21:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBD0LYE27068; Thu, 12 Dec 2002 16:21:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03023 Thu, 12 Dec 2002 18:58:02 -0500 (EST) Message-ID: <045701c2a23a$7ccd7e00$b110a8c0@Tarun> From: "Tarun Ahuja" To: References: <15863.31792.10687.876714@pkoning.dev.equallogic.com> <3.0.5.32.20021211214604.0086ac80@pop.mindspring.com> Subject: Re: speaking of keys Date: Thu, 12 Dec 2002 15:59:18 -0800 Organization: Cavium Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 12 Dec 2002 23:59:21.0955 (UTC) FILETIME=[7DA4CB30:01C2A23A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The new generation of crypto accelerators can do 40000+ RSA(yes forty thousand and that's not a typo) operations/second using CRT. You can get the details of the products by clicking on the following link. http://www.cavium.com/Table.html -Tarun ----- Original Message ----- From: "Joseph J. Tardo" To: "Derrell Piper" ; "Paul Koning" Cc: Sent: Wednesday, December 11, 2002 9:46 PM Subject: Re: speaking of keys > The Broadcom chips indeed do native 2048-bit modulo arithmetic. > > Note that speed and cost are coming down not only for hardware (from > multiple vendors) but also for software (e.g., tailored assembly code for > the P4 and Itanium processors said to be capable of 800 RSA > Signatures/second using CRT). > > At 11:32 AM 12/11/02 -0800, Derrell Piper wrote: > >I mistyped that, I meant >1024 bits and I was specifically thinking > >about the Hi/fn 6500. I knew the Broadcom chips could do better, but I > >wasn't sure what the limits were... 2048 seems to be pretty common now. > > > >Derrell > > > >On Wednesday, December 11, 2002, at 09:56 AM, Paul Koning wrote: > > > >>>>>>> "Derrell" == Derrell Piper writes: > >> > >> Derrell> What's the current state-of-the-art for COTS hardware > >> Derrell> accelerators? It was the case a few years back that many > >> Derrell> public-key chips didn't do 1024 bit DH groups. What's the > >> Derrell> story today? Do we care? > >> > >> I don't remember ever seeing an accelerator with a limit less than > >> 1024 bits in recent years (since IPsec). The only other case that > >> comes to mind is Rivest's research prototype bignum ALU chip, 512 bits > >> wide, early 1980s. > >> > >> paul > >> > > > > From owner-ipsec@lists.tislabs.com Thu Dec 12 17:07:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBD17SE00852; Thu, 12 Dec 2002 17:07:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03134 Thu, 12 Dec 2002 19:44:26 -0500 (EST) Message-ID: <51C7002B020CD411824E009027C469F7DD341B@cldxch01.hifn.com> From: Bob Doud To: "'Derrell Piper'" , Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: speaking of keys Date: Thu, 12 Dec 2002 16:45:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Hifn 6500 supports 2048-bit modulus sizes. In fact, all of the chips we've produced in the last couple of years support 2048, and more recently the HIPP II family goes to 3072-bit modulus sizes. Our newest chips will be going up to 4096-bit support. But keep in mind, it usually takes 4x longer to compute a D-H when you double the modulus. Bob >>>>>> "Derrell" == Derrell Piper writes: > > I mistyped that, I meant >1024 bits and I was specifically thinking > about the Hi/fn 6500. I knew the Broadcom chips could do > better, but I > wasn't sure what the limits were... 2048 seems to be pretty > common now. > > Derrell > > On Wednesday, December 11, 2002, at 09:56 AM, Paul Koning wrote: > > >>>>>> "Derrell" == Derrell Piper writes: > > > > Derrell> What's the current state-of-the-art for COTS hardware > > Derrell> accelerators? It was the case a few years back that many > > Derrell> public-key chips didn't do 1024 bit DH groups. What's the > > Derrell> story today? Do we care? > > > > I don't remember ever seeing an accelerator with a limit less than > > 1024 bits in recent years (since IPsec). The only other case that > > comes to mind is Rivest's research prototype bignum ALU > chip, 512 bits > > wide, early 1980s. > > > > paul > > > From owner-ipsec@lists.tislabs.com Thu Dec 12 17:54:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBD1sWE02149; Thu, 12 Dec 2002 17:54:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03374 Thu, 12 Dec 2002 20:32:51 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <51C7002B020CD411824E009027C469F7DD341B@cldxch01.hifn.com> References: <51C7002B020CD411824E009027C469F7DD341B@cldxch01.hifn.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: Thu, 12 Dec 2002 17:34:31 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: speaking of keys Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Whatever we put for MUST will be the default for the UIs. Over half of the VPN boxes in our interop lab, all of which shipped this year, default to DES and MD5, not because any of the manufacturers think those are good ideas, but because those are the MUSTs in IKEv1. If we pick too big of a single MUST, we will make IKEv2 look slow. It sounds like most people who want a large value for MUST mean that they want to guarantee that large values can be used interoperably by people who can afford the CPU and/or accelerator time. To do that, we could say "MUST support key sizes of 1024, 1536, and 2048." That gets us the guarantee of interop, and forces the manufacturers to actually think about what they want their default values to be. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Dec 12 18:46:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBD2kQE05630; Thu, 12 Dec 2002 18:46:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03464 Thu, 12 Dec 2002 21:24:04 -0500 (EST) Message-ID: <51C7002B020CD411824E009027C469F7DD3422@cldxch01.hifn.com> From: Bob Doud To: "'Paul Hoffman / VPNC'" Cc: ipsec@lists.tislabs.com Subject: RE: speaking of keys Date: Thu, 12 Dec 2002 18:25:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excellent suggestion. I agree. Bob Paul Hoffman / VPNC writes: > > Whatever we put for MUST will be the default for the UIs. Over half > of the VPN boxes in our interop lab, all of which shipped this year, > default to DES and MD5, not because any of the manufacturers think > those are good ideas, but because those are the MUSTs in IKEv1. > > If we pick too big of a single MUST, we will make IKEv2 look slow. > > It sounds like most people who want a large value for MUST mean that > they want to guarantee that large values can be used interoperably by > people who can afford the CPU and/or accelerator time. To do that, we > could say "MUST support key sizes of 1024, 1536, and 2048." That gets > us the guarantee of interop, and forces the manufacturers to actually > think about what they want their default values to be. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Fri Dec 13 09:59:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBDHx1E25977; Fri, 13 Dec 2002 09:59:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05256 Fri, 13 Dec 2002 12:31:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15866.6586.939105.224341@pkoning.dev.equallogic.com> Date: Fri, 13 Dec 2002 12:32:42 -0500 From: Paul Koning To: shacham@shacham.net Cc: henry@spsystems.net, ippcp@external.cisco.com, ipsec@lists.tislabs.com Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Avram" == Avram Shacham writes: Avram> Even simpler is to keep existing IPComp implementations Avram> unchanged. Not true. That's valid if you leave IKE V1 in place. IKEv2 is different code (much simpler). Trying to extract the gnarly IPcomp code within IKEv1 from the larger and even gnarlier IKEv1 body is a lot more work than implementing the trivial mechanisms that Charlie & al. have proposed. paul From owner-ipsec@lists.tislabs.com Fri Dec 13 10:48:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBDImhE01531; Fri, 13 Dec 2002 10:48:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05371 Fri, 13 Dec 2002 13:27:59 -0500 (EST) Date: Fri, 13 Dec 2002 10:26:53 -0800 (PST) From: Avram Shacham To: Paul Koning cc: , , Subject: Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2 In-Reply-To: <15866.6586.939105.224341@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Trying to be crystal clear: I raised no arguments on the negotiation mechanism (aka IKEv2), as long as it provides the (also simple) functionality, i.e. the collection of parameters, that's required to keep working-code IPComp implementations running. The differences described in this thread are (a) the content of the 16-bit CPI, and (b) the optional algorithm parameters. Adding the capability to have the above in IKEv2 should be pretty simple. Regards, avram On Fri, 13 Dec 2002, Paul Koning wrote: > >>>>> "Avram" == Avram Shacham writes: > > Avram> Even simpler is to keep existing IPComp implementations > Avram> unchanged. > > Not true. > > That's valid if you leave IKE V1 in place. IKEv2 is different code > (much simpler). Trying to extract the gnarly IPcomp code within IKEv1 > from the larger and even gnarlier IKEv1 body is a lot more work than > implementing the trivial mechanisms that Charlie & al. have proposed. > > paul > > From owner-ipsec@lists.tislabs.com Fri Dec 13 11:06:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBDJ6lE02666; Fri, 13 Dec 2002 11:06:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05423 Fri, 13 Dec 2002 13:44:22 -0500 (EST) Date: Fri, 13 Dec 2002 10:45:23 -0800 Subject: Re: speaking of keys Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com To: Bob Doud From: Derrell Piper In-Reply-To: <51C7002B020CD411824E009027C469F7DD3422@cldxch01.hifn.com> Message-Id: <09722C7D-0ECB-11D7-BC1A-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday, December 12, 2002, at 06:25 PM, Bob Doud wrote: > Excellent suggestion. I agree. > > Bob So do I. Require support for 1024, 1536, and 2048. And forbid anything less than 1024. This gives us maximal interoperability and good security when you want to pay the price. Derrell > Paul Hoffman / VPNC writes: >> >> Whatever we put for MUST will be the default for the UIs. Over half >> of the VPN boxes in our interop lab, all of which shipped this year, >> default to DES and MD5, not because any of the manufacturers think >> those are good ideas, but because those are the MUSTs in IKEv1. >> >> If we pick too big of a single MUST, we will make IKEv2 look slow. >> >> It sounds like most people who want a large value for MUST mean that >> they want to guarantee that large values can be used interoperably by >> people who can afford the CPU and/or accelerator time. To do that, we >> could say "MUST support key sizes of 1024, 1536, and 2048." That gets >> us the guarantee of interop, and forces the manufacturers to actually >> think about what they want their default values to be. >> >> --Paul Hoffman, Director >> --VPN Consortium >> From owner-ipsec@lists.tislabs.com Fri Dec 13 11:36:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBDJaTE05078; Fri, 13 Dec 2002 11:36:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05465 Fri, 13 Dec 2002 14:08:29 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <09722C7D-0ECB-11D7-BC1A-000393CDFD1A@electric-loft.org> References: <09722C7D-0ECB-11D7-BC1A-000393CDFD1A@electric-loft.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 13 Dec 2002 11:09:50 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: speaking of keys Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:45 AM -0800 12/13/02, Derrell Piper wrote: >So do I. Require support for 1024, 1536, and 2048. And forbid >anything less than 1024. This gives us maximal interoperability and >good security when you want to pay the price. This would also show that we aren't very good at math. If we allow encryption mechanisms with keys of less than about 80 bits, we have to allow public keys that match those smaller sizes. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Dec 13 11:46:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBDJk5E06069; Fri, 13 Dec 2002 11:46:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05500 Fri, 13 Dec 2002 14:26:38 -0500 (EST) Date: Fri, 13 Dec 2002 11:28:24 -0800 Subject: Re: speaking of keys Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipsec@lists.tislabs.com To: Paul Hoffman / VPNC From: Derrell Piper In-Reply-To: Message-Id: <0BEB44EC-0ED1-11D7-BC1A-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I disagree. 768 is barely sufficient for single DES. It's clearly insufficient for most everything people ought to be using (and whatever's likely to be the default MUST). Derrell On Friday, December 13, 2002, at 11:09 AM, Paul Hoffman / VPNC wrote: > At 10:45 AM -0800 12/13/02, Derrell Piper wrote: >> So do I. Require support for 1024, 1536, and 2048. And forbid >> anything less than 1024. This gives us maximal interoperability and >> good security when you want to pay the price. > > This would also show that we aren't very good at math. If we allow > encryption mechanisms with keys of less than about 80 bits, we have to > allow public keys that match those smaller sizes. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Dec 13 13:53:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBDLrpE13521; Fri, 13 Dec 2002 13:53:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05890 Fri, 13 Dec 2002 16:26:02 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15866.20643.7955.413298@pkoning.dev.equallogic.com> Date: Fri, 13 Dec 2002 16:26:59 -0500 From: Paul Koning To: paul.hoffman@vpnc.org CC: ipsec@lists.tislabs.com Subject: Re: speaking of keys References: <09722C7D-0ECB-11D7-BC1A-000393CDFD1A@electric-loft.org> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> At 10:45 AM -0800 12/13/02, Derrell Piper wrote: >> So do I. Require support for 1024, 1536, and 2048. And forbid >> anything less than 1024. This gives us maximal interoperability >> and good security when you want to pay the price. Paul> This would also show that we aren't very good at math. If we Paul> allow encryption mechanisms with keys of less than about 80 Paul> bits, ... Do we? We shouldn't... DES should be, at best, on the "deprecated" list, and preferably on the "historic" list. paul From owner-ipsec@lists.tislabs.com Fri Dec 13 16:31:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBE0VsE28322; Fri, 13 Dec 2002 16:31:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05991 Fri, 13 Dec 2002 19:02:35 -0500 (EST) Date: Fri, 13 Dec 2002 19:03:36 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: speaking of keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 13 Dec 2002, Paul Hoffman / VPNC wrote: > This would also show that we aren't very good at math. If we allow > encryption mechanisms with keys of less than about 80 bits, we have > to allow public keys that match those smaller sizes. (a) We shouldn't allow encryption mechanisms with such grossly inadequate key lengths. (b) There is nothing wrong with getting more bits than you need, except possibly some extra cycles used to generate them. There are people who are probably too cycle-poor to use 1024-bit public keys, but I see no indication that there are enough of them to be worth compromising our standard for. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 13 16:45:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBE0jRE28570; Fri, 13 Dec 2002 16:45:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06027 Fri, 13 Dec 2002 19:26:39 -0500 (EST) Date: Fri, 13 Dec 2002 19:28:01 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: speaking of keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Dec 2002, Paul Hoffman / VPNC wrote: > ...could say "MUST support key sizes of 1024, 1536, and 2048." That gets > us the guarantee of interop, and forces the manufacturers to actually > think about what they want their default values to be. I'd be happier if there were some way to work in an explicit preference for the longer lengths, but setting that aside, this approach seems acceptable. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 16 12:17:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBGKHto17434; Mon, 16 Dec 2002 12:17:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12364 Mon, 16 Dec 2002 14:31:26 -0500 (EST) Message-Id: <5.2.0.9.2.20021216142916.02f434c0@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Dec 2002 14:31:57 -0500 To: tarun.ahuja@cavium.com From: Russ Housley Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com In-Reply-To: <045701c2a23a$7ccd7e00$b110a8c0@Tarun> References: <15863.31792.10687.876714@pkoning.dev.equallogic.com> <3.0.5.32.20021211214604.0086ac80@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tarun: According to the table on the referenced web page, the RSA and Diffie-Hellman operations use 1024-bit keys. What happens when the keys are bigger? If software must be used when the keys are bigger, then the performance reduction will be significant! Russ >The new generation of crypto accelerators can do 40000+ RSA(yes forty >thousand and that's not a typo) operations/second using CRT. >You can get the details of the products by clicking on the following link. >http://www.cavium.com/Table.html > >-Tarun > >----- Original Message ----- >From: "Joseph J. Tardo" >To: "Derrell Piper" ; "Paul Koning" > >Cc: >Sent: Wednesday, December 11, 2002 9:46 PM >Subject: Re: speaking of keys > > > > The Broadcom chips indeed do native 2048-bit modulo arithmetic. > > > > Note that speed and cost are coming down not only for hardware (from > > multiple vendors) but also for software (e.g., tailored assembly code for > > the P4 and Itanium processors said to be capable of 800 RSA > > Signatures/second using CRT). > > > > At 11:32 AM 12/11/02 -0800, Derrell Piper wrote: > > >I mistyped that, I meant >1024 bits and I was specifically thinking > > >about the Hi/fn 6500. I knew the Broadcom chips could do better, but I > > >wasn't sure what the limits were... 2048 seems to be pretty common now. > > > > > >Derrell > > > > > >On Wednesday, December 11, 2002, at 09:56 AM, Paul Koning wrote: > > > > > >>>>>>> "Derrell" == Derrell Piper writes: > > >> > > >> Derrell> What's the current state-of-the-art for COTS hardware > > >> Derrell> accelerators? It was the case a few years back that many > > >> Derrell> public-key chips didn't do 1024 bit DH groups. What's the > > >> Derrell> story today? Do we care? > > >> > > >> I don't remember ever seeing an accelerator with a limit less than > > >> 1024 bits in recent years (since IPsec). The only other case that > > >> comes to mind is Rivest's research prototype bignum ALU chip, 512 bits > > >> wide, early 1980s. > > >> > > >> paul > > >> > > > > > > From owner-ipsec@lists.tislabs.com Mon Dec 16 12:32:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBGKWEo17857; Mon, 16 Dec 2002 12:32:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12464 Mon, 16 Dec 2002 15:07:07 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C666@corpmx14.us.dg.com> To: larse@ISI.EDU Cc: ipsec@lists.tislabs.com Subject: RE: IKEv2 transport concerns Date: Mon, 16 Dec 2002 15:07:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Would you be amenable to an approach based on a small draft that > > contains just the tunnel encapsulation/decapsulation material needed > > to specify ECN handling for tunnel-mode SAs? > > ... > > RFC2003 is currently under revision in the Mobile-IP WG. It may be > simpler to consolidate IPsec-related tunneling specifics in 2003bis, > since Mobile-IP owns IP protocol 4 and will have to be > involved in any changes anyhow. Lars, That's fine, except that the IPsec-related tunneling specifics are currently in 2401, and hence 2401bis would have to reference 2003bis for the reasons found earlier in this thread. I'm inclined to write the small draft, and let 2003bis and 2401bis compete to see who gets to obsolete it first and how :-). --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Dec 17 14:59:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBHMxVo24397; Tue, 17 Dec 2002 14:59:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15150 Tue, 17 Dec 2002 17:09:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: Date: Mon, 16 Dec 2002 11:56:06 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Fwd: Processing of ESP packet Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >X-Originating-IP: [67.118.241.65] >From: "bepsy paul" >Subject: Processing of ESP packet >Date: Fri, 13 Dec 2002 11:29:16 -0800 >X-OriginalArrivalTime: 13 Dec 2002 19:29:16.0652 (UTC) >FILETIME=[ECF18AC0:01C2A2DD] >X-Spam-Status: NO >X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang) >Status: > > > > I am Bepsy and doing IPsec development in a small company. I got >your mail id from ipsec@lists.tislabs.com mailing list. I am not >able to join this group. That's why I am writing to you. > > I have a simple doubt in the inbound ESP/AH packet processing. I >have negotiated the IKE SA and IPSec SA. My IPSec SA looks like >this. > >SPI=0xd930f1db 0.0.0.0/32>10.1.0.171/32 ESP >AUTHKEY=0x9a4bdd1830b7bb24783353cdacd4f45c872e496,160bits >AUTH HMAC-SHA1 REPLAY 32 >ENCRYPTKEY=0xf09aa0fe1aa253d7e630e8bacf19e096cbc0452a1e5f3c6,192bits >ENCRYPT 3DES-CBC >IV=0xa98dcb69b26cb19,64 >LIFE_ADD_TIME_HARD 120 > > When I get the inbound ESP packet, first I have to do the digest >verification,right? For that, do I have to use the AUTHKEY in the >SA? I am using openssl-crypto for my cryptographic operations. Do >you know how I can pass this AUTHKEY to EVP_DigestUpdate() function? >If yes, please reply to me. Do you have a sample inbound packet >processing code? If yes, would you mind sending to me? > > If you could, please forward this question to the mailing list so >that I may get suggestions from others also. > >Thanking you in advance, > >Best Regards, >Bepsy > > > > > >_________________________________________________________________ >Help STOP SPAM with the new MSN 8 and get 2 months FREE* >http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Tue Dec 17 17:44:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBI1i1o03103; Tue, 17 Dec 2002 17:44:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15520 Tue, 17 Dec 2002 20:16:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message Subject: IKEv2: SA attribute processing rules Date: Tue, 17 Dec 2002 17:17:05 -0800 Message-ID: Thread-Topic: IKEv2: SA attribute processing rules Thread-Index: AcKmM0JUOLonOw7JQi+liiQJua0hEQ== From: "William Dixon" To: X-OriginalArrivalTime: 18 Dec 2002 01:16:51.0895 (UTC) FILETIME=[254A1470:01C2A633] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was researching the exact way to handle additional MODP groups in IKEv1 and realized that IKEv1 was unclear on how to handle additional transform attribute types in the SA payload that you didn't recognize, including the private use range values. IKEv2 does not yet clarify this in section 5.3. And then I found a number of other issues with IKEv2's current treatment of SA attribute processing. Maybe some of these have been discussed on the list already. If so, I've missed that discussion. I just didn't want to lose these thoughts while they were present. The following topics are addressed in this mail for IKEv2: A.) How to handle unrecognized attribute types B.) Gap in private use range C.) Regarding how we indicate "mutually consenting parties" - vendor ID can't be used. D.) No real clarification on SA attribute handling E.) Implied requirement for 1536, should be 2048 or 3072. F.) Be clear what fails the negotiation and what doesn't. My impression is that the current IKEv2 draft is missing it's goal of making IKE easier to analyze and implement by not clearly describing how to negotiate (what it means to include, omit, and accept) each SA attribute and the selection/ordering of these attributes in terms of having a predictable outcome when processing two lists of preferences. To implement IKEv2 SA attribute processing correctly, you must now analyze text in 4 documents: IKEv2, IKEv1, ISAKMP, and the DOI, and still guess whether the peer is going to fail the negotiation, and guess at what the outcome will be. -------------------- A.) How to handle unrecognized attribute types, I suggest text: "An unrecognized transform attribute type MUST be ignored. If no SA attributes are recognized, then the negotiation MUST fail." B.) Gap in private use range. Some questions come up from this text: "values 2-65000 are reserved to IANA. Values 65501-65533 are for private use among mutually consenting parties." - did the authors purposely skip the range 65001 through 65500 ? If so, I assume this was done to allow implementers of IKEv1 to continue to use their private identifiers that may have been chosen in the omitted range. But it leaves implementers in a weird spot if they do what to use 65001, which is neither allocated for private use nor assigned to IANA. C.) Regarding how we indicate "mutually consenting parties". Common practice is to use the vendor-ID, and so we should be clear and say that this is the method used when administrative configuration permits the advertisement of such consent. Section 5.12 Vendor ID discussion talks about this, but note that it prohibits making assumptions on what the peer may accept, and mandates that the initiator always know what the peer is willing to accept before sending it private use ranges. However, this prohibits the use of private use ranges in the SA attributes...: IKEv2 draft-03 current text: "The Vendor ID payload is not an announcement from the sender that it will send private payload types but rather an announcement of the sort of private payloads it is willing to accept. The implementation sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID of like stature is received as well. " D.) No real clarification on SA attribute handling. I'm surprised that we are not taking the opportunity in IKEv2 to clean up the confusion about the IKEv1 SA attributes having different definitions for Phase I and Phase 2. Phase 1 is defined in the IKEv1 appendix A. Phase 2 is defined in the DOI with different SA attribute type numbers. For example, the DH Group Description is defined to be 4 in Phase I, but 3 in Phase 2 in the DOI (unless you realize that you're using quick mode PFS and the group is really the same as in Phase 1...) I don't see a reason why the IKEv2 can't fix this to have one list of attribute types. I haven't studied this enough to see if IKEv2 solved the problem of being able to negotiate PFS, but it should. My impression is that the current IKEv2 draft is missing it's goal of making IKE easier to analyze and implement by not clearly describing how to negotiate (what it means to include, omit, and accept) each SA attribute and the ordering of these attributes in terms of having a predictable outcome when processing two lists of preferences. To implement IKEv2 SA attribute processing correctly, you must now analyze text in 4 documents: IKEv2, IKEv1, ISAKMP, and the DOI, and still guess whether the peer is going to fail the negotiation, and guess at what the outcome will be. E.) Implied requirement for 1536, should be 2048 or 3072. The example suite given suggests that DH1536 would be a "default". It doesn't say whether it's a MUST support. I think we need something greater than DH1024, but why does IKEv2 need to specify it ? Given the strength calculation in Tero's MODP draft, DH1536 supports by one calculation only 90bits entropy, which is still much less than 3DES ~112bits entropy (from Schneier's Applied Cryptography) which is included in that suite, and insuffient for keying 128bit AES. So DH2048 or DH3072 should be the choice to ensure IKE DH is not the weakest point, and thus force the attack to the 3DES keys, which of course is being rekeyed far more often than the DH is generated in most cases. F.) Be clear what fails the negotiation and what doesn't. When that same section talks about Reserved-MBZ: "a proposal containing a non-zero value MUST NOT be accepted.", it's not clear whether this means fail the negotiation if it isn't, or ignore the value. >From earlier research, and practical experience, we need to be clear about what specific conditions fail the negotiation, and absent those specific conditions, any other violation of MUST does not fail the negotiation. Yes, the implementer's rule of "be liberal in what we accept" is true, but at the cost of accepting an RFC MUST violation ? Thx, Wm From owner-ipsec@lists.tislabs.com Wed Dec 18 00:17:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBI8Hjo11513; Wed, 18 Dec 2002 00:17:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16123 Wed, 18 Dec 2002 02:48:29 -0500 (EST) From: "Sergey Zakharov" To: Subject: Associating newly created SA bundles with Policies Date: Wed, 18 Dec 2002 10:49:32 +0300 Message-ID: <001101c2a66a$00670190$04016d6a@sergeyxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: sergeyxp X-SMTP-MAIL-FROM: Sergey.Zakharov@samsung.ru X-SMTP-RCPT-TO: ipsec@lists.tislabs.com,ipsec@lists.tislabs.com X-SMTP-PEER-INFO: 106-109-1-4.samsung.ru [106.109.1.4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello. The SA bundle was created as a result of IKE negotiations. The host acts in these negotiations as a responder. Should it associate this bundle with some policy? If the answer to this question - yes: - If several Policies match this bundle (we can use only IP address as a selector), it should be associated with all of them? This can cause some problems (on this host this bundle is associated with multiple policies, but on the remote host only with single) If the answer - no: - The outbound SA will be never used? Thanks, Sergey Zakharov From owner-ipsec@lists.tislabs.com Wed Dec 18 15:29:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBINT9o24791; Wed, 18 Dec 2002 15:29:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17864 Wed, 18 Dec 2002 17:38:17 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15872.63797.778691.404075@ryijy.hel.fi.ssh.com> Date: Thu, 19 Dec 2002 00:39:49 +0200 From: Tero Kivinen To: "William Dixon" Cc: , Subject: Status on draft-ietf-ipsec-ike-modp-groups-04.txt ? In-Reply-To: References: X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William Dixon writes: > What is the detailed status here ? I know it's passed WG last call. I > thought it was past IETF last call. But I don't see it in the RFC > editor queue... It is waiting for me to get the final version out (to put in the comments from the IESG i.e split the references to normative and non-normative, allocate numbers etc) and then it is ready to get forward. I should get it out in few days (I have been on vacation for last few weeks and I am now getting back up to date in my email backlog). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Dec 18 23:09:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJ79bo21956; Wed, 18 Dec 2002 23:09:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA18666 Thu, 19 Dec 2002 01:38:25 -0500 (EST) From: "Sergey Zakharov" To: "'jeff pickering'" Cc: Subject: RE: Associating newly created SA bundles with Policies Date: Thu, 19 Dec 2002 09:39:09 +0300 Message-ID: <000901c2a729$59e6c970$04016d6a@sergeyxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E00B3CB.80A45923@caspiannetworks.com> X-SMTP-HELO: sergeyxp X-SMTP-MAIL-FROM: Sergey.Zakharov@samsung.ru X-SMTP-RCPT-TO: ipsec@lists.tislabs.com,jeffp@caspiannetworks.com,ipsec@lists.tislabs.com,jeffp@caspiannetworks.com X-SMTP-PEER-INFO: 106-109-1-4.samsung.ru [106.109.1.4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jeff, I agree with you, it is necessary to select certain policy in order to respond to negotiations. But, the only selector we can use in this stage is IP address of the remote host, isn't it? When I respond to negotiations I can't determine whether this SA will be used for TCP traffic or maybe for UDP... Thus, I can't understand how to implement the following scenario: Between two hosts, I want: 1. All ICMP traffic to be protected with ESP only 2. All TCP traffic to be protected with AH only 3. All UDP traffic to e protected with ESP and AH In this case all selectors described in 4.4.2 [RFC2401], are unusable and the single selector becomes only IP address. Sergey > -----Original Message----- > From: jeff pickering [mailto:jeffp@caspiannetworks.com] > Sent: Wednesday, December 18, 2002 8:44 PM > To: Sergey Zakharov > Subject: Re: Associating newly created SA bundles with Policies > > > Sergey, > I would assume that the responder would need to know the appropriate > policy in order to create the SA(bundle) in the first place, ie its the > policy that > determines acceptable proposals, etc. > Jeff > > > Sergey Zakharov wrote: > > > Hello. > > > > The SA bundle was created as a result of IKE negotiations. The host acts > > in these negotiations as a responder. Should it associate this bundle > > with some policy? > > > > If the answer to this question - yes: > > - If several Policies match this bundle (we can use only IP address as a > > selector), it should be associated with all of them? This can cause some > > problems (on this host this bundle is associated with multiple policies, > > but on the remote host only with single) > > > > If the answer - no: > > - The outbound SA will be never used? > > > > Thanks, > > Sergey Zakharov From owner-ipsec@lists.tislabs.com Thu Dec 19 00:42:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJ8gLo05429; Thu, 19 Dec 2002 00:42:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18834 Thu, 19 Dec 2002 03:09:43 -0500 (EST) From: "Sergey Zakharov" To: "'jeff pickering'" Cc: Subject: RE: Associating newly created SA bundles with Policies Date: Thu, 19 Dec 2002 11:10:27 +0300 Message-ID: <001901c2a736$19cf6510$04016d6a@sergeyxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E00B3CB.80A45923@caspiannetworks.com> X-SMTP-HELO: sergeyxp X-SMTP-MAIL-FROM: Sergey.Zakharov@samsung.ru X-SMTP-RCPT-TO: ipsec@lists.tislabs.com,jeffp@caspiannetworks.com,ipsec@lists.tislabs.com,jeffp@caspiannetworks.com X-SMTP-PEER-INFO: 106-109-1-4.samsung.ru [106.109.1.4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks a lot, I've got it! All selectors are in Identification payload in the first Quick mode message. Now, with these selectors I can select the particular policy and link new SA to this policy. Sergey Zakharov > -----Original Message----- > From: jeff pickering [mailto:jeffp@caspiannetworks.com] > Sent: Wednesday, December 18, 2002 8:44 PM > To: Sergey Zakharov > Subject: Re: Associating newly created SA bundles with Policies > > > Sergey, > I would assume that the responder would need to know the appropriate > policy in order to create the SA(bundle) in the first place, ie its the > policy that > determines acceptable proposals, etc. > Jeff > > > Sergey Zakharov wrote: > > > Hello. > > > > The SA bundle was created as a result of IKE negotiations. The host acts > > in these negotiations as a responder. Should it associate this bundle > > with some policy? > > > > If the answer to this question - yes: > > - If several Policies match this bundle (we can use only IP address as a > > selector), it should be associated with all of them? This can cause some > > problems (on this host this bundle is associated with multiple policies, > > but on the remote host only with single) > > > > If the answer - no: > > - The outbound SA will be never used? > > > > Thanks, > > Sergey Zakharov From owner-ipsec@lists.tislabs.com Thu Dec 19 07:43:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJFhho16065; Thu, 19 Dec 2002 07:43:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19806 Thu, 19 Dec 2002 10:11:07 -0500 (EST) Reply-To: From: "Darren Dukes" To: Cc: Subject: Proposed Configuration payload for IKEv2 Date: Wed, 18 Dec 2002 15:10:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A4_01C2A6A7.96A489B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A4_01C2A6A7.96A489B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is a draft which is intended to be merged with the IKEv2 draft. There is no intent for this draft to continue on its own. It contains a payload and description of how an IPsec Remote Access Client (IRAC) may use that payload to get configuration information (internal IP, subnets, etc.) from an IPsec Remote Access Server (IRAS). The payload in this draft is very similar to the IKEv1 modecfg draft, this draft states the differences between the two. Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in November, 2002, the IPsec WG decided to add remote access capabilities (legacy authentication and remote client configuration) to IKEv2. At an informal design team meeting after the WG meeting, the VPN vendors attending decided that the best options to propose to the WG were to add capabilities similar to XAUTH and MODE-CFG." Please send all comments regarding this draft to ipsec@lists.tislabs.com Thanks, Darren ------=_NextPart_000_00A4_01C2A6A7.96A489B0 Content-Type: text/plain; name="draft-dukes-ikev2-config-payload-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-dukes-ikev2-config-payload-00.txt" INTERNET-DRAFT Darren Dukes=20 Expires July 2003 =20 Document: Cisco Systems=20 December 2002=20 =20 =20 Configuration payload=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This document proposes changes to IKEv2 [IKEv2] to allow=20 configuration data to be securely distributed to IPsec Remote Access=20 Clients (IRACs) by IPsec Remote Access Servers (IRASs). It is=20 assumed this draft will be merged with the IKEv2 draft [IKEv2] and=20 refers to sections in that draft, preceded by "****=94. This draft,=20 on its own, is not intended to progress to any RFC status.=20 =20 Comments regarding this draft should be sent to ddukes@cisco.com or=20 ipsec@lists.tislabs.com=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [2].=20 =20 =20 =20 Dukes 1 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 Table of Contents=20 1. Introduction...................................................3=20 1.1. Changes from draft-dukes-ike-mode-cfg-02.txt.................3=20 1.2. Reader Prerequisites.........................................3=20 2. IKE_SA_AUTH Exchange changes...................................3=20 2. Informational (Phase 2) Exchanges..............................4=20 3. Configuration Payload..........................................4=20 3.1. Configuration Attributes.....................................6=20 4. Notify Message Types...........................................8=20 5. Implementation Notes...........................................8=20 5.1. Requesting an Internal Address...............................8=20 5.2. Requesting the Peer's Version................................9=20 6. Enterprise Management Considerations..........................10=20 7. Security Considerations.......................................10=20 8. References....................................................10=20 9. Acknowledgments...............................................11=20 10. Author's Addresses...........................................11=20 Full Copyright Statement.........................................12=20 =20 =20 Dukes 2 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 1. Introduction=20 =20 In remote access scenarios it is desirable and often necessary for=20 an IRAS to provide configuration data, such as an internal IP=20 address, to an IRAC before Child-SAs are created. This document=20 describes requirements on TSi and TSr, and an additional=20 Configuration Payload in message 3 and 4 (IKE_SA_AUTH) of IKE-SA=20 creation in order to provide configuration data necessary for the=20 creation of Child-SAs. The Configuration Payload MAY also be used=20 within an Informational Exchange protected by an IKE-SA to request=20 or set configuration data from or to an IKE peer.=20 =20 1.1. Changes from draft-dukes-ike-mode-cfg-02.txt=20 =20 This document is similar to draft-dukes-ike-mode-cfg-02.txt for=20 IKEv1 [IKE], but is not intended to interoperate directly with=20 implementations of that draft.=20 =20 Some differences for IKEv2=20 1 - No transaction exchange, use the Informational exchange and the=20 IKE_SA_AUTH exchange.=20 2 - The payload was called Attribute payload in the IKEv1 modecfg,=20 it is called Configuration payload in IKEv2. =20 3 - No Identifier in the Configuration Payload since this was a=20 major point of confusion in the IKEv1 modecfg draft, with no known=20 use other than XAUTH.=20 4 - Configuration payloads are always secured via the IKE-SA.=20 =20 =20 1.2. Reader Prerequisites=20 =20 It is assumed that the reader is familiar with Proposal for the=20 Internet Key Exchange (IKEv2) Protocol [IKEv2]=20 =20 2. IKE_SA_AUTH Exchange changes=20 =20 **** [Below are changes to section 3.1 of [IKEv2], Message 3 and 4 are=20 modified to include the Configuration Payload and additional=20 description of CP and TS requirements are added]=20 =20 HDR, SAi1, KEi, Ni, Nr,=20 SK {IDi, [CERT,] [CERTREQ,] [IDr,]=20 AUTH, [CP], SAi2, TSi, TSr} -->=20 =20 The optional CP (Configuration Payload) MAY be sent by the initiator=20 to request configuration data. If CP is used to request an internal=20 IP address (as is often the case when the initiator is an IRAC) the=20 initiator may not know what to place in the TSi payload, in this=20 case she MUST include at least one Traffic Selector in TSi with a=20 suitable range of ports, and addresses. As an example, if the=20 initiator did not have a selector trigger SA creation (as may be the=20 case when an IRAC starts up) she may include the selector (0.0.0.0- =20 Dukes 3 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 255.255.255.255) all ports and protocols. At least one suitable=20 selector MUST be included in TSr. Continuing with this example, the=20 initiator may not have any knowledge of the addresses secured by the=20 responder so she MAY include the selector (0.0.0.0-255.255.255.255)=20 all ports and protocols, requiring the responder to choose a=20 narrower selector if necessary.=20 =20 <-- HDR, SK {IDr, [CERT,] AUTH,=20 [CP], SAr2, TSi, TSr}=20 =20 If CP was present in message 3 there MUST be a corresponding CP in=20 message 4. When the responder sends a CP containing an internal IP=20 address in message 4, he MUST limit the traffic selector(s) in TSi=20 to contain only the address, or addresses, in the CP. The responder=20 MAY choose to limit TSr as described in section 4.9 Negotiating=20 Traffic Selectors of [IKEv2].=20 =20 2. Informational (Phase 2) Exchanges=20 =20 **** [This is an amendment to [IKEv2] section 3.3, paragraph 5 and the=20 exchange description at the end of that section]=20 =20 Messages in an Informational Exchange may contain zero or one=20 Configuration Payloads. If there is a Configuration Payload in a=20 request there MUST be a corresponding Configuration Payload in the=20 response.=20 =20 The Informational Exchange is defined as:=20 =20 Initiator Responder=20 ----------- -----------=20 HDR, SK {N, ..., D, ..., CP, ...} -->=20 <-- HDR, SK {N, ..., D, ..., CP, ...}=20 =20 3. Configuration Payload=20 =20 **** [This should be added to [IKEv2] section 5.?]=20 =20 A Configuration payload, denoted CP in this document, is used to=20 exchange configuration information between IKE peers. Typically the=20 peers would be an IRAC and IRAS. A Configuration Payload MAY appear=20 in an Informational exchange, or an IKE_SA_AUTH exchange, and MUST=20 NOT be in any other exchanges.=20 =20 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or=20 CFG_SET/CFG_ACK (see CFG Type in the payload description below) =20 =20 o "CFG_REQUEST/CFG_REPLY" allows an IRAC to request information from=20 an IRAS. If an attribute in the CFG_REQUEST Configuration Payload=20 is not zero length it is taken as a suggestion for that attribute. =20 The CFG_REPLY Configuration Payload MAY return that attribute, or a=20 new one. It MAY also add new attributes and not include some=20 requested ones.=20 =20 Dukes 4 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 A CFG_REPLY MUST be sent when a CFG_REQUEST is received, even if it=20 is empty, or missing attributes from the CFG_REQUEST. This merely=20 means that the requested attributes were not available or unknown.=20 =20 Initiator Responder=20 --------------- --------------=20 HDR, SK{CP(CFG_REQUEST)} -->=20 <-- HDR, SK{CP(CFG_REPLY)}=20 =20 o "CFG_SET/CFG_ACK" allows an IRAS to push configuration data to an=20 IRAC. In this case the CFG_SET Configuration Payload contains=20 attributes the initiator wants its peer to alter. The responder=20 MUST return a Configuration Payload and it MUST contain the zero=20 length attributes that the responder accepted. Those attributes=20 that it did not accept MUST NOT be in the CFG_ACK Configuration=20 Payload.=20 =20 Initiator Responder=20 --------------- --------------=20 HDR, SK{CP(CFG_SET)} -->=20 <-- HDR, SK{CP(CFG_ACK)}=20 =20 =20 The Configuration Payload is defined as follows:=20 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ! Next Payload !C! RESERVED ! Payload Length !=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ! CFG Type ! RESERVED !=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 ! !=20 ~ Configuration Attributes ~=20 ! !=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 o CFG Type (1 octet) - The type of exchange represented by the=20 Configuration Attributes.=20 =20 Types Value=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 RESERVED 0=20 CFG_REQUEST 1=20 CFG_REPLY 2=20 CFG_SET 3=20 CFG_ACK 4=20 =20 values 5-127 are reserved to IANA. Values 128-255 are for private=20 use among mutually consenting parties.=20 =20 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored.=20 =20 Dukes 5 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 o Configuration Attribute (variable length) - These are type length=20 values specific to the Configuration Payload and are defined below. =20 There may be zero or more Configuration Attributes in this payload.=20 =20 The payload type for the Configuration Payload is **TBD** (**TBD**).=20 =20 =20 3.1. Configuration Attributes=20 =20 **** [ This section would be a subsection 5.?.1]=20 =20 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 !R| Attribute Type ! Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Value ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 o Reserved (1 bit) - This bit MUST be set to zero and MUST be=20 ignored.=20 =20 o Attribute Type (7 bits) - A unique identifier for each of the=20 Configuration Attribute Types, the following are currently defined:=20 =20 MUST=20 Attribute Type Value Support Length=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 RESERVED 0=20 INTERNAL_IP4_ADDRESS 1 YES 0 or 4 octets=20 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets=20 INTERNAL_IP4_DNS 3 NO 0 or 4 octets=20 INTERNAL_IP4_NBNS 4 NO 0 or 4 octets=20 INTERNAL_ADDRESS_EXPIRY 5 YES 0 or 4 octets=20 INTERNAL_IP4_DHCP 6 NO 0 or 4 octets=20 APPLICATION_VERSION 7 YES 0 or more=20 INTERNAL_IP6_ADDRESS 8 YES 0 or 16 octets=20 INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets=20 INTERNAL_IP6_DNS 10 NO 0 or 16 octets=20 INTERNAL_IP6_NBNS 11 NO 0 or 16 octets=20 INTERNAL_IP6_DHCP 12 NO 0 or 16 octets=20 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets=20 SUPPORTED_ATTRIBUTES 14 YES 0 or multiples of 2=20 INTERNAL_IP6_SUBNET 15 YES 0 or 17 octets=20 =20 values 16-16383 are reserved to IANA. Values 16384-32767 are for=20 private use among mutually consenting parties.=20 =20 =20 Dukes 6 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the=20 internal network, sometimes called a red node address or private=20 address and MAY be a private address on the Internet. Multiple=20 internal addresses MAY be requested by requesting multiple=20 internal address attributes. The responder MAY only send up to=20 the number of addresses requested.=20 =20 The requested address is valid until the expiry time defined with=20 the INTERNAL_ADDRESS EXPIRY attribute or there are no IKE-SAs=20 between the peers.=20 =20 o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal=20 network's netmask. Only one netmask is allowed in the request and=20 reply messages (e.g. 255.255.255.0) and it MUST be used only with=20 an INTERNAL_ADDRESS attribute.=20 =20 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a=20 DNS server within the network. Multiple DNS servers MAY be=20 requested. The responder MAY respond with zero or more DNS server=20 attributes.=20 =20 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a=20 NetBios Name Server (WINS) within the network. Multiple NBNS=20 servers MAY be requested. The responder MAY respond with zero or=20 more NBNS server attributes.=20 =20 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that=20 the host can use the internal IP address. The host MUST renew the=20 IP address before this expiry time. Only one of these attributes=20 MAY be present in the reply.=20 =20 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to=20 send any internal DHCP requests to the address contained within=20 the attribute. Multiple DHCP servers MAY be requested. The=20 responder MAY respond with zero or more DHCP server attributes.=20 =20 o APPLICATION_VERSION - The version or application information of=20 the IPSec host. This is a string of printable ASCII characters=20 that is NOT null terminated.=20 =20 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- device protects. This attribute is made up of two fields; the=20 first being an IP address and the second being a netmask. =20 Multiple sub-networks MAY be requested. The responder MAY respond=20 with zero or more sub-network attributes.=20 =20 o SUPPORTED_ATTRIBUTES - When used within a Request, this=20 attribute must be zero length and specifies a query to the=20 responder to reply back with all of the attributes that it=20 supports. The response contains an attribute that contains a set=20 of attribute identifiers each in 2 octets. The length divided by=20 2 (bytes) would state the number of supported attributes contained=20 in the response.=20 =20 Dukes 7 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 =20 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- device protects. This attribute is made up of two fields; the=20 first being a 16 octet IPv6 address the second being a one octet=20 prefix-mask as defined in [ADDRIPV6]. Multiple sub-networks MAY=20 be requested. The responder MAY respond with zero or more sub- network attributes.=20 =20 Note that no recommendations are made in this document how an=20 implementation actually figures out what information to send in a=20 reply. i.e. we do not recommend any specific method of an IRAS=20 determining which DNS server should be returned to a requesting=20 IRAC.=20 =20 o Length (2 octets) - Length in octets of Value.=20 =20 o Value (0 or more octets) - The variable length value of this=20 Configuration Attribute.=20 =20 4. Notify Message Types=20 =20 **** [ This section is an amendment to 5.10.1 of [IKEv2] ]=20 =20 =20 INTERNAL-ADDRESS-FAILURE 36=20 =20 Indicates an error assigning an internal address (i.e.,=20 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the=20 processing of a Configuration Payload by a Responder. If this=20 error is generated within an IKE_SA_AUTH exchange no Child-SA=20 will be created.=20 =20 =20 5. Implementation Notes=20 =20 ****[ This section and its subsections should be placed in an appendix=20 to [IKEv2] ] =20 =20 The following descriptions detail how to perform specific functions=20 using the configuration payload. Other functions are possible and=20 thus this list is not a complete list of all of the possibilities. =20 While other functions are possible, the functions listed below MUST=20 be performed as detailed in this document to preserve=20 interoperability among different vendor's implementations.=20 =20 =20 5.1. Requesting an Internal Address=20 =20 This function provides address allocation to an IRAC trying to=20 tunnel into a network protected by an IRAS. Since the IKE_SA_AUTH=20 exchange creates an IKE-SA and a Child-SA the IRAC MUST request the=20 internal address, and optionally other information concerning the=20 internal network, in the IKE_SA_AUTH exchange. The may IRAS procure=20 =20 Dukes 8 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 an internal address for the IRAC from any number of sources such as=20 a DHCP/BOOTP server or its own address pool.=20 =20 Initiator Responder=20 ----------------------------- -------------------------------=20 HDR, SAi1, KEi, Ni, Nr,=20 SK {IDi, [CERT,] [CERTREQ,] [IDr,]=20 AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->=20 =20 <-- HDR, SK {IDr, [CERT,] AUTH,=20 CP(CFG_REPLY), SAr2, TSi, TSr}=20 =20 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute=20 (either IPv4 or IPv6) but MAY contain any number of additional=20 attributes the initiator wants returned in the response.=20 =20 For example, message from Initiator to Responder:=20 CP(CFG_REQUEST)=3D=20 INTERNAL_ADDRESS(0.0.0.0)=20 INTERNAL_NETMASK(0.0.0.0)=20 INTERNAL_DNS(0.0.0.0)=20 TSi =3D (0, 0-65536,0.0.0.0-255.255.255.255)=20 TSr =3D (0, 0-65536,0.0.0.0-255.255.255.255)=20 =20 NOTE: Traffic Selectors are a (protocol, port range, address range)=20 =20 message from Responder to Initiator:=20 =20 CP(CFG_REPLY)=3D=20 INTERNAL_ADDRESS(192.168.219.202)=20 INTERNAL_NETMASK(255.255.255.0)=20 INTERNAL_SUBNET(192.168.219.0/255.255.255.0)=20 TSi =3D (0, 0-65536,192.168.219.202-192.168.219.202)=20 TSr =3D (0, 0-65536,192.168.219.0-192.168.219.255)=20 =20 All returned values will be implementation dependent. As can be=20 seen in the above example, the IRAS MAY also send other attributes=20 that were not included in CP(CFG_REQUEST) and MAY ignore the non- mandatory attributes that it does not support.=20 =20 =20 5.2. Requesting the Peer's Version=20 =20 An IKE peer wishing to inquire about the other peer's version=20 information MUST use the method below. This is an example of a=20 configuration request within an Informational Exchange, after the=20 IKE-SA and first Child-SA have been created.=20 =20 Initiator Responder=20 ----------------------------- --------------------------=20 HDR, SK{CP(CFG_REQUEST)} -->=20 <-- HDR, SK{CP(CFG_REPLY)}=20 =20 =20 Dukes 9 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 =20 CP(CFG_REQUEST)=3D=20 APPLICATION_VERSION("")=20 =20 CP(CFG_REPLY)=20 APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")=20 =20 6. Enterprise Management Considerations=20 =20 =20 ****[ Something similar to this section could be placed in an appendix=20 to [IKEv2] as well] =20 The method defined in this document SHOULD NOT be used for wide=20 scale management. Its main intent is to provide a bootstrap=20 mechanism to exchange information within IPSec from IRAS to IRAC. =20 While it MAY be useful to use such a method to exchange information=20 between some Security Gateways (SGW) or small networks, existing=20 management protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP or=20 LDAP [LDAP] should be considered for enterprise management as well=20 as subsequent information exchanges.=20 =20 =20 7. Security Considerations=20 =20 This draft defines a payload for the Informational Exchange and MUST=20 be protected by an IKE-SA.=20 =20 =20 8. References=20 =20 =20 [1] Bradner, S., "The Internet Standards Process -- Revision=20 3", BCP 9, RFC 2026, October 1996.=20 =20 [2] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997=20 =20 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange=20 (IKE)", RFC240=20 =20 [IKEv2] Charlie Kaufman, "Internet Key Exchange(IKEv2) = Protocol=94 =20 draft-ietf-ipsec-ikev2-03.txt=20 =20 [DHCP] R. Droms, "Dynamic Host Configuration Protocol",=20 RFC2131=20 =20 [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote=20 Authentication Dial In User Service (RADIUS)", RFC2138=20 =20 [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory=20 Access Protocol (v3)", RFC2251=20 =20 [ESP] S. Kent, "IP Encapsulating Security Payload (ESP)",=20 RFC2406=20 =20 Dukes 10 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 [ADDRIPV6] Hinden, R., "IP Version 6 Addressing Architecture",=20 RFC 2373, July 1998.=20 =20 =20 . Acknowledgments=20 =20 The editor would like to thank Stephane Beaulieu, Dan Harkins,=20 Derrell Piper, and Paul Hauffman.=20 =20 =20 0. Author's Addresses=20 =20 Darren Dukes=20 Cisco Systems Co.=20 2000 Innovation Drive=20 Kanata, ON, Canada=20 Phone: 1-613-254-3679=20 Email: ddukes@cisco.com=20 =20 =20 =20 ukes 11 =0A= =0C IKEv2 Configuration Payload December 2002=20 =20 ull Copyright Statement=20 "Copyright (C) The Internet Society (date). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into=20 =20 =20 This Internet Draft expires July 2003=20 =20 =20 ukes 12 =0A= =0C ------=_NextPart_000_00A4_01C2A6A7.96A489B0-- From owner-ipsec@lists.tislabs.com Thu Dec 19 07:43:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJFhmo16082; Thu, 19 Dec 2002 07:43:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19812 Thu, 19 Dec 2002 10:12:09 -0500 (EST) Subject: IBM alphaworks release for IP-sec Configuration Validator. To: ipsec@lists.tislabs.com Cc: Raymond Jennings , Mandis S Beigi , Reiner Sailer X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Dinesh Verma Date: Thu, 19 Dec 2002 05:17:00 -0500 X-MIMETrack: Serialize by Router on D01ML244/01/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 12/19/2002 05:17:02 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IP-sec researchers, A download of the IPsec configuration validation software for linux is now available from IBM alphaworks. The URL for the download is http://alphaworks.ibm.com/tech/ipsecvalidate. You can find more details of the software in our paper available at URL http://www.usenix.org/events/lisa2001/tech/sailer.html. regards, Dinesh C. Verma IBM TJ Watson Research Center PO Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-7466 Email: dverma@us.ibm.com From owner-ipsec@lists.tislabs.com Thu Dec 19 10:00:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJI0Go25644; Thu, 19 Dec 2002 10:00:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21561 Thu, 19 Dec 2002 12:29:55 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 19 Dec 2002 09:30:54 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. The following draft comes out of the meeting we had after the IPsec WG meeting in Atlanta. It represents the thinking of many folks about the cleanest way to do legacy authentication in IKEv2. Please read it and comment here on the list. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Dec 19 10:00:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJI0ko25713; Thu, 19 Dec 2002 10:00:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21537 Thu, 19 Dec 2002 12:27:54 -0500 (EST) Date: Thu, 19 Dec 2002 19:29:38 +0200 (IST) From: Hugo Krawczyk To: Darren Dukes cc: ipsec@lists.tislabs.com, ietf-mode-cfg@vpnc.org Subject: Re: Proposed Configuration payload for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 18 Dec 2002, Darren Dukes wrote: > Attached is a draft which is intended to be merged with the IKEv2 draft. > There is no intent for this draft to continue on its own. It contains a > payload and description of how an IPsec Remote Access Client (IRAC) may use > that payload to get configuration information (internal IP, subnets, etc.) > from an IPsec Remote Access Server (IRAS). > > The payload in this draft is very similar to the IKEv1 modecfg draft, this > draft states the differences between the two. > > Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in > November, 2002, the IPsec WG decided to add remote access capabilities > (legacy authentication and remote client configuration) to IKEv2. At an If I understand it correctly, your draft only addresses the remote client configuration issue, not the legacy authentication. How do you envision adding the legacy authentication support and still making use of the configuration mechanism described in the draft? Note that you add the configuration mechanism to messages 3 and 4 of ikev2 and assume that it is protected under the IKE-SA, however if you need to perform legacy authentication then you will not have an established IKE-SA in messages 3 and 4. Also, it is worth noting that even if client and server use regular IKE authentication (signatures or preshared key) then in message 3 the server (responder) is not yet authenticated by the client so the information transmitted from IRAC to IRAS in this message is NOT protected. This should be documented and explicitly said that this message should not contain any confidential information. These problems are solved if the configuration information exchange happens in phase 2 (at the expense, of course, of more round trips). Hugo > informal design team meeting after the WG meeting, the VPN vendors attending > decided that the best options to propose to the WG were to add capabilities > similar to XAUTH and MODE-CFG." > > Please send all comments regarding this draft to ipsec@lists.tislabs.com > > Thanks, > Darren > From owner-ipsec@lists.tislabs.com Thu Dec 19 12:09:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJK9qo06350; Thu, 19 Dec 2002 12:09:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22710 Thu, 19 Dec 2002 14:37:47 -0500 (EST) Reply-To: From: "Darren Dukes" To: "Hugo Krawczyk" Cc: , Subject: RE: Proposed Configuration payload for IKEv2 Date: Thu, 19 Dec 2002 14:39:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Thursday, December 19, 2002 12:30 PM > > On Wed, 18 Dec 2002, Darren Dukes wrote: > > > Attached is a draft which is intended to be merged with the IKEv2 draft. > > There is no intent for this draft to continue on its own. It contains a > > payload and description of how an IPsec Remote Access Client > (IRAC) may use > > that payload to get configuration information (internal IP, > subnets, etc.) > > from an IPsec Remote Access Server (IRAS). > > > > The payload in this draft is very similar to the IKEv1 modecfg > draft, this > > draft states the differences between the two. > > > > Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in > > November, 2002, the IPsec WG decided to add remote access capabilities > > (legacy authentication and remote client configuration) to IKEv2. At an > > If I understand it correctly, your draft only addresses the remote client > configuration issue, not the legacy authentication. How do you envision > adding the legacy authentication support and still making use of the > configuration mechanism described in the draft? After taking a quick look at Paul's draft he just sent out, I think CP will go in the LAS exchange message 3 and message N the same way it's specified for message 3 and 4 now. > Note that you add the > configuration mechanism to messages 3 and 4 of ikev2 and assume that it is > protected under the IKE-SA, however if you need to perform legacy > authentication then you will not have an established IKE-SA in messages 3 > and 4. > > Also, it is worth noting that even if client and server use regular IKE > authentication (signatures or preshared key) then in message 3 the server > (responder) is not yet authenticated by the client so the information > transmitted from IRAC to IRAS in this message is NOT protected. This > should be documented and explicitly said that this message should not > contain any confidential information. You are right about message 3, and the IRAS not being authenticated to IRAC. I think text about the lack of authentication should suffice with strong suggestions of what configuration attributes should go into the CFG_REQUEST. > > These problems are solved if the configuration information exchange > happens in phase 2 (at the expense, of course, of more round trips). I had originally thought of this as just a post 'phase-1' exchange but since the first Child-SA is always created in message 3 and 4 we will need the configuration data before or during its creation. Without it the IRAS has no way of knowing how to narrow TSi in message 4. Darren > > Hugo > > > informal design team meeting after the WG meeting, the VPN > vendors attending > > decided that the best options to propose to the WG were to add > capabilities > > similar to XAUTH and MODE-CFG." > > > > Please send all comments regarding this draft to ipsec@lists.tislabs.com > > > > Thanks, > > Darren > > > From owner-ipsec@lists.tislabs.com Thu Dec 19 12:26:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJKQco08095; Thu, 19 Dec 2002 12:26:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22870 Thu, 19 Dec 2002 14:52:15 -0500 (EST) Message-Id: <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Dec 2002 14:06:35 -0500 To: Paul Hoffman / VPNC From: David Jablon Subject: Re: Secure legacy authentication for IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Perhaps "extensibility" should include the ability to take advantage of keys generated by methods that use legacy credentials. I've heard this referred (somewhat redundantly) as "future extensibility" in other protocols. Although I didn't see this capability in the SLA draft, could it be added? -- David At 09:30 AM 12/19/02 -0800, Paul Hoffman / VPNC wrote: >Greetings again. The following draft comes out of the meeting we had after the IPsec WG meeting in Atlanta. It represents the thinking of many folks about the cleanest way to do legacy authentication in IKEv2. Please read it and comment here on the list. > > > >--Paul Hoffman, Director >--VPN Consortium From owner-ipsec@lists.tislabs.com Thu Dec 19 15:10:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJNA1o21247; Thu, 19 Dec 2002 15:10:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24610 Thu, 19 Dec 2002 17:27:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 19 Dec 2002 17:26:24 -0500 To: Henry Spencer From: Stephen Kent Subject: Re: speaking of keys Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:53 PM -0500 12/9/02, Henry Spencer wrote: >On Fri, 6 Dec 2002, Stephen Kent wrote: >> I don't have a problem with a MAY for bigger groups, but I really >> think it is most appropriate to focus on the management facility to >> allow user communities to select their own, of whatever size they >> feel is appropriate. > >While I have some sympathy with that, historically IPsec has suffered >badly from an excess of useless flexibility, an unwillingness to make >decisions among largely-equivalent alternatives, and an inability to set >clear standards even when they are crucial to interoperability. > >If we think one choice is definitely preferable in most cases, but >specific users may have reasons to prefer another, we have a word for >that: not MAY, but SHOULD. > >And as a matter of basic principle, the default should be good security, >with an option to weaken it when necessary, not poor security with an >option to upgrade it. Henry, I agree that we don't want default key lengths that are so short as to be unacceptably weak, nor do we want lengths that are so long as to discourage use of the technology. Over time, Moore's Law will allow us to increase the key length and not suffer as much, so we know the long term trend and we are probably wrangling over the details of what is the right size, not the principles. I also am very much in agreement with the notion of not making things more complex. However, I see a need to allow private groups to be specified by user communities, and Hugo even noted why this has potential security benefits. We have had a provision for passing private group params, and that adds complexity of one sort. I'd be happy if we omitted support that approach, and instead mandated management support for entering private group params and then just use a compact reference (e.g., an OID) to specify the private groups. I would not expect most users to make use of this capability, but sophisticated user communities could use this facility and it might even provide us with an out re the debate over the right group sizes, although I don't yet have a good proposal of how to do that. Steve From owner-ipsec@lists.tislabs.com Thu Dec 19 15:10:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJNA1o21248; Thu, 19 Dec 2002 15:10:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24503 Thu, 19 Dec 2002 17:17:43 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212062109.gB6L9aUS013157@sandelman.ottawa.on.ca> References: <200212062109.gB6L9aUS013157@sandelman.ottawa.on.ca> Date: Thu, 19 Dec 2002 17:18:37 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:09 PM -0500 12/6/02, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Stephen" == Stephen Kent writes: > Stephen> Also, let's remember that the key size is not the only factor in > Stephen> determining the security of these systems. It's >tempting to raise > > Absolutely. > > Stephen> software implementation on a user WS/laptop where there >are lots more > Stephen> likely ways that the security of the traffic will be compromised > Stephen> (other than solving the discrete log problem for a >1024-bit group) > Stephen> and where the performance hit will be most visible and thus may > Stephen> eventually motivate an individual to NOT use IPsec at all. > > I think that we can write a MAY for a smaller size (i.e. 1024). > The reason to pick something for the MUST is interoperability. That is the >only reason. > > Stephen> I don't have a problem with a MAY for bigger groups, but I really > Stephen> think it is most appropriate to focus on the management >facility to > Stephen> allow user communities to select their own, of whatever size they > Stephen> feel is appropriate. > > It has been a long time since anyone has talked about APIs. > > Bill Sommerfeld has promised to take us (IPSP specifically) down that path >again, and it is high time that we do this. I do not think that applications >writers should have to deal with DH modulus size. I think that we should have >a direct mapping that gives minimum modulus sizes for particular levels of >security. > Michael, I don't think we need an API here, although that might be nice long term. What we need is a set if MUSTs in IKE v2 that mandate the provision of (local?) management controls over the specification of DH groups, not just the ones already specified. We have provisions in IKE for passing group parameters, but I have been told that they are not generally supported, and thus rarely if ever used. For my purposes, I would be happy with a way for a community to specify the parameters and inserts them into all of the community members' systems via a management interface, and then use a locally managed (but globally unique) ID, e.g., an OID, to refer to the parameters. However, I realize that this would not be supportive of the opportunistic encryption model you have proposed, so maybe this approach is not sufficient for all. Steve From owner-ipsec@lists.tislabs.com Thu Dec 19 15:44:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBJNiKo23081; Thu, 19 Dec 2002 15:44:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25026 Thu, 19 Dec 2002 18:04:28 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 19 Dec 2002 14:18:00 -0800 To: , "Hugo Krawczyk" From: Paul Hoffman / VPNC Subject: RE: Proposed Configuration payload for IKEv2 Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:39 PM -0500 12/19/02, Darren Dukes wrote: >After taking a quick look at Paul's draft he just sent out, I think CP will >go in the LAS exchange message 3 and message N the same way it's specified >for message 3 and 4 now. That sounds right, and it keeps parallel with IKEv2. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Dec 19 16:45:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK0jDo27479; Thu, 19 Dec 2002 16:45:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25860 Thu, 19 Dec 2002 19:16:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212100150.gBA1obp3012139@sandelman.ottawa.on.ca> References: <200212100150.gBA1obp3012139@sandelman.ottawa.on.ca> Date: Thu, 19 Dec 2002 19:17:02 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: Summary of revised identity changes Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:50 PM -0500 12/9/02, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > > >> a) For certificate authentication, in messages 3 and 4, you no longer > >> send both an ID and a certificate. Instead, you send only a > >> certificate and the receiver gets your identity from the certificate. > > I'm profoundly unhappy about this. > I feel that it will lead to massive amounts of failure to interoperate. > > Right now, I can make an X.509 implementation and a non-X.509 >implementation (such as might be found in a handheld!) interop by arranging >for appropriate keys to be in the right places. > > I.e. I can generate the handheld's "certificate" in a number of ways that >doesn't involve having the handheld actually know about X.509. The contents >of the CERT payload is just "bytes" - doesn't matter to the handheld. > > Now, if you do this, then the handheld winds up with goop it doesn't >understand setting policy for it. Maybe this is appropriate for you, but not >for me. > > I fear strongly that this proposal will permanently wed people to the >false belief that public key operations involve PKIs. > > By all means, make the contents of certificates clear. But, they aren't to >be involved in the identities. Michael, I can't understand this last sentence. When we use certs for authentication in IKE, they should be used to convey the IDs that we are asserting. If we use certs to authenticate IKE peers and these have no relationship to the IDs we assert, then we have to have some other mapping of the certs to the sets of IDs that they are authorized to represent, and that mapping is another source of complexity and errors that can result in security problems. Did I misunderstand your last comment? Steve From owner-ipsec@lists.tislabs.com Thu Dec 19 16:46:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK0kZo27521; Thu, 19 Dec 2002 16:46:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25933 Thu, 19 Dec 2002 19:22:52 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212111549.gBBFnxFn017684@sandelman.ottawa.on.ca> References: <200212111549.gBBFnxFn017684@sandelman.ottawa.on.ca> Date: Thu, 19 Dec 2002 19:25:08 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:49 AM -0500 12/11/02, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "David" == David Wagner writes: > David> But is it too small for the MUST requirement in the RFC? > > David> As I see it, we have to balance two costs here. If we require a > David> 1024-bit modulus, there is a risk it will get broken in >our lifetime. > David> If we require a 2048-bit modulus, some people will not >use IPSEC because > David> it is too slow (this is not just a risk; this is for >sure). How do we > David> balance these two? > > I don't understand this argument. MUST doesn't mean that you have to use it >in an exchange, it means that you must support it. The purpose of the MUST is >to encourage interopability. It doesn't have to the fastest, nor the >cheapest. It has to be there for the long term. I have to disagree slightly. We can only rely on vendors to implement the MUSTs, by definition, for any standard. Thus it is reasonable for users to generally default to the MUSTs (algorithms, modes, key lengths, ...) to ensure interoperability. I realize that there are exceptions to this, but if we choose a single MUST value that we all agree would be secure long term, then we should expect people will use only it, consistent with Paul Hoffman's observation about VPN products. If we choose more than one MUST value, then we should be able to rely on interoperability on either value, and people at least have an ability to pick one as a default. My original concern was that they might default to the biggest value (on the "bigger is better" theory of operation) and then we would get bad press re the expense of IPsec/IKE. Maybe we can't avoid this, but that was the concern I originally voiced. Another way of approaching this might be to mandate support for larger group sizes, but not yet mandate support for SPECIFIC groups at these larger sizes. That way user communities would be free to choose groups at bigger sizes and be assured of interoperability among various vendor products, but we could avoid creating defaults that we know users would select mindlessly. I am comfortable with mandating the current 1024 group because it is so widely used in existing IPsec implementations that this would be a good default in terms of ensuring interoperability in a backwards compatible context. If we mandate a specific 1500ish bit group, that would seem reasonable for folks who are concerned about the entropy of 1024-bit groups, based on what I have seen on this thread. Anything bigger could be selected as a private group for use in a community that feels that it needs a bigger key size and is comfortable with the performance implications based on their set of implementations. In any case, so long as we mandate that larger groups up to some size can be supported by the underlying software/hardware, user communities are free to select such groups and be confident that their implementations will work (if we mandate suitable management interfaces to enable this ...). > > If you are building a system where you control all components you may >configure it anyway that you like. So, if Verizon's new IP-mobile-phone needs >to use 1024 bit moduli, and they won't let me use a third party handset, they >can do what they like. > > Now, if asking for 1536 or 2048 bit moduli causes the software to always >use more resources than you can afford (i.e. 256 byte buffers for bignums >rather than 128 byte buffers), then this is a problem. Is that really a >concern here? That is one possible concern. In developing this standard we have a delicate balancing act. On one hand we don't want to impose constraints that would impede high speed hardware implementations, but on the other hand we also don't want to impose undue burdens on software either. Steve From owner-ipsec@lists.tislabs.com Thu Dec 19 17:27:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK1RIo01289; Thu, 19 Dec 2002 17:27:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26380 Thu, 19 Dec 2002 20:03:26 -0500 (EST) Message-ID: <3E026C53.566627C2@nortelnetworks.com> Date: Thu, 19 Dec 2002 20:03:15 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: speaking of keys References: <200212111549.gBBFnxFn017684@sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > If we choose more than one MUST value, then we should be able to rely > on interoperability on either value, and people at least have an > ability to pick one as a default. My original concern was that they > might default to the biggest value (on the "bigger is better" theory > of operation) and then we would get bad press re the expense of > IPsec/IKE. > > Maybe we can't avoid this, but that was the concern I originally > voiced. Another way of approaching this might be to mandate support > for larger group sizes, but not yet mandate support for SPECIFIC > groups at these larger sizes. That way user communities would be free > to choose groups at bigger sizes and be assured of interoperability > among various vendor products, but we could avoid creating defaults > that we know users would select mindlessly. > One could put some guidance in the document about relative performance and security merits of the mandated groups. Or even actual numbers ("at the time of writing, here's the deal on performance"). I think that the best we can accomplish is to provide guidance to the developers trying to cut code for this standard. It's up to them to determine how to best "package" this for the ultimate consumer. I really don't have a problem with MUSTing a couple of groups at least. 1024 - fast, but somewhat less secure 15xx - slower, but rather more secure I can sympathize with not wanting to mandate the much larger groups. Small devices (telephones, for example) really do have some serious storage and peformance issues, but storage is the real killer, as it turns out. Bad engineering, if you ask me, but the reality is that there are a whole poopload of these devices out in the field, with a bigger poopload on the way. These things are *very* cost-sensitive. It really is the case that product line managers will agonize over feature decisions that might require adding another $0.50 to the hardware cost of the device. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Thu Dec 19 19:24:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK3Oeo10633; Thu, 19 Dec 2002 19:24:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27662 Thu, 19 Dec 2002 21:57:49 -0500 (EST) Date: Fri, 20 Dec 2002 04:58:53 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: ddukes@cisco.com, IPsec WG , ietf-mode-cfg@vpnc.org Subject: RE: Proposed Configuration payload for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 19 Dec 2002, Paul Hoffman / VPNC wrote: > At 2:39 PM -0500 12/19/02, Darren Dukes wrote: > >After taking a quick look at Paul's draft he just sent out, I think CP will > >go in the LAS exchange message 3 and message N the same way it's specified > >for message 3 and 4 now. > > That sounds right, and it keeps parallel with IKEv2. Paul, There is no real "parallel" with IKEv2. The exchange you propose (the SLA draft) changes the logic of the cryptographic key exchange in IKEv2 by making the responder the first to authenticate in message 2. Consequently, it also changes the contents of the signature. It resembles agressive mode of IKEv1 much more than IKEv2. In other words, from the point of view of IKEv2 this is a totally different mode of authentication, not only by the kind of credentials in use but also by its cryptographic logic. You have to be very careful when you change the cryptographic logic in IKEv2. Is the protocol you are proposing still secure? It seems to me, at least at first glance, that the protocol may be open to some form of man-in-the-middle attack (or more precisely, "server in the middle"). Have you checked that? At the functional (and security) level the identity of the server (and/or its certificate) seems to be missing in message 2. Is this just an overlook, or is it deliberate? In any case I would not like to assume that the client always has this cert in advance or that there is a single PK with which the server's signature is to be verified. Note that there may be, in principle, more than one server answering the client's request. Hugo > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Thu Dec 19 20:33:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK4X4o13326; Thu, 19 Dec 2002 20:33:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28244 Thu, 19 Dec 2002 23:00:14 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 19 Dec 2002 20:01:13 -0800 To: Hugo Krawczyk From: Paul Hoffman / VPNC Subject: RE: Proposed Configuration payload for IKEv2 Cc: ddukes@cisco.com, IPsec WG , ietf-mode-cfg@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:58 AM +0200 12/20/02, Hugo Krawczyk wrote: >You have to be very careful when you change the cryptographic logic in >IKEv2. Is the protocol you are proposing still secure? Somehow, we thought that *you* might answer that question. :-) >It seems to me, at least at first glance, that the protocol may be open to >some form of man-in-the-middle attack (or more precisely, "server in the >middle"). Have you checked that? As I understand it, the server-in-the-middle attack that has been discussed this last month requires that the messages being passed in the IPsec remote access protocol have the same format as the messages being passed in the legacy authentication protocol. If that is a correct understanding, then it seems like we aren't susceptible to it because we have our own message format for CHRE payloads. >At the functional (and security) level the identity of the server (and/or >its certificate) seems to be missing in message 2. Is this just an >overlook, or is it deliberate? In any case I would not like to assume that >the client always has this cert in advance or that there is a single PK >with which the server's signature is to be verified. Note that there may >be, in principle, more than one server answering the client's request. The model we assumed was that the initiator knew the identity of the responder. You are correct, there might be a pool of responders. We could certainly add a certificate in message 2 for that. As per the discussion earlier this year, in the remote access case, it is fine to expose the identity of the responder to passive snooping if it is a remote access server. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Dec 20 01:14:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBK9Ebo12432; Fri, 20 Dec 2002 01:14:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01120 Fri, 20 Dec 2002 03:46:44 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E55090EB3@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ddukes@cisco.com'" , Hugo Krawczyk Cc: ipsec@lists.tislabs.com, ietf-mode-cfg@vpnc.org Subject: RE: Proposed Configuration payload for IKEv2 Date: Fri, 20 Dec 2002 09:48:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Gents, Is not intended for IP configuration of remote hosts ? IMHO, decouples IPSec and IRAC config in the sense that only a short lived tunnel is required for DHCP messages hence all other complexity is in DHCP. What is gained from decoupling IKE from host configuration is that only a single mechanism is required for host configuration. In that way a system administrator must not learn new mechanisms/methods to configure hosts. To her/him it is the same whether configuring a central office or a remote IPSec protected host. Best regards - Dirk -----Original Message----- From: Darren Dukes [mailto:ddukes@cisco.com] Sent: donderdag 19 december 2002 20:39 To: Hugo Krawczyk Cc: ipsec@lists.tislabs.com; ietf-mode-cfg@vpnc.org Subject: RE: Proposed Configuration payload for IKEv2 > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Thursday, December 19, 2002 12:30 PM > > On Wed, 18 Dec 2002, Darren Dukes wrote: > > > Attached is a draft which is intended to be merged with the IKEv2 draft. > > There is no intent for this draft to continue on its own. It contains a > > payload and description of how an IPsec Remote Access Client > (IRAC) may use > > that payload to get configuration information (internal IP, > subnets, etc.) > > from an IPsec Remote Access Server (IRAS). > > > > The payload in this draft is very similar to the IKEv1 modecfg > draft, this > > draft states the differences between the two. > > > > Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in > > November, 2002, the IPsec WG decided to add remote access capabilities > > (legacy authentication and remote client configuration) to IKEv2. At an > > If I understand it correctly, your draft only addresses the remote client > configuration issue, not the legacy authentication. How do you envision > adding the legacy authentication support and still making use of the > configuration mechanism described in the draft? After taking a quick look at Paul's draft he just sent out, I think CP will go in the LAS exchange message 3 and message N the same way it's specified for message 3 and 4 now. > Note that you add the > configuration mechanism to messages 3 and 4 of ikev2 and assume that it is > protected under the IKE-SA, however if you need to perform legacy > authentication then you will not have an established IKE-SA in messages 3 > and 4. > > Also, it is worth noting that even if client and server use regular IKE > authentication (signatures or preshared key) then in message 3 the server > (responder) is not yet authenticated by the client so the information > transmitted from IRAC to IRAS in this message is NOT protected. This > should be documented and explicitly said that this message should not > contain any confidential information. You are right about message 3, and the IRAS not being authenticated to IRAC. I think text about the lack of authentication should suffice with strong suggestions of what configuration attributes should go into the CFG_REQUEST. > > These problems are solved if the configuration information exchange > happens in phase 2 (at the expense, of course, of more round trips). I had originally thought of this as just a post 'phase-1' exchange but since the first Child-SA is always created in message 3 and 4 we will need the configuration data before or during its creation. Without it the IRAS has no way of knowing how to narrow TSi in message 4. Darren > > Hugo > > > informal design team meeting after the WG meeting, the VPN > vendors attending > > decided that the best options to propose to the WG were to add > capabilities > > similar to XAUTH and MODE-CFG." > > > > Please send all comments regarding this draft to ipsec@lists.tislabs.com > > > > Thanks, > > Darren > > > From owner-ipsec@lists.tislabs.com Fri Dec 20 04:31:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKCV0o04147; Fri, 20 Dec 2002 04:31:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03140 Fri, 20 Dec 2002 07:04:48 -0500 (EST) Message-ID: <0a5a01c2a820$416abfd0$640572d4@trustworks.com> From: "Valery Smyslov" To: , "Paul Hoffman / VPNC" References: Subject: Re: Secure legacy authentication for IKEv2 Date: Fri, 20 Dec 2002 15:06:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Paul Hoffman / VPNC" To: Sent: Thursday, December 19, 2002 8:30 PM Subject: Secure legacy authentication for IKEv2 > Greetings again. The following draft comes out of the meeting we had > after the IPsec WG meeting in Atlanta. It represents the thinking of > many folks about the cleanest way to do legacy authentication in > IKEv2. Please read it and comment here on the list. > > Hi, draft suggests that no negotiation of LAM type is possible between client and server: server can just accept or reject LAM type that client proposed, and he has no means to indicate to client which LAM type he is willing to do. This can lead to situation, when client will have to perform up to 4 connection attempts with different LAM types. Not only will it delay the connection setup, but also it will put an unnecessary load to server - for each attempt he will have to do both DH and RSA/DSA. I think better way to handle this situation is to allow server to change LAM type if he doesn't like what client proposed. This will provide an indication to client that legacy authentication process must be restarted according to new LAM type. For example: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, AUTH Client doesn't know yet what LAM type server will accept. So, she tries the first one she supports, for example - PASSWORD. HDR*, CHRE(LAM Type = SLA_PASSWORD), SAi2, TSi, TSr --> At this point server decides, that this particular user must be authenticated with OTP instead of PASSWORD. So, he changes LAM type to SLA_OTP and sends it back to client. <-- HDR*, CHRE(LAM Type = SLA_OTP) Client restarts authentication process with OTP. HDR*, CHRE(LAM Type = SLA_OTP) --> and an excahnge continues as described in the draft. As a side affect, it will also allow server to perform successive user authentication by multiple LAM (not sure if it is really useful). Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Fri Dec 20 07:04:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKF49o14004; Fri, 20 Dec 2002 07:04:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04584 Fri, 20 Dec 2002 09:34:11 -0500 (EST) Message-Id: <5.2.0.9.2.20021220092037.021cb2f0@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 20 Dec 2002 09:35:34 -0500 To: "Marcus Leech" From: Russ Housley Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com In-Reply-To: <3E026C53.566627C2@nortelnetworks.com> References: <200212111549.gBBFnxFn017684@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Marcus: >One could put some guidance in the document about relative performance > and security merits of the mandated groups. Or even actual numbers > ("at the time of writing, here's the deal on performance"). I think > that the best we can accomplish is to provide guidance to the developers > trying to cut code for this standard. It's up to them to determine how > to best "package" this for the ultimate consumer. > >I really don't have a problem with MUSTing a couple of groups at > least. > > 1024 - fast, but somewhat less secure > 15xx - slower, but rather more secure I think that Paul Hoffman was the first to suggest the more than one MUST approach. I think it offers a good way forward. Of course, whatever sizes we select, a paragraph is needed in the security considerations. With the advance of time, bigger values will be needed. I think that 1024 should be one of the MUST implement sizes. Hugo and David Wagner have both said that they could live with this size, and the draft NIST guidelines say that this is sufficient for protecting sensitive information until 2015. Further, there is some hardware the supports 1024, then uses software if a larger key is provided. Finally, 1024 performance is quite reasonable in software. As for picking the right value for the next MUST implement size, I have less clarity. We have learned that more and more hardware supports 2048, and the draft NIST guidelines say that this is sufficient for protecting sensitive information until 2035. Yet, the software performance, especially on small processors, is quite poor. I think that a smaller value is a better choice. The draft NIST guidelines do not offer an recommendations on values between 1024 and 2048. However, some interpolation is possible. I think that we should consider 1280 and 1536. Russ From owner-ipsec@lists.tislabs.com Fri Dec 20 07:04:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKF4Po14054; Fri, 20 Dec 2002 07:04:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04622 Fri, 20 Dec 2002 09:38:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: Status on draft-ietf-ipsec-ike-modp-groups-04.txt ? Date: Wed, 18 Dec 2002 12:29:34 -0800 Message-ID: Thread-Topic: Status on draft-ietf-ipsec-ike-modp-groups-04.txt ? Thread-Index: AcKm1C4O3fVBk4kfSZSt24WV6ybelw== From: "William Dixon" To: , "Tero Kivinen" Cc: X-OriginalArrivalTime: 18 Dec 2002 20:29:37.0165 (UTC) FILETIME=[2F00BBD0:01C2A6D4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A6D4.2D329AE8" ------_=_NextPart_001_01C2A6D4.2D329AE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is the detailed status here ? I know it's passed WG last call. I thought it was past IETF last call. But I don't see it in the RFC editor queue... ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif ------_=_NextPart_001_01C2A6D4.2D329AE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Status on draft-ietf-ipsec-ike-modp-groups-04.txt ?

What is the detailed status here = ?  I know it's passed WG last call.  I thought it was past = IETF last call.  But I don't see it in the RFC editor = queue...

ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-pr= ocess.gif

------_=_NextPart_001_01C2A6D4.2D329AE8-- --------------InterScan_NT_MIME_Boundary-- From owner-ipsec@lists.tislabs.com Fri Dec 20 07:06:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKF6Jo14306; Fri, 20 Dec 2002 07:06:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04634 Fri, 20 Dec 2002 09:39:12 -0500 (EST) Subject: Public URL for ipsecvalidate paper. To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Dinesh Verma Date: Thu, 19 Dec 2002 15:36:16 -0500 X-MIMETrack: Serialize by Router on D01ML244/01/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 12/19/2002 15:36:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The paper reference for the URL paper at Usenix site is only accessible to Usenix members. Here is the revised mail with a publicly accessible URL. ---------- A download of the IPsec configuration validation software for linux is now available from IBM alphaworks. The URL for the download is http://alphaworks.ibm.com/tech/ipsecvalidate. You can find more details of the software in our paper available at URL http://citeseer.nj.nec.com/532482.html. ----------- Please accept my apologies for the duplicate mail. Regards, Dinesh C. Verma IBM TJ Watson Research Center PO Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-7466 Email: dverma@us.ibm.com From owner-ipsec@lists.tislabs.com Fri Dec 20 07:37:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKFbqo16437; Fri, 20 Dec 2002 07:37:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05031 Fri, 20 Dec 2002 10:16:40 -0500 (EST) Message-ID: <3E033457.1EDA4831@nortelnetworks.com> Date: Fri, 20 Dec 2002 10:16:39 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Russ Housley CC: "Marcus Leech" , ipsec@lists.tislabs.com Subject: Re: speaking of keys References: <200212111549.gBBFnxFn017684@sandelman.ottawa.on.ca> <5.2.0.9.2.20021220092037.021cb2f0@mail.binhost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ Housley wrote: > > The draft NIST guidelines do not offer an recommendations on values between > 1024 and 2048. However, some interpolation is possible. I think that we > should consider 1280 and 1536. > > Russ Actually, 1280 was one of the values I had thought of, but I don't have a good intuitive feel for how much stronger it is than 1024. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Fri Dec 20 08:33:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKGXko18301; Fri, 20 Dec 2002 08:33:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05649 Fri, 20 Dec 2002 11:06:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C602@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564C602@corpmx14.us.dg.com> Date: Fri, 20 Dec 2002 11:03:38 -0500 To: Black_David@emc.com From: Stephen Kent Subject: RE: IKEv2 transport concerns Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:46 PM -0500 12/6/02, Black_David@emc.com wrote: > > >> >I think it needs to be in both places. We have a one-time >opportunity >> >> >to avoid the IKEv1 ECN negotiation kludge if all IKEv2 >implementations >> >> >are REQUIRED to handle ECN correctly at tunnel egress. IMHO, this >> >> >outcome is important enough to merit specifying the means of >achieving >> >> >it in both the IKEv2 and RFC2401bis documents. If we wind up dealing >> >> >with IKEv2 systems that get this wrong, the negotiation kludge will >be >> >> >with us for much longer ... >> >> >> >> David, >> >> >> >> I don't think the IKE v2 document is the appropriate place to make >> >> note of the ECN handling you refer to, since it applies to the >> >> actions performed on the child SAs that IKE establishes, not on the >> >> IKE SAs, right? It really is a 2401bis matter, I believe. >> >> >> >> Steve >> > >> >Will 2401bis progress on a timeline that will allow a normative reference >> >to it from IKEv2? If so having IKEv2 say "MUST do ECN right, see 2401bis >> >for details" would be fine. I'm concerned that no mention of this at all >in >> >IKEv2 implicitly allows IKEv2 to negotiate 2401classic style tunnel >handling >> >of ECN, and that would be unfortunate. >> >> David, >> >> I doubt that IKE v2 and 2401 bis will be issued concurrently. But, my >> concern is over where a requirement belongs in our documents, more >> than what gets it out soonest. I recognize the value in the time to >> market issue you raise, but I think putting requirement in the proper >> place is more important. >> >> Steve > >Steve, > >Would you be amenable to an approach based on a small draft that >contains just the tunnel encapsulation/decapsulation material needed >to specify ECN handling for tunnel-mode SAs? That could be put >together in short enough order to allow IKEv2 to use a "MUST" to >reference it without delaying IKEv2. When 2401bis is ready, it >would obsolete both the new small tunnel draft and 2401 itself, >so that the requirement winds up in the right place. I'll sign >up to write the small ECN handling draft on a schedule that won't >hold up IKEv2. > >If 2401bis gets done faster than expected, the new small ECN handling >draft could vanish without a trace, having served its purposes >of preventing 2401-classic tunnel (mis)handling of ECN in SAs set up >by IKEv2, and allowing us to leave the IKEv1 ECN negotiation >kludge on the scrap heap where it belongs. > >Thanks, >--David David, I'm in favor of keeping the ECN processing separate from IKE v2, so to that extent the separate draft sounds good. However, I would like to be reminded of the reason for having a reference to the separate draft in IKE v2. Steve From owner-ipsec@lists.tislabs.com Fri Dec 20 09:04:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKH4io20174; Fri, 20 Dec 2002 09:04:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05986 Fri, 20 Dec 2002 11:39:56 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <0a5a01c2a820$416abfd0$640572d4@trustworks.com> References: <0a5a01c2a820$416abfd0$640572d4@trustworks.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: Fri, 20 Dec 2002 08:39:01 -0800 To: "Valery Smyslov" , From: Paul Hoffman / VPNC Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:06 PM +0300 12/20/02, Valery Smyslov wrote: >draft suggests that no negotiation of LAM type is possible between client >and server: >server can just accept or reject LAM type that client proposed, and he has >no means >to indicate to client which LAM type he is willing to do. This can lead to >situation, >when client will have to perform up to 4 connection attempts with different >LAM types. >Not only will it delay the connection setup, but also it will put an >unnecessary load >to server - for each attempt he will have to do both DH and RSA/DSA. Er, do you really think that the client and server haven't agreed out of band which legacy auth mechanism they will do? In the real world, companies tell their users which auth mechanism they will use, and the information needed to do it. >I think better way to handle this situation is to allow server to change LAM >type >if he doesn't like what client proposed. This adds a lot of complexity for a usage model that no one seems to have. Am I wrong here? Do any of the VPN makers out there have customers who want to do legacy auth negotiation? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Dec 20 10:33:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKIX8o25131; Fri, 20 Dec 2002 10:33:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06745 Fri, 20 Dec 2002 13:02:02 -0500 (EST) Message-ID: <007701c2a852$061fd7d0$0bfd2ed4@trustworks.com> From: "Valery Smyslov" To: , "Paul Hoffman / VPNC" References: <0a5a01c2a820$416abfd0$640572d4@trustworks.com> Subject: Re: Secure legacy authentication for IKEv2 Date: Fri, 20 Dec 2002 21:02:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Paul Hoffman / VPNC" To: "Valery Smyslov" ; Sent: Friday, December 20, 2002 7:39 PM Subject: Re: Secure legacy authentication for IKEv2 > At 3:06 PM +0300 12/20/02, Valery Smyslov wrote: > >draft suggests that no negotiation of LAM type is possible between client > >and server: > >server can just accept or reject LAM type that client proposed, and he has > >no means > >to indicate to client which LAM type he is willing to do. This can lead to > >situation, > >when client will have to perform up to 4 connection attempts with different > >LAM types. > >Not only will it delay the connection setup, but also it will put an > >unnecessary load > >to server - for each attempt he will have to do both DH and RSA/DSA. > > Er, do you really think that the client and server haven't agreed out > of band which legacy auth mechanism they will do? In the real world, > companies tell their users which auth mechanism they will use, and > the information needed to do it. I've been thinking of situation when company upgrades its legathy auth from one type to another (i.e. from passwords to SecurID). This will not happen overnight, so a transition period will take place. During such period both types will be in use. > >I think better way to handle this situation is to allow server to change LAM > >type > >if he doesn't like what client proposed. > > This adds a lot of complexity for a usage model that no one seems to > have. Am I wrong here? Do any of the VPN makers out there have > customers who want to do legacy auth negotiation? It will add some complexity to the protocol, but it will reduce client configuration complexity. Currently, both XAUTH and Hybrid are designed so, that client plays a passive role in legacy auth process (with an exception that she must indicate to server that she can and will do legacy auth). It is server who decides what type of legacy auth will take place and what attributes are needed. Client just displays corresponding prompts to user and sends back reply to server. This allow client to be configurationless with this regard. In your proposal client plays more active role in the process. Therefore, either client needs to be preconfigured, or should use "try-and-catch" technique. The first alternative adds configuration complexity (espeshially during transition period), the second delays connection setup and puts an extra load to server. Anyway, I'm not very happy with both. > --Paul Hoffman, Director > --VPN Consortium Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Fri Dec 20 10:51:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKIp0o27256; Fri, 20 Dec 2002 10:51:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06968 Fri, 20 Dec 2002 13:23:20 -0500 (EST) Date: Fri, 20 Dec 2002 11:23:00 -0700 Message-Id: <200212201823.gBKIN0d09395@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: mleech@nortelnetworks.com Cc: housley@vigilsec.com, ipsec@lists.tislabs.com In-reply-to: Yourmessage <3E033457.1EDA4831@nortelnetworks.com> Subject: Re: speaking of keys Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You get about 8 bits of extra strength going from 1024 to 1280. You get about 17 bits going from 1024 to 1536. It is ridiculous to consider 1024 for a protocol that will exchange billions of keys over the next several years. Hilarie > > > > The draft NIST guidelines do not offer an recommendations on values between > > 1024 and 2048. However, some interpolation is possible. I think that we > > should consider 1280 and 1536. > > > > Russ > Actually, 1280 was one of the values I had thought of, but I don't have > a good intuitive feel for how much stronger it is than 1024. From owner-ipsec@lists.tislabs.com Fri Dec 20 13:29:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKLTTo05789; Fri, 20 Dec 2002 13:29:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08403 Fri, 20 Dec 2002 15:52:01 -0500 (EST) Message-Id: <200212202052.gBKKqYqF005808@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: speaking of keys In-reply-to: Your message of "Thu, 19 Dec 2002 17:18:37 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 20 Dec 2002 15:52:34 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> I don't think we need an API here, although that might be nice long Stephen> term. What we need is a set if MUSTs in IKE v2 that mandate the Well, it is 2002, had you said "long term" in 1995, I'd agree. I think that we have arrived where we need to be. Stephen> provision of (local?) management controls over the specification of Stephen> DH groups, not just the ones already specified. We have provisions in Stephen> IKE for passing group parameters, but I have been told that they are Stephen> not generally supported, and thus rarely if ever used. For my Stephen> purposes, I would be happy with a way for a community to specify the Stephen> parameters and inserts them into all of the community members' Stephen> systems via a management interface, and then use a locally managed Stephen> (but globally unique) ID, e.g., an OID, to refer to the parameters. That's a lot of words that you want to use instead of the words "API"! Remember that we got into this discussion because some people feel that DH groups larger than 1024 might be "too slow" for their application. Right now, this is up to the admins of the gateway boxes. As we move towards host IPsec (I run a *LOT* of /32<->/32 tunnels now), it becomes more and more necessary for applications to be able specify what they want. The details - like you need 1535 bit DH groups to properly key AES-128, is *NOT* something I want the applications people to concern themselves with. (by this, I mean those people in WGs that fall into "APP" categories. They want to be able to say "Just use IPsec", and we want them to, but we probably need them to say IPsec(X,Y,Z) and definitions of X,Y,Z should be as simple as possible) Stephen> However, I realize that this would not be supportive of the Stephen> opportunistic encryption model you have proposed, so maybe this Stephen> approach is not sufficient for all. Remember that there are three issues here, that are very seperate. 1) what is the MUST in the document. 2) how does an application that wants deviate from the norm indicate this to IKE? 3) how does an administrator that wants to deviate from the norm indicate this in their management interface. You want #3, that's fine. You need to first define this common management interface --- sounds like IPSP work to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgOCsIqHRg3pndX9AQEldwQAtC/3nRGKkPjo6Yb0Lcgf+0e28BkRQOJi M0Cga72bGkj/cPEnx2E/OrpWswV4Jh5n7etXWd0Xo9W+hhw6S6n4IhbJ4W5XoPK+ 5LTt7xD4yQSIkcwhNzhyX/+90rLH6sB/iYYc2AMUTFUiwKoZ/PpTGW53kgRMtgg2 Rn5C08LF1QU= =rw1N -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Dec 20 13:29:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKLTTo05788; Fri, 20 Dec 2002 13:29:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08385 Fri, 20 Dec 2002 15:50:58 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Secure legacy authentication for IKEv2 Date: Fri, 20 Dec 2002 12:52:33 -0800 Message-ID: Thread-Topic: Secure legacy authentication for IKEv2 Thread-Index: AcKoU6eKxkcLYnZDTmiMRmFxuaTxJAAFFq8w From: "William Dixon" To: "Valery Smyslov" , , "Paul Hoffman / VPNC" Cc: "Bernard Aboba" X-OriginalArrivalTime: 20 Dec 2002 20:52:35.0157 (UTC) FILETIME=[B92D2050:01C2A869] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA08379 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC ? It seems you are re-inventing EAP types here. For every new or different auth method type, you'd have to define a new one in the IKEv2 spec. -----Original Message----- From: Valery Smyslov [mailto:svan@trustworks.com] Sent: Friday, December 20, 2002 10:03 AM To: ipsec@lists.tislabs.com; Paul Hoffman / VPNC Subject: Re: Secure legacy authentication for IKEv2 ----- Original Message ----- From: "Paul Hoffman / VPNC" To: "Valery Smyslov" ; Sent: Friday, December 20, 2002 7:39 PM Subject: Re: Secure legacy authentication for IKEv2 > At 3:06 PM +0300 12/20/02, Valery Smyslov wrote: > >draft suggests that no negotiation of LAM type is possible between > >client and server: server can just accept or reject LAM type that > >client proposed, and he has > >no means > >to indicate to client which LAM type he is willing to do. This can > >lead to > >situation, > >when client will have to perform up to 4 connection attempts with different > >LAM types. > >Not only will it delay the connection setup, but also it will put an > >unnecessary load to server - for each attempt he will have to do both > >DH and RSA/DSA. > > Er, do you really think that the client and server haven't agreed out > of band which legacy auth mechanism they will do? In the real world, > companies tell their users which auth mechanism they will use, and the > information needed to do it. I've been thinking of situation when company upgrades its legathy auth from one type to another (i.e. from passwords to SecurID). This will not happen overnight, so a transition period will take place. During such period both types will be in use. > >I think better way to handle this situation is to allow server to > >change LAM > >type > >if he doesn't like what client proposed. > > This adds a lot of complexity for a usage model that no one seems to > have. Am I wrong here? Do any of the VPN makers out there have > customers who want to do legacy auth negotiation? It will add some complexity to the protocol, but it will reduce client configuration complexity. Currently, both XAUTH and Hybrid are designed so, that client plays a passive role in legacy auth process (with an exception that she must indicate to server that she can and will do legacy auth). It is server who decides what type of legacy auth will take place and what attributes are needed. Client just displays corresponding prompts to user and sends back reply to server. This allow client to be configurationless with this regard. In your proposal client plays more active role in the process. Therefore, either client needs to be preconfigured, or should use "try-and-catch" technique. The first alternative adds configuration complexity (espeshially during transition period), the second delays connection setup and puts an extra load to server. Anyway, I'm not very happy with both. > --Paul Hoffman, Director > --VPN Consortium Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Fri Dec 20 13:33:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKLXFo05879; Fri, 20 Dec 2002 13:33:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08521 Fri, 20 Dec 2002 16:03:14 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C6AD@corpmx14.us.dg.com> To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: IKEv2 transport concerns Date: Fri, 20 Dec 2002 16:03:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Steve, > > > >Would you be amenable to an approach based on a small draft that > >contains just the tunnel encapsulation/decapsulation material needed > >to specify ECN handling for tunnel-mode SAs? That could be put > >together in short enough order to allow IKEv2 to use a "MUST" to > >reference it without delaying IKEv2. When 2401bis is ready, it > >would obsolete both the new small tunnel draft and 2401 itself, > >so that the requirement winds up in the right place. I'll sign > >up to write the small ECN handling draft on a schedule that won't > >hold up IKEv2. > > > >If 2401bis gets done faster than expected, the new small ECN handling > >draft could vanish without a trace, having served its purposes > >of preventing 2401-classic tunnel (mis)handling of ECN in SAs set up > >by IKEv2, and allowing us to leave the IKEv1 ECN negotiation > >kludge on the scrap heap where it belongs. > > > >Thanks, > >--David > > David, > > I'm in favor of keeping the ECN processing separate from IKE v2, so > to that extent the separate draft sounds good. However, I would like > to be reminded of the reason for having a reference to the separate > draft in IKE v2. > > Steve Steve, The goal here is that any use of IKEv2 to negotiate a tunnel-mode SA (or UDP-encapsulated tunnel-mode SA for NAT traversal) carry an implied promise that ECN will be supported and handled correctly for that tunnel. This avoids any need for IKEv2 to negotiate/report/etc. ECN handling, in contrast to IKEv1 where a negotiable SA attribute and some other stuff was necessary to deal with the installed base (see Section 9.2 of RFC 3168 and its subsections for details). I like this sort of simple solution, and it fits with IKEv2's goal of simplifying negotiation, but for this solution to work, it has to be required of implementations before any IKEv2 installed base has a chance to develop, otherwise we wind up back in the IKEv1 situation of having to ask whether the other end of the SA supports ECN correctly or not and be prepared to behave differently depending on the answer. Not having to ask seems preferable. An alternative would be to put a normative reference to 2401bis into the IKEv2 draft, although that may not be consistent with the intended time schedules of the two drafts. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Dec 20 14:36:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKMa8o13313; Fri, 20 Dec 2002 14:36:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09185 Fri, 20 Dec 2002 17:07:05 -0500 (EST) Date: Fri, 20 Dec 2002 15:09:33 -0700 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Valery Smyslov" , , "Paul Hoffman / VPNC" , "Bernard Aboba" To: "William Dixon" From: Derrell Piper In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William, I view using EAP within IKEv2's legacy authentication as problematic for several reasons, here's why... First, an initial proposal for SLA did try to use EAP but it was pointed out that doing so opened up the protocol to a so-called authentication binding attack. Fixing this is certainly possible, by mixing the keying derivations of EAP with IKEv2, but the cost is additional complexity and a somewhat gross laying violation. Second, I think there's value to having legacy authentication be self-contained in the IKEv2 specification and not require IKEv2 implementations to also have to take on EAP. This adds a rather gnarly dependency with respect to security assurance. Any multi-headed authentication protocol is clearly more complex than a self-contained protocol. Given that the overriding goal for IKEv2 was eliminating complexity and ensuring interoperability, adding EAP to IKE solely for legacy authentication doesn't seem like a step in the right direction. Regarding extensibility claims, SLA is intended to secure existing legacy authentication. Arguments about future extensibility that you might get if you used EAP don't do much for me. Many of the proposed EAP authentication extensions in fact have no relevance to legacy authentication for VPN's. I don't anticipate having to add to the defined LAM types. The four defined types have been fleshed out over several years of real world VPN demand. A third reason is that EAP (as I understand it) does not allow for the client (initiator) to send either a username/password or username/pin-code combo in message three. Instead, EAP requires that only the username be sent in message three. This adds an extra message for what many of us consider the common case: where the LAM type is password or SecurID. The SLA protocol instead allows the client to send them together. Regards, Derrell On Friday, December 20, 2002, at 01:52 PM, William Dixon wrote: > Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC > ? It seems you are re-inventing EAP types here. For every new or > different auth method type, you'd have to define a new one in the IKEv2 > spec. > > -----Original Message----- > From: Valery Smyslov [mailto:svan@trustworks.com] > Sent: Friday, December 20, 2002 10:03 AM > To: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > Subject: Re: Secure legacy authentication for IKEv2 > > > ----- Original Message ----- > From: "Paul Hoffman / VPNC" > To: "Valery Smyslov" ; > Sent: Friday, December 20, 2002 7:39 PM > Subject: Re: Secure legacy authentication for IKEv2 > > >> At 3:06 PM +0300 12/20/02, Valery Smyslov wrote: >>> draft suggests that no negotiation of LAM type is possible between >>> client and server: server can just accept or reject LAM type that >>> client proposed, and he > has >>> no means >>> to indicate to client which LAM type he is willing to do. This can >>> lead > to >>> situation, >>> when client will have to perform up to 4 connection attempts with > different >>> LAM types. >>> Not only will it delay the connection setup, but also it will put an >>> unnecessary load to server - for each attempt he will have to do both > >>> DH and RSA/DSA. >> >> Er, do you really think that the client and server haven't agreed out >> of band which legacy auth mechanism they will do? In the real world, >> companies tell their users which auth mechanism they will use, and the > >> information needed to do it. > > I've been thinking of situation when company upgrades its legathy auth > from one type to another (i.e. from passwords to SecurID). This will > not > happen overnight, so a transition period will take place. During such > period both types will be in use. > >>> I think better way to handle this situation is to allow server to >>> change > LAM >>> type >>> if he doesn't like what client proposed. >> >> This adds a lot of complexity for a usage model that no one seems to >> have. Am I wrong here? Do any of the VPN makers out there have >> customers who want to do legacy auth negotiation? > > It will add some complexity to the protocol, but it will reduce client > configuration complexity. Currently, both XAUTH and Hybrid are designed > so, that client plays a passive role in legacy auth process (with an > exception that she must indicate to server that she can and will do > legacy auth). It is server who decides what type of legacy auth will > take place and what attributes are needed. Client just displays > corresponding prompts to user and sends back reply to server. This > allow > client to be configurationless with this regard. In your proposal > client > plays more active role in the process. Therefore, either client needs > to > be preconfigured, or should use "try-and-catch" technique. The first > alternative adds configuration complexity (espeshially during > transition > period), the second delays connection setup and puts an extra load to > server. Anyway, I'm not very happy with both. > >> --Paul Hoffman, Director >> --VPN Consortium > > Regards, > Valery Smyslov. > From owner-ipsec@lists.tislabs.com Fri Dec 20 14:43:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKMhFo13596; Fri, 20 Dec 2002 14:43:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09295 Fri, 20 Dec 2002 17:16:09 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 20 Dec 2002 14:17:12 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:52 PM -0800 12/20/02, William Dixon wrote: >Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC >? It seems you are re-inventing EAP types here. For every new or >different auth method type, you'd have to define a new one in the IKEv2 >spec. If we used EAP, we would be susceptible to the man-in-the-middle attack described at . The "EAP and EAP-like problem" is being discussed in many places, and is one of the things that is holding up PIC as well. Dan and Derrell decided that the danger of mis-use of EAP was more worrisome than the need for automatic extensibility. Note that SLA already covers all of the methods that are covered by XAUTH, and there haven't been any calls in a quite a while for new XAUTH methods. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Dec 20 14:58:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKMwDo13999; Fri, 20 Dec 2002 14:58:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09503 Fri, 20 Dec 2002 17:34:33 -0500 (EST) Message-Id: <200212202235.gBKMZ6Fw007195@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Summary of revised identity changes In-reply-to: Your message of "Thu, 19 Dec 2002 19:17:02 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 20 Dec 2002 17:35:06 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: >> By all means, make the contents of certificates clear. But, they aren't to >> be involved in the identities. Stephen> I can't understand this last sentence. When we use certs for Stephen> authentication in IKE, they should be used to convey the IDs that we Stephen> are asserting. If we use certs to authenticate IKE peers and these Stephen> have no relationship to the IDs we assert, then we have to have some Stephen> other mapping of the certs to the sets of IDs that they are Stephen> authorized to represent, and that mapping is another source of Absolutely correct, and no, you didn't misunderstand me. There is that other mapping, and it had better be there. I appreciate it is convenient, and less error-prone if it is a null operation for many. If I *have* to get the *contents* of the cert correct in order to use certificates at all, then that means that I can not, for instance, use the same certificate for multiple uses. While that may be the desired effect for people with real PKI infrastructure and real PKI clue, for the people who just want to connect two LANs with a VPN, a self-signed certificate generated by openssl is *just fine*. If they have to get right goop in place to use certificates, even more people will want to continue using pre-shared keys. Now, if you, instead, are willing to say: All implementations MUST support RAW RSA key formats, providing a way to load/save them interactively (i.e. in a UI or CLI) in RFC3110 format. Then, you can do whatever you want with certificates. But, up to this point, even doing self-signed X.509 (I wish they'd say "RFC2459" certificates) is hard for many products, and people therefore resort to pre-shared keys. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgObF4qHRg3pndX9AQHwPAP/U+cpeCPMnrMH/7/nSU7OgZYl3Ne/l/4Y qKTuQ7qXvaSc/f/pVSEVpcwAdoGjwrHsS0wSc0tTPv6cAXDSt4dDIIA77uuN76Qg b1EIvTNfwOY2BnE7B/0i8GnE8N+Pbau3KFjp0/q/GVhWt2VkyJfaA7SozXhRehst b80vxljbGWM= =g2EF -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Dec 20 15:10:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKNAOo14844; Fri, 20 Dec 2002 15:10:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09623 Fri, 20 Dec 2002 17:45:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> References: <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> Date: Fri, 20 Dec 2002 17:39:50 -0500 To: David Jablon From: Stephen Kent Subject: Re: Secure legacy authentication for IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:06 PM -0500 12/19/02, David Jablon wrote: >Perhaps "extensibility" should include the ability to take advantage >of keys generated by methods that use legacy credentials. >I've heard this referred (somewhat redundantly) as "future extensibility" >in other protocols. > >Although I didn't see this capability in the SLA draft, could it be added? > >-- David > Use of keys on what way? IKE v2 has introduced a clean separation of key material generation via DH exchange from authentication processes. I don't see how a legacy authentication system would contribute keys for IPsec, and I would rather not see it enter into the key generation process now that we have a clean separation. Steve From owner-ipsec@lists.tislabs.com Fri Dec 20 15:20:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKNKno16214; Fri, 20 Dec 2002 15:20:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09741 Fri, 20 Dec 2002 17:55:08 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212202052.gBKKqYqF005808@sandelman.ottawa.on.ca> References: <200212202052.gBKKqYqF005808@sandelman.ottawa.on.ca> Date: Fri, 20 Dec 2002 17:50:34 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: speaking of keys Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, > > Stephen> provision of (local?) management controls over the >specification of > Stephen> DH groups, not just the ones already specified. We have >provisions in > Stephen> IKE for passing group parameters, but I have been told >that they are > Stephen> not generally supported, and thus rarely if ever used. For my > Stephen> purposes, I would be happy with a way for a community >to specify the > Stephen> parameters and inserts them into all of the community members' > Stephen> systems via a management interface, and then use a >locally managed > Stephen> (but globally unique) ID, e.g., an OID, to refer to the >parameters. > > That's a lot of words that you want to use instead of the words "API"! > > Remember that we got into this discussion because some people feel that DH >groups larger than 1024 might be "too slow" for their application. Right now, >this is up to the admins of the gateway boxes. As we move towards host IPsec >(I run a *LOT* of /32<->/32 tunnels now), it becomes more and more necessary >for applications to be able specify what they want. An important feature of IPsec is that an administrator can impose security controls on traffic without having to rely on individual applications to be able to make these choices, and without having to worry that a Trojan Horse has tampered with an application to disable security controls. I agree that under some circumstances an application could make these choices, but there are lots of circumstances where this would delay use of Ipsec (because the apps are not security-aware) or could lead to vulnerabilities due to TH problems of the sort I mention. So, whole I am not opposed to work on an API for IPsec management, I do not believe it is a prerequisite for the sort of function I am suggesting, i.e., a local management capability to select (possibly private) DH groups. We can mandate such a capability for IPsec implementations without specifying HOW the capability is provided. Also, if you want to develop an API, that would not conflict with the mandate capability requirement. > The details - like you need 1535 bit DH groups to properly key AES-128, is >*NOT* something I want the applications people to concern themselves with. >(by this, I mean those people in WGs that fall into "APP" categories. They >want to be able to say "Just use IPsec", and we want them to, but we probably >need them to say IPsec(X,Y,Z) and definitions of X,Y,Z should be as simple as >possible) we agree on these points. > > Stephen> However, I realize that this would not be supportive of the > Stephen> opportunistic encryption model you have proposed, so maybe this > Stephen> approach is not sufficient for all. > > Remember that there are three issues here, that are very seperate. > > 1) what is the MUST in the document. > 2) how does an application that wants deviate from the norm indicate this > to IKE? > 3) how does an administrator that wants to deviate from the norm indicate > this in their management interface. > > You want #3, that's fine. You need to first define this common management >interface --- sounds like IPSP work to me. > I am not opposed to facilities that support #2, I just think they are less critical than #1 & #3, and, as I noted above, I am willing to reword my request to say that it would be satisfied by a suitable implementation of #2. For example, I assume that even if we have an API that apps can use to specify controls, that you would want some defaults and one way of configuring the defaults is via an administrator interface. Would that satisfy your goals? Steve From owner-ipsec@lists.tislabs.com Fri Dec 20 15:53:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKNrVo17539; Fri, 20 Dec 2002 15:53:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10030 Fri, 20 Dec 2002 18:21:45 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C6AD@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564C6AD@corpmx14.us.dg.com> Date: Fri, 20 Dec 2002 18:19:37 -0500 To: Black_David@emc.com From: Stephen Kent Subject: RE: IKEv2 transport concerns Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, >Steve, > >The goal here is that any use of IKEv2 to negotiate a tunnel-mode SA >(or UDP-encapsulated tunnel-mode SA for NAT traversal) carry an implied >promise that ECN will be supported and handled correctly for that >tunnel. This avoids any need for IKEv2 to negotiate/report/etc. >ECN handling, in contrast to IKEv1 where a negotiable SA attribute >and some other stuff was necessary to deal with the installed base >(see Section 9.2 of RFC 3168 and its subsections for details). > >I like this sort of simple solution, and it fits with IKEv2's goal of >simplifying negotiation, but for this solution to work, it has to be >required of implementations before any IKEv2 installed base has a >chance to develop, otherwise we wind up back in the IKEv1 situation >of having to ask whether the other end of the SA supports ECN correctly >or not and be prepared to behave differently depending on the answer. >Not having to ask seems preferable. > >An alternative would be to put a normative reference to 2401bis into the >IKEv2 draft, although that may not be consistent with the intended >time schedules of the two drafts. > >Thanks, >--David OK, I now understand the rationale for including a mention of this in IKE v2, because of the IKE v1 negotiation issue. I concur. Steve From owner-ipsec@lists.tislabs.com Fri Dec 20 15:56:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKNuCo17617; Fri, 20 Dec 2002 15:56:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10135 Fri, 20 Dec 2002 18:31:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212202235.gBKMZ6Fw007195@sandelman.ottawa.on.ca> References: <200212202235.gBKMZ6Fw007195@sandelman.ottawa.on.ca> Date: Fri, 20 Dec 2002 18:34:00 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: Summary of revised identity changes Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:35 PM -0500 12/20/02, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Stephen" == Stephen Kent writes: > >> By all means, make the contents of certificates clear. But, >they aren't to > >> be involved in the identities. > > Stephen> I can't understand this last sentence. When we use certs for > Stephen> authentication in IKE, they should be used to convey >the IDs that we > Stephen> are asserting. If we use certs to authenticate IKE >peers and these > Stephen> have no relationship to the IDs we assert, then we have >to have some > Stephen> other mapping of the certs to the sets of IDs that they are > Stephen> authorized to represent, and that mapping is another source of > > Absolutely correct, and no, you didn't misunderstand me. > > There is that other mapping, and it had better be there. I appreciate it is >convenient, and less error-prone if it is a null operation for many. > > If I *have* to get the *contents* of the cert correct in order to use >certificates at all, then that means that I can not, for instance, use the >same certificate for multiple uses. could you elaborate a bit. I can see some circumstances where this would be true, but I'm not sure how common the problem would be. for exmaple, a cert with my e-mail address is a perfectly fine user ID cert for IPsec, as well as for s/mime, and it might be OK for authenticating me in an SSL/TLS context as well. > While that may be the desired effect for people with real PKI >infrastructure and real PKI clue, for the people who just want to connect two >LANs with a VPN, a self-signed certificate generated by openssl is *just >fine*. > > If they have to get right goop in place to use certificates, even more >people will want to continue using pre-shared keys. > > Now, if you, instead, are willing to say: > > All implementations MUST support RAW RSA key formats, providing a > way to load/save them interactively (i.e. in a UI or CLI) in RFC3110 > format. > > Then, you can do whatever you want with certificates. But, up to this >point, even doing self-signed X.509 (I wish they'd say "RFC2459" >certificates) is hard for many products, and people therefore resort to >pre-shared keys. > I too don't want to promote use of pre-shared keys. But, if I have a RAW RSA format, what is the mechanism by which this identifies me? It is not one of the ID types supported by the SPD. If you're saying that we need another mapping table from key to ID, then I have the same concerns re getting this mapping wrong. Steve From owner-ipsec@lists.tislabs.com Fri Dec 20 16:20:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBL0KKo18402; Fri, 20 Dec 2002 16:20:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10335 Fri, 20 Dec 2002 18:47:26 -0500 (EST) Date: Fri, 20 Dec 2002 16:49:48 -0700 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "William Dixon" , "Valery Smyslov" , , "Paul Hoffman / VPNC" To: "Bernard Aboba" From: Derrell Piper In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bernard, I don't believe so because the server is fully authenticated by the client before the client needs to begin speaking the legacy authentication protocol and there's no way that a client can be induced to begin the legacy authentication without first authenticating the server. If the server authentication fails after message two, the client MUST immediately terminate the IKE exchange. (The client is presumed to be configured either with a set of trusted public keys or with a set of trusted root certificates.) You can't run just half of the exchange. For the binding attack (as I understand it) to be viable, an active attacker would have to bring up the SLA IKE tunnel through message two and then somehow induce someone to speak one of the legacy authentication methods to it. But for that to happen, the attacker would have to complete the first two messages with the intended victim and in doing so, the client would learn that the attacker wasn't trusted. (We were not concerned with trusted gateways impersonating each other.) So please say more... Derrell On Friday, December 20, 2002, at 03:48 PM, Bernard Aboba wrote: > Isn't the current version of SLA vulnerable to the same attack? I > don't see anywhere in the spec where a "binding" is carried out. In > fact, this would not be possible with the methods you're supporting, > because none of them generate keys. From owner-ipsec@lists.tislabs.com Fri Dec 20 16:57:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBL0vLo21125; Fri, 20 Dec 2002 16:57:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10781 Fri, 20 Dec 2002 19:29:20 -0500 (EST) Date: Sat, 21 Dec 2002 02:30:48 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: RE: Secure legacy authentication for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, What you wrote below regarding the man-in-the-middle attacks is incorrect. SLA with the use of "proprietary" payloads is susceptible to these attacks exactly as if it used EAP payloads. It is actually the other way around: these attacks may be a good reason to use EAP. See more specific coments below. On Fri, 20 Dec 2002, Paul Hoffman / VPNC wrote: > At 12:52 PM -0800 12/20/02, William Dixon wrote: > >Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC > >? It seems you are re-inventing EAP types here. For every new or > >different auth method type, you'd have to define a new one in the IKEv2 > >spec. > > If we used EAP, we would be susceptible to the man-in-the-middle > attack described at > . These attacks have nothing to do with EAP but with a mixed use of SAME authentication credentials in unprotected and tunnel-protected runs (such as the IKE-based tunnel that SLA would provide). I am not going to explain the attacks here but I want to point out that they are NOT due to EAP encapsulation. In particular, the CHRE encapsulation in SLA would be susceptible to the SAME attacks. In these attacks the attacker uses the unprotected run of the authentication to obtain from the user responses to server-generated challenges. Once the attacker obtains these responses from the legitimate user it can go on and encapsulate these responses in CHRE payloads and complete his man-in-the-middle atack against SLA. For those interested in this type of attacks see the above mentioned draft and also the paper "Man-in-the-Middle in Tunnelled Authentication Protocols" by N. Asokan and Valtteri Niemi and Kaisa Nyberg http://eprint.iacr.org/2002/163/ > The "EAP and EAP-like problem" is being discussed in many places, and > is one of the things that is holding up PIC as well. If that is a reason to hold up PIC then for the same reason you'll have to hold up SLA. I suggest not to hold up any of these protocols on the basis of these attacks (rather have clear language regarding the reasons for these attacks and the essentially-limited scope of possible solutions). It is up to the "legacy authentication" community to come up with solutions to these problems (which arise from the essentially-insecure use of credentials in mixed protected/unprotected environments). Moreover, if you support EAP exchanges and the EAP community comes up with measures to alleviate these attacks in the context of EAP then you get the benefits of this solution automatically. If you do CHRE then you don't. That's a good reason to support EAP in SLA. And it is not the only benefit: There is a lot of deployment of EAP and the definition of authentication mechanisms over EAP can be (and is) done independently of IKE. In my view, it is better to leave these definitions in the hands of people (such as the EAP WG) that specifically care about transport of client authentication. If you rely on EAP then all you have to care about is to build a sound tunneling mechanism for EAP in the context of IKEv2 (rather than bulding profiles that depend on the specifics of secure-id, radius, etc.) And, as said, the EAP guys are better suited to take care of problems in the "legacy authentication" world such as the above "man in the middle attacks" against tunneled authentication that have been a concern lately in this community. And adopting EAP into SLA is easy, just copy PIC. > > Dan and Derrell decided that the danger of mis-use of EAP was more > worrisome than the need for automatic extensibility. Note that SLA > already covers all of the methods that are covered by XAUTH, and > there haven't been any calls in a quite a while for new XAUTH methods. SInce this decision is justified on the basis of a wrong assumption (i.e. that the mitm atacks work against EAP and not SLA) then this whole conclusion needs to be revised as suggested above. Hugo > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Fri Dec 20 17:05:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBL15No21249; Fri, 20 Dec 2002 17:05:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10908 Fri, 20 Dec 2002 19:40:28 -0500 (EST) Date: Sat, 21 Dec 2002 02:42:12 +0200 (IST) From: Hugo Krawczyk To: Derrell Piper cc: Bernard Aboba , William Dixon , Valery Smyslov , ipsec@lists.tislabs.com, Paul Hoffman / VPNC Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > For the binding attack (as I understand it) to be viable, an active > attacker would have to bring up the SLA IKE tunnel through message two > and then somehow induce someone to speak one of the legacy > authentication methods to it. But for that to happen, the attacker > would have to complete the first two messages with the intended victim > and in doing so, the client would learn that the attacker wasn't > trusted. (We were not concerned with trusted gateways impersonating > each other.) In these attacks the attacker (a) impersonates the server to the client in the unprotected run (we are talking of legacy authentication methods that do NOT authenticate the server so this impersonation is possible) (b) impersonates the client to the server in the protected run (SLA, PIC, etc) using the responses that it gets from the client in the impersonated unprotected run (a). But again see the mentioned documents for a full undertsanding of these attacks, their independence from EAP, and applicabilty to SLA (in particular, the fact that SLA requires server authentication does not help against the attacks). Hugo > > So please say more... > > Derrell > > On Friday, December 20, 2002, at 03:48 PM, Bernard Aboba wrote: > > > Isn't the current version of SLA vulnerable to the same attack? I > > don't see anywhere in the spec where a "binding" is carried out. In > > fact, this would not be possible with the methods you're supporting, > > because none of them generate keys. > > From owner-ipsec@lists.tislabs.com Fri Dec 20 17:24:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBL1Odo21490; Fri, 20 Dec 2002 17:24:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11113 Fri, 20 Dec 2002 19:59:50 -0500 (EST) Date: Sat, 21 Dec 2002 03:02:03 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After seeing the SLA proposal I want to propose the (controversial and not necessarily popular) idea that this mechanism is separated to a different document. If possible I would also move the configuration mechanism defined in Dukes document to be part of that separate document whose subject would be "standarized support of remote user authentication for IKEv2". (If there are significant applications of the configuration mechanisms in more general situations than remote user access then one may want to leave the configuration mechanisms as part of the basic IKEv2). The reason for the separation (at least of SLA) are: (1) the mechanisms add very significant complexity to the basic IKEv2 document (complexity in terms of specifications, understanding, evaluation, analysis, implementation and testing). This is particularly true with SLA which (as I pointed out in a previous note) changes the basic IKEv2 exchange significantly (both its logic and processing). (2) While there is a clear market demand for user legacy authentication support in IKE it is not clear at all that all applications of IKE will require such support. Thus, it is not clear that this mode (and all its inherent complexity) needs to be mandated for all IKEv2 implementations. Moreover, I can envision that many (future) implementations, even if mandated to support legacy authentication, will opt to prevent its use completely (this mode of authentication may easily become the weakest link in the protocol). (3) Separating SLA (and maybe config) into a separate document has does not jeopardize standardization. There is no reason not to advance both documents (IKEv2 and remote-access concurrently). The remote user standard will be implemented by those that care about it. Since today's ipsec market is dominated by VPN then we will see that most (probably all) vendors that offer general implementations of ipsec/ike (and, in particular, VPN) will include the remote access capability. The advantage of developing IKEv2 and remote access together is that this joint development may point out to extensibility mechanisms that IKEv2 may need to provide in order for SLA to be able to support remote access. But this does not mean that the added mechanisms need to be part of the basic IKE (v2). Just to illustrate the problems of making SLA part of IKEv2 let me point out to an argument against using EAP in the context of SLA that was given in a previous message. It was claimed that adding EAP to SLA would require all implementations of IKE to implement EAP. But then why should ALL implementation of IKE be required to implement all the remote-access and legacy-authentication payloads and the sepcial authentication mode?? If, in contrast, SLA implementation would be required only for those providing remote user access, then implementing EAP would be a natural thing to require given that EAP is today's most general IETF-standarized mechanissm for transporting user (and legacy) authentication information. Bottom line: I suggest to (a) separate SLA to another document; (b) develop IKEv2 and SLA at the same time (i.e. now); (c) advance the separate documents for standardization concurrently; (d) do NOT make SLA a mandatory mode of IKEv2. Hugo From owner-ipsec@lists.tislabs.com Fri Dec 20 17:33:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBL1Xmo21819; Fri, 20 Dec 2002 17:33:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11300 Fri, 20 Dec 2002 20:10:12 -0500 (EST) Date: Sat, 21 Dec 2002 03:12:02 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: IPsec WG , ietf-mode-cfg@vpnc.org Subject: RE: Proposed Configuration payload for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 19 Dec 2002, Paul Hoffman / VPNC wrote: > At 4:58 AM +0200 12/20/02, Hugo Krawczyk wrote: > >You have to be very careful when you change the cryptographic logic in > >IKEv2. Is the protocol you are proposing still secure? > > Somehow, we thought that *you* might answer that question. :-) I thought that the burden of proof should be on the proponent... In any case I was not referring to the man-in-the-middle attacks that we are discussing in a parallel threat and which are based on the bad practice of using same credentials in protected and unprotected runs. Here I am talking about weaknesses in the cryptographic logic of the SLA protocol. But since there is enough traffic regarding the other MitM attacks (and it is late) I prefer to postpone this issue for next week. The bottom line is that the cryptography of SLA is open to attacks against the "consistency" (or "mutual belief") requirement for authenticated key exchanges (see, for example, my SIGMA paper). Yet, since SLA is specifically intended for use in the client-server model of legacy authentication the practical significance of the *specific* attacks that I can see is questionable. Still I believe that these weaknesses will have to be repaired (at least to avoid the publication of crypto papers that break the protocol :). I will write more about this next week. Hugo > > >It seems to me, at least at first glance, that the protocol may be open to > >some form of man-in-the-middle attack (or more precisely, "server in the > >middle"). Have you checked that? > > As I understand it, the server-in-the-middle attack that has been > discussed this last month requires that the messages being passed in > the IPsec remote access protocol have the same format as the messages > being passed in the legacy authentication protocol. If that is a > correct understanding, then it seems like we aren't susceptible to it > because we have our own message format for CHRE payloads. > > >At the functional (and security) level the identity of the server (and/or > >its certificate) seems to be missing in message 2. Is this just an > >overlook, or is it deliberate? In any case I would not like to assume that > >the client always has this cert in advance or that there is a single PK > >with which the server's signature is to be verified. Note that there may > >be, in principle, more than one server answering the client's request. > > The model we assumed was that the initiator knew the identity of the > responder. You are correct, there might be a pool of responders. We > could certainly add a certificate in message 2 for that. As per the > discussion earlier this year, in the remote access case, it is fine > to expose the identity of the responder to passive snooping if it is > a remote access server. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Sat Dec 21 00:29:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBL8T4o22533; Sat, 21 Dec 2002 00:29:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA15266 Sat, 21 Dec 2002 02:56:11 -0500 (EST) Subject: Re: Secure legacy authentication for IKEv2 From: Steve Dispensa To: ipsec@lists.tislabs.com In-Reply-To: <007701c2a852$061fd7d0$0bfd2ed4@trustworks.com> References: <0a5a01c2a820$416abfd0$640572d4@trustworks.com> <007701c2a852$061fd7d0$0bfd2ed4@trustworks.com> Content-Type: text/plain Organization: Positive Networks Message-Id: <1040457295.2283.73.camel@stratocaster.positivenetworks.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 21 Dec 2002 01:54:55 -0600 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 2002-12-20 at 12:02, Valery Smyslov wrote: > > Er, do you really think that the client and server haven't agreed out > > of band which legacy auth mechanism they will do? In the real world, > > companies tell their users which auth mechanism they will use, and > > the information needed to do it. > > I've been thinking of situation when company upgrades its legathy auth > from one type to another (i.e. from passwords to SecurID). This will > not happen overnight, so a transition period will take place. During such > period both types will be in use. There are other situations where pre-agreement is inconvenient as well. I run IPSec in a service provider environment in which we connect N remote users to M target networks. Any N can connect to any M, and each M network is free to specify its preferred auth type, including in particular SecurID and username/password. Out-of-band agreement can be done (and we're running custom/inconvenient/dubiously secure i fear) code to do it, but it would be much more convenient for my implementation if it were part of the protocol. [BTW, since i've never posted here before] I'm the CTO of a VPN-based remote access service provider. We hook remote workers to corporate networks via our hardware, and we add a few value-added services to the mix. We've been in {beta|production} operation for about 18 months. The challenges of this architecture inspired me to join this mail list a while ago to keep tabs on progress... perhaps I can make some contribution from the perspective of an operator as well. -sd From owner-ipsec@lists.tislabs.com Sat Dec 21 08:42:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBLGgMo01426; Sat, 21 Dec 2002 08:42:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19936 Sat, 21 Dec 2002 11:15:04 -0500 (EST) Date: Sat, 21 Dec 2002 09:17:50 -0700 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Bernard Aboba , William Dixon , Valery Smyslov , ipsec@lists.tislabs.com, Paul Hoffman / VPNC To: Hugo Krawczyk From: Derrell Piper In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Friday, December 20, 2002, at 05:42 PM, Hugo Krawczyk wrote: >> For the binding attack (as I understand it) to be viable, an active >> attacker would have to bring up the SLA IKE tunnel through message two >> and then somehow induce someone to speak one of the legacy >> authentication methods to it. But for that to happen, the attacker >> would have to complete the first two messages with the intended victim >> and in doing so, the client would learn that the attacker wasn't >> trusted. (We were not concerned with trusted gateways impersonating >> each other.) > > In these attacks the attacker > > (a) impersonates the server to the client in the unprotected run (we > are > talking of legacy authentication methods that do NOT authenticate the > server so this impersonation is possible) > > (b) impersonates the client to the server in the protected run (SLA, > PIC, etc) using the responses that it gets from the client in the > impersonated unprotected run (a). > > But again see the mentioned documents for a full understanding of these > attacks, their independence from EAP, and applicability to SLA (in > particular, the fact that SLA requires server authentication does not > help against the attacks). > > Hugo Hugo, Thanks for the pointer to the NRC paper. Between it and I now have a good understanding of the particular MitM attack we're discussing. Further I now see that the distinction between using EAP vs. SLA (with its CHRE) is irrelevant with respect to this. We agree that this attack requires that: 1) the authentication protocol that's run in the tunnel also be run outside of the tunnel (i.e. unprotected) 2) an attacker is somehow able to lure clients into running the unprotected legacy authentication against him For SLA, we assumed that the legacy authentication methods that we're talking about tunneling are in use only back on the corporate network, not across the Internet. We assumed that the corporate network is appropriately isolated (behind a firewall) from the Internet and blocks nearly everything. It's our belief that that's the usual configuration for deployed IPSec VPN gateways today, which are increasingly hosted on (or built into) the firewall itself. Given these assumptions, clients aren't running the legacy authentication protocols anywhere outside of SLA because there's nothing to talk to (it's all blocked at the firewall). Perhaps the salient point is that these assumptions and their implications on the security of the protocol do need to be clearly stated. I'm guessing you might agree with this because in another later email you wrote: "I suggest not to hold up any of these protocols on the basis of these attacks (rather have clear language regarding the reasons for these attacks and the essentially-limited scope of possible solutions)." If we're on the same page, then it seems to me what's interesting to talk about as a group is whether or not these assumptions are realistic for our to-be-deployed IPSec remote client protocol. If we are indeed worried that the legacy authentication methods are today in use across the Internet then we've got more work to do. Derrell From owner-ipsec@lists.tislabs.com Sat Dec 21 08:53:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBLGrWo02204; Sat, 21 Dec 2002 08:53:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20099 Sat, 21 Dec 2002 11:32:13 -0500 (EST) Date: Sat, 21 Dec 2002 09:33:58 -0700 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: IPsec WG To: Hugo Krawczyk From: Derrell Piper In-Reply-To: Message-Id: <0152BA0D-1502-11D7-9FFC-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Fair enough. I strongly support (d), BTW. I think it's essential to see an SLA defined, but it should not be made mandatory to implement. I can see arguments both for and against having SLA be in a separate document. Whether (a) occurs is not as important to me as making sure that (b) and (c) happen and happen soon. Derrell On Friday, December 20, 2002, at 06:02 PM, Hugo Krawczyk wrote: > Just to illustrate the problems of making SLA part of IKEv2 let me > point out to > an argument against using EAP in the context of SLA that was given in a > previous message. It was claimed that adding EAP to SLA would > require all implementations of IKE to implement EAP. But then why > should ALL > implementation of IKE be required to implement all the remote-access > and legacy-authentication payloads and the sepcial authentication > mode?? > If, in contrast, SLA implementation would be required only for > those providing remote user access, then implementing EAP would be > a natural thing to require given that EAP is today's most general > IETF-standarized mechanissm for transporting user (and legacy) > authentication > information. > > Bottom line: I suggest to > (a) separate SLA to another document; > (b) develop IKEv2 and SLA at the same time (i.e. now); > (c) advance the separate documents for standardization concurrently; > (d) do NOT make SLA a mandatory mode of IKEv2. From owner-ipsec@lists.tislabs.com Sat Dec 21 10:19:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBLIJvo05223; Sat, 21 Dec 2002 10:19:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20948 Sat, 21 Dec 2002 12:55:58 -0500 (EST) From: "Yaron Sheffer" To: "Derrell Piper" , "Hugo Krawczyk" Cc: "Bernard Aboba" , "William Dixon" , "Valery Smyslov" , , "Paul Hoffman / VPNC" Subject: RE: Secure legacy authentication for IKEv2 Date: Sat, 21 Dec 2002 19:56:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Derrell, the original reason why EAP was implicated in this attack in the context of PIC is that people are using EAP to authenticate to wireless-LAN hot spots (access points) outside the corporate boundary, e.g. in airports. And people are using the same password there as they do inside the corporate boundary, even though everybody tells them not to. Also, I'd like to request that you reconsider using EAP for SLA. EAP is probably already more widely deployed than XAUTH, and I don't think this is about to change. And it's a very lightweight protocol, too. Regards, Yaron -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper Sent: Saturday, December 21, 2002 6:18 PM To: Hugo Krawczyk Cc: Bernard Aboba; William Dixon; Valery Smyslov; ipsec@lists.tislabs.com; Paul Hoffman / VPNC Subject: Re: Secure legacy authentication for IKEv2 On Friday, December 20, 2002, at 05:42 PM, Hugo Krawczyk wrote: >> For the binding attack (as I understand it) to be viable, an active >> attacker would have to bring up the SLA IKE tunnel through message two >> and then somehow induce someone to speak one of the legacy >> authentication methods to it. But for that to happen, the attacker >> would have to complete the first two messages with the intended victim >> and in doing so, the client would learn that the attacker wasn't >> trusted. (We were not concerned with trusted gateways impersonating >> each other.) > > In these attacks the attacker > > (a) impersonates the server to the client in the unprotected run (we > are > talking of legacy authentication methods that do NOT authenticate the > server so this impersonation is possible) > > (b) impersonates the client to the server in the protected run (SLA, > PIC, etc) using the responses that it gets from the client in the > impersonated unprotected run (a). > > But again see the mentioned documents for a full understanding of these > attacks, their independence from EAP, and applicability to SLA (in > particular, the fact that SLA requires server authentication does not > help against the attacks). > > Hugo Hugo, Thanks for the pointer to the NRC paper. Between it and I now have a good understanding of the particular MitM attack we're discussing. Further I now see that the distinction between using EAP vs. SLA (with its CHRE) is irrelevant with respect to this. We agree that this attack requires that: 1) the authentication protocol that's run in the tunnel also be run outside of the tunnel (i.e. unprotected) 2) an attacker is somehow able to lure clients into running the unprotected legacy authentication against him For SLA, we assumed that the legacy authentication methods that we're talking about tunneling are in use only back on the corporate network, not across the Internet. We assumed that the corporate network is appropriately isolated (behind a firewall) from the Internet and blocks nearly everything. It's our belief that that's the usual configuration for deployed IPSec VPN gateways today, which are increasingly hosted on (or built into) the firewall itself. Given these assumptions, clients aren't running the legacy authentication protocols anywhere outside of SLA because there's nothing to talk to (it's all blocked at the firewall). Perhaps the salient point is that these assumptions and their implications on the security of the protocol do need to be clearly stated. I'm guessing you might agree with this because in another later email you wrote: "I suggest not to hold up any of these protocols on the basis of these attacks (rather have clear language regarding the reasons for these attacks and the essentially-limited scope of possible solutions)." If we're on the same page, then it seems to me what's interesting to talk about as a group is whether or not these assumptions are realistic for our to-be-deployed IPSec remote client protocol. If we are indeed worried that the legacy authentication methods are today in use across the Internet then we've got more work to do. Derrell From owner-ipsec@lists.tislabs.com Sat Dec 21 11:24:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBLJOJo11585; Sat, 21 Dec 2002 11:24:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21576 Sat, 21 Dec 2002 14:00:27 -0500 (EST) Date: Sat, 21 Dec 2002 12:02:29 -0700 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com To: Hugo Krawczyk From: Derrell Piper In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, I think I was the main opponent to using EAP, but I'm willing to concede this point if it helps get us to consensus. I see now that using EAP is cryptographically no worse than what we proposed with SLA (see other thread) and you make some good arguments here for its adoption (as do others). Note that SLA proposed a strict client-directed authentication exchange. For each client request, the server's response either completed the exchange or contained an additional challenge. The SLA protocol did not allow for negotiation of the LAM type (without restarting the exchange). This was chosen primarily so that the client could aggressively send his credentials in message three. RFC2284 (EAP) instead implements a request/response protocol run by the responder ("authenticator" in RFC2284) and allows for flexibility in authentication type negotiation (the client can "nak" the requested type and request something else). So here's a fairly straightforward substitution of EAP for CHRE in SLA: We'll need to define an EAP payload: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ EAP Packet ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Critical Bit MUST be set in all EAP payloads. The EAP Packet and its contents are defined in RFC2284. The first two messages remain almost the same as for SLA. The response from the gateway now also includes the EAP identity request and begins the EAP protocol. Note that this is only a request; identity protection for the client is not compromised if the server authentication fails. Initiator (client) Responder (gateway) ------------------ ------------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, EAP(Request/Identity), AUTH The responder's AUTH payload is computed over all of message one concatenated with all of message two. Because the contents of the AUTH payload cannot be known when creating the concatenation, a dummy AUTH payload is constructed which consists of the payload header that would have been used (including a correct length field), but with each octet of the contents set to 0x0. The client MUST both verify the signature as being valid for the gateway's public key as well as verify that the signed exchange matches the actual data sent by the client in the first message. Message 3 contains the EAP identity response: HDR*, SAi2, TSi, TSr, EAP(Reply/Identity) --> Message 4 through message N-1 have the following format and essentially define a challenge/response exchange between the gateway (acting as an RFC2284 "authenticator") and the client (an RFC2284 "peer"): HDR*, EAP(n) Message N is the last message, and MUST come from the responder. If the responder successfully authenticates the initiator, message N is: <-- HDR*, EAP(SUCCESS), SAr2, TSi, TSr If the responder does not successfully authenticate the initiator, message N is: <-- HDR*, EAP(FAILURE) Best case we complete the exchange in six messages vs. four for CHRE in SLA. (NB: this is still a whole lot better than the nine or ten required for IKEv1 when using a standard MM/QM exchange). Note also that the even number of messages defined here plays well with IKEv2's retransmission policy (c.f. IKEv2 (03) Section 4.1). Derrell On Friday, December 20, 2002, at 05:30 PM, Hugo Krawczyk wrote: > It is up to the "legacy authentication" community to come up with > solutions to > these problems (which arise from the essentially-insecure use of > credentials > in mixed protected/unprotected environments). Moreover, if you support > EAP > exchanges and the EAP community comes up with measures to alleviate > these > attacks in the context of EAP then you get the benefits of this > solution > automatically. If you do CHRE then you don't. > > That's a good reason to support EAP in SLA. > > And it is not the only benefit: > There is a lot of deployment of EAP and the definition of > authentication > mechanisms over EAP can be (and is) done independently of IKE. In my > view, it is better to leave these definitions in the hands of people > (such as the EAP WG) that specifically care about transport of client > authentication. If you rely on EAP then all you have to care about is > to > build a sound tunneling mechanism for EAP in the context of IKEv2 > (rather than building profiles that depend on the specifics of > secure-id, > radius, etc.) And, as said, the EAP guys are better suited to take > care of > problems in the "legacy authentication" world such as the above "man > in the > middle attacks" against tunneled authentication that have been a > concern > lately in this community. > > And adopting EAP into SLA is easy, just copy PIC. From owner-ipsec@lists.tislabs.com Sat Dec 21 11:48:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBLJmCo11793; Sat, 21 Dec 2002 11:48:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21787 Sat, 21 Dec 2002 14:20:40 -0500 (EST) Message-Id: <200212211921.gBLJLpiJ026223@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: speaking of keys In-reply-to: Your message of "Thu, 19 Dec 2002 19:25:08 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 21 Dec 2002 14:21:50 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> I have to disagree slightly. We can only rely on vendors to implement Stephen> the MUSTs, by definition, for any standard. Thus it is reasonable for Stephen> users to generally default to the MUSTs (algorithms, modes, key Stephen> lengths, ...) to ensure interoperability. I realize that there are While I don't disagree with any of your words, I think that you are making too strong a case here. i.e. overconstraining us. The key missing word is: "Thus it is reasonable for users to generally default to the MUSTs to ensure interoperability without pre-arrangement. " ^^^^^^^^^^^^^^^^^^^^^^^ IPsec, as used in VPNs, is not like TCP as used by SMTP, (or TLS as used in HTTPS). In a VPN, you are generally dealing with nodes that are there by *pre-arrangement*. Therefore, you can have things like policy MIBs/PIBs, and pre-configured root CAs for the certificates, etc.. I've said this before, and I'll say it again - I strongly think that we would make a lot more progress in the *IPsec* WG (whose job it is to produce tools, not solutions) if the VPN folks would write a VPN-profile of IPsec. It doesn't have to be long, but it can have things like: You MUST support 1024 bit DH or You MUST support CRMF (to pick a random PKIX acronym) ... To my knowledge, the only place where IPsec is being used without pre-arrangement is in FreeS/WAN's Opportunistic Encryption, and we are very specific in saying what our profile our IPsec is. To a large extent, I don't know if any parameter type MUSTs are really appropriate in either the base RFC2401 or base IKE drafts. I would much prefer that they were in specific profiles of IPsec. But, if we are putting MUSTs into the standard, then they are there for interoperability *without pre-arrangement*. That excludes pretty much *ALL* VPNs uses. Arguing over whether or not 80 or 128 bits of entropy is enough to key AES out of any context of the data that is being protected is really bizarre. You just do not prescribe security that way - how are we to say what appropriate cost is when we have no definition of risk or benefit? I really think that the rest of your message gets trapped into this mindset. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgS/SoqHRg3pndX9AQF/4gP8DaK/f6uhHrRlsTtyDBnjwV0HmUO6ZKoU PCAqVacxSSdUsm1rkNrQKIciT7aqYSsRZIh4+VTWysZ72FLa1JGb7/IJ3wnqW6lz MP+e86mnpe6jrcGh9W0t3eACNdzA7bTn4TA6cpK1OI4a3BJ4zvqnK3v+byDUOWhV /cKrCOcDKW8= =18NU -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Dec 21 11:55:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBLJtLo11874; Sat, 21 Dec 2002 11:55:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21858 Sat, 21 Dec 2002 14:27:42 -0500 (EST) Message-Id: <200212211928.gBLJSm1W026310@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: speaking of keys In-reply-to: Your message of "Thu, 19 Dec 2002 20:03:15 EST." <3E026C53.566627C2@nortelnetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 21 Dec 2002 14:28:47 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Marcus" == Marcus Leech writes: Marcus> I really don't have a problem with MUSTing a couple of groups at Marcus> least. Marcus> 1024 - fast, but somewhat less secure Marcus> 15xx - slower, but rather more secure Marcus> I can sympathize with not wanting to mandate the much larger groups. Marcus> Small Marcus> devices (telephones, for example) really do have some serious storage Marcus> and peformance issues, but storage is the real killer, as it Marcus> turns Marcus, while I would be overjoyed to see these devices do random IPsec connections to random other devices, I have serious doubts that this is really going to occur. What's the application? VPNs? VoIP? I honestly have my doubts here. A device that can afford a full fledged Java implementation to web surf and do IMAP, that can't do IKE? While Bert's laptop runs IPsec OE, it has as much ram as my previous notebook computer, and more CPU, actually. I just don't get it. You can't set these numbers in isolation from the applications involved. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgTA7oqHRg3pndX9AQFhzwQAuq2Vjcnvogi4X/6yuLVWTLJa71w0WedD cdqFb5V699AhtrR6t7z2fVbDaRUF855XXtmJF/ehVoSR9d53Jo57OqhZ4kpmtkW6 MlkHczwGXcQDqeQyIxrOt6rPjhJ9ynlYkJsjZYq50ru1TOhN9+JSdEKOrancy+YI YjuY0ufzpug= =k7BJ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Dec 21 19:49:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBM3nNo03900; Sat, 21 Dec 2002 19:49:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26166 Sat, 21 Dec 2002 22:13:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Secure legacy authentication for IKEv2 Date: Sat, 21 Dec 2002 19:14:36 -0800 Message-ID: Thread-Topic: Secure legacy authentication for IKEv2 Thread-Index: AcKpDGcV6M2PU4C6T1uq+dBsGDJAcAAWg2Qg From: "William Dixon" To: "Derrell Piper" , "Hugo Krawczyk" Cc: "Bernard Aboba" , "Valery Smyslov" , , "Paul Hoffman / VPNC" X-OriginalArrivalTime: 22 Dec 2002 03:14:43.0353 (UTC) FILETIME=[45DBF090:01C2A968] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id WAA26158 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell, we can't assume IKEv2 is just for VPN purposes, or has the protections you describe. It should solve generalized end-to-end IP scenarios, e.g. protect end-to-end TCP and UDP, across a hostile network. Re: CHRE vs. EAP: I see no need to re-invent individual auth methods when an existing IETF RFC framework exists for authentication in EAP, which is a better (more flexible) solution in the long-term, and one that leverages established code bases for implementers (EAP for PPP, 802.1x, PIC, EAP-TLS, etc), as well as one that plugs into existing customer infrastructures. -----Original Message----- From: Derrell Piper [mailto:ddp@electric-loft.org] Sent: Saturday, December 21, 2002 8:18 AM To: Hugo Krawczyk Cc: Bernard Aboba; William Dixon; Valery Smyslov; ipsec@lists.tislabs.com; Paul Hoffman / VPNC Subject: Re: Secure legacy authentication for IKEv2 On Friday, December 20, 2002, at 05:42 PM, Hugo Krawczyk wrote: >> For the binding attack (as I understand it) to be viable, an active >> attacker would have to bring up the SLA IKE tunnel through message >> two and then somehow induce someone to speak one of the legacy >> authentication methods to it. But for that to happen, the attacker >> would have to complete the first two messages with the intended >> victim and in doing so, the client would learn that the attacker >> wasn't trusted. (We were not concerned with trusted gateways >> impersonating each other.) > > In these attacks the attacker > > (a) impersonates the server to the client in the unprotected run (we > are > talking of legacy authentication methods that do NOT authenticate the > server so this impersonation is possible) > > (b) impersonates the client to the server in the protected run (SLA, > PIC, etc) using the responses that it gets from the client in the > impersonated unprotected run (a). > > But again see the mentioned documents for a full understanding of > these attacks, their independence from EAP, and applicability to SLA > (in particular, the fact that SLA requires server authentication does > not help against the attacks). > > Hugo Hugo, Thanks for the pointer to the NRC paper. Between it and I now have a good understanding of the particular MitM attack we're discussing. Further I now see that the distinction between using EAP vs. SLA (with its CHRE) is irrelevant with respect to this. We agree that this attack requires that: 1) the authentication protocol that's run in the tunnel also be run outside of the tunnel (i.e. unprotected) 2) an attacker is somehow able to lure clients into running the unprotected legacy authentication against him For SLA, we assumed that the legacy authentication methods that we're talking about tunneling are in use only back on the corporate network, not across the Internet. We assumed that the corporate network is appropriately isolated (behind a firewall) from the Internet and blocks nearly everything. It's our belief that that's the usual configuration for deployed IPSec VPN gateways today, which are increasingly hosted on (or built into) the firewall itself. Given these assumptions, clients aren't running the legacy authentication protocols anywhere outside of SLA because there's nothing to talk to (it's all blocked at the firewall). Perhaps the salient point is that these assumptions and their implications on the security of the protocol do need to be clearly stated. I'm guessing you might agree with this because in another later email you wrote: "I suggest not to hold up any of these protocols on the basis of these attacks (rather have clear language regarding the reasons for these attacks and the essentially-limited scope of possible solutions)." If we're on the same page, then it seems to me what's interesting to talk about as a group is whether or not these assumptions are realistic for our to-be-deployed IPSec remote client protocol. If we are indeed worried that the legacy authentication methods are today in use across the Internet then we've got more work to do. Derrell From owner-ipsec@lists.tislabs.com Sun Dec 22 10:52:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBMIqso21932; Sun, 22 Dec 2002 10:52:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04212 Sun, 22 Dec 2002 13:22:59 -0500 (EST) Message-Id: <200212221823.gBMINiRq012964@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 transport concerns In-reply-to: Your message of "Fri, 20 Dec 2002 16:03:55 EST." <277DD60FB639D511AC0400B0D068B71E0564C6AD@corpmx14.us.dg.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 22 Dec 2002 13:23:43 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Black" == Black David writes: Black> Steve, Black> The goal here is that any use of IKEv2 to negotiate a tunnel-mode SA Black> (or UDP-encapsulated tunnel-mode SA for NAT traversal) carry an implied Black> promise that ECN will be supported and handled correctly for that Black> tunnel. This avoids any need for IKEv2 to negotiate/report/etc. Black> ECN handling, in contrast to IKEv1 where a negotiable SA attribute David, while I understand what you are trying to do, you are assuming that IKEv2 can only be deployed with an entirely new system. IKEv2 is a trivial upgrade of system software (perhaps a "Service Pack"), while the upgrade to the IPsec portions may in fact require changes to hardware. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgYDLYqHRg3pndX9AQFQPAQAhIARLR3+3zJHttma1196V8hs7fj+Dd9X SQC+YN4CtfT3ncc3mK6JxZWq7g3J+zhrtSCDy8TQV3gf2Tn1EXFF3y07i3/dfaMy oYBqYh8MtRiMCNVVb+IdmCL9/fIHlmFbm1HZsqursFYRYWhjMkiDVmDdPoD3LbgL pYwY7Du/vnI= =DIY5 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Dec 22 10:58:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBMIwko22512; Sun, 22 Dec 2002 10:58:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04265 Sun, 22 Dec 2002 13:30:02 -0500 (EST) Message-Id: <200212221831.gBMIVJtp013093@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: application APIs In-reply-to: Your message of "Fri, 20 Dec 2002 17:50:34 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 22 Dec 2002 13:31:19 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> An important feature of IPsec is that an administrator can impose Stephen> security controls on traffic without having to rely on individual Stephen> applications to be able to make these choices, and without having to ... Stephen> For example, I assume that even if we have an API that apps can use Stephen> to specify controls, that you would want some defaults and one way of Stephen> configuring the defaults is via an administrator interface. Would Stephen> that satisfy your goals? Stephen, if you go see the original NRL API (which KAME is mostly a clone of), it pretty much has everything you want: 1) admin can force things to be clear, or to be private. 2) applications can request services within the parameters given 3) some applications (priveledged ones) can override, particularly, IKE daemons can get port 500 stuff out. But, the NRL API wasn't perfect, and left lots of things to be desired. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgYE9YqHRg3pndX9AQFCnAQAqjnB9F0gmWGlB5TPT/s9DSY/jS1NBrqo dUeRqcsW8zshsh0Lgiiedc+8wh6t5QgxHOF9LtHaFbWE5VIwTL8IeuGkwAPpssut 6efS/hxqI3+BK2Okg75tcYaVKIfUq4X3ISkV8ZIrtlGVzA73VP3A74MkMIuB+u8a 2afZc6+faQg= =KW7a -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Dec 22 11:02:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBMJ2Vo22616; Sun, 22 Dec 2002 11:02:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04311 Sun, 22 Dec 2002 13:40:03 -0500 (EST) Message-Id: <200212221841.gBMIfD3Q013231@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Reply-To: mcr@sandelman.ottawa.on.ca Subject: Carson Sutton's stupid vacation messages Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 22 Dec 2002 13:41:12 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I encourage everyone who has received a vacation message from Carson Sutton of Alcatel to complain to postmaster@alcatel.com. Do so for each copy of the message that you receive. I have a template complaint if you want a copy. It is sending out vacation messages for *each* message that you post to ipsec@lists.tislabs.com. This is very much in contradiction to RFC1123, a specification that is now 13 years old. You can complain also by calling 972-519-3000, ask for the helpdesk, push #5. Yes, they are open on Sundays. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgYHOoqHRg3pndX9AQGQvwP9G+8mhjHh3UeJU0UA4zNSjpaSURrucnm5 /fWJ5ePN99mHwbTfbrDoZnYsqkhiGBs5HoOksiyPGmhuA6KBJkgUUz+GCakeHx5Q 4cnph4G1Gg8PQtZEyoi740ctoPjsSo/t7+NnyDd92viLN1XA6TAdDGAjbId8zAuU Utdb/OeWgNM= =jM2z -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Dec 22 11:16:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBMJGGo22838; Sun, 22 Dec 2002 11:16:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04492 Sun, 22 Dec 2002 13:53:18 -0500 (EST) Message-Id: <200212221854.gBMIsjr6013455@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Summary of revised identity changes In-reply-to: Your message of "Fri, 20 Dec 2002 18:34:00 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 22 Dec 2002 13:54:42 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> could you elaborate a bit. I can see some circumstances where Stephen> this would be true, but I'm not sure how common the problem Stephen> would be. for exmaple, a cert with my e-mail address is a Let me put it this way - I have yet to see a two node VPN that was built with commercial VPN products actually use RSA authentication - the X.509 hill is just too steep. This is *WITHOUT* any restrictions on certificate contents. I've seen a lot of installations. At the same time, the *ONLY* reason that the X.509 patches exist for FreeS/WAN is pretty much to talk to Win32 implementations that can barely handle self-signed certificates. They *CERTAINLY* aren't getting the contents of the certificate request correct very often either. Stephen> perfectly fine user ID cert for IPsec, as well as for s/mime, Stephen> and it might be OK for authenticating me in an SSL/TLS context Stephen> as well. Can you tell me how I initiate to another system based upon an e-mail address? Remember, since we eliminated the mapping, you can't insert anything that says: CN=kent@bbn.com 192.160.6.91 so, how do you set up *two* systems that can talk to each other? Where are they? No, there is no configuration file, this proposal eliminates the need for it.... it might be wrong. >> While that may be the desired effect for people with real PKI >> infrastructure and real PKI clue, for the people who just want to >> connect two LANs with a VPN, a self-signed certificate generated by >> openssl is *just fine*. >> >> If they have to get right goop in place to use certificates, even more >> people will want to continue using pre-shared keys. >> >> Now, if you, instead, are willing to say: >> >> All implementations MUST support RAW RSA key formats, providing a way >> to load/save them interactively (i.e. in a UI or CLI) in RFC3110 >> format. >> >> Then, you can do whatever you want with certificates. But, up to this >> point, even doing self-signed X.509 (I wish they'd say "RFC2459" >> certificates) is hard for many products, and people therefore resort >> to pre-shared keys. >> Stephen> I too don't want to promote use of pre-shared keys. But, if I Stephen> have a RAW RSA format, what is the mechanism by which this Stephen> identifies me? It is not one of the ID types supported by the It identifies you because I said it did. Stop thinking about million node VPNs for a minute. Think about Bob's dinner's two franchises. He buys two D-Link IPsec/DSL boxes. These are like ~$200 each. He hires some kid to hook them up into a VPN. He plugs his Cisco IP phones in, and his cash registers in. Stephen> SPD. If you're saying that we need another mapping table from Stephen> key to ID, then I have the same concerns re getting this mapping Stephen> wrong. Let's go back here a moment. If you make it hard, then people will use PSK. As such, you lose. If you want to kill public key use of IPsec with PKI, this proposal is a way to do it. Go see EAP thread, cause we will need it. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgYKb4qHRg3pndX9AQFmdgP+PAgq1IDFN9pdIDeB+pbNjY61PzEr0mkf lvoPulAPpTF6SH9u3iJl9kWIJv1kjSxRCMEwBXnoYud40SHJeHtqHy9152/JhhkE bUHb/OydRK7ZehlfRReORT+24HJUQx+oKVvj6kVf15onFi/3ydCIBeDnkc0oqS/v FEs3S/1zr2c= =mXBz -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 23 06:49:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNEmxo22393; Mon, 23 Dec 2002 06:48:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18413 Mon, 23 Dec 2002 09:11:46 -0500 (EST) Message-Id: <200212231255.HAA27622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-udp-encaps-05.txt Date: Mon, 23 Dec 2002 07:55:25 -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 : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen et al. Filename : draft-ietf-ipsec-udp-encaps-05.txt Pages : 0 Date : 2002-12-20 This draft defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-05.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-udp-encaps-05.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-udp-encaps-05.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: <2002-12-20130022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130022.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Dec 23 06:49:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNEmxo22394; Mon, 23 Dec 2002 06:48:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18414 Mon, 23 Dec 2002 09:11:46 -0500 (EST) Message-Id: <200212231255.HAA27622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-udp-encaps-05.txt Date: Mon, 23 Dec 2002 07:55:25 -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 : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen et al. Filename : draft-ietf-ipsec-udp-encaps-05.txt Pages : 0 Date : 2002-12-20 This draft defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-05.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-udp-encaps-05.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-udp-encaps-05.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: <2002-12-20130022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130022.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Dec 23 06:49:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNEn1o22413; Mon, 23 Dec 2002 06:49:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18415 Mon, 23 Dec 2002 09:11:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Secure legacy authentication for IKEv2 Date: Fri, 20 Dec 2002 14:48:41 -0800 Message-ID: Thread-Topic: Secure legacy authentication for IKEv2 Thread-Index: AcKodF6FC2H85FomSAu2EUfFjYGm3AABRjOw From: "Bernard Aboba" To: "Derrell Piper" , "William Dixon" Cc: "Valery Smyslov" , , "Paul Hoffman / VPNC" X-OriginalArrivalTime: 20 Dec 2002 22:48:42.0012 (UTC) FILETIME=[F1BED5C0:01C2A879] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA09633 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Isn't the current version of SLA vulnerable to the same attack? I don't see anywhere in the spec where a "binding" is carried out. In fact, this would not be possible with the methods you're supporting, because none of them generate keys. From owner-ipsec@lists.tislabs.com Mon Dec 23 06:49:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNEn3o22435; Mon, 23 Dec 2002 06:49:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18437 Mon, 23 Dec 2002 09:12:46 -0500 (EST) Message-Id: <5.1.0.14.0.20021220184329.00a2aac0@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Dec 2002 19:18:07 -0500 To: Stephen Kent From: David Jablon Subject: Re: Secure legacy authentication for IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Regarding extensibility of SLA ... >At 2:06 PM -0500 12/19/02, I wrote: >>Perhaps "extensibility" should include the ability to take advantage >>of keys generated by methods that use legacy credentials. [...] At 05:39 PM 12/20/02 -0500, Stephen Kent wrote: >Use of keys [in] what way? ... A key generated by a client authentication method could be blended with the presumably-server-authenticated DH key, say using a standard key derivation function (HMAC-SHA, etc.), to produce a resulting key with the qualities of both. >... IKE v2 has introduced a clean separation of key material generation via DH exchange from authentication processes. I don't see how a legacy authentication system would contribute keys for IPsec, and I would rather not see it enter into the key generation process now that we have a clean separation. The "clean separation" to which you refer merely insures that the quality of the initial DH key can *never* be improved or strengthened by the quality of the client authentication method. Got a password-authenticated key? Just throw it away. Yep, it's clean all right. But it is awfully limiting, and does not seem in the best interests of security. To mandate that any keying material generated by any method that uses legacy credentials must discard such valuable material when used with IKE v2 seems something more than just "clean". I presume people mentioned EAP because it appears to be the first IETF authentication framework to allow one to take advantage of keying material derived from a legacy credential method. Anyway, whether or not EAP is the right way to go for IPSEC, I was wondering if other simple constructions might fit just fine. -- David From owner-ipsec@lists.tislabs.com Mon Dec 23 07:30:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNFUZo27713; Mon, 23 Dec 2002 07:30:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19234 Mon, 23 Dec 2002 10:08:50 -0500 (EST) Message-ID: <421CB3B9B2D2F645B548D213C0A90E5583FA2B@TMM_EDGMSMSG01> From: Van Aken Dirk To: "'ipsec@lists.tislabs.com'" Subject: Re: Proposed Configuration payload for IKEv2 Date: Mon, 23 Dec 2002 16:09:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Gents, Is not intended for IP configuration of remote hosts ? IMHO, decouples IPSec and IRAC config in the sense that only a short lived tunnel is required for DHCP messages hence all other complexity is in DHCP. What is gained from decoupling IKE from host configuration is that only a single mechanism is required for host configuration. In that way a system administrator must not learn new mechanisms/methods to configure hosts. To her/him it is the same whether configuring a central office or a remote IPSec protected host. Best regards - Dirk -----Original Message----- From: Darren Dukes [mailto:ddukes@cisco.com] Sent: donderdag 19 december 2002 20:39 To: Hugo Krawczyk Cc: ipsec@lists.tislabs.com; ietf-mode-cfg@vpnc.org Subject: RE: Proposed Configuration payload for IKEv2 > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Thursday, December 19, 2002 12:30 PM > > On Wed, 18 Dec 2002, Darren Dukes wrote: > > > Attached is a draft which is intended to be merged with the IKEv2 draft. > > There is no intent for this draft to continue on its own. It contains a > > payload and description of how an IPsec Remote Access Client > (IRAC) may use > > that payload to get configuration information (internal IP, > subnets, etc.) > > from an IPsec Remote Access Server (IRAS). > > > > The payload in this draft is very similar to the IKEv1 modecfg > draft, this > > draft states the differences between the two. > > > > Why do this? (copied from vpnc.org) "At the IETF meeting in Atlanta in > > November, 2002, the IPsec WG decided to add remote access capabilities > > (legacy authentication and remote client configuration) to IKEv2. At an > > If I understand it correctly, your draft only addresses the remote client > configuration issue, not the legacy authentication. How do you envision > adding the legacy authentication support and still making use of the > configuration mechanism described in the draft? After taking a quick look at Paul's draft he just sent out, I think CP will go in the LAS exchange message 3 and message N the same way it's specified for message 3 and 4 now. > Note that you add the > configuration mechanism to messages 3 and 4 of ikev2 and assume that it is > protected under the IKE-SA, however if you need to perform legacy > authentication then you will not have an established IKE-SA in messages 3 > and 4. > > Also, it is worth noting that even if client and server use regular IKE > authentication (signatures or preshared key) then in message 3 the server > (responder) is not yet authenticated by the client so the information > transmitted from IRAC to IRAS in this message is NOT protected. This > should be documented and explicitly said that this message should not > contain any confidential information. You are right about message 3, and the IRAS not being authenticated to IRAC. I think text about the lack of authentication should suffice with strong suggestions of what configuration attributes should go into the CFG_REQUEST. > > These problems are solved if the configuration information exchange > happens in phase 2 (at the expense, of course, of more round trips). I had originally thought of this as just a post 'phase-1' exchange but since the first Child-SA is always created in message 3 and 4 we will need the configuration data before or during its creation. Without it the IRAS has no way of knowing how to narrow TSi in message 4. Darren > > Hugo > > > informal design team meeting after the WG meeting, the VPN > vendors attending > > decided that the best options to propose to the WG were to add > capabilities > > similar to XAUTH and MODE-CFG." > > > > Please send all comments regarding this draft to ipsec@lists.tislabs.com > > > > Thanks, > > Darren > > > From owner-ipsec@lists.tislabs.com Mon Dec 23 08:40:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNGeFo02215; Mon, 23 Dec 2002 08:40:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20142 Mon, 23 Dec 2002 11:13:55 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.0.20021220184329.00a2aac0@pop.theworld.com> References: <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> <5.1.0.14.0.20021220184329.00a2aac0@pop.theworld.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: Mon, 23 Dec 2002 08:15:28 -0800 To: David Jablon , Stephen Kent From: Paul Hoffman / VPNC Subject: Re: Secure legacy authentication for IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:18 PM -0500 12/20/02, David Jablon wrote: >The "clean separation" to which you refer merely insures that the quality >of the initial DH key can *never* be improved or strengthened by the quality >of the client authentication method. Got a password-authenticated key? >Just throw it away. Yep, it's clean all right. The same argument goes for IKEv2's authentication. Are you saying that we should change the key derivation for IKEv2 itself to include material from those authentication methods? If so, please suggest text so the cryptographers can analyze it. The current IKEv2 draft has: SKEYSEED = prf(Ni | Nr, g^ir) {SK_d, SK_ai, SK_ar, SK_ei, SK_er} = prf+ (SKEYSEED, Ni | Nr | CKY-I | CKY-R) What is your proposal for improving this in a provably secure way? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Dec 23 09:46:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNHkKo05743; Mon, 23 Dec 2002 09:46:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20997 Mon, 23 Dec 2002 12:20:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212221854.gBMIsjr6013455@sandelman.ottawa.on.ca> References: <200212221854.gBMIsjr6013455@sandelman.ottawa.on.ca> Date: Mon, 23 Dec 2002 12:06:49 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: Summary of revised identity changes Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, > Can you tell me how I initiate to another system based upon an e-mail >address? Remember, since we eliminated the mapping, you can't insert anything >that says: > CN=kent@bbn.com 192.160.6.91 In the typical case for an individual in an enterprise setting (not in the opportunistic context), the individual is contacting the corporate IPsec server and that info is a local config parameter. That server would have a symbolic SPD entry for kent@bbn.com, and when the IKE exchange took place the current address for keent@bbn.com would be instantiated in the SAD and SPD cache, for use with future packets during the life of the SA. > > so, how do you set up *two* systems that can talk to each other? >Where are they? No, there is no configuration file, this proposal eliminates >the need for it.... it might be wrong. I can't follow your text here, but the whole issue of how one uses symbolic entries for IP addresses in the SPD, and the translates them into specific IP addresses for the duration of an SA, is something that I hope to better describe in 2401bis, although the notion has always been in 2401. > > >> While that may be the desired effect for people with real PKI > >> infrastructure and real PKI clue, for the people who just want to > >> connect two LANs with a VPN, a self-signed certificate generated by > >> openssl is *just fine*. > >> > >> If they have to get right goop in place to use certificates, even more > >> people will want to continue using pre-shared keys. > >> > >> Now, if you, instead, are willing to say: > >> > >> All implementations MUST support RAW RSA key formats, providing a way > >> to load/save them interactively (i.e. in a UI or CLI) in RFC3110 > >> format. > >> > >> Then, you can do whatever you want with certificates. But, up to this > >> point, even doing self-signed X.509 (I wish they'd say "RFC2459" > >> certificates) is hard for many products, and people therefore resort > >> to pre-shared keys. > >> > Stephen> I too don't want to promote use of pre-shared keys. But, if I > Stephen> have a RAW RSA format, what is the mechanism by which this > Stephen> identifies me? It is not one of the ID types supported by the > > It identifies you because I said it did. Stop thinking about million node >VPNs for a minute. I am accustomed to thinking about small PKIs, but I also want to make sure that the mechanisms we standardize scale well. I think what you are saying here is that the key identifies you only because someone built a table to map from the key to an ID. Asd I noted, there is no provision for IDs as IDs in the SPD in 2401, and I do not anticipate making such provision in 2401bis. > Think about Bob's dinner's two franchises. He buys two D-Link IPsec/DSL >boxes. These are like ~$200 each. He hires some kid to hook them up into a >VPN. He plugs his Cisco IP phones in, and his cash registers in. and what happens then? as many folks have noted for some time, its not hard to provide software that creates self-signed certs and exchange them for ID and authentication purposes. if you are going to have to go to the trouble of creating table entries to map big strings of bits (keys) as IDs, you could just as well perform the functions needed to use certs, including self-signed certs. > > > Stephen> SPD. If you're saying that we need another mapping table from > Stephen> key to ID, then I have the same concerns re getting this mapping > Stephen> wrong. > > Let's go back here a moment. > > If you make it hard, then people will use PSK. As such, you lose. > If you want to kill public key use of IPsec with PKI, this proposal is a >way to do it. Go see EAP thread, cause we will need it. We agree in principle, but I don't agree that any use of certs is as complex as your suggest. It seems to me that you are the one thinking in terms of very large PKIs and the complexity that accompanies them. Just because many IPsec vendors have chosen to use PKI software that was designed for large scale environments, and thus is overkill for the trivial context you describe above, does not mean that the problem is intrinsic in PKI. the different between public keys and self-signed certs is relatively small, but it allows more uniformity (and thus less complexity) for implementations that want to support both very small and larger populations. Steve From owner-ipsec@lists.tislabs.com Mon Dec 23 09:46:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNHkKo05744; Mon, 23 Dec 2002 09:46:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20964 Mon, 23 Dec 2002 12:18:41 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.1.0.14.0.20021220184329.00a2aac0@pop.theworld.com> References: <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> <5.1.0.14.0.20021220184329.00a2aac0@pop.theworld.com> Date: Mon, 23 Dec 2002 12:12:58 -0500 To: David Jablon From: Stephen Kent Subject: Re: Secure legacy authentication for IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:18 PM -0500 12/20/02, David Jablon wrote: >Regarding extensibility of SLA ... > >>At 2:06 PM -0500 12/19/02, I wrote: >>>Perhaps "extensibility" should include the ability to take advantage >>>of keys generated by methods that use legacy credentials. [...] > >At 05:39 PM 12/20/02 -0500, Stephen Kent wrote: >>Use of keys [in] what way? ... > >A key generated by a client authentication method could be blended >with the presumably-server-authenticated DH key, say using a >standard key derivation function (HMAC-SHA, etc.), to produce a >resulting key with the qualities of both. that approach complicates the analysis of the security provided by the system, not a path that this WG is likely to find appealing in this era of simplicity. > >>... IKE v2 has introduced a clean separation of key material >>generation via DH exchange from authentication processes. I don't >>see how a legacy authentication system would contribute keys for >>IPsec, and I would rather not see it enter into the key generation >>process now that we have a clean separation. > >The "clean separation" to which you refer merely insures that the quality >of the initial DH key can *never* be improved or strengthened by the quality >of the client authentication method. Got a password-authenticated key? >Just throw it away. Yep, it's clean all right. > >But it is awfully limiting, and does not seem in the best interests >of security. >To mandate that any keying material generated by any method that >uses legacy credentials must discard such valuable material when >used with IKE v2 seems something more than just "clean". We need to be able to make statement about the security of the key material used for packet confidentiality and packet integrity irrespective of the peer authentication mechanism chosen. To do otherwise would unduly complicate the overall system. That's why the current separation is desirable. Steve From owner-ipsec@lists.tislabs.com Mon Dec 23 10:11:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNIBjo06660; Mon, 23 Dec 2002 10:11:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21384 Mon, 23 Dec 2002 12:48:12 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200212221831.gBMIVJtp013093@sandelman.ottawa.on.ca> References: <200212221831.gBMIVJtp013093@sandelman.ottawa.on.ca> Date: Mon, 23 Dec 2002 12:37:09 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: application APIs Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:31 PM -0500 12/22/02, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Stephen" == Stephen Kent writes: > Stephen> An important feature of IPsec is that an administrator can impose > Stephen> security controls on traffic without having to rely on individual > Stephen> applications to be able to make these choices, and >without having to > >... > > Stephen> For example, I assume that even if we have an API that >apps can use > Stephen> to specify controls, that you would want some defaults >and one way of > Stephen> configuring the defaults is via an administrator interface. Would > Stephen> that satisfy your goals? > > Stephen, if you go see the original NRL API (which KAME is mostly a clone >of), it pretty much has everything you want: > 1) admin can force things to be clear, or to be private. > 2) applications can request services within the parameters given > 3) some applications (priveledged ones) can override, particularly, IKE > daemons can get port 500 stuff out. > > But, the NRL API wasn't perfect, and left lots of things to be desired. > I don't disagree with your observations, but I also am more concerned about putting the MUSTs into IKEv2 to make sure we have the requisite management capabilities, irrespective of whether folks use an API or not. It seems unlikely that we make provision of a specific API a MUST at this point. Steve From owner-ipsec@lists.tislabs.com Mon Dec 23 13:36:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNLamo18609; Mon, 23 Dec 2002 13:36:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23963 Mon, 23 Dec 2002 16:09:46 -0500 (EST) Message-Id: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Dec 2002 16:11:34 -0500 To: ipsec@lists.tislabs.com From: Thomas Hardjono Subject: Proposed text changes to ESPbis and AHbis for multicast support Cc: kent@bbn.com, canetti@watson.ibm.com, mbaugher@cisco.com, bew@cisco.com, msec@securemulticast.org, thardjono@verisign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The MSEC working group has a number of proposed changes to the text of ESPbis (draft-ietf-ipsec-esp-v3-03.txt) and AHbis (draft-ietf-ipsec-rfc2402bis-01.txt) These proposed changes and its implications to the usability of IPsec in multicast have been rationalized in the following draft: ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt The draft explains at length the motivations, though below is a list of the suggested changes. We would like to see some discussion on the IPsec mailing-list regarding these proposed changes. Regards, Thomas/Ran ---------- --------------------------------------------------------------------- ESPbis-change#1: SPI allocation and SA lookup Section 2.1 (Security Parameters Index) specifies exactly how the SPI should be dealt with: For multicast SAs, the SPI (and optionally the protocol ID) in combination with the destination address is used to select an SA. This is because multicast SAs are defined by a multicast controller, not by each IPsec receiver. (See the Security Architecture document for more details) [ESPbis]. We propose this section to be replaced with the following wording: For broadcast, multicast, and anycast SAs, the SPI and protocol ID (ESP) in combination with the destination address is used to select an SA. In some cases, other parameters (such as a source address) MAY be used by a receiver to further identify the correct SA. This is because multicast SAs may be defined by more than one multicast group controller. --------------------------------------------------------------------- ESPbis-change#2: SPI allocation and SA lookup Section 3.4.2 (Security Association Lookup) of [ESPbis] currently states: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the SPI alone (unicast) or SPI combined with destination IP address (multicast). (This process is described in more detail in the Security Architecture document) [ESPbis]. We propose this text be replaced as follows. Upon receipt of a unicast packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the SPI alone. (This process is described in more detail in the Security Architecture document.) If the packet is a broadcast, multicast, or anycast packet, there may be more than one SA pointed to by the combination of SPI, security protocol and destination address. This can happen if multiple non-cooperating multicast controllers are present in the network. In this case the receiver MAY use other parameters (such as a source address) to identify the correct SA. Key management MAY indicate (e.g., with an SA attribute) that such processing is necessary in order for a receiver to properly process the ESP packets for a group if that is known a priori. --------------------------------------------------------------------- ESPbis-change#3: Multiple sender SAs and replay protection Section 2.2 (Sequence Number) states: Sharing an SA among multiple senders is deprecated, since there is no general means of synchronizing packet counters among the senders or meaningfully managing a receiver packet counter and window in the context of multiple senders [ESPbis]. We propose the following replacement for the above text in [ESPbis]. For a multi-sender multicast SA, the anti-replay service MUST NOT be used unless key management signals its use. If the anti-replay service is used in this case, each receiver must keep a replay window per sender. --------------------------------------------------------------------- ESPbis-change#4: Integrity vs. Authentication The name associated with the authentication portion of ESP is "Authentication Data". However, [ESPbis] changed the name to "Integrity Check Value". Section 1 says: Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity." (This term is employed because, on a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer [ESPbis]. We propose the following wording changes to [ESPbis]. 1. The text quoted above from Section 1 should be replaced with: Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "authentication." 2. All occurrences of "Integrity-only ESP" should be "Authentication-only ESP". 3. The "Integrity Check Value" field in AH should be named "Authentication Data", and all references to that section should be updated. --------------------------------------------------------------------- AHbis-change#1: SPI allocation and SA lookup Section 2.4 (Security Parameters Index) specifies exactly how the SPI should be dealt with. It is identical to [ESPbis] wording: For multicast SAs, the SPI (and optionally the protocol ID) in combination with the destination address is used to select an SA. This is because multicast SAs are defined by a multicast controller, not by each IPsec receiver. (See the Security Architecture document for more details) [AHbis]. As in the case with [ESPbis], we propose this section to be replaced with the following wording: For broadcast, multicast, and anycast SAs, the SPI and protocol ID (AH) in combination with the destination address is used to select an SA. In some cases other parameters (such as a source address) MAY be used by a receiver to further identify the correct SA. This is because multicast SAs may be defined by more than one multicast group controller. --------------------------------------------------------------------- AHbis-change#2: (appended text) Section 3.4.2 (Security Association Lookup) of [AHbis] also needs to be modified to reflect these semantics. It currently states: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), and the SPI [AHbis]. No change to this text is necessary. We propose that the following text be appended to it. If the packet is a broadcast, multicast, or anycast packet, there may be more than one SA pointed to by the combination of SPI, security protocol and destination address. This can happen if multiple non-cooperating multicast controllers are present in the network. In this case the receiver MAY use other parameters (such as a source address) to identify the correct SA. Key management MAY indicate (e.g., with an SA attribute) that such processing is necessary in order for a receiver to properly process the AH packets for a group if that is known a priori. --------------------------------------------------------------------- AHbis-change#3: Multiple sender SAs and replay protection Same as ESPbis-change#3 above. --------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Dec 23 15:48:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNNmbo23492; Mon, 23 Dec 2002 15:48:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25663 Mon, 23 Dec 2002 18:21:23 -0500 (EST) Date: Tue, 24 Dec 2002 01:23:02 +0200 (IST) From: Hugo Krawczyk To: Derrell Piper cc: IPsec WG Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: <0152BA0D-1502-11D7-9FFC-000393CDFD1A@electric-loft.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell, based on your messages and other recent traffic on the list on this issues I think that we can summarize several points of agreement as follows: (what do other think?) (1) do not mandate SLA in IKEv2 (2) leave SLA as a separate document (3) advance IKEv2 and SLA concurrently in the standards process (4) replace the CHRE formats with standarized EAP transport (5) regarding MitM attacks due to the use of mixed protected/unprotected runs of the legacy authentication, the WG has to decide on one of two ways to go: (a) do not do anything about solving the problem in SLA. This has several possible justifications: - assume (as you said in a previous message) that the mixed authentication scenario does not occur in ipsec [this would probably require more feedback from the list] - assume that even if some mixed authentication scenarios do show up in the ipsec world it is due to a BAD PRACTICE that should be abandoned (not a sin that SLA needs to help washing) - be "respectful" to people that use mixed authentication but tell them to look for a solution elsewhere (at the legacy authentication layer or as a generic mechansims on top of EAP, for example). (b) allow for an optional mixing of key material derived from SLA and from the underlying authentication method in the key derivation procedure of SLA. This is a solution of limited scope (assumes that the legacy authentication produces a key and that the key can be made available to SLA) and it does not address at all the dangers of dictionary attacks if the legacy authentication is based on password (or other low-entropy keys). It also constitutes (as someone said) a logical layer violation. Hugo From owner-ipsec@lists.tislabs.com Mon Dec 23 15:49:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNNnBo23515; Mon, 23 Dec 2002 15:49:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25717 Mon, 23 Dec 2002 18:25:31 -0500 (EST) Date: Tue, 24 Dec 2002 01:26:58 +0200 (IST) From: Hugo Krawczyk To: Derrell Piper cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "In principle" this sounds correct (up to an authentication problem in message 2 that I hinted to in a previous message but which is orthogonal to the issues related to EAP authentication). At the more specific level, I recommend that you follow PIC in its use and specification of EAP exchanges. They were designed by two knowedgeable guys: Yaron Sheffer and Bernard Aboba who I believe will be willing to help here. In order to utilize PIC in the SLA context you need to: (1) format messages 1 and 2 according to IKEv2 payloads (2) refer to IKEv2 for key derivation (3) use HDR* in the sense of IKEv2 (thus no need for the HASH payload in messages 3 and 4 that PIC uses) (4) eliminate the credential-request and credential payloads used in PIC. Hugo PS: Question: you say that the SLA exchange with EAP must have 6 messages at least. Aren't there EAP methods where the server (responder in SLA) sends its challenge already in the first EAP message? In this case the whole SLA exchange can be completed in 4 msgs rather than 6. On Sat, 21 Dec 2002, Derrell Piper wrote: > Hugo, > > I think I was the main opponent to using EAP, but I'm willing to > concede this point if it helps get us to consensus. I see now that > using EAP is cryptographically no worse than what we proposed with SLA > (see other thread) and you make some good arguments here for its > adoption (as do others). > > Note that SLA proposed a strict client-directed authentication > exchange. For each client request, the server's response either > completed the exchange or contained an additional challenge. The SLA > protocol did not allow for negotiation of the LAM type (without > restarting the exchange). This was chosen primarily so that the client > could aggressively send his credentials in message three. RFC2284 > (EAP) instead implements a request/response protocol run by the > responder ("authenticator" in RFC2284) and allows for flexibility in > authentication type negotiation (the client can "nak" the requested > type and request something else). > > So here's a fairly straightforward substitution of EAP for CHRE in SLA: > > We'll need to define an EAP payload: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload !C! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ EAP Packet ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The Critical Bit MUST be set in all EAP payloads. The EAP Packet and > its contents are defined in RFC2284. > > The first two messages remain almost the same as for SLA. The response > from the gateway now also includes the EAP identity request and begins > the EAP protocol. Note that this is only a request; identity > protection for the client is not compromised if the server > authentication fails. > > Initiator (client) Responder (gateway) > ------------------ ------------------- > HDR, SAi1, KEi, Ni --> > <-- HDR, SAr1, KEr, Nr, > EAP(Request/Identity), AUTH > > The responder's AUTH payload is computed over all of message one > concatenated with all of message two. Because the contents of the AUTH > payload cannot be known when creating the concatenation, a dummy AUTH > payload is constructed which consists of the payload header that would > have been used (including a correct length field), but with each octet > of the contents set to 0x0. > > The client MUST both verify the signature as being valid for the > gateway's public key as well as verify that the signed exchange matches > the actual data sent by the client in the first message. > > Message 3 contains the EAP identity response: > > HDR*, SAi2, TSi, TSr, > EAP(Reply/Identity) --> > > Message 4 through message N-1 have the following format and essentially > define a challenge/response exchange between the gateway (acting as an > RFC2284 "authenticator") and the client (an RFC2284 "peer"): > > HDR*, EAP(n) > > Message N is the last message, and MUST come from the responder. If > the responder successfully authenticates the initiator, message N is: > > <-- HDR*, EAP(SUCCESS), > SAr2, TSi, TSr > > If the responder does not successfully authenticate the initiator, > message N is: > > <-- HDR*, EAP(FAILURE) > > Best case we complete the exchange in six messages vs. four for CHRE in > SLA. (NB: this is still a whole lot better than the nine or ten > required for IKEv1 when using a standard MM/QM exchange). Note also > that the even number of messages defined here plays well with IKEv2's > retransmission policy (c.f. IKEv2 (03) Section 4.1). > > Derrell > > On Friday, December 20, 2002, at 05:30 PM, Hugo Krawczyk wrote: > > > It is up to the "legacy authentication" community to come up with > > solutions to > > these problems (which arise from the essentially-insecure use of > > credentials > > in mixed protected/unprotected environments). Moreover, if you support > > EAP > > exchanges and the EAP community comes up with measures to alleviate > > these > > attacks in the context of EAP then you get the benefits of this > > solution > > automatically. If you do CHRE then you don't. > > > > That's a good reason to support EAP in SLA. > > > > And it is not the only benefit: > > There is a lot of deployment of EAP and the definition of > > authentication > > mechanisms over EAP can be (and is) done independently of IKE. In my > > view, it is better to leave these definitions in the hands of people > > (such as the EAP WG) that specifically care about transport of client > > authentication. If you rely on EAP then all you have to care about is > > to > > build a sound tunneling mechanism for EAP in the context of IKEv2 > > (rather than building profiles that depend on the specifics of > > secure-id, > > radius, etc.) And, as said, the EAP guys are better suited to take > > care of > > problems in the "legacy authentication" world such as the above "man > > in the > > middle attacks" against tunneled authentication that have been a > > concern > > lately in this community. > > > > And adopting EAP into SLA is easy, just copy PIC. > > From owner-ipsec@lists.tislabs.com Mon Dec 23 15:54:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBNNsdo23658; Mon, 23 Dec 2002 15:54:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25821 Mon, 23 Dec 2002 18:31:43 -0500 (EST) Date: Tue, 24 Dec 2002 01:32:50 +0200 (IST) From: Hugo Krawczyk To: "The Purple Streak, Hilarie Orman" cc: mleech@nortelnetworks.com, housley@vigilsec.com, ipsec@lists.tislabs.com Subject: Re: speaking of keys In-Reply-To: <200212201823.gBKIN0d09395@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 20 Dec 2002, The Purple Streak, Hilarie Orman wrote: > You get about 8 bits of extra strength going from 1024 to 1280. You get about > 17 bits going from 1024 to 1536. 8 (or even 17) bits may sound as very little, but if we consider only computational advances (not cryptanalytical ones) 8 bits of additional strength means 12 more years of security in terms of Moore's progress. That is, if we consider that computational resources double each 1.5 year, then we have that they quadruple each 3 years. In terms of "bits of strength" this means that 2 additional bits count for 3 more years of security. Thus, 8 bits give you another 12 years and 17 give 25 years. That is very significant. Of course (and again) this does not take into account cryptanalytical advances which is where the highest danger to cryptography lies. In particular, we do not know when (and by whom) the 1024 -bit DH standarized groups will be practically broken. Hugo > > It is ridiculous to consider 1024 for a protocol that will exchange billions > of keys over the next several years. > > Hilarie > > > > > > > The draft NIST guidelines do not offer an recommendations on values between > > > 1024 and 2048. However, some interpolation is possible. I think that we > > > should consider 1280 and 1536. > > > > > > Russ > > Actually, 1280 was one of the values I had thought of, but I don't have > > a good intuitive feel for how much stronger it is than 1024. > From owner-ipsec@lists.tislabs.com Tue Dec 24 05:35:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBODZFo01225; Tue, 24 Dec 2002 05:35:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04223 Tue, 24 Dec 2002 08:03:53 -0500 (EST) Date: Tue, 24 Dec 2002 06:06:10 -0700 Subject: Re: Secure legacy authentication for IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipsec@lists.tislabs.com To: Hugo Krawczyk From: Derrell Piper In-Reply-To: Message-Id: <78D86CF4-1740-11D7-8066-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, In EAP the identity request is optional, so if the server side somehow knows ahead of time the presumed identity of the peer (typical example is leased line), it could begin the EAP exchange with a challenge and complete in four. I'd also guess for EAP using CHAP/MD5 that a clever implementation could begin with the challenge if you knew that you'd be picking up the identity (out-of-band w.r.t. EAP) before you'd have to process the EAP response and you had a rich enough EAP API to be able to associate an identity with a pending EAP request. But that's a hack. And for OTP and tokens, this optimization isn't possible because you need to the username to lookup the sequence or generate the challenge. So in the general case, I don't see an obvious way to do this and preserve client identity protection. Derrell On Monday, December 23, 2002, at 04:26 PM, Hugo Krawczyk wrote: > PS: Question: you say that the SLA exchange with EAP must have 6 > messages > at least. Aren't there EAP methods where the server (responder in SLA) > sends its challenge already in the first EAP message? In this case the > whole SLA exchange can be completed in 4 msgs rather than 6. From owner-ipsec@lists.tislabs.com Tue Dec 24 13:30:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBOLUro29739; Tue, 24 Dec 2002 13:30:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13270 Tue, 24 Dec 2002 15:57:28 -0500 (EST) Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-05.txt From: Steve Dispensa To: ipsec@lists.tislabs.com In-Reply-To: <200212231255.HAA27622@ietf.org> References: <200212231255.HAA27622@ietf.org> Content-Type: text/plain Organization: Positive Networks Message-Id: <1040763337.6761.26.camel@stratocaster.positivenetworks.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 24 Dec 2002 14:55:37 -0600 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 2002-12-23 at 06:55, Internet-Drafts@ietf.org wrote: > 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 : UDP Encapsulation of IPsec Packets > Author(s) : A. Huttunen et al. > Filename : draft-ietf-ipsec-udp-encaps-05.txt > Pages : 0 > Date : 2002-12-20 This may be a typo, but the second paragraph of the introduction states: "It is up to the need of the clients whether transport mode or tunnel mode is to be supported. L2TP/IPsec clients MUST support transport mode since [RFC 3193] defines that L2TP/IPsec MUST use transport mode], and IPsec tunnel mode clients MUST support tunnel mode." Note that RFC 3193 does not, in fact, require the use of transport mode with L2TP, just that implementations support transport mode. (RFC 3193 section 2.1) This is sort of cleared up in the next sentence, but the wording should probably be fixed. FWIW, this is a bit of a sore spot with me. We regularly use L2TP over tunnel mode due to separation of the l2tp server from the IPSEC concentrator. This creates problems on the client side (Windows users in particular) due to dumb client implementations. -sd From owner-ipsec@lists.tislabs.com Tue Dec 24 13:30:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBOLUto29751; Tue, 24 Dec 2002 13:30:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13332 Tue, 24 Dec 2002 16:03:31 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> References: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Date: Tue, 24 Dec 2002 16:06:47 -0500 To: Thomas Hardjono From: Stephen Kent Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: ipsec@lists.tislabs.com, canetti@watson.ibm.com, mbaugher@cisco.com, bew@cisco.com, msec@securemulticast.org, thardjono@verisign.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thomas, I have read the message and your ID on multicast and IPsec. Here are my comments: >--------------------------------------------------------------------- >ESPbis-change#1: SPI allocation and SA lookup > >Section 2.1 (Security Parameters Index) specifies exactly how the >SPI should be dealt with: > > For multicast SAs, the SPI (and optionally the protocol ID) in > combination with the destination address is used to select an SA. > This is because multicast SAs are defined by a multicast > controller, not by each IPsec receiver. (See the Security > Architecture document for more details) [ESPbis]. > >We propose this section to be replaced with the following wording: > > For broadcast, multicast, and anycast SAs, the SPI and protocol > ID (ESP) in combination with the destination address is used to > select an SA. In some cases, other parameters (such as a source > address) MAY be used by a receiver to further identify the > correct SA. This is because multicast SAs may be defined by more > than one multicast group controller. The text above does not provide a useful, testable specification. It allows (MAY) a receiver to use a source address and other, undefined parameters for SA selection, but does not require it. The result is that a complaint IPsec implementation need not do any of this, which makes for a weak standard and does nothing for interoperability. We need concrete specs for developers and this does not provide such specs. It has the feature of allowing a future implementation to able to claim compliance with the spec when someone figures out exactly what to do for multicast/broadcast/anycast, but this does nothing for interoperabilty, which is a primary goal of RFCs. At a minimum I think you need to be able to create text of the form "An IPsec implementation that supports multicast, broadcast, or anycast MUST ..." in order for this to be useful. I get the sense, from the ID you just published, that the MSEC WG has not yet decided exactly what requirements need to be imposed and exactly how to deal with these issues, and thus it seems premature to write the sort of text I suggest is really required. Your ID erroneously states that the revised AH and ESP IDs change the semantics of SA demuxing and make the lookups "less specific." The changes we made in the new AH & ESP drafts re what parameters define an SA and thus are used to demux incoming IPsec packets, are clarifications designed to reflect what many developers already knew and practiced in their implementations. The original text over-specified SA demuxing, imposing parameters (destination address and protocol) that were irrelevant for unicast SA demuxin. As a result, smart developers realized that they could manage the SPI space in a way that never made use of these values and they did so. The changes you suggest for multicast SA demuxing here, i.e., use of the source address, were NOT supported in the current AH and ESP RFCs not in 2401 and so the clarifications made in the revised AH and ESP specs did not adversely affect what you suggest might need to done to better support multicast SAs. Your ID cites two issues re what parameters are used to uniquely identify (demux) an SA, but seems to confuse the implications of these two issues, and the text above seems to reflect this confusion. Your ID says that an SSM group is defined by a single sender and a set of receivers. it may use the same multicast address as another, distinct SSM group, presumably with a different sender but perhaps an overlapping set of receivers. Hence you infer that using the destination (multicast) address and an SPI is not sufficient to uniquely identify (for receivers) an SA for this type of multicast group, because the senders do not coordinate with one another. It would seem for this case that use of the sender address plus the multicast destination address provides a natural means of identifying the SA, but the ID does not discuss any other options that have been explored and rejected. For example, what sort of interactions do the sender and receivers engage in to create this sort of group, how is the key distributed, and might there be a way to use data from those interactions to create an SPI that would allow demuxing using the parameters currently defined? Separately, the ID discusses the notion that multiple controllers might be involved inn managing a multicast group (presumably not an SSM group) and that these controllers might not be able to coordinate to select a unique SPI (relative to a single multicast address). But if these controllers coordinate to distribute the single key used for encrypting/decrypting traffic on a multicast SA, why are they unable to coordinate on assigning a single SPI for a multicast SA? Thus this latter argument for having to use some parameter other than the destination address and SPI for SA demuxing is not persuasive. I think a better analysis is required here before we impose new/additional constraints on SA demuxing in IPsec. >--------------------------------------------------------------------- >ESPbis-change#2: SPI allocation and SA lookup > >Section 3.4.2 (Security Association Lookup) of [ESPbis] currently states: > > Upon receipt of a packet containing an ESP Header, the receiver > determines the appropriate (unidirectional) SA, based on the SPI > alone (unicast) or SPI combined with destination IP address > (multicast). (This process is described in more detail in the > Security Architecture document) [ESPbis]. > >We propose this text be replaced as follows. > > Upon receipt of a unicast packet containing an ESP Header, the > receiver determines the appropriate (unidirectional) SA, based on > the SPI alone. (This process is described in more detail in the > Security Architecture document.) > > If the packet is a broadcast, multicast, or anycast packet, there > may be more than one SA pointed to by the combination of SPI, > security protocol and destination address. This can happen if > multiple non-cooperating multicast controllers are present in the > network. In this case the receiver MAY use other parameters (such > as a source address) to identify the correct SA. Key management > MAY indicate (e.g., with an SA attribute) that such processing is > necessary in order for a receiver to properly process the ESP > packets for a group if that is known a priori. The second paragraph begins by redefining what an SA is, and that's not a great start considering how long we have had a stable definition for an SA. Here too, the the lack of specific, testable requirements here makes for a poor spec. We want to ensure interoperability and MAYs don't cut it. This is essentially a placeholder that allows a later design to say it is compliant, but which does not contribute to interoperability. I don't think this is a good path for IPsec RFCs. If we cannot specify exactly what values are used by a receiver to identify traffic as belonging to a specific SA, then a developer cannot produce code or hardware that will perform the selection. Deferring this to the key management protocol is not a solution, it is just a level of indirection. >--------------------------------------------------------------------- >ESPbis-change#3: Multiple sender SAs and replay protection > > >Section 2.2 (Sequence Number) states: > > Sharing an SA among multiple senders is deprecated, since there > is no general means of synchronizing packet counters among the > senders or meaningfully managing a receiver packet counter and > window in the context of multiple senders [ESPbis]. > > >We propose the following replacement for the above text in [ESPbis]. > > For a multi-sender multicast SA, the anti-replay service MUST NOT > be used unless key management signals its use. If the anti-replay > service is used in this case, each receiver must keep a replay > window per sender. I agree in principle with the intent of this notion, but the sticking point is that we have not yet agreed on a way to accommodate this requirement. Your ID states that requiring an SA per sender is unacceptable, and alludes to some scenario that motivates this statement, but provide no details to support the assertion. The text above has the flavor of a placeholder, rather than a useful spec to guide developers in producing interoperable implementations. The text imposes a vague requirement without any supporting analysis of the problems imposed by the requirement. >--------------------------------------------------------------------- >ESPbis-change#4: Integrity vs. Authentication > >The name associated with the authentication portion of ESP is >"Authentication Data". However, [ESPbis] changed the name to >"Integrity Check Value". > >Section 1 says: > > Data origin authentication and connectionless integrity are joint > services, hereafter referred to jointly as "integrity." (This > term is employed because, on a per-packet basis, the computation > being performed provides connectionless integrity directly; data > origin authentication is provided indirectly as a result of > binding the key used to verify the integrity to the identity of > the IPsec peer [ESPbis]. > >We propose the following wording changes to [ESPbis]. > > 1. The text quoted above from Section 1 should be replaced with: > > Data origin authentication and connectionless integrity are joint > services, hereafter referred to jointly as "authentication." > > 2. All occurrences of "Integrity-only ESP" should be > "Authentication-only ESP". > > 3. The "Integrity Check Value" field in AH should be named > "Authentication Data", and all references to that section should > be updated. We changed the term for good reasons. First, the ICV acronym expands to "Integrity Check Value" and it has been there since before the previous set of RFCs. Second, the function really does provide integrity. Authentication is a side effect that results from knowing the identity of the holder of the key used to generate the ICV, as noted above. Overall, I found that the ID did not provide adequate motivation for most of the proposed changes, and I recommend that none of the proposed changes be made at this time. The text needs to be changed so that is sufficiently detailed to promote the development of interoperable implementations, something that it does not do as it stands. If such text is provided, then the IPsec WG needs to review any new requirements for multicast/broadcast/anycast support, to ensure that they do not impose unacceptable burdens, e.g., re support of anti-replay for multi-sender SAs. The IPsec WG chairs need to determine if they wish to delay the revisions to AH and ESP until both of these criteria are satisfied. Steve From owner-ipsec@lists.tislabs.com Wed Dec 25 01:15:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBP9F9o20292; Wed, 25 Dec 2002 01:15:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA19827 Wed, 25 Dec 2002 03:40:49 -0500 (EST) Message-Id: <5.1.1.5.2.20021225000045.04b64b30@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 25 Dec 2002 00:41:23 -0800 To: Stephen Kent From: Mark Baugher Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: Thomas Hardjono , ipsec@lists.tislabs.com, canetti@watson.ibm.com, Brian Weis , msec@securemulticast.org In-Reply-To: References: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, At 04:06 PM 12/24/2002 -0500, Stephen Kent wrote: >Thomas, > >I have read the message and your ID on multicast and IPsec. Here are my >comments: > >>--------------------------------------------------------------------- >>ESPbis-change#1: SPI allocation and SA lookup >> >>Section 2.1 (Security Parameters Index) specifies exactly how the >>SPI should be dealt with: >> >> For multicast SAs, the SPI (and optionally the protocol ID) in >> combination with the destination address is used to select an SA. >> This is because multicast SAs are defined by a multicast >> controller, not by each IPsec receiver. (See the Security >> Architecture document for more details) [ESPbis]. >> >>We propose this section to be replaced with the following wording: >> >> For broadcast, multicast, and anycast SAs, the SPI and protocol >> ID (ESP) in combination with the destination address is used to >> select an SA. In some cases, other parameters (such as a source >> address) MAY be used by a receiver to further identify the >> correct SA. This is because multicast SAs may be defined by more >> than one multicast group controller. > >The text above does not provide a useful, testable specification. It >allows (MAY) a receiver to use a source address and other, undefined >parameters for SA selection, but does not require it. The result is that a >complaint IPsec implementation need not do any of this, which makes for a >weak standard and does nothing for interoperability. We need concrete >specs for developers and this does not provide such specs. It has the >feature of allowing a future implementation to able to claim compliance >with the spec when someone figures out exactly what to do for >multicast/broadcast/anycast, but this does nothing for interoperabilty, >which is a primary goal of RFCs. I agree and think think that the source address, and only the source address, should be a MUST. >At a minimum I think you need to be able to create text of the form "An >IPsec implementation that supports multicast, broadcast, or anycast MUST >..." in order for this to be useful. I get the sense, from the ID you just >published, that the MSEC WG has not yet decided exactly what requirements >need to be imposed and exactly how to deal with these issues, and thus it >seems premature to write the sort of text I suggest is really required. Inclusion of the source address in SA lookup was recommended by IRTF SMuG years ago and nothing has changed in MSEC since that time. >Your ID erroneously states that the revised AH and ESP IDs change the >semantics of SA demuxing and make the lookups "less specific." The changes >we made in the new AH & ESP drafts re what parameters define an SA and >thus are used to demux incoming IPsec packets, are clarifications designed >to reflect what many developers already knew and practiced in their >implementations. The original text over-specified SA demuxing, imposing >parameters (destination address and protocol) that were irrelevant for >unicast SA demuxin. As a result, smart developers realized that they could >manage the SPI space in a way that never made use of these values and they >did so. The changes you suggest for multicast SA demuxing here, i.e., use >of the source address, were NOT supported in the current AH and ESP RFCs >not in 2401 and so the clarifications made in the revised AH and ESP specs >did not adversely affect what you suggest might need to done to better >support multicast SAs. > >Your ID cites two issues re what parameters are used to uniquely identify >(demux) an SA, but seems to confuse the implications of these two issues, >and the text above seems to reflect this confusion. > > Your ID says that an SSM group is defined by a single sender and > a set of receivers. it may use the same multicast address as another, > distinct SSM group, presumably with a different sender but perhaps an > overlapping set of receivers. Hence you infer that using the destination > (multicast) address and an SPI is not sufficient to uniquely identify > (for receivers) an SA for this type of multicast group, because the > senders do not coordinate with one another. This is primarily a group controller issue and not a sender issue as described in section 2.1 of the I-D. >It would seem for this case that use of the sender address plus the >multicast destination address provides a natural means of identifying the >SA, but the ID does not discuss any other options that have been explored >and rejected. For example, what sort of interactions do the sender and >receivers engage in to create this sort of group, how is the key >distributed, and might there be a way to use data from those interactions >to create an SPI that would allow demuxing using the parameters currently >defined? I think the I-D states what it needs to: A group controller maintains the key for the group and the members (senders and receivers) interact with the group controller to establish the group key. A single multicast group can support multiple SSM groups, each can be in a separate administrative domain with a separate group controller. > Separately, the ID discusses the notion that multiple controllers > might be involved inn managing a multicast group (presumably not an SSM > group) and that these controllers might not be able to coordinate to > select a unique SPI (relative to a single multicast address). But if > these controllers coordinate to distribute the single key used for > encrypting/decrypting traffic on a multicast SA, These controllers need not and do not coordinate to do anything. No such protocol exists to my knowledge, at least not in the public domain. >why are they unable to coordinate on assigning a single SPI for a >multicast SA? Thus this latter argument for having to use some parameter >other than the destination address and SPI for SA demuxing is not persuasive. Maybe the I-D is not clear enough. There can be N SSM groups for an IP multicast group and there can be as many as N group controllers operating independently. >I think a better analysis is required here before we impose new/additional >constraints on SA demuxing in IPsec. > >>--------------------------------------------------------------------- >>ESPbis-change#2: SPI allocation and SA lookup >> >>Section 3.4.2 (Security Association Lookup) of [ESPbis] currently states: >> >> Upon receipt of a packet containing an ESP Header, the receiver >> determines the appropriate (unidirectional) SA, based on the SPI >> alone (unicast) or SPI combined with destination IP address >> (multicast). (This process is described in more detail in the >> Security Architecture document) [ESPbis]. >> >>We propose this text be replaced as follows. >> >> Upon receipt of a unicast packet containing an ESP Header, the >> receiver determines the appropriate (unidirectional) SA, based on >> the SPI alone. (This process is described in more detail in the >> Security Architecture document.) >> >> If the packet is a broadcast, multicast, or anycast packet, there >> may be more than one SA pointed to by the combination of SPI, >> security protocol and destination address. This can happen if >> multiple non-cooperating multicast controllers are present in the >> network. In this case the receiver MAY use other parameters (such >> as a source address) to identify the correct SA. Key management >> MAY indicate (e.g., with an SA attribute) that such processing is >> necessary in order for a receiver to properly process the ESP >> packets for a group if that is known a priori. > >The second paragraph begins by redefining what an SA is, and that's not a >great start considering how long we have had a stable definition for an SA. It's a matter of SA lookup. The second paragraph wants to redefine SA lookup, which is the point of the I-D. >Here too, the the lack of specific, testable requirements here makes for a >poor spec. We want to ensure interoperability and MAYs don't cut it. This >is essentially a placeholder that allows a later design to say it is >compliant, but which does not contribute to interoperability. I don't >think this is a good path for IPsec RFCs. If we cannot specify exactly >what values are used by a receiver to identify traffic as belonging to a >specific SA, then a developer cannot produce code or hardware that will >perform the selection. Deferring this to the key management protocol is >not a solution, it is just a level of indirection. This is the same issue as above because the text was copied. >>--------------------------------------------------------------------- >>ESPbis-change#3: Multiple sender SAs and replay protection >> >> >>Section 2.2 (Sequence Number) states: >> >> Sharing an SA among multiple senders is deprecated, since there >> is no general means of synchronizing packet counters among the >> senders or meaningfully managing a receiver packet counter and >> window in the context of multiple senders [ESPbis]. >> >> >>We propose the following replacement for the above text in [ESPbis]. >> >> For a multi-sender multicast SA, the anti-replay service MUST NOT >> be used unless key management signals its use. If the anti-replay >> service is used in this case, each receiver must keep a replay >> window per sender. > >I agree in principle with the intent of this notion, but the sticking >point is that we have not yet agreed on a way to accommodate this >requirement. Your ID states that requiring an SA per sender is unacceptable, Where does it state that? >and alludes to some scenario that motivates this statement, but provide no >details to support the assertion. The text above has the flavor of a >placeholder, rather than a useful spec to guide developers in producing >interoperable implementations. The text imposes a vague requirement >without any supporting analysis of the problems imposed by the requirement. The requirement was stated in a note posted by Bill Fenner to this list last Spring. The replacement text allows multi-sender SAs, it's clear that this is a change from ESPbis, and designates key management as the entity that determines whether or not a replay window is kept in the receiver. >>--------------------------------------------------------------------- >>ESPbis-change#4: Integrity vs. Authentication >> >>The name associated with the authentication portion of ESP is >>"Authentication Data". However, [ESPbis] changed the name to >>"Integrity Check Value". >> >>Section 1 says: >> >> Data origin authentication and connectionless integrity are joint >> services, hereafter referred to jointly as "integrity." (This >> term is employed because, on a per-packet basis, the computation >> being performed provides connectionless integrity directly; data >> origin authentication is provided indirectly as a result of >> binding the key used to verify the integrity to the identity of >> the IPsec peer [ESPbis]. >> >>We propose the following wording changes to [ESPbis]. >> >> 1. The text quoted above from Section 1 should be replaced with: >> >> Data origin authentication and connectionless integrity are joint >> services, hereafter referred to jointly as "authentication." >> >> 2. All occurrences of "Integrity-only ESP" should be >> "Authentication-only ESP". >> >> 3. The "Integrity Check Value" field in AH should be named >> "Authentication Data", and all references to that section should >> be updated. > >We changed the term for good reasons. First, the ICV acronym expands to >"Integrity Check Value" and it has been there since before the previous >set of RFCs. Second, the function really does provide >integrity. Authentication is a side effect that results from knowing the >identity of the holder of the key used to generate the ICV, as noted above. It's not suitable for multicast source authentication. I think this is explained adequately in section 3.3 of the I-D. >Overall, I found that the ID did not provide adequate motivation for most >of the proposed changes, and I recommend that none of the proposed changes >be made at this time. The text needs to be changed so that is >sufficiently detailed to promote the development of interoperable >implementations, something that it does not do as it stands. If such text >is provided, then the IPsec WG needs to review any new requirements for >multicast/broadcast/anycast support, to ensure that they do not impose >unacceptable burdens, e.g., re support of anti-replay for multi-sender >SAs. The IPsec WG chairs need to determine if they wish to delay the >revisions to AH and ESP until both of these criteria are satisfied. I hope you'll work with us to address the issues that you have identified. Mark >Steve From owner-ipsec@lists.tislabs.com Thu Dec 26 08:28:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBQGSJo28216; Thu, 26 Dec 2002 08:28:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08698 Thu, 26 Dec 2002 10:46:51 -0500 (EST) Message-ID: <3E0B24C7.2000908@F-Secure.com> Date: Thu, 26 Dec 2002 17:48:23 +0200 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Dispensa CC: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-05.txt References: <200212231255.HAA27622@ietf.org> <1040763337.6761.26.camel@stratocaster.positivenetworks.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2002 15:48:22.0818 (UTC) FILETIME=[3869B820:01C2ACF6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve Dispensa wrote: > On Mon, 2002-12-23 at 06:55, Internet-Drafts@ietf.org wrote: > >>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 : UDP Encapsulation of IPsec Packets >> Author(s) : A. Huttunen et al. >> Filename : draft-ietf-ipsec-udp-encaps-05.txt >> Pages : 0 >> Date : 2002-12-20 > > > This may be a typo, but the second paragraph of the introduction > states: "It is up to the need of the clients whether transport mode or > tunnel mode is to be supported. L2TP/IPsec clients MUST support > transport mode since [RFC 3193] defines that L2TP/IPsec MUST use > transport mode], and IPsec tunnel mode clients MUST support tunnel > mode." Note that RFC 3193 does not, in fact, require the use of > transport mode with L2TP, just that implementations support transport > mode. (RFC 3193 section 2.1) This is sort of cleared up in the next > sentence, but the wording should probably be fixed. RFC 3193 seems to say "Transport mode MUST be supported; tunnel mode MAY be supported." We could rephrase the introduction to be something like this, because otherwise we'd no longer even optionally support this tunnel mode L2TP/IPsec. Or so it could be seen. At least that's what I see was intended originally. (Note that I've not read RFC 3193 in full and hopefully never will.) It is up to the need of the clients whether transport mode or tunnel mode is to be supported. L2TP/IPsec clients MUST support transport mode and MAY support tunnel mode, as defined in [RFC 3193]. IPsec tunnel mode clients MUST support tunnel mode. > FWIW, this is a bit of a sore spot with me. We regularly use L2TP over > tunnel mode due to separation of the l2tp server from the IPSEC > concentrator. This creates problems on the client side (Windows users > in particular) due to dumb client implementations. Well, looks to me like those Windows clients are behaving according to RFC 3193, by not implementing tunnel mode. Tough luck. Ari > > -sd > > -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Thu Dec 26 12:51:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBQKp7o14692; Thu, 26 Dec 2002 12:51:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10003 Thu, 26 Dec 2002 14:55:37 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.1.1.5.2.20021225000045.04b64b30@mira-sjc5-6.cisco.com> References: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> <5.1.1.5.2.20021225000045.04b64b30@mira-sjc5-6.cisco.com> Date: Thu, 26 Dec 2002 14:57:43 -0500 To: Mark Baugher From: Stephen Kent Subject: Re: Proposed text changes to ESPbis and AHbis for multicast support Cc: Thomas Hardjono , ipsec@lists.tislabs.com, canetti@watson.ibm.com, Brian Weis , msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, I'll try to condense the text to that this message does not grow to unmanageable proportions. >I agree and think think that the source address, and only the source >address, should be a MUST. I'm glad we agree on the need to be clear on what is needed. I presume the plan would be to mandate support for using the source address for SA demuxing ONLY for SSM SAs, right? We would not change this for unicast SAs, not has there been a good argument for why any other form of mutlicast SA needs to make use of this value, so far as I can tell. If my interpretation is correct, then the IPsec WG needs to decide whether we mandate that all IPsec implementations support SSM, or if we say that IF you support SSM, then this is how to do it. >This is primarily a group controller issue and not a sender issue as >described in section 2.1 of the I-D. The I-D includes text that talks expressly about SSM, and text that talks about multiple controllers, without an indication of whether the latter text is SSM-specific or applicable to any multicast mechanism. I have interpreted it as the latter, and your comment suggests this is the desired interpretation. >I think the I-D states what it needs to: A group controller >maintains the key for the group and the members (senders and >receivers) interact with the group controller to establish the group >key. A single multicast group can support multiple SSM groups, each >can be in a separate administrative domain with a separate group >controller. >These controllers need not and do not coordinate to do anything. No >such protocol exists to my knowledge, at least not in the public >domain. I think I see the problem in terminology here. The term "group" is beong used to refer to a multicast address, and to the set of folks who transmit and receive traffic using the address. For security purposes, the latter set is the relevant one, wether it's SSM or some other multicast method, right? My comments about multiple controllers for a multicast group are expressed relative to this latter construct. So, for exmaple, I understand that different SSM groups, ecah with its own controller, have no assumed relationship among the controllers, despiet the fact that they may all make use of the same multicast address. What I was referring to was the more general case, where there were multiple controllers for a single group, where all the group members shared a key for transmission/reception. Perhaps this is the source of much confusion re multiple controllers for a "multicast group." I suggest revised terminology to avoid this confusion in the future. >>why are they unable to coordinate on assigning a single SPI for a >>multicast SA? Thus this latter argument for having to use some >>parameter other than the destination address and SPI for SA >>demuxing is not persuasive. > >Maybe the I-D is not clear enough. There can be N SSM groups for an >IP multicast group and there can be as many as N group controllers >operating independently. Yes, the I-D is NOT clear enough in this regard, because of the reuse of the term "group." >It's a matter of SA lookup. The second paragraph wants to redefine >SA lookup, which is the point of the I-D. I now see what is trying to be expressed, but it is said poorly. Do you want to say that an SSM multicast SA (if this applies to ALL forms of multicast SAs that would be cleaner, but I've yet to see the right arguments for this broad-based characterization) is defined by the pair of source IP address plus Destination IP address? Is there a need to use the SPI here too, i.e., can there be more than one SA from a given transmitter to a single multicast address? If so, then we need to use the triple Source/Destination/SPI for these SAs, but that requirement needs to be made clear. >This is the same issue as above because the text was copied. right. >>I agree in principle with the intent of this notion, but the >>sticking point is that we have not yet agreed on a way to >>accommodate this requirement. Your ID states that requiring an SA >>per sender is unacceptable, > >Where does it state that? I infer that this is the underlying assumption, otherwise there would be no need to make the explicit statement about per-sender receive windows, since each SA provides this facility already and thus does not merit repetition here. If I am wrong that's fine, and we just need to reword this. >>and alludes to some scenario that motivates this statement, but >>provide no details to support the assertion. The text above has the >>flavor of a placeholder, rather than a useful spec to guide >>developers in producing interoperable implementations. The text >>imposes a vague requirement without any supporting analysis of the >>problems imposed by the requirement. > >The requirement was stated in a note posted by Bill Fenner to this >list last Spring. The replacement text allows multi-sender SAs, >it's clear that this is a change from ESPbis, and designates key >management as the entity that determines whether or not a replay >window is kept in the receiver. The IPsec list gets lots of traffic and much of it never affects standards, in the final analysis. The I-D you co-authored should provide a concise rationale for the proposed changes, which it seems to try to do in places. Anyway, if the intent here is to propose allowing multi-sender SAs WITHOUT anti-replay, and mandating per-sender SA's when anti-replay is used, then it could be stated much, much better. So, what exactly are your suggesting? >>We changed the term for good reasons. First, the ICV acronym >>expands to "Integrity Check Value" and it has been there since >>before the previous set of RFCs. Second, the function really does >>provide integrity. Authentication is a side effect that results >>from knowing the identity of the holder of the key used to generate >>the ICV, as noted above. > >It's not suitable for multicast source authentication. I think this >is explained adequately in section 3.3 of the I-D. I don't think we are communicating, again. The field "ICV" has been there for years and we just clarified the function it provides in the recent revised I-Ds. The comment " It's not suitable for multicast source authentication" is without antecedent and needs explanation. Are you trying to say that for multicast SAs this field will carry a value that provides authentication in a fashion that makes the integrity/authentication distinction meaningless? Are you arguing that we were wrong to make the distinction even for unicast SAs and the current, default HMAC function? I can't tell from the I-D, or from your responses, what you are trying to say here. >I hope you'll work with us to address the issues that you have identified. > >Mark I'm trying. Steve From owner-ipsec@lists.tislabs.com Fri Dec 27 10:09:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBRI9No19894; Fri, 27 Dec 2002 10:09:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12263 Fri, 27 Dec 2002 12:30:15 -0500 (EST) Message-Id: <5.1.0.14.0.20021224092945.00a51260@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 27 Dec 2002 11:58:27 -0500 To: IPsec WG From: David Jablon Subject: Re: Secure legacy authentication for IKEv2 Cc: Hugo Krawczyk In-Reply-To: References: <0152BA0D-1502-11D7-9FFC-000393CDFD1A@electric-loft.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Regarding the "points of agreement" summary, some points of disagreement in the presentation of (5) on the use of key material are noted below. At 01:23 AM 12/24/02 +0200, Hugo Krawczyk wrote: >Derrell, based on your messages and other recent traffic on the list on >this issues I think that we can summarize several points of agreement >as follows: (what do other think?) > >(1) do not mandate SLA in IKEv2 >(2) leave SLA as a separate document >(3) advance IKEv2 and SLA concurrently in the standards process > >(4) replace the CHRE formats with standarized EAP transport > >(5) regarding MitM attacks due to the use of mixed protected/unprotected >runs of the legacy authentication, the WG has to decide on one of two ways to >go: > > (a) do not do anything about solving the problem in SLA. This has > several possible justifications: > > - assume (as you said in a previous message) that the mixed authentication > scenario does not occur in ipsec > [this would probably require more feedback from the list] > > - assume that even if some mixed authentication scenarios do show up > in the ipsec world it is due to a BAD PRACTICE that should be abandoned > (not a sin that SLA needs to help washing) > > - be "respectful" to people that use mixed authentication but tell them to > look for a solution elsewhere (at the legacy authentication layer or as a > generic mechansims on top of EAP, for example). > > (b) allow for an optional mixing of key material derived from SLA and from > the underlying authentication method in the key derivation procedure of > SLA. This is a solution of limited scope (assumes that the legacy > authentication produces a key and that the key can be made available to > SLA) and it does not address at all the dangers of dictionary attacks if > the legacy authentication is based on password (or other low-entropy > keys). It also constitutes (as someone said) a logical layer violation. In (5)(b), it seems more appropriate to characterize as "limited scope" the choice to NOT permit use of optional authenticated key material. Problems arise when the concept of "SLA" is limited to "legacy methods for authentication that do not produce key material", rather than the more broadly useful "authentication methods that use legacy credentials". Not all such methods are alike, so why shouldn't the solution be able to leverage the best qualities of any method? As to whether using available key material constitutes a "layer violation", I'd say the alternative is clearly the larger crime. Choosing to discard authenticated keying material, instead of binding it in some way to the session key, violates several important security principles. A key-producing SLA method may well address "dictionary attack", and key binding can prevent other MitM attacks that may otherwise occur when using server-only authenticated keys. As for the summary of (5)(a), none of the "possible justifications" presented justifies the "do nothing" approach, because the ramifications of such a decision go beyond the lone issue of "MitM attacks due to mixed protected/unprotected runs" as presented. -- David From owner-ipsec@lists.tislabs.com Fri Dec 27 15:05:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBRN5Bo09333; Fri, 27 Dec 2002 15:05:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13308 Fri, 27 Dec 2002 17:36:18 -0500 (EST) Message-Id: <200212272237.gBRMbVFr032043@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-reply-to: Your message of "Mon, 11 Nov 2002 11:13:41 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Dec 2002 17:37:30 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jan" == Jan Vilhuber writes: >> >> This is what IKE v2 and a cert profile should do, in combination. >> > >> >Given the importance of certificates to IKEv2, the profile should be a >> >part of the IKEv2 document. >> >> Why do you think it needs to be one document? Jan> Presumably for the same reason we decided to fold the IKE, ISAKMP, Jan> IPDOI etc drafts into a single document. No, that's not the same. It would be, if the only way to use IKE was with PKIX certificates, but it is not. The certificate profile *MUST* exist. I would prefer that it was in a seperate document. In fact, I suggest that this document should be extensively reviewed by the PKIX WG, and that in itself is a reason to do it in a different schedule. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgzWKIqHRg3pndX9AQHbIQQAzpF2LKBEAYGx4ST9AhSGt9mt8ei44UxP jSe/pkU2l6HuaHQ+ZpyeY0jFyW+IL0FkT1LIg76CmesyXM95ULz/LVtE5kijsjvE ZO/5TtY6TEmwyExW8N4hOgzn3VSIu10qe8mEgQEWnnZsCM4z9eU5JyqmyeZR3NRk OOx36Kxld5c= =d2PE -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Dec 27 15:11:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBRNB9o09874; Fri, 27 Dec 2002 15:11:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13385 Fri, 27 Dec 2002 17:50:20 -0500 (EST) Message-Id: <200212272251.gBRMpqF8032268@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-reply-to: Your message of "Tue, 12 Nov 2002 22:22:41 +0200." <15825.25361.887103.61323@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Dec 2002 17:51:51 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> One thing missing that was in the IKEv1 is the transfering of the Tero> CRLs, but when considering the size of them it is better to leave them Tero> out. Doesn't RFC2585 cover this? I.e. if you can find the certificate via HTTP, can't you also find the CRL at the same place, if there is one? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgzZhoqHRg3pndX9AQHv6wP/djqveU4B7ec8wrC20oicE5WqpS0M+QQe +GGU8sT9nhzklSiWZqpQeYM80DkVSl3xo2NOl7+fsmUNUCkVwSJGMQWlKI6j7obm Ifws0NYZ50/koE8WN4IaFVjhhcfg/gEP5v6owCmAzBL4K1nBwcEEZcbKr3cJyktB kgCCA+klxSw= =4XEG -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Dec 27 15:26:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBRNQZo10909; Fri, 27 Dec 2002 15:26:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13468 Fri, 27 Dec 2002 18:05:30 -0500 (EST) Message-Id: <200212272306.gBRN6okc032480@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Authentication methods in IKEv2 In-reply-to: Your message of "Thu, 14 Nov 2002 22:29:08 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Dec 2002 18:06:50 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> At 11:45 AM +0300 11/11/02, Valery Smyslov wrote: >> I have some doubts about using of authentication methods in IKEv2. >> In IKEv2 negotiation of authentication methods was completely >> removed - each side simply uses his/her favourite method. >> I think this may lead to the lack of interoperability and extensibility >> in case one of the endpoints supports more than one method of >> authentication. Charlie> A problem only occurs when one or both sides have multiple different keys Charlie> (or different ways of using the keys) with which they could authenticate. I Charlie> would expect this case to be unusual, but it certainly could happen. If it The situation is not unusual. Any system that generates new public keys regularly will have multiple keys that it could use. Combined with the fact that many directory systems are not instantaeous, and you have a wave effect, that reminds me of how light/sound propogates. Consider a system that wants to generate a new key every day. If you combine that with a directory system that can cache, and that may take 6-12 hours to propogate changes to all places, then there is a problem to solve. (DNS is like this, LDAP would be as well, but deployed LDAP doesn't replicate or cache very well yet) So, on day 0, I generate a key K1, and I enter it into my directory via my "CA". Nobody can see it yet, since it hasn't propogated yet, so I can't use it yet. On day 1, I start using key K1. Most sites can see it, and they cache it for 24 hours. I generate key K2, which I enter into my directory, asking it to expire K1 in 1 day. I continue to initiate with K1. I may be able to mark K2 to be effective only on day 2, expiring before the end of day 3. Depends upon my technology and how cooperative my CA is. Now, some sites (those very close to my directory primary), will see K2 immediately, but will see that they shouldn't use it. Some sites will have K1 in their cache, and won't see K2 until K1 expires from their cache. Now, at midnight on day 1 (is this local time, or GMT... are all the clocks synchronized?), I start using K2, and I generate K3 as required. Some sites won't have visited the directory yet, or may have even started negotiating 2 seconds before midnight. Now, I'm asked to authenticate... do I use K1 or K2? It depends upon what my peer thinks I should use. This is why it is important for the initiator to specify what key/identity it thinks the responder should use. >> For the rare case where the two endpoints don't really know each >> other *and* are going to trust each other *and* have multiple >> authentication mechanisms, we have eliminated a confusing option from >> IKEv1. That's exactly what IKEv2 was designed to do. Charlie> I might buy this. It is an uncommon circumstance. It will add Charlie> complexity to IKEv2 to handle it. If we decide to allow this, I It is non-existant in a single Enterprise VPN, which is the only major deployment we have. So, to say it is uncommon is not useful here. It is precisely the case of requiring interopability without pre-arrangement that must push things here. >> need to be able to tell the 'client' that she's supposed to do legacy >> authentication (at least in my idea of how legacy authentication needs >> to work). So authentication-parameters for phase 1 need to be part of >> the SA payload in some way (as part of the cipher suite or as an extra >> value somewhere or whatever). Charlie> Yes, one of the issues with legacy authentication is how to negotiate Charlie> it in the case where it's one of several possible forms of authentication Charlie> an endpoint has "keys" for (again a fringe case). If we've going to Charlie> negotiate it, my preference would be to see it in an optional payload. I for one, am in favour of simplifying things by claiming that legacy authentication is only ever used in a single direction, and only relevant to enterprise VPN situations. As such, the "server", being the one with the public key, should, if it is willing to do something, should be the one to indicate, within phase 1, what it can do. I think that EAP provides all of this. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgzdCIqHRg3pndX9AQEugAQA0RERjnU5wGYpszUusgyMNpfTRcjGKmsC TJFH8H7kRvyYteZIB1qJIGf3smBCPT9q3bC9E/78tkAPymAELRW2udyZqugRdzLN 9RxgjEQnQ61MXhDcdPsVhBVo333YVRpZshiSvJkt+uyvefAvtq44zI5MlGq0rQR3 85KnTagcUtU= =ang6 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Dec 27 16:44:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBS0iio15102; Fri, 27 Dec 2002 16:44:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13787 Fri, 27 Dec 2002 19:18:47 -0500 (EST) Message-Id: <200212280019.gBS0JVOV001346@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com cc: Paul Hoffman / VPNC , hugh@freeswan.org Subject: Re: Adding revised identities to IKEv2 In-reply-to: Your message of "Tue, 05 Nov 2002 14:20:53 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Dec 2002 19:19:30 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- {I'm sorry to take so long to reply to this thread. I have read the entire thread, which has been on my todo for a long time} I would like to amend the 5.5 section as follows. The goal here is to make sure that the initiator can indicate to the responder which identity the initiator thinks it is connecting to. This does not have a lot of relevance to a typical VPN usage, but becomes critical when the responder is a multiuser system, or a multi-identiy system. Any system that practices key rollover where a new key may get published in advance of retiring the old key may experience the problems of multi-identity. I will preface this with two comments: a) it might be that is makes sense to have two FullID-type payloads, with differing type codes, but otherwise identical structure. One for "Me", the other for "You" b) we have explicitely included the public key used for signing in the payload, in addition to either a certificate, or reference to something that would authenticate the public key. This is so that IKEv2 processing can continue *in parallel* with key verification. This is the "Me-Tarzan/You-Jane" (vs "Me-Tarzan/You-Sybil") proposal several of us have been talking about. Finally, if the key is not verified, but just accepted (according to some policy that would permit this in certain situations), one has a form of anonymous encryption that is possible. This may in fact be useful for use by legacy authentication systems - in this context one would use the legacy auth to authenticate the public keys rather than the DH exponents. This may be easier to do - certainly, it is easier to *CACHE*, and therefore may make rekeying of SAs that were established using a legacy auth more clear. ===== 5.5 FullID Payload The FullID Payload, denoted FullID in this memo, allows peers to identify themselves, and to indicate to whom they believe they are speaking. The FullID Payload appears in messages 3 and 4, and names the identity associated with the AUTH payload. The FullID Payload consists of the IKE generic header followed by identification fields as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! me-ID Type ! You-ID Type ! me-public key length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! me-ID length ! you-public key length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! algorithm ! ! +-+-+-+-+-+-+-+-+ + ~ Me-public key (RFC 3110/2536 format) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Me-Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! algorithm ! ! +-+-+-+-+-+-+-+-+ + ! ! ~ You-public key (RFC 3110/2536 format) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ You-Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: FullID Payload Format o Me/You ID Type (1 octet) - Specifies the type of Identification being used. o RESERVED - MUST be sent as zero; MUST be ignored. o Me-public key length - the length in bytes of my public key section, including the algorithm byte. o Me-ID length - the length of the Me-Identification section. o You-public key length - the length in bytes of the public key I expect you to use, zero, if the initiator doesn't not know. The length includes the algorithm byte. o algorithm - as per section 3.2 of RFC2525 (or its successor) o Me/You-public key. An RSA or DSA key, in RFC3110 or RFC2536 format. (i.e. 1 byte for exponent size, that many bytes of exponent, and the rest is modulus). o Me/You-Identification Data (variable length) - Value, as indicated by the Identification Type. The length of the You-Identification Data is computed from the size in the ID payload header, subtracting the other three field sizes. The payload type for the Identification Payload is XXXX. ****This should not be 5; that is, we should not re-use the payload number from IKEv1's Identity payload.***** The following table lists the assigned values for the FullID Type field, followed by a description of the Identification Data which follows: The payload's format is an ID type followed by the content. The ID types are: ID Type Value ------- ----- RESERVED 0 PKIX certificate 1 A standalone PKIX certificate. Certificate bundle 2 A simple ASN.1 sequence of PKIX certificates. A bundle can have end-entity certificates and/or certificates from a chain to a root. The first certificate in the bundle is the sender's preferred identity certificate, but beyond that there is no meaning to the ordering. Hash-and-URL of PKIX certificate 3 The first 20 octets are the SHA-1 hash of a certificate; the rest is a URL that resolves to the certificate. This is described in more detail below. URL to a PKIX certificate bundle 4 This is described in more detail below. PKIX keyIdentifier 5 Identifies a self-signed certificate that the receiver has already pre-loaded. Note that this is only useful when using self-signed certificates. IDForSharedSecret 6 This is only for use with shared secrets. It is an ASCII string (all octets are 31 < x < 127) of any length. DNS name 7 A fully qualified DNS name at which an IPSECKEY record will be found. DNSSEC will authenticate the data. If the length of this field is zero, then the value found in the Identity payload is used if appropriate. (i.e. it must be ID_FQDN, ID_RFC822_ADDR, ID_IPV4_ADDR, or ID_IPV6_ADDR. ID_RFC822_ADDR is converted to a domain by converting the @ to a period) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPgzuC4qHRg3pndX9AQEH7gP/Z3fnJF57atzcaKA6pR1lorRdLYximzrT fzXYDOeZmdUIs18F4etzZQc7TAPVXgBQo56G2kXyQknUdVROrSIa8kjo35iPXJGo l4j75yEFMpbVtdgltCPl9v3gxmselCAdtJn2q0zlUGNV3kmjnBHdGIL1uxq8TZaN PS4ASYtEM1Q= =Nifj -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Dec 29 14:36:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBTMalo19346; Sun, 29 Dec 2002 14:36:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27123 Sun, 29 Dec 2002 16:55:35 -0500 (EST) Message-Id: <200212292156.gBTLuj0d000415@fatty.lounge.org> To: Hugo Krawczyk Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: Your message of "Sat, 21 Dec 2002 02:30:48 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <380.1041198800.1@tibernian.com> Date: Sun, 29 Dec 2002 13:56:45 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, The problem with using EAP (that SLA doesn't have) is that EAP all by itself is a perfectly legitimate way to do good, strong, mutual authentication and therefore it is easy to launch the authentication binding attack by inducing the client to speak that EAP method all by itself. Quite a few EAP methods-- EAP-SIM for instance-- provide mutual authentication (and key generation) and speaking EAP-SIM by itself is a perfectly legitimate thing to do. SIM cards are used in mobile phones and in wireless NIC cards today. They'll be used in more things tomorrow. The more they're used the more willing a client will be to speak EAP-SIM all by itself, and therefore the easier it will be for an attacker to tunnel it to a server who is only willing to speak a tunneled version of EAP-SIM. Ditto for EAP-TLS. (And yes, there are implementations today that do EAP-TLS-encapsulated EAP-TLS). But how could someone be induced into encapsulating its legacay authentication protocol in some format that is specific for SLA and thereby enable the authentication binding attack on it? It is not a legitimate authentication encapsulation all by itself. The authentication binding attack is possible on SLA only if the client is doing something that she should not be doing in the first place-- like providing her credentials to anyone who asks. It's possible for anything to be attacked if the client is doing something insecure! A password of "password", a PIN for a token card written on a the token card itself. In another email you wrote that in these attacks the attacker: "(a) impersonates the server to the client in the unprotected run (we are talking of legacy authentication methods that do NOT authenticate the server so this impersonation is possible)" Yes, it's possible. It's possible to write the PIN on the token card and leave it lying around and thereby leave one open to "attack". But we can't protect against things that are predicated on the client doing a patently insecure thing in the first place. It's possible to steal the contents of a locked car if the windows are down. Is that an "attack" against the lock, or does that, by itself, mean the lock is somehow ineffective? No, it means the owner did something stupid to eliminate the security afforded by other mechanisms. Dan. On Sat, 21 Dec 2002 02:30:48 +0200 you wrote > Paul, > > What you wrote below regarding the man-in-the-middle attacks is incorrect. > SLA with the use of "proprietary" payloads is susceptible to these > attacks exactly as if it used EAP payloads. It is actually the other way > around: these attacks may be a good reason to use EAP. > See more specific coments below. > > On Fri, 20 Dec 2002, Paul Hoffman / VPNC wrote: > > > At 12:52 PM -0800 12/20/02, William Dixon wrote: > > >Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC > > >? It seems you are re-inventing EAP types here. For every new or > > >different auth method type, you'd have to define a new one in the IKEv2 > > >spec. > > > > If we used EAP, we would be susceptible to the man-in-the-middle > > attack described at > > . > > > These attacks have nothing to do with EAP but with a mixed use of SAME > authentication credentials in unprotected and tunnel-protected runs (such as > the IKE-based tunnel that SLA would provide). > I am not going to explain the attacks here but I want to point out > that they are NOT due to EAP encapsulation. In particular, the CHRE > encapsulation in SLA would be susceptible to the SAME attacks. In > these attacks the attacker uses the unprotected run of the authentication > to obtain from the user responses to server-generated challenges. > Once the attacker obtains these responses from the legitimate user > it can go on and encapsulate these responses in CHRE payloads and > complete his man-in-the-middle atack against SLA. > > For those interested in this type of attacks see the above mentioned draft > and also the paper "Man-in-the-Middle in Tunnelled Authentication Protocols" > by N. Asokan and Valtteri Niemi and Kaisa Nyberg > http://eprint.iacr.org/2002/163/ > > > The "EAP and EAP-like problem" is being discussed in many places, and > > is one of the things that is holding up PIC as well. > > If that is a reason to hold up PIC then for the same reason you'll have to > hold up SLA. I suggest not to hold up any of these protocols on the basis of > these attacks (rather have clear language regarding the reasons for these > attacks and the essentially-limited scope of possible solutions). > It is up to the "legacy authentication" community to come up with solutions t >o > these problems (which arise from the essentially-insecure use of credentials > in mixed protected/unprotected environments). Moreover, if you support EAP > exchanges and the EAP community comes up with measures to alleviate these > attacks in the context of EAP then you get the benefits of this solution > automatically. If you do CHRE then you don't. > > That's a good reason to support EAP in SLA. > > And it is not the only benefit: > There is a lot of deployment of EAP and the definition of authentication > mechanisms over EAP can be (and is) done independently of IKE. In my > view, it is better to leave these definitions in the hands of people > (such as the EAP WG) that specifically care about transport of client > authentication. If you rely on EAP then all you have to care about is to > build a sound tunneling mechanism for EAP in the context of IKEv2 > (rather than bulding profiles that depend on the specifics of secure-id, > radius, etc.) And, as said, the EAP guys are better suited to take care of > problems in the "legacy authentication" world such as the above "man in the > middle attacks" against tunneled authentication that have been a concern > lately in this community. > > And adopting EAP into SLA is easy, just copy PIC. > > > > > > Dan and Derrell decided that the danger of mis-use of EAP was more > > worrisome than the need for automatic extensibility. Note that SLA > > already covers all of the methods that are covered by XAUTH, and > > there haven't been any calls in a quite a while for new XAUTH methods. > > SInce this decision is justified on the basis of a wrong assumption (i.e. tha >t > the mitm atacks work against EAP and not SLA) then this whole conclusion need >s > to be revised as suggested above. > > Hugo > > > > > --Paul Hoffman, Director > > --VPN Consortium > > > From owner-ipsec@lists.tislabs.com Mon Dec 30 08:41:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBUGfCo27955; Mon, 30 Dec 2002 08:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28782 Mon, 30 Dec 2002 11:08:04 -0500 (EST) Message-Id: <5.1.0.14.0.20021227164656.045fe700@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 27 Dec 2002 17:19:40 -0500 To: Stephen Kent From: David Jablon Subject: Re: Secure legacy authentication for IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.0.14.0.20021220184329.00a2aac0@pop.theworld.com> <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> <5.1.0.14.0.20021219134708.00a55b00@pop.theworld.com> <5.1.0.14.0.20021220184329.00a2aac0@pop.theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:12 PM 12/23/02 -0500, Stephen Kent wrote: >We need to be able to make statement about the security of the key material used for packet confidentiality and packet integrity irrespective of the peer authentication mechanism chosen. To do otherwise would unduly complicate the overall system. That's why the current separation is desirable. That part of your reply seems reasonable. I'll attempt to describe a simple change that cannot possibly degrade any security analysis of the existing system, that can be used to provide an added layer of security when using legacy credentials, and that maintains the necessary cryptographic isolation. -- David From owner-ipsec@lists.tislabs.com Mon Dec 30 09:06:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBUH6Go28402; Mon, 30 Dec 2002 09:06:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28862 Mon, 30 Dec 2002 11:41:17 -0500 (EST) Message-ID: <82CC1E573B94A648B87027C9419E2C0516C36C@losgatos> From: Michael Choung Shieh To: ipsec Subject: Out of Office AutoReply: End Sitestat4 code Date: Mon, 30 Dec 2002 08:39:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am taking vacation from 12/20/02 to 12/29/02. I will be back to office on 12/30/02. Please forward all urgent project issues to Shih-Ho to quick resolution. From owner-ipsec@lists.tislabs.com Mon Dec 30 12:09:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBUK93o09587; Mon, 30 Dec 2002 12:09:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29376 Mon, 30 Dec 2002 14:39:04 -0500 (EST) Message-Id: <5.2.0.9.2.20021230143009.00ba5388@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Dec 2002 14:40:28 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Counter Mode: Proposed Way Forward In-Reply-To: <5.2.0.9.2.20021127191422.00b82a78@mail.binhost.com> References: <15845.1606.961113.340051@pkoning.dev.equallogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I updated the AES Counter Mode draft. It should be posted as soon as the repository administrator returns from the holiday break. The document describes the use of a nonce as previously discussed on the list. And, a new section describes the way that IKE can provide the nonce. This is the only part that has not already been discussed on the list, so I am posting it here to foster discussion. 5. IKE Conventions As described in section 2.1, implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) [IKE] protocol can be used to establish fresh keys. IKE can also provide the nonce value. This section describes the conventions for obtaining the unpredictable nonce from IKE. The IKE_SA_init and the IKE_SA_init_response each contain a nonce. These nonces are used as inputs to cryptographic functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain nonces. These nonces are used to add freshness to keys for child security associations. In both cases, these nonces are unpredictable, they are longer than 32 bits, and IKE transfers the nonce value to the peer. Each party will use the nonce that it generated for encryption, and the nonce that the other party generated for decryption. The 32 least significant bits of the nonce used to establish the security association will be used in the AES-CTR counter block. For the first security association, the nonces come from the IKE_SA_init and IKE_SA_init_response. For subsequent security associations, the nonces come from the CREATE_CHILD_SA request and CREATE_CHILD_SA response. Enjoy, Russ From owner-ipsec@lists.tislabs.com Mon Dec 30 13:27:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBULRWo14260; Mon, 30 Dec 2002 13:27:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29527 Mon, 30 Dec 2002 15:56:49 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: Authentication methods in IKEv2 To: ipsec@lists.tislabs.com Cc: Michael Richardson X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sun, 29 Dec 2002 21:59:42 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 12/30/2002 03:57:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You're describing a different problem than the one addressed by the proposed solution. The proposal was for the negotiation of authentication methods (e.g. X.509 cert or SecurID # or Password). That was the case I claimed was unusual. You're trying to handle the case of negotiation of which of several keys is used with a single authentication method. While I agree this would be a nice feature, it's not supported today with or without authentication method negotiation. If we wanted to support such a capability, I think the appropriate syntax would be to have something like a CERTREQ payload that instead of stating what certifiers I trust states what key(s) I would like you to use in creating the AUTH payload. Do people think such a capability should be added? --Charlie > >>>>> "Charlie" == Charlie Kaufman writes: > Charlie> At 11:45 AM +0300 11/11/02, Valery Smyslov wrote: > >> I have some doubts about using of authentication methods in IKEv2. > >> In IKEv2 negotiation of authentication methods was completely > >> removed - each side simply uses his/her favourite method. > >> I think this may lead to the lack of interoperability and extensibility > >> in case one of the endpoints supports more than one method of > >> authentication. > > Charlie> A problem only occurs when one or both sides have > multiple different keys > Charlie> (or different ways of using the keys) with which they > could authenticate. I > Charlie> would expect this case to be unusual, but it certainly > could happen. If it > > The situation is not unusual. > > Any system that generates new public keys regularly will have multiple keys > that it could use. Combined with the fact that many directory systems are not > instantaeous, and you have a wave effect, that reminds me of how light/sound > propogates. From owner-ipsec@lists.tislabs.com Mon Dec 30 13:27:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBULRio14299; Mon, 30 Dec 2002 13:27:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29523 Mon, 30 Dec 2002 15:56:46 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: IKEv2: SA attribute processing rules To: "William Dixon" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Message-ID: Date: Sun, 29 Dec 2002 19:58:14 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 12/30/2002 03:57:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm confused by a number of your suggestions... specific responses below: > A.) How to handle unrecognized attribute types, I suggest text: > "An unrecognized transform attribute type MUST be ignored. If no SA > attributes are recognized, then the negotiation MUST fail." What version of the spec are you reading? I don't think transform attributes are there anymore. The document does say that unrecognized payload types MUST be ignored (unless marked critical). I thought it was clear that unrecognized suite IDs MUST be ignored, but I added text saying it again. > B.) Gap in private use range. Some questions come up from this text: > "values 2-65000 are reserved to IANA. Values 65501-65533 are for private > use among mutually consenting parties." > - did the authors purposely skip the range 65001 through 65500 ? If so, > I assume this was done to allow implementers of IKEv1 to continue to use > their private identifiers that may have been chosen in the omitted > range. But it leaves implementers in a weird spot if they do what to > use 65001, which is neither allocated for private use nor assigned to > IANA. This was just a typo; I fixed it. > C.) Regarding how we indicate "mutually consenting parties". Common > practice is to use the vendor-ID, and so we should be clear and say that > this is the method used when administrative configuration permits the > advertisement of such consent. Section 5.12 Vendor ID discussion talks > about this, but note that it prohibits making assumptions on what the > peer may accept, and mandates that the initiator always know what the > peer is willing to accept before sending it private use ranges. > However, this prohibits the use of private use ranges in the SA > attributes...: You're right; the current text is too restrictive. vendor ID should be allowed to disambiguate private use numbers. > D.) No real clarification on SA attribute handling. I'm surprised that > we are not taking the opportunity in IKEv2 to clean up the confusion > about the IKEv1 SA attributes having different definitions for Phase I > and Phase 2. Phase 1 is defined in the IKEv1 appendix A. Phase 2 is > defined in the DOI with different SA attribute type numbers. For > example, the DH Group Description is defined to be 4 in Phase I, but 3 > in Phase 2 in the DOI (unless you realize that you're using quick mode > PFS and the group is really the same as in Phase 1...) I don't see a > reason why the IKEv2 can't fix this to have one list of attribute types. > I haven't studied this enough to see if IKEv2 solved the problem of > being able to negotiate PFS, but it should. > > My impression is that the current IKEv2 draft is missing it's goal of > making IKE easier to analyze and implement by not clearly describing how > to negotiate (what it means to include, omit, and accept) each SA > attribute and the ordering of these attributes in terms of having a > predictable outcome when processing two lists of preferences. To > implement IKEv2 SA attribute processing correctly, you must now analyze > text in 4 documents: IKEv2, IKEv1, ISAKMP, and the DOI, and still guess > whether the peer is going to fail the negotiation, and guess at what the > outcome will be. A am mystified as to what you're talking about. It is a goal of the IKEv2 spec that it have no normative references to IKEv1, ISAKMP, or the DOI. Could you give an example of ambiguity? > E.) Implied requirement for 1536, should be 2048 or 3072. The example > suite given suggests that DH1536 would be a "default". It doesn't say > whether it's a MUST support. I think we need something greater than > DH1024, but why does IKEv2 need to specify it ? Given the strength > calculation in Tero's MODP draft, DH1536 supports by one calculation > only 90bits entropy, which is still much less than 3DES ~112bits entropy > (from Schneier's Applied Cryptography) which is included in that suite, > and insuffient for keying 128bit AES. So DH2048 or DH3072 should be the > choice to ensure IKE DH is not the weakest point, and thus force the > attack to the 3DES keys, which of course is being rekeyed far more often > than the DH is generated in most cases. This has been extensively debated, with no clear resolution. What I think I heard was that there should be multiple required suites with sizes ranging from 1024 to 2048. The reason to require more than one is that if there is a single required suite everyone will tend to use it. If it's 1024, IKEv2 will be criticized as insecure. If it's 2048, IKEv2 will be criticized for being slow. I'm concerned that if there are multiple required suites that it will be criticized for being complex. I'm not sure what to put in the next draft, but I don't expect people to be happy whatever it is. > F.) Be clear what fails the negotiation and what doesn't. When that > same section talks about Reserved-MBZ: "a proposal containing a non-zero > value MUST NOT be accepted.", it's not clear whether this means fail the > negotiation if it isn't, or ignore the value. This means reject/ignore the proposal. The negotiation may still succeed if there is another acceptable proposal. I have added text to that effect. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Dec 30 14:26:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBUMQCo19289; Mon, 30 Dec 2002 14:26:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29653 Mon, 30 Dec 2002 16:56:20 -0500 (EST) From: Yogesh.Swami@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Making JFK DOS resilient for Message-3 Date: Mon, 30 Dec 2002 15:56:58 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CEC72464@daebe004.americas.nokia.com> Thread-Topic: Making JFK DOS resilient for Message-3 Thread-Index: AcKwTl+rhdIRWuH2QFeJf+Gu+8Hpjg== To: , , , , , , Cc: X-OriginalArrivalTime: 30 Dec 2002 21:56:59.0264 (UTC) FILETIME=[607E9000:01C2B04E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA29650 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a few comments on the JFK draft: JFK does a great job for DOS protection against blind attacks and it also makes the right engineering compromises by defining a PFS interval, however the message 3 of JFK is still prone to DOS attacks by an attacker who can eavesdrop on the channel. Fortunately, it's possible to counter that attack also without requiring any changes to the protocol, except for adding one more piece of information in message-3. Let me first explain the attack and then how to counter it. Let's say Alice wants to establish a secure channel with Bob, and Eve is capable of eavesdropping on their channel. Let's also assume that the round trip time between Bob and Eve is much shorter than the round-trip time between Bob and Alice (Eve could potentially be on the same LAN as Bob). Since Eve can see all messages coming from Bob, she is capable of collecting the following information based on Message-1 and Message-2: Ni, Nr, g^r, g^i, IPi, GRPINFOr, HMAC{HKr}(g^r, Nr, Ni, IPi) ( Note that snooping on Message-2 alone is not sufficient since g^i is not returned by Bob. By the way (BTW), why should Message-1 contain g^i? In message-2, the HMAC does not cover g^i. This can cause some problems--in the proof of the protocol the HMAC does cover g^i--but I will send a separate e-mail for this. ) Having collected this information, Eve can now fabricate a message-3 as follows: Fake-Message-3(k,j): Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi), Garbage(k), Garbage(j) Please note that IPi is sent in clear in Message-1, and therefore the authenticator alone cannot prevent Eve from sending a valid message before one complete round trip (it's still needed in the authenticator for cookie jar). Eve can now flood Bob with several Fake-Message-3(k,j) in which she copies the authenticator, IPi, etc., that she had snooped, and fills the rest of the fields with garbage for different values of (k,j). For example, Eve can send 1000 copies of Message-3 to Bob with the same HMAC but different Garbage(j,k). Note that Alice needs to sign some fields in Message-3, and the keys for signing the document *might* reside on a separate server. This means that there could be considerable delay (~sec) from the time when Bob sends Message-2 and receives Message-3. During this time, Eve can generate a large number of Fake-Message-3 and send it to Bob. When Bob receives Fake-Message-3, he will find the authenticator intact, so he will proceed with calculating Ke and Ka. Unfortunately, calculating Ke and Ka will require DH exponentiation. After performing the DH exponentiation, Bob will try to verify the identity of Alice, and he will try to decrypt Garbage(i) and Garbage(j) only to find that the identities do not match. Unfortunately by this time it would be too late because Eve would have forced Bob to unnecessarily compute the DH exponential. As the draft suggests, Bob will mark this connection as one which has some trouble, but it cannot do anything more than that. Bob, for example, cannot say that he will not process future Message-3 with the same authenticator. Doing so will allow Eve to prevent Alice from communicating with Bob since Eve can always send Message-3 before Alice can. In fact, Bob has no other option than to move to the next message Fake-Message-3(k+1, j+1) and run the same exponentiation again and again until he finally receives a legitimate Message-3 from Alice. This is a typical down side of stateless mechanism--yet its worth keeping ... Read on ... Please also note that if Alice's Message-3 gets lost in the network (or Alice crashes and reboots), Eve will have one complete PFS interval to keep sending Fake-Message-3. This could be potentially exhausting to Bob if the PFS interval is large. To summarize, There are two problems with this: a) Bob will run out of computation resources if Eve could send sufficiently many Fake-Message-3 before Alice's Message-3 arrives, and b) Alice will receive several identity-match-failure messages, and depending upon how agile she is (wants to be), she might try to initiate new SAs for each rejection. BTW, the draft should mention that if Message-3 is rejected, then Bob MUST echo back Ni in Message-4 so that if new rejects with same Nis arrive to Alice, she does not immediately start new key exchange. In addition, Bob must also send a valid proof for his own identity for the rejected message, otherwise Eve can send a reject message on behalf of Bob and prevent Alice from communicating with Bob. Fortunately, its possible to counter this DOS attack without having to change anything, expect for adding one more piece of (64-128bit) information in Message-3. The basic idea is that Alice must provide a computationally inexpensive proof in Message-3 that can convince Bob that Ni came from Alice, and Alice alone. Once Bob has this information, he has evidence *beyond reasonable doubt* to go ahead and compute the exponentials. This is how Alice can prove this (this protocol can be used with any DH scheme that uses cookies to avoid DOS attack): Message-1 (Alice->Bob) : Instead of generating *any* random number Ni, Alice should generate Ni as follows: Ni = HMAC{rand_key}(IPi|IPr|rand_key) In other words, Alice generates a random number rand_key, and uses that number as a key to compute the HMAC on the concatenation of the IP addresses and the rand_key itself. Alice then sends Message-1 as usual. Alice MUST keep rand_key and Ni in a table because she will later need this in Message-3 (this is not a threat). Message-2 (Bob->Alice): Bob returns the Message-2 as before, computing the HMAC as usual. No new processing/states for Bob. When Alice receives Message-2 from Bob, she must return all the usual information in Message-3, but she must also send back rand_key--in plain text!--to Bob. In other words, Message-3 will now look like: Message-3 (Alice->Bob): rand_key, Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi) When bob receives Message-3, he should first calculate, HMAC{HKr}(g^r, Nr, Ni, IPi) .... (1) and verify that it matches with the value of authenticator returned. If it does, then Bob should compute: HMAC{rand_key}(IPi|IPr|rand_key) == Ni .... (2) If the above expression also matches, Bob should compute the DH exponential. If either (1) or (2) fails to match, Bob should reject the message-3, but he *should not* inform Alice about it. Why should this seemingly stupid protocol that sends keys in plain text work? The reason it works is because Eve does not know about rand_key, and therefore she cannot return the rand_key in Message-3. Since Bob verifies (equation-2) that Ni was calculated using the right HMAC, He can discard those messages where it does not match and this way he can prevent himself from computing the exponential. What if Eve tries to respond with a fake value of Ni computed with her own rand_key. Well, the HMAC{HKr}(g^r, Nr, Ni, IPi) in (1) will not match and Bob can safely reject the message even in that case. There is, however, a potential problem. Let's say Alice's Message-3 reaches Eve, but gets lost/dropped after that. This can happen since Alice is using UDP (using TCP does not help either; Eve can see the TCP sequence number in clear...). In that case, Eve can send the right key, rand_key, and Bob will have to compute the DH exponential. Bob can however prevent himself from computing a large number of exponentials in this case. If Bob finds that Ni's and HMAC{rand_key}[*] match, but the signed document does not, he can mark such a connection as "In Trouble," and stop processing all future message with the same authenticator returned in Message-3. In addition, Bob can ask Alice to re-initiate key exchange. In present JFK protocol, Bob could not have rejected all future messages because Eve could have always sent a message before Alice, potentially denying Alice the access to Bob. But now for Eve's attack to be successful, she must somehow get Alice's packet dropped. Getting Alice's packet dropped is beyond the control of Eve (if Eve can control packet dropping, she can drop Message-1 itself, preventing Alice from communicating with Bob. She does not have to do all this eavesdropping acrobatics in that case) and therefore her attack will be successful only if packets are dropped even the second time. Please note that if Alice's packet is lost in the network before Eve sees it, then Eve cannot take advantage of a longer PFS interval because Bob will never compute the exponentials. It's possible to make this protocol resilient to packet loss also by adding a few extra "tricks," but that would require more computation, so I will not describe it...(besides this e-mail is already too long. Apologies ...) To make this protocol robust to packet reordering that can happen between Alice and Eve, Bob should not immediately stop processing the DH exponential if the Ni's match but the signatures don't. He should process at least 3 messages before marking the packet as "In Trouble." If Bob is under-loaded he can process a few more than 3 messages. JFK is a very nice protocol; I hope it totally replaces all IKEvXYZ. JFK draft does however requires a few more paragraphs on how to reject messages. Don't forget that rejecting a key initiation is as big a decision as accepting it, and it should too get it's fair share of attention. If rejection details are left unmentioned, there might be interpretability problems later on. Please let me know what you think. --Yogesh From owner-ipsec@lists.tislabs.com Mon Dec 30 14:39:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBUMdno19627; Mon, 30 Dec 2002 14:39:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29668 Mon, 30 Dec 2002 17:10:28 -0500 (EST) Message-Id: <5.2.0.9.2.20021230164012.02755548@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 30 Dec 2002 17:11:30 -0500 To: "William Dixon" From: Russ Housley Subject: Re: IKEv2: SA attribute processing rules Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William: >The following topics are addressed in this mail for IKEv2: > >A.) How to handle unrecognized attribute types >B.) Gap in private use range >C.) Regarding how we indicate "mutually consenting parties" - vendor ID >can't be used. >D.) No real clarification on SA attribute handling >E.) Implied requirement for 1536, should be 2048 or 3072. >F.) Be clear what fails the negotiation and what doesn't. I agree with the bulk of your comments. However, I do want to respond to item E. >E.) Implied requirement for 1536, should be 2048 or 3072. The example >suite given suggests that DH1536 would be a "default". It doesn't say >whether it's a MUST support. I think we need something greater than >DH1024, but why does IKEv2 need to specify it ? Given the strength >calculation in Tero's MODP draft, DH1536 supports by one calculation >only 90bits entropy, which is still much less than 3DES ~112bits entropy >(from Schneier's Applied Cryptography) which is included in that suite, >and insuffient for keying 128bit AES. So DH2048 or DH3072 should be the >choice to ensure IKE DH is not the weakest point, and thus force the >attack to the 3DES keys, which of course is being rekeyed far more often >than the DH is generated in most cases. There has been some discussion of this in a separate thread, but it has not reached an obvious conclusion. However, I want to correct one aspect of your description. Maybe you already understand this, and you used loose wording, but I know that many people miss this important point. If one wants, say, 80 bits of protection, then it is appropriate to select mechanisms that each provide this level of protection, or more. Achieving 80-bit security would allow many choices: Diffie-Hellman: 1024, 1280, 1536, 2048, and so on Encryption: 3DES, AES-128, AES-192, AES-256, others Alternatively, if one want 90 bits of protection, as you point out, Diffie-Hellman with 1024-bit keys is no longer appropriate, but all of the encryption algorithm alternatives are still viable. One would not normally select a symmetric cipher that provides exactly desired protection. There are not that many quality algorithms floating around, each with different key sizes. Although there are a few that take variable length keys, these are not the most widely adopted by teh IPsec community. Further, it is not a good practice to roll your own symmetric cipher. It is not likely to be secure, and even if it is secure, it is not likely to be widely implemented. For this reason, one normally selects a symmetric cipher that is well known, widely implemented, and provides adequate performance. For this reason, I expect to see movement from 3DES to AES-128. Not because 112 bits of security is problematic, rather because AES is fast. More security and fewer cycles. The Diffie-Hellman key size selection is different. One choose exactly the desired level of protection, without the same interoperability concerns. Yet, there is a huge performance penalty for selecting a bigger key than necessary. Some hardware implementations may have a maximum buffer size, and many of these will resort to software if the hardware buffer size is exceeded. This means that there is a huge performance cliff if the hardware buffer size is exceeded. In summary, one should select the fastest, widely deployed, well studied symmetric cipher that exceeds the security requirements; however, one should select the Diffie-Hellman key size that provides the desired security, and no more. So, what should IKEv2 impose as the MUST implement Diffie-Hellman key sizes? In my opinion, 1024 should be on the list for backward compatibility with the currently fielded devices. Further, either 1280 of 1536 should be required. This allows us to move incrementally forward, without imposing a huge performance hit. Of course, support for even bigger keys is encouraged, but not required. Russ From owner-ipsec@lists.tislabs.com Mon Dec 30 15:53:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBUNrMo22970; Mon, 30 Dec 2002 15:53:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29818 Mon, 30 Dec 2002 18:24:02 -0500 (EST) Date: Tue, 31 Dec 2002 01:25:27 +0200 (IST) From: Hugo Krawczyk To: David Jablon cc: IPsec WG Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: <5.1.0.14.0.20021224092945.00a51260@pop.theworld.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 27 Dec 2002, David Jablon wrote: > Regarding the "points of agreement" summary, some points of > disagreement in the presentation of (5) on the use of key material > are noted below. > > At 01:23 AM 12/24/02 +0200, Hugo Krawczyk wrote: > >Derrell, based on your messages and other recent traffic on the list on > >this issues I think that we can summarize several points of agreement > >as follows: (what do other think?) > > > >(1) do not mandate SLA in IKEv2 > >(2) leave SLA as a separate document > >(3) advance IKEv2 and SLA concurrently in the standards process > > > >(4) replace the CHRE formats with standarized EAP transport > > > >(5) regarding MitM attacks due to the use of mixed protected/unprotected > >runs of the legacy authentication, the WG has to decide on one of two ways to > >go: > > > > (a) do not do anything about solving the problem in SLA. This has > > several possible justifications: > > > > - assume (as you said in a previous message) that the mixed authentication > > scenario does not occur in ipsec > > [this would probably require more feedback from the list] > > > > - assume that even if some mixed authentication scenarios do show up > > in the ipsec world it is due to a BAD PRACTICE that should be abandoned > > (not a sin that SLA needs to help washing) > > > > - be "respectful" to people that use mixed authentication but tell them to > > look for a solution elsewhere (at the legacy authentication layer or as a > > generic mechansims on top of EAP, for example). > > > > (b) allow for an optional mixing of key material derived from SLA and from > > the underlying authentication method in the key derivation procedure of > > SLA. This is a solution of limited scope (assumes that the legacy > > authentication produces a key and that the key can be made available to > > SLA) and it does not address at all the dangers of dictionary attacks if > > the legacy authentication is based on password (or other low-entropy > > keys). It also constitutes (as someone said) a logical layer violation. > > In (5)(b), it seems more appropriate to characterize as "limited scope" > the choice to NOT permit use of optional authenticated key material. I don't understand your intention here. Choice 5(b) is the one that DOES support the use of optional authenticated key material and it IS of limited scope as explained in the parentheses above. So what is more (or less) appropriate here? > > Problems arise when the concept of "SLA" is limited to > "legacy methods for authentication that do not produce key material", > rather than the more broadly useful > "authentication methods that use legacy credentials". I do not agree. The problem is really with legacy authentication *protocols*, not with legacy *credentials*. If you let me re-design even the most basic of pswd authentication protocols such as CHAP I will do it in a way that will change the protocol very slightly (and will use passwds the same way CHAP uses now) but will make the modified protocol resistant to the MitM attacks we were discussing here. How? Simply put under the response computation the name of the server with which you are comunicating and (if possible) the name of the tunnel protocol under which the protocol is run (with a special "protocol name" for "no tunneling"). Needless to say this does not resolve dictionary attacks if the protocol is run unprotected but that is something that NO solution can avoid (except of course for NOT running the protocol unprotected or for switching to dictionary-attack resistant methods (which exist of course but not as "legacy"). In other words, it is easy to build future or modified protocols using legacy credentials that are not susceptible to the discussed MitM attacks. The problem is only with existing protocols (not with legacy credentials per se). > Not all such methods are alike, so why shouldn't the solution > be able to leverage the best qualities of any method? > This is the usual generality/security/complexity trade-off discussion. We all prefer to be beautiful and rich than ugly and poor. Here unfortunately we cannot get it all and will have to decide where to pay the cost and where to compromise. It is up to the WG to decide which trade-offs are preferred. If you have a "beautiful and rich" solution, please suggest it. Everyone will be happy to accept it. > As to whether using available key material constitutes a "layer violation", > I'd say the alternative is clearly the larger crime. Choosing to discard > authenticated keying material, instead of binding it in some way to the > session key, violates several important security principles. > This is not so black and white: if you "mix" keys from two protocols you have to make sure that these keys were not used in their "parent protocol" for functionalities that conflict with their use in the mix (e.g. making sure you do not use for MACing a key that the parent-protocol used for encryption). Actually, the whole issue of "importing" and "exporting" keys is problematic, especially if the tunneling protocol wants to use the underlying authentication in a black-box manner. Abandoning this black-box apprach can be considered but it has a generality and complexity penalty. > A key-producing SLA method may well address "dictionary attack", > and key binding can prevent other MitM attacks that may otherwise > occur when using server-only authenticated keys. > > As for the summary of (5)(a), none of the "possible justifications" > presented justifies the "do nothing" approach, because the ramifications > of such a decision go beyond the lone issue of "MitM attacks due > to mixed protected/unprotected runs" as presented. Please explain these ramifications. I cannot see how these attacks go beyond the mixed protected/unprotected runs. (Or how a compound authentication as we are discussing resolves any issue beyond these attacks). Hugo > > -- David > > > From owner-ipsec@lists.tislabs.com Mon Dec 30 16:24:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBV0O7o23860; Mon, 30 Dec 2002 16:24:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29868 Mon, 30 Dec 2002 18:56:07 -0500 (EST) Date: Tue, 31 Dec 2002 01:58:08 +0200 (IST) From: Hugo Krawczyk To: Dan Harkins cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: <200212292156.gBTLuj0d000415@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Are you claiming, for example, that SLA-OTP is not susceptible to MitM attacks if the same passwords are used under EAP-OTP (same for CHAP, secure-ID, etc)? Or is there something special about EAP-SIM (which I am not familiar with) on which you base your argument below? In any case, if you consider legacy methods such as CHAP, OTP etc then the use of EAP-CHAP, EAP-OTP, etc in mixed protected/unprotected runs is insecure with SLA regardless of the "wrapping" mechanism you use to transport the authentication information in SLA (i.e it makes no difference for the sake of these MitM attacks if you have specialized formats or use EAP in SLA). Note that the fact that the unprotected run wraps the chalenges and responses under a EAP construct does not mean that the attacker cannot unwrap this information and re-format it under SLA. For example, if you talk EAP-OTP in the clear then I can attack the "protected" SLA-OTP simply by reading the one-time-pad from the unprotected EAP-OTP run. Once I have that otp, SLA has nothing to do to protect the server against impersonation. If you agree with the above and still keep your objections against using EAP then please explain again why. Regarding "stupid practices" see below On Sun, 29 Dec 2002, Dan Harkins wrote: > Hugo, > > The problem with using EAP (that SLA doesn't have) is that EAP all > by itself is a perfectly legitimate way to do good, strong, mutual > authentication and therefore it is easy to launch the authentication > binding attack by inducing the client to speak that EAP method all > by itself. > > Quite a few EAP methods-- EAP-SIM for instance-- provide mutual > authentication (and key generation) and speaking EAP-SIM by itself is > a perfectly legitimate thing to do. SIM cards are used in mobile > phones and in wireless NIC cards today. They'll be used in more things > tomorrow. The more they're used the more willing a client will be > to speak EAP-SIM all by itself, and therefore the easier it will be > for an attacker to tunnel it to a server who is only willing to speak > a tunneled version of EAP-SIM. Ditto for EAP-TLS. (And yes, there are > implementations today that do EAP-TLS-encapsulated EAP-TLS). > > But how could someone be induced into encapsulating its legacay > authentication protocol in some format that is specific for SLA and > thereby enable the authentication binding attack on it? It is > not a legitimate authentication encapsulation all by itself. > > The authentication binding attack is possible on SLA only if the > client is doing something that she should not be doing in the first > place-- like providing her credentials to anyone who asks. It's > possible for anything to be attacked if the client is doing something > insecure! A password of "password", a PIN for a token card written on > a the token card itself. > > In another email you wrote that in these attacks the attacker: > > "(a) impersonates the server to the client in the unprotected run (we are > talking of legacy authentication methods that do NOT authenticate the > server so this impersonation is possible)" > > Yes, it's possible. It's possible to write the PIN on the token card > and leave it lying around and thereby leave one open to "attack". But > we can't protect against things that are predicated on the client > doing a patently insecure thing in the first place. It's possible to > steal the contents of a locked car if the windows are down. Is that > an "attack" against the lock, or does that, by itself, mean the lock > is somehow ineffective? No, it means the owner did something stupid > to eliminate the security afforded by other mechanisms. I am not sure what exactly you are ridiculizing here. Are you saying that the mixed protected/unprotected runs we are discussing are a "stupid practice" and then there is no reason for us to address them? This is indeed one of the options I enumerated in a previous email for solving (or not solving) this issue. On the other hand, I guess that many people using legacy authentication may want to keep the "stupid practice" of mixed runs and get as much defense as they can in the protected runs. In one way or another I do not see that the use of EAP in SLA makes things worse. Hugo > > Dan. From owner-ipsec@lists.tislabs.com Mon Dec 30 16:45:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBV0j9o24215; Mon, 30 Dec 2002 16:45:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29975 Mon, 30 Dec 2002 19:19:16 -0500 (EST) Date: Tue, 31 Dec 2002 02:21:14 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: identity-misbinding attack on SLA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In a message to this list on Dec 21st I referred to a possible cryptographic weakness in the design of SLA (draft-hoffman-sla-00.txt). The following discussion is intended to present the problem and to recommend a fix. This story should be of interest to those that care about the ikev2 design and not just to the SLA people. Indeed it has a moral that applies to the design of IKEv2 too (for your "enjoyment" I will follow with another message regarding some related issues in the more general IKEv2 setting). This message is LONG and can be safely skipped by those that do not care about the cryptographic design of ikev2 and SLA. Others please read this message (and the one that follows about changes to ikev2). For a more comprehensive explanation of these issues please refer to the SIGMA paper http://www.ee.technion.ac.il/~hugo/sigma.ps [.pdf] The SLA Protocol ================= The SLA (secure legacy authentication) protocol is described in draft-hoffman-sla-00.txt: the Initiator is a client machine C that uses the legacy authentication credentials of a user U to authenticate to a server S (an ipsec gateway, authentication server, etc) which acts as the responder. Messages 1 and 2 of SLA are: Initiator (client) Responder (server) ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, AUTH (The responder's AUTH payload is computed over all of message 1 concatenated with all of message 2.) The subsequent messages use the DH key g^xy (derived from KEi and KEr) to protect a legacy authentication from client C to server S. First note that the protocol as described above only works when the client machine knows in advance the identity AND certificate of the server. This assumption holds in some scenarios but certainly not in all remote user authentication cases. In many instances the client machine will not have the server's certificate but will rather have to receive the cert from the server itself (this cert is verified at the client on the basis of some verification PK and policy settings installed at the client). Moreover, in the general case there may be more than one server responding to the client's "call". Therefore (and as agreed by Paul Hoffman in a previous message) we will consider the augmented protocol where a cert (or identity) of the server is sent back to the client in message 2 (this identity goes in the clear, which is ok since we are not concerned with gateway's anonymity). The attack ========== For describing the attack let's assume two servers (or gateways), Sbad and Sgood, that may legitmately answer C's (the client) call (i.e. both servers have certs that C would accept as valid for running a legacy authentication under SLA). Now imagine that Sbad is controlled by an attacker, while Sgood behaves correctly. Assume that the first to respond to C's first message is Sgood who sends message 2 to C. Sbad intercepts this message, changes the cert of Sgood to its own cert, and replaces Sgood's signature with Sbad's. The rest of the message is unchaged. (Note that the message contains KEr as chosen by Sgood but this does not prevent Sbad from signing it.) The client receives the message from Sbad, checks Sbad's cert and signature, and follows with message 3. Sbad receives this message and relays it to Sgood as if it came from C. Sgood understands this as message 3 in its half-open session and follows with message 4 in the protocol. Sbad intercepts this message and sends it to C as if it originated from Sbad (the SLA message itself is not changed). Messages 5 to N in SLA are treated in the same way by Sbad (i.e. relayed unchanged between Sgood and C, except that the messages to C originated at Sgood are sent to C as coming from Sbad -- for example they are sent to C with the source IP address of Sbad). Consequences of the attack ========================== At the end of the protocol's run the situation is as follows: The honest server Sgood is convinced that it interacted and established an authenticated key g^xy with C. The client C, however, is convinced that this same authentication and key exchange session was run with Sbad (in particular C believes that the key g^xy and its derivatives are shared with Sbad). In other words, two honest parties to the exchange end the protocol with inconsistent views of who did they talk to. Sgood binds the exchange to C, while C binds the exchange to Sbad. This is a clear break of the "consistency" (or "mutual belief") requirement of any generally sound key exchange protocol. Note that this form of attack (discovered many years ago by Diffie-van Oorschot and Wiener in their famous STS paper) is not a standard MitM attack against the secrecy of the key but an attack against the authenticity of the exchange. In particular, traffic coming from Sgood and protected under the exchanged DH key is understood by C as originated at Sbad, while traffic sent from C and intended for Sbad is understood by Sgood as intended for Sgood. I refer to this type of attack as an "identity misbinding" attack; it is sometimes called in the literature "unknown key share" attack. (I called it the "triangle attack" in the SIGMA paper mentioned above but this name has already been used elsewhere for a different attack so I'll change the name to avoid confusion.) While this attack may have very bad consequences in many key exchange scenarios, its practical significance in the specific case of SLA is debatable. Yet, it is hard to confidently claim that this weakness cannot be exploited in the SLA context which is intended to work with a variety of different user authentication mechanisms. In particular, the fact that two honest parties, C and Sgood, generate inconsistent records of the exchange is something that one does not expect from a well designed key-exchange protocol. For example, C could make wrong policy decisions on the basis of the wrong server's identity (Sbad instead of Sgood). [A somewhat contrived example could work as follows: C's policy may dictate different forms of information sent when talking to Sgood or Sbad. For example, when talking to Sbad some confidential information is included that should not be sent if talking to Sgood. In the above case, however, C will unintentionally disclose this information to Sgood since C believes that it is talking to Sbad. One can argue that a misbehaving Sbad could directly pass this information on to Sgood. That is true, however this presumes some collaboration between Sbad and Sgood, and even then Sbad may not be able to convince Sgood that this information really came from C. However through the above attack Sgood gets this information directly from C, and authenticated by C!] Clearly, a weakness as above (if immediately exploitable or not) should not be a property of the protocol. What went wrong? ================ Why is this attack possible in spite of the signature of the server in message 2? Simply because signing the DH exponentials in an authenticated DH exchange is a NECESSARY BUT NOT SUFFICIENT authentication measure (see the sigma paper). What is missing for a consistent ("mutual belief") authentication is to BIND the DH key to the identity of the responder (server) in message 2. This can be achieved by adding a MAC computed on the responder's identity and keyed with (a derivative of) g^xy. It is important to note that in IKEv2 the above "identity misbinding attack" cannot occur. Indeed, when the responder authenticates to the initiator in message 4 of ikev2, there is a MAC computed on the responder's identity which guarantees the essential key-identity binding. The problem in ikev2 is that this MAC is not explicit: it is there as part of the SK{} processing that "happens" to include the responder's identity. I have criticiized this lack of explicitness in ikev2 as a "design robustness" problem, namely, it is easy to make apparently harmless changes to the protocol that break its security. This is especially plaussible since the SK{} processing which includes the binding MAC is usually seen as part of the encryption process that is needed only for identity protection, not for key-exchange authentication. This lack of robustness in IKEv2 is exemplified very clearly in the SLA design. The authors of SLA moved to message 2 what seemed to be the essence of the authentication in message 4 (namely, the signature) and did not care about the SK{} processing since identity protection was not an issue. Note: SLA has a strong similarity to IKEv1's signature-based aggressive mode and to PIC. Yet, the later protocols are not susceptible to the above attack since they include a secure key-identity binding via the prf (which also functions as a MAC) included under the signature (HASH-R in ikev1 terminology). The fix ======= There are several ways to go about solving these issues: 1) assume that the client is willing to talk to a single server for which the client knows the public key in advance. The above attack (which requires at least two potential servers as responders) will not work in this case. 2) do not assume 1 but consider the attack impractical in this setting. Do nothing to fix it. 3) Use ikev2 mechanism: add SK{} on top of message 2 (as in message 4). This however is not possible: you cannot encrypt message 2 in SLA. What you can do is to define something like SK*{} which would mean: MAC but do not encrypt. 4) Use IKEv1 mechanism: do not sign the message information direclty but first apply to this information (which includes the server id) a prf (or mac) with a key derived from g^xy and then sign the output of the prf. 5) Keep the signature as defined now but add to the signed information the value MAC(SK_ar, IDr) where SK_ar is the authentication key derived in ikev2 for the responder, and IDr is the identity of the server (and/or its full certificate). Note that this MAC value does not need to be transmitted, it is recomputed at the other side. Solution 1 seems too restrictive and probably unrealistic. Solution 2 is dangerous and certainly not something to be proud of... Solutions 3-5 are all valid cryptographically (they have a well-understood analysis -- even proofs if anyone cares), and all require adding a mechanism which is not defined in ikev2 now: (3) requires to define SK{} with null encryption, (4) adds a prf processing before the signing, (5) needs to include MAC(ID) under the signature. I personally prefer either (4) or (5) as being clearer and cleaner from a cryptographic point of view (and independent of identity protection mechanisms). Possibly, (5) is the simplest to specify on the basis of the current ikev2 document. Instead of detailing a specific solution for SLA I will request to change IKEv2's specification in a way that will automatically solve the SLA problem and, more importantly, will make ikev2 more robust to future changes and more amenable to analysis. I will send a separate message on this. Hugo From owner-ipsec@lists.tislabs.com Mon Dec 30 17:06:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBV16Yo24482; Mon, 30 Dec 2002 17:06:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00107 Mon, 30 Dec 2002 19:36:28 -0500 (EST) Date: Tue, 31 Dec 2002 02:38:14 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: a change to the signature processing in IKEv2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message contains a request for a change to the cryptographic specifications of ikev2's signatures. It is a relatively easy change that will add security to the protocol in the sense of making the protocol's security more robust to changes (in particular new modes and variants such as SLA). It will also improve the protocol by making its logic easier to understand and analyze. In a previous message I described an "identity misbinding attack" on SLA. I said there that this attack against the authenticity of the protocol is NOT possible in IKEv2. Indeed, IKEv2 provides strong authentication via the combination of a digital signature on the DH exponentials and a MAC on the signer's identity. This follows the "sign and mac" of the SIGMA protocols which has been rigorously analyzed. Therefore I have no complaints about the security of IKEv2 as specified now (draft v3). On the other hand, I do have a complaint (that I expressed several times in the past) regarding the "robustness" of the IKEv2 design. The problem is that the essential key-identity binding through a MAC is achieved in IKEv2 in an indirect way that is not sufficiently explicit and thus it is prone to misunderstandings and mistakes in modified versions of the protocol. I have been saying (since Nov 2001) that sooner or later people will propose variants or changes that will fail to be secure due to this design "obscurity". And indeed it happened sooner than later with the design of SLA. The problem is that IKEv2 authentication (and specifically key-identity binding) depends on two elements: (1) the MAC that is applied through the SK{} processing (which most people understand as needed for identity protection, or encryption integrity, rather than for the core authentication of the protocol) (2) the transmission of the initiator's identity in message 3 and of the responder's in message 4. If you remove any of these elements, or move the identities to another message, the protocol becomes insecure. SLA is an example in which the authentication in message 4 (the responder's) is moved to message 2 but SK{} (and its MAC) is not carried to that message. And it is not really the SLA designers fault: the SK{} processing includes encryption while message 2 of SLA cannot be encrypted (since it contains KEr which needs to be sent in the clear). Moreover, in SLA you do not care about protecting the identity of the responder (the server) and thus the SK{} processing is not only problematic but actually unnecessary. Another case in which the protocol's security would break down is in the following (not completely) hypotetical scenario. Assume that in some setting you do not care about identity protection of the initiator. In this case it makes a lot of sense to transmit this identity already in the first message so that the responder can make policy decisions early on based on this identity (this, btw, was one of the properties people liked/wanted in the aggressive modes of IKEv1). In this case, the authentication by the initiator still occurs in message 3, but the identity is not included there (since it was sent in message 1). However, while this change (or option) may seem very reasonable the resultant protocol would fail to "identity misbinding" attacks (i.e. the basic "mutual belief" property is lost). Note that while the effect of such an attack is debatable in the specific case of SLA, it is a major vulnerabiity in a general peer-to-peer key exchange protocol as IKEv2. As a fix to SLA and a general fix to this lack of robustness of IKEv2 I propose the following change to the signature computation (the AUTH payload) in IKEv2. Currently IKEv2 defines that the signature is to be applied to the concatenation of the peer's nonce and the contents of certain messages in the protocol. The change I am asking for is to add to the signed information also a value computed as MAC(SK_a,ID) where SK_a is is the MAC key already computed by the protocol, and ID is the identity of the signer. More specifically, in the initiator's signature (in message 3) this additional value will be MAC(SK_ai,IDi), while in the responder's signature it will be MAC(SK_ar,IDr). The computation of the keys SK_ai/SK_ar requires no additional processing or change since they are already derived in IKEv2 for use in the MAC in SK{}. Also note that the value MAC(SK_a,ID) added to the signature computation will NOT be transmitted but just re-computed by the receiving end when verifying the signature, so it requires no new payload nor it increases the length of messages. Thus, while the proposed change adds negligible complexity relative to the whole complexity of IKEv2 it provides for a significantly more robust and easier to analyze design. In particular: (1) the signatures can be moved to any message where they make sense (e.g. to message 2 in SLA) without loosing the protocols security (2) the identities can be transmitted in any message (e.g. the initiator's identity in message 1) without impacting the authentication of the protocol (3) the MAC used in SK{} will be confined to two functionalities: (a) protecting the identity encryption against active attacks (b) protecting the authenticity of phase-2 information piggybacked to msgs 3 and 4. Then I would also suggest a second change that will reduce the need for SK{} to functionality (a) (identity protection) only. The idea is to expand the signature's scope to the WHOLE information sent by each signer. That is, I's signature will be applied to the full messages 1 and 3, while R's signature to the full messages 2 and 4. In this case the AUTH payload can be moved to the end of messages 3 and 4 (before the SK{} processing). Relative to what is signed today, this change has the cost that each signature needs to be applied to two messages (instead of one message only). However making sure that you sign ALL the information sent by each party makes a better design. And, not less important, we make the MAC under SK only needed for identity protection. In particular, the resultant protocol can be proven secure even if the whole SK{} processing is omitted in case that identity protection is not required. I consider this as a significant robustness AND analytical advantage. In any case, while I'd prefer to see both changes accepted, I still consider the firsr one (adding MAC(SK_a,ID) to the signatures) as more significant and needed independently of the second change (i.e. expanding the scope of signatures). If anyone opposes these changes (especially the first one) please explain the rationale of this objection in a message to this list. I would suggest that whoever wants to raise objections against these changes first reads the SIGMA paper which addresses in much more detail the motivation and rationale behind these changes (in particular, see section 5.4 of the paper). The url (again) is http://www.ee.technion.ac.il/~hugo/sigma.ps [.pdf] Happy new year Hugo From owner-ipsec@lists.tislabs.com Mon Dec 30 17:13:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBV1DNo24839; Mon, 30 Dec 2002 17:13:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00179 Mon, 30 Dec 2002 19:48:32 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C6BF@corpmx14.us.dg.com> To: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: RE: IKEv2 transport concerns Date: Mon, 30 Dec 2002 19:49:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, > Black> The goal here is that any use of IKEv2 to negotiate a tunnel-mode SA > Black> (or UDP-encapsulated tunnel-mode SA for NAT traversal) carry an implied > Black> promise that ECN will be supported and handled correctly for that > Black> tunnel. This avoids any need for IKEv2 to negotiate/report/etc. > Black> ECN handling, in contrast to IKEv1 where a negotiable SA attribute > > David, while I understand what you are trying to do, you are assuming that > IKEv2 can only be deployed with an entirely new system. IKEv2 is a trivial > upgrade of system software (perhaps a "Service Pack"), while the upgrade to > the IPsec portions may in fact require changes to hardware. I wouldn't agree with "entirely new system" - if the ECN handling logic can be upgraded as part of the IKEv1 -> IKEv2 upgrade, everything's ok, although the upgrade is more complicated (e.g., may have to patch in a driver/stack change). How much hardware is there out there that can't cope with handling ECN correctly via an upgrade? Unless the answer is "a whole lot", the right thing to do may still be to require correct handling of ECN in IKEv2 and leave that hardware at IKEv1. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Dec 30 18:46:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBV2kuo00502; Mon, 30 Dec 2002 18:46:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01868 Mon, 30 Dec 2002 21:18:27 -0500 (EST) Message-Id: <200212310220.gBV2KSkG032681@mail2.trpz.com> To: Hugo Krawczyk cc: ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: Your message of "Tue, 31 Dec 2002 01:58:08 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1003.1041301207.1@tibernian.com> Date: Mon, 30 Dec 2002 18:20:07 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, What I'm saying is that providing legacy authentication credentials in an unprotected run is insecure. Clients should never do that. So for a second let's forget about attacks that are predecated on obtaining the credentials via an unprotected run. Protocols which tunnel EAP (PEAP, PIC, and SLA if it used EAP) are still susceptible to attack because the attacker does not need to obtain the credentials in an unprotected run. All the attacker needs to do is get the client to speak the EAP method by itself that the server demands to be tunneled. For instance, server wants PEAP with EAP-TLS as the "sub-protocol". Client is willing to do PEAP with EAP-TLS as the "sub-protocol" but would also settle for EAP-TLS by itself. This is entirely reasonable since EAP-TLS provides strong mutual authentication and generates keys. The attacker establishes the "outer" PEAP tunnel with the server masquerading as the client and then merely tunnels the EAP-TLS conversation from the client to the server. The client thinks it's doing EAP-TLS by itself the server thinks it's doing PEAP with EAP-TLS as the "sub-protocol". When the EAP-TLS conversation is finished the attacker terminates the connection to the client (perhaps sending an EAP failure) and now starts impersonating the client with an authenticated connection to the server. This same thing can happen with PIC. That attack is possible even though the legacy credentials are not sent in an unprotected run. That is an objection to using EAP. To use EAP we would have to do something like use the keys generated as part of the EAP exchange and mix them with the SKEYSEED blob. We'd also have to prohibit use of EAP methods which do not generate keys. But if we do that we've basically wiped out the whole desire of having this sort of authentication option in IKE in the first place! To answer your question about what I'm claiming: I'm claiming that providing your securID credential in an unprotected run would be patently insecure and we should not consider attacks that rely on someone first doing something patently insecure. One could describe an attack against regular-old digital signature IKE by starting off with "if I was to be given your private key...." Now that's absurd. We should not attempt to protect against that. Similarly we should not demand that our legacy authentication add-on to IKE protect against attacks that start off with someone doing something patently insecure like providing their legacy credentials in an unprotected run. A client should never provide its legacy credentials in an unprotected run. If you accept that then the reason to not use EAP is it is _still_ susceptible to attack (described above) while SLA is not. You may not accept that, though. But the point I'm making is that tunneling EAP with SLA opens one up to a more sinister attack than using a "proprietary" method of tunneling legacy credentials. Do you agree? Dan. On Tue, 31 Dec 2002 01:58:08 +0200 you wrote > Dan, > > Are you claiming, for example, that SLA-OTP is not susceptible to MitM > attacks if the same passwords are used under EAP-OTP (same for CHAP, > secure-ID, etc)? Or is there something special about EAP-SIM (which I am > not familiar with) on which you base your argument below? > > In any case, if you consider legacy methods such as CHAP, OTP etc > then the use of EAP-CHAP, EAP-OTP, etc in mixed protected/unprotected > runs is insecure with SLA regardless of the "wrapping" mechanism you use to > transport the authentication information in SLA (i.e it makes no difference > for the sake of these MitM attacks if you have specialized formats or use > EAP in SLA). > > Note that the fact that the unprotected run wraps the chalenges and > responses under a EAP construct does not mean that the attacker cannot > unwrap this information and re-format it under SLA. For example, if > you talk EAP-OTP in the clear then I can attack the "protected" SLA-OTP > simply by reading the one-time-pad from the unprotected EAP-OTP run. > Once I have that otp, SLA has nothing to do to protect the server against > impersonation. > > If you agree with the above and still keep your objections against using > EAP then please explain again why. > > Regarding "stupid practices" see below > > On Sun, 29 Dec 2002, Dan Harkins wrote: > > > Hugo, > > > > The problem with using EAP (that SLA doesn't have) is that EAP all > > by itself is a perfectly legitimate way to do good, strong, mutual > > authentication and therefore it is easy to launch the authentication > > binding attack by inducing the client to speak that EAP method all > > by itself. > > > > Quite a few EAP methods-- EAP-SIM for instance-- provide mutual > > authentication (and key generation) and speaking EAP-SIM by itself is > > a perfectly legitimate thing to do. SIM cards are used in mobile > > phones and in wireless NIC cards today. They'll be used in more things > > tomorrow. The more they're used the more willing a client will be > > to speak EAP-SIM all by itself, and therefore the easier it will be > > for an attacker to tunnel it to a server who is only willing to speak > > a tunneled version of EAP-SIM. Ditto for EAP-TLS. (And yes, there are > > implementations today that do EAP-TLS-encapsulated EAP-TLS). > > > > But how could someone be induced into encapsulating its legacay > > authentication protocol in some format that is specific for SLA and > > thereby enable the authentication binding attack on it? It is > > not a legitimate authentication encapsulation all by itself. > > > > The authentication binding attack is possible on SLA only if the > > client is doing something that she should not be doing in the first > > place-- like providing her credentials to anyone who asks. It's > > possible for anything to be attacked if the client is doing something > > insecure! A password of "password", a PIN for a token card written on > > a the token card itself. > > > > In another email you wrote that in these attacks the attacker: > > > > "(a) impersonates the server to the client in the unprotected run (we are > > talking of legacy authentication methods that do NOT authenticate the > > server so this impersonation is possible)" > > > > Yes, it's possible. It's possible to write the PIN on the token card > > and leave it lying around and thereby leave one open to "attack". But > > we can't protect against things that are predicated on the client > > doing a patently insecure thing in the first place. It's possible to > > steal the contents of a locked car if the windows are down. Is that > > an "attack" against the lock, or does that, by itself, mean the lock > > is somehow ineffective? No, it means the owner did something stupid > > to eliminate the security afforded by other mechanisms. > > I am not sure what exactly you are ridiculizing here. > Are you saying that the mixed protected/unprotected runs we are discussing > are a "stupid practice" and then there is no reason for us to address them? > This is indeed one of the options I enumerated in a previous email for > solving (or not solving) this issue. On the other hand, I guess that many > people using legacy authentication may want to keep the "stupid practice" of > mixed runs and get as much defense as they can in the protected runs. > > In one way or another I do not see that the use of EAP in SLA makes things > worse. > > Hugo > > > > > Dan. > From owner-ipsec@lists.tislabs.com Mon Dec 30 23:02:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBV72Vo13739; Mon, 30 Dec 2002 23:02:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02308 Tue, 31 Dec 2002 01:36:18 -0500 (EST) From: Charlie_Kaufman@notesdev.ibm.com X-Mailer: Lotus Notes Build V601_11252002 November 25, 2002 Subject: Summary of MITM attacks with legacy authentication To: Message-ID: Date: Tue, 31 Dec 2002 01:20:27 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_12112002NP|December 11, 2002) at 12/31/2002 01:37:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been a lot of traffic about avoiding MITM attacks when incorporating legacy authentication into IKEv2. For a long time, I didn't understand it. Now I think I do. That does not imply I really do. I'm writing this note both to summarize the other notes here and to find out whether I really understand it by giving everyone a chance to stomp on me if I don't. Q: What is a man-in-the-middle (MITM) attack? A: This is where someone gets between the two communicating parties in an IPSec connection, impersonates each end to the other, and ends up with connections to both such that he can read and/or modify messages as they pass while the two parties think they are talking only to one another. Normally in IPSec, the MITM attack is avoided by having each end of the connection authenticate in a means that is tied to the keys used to protect the connection. The AUTH payload in IKEv2 is computed over data including the Diffie-Hellman numbers used to derive the keys. The challenge with legacy authentication is somehow cryptographically entangling the authentication data with the keys used to encrypt the connection. With some forms of legacy authentication, it is impossible. With others, it's possible but not easy. With still others, it's not necessary. A lot of the discussion on this list concerns making sure that we do it when it's possible. A lot of the confusion concerns knowing when it's possible and when it's not. An example when it's not necessary to protect against MITM: Alice has a SecurID card that she uses to authenticate to server Bob. When the connection is set up, Bob first authenticates to Alice using an X.509 certificate. Alice verifies that she is connected to Bob before typing the number from the SecurID card, which is sent over the encrypted channel. Alice knows she is talking directly to Bob because he authenticated with a certificate. Bob knows he is talking directly to Alice because he knows Alice would never give her SecurID number to anybody but him. An example when it's not possible to protect against MITM: Same as the above except that Alice uses her SecurID number to authenticate to lots of servers besides Bob. If Alice connects to Carl, verifies his identity and then sends her SecurID number, Carl could use that number to impersonate Alice to Bob. Anyone who learns Alice's SecurID number of the minute can impersonate Alice to any server accepting that form of authentication. The cryptographic trick we would like to play is sending Carl a hash of the SecurID number and his name. If he could present such a hash to the SecurID server and have it verify the hash, then Carl would never have to learn the raw number and hence would not be able to impersonate Alice to Bob. But the very nature of "Legacy Authentication" is that we can't assume that we can change what the verification routine is willing to accept. Today, the SecurID server will only verify a raw number and we're not likely to get them to change it for IKE. Note that in this case, Alice is not fooled... she knows that she's not talking to Bob. But Bob is fooled and there is no fancy crypto that can prevent it. An example when we might be able to protect against MITM: Suppose Alice has a password, and she uses that password to authenticate to many servers. If the authentication protocol consists of sending the password over an encrypted channel to the server, then it has the same problem as the case above... anyone who learns Alice's password can impersonate Alice. But if the authentication protocol is based on Challenge-Response, where the server sends Alice a challenge, Alice cryptographically combines it with her password and sends the result back, then the protocol would resist MITM if the challenge had to include Bob's name or some function of the IKE session key. So what does this mean for Legacy Authentication in IKEv2? My reading of the SLA proposal is that the mechanisms supported are: (1) password sent to Bob, (2) OTP password sent to Bob, (3) Challenge-Response Card where Bob generates full challenge (4) SecurID card where Alice sends the displayed number to Bob. For all of these mechanisms, MITM protection is impossible because those protocols require that the secret value (and not just a hash of it) be available on the server for verification. If we were to add stronger legacy authentication mechanisms (e.g. CRAM-MD5, Kerberos, SRP), we should at that time design MITM protection. There are several plausible mechanisms. My favorite would be to generate some sort of key identifier for the IKE connection and wind that in to the legacy authentication mechanism rather than taking a key generated by the legacy authentication and winding it into IKE. But either would work. OK, guys. How much of this did I get wrong. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Tue Dec 31 05:20:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBVDK4o03878; Tue, 31 Dec 2002 05:20:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02890 Tue, 31 Dec 2002 07:53:09 -0500 (EST) X-Originating-IP: [207.6.242.120] From: "Andrew Krywaniuk" To: hugo@ee.technion.ac.il Cc: ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 Date: Tue, 31 Dec 2002 04:27:53 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Dec 2002 09:27:53.0710 (UTC) FILETIME=[E54508E0:01C2B0AE] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suggested a long time ago that we could solve the problem by simply adding a private attribute that says "I am running EAP over an IPsec tunnel", but I was told that adding a new EAP attribute is so hard that it would be easier to design our own SLA protocol. I don't really know enough about EAP to confirm or deny this. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. I do not agree. The problem is really with legacy authentication *protocols*, not with legacy *credentials*. If you let me re-design even the most basic of pswd authentication protocols such as CHAP I will do it in a way that will change the protocol very slightly (and will use passwds the same way CHAP uses now) but will make the modified protocol resistant to the MitM attacks we were discussing here. How? Simply put under the response computation the name of the server with which you are comunicating and (if possible) the name of the tunnel protocol under which the protocol is run (with a special "protocol name" for "no tunneling"). Needless to say this does not resolve dictionary attacks if the protocol is run unprotected but that is something that NO solution can avoid (except of course for NOT running the protocol unprotected or for switching to dictionary-attack resistant methods (which exist of course but not as "legacy"). _________________________________________________________________ MSN 8: advanced junk mail protection and 3 months FREE*. http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_advancedjmf_3mf From owner-ipsec@lists.tislabs.com Tue Dec 31 08:44:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBVGi5o13450; Tue, 31 Dec 2002 08:44:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03345 Tue, 31 Dec 2002 11:14:55 -0500 (EST) Message-Id: <200212311616.gBVGGkkF010743@mail2.trpz.com> To: "Andrew Krywaniuk" cc: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 In-Reply-To: Your message of "Tue, 31 Dec 2002 04:27:53 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <287.1041351384.1@tibernian.com> Date: Tue, 31 Dec 2002 08:16:24 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, It's probably easier to add things in the EAP WG than the IPsec WG :-) But I think your solution would only work for EAP methods that protect the EAP conversation themselves (like EAP-TLS). If Alice was to speak EAP-OTP then the attacker could just splice in the "I am running EAP over an IPsec tunnel" attribute. Dan. On Tue, 31 Dec 2002 04:27:53 EST you wrote > > I suggested a long time ago that we could solve the problem by simply adding > a private attribute that says "I am running EAP over an IPsec tunnel", but I > was told that adding a new EAP attribute is so hard that it would be easier > to design our own SLA protocol. I don't really know enough about EAP to > confirm or deny this. > > Andrew > -------------------------------------- > The odd thing about fairness is when > we strive so hard to be equitable > that we forget to be correct. > > > I do not agree. The problem is really with legacy authentication > *protocols*, > not with legacy *credentials*. If you let me re-design even the most basic > of pswd authentication protocols such as CHAP I will do it in a way that > will change the protocol very slightly (and will use passwds the same way > CHAP uses now) but will make the modified protocol resistant to the MitM > attacks we were discussing here. How? Simply put under the response > computation the name of the server with which you are comunicating and (if > possible) the name of the tunnel protocol under which the protocol is run > (with a special "protocol name" for "no tunneling"). Needless to say this > does not resolve dictionary attacks if the protocol is run unprotected but > that is something that NO solution can avoid (except of course for NOT > running the protocol unprotected or for switching to dictionary-attack > resistant methods (which exist of course but not as "legacy"). > > > > _________________________________________________________________ > MSN 8: advanced junk mail protection and 3 months FREE*. > http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474 >&SU= > http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_advancedjmf_ >3mf > From owner-ipsec@lists.tislabs.com Tue Dec 31 09:46:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBVHk6o17278; Tue, 31 Dec 2002 09:46:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03458 Tue, 31 Dec 2002 12:19:11 -0500 (EST) Message-ID: <20021231172034.7046.qmail@web13106.mail.yahoo.com> Date: Tue, 31 Dec 2002 14:20:34 -0300 (ART) From: =?iso-8859-1?q?Jorge=20Davila?= To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi friends before anything I want to wish you a happy new year from here: Peru I am recently researching about a freeSwan/PGPnet freeware 7.03 VPN. First I get a SA in my network among 192.168.0.202 and 192.168.0.242 but only in share paraphrase mode, I mean without RSA. I had an aparently success but there were the follow problems: -When I finished PGPnet installation I couldn't access to internet. -I couldn't read my emails in Outlook Express. - I tried to change at ipsec.conf the following line left=192.168.0.202 by left=%any and I couldn't get the tunnel. ?? -I uninstalled PGP and internet conection back but Outlook Express had problems. I hope somebody can help me to discuss this an others themes, then I could write a spanish HOWTO and upload in my web page. My final objective is to get a tunnel like: RoadWarrior----Modem----internet-----Router-----Secure----intranet Dial up Gateway happy new year from Peru Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html From owner-ipsec@lists.tislabs.com Tue Dec 31 12:00:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBVK0ho27625; Tue, 31 Dec 2002 12:00:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03693 Tue, 31 Dec 2002 14:25:58 -0500 (EST) Message-Id: <200212311927.gBVJRQlW002905@sandelman.ottawa.on.ca> To: IPsec WG Subject: Re: identity-misbinding attack on SLA In-reply-to: Your message of "Tue, 31 Dec 2002 02:21:14 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Dec 2002 14:27:25 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> This assumption holds in some scenarios but certainly not in all remote user Hugo> authentication cases. In many instances the client machine will not have the Hugo> server's certificate but will rather have to receive the cert from the Hugo> server itself (this cert is verified at the client on the basis of some Hugo> verification PK and policy settings installed at the client). I dispute the claim that the public key of the server is not know to the client. I would further dispute that this will be deployed along with a PKI that would permit the client to even verify the server. Yes, in the general case it might be true, but I don't want to promote legacy authentication for cross-enterprise use. Single-enterprise only. Places big enough to have too many people to handle raw RSA keys manually, yet not big enough to justify a PKI deployment. Those are the places that "legacy" authentication will be used. The only situation where I could imagine not knowing the right *server* certificate in a single enterprise situation is when there is some kind of failover situation, or anycast-reachable gateway. I don't think either is in scope. I won't speak on the validity of the attack described - just your assumptions. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPhHvnIqHRg3pndX9AQFIrAQAx3VRey8Fk7bNz6MMjz59XUjW4NVLs/XL X9MyyWdgA1NmkyzieycGdQQ40LvbLgbe99kJ3KAtVMLpzAO53hYxMjRwGxkYr0Tx 2UdxmRtufv4VgjOuQJEJT43UjaF02etMnAvS6Ex+bg9KZxarTCZvCo5mzV+cjOox Jc26MFRByO8= =37XJ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 31 12:00:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBVK0ho27626; Tue, 31 Dec 2002 12:00:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03713 Tue, 31 Dec 2002 14:32:10 -0500 (EST) Message-Id: <200212311933.gBVJXsCU003005@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Secure legacy authentication for IKEv2 In-reply-to: Your message of "Mon, 30 Dec 2002 18:20:07 PST." <200212310220.gBV2KSkG032681@mail2.trpz.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Dec 2002 14:33:54 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I didn't understand Dan's scenario, so I asked him if this was what he meant. So I'll repost it: the scenario is: EAPclient ----- some transport ---- man-in-the-middle ====IKEv2==== gateway i.e. web-bunny ebay.su whitehouse.gov Web bunny thinks she is opening her wallet to buy stuff from some new ebay-like site, and in fact ebay.su uses the credentials to build themselves an IPsec tunnel to the web-bunny's place of work. Is this the attack? It seems to be because there is no binding in the EAP inner pieces to something like the IKEv2 cookies or vica-versa. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPhHxIIqHRg3pndX9AQEvdwQAhNhU/WLLVmSiWiiA4+DWg+cwN0ytI+l0 +bZjNKiShxLcSWTojX1TUbJ6yot6KJUYg+PnZb/jrbpmSMSYyfck1JIKmi9190Hf LgFdshz1jQtU71ZucRFa8plBJhti+qRffqrvQI5lgt1py0q62AalUhYZu2IB12B/ Mj78eDLIUX8= =/uHl -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 31 13:14:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBVLEXo01128; Tue, 31 Dec 2002 13:14:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03870 Tue, 31 Dec 2002 15:44:40 -0500 (EST) Message-Id: <5.1.0.14.0.20021231131024.00a746e0@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Dec 2002 14:26:14 -0500 To: ipsec@lists.tislabs.com From: David Jablon Subject: "legacy" confusion (was Re: Summary of MITM attacks with legacy authentication) Cc: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie's summary valiantly dispels some confusion in this discussion, and yet it still perpetuates some of it in too-loosely using the term "legacy". "Legacy" seems to have a clear and useful meaning within "legacy credentials". There it means something other than a shared key or private/public key pair, like a static password or one-time password, essentially any non-key data that has historically been simply transmitted to prove identity in olden-days. But "legacy" has no clear meaning in "legacy authentication method". From various threads of discussion, this phrase can be interpreted to mean a method with almost any combination of the following characteristics: -- uses a "legacy credential" for authentication -- requires secure transmission of the credential -- does not require a key -- does not establish a key -- has been widely used (defined arbitrarily) -- has been in use since Month Day, Year (fill in as desired) The term "Secure Legacy Authentication" is especially confusing when it is limited to encompass *only* methods that have historically used legacy credentials in *insecure* ways. This confusion is perpetuated further in reference to Kerberos, MD5-CRAM, and SRP as "stronger legacy mechanisms". "Legacy" in what sense? "Stronger" than what, and in what ways? Discussions will likely continue to circle in unproductive ways until our legacy jargon is replaced. The common theme seems simple: methods that use passwords as credentials, including both re-usable passwords and one-time passwords (e.g. SecurID). In discussions of threat scenarios it certainly makes sense to distinguish between sub-classes of such methods. But when discussing a framework for how they can be plugged-in to IKEv2, it seems to make more sense to treat them as a comprehensive class in so far as there is no technically compelling reason to subdivide. -- David At 01:20 AM 12/31/02 -0500, Charlie_Kaufman@notesdev.ibm.com wrote: >There has been a lot of traffic about avoiding MITM attacks when >incorporating legacy authentication into IKEv2. For a long time, I didn't >understand it. Now I think I do. That does not imply I really do. I'm >writing this note both to summarize the other notes here and to find out >whether I really understand it by giving everyone a chance to stomp on me >if I don't. ... >If we were to add stronger legacy authentication mechanisms (e.g. CRAM-MD5, >Kerberos, SRP), we should at that time design MITM protection. There are >several plausible mechanisms. My favorite would be to generate some sort of >key identifier for the IKE connection and wind that in to the legacy >authentication mechanism rather than taking a key generated by the legacy >authentication and winding it into IKE. But either would work. > >OK, guys. How much of this did I get wrong. > > --Charlie From owner-ipsec@lists.tislabs.com Tue Dec 31 13:28:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBVLSwo02154; Tue, 31 Dec 2002 13:28:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03932 Tue, 31 Dec 2002 16:02:47 -0500 (EST) Message-Id: <200212312104.gBVL4WWi004154@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Summary of MITM attacks with legacy authentication In-reply-to: Your message of "Tue, 31 Dec 2002 01:20:27 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Dec 2002 16:04:31 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> An example when it's not necessary to protect against MITM: Charlie> Alice has a SecurID card that she uses to authenticate to server Bob. When Charlie> the connection is set up, Bob first authenticates to Alice using an X.509 If the client can be configured to never do SecurID with anything other than Bob - i.e, a config file that says: Use SecurID SLA when speaking to public key X. then we can administratively prevent Alice from giving herself away. This isn't very strong, I agree, and doesn't help Bob defend himself. As you say, Alice is never fooled. Only Bob is. Charlie> Same as the above except that Alice uses her SecurID number to authenticate Charlie> to lots of servers besides Bob. If Alice connects to Carl, verifies his The major concern is if Alice uses her card to authenticate into multiple realms. This is fundamentally not a supported method with SecurID - those other realms can *already* impersonate her. Same with every system where Bob has to know the entire secret value! (Kerberos, NT-domain authentication, X9.9 and SecurID) Charlie> So what does this mean for Legacy Authentication in IKEv2? Charlie> My reading of the SLA proposal is that the mechanisms supported are: Charlie> (1) password sent to Bob, note that for MD5/DES/Unix-style /etc/passwd, Bob doesn't have a secret, just a way to check a value. Charlie> (2) OTP password sent to Bob, i.e. S/Key. Bob doesn't have the secret here either. Charlie> (3) Challenge-Response Card where Bob generates full challenge i.e. X9.9. Charlie> (4) SecurID card where Alice sends the displayed number to Bob. Charlie> For all of these mechanisms, MITM protection is impossible because those Charlie> protocols require that the secret value (and not just a hash of it) be Charlie> available on the server for verification. If it were possible to include some non-transmitted value into the SKEYSEED, we might be able to cause the MITM to be unable derive the same sessions keys. This could be accomplished in X9.9 and SecurID by not transmitting the entire displayed value - both ends can derive it in theory. In practice, Bob will use Radius or some such to verify the value, and the standard protocols do not return the "correct" value to Bob. Charlie> OK, guys. How much of this did I get wrong. I think that you got it perfectly correct. But, I think that this is why Legacy Auth is a pain. This is why we must make it easy to bootstrap into public key authentication, permitting it to be deployed easily - this starts by not tying it to PK*I*. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPhIGVoqHRg3pndX9AQHDzAP/SOnRyEc6DvjZTSI86LlntywEtq7M5CMR HUSTWSslfbZxvcJgN1qyxsiFGFWyoH7HcDBlwvqh5gGwPpKU69Bi7eoP2F85F8PS eHhvlPf8UEfz4bE4YCYd8bCfmiT3/XF1lKPZArgwsiOTKpfUmyXPrNPouSfD+9oH 3y4P6TTEbhA= =Qj9t -----END PGP SIGNATURE-----