From owner-ipsec@lists.tislabs.com Sat Dec 1 08:09:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB1G9g803755; Sat, 1 Dec 2001 08:09:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17256 Sat, 1 Dec 2001 10:03:32 -0500 (EST) Message-ID: <3C08F3AD.AE194FBC@storm.ca> Date: Sat, 01 Dec 2001 10:13:49 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <4652644B98DFF34696801F8F3070D3FE01188472@D2CSPEXM001.smartpipes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" wrote: > > It depends on how you see things. I agree that you only need to have 2N keys > in existence. > But from a usage/implementation/deployment point of view, you are still > dealing n*(n-1) key delivery. The only difference is that you deliver the > same public key (N-1) times to N boxes in the case of RSA, but you deliver > (N-1)*N/2 different keys in PSK case, assuming we are talking a full mesh > relationship. There is another important differences. With symmetric keys, you must make all the PSK deliveries securely, whether from peer to peer or from server to client, for the system to work. With public key tehniques, it does not matter if the enemy learns the public keys, so there is no need for a secure channel for those. If you have each system generate its own public/private key pair, then only public keys ever need to be transmitted (directly to peers or to the server if you use one) or shared. From owner-ipsec@lists.tislabs.com Sat Dec 1 08:56:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB1GuX805510; Sat, 1 Dec 2001 08:56:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17305 Sat, 1 Dec 2001 11:07:34 -0500 (EST) To: Joe Touch Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> <3C07CF58.4070802@isi.edu> <3C080214.8040603@isi.edu> <3C087834.2060308@isi.edu> From: Derek Atkins Date: 01 Dec 2001 11:17:04 -0500 In-Reply-To: Joe Touch's message of "Fri, 30 Nov 2001 22:27:00 -0800" Message-ID: Lines: 94 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, Steve, Here is an example where keeping a pointer to the SA in question (and a way to access the SA authentication/identification information) would be a real asset: the ability to leverage IPsec security services at the application level. Imagine an implmentation of IPsec within a host where during IPsec processing, the host kept a pointer to the SA along with the packet (a metadata pointer). As the packet goes up the IP stack, other layers (e.g. Application) could access the security information for themselves. This allows the application modify its behavior based upon the IPsec security information. If the host is implementing a firewall, this would allow the firewall module to see the IPsec authentication and process the packet accordingly. It is not IPsec performing the firewalling (or the aforemetioned application), however if IPsec is integrated into the OS then it can make the authentication information available to other modules that process a packet. -derek Joe Touch writes: > Stephen Kent wrote: > > > At 2:03 PM -0800 11/30/01, Joe Touch wrote: > > > >> Stephen Kent wrote: > >> > >>> > >>> 2401 requires that the SA binding be maintained only within the IPsec > >>> implementation. I understood your comments to suggest something else, > >>> e.g., a separate firewall module not part of IPsec. If I > >>> misunderstood, I apologize. > >> > >> > >> > >> We want the SA is kept outside the IPsec, so that packets that pass > >> through other modules in the meantime will retain their SA, e.g., Sec > >> 8.4. > >> > >> Joe > > > > > > Joe, > > > > Your sentence is not well formed, but I suspect we do have a serious > > disagreement here. > > > Delete the /is/. Sorry about that :-) > > Yes, it appears we do disagree - let's see where the thread goes, though. > > > > An SA is an IPsec concept and thus it exists only within an IPsec > > module. IPsec has never been just an encryption protocol, although some > > have suggested otherwise. Encryption, by itself, does not provide > > protection against the major forms of attack that most Internet users > > experience. Rather, access control is the security service that is the > > focus of most security mechanisms that we employ, if one remembers that > > the primary motivation for authentication (user or otherwise) is as an > > input to an access control decision. > > > > Since the authentication of the other IPsec peer is an IPsec function, > > it makes sense to retain that authentication info and use it to filter > > traffic within IPsec, i.e., to perform identity-based access control > > enforcement there. > > > In that case, what we have is a failure of firewall code (ipfw, e.g.) > and tunnel mechanisms (gifconfig, e.g.). If that code is "inside" the > IPsec implementation, the SA would be available. > > There is more to packet processing than just encryption and > authentication, _however_ that doesn't mean that the configuration > interface needs to be as integrated as the implementation. If, for > example, all firewall processing and tunneling were _implemented_ inside > IPsec, then the SAs would be properly available. > > So, I agree that the implementation should be integrated, but not > necessarily that the configuration should be as tightly integrated. > > Joe > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Sat Dec 1 10:38:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB1Ic9811861; Sat, 1 Dec 2001 10:38:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17417 Sat, 1 Dec 2001 12:35:07 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Joe Touch" Cc: "Stephen Kent" , Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> <3C07CF58.4070802@isi.edu> <3C080214.8040603@isi.edu> <3C087834.2060308@isi.edu> From: "Derek Atkins" Date: 01 Dec 2001 11:17:04 -0500 In-Reply-To: Joe Touch's message of "Fri, 30 Nov 2001 22:27:00 -0800" Message-ID: Lines: 94 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 01 Dec 2001 17:14:36.0406 (UTC) FILETIME=[A7021960:01C17A8B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, Steve, Here is an example where keeping a pointer to the SA in question (and a way to access the SA authentication/identification information) would be a real asset: the ability to leverage IPsec security services at the application level. Imagine an implmentation of IPsec within a host where during IPsec processing, the host kept a pointer to the SA along with the packet (a metadata pointer). As the packet goes up the IP stack, other layers (e.g. Application) could access the security information for themselves. This allows the application modify its behavior based upon the IPsec security information. If the host is implementing a firewall, this would allow the firewall module to see the IPsec authentication and process the packet accordingly. It is not IPsec performing the firewalling (or the aforemetioned application), however if IPsec is integrated into the OS then it can make the authentication information available to other modules that process a packet. -derek Joe Touch writes: > Stephen Kent wrote: > > > At 2:03 PM -0800 11/30/01, Joe Touch wrote: > > > >> Stephen Kent wrote: > >> > >>> > >>> 2401 requires that the SA binding be maintained only within the IPsec > >>> implementation. I understood your comments to suggest something else, > >>> e.g., a separate firewall module not part of IPsec. If I > >>> misunderstood, I apologize. > >> > >> > >> > >> We want the SA is kept outside the IPsec, so that packets that pass > >> through other modules in the meantime will retain their SA, e.g., Sec > >> 8.4. > >> > >> Joe > > > > > > Joe, > > > > Your sentence is not well formed, but I suspect we do have a serious > > disagreement here. > > > Delete the /is/. Sorry about that :-) > > Yes, it appears we do disagree - let's see where the thread goes, though. > > > > An SA is an IPsec concept and thus it exists only within an IPsec > > module. IPsec has never been just an encryption protocol, although some > > have suggested otherwise. Encryption, by itself, does not provide > > protection against the major forms of attack that most Internet users > > experience. Rather, access control is the security service that is the > > focus of most security mechanisms that we employ, if one remembers that > > the primary motivation for authentication (user or otherwise) is as an > > input to an access control decision. > > > > Since the authentication of the other IPsec peer is an IPsec function, > > it makes sense to retain that authentication info and use it to filter > > traffic within IPsec, i.e., to perform identity-based access control > > enforcement there. > > > In that case, what we have is a failure of firewall code (ipfw, e.g.) > and tunnel mechanisms (gifconfig, e.g.). If that code is "inside" the > IPsec implementation, the SA would be available. > > There is more to packet processing than just encryption and > authentication, _however_ that doesn't mean that the configuration > interface needs to be as integrated as the implementation. If, for > example, all firewall processing and tunneling were _implemented_ inside > IPsec, then the SAs would be properly available. > > So, I agree that the implementation should be integrated, but not > necessarily that the configuration should be as tightly integrated. > > Joe > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Sat Dec 1 19:07:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB237L207374; Sat, 1 Dec 2001 19:07:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18210 Sat, 1 Dec 2001 21:24:56 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188475@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , "Wang, Cliff" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Sun, 2 Dec 2001 02:33:59 -0000 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 Thanks for the discussion and see my comments in line. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Friday, November 30, 2001 11:52 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) [david] Cliff, Let's agree that the pre-shared symmetric key will only *intended* used by two devices. Let's look at a 5 devices network and a central keys deposit server. For key management purpose, both the pre-shared RSA public keys and the symmetic keys will be in a server. (Don't see any scalable model other than this) For a fully meshed communication model among these 5 devices: 1) the symmetric keys case: The server have to store 10 = (5*4)/2 s. keys. and keep track of which link associate to which key. Before device_1 communicates with device_2, these transactions have to happen: the sk_12 will be sent from server to device_1 and device_2 through out-of-band secured channel. (well, this dynamic model is scalable otherwise if the 10 keys pre-loaed on each of the 5 devices; it will be difficult when a device join-in...) After the full mesh is reached, each device will have 4 Skeys. 2) the RSA keys case: The server have to strore 5 public keys and don't care about link info., but have to associate device to its public key. Before device_1 communicates with device_2, these transactions have to happen: the pk_1 is sent to device_2 from server and the pk_2 is sent to device_1 trough out-of-band secured channel. After the full mesh is reached, each device will have 4 public keys and its own private keys. Observation: 1. The symmetric key management model shows that for a single skey, there are 3 parties know it. The 2 devices and the server. Clearly, get the skeys in the server is most effective to break entire mesh. In contrast to the symmetric key, get the public-keys in the RA does not break any secure link. (therefore, you can let 3rd party manage this server "RA", as long as it guarantees id/public-key bindings) [cliff] agree. In this case, a server break-in is a very serious security breach and it can jeopardize the whole operation. When such an event happens, even though the attacker can't take advantage of the public key, he can do enough damage to other things such as billing, device configuration, etc. In contrast with the server break-in case, a device compromise is much more likely. Let's take a look at this case. In a full mesh setup, PSK or pre-shared RSA suffers the same degree, say 4 partners are compromised. However, in a hub-spoke setting where only 4 tunnels exists, if a spoke is compromised, only the link to the hub is compromised when PSK is used. If pre-shared RSA is used, then potentially communication to both hub and the rest 3 spoke can be compromised. So in that case, pre-shared RSA is worse than a pre-shared key. [david] 2. The number of keys in the server is clearly more for symmetric keys. In addition, it has to keep track of 'link-id'/key pair which is more difficult than that of 'device-id' in the case of public keys. [cliff] Although the public key may be cached in the server, there is no need to save the PSK for a tunnel at the server, since they have been delivered to both tunnel ends. If a new PSK is needed, just generate it and push it out to both ends again. However, the server key storage seems to be an implementation issue. --- David P.S. I agree that when a device been tampered, all the established secured link to this device are broken for either symmetric or asymmetric keys are used. ----- Original Message ----- From: "Wang, Cliff" To: "'david chen'" ; "Sandy Harris" ; "'IPsec WG'" Sent: Friday, November 30, 2001 2:49 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > This analysis is seriously flawed: > 1) SPSK or group pre-shared key per box is a bad idea. No security conscious > people will adopt this. Because of this serious flaw in assumption, > all security level comparison are meaningless. > 2) Once an attacker compromise a box, he has access to either private > key or > the pre-shared key. > Any communication with the box's partners are compromised, whether > using PKI > or PSK for IKE authentication. Where is the 200% risk come from? > 3) why each device needs to have 499 public keys? They are contained > in each > box's cert and delivered as part of IKE exchange. > > -----Original Message----- > From: david chen [mailto:ietf_davidchen@hotmail.com] > Sent: Friday, November 30, 2001 1:15 PM > To: Sandy Harris; 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > Here is my observation: > > The RSA puliblic/private key (RSA key) is better than symmetric > pre-shared key (SPSK) in the following way: Suppose both the RSA key > and SPSK all using > centerally managed server in a domain and further assume that the SPSK > is one for each device (not one for each pair of device). Let's say > there are 500 devices in this domain: Then there will be 500 keys for > SPSK so is RSA keys. Each device will either have 499 public keys or > 499 SPSKs. Given the key management (add/delete/remove) are *almost* > equal, the SPSK has a not ignorable drawback than RSA Key structure: > To break RSA key, attacker has to > break into the device that hold the private key or break into the > device that itself is the victim of MIM attack. The device has to > responsible for its own security. (Given the real world that the > security of a device are not created equal, this is a reasonable > requirement) > > On the other hand, to break a SPSK, the attacker can choose any of the > 500 devices to breakin. The risk is much higher for a device due to it > demand all other participated devices have the same security level. > > Sure, the SPSK can increase the number of keys that limited the key to only > two parties (and increase the complexicity of the key management) but still > it is 200% risk more than RSA key due to it demands the same level of > security level on peer. > > > --- David > > > > ----- Original Message ----- > From: "Sandy Harris" > To: "'IPsec WG'" > Sent: Friday, November 30, 2001 10:10 AM > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > > Alex Alten wrote: > > > > > I will re-iterate my position. If a network security system is > > > properly designed then either Public Key or Symmetric/Private Key > > > cryptography will work fine in establishing trust. > > > > So far, so good. > > > > > I furthermore claim that Symmetric/Private Key cryptography will > > > scale to great numbers of users > > > > Sorry, but this is nonsense. The classic problem with symmetric > > crypto is key management. It neither scales well nor works well > > across > administrative > > boundaries. > > > > Consider n sites which all want to communicate. > > > > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which > > is known to exactly two players and none of the others. Moreover, > > you have to communicate those keys securely to the second player in > > each case, and then keep it secure on both systems. > > > > With public key, you need only n key pairs. There is no need to > communicate > > keys securely; the system is designed to work even if the enemy > > knows the public keys. Nor do you have to manage security for > > multiple keys, or keep track of who each key is shared with. You > > just need to keep your private key secure, not shared with anyone. > > > > Of course you can build a kerberos-like system using symmetric > > ciphers that has many of the advantages of public key. Using a > > central key server reduces the number of keys to n client-to-server > > keys and may simplify management. However, I doubt such a > > centralised model is appropriate for Internet infrastructure. > > > > > and I use the bank ATM secure network using DES as an excellent > > > example. ... > > > > I think that's an irrelevant example. A tightly controlled single > > purpose terminal-to-mainframe network under a single administrative > > authority bears no useful resemblanmce to the Internet. Someone gave > > a good detailed analysis earlier in the thread. You should re-read > > it. > > > > > As far as I'm concerned this should be the end of the discussion > > > > I agree, but for opposite reasons. > > > > > about whether or not Symmetric/Private Key cryptography can scale > > > to large numbers of users in an efficient, easy to use by ordinary > > > people, inexpensive to implement manner and interoperable between > > > devices made by different manufacturers and maintained by > > > different organizations. It has been done for the past 20 years by what > is > > > probably the most successful world-wide commercial networked > > > security > system. > > > > > > Anyone who still claims that Public Key is superior to > > > Symmetric/Private > Key > > > cryptography, or that it is the only way to scale, is a *damn > > > fool* and > should > > > be treated as such. > > > > How about "obviously superior for some purposes, including most key > > distribution applications" and "almost always the best way to build > > scalable systems"? > > > > Methinks you'll consider me a fool. I heartily return the sentiment. > > > From owner-ipsec@lists.tislabs.com Sat Dec 1 19:07:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB237T207387; Sat, 1 Dec 2001 19:07:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18187 Sat, 1 Dec 2001 21:04:36 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188474@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Sun, 2 Dec 2001 02:13:34 -0000 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 Yes I agree that the symmetric key adds more secure delivery requirement, although the delivery scalability is the same as that of a pre-shared public key system. In a managed IPsec VPN system, usually there is a dedicated security channel between the managed device and the server. So to such a type of provisioning and management system, the extra security requirement imposed by symmetric key is non-significant. So I hope that we at least agree that key delivery scalability is about the same. -----Original Message----- From: Sandy Harris [mailto:sandy@storm.ca] Sent: Saturday, December 01, 2001 10:14 AM To: 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) "Wang, Cliff" wrote: > > It depends on how you see things. I agree that you only need to have > 2N keys in existence. But from a usage/implementation/deployment point > of view, you are still dealing n*(n-1) key delivery. The only > difference is that you deliver the same public key (N-1) times to N > boxes in the case of RSA, but you deliver (N-1)*N/2 different keys in > PSK case, assuming we are talking a full mesh relationship. There is another important differences. With symmetric keys, you must make all the PSK deliveries securely, whether from peer to peer or from server to client, for the system to work. With public key tehniques, it does not matter if the enemy learns the public keys, so there is no need for a secure channel for those. If you have each system generate its own public/private key pair, then only public keys ever need to be transmitted (directly to peers or to the server if you use one) or shared. From owner-ipsec@lists.tislabs.com Sun Dec 2 02:59:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB2Ax0216731; Sun, 2 Dec 2001 02:59:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18691 Sun, 2 Dec 2001 04:55:32 -0500 (EST) Message-ID: <003e01c17b18$9335e960$0c00a8c0@internet> Reply-To: "Mahdavi" From: "Mahdavi" To: "ipsec" Subject: Hub and Spoke RFC ? Date: Sun, 2 Dec 2001 12:51:58 +0330 Organization: PayamPardaz MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C17B30.20D8A480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C17B30.20D8A480 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi.=20 Is there any RFC about Hub and Spoke ?=20 any suggestion?=20 thanks before.=20 mahdavi ------=_NextPart_000_0033_01C17B30.20D8A480 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi.
 
Is there any RFC about Hub and Spoke ?=20
 
any suggestion?
 
thanks before.
 
mahdavi
 
------=_NextPart_000_0033_01C17B30.20D8A480-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Sun Dec 2 02:59:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB2Ax0216737; Sun, 2 Dec 2001 02:59:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18704 Sun, 2 Dec 2001 04:59:01 -0500 (EST) Message-ID: <004701c17b19$102bf680$0c00a8c0@internet> Reply-To: "Mahdavi" From: "Mahdavi" To: "ipsec" Subject: RFC 2628 Implementation ( Crypto API ) Date: Sun, 2 Dec 2001 13:36:45 +0330 Organization: PayamPardaz MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C17B36.625D0BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C17B36.625D0BC0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi. Does any body knows any Implementation of RFC 2628 ( crypto API )? I want to use it for abstracting cryptographic modules of IPSec.=20 Thanks before=20 mahdavi=20 ------=_NextPart_000_0044_01C17B36.625D0BC0 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi.
 
Does any body knows any Implementation = of RFC 2628=20 ( crypto API )?
 
I want to use it for abstracting = cryptographic=20 modules of IPSec.
 
Thanks before
 
mahdavi
 
------=_NextPart_000_0044_01C17B36.625D0BC0-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Mon Dec 3 01:45:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB39jg200814; Mon, 3 Dec 2001 01:45:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21094 Mon, 3 Dec 2001 03:35:20 -0500 (EST) Message-ID: <3C0B3B84.5959DFA3@F-Secure.com> Date: Mon, 03 Dec 2001 10:44:52 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jayant Shukla CC: ipsec@lists.tislabs.com Subject: Re: LAST CALL: NAT TRAVERSAL DRAFTS References: <000001c179bb$4c70f140$9865fea9@TRLSHUKLA1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2001 08:44:52.0047 (UTC) FILETIME=[C622C5F0:01C17BD6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can add a note about your pending patents to the encapsulation draft. It already has a section for it, i.e. the one below > 6. Intellectual Property Rights > > The IETF has been notified of intellectual property rights claimed in > regard to some or all of the specification contained in this document. > For more information consult the online list of claimed rights. > > SSH Communications Security Corp has notified the working group of one > or more patents or patent applications that may be relevant to this > internet-draft. SSH Communications Security Corp has already given a > licence for those patents to the IETF. For more information consult the > online list of claimed rights. Please provide a short statement about this issue and optionally send something to IETF web page as well. Please at least provide your company's name.. Ari > Jayant Shukla wrote: > > These drafts infringe on our pending patents, specifically the part about transport mode > ESP encapsulation. > > BTW, the original ESP-UDP proposal does not infringe on our IP. The modifications > that were made after the San Diego meeting (where we presented > our proposal) are the problem. > > regards, > Jayant > -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Mon Dec 3 06:40:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3EeZ225801; Mon, 3 Dec 2001 06:40:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21425 Mon, 3 Dec 2001 08:23:14 -0500 (EST) Message-Id: <200112031332.IAA28333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-properties-01.txt Date: Mon, 03 Dec 2001 08:32:50 -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 : Security Properties of the IPsec Protocol Suite Author(s) : A. Krywaniuk Filename : draft-ietf-ipsec-properties-01.txt Pages : 18 Date : 30-Nov-01 This document describes the 'security properties' of the IPsec architecture and protocols, including ESP, AH, and IKE. By documenting these properties, we aim to provide a guide for users who wish to understand the abilities and limitations of the IPsec protocol suite. We also hope to provide motivation for future work in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-properties-01.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-properties-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-properties-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011130132742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-properties-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-properties-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130132742.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Dec 3 06:50:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3EoH226442; Mon, 3 Dec 2001 06:50:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21584 Mon, 3 Dec 2001 08:58:08 -0500 (EST) Message-Id: <200112022238.fB2Mcp505964@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: Some comments on JFK Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 02 Dec 2001 14:38:51 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (1) In message 1 the initiator sends g^i. This is replayed in message 3. I see why the initiator needs to tell the responder the group he wants to use but why does it need to communicate g^i? If you simply want the initiator to commit to g^i, why not use a hash? This would save some bandwidth, which is always nice :) (2) The discussion of message 2 says: The authenticator key is changed at least as often as g^r, thus preventing replays of stale data. But the discussion of message 3 says: The Responder's exponential (g^r) is re-sent by the Initiator because the Responder may be generating a new g^r for every new JFK protocol run This seems problematic. Verification of message 3 uses HKr so if you have multiple message 2s outstanding each with different g^rs (and hence different HKrs according to the first quote) then you must maintain a table of old HKrs, one per message. Is this really your intention? I agree that HKr must be changed to prevent replays but I don't see why it needs to be changed as often as g^r. Have I missed something? There appear to be some similar inconsistencies in the discussion of message 3 caching where it says: This cache of messages can be reset as soon as g^r or HKr are changed. Incidentally, it would save some bandwidth if the client echoed a hash of g^r (or a key id provided in message 2) in message 3. Again, this would save some bandwidth. (3) The discussion of message 3 says: The Responder keeps a copy of recently-received Message (3)'s, and their corresponding Message (4). Receiving a duplicate (or replayed) Message (3) causes the Responder to simply retransmit the corresponding Message (4), without creating new state or invoking IPsec. This suggests that the cache lookup is performed on the entire message 3. E.g. if(msg4=table_lookup(message3,message3_len)){ retransmit(msg4); } else ... However, this may open the responder to a DoS attack whereby the attacker replays copies of message 3 with different encrypted blocks (i.e. garbage). The attacker can thereby force a cache miss and force the responder to repeatedly compute g^ir while attempting to process these messages. This entails no particular computational burden on the attacker. The easiest fix for this is for the responder to use only the authenticated data (Ni,Nr,g^i,g^r) or simply HKr as the cache key. (3) Section 2.3 says: The Initiator bears the initial computational burden and must establish round-trip communication with the Responder before the latter is required to perform expensive operations. Note that the initiator does not have to perform expensive computations in order to force the responder to perform expensive computations. It's trivial to generate a plausible-appearing g^i without doing any actual modular exponentiation. This forces the responder to compute g^ir. The initiator does of course have to prove that he can perform a round-trip. The Responder may compute a new exponential g^r for each interaction. This is an expensive option, however, and at times of high load (or attack) it would be inadvisable. Technically speaking, it's not the generation of g^r that is expensive. If you're using g=2 this is can be made pretty fast. It's SIG{r}(g^r) that's expensive, especially if you're using RSA. This is just a nit of course. The key used to protect Messages (3) and (4), Ke, is computed as HMAC{g^ir}{Ni, Nr, 1}. The session key used by IPsec (or any other application), Kir, is HMAC{g^ir}(Ni, Nr, 0). This isn't guaranteed to create a long enough key. In particular, you don't say whether you're using 2 or 3 key 3DES but if you're using 3 key then you're already short at least 8 bits :) Additionally, it seems like bad practice to use the same key for messages (3) and (4). I'd much rather see different keys. Also, I don't see where you're getting the 3DES initialization vector from, though I assume you use CBC. Is it generated from g^ir? Random and included in the message? (4) Section 2.5 contains a minor glitch: implicit in $\mbox{ID}_I$ and $\mbox{ID}_R$) should be accomplished (5) The wire format is, uh... unusual. Is there some reason you've chosen not to go with some fixed packet format specified either by byte-diagrams or some description language. This is not going to be the easiest message format to write a codec for. (6) Performance issues: The standard JFK exchange requires at least the following public-key operations on each side: 1 DH key agreement 1 signature generation 1 signature verification + 1 verification for each peer certificate If you want true PFS the situation is worse since you must also do an extra g^X mod p and signature generation (to sign g^r, whereas if you reuse g^r you can amortize this signature over multiple interactions). This may not sound like a lot but remember that people avoid SSL for performance reasons even though it's substantially cheaper than JFK. I'd certainly expect people to reuse keys rather than use PFS in order to improve performance. This isn't that desirable. It's possible to optimize away the extra signature by adding a little complexity to the protocol. If we change g^r with every interaction we can dispense with the final signature in message 4, provided that message 2 contains a signature over Ni and Nr as well as g^r. [Actually, it's arguable that we could dispense with the signature in message 4 entirely and replace it with a MAC but that would allow an attacker who compromised a single g^r to impersonate the server indefinitely. You could imagine some sort of hack where the signature was over g^r and a timestamp but this seems pretty scary.] Anyway, for this to work the server needs to recognize that it's in PFS mode and do a MAC in message 4 and the client needs to know what to expect when it reads message 4. Let me know if any of this isn't clear or if I've misunderstood something. -Ekr -- [Eric Rescorla ekr@rtfm.com] Author of "SSL and TLS: Designing and Building Secure Systems" http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Dec 3 07:07:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3F7w227308; Mon, 3 Dec 2001 07:07:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21725 Mon, 3 Dec 2001 09:15:44 -0500 (EST) Date: Mon, 3 Dec 2001 16:25:44 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: compare-jfk-sigma.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Several people asked me in personal emails about my opinion of JFK, so after writing enough personal responses I decided to compile the issues in one document and make it public. It is too long to send in an email message (450 lines of text) so I am posting it in the web http://www.ee.technion.ac.il/~hugo/compare-jfk-sigma.txt for whoever is interested in the subject. In this document I comment on the design of JFK with special emphasis on its core security and performance aspects. In addition I offer a comparison with SIGMA. Much of the comparison will be relevant to IKEv2, once this protocol adopts the "signed prf" cryptographic design of SIGMA. There are four parts to the document: A. Background on secure key exchange protocols B. Weaknesses of JFK and comparison to SIGMA C. Number of messages and communication latency D. Specification and implementation complexity While most of the document discusses cryptographic design and performance, part D briefly discusses some specification issues. In particular, I suggest the possible adoption of SSL-like approach to negotiation via standarized ciphersuites. I would like to know what people think about that. Hugo From owner-ipsec@lists.tislabs.com Mon Dec 3 10:35:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3IZw210055; Mon, 3 Dec 2001 10:35:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22179 Mon, 3 Dec 2001 12:42:14 -0500 (EST) Message-ID: <01ea01c17c23$59de3940$32c02ca1@cisco.com> From: "Stephane Beaulieu" To: "ipsec-list" Subject: Comments on IKEv2 Date: Mon, 3 Dec 2001 12:53:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Charlie, Radia, Thanks for taking the effort of putting this together. Here are a few comments and (hopefully) constructive criticisms. My comments focus mainly on management issues. 1 - I'm not a big fan of merging of the three documents. I guess I've grown accustomed to the way it was. I suspect those who wanted to define new DOIs will probably strongly object. Myself, I just find the new doc to be too cluttered with info. No reply necessary on this point. I understand why it was done. I'm just voicing my opinion on this one. 2 - Many nice new features were added (Stateless Cookies, IKE rekey, removal of modes / methods, removal of commit bit, Tero's HASH fix, SA payload negotiation, Continuous Channel Mode, fixing K1, K2, K3 calculation, Critical Bit, many more....) Good Job ! 3- It would have been nice to have Legacy Auth built into IKEv2. Dan had a good proposal with CRACK. I understand the political motivation for leaving this out though. 4 - Section 2.2 (sequence numbers). - What is the expected behavior if a peer receives a sequence number which is out of whack. - It will be possible to receive CREATE-CHILD-SA out of order if several requests are sent simult. What do you do in this case. - If the point of seq numbers is to identify retransmits, then I would guess we would need to keep a window, rather than just a "current" Message ID. - What is the expected behavior if / when MID reaches 2^32. OK it'll never happen, but we still have to write code for it. I expect if this is used for DPD (Dead Peer Detection), then an IKE rekey would be necessary at this point. This should be documented. 5 - Section 2.3. - What is the point of the window size. I figure if Bob can't handle all the requests, he can just drop them, and Alice will retransmit. This seems a little bit simpler than negotiating / managing a window. 6 - Section 2.4 "If a cryptographically protected message has been received from the other side recently, unprotected notifications MAY be ignored. Implementations MUST limit the rate at which they generate responses to unprotected messages." IMO, if you're doing CC mode AND you have DPD (IKEv2's null-query equiv), unprotected notifications MUST ALWAYS be ignored. If the peer can't respond to a null-query, then he is dead. Kill him ! Hopefully (in a good implementation) a peer sending traffic into a black hole will notice that you're not responding to packets, initiate his own null-query, and figure out that the peers are out of sync. See the DPD draft for more discussion on this. 7 - Section 2.8 - Rekeying last sentence "The node that initiated the rekeying SHOULD delete the older SA after the new one is established." I believe the following sentence needs to be added for completeness "The node that is the responder SHOULD NOT delete the older SA until it receives traffic on the new SA". along with a little bit more text talking about the timing issues (i.e. responder's keys are ready before the initiators keys) This timing problem is discussed in detail in Tim Jenkin's expired rekey draft. 8 - Missing AUTH in CREATE-CHILD-SA. I notice that there is no HASH payload in the CREATE-CHILD-SA exchange. This allows an attacker to replay the message and force a DH. Or am I missing something? 9 - Missing AUTH is Notify message. - This is needed, especially if you're sending the null-query for DPD. Else, an attacker could just keep transmitting null-query messages with a different seq number in the header. 10 - INITIAL-CONTACT - We should specify exactly in which messages this should be specified. I would guess that it could be put in message 3 and 4, and it's presence added into the AUTH calculation. 11- Deletes for IKE SAs. - Why can't we specify the COOKIES to identify an IKE SA for deletion? If you get into a situation where a peer (which you have a valid IKE SA with) is sending you data using unknown COOKIES then you could send an IKE delete authenticated by the valid IKE SA to delete the unknown IKE SA. 12- VID payload. - might want to rename this Feature ID payload, since that's what it's become. 13- Nat traversal. I think everyone (vendors at least) agree this is a problem. Any chance of integrating some of the drafts in here? Thanks. Stephane. ------ Stephane Beaulieu S/W Engineer Cisco Systems. email: stephane@cisco.com phone: (613) 254-3678 From owner-ipsec@lists.tislabs.com Mon Dec 3 10:38:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Icu210100; Mon, 3 Dec 2001 10:38:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22161 Mon, 3 Dec 2001 12:39:06 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Wang, Cliff" , "Sandy Harris" , "'IPsec WG'" References: <4652644B98DFF34696801F8F3070D3FE01188475@D2CSPEXM001.smartpipes.com> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Mon, 3 Dec 2001 12:48:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01C17BF8.D61FD200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 03 Dec 2001 17:48:09.0704 (UTC) FILETIME=[ABDA7E80:01C17C22] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C17BF8.D61FD200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cliff, My comment is in blue. In addition, The RSA public/private key is better than symmetric key for the key management and scalability measures with slight=20 advantage of security that the public key can be 'public' as long as the id/public-key binding is intact in apposing to the symmetric key has to defend both. --- David ----- Original Message -----=20 From: "Wang, Cliff" To: "'david chen'" ; "Wang, Cliff" = ; "Sandy Harris" ; "'IPsec WG'" = Sent: Saturday, December 01, 2001 9:33 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > Thanks for the discussion and see my comments in line. >=20 > -----Original Message----- > From: david chen [mailto:ietf_davidchen@hotmail.com] > Sent: Friday, November 30, 2001 11:52 PM > To: Wang, Cliff; Sandy Harris; 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) >=20 > [david] > Cliff, > Let's agree that the pre-shared symmetric key will only *intended* = used by > two devices. Let's look at a 5 devices network and a central keys = deposit > server. For key management purpose, both the pre-shared RSA public = keys and > the symmetic keys will be in a server. (Don't see any scalable model = other > than this) >=20 > For a fully meshed communication model among these 5 devices: > 1) the symmetric keys case: > The server have to store 10 =3D (5*4)/2 s. keys. and keep track of = which link > associate to which key. Before device_1 communicates with device_2, = these > transactions have to happen: the sk_12 will be sent from server to = device_1 > and device_2 through out-of-band secured channel. (well, this dynamic = model > is scalable otherwise if the 10 keys pre-loaed on each of the 5 = devices; it > will be difficult when a device join-in...) After the full mesh is = reached, > each device will have 4 Skeys. >=20 > 2) the RSA keys case: > The server have to strore 5 public keys and don't care about link = info., but > have to associate device to its public key. Before device_1 = communicates > with device_2, these transactions have to happen: the pk_1 is sent = to > device_2 from server and the pk_2 is sent to device_1 trough = out-of-band > secured channel. After the full mesh is reached, each device will have = 4 > public keys and its own private keys. >=20 > Observation: > 1. The symmetric key management model shows that for a single skey, = there > are 3 parties know it. The 2 devices and the server. Clearly, get the = skeys > in the server is most effective to break entire mesh. In contrast to = the > symmetric key, get the public-keys in the RA does not break any secure = link. > (therefore, you can let 3rd party manage this server "RA", as long as = it > guarantees id/public-key bindings) >=20 > [cliff] agree. In this case, a server break-in is a very serious = security > breach and it can jeopardize the whole operation. When such an event > happens, even though the attacker can't take advantage of the public = key, he > can do enough damage to other things such as billing, device = configuration, > etc. >=20 > In contrast with the server break-in case, a device compromise is much = more > likely. Let's take a look at this case. In a full mesh setup, PSK or > pre-shared RSA suffers the same degree, say 4 partners are = compromised. > However, in a hub-spoke setting where only 4 tunnels exists, if a = spoke is > compromised, only the link to the hub is compromised when PSK is used. = If > pre-shared RSA is used, then potentially communication to both hub and = the > rest 3 spoke can be compromised. So in that case, pre-shared RSA is = worse > than a pre-shared key. >=20 In the case of hub-spoke topology (not full-mesh) and=20 pre-shared RSA public key are used, if a spoke is compromised, only the link to the hub is compromised, don't see how the rest of 3 spokes are compromised. Note that, In above example,=20 each device in the hub-spoke only stores its own private key and=20 others' public keys. The server in above exmample is part of = "out-of-band" communication model. It is a reasonable way for key management and not part of 'security link' topology (full mesh, start, bus, and any = 'secured' comm. topology)=20 in the participated devices. (It is possible that the server is a person :-) =20 > [david] > 2. The number of keys in the server is clearly more for symmetric = keys. In > addition, it has to keep track of 'link-id'/key pair which is more = difficult > than that of 'device-id' in the case of public keys. > [cliff] Although the public key may be cached in the server, there is = no > need to save the PSK for a tunnel at the server, since they have been > delivered to both tunnel ends. If a new PSK is needed, just generate = it and > push it out to both ends again. However, the server key storage seems = to be > an implementation issue. >=20 >=20 >=20 > --- David > P.S. I agree that when a device been tampered, all the established = secured > link to this device are broken for either symmetric or asymmetric keys = are > used. >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: "Wang, Cliff" > To: "'david chen'" ; "Sandy Harris" > ; "'IPsec WG'" > Sent: Friday, November 30, 2001 2:49 PM > Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) >=20 >=20 > > This analysis is seriously flawed: > > 1) SPSK or group pre-shared key per box is a bad idea. No security > conscious > > people will adopt this. Because of this serious flaw in assumption, > > all security level comparison are meaningless. > > 2) Once an attacker compromise a box, he has access to either = private > > key > or > > the pre-shared key. > > Any communication with the box's partners are compromised, whether > > using > PKI > > or PSK for IKE authentication. Where is the 200% risk come from? > > 3) why each device needs to have 499 public keys? They are contained > > in > each > > box's cert and delivered as part of IKE exchange. > > > > -----Original Message----- > > From: david chen [mailto:ietf_davidchen@hotmail.com] > > Sent: Friday, November 30, 2001 1:15 PM > > To: Sandy Harris; 'IPsec WG' > > Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS) > > > > > > Here is my observation: > > > > The RSA puliblic/private key (RSA key) is better than symmetric > > pre-shared key (SPSK) in the following way: Suppose both the RSA key > > and SPSK all > using > > centerally managed server in a domain and further assume that the = SPSK > > is one for each device (not one for each pair of device). Let's say > > there are 500 devices in this domain: Then there will be 500 keys = for > > SPSK so is RSA keys. Each device will either have 499 public keys or > > 499 SPSKs. Given the key management (add/delete/remove) are *almost* > > equal, the SPSK has a not ignorable drawback than RSA Key structure: > > To break RSA key, attacker has > to > > break into the device that hold the private key or break into the > > device that itself is the victim of MIM attack. The device has to > > responsible for its own security. (Given the real world that the > > security of a device are not created equal, this is a reasonable > > requirement) > > > > On the other hand, to break a SPSK, the attacker can choose any of = the > > 500 devices to breakin. The risk is much higher for a device due to = it > > demand all other participated devices have the same security level. > > > > Sure, the SPSK can increase the number of keys that limited the key = to > only > > two parties (and increase the complexicity of the key management) = but > still > > it is 200% risk more than RSA key due to it demands the same level = of > > security level on peer. > > > > > > --- David > > > > > > > > ----- Original Message ----- > > From: "Sandy Harris" > > To: "'IPsec WG'" > > Sent: Friday, November 30, 2001 10:10 AM > > Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS) > > > > > > > Alex Alten wrote: > > > > > > > I will re-iterate my position. If a network security system is > > > > properly designed then either Public Key or Symmetric/Private = Key > > > > cryptography will work fine in establishing trust. > > > > > > So far, so good. > > > > > > > I furthermore claim that Symmetric/Private Key cryptography will > > > > scale to great numbers of users > > > > > > Sorry, but this is nonsense. The classic problem with symmetric > > > crypto is key management. It neither scales well nor works well > > > across > > administrative > > > boundaries. > > > > > > Consider n sites which all want to communicate. > > > > > > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of = which > > > is known to exactly two players and none of the others. Moreover, > > > you have to communicate those keys securely to the second player = in > > > each case, and then keep it secure on both systems. > > > > > > With public key, you need only n key pairs. There is no need to > > communicate > > > keys securely; the system is designed to work even if the enemy > > > knows the public keys. Nor do you have to manage security for > > > multiple keys, or keep track of who each key is shared with. You > > > just need to keep your private key secure, not shared with anyone. > > > > > > Of course you can build a kerberos-like system using symmetric > > > ciphers that has many of the advantages of public key. Using a > > > central key server reduces the number of keys to n = client-to-server > > > keys and may simplify management. However, I doubt such a > > > centralised model is appropriate for Internet infrastructure. > > > > > > > and I use the bank ATM secure network using DES as an excellent > > > > example. ... > > > > > > I think that's an irrelevant example. A tightly controlled single > > > purpose terminal-to-mainframe network under a single = administrative > > > authority bears no useful resemblanmce to the Internet. Someone = gave > > > a good detailed analysis earlier in the thread. You should re-read > > > it. > > > > > > > As far as I'm concerned this should be the end of the discussion > > > > > > I agree, but for opposite reasons. > > > > > > > about whether or not Symmetric/Private Key cryptography can = scale > > > > to large numbers of users in an efficient, easy to use by = ordinary > > > > people, inexpensive to implement manner and interoperable = between > > > > devices made by different manufacturers and maintained by > > > > different organizations. It has been done for the past 20 years = by > what > > is > > > > probably the most successful world-wide commercial networked > > > > security > > system. > > > > > > > > Anyone who still claims that Public Key is superior to > > > > Symmetric/Private > > Key > > > > cryptography, or that it is the only way to scale, is a *damn > > > > fool* and > > should > > > > be treated as such. > > > > > > How about "obviously superior for some purposes, including most = key > > > distribution applications" and "almost always the best way to = build > > > scalable systems"? > > > > > > Methinks you'll consider me a fool. I heartily return the = sentiment. > > > > > >=20 ------=_NextPart_000_007E_01C17BF8.D61FD200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cliff,
My comment is in = blue.
 
In addition,
The RSA public/private key is better = than symmetric=20 key for
the key management and scalability = measures with=20 slight
advantage of security that the public = key can be=20 'public' as long
as the id/public-key binding is intact = in apposing=20 to
the symmetric key has to defend = both.
 
--- David
 
 
----- Original Message -----
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'david chen'" <ietf_davidchen@hotmail.com>; "Wang,=20 Cliff" <CWang@smartpipes.com>; "Sandy=20 Harris" <sandy@storm.ca>; = "'IPsec WG'"=20 <ipsec@lists.tislabs.com>
Sent: Saturday, December 01, 2001 9:33=20 PM
Subject: RE: On shared keys (was RE: = SOI: identity=20 protection and DOS)

> Thanks for the discussion and see = my comments=20 in line.
>
> -----Original Message-----
> From: david = chen=20 [mailto:ietf_davidchen@hotmail.com]
> Sent: Friday, November 30, = 2001=20 11:52 PM
> To: Wang, Cliff; Sandy Harris; 'IPsec WG'
> = Subject: Re:=20 On shared keys (was RE: SOI: identity protection and DOS)
> =
>=20 [david]
> Cliff,
> Let's agree that the pre-shared symmetric = key=20 will only *intended* used by
> two devices. Let's look at a 5 = devices=20 network and a central keys deposit
> server. For key management = purpose,=20 both the pre-shared RSA public keys and
> the symmetic keys will = be in a=20 server.  (Don't see any scalable model other
> than = this)
>=20
> For a fully meshed communication model among these 5 = devices:
>=20 1) the symmetric keys case:
> The server have to store 10 =3D = (5*4)/2 s.=20 keys. and keep track of which link
> associate to which key. = Before=20 device_1 communicates with device_2, these
> transactions have to=20 happen:  the sk_12 will be sent from server to device_1
> and = device_2 through out-of-band secured channel. (well, this dynamic = model
>=20 is scalable otherwise if the 10 keys pre-loaed on each of the 5 devices; = it
> will be difficult when a device join-in...) After the full = mesh is=20 reached,
> each device will have 4 Skeys.
>
> 2) the = RSA keys=20 case:
> The server have to strore 5 public keys and don't care = about link=20 info., but
> have to associate device to its public key. Before = device_1=20 communicates
> with device_2, these transactions have to =20 happen:  the pk_1 is sent to
> device_2 from server and the = pk_2 is=20 sent to device_1 trough out-of-band
> secured channel. After the = full mesh=20 is reached, each device will have 4
> public keys and its own = private=20 keys.
>
> Observation:
> 1. The symmetric key = management=20 model shows that for a single skey, there
> are 3 parties know it. = The 2=20 devices and the server.  Clearly, get the skeys
> in the = server is=20 most effective to break entire mesh. In contrast to the
> = symmetric key,=20 get the public-keys in the RA does not break any secure link.
>=20 (therefore, you can let 3rd party manage this server "RA", as long as = it
>=20 guarantees id/public-key bindings)
>
> [cliff] agree. In = this case,=20 a server break-in is a very serious security
> breach and it can=20 jeopardize the whole operation. When such an event
> happens, even = though=20 the attacker can't take advantage of the public key, he
> can do = enough=20 damage to other things such as billing, device configuration,
>=20 etc.
>
> In contrast with the server break-in case, a = device=20 compromise is much more
> likely. Let's take a look at this case. = In a=20 full mesh setup, PSK or
> pre-shared RSA suffers the same degree, = say 4=20 partners are compromised.
> However, in a hub-spoke setting where = only 4=20 tunnels exists, if a spoke is
> compromised, only the link to the = hub is=20 compromised when PSK is used. If
> pre-shared RSA is used, then=20 potentially communication to both hub and the
> rest 3 spoke can = be=20 compromised. So in that case, pre-shared RSA is worse
> than a = pre-shared=20 key.
>
In the case of = hub-spoke=20 topology (not full-mesh) and
pre-shared RSA = public key are=20 used,
if a spoke is = compromised, only the=20 link to the hub is compromised,
don't see how the rest = of 3 spokes=20 are compromised.
Note that, In = above=20 example, 
each device in the = hub-spoke only=20 stores its own private key and
others' public=20 keys.    The server in above exmample is part of=20 "out-of-band"
communication=20 model.  It is a reasonable way for key management=20 and
not part of=20 'security link' topology (full mesh, start, bus, and any 'secured' = comm.=20 topology)
in the = participated=20 devices.
(It = is possible=20 that the server is a person :-)  =20

> = [david]
>=20 2. The number of keys in the server is clearly more for symmetric = keys. =20 In
> addition, it has to keep track of 'link-id'/key pair which is = more=20 difficult
> than that of 'device-id' in the case of public = keys.
>=20 [cliff] Although the public key may be cached in the server, there is = no
>=20 need to save the PSK for a tunnel at the server, since they have = been
>=20 delivered to both tunnel ends. If a new PSK is needed, just generate it=20 and
> push it out to both ends again. However, the server key = storage=20 seems to be
> an implementation issue.
>
>
> =
>=20 --- David
> P.S. I agree that when a device been tampered, all the = established secured
> link to this device are broken for either = symmetric=20 or asymmetric keys are
> used.
>
>
>
> =
>=20 ----- Original Message -----
> From: "Wang, Cliff" <CWang@smartpipes.com>
> To:=20 "'david chen'" <ietf_davidchen@hotmail.com>; "Sandy Harris"
> <sandy@storm.ca>; = "'IPsec WG'"=20 <ipsec@lists.tislabs.com>
>=20 Sent: Friday, November 30, 2001 2:49 PM
> Subject: RE: On shared = keys (was=20 RE: SOI: identity protection and DOS)
>
>
> > = This=20 analysis is seriously flawed:
> > 1) SPSK or group pre-shared = key per=20 box is a bad idea. No security
> conscious
> > people = will adopt=20 this. Because of this serious flaw in assumption,
> > all = security=20 level comparison are meaningless.
> > 2) Once an attacker = compromise a=20 box, he has access to either private
> > key
> or
> = >=20 the pre-shared key.
> > Any communication with the box's = partners are=20 compromised, whether
> > using
> PKI
> > or PSK = for IKE=20 authentication. Where is the 200% risk come from?
> > 3) why = each=20 device needs to have 499 public keys? They are contained
> > = in
>=20 each
> > box's cert and delivered as part of IKE = exchange.
>=20 >
> > -----Original Message-----
> > From: david = chen=20 [mailto:ietf_davidchen@hotmail.com]
> > Sent: Friday, November = 30, 2001=20 1:15 PM
> > To: Sandy Harris; 'IPsec WG'
> > Subject: = Re: On=20 shared keys (was RE: SOI: identity protection and DOS)
> = >
>=20 >
> > Here is my observation:
> >
> > The = RSA=20 puliblic/private key (RSA key) is better than symmetric
> > = pre-shared=20 key (SPSK) in the following way: Suppose both the RSA key
> > = and SPSK=20 all
> using
> > centerally managed server in a domain and = further=20 assume that the SPSK
> > is one for each device (not one for = each pair=20 of device). Let's say
> > there are 500 devices in this domain: = Then=20 there will be 500 keys for
> > SPSK so is RSA keys. Each device = will=20 either have 499 public keys or
> > 499 SPSKs. Given the key = management=20 (add/delete/remove) are *almost*
> > equal, the SPSK has a not=20 ignorable drawback than RSA Key structure:
> > To break RSA = key,=20 attacker has
> to
> > break into the device that hold the = private=20 key or break into the
> > device that itself is the victim of = MIM=20 attack. The device has to
> > responsible for its own security. = (Given=20 the real world that the
> > security of a device are not = created equal,=20 this is a reasonable
> > requirement)
> >
> > = On the=20 other hand, to break a SPSK, the attacker can choose any of the
> = > 500=20 devices to breakin. The risk is much higher for a device due to = it
> >=20 demand all other participated devices have the same security = level.
>=20 >
> > Sure, the SPSK can increase the number of keys that = limited=20 the key to
> only
> > two parties (and increase the = complexicity=20 of the key management) but
> still
> > it is 200% risk = more than=20 RSA key due to it demands the same level of
> > security level = on=20 peer.
> >
> >
> > --- David
> = >
>=20 >
> >
> > ----- Original Message -----
> > = From:=20 "Sandy Harris" <sandy@storm.ca>
> > To:=20 "'IPsec WG'" <ipsec@lists.tislabs.com>
> > Sent: Friday, November 30, 2001 10:10 = AM
> >=20 Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS)
>=20 >
> >
> > > Alex Alten wrote:
> > = >
>=20 > > > I will re-iterate my position.  If a network = security system=20 is
> > > > properly designed then either Public Key or=20 Symmetric/Private Key
> > > > cryptography will work fine = in=20 establishing trust.
> > >
> > > So far, so = good.
>=20 > >
> > > > I furthermore claim that = Symmetric/Private Key=20 cryptography will
> > > > scale to great numbers of = users
>=20 > >
> > > Sorry, but this is nonsense. The classic = problem=20 with symmetric
> > > crypto is key management. It neither = scales=20 well nor works well
> > > across
> > = administrative
>=20 > > boundaries.
> > >
> > > Consider n = sites which=20 all want to communicate.
> > >
> > > For = symmetric=20 ciphers, you need n*(n-1)/2 unique keys, each of which
> > > = is=20 known to exactly two players and none of the others. Moreover,
> = > >=20 you have to communicate those keys securely to the second player = in
> >=20 > each case, and then keep it secure on both systems.
> >=20 >
> > > With public key, you need only n key pairs. There = is no=20 need to
> > communicate
> > > keys securely; the = system is=20 designed to work even if the enemy
> > > knows the public = keys. Nor=20 do you have to manage security for
> > > multiple keys, or = keep=20 track of who each key is shared with. You
> > > just need to = keep=20 your private key secure, not shared with anyone.
> > = >
> >=20 > Of course you can build a kerberos-like system using = symmetric
> >=20 > ciphers that has many of the advantages of public key. Using = a
> >=20 > central key server reduces the number of keys to n = client-to-server
>=20 > > keys and may simplify management. However, I doubt such = a
> >=20 > centralised model is appropriate for Internet = infrastructure.
> >=20 >
> > > > and I use the bank ATM secure network using = DES as=20 an excellent
> > > > example. ...
> > = >
> >=20 > I think that's an irrelevant example. A tightly controlled = single
>=20 > > purpose terminal-to-mainframe network under a single=20 administrative
> > > authority bears no useful resemblanmce = to the=20 Internet. Someone gave
> > > a good detailed analysis = earlier in the=20 thread. You should re-read
> > > it.
> > = >
> >=20 > > As far as I'm concerned this should be the end of the=20 discussion
> > >
> > > I agree, but for opposite = reasons.
> > >
> > > > about whether or not=20 Symmetric/Private Key cryptography can scale
> > > > to = large=20 numbers of users in an efficient, easy to use by ordinary
> > = > >=20 people, inexpensive to implement manner and interoperable = between
> >=20 > > devices made by different manufacturers and maintained = by
> >=20 > > different organizations.  It has been done for the past = 20 years=20 by
> what
> > is
> > > > probably the most = successful world-wide commercial networked
> > > >=20 security
> > system.
> > > >
> > > = >=20 Anyone who still claims that Public Key is superior to
> > > = >=20 Symmetric/Private
> > Key
> > > > cryptography, = or that=20 it is the only way to scale, is a *damn
> > > > fool* = and
>=20 > should
> > > > be treated as such.
> > = >
>=20 > > How about "obviously superior for some purposes, including = most=20 key
> > > distribution applications" and "almost always the = best way=20 to build
> > > scalable systems"?
> > >
> = >=20 > Methinks you'll consider me a fool. I heartily return the=20 sentiment.
> > >
> >
> =
------=_NextPart_000_007E_01C17BF8.D61FD200-- From owner-ipsec@lists.tislabs.com Mon Dec 3 11:18:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3JIB212215; Mon, 3 Dec 2001 11:18:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22329 Mon, 3 Dec 2001 13:30:21 -0500 (EST) To: "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: Re: Some comments on JFK References: <200112031815.fB3IEqpv029879@coredump.cs.columbia.edu> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 03 Dec 2001 10:38:54 -0800 In-Reply-To: "Angelos D. Keromytis"'s message of "Mon, 03 Dec 2001 13:14:52 -0500" Message-ID: Lines: 109 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Angelos D. Keromytis" writes: > In message <200112022238.fB2Mcp505964@romeo.rtfm.com>, Eric Rescorla writes: > >This seems problematic. Verification of message 3 uses HKr so if you > >have multiple message 2s outstanding each with different g^rs (and > >hence different HKrs according to the first quote) then you must > >maintain a table of old HKrs, one per message. Is this really your > >intention? > > If you have different g^r's, you need to keep the corresponding r's anyway, so > you can keep HKr as well. If you're re-using the same (r, g^r) pair, you only > need to keep those around (and only one HKr). Right, but what's the virtue of changing HKr so frequently? > >Note that the initiator does not have to perform expensive computations > >in order to force the responder to perform expensive computations. > >It's trivial to generate a plausible-appearing g^i without doing > >any actual modular exponentiation. This forces the responder to > >compute g^ir. The initiator does of course have to prove that he > >can perform a round-trip. > > Right, but valid initiators do have to spend cycles before the responder > does. Yes, but purpose of forcing the initiator to spend cycles before the responder is for DoS prevention, not rate throttling of legitimate initiators, no? > > The key used to protect > > Messages (3) and (4), Ke, is computed as HMAC{g^ir}{Ni, Nr, 1}. The > > session key used by IPsec (or any other application), Kir, is > > HMAC{g^ir}(Ni, Nr, 0). > > > >This isn't guaranteed to create a long enough key. In particular, you > >don't say whether you're using 2 or 3 key 3DES but if you're using 3 > >key then you're already short at least 8 bits :) > > Good point -- the reason for selecting this scheme is that it was shown to be > secure (ask Omer Reingold for more details -- co-author of the draft). I understand that Uri has a provably secure PRF scheme that will generate an essentially unlimited amount of keying material from your shared key: draft-blumenthal-keygen-02.txt. This would eem to be a superior choice. > >Additionally, it seems > >like bad practice to use the same key for messages (3) and (4). I'd > >much rather see different keys. > > Actually, there is no security problem by reusing the same key in the > two messages (the encryption is used only for privacy purposes -- the > security of the exchange is based on the signatures). This makes some unstated assumptions about the encryption algorithm. For instance, using RC4 or DES-ECB could lead to revelation of plaintext. A design that used separate keys would not have this problem. If you're going to have substitutable algorithms it's better to design for the worst case. > CBC seems the most likely candidate, although we wouldn't want to preclude > some of the newer modes of operation. If there is an IV, it is random and > included in the message. Ok. This will obviously need to be specified. > >(5) The wire format is, uh... unusual. Is there some reason > > you've chosen not to go with some fixed packet format specified > > either by byte-diagrams or some description language. This is > > not going to be the easiest message format to write a codec > > for. > > I thought it was one of the simplest formats imaginable... Simple, but annoying. > > It's possible to optimize away the extra signature by adding a little > > complexity to the protocol. If we change g^r with every interaction > > we can dispense with the final signature in message 4, provided that > > message 2 contains a signature over Ni and Nr as well as g^r. > > Always changing g^r requires state to be kept for each Message 1 received, > thereby re-introducing the problem with IKE. That would be a clear violation > of our design goals. I don't think what I wrote here was clear. I'm suggesting that the responder operate in two modes: (1) Ordinary PFS mode where a new g^r is created for each interaction and state is created after msg 1. (2) "Safe" mode (presumably where the responder believes itself to be under attack) and g^r is reused. This is already possible with JFK but at a performance cost--PFS mode is faster than safe mode. The modifications to the protocol that I suggested make PFS mode as fast as safe mode. > > [Actually, it's arguable that we could dispense with the signature > > in message 4 entirely and replace it with a MAC but that would > > allow an attacker who compromised a single g^r to impersonate the > > server indefinitely. You could imagine some sort of hack where > > the signature was over g^r and a timestamp but this seems pretty > > scary.] > > To impersonate the server indefinitely, the attacker also has to have the > server's RSA key (and if he does, there's no protocol to protect you against > that :-) I was talking about a situation in which you replaced the signature in message 4 with a MAC. In that case, an attacker who recovers any r,g^r pair can pose as the server since he can capture a g^r signature off the wire. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Dec 3 11:47:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Jln213992; Mon, 3 Dec 2001 11:47:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22468 Mon, 3 Dec 2001 14:05:29 -0500 (EST) Message-Id: <200112031815.fB3IEqpv029879@coredump.cs.columbia.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Eric Rescorla Cc: ipsec@lists.tislabs.com Subject: Re: Some comments on JFK In-reply-to: Your message of "Sun, 02 Dec 2001 14:38:51 PST." <200112022238.fB2Mcp505964@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Dec 2001 13:14:52 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200112022238.fB2Mcp505964@romeo.rtfm.com>, Eric Rescorla writes: >(1) In message 1 the initiator sends g^i. This is replayed in message >3. I see why the initiator needs to tell the responder the group he >wants to use but why does it need to communicate g^i? If you simply >want the initiator to commit to g^i, why not use a hash? This would >save some bandwidth, which is always nice :) I think this makes sense. >(2) The discussion of message 2 says: > The authenticator key is changed at least > as often as g^r, thus preventing replays of stale data. > > But the discussion of message 3 says: > The Responder's exponential (g^r) is re-sent by the Initiator because > the Responder may be generating a new g^r for every new JFK > protocol run > >This seems problematic. Verification of message 3 uses HKr so if you >have multiple message 2s outstanding each with different g^rs (and >hence different HKrs according to the first quote) then you must >maintain a table of old HKrs, one per message. Is this really your >intention? If you have different g^r's, you need to keep the corresponding r's anyway, so you can keep HKr as well. If you're re-using the same (r, g^r) pair, you only need to keep those around (and only one HKr). >There appear to be some similar inconsistencies in the discussion of >message 3 caching where it says: > > This cache of messages can be reset as soon as g^r or HKr are > changed. > >Incidentally, it would save some bandwidth if the client echoed >a hash of g^r (or a key id provided in message 2) in message 3. >Again, this would save some bandwidth. Generally, yes. > >(3) The discussion of message 3 says: > > The Responder keeps a copy of recently-received Message (3)'s, and > their corresponding Message (4). Receiving a duplicate (or > replayed) Message (3) causes the Responder to simply retransmit the > corresponding Message (4), without creating new state or invoking IPsec. > >This suggests that the cache lookup is performed on the entire message 3. >E.g. > > if(msg4=table_lookup(message3,message3_len)){ > retransmit(msg4); > } > else ... > >However, this may open the responder to a DoS attack whereby the >attacker replays copies of message 3 with different encrypted blocks >(i.e. garbage). The attacker can thereby force a cache miss and force >the responder to repeatedly compute g^ir while attempting to process >these messages. This entails no particular computational burden on >the attacker. > >The easiest fix for this is for the responder to use only the >authenticated data (Ni,Nr,g^i,g^r) or simply HKr as the cache key. Yes -- sorry, I suppose that wasn't clear in the text; the intent was to have the authenticator be the key. >(3) Section 2.3 says: > > The Initiator bears the initial computational burden > and must establish round-trip communication with the Responder > before the latter is required to perform expensive operations. > >Note that the initiator does not have to perform expensive computations >in order to force the responder to perform expensive computations. >It's trivial to generate a plausible-appearing g^i without doing >any actual modular exponentiation. This forces the responder to >compute g^ir. The initiator does of course have to prove that he >can perform a round-trip. Right, but valid initiators do have to spend cycles before the responder does. > The Responder may compute a new exponential g^r for each > interaction. This is an expensive option, however, and at times of > high load (or attack) it would be inadvisable. > >Technically speaking, it's not the generation of g^r that is >expensive. If you're using g=2 this is can be made pretty fast. >It's SIG{r}(g^r) that's expensive, especially if you're using >RSA. This is just a nit of course. It's still more expensive than reusing the old g^r :-) > The key used to protect > Messages (3) and (4), Ke, is computed as HMAC{g^ir}{Ni, Nr, 1}. The > session key used by IPsec (or any other application), Kir, is > HMAC{g^ir}(Ni, Nr, 0). > >This isn't guaranteed to create a long enough key. In particular, you >don't say whether you're using 2 or 3 key 3DES but if you're using 3 >key then you're already short at least 8 bits :) Good point -- the reason for selecting this scheme is that it was shown to be secure (ask Omer Reingold for more details -- co-author of the draft). >Additionally, it seems >like bad practice to use the same key for messages (3) and (4). I'd >much rather see different keys. Actually, there is no security problem by reusing the same key in the two messages (the encryption is used only for privacy purposes -- the security of the exchange is based on the signatures). >Also, I don't see where you're getting the 3DES initialization vector >from, though I assume you use CBC. Is it generated from g^ir? Random >and included in the message? CBC seems the most likely candidate, although we wouldn't want to preclude some of the newer modes of operation. If there is an IV, it is random and included in the message. >(4) Section 2.5 contains a minor glitch: > > implicit in $\mbox{ID}_I$ and $\mbox{ID}_R$) should be accomplished Oops, my bad. >(5) The wire format is, uh... unusual. Is there some reason > you've chosen not to go with some fixed packet format specified > either by byte-diagrams or some description language. This is > not going to be the easiest message format to write a codec > for. I thought it was one of the simplest formats imaginable... Anyway, we're not really attached to any format -- the one in the draft is just a strawman (we had to have something in there -- at the very least for the prototype implementations --- more on this, at the IETF :) >(6) Performance issues: > > The standard JFK exchange requires at least the following > public-key operations on each side: > > 1 DH key agreement > 1 signature generation > 1 signature verification + 1 verification for each peer certificate > > If you want true PFS the situation is worse since you must > also do an extra g^X mod p and signature generation (to sign g^r, > whereas if you reuse g^r you can amortize this signature over multiple > interactions). This may not sound like a lot but remember that people > avoid SSL for performance reasons even though it's substantially cheaper > than JFK. I'd certainly expect people to reuse keys rather than > use PFS in order to improve performance. This isn't that desirable. Bear in mind that any protocol can reuse a g^x value across multiple exchanges -- it's strictly an implementation issue. That said, it is possible to do away with the signature in message 2. The purpose of that signature is to prevent active attacks on the identity of the initiator (an attacker can introduce their own g^r in a message 2, and the Initiator would encrypt with that derived key). If protection of the Initiator from this attack is not deemed necessary, the signature can go. (You can protect the Initiator from active identity attacks without a signature if you add another message to the protocol, as SIGMA does. However, there is a good practical reason not to have an odd number of messages in a protocol...) > It's possible to optimize away the extra signature by adding a little > complexity to the protocol. If we change g^r with every interaction > we can dispense with the final signature in message 4, provided that > message 2 contains a signature over Ni and Nr as well as g^r. Always changing g^r requires state to be kept for each Message 1 received, thereby re-introducing the problem with IKE. That would be a clear violation of our design goals. > [Actually, it's arguable that we could dispense with the signature > in message 4 entirely and replace it with a MAC but that would > allow an attacker who compromised a single g^r to impersonate the > server indefinitely. You could imagine some sort of hack where > the signature was over g^r and a timestamp but this seems pretty > scary.] To impersonate the server indefinitely, the attacker also has to have the server's RSA key (and if he does, there's no protocol to protect you against that :-) I think you mean that the attacker can mount active identity attacks on any Initiator that tries to contact the server. My feeling is that if the attacker can get an r (and the corresponding g^r), with overwhelming probability he also has the server's RSA key. Thus, back to square one (meaning, we need to depend on revocation etc. to protect against that). Thanks for the comments! -Angelos From owner-ipsec@lists.tislabs.com Mon Dec 3 11:48:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3JmC214023; Mon, 3 Dec 2001 11:48:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22367 Mon, 3 Dec 2001 13:51:30 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698AE@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Hugo Krawczyk'" , IPsec WG Subject: RE: compare-jfk-sigma.txt Date: Mon, 3 Dec 2001 11:00:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17C2C.CB6CE080" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17C2C.CB6CE080 Content-Type: text/plain; charset="iso-8859-1" I for one would really like to NOT consider negotiation of ciphersuites. At present the set 'possible ciphers' is very large, the set 'recommended ciphers' is actually small. We have RSA, DSA, DH, AES, SHA-1 and the AES SHA. I have yet to see a cryptographic negotiation that adds security over 'try your strongest cipher, if that is rejected read the list of acceptable ciphers and choose the strongest'. I have seen plenty of rational implementations that will behave disastrously. for example if you build a crypto application on top of CAPI a rational implementation choice would be to search through the cipher store for supported algorithms and offer that set. This is a bit of a lose however when someone installs a cryptographic provider that implements a broken cipher such as MD4 or (worse) a test cipher suite such as NULL or Rot 13. Looking at Sigma the reason I hate it is that the initiator does not know if the operation succeeded. To me that is bad design practice. In XKASS the responder doe not know if the protocol completes, but the responder does not care. It seems to me that you have to add in some sort of acknowledgement message into the protocol and that it has to incorporate some sort of cryptographic assurance from the responder that the protocol completed successfully and that this has to be included in the analysis of the cryptography. In effect you have failed to specify a necessary and important message. This should appear up front: 1. HDR, SA, KE, Ni [, OIDii] --> 2. <-- HDR, SA, KE, Nr, *, [ *, ] * 3. HDR, *, [ *, ] * --> 4. <-- New message to be specified. After adding this in the comparison between JFK and Sigma does not appear to be as strongly differentiated as it appears in the paper. Specifically to reply to the points raised in the paper: (1) JFK FORCES the disclosure of R's identity. So what? The whole idea that you can keep your identity secret in IPSEC is pretty questionable, the idea that both parties can conceal their identity in an IP exchange is pretty wierd. If I am accessing the amazon.com web site I will first resolve the name to an address via DNS and proceed. One can make a case for concealling the identity of the client. BUT THE SERVER??? What are folk smoking? What is the use case here? Why should an infrastructure protocol support such a mode? Is identity conceallment in the key exchange algorithm suffiecient to conceal identity in the mode of use? I don't think so. As with Chaum's digital cash, what is the point of using e-coins if the merchant is running a double click ad server on their site? If you insist on identity conceallment for the client I don't think that either JFK or Sigma succeeds when the entire use case is considered. 2) If the responder does not want to generate such a new signature with each exchange it MUST keep g^r for several (and possibly many) different exchanges. Why not pre-compute g^r and the signature? It is a trivial matter for a responder to pre-compute new cryptographic parameters and store them ready for the next request. If one was building a really high performance implementation this could even be done on a separate processor. I do not approave of the conflation of an imagined performance optimization here being described as a security issue. Clearly JFK can be implemented securely and nobody who shared use of g^r would be unaware of the consequences. 3) Yet another security cost of JFK's design is that it suffices for the attacker to find a single pair (r,SIG(g^r)) (e.g. via the exposure of a single session state) to be able to trick all initiators in subsequent exchanges with R to disclose their identities. Again, I am exceptionally skeptical as to the possibility of identity conceallment. Sigma may be imune to the attack as you claim, but I am almost certainly going to be able to uncover your identity from your IP address so what are you actually gaining? However the objection does appear to call into question the value of the pre-exchange from the point of view of identity conceallment. The DoS protection ability still remains of course. But should a protocol require an extra round trip on every occasion for that sole purpose? Wouldn't it be better to start the exchange assuming it will complete in one round trip and only require cookies to be sent on the occasions when the responder is actually under a DoS attack? 4) By forcing a signature of each party on the peer's identity JFK always leaves a transferable proof of communication for each exchange. This can be used to provide a proof (to a judge, journalist or business competitor) that a communication with certain peer happened. Again, look at the IP traces. Believe me, no judge has ever demanded that a digital communication be digitally signed before accepting it as evidence that a communication took place between the parties. The purpose of a digital signature is to authenticate the contents of the transmission. In order to guarantee concealment of identity you would need to use some sort of anonymizer service to conceal the packets (go ask Austin Hill about the economic viability of such an enterprise). So allow the anonymizer to perform an intermediate key agreement under its credentials, or issue users with 'disposable credentials' that are used once only for the sole purpose of establishing a secure channel for a key agreement. I strongly suspect that there is no protocol that provides perfect identity conceallment which does not do so by in effect performing a complete duplicate key agrement. The reason being that to securely exchange credentials requires the very assurances a public key exchange is meant to establish. Identity concealment is a wonderful subject for academic study. It is a bogus requirement for IPSEC. (5) The DoS defense mechanism at JFK is computationally wasteful, a cost that may be crucial during actual DoS attacks. The reason is that the input to HMAC for generating the DoS cookie is very long. This complaint appears to be scraping the barrel. HMAC functions are cheap compared to an exponentiation. In XKASS we put everything we can through the HMAC because that makes the proofs much easier. I could care less about being miserly with computational costs, round trips and exponentiations are the overheads here. In contrast, the DoS mechanism in SIGMA is used at the discretion of the responder (and only in periods of time during which the responder's node discovers actual DoS activity). Which is precisely the modification I am proposing to JFK, junk the identity conceallment which will never really work anyway and cut the exchange down from two round trips to one. CONCLUSION: SIGMA does a better job than JFK both in respect to security and performance. In particular, it provides: I don't think you make a case. The only grounds on which you made any points were on the identity concealment issue which I repeat is bogus and should be excised from the requirements anyway. Moreover, the extra costs and weaknesses in JFK (maybe with the exception of point (5)) are all UNAVOIDABLE without a re-design of the core cryptographic protocol. Yet, I want to emphasize the "provable secure" nature of JFK. This was stated as a main goal by the protocol authors, and is achieved for the core cryptographic protocol. I don't give a hoot for 'provable'. I only care about 'proven'. If people want to claim that they have analysed the security properties of a protocol in a formal protocol that is great. However until the proof and the calculus are shown it is a bit like the difference between 'B2 equivalent' and 'B2 certified' the number of copies of 'B2 equivalent' UNIX installations that shipped with a version of sendmail that had been broken 3 years earlier in the 1990s was very high. On section C, XKASS requires two messages, JFK four, SIGMA three or five under DoS attack, four or six if you add in the acks. Incorporating the JFK cookie concept into XKASS gives us two or four under Dos attack. Conclusions 1. Sigma is not a noticable improvement over JFK or XKASS. It is claimed to provide better protection against irrelevant risks and requires an extra round trip under realistic ones. 2. The proposal to separate the DoS cookie into a separate exchange is a good one however and may be achieved through a minor modification which will reduce the number of round trips required to one at the cost of eliminating the not very usefull identity concealment feature and making the protocol look pretty much identical to XKASS. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C17C2C.CB6CE080 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17C2C.CB6CE080-- From owner-ipsec@lists.tislabs.com Mon Dec 3 11:48:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3JmF214037; Mon, 3 Dec 2001 11:48:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22376 Mon, 3 Dec 2001 13:53:31 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698AF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'EKR'" , "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: RE: Some comments on JFK Date: Mon, 3 Dec 2001 11:03:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17C2D.2D6B3DE0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17C2D.2D6B3DE0 Content-Type: text/plain; charset="iso-8859-1" > Yes, but purpose of forcing the initiator to spend cycles before the > responder is for DoS prevention, not rate throttling of legitimate > initiators, no? Carefull, you don't 'force' the initiator to spend cycles before the responder. What you actually do is to force the initiator to prove that it can recieve packets sent to the purported initiator address before the responder spends cycles. The initiator can send any old junk to the respinder and the responder will not know until the cycles are spent. Phill ------_=_NextPart_000_01C17C2D.2D6B3DE0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17C2D.2D6B3DE0-- From owner-ipsec@lists.tislabs.com Mon Dec 3 11:49:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Jnf214121; Mon, 3 Dec 2001 11:49:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22495 Mon, 3 Dec 2001 14:09:32 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698B0@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? Date: Mon, 3 Dec 2001 11:19:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17C2F.6BFD3CF0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17C2F.6BFD3CF0 Content-Type: text/plain; charset="iso-8859-1" I think before we start discussing selection we should look to see what other alternatives are on offer, and whether the discussion leads to better choices emerging. I really don't think we should go down to the bit level yet. Syntax is the hobgoblin of tiny minds. Lets agree on the principles first. In particular the improvements in JFK are largely the result of discovering that certain 'requirements' to be dictated by cryptographic dogma rather than the real world. In the real world we don't need a negotiation algorithm to support several hundred possible combinations of algorithms because there is in general only one 'prefered set' at a time and it typically only changes every 5 years or so. Equally it may turn out that certain 'requirements' are actually unreachable. concealment of identity for example. My preferred means of dealing with that is to 1. Issue every device an IP identity credential bound to its IP address. This is the ONLY form of identity that can provably prevent any additional disclosure of identity in an IP environment since your IP address is known in any case. 2. Perform two sequential key agreements, ] first an IP address based agreement second an identity based agreement encrypted under the key of (1). Unfortunately I did not have time between the publication of JFK to reformat XKASS as an internet draft and submitt in time for the IETF meeting cut off. the paper has been available for several months now however and for those of you who do not like pdf a version in internet draft format will shortly be available, albeit with the inevitable readbility problems of plaintext documents describing mathematical algorithms. If people are interested the paper is at: http://www.xmltrustcenter.org/research/xkass/index.htm The intended application is XML Web services, however readers will note a distinct resemblance to JFK. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C17C2F.6BFD3CF0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17C2F.6BFD3CF0-- From owner-ipsec@lists.tislabs.com Mon Dec 3 11:50:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Jov214208; Mon, 3 Dec 2001 11:50:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22580 Mon, 3 Dec 2001 14:12:55 -0500 (EST) To: "Angelos D. Keromytis" Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Subject: Re: Some comments on JFK References: <200112031916.fB3JFmpv031573@coredump.cs.columbia.edu> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 03 Dec 2001 11:20:46 -0800 In-Reply-To: "Angelos D. Keromytis"'s message of "Mon, 03 Dec 2001 14:15:48 -0500" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Angelos D. Keromytis" writes: > Ambiguous language --- valid Initiators do perform computation before the > Responder, and that was the observation. Just out of curiousity, what benefit is this intended to provide? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Dec 3 11:54:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Js7214427; Mon, 3 Dec 2001 11:54:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22451 Mon, 3 Dec 2001 14:01:32 -0500 (EST) To: "Hallam-Baker, Phillip" Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com Subject: Re: Some comments on JFK References: <2F3EC696EAEED311BB2D009027C3F4F4058698AF@vhqpostal.verisign.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 03 Dec 2001 11:10:10 -0800 In-Reply-To: "Hallam-Baker, Phillip"'s message of "Mon, 3 Dec 2001 11:03:22 -0800" Message-ID: Lines: 31 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hallam-Baker, Phillip" writes: > [1 ] > > Yes, but purpose of forcing the initiator to spend cycles before the > > responder is for DoS prevention, not rate throttling of legitimate > > initiators, no? > > Carefull, you don't 'force' the initiator to spend cycles before the > responder. What you actually do is to force the initiator to prove that > it can recieve packets sent to the purported initiator address before > the responder spends cycles. > > The initiator can send any old junk to the respinder and the responder > will not know until the cycles are spent. This was exactly my point. The draft says: The Initiator bears the initial computational burden and must establish round-trip communication with the Responder before the latter is required to perform expensive operations. This text suggests that the fact that the initiator performs the DH operation first protects against DoS. As far as I can tell it does not. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Dec 3 11:57:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3JvS214659; Mon, 3 Dec 2001 11:57:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22634 Mon, 3 Dec 2001 14:19:30 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Hallam-Baker, Phillip" Cc: "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Selection Criteria? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Dec 2001 14:29:08 -0500 Message-Id: <20011203192908.5FC3D7B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <2F3EC696EAEED311BB2D009027C3F4F4058698B0@vhqpostal.verisign.com>, " Hallam-Baker, Phillip" writes: > >1. Issue every device an IP identity credential bound to its IP address. > This is the ONLY form of identity that can provably prevent any > additional disclosure of identity in an IP environment since your > IP address is known in any case. > The problem is that many devices have dynamic IP addresses, i.e., dial-up machines, machines owned by hotel guests -- and machines owned by IETF attendees... Who should issue such credentials? Send them along with the DHCP or PPP negotiation? That would stall SoI until the service providers wanted to support it. Worse yet, most hotel access is via NAT boxes, which means that many guests are sharing the same credential. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Mon Dec 3 12:20:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3KKq215390; Mon, 3 Dec 2001 12:20:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22723 Mon, 3 Dec 2001 14:37:45 -0500 (EST) Message-Id: <200112031916.fB3JFmpv031573@coredump.cs.columbia.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: EKR Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Subject: Re: Some comments on JFK In-reply-to: Your message of "03 Dec 2001 11:10:10 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Dec 2001 14:15:48 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Eric Rescorla writes: >The draft says: > > The Initiator bears the initial computational burden > and must establish round-trip communication with the Responder > before the latter is required to perform expensive operations. > >This text suggests that the fact that the initiator performs >the DH operation first protects against DoS. As far as I can >tell it does not. Ambiguous language --- valid Initiators do perform computation before the Responder, and that was the observation. This is not a mechanism for protecting against DoS attacks. The IPsec mailing list seems to be randomly dropping my messages (or delaying them forever ?) -Angelos From owner-ipsec@lists.tislabs.com Mon Dec 3 12:21:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3KLn215424; Mon, 3 Dec 2001 12:21:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22737 Mon, 3 Dec 2001 14:38:45 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE0118847B@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Mon, 3 Dec 2001 19:17:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C2F.2C69C180" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17C2F.2C69C180 Content-Type: text/plain David, I have been trying to convince people that RSA public operation provides no clear scalability adavantage over symmetric key. So let me do a orange to orange comparison again using a full mesh and a hub-spoke case. I am only willing to agree with your saying that RSA is better in scalability if such comparison proves it. Assumption: 1) No CA 2) RSA key pair generated in device. Symmetric key generated in server. 3) Server needs to deliver either public key or symmetric key. case 1: Full mesh: N*(N-1)/2 tunnels RSA PSK 1) total number of keys N key pair N*(N-1)/2 PSK 2) key generation cost high low 3) number of key delivery N*(N-1) N*(N-1) 4) key storage on the box 1 private key N-1 PSK N public key 5) authentication calculation high low cost 6) key on server N public key N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA PSK 1) total number of keys N key pair N-1 PSK 2) key generation cost high low 3) number of key delivery (N-1)*2 (N-1)*2 4) key storage on the box hub N public key N-1 PSK spoke 2 public key 1 PSK 5) authentication calculation high low cost 6) key on server N public key N-1 (usually not stored) So if you are only considering the total number of keys, RSA wins. If you look at overall operation cost, the comparison speaks itself. Unfortunately, there is a lack of scalability adavantage for RSA. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Monday, December 03, 2001 12:49 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cliff, My comment is in blue. In addition, The RSA public/private key is better than symmetric key for the key management and scalability measures with slight advantage of security that the public key can be 'public' as long as the id/public-key binding is intact in apposing to the symmetric key has to defend both. --- David ----- Original Message ----- From: "Wang, Cliff" < CWang@smartpipes.com> To: "'david chen'" < ietf_davidchen@hotmail.com>; "Wang, Cliff" < CWang@smartpipes.com>; "Sandy Harris" < sandy@storm.ca>; "'IPsec WG'" < ipsec@lists.tislabs.com> Sent: Saturday, December 01, 2001 9:33 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > Thanks for the discussion and see my comments in line. > > -----Original Message----- > From: david chen [mailto:ietf_davidchen@hotmail.com] > Sent: Friday, November 30, 2001 11:52 PM > To: Wang, Cliff; Sandy Harris; 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > [david] > Cliff, > Let's agree that the pre-shared symmetric key will only *intended* used by > two devices. Let's look at a 5 devices network and a central keys deposit > server. For key management purpose, both the pre-shared RSA public keys and > the symmetic keys will be in a server. (Don't see any scalable model other > than this) > > For a fully meshed communication model among these 5 devices: > 1) the symmetric keys case: > The server have to store 10 = (5*4)/2 s. keys. and keep track of which link > associate to which key. Before device_1 communicates with device_2, these > transactions have to happen: the sk_12 will be sent from server to device_1 > and device_2 through out-of-band secured channel. (well, this dynamic model > is scalable otherwise if the 10 keys pre-loaed on each of the 5 devices; it > will be difficult when a device join-in...) After the full mesh is reached, > each device will have 4 Skeys. > > 2) the RSA keys case: > The server have to strore 5 public keys and don't care about link info., but > have to associate device to its public key. Before device_1 communicates > with device_2, these transactions have to happen: the pk_1 is sent to > device_2 from server and the pk_2 is sent to device_1 trough out-of-band > secured channel. After the full mesh is reached, each device will have 4 > public keys and its own private keys. > > Observation: > 1. The symmetric key management model shows that for a single skey, there > are 3 parties know it. The 2 devices and the server. Clearly, get the skeys > in the server is most effective to break entire mesh. In contrast to the > symmetric key, get the public-keys in the RA does not break any secure link. > (therefore, you can let 3rd party manage this server "RA", as long as it > guarantees id/public-key bindings) > > [cliff] agree. In this case, a server break-in is a very serious security > breach and it can jeopardize the whole operation. When such an event > happens, even though the attacker can't take advantage of the public key, he > can do enough damage to other things such as billing, device configuration, > etc. > > In contrast with the server break-in case, a device compromise is much more > likely. Let's take a look at this case. In a full mesh setup, PSK or > pre-shared RSA suffers the same degree, say 4 partners are compromised. > However, in a hub-spoke setting where only 4 tunnels exists, if a spoke is > compromised, only the link to the hub is compromised when PSK is used. If > pre-shared RSA is used, then potentially communication to both hub and the > rest 3 spoke can be compromised. So in that case, pre-shared RSA is worse > than a pre-shared key. > In the case of hub-spoke topology (not full-mesh) and pre-shared RSA public key are used, if a spoke is compromised, only the link to the hub is compromised, don't see how the rest of 3 spokes are compromised. Note that, In above example, each device in the hub-spoke only stores its own private key and others' public keys. The server in above exmample is part of "out-of-band" communication model. It is a reasonable way for key management and not part of 'security link' topology (full mesh, start, bus, and any 'secured' comm. topology) in the participated devices. (It is possible that the server is a person :-) > [david] > 2. The number of keys in the server is clearly more for symmetric keys. In > addition, it has to keep track of 'link-id'/key pair which is more difficult > than that of 'device-id' in the case of public keys. > [cliff] Although the public key may be cached in the server, there is no > need to save the PSK for a tunnel at the server, since they have been > delivered to both tunnel ends. If a new PSK is needed, just generate it and > push it out to both ends again. However, the server key storage seems to be > an implementation issue. > > > > --- David > P.S. I agree that when a device been tampered, all the established secured > link to this device are broken for either symmetric or asymmetric keys are > used. > > > > > ----- Original Message ----- > From: "Wang, Cliff" < CWang@smartpipes.com> > To: "'david chen'" < ietf_davidchen@hotmail.com>; "Sandy Harris" > < sandy@storm.ca>; "'IPsec WG'" < ipsec@lists.tislabs.com> > Sent: Friday, November 30, 2001 2:49 PM > Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > > > > This analysis is seriously flawed: > > 1) SPSK or group pre-shared key per box is a bad idea. No security > conscious > > people will adopt this. Because of this serious flaw in assumption, > > all security level comparison are meaningless. > > 2) Once an attacker compromise a box, he has access to either private > > key > or > > the pre-shared key. > > Any communication with the box's partners are compromised, whether > > using > PKI > > or PSK for IKE authentication. Where is the 200% risk come from? > > 3) why each device needs to have 499 public keys? They are contained > > in > each > > box's cert and delivered as part of IKE exchange. > > > > -----Original Message----- > > From: david chen [mailto:ietf_davidchen@hotmail.com] > > Sent: Friday, November 30, 2001 1:15 PM > > To: Sandy Harris; 'IPsec WG' > > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > > > > Here is my observation: > > > > The RSA puliblic/private key (RSA key) is better than symmetric > > pre-shared key (SPSK) in the following way: Suppose both the RSA key > > and SPSK all > using > > centerally managed server in a domain and further assume that the SPSK > > is one for each device (not one for each pair of device). Let's say > > there are 500 devices in this domain: Then there will be 500 keys for > > SPSK so is RSA keys. Each device will either have 499 public keys or > > 499 SPSKs. Given the key management (add/delete/remove) are *almost* > > equal, the SPSK has a not ignorable drawback than RSA Key structure: > > To break RSA key, attacker has > to > > break into the device that hold the private key or break into the > > device that itself is the victim of MIM attack. The device has to > > responsible for its own security. (Given the real world that the > > security of a device are not created equal, this is a reasonable > > requirement) > > > > On the other hand, to break a SPSK, the attacker can choose any of the > > 500 devices to breakin. The risk is much higher for a device due to it > > demand all other participated devices have the same security level. > > > > Sure, the SPSK can increase the number of keys that limited the key to > only > > two parties (and increase the complexicity of the key management) but > still > > it is 200% risk more than RSA key due to it demands the same level of > > security level on peer. > > > > > > --- David > > > > > > > > ----- Original Message ----- > > From: "Sandy Harris" < sandy@storm.ca> > > To: "'IPsec WG'" < ipsec@lists.tislabs.com> > > Sent: Friday, November 30, 2001 10:10 AM > > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > > > > > Alex Alten wrote: > > > > > > > I will re-iterate my position. If a network security system is > > > > properly designed then either Public Key or Symmetric/Private Key > > > > cryptography will work fine in establishing trust. > > > > > > So far, so good. > > > > > > > I furthermore claim that Symmetric/Private Key cryptography will > > > > scale to great numbers of users > > > > > > Sorry, but this is nonsense. The classic problem with symmetric > > > crypto is key management. It neither scales well nor works well > > > across > > administrative > > > boundaries. > > > > > > Consider n sites which all want to communicate. > > > > > > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which > > > is known to exactly two players and none of the others. Moreover, > > > you have to communicate those keys securely to the second player in > > > each case, and then keep it secure on both systems. > > > > > > With public key, you need only n key pairs. There is no need to > > communicate > > > keys securely; the system is designed to work even if the enemy > > > knows the public keys. Nor do you have to manage security for > > > multiple keys, or keep track of who each key is shared with. You > > > just need to keep your private key secure, not shared with anyone. > > > > > > Of course you can build a kerberos-like system using symmetric > > > ciphers that has many of the advantages of public key. Using a > > > central key server reduces the number of keys to n client-to-server > > > keys and may simplify management. However, I doubt such a > > > centralised model is appropriate for Internet infrastructure. > > > > > > > and I use the bank ATM secure network using DES as an excellent > > > > example. ... > > > > > > I think that's an irrelevant example. A tightly controlled single > > > purpose terminal-to-mainframe network under a single administrative > > > authority bears no useful resemblanmce to the Internet. Someone gave > > > a good detailed analysis earlier in the thread. You should re-read > > > it. > > > > > > > As far as I'm concerned this should be the end of the discussion > > > > > > I agree, but for opposite reasons. > > > > > > > about whether or not Symmetric/Private Key cryptography can scale > > > > to large numbers of users in an efficient, easy to use by ordinary > > > > people, inexpensive to implement manner and interoperable between > > > > devices made by different manufacturers and maintained by > > > > different organizations. It has been done for the past 20 years by > what > > is > > > > probably the most successful world-wide commercial networked > > > > security > > system. > > > > > > > > Anyone who still claims that Public Key is superior to > > > > Symmetric/Private > > Key > > > > cryptography, or that it is the only way to scale, is a *damn > > > > fool* and > > should > > > > be treated as such. > > > > > > How about "obviously superior for some purposes, including most key > > > distribution applications" and "almost always the best way to build > > > scalable systems"? > > > > > > Methinks you'll consider me a fool. I heartily return the sentiment. > > > > > > ------_=_NextPart_001_01C17C2F.2C69C180 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message David, I have=20 been trying to convince people that RSA public operation provides no = clear=20 scalability adavantage over symmetric key. So let me do a orange to = orange=20 comparison again using a full mesh and a hub-spoke case. I am only = willing to=20 agree with your saying that RSA is better in scalability if = such=20 comparison proves it. Assumption: 1) No=20 CA 2) RSA=20 key pair generated in device. Symmetric key generated in=20 server. 3)=20 Server needs to deliver either public key or symmetric = key. case=20 1: Full mesh: N*(N-1)/2 = tunnels &nb= sp; =20 = =20 =20 RSA &nb= sp; =20 PSK &nb= sp; =20 1)=20 total number of=20 keys &n= bsp;N=20 key=20 pair &n= bsp; =20 N*(N-1)/2 PSK 2) key=20 generation=20 cost &n= bsp; high =20 = =20 low 3)=20 number of key = delivery =20 N*(N-1) = ; N*(N-1) 4) key=20 storage on the box =20 1 private=20 key = N-1=20 PSK =20 = = = =20 N public key 5)=20 authentication calculation high&= nbsp; &= nbsp; = low cost 6) key=20 on=20 server = =20 N public=20 key &nb= sp;=20 N*(N-1)/2 (usually not stored) case 2=20 : hub-spoke : N-1 tunnels &nb= sp; =20 = =20 =20 RSA &nb= sp; =20 PSK &nb= sp; =20 1)=20 total number of=20 keys &n= bsp; N=20 key=20 pair &n= bsp; N-1 =20 PSK 2) key=20 generation=20 cost &n= bsp; high &nbs= p; =20 low 3)=20 number of key = delivery =20 (N-1)*2 = ; (N-1)*2 4) key=20 storage on the box =20 hub = = = =20 N public = key =20 N-1 PSK =20 spoke &= nbsp; &= nbsp; 2=20 public=20 key &nb= sp; 1=20 PSK 5)=20 authentication calculation high&= nbsp; &= nbsp; = low cost 6) key=20 on=20 server = =20 N public=20 key &nb= sp; N-1=20 (usually not stored) So if=20 you are only considering the total number of keys, RSA wins. If you = look at=20 overall operation cost, the comparison speaks itself. = Unfortunately,=20 there is a lack of scalability adavantage for RSA. >-----Original Message----- >From: = david chen=20 [mailto:ietf_davidchen@hotmail.com] >Sent: Monday, December = 03, 2001=20 12:49 PM >To: Wang, Cliff; Sandy Harris; 'IPsec=20 WG' >Subject: Re: On shared keys (was RE: SOI: identity = protection=20 and DOS) > >Cliff, >My comment is in = blue. > >In addition, >The RSA public/private key is better = than=20 symmetric key for >the key management and scalability = measures with=20 slight >advantage of security that the = public key can be=20 'public' as long >as the id/public-key binding is = intact in=20 apposing to >the symmetric key has to defend=20 both. > >--- David > > >----- Original Message ----- >From: "Wang, Cliff" <<3d.htm>CWang@smartpipes.<3d.htm>com> >To: "'david chen'" <<3d.htm>ietf_davidchen@hotmail.<3d.htm>com>;=20 "Wang, Cliff" <<3d.htm>CWang@smartpipes.<3d.htm>com>;=20 "Sandy Harris" <<3d.htm>sandy@storm.ca>; = "'IPsec WG'"=20 <<3d.htm>ipsec@lists.tislabs.<3d.htm>com> >Sent: Saturday, December 01, 2001 = 9:33=20 PM >Subject: RE: On shared keys (was RE: = SOI:=20 identity protection and DOS) > > > Thanks for the discussion and = see my=20 comments in line. > > > > -----Original Message----- > > = From:=20 david chen [mailto:ietf_davidchen@hotmail.com] > > Sent: Friday, = November=20 30, 2001 11:52 PM > > To: Wang, Cliff; Sandy Harris; 'IPsec = WG' > >=20 Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS) > >=20 > > [david] > > Cliff, > > Let's agree that the = pre-shared=20 symmetric key will only *intended* used by > > two devices. Let's = look at=20 a 5 devices network and a central keys deposit > > server. For = key=20 management purpose, both the pre-shared RSA public keys and > > = the=20 symmetic keys will be in a server. (Don't see any scalable = model=20 other > > than this) > > > > For a fully meshed = communication=20 model among these 5 devices: > > 1) the symmetric keys = case: > > The=20 server have to store 10 =3D (5*4)/2 s. keys. and keep track of which=20 link > > associate to which key. Before device_1 communicates = with=20 device_2, these > > transactions have to happen: the sk_12 = will be=20 sent from server to device_1 > > and device_2 through out-of-band = secured=20 channel. (well, this dynamic model > > is scalable otherwise if = the 10=20 keys pre-loaed on each of the 5 devices; it > > will be difficult = when a=20 device join-in...) After the full mesh is reached, > > each = device will=20 have 4 Skeys. > > > > 2) the RSA keys case: > > The = server have=20 to strore 5 public keys and don't care about link info., but > > = have to=20 associate device to its public key. Before device_1 = communicates > > with=20 device_2, these transactions have to happen: the pk_1 is = sent=20 to > > device_2 from server and the pk_2 is sent to device_1 = trough=20 out-of-band > > secured channel. After the full mesh is reached, = each=20 device will have 4 > > public keys and its own private = keys. > >=20 > > Observation: > > 1. The symmetric key management model = shows that=20 for a single skey, there > > are 3 parties know it. The 2 devices = and the=20 server. Clearly, get the skeys > > in the server is most = effective=20 to break entire mesh. In contrast to the > > symmetric key, get = the=20 public-keys in the RA does not break any secure link. > > = (therefore, you=20 can let 3rd party manage this server "RA", as long as it > > = guarantees=20 id/public-key bindings) > > > > [cliff] agree. In this case, = a server=20 break-in is a very serious security > > breach and it can = jeopardize the=20 whole operation. When such an event > > happens, even though the = attacker=20 can't take advantage of the public key, he > > can do enough = damage to=20 other things such as billing, device configuration, > > = etc. > >=20 > > In contrast with the server break-in case, a device = compromise is=20 much more > > likely. Let's take a look at this case. In a full = mesh=20 setup, PSK or > > pre-shared RSA suffers the same degree, say 4 = partners=20 are compromised. > > However, in a hub-spoke setting where only 4 = tunnels=20 exists, if a spoke is > > compromised, only the link to the hub = is=20 compromised when PSK is used. If > > pre-shared RSA is used, then = potentially communication to both hub and the > > rest 3 spoke = can be=20 compromised. So in that case, pre-shared RSA is worse > > than a=20 pre-shared key. > > >In the case of = hub-spoke=20 topology (not full-mesh) and >pre-shared RSA = public key are=20 used, >if a spoke is = compromised, only the=20 link to the hub is compromised, >don't see how the = rest of 3 spokes=20 are compromised. >Note that, In = above=20 example, >each device in the = hub-spoke only=20 stores its own private key and >others' public=20 keys. The server in above exmample is part of=20 "out-of-band" >communication=20 model. It is a reasonable way for key management=20 and >not part of=20 'security link' topology (full mesh, start, bus, and any = 'secured' comm.=20 topology) >in the = participated=20 devices. >(It is=20 possible that the server is a person :-) =20 > > >=20 [david] > > 2. The number of keys in the server is clearly more = for=20 symmetric keys. In > > addition, it has to keep track of=20 'link-id'/key pair which is more difficult > > than that of = 'device-id' in=20 the case of public keys. > > [cliff] Although the public key may = be cached=20 in the server, there is no > > need to save the PSK for a tunnel = at the=20 server, since they have been > > delivered to both tunnel ends. = If a new=20 PSK is needed, just generate it and > > push it out to both ends = again.=20 However, the server key storage seems to be > > an implementation = issue. > > > > > > > > --- David > > P.S. I = agree that=20 when a device been tampered, all the established secured > > link = to this=20 device are broken for either symmetric or asymmetric keys are > > = used. > > > > > > > > > > ----- Original = Message=20 ----- > > From: "Wang, Cliff" <<3d.htm>CWang@smartpipes.com> > > To:=20 "'david chen'" <<3d.htm>ietf_davidchen@hotmail.com>; "Sandy Harris" > > <<3d.htm>sandy@storm.ca>; = "'IPsec WG'"=20 <<3d.htm>ipsec@lists.tislabs.com> > >=20 Sent: Friday, November 30, 2001 2:49 PM > > Subject: RE: On = shared keys=20 (was RE: SOI: identity protection and DOS) > > > > > > = > This=20 analysis is seriously flawed: > > > 1) SPSK or group = pre-shared key per=20 box is a bad idea. No security > > conscious > > > people = will=20 adopt this. Because of this serious flaw in assumption, > > > = all=20 security level comparison are meaningless. > > > 2) Once an = attacker=20 compromise a box, he has access to either private > > > = key > >=20 or > > > the pre-shared key. > > > Any communication = with the=20 box's partners are compromised, whether > > > using > > = PKI > >=20 > or PSK for IKE authentication. Where is the 200% risk come = from? > >=20 > 3) why each device needs to have 499 public keys? They are=20 contained > > > in > > each > > > box's cert and = delivered=20 as part of IKE exchange. > > > > > > -----Original=20 Message----- > > > From: david chen=20 [mailto:ietf_davidchen@hotmail.com] > > > Sent: Friday, = November 30,=20 2001 1:15 PM > > > To: Sandy Harris; 'IPsec WG' > > > = Subject:=20 Re: On shared keys (was RE: SOI: identity protection and DOS) > > = > > > > > > > Here is my observation: > > = > > >=20 > The RSA puliblic/private key (RSA key) is better than = symmetric > >=20 > pre-shared key (SPSK) in the following way: Suppose both the RSA = key > > > and SPSK all > > using > > > centerally = managed=20 server in a domain and further assume that the SPSK > > > is = one for=20 each device (not one for each pair of device). Let's say > > > = there=20 are 500 devices in this domain: Then there will be 500 keys = for > > >=20 SPSK so is RSA keys. Each device will either have 499 public keys = or > >=20 > 499 SPSKs. Given the key management (add/delete/remove) are=20 *almost* > > > equal, the SPSK has a not ignorable drawback = than RSA=20 Key structure: > > > To break RSA key, attacker has > > = to > >=20 > break into the device that hold the private key or break into = the > >=20 > device that itself is the victim of MIM attack. The device has = to > >=20 > responsible for its own security. (Given the real world that = the > >=20 > security of a device are not created equal, this is a = reasonable > >=20 > requirement) > > > > > > On the other hand, to = break a=20 SPSK, the attacker can choose any of the > > > 500 devices to = breakin.=20 The risk is much higher for a device due to it > > > demand = all other=20 participated devices have the same security level. > > = > > > >=20 Sure, the SPSK can increase the number of keys that limited the key = to > >=20 only > > > two parties (and increase the complexicity of the = key=20 management) but > > still > > > it is 200% risk more than = RSA key=20 due to it demands the same level of > > > security level on=20 peer. > > > > > > > > > --- David > > = > > >=20 > > > > > > > ----- Original Message ----- > > = > From:=20 "Sandy Harris" <<3d.htm>sandy@storm.ca> > > > To:=20 "'IPsec WG'" <<3d.htm>ipsec@lists.tislabs.com> > > > Sent: Friday, November 30, 2001 10:10 = AM > > >=20 Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS) > >=20 > > > > > > > > Alex Alten wrote: > > >=20 > > > > > > I will re-iterate my position. If a = network=20 security system is > > > > > properly designed then = either Public=20 Key or Symmetric/Private Key > > > > > cryptography will = work=20 fine in establishing trust. > > > > > > > > So = far, so=20 good. > > > > > > > > > I furthermore claim = that=20 Symmetric/Private Key cryptography will > > > > > scale = to great=20 numbers of users > > > > > > > > Sorry, but this = is=20 nonsense. The classic problem with symmetric > > > > crypto = is key=20 management. It neither scales well nor works well > > > >=20 across > > > administrative > > > > = boundaries. > > >=20 > > > > > Consider n sites which all want to communicate.= > >=20 > > > > > > For symmetric ciphers, you need n*(n-1)/2 = unique=20 keys, each of which > > > > is known to exactly two players = and none=20 of the others. Moreover, > > > > you have to communicate = those keys=20 securely to the second player in > > > > each case, and = then keep it=20 secure on both systems. > > > > > > > > With = public key,=20 you need only n key pairs. There is no need to > > >=20 communicate > > > > keys securely; the system is designed = to work=20 even if the enemy > > > > knows the public keys. Nor do you = have to=20 manage security for > > > > multiple keys, or keep track of = who each=20 key is shared with. You > > > > just need to keep your = private key=20 secure, not shared with anyone. > > > > > > > > = Of course=20 you can build a kerberos-like system using symmetric > > > = > ciphers=20 that has many of the advantages of public key. Using a > > > = >=20 central key server reduces the number of keys to n = client-to-server > >=20 > > keys and may simplify management. However, I doubt such = a > >=20 > > centralised model is appropriate for Internet=20 infrastructure. > > > > > > > > > and I use = the bank=20 ATM secure network using DES as an excellent > > > > > = example.=20 ... > > > > > > > > I think that's an irrelevant = example.=20 A tightly controlled single > > > > purpose = terminal-to-mainframe=20 network under a single administrative > > > > authority = bears no=20 useful resemblanmce to the Internet. Someone gave > > > > a = good=20 detailed analysis earlier in the thread. You should re-read > > = > >=20 it. > > > > > > > > > As far as I'm concerned = this=20 should be the end of the discussion > > > > > > > = > I=20 agree, but for opposite reasons. > > > > > > > > = >=20 about whether or not Symmetric/Private Key cryptography can = scale > > >=20 > > to large numbers of users in an efficient, easy to use by=20 ordinary > > > > > people, inexpensive to implement = manner and=20 interoperable between > > > > > devices made by = different=20 manufacturers and maintained by > > > > > different=20 organizations. It has been done for the past 20 years = by > >=20 what > > > is > > > > > probably the most = successful=20 world-wide commercial networked > > > > > = security > > >=20 system. > > > > > > > > > > Anyone who = still claims=20 that Public Key is superior to > > > > >=20 Symmetric/Private > > > Key > > > > > = cryptography, or=20 that it is the only way to scale, is a *damn > > > > > = fool*=20 and > > > should > > > > > be treated as = such. > >=20 > > > > > > How about "obviously superior for some = purposes,=20 including most key > > > > distribution applications" and = "almost=20 always the best way to build > > > > scalable = systems"? > > >=20 > > > > > Methinks you'll consider me a fool. I heartily = return=20 the sentiment. > > > > > > > > >=20 > > > ------_=_NextPart_001_01C17C2F.2C69C180-- From owner-ipsec@lists.tislabs.com Mon Dec 3 12:21:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3KLw215441; Mon, 3 Dec 2001 12:21:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22750 Mon, 3 Dec 2001 14:39:48 -0500 (EST) Message-Id: <200112031922.fB3JMJpv001495@coredump.cs.columbia.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: EKR Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Subject: Re: Some comments on JFK In-reply-to: Your message of "03 Dec 2001 11:20:46 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Dec 2001 14:22:19 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Eric Rescorla writes: >"Angelos D. Keromytis" writes: >> Ambiguous language --- valid Initiators do perform computation before the >> Responder, and that was the observation. >Just out of curiousity, what benefit is this intended to provide? None, it's just a side effect of the protocol. There is no cryptographic significance in this, and the fact that the text said so at that particular place was a mistake. -Angelos From owner-ipsec@lists.tislabs.com Mon Dec 3 13:26:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3LQ6217433; Mon, 3 Dec 2001 13:26:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23145 Mon, 3 Dec 2001 15:29:48 -0500 (EST) Message-Id: <200112032039.PAA22522@bcn.East.Sun.COM> Date: Mon, 3 Dec 2001 15:39:21 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Stephane's Comments on IKEv2 To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BCPrnH+QY4Ws3cUUtCENXQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane, thanks for you comments. Here are some answers to some of your questions. questions 4 and 5: Clarification of sequence numbers: If a sequence number is "out of whack", drop the message. Out of whack: Suppose the receiver Bob's window is n, and the largest sequence number of a valid message Bob has seen is k and the most recent "hole", i.e., sequence number he has NOT yet seen, is j. j is guaranteed to be less than k, and in fact less than k+n+1, if Alice is following the rules. Bob must reject anything greater than j+n (Alice shouldn't be sending anything greater than j+n if Bob has not ack'd j) or less than k-n. For something between k-n and j+n, Bob will respond. He is committed to keeping track of n messages if the msg isn't idempotent, so if it's within the window if Bob has seen it before he is guaranteed to send back the same response as he did before. That's why we don't want him to simply drop messages if his receive window is, say, n, and Alice sends n+5 messages at once. He might respond to something, and then get a retransmission, and perhaps he'd respond something different the second time. And his first response might actually reach Alice (she'd prematurely given up on it) and perhaps things would get confused. Seemed simpler to just have Alice NOT send more than Bob is willing to remember. As for reaching sequence number 2^32 on the IKE-SA...Funny thing about that... Charlie asked me that and I said, "Come on! There's no way you could ever send that many IKE messages", so he agreed not to say anything in the spec about it. But it would be easy to add that if you run out of sequence numbers you rekey. And then I'd have to admit to Charlie that he was right and we should have said something about that in the spec. :-) 8-9: missing AUTH payload: We don't use an auth payload to protect the contents of any IKE messages beyond 1 and 2. The AUTH payload protects messages 1 and 2 and proves identity. All IKEv2 messages after the first 2 in the initial IKE-SA creation are fully encrypted and integrity protected using a key which is a function, among other things, of the Diffie-Hellman key established in messages 1 and 2, so if the other side knows the integrity check key they must be the entity that proved their identity in the AUTH payload. Instead of doing integrity protection for messages 3 and later with an AUTH payload, which was kind of painful to specify because it involves discussing how to integrity protect something that includes the integrity protection bytes, the integrity field is at the end of the packet. To save words in the spec, we said "use the same format as ESP", i.e., IV | encrypted data | encrypted padding | enc. pad. length | wasted byte (where ESP has "next header") | integrity check So this is equivalent to having an AUTH payload...it's just that the integrity check follows the encrypted data rather than being in the middle of it. And the integrity check protects everything, including the IKE header, so we don't have to think about what fields should go into an integrity check payload. Some people objected to, and some people were confused by, our pointing to the ESP spec. We certainly could explicitly lay out the packet format inside IKEv2 rather than pointing to the ESP spec, and then we could get rid of the funny reserved byte after the encrypted padding length field. 6) reactions to unprotected messages like ICMP "destination unreachable" or unprotected "unknown SPI" IKE messages: If you rely on periodic IKE pings to detect the dead peer, it might be a long time that you'd be sending into a black hole. If the routing infrastructure says the destination is unreachable, you can use that to be suspicious and check for aliveness in order to speed things up, but it has to be rate limited so someone can't send you a zillion ICMP messages. 7) being more specific about waiting for known aliveness of new SA before deleting the old one. Seems like a good idea. I'd be glad to read Tim Jenkin's draft except you said it was expired. Pet peeve: you pointed me at an expired internet draft, which means it's hard to get. It would be nice if the IETF page had a link to all drafts ever made. At any rate, could you send me a copy of Tim's draft? (don't CC the list when you do of course) 10: INITIAL-CONTACT: I'm not a fan of it at all, but I understand other people like it. It makes me nervous because although the spec says "don't do that" it's possible someone will replicate a service and then you could have multiple things with the same ID and nullifying each other's connections. Bill Sommerfeld got me to like the INITIAL-CONTACT thing better if we add "and the same IP address" after the phrase "to the same authenticated identity". An alternative is Bill Sommerfeld's birth certificate proposal, which is a "to be written" internet draft rather than an "expired draft" which makes it just as hard to find. :-) I'm slightly nervous about that as well, in the unlikely event that someone's monotonically increasing counter actually goes backwards, without being aware of it. And I'm not convinced things wouldn't work without either mechanism. I don't have strong feelings either way though. As for your question about where INITIAL-CONTACT would appear: It would be in message 3 or 4, and it would be covered by the integrity check as would everything else inside messages 3 and 4. 11: deletes for IKE SAs: I don't understand what you were asking. 13: Nat traversal: we'll have to think about this. As well as perhaps going through an anonymizer, which I'd think would be similar. Wanna help? :-) Radia From owner-ipsec@lists.tislabs.com Mon Dec 3 13:28:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3LSk217538; Mon, 3 Dec 2001 13:28:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23181 Mon, 3 Dec 2001 15:35:52 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Wang, Cliff" , "Sandy Harris" , "'IPsec WG'" References: <4652644B98DFF34696801F8F3070D3FE0118847B@D2CSPEXM001.smartpipes.com> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Mon, 3 Dec 2001 15:45:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01C17C11.8AEF2060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 03 Dec 2001 20:44:59.0222 (UTC) FILETIME=[5F9E7760:01C17C3B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0160_01C17C11.8AEF2060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageCliff, Let's look at this example with some further definition to show why the = RSA is more scalable than the symmetric keys. 1) first let's compare that if all keys stored in server: a) full-meshed topology: It's celar that the RSA public keys is much less than the symmetric keys = in terms of number and the device/public-key association vs. = link/public-key association. In addition, for RSA public key model,=20 the server in each realm can exchange the stored id/public-key info. = without compromise any privacy of involed devices. It is scalable that it can incorporate = as many as servers of realms in the internet.=20 b) star topology: Appx. same number of keys stored for both method. However, the star topooloy Is not scable as the full-meshed topology: Hub-spoke topology limits the spoke have only 1 secure link. It is difficult for a device to join across two different spoke-hub. Hence, it is only good for a small realm and is not as scable as a = meshed model. The Hub-spoke is not what internet's (IP) farvorite topology and don't = mention about secured internet.=20 =20 2) what if no server is used. (this means no 3rd-party's help and no out-of-band secure channel) For both the pre-share RSA and symmetric key have same issue of=20 mutual authentication at beginning... Operational cost is a factor of mathematical effeciency, there are lots = of algorithms/variations for symmetric and asymmetric keys. =20 Let's deal with topology first. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 2:17 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) David, I have been trying to convince people that RSA public operation = provides no clear scalability adavantage over symmetric key. So let me = do a orange to orange comparison again using a full mesh and a hub-spoke = case. I am only willing to agree with your saying that RSA is better in = scalability if such comparison proves it. Assumption:=20 1) No CA 2) RSA key pair generated in device. Symmetric key generated in = server. 3) Server needs to deliver either public key or symmetric key. case 1: Full mesh: N*(N-1)/2 tunnels=20 RSA = PSK =20 1) total number of keys N key pair N*(N-1)/2 = PSK 2) key generation cost high low 3) number of key delivery N*(N-1) N*(N-1) 4) key storage on the box 1 private key N-1 PSK N public key =20 5) authentication calculation high low cost 6) key on server N public key = N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA = PSK =20 1) total number of keys N key pair N-1 PSK 2) key generation cost high low 3) number of key delivery (N-1)*2 (N-1)*2 4) key storage on the box =20 hub N public key = N-1 PSK spoke 2 public key 1 = PSK 5) authentication calculation high low cost 6) key on server N public key N-1 = (usually not stored) So if you are only considering the total number of keys, RSA wins. If = you look at overall operation cost, the comparison speaks itself. = Unfortunately, there is a lack of scalability adavantage for RSA. >=20 ------=_NextPart_000_0160_01C17C11.8AEF2060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Cliff,
Let's look at this example with some = further=20 definition to show why the RSA is more
scalable than the symmetric = keys.
 
1) first let's compare that if all keys = stored=20 in  server:
a) full-meshed topology:
It's celar that the RSA public keys is much less than the symmetric = keys 
in terms of number and the device/public-key association vs.=20 link/public-key association.
In addition, for RSA public key model,
the server in each realm can exchange the stored id/public-key = info.=20 without compromise
any privacy of involed devices.  It is scalable = that it can incorporate as many as
servers of realms in the internet. 
 
b) star topology:
Appx. same number of keys stored for both method.
However, the star topooloy Is not scable as the=20 full-meshed topology:
Hub-spoke topology limits the spoke have only 1 secure = link.
It is=20 difficult for a device to join across two different spoke-hub.
Hence, it is only good for a small realm and is not as scable = as=20 a meshed model.
The Hub-spoke is not what internet's (IP) farvorite = topology=20 and don't mention about
secured internet. 
 
2) what if no server is used. (this = means no=20 3rd-party's help and
    no out-of-band = secure=20 channel)
For both the pre-share RSA and symmetric key have same issue of =
mutual authentication at beginning...
 
 
Operational cost is a factor of mathematical effeciency, there are = lots of=20 algorithms/variations
 for symmetric and asymmetric keys.  
 
Let's deal with topology first.
 
--- David
 
 
 
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; Sandy Harris = ; 'IPsec=20 WG'
Sent: Monday, December 03, 2001 = 2:17=20 PM
Subject: RE: On shared keys = (was RE: SOI:=20 identity protection and DOS)

David,
 
I=20 have been trying to convince people that RSA public operation provides = no=20 clear scalability adavantage over symmetric key. So let me do a orange = to=20 orange comparison again using a full mesh and a hub-spoke case. I am = only=20 willing to agree with your saying that RSA is better in = scalability=20 if such comparison proves it.
 
Assumption:
1)=20 No CA
2)=20 RSA key pair generated in device. Symmetric key generated in=20 server.
3)=20 Server needs to deliver either public key or symmetric=20 key.
 
case=20 1:  Full mesh:  N*(N-1)/2 =20 tunnels 
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1)=20 total number of=20 = keys           &nb= sp;N=20 key=20 = pair           &nb= sp;   =20 N*(N-1)/2 PSK
2)=20 key generation=20 = cost           &nb= sp; high         =20 =             &= nbsp; =20 low
3)=20 number of key = delivery         =20 = N*(N-1)           =          N*(N-1)
4)=20 key storage on the box         = 1 private=20 key            = N-1=20 PSK
      =20 =             &= nbsp;           &n= bsp;           &nb= sp; =20 N public key   
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
    cost
6)=20 key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N*(N-1)/2  (usually not stored)
 
 
case=20 2 : hub-spoke :  N-1 tunnels
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1)=20 total number of=20 = keys           &nb= sp; N=20 key=20 = pair           &nb= sp;   N-1 =20 PSK
2)=20 key generation=20 = cost           &nb= sp;  high         =    =20 =            low
3)=20 number of key = delivery         =20 = (N-1)*2           =          (N-1)*2
4)=20 key storage on the box         =
    hub   &= nbsp;           &n= bsp;           &nb= sp;        =20 N public = key          =20  N-1  PSK
   =20 = spoke           &n= bsp;           &nb= sp;         2=20 public=20 = key           &nbs= p;  1=20 PSK
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
    cost
6)=20 key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N-1 (usually not stored)
 
=
So=20 if you are only considering the total number of keys, RSA wins. If you = look at=20 overall operation cost, the comparison speaks itself. = Unfortunately,=20 there is a lack of scalability adavantage for RSA.
 
 
 
> =
------=_NextPart_000_0160_01C17C11.8AEF2060-- From owner-ipsec@lists.tislabs.com Mon Dec 3 13:56:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Luw220021; Mon, 3 Dec 2001 13:56:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23267 Mon, 3 Dec 2001 16:07:23 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE0118847E@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Mon, 3 Dec 2001 21:15:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C3F.92759D90" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17C3F.92759D90 Content-Type: text/plain See my comments inline. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Monday, December 03, 2001 3:46 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cliff, Let's look at this example with some further definition to show why the RSA is more scalable than the symmetric keys. 1) first let's compare that if all keys stored in server: a) full-meshed topology: It's celar that the RSA public keys is much less than the symmetric keys in terms of number and the device/public-key association vs. link/public-key association. In addition, for RSA public key model, the server in each realm can exchange the stored id/public-key info. without compromise any privacy of involed devices. It is scalable that it can incorporate as many as servers of realms in the internet. [--------cliff-----] I have already said if you just compare the number of keys, RSA wins, in the case of a full mesh. But there are other issues in the comparison, other than just the number of keys needed. Without CA/cert, the public key/ID binding is questionable. Also this binding/security topic is off the scalability issue that my comparison focuses on, within a single realm. If you want to expand the comparion to cross-realm, I can do another number comparison. b) star topology: Appx. same number of keys stored for both method. However, the star topooloy Is not scable as the full-meshed topology: Hub-spoke topology limits the spoke have only 1 secure link. It is difficult for a device to join across two different spoke-hub. Hence, it is only good for a small realm and is not as scable as a meshed model. The Hub-spoke is not what internet's (IP) farvorite topology and don't mention about secured internet. [------cliff------] again, you are off the topic. We are not talking about the topology comparison, full mesh vs hub-spoke. On the contrary to your claim, in our real-world deployment experience, hub-spoke is much more popular. The reason I did both full mesh and hub-spoke is because they represent two ends of spectrum. 2) what if no server is used. (this means no 3rd-party's help and no out-of-band secure channel) For both the pre-share RSA and symmetric key have same issue of mutual authentication at beginning... [--------cliff-----] if you name a key delivery scheme, we can do a number comparison, as I did before. Operational cost is a factor of mathematical effeciency, there are lots of algorithms/variations for symmetric and asymmetric keys. [--------cliff-----] agree. That's why you need to make your assumption first. But key delivery cost is quite independent of mathematics and probably the most demanding job in terms of scalability. Let's deal with topology first. --- David ----- Original Message ----- From: Wang, Cliff To: 'david chen' ; Sandy Harris ; 'IPsec WG' Sent: Monday, December 03, 2001 2:17 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) David, I have been trying to convince people that RSA public operation provides no clear scalability adavantage over symmetric key. So let me do a orange to orange comparison again using a full mesh and a hub-spoke case. I am only willing to agree with your saying that RSA is better in scalability if such comparison proves it. Assumption: 1) No CA 2) RSA key pair generated in device. Symmetric key generated in server. 3) Server needs to deliver either public key or symmetric key. case 1: Full mesh: N*(N-1)/2 tunnels RSA PSK 1) total number of keys N key pair N*(N-1)/2 PSK 2) key generation cost high low 3) number of key delivery N*(N-1) N*(N-1) 4) key storage on the box 1 private key N-1 PSK N public key 5) authentication calculation high low cost 6) key on server N public key N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA PSK 1) total number of keys N key pair N-1 PSK 2) key generation cost high low 3) number of key delivery (N-1)*2 (N-1)*2 4) key storage on the box hub N public key N-1 PSK spoke 2 public key 1 PSK 5) authentication calculation high low cost 6) key on server N public key N-1 (usually not stored) So if you are only considering the total number of keys, RSA wins. If you look at overall operation cost, the comparison speaks itself. Unfortunately, there is a lack of scalability adavantage for RSA. > ------_=_NextPart_001_01C17C3F.92759D90 Content-Type: text/html Message
See my comments inline.
-----Original Message-----
From: david chen [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, December 03, 2001 3:46 PM
To: Wang, Cliff; Sandy Harris; 'IPsec WG'
Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)

Cliff,
Let's look at this example with some further definition to show why the RSA is more
scalable than the symmetric keys.
 
1) first let's compare that if all keys stored in  server:
a) full-meshed topology:
It's celar that the RSA public keys is much less than the symmetric keys 
in terms of number and the device/public-key association vs. link/public-key association.
In addition, for RSA public key model,
the server in each realm can exchange the stored id/public-key info. without compromise
any privacy of involed devices.  It is scalable that it can incorporate as many as
servers of realms in the internet. 
 
[--------cliff-----] I have already said if you just compare the number of keys, RSA wins, in the case of a full mesh. But there are other issues in the comparison, other than just the number of keys needed.
 
Without CA/cert, the public key/ID binding is questionable.  Also this binding/security  topic is off the scalability issue that my comparison focuses on, within a single realm. If you want to expand the comparion to cross-realm, I can do another number comparison.
 
b) star topology:
Appx. same number of keys stored for both method.
However, the star topooloy Is not scable as the full-meshed topology:
Hub-spoke topology limits the spoke have only 1 secure link.
It is difficult for a device to join across two different spoke-hub.
Hence, it is only good for a small realm and is not as scable as a meshed model.
The Hub-spoke is not what internet's (IP) farvorite topology and don't mention about
secured internet. 
 
[------cliff------] again, you are off the topic. We are not talking about the topology comparison, full mesh vs hub-spoke.
On the contrary to your claim, in our real-world deployment experience, hub-spoke is much more popular.
The reason I did both full mesh and hub-spoke is because they represent two ends of spectrum.
 
 
 
2) what if no server is used. (this means no 3rd-party's help and
    no out-of-band secure channel)
For both the pre-share RSA and symmetric key have same issue of
mutual authentication at beginning...
 
[--------cliff-----] if you name a key delivery scheme, we can do a number comparison, as I did before.
 
 
 
Operational cost is a factor of mathematical effeciency, there are lots of algorithms/variations
 for symmetric and asymmetric keys.  
 
[--------cliff-----] agree. That's why you need to make your assumption first. But key delivery cost is quite independent of mathematics and probably the most demanding job in terms of scalability.
 
 
 
Let's deal with topology first.
 
--- David
 
 
 
 
----- Original Message -----
Sent: Monday, December 03, 2001 2:17 PM
Subject: RE: On shared keys (was RE: SOI: identity protection and DOS)

David,
 
I have been trying to convince people that RSA public operation provides no clear scalability adavantage over symmetric key. So let me do a orange to orange comparison again using a full mesh and a hub-spoke case. I am only willing to agree with your saying that RSA is better in scalability if such comparison proves it.
 
Assumption:
1) No CA
2) RSA key pair generated in device. Symmetric key generated in server.
3) Server needs to deliver either public key or symmetric key.
 
case 1:  Full mesh:  N*(N-1)/2  tunnels 
 
                                             RSA                        PSK                
1) total number of keys            N key pair                N*(N-1)/2 PSK
2) key generation cost             high                         low
3) number of key delivery          N*(N-1)                    N*(N-1)
4) key storage on the box         1 private key            N-1 PSK
                                              N public key   
5) authentication calculation      high                         low
    cost
6) key on server                      N public key             N*(N-1)/2  (usually not stored)
 
 
case 2 : hub-spoke :  N-1 tunnels
 
                                             RSA                        PSK                
1) total number of keys             N key pair               N-1  PSK
2) key generation cost              high                        low
3) number of key delivery          (N-1)*2                    (N-1)*2
4) key storage on the box        
    hub                                     N public key            N-1  PSK
    spoke                                 2 public key              1 PSK
5) authentication calculation      high                         low
    cost
6) key on server                      N public key             N-1 (usually not stored)
 
So if you are only considering the total number of keys, RSA wins. If you look at overall operation cost, the comparison speaks itself. Unfortunately, there is a lack of scalability adavantage for RSA.
 
 
 
>
------_=_NextPart_001_01C17C3F.92759D90-- From owner-ipsec@lists.tislabs.com Mon Dec 3 14:50:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Mow224619; Mon, 3 Dec 2001 14:50:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23519 Mon, 3 Dec 2001 16:54:59 -0500 (EST) Message-Id: <200112032204.RAA22879@bcn.East.Sun.COM> Date: Mon, 3 Dec 2001 17:04:27 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Some comments on JFK To: ipsec@lists.tislabs.com, ekr@rtfm.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wk0FKsxUQZ0f9laNdWmO6g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk EKR said: >> (1) In message 1 the initiator sends g^i. This is replayed in message >> 3. I see why the initiator needs to tell the responder the group he >> wants to use but why does it need to communicate g^i? If you simply >> want the initiator to commit to g^i, why not use a hash? This would >> save some bandwidth, which is always nice :) If g^i is in message 1 it gives Bob the option of getting going on his Diffie-Hellman calculation if he was willing to not be stateless and computeless. Radia From owner-ipsec@lists.tislabs.com Mon Dec 3 14:50:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Mox224621; Mon, 3 Dec 2001 14:50:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23568 Mon, 3 Dec 2001 17:04:50 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Wang, Cliff" , "Sandy Harris" , "'IPsec WG'" References: <4652644B98DFF34696801F8F3070D3FE0118847E@D2CSPEXM001.smartpipes.com> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Mon, 3 Dec 2001 17:14:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B2_01C17C1D.F6669BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 03 Dec 2001 22:13:53.0546 (UTC) FILETIME=[CB1FB6A0:01C17C47] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01B2_01C17C1D.F6669BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageCliff, As in communication, topology first. It was you to bring up hub-sopke against mesh. 1) Don't find anyone claim don't want to have more than one secure = link. =20 Since RSA is the same (as symmetric) in hub-sopke and=20 better in mesh, it is clear to me RSA is better. 2) For pre-shared RSA key and pre-shared symmetric key, The delivery method are through the same "out-of-band" secured = channel. This was the assumption.=20 It assumed no CA and don't need it. 3) The operation cost has different meaning for different profession. Let's defined it as the computional cost; and that is *ultimately* = mathematical bond. (since, it is 'computatoin'. :-) The crypto-algorithm, number of transcations, protocol used,.. (and = others) are all factors of the computational cost.=20 Can't be done this way (in e-mail) unless you have paper/URL pointer = in mind. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 4:15 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) See my comments inline. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com]=20 Sent: Monday, December 03, 2001 3:46 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS) Cliff, Let's look at this example with some further definition to show why = the RSA is more scalable than the symmetric keys. 1) first let's compare that if all keys stored in server: a) full-meshed topology: It's celar that the RSA public keys is much less than the symmetric = keys=20 in terms of number and the device/public-key association vs. = link/public-key association. In addition, for RSA public key model,=20 the server in each realm can exchange the stored id/public-key info. = without compromise any privacy of involed devices. It is scalable that it can = incorporate as many as servers of realms in the internet.=20 [--------cliff-----] I have already said if you just compare the = number of keys, RSA wins, in the case of a full mesh. But there are = other issues in the comparison, other than just the number of keys = needed. Without CA/cert, the public key/ID binding is questionable. Also = this binding/security topic is off the scalability issue that my = comparison focuses on, within a single realm. If you want to expand the = comparion to cross-realm, I can do another number comparison. b) star topology: Appx. same number of keys stored for both method. However, the star topooloy Is not scable as the full-meshed = topology: Hub-spoke topology limits the spoke have only 1 secure link. It is difficult for a device to join across two different spoke-hub. Hence, it is only good for a small realm and is not as scable as a = meshed model. The Hub-spoke is not what internet's (IP) farvorite topology and = don't mention about secured internet.=20 [------cliff------] again, you are off the topic. We are not talking = about the topology comparison, full mesh vs hub-spoke. On the contrary to your claim, in our real-world deployment = experience, hub-spoke is much more popular. The reason I did both full mesh and hub-spoke is because they = represent two ends of spectrum. 2) what if no server is used. (this means no 3rd-party's help and no out-of-band secure channel) For both the pre-share RSA and symmetric key have same issue of=20 mutual authentication at beginning... [--------cliff-----] if you name a key delivery scheme, we can do a = number comparison, as I did before. Operational cost is a factor of mathematical effeciency, there are = lots of algorithms/variations for symmetric and asymmetric keys. =20 [--------cliff-----] agree. That's why you need to make your = assumption first. But key delivery cost is quite independent of = mathematics and probably the most demanding job in terms of scalability. Let's deal with topology first. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 2:17 PM Subject: RE: On shared keys (was RE: SOI: identity protection and = DOS) David, I have been trying to convince people that RSA public operation = provides no clear scalability adavantage over symmetric key. So let me = do a orange to orange comparison again using a full mesh and a hub-spoke = case. I am only willing to agree with your saying that RSA is better in = scalability if such comparison proves it. Assumption:=20 1) No CA 2) RSA key pair generated in device. Symmetric key generated in = server. 3) Server needs to deliver either public key or symmetric key. case 1: Full mesh: N*(N-1)/2 tunnels=20 RSA = PSK =20 1) total number of keys N key pair = N*(N-1)/2 PSK 2) key generation cost high = low 3) number of key delivery N*(N-1) = N*(N-1) 4) key storage on the box 1 private key N-1 PSK N public key =20 5) authentication calculation high = low cost 6) key on server N public key = N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA = PSK =20 1) total number of keys N key pair N-1 = PSK 2) key generation cost high = low 3) number of key delivery (N-1)*2 = (N-1)*2 4) key storage on the box =20 hub N public key = N-1 PSK spoke 2 public key = 1 PSK 5) authentication calculation high = low cost 6) key on server N public key N-1 = (usually not stored) So if you are only considering the total number of keys, RSA wins. = If you look at overall operation cost, the comparison speaks itself. = Unfortunately, there is a lack of scalability adavantage for RSA. >=20 ------=_NextPart_000_01B2_01C17C1D.F6669BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Cliff,
As in communication, topology=20 first.
It was you to bring up hub-sopke = against=20 mesh.
 
1) Don't find anyone claim=20 don't  want to have more than one secure = link.
   
    Since RSA is the = same (as=20 symmetric) in hub-sopke and
    better in mesh, it = is clear to=20 me RSA is better.
 
2) For pre-shared RSA key and = pre-shared symmetric=20 key,
   The delivery method are = through the=20 same "out-of-band" secured channel.
   This was the=20 assumption. 
    It assumed no CA and = don't need=20 it.
 
3)  The=20 operation cost has different meaning for different = profession.
     Let's defined = it as the=20 computional cost; and that is *ultimately* mathematical = bond.
     (since, it is=20 'computatoin'. :-)
    The = crypto-algorithm, number=20 of transcations, protocol used,.. (and others) are all=20 factors of
    the computational = cost.=20
    Can't be done = this way (in=20 e-mail) unless you have paper/URL pointer in mind.
 
--- David
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; Sandy Harris = ; 'IPsec=20 WG'
Sent: Monday, December 03, 2001 = 4:15=20 PM
Subject: RE: On shared keys = (was RE: SOI:=20 identity protection and DOS)

See=20 my comments inline.
-----Original Message-----
From: = david chen=20 [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, = December 03,=20 2001 3:46 PM
To: Wang, Cliff; Sandy Harris; 'IPsec=20 WG'
Subject: Re: On shared keys (was RE: SOI: identity = protection=20 and DOS)

Cliff,
Let's look at this example with = some further=20 definition to show why the RSA is more
scalable than the symmetric = keys.
 
1) first let's compare that if all = keys stored=20 in  server:
a) full-meshed = topology:
It's celar that the RSA public keys = is much=20 less than the symmetric keys 
in terms of number and the = device/public-key=20 association vs. link/public-key association.
In addition, for RSA public key = model,=20
the server in each realm can = exchange the=20 stored id/public-key info. without compromise
any privacy=20 of involed devices.  It is scalable that it can=20 incorporate as many as
servers of realms in the=20 internet. 
 
[--------cliff-----] I have already said = if you=20 just compare the number of keys, RSA wins, in the case of a full = mesh. But=20 there are other issues in the comparison, other than just the number = of keys=20 needed.
 
Without CA/cert, the public key/ID = binding is=20 questionable.  Also this binding/security  topic=20 is off the scalability issue that my comparison = focuses on,=20 within a single realm. If you want to expand the comparion to = cross-realm, I=20 can do another number comparison.
 
b) star topology:
Appx. same number of keys stored = for both=20 method.
However, the star topooloy = Is not scable=20 as the full-meshed topology:
Hub-spoke topology limits the spoke = have only 1=20 secure link.
It is difficult = for a=20 device to join across two different spoke-hub.
Hence, it is only good for a = small realm=20 and is not as scable as a meshed model.
The Hub-spoke is not = what internet's=20 (IP) farvorite topology and don't mention about
secured = internet. 
 
[------cliff------] again, you are off = the topic.=20 We are not talking about the topology comparison, full mesh vs=20 hub-spoke.
On = the contrary=20 to your claim, in our real-world deployment experience, hub-spoke is = much=20 more popular.
The reason I did=20 both full mesh and hub-spoke is because they represent two ends of=20 spectrum.
 
 
 
2) what if no server is used. (this = means no=20 3rd-party's help and
    no out-of-band = secure=20 channel)
For both the pre-share RSA and = symmetric key=20 have same issue of
mutual authentication at=20 beginning...
 
[--------cliff-----] if you name a key = delivery=20 scheme, we can do a number comparison, as I did = before.
 
 
 
Operational cost is a factor of = mathematical=20 effeciency, there are lots of algorithms/variations
 for symmetric and asymmetric=20 keys.  
 
[--------cliff-----] agree. That's why you need to make = your=20 assumption first. But key delivery cost is quite independent of = mathematics=20 and probably the most demanding job in terms of=20 scalability.
 
 
 
Let's deal with topology = first.
 
--- David
 
 
 
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; Sandy = Harris ; 'IPsec=20 WG'
Sent: Monday, December 03, = 2001 2:17=20 PM
Subject: RE: On shared keys = (was RE:=20 SOI: identity protection and DOS)

David,
 
I have been trying to convince people = that RSA=20 public operation provides no clear scalability adavantage over = symmetric=20 key. So let me do a orange to orange comparison again using a full = mesh=20 and a hub-spoke case. I am only willing to agree with your=20 saying that RSA is better in scalability if such = comparison=20 proves it.
 
Assumption:
1) No CA
2) RSA key pair generated in device. = Symmetric=20 key generated in server.
3) Server needs to deliver either = public key or=20 symmetric key.
 
case 1:  Full=20 mesh:  N*(N-1)/2  tunnels 
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1) total number of=20 = keys           &nb= sp;N=20 key=20 = pair           &nb= sp;   =20 N*(N-1)/2 PSK
2) key generation=20 = cost           &nb= sp; high         =20 =             &= nbsp; =20 low
3) number of key=20 delivery         =20 = N*(N-1)           =          N*(N-1)
4) key storage on the=20 box         1 private = = key            = N-1=20 PSK
      =20 =             &= nbsp;           &n= bsp;           &nb= sp; =20 N public key   
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
    = cost
6) key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N*(N-1)/2  (usually not stored)
 
 
case 2 : hub-spoke :  N-1=20 tunnels
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1) total number of=20 = keys           &nb= sp; N=20 key=20 = pair           &nb= sp;   N-1 =20 PSK
2) key generation=20 = cost           &nb= sp;  high         =    =20 =            low
3) number of key=20 delivery         =20 = (N-1)*2           =          (N-1)*2
4) key storage on the=20 box         =
    hub   &= nbsp;           &n= bsp;           &nb= sp;        =20 N public = key          =20  N-1  PSK
   =20 = spoke           &n= bsp;           &nb= sp;         2=20 public=20 = key           &nbs= p;  1=20 PSK
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
    = cost
6) key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N-1 (usually not stored)
 
=
So if you are only considering the = total number=20 of keys, RSA wins. If you look at overall operation cost, the = comparison=20 speaks itself. Unfortunately, there is a lack of = scalability=20 adavantage for RSA.
 
 
 
>=20
------=_NextPart_000_01B2_01C17C1D.F6669BA0-- From owner-ipsec@lists.tislabs.com Mon Dec 3 15:15:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3NFk225735; Mon, 3 Dec 2001 15:15:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23629 Mon, 3 Dec 2001 17:32:48 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188485@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Mon, 3 Dec 2001 22:41:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C4B.B5DDD4D0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17C4B.B5DDD4D0 Content-Type: text/plain David, 1) my analysis is on scalability, using hub-spoke and full mesh as two cases, since they represent two ends of the spectrum. It is NOT my intention to compare the topology themselves. 2) Key distribution is the most demanding and critical job. Without PKI, there is no clear scalability advantage of using public key. That's why PKI is introduced. 3) Let's stop the thread here since enough fact and analysis has been presented. People on the list are able to draw their own conclusion based on the analysis. It is much less important for us to agree with each other. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Monday, December 03, 2001 5:14 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cliff, As in communication, topology first. It was you to bring up hub-sopke against mesh. 1) Don't find anyone claim don't want to have more than one secure link. Since RSA is the same (as symmetric) in hub-sopke and better in mesh, it is clear to me RSA is better. 2) For pre-shared RSA key and pre-shared symmetric key, The delivery method are through the same "out-of-band" secured channel. This was the assumption. It assumed no CA and don't need it. 3) The operation cost has different meaning for different profession. Let's defined it as the computional cost; and that is *ultimately* mathematical bond. (since, it is 'computatoin'. :-) The crypto-algorithm, number of transcations, protocol used,.. (and others) are all factors of the computational cost. Can't be done this way (in e-mail) unless you have paper/URL pointer in mind. --- David ----- Original Message ----- From: Wang, Cliff To: 'david chen' ; Sandy Harris ; 'IPsec WG' Sent: Monday, December 03, 2001 4:15 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) See my comments inline. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Monday, December 03, 2001 3:46 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cliff, Let's look at this example with some further definition to show why the RSA is more scalable than the symmetric keys. 1) first let's compare that if all keys stored in server: a) full-meshed topology: It's celar that the RSA public keys is much less than the symmetric keys in terms of number and the device/public-key association vs. link/public-key association. In addition, for RSA public key model, the server in each realm can exchange the stored id/public-key info. without compromise any privacy of involed devices. It is scalable that it can incorporate as many as servers of realms in the internet. [--------cliff-----] I have already said if you just compare the number of keys, RSA wins, in the case of a full mesh. But there are other issues in the comparison, other than just the number of keys needed. Without CA/cert, the public key/ID binding is questionable. Also this binding/security topic is off the scalability issue that my comparison focuses on, within a single realm. If you want to expand the comparion to cross-realm, I can do another number comparison. b) star topology: Appx. same number of keys stored for both method. However, the star topooloy Is not scable as the full-meshed topology: Hub-spoke topology limits the spoke have only 1 secure link. It is difficult for a device to join across two different spoke-hub. Hence, it is only good for a small realm and is not as scable as a meshed model. The Hub-spoke is not what internet's (IP) farvorite topology and don't mention about secured internet. [------cliff------] again, you are off the topic. We are not talking about the topology comparison, full mesh vs hub-spoke. On the contrary to your claim, in our real-world deployment experience, hub-spoke is much more popular. The reason I did both full mesh and hub-spoke is because they represent two ends of spectrum. 2) what if no server is used. (this means no 3rd-party's help and no out-of-band secure channel) For both the pre-share RSA and symmetric key have same issue of mutual authentication at beginning... [--------cliff-----] if you name a key delivery scheme, we can do a number comparison, as I did before. Operational cost is a factor of mathematical effeciency, there are lots of algorithms/variations for symmetric and asymmetric keys. [--------cliff-----] agree. That's why you need to make your assumption first. But key delivery cost is quite independent of mathematics and probably the most demanding job in terms of scalability. Let's deal with topology first. --- David ----- Original Message ----- From: Wang, Cliff To: 'david chen' ; Sandy Harris ; 'IPsec WG' Sent: Monday, December 03, 2001 2:17 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) David, I have been trying to convince people that RSA public operation provides no clear scalability adavantage over symmetric key. So let me do a orange to orange comparison again using a full mesh and a hub-spoke case. I am only willing to agree with your saying that RSA is better in scalability if such comparison proves it. Assumption: 1) No CA 2) RSA key pair generated in device. Symmetric key generated in server. 3) Server needs to deliver either public key or symmetric key. case 1: Full mesh: N*(N-1)/2 tunnels RSA PSK 1) total number of keys N key pair N*(N-1)/2 PSK 2) key generation cost high low 3) number of key delivery N*(N-1) N*(N-1) 4) key storage on the box 1 private key N-1 PSK N public key 5) authentication calculation high low cost 6) key on server N public key N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA PSK 1) total number of keys N key pair N-1 PSK 2) key generation cost high low 3) number of key delivery (N-1)*2 (N-1)*2 4) key storage on the box hub N public key N-1 PSK spoke 2 public key 1 PSK 5) authentication calculation high low cost 6) key on server N public key N-1 (usually not stored) So if you are only considering the total number of keys, RSA wins. If you look at overall operation cost, the comparison speaks itself. Unfortunately, there is a lack of scalability adavantage for RSA. > ------_=_NextPart_001_01C17C4B.B5DDD4D0 Content-Type: text/html Message
David,
 
1) my analysis is on scalability, using hub-spoke and full mesh as two cases, since they represent two ends of the spectrum. It is NOT my intention to compare the topology themselves.
2) Key distribution is the most demanding and critical job. Without PKI, there is no clear scalability advantage of using public key. That's why PKI is introduced.
3) Let's  stop the thread here since enough fact and analysis has been presented. People on the list are able to draw their own conclusion based on the analysis. It is much less important for us to agree with each other.
 
-----Original Message-----
From: david chen [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, December 03, 2001 5:14 PM
To: Wang, Cliff; Sandy Harris; 'IPsec WG'
Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)

Cliff,
As in communication, topology first.
It was you to bring up hub-sopke against mesh.
 
1) Don't find anyone claim don't  want to have more than one secure link.
   
    Since RSA is the same (as symmetric) in hub-sopke and
    better in mesh, it is clear to me RSA is better.
 
2) For pre-shared RSA key and pre-shared symmetric key,
   The delivery method are through the same "out-of-band" secured channel.
   This was the assumption. 
    It assumed no CA and don't need it.
 
3)  The operation cost has different meaning for different profession.
     Let's defined it as the computional cost; and that is *ultimately* mathematical bond.
     (since, it is 'computatoin'. :-)
    The crypto-algorithm, number of transcations, protocol used,.. (and others) are all factors of
    the computational cost.
    Can't be done this way (in e-mail) unless you have paper/URL pointer in mind.
 
--- David
 
----- Original Message -----
Sent: Monday, December 03, 2001 4:15 PM
Subject: RE: On shared keys (was RE: SOI: identity protection and DOS)

See my comments inline.
-----Original Message-----
From: david chen [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, December 03, 2001 3:46 PM
To: Wang, Cliff; Sandy Harris; 'IPsec WG'
Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)

Cliff,
Let's look at this example with some further definition to show why the RSA is more
scalable than the symmetric keys.
 
1) first let's compare that if all keys stored in  server:
a) full-meshed topology:
It's celar that the RSA public keys is much less than the symmetric keys 
in terms of number and the device/public-key association vs. link/public-key association.
In addition, for RSA public key model,
the server in each realm can exchange the stored id/public-key info. without compromise
any privacy of involed devices.  It is scalable that it can incorporate as many as
servers of realms in the internet. 
 
[--------cliff-----] I have already said if you just compare the number of keys, RSA wins, in the case of a full mesh. But there are other issues in the comparison, other than just the number of keys needed.
 
Without CA/cert, the public key/ID binding is questionable.  Also this binding/security  topic is off the scalability issue that my comparison focuses on, within a single realm. If you want to expand the comparion to cross-realm, I can do another number comparison.
 
b) star topology:
Appx. same number of keys stored for both method.
However, the star topooloy Is not scable as the full-meshed topology:
Hub-spoke topology limits the spoke have only 1 secure link.
It is difficult for a device to join across two different spoke-hub.
Hence, it is only good for a small realm and is not as scable as a meshed model.
The Hub-spoke is not what internet's (IP) farvorite topology and don't mention about
secured internet. 
 
[------cliff------] again, you are off the topic. We are not talking about the topology comparison, full mesh vs hub-spoke.
On the contrary to your claim, in our real-world deployment experience, hub-spoke is much more popular.
The reason I did both full mesh and hub-spoke is because they represent two ends of spectrum.
 
 
 
2) what if no server is used. (this means no 3rd-party's help and
    no out-of-band secure channel)
For both the pre-share RSA and symmetric key have same issue of
mutual authentication at beginning...
 
[--------cliff-----] if you name a key delivery scheme, we can do a number comparison, as I did before.
 
 
 
Operational cost is a factor of mathematical effeciency, there are lots of algorithms/variations
 for symmetric and asymmetric keys.  
 
[--------cliff-----] agree. That's why you need to make your assumption first. But key delivery cost is quite independent of mathematics and probably the most demanding job in terms of scalability.
 
 
 
Let's deal with topology first.
 
--- David
 
 
 
 
----- Original Message -----
Sent: Monday, December 03, 2001 2:17 PM
Subject: RE: On shared keys (was RE: SOI: identity protection and DOS)

David,
 
I have been trying to convince people that RSA public operation provides no clear scalability adavantage over symmetric key. So let me do a orange to orange comparison again using a full mesh and a hub-spoke case. I am only willing to agree with your saying that RSA is better in scalability if such comparison proves it.
 
Assumption:
1) No CA
2) RSA key pair generated in device. Symmetric key generated in server.
3) Server needs to deliver either public key or symmetric key.
 
case 1:  Full mesh:  N*(N-1)/2  tunnels 
 
                                             RSA                        PSK                
1) total number of keys            N key pair                N*(N-1)/2 PSK
2) key generation cost             high                         low
3) number of key delivery          N*(N-1)                    N*(N-1)
4) key storage on the box         1 private key            N-1 PSK
                                              N public key   
5) authentication calculation      high                         low
    cost
6) key on server                      N public key             N*(N-1)/2  (usually not stored)
 
 
case 2 : hub-spoke :  N-1 tunnels
 
                                             RSA                        PSK                
1) total number of keys             N key pair               N-1  PSK
2) key generation cost              high                        low
3) number of key delivery          (N-1)*2                    (N-1)*2
4) key storage on the box        
    hub                                     N public key            N-1  PSK
    spoke                                 2 public key              1 PSK
5) authentication calculation      high                         low
    cost
6) key on server                      N public key             N-1 (usually not stored)
 
So if you are only considering the total number of keys, RSA wins. If you look at overall operation cost, the comparison speaks itself. Unfortunately, there is a lack of scalability adavantage for RSA.
 
 
 
>
------_=_NextPart_001_01C17C4B.B5DDD4D0-- From owner-ipsec@lists.tislabs.com Mon Dec 3 15:52:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Nqj227605; Mon, 3 Dec 2001 15:52:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23717 Mon, 3 Dec 2001 18:08:04 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15372.2029.827473.954773@thomasm-u1.cisco.com> Date: Mon, 3 Dec 2001 15:17:01 -0800 (PST) To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com, ekr@rtfm.com Subject: Re: Some comments on JFK In-Reply-To: <200112032204.RAA22879@bcn.East.Sun.COM> References: <200112032204.RAA22879@bcn.East.Sun.COM> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking writes: > EKR said: > >> (1) In message 1 the initiator sends g^i. This is replayed in message > >> 3. I see why the initiator needs to tell the responder the group he > >> wants to use but why does it need to communicate g^i? If you simply > >> want the initiator to commit to g^i, why not use a hash? This would > >> save some bandwidth, which is always nice :) > > If g^i is in message > 1 it gives Bob the option of getting going on his Diffie-Hellman > calculation if he was willing to > not be stateless and computeless. Right, and this goes well with my "average case" mantra which is that you're normally not going to be under attack, so it would be nice eliminate its overhead when you're not hurting. TCP-SYN cookies work the same way. Mike From owner-ipsec@lists.tislabs.com Mon Dec 3 15:53:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Nqx227626; Mon, 3 Dec 2001 15:52:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23707 Mon, 3 Dec 2001 18:06:14 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Wang, Cliff" , "Sandy Harris" , "'IPsec WG'" References: <4652644B98DFF34696801F8F3070D3FE01188485@D2CSPEXM001.smartpipes.com> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Mon, 3 Dec 2001 18:15:53 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E0_01C17C26.8BD0C140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 03 Dec 2001 23:15:21.0649 (UTC) FILETIME=[61679210:01C17C50] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01E0_01C17C26.8BD0C140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageCliff, You know the remote-access and IP 'back-bone' are the topology of sopke-hub and mesh. You know the assumptions are no CA and using out-of-band secured channel = for both RSA and symmetric keys. It is clearly, given same topology, key delivery method are used,=20 RSA public keys is much more scalable than symmetric keys. If cert/PKI/CA ultimately depends on "self-signed cert", the PKI model is no better than pre-shared model and worser due to its complexicity. But, this is another discussion. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 5:41 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) David, 1) my analysis is on scalability, using hub-spoke and full mesh as two = cases, since they represent two ends of the spectrum. It is NOT my = intention to compare the topology themselves. 2) Key distribution is the most demanding and critical job. Without = PKI, there is no clear scalability advantage of using public key. That's = why PKI is introduced. 3) Let's stop the thread here since enough fact and analysis has been = presented. People on the list are able to draw their own conclusion = based on the analysis. It is much less important for us to agree with = each other. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com]=20 Sent: Monday, December 03, 2001 5:14 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS) Cliff, As in communication, topology first. It was you to bring up hub-sopke against mesh. 1) Don't find anyone claim don't want to have more than one secure = link. =20 Since RSA is the same (as symmetric) in hub-sopke and=20 better in mesh, it is clear to me RSA is better. 2) For pre-shared RSA key and pre-shared symmetric key, The delivery method are through the same "out-of-band" secured = channel. This was the assumption.=20 It assumed no CA and don't need it. 3) The operation cost has different meaning for different = profession. Let's defined it as the computional cost; and that is = *ultimately* mathematical bond. (since, it is 'computatoin'. :-) The crypto-algorithm, number of transcations, protocol used,.. = (and others) are all factors of the computational cost.=20 Can't be done this way (in e-mail) unless you have paper/URL = pointer in mind. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 4:15 PM Subject: RE: On shared keys (was RE: SOI: identity protection and = DOS) See my comments inline. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com]=20 Sent: Monday, December 03, 2001 3:46 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection = and DOS) Cliff, Let's look at this example with some further definition to show = why the RSA is more scalable than the symmetric keys. 1) first let's compare that if all keys stored in server: a) full-meshed topology: It's celar that the RSA public keys is much less than the = symmetric keys=20 in terms of number and the device/public-key association vs. = link/public-key association. In addition, for RSA public key model,=20 the server in each realm can exchange the stored id/public-key = info. without compromise any privacy of involed devices. It is scalable that it can = incorporate as many as servers of realms in the internet.=20 [--------cliff-----] I have already said if you just compare the = number of keys, RSA wins, in the case of a full mesh. But there are = other issues in the comparison, other than just the number of keys = needed. Without CA/cert, the public key/ID binding is questionable. = Also this binding/security topic is off the scalability issue that my = comparison focuses on, within a single realm. If you want to expand the = comparion to cross-realm, I can do another number comparison. b) star topology: Appx. same number of keys stored for both method. However, the star topooloy Is not scable as the full-meshed = topology: Hub-spoke topology limits the spoke have only 1 secure link. It is difficult for a device to join across two different = spoke-hub. Hence, it is only good for a small realm and is not as scable as = a meshed model. The Hub-spoke is not what internet's (IP) farvorite topology and = don't mention about secured internet.=20 [------cliff------] again, you are off the topic. We are not = talking about the topology comparison, full mesh vs hub-spoke. On the contrary to your claim, in our real-world deployment = experience, hub-spoke is much more popular. The reason I did both full mesh and hub-spoke is because they = represent two ends of spectrum. 2) what if no server is used. (this means no 3rd-party's help = and no out-of-band secure channel) For both the pre-share RSA and symmetric key have same issue of=20 mutual authentication at beginning... [--------cliff-----] if you name a key delivery scheme, we can = do a number comparison, as I did before. Operational cost is a factor of mathematical effeciency, there = are lots of algorithms/variations for symmetric and asymmetric keys. =20 [--------cliff-----] agree. That's why you need to make your = assumption first. But key delivery cost is quite independent of = mathematics and probably the most demanding job in terms of scalability. Let's deal with topology first. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 2:17 PM Subject: RE: On shared keys (was RE: SOI: identity protection = and DOS) David, I have been trying to convince people that RSA public = operation provides no clear scalability adavantage over symmetric key. = So let me do a orange to orange comparison again using a full mesh and a = hub-spoke case. I am only willing to agree with your saying that RSA is = better in scalability if such comparison proves it. Assumption:=20 1) No CA 2) RSA key pair generated in device. Symmetric key generated = in server. 3) Server needs to deliver either public key or symmetric key. case 1: Full mesh: N*(N-1)/2 tunnels=20 RSA = PSK =20 1) total number of keys N key pair = N*(N-1)/2 PSK 2) key generation cost high = low 3) number of key delivery N*(N-1) = N*(N-1) 4) key storage on the box 1 private key N-1 = PSK N public key =20 5) authentication calculation high = low cost 6) key on server N public key = N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA = PSK =20 1) total number of keys N key pair = N-1 PSK 2) key generation cost high = low 3) number of key delivery (N-1)*2 = (N-1)*2 4) key storage on the box =20 hub N public key = N-1 PSK spoke 2 public key = 1 PSK 5) authentication calculation high = low cost 6) key on server N public key = N-1 (usually not stored) So if you are only considering the total number of keys, RSA = wins. If you look at overall operation cost, the comparison speaks = itself. Unfortunately, there is a lack of scalability adavantage for = RSA. >=20 ------=_NextPart_000_01E0_01C17C26.8BD0C140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Cliff,
You know the remote-access and IP = 'back-bone' are=20 the topology of
sopke-hub and mesh.
You know the assumptions are no CA and = using=20 out-of-band secured channel for
both RSA and symmetric = keys.
 
It is clearly, given same = topology, key=20 delivery method are used,
RSA public keys is much more scalable = than symmetric keys.
 
If cert/PKI/CA ultimately depends on = "self-signed=20 cert",
the PKI model is no better than = pre-shared model=20 and worser due to
its complexicity.
 
But, this is another = discussion.
 
--- David
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; Sandy Harris = ; 'IPsec=20 WG'
Sent: Monday, December 03, 2001 = 5:41=20 PM
Subject: RE: On shared keys = (was RE: SOI:=20 identity protection and DOS)

David,
 
1)=20 my analysis is on scalability, using hub-spoke and full mesh as two = cases,=20 since they represent two ends of the spectrum. It is NOT my intention = to=20 compare the topology themselves.
2)=20 Key distribution is the most demanding and critical job. Without PKI, = there is=20 no clear scalability advantage of using public key. That's why PKI is=20 introduced.
3) Let's=20  stop the = thread here since=20 enough fact and analysis has been presented. People on the list are = able to=20 draw their own conclusion based on the analysis. It is much less = important for=20 us to agree with each other.
 
-----Original Message-----
From: = david chen=20 [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, = December 03,=20 2001 5:14 PM
To: Wang, Cliff; Sandy Harris; 'IPsec=20 WG'
Subject: Re: On shared keys (was RE: SOI: identity = protection=20 and DOS)

Cliff,
As in communication, topology=20 first.
It was you to bring up hub-sopke = against=20 mesh.
 
1) Don't find anyone claim=20 don't  want to have more than one secure=20 link.
   
    Since RSA is the = same (as=20 symmetric) in hub-sopke and
    better in mesh, = it is clear=20 to me RSA is better.
 
2) For pre-shared RSA key and = pre-shared=20 symmetric key,
   The delivery method = are through=20 the same "out-of-band" secured channel.
   This was the=20 assumption. 
    It assumed no CA = and don't=20 need it.
 
3)  The=20 operation cost has different meaning for different = profession.
     Let's = defined it as=20 the computional cost; and that is *ultimately* mathematical=20 bond.
     (since, it = is=20 'computatoin'. :-)
    The = crypto-algorithm, number=20 of transcations, protocol used,.. (and others) are = all=20 factors of
    the = computational cost.=20
    Can't be = done this way=20 (in e-mail) unless you have paper/URL pointer in = mind.
 
--- David
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; Sandy = Harris ; 'IPsec=20 WG'
Sent: Monday, December 03, = 2001 4:15=20 PM
Subject: RE: On shared keys = (was RE:=20 SOI: identity protection and DOS)

See my comments inline.
-----Original = Message-----
From: david chen=20 [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, = December=20 03, 2001 3:46 PM
To: Wang, Cliff; Sandy Harris; 'IPsec = WG'
Subject: Re: On shared keys (was RE: SOI: identity = protection and DOS)

Cliff,
Let's look at this example with = some=20 further definition to show why the RSA is more
scalable than the symmetric=20 keys.
 
1) first let's compare that if = all keys=20 stored in  server:
a) full-meshed = topology:
It's celar that the RSA public = keys is much=20 less than the symmetric keys 
in terms of number and the=20 device/public-key association vs. link/public-key=20 association.
In addition, for RSA public key = model,=20
the server in each realm can = exchange the=20 stored id/public-key info. without compromise
any privacy=20 of involed devices.  It is scalable that it = can=20 incorporate as many as
servers of realms in the=20 internet. 
 
[--------cliff-----] I have already = said if you=20 just compare the number of keys, RSA wins, in the case of a full = mesh.=20 But there are other issues in the comparison, other than just = the number=20 of keys needed.
 
Without CA/cert, the public key/ID = binding is=20 questionable.  Also this binding/security  topic=20 is off the scalability issue that my comparison = focuses=20 on, within a single realm. If you want to expand the comparion = to=20 cross-realm, I can do another number = comparison.
 
b) star topology:
Appx. same number of keys = stored for both=20 method.
However, the star topooloy = Is not=20 scable as the full-meshed topology:
Hub-spoke topology limits the = spoke have=20 only 1 secure link.
It = is difficult=20 for a device to join across two different = spoke-hub.
Hence, it is only good for = a small=20 realm and is not as scable as a meshed model.
The Hub-spoke is not=20 what internet's (IP) farvorite topology and don't = mention=20 about
secured = internet. 
 
[------cliff------] again, you are = off the=20 topic. We are not talking about the topology comparison, full = mesh vs=20 hub-spoke.
On the=20 contrary to your claim, in our real-world deployment experience, = hub-spoke is much more popular.
The reason I=20 did both full mesh and hub-spoke is because they represent two = ends of=20 spectrum.
 
 
 
2) what if no server is used. = (this means=20 no 3rd-party's help and
    no = out-of-band secure=20 channel)
For both the pre-share RSA and = symmetric=20 key have same issue of
mutual authentication at=20 beginning...
 
[--------cliff-----] if you name a = key delivery=20 scheme, we can do a number comparison, as I did=20 before.
 
 
 
Operational cost is a factor of = mathematical effeciency, there are lots of=20 algorithms/variations
 for symmetric and = asymmetric=20 keys.  
 
[--------cliff-----] agree. That's why you need to make = your=20 assumption first. But key delivery cost is quite independent of=20 mathematics and probably the most demanding job in terms of=20 scalability.
 
 
 
Let's deal with topology=20 first.
 
--- David
 
 
 
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; = Sandy = Harris ;=20 'IPsec WG'
Sent: Monday, December = 03, 2001=20 2:17 PM
Subject: RE: On shared = keys (was=20 RE: SOI: identity protection and DOS)

David,
 
I have been trying to convince = people that=20 RSA public operation provides no clear scalability adavantage = over=20 symmetric key. So let me do a orange to orange comparison = again using=20 a full mesh and a hub-spoke case. I am only willing to agree = with your=20 saying that RSA is better in scalability if such = comparison=20 proves it.
 
Assumption:
1) No CA
2) RSA key pair generated in = device.=20 Symmetric key generated in server.
3) Server needs to deliver either = public key=20 or symmetric key.
 
case 1:  Full=20 mesh:  N*(N-1)/2  = tunnels 
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1) total number of=20 = keys           &nb= sp;N=20 key=20 = pair           &nb= sp;   =20 N*(N-1)/2 PSK
2) key generation=20 = cost           &nb= sp; high         =20 =             &= nbsp; =20 low
3) number of key=20 delivery          = = N*(N-1)           =          N*(N-1)
4) key storage on the=20 box         = 1 private=20 = key           =20 N-1 PSK
      =20 =             &= nbsp;           &n= bsp;           &nb= sp; =20 N public key   
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
    = cost
6) key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N*(N-1)/2  (usually not stored)
 
 
case 2 : hub-spoke :  N-1=20 tunnels
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1) total number of=20 = keys           &nb= sp; N=20 key=20 = pair           &nb= sp;   N-1 =20 PSK
2) key generation=20 = cost           &nb= sp;  high         =    =20 =            low
3) number of key=20 delivery          = = (N-1)*2           =          (N-1)*2
4) key storage on the=20 box        =20
    hub   &= nbsp;           &n= bsp;           &nb= sp;        =20 N public=20 = key          =20  N-1  PSK
   =20 = spoke           &n= bsp;           &nb= sp;         2=20 public=20 = key           &nbs= p;  1=20 PSK
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
    = cost
6) key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N-1 (usually not stored)
 
=
So if you are only considering the = total=20 number of keys, RSA wins. If you look at overall operation = cost, the=20 comparison speaks itself. Unfortunately, there = is a lack=20 of scalability adavantage for RSA.
 
 
 
>=20 =
------=_NextPart_000_01E0_01C17C26.8BD0C140-- From owner-ipsec@lists.tislabs.com Mon Dec 3 17:48:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB41lx203452; Mon, 3 Dec 2001 17:47:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24062 Mon, 3 Dec 2001 19:57:38 -0500 (EST) Message-ID: <89680B404BA1DD419E6D93B28B41899B032335@01mail.nomadix.com> From: Bikramjit Singh To: "'ipsec@lists.tislabs.com'" , vpn@securityfocus.com Subject: Problem with Cisco VPN concentrator Date: Mon, 3 Dec 2001 16:58:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C5E.C3694270" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17C5E.C3694270 Content-Type: text/plain; charset="iso-8859-1" We have developed kind of a VPN masquerade feature for our USG (Universal Subscriber Gateway) product to let ISAKMP and ESP connections passthrough from clients behind our gateway to respective VPN servers. We have taken tips to do accurate routing for inbound traffic from the Linux VPN Masquerade patch code. We are facing a weird problem with the Cisco VPN Concentrator series 3000 ( and maybe all Cisco VPN servers). Since we are doing PAT ( port address translation) multiple subscribers trying to connect to the same Cisco VPN concentrator are unable to do that since Cisco can see only the our USG's IP address and the same port number for ISAKMP (UDP/500) traffic from multiple subscribers. This way Cisco keeps the most recent connection only and the earlier clients connection gets dropped. Other devices (e.g Nortel Contivity) do not show such behaviour and can keep simultaneous sessions even though coming apparently ( USG's IP address) from the same client ( i guess by differentiating them on the basis of the ISAKMP initiator cookies). Cisco accepts the issue with PAT in its release notes and says that it will accept multiple connection from the same client (apparently - although in our case they are multiple clients being PATed on the same IP address and same port) only if they have different source port numbers. Now the question. We want to support both Cisco and non-Cisco connection going through are box without the user seeing any disconnections. Cisco will work with normal PAT ( src ip/src port <---> USG IP/ assigned src port) But others ( e.g Nortel) don't, which require both destination and source port to be 500. Is there a way to "probe" the Cisco concentrator that will till us that it is a "Cisco" and so we should do normal PAT otherwise we should do our normal ISAKMP handling ( keeping track of cookies)? Anybody has any other solution/idea for it? thanks -Bik ---------------------------------------------------------------------------- -------------- Bik Singh 818-575-2518 (Off) Research Scientist 818-597-1502 (Fax) Product Development 31355 Agoura Road Nomadix Westlake Village, CA 91361 ------_=_NextPart_001_01C17C5E.C3694270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We = have developed=20 kind of a VPN masquerade feature for our USG (Universal Subscriber=20 Gateway) product to let ISAKMP and ESP connections passthrough = from clients=20 behind our gateway to respective VPN servers. We have taken tips to do = accurate=20 routing for inbound traffic from the Linux VPN Masquerade patch code. = We are=20 facing a weird problem with the Cisco VPN Concentrator series 3000 ( = and maybe=20 all Cisco VPN servers).
 
Since = we are doing=20 PAT ( port address translation) multiple subscribers trying to connect = to the=20 same Cisco VPN concentrator are unable to do that since Cisco can see = only the=20 our USG's IP address and the same port number for ISAKMP (UDP/500) = traffic from=20 multiple subscribers. This way Cisco keeps the most recent connection = only and=20 the earlier clients connection gets dropped. Other devices (e.g Nortel=20 Contivity) do not show such behaviour and can keep simultaneous = sessions even=20 though coming apparently ( USG's IP address) from the same client ( i = guess by=20 differentiating them on the basis of the ISAKMP initiator cookies).=20
 
Cisco = accepts the=20 issue with PAT in its release notes and says that it will accept = multiple=20 connection from the same client (apparently - although in our case they = are=20 multiple clients being PATed on the same IP address and same port) only = if they=20 have different source port numbers.
 
Now = the question. We=20 want to support both Cisco and non-Cisco connection going through are = box=20 without the user seeing any disconnections. Cisco will work with normal = PAT (=20 src ip/src port <---> USG IP/ assigned src port) But others ( e.g = Nortel)=20 don't, which require both destination and source port to be 500. Is = there a way=20 to "probe" the Cisco concentrator that will till us that it is a = "Cisco" and so=20 we should do normal PAT otherwise we should do our normal ISAKMP = handling (=20 keeping track of cookies)?
 
Anybody has any=20 other solution/idea for it?
 
thanks
 
-Bik

---------------------------------------------------------------= ---------------------------=20
Bik=20 Singh           &= nbsp;           &= nbsp;          =20 818-575-2518 (Off)
Research=20 Scientist          &nb= sp;          =20 818-597-1502 (Fax)
Product=20 Development          &= nbsp;       31355=20 Agoura Road
Nomadix=20        =20        =20         Westlake Village, CA = 91361=20

 
------_=_NextPart_001_01C17C5E.C3694270-- From owner-ipsec@lists.tislabs.com Mon Dec 3 18:32:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB42W5204462; Mon, 3 Dec 2001 18:32:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24250 Mon, 3 Dec 2001 20:44:48 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" Cc: "'IPsec WG'" Subject: RE: SOI: identity protection and DOS Date: Mon, 3 Dec 2001 20:51:09 -0500 Message-ID: <001e01c17c66$261a49d0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I never said that the sig mode of IKE was inadequately secure. > I did mention the advantage of pre-shared mode against possible > break of a DH group in the future. The fact that pre-shared mode is > (much) better in this sense does not mean that people should consider > the sig mode "inadequately secure". When somebody changes something, I take that to mean that what was there before was inadequate. > Moreover, I already said many times, and "implemented" this idea in my > P-SIGMA proposal, that the problem of having to rely on the > IP address for > identifying the shared-key is easily solvable through > an ID payload of type ID_KEY_ID (this was also the motivation to > introduce this type several years ago). > In P-SIGMA this is done via the OIDi field. > Using this you get PFS and protection against active attacks > for BOTH peers (which is impossible to achieve under > any signature mode). > > Actually, even in IKE as it is now, where the OID mechanism > is missing, > one could have used the cookies in the header to identify > shared keys in > the keys database. Any idea, why people did not do that? The problem with the ID_KEY_ID is that it would require extra per host configuration to setup the fake ids and the fake ids still correlate to a real id. I guess the protocol to change the ids on each login and to keep the peers synchronized is complicated enough that no one though it was worth implementing. As for using the cookies for yet another purpose, maybe people felt that they had been abused enough already... Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk > Sent: Wednesday, November 28, 2001 4:21 PM > To: Andrew Krywaniuk > Cc: IPsec WG > Subject: RE: SOI: identity protection and DOS > > > Andrew, see below for a clarification... > > On Tue, 27 Nov 2001, Andrew Krywaniuk wrote: > > > > >(e) is only due to a flaw in IKEv1, and is unrelated to the > > > use of preshared > > > >keys in general. > > > > > > Yup. Some people think that identity protection is > absolutely needed > > > in every circumstance, but most people would agree that identity > > > protection isn't worth preventing pre-shared secrets from working > > > with mobile users. > > > > Well, my point was more that there isn't a conflict between > preshared keys > > and identity protection (of the passive variety). If the > PSK & PKsig SKEYID > > derivations in IKEv1 had been the same (as they could have > been), this > > argument would have never come up. > > > > As some may recall, Hugo originally argued that the PKsig > authentication > > method was inadequately secure because its strength was > based solely on the > > strength of the DH algorithm. The SKEYID for PSK was based > on the DH value + > > a secret value. Therefore, the decision to define the > SKEYID this way was > > merely a design tradeoff of identity protection for > increased security. As > > we noted in draft-improveike (and elsewhere), this tradeoff was not > > necessary since an alternate SKEYID derivation could have > given us both > > properties. > > I never said that the sig mode of IKE was inadequately secure. > I did mention the advantage of pre-shared mode against possible > break of a DH group in the future. The fact that pre-shared mode is > (much) better in this sense does not mean that people should consider > the sig mode "inadequately secure". > > Moreover, I already said many times, and "implemented" this idea in my > P-SIGMA proposal, that the problem of having to rely on the > IP address for > identifying the shared-key is easily solvable through > an ID payload of type ID_KEY_ID (this was also the motivation to > introduce this type several years ago). > In P-SIGMA this is done via the OIDi field. > Using this you get PFS and protection against active attacks > for BOTH peers (which is impossible to achieve under > any signature mode). > > Actually, even in IKE as it is now, where the OID mechanism > is missing, > one could have used the cookies in the header to identify > shared keys in > the keys database. Any idea, why people did not do that? > > Hugo > > > From owner-ipsec@lists.tislabs.com Mon Dec 3 19:53:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB43ra206524; Mon, 3 Dec 2001 19:53:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24365 Mon, 3 Dec 2001 21:57:20 -0500 (EST) Message-Id: <200112040301.fB431Eq10809@marajade.sandelman.ottawa.on.ca> To: Bikramjit Singh cc: "'ipsec@lists.tislabs.com'" , vpn@securityfocus.com Subject: Re: Problem with Cisco VPN concentrator In-reply-to: Your message of "Mon, 03 Dec 2001 16:58:19 PST." <89680B404BA1DD419E6D93B28B41899B032335@01mail.nomadix.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Dec 2001 22:01:13 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bikramjit" == Bikramjit Singh writes: Bikramjit> We have developed kind of Bikramjit> a VPN masquerade feature for our USG (Universal Subscriber Bikramjit> Gateway) product to let ISAKMP and ESP connections passthrough Noble. Please consider making your box do IPv6 with 6to4 addresses (or preconfigured ones) as well. Bikramjit> Since we are doing PAT ( port address translation) multiple Bikramjit> subscribers trying to connect to the same Cisco VPN Bikramjit> concentrator are unable to do that since Cisco can see only Bikramjit> the our USG's IP address and the same port number for ISAKMP Bikramjit> (UDP/500) traffic from multiple subscribers. This way Cisco This isn't surprising. The box has no way to know that you are in fact multiple people behind the gateway. Bikramjit> keeps the most recent connection only and the earlier clients Bikramjit> connection gets dropped. Other devices (e.g Nortel Contivity) Bikramjit> do not show such behaviour and can keep simultaneous sessions Bikramjit> even though coming apparently ( USG's IP address) from the Bikramjit> same client ( i guess by differentiating them on the basis of Bikramjit> the ISAKMP initiator cookies). That's certainly a common way do things, but it isn't required. The other thing that some code does is to send everything from port 500, and demux on incoming based upon the ISAKMP cookies. That way you interoperate with devices that insist on using port 500 for origination. Bikramjit> Cisco accepts the issue with PAT in its release notes and says Bikramjit> that it will accept multiple connection from the same client Bikramjit> (apparently - although in our case they are multiple clients Bikramjit> being PATed on the same IP address and same port) only if they Bikramjit> have different source port numbers. Okay, that's the opposite situation than I'd expect :-) Bikramjit> Now the question. We want to support both Cisco and non-Cisco Bikramjit> connection going through are box without the user seeing any Bikramjit> disconnections. Cisco will work with normal PAT ( src ip/src Bikramjit> port <---> USG IP/ assigned src port) But others ( e.g Nortel) Bikramjit> don't, which require both destination and source port to be Bikramjit> 500. Is there a way to "probe" the Cisco concentrator that Bikramjit> will till us that it is a "Cisco" and so we should do normal Bikramjit> PAT otherwise we should do our normal ISAKMP handling ( Bikramjit> keeping track of cookies)? At a minimum, I guess you need to offer a way a way to configure PAT or not on a per-destination basis. You might be able to probe by doing a minimal IKE exchange and looking for vendor ID strings, but this would be bad. Offer IPv6 as well and you can help this problem go away in the future. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Dec 3 20:13:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB44Du207096; Mon, 3 Dec 2001 20:13:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24448 Mon, 3 Dec 2001 22:25:57 -0500 (EST) Message-ID: <89680B404BA1DD419E6D93B28B41899B03233A@01mail.nomadix.com> From: Bikramjit Singh To: "'Michael Richardson'" , Bikramjit Singh Cc: "'ipsec@lists.tislabs.com'" , vpn@securityfocus.com Subject: RE: Problem with Cisco VPN concentrator Date: Mon, 3 Dec 2001 19:26:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C73.7D958A00" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17C73.7D958A00 Content-Type: text/plain; charset="iso-8859-1" Michael, thanks for the input.. i have some comments inline > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Monday, December 03, 2001 7:01 PM > To: Bikramjit Singh > Cc: 'ipsec@lists.tislabs.com'; vpn@securityfocus.com > Subject: Re: Problem with Cisco VPN concentrator > > > > >>>>> "Bikramjit" == Bikramjit Singh writes: > Bikramjit> We have developed kind of > Bikramjit> a VPN masquerade feature for our USG > (Universal Subscriber > Bikramjit> Gateway) product to let ISAKMP and ESP > connections passthrough > > Noble. Please consider making your box do IPv6 with 6to4 > addresses (or > preconfigured ones) as well. > > Bikramjit> Since we are doing PAT ( port address > translation) multiple > Bikramjit> subscribers trying to connect to the same Cisco VPN > Bikramjit> concentrator are unable to do that since Cisco > can see only > Bikramjit> the our USG's IP address and the same port > number for ISAKMP > Bikramjit> (UDP/500) traffic from multiple subscribers. > This way Cisco > > This isn't surprising. The box has no way to know that you > are in fact > multiple people behind the gateway. > Other concentrators like Nortel do distinguish different connections coming from the same IP/port by looking at initiator/responder cookie values ( i guess). i have been able to maintain multiple connections to the same Nortel server by 2 clients being address translated to the the same IP/port (a.b.c.d/500) at the same time. The cookie values will be different for different boxes behind our gateway. > Bikramjit> keeps the most recent connection only and the > earlier clients > Bikramjit> connection gets dropped. Other devices (e.g > Nortel Contivity) > Bikramjit> do not show such behaviour and can keep > simultaneous sessions > Bikramjit> even though coming apparently ( USG's IP > address) from the > Bikramjit> same client ( i guess by differentiating them > on the basis of > Bikramjit> the ISAKMP initiator cookies). > > That's certainly a common way do things, but it isn't required. > > The other thing that some code does is to send everything > from port 500, > and demux on incoming based upon the ISAKMP cookies. That way you > interoperate with devices that insist on using port 500 for > origination. > This is exactly what we are doing.. But with this configuration Cisco doesn't accept more than one connection. it drops the earlier connection. And if we disable this config and enable normal PAT mode where different source ports are assigned to ISAKMP sessions coming from different clients behind the gateway then Cisco can maintain multiple sessions but not the others (e.g Nortel expects to connect only if src port is 500). There is no way looking at the packet to know if it is going to a Cisco server or a non-Cisco server. > Bikramjit> Cisco accepts the issue with PAT in its > release notes and says > Bikramjit> that it will accept multiple connection from > the same client > Bikramjit> (apparently - although in our case they are > multiple clients > Bikramjit> being PATed on the same IP address and same > port) only if they > Bikramjit> have different source port numbers. > > Okay, that's the opposite situation than I'd expect :-) > > Bikramjit> Now the question. We want to support both > Cisco and non-Cisco > Bikramjit> connection going through are box without the > user seeing any > Bikramjit> disconnections. Cisco will work with normal > PAT ( src ip/src > Bikramjit> port <---> USG IP/ assigned src port) But > others ( e.g Nortel) > Bikramjit> don't, which require both destination and > source port to be > Bikramjit> 500. Is there a way to "probe" the Cisco > concentrator that > Bikramjit> will till us that it is a "Cisco" and so we > should do normal > Bikramjit> PAT otherwise we should do our normal ISAKMP handling ( > Bikramjit> keeping track of cookies)? > > At a minimum, I guess you need to offer a way a way to > configure PAT or not > on a per-destination basis. > Yes, but is there a way to probe the destination and prompt it to say " I am a Cisco " other than snmp (for which we would need apriori knowledge of the community) and is still not a certain response.. > You might be able to probe by doing a minimal IKE exchange > and looking for > vendor ID strings, but this would be bad. > How would you do this?? I do have at my disposal another IP address on the gateway which i could use for such activity ( this would make the Cisco VPN not disconnect the client because its being PATed onto a different IP address ). > Offer IPv6 as well and you can help this problem go away in > the future. not an option right now. > > ] ON HUMILITY: to err is human. To moo, bovine. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another NetBSD/notebook using, kernel hacking, > security guy"); [ > ------_=_NextPart_001_01C17C73.7D958A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Problem with Cisco VPN concentrator

Michael, thanks for the input.. i have some comments = inline

> -----Original Message-----
> From: Michael Richardson [mailto:mcr@sandelman.ottawa.o= n.ca]
> Sent: Monday, December 03, 2001 7:01 PM
> To: Bikramjit Singh
> Cc: 'ipsec@lists.tislabs.com'; = vpn@securityfocus.com
> Subject: Re: Problem with Cisco VPN = concentrator
>
>
>
> >>>>> "Bikramjit" = =3D=3D Bikramjit Singh <BSingh@Nomadix.com> writes:
>     Bikramjit> We have = developed kind of
>     Bikramjit> a VPN = masquerade feature for our USG
> (Universal Subscriber
>     Bikramjit> Gateway) = product to let ISAKMP and ESP
> connections passthrough
>
>   Noble. Please consider making your = box do IPv6 with 6to4
> addresses (or
> preconfigured ones) as well.
>
>     Bikramjit> Since we = are doing PAT ( port address
> translation) multiple
>     Bikramjit> = subscribers trying to connect to the same Cisco VPN
>     Bikramjit> = concentrator are unable to do that since Cisco
> can see only
>     Bikramjit> the our = USG's IP address and the same port
> number for ISAKMP
>     Bikramjit> (UDP/500) = traffic from multiple subscribers.
> This way Cisco
>
>   This isn't surprising. The box has = no way to know that you
> are in fact
> multiple people behind the gateway.
>

Other concentrators like Nortel do distinguish = different connections coming from the same IP/port by looking at = initiator/responder cookie values ( i guess). i have been able to = maintain multiple connections to the same Nortel server by 2 clients = being address translated to the the same IP/port (a.b.c.d/500) at the = same time. The cookie values will be different for different boxes = behind our gateway.

>     Bikramjit> keeps the = most recent connection only and the
> earlier clients
>     Bikramjit> = connection gets dropped. Other devices (e.g
> Nortel Contivity)
>     Bikramjit> do not = show such behaviour and can keep
> simultaneous sessions
>     Bikramjit> even = though coming apparently ( USG's IP
> address) from the
>     Bikramjit> same = client ( i guess by differentiating them
> on the basis of
>     Bikramjit> the = ISAKMP initiator cookies).
>
>   That's certainly a common way do = things, but it isn't required.
>
>   The other thing that some code does = is to send everything
> from port 500,
> and demux on incoming based upon the ISAKMP = cookies.  That way you
> interoperate with devices that insist on using = port 500 for
> origination.
> 

This is exactly what we are doing.. But with this = configuration Cisco doesn't accept more than one connection. it drops = the earlier connection. And if we disable this config and enable normal = PAT mode where different source ports are assigned to ISAKMP sessions = coming from different clients behind the gateway then Cisco can = maintain multiple sessions but not the others (e.g Nortel expects to = connect only if src port is 500). There is no way looking at the packet = to know if it is going to a Cisco server or a non-Cisco = server.

>     Bikramjit> Cisco = accepts the issue with PAT in its
> release notes and says
>     Bikramjit> that it = will accept multiple connection from
> the same client
>     Bikramjit> = (apparently - although in our case they are
> multiple clients
>     Bikramjit> being = PATed on the same IP address and same
> port) only if they
>     Bikramjit> have = different source port numbers.
>
>   Okay, that's the opposite situation = than I'd expect :-)
> 
>     Bikramjit> Now the = question. We want to support both
> Cisco and non-Cisco
>     Bikramjit> = connection going through are box without the
> user seeing any
>     Bikramjit> = disconnections. Cisco will work with normal
> PAT ( src ip/src
>     Bikramjit> port = <---> USG IP/ assigned src port) But
> others ( e.g Nortel)
>     Bikramjit> don't, = which require both destination and
> source port to be
>     Bikramjit> 500. Is = there a way to "probe" the Cisco
> concentrator that
>     Bikramjit> will till = us that it is a "Cisco" and so we
> should do normal
>     Bikramjit> PAT = otherwise we should do our normal ISAKMP handling (
>     Bikramjit> keeping = track of cookies)?
>
>   At a minimum, I guess you need to = offer a way a way to
> configure PAT or not
> on a per-destination basis.
>

Yes, but is there a way to probe the destination and = prompt it to say " I am a Cisco " other than snmp (for which = we would need apriori knowledge of the community) and is still not a = certain response..

>   You might be able to probe by doing = a minimal IKE exchange
> and looking for
> vendor ID strings, but this would be = bad.
>

How would you do this?? I do have at my disposal = another IP address on the gateway which i could use for such activity ( = this would make the Cisco VPN not disconnect the client because its = being PATed onto a different IP address ).

>   Offer IPv6 as well and you can help = this problem go away in
> the future.

not an option right now.

>
> ]       ON = HUMILITY: to err is human. To moo, = bovine.        
>   |  firewalls  [
> ]   Michael Richardson, Sandelman = Software Works, Ottawa, ON 
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca
> http://www.sandelman.ottawa.on.ca/ |device = driver[
> ] panic("Just another NetBSD/notebook = using, kernel hacking,
> security guy");  [
>

------_=_NextPart_001_01C17C73.7D958A00-- From owner-ipsec@lists.tislabs.com Mon Dec 3 20:40:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB44e5207655; Mon, 3 Dec 2001 20:40:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24511 Mon, 3 Dec 2001 22:50:46 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188488@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Tue, 4 Dec 2001 03:59:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17C78.225D3CA0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17C78.225D3CA0 Content-Type: text/plain David, As I said earlier, let me summarize my discussion and hopefully to stop this thread. Based on the assumption (no CA, out-of-band delivery, for full mesh or hub-spoke) and my analysis result, I failed to see the scalability advantage of RSA public based on the comparison numbers. It is not important for me to convince you or not. However, it is important to do an accurate analysis based on the assumption. From the result, the reader of this thread can decide for themselves. The number and fact will speak for itself, whether there is an adavantage or not, right? Thank you for your discussion. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Monday, December 03, 2001 6:16 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cliff, You know the remote-access and IP 'back-bone' are the topology of sopke-hub and mesh. You know the assumptions are no CA and using out-of-band secured channel for both RSA and symmetric keys. It is clearly, given same topology, key delivery method are used, RSA public keys is much more scalable than symmetric keys. If cert/PKI/CA ultimately depends on "self-signed cert", the PKI model is no better than pre-shared model and worser due to its complexicity. But, this is another discussion. --- David ----- Original Message ----- From: Wang, Cliff To: 'david chen' ; Sandy Harris ; 'IPsec WG' Sent: Monday, December 03, 2001 5:41 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) David, 1) my analysis is on scalability, using hub-spoke and full mesh as two cases, since they represent two ends of the spectrum. It is NOT my intention to compare the topology themselves. 2) Key distribution is the most demanding and critical job. Without PKI, there is no clear scalability advantage of using public key. That's why PKI is introduced. 3) Let's stop the thread here since enough fact and analysis has been presented. People on the list are able to draw their own conclusion based on the analysis. It is much less important for us to agree with each other. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Monday, December 03, 2001 5:14 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cliff, As in communication, topology first. It was you to bring up hub-sopke against mesh. 1) Don't find anyone claim don't want to have more than one secure link. Since RSA is the same (as symmetric) in hub-sopke and better in mesh, it is clear to me RSA is better. 2) For pre-shared RSA key and pre-shared symmetric key, The delivery method are through the same "out-of-band" secured channel. This was the assumption. It assumed no CA and don't need it. 3) The operation cost has different meaning for different profession. Let's defined it as the computional cost; and that is *ultimately* mathematical bond. (since, it is 'computatoin'. :-) The crypto-algorithm, number of transcations, protocol used,.. (and others) are all factors of the computational cost. Can't be done this way (in e-mail) unless you have paper/URL pointer in mind. --- David ----- Original Message ----- From: Wang, Cliff To: 'david chen' ; Sandy Harris ; 'IPsec WG' Sent: Monday, December 03, 2001 4:15 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) See my comments inline. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Monday, December 03, 2001 3:46 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cliff, Let's look at this example with some further definition to show why the RSA is more scalable than the symmetric keys. 1) first let's compare that if all keys stored in server: a) full-meshed topology: It's celar that the RSA public keys is much less than the symmetric keys in terms of number and the device/public-key association vs. link/public-key association. In addition, for RSA public key model, the server in each realm can exchange the stored id/public-key info. without compromise any privacy of involed devices. It is scalable that it can incorporate as many as servers of realms in the internet. [--------cliff-----] I have already said if you just compare the number of keys, RSA wins, in the case of a full mesh. But there are other issues in the comparison, other than just the number of keys needed. Without CA/cert, the public key/ID binding is questionable. Also this binding/security topic is off the scalability issue that my comparison focuses on, within a single realm. If you want to expand the comparion to cross-realm, I can do another number comparison. b) star topology: Appx. same number of keys stored for both method. However, the star topooloy Is not scable as the full-meshed topology: Hub-spoke topology limits the spoke have only 1 secure link. It is difficult for a device to join across two different spoke-hub. Hence, it is only good for a small realm and is not as scable as a meshed model. The Hub-spoke is not what internet's (IP) farvorite topology and don't mention about secured internet. [------cliff------] again, you are off the topic. We are not talking about the topology comparison, full mesh vs hub-spoke. On the contrary to your claim, in our real-world deployment experience, hub-spoke is much more popular. The reason I did both full mesh and hub-spoke is because they represent two ends of spectrum. 2) what if no server is used. (this means no 3rd-party's help and no out-of-band secure channel) For both the pre-share RSA and symmetric key have same issue of mutual authentication at beginning... [--------cliff-----] if you name a key delivery scheme, we can do a number comparison, as I did before. Operational cost is a factor of mathematical effeciency, there are lots of algorithms/variations for symmetric and asymmetric keys. [--------cliff-----] agree. That's why you need to make your assumption first. But key delivery cost is quite independent of mathematics and probably the most demanding job in terms of scalability. Let's deal with topology first. --- David ----- Original Message ----- From: Wang, Cliff To: 'david chen' ; Sandy Harris ; 'IPsec WG' Sent: Monday, December 03, 2001 2:17 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) David, I have been trying to convince people that RSA public operation provides no clear scalability adavantage over symmetric key. So let me do a orange to orange comparison again using a full mesh and a hub-spoke case. I am only willing to agree with your saying that RSA is better in scalability if such comparison proves it. Assumption: 1) No CA 2) RSA key pair generated in device. Symmetric key generated in server. 3) Server needs to deliver either public key or symmetric key. case 1: Full mesh: N*(N-1)/2 tunnels RSA PSK 1) total number of keys N key pair N*(N-1)/2 PSK 2) key generation cost high low 3) number of key delivery N*(N-1) N*(N-1) 4) key storage on the box 1 private key N-1 PSK N public key 5) authentication calculation high low cost 6) key on server N public key N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA PSK 1) total number of keys N key pair N-1 PSK 2) key generation cost high low 3) number of key delivery (N-1)*2 (N-1)*2 4) key storage on the box hub N public key N-1 PSK spoke 2 public key 1 PSK 5) authentication calculation high low cost 6) key on server N public key N-1 (usually not stored) So if you are only considering the total number of keys, RSA wins. If you look at overall operation cost, the comparison speaks itself. Unfortunately, there is a lack of scalability adavantage for RSA. > ------_=_NextPart_001_01C17C78.225D3CA0 Content-Type: text/html Message
David,
 
As I said earlier, let me summarize my discussion and hopefully to stop this thread.
 
Based on the assumption  (no CA, out-of-band delivery, for full mesh or hub-spoke) and my analysis result, I failed to see the scalability advantage of RSA public based on the comparison numbers. It is not important for me to convince you or not. However, it is important to do an accurate analysis based on the assumption. From the result, the reader of this thread can decide for themselves. The number and fact will speak for itself, whether there is an adavantage or not, right?
 
Thank you for your discussion.
 
-----Original Message-----
From: david chen [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, December 03, 2001 6:16 PM
To: Wang, Cliff; Sandy Harris; 'IPsec WG'
Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)

Cliff,
You know the remote-access and IP 'back-bone' are the topology of
sopke-hub and mesh.
You know the assumptions are no CA and using out-of-band secured channel for
both RSA and symmetric keys.
 
It is clearly, given same topology, key delivery method are used,
RSA public keys is much more scalable than symmetric keys.
 
If cert/PKI/CA ultimately depends on "self-signed cert",
the PKI model is no better than pre-shared model and worser due to
its complexicity.
 
But, this is another discussion.
 
--- David
 
----- Original Message -----
Sent: Monday, December 03, 2001 5:41 PM
Subject: RE: On shared keys (was RE: SOI: identity protection and DOS)

David,
 
1) my analysis is on scalability, using hub-spoke and full mesh as two cases, since they represent two ends of the spectrum. It is NOT my intention to compare the topology themselves.
2) Key distribution is the most demanding and critical job. Without PKI, there is no clear scalability advantage of using public key. That's why PKI is introduced.
3) Let's  stop the thread here since enough fact and analysis has been presented. People on the list are able to draw their own conclusion based on the analysis. It is much less important for us to agree with each other.
 
-----Original Message-----
From: david chen [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, December 03, 2001 5:14 PM
To: Wang, Cliff; Sandy Harris; 'IPsec WG'
Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)

Cliff,
As in communication, topology first.
It was you to bring up hub-sopke against mesh.
 
1) Don't find anyone claim don't  want to have more than one secure link.
   
    Since RSA is the same (as symmetric) in hub-sopke and
    better in mesh, it is clear to me RSA is better.
 
2) For pre-shared RSA key and pre-shared symmetric key,
   The delivery method are through the same "out-of-band" secured channel.
   This was the assumption. 
    It assumed no CA and don't need it.
 
3)  The operation cost has different meaning for different profession.
     Let's defined it as the computional cost; and that is *ultimately* mathematical bond.
     (since, it is 'computatoin'. :-)
    The crypto-algorithm, number of transcations, protocol used,.. (and others) are all factors of
    the computational cost.
    Can't be done this way (in e-mail) unless you have paper/URL pointer in mind.
 
--- David
 
----- Original Message -----
Sent: Monday, December 03, 2001 4:15 PM
Subject: RE: On shared keys (was RE: SOI: identity protection and DOS)

See my comments inline.
-----Original Message-----
From: david chen [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, December 03, 2001 3:46 PM
To: Wang, Cliff; Sandy Harris; 'IPsec WG'
Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)

Cliff,
Let's look at this example with some further definition to show why the RSA is more
scalable than the symmetric keys.
 
1) first let's compare that if all keys stored in  server:
a) full-meshed topology:
It's celar that the RSA public keys is much less than the symmetric keys 
in terms of number and the device/public-key association vs. link/public-key association.
In addition, for RSA public key model,
the server in each realm can exchange the stored id/public-key info. without compromise
any privacy of involed devices.  It is scalable that it can incorporate as many as
servers of realms in the internet. 
 
[--------cliff-----] I have already said if you just compare the number of keys, RSA wins, in the case of a full mesh. But there are other issues in the comparison, other than just the number of keys needed.
 
Without CA/cert, the public key/ID binding is questionable.  Also this binding/security  topic is off the scalability issue that my comparison focuses on, within a single realm. If you want to expand the comparion to cross-realm, I can do another number comparison.
 
b) star topology:
Appx. same number of keys stored for both method.
However, the star topooloy Is not scable as the full-meshed topology:
Hub-spoke topology limits the spoke have only 1 secure link.
It is difficult for a device to join across two different spoke-hub.
Hence, it is only good for a small realm and is not as scable as a meshed model.
The Hub-spoke is not what internet's (IP) farvorite topology and don't mention about
secured internet. 
 
[------cliff------] again, you are off the topic. We are not talking about the topology comparison, full mesh vs hub-spoke.
On the contrary to your claim, in our real-world deployment experience, hub-spoke is much more popular.
The reason I did both full mesh and hub-spoke is because they represent two ends of spectrum.
 
 
 
2) what if no server is used. (this means no 3rd-party's help and
    no out-of-band secure channel)
For both the pre-share RSA and symmetric key have same issue of
mutual authentication at beginning...
 
[--------cliff-----] if you name a key delivery scheme, we can do a number comparison, as I did before.
 
 
 
Operational cost is a factor of mathematical effeciency, there are lots of algorithms/variations
 for symmetric and asymmetric keys.  
 
[--------cliff-----] agree. That's why you need to make your assumption first. But key delivery cost is quite independent of mathematics and probably the most demanding job in terms of scalability.
 
 
 
Let's deal with topology first.
 
--- David
 
 
 
 
----- Original Message -----
Sent: Monday, December 03, 2001 2:17 PM
Subject: RE: On shared keys (was RE: SOI: identity protection and DOS)

David,
 
I have been trying to convince people that RSA public operation provides no clear scalability adavantage over symmetric key. So let me do a orange to orange comparison again using a full mesh and a hub-spoke case. I am only willing to agree with your saying that RSA is better in scalability if such comparison proves it.
 
Assumption:
1) No CA
2) RSA key pair generated in device. Symmetric key generated in server.
3) Server needs to deliver either public key or symmetric key.
 
case 1:  Full mesh:  N*(N-1)/2  tunnels 
 
                                             RSA                        PSK                
1) total number of keys            N key pair                N*(N-1)/2 PSK
2) key generation cost             high                         low
3) number of key delivery          N*(N-1)                    N*(N-1)
4) key storage on the box         1 private key            N-1 PSK
                                              N public key   
5) authentication calculation      high                         low
    cost
6) key on server                      N public key             N*(N-1)/2  (usually not stored)
 
 
case 2 : hub-spoke :  N-1 tunnels
 
                                             RSA                        PSK                
1) total number of keys             N key pair               N-1  PSK
2) key generation cost              high                        low
3) number of key delivery          (N-1)*2                    (N-1)*2
4) key storage on the box        
    hub                                     N public key            N-1  PSK
    spoke                                 2 public key              1 PSK
5) authentication calculation      high                         low
    cost
6) key on server                      N public key             N-1 (usually not stored)
 
So if you are only considering the total number of keys, RSA wins. If you look at overall operation cost, the comparison speaks itself. Unfortunately, there is a lack of scalability adavantage for RSA.
 
 
 
>
------_=_NextPart_001_01C17C78.225D3CA0-- From owner-ipsec@lists.tislabs.com Mon Dec 3 22:02:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4629216490; Mon, 3 Dec 2001 22:02:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24652 Tue, 4 Dec 2001 00:17:09 -0500 (EST) Date: Tue, 4 Dec 2001 00:26:15 -0500 From: Ran Canetti Message-Id: <200112040526.AAA28640@ornavella.watson.ibm.com> To: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, I agree with most of the facts in your assessment of JFK vs. SIGMA. To sum up, the main technical points seem to be: In terms of security: * The "basic security" of both protocols is sound. * Both protocols allow reuse of the DH exponents in times of high load with a similar price in PFS. * Both protocols offer comparable DOS protection. (What gets included in the cookies can be decided upon independently of the rest of the protocol.) * Both protocols offer identity protection for the initiator against active attackers. * SIGMA offers ID protection for the the receiver against eavesdroppers. JFK does not. In terms of performance: * SIGMA is either 3/5 messages, depending on whether DOS protection is turned on. JFK is 4 messages period. * JFK has an additional signature that, in times of high load, can be amotized over many sessions. Now that the main technical differences are clear, it should be easier for people to decide which properties are preferable to them. Ran From owner-ipsec@lists.tislabs.com Mon Dec 3 22:10:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB46AG216625; Mon, 3 Dec 2001 22:10:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24666 Tue, 4 Dec 2001 00:30:05 -0500 (EST) Date: Tue, 4 Dec 2001 00:39:08 -0500 From: Ran Canetti Message-Id: <200112040539.AAA29828@ornavella.watson.ibm.com> To: ekr@rtfm.com Subject: Re: Some comments on JFK Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric, thanks for your good comments. Two points: * Regarding key derivation and expansion. This can be done in a number of standard ways. For instance, the way it is done in IKEv1 is fine. (To be specific, use HMAC in lieu of the generic PRF.) Indeed, this should be specified. * Regarding different keys for encryption by I and R. This is not really necessary if you're using CBC with random IV, or any "decent" encryption method. (And, yes, ECB mode is not really "decent" in this context.) Ran From owner-ipsec@lists.tislabs.com Tue Dec 4 03:38:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4BcE228818; Tue, 4 Dec 2001 03:38:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25187 Tue, 4 Dec 2001 05:23:51 -0500 (EST) From: johannes.russek@company-bremen.de Date: Tue, 4 Dec 2001 11:33:02 +0100 Message-Id: <200112041033.fB4AWpq25723@ds217-115-141-95.dedicated.hosteurope.de> To: ipsec list Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ÿôÿý From owner-ipsec@lists.tislabs.com Tue Dec 4 03:38:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4BcG228829; Tue, 4 Dec 2001 03:38:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25194 Tue, 4 Dec 2001 05:27:16 -0500 (EST) Date: Tue, 4 Dec 2001 11:33:57 +0100 Message-Id: <200112041033.fB4AXnq25730@ds217-115-141-95.dedicated.hosteurope.de> From: Johannes Russek To: IPSec mailing list Subject: IPSec/IKE/x.509 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi everybody. i read the discussion about IKEv2 and JFK and stuff the last days, and i was reading about IPSec for mobile users in ciscos technical papers, and in the OpenBSD FAQ, and i wonder if there are any other products that use IPSec with IKE and x.509 for mobile users VPN. is there any other implementation, that could be used in a software firewall environment, like Solaris with ipfilter, or maybe OpenBSD, but with a GUI ;) thx in advance! regards, johannes russek From owner-ipsec@lists.tislabs.com Tue Dec 4 06:48:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4Emx203705; Tue, 4 Dec 2001 06:48:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25539 Tue, 4 Dec 2001 08:58:44 -0500 (EST) Message-Id: <5.1.0.14.0.20011204100610.020fcbf0@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Dec 2001 10:13:46 +0100 To: Bikramjit Singh , "'ipsec@lists.tislabs.com'" , vpn@securityfocus.com From: Joern Sierwald Subject: Re: Problem with Cisco VPN concentrator In-Reply-To: <89680B404BA1DD419E6D93B28B41899B032335@01mail.nomadix.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 DAA25009 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:58 03.12.2001 -0800, Bikramjit Singh wrote: >We have developed kind of a VPN masquerade feature for our USG (Universal >Subscriber Gateway) product to let ISAKMP and ESP connections passthrough >from clients behind our gateway to respective VPN servers. We have taken >tips to do accurate routing for inbound traffic from the Linux VPN >Masquerade patch code. We are facing a weird problem with the Cisco VPN >Concentrator series 3000 ( and maybe all Cisco VPN servers). > >Since we are doing PAT ( port address translation) multiple subscribers >trying to connect to the same Cisco VPN concentrator are unable to do that >since Cisco can see only the our USG's IP address and the same port number >for ISAKMP (UDP/500) traffic from multiple subscribers. This way Cisco >keeps the most recent connection only and the earlier clients connection >gets dropped. Other devices (e.g Nortel Contivity) do not show such >behaviour and can keep simultaneous sessions even though coming apparently >( USG's IP address) from the same client ( i guess by differentiating them >on the basis of the ISAKMP initiator cookies). > >Cisco accepts the issue with PAT in its release notes and says that it >will accept multiple connection from the same client (apparently - >although in our case they are multiple clients being PATed on the same IP >address and same port) only if they have different source port numbers. > >Now the question. We want to support both Cisco and non-Cisco connection >going through are box without the user seeing any disconnections. Cisco >will work with normal PAT ( src ip/src port <---> USG IP/ assigned src >port) But others ( e.g Nortel) don't, which require both destination and >source port to be 500. Is there a way to "probe" the Cisco concentrator >that will till us that it is a "Cisco" and so we should do normal PAT >otherwise we should do our normal ISAKMP handling ( keeping track of cookies)? > >Anybody has any other solution/idea for it? > >thanks > >-Bik > >------------------------------------------------------------------------------------------ > >Bik Singh 818-575-2518 (Off) >Research Scientist 818-597-1502 (Fax) >Product Development 31355 Agoura Road >Nomadix Westlake Village, CA 91361 > My comment is that our product VPN+ 5.4 Gateway behaves very much like the Concentrator in this case. The software maintain a list of "currently connected remote clients" and the primary index for the list is (remote IP address;UDP port number). So, having multiple clients mapped to the same (IP address;port number) pair is a bad idea, the gateway will delete session all the time. I just wonder... All PNAT implementations I've seen choose a random port (per UDP "session") for clients. The PNAT I'm exposed to every day is a FW-1. And it translates my UDP-500 IKE packets to src-address 712 or whatever port was free. And this is the behaviour I would expect from ANY PNAT box! If the contivity requires port 500 as src, I'd call that a bug. I'm aware that this won't help much, sorry. J–rn Sierwald From owner-ipsec@lists.tislabs.com Tue Dec 4 06:51:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4Ep2203773; Tue, 4 Dec 2001 06:51:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25538 Tue, 4 Dec 2001 08:58:43 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Wang, Cliff" , "Sandy Harris" , "'IPsec WG'" References: <4652644B98DFF34696801F8F3070D3FE01188488@D2CSPEXM001.smartpipes.com> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Tue, 4 Dec 2001 00:53:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02BF_01C17C5E.1B1956A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 04 Dec 2001 05:53:05.0903 (UTC) FILETIME=[F19BBFF0:01C17C87] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_02BF_01C17C5E.1B1956A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageCliff, You are quite welcome. :-) --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 10:59 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) David, As I said earlier, let me summarize my discussion and hopefully to = stop this thread. Based on the assumption (no CA, out-of-band delivery, for full mesh = or hub-spoke) and my analysis result, I failed to see the scalability = advantage of RSA public based on the comparison numbers. It is not = important for me to convince you or not. However, it is important to do = an accurate analysis based on the assumption. From the result, the = reader of this thread can decide for themselves. The number and fact = will speak for itself, whether there is an adavantage or not, right? Thank you for your discussion. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com]=20 Sent: Monday, December 03, 2001 6:16 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and = DOS) Cliff, You know the remote-access and IP 'back-bone' are the topology of sopke-hub and mesh. You know the assumptions are no CA and using out-of-band secured = channel for both RSA and symmetric keys. It is clearly, given same topology, key delivery method are used,=20 RSA public keys is much more scalable than symmetric keys. If cert/PKI/CA ultimately depends on "self-signed cert", the PKI model is no better than pre-shared model and worser due to its complexicity. But, this is another discussion. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 5:41 PM Subject: RE: On shared keys (was RE: SOI: identity protection and = DOS) David, 1) my analysis is on scalability, using hub-spoke and full mesh as = two cases, since they represent two ends of the spectrum. It is NOT my = intention to compare the topology themselves. 2) Key distribution is the most demanding and critical job. = Without PKI, there is no clear scalability advantage of using public = key. That's why PKI is introduced. 3) Let's stop the thread here since enough fact and analysis has = been presented. People on the list are able to draw their own conclusion = based on the analysis. It is much less important for us to agree with = each other. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com]=20 Sent: Monday, December 03, 2001 5:14 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection = and DOS) Cliff, As in communication, topology first. It was you to bring up hub-sopke against mesh. 1) Don't find anyone claim don't want to have more than one = secure link. =20 Since RSA is the same (as symmetric) in hub-sopke and=20 better in mesh, it is clear to me RSA is better. 2) For pre-shared RSA key and pre-shared symmetric key, The delivery method are through the same "out-of-band" = secured channel. This was the assumption.=20 It assumed no CA and don't need it. 3) The operation cost has different meaning for different = profession. Let's defined it as the computional cost; and that is = *ultimately* mathematical bond. (since, it is 'computatoin'. :-) The crypto-algorithm, number of transcations, protocol = used,.. (and others) are all factors of the computational cost.=20 Can't be done this way (in e-mail) unless you have paper/URL = pointer in mind. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 4:15 PM Subject: RE: On shared keys (was RE: SOI: identity protection = and DOS) See my comments inline. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com]=20 Sent: Monday, December 03, 2001 3:46 PM To: Wang, Cliff; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity = protection and DOS) Cliff, Let's look at this example with some further definition to = show why the RSA is more scalable than the symmetric keys. 1) first let's compare that if all keys stored in server: a) full-meshed topology: It's celar that the RSA public keys is much less than the = symmetric keys=20 in terms of number and the device/public-key association vs. = link/public-key association. In addition, for RSA public key model,=20 the server in each realm can exchange the stored = id/public-key info. without compromise any privacy of involed devices. It is scalable that it can = incorporate as many as servers of realms in the internet.=20 [--------cliff-----] I have already said if you just compare = the number of keys, RSA wins, in the case of a full mesh. But there are = other issues in the comparison, other than just the number of keys = needed. Without CA/cert, the public key/ID binding is questionable. = Also this binding/security topic is off the scalability issue that my = comparison focuses on, within a single realm. If you want to expand the = comparion to cross-realm, I can do another number comparison. b) star topology: Appx. same number of keys stored for both method. However, the star topooloy Is not scable as the full-meshed = topology: Hub-spoke topology limits the spoke have only 1 secure link. It is difficult for a device to join across two different = spoke-hub. Hence, it is only good for a small realm and is not as = scable as a meshed model. The Hub-spoke is not what internet's (IP) farvorite topology = and don't mention about secured internet.=20 [------cliff------] again, you are off the topic. We are not = talking about the topology comparison, full mesh vs hub-spoke. On the contrary to your claim, in our real-world deployment = experience, hub-spoke is much more popular. The reason I did both full mesh and hub-spoke is because = they represent two ends of spectrum. 2) what if no server is used. (this means no 3rd-party's = help and no out-of-band secure channel) For both the pre-share RSA and symmetric key have same issue = of=20 mutual authentication at beginning... [--------cliff-----] if you name a key delivery scheme, we = can do a number comparison, as I did before. Operational cost is a factor of mathematical effeciency, = there are lots of algorithms/variations for symmetric and asymmetric keys. =20 [--------cliff-----] agree. That's why you need to make your = assumption first. But key delivery cost is quite independent of = mathematics and probably the most demanding job in terms of scalability. Let's deal with topology first. --- David ----- Original Message -----=20 From: Wang, Cliff=20 To: 'david chen' ; Sandy Harris ; 'IPsec WG'=20 Sent: Monday, December 03, 2001 2:17 PM Subject: RE: On shared keys (was RE: SOI: identity = protection and DOS) David, I have been trying to convince people that RSA public = operation provides no clear scalability adavantage over symmetric key. = So let me do a orange to orange comparison again using a full mesh and a = hub-spoke case. I am only willing to agree with your saying that RSA is = better in scalability if such comparison proves it. Assumption:=20 1) No CA 2) RSA key pair generated in device. Symmetric key = generated in server. 3) Server needs to deliver either public key or symmetric = key. case 1: Full mesh: N*(N-1)/2 tunnels=20 RSA = PSK =20 1) total number of keys N key pair = N*(N-1)/2 PSK 2) key generation cost high = low 3) number of key delivery N*(N-1) = N*(N-1) 4) key storage on the box 1 private key = N-1 PSK N public key = =20 5) authentication calculation high = low cost 6) key on server N public key = N*(N-1)/2 (usually not stored) case 2 : hub-spoke : N-1 tunnels RSA = PSK =20 1) total number of keys N key pair = N-1 PSK 2) key generation cost high = low 3) number of key delivery (N-1)*2 = (N-1)*2 4) key storage on the box =20 hub N public key = N-1 PSK spoke 2 public key = 1 PSK 5) authentication calculation high = low cost 6) key on server N public key = N-1 (usually not stored) So if you are only considering the total number of keys, = RSA wins. If you look at overall operation cost, the comparison speaks = itself. Unfortunately, there is a lack of scalability adavantage for = RSA. >=20 ------=_NextPart_000_02BF_01C17C5E.1B1956A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Cliff,
You are quite welcome. :-)
--- David
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; Sandy Harris = ; 'IPsec=20 WG'
Sent: Monday, December 03, 2001 = 10:59=20 PM
Subject: RE: On shared keys = (was RE: SOI:=20 identity protection and DOS)

David,
 
As I=20 said earlier, let me summarize my discussion and hopefully to = stop this=20 thread.
 
Based on the assumption  (no CA, out-of-band delivery, = for full=20 mesh or hub-spoke) and my analysis result, I failed to see the = scalability=20 advantage of RSA public based on the comparison numbers. It is not = important=20 for me to convince you or not. However, it is important to do an = accurate=20 analysis based on the assumption. From the result, the reader of = this=20 thread can decide for themselves. The number and fact will speak = for=20 itself, whether there is an adavantage or not, = right?
 
Thank you for your discussion.
 
-----Original Message-----
From: = david chen=20 [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, = December 03,=20 2001 6:16 PM
To: Wang, Cliff; Sandy Harris; 'IPsec=20 WG'
Subject: Re: On shared keys (was RE: SOI: identity = protection=20 and DOS)

Cliff,
You know the remote-access and IP = 'back-bone'=20 are the topology of
sopke-hub and mesh.
You know the assumptions are no CA = and using=20 out-of-band secured channel for
both RSA and symmetric = keys.
 
It is clearly, given same = topology, key=20 delivery method are used,
RSA public keys is much more = scalable=20 than symmetric keys.
 
If cert/PKI/CA ultimately depends = on=20 "self-signed cert",
the PKI model is no better than = pre-shared=20 model and worser due to
its complexicity.
 
But, this is another = discussion.
 
--- David
 
----- Original Message ----- =
From:=20 Wang,=20 Cliff
To: 'david chen' ; Sandy = Harris ; 'IPsec=20 WG'
Sent: Monday, December 03, = 2001 5:41=20 PM
Subject: RE: On shared keys = (was RE:=20 SOI: identity protection and DOS)

David,
 
1) my analysis is on scalability, using hub-spoke and = full mesh as=20 two cases, since they represent two ends of the spectrum. It is = NOT my=20 intention to compare the topology themselves.
2) Key distribution is the most demanding and critical = job. Without=20 PKI, there is no clear scalability advantage of using public key. = That's=20 why PKI is introduced.
3) Let's=20  stop the = thread here=20 since enough fact and analysis has been presented. People on the = list are=20 able to draw their own conclusion based on the analysis. It is = much less=20 important for us to agree with each other.
 
-----Original = Message-----
From: david chen=20 [mailto:ietf_davidchen@hotmail.com]
Sent: Monday, = December=20 03, 2001 5:14 PM
To: Wang, Cliff; Sandy Harris; 'IPsec = WG'
Subject: Re: On shared keys (was RE: SOI: identity = protection and DOS)

Cliff,
As in = communication, topology=20 first.
It was you to bring up = hub-sopke against=20 mesh.
 
1) Don't find anyone claim = don't  want to have more than one secure=20 link.
    =
    Since RSA is = the same=20 (as symmetric) in hub-sopke and
    better in = mesh, it is=20 clear to me RSA is = better.
 
2) For pre-shared RSA key and = pre-shared=20 symmetric key,
   The delivery = method are=20 through the same "out-of-band" secured = channel.
   This was the=20 assumption. 
    It assumed = no CA and=20 don't need it.
 
3)  The=20 operation cost has different meaning for different=20 profession.
     Let's = defined it=20 as the computional cost; and that is *ultimately* = mathematical=20 bond.
     = (since, it is=20 'computatoin'. :-)
    The = crypto-algorithm,=20 number of transcations, protocol used,.. (and = others) are=20 all factors of
    the = computational cost.=20
    Can't = be done this=20 way (in e-mail) unless you have paper/URL pointer in=20 mind.
 
--- David
 
----- Original Message -----
From:=20 Wang,=20 Cliff
To: 'david chen' ; = Sandy = Harris ;=20 'IPsec WG'
Sent: Monday, December = 03, 2001=20 4:15 PM
Subject: RE: On shared = keys (was=20 RE: SOI: identity protection and DOS)

See my comments inline.
-----Original = Message-----
From: david=20 chen [mailto:ietf_davidchen@hotmail.com]
Sent: = Monday,=20 December 03, 2001 3:46 PM
To: Wang, Cliff; Sandy = Harris;=20 'IPsec WG'
Subject: Re: On shared keys (was RE: = SOI:=20 identity protection and DOS)

Cliff,
Let's look at this example = with some=20 further definition to show why the RSA is more
scalable than the symmetric = keys.
 
1) first let's compare that = if all keys=20 stored in  server:
a) full-meshed = topology:
It's celar that the RSA = public keys is=20 much less than the symmetric keys 
in terms of number and the=20 device/public-key association vs. link/public-key=20 association.
In addition, for RSA public = key model,=20
the server in each realm = can exchange=20 the stored id/public-key info. without = compromise
any privacy=20 of involed devices.  It is scalable = that it can=20 incorporate as many as
servers of realms in the=20 internet. 
 
[--------cliff-----] I have = already said if=20 you just compare the number of keys, RSA wins, in the case = of a full=20 mesh. But there are other issues in the comparison, other = than just=20 the number of keys needed.
 
Without CA/cert, the public = key/ID binding=20 is questionable.  Also this binding/security =  topic=20 is off the scalability issue that my = comparison=20 focuses on, within a single realm. If you want to expand the = comparion to cross-realm, I can do another number=20 comparison.
 
b) star = topology:
Appx. same number of keys = stored for=20 both method.
However, the star topooloy = Is not=20 scable as the full-meshed topology:
Hub-spoke topology limits = the spoke=20 have only 1 secure link.
It is=20 difficult for a device to join across two different=20 spoke-hub.
Hence, it is only good = for a small=20 realm and is not as scable as a meshed = model.
The Hub-spoke is not=20 what internet's (IP) farvorite topology and don't = mention=20 about
secured = internet. 
 
[------cliff------] again, you = are off the=20 topic. We are not talking about the topology comparison, = full mesh=20 vs hub-spoke.
On the=20 contrary to your claim, in our real-world deployment = experience,=20 hub-spoke is much more popular.
The=20 reason I did both full mesh and hub-spoke is because they = represent=20 two ends of spectrum.
 
 
 
2) what if no server is = used. (this=20 means no 3rd-party's help and
    no = out-of-band=20 secure channel)
For both the pre-share RSA = and=20 symmetric key have same issue of
mutual authentication at=20 beginning...
 
[--------cliff-----] if you name = a key=20 delivery scheme, we can do a number comparison, as I did=20 before.
 
 
 
Operational cost is a = factor of=20 mathematical effeciency, there are lots of=20 algorithms/variations
 for symmetric and = asymmetric=20 keys.  
 
[--------cliff-----] agree. That's why you need to = make your=20 assumption first. But key delivery cost is quite independent = of=20 mathematics and probably the most demanding job in terms of=20 scalability.
 
 
 
Let's deal with topology=20 first.
 
--- David
 
 
 
 
----- Original Message -----
From:=20 Wang, Cliff =
To: 'david = chen' ; Sandy Harris=20 ; 'IPsec WG' =
Sent: Monday, = December 03,=20 2001 2:17 PM
Subject: RE: On = shared keys=20 (was RE: SOI: identity protection and DOS)

David,
 
I have been trying to convince = people=20 that RSA public operation provides no clear scalability = adavantage=20 over symmetric key. So let me do a orange to orange = comparison=20 again using a full mesh and a hub-spoke case. I am only = willing to=20 agree with your saying that RSA is better in = scalability=20 if such comparison proves it.
 
Assumption: =
1) No CA
2) RSA key pair generated in = device.=20 Symmetric key generated in server.
3) Server needs to deliver = either public=20 key or symmetric key.
 
case 1:  Full=20 mesh:  N*(N-1)/2  = tunnels 
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1) total number of=20 = keys           &nb= sp;N=20 key=20 = pair           &nb= sp;   =20 N*(N-1)/2 PSK
2) key generation=20 = cost           &nb= sp; high         =20 =             &= nbsp; =20 low
3) number of key=20 = delivery         =20 = N*(N-1)           =          N*(N-1)
4) key storage on the=20 box         = 1 private=20 = key           =20 N-1 PSK
      =20 =             &= nbsp;           &n= bsp;           &nb= sp; =20 N public key   
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
   =20 cost
6) key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N*(N-1)/2  (usually not stored)
 
 
case 2 : hub-spoke :  N-1=20 tunnels
 
       &nbs= p;          =20 =             &= nbsp;     =20       =20 = RSA           &nbs= p;           =20 = PSK           &nbs= p;    =20
1) total number of=20 = keys           &nb= sp; N=20 key=20 = pair           &nb= sp;   N-1 =20 PSK
2) key generation=20 = cost           &nb= sp;  high         =    =20 =            low
3) number of key=20 = delivery         =20 = (N-1)*2           =          (N-1)*2
4) key storage on the=20 box        =20
    hub   &= nbsp;           &n= bsp;           &nb= sp;        =20 N public=20 = key          =20  N-1  PSK
   =20 = spoke           &n= bsp;           &nb= sp;         2=20 public=20 = key           &nbs= p;  1=20 PSK
5)=20 = authentication calculation      high&n= bsp;           &nb= sp;           =20 low
   =20 cost
6) key on=20 = server           &= nbsp;         =20 N public=20 = key           &nbs= p;=20 N-1 (usually not stored)
 
=
So if you are only considering = the total=20 number of keys, RSA wins. If you look at overall operation = cost,=20 the comparison speaks itself. Unfortunately,=20 there is a lack of scalability adavantage for=20 RSA.
 
 
 
>=20 =
------=_NextPart_000_02BF_01C17C5E.1B1956A0-- From owner-ipsec@lists.tislabs.com Tue Dec 4 06:58:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4Ewp203959; Tue, 4 Dec 2001 06:58:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25631 Tue, 4 Dec 2001 09:10:55 -0500 (EST) Message-ID: <035501c17cce$fd6de730$32c02ca1@cisco.com> From: "Stephane Beaulieu" To: "Radia Perlman - Boston Center for Networking" , References: <200112032039.PAA22522@bcn.East.Sun.COM> Subject: Re: Stephane's Comments on IKEv2 Date: Tue, 4 Dec 2001 09:21:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > questions 4 and 5: Clarification of sequence numbers: If a sequence number > is "out of whack", drop the message. Well, yes. But I was just wondering if a NOTIFY or something was required, or if we should just blindly drop the packet. > Out of whack: Suppose the receiver Bob's window is n, and the largest > sequence number of a valid message Bob has seen is k and the most > recent "hole", i.e., sequence number he has NOT yet seen, is j. j is > guaranteed to be less than k, and in fact less than k+n+1, if Alice > is following the rules. Bob must reject anything greater than j+n (Alice > shouldn't be sending anything > greater than j+n if Bob has not ack'd j) or less than k-n. For something > between k-n and j+n, Bob will respond. He is committed to keeping track > of n messages if the msg isn't idempotent, so if it's within the window > if Bob has seen it before he is guaranteed to send back the same response > as he did before. That's why we don't want him to simply drop messages > if his receive window is, say, n, and Alice sends n+5 messages at once. > He might respond to something, and then get a retransmission, and perhaps > he'd respond something different the second time. And his first response > might actually reach Alice (she'd prematurely given up on it) and perhaps > things would get confused. Seemed simpler to just have Alice NOT send > more than Bob is willing to remember. > > As for reaching sequence number 2^32 on > the IKE-SA...Funny thing about that... > Charlie asked me that and I said, "Come on! There's no > way you could ever send that many IKE messages", so he agreed > not to say anything in the spec about it. But it would > be easy to add that if you run out of sequence numbers > you rekey. And then I'd have to admit to Charlie that he was right > and we should have said something about that in the spec. :-) I'm still not very keen on this "windowing" concept. It seems that the initiator will have to perform some logic to ensure that it doesn't overwhelm the responder. In essence, the initiator is doing the responder's job in managing it's resources. I prefer the model where the initiator makes requests, and the responder processes as many as he can. Once the responder is overwhelmed, it starts to ignore requests. The initiator's job in this case is to ensure that it re-requests the service if it is still needed, or perhaps attempt a connection with a secondary Gateway which is hopefully not as busy. > > 8-9: missing AUTH payload: We don't use an auth payload to protect > the contents of any IKE messages beyond 1 and 2. The AUTH payload protects > messages 1 and 2 and proves identity. All IKEv2 messages after the first 2 in > the initial IKE-SA creation are fully > encrypted and integrity protected using a key > which is a function, among other things, of the Diffie-Hellman > key established in messages 1 and 2, so if the other side knows > the integrity check key they must be the entity that proved their > identity in the AUTH payload. Instead of doing integrity protection > for messages 3 and later > with an AUTH payload, which was kind of painful to specify because it > involves discussing how to integrity protect something that includes > the integrity protection bytes, the integrity field is at the end of > the packet. To save words in the spec, we said "use the same format > as ESP", i.e., IV | encrypted data | encrypted padding | enc. pad. length | > wasted byte (where ESP has "next header") | integrity check > So this is equivalent to having an AUTH payload...it's just that the integrity > check follows the encrypted data rather than being in the middle of it. > > And the integrity check protects everything, including the IKE header, so > we don't have to think about what fields should go into an integrity check > payload. > > Some people objected to, and some people were confused by, our pointing > to the ESP spec. We certainly could explicitly lay out the packet format > inside IKEv2 rather than pointing to the ESP spec, and then we could > get rid of the funny reserved byte after the encrypted padding length field. > Count me among the confused. I completely missed any such wording. I'll take another look. Thanks for pointing it out. > > 6) reactions to unprotected messages like ICMP "destination unreachable" > or unprotected "unknown SPI" IKE messages: > > If you rely on periodic IKE pings to detect the dead peer, it might be > a long time that you'd be sending into a black hole. If the routing > infrastructure says the destination is unreachable, you can use that > to be suspicious and check for aliveness in order to speed things up, > but it has to be rate limited so someone can't send you a zillion > ICMP messages. Ah.... I just re-read this section. I was completely mis-understanding what you were saying. Sorry. > > 7) being more specific about waiting for known aliveness of new SA before > deleting the old one. Seems like a good idea. I'd be glad to > read Tim Jenkin's draft except you said it was expired. > Pet peeve: you pointed me at an expired internet draft, which means it's > hard to get. It would be nice if the IETF page had a link to all drafts > ever made. At any rate, could you send me a copy of Tim's draft? (don't > CC the list when you do of course) OK. It's on its way. > > 10: INITIAL-CONTACT: I'm not a fan of it at all, but > I understand other people like it. It makes me nervous > because although the spec says "don't do that" it's possible > someone will replicate a service and then you could have multiple > things with the same ID and nullifying each other's connections. > Bill Sommerfeld got me to like the INITIAL-CONTACT > thing better if we add "and the > same IP address" after the phrase "to the same > authenticated identity". > An alternative is > Bill Sommerfeld's birth certificate proposal, which is a "to be written" > internet draft rather than an "expired draft" which makes it just as > hard to find. :-) I'm slightly nervous about that as well, in the > unlikely event that someone's monotonically increasing counter actually > goes backwards, without being aware of it. And I'm not convinced > things wouldn't work without either mechanism. I don't have strong > feelings either way though. As for your question > about where INITIAL-CONTACT would appear: It would be in message 3 or 4, and > it would be covered by the integrity check > as would everything else inside messages 3 and 4. OK. Can you add text to that effect. I've seen INITIAL-CONTACT in strange places before ;) > > 11: deletes for IKE SAs: I don't understand what you were asking. Section 7.11 The new IKE SA delete payload doesn't allow you to specify cookies in the SPI field. That was allowed in IKEv1. This was conveniant in order to use an IKE SA to send a protected DELETE for some out-of-sync IKE SA. So in other words, if peer A thought he had 2 IKE SAs (SA1, SA2), and peer B only thought he had 1 IKE SA (SA2). This out-of-sync scenario could happen for multiple reasons in IKEv1. In this case peer A could be sending data (ex. Create-Child-SA) with SA1. When peer B received this data, it wouldn't be able to find the matching SA to decrypt with. Peer B could then send a DELETE with SA1's cookies, using SA2 to encrypt it. I guess we could also use INVALID_COOKIE notify, but it was always more reliable / predictable to send the delete. Granted, many of the conditions which led to this scenario are gone in IKEv2. The ack'd DELETES solve the most common case. However, permitting the specification of cookies in the SPI has no drawbacks (other than a few more bits on the wire), yet it could prove to be very useful. > > 13: Nat traversal: we'll have to think about this. As well as perhaps > going through an anonymizer, which I'd think would be similar. Wanna help? :-) > > Radia > > From owner-ipsec@lists.tislabs.com Tue Dec 4 08:23:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4GNq208690; Tue, 4 Dec 2001 08:23:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00960 Tue, 4 Dec 2001 10:16:03 -0500 (EST) Date: Tue, 4 Dec 2001 17:25:49 +0200 (IST) From: Hugo Krawczyk To: Ran Canetti cc: ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-Reply-To: <200112040526.AAA28640@ornavella.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 4 Dec 2001, Ran Canetti wrote: > > Hugo, > > I agree with most of the facts in your assessment of JFK vs. SIGMA. Ran, I'm happy we agree. Now the question is what we do about it. It seems to me that you (and maybe the other JFK designers) do not consider the extra signature SIG(g^r) to be AS BAD as I think. I see it as a real computational burden and/or a push to limit PFS (at the responder's side). It also calls for "outlawing" signatures like DSA (or ECDSA) where the verification complexity is significant. (Is this an idea coming from RSA Inc.? :) Note that the poor initiator cannot amortize the costs of this signature verification! The drawbacks are clear. So, what are the benefits? Only keeping the initiator's id protected from active attackers, something I appreciate as a good thing, but not at the expense of generation/verification of this signature AND forcing responder's id diclosure. If keeping a 4-msg protocol that includes DoS is important to you, I would recommend the following protocol that combines the JFK structure with the SIGMA ("Sign-and-MAC") authentication and avoids all the problems that I pointed out in part B of compare-jfk-sigma.txt, except for the long input to HMAC (see below). Its main accomplishment regarding JFK is the elimination of the (irritating) SIG(g^r) and its pfs-limitation consequences, providing R with active protection (as opposed to no protection in JFK), and providing I with passive protection (as opposed to active protection in JFK; well, there is no free lunch...) This id protection is the same as provided by IKEv2. The protocol (with some details/optimization to be discussed) goes: 1. I->R: Ni, g^i 2. R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKr}(Ni, Nr, g^r) 3. I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(Ni, Nr, g^r) E{Ke}(IDi, sa, SIG{i}(MAC{Ka}(0, Nr, Ni, IDi, g^i, g^r, sa)) 4. R->I: E{Ke}(IDr, sa', SIG{r}(MAC{Ka}(1, Ni, Nr, IDr, g^r, g^i, sa')) All notation is as in JFK, with the key Ka being derived from g^ir in a similar way to Ke. There are some possible optimizations, like not sending g^i in first message (maybe only a group identifier), but then this is less good for responders that do not care about DoS. Another one is making the DoS protection optional for R (just avoids the generation and sending of the cookie and related stuff). One thing that I still do not like here is putting g^r under the cookie computation: it's long. One could include HASH(g^r) under the cookie, but this helps performance only when you keep same r for several sessions. In any case this is "nothing" compared to the need to compute SIG(g^r)... And please, with all my respect to HMAC :), do not specify HMAC as the ONLY cookie mechansim. You can suggest it, or make it a "SHOULD", but why mandate something that is a local implementation issue, and for which other MAC mechansims may work better (e.g. faster)? Hugo PS: Note that the above protocol is the "ultimate merge" between JFK, IKEv2, and SIGMA. Negotiation, phase 2, etc are independent matters and can be dealt with separately. On Tue, 4 Dec 2001, Ran Canetti wrote: > > Hugo, > > I agree with most of the facts in your assessment of JFK vs. SIGMA. > To sum up, the main technical points seem to be: > > In terms of security: > > * The "basic security" of both protocols is sound. > > * Both protocols allow reuse of the DH exponents in times of high load > with a similar price in PFS. > > * Both protocols offer comparable DOS protection. (What gets included in > the cookies can be decided upon independently of the rest of the protocol.) > > * Both protocols offer identity protection for the initiator against active > attackers. > > * SIGMA offers ID protection for the the receiver against eavesdroppers. > JFK does not. > > > In terms of performance: > > * SIGMA is either 3/5 messages, depending on whether DOS protection is > turned on. JFK is 4 messages period. > > * JFK has an additional signature that, in times of high load, can be > amotized over many sessions. > > > Now that the main technical differences are clear, it should be easier for > people to decide which properties are preferable to them. > > > Ran > > > From owner-ipsec@lists.tislabs.com Tue Dec 4 11:05:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB4J5h213281; Tue, 4 Dec 2001 11:05:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01496 Tue, 4 Dec 2001 13:13:15 -0500 (EST) Date: Tue, 4 Dec 2001 20:23:13 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'IPsec WG'" Subject: RE: SOI: identity protection and DOS In-Reply-To: <001e01c17c66$261a49d0$1e72788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 3 Dec 2001, Andrew Krywaniuk wrote: > > I never said that the sig mode of IKE was inadequately secure. > > I did mention the advantage of pre-shared mode against possible > > break of a DH group in the future. The fact that pre-shared mode is > > (much) better in this sense does not mean that people should consider > > the sig mode "inadequately secure". > > When somebody changes something, I take that to mean that what was there > before was inadequate. I am confused. Which change and which "somebody" are you talking about? > > > > Moreover, I already said many times, and "implemented" this idea in my > > P-SIGMA proposal, that the problem of having to rely on the > > IP address for > > identifying the shared-key is easily solvable through > > an ID payload of type ID_KEY_ID (this was also the motivation to > > introduce this type several years ago). > > In P-SIGMA this is done via the OIDi field. > > Using this you get PFS and protection against active attacks > > for BOTH peers (which is impossible to achieve under > > any signature mode). > > > > Actually, even in IKE as it is now, where the OID mechanism > > is missing, > > one could have used the cookies in the header to identify > > shared keys in > > the keys database. Any idea, why people did not do that? > > > The problem with the ID_KEY_ID is that it would require extra per host > configuration to setup the fake ids and the fake ids still correlate to a > real id. I guess the protocol to change the ids on each login and to keep > the peers synchronized is complicated enough that no one though it was worth > implementing. There is no configuration issue involved (except maybe if you talk about manual installation which is already a high-cost management issue). As for correlation, I can imaging that MOST people will not care about that. And for those, that care, doing chaining is not such a big deal. It is quite equivalent to the management of sequence number windows for phase 2 in IKEv2, except that you need to maintain a number of key identifiers as the window size. The good thing about these chained identifiers is that they require no set-up, no management, no interaction and they solve FOR FREE the DoS issue. Ah... and it gives active protection to BOTH iniitator and responder! (Actually, now that I think of it they are really nice :) > > As for using the cookies for yet another purpose, maybe people felt that > they had been abused enough already... As opposed to many other abuses of cookies, this is not a real "abuse". The real functionality of cookies in IKE is as session-identifiers. Using them as key identifiers is not very different. BTW, if I understand correctly the description of phase 2 in IKEv2 they DO use the cookies in the header to point to the "phase 1 shared secret". ANd, franky, I still have no clue why people didn't use the KEY-ID or cookie solution? Anyway, this is a somewhat theoretical question, since we are going to change IKE anyway. Hugo > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk > > Sent: Wednesday, November 28, 2001 4:21 PM > > To: Andrew Krywaniuk > > Cc: IPsec WG > > Subject: RE: SOI: identity protection and DOS > > > > > > Andrew, see below for a clarification... > > > > On Tue, 27 Nov 2001, Andrew Krywaniuk wrote: > > > > > > >(e) is only due to a flaw in IKEv1, and is unrelated to the > > > > use of preshared > > > > >keys in general. > > > > > > > > Yup. Some people think that identity protection is > > absolutely needed > > > > in every circumstance, but most people would agree that identity > > > > protection isn't worth preventing pre-shared secrets from working > > > > with mobile users. > > > > > > Well, my point was more that there isn't a conflict between > > preshared keys > > > and identity protection (of the passive variety). If the > > PSK & PKsig SKEYID > > > derivations in IKEv1 had been the same (as they could have > > been), this > > > argument would have never come up. > > > > > > As some may recall, Hugo originally argued that the PKsig > > authentication > > > method was inadequately secure because its strength was > > based solely on the > > > strength of the DH algorithm. The SKEYID for PSK was based > > on the DH value + > > > a secret value. Therefore, the decision to define the > > SKEYID this way was > > > merely a design tradeoff of identity protection for > > increased security. As > > > we noted in draft-improveike (and elsewhere), this tradeoff was not > > > necessary since an alternate SKEYID derivation could have > > given us both > > > properties. > > > > I never said that the sig mode of IKE was inadequately secure. > > I did mention the advantage of pre-shared mode against possible > > break of a DH group in the future. The fact that pre-shared mode is > > (much) better in this sense does not mean that people should consider > > the sig mode "inadequately secure". > > > > Moreover, I already said many times, and "implemented" this idea in my > > P-SIGMA proposal, that the problem of having to rely on the > > IP address for > > identifying the shared-key is easily solvable through > > an ID payload of type ID_KEY_ID (this was also the motivation to > > introduce this type several years ago). > > In P-SIGMA this is done via the OIDi field. > > Using this you get PFS and protection against active attacks > > for BOTH peers (which is impossible to achieve under > > any signature mode). > > > > Actually, even in IKE as it is now, where the OID mechanism > > is missing, > > one could have used the cookies in the header to identify > > shared keys in > > the keys database. Any idea, why people did not do that? > > > > Hugo > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Dec 4 16:08:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB508f224073; Tue, 4 Dec 2001 16:08:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11521 Tue, 4 Dec 2001 17:56:45 -0500 (EST) Date: Wed, 5 Dec 2001 01:06:23 +0200 Message-Id: <200112042306.BAA16872@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: (message from Hugo Krawczyk on Mon, 3 Dec 2001 16:25:44 +0200 (IST)) Subject: Re: compare-jfk-sigma.txt References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmm.. Does JFK do policy or not? A quick read through the draft didn't make it quite clear. Seeing some selector payloads introduced in IKE2, I think this is totally wrong direction. Key negotiation does not need the selectors (and old IKE should not have tried to use id payloads to pass selector/policy type information). If Key negotiation protocol is open for new ideas, I would strongly prefer a key negotiation that only negotiates one directional SA as requested by the kernel side of the IPSEC (in my case, key management is provided with the information about the required SA via PFKEYv2 ACQUIRE message). It does not need to know about selectors, it does not need to know even if the SA is for tunnel or transport mode! Also, note that key management doesn't need care about bundles either! If JFK fullfills this wish, I would be very interested to get implementation into Symbian EPOC OS :-). The kernel side supports functionality of PFKEYv2. -- Markku Savela From owner-ipsec@lists.tislabs.com Tue Dec 4 16:36:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB50aM224609; Tue, 4 Dec 2001 16:36:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11692 Tue, 4 Dec 2001 18:53:09 -0500 (EST) Message-ID: <009201c17d20$7b016900$4a2c12ce@JinME> From: "Jin Zhang" To: "'IPsec WG'" References: <4652644B98DFF34696801F8F3070D3FE01188488@D2CSPEXM001.smartpipes.com> Subject: SA look up Date: Tue, 4 Dec 2001 16:04:59 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C17CDD.6C68AAE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 05 Dec 2001 00:01:34.0967 (UTC) FILETIME=[00D81070:01C17D20] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C17CDD.6C68AAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageHi, there,=20 I know I must be wrong somewhere, please kindly correct me: C 192.168.1.2 / / / / A -----------B 192.168.1.3 192.168.1.1 At site A, there exists policy: >From source (192.168.1.1) to destination (ip minmum 192.168.1.2 to - ip = maximum 192.168.1.10), any src port, any dst port, any prorocol, use = AH-transport mode, and md5-hmac to protect traffic. All the SA selector = uses the value associated with the policy entry. Now if A wants to send message to B, SAs will be negotiated between A = and B, so there will be an outbound SA at site A. Since the selector = value will use the policy entry, the same SA will be used for traffic A = -> C. Now the problem comes, when C receives a packet from A, it looks its own = inbound SA table by looking ), the SA is = NOT there ! The packet will be dropped. And it seems no way to overcome = this, because whenever A wants to send message to C, it will locate a = SA, which is actually negotiated between A and B. Thanks for your help, Jin Zhang Elmic Systems USA ------=_NextPart_000_008F_01C17CDD.6C68AAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi, there,
 
I know I must be wrong somewhere, = please kindly=20 correct me:
 
       C=20 192.168.1.2
      =20 /
      /
    =20 /
    /
   A -----------B =20 192.168.1.3
192.168.1.1
 
At site A, there exists policy:
From = source=20 (192.168.1.1) to destination (ip minmum 192.168.1.2 to - ip maximum=20 192.168.1.10), any src port, any dst port, any prorocol, use = AH-transport mode,=20 and md5-hmac to protect traffic. All the SA selector uses the value = associated=20 with the policy entry.
 
Now if A wants to send message to B, = SAs will be=20 negotiated between A and B, so there will be an outbound SA at site A. = Since the=20 selector value will use the policy entry, the same SA will be used for = traffic A=20 -> C.
 
Now the problem comes, when C receives = a packet=20 from A, it looks its own inbound SA table by looking <dst IP=3D C, = spi,=20 AH-protocol> ), the SA is NOT there ! The packet will be dropped. And = it=20 seems no way to overcome this, because whenever A wants to send message = to C, it=20 will locate a SA, which is actually negotiated between A and = B.
 
Thanks for your help,
 
Jin Zhang
Elmic Systems = USA
------=_NextPart_000_008F_01C17CDD.6C68AAE0-- From owner-ipsec@lists.tislabs.com Tue Dec 4 21:09:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB559b207769; Tue, 4 Dec 2001 21:09:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12238 Tue, 4 Dec 2001 23:08:45 -0500 (EST) Date: Tue, 4 Dec 2001 23:17:50 -0500 From: Ran Canetti Message-Id: <200112050417.XAA40370@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, hugo@ee.technion.ac.il Subject: Re: compare-jfk-sigma.txt Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I actually like that suggestion, and agree that it would nicely merge the good properties of all three protocols. (Note: This is so only if the WG decides that providing ID protection to the initiator against active attacks is not worth the extra signature). I would make one modification though: In messages 3 and 4, I would do the MAC{Ka} on the "outside", instead of doing it under the signature. This way, in one blow you get both the authentication needed for the core security of the protocol, and you protect the encryption against active attacks that can compromise the ID protection (as you pointed out). Remark: Indeed, this is the way IKEv2 does the authentication. But, unlike IKEv2, I would make this an integral part of the protocol rather than invoking ESP. In other words, do: Message 1, I->R: Ni,g^r Message 2, R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKe}(Ni, Nr, g^i, g^r) Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKe}(Ni, Nr, g^i, g^r), E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr)), HMAC{ka}(E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr))) Message 4, R->I: E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa')), HMAC{ka}(E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa'))) (Ka is a key derived from g^ir in the same way as Ke.) BTW, Notice that in the above I included in the signature in message 3. This is needed to prevent an attacker from changing GRPINFOr in msg 2 without this being noticed. (Thanks to Dave Wagner for pointing the problem to us.) Regarding what's included in the cookie and whether to mandate HMAC I agree that this can be more flexible. This is less important for interoperability though so it can be decided later. Ran > > From hugo@ee.technion.ac.il Tue Dec 4 10:25:34 2001 > ... > > If keeping a 4-msg protocol that includes DoS is important to you, I would > recommend the following protocol that combines the JFK structure with > the SIGMA ("Sign-and-MAC") authentication and avoids all the problems > that I pointed out in part B of compare-jfk-sigma.txt, except for the long > input to HMAC (see below). > > Its main accomplishment regarding JFK is the elimination of the > (irritating) SIG(g^r) and its pfs-limitation consequences, > providing R with active protection (as opposed to no protection > in JFK), and providing I with passive protection (as opposed to active > protection in JFK; well, there is no free lunch...) > This id protection is the same as provided by IKEv2. > > The protocol (with some details/optimization to be discussed) goes: > > 1. I->R: Ni, g^i > > 2. R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKr}(Ni, Nr, g^r) > > 3. I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(Ni, Nr, g^r) > E{Ke}(IDi, sa, SIG{i}(MAC{Ka}(0, Nr, Ni, IDi, g^i, g^r, sa)) > > 4. R->I: E{Ke}(IDr, sa', SIG{r}(MAC{Ka}(1, Ni, Nr, IDr, g^r, g^i, sa')) > > All notation is as in JFK, with the key Ka being derived from g^ir in > a similar way to Ke. > > There are some possible optimizations, like not sending g^i in first > message (maybe only a group identifier), but then this is less good > for responders that do not care about DoS. Another one is making the DoS > protection optional for R (just avoids the generation and sending of the > cookie and related stuff). > > One thing that I still do not like here is putting g^r under the cookie > computation: it's long. One could include HASH(g^r) under the > cookie, but this helps performance only when you keep same r for > several sessions. In any case this is "nothing" compared to the > need to compute SIG(g^r)... > > And please, with all my respect to HMAC :), do not specify HMAC as the > ONLY cookie mechansim. You can suggest it, or make it a "SHOULD", but why > mandate something that is a local implementation issue, and for > which other MAC mechansims may work better (e.g. faster)? > > Hugo > > PS: Note that the above protocol is the "ultimate merge" between JFK, > IKEv2, and SIGMA. > Negotiation, phase 2, etc are independent matters and can be dealt with > separately. > > > On Tue, 4 Dec 2001, Ran Canetti wrote: > > > > > Hugo, > > > > I agree with most of the facts in your assessment of JFK vs. SIGMA. > > To sum up, the main technical points seem to be: > > > > In terms of security: > > > > * The "basic security" of both protocols is sound. > > > > * Both protocols allow reuse of the DH exponents in times of high load > > with a similar price in PFS. > > > > * Both protocols offer comparable DOS protection. (What gets included in > > the cookies can be decided upon independently of the rest of the protocol.) > > > > * Both protocols offer identity protection for the initiator against active > > attackers. > > > > * SIGMA offers ID protection for the the receiver against eavesdroppers. > > JFK does not. > > > > > > In terms of performance: > > > > * SIGMA is either 3/5 messages, depending on whether DOS protection is > > turned on. JFK is 4 messages period. > > > > * JFK has an additional signature that, in times of high load, can be > > amotized over many sessions. > > > > > > Now that the main technical differences are clear, it should be easier for > > people to decide which properties are preferable to them. > > > > > > Ran > > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Dec 4 21:12:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB55CI207815; Tue, 4 Dec 2001 21:12:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12263 Tue, 4 Dec 2001 23:34:02 -0500 (EST) Message-Id: <200112050443.XAA29143@bcn.East.Sun.COM> Date: Tue, 4 Dec 2001 23:43:40 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Stephane's Comments on IKEv2 To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xH1ESxKIofICAZtJ15ztXg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re: Stephane's comments about deletes for IKE SAs. To summarize what I think you're asking..., you're asking for something that was in IKEv1, where if I get something from IP address foo with an unknown IKE-SPI, and if I do have an IKE-SA to IP address foo, I send back an authenticated delete for the unknown IKE-SPI on the IKE-SA that I have to IP address foo (on the assumption that maybe it was from a previous incarnation of me). As you said, there are fewer cases where something like this could happen. Also, the INITIAL-CONTACT ought to handle that, and also the Sommerfeld birth certificate could also handle that. And also half open connections will get closed eventually because of periodic reliable pinging and therefore adding another mechanism for getting rid of them seems unnecessary. Thanks! Radia From owner-ipsec@lists.tislabs.com Tue Dec 4 21:23:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB55Nw208534; Tue, 4 Dec 2001 21:23:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12296 Tue, 4 Dec 2001 23:48:18 -0500 (EST) Date: Tue, 4 Dec 2001 23:57:25 -0500 From: Ran Canetti Message-Id: <200112050457.XAA25280@ornavella.watson.ibm.com> To: ekr@rtfm.com Subject: Re: Some comments on JFK Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree - The encryption algorithm(s) in use should be part of the protocol specification. (Indeed, stream ciphers such as RC4 are not appropriate.) BTW, forgot to mention - I agree with your assessment of what goes wrong if the signature in message 4 in JFK is replaced with a MAC. This is exactly why it is there. Ran > From ekr@rtfm.com Tue Dec 4 00:49:08 2001 > > Ran Canetti writes: > > * Regarding different keys for encryption by I and R. This is not really > > necessary if you're using CBC with random IV, or any "decent" encryption > > method. (And, yes, ECB mode is not really "decent" in this context.) > It wouldn't be safe to use RC4, however. IMHO the protocol should either > state what invariants are being assumed or should be constructed to be > safe in the face of a weaker set of invariants. > > Cheers, > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > From owner-ipsec@lists.tislabs.com Wed Dec 5 08:38:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Gcq212321; Wed, 5 Dec 2001 08:38:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22137 Wed, 5 Dec 2001 09:57:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17D9E.340F8F28" Subject: RE: SA look up Date: Wed, 5 Dec 2001 10:04:57 -0500 Message-ID: <675E14B1F51412408D550FF74C036B2614C831@THOREAU.starentnetworks.com> Thread-Topic: SA look up Thread-Index: AcF9MAL7Oc5DxXL0R2WcUCwPkfA6qwAa8fqg From: "Li, Ruicong" To: "Jin Zhang" , "IPsec WG" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C17D9E.340F8F28 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another SA pair must be negotiated if A wants to directly send the IPSec packet to C. But if a Security Gateway is used, all the IPSec packets should be sent to SG, so only one SA pair (A<->SG) is needed to protect all the traffic (A<->B and A<->C). =20 Ruicong Li [Li, Ruicong] -----Original Message----- From: Jin Zhang [mailto:jzhang@elmic.com] Sent: Tuesday, December 04, 2001 7:05 PM To: 'IPsec WG' Subject: SA look up Hi, there,=20 =20 I know I must be wrong somewhere, please kindly correct me: =20 C 192.168.1.2 / / / / A -----------B 192.168.1.3 192.168.1.1 =20 At site A, there exists policy: >From source (192.168.1.1) to destination (ip minmum 192.168.1.2 to - ip maximum 192.168.1.10), any src port, any dst port, any prorocol, use AH-transport mode, and md5-hmac to protect traffic. All the SA selector uses the value associated with the policy entry. =20 Now if A wants to send message to B, SAs will be negotiated between A and B, so there will be an outbound SA at site A. Since the selector value will use the policy entry, the same SA will be used for traffic A -> C. =20 Now the problem comes, when C receives a packet from A, it looks its own inbound SA table by looking ), the SA is NOT there ! The packet will be dropped. And it seems no way to overcome this, because whenever A wants to send message to C, it will locate a SA, which is actually negotiated between A and B. =20 Thanks for your help, =20 Jin Zhang Elmic Systems USA ------_=_NextPart_001_01C17D9E.340F8F28 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Another SA pair must be negotiated if A wants to directly send = the IPSec=20 packet to C. But if a Security Gateway is used, all the IPSec = packets=20 should be sent to SG, so only one SA pair (A<->SG) is needed to = protect=20 all the traffic (A<->B and A<->C).
 
Ruicong Li

[Li, = Ruicong]  -----Original=20 Message-----
From: Jin Zhang = [mailto:jzhang@elmic.com]
Sent:=20 Tuesday, December 04, 2001 7:05 PM
To: 'IPsec = WG'
Subject:=20 SA look up

Hi, there,
 
I know I must be wrong somewhere, = please kindly=20 correct me:
 
       = C=20 192.168.1.2
      =20 /
      /
    =20 /
    /
   A -----------B =20 192.168.1.3
192.168.1.1
 
At site A, there exists = policy:
From source=20 (192.168.1.1) to destination (ip minmum 192.168.1.2 to - ip maximum=20 192.168.1.10), any src port, any dst port, any prorocol, use = AH-transport=20 mode, and md5-hmac to protect traffic. All the SA selector uses the = value=20 associated with the policy entry.
 
Now if A wants to send message to B, = SAs will be=20 negotiated between A and B, so there will be an outbound SA at site A. = Since=20 the selector value will use the policy entry, the same SA will be used = for=20 traffic A -> C.
 
Now the problem comes, when C = receives a packet=20 from A, it looks its own inbound SA table by looking <dst IP=3D C, = spi,=20 AH-protocol> ), the SA is NOT there ! The packet will be dropped. = And it=20 seems no way to overcome this, because whenever A wants to send = message to C,=20 it will locate a SA, which is actually negotiated between A and=20 B.
 
Thanks for your help,
 
Jin Zhang
Elmic Systems=20 USA
------_=_NextPart_001_01C17D9E.340F8F28-- From owner-ipsec@lists.tislabs.com Wed Dec 5 09:17:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5HHM216801; Wed, 5 Dec 2001 09:17:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22821 Wed, 5 Dec 2001 11:28:14 -0500 (EST) To: Hugo Krawczyk Cc: Ran Canetti , ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt References: From: Derek Atkins Date: 05 Dec 2001 11:37:48 -0500 In-Reply-To: Hugo Krawczyk's message of "Tue, 4 Dec 2001 17:25:49 +0200 (IST)" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > Note that the poor initiator cannot amortize the costs of this > signature verification! This is actually a feature for DoS protection -- you want the initiator to do as much if not more work than the responder. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Dec 5 09:30:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5HUl217093; Wed, 5 Dec 2001 09:30:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22855 Wed, 5 Dec 2001 11:48:24 -0500 (EST) To: "Stephane Beaulieu" Cc: "Radia Perlman - Boston Center for Networking" , Subject: Re: Stephane's Comments on IKEv2 References: <200112032039.PAA22522@bcn.East.Sun.COM> <035501c17cce$fd6de730$32c02ca1@cisco.com> From: Derek Atkins Date: 05 Dec 2001 11:58:02 -0500 In-Reply-To: "Stephane Beaulieu"'s message of "Tue, 4 Dec 2001 09:21:39 -0500" Message-ID: Lines: 26 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Stephane Beaulieu" writes: > I'm still not very keen on this "windowing" concept. It seems that the > initiator will have to perform some logic to ensure that it doesn't > overwhelm the responder. In essence, the initiator is doing the responder's > job in managing it's resources. I prefer the model where the initiator > makes requests, and the responder processes as many as he can. Once the > responder is overwhelmed, it starts to ignore requests. The initiator's job > in this case is to ensure that it re-requests the service if it is still > needed, or perhaps attempt a connection with a secondary Gateway which is > hopefully not as busy. As TCP has shown, you want to squelch traffic as close to the source as possible. The fact that the initiator is behaving properly is a Good Thing (TM). However you are correct that the responder should still protect itself from a misbehaving initiator. This doesn't mean that initiators should be free to drown out a responder if they believe they REALLY want that service! ;) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Dec 5 09:48:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Hm8217528; Wed, 5 Dec 2001 09:48:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22882 Wed, 5 Dec 2001 11:59:01 -0500 (EST) Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_SA_look_up?= To: "Jin Zhang" Cc: "'IPsec WG'" , owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Francis Montreuil" Date: Wed, 5 Dec 2001 12:09:07 -0500 X-MIMETrack: Serialize by Router on motus1/Motus Technologies Inc.(Release 5.0.6a |January 17, 2001) at 2001-12-05 12:09:40 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA22879 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Your SP (Security Policy) has address selectors of a range from 192.168.1.2 to 192.168.1.10. When you first communicate with B (192.168.1.3) you "hit" your SP and you negotiate a SA for an address selector of 192.168.1.3. This is, your SAs with B will have an address selector fo a single address. This SA pair cannot be used to communicate with C. Sending more messages to B will hit the SP and use the avalaible SAs to protect the packets. Sending a message to C will hit also hit the SP, but no SA is available (remember that the SA which is there has an address selector to B only), you then have to negotiate it with C for an address selector of 192.168.1.2. You then have 2 SA pairs (Inbound+Outboud) for your single SP. Your SP can have up to 9 SA pairs because of its address selectors. Francis Montreuil Motus Technologies inc. "Jin Zhang" Pour : "'IPsec WG'" Envoyé par : cc : owner-ipsec@lists.t Objet : SA look up islabs.com 04/12/2001 19:04 Hi, there, I know I must be wrong somewhere, please kindly correct me: C 192.168.1.2 / / / / A -----------B 192.168.1.3 192.168.1.1 At site A, there exists policy: >From source (192.168.1.1) to destination (ip minmum 192.168.1.2 to - ip maximum 192.168.1.10), any src port, any dst port, any prorocol, use AH-transport mode, and md5-hmac to protect traffic. All the SA selector uses the value associated with the policy entry. Now if A wants to send message to B, SAs will be negotiated between A and B, so there will be an outbound SA at site A. Since the selector value will use the policy entry, the same SA will be used for traffic A -> C. Now the problem comes, when C receives a packet from A, it looks its own inbound SA table by looking ), the SA is NOT there ! The packet will be dropped. And it seems no way to overcome this, because whenever A wants to send message to C, it will locate a SA, which is actually negotiated between A and B. Thanks for your help, Jin Zhang Elmic Systems USA From owner-ipsec@lists.tislabs.com Wed Dec 5 10:13:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5IDE218339; Wed, 5 Dec 2001 10:13:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22937 Wed, 5 Dec 2001 12:23:59 -0500 (EST) Message-ID: <002101c17db3$433a5980$4a2c12ce@JinME> From: "Jin Zhang" To: "'IPsec WG'" References: Subject: =?iso-8859-1?Q?Re:_R=E9f._:_SA_look_up?= Date: Wed, 5 Dec 2001 09:35:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 05 Dec 2001 17:32:15.0415 (UTC) FILETIME=[C7E10C70:01C17DB2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Francis, Thanks for your answer. And I understand the SA should be generated as in your description if the SP says using the PACKET value. But my problem is using the POLICY value. The RFC 2401 section 4.4.1 has an example, if SP says using the value associated with the POLICY entry, the SA selector will be RANGE OF HOSTS, NOT SINGLE ADDRESS. My understanding is that, besides the selector (in which the destination address could be a range ), we should have another destination address which must be a single address(the peer IP). And when we look up the SA, as RFC 2401 section 5.1.1 step 2, we should not only match the selector destination(could be a RANGE), but also match this single destination address. Then what is the use to use RANGE OF HOSTS in SAD selector, as descriped in RFC 2401 ? still puzzled, Jin ----- Original Message ----- From: "Francis Montreuil" To: "Jin Zhang" Cc: "'IPsec WG'" ; Sent: Wednesday, December 05, 2001 9:09 AM Subject: Réf. : SA look up Your SP (Security Policy) has address selectors of a range from 192.168.1.2 to 192.168.1.10. When you first communicate with B (192.168.1.3) you "hit" your SP and you negotiate a SA for an address selector of 192.168.1.3. This is, your SAs with B will have an address selector fo a single address. This SA pair cannot be used to communicate with C. Sending more messages to B will hit the SP and use the avalaible SAs to protect the packets. Sending a message to C will hit also hit the SP, but no SA is available (remember that the SA which is there has an address selector to B only), you then have to negotiate it with C for an address selector of 192.168.1.2. You then have 2 SA pairs (Inbound+Outboud) for your single SP. Your SP can have up to 9 SA pairs because of its address selectors. Francis Montreuil Motus Technologies inc. "Jin Zhang" Pour : "'IPsec WG'" Envoyé par : cc : owner-ipsec@lists.t Objet : SA look up islabs.com 04/12/2001 19:04 Hi, there, I know I must be wrong somewhere, please kindly correct me: C 192.168.1.2 / / / / A -----------B 192.168.1.3 192.168.1.1 At site A, there exists policy: >From source (192.168.1.1) to destination (ip minmum 192.168.1.2 to - ip maximum 192.168.1.10), any src port, any dst port, any prorocol, use AH-transport mode, and md5-hmac to protect traffic. All the SA selector uses the value associated with the policy entry. Now if A wants to send message to B, SAs will be negotiated between A and B, so there will be an outbound SA at site A. Since the selector value will use the policy entry, the same SA will be used for traffic A -> C. Now the problem comes, when C receives a packet from A, it looks its own inbound SA table by looking ), the SA is NOT there ! The packet will be dropped. And it seems no way to overcome this, because whenever A wants to send message to C, it will locate a SA, which is actually negotiated between A and B. Thanks for your help, Jin Zhang Elmic Systems USA From owner-ipsec@lists.tislabs.com Wed Dec 5 10:28:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5IS0218855; Wed, 5 Dec 2001 10:28:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23016 Wed, 5 Dec 2001 12:45:11 -0500 (EST) Message-Id: <200112051754.fB5HsK570688@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: Comments on IKEv2 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Dec 2001 09:54:20 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In part 2 of our series, I look at IKEv2 :) (1) Criticality. S 2.5 specifies a "Critical" bit. IMHO, experience with PKIX shows that criticality is a rathole. Is there some reason that this is actually necessary? (2) The use of cookies seems pretty confusing. In S. 2.6 you already allow the responder to use an anti-clogging token and then change it's value to be more meaningful. Why not simply make these two different protocol elements. Also, S 2.6 says: To avoid the cookie exchange adding extra messages to the protocol in the common case where the Responder is not under attack, IKEv2 goes back to the approach in Oakley (RFC 2412) where the cookie challenge is optional. Upon receipt of an IKE_SA_init, a Responder may either proceed with setting up the SA or may tell the Initiator to send another IKE_SA_init, this time providing a supplied cookie. Does this mean that if you want anti-clogging protection you need to send 6 messages, not 4? (3) S 2.9 says: The Responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating one or more members of the set of traffic selectors provided the set does not become the NULL set. Can the responder widen the choices? If not, why not? (4) It would be very nice to have a complete diagram of each exchange pretty early in the document. Having it show up one message at a time is pretty hard to read. (5) The proposal section in S 7.3 is, pretty scarey. I understand that some of this is inherited from IKEv1 but I think it may be time for it to go. I'll send a separate message to the list with some thoughts one negotiation but I wanted to mention that this section gave me a headache. I also have a question: under what circumstances would you want to propose an IKE child SA? Is this a normal operation? Have I just missed something? (6) What's the type of the Certificate Authority field in S 7.7? (7) S 7.8 says: The signature MUST be a PKCS#1 encoded signature using the cryptographic hash and signature algorithms chosen by the signer. This is inconsistent with S 3.2 which says that the AUTH payload may contain a DSS signature. PKCS#1 only specifies RSA signatures. You probably want to specify the ASN.1 encoding provided in PKIX. You of course need to require that DSS be used with SHA-1. -Ekr -- [Eric Rescorla ekr@rtfm.com] Author of "SSL and TLS: Designing and Building Secure Systems" http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Dec 5 10:34:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5IYU219070; Wed, 5 Dec 2001 10:34:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23023 Wed, 5 Dec 2001 12:46:25 -0500 (EST) Date: Wed, 5 Dec 2001 19:56:20 +0200 (IST) From: Hugo Krawczyk To: Derek Atkins cc: Ran Canetti , ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt 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 5 Dec 2001, Derek Atkins wrote: > Hugo Krawczyk writes: > > > Note that the poor initiator cannot amortize the costs of this > > signature verification! > > This is actually a feature for DoS protection -- you want the > initiator to do as much if not more work than the responder. > > -derek > Derek, That's a beautiful idea! Let's add 17 such signature verifications to the initiator so to increase DoS protection. There is just a little catch here: the only initiators that need to do this verification are the legitimate ones. The DoS attacker does not need to verify anything! So it's a bug, dear, not a feature... Hugo From owner-ipsec@lists.tislabs.com Wed Dec 5 11:48:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5Jmd222666; Wed, 5 Dec 2001 11:48:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23264 Wed, 5 Dec 2001 13:56:22 -0500 (EST) To: Derek Atkins Cc: Hugo Krawczyk , Ran Canetti , ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt References: Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 05 Dec 2001 11:05:26 -0800 In-Reply-To: Derek Atkins's message of "05 Dec 2001 11:37:48 -0500" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins writes: > Hugo Krawczyk writes: > > > Note that the poor initiator cannot amortize the costs of this > > signature verification! > > This is actually a feature for DoS protection -- you want the > initiator to do as much if not more work than the responder. I don't see that this really works. Attackers can pretty much ignore the server's signature. Legitimate servers don't usually generate bogus signatures on their DH shares :) -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Dec 5 13:25:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5LPi227328; Wed, 5 Dec 2001 13:25:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23578 Wed, 5 Dec 2001 15:23:02 -0500 (EST) To: "Hallam-Baker, Phillip" Cc: "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Selection Criteria? References: <2F3EC696EAEED311BB2D009027C3F4F4058698B0@vhqpostal.verisign.com> From: Derek Atkins Date: 05 Dec 2001 15:32:40 -0500 In-Reply-To: "Hallam-Baker, Phillip"'s message of "Mon, 3 Dec 2001 11:19:26 -0800" Message-ID: Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phill, "Hallam-Baker, Phillip" writes: > 1. Issue every device an IP identity credential bound to its IP address. > This is the ONLY form of identity that can provably prevent any > additional disclosure of identity in an IP environment since your > IP address is known in any case. > > 2. Perform two sequential key agreements, ] > first an IP address based agreement > second an identity based agreement encrypted under the key of (1). > How would you cope with machines with dynamic IP address? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Dec 5 13:29:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5LTS227470; Wed, 5 Dec 2001 13:29:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23571 Wed, 5 Dec 2001 15:19:28 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884A2@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: ipsec@lists.tislabs.com Subject: Please save the pre-shared key mode Date: Wed, 5 Dec 2001 20:27:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17DCB.4EC94190" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17DCB.4EC94190 Content-Type: text/plain I have noticed that pre-shared key has been eliminated in the new key management protocol drafts. I understand the urge to simplify the existing IKE protocol. However, I do think that pre-shared key mode should be left as an option. There are a couple of reasons for that suggestion: 1) Simplicity Pre-shared key mode is simpler to support by eliminating the requirement of supporting complex PKI. Without the pre-shared key mode, are we forcing ourselves into using PKI system (assuming we are not using KINK)? If so, I would like to suggest that the new IKE replacement draft authors add the PSK options. There are many existing deployment of PSK based IPsec VPN and service providers are happy to keep the way it is without using PKI. 2) Cost Running PKI requires additional resources and increase the overall cost of VPN deployment for managed service providers, while end customer sees no increased benefits. If a customer out-sources his VPN and he only cares about site-to-site secure connection, he is probably not willing to choose a more costly PKI based solution. 3) Scalability Although PKI does provide a much better scalability in key delivery, for a managed VPN where each device has a secure channel to the managing server, this advantage is less important. PSK can be generated and provisioned to each box via the management channel to the device easily for a managed VPN, along with other IPsec tunnel parameter settings. Under such a centralized managed VPN, PSK based solution has a good scalability. We have implementations and operational experience that show that an automated VPN management tool has no scalability difficulties managing PSK for each tunnel. Therefore we believe that PSK is a viable choice for VPN implementations and that PSK mode should be saved. ------_=_NextPart_001_01C17DCB.4EC94190 Content-Type: text/html Message
 
I have noticed that pre-shared key has been eliminated in the new key management protocol drafts. I understand the urge to simplify the existing IKE protocol. However, I do think that pre-shared key mode should be left as an option. There are a couple of reasons for that suggestion:
 
1) Simplicity
Pre-shared key mode is simpler to support by eliminating the requirement of supporting complex PKI. Without the pre-shared key mode, are we forcing ourselves into using PKI system  (assuming we are not using KINK)? If so, I would like to suggest that the new IKE replacement draft authors add the PSK options. There are many existing deployment of PSK based IPsec VPN and service providers are happy to keep the way it is without using PKI.
 
2) Cost
Running PKI requires additional resources and increase the overall cost of VPN deployment for managed service providers, while end customer sees no increased benefits. If a customer out-sources his VPN and he only cares about site-to-site secure connection, he is probably not willing to choose a more costly PKI based solution.
 
3) Scalability
Although PKI does provide a much better scalability in key delivery, for a managed VPN where each device has a secure channel to the managing server, this advantage is less important. PSK can be generated and provisioned to each box via the management channel to the device easily for a managed VPN, along with other IPsec tunnel parameter settings. Under such a centralized managed VPN, PSK based solution has a good scalability.
 
We have implementations and operational experience that show that an automated VPN management tool has no scalability difficulties managing PSK for each tunnel.  Therefore we believe that PSK is a viable choice for VPN implementations and that PSK mode should be saved.
 
------_=_NextPart_001_01C17DCB.4EC94190-- From owner-ipsec@lists.tislabs.com Wed Dec 5 14:54:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5MsT202410; Wed, 5 Dec 2001 14:54:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23742 Wed, 5 Dec 2001 17:03:49 -0500 (EST) To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: Re: Comments on IKEv2 References: <200112051242.fB5Cfon01516@fatty.lounge.org> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 05 Dec 2001 14:05:43 -0800 In-Reply-To: Dan Harkins's message of "Wed, 05 Dec 2001 04:41:50 -0800" Message-ID: Lines: 59 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > On Wed, 05 Dec 2001 09:54:20 PST you wrote > > Does this mean that if you want anti-clogging protection you need to > > send 6 messages, not 4? > > Yes. Deployment experience has shown that a box is usually not under > attack and that it would be nice to eliminate the overhead for the > usual (overwhelming majority) case. Yes, that's what I figured. Just making sure I understood. > > (3) S 2.9 says: > > > > The Responder is allowed to narrow the choices by selecting a subset > > of the traffic, for instance by eliminating one or more members of > > the set of traffic selectors provided the set does not become the > > NULL set. > > > > Can the responder widen the choices? If not, why not? > > We want the two sides to converge on the largest intersection of their > policy in the fewest possible number of messages. If the Responder added > things it might be unacceptable to the Initiator and result in more > round trips. Fair enough. > > (5) The proposal section in S 7.3 is, pretty scarey. I understand that > > some of this is inherited from IKEv1 but I think it may be time for it > > to go. I'll send a separate message to the list with some thoughts > > one negotiation but I wanted to mention that this section > > gave me a headache. > > The scariness is inherited from IKEv1. We tried to make it less scary by > eliminating the combinatorial explosion of options that the notion of a > "protection suite" introduced. There was a much simpler version of this > in an early edit but it could not specify the whole range of things this > can and it was abandoned. I think it might be worth reconsidering. I wonder how broad a range people really use in practice. > > (6) What's the type of the Certificate Authority field in S 7.7? > > It's the same as in the "Certificate Data" in S 3.9 of RFC2408. That doesn't seem right: S 7.7 says: The Certificate Request Payload is constructed by setting the "Cert Encoding" field to be the type of certificate being desired and the "Certification Authority" field to a proper encoding of a certification authority for the specified certificate. For example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certification authority acceptable to the sender of this payload. But the Certificate Data is a whole certificate. I think you pretty much need to specify the actual contents in each case. :( -Ekr From owner-ipsec@lists.tislabs.com Wed Dec 5 15:09:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5N9w203304; Wed, 5 Dec 2001 15:09:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23768 Wed, 5 Dec 2001 17:24:01 -0500 (EST) Message-Id: <200112052233.fB5MXB571034@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: Son-of-IKE Performance Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Dec 2001 14:33:11 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As background to the discussion, I thought it might be worth looking at performance of the various IKE replacements. The following table summarizes the performance behavior of the major proposals as far as I can make out. I've also added TLS for comparison. Protocol Initiator Responder Latency ------------------------------------------------ IKEv2 1 signature 1 signature 2 RTT 1 verify 1 verify 1 DH agree 1 DH agree IKEv2 1 signature 1 signature 3 RTT (DoS mode) 1 verify 1 verify 1 DH agree 1 DH agree SIGMA 1 signature 1 signature 1.5 RTT [1] 1 verify 1 verify 1 DH agree 1 DH agree SIGMA 1 signature 1 signature 2.5 RTT [1] (DoS mode) 1 verify 1 verify 1 DH agree 1 DH agree JFK(normal) 1 signature 1 signature 2 RTT 2 verifies 1 verify 1 DH agree 1 DH agree JFK(PFS)[2] 1 signature 2 signatures 2 RTT 2 verifies 1 verify 1 DH agree 1 DH agree TLS (RSA)[3] 1 signature 1 decryption 2 RTT 1 RSA encrypt 1 verify TLS (PFS)[3] 1 signature 1 signature 2 RTT 1 verify 1 verify 1 DH agree 1 DH agree Notes: [0] I'm ignoring the following computational costs since they're more or less constant across protocols and are usually cheap. Digests, symmetric encryption, and PRFs. Certificate verification (not cheap if DSS) All of the PFS modes require an additional g^x mod p. [1] I'm dubious about the value of this. As Phill Hallam-Baker argues, you'd probably want to use a 4-message handshake anyway. [2] In JFK, PFS mode is incompatible with DoS protection. [3] Note that TLS has an anonymous client mode which is even faster: 1 RSA encrypt on the client and 1 RSA decrypt on the server. [4] Here are some approximate timings for the various operations (measured on a Celeron 300). All moduli are 1024-bit. RSA private key op 30 ms RSA public key op 2 ms DH key agree (1024-bit X) 100 ms (256-bit X) 25 ms DSA signature 17 ms DSA verify 21 ms -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Dec 5 15:27:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB5NRL203690; Wed, 5 Dec 2001 15:27:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23809 Wed, 5 Dec 2001 17:43:21 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" , "'IPsec WG'" Subject: RE: IKEv2 and SIGMA Date: Wed, 5 Dec 2001 17:49:41 -0500 Message-ID: <000701c17ddf$214d2f10$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, you have talked about the importance of carefully choosing the inputs to the authentication hash. I envision a situation where: Responder chooses Nr = SIG_r(Ni, g^xi, IDr, ...) Initiator creates AUTHi = SIG_i(Ni, g^xy, Nr, ...) So now the initiator has been tricked into signing something which binds a derivative of the responder's identity to the nonce and DH values from the exchange. And the result is that the initiator can no longer repudiate the exchange. Is this the kind of attack you are talking about? Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed Dec 5 16:03:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB603H205765; Wed, 5 Dec 2001 16:03:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23893 Wed, 5 Dec 2001 18:20:41 -0500 (EST) Date: Thu, 6 Dec 2001 01:30:48 +0200 (IST) From: Hugo Krawczyk To: Eric Rescorla cc: IPsec WG Subject: Re: Son-of-IKE Performance In-Reply-To: <200112052233.fB5MXB571034@romeo.rtfm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric, good summary! One comment about latency and RTT. What you count as latency is the total number of round trips in the protocol. However, note that if you define latency as the time it elapses from the moment the initiator sends its first message until it has an active SA then the numbers in the table change. In particular, SIGMA gets a SINGLE RTT (or two in DoS mode). Now, in relation to SIGMA having an odd number of messages: I am now convinced that an even number is good to preserve an healthy request-response approach. This is easy to obtain in SIGMA: just add a fourth message with an (authenticated) ACK from R to I. So now we have four messages, but the initiator is free to start using its SA (for protecting IPsec traffic) already after sending the third message (i.e after 1 RTT). In most cases, R will have its SA ready when I's IPsec traffic starts arriving. On the other hand, when network conditions call for it, the initiator may wait for the ACK to arrive before sending IPsec traffic. In this case, we have 4 messages in the protocol, we provide a full req/resp design, and yet the initiator has a latency of only 1 RTT until it creates the SA (also R has 1 RTT latency since the time it sends its first message until it creates its SA) If this notion of latency is significant (isn't it?) then SIGMA has a real latency advantage over the other proposals (including my last "merge" proposal). In all these protocols this latency is 2 RTTs for the initiator and 1.5 for responder. Makes sense? Hugo From owner-ipsec@lists.tislabs.com Wed Dec 5 16:09:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB609J206198; Wed, 5 Dec 2001 16:09:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23840 Wed, 5 Dec 2001 18:00:10 -0500 (EST) Date: Thu, 6 Dec 2001 01:10:08 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'IPsec WG'" Subject: RE: IKEv2 and SIGMA In-Reply-To: <000701c17ddf$214d2f10$1e72788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk correct. Even though the initiator, IDi, could still claim that this Nr was sent to him in a convesation with some other party ID' that was colluding with IDr to frame I. Anyway, the point is that there needs to be a real malicious action from the responder to try to leave some provable (to third parties) traces of the conversation. A regular run does not leave any. (And as I said somewhere, if you want better protection than this you should go back to something like the enc mode of IKE :) In contrast, JFK (following the ISO protocol) leaves an explicit undeniable and transferable proof in each exchange. Hugo On Wed, 5 Dec 2001, Andrew Krywaniuk wrote: > Hugo, you have talked about the importance of carefully choosing the inputs > to the authentication hash. I envision a situation where: > > Responder chooses Nr = SIG_r(Ni, g^xi, IDr, ...) > Initiator creates AUTHi = SIG_i(Ni, g^xy, Nr, ...) > > So now the initiator has been tricked into signing something which binds a > derivative of the responder's identity to the nonce and DH values from the > exchange. And the result is that the initiator can no longer repudiate the > exchange. > > Is this the kind of attack you are talking about? > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > From owner-ipsec@lists.tislabs.com Wed Dec 5 16:11:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60B9206392; Wed, 5 Dec 2001 16:11:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23914 Wed, 5 Dec 2001 18:26:48 -0500 (EST) Date: Thu, 6 Dec 2001 01:36:55 +0200 (IST) From: Hugo Krawczyk To: Ran Canetti cc: ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-Reply-To: <200112050417.XAA40370@ornavella.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 4 Dec 2001, Ran Canetti wrote: > > I actually like that suggestion, and agree that it would nicely merge the > good properties of all three protocols. Correct. It takes the proven cryptographic design of SIGMA, the active responder's protection from IKEv2, and the 4-message built-in DoS protection from JFK. > > (Note: This is so only if the WG decides that providing ID protection to > the initiator against active attacks is not worth the extra signature). If you are referring to the extra signature of JFK, then please add to that cost the exposure of the responder's id, the per-exchange signature verification by the initiator, and reduced-pfs for signature-generation amortization. Anyway, if you want to have active initiator's protection you can still avoid all these costs by using adaptive DoS protection (yes it is one more round trip but only when R is under attack). As for WG preferences regarding who should be better protected (against active attacks): it seems that some do not care at all about ID protection, some would prefer to have it adaptive (as happened in both Photuris and IKEv1), other prefer the initiator (especially the client-to-gateway applications), and other prefer the responder (which in my view makes the most sense in a truly peer-to-peer scenario -- as Radia once explained). But overall no one seems totally attached to one of the two approaches. Actually, when I wrote my SIGMA draft I was under the impression that most people would prefer to protect the initiator (especially, Radia in her paper and ipsec presentation in July was very explicit about this and it seemed to have many buyers). So I decided to present the version of SIGMA that protects the initiator (without any "extra signature"). Then it turned out that IKEv2 adopted the responder's protection and no one seemed to care much; this is why I was willing to present this 4-message version of SIGMA (SIGMA-4), as we are discussing now, and which protects the responder from active attacks and the initiator only under passive attackers. > > I would make one modification though: In messages 3 and 4, I would do > the MAC{Ka} on the "outside", instead of doing it > under the signature. This way, in one blow you get both the authentication > needed for the core security of the protocol, and you protect the > encryption against active attacks that can compromise the ID protection > (as you pointed out). This is correct from an analytical point of view, but makes the security of the protocol (and analysis) less robust to changes. For example, one day the encryption may be changed to one that is secure against active attackers but does not use the MAC at all (our proof of security is not "robust" enough to make sure that ALL possible future changes to the encryption specifications will still keep SIGMA's security if you tie its core authentication to the encryption's integrity specification). Therefore, I still prefer two separate MAC's with clearly separated functionalities: one (under the signature) to provide the core key-identities binding, the other (on the ciphertext) for protecting the identities ciphertext from active attacks. For the later functionality, identity protection, using an ESP definition as sugested in IKEv2 makes a lot of sense (but then we need directional Ke/Ka keys). It is important to note that the "cost" of having two MACs is just one extra application of a hash function (such as SHA-1) on a single block. (I can explain this exactly but I prefer not to make this note even longer). In any case, if for any reason the one-MAC approach is adopted, I would still make a change to your description below: In message 3 you send C_i, HMAC{ka}(C_i) where C_i=E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr)) I would recommend sending C_i, HMAC{ka}('0',Nr,IDi,C_i). Here '0' represents the fact that the authentication is from I to R (in the other direction it will be a '1') and helps against reflexion attacks ('0' is not needed if one uses directional Ka keys). IDi is EXPLICITLY included since it is the MOST IMPORTANT piece of information to be included under the MAC; I do NOT want to depend on whether IDi is transported or not in the third message, or whether or not it is encrypted. Putting Nr is to make the freshness guarantee for the MAC explicit. (This is not strictly needed if Ka uses Ni in its derivation, but again I prefer this more conservative and robust approach; it also makes the analysis cleaner.) For the fourth message you will send C_r, HMAC{ka}('0',Ni,IDr,C_r). BTW, if the protocol tranports any addditional information (such as IKE's notifies, etc) they must be authenticated too. > > Remark: Indeed, this is the way IKEv2 does the authentication. But, unlike > IKEv2, I would make this an integral part of the protocol rather than > invoking ESP. You are absolutely right in not relying in ESP for the key-exchange authenticity; but if you have the MAC under the signature (as I still prefer) then you can use ESP for the sake of id protection only. Hugo PS: there is a "cut-and-paste" typo in message 4 in your description: sig{i} instead of sig{r} (IKE suffers to this date from such a "cut-and-paste" typo :) > > In other words, do: > > Message 1, I->R: Ni,g^r > > Message 2, R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKe}(Ni, Nr, g^i, g^r) > > Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKe}(Ni, Nr, g^i, g^r), > E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr)), > HMAC{ka}(E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr))) > > Message 4, R->I: E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa')), > HMAC{ka}(E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa'))) > > (Ka is a key derived from g^ir in the same way as Ke.) > > BTW, Notice that in the above I included in the signature in message 3. > This is needed to prevent an attacker from changing GRPINFOr in msg 2 without > this being noticed. (Thanks to Dave Wagner for pointing the problem to us.) > > > Regarding what's included in the cookie and whether to mandate HMAC > I agree that this can be more flexible. This is less important for > interoperability though so it can be decided later. > > > Ran > > > > > > > From hugo@ee.technion.ac.il Tue Dec 4 10:25:34 2001 > > > ... > > > > If keeping a 4-msg protocol that includes DoS is important to you, I would > > recommend the following protocol that combines the JFK structure with > > the SIGMA ("Sign-and-MAC") authentication and avoids all the problems > > that I pointed out in part B of compare-jfk-sigma.txt, except for the long > > input to HMAC (see below). > > > > Its main accomplishment regarding JFK is the elimination of the > > (irritating) SIG(g^r) and its pfs-limitation consequences, > > providing R with active protection (as opposed to no protection > > in JFK), and providing I with passive protection (as opposed to active > > protection in JFK; well, there is no free lunch...) > > This id protection is the same as provided by IKEv2. > > > > The protocol (with some details/optimization to be discussed) goes: > > > > 1. I->R: Ni, g^i > > > > 2. R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKr}(Ni, Nr, g^r) > > > > 3. I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(Ni, Nr, g^r) > > E{Ke}(IDi, sa, SIG{i}(MAC{Ka}(0, Nr, Ni, IDi, g^i, g^r, sa)) > > > > 4. R->I: E{Ke}(IDr, sa', SIG{r}(MAC{Ka}(1, Ni, Nr, IDr, g^r, g^i, sa')) > > > > All notation is as in JFK, with the key Ka being derived from g^ir in > > a similar way to Ke. > > > > There are some possible optimizations, like not sending g^i in first > > message (maybe only a group identifier), but then this is less good > > for responders that do not care about DoS. Another one is making the DoS > > protection optional for R (just avoids the generation and sending of the > > cookie and related stuff). > > > > One thing that I still do not like here is putting g^r under the cookie > > computation: it's long. One could include HASH(g^r) under the > > cookie, but this helps performance only when you keep same r for > > several sessions. In any case this is "nothing" compared to the > > need to compute SIG(g^r)... > > > > And please, with all my respect to HMAC :), do not specify HMAC as the > > ONLY cookie mechansim. You can suggest it, or make it a "SHOULD", but why > > mandate something that is a local implementation issue, and for > > which other MAC mechansims may work better (e.g. faster)? > > > > Hugo > > > > PS: Note that the above protocol is the "ultimate merge" between JFK, > > IKEv2, and SIGMA. > > Negotiation, phase 2, etc are independent matters and can be dealt with > > separately. > > > > > > On Tue, 4 Dec 2001, Ran Canetti wrote: > > > > > > > > Hugo, > > > > > > I agree with most of the facts in your assessment of JFK vs. SIGMA. > > > To sum up, the main technical points seem to be: > > > > > > In terms of security: > > > > > > * The "basic security" of both protocols is sound. > > > > > > * Both protocols allow reuse of the DH exponents in times of high load > > > with a similar price in PFS. > > > > > > * Both protocols offer comparable DOS protection. (What gets included in > > > the cookies can be decided upon independently of the rest of the protocol.) > > > > > > * Both protocols offer identity protection for the initiator against active > > > attackers. > > > > > > * SIGMA offers ID protection for the the receiver against eavesdroppers. > > > JFK does not. > > > > > > > > > In terms of performance: > > > > > > * SIGMA is either 3/5 messages, depending on whether DOS protection is > > > turned on. JFK is 4 messages period. > > > > > > * JFK has an additional signature that, in times of high load, can be > > > amotized over many sessions. > > > > > > > > > Now that the main technical differences are clear, it should be easier for > > > people to decide which properties are preferable to them. > > > > > > > > > Ran > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Wed Dec 5 16:13:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60DY206603; Wed, 5 Dec 2001 16:13:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23919 Wed, 5 Dec 2001 18:26:53 -0500 (EST) Date: Wed, 5 Dec 2001 15:35:59 -0800 (PST) From: Jan Vilhuber To: Eric Rescorla cc: ipsec@lists.tislabs.com Subject: Re: Comments on IKEv2 In-Reply-To: <200112051754.fB5HsK570688@romeo.rtfm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 5 Dec 2001, Eric Rescorla wrote: > In part 2 of our series, I look at IKEv2 :) > > (1) Criticality. S 2.5 specifies a "Critical" bit. IMHO, experience > with PKIX shows that criticality is a rathole. Is there some reason > that this is actually necessary? > See draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt, section 4, point 1. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 5 16:20:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60K0207074; Wed, 5 Dec 2001 16:20:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23934 Wed, 5 Dec 2001 18:31:56 -0500 (EST) Date: Thu, 6 Dec 2001 01:42:01 +0200 (IST) From: Hugo Krawczyk To: Ran Canetti cc: ekr@rtfm.com, ipsec@lists.tislabs.com Subject: Re: Some comments on JFK In-Reply-To: <200112050457.XAA25280@ornavella.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 4 Dec 2001, Ran Canetti wrote: > > I agree - The encryption algorithm(s) in use should be part of the protocol > specification. (Indeed, stream ciphers such as RC4 are not appropriate.) Do you mean specifically RC4, or any stream cipher? I do not think you need to prohibit the use of stream ciphers for identity protection. You have to define their use correctly (e.g. via directional Ke's). Hugo From owner-ipsec@lists.tislabs.com Wed Dec 5 16:51:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60pJ208370; Wed, 5 Dec 2001 16:51:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24066 Wed, 5 Dec 2001 19:02:18 -0500 (EST) Date: Wed, 5 Dec 2001 16:11:15 -0800 (PST) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: discussion of SIGMA-IKE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't want this to sound the wrong way (but I'm sure it will), but I don't think it's appropriate for this list to be discussing SIGMA-IKE, because it's not an official draft yet. I say this because I've had several people already ask me what this SIGMA-IKE was, and where they can find the draft. If the draft isn't readily available from the IETF web-site, should we be discussing it as a valid contender, if some part of the people on this list can't find it? I realize a link to Hugo's web-site is on the archives somewhere, but I don't call this readily available. Perhaps a daily message where to find it would be OK, but that would seem to set a bad precedent (and be spam for most people). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 5 16:52:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60qG208774; Wed, 5 Dec 2001 16:52:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24105 Wed, 5 Dec 2001 19:06:05 -0500 (EST) To: sommerfeld@east.sun.com Cc: ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance References: <200112060003.fB603jU8014329@thunk.east.sun.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 05 Dec 2001 16:15:13 -0800 In-Reply-To: Bill Sommerfeld's message of "Wed, 05 Dec 2001 19:03:44 -0500" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld writes: > I'd like to see a little more detail on the real impact of the key > exchange on end-to-end latency. Yes, I agree that this would be worthwhile. However, now we're getting into the realm of measurement, not just desk analysis :) This is a little difficult since some (all?) of these protocols are unimplemented. There's also the issue of computational latency and parallelism. I'm afraid this is goign to at least require drawing timelines... Anecdotally, I use Racoon and KAME and I find that it _feels_ pretty terrible. OTOH, it might be misconfigured. > At what point in each exchange can the initiator set up its outbound > SA? Its inbound SA? Likewise for the responder. Hugo brought up this point as well and I'll be looking over the protocols to determine the answer. However, as Jan Vilhuber points out, exactly when you can set up SAs isn't totally clearcut. If anyone wants to offer some answers to these questions to help fill the table I wouldn't complain :) -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Dec 5 16:54:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60s1209314; Wed, 5 Dec 2001 16:54:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24098 Wed, 5 Dec 2001 19:05:17 -0500 (EST) Date: Thu, 6 Dec 2001 02:15:19 +0200 (IST) From: Hugo Krawczyk To: Jan Vilhuber cc: Eric Rescorla , IPsec WG Subject: Re: Son-of-IKE Performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, we are not back to the commit bit. This is why you have the ACK from R to I. I am just saying that an initiator, I, MAY start sending ipsec data after the third message, it does not have to. In any case, I was offering this as a possible feature to be used at the discretion of the initiator. But this is not my area of expertise, so I am really asking for feedback from the experts. Thanks, Hugo On Wed, 5 Dec 2001, Jan Vilhuber wrote: > On Thu, 6 Dec 2001, Hugo Krawczyk wrote: > > > Eric, good summary! > > > > One comment about latency and RTT. > > What you count as latency is the total number of round trips in > > the protocol. However, note that if you define latency > > as the time it elapses from the moment the initiator sends its > > first message until it has an active SA then the numbers in the > > table change. In particular, SIGMA gets a SINGLE RTT (or two in DoS mode). > > > > Now, in relation to SIGMA having an odd number of messages: I am now > > convinced that an even number is good to preserve an healthy > > request-response approach. This is easy to obtain in SIGMA: just add a > > fourth message with an (authenticated) ACK from R to I. So now we have > > four messages, but the initiator is free to start using its SA > > (for protecting IPsec traffic) already after sending the third message > > I disagree. The purpose of the ACK is to tell you that the resonder is now > ready to accept traffic, i.e. the incoming Sa is set up. All the initiator > can do when sending msg3 is start ACCEPTING traffic on an incoming SA. It > can't make any assumptions about the state at the responder. > > > (i.e after 1 RTT). In most cases, R will have its SA ready when I's IPsec > > traffic starts arriving. > > But not in all cases. I would actually claim the reverse. In almost all > cases, data traffic sent by the initiator and key-exchange traffic sent by > the initiator will likely be processed in reverse order due to potential > network packet reordering and processing-paths of data versus control on the > responder (unless you build in a delay between sending msg3 and data traffic, > but that sounds even worse). > > Consider voice traffic, which may have a higher quality of service than the > key-exchange traffic. I can almost guarantee that the encrypted voice traffic > will arrive before your msg3 is even seen... > > Can the responder (and would it be wise to do so) install it's SA's after > sending msg2? > > > On the other hand, when network conditions call > > for it, the initiator may wait for the ACK to arrive before sending IPsec > > traffic. > > > Great. And we're back to all the debates spawned by the commit-bit in quick > mode. > > > > In this case, we have 4 messages in the protocol, we provide a full > > req/resp design, and yet the initiator has a latency of only 1 RTT > > until it creates the SA (also R has 1 RTT latency since the time it > > sends its first message until it creates its SA) > > > > If this notion of latency is significant (isn't it?) then SIGMA > > has a real latency advantage over the other proposals > > If you discount possible data-traffic loss due to the first few data packets > being lost because the responder isn't ready, yes. Otherwise, no. > > I claim that any key exchange protocol with an uneven number of messages is > inherently unstable. The extra packet may cost you to wait an extra > round-trip but buys you a lot of stability and lack of packet loss (there's > enough of that. We don't need to add to it). > > jan > > > > > (including > > my last "merge" proposal). In all these protocols this latency > > is 2 RTTs for the initiator and 1.5 for responder. > > > > Makes sense? > > > > Hugo > > > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > > From owner-ipsec@lists.tislabs.com Wed Dec 5 16:59:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB60wx209846; Wed, 5 Dec 2001 16:58:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24163 Wed, 5 Dec 2001 19:16:50 -0500 (EST) Date: Wed, 5 Dec 2001 16:22:50 -0800 (PST) From: Jan Vilhuber To: Hugo Krawczyk cc: Eric Rescorla , IPsec WG Subject: Re: Son-of-IKE Performance 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, 6 Dec 2001, Hugo Krawczyk wrote: > Jan, we are not back to the commit bit. > This is why you have the ACK from R to I. > Is that a MUST? If not, we ARE back to optional commit-bits. I don't remember seeing an ACK in the 'draft'. > I am just saying that an initiator, I, MAY start sending > ipsec data after the third message, it does not have to. > I would claim that's broken. The draft should state disallow that. At LEAST it should point out all the potential problems this will cause. > In any case, I was offering this as a possible feature > to be used at the discretion of the initiator. > But this is not my area of expertise, so I am really > asking for feedback from the experts. > The exchange needs to have an even number of messages to data packets don't get lost, as they almost certainly will with out the ACK. The ACK MUST not be optional, and traffic MUST NOT be sent by the initiator before the ACK is received. I'm no expert, but the above reflects my experience dealing with live networks and implementing IKE. jan > Thanks, > > Hugo > > On Wed, 5 Dec 2001, Jan Vilhuber wrote: > > > On Thu, 6 Dec 2001, Hugo Krawczyk wrote: > > > > > Eric, good summary! > > > > > > One comment about latency and RTT. > > > What you count as latency is the total number of round trips in > > > the protocol. However, note that if you define latency > > > as the time it elapses from the moment the initiator sends its > > > first message until it has an active SA then the numbers in the > > > table change. In particular, SIGMA gets a SINGLE RTT (or two in DoS mode). > > > > > > Now, in relation to SIGMA having an odd number of messages: I am now > > > convinced that an even number is good to preserve an healthy > > > request-response approach. This is easy to obtain in SIGMA: just add a > > > fourth message with an (authenticated) ACK from R to I. So now we have > > > four messages, but the initiator is free to start using its SA > > > (for protecting IPsec traffic) already after sending the third message > > > > I disagree. The purpose of the ACK is to tell you that the resonder is now > > ready to accept traffic, i.e. the incoming Sa is set up. All the initiator > > can do when sending msg3 is start ACCEPTING traffic on an incoming SA. It > > can't make any assumptions about the state at the responder. > > > > > (i.e after 1 RTT). In most cases, R will have its SA ready when I's IPsec > > > traffic starts arriving. > > > > But not in all cases. I would actually claim the reverse. In almost all > > cases, data traffic sent by the initiator and key-exchange traffic sent by > > the initiator will likely be processed in reverse order due to potential > > network packet reordering and processing-paths of data versus control on the > > responder (unless you build in a delay between sending msg3 and data traffic, > > but that sounds even worse). > > > > Consider voice traffic, which may have a higher quality of service than the > > key-exchange traffic. I can almost guarantee that the encrypted voice traffic > > will arrive before your msg3 is even seen... > > > > Can the responder (and would it be wise to do so) install it's SA's after > > sending msg2? > > > > > On the other hand, when network conditions call > > > for it, the initiator may wait for the ACK to arrive before sending IPsec > > > traffic. > > > > > Great. And we're back to all the debates spawned by the commit-bit in quick > > mode. > > > > > > > In this case, we have 4 messages in the protocol, we provide a full > > > req/resp design, and yet the initiator has a latency of only 1 RTT > > > until it creates the SA (also R has 1 RTT latency since the time it > > > sends its first message until it creates its SA) > > > > > > If this notion of latency is significant (isn't it?) then SIGMA > > > has a real latency advantage over the other proposals > > > > If you discount possible data-traffic loss due to the first few data packets > > being lost because the responder isn't ready, yes. Otherwise, no. > > > > I claim that any key exchange protocol with an uneven number of messages is > > inherently unstable. The extra packet may cost you to wait an extra > > round-trip but buys you a lot of stability and lack of packet loss (there's > > enough of that. We don't need to add to it). > > > > jan > > > > > > > > > (including > > > my last "merge" proposal). In all these protocols this latency > > > is 2 RTTs for the initiator and 1.5 for responder. > > > > > > Makes sense? > > > > > > Hugo > > > > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 5 17:20:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB61Kp211004; Wed, 5 Dec 2001 17:20:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24214 Wed, 5 Dec 2001 19:30:23 -0500 (EST) To: Hugo Krawczyk Cc: Jan Vilhuber , IPsec WG Subject: Re: Son-of-IKE Performance References: Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 05 Dec 2001 16:36:27 -0800 In-Reply-To: Hugo Krawczyk's message of "Thu, 6 Dec 2001 02:15:19 +0200 (IST)" Message-ID: Lines: 45 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > Jan, we are not back to the commit bit. > This is why you have the ACK from R to I. > > I am just saying that an initiator, I, MAY start sending > ipsec data after the third message, it does not have to. > > In any case, I was offering this as a possible feature > to be used at the discretion of the initiator. > But this is not my area of expertise, so I am really > asking for feedback from the experts. It's a clever idea but I suspect too clever :) The problem is that if the first encrypted packet arrives before the responder establishes the SA then the packet will be dropped. This creates pathological conditions. For instance, if the first encrypted packet is a TCP SYN then the retransmit won't happen for 500ms, which is usually greater than 1RTT. Obviously, it's worth taking this chance if it almost never happens in practice, but I think the opposite is true--the first encrypted packet will arrive before the SA is established quite frequently. Jan brings up the point that the key exchange messages and the data messages may be reordered (perhaps due to QoS reasons) but there are implementation reasons to believe that this will be a problem as well. Recall that the SA isn't installed by the responder as soon as message 3 arrives. At the very least certificates and signature have to be verified. Additionally, since the key exchange is typically implemented in some daemon, the data has to be passed up into user space and then the daemon needs to call down to the kernel to set up the SA. This all takes time (possibly 10s of ms for the signature verification alone). Interpacket arrival times on fast networks are often very short and there's a significant probability that even if the data packet arrives after message 3 it will already have been rejected before the new SA is installed. In short, what you propose might be safe under certain circumstances but I suspect that the average case behavior will be worse than just waiting the extra RTT. -Ekr From owner-ipsec@lists.tislabs.com Wed Dec 5 17:48:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB61mn211625; Wed, 5 Dec 2001 17:48:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24029 Wed, 5 Dec 2001 18:54:07 -0500 (EST) Message-Id: <200112060003.fB603jU8014329@thunk.east.sun.com> From: Bill Sommerfeld To: Eric Rescorla cc: ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-Reply-To: Your message of "Wed, 05 Dec 2001 14:33:11 PST." <200112052233.fB5MXB571034@romeo.rtfm.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 05 Dec 2001 19:03:44 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to see a little more detail on the real impact of the key exchange on end-to-end latency. For a very simple example, assume that I want to ping a peer; my policy says "use transport mode", and no SA's are currently active. How much additional latency did we add to the connection setup? At what point in each exchange can the initiator set up its outbound SA? Its inbound SA? Likewise for the responder. - Bill From owner-ipsec@lists.tislabs.com Wed Dec 5 18:12:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB62CO213126; Wed, 5 Dec 2001 18:12:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24490 Wed, 5 Dec 2001 20:26:12 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'EKR'" Cc: Subject: IKEv2 & DoS protection Date: Wed, 5 Dec 2001 20:32:30 -0500 Message-ID: <000d01c17df5$e00184e0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Does this mean that if you want anti-clogging protection > you need to > > > send 6 messages, not 4? > > > > Yes. Deployment experience has shown that a box is usually not under > > attack and that it would be nice to eliminate the overhead for the > > usual (overwhelming majority) case. > Yes, that's what I figured. Just making sure I understood. In disussions related to DoS protection during the last few years, there have been many suggestions for how to do DoS protection: 1. Mandatory stateless cookie exchange (e.g. Photuris) 2. Optional stateless cookie exchange (e.g. Oakley) 3. Random drop 4. STATE payload 5. Repeat payloads from message 1 in message 3 6. (5) with a round-trip optimization (e.g. JFK) All of these work, although (3), which is what you're supposed to do with modern day IKE, has a lot of undesirable properties. (6) is a very clever optimization, and although I am a fan of doing things just because they are cool, I can't help thinking that (2) is the superior approach. When I heard that JFK was going to be state DoS resistant and protect the identity of the initiator in a 4 message exchange, I was initially very skeptical. But they did it, and I congratulate the authors for resolving three seemingly incompatible goals. But I guess the question on my mind is still "Okay, but so what." (6) imposes severe restrictions on the format of the exchange. (2) is just a modular DoS protection mechanism that could be grafted onto any key exchange without degrading average case performance. (2) is a more generic solution, and IMHO that makes it better. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed Dec 5 18:54:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB62ss215656; Wed, 5 Dec 2001 18:54:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24019 Wed, 5 Dec 2001 18:49:10 -0500 (EST) Date: Wed, 5 Dec 2001 15:58:17 -0800 (PST) From: Jan Vilhuber To: Hugo Krawczyk cc: Eric Rescorla , IPsec WG Subject: Re: Son-of-IKE Performance 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, 6 Dec 2001, Hugo Krawczyk wrote: > Eric, good summary! > > One comment about latency and RTT. > What you count as latency is the total number of round trips in > the protocol. However, note that if you define latency > as the time it elapses from the moment the initiator sends its > first message until it has an active SA then the numbers in the > table change. In particular, SIGMA gets a SINGLE RTT (or two in DoS mode). > > Now, in relation to SIGMA having an odd number of messages: I am now > convinced that an even number is good to preserve an healthy > request-response approach. This is easy to obtain in SIGMA: just add a > fourth message with an (authenticated) ACK from R to I. So now we have > four messages, but the initiator is free to start using its SA > (for protecting IPsec traffic) already after sending the third message I disagree. The purpose of the ACK is to tell you that the resonder is now ready to accept traffic, i.e. the incoming Sa is set up. All the initiator can do when sending msg3 is start ACCEPTING traffic on an incoming SA. It can't make any assumptions about the state at the responder. > (i.e after 1 RTT). In most cases, R will have its SA ready when I's IPsec > traffic starts arriving. But not in all cases. I would actually claim the reverse. In almost all cases, data traffic sent by the initiator and key-exchange traffic sent by the initiator will likely be processed in reverse order due to potential network packet reordering and processing-paths of data versus control on the responder (unless you build in a delay between sending msg3 and data traffic, but that sounds even worse). Consider voice traffic, which may have a higher quality of service than the key-exchange traffic. I can almost guarantee that the encrypted voice traffic will arrive before your msg3 is even seen... Can the responder (and would it be wise to do so) install it's SA's after sending msg2? > On the other hand, when network conditions call > for it, the initiator may wait for the ACK to arrive before sending IPsec > traffic. > Great. And we're back to all the debates spawned by the commit-bit in quick mode. > In this case, we have 4 messages in the protocol, we provide a full > req/resp design, and yet the initiator has a latency of only 1 RTT > until it creates the SA (also R has 1 RTT latency since the time it > sends its first message until it creates its SA) > > If this notion of latency is significant (isn't it?) then SIGMA > has a real latency advantage over the other proposals If you discount possible data-traffic loss due to the first few data packets being lost because the responder isn't ready, yes. Otherwise, no. I claim that any key exchange protocol with an uneven number of messages is inherently unstable. The extra packet may cost you to wait an extra round-trip but buys you a lot of stability and lack of packet loss (there's enough of that. We don't need to add to it). jan > (including > my last "merge" proposal). In all these protocols this latency > is 2 RTTs for the initiator and 1.5 for responder. > > Makes sense? > > Hugo > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 5 18:58:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB62wa215722; Wed, 5 Dec 2001 18:58:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24706 Wed, 5 Dec 2001 21:20:46 -0500 (EST) To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: Re: discussion of SIGMA-IKE References: Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 05 Dec 2001 18:29:49 -0800 In-Reply-To: Jan Vilhuber's message of "Wed, 5 Dec 2001 16:11:15 -0800 (PST)" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > I don't want this to sound the wrong way (but I'm sure it will), but I don't > think it's appropriate for this list to be discussing SIGMA-IKE, because it's > not an official draft yet. This doesn't concern me overly. Based on the date on the draft, I assume that Hugo just mised the I-D deadline. It's not like that's never happened to anyone else :) > I say this because I've had several people already ask me what this SIGMA-IKE > was, and where they can find the draft. If the draft isn't readily available > from the IETF web-site, should we be discussing it as a valid contender, if > some part of the people on this list can't find it? I don't see why not. It's not like we're going to make some irrevocable decision on any of this stuff between now and next week. Anyone who truly wants to read it shouldn't have much trouble digging it up. It took me about a minute and a half to find. http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Wed Dec 5 19:48:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB63m9217992; Wed, 5 Dec 2001 19:48:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24837 Wed, 5 Dec 2001 22:08:46 -0500 (EST) Message-Id: <3.0.3.32.20011205192048.00bb2168@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 05 Dec 2001 19:20:48 -0800 To: "Wang, Cliff" , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884A2@D2CSPEXM001.smart pipes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I *strongly* 2nd this motion. It would be extremely foolish to eliminate PSK support. Foolish in this case translates into lots of extra expensive hardware, etc., for our poor customers. Of course software can handle the complexity of key distribution, thus eliminating the supposed advantage of PK v.s. PSK. Cliff, you need to understand the reason why PK is so popular with the IP crowd here. Basically most of the older, influencial developers/architects are very pro-privacy. They grew up in the 60's and 70's during the height of the US Vietnam anti-war protests. PK really fits into their group-think philosphy of distrusting the government or whatever (dispite the fact that in the US, Europe and Japan most governments are very representative of the people). Unfortunately for them, in the real world, IP routing layer infrastructure is owned by corporate or governmental organizations, not by individuals. Therefore privacy is being granted by the organization to the individual in order to use and access network resources owned by that organization. PK does *not* fit this model very well. After all why does an individual need generate a private key to access an organization's computers? Might as well just hand him the private key, therefore PSK works just as well. The pity is that this heavy bias toward PK then blinds these guys and gals to the real problems with PK, primarily that it is **dog slow**, and tends to expand things (to the modulus size) thus making it a pain-in-the-ass to stick into a protocol (especially one that has to go over a slow, noisy wireless link). Basically PK is the crypto world's equivalent of the networking world's ASN.1. It will be with us always whether we like it or not. Ugh. BTW, AtHome made it very clear to me recently that I (or my ISP ATT/TCI) had absolutely no rights to their network computers (like my email inbox on one of their servers). A rather clear demonstration of the fact that my network access is a privilege granted by an organization (in exchange for money in this case), not a right. Therefore using PK for it's secret private key advantage is rather useless. AtHome would have cared less if I used PK or PSK with a VPN to access their email server. - Alex At 08:27 PM 12/5/2001 -0000, Wang, Cliff wrote: > > > I have noticed that pre-shared key has been eliminated in the > new key management protocol drafts. I understand the urge to > simplify the existing IKE protocol. However, I do think that > pre-shared key mode should be left as an option. There are a > couple of reasons for that suggestion: > > 1) Simplicity > Pre-shared key mode is simpler to support by eliminating the > requirement of supporting complex PKI. Without the pre-shared > key mode, are we forcing ourselves into using PKI system > (assuming we are not using KINK)? If so, I would like to suggest > that the new IKE replacement draft authors add the PSK options. > There are many existing deployment of PSK based IPsec VPN and > service providers are happy to keep the way it is without using > PKI. > > 2) Cost > Running PKI requires additional resources and increase the overall > cost of VPN deployment for managed service providers, while end > customer sees no increased benefits. If a customer out-sources his > VPN and he only cares about site-to-site secure connection, he is > probably not willing to choose a more costly PKI based solution. > > 3) Scalability > Although PKI does provide a much better scalability in key delivery, > for a managed VPN where each device has a secure channel to the > managing server, this advantage is less important. PSK can be generated > and provisioned to each box via the management channel to the device > easily for a managed VPN, along with other IPsec tunnel parameter > settings. Under such a centralized managed VPN, PSK based solution has > a good scalability. > > We have implementations and operational experience that show that an > automated VPN management tool has no scalability difficulties managing > PSK for each tunnel. Therefore we believe that PSK is a viable choice > for VPN implementations and that PSK mode should be saved. -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Wed Dec 5 20:43:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB64hj220705; Wed, 5 Dec 2001 20:43:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24968 Wed, 5 Dec 2001 23:03:22 -0500 (EST) Date: Wed, 5 Dec 2001 23:12:17 -0500 (EST) From: Henry Spencer To: Alex Alten cc: "Wang, Cliff" , ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: <3.0.3.32.20011205192048.00bb2168@pop3.netvista.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 5 Dec 2001, Alex Alten wrote: > I *strongly* 2nd this motion. It would be extremely foolish > to eliminate PSK support. Foolish in this case translates into > lots of extra expensive hardware, etc., for our poor customers. You need to be more precise about what you want. Is it preshared key mode in particular, or just some sort of non-PKI mode that does not require extensive infrastructure to get it set up? Don't confuse one with the other; at least some of the new proposals can provide the latter easily even though they do not provide the former. If you believe you specifically need preshared key mode, please explain why in more detail. The need for "lots of extra expensive hardware" has to be justified, not just asserted. Our implementation does both, using the sort of hardware that can be found in dumpsters these days. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Dec 6 02:32:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6AW3220759; Thu, 6 Dec 2001 02:32:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25484 Thu, 6 Dec 2001 03:39:04 -0500 (EST) Date: Thu, 06 Dec 2001 10:47:44 +0200 From: Sara Bitan Subject: Re: Please save the pre-shared key mode To: "Wang, Cliff" , ipsec@lists.tislabs.com, Alex Alten Message-id: <001201c17e32$ad0adf40$4ba6003e@cs.technion.ac.il> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3.0.3.32.20011205192048.00bb2168@pop3.netvista.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well I guess I am the 3rd... - Pre shared keys don't necessarily mean manual installation. Kerberos creates a symmetric shared key between two principals, that can be used as a pre-shared key. There is a whole family of challenge response protocols that supply the parties with a symmetric key that can be used a pre-shared IKE authentication key (.e.g. 3GPP AKA protocol). - There are many market segments that don't want to use public key cryptography for pure efficiency reasons. Are we going to tell these guys : "give up efficiency because PK cryptography is more secure", or are we simply going to say to them "Don't use IKE and IPSec" ? - We've been in this game before. We said "we will not support legacy authentication because it is insecure". Well, the market thought us a lesson, and look where we are today... I don't think we want to see us three years ahead in time with new WGs struggling to integrate pre-shared keys authentication into a framework that wasn't meant to support it. - Integration of pre-shared keys authentication into IKEv2 and IKE-SIGMA is simple. I not that an expert to say if this can be done in JFK, but I think that the new version of IKE must support pre-shared keys authentication. Sara. ----- Original Message ----- From: Alex Alten To: Wang, Cliff ; Sent: Thursday, December 06, 2001 5:20 AM Subject: Re: Please save the pre-shared key mode > > I *strongly* 2nd this motion. It would be extremely foolish > to eliminate PSK support. Foolish in this case translates into > lots of extra expensive hardware, etc., for our poor customers. > > Of course software can handle the complexity of key distribution, > thus eliminating the supposed advantage of PK v.s. PSK. > > Cliff, you need to understand the reason why PK is so popular > with the IP crowd here. Basically most of the older, influencial > developers/architects are very pro-privacy. They grew up in the 60's > and 70's during the height of the US Vietnam anti-war protests. > PK really fits into their group-think philosphy of distrusting the > government or whatever (dispite the fact that in the US, Europe and > Japan most governments are very representative of the people). > > Unfortunately for them, in the real world, IP routing layer > infrastructure is owned by corporate or governmental organizations, > not by individuals. Therefore privacy is being granted by the > organization to the individual in order to use and access network > resources owned by that organization. PK does *not* fit this model > very well. After all why does an individual need generate a private > key to access an organization's computers? Might as well just hand > him the private key, therefore PSK works just as well. > > The pity is that this heavy bias toward PK then blinds these guys > and gals to the real problems with PK, primarily that it is **dog > slow**, and tends to expand things (to the modulus size) thus making > it a pain-in-the-ass to stick into a protocol (especially one that > has to go over a slow, noisy wireless link). Basically PK is > the crypto world's equivalent of the networking world's ASN.1. > It will be with us always whether we like it or not. Ugh. > > BTW, AtHome made it very clear to me recently that I (or my ISP ATT/TCI) > had absolutely no rights to their network computers (like my email inbox > on one of their servers). A rather clear demonstration of the fact > that my network access is a privilege granted by an organization (in > exchange for money in this case), not a right. Therefore using PK for > it's secret private key advantage is rather useless. AtHome would > have cared less if I used PK or PSK with a VPN to access their email > server. > > - Alex > > > > > At 08:27 PM 12/5/2001 -0000, Wang, Cliff wrote: > > > > > > I have noticed that pre-shared key has been eliminated in the > > new key management protocol drafts. I understand the urge to > > simplify the existing IKE protocol. However, I do think that > > pre-shared key mode should be left as an option. There are a > > couple of reasons for that suggestion: > > > > 1) Simplicity > > Pre-shared key mode is simpler to support by eliminating the > > requirement of supporting complex PKI. Without the pre-shared > > key mode, are we forcing ourselves into using PKI system > > (assuming we are not using KINK)? If so, I would like to suggest > > that the new IKE replacement draft authors add the PSK options. > > There are many existing deployment of PSK based IPsec VPN and > > service providers are happy to keep the way it is without using > > PKI. > > > > 2) Cost > > Running PKI requires additional resources and increase the overall > > cost of VPN deployment for managed service providers, while end > > customer sees no increased benefits. If a customer out-sources his > > VPN and he only cares about site-to-site secure connection, he is > > probably not willing to choose a more costly PKI based solution. > > > > 3) Scalability > > Although PKI does provide a much better scalability in key delivery, > > for a managed VPN where each device has a secure channel to the > > managing server, this advantage is less important. PSK can be generated > > and provisioned to each box via the management channel to the device > > easily for a managed VPN, along with other IPsec tunnel parameter > > settings. Under such a centralized managed VPN, PSK based solution has > > a good scalability. > > > > We have implementations and operational experience that show that an > > automated VPN management tool has no scalability difficulties managing > > PSK for each tunnel. Therefore we believe that PSK is a viable choice > > for VPN implementations and that PSK mode should be saved. > > -- > > Alex Alten > Alten@Home.Com > From owner-ipsec@lists.tislabs.com Thu Dec 6 07:38:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6FcZ214873; Thu, 6 Dec 2001 07:38:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00314 Thu, 6 Dec 2001 09:37:40 -0500 (EST) Message-Id: <200112051219.fB5CJDn01472@fatty.lounge.org> To: Markku Savela Cc: ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-Reply-To: Your message of "Wed, 05 Dec 2001 01:06:23 +0200." <200112042306.BAA16872@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1469.1007554753.1@tibernian.com> Date: Wed, 05 Dec 2001 04:19:13 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 05 Dec 2001 01:06:23 +0200 you wrote > > Seeing some selector payloads introduced in IKE2, I think this is > totally wrong direction. Key negotiation does not need the selectors > (and old IKE should not have tried to use id payloads to pass > selector/policy type information). > > If Key negotiation protocol is open for new ideas, I would strongly > prefer a key negotiation that only negotiates one directional SA as > requested by the kernel side of the IPSEC (in my case, key management > is provided with the information about the required SA via PFKEYv2 > ACQUIRE message). It does not need to know about selectors, it does > not need to know even if the SA is for tunnel or transport mode! Also, > note that key management doesn't need care about bundles either! Yes, it does need to know. To do as you suggest would result in undetectable blackholes. In Alice's mind she's going to access 172.21/16 since that's in her SPD. In Bob's mind Alice is only going to be allowed to send TCP traffic to 172.21.74.113/28 since that's in his. If SPD information is not conveyed then Alice's packets that are not TCP to 172.21.74.113/28 will be dropped by Bob and there is no way for Bob to inform her of the problem or for her to figure it out for herself. We've had this discussion before (the last one in person at Nokia Research Center in Helsinki) and I thought it was resolved. If this is more than a religious issue can you explain what problem is caused by having SPD information conveyed during SA establishment? Dan. From owner-ipsec@lists.tislabs.com Thu Dec 6 07:43:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6FhC215347; Thu, 6 Dec 2001 07:43:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00386 Thu, 6 Dec 2001 09:51:01 -0500 (EST) Message-ID: <8B204D152222D51182B70001028841374EF8BC@postmaster.cryptek.com> From: "Welling, Graham" To: "'ipsec@lists.tislabs.com'" Subject: UDP encapsulation of IKE for NAT traversal Date: Thu, 6 Dec 2001 10:12:51 -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 As a newbie to this list I would beg for apologies in advance if this question has been addressed before (I did see a flurry of activity from October of 2000 under the subject "NAT and IPsec" although the issue below was not directly addressed). And please, no screaming flames if this question is answered in one of the RFCs or drafts (although we've read through most of the relevant documents). In implementing NAPT awareness in our IPSec product we have encountered a scenario where it would seem that tunneling of the IKE packets between the peers is necessary if NAT is being used. Consider the following configuration: ------- ------- -------- ------- | | | | | | ------ | | | | | | -------- | | | | | Host |C |IPSec |C | |A | | S| IPSec | S| Host | |Client |----|encryp-|----| NAT |-----|Internet|-----| encryp-|---| Web | | | |tor | | | | | | tor | | Svr | | | | | | | | | | | | | ------- | | | | | | | | ------ | | | | | | | | | | | | -------- | | ------- ------- -------- Assume that there is a security policy known to encryptors C and S allowing ESP tunnel mode traffic between C and S. Assume that the private IP address C *behind* the NAT is translated to public IP address A. Assume following convention for TCP_UDP/IP packet headers: source and destination addresses and ports are written as: src_addr, dest_addr: src_port, dest_port e.g. 1.2.3.4,5.6.7.8:1000,2000 The client (IP address C) wishes to open a session with the web server (IP address S) and sends an IP packet to S as C,S:Pc,80. The IPSec encryptor C detects that there is no SA for the address pair C and S and begins the IKE process by issuing an IKE packet to S. The IKE has IP header C,S:500,500. The NAT translates the source address and source port of the IKE packet as A,S:Pa,500. As a result of the subsequent IKE exchange encryptor C has a SA between C and S, and encryptor S has a SA between A and S (and not C and S). This assumes of course that IP address A was present in the policy database of encryptor S. Herein lies our confusion. Once the IPSec SA is setup between C and S, a HTTP/TCP/IP packet from the web server destined for the client (i.e. S,C:80,Pc) will result in encryptor S not being able to find a SA, since the SA that was established was between A and S. One solution that we are considering is that the IKE/UDP/IP packet itself be encapsulated in UDP so that the original IP addresses and ports are left intact. Looking at draft-ietf-ipsec-nat-t-ike-01.txt it is not clear (at least to us) whether this is the intention or not. Section 4.2 of the draft states: "In case of transport mode both ends SHOULD send the original source address to the other end. For the tunnel mode both ends SHOULD NOT send original source address to the other end." We notice in draft-ietf-ipsec-udp-encaps-01.txt in section 5 headed "Usage with Another Key Management Protocol" that the "...key management packet..." is UDP encapsulated. Does this apply to the standard IKE as well? And does the *key management packet* include the original IP/UDP headers? Other solutions (and some of these are proprietary) are (i) that we use a vendor specific payload in the IKE packet from C to S to inform S of the IP address (as well as the Ethernet address) of C, (ii) that the policy database that resides in S have an entry that relates IP addresses C and S together with the NAT address A (a problem here is if the client C is using DHCP to acquire its IP address - in this case, the policy cannot know the private IP address behind the NAT), and (iii) that encryptor S brute force the received NAT-D hash to try to determine which IP address and port in the policy table initiated the IKE (again, useless for a DHCP host, and problematic due to the possibility of hash collisions). If the entire IKE packet is to be UDP encapsulated then should it *always* tunnel the IKE, or only for those cases where NAT is detected? The discussion from October of last year proposed that two IKE *probes*, regular IKE and NAT-IKE, be sent and then a determination made on which to use based on a response or non-response. However, in the above configuration the transmission of regular IKE would result in a response being received fine, albeit with the knowledge that NAT was present. Any ideas? Graham Welling Cryptek Secure Communications gwelling@cryptek.com From owner-ipsec@lists.tislabs.com Thu Dec 6 07:45:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6FjI215555; Thu, 6 Dec 2001 07:45:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00353 Thu, 6 Dec 2001 09:38:39 -0500 (EST) Message-Id: <200112051242.fB5Cfon01516@fatty.lounge.org> To: Eric Rescorla Cc: ipsec@lists.tislabs.com Subject: Re: Comments on IKEv2 In-Reply-To: Your message of "Wed, 05 Dec 2001 09:54:20 PST." <200112051754.fB5HsK570688@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1513.1007556110.1@tibernian.com> Date: Wed, 05 Dec 2001 04:41:50 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 05 Dec 2001 09:54:20 PST you wrote > In part 2 of our series, I look at IKEv2 :) > > (1) Criticality. S 2.5 specifies a "Critical" bit. IMHO, experience > with PKIX shows that criticality is a rathole. Is there some reason > that this is actually necessary? There was a complaint expressed in the WG that when new payloads are chained onto a message there is no way to tell the recipient whether he should ignore the payload or discard the entire message (containing the payload) if he does not understand the message type. That's what this is for. Coincidentally, this is actually in Cheryl's requirements document. > (2) The use of cookies seems pretty confusing. In S. 2.6 you already > allow the responder to use an anti-clogging token and then change > it's value to be more meaningful. Why not simply make these two > different protocol elements. We went around and around on this. Different protocol elements would make sense. Alternatively it was suggested to not allow the responder to change cookies since the amount of "meaningful"ness the new cookie could have probably won't outweigh the complexity on the protocol. > Also, S 2.6 says: > > To avoid the cookie exchange > adding extra messages to the protocol in the common case where the > Responder is not under attack, IKEv2 goes back to the approach in > Oakley (RFC 2412) where the cookie challenge is optional. Upon > receipt of an IKE_SA_init, a Responder may either proceed with > setting up the SA or may tell the Initiator to send another > IKE_SA_init, this time providing a supplied cookie. > > Does this mean that if you want anti-clogging protection you need to > send 6 messages, not 4? Yes. Deployment experience has shown that a box is usually not under attack and that it would be nice to eliminate the overhead for the usual (overwhelming majority) case. > (3) S 2.9 says: > > The Responder is allowed to narrow the choices by selecting a subset > of the traffic, for instance by eliminating one or more members of > the set of traffic selectors provided the set does not become the > NULL set. > > Can the responder widen the choices? If not, why not? We want the two sides to converge on the largest intersection of their policy in the fewest possible number of messages. If the Responder added things it might be unacceptable to the Initiator and result in more round trips. > (4) It would be very nice to have a complete diagram of each exchange > pretty early in the document. Having it show up one message at a time > is pretty hard to read. OK. > (5) The proposal section in S 7.3 is, pretty scarey. I understand that > some of this is inherited from IKEv1 but I think it may be time for it > to go. I'll send a separate message to the list with some thoughts > one negotiation but I wanted to mention that this section > gave me a headache. The scariness is inherited from IKEv1. We tried to make it less scary by eliminating the combinatorial explosion of options that the notion of a "protection suite" introduced. There was a much simpler version of this in an early edit but it could not specify the whole range of things this can and it was abandoned. > I also have a question: under what circumstances would you want to propose > an IKE child SA? Is this a normal operation? Have I just missed something? If I understand the question, you'd do that to "rekey" the IKE SA. > (6) What's the type of the Certificate Authority field in S 7.7? It's the same as in the "Certificate Data" in S 3.9 of RFC2408. > (7) S 7.8 says: > > The signature MUST > be a PKCS#1 encoded signature using the cryptographic hash and > signature algorithms chosen by the signer. > > This is inconsistent with S 3.2 which says that the AUTH payload may > contain a DSS signature. PKCS#1 only specifies RSA signatures. You > probably want to specify the ASN.1 encoding provided in PKIX. You > of course need to require that DSS be used with SHA-1. Correct. An oversight on my part. Thanks for the comments! Dan. From owner-ipsec@lists.tislabs.com Thu Dec 6 08:26:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6GQo221733; Thu, 6 Dec 2001 08:26:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00663 Thu, 6 Dec 2001 10:35:41 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15375.37461.964246.113250@pkoning.dev.equallogic.com> Date: Thu, 6 Dec 2001 10:44:21 -0500 (EST) From: Paul Koning To: hugo@ee.technion.ac.il Cc: ekr@rtfm.com, ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance References: <200112052233.fB5MXB571034@romeo.rtfm.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> Now, in relation to SIGMA having an odd number of messages: I Hugo> am now convinced that an even number is good to preserve an Hugo> healthy request-response approach. I don't think there is anything inherently valuable in having an even number of packets. Indeed, the opposite is true in some important cases: even though TCP (and other transports) has had a 3-way handshake for decades, for very good and important reasons, people have continued to reinvent broken connection establishment handshakes in transport protocols that use two-way handshakes. (ATM is an example...) The way to decide the correct number of packets is to analyze the protocol and determine what number is needed to obtain the required synchronization. As Jan points out, you have to be careful to distinguish the two endpoints, and the "ready to receive" from the "ready to send" properties. This is where the reinventors of the broken two way handshakes trip up. It may be for a particular protocol that the answer comes out as an even number, but if so, that's because of how that particular protocol is built, not because of any general principle of protocol design that favors evenness. paul From owner-ipsec@lists.tislabs.com Thu Dec 6 09:50:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Ho2225689; Thu, 6 Dec 2001 09:50:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00882 Thu, 6 Dec 2001 11:58:31 -0500 (EST) Reply-To: From: "Alister Yap" To: "Sara Bitan" , "Wang, Cliff" , , "Alex Alten" Subject: RE: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 17:04:04 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <001201c17e32$ad0adf40$4ba6003e@cs.technion.ac.il> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And I fourth that! :-) PSK should be option for now and the future. For now, the obvious reason is interoperability between IPsec and PKI devices. PKI, at the moment, is still too immature a technology. For example, We have found that the implementation of certain standards vary between PKI vendors, IPsec CPE devices and Directory (CRL) infrastructure even though it is supposed to be based on 1 standard! Through much struggle, we have almost got a PKI system issuing certs and CRLs to our IPsec devices. On the other hand, PSK was very simple to use. It took us almost 6 months, numerous support cases and many sleepless nights to get our PKI working with our IPsec devices! In that sense, PSK should be an option for companies looking to go to market quickly and with as little hassle as possible [with the understanding that it is much less secure]. Till PKI fully interworks with IPsec devices, only then should we decide whether to drop PSK or not. Henry Spencer mentioned a non PKI mode. I don't see what benefit that it or how much more secure that is compared with PSK. Could anyone elaborate on that please? Alister > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sara Bitan > Sent: 06 December 2001 08:48 > To: Wang, Cliff; ipsec@lists.tislabs.com; Alex Alten > Subject: Re: Please save the pre-shared key mode > > > Well I guess I am the 3rd... > - Pre shared keys don't necessarily mean manual installation. Kerberos > creates a symmetric shared key between two principals, that can > be used as a > pre-shared key. There is a whole family of challenge response > protocols that > supply the parties with a symmetric key that can be used a pre-shared IKE > authentication key (.e.g. 3GPP AKA protocol). > - There are many market segments that don't want to use public key > cryptography for pure efficiency reasons. Are we going to tell > these guys : > "give up efficiency because PK cryptography is more secure", or are we > simply going to say to them "Don't use IKE and IPSec" ? > - We've been in this game before. We said "we will not support legacy > authentication because it is insecure". Well, the market thought us a > lesson, and look where we are today... I don't think we want to > see us three > years ahead in time with new WGs struggling to integrate pre-shared keys > authentication into a framework that wasn't meant to support it. > - Integration of pre-shared keys authentication into IKEv2 and > IKE-SIGMA is > simple. I not that an expert to say if this can be done in JFK, > but I think > that the new version of IKE must support pre-shared keys authentication. > > Sara. > > ----- Original Message ----- > From: Alex Alten > To: Wang, Cliff ; > Sent: Thursday, December 06, 2001 5:20 AM > Subject: Re: Please save the pre-shared key mode > > > > > > I *strongly* 2nd this motion. It would be extremely foolish > > to eliminate PSK support. Foolish in this case translates into > > lots of extra expensive hardware, etc., for our poor customers. > > > > Of course software can handle the complexity of key distribution, > > thus eliminating the supposed advantage of PK v.s. PSK. > > > > Cliff, you need to understand the reason why PK is so popular > > with the IP crowd here. Basically most of the older, influencial > > developers/architects are very pro-privacy. They grew up in the 60's > > and 70's during the height of the US Vietnam anti-war protests. > > PK really fits into their group-think philosphy of distrusting the > > government or whatever (dispite the fact that in the US, Europe and > > Japan most governments are very representative of the people). > > > > Unfortunately for them, in the real world, IP routing layer > > infrastructure is owned by corporate or governmental organizations, > > not by individuals. Therefore privacy is being granted by the > > organization to the individual in order to use and access network > > resources owned by that organization. PK does *not* fit this model > > very well. After all why does an individual need generate a private > > key to access an organization's computers? Might as well just hand > > him the private key, therefore PSK works just as well. > > > > The pity is that this heavy bias toward PK then blinds these guys > > and gals to the real problems with PK, primarily that it is **dog > > slow**, and tends to expand things (to the modulus size) thus making > > it a pain-in-the-ass to stick into a protocol (especially one that > > has to go over a slow, noisy wireless link). Basically PK is > > the crypto world's equivalent of the networking world's ASN.1. > > It will be with us always whether we like it or not. Ugh. > > > > BTW, AtHome made it very clear to me recently that I (or my ISP ATT/TCI) > > had absolutely no rights to their network computers (like my email inbox > > on one of their servers). A rather clear demonstration of the fact > > that my network access is a privilege granted by an organization (in > > exchange for money in this case), not a right. Therefore using PK for > > it's secret private key advantage is rather useless. AtHome would > > have cared less if I used PK or PSK with a VPN to access their email > > server. > > > > - Alex > > > > > > > > > > At 08:27 PM 12/5/2001 -0000, Wang, Cliff wrote: > > > > > > > > > I have noticed that pre-shared key has been eliminated in the > > > new key management protocol drafts. I understand the urge to > > > simplify the existing IKE protocol. However, I do think that > > > pre-shared key mode should be left as an option. There are a > > > couple of reasons for that suggestion: > > > > > > 1) Simplicity > > > Pre-shared key mode is simpler to support by eliminating the > > > requirement of supporting complex PKI. Without the pre-shared > > > key mode, are we forcing ourselves into using PKI system > > > (assuming we are not using KINK)? If so, I would like to suggest > > > that the new IKE replacement draft authors add the PSK options. > > > There are many existing deployment of PSK based IPsec VPN and > > > service providers are happy to keep the way it is without using > > > PKI. > > > > > > 2) Cost > > > Running PKI requires additional resources and increase the overall > > > cost of VPN deployment for managed service providers, while end > > > customer sees no increased benefits. If a customer out-sources his > > > VPN and he only cares about site-to-site secure connection, he is > > > probably not willing to choose a more costly PKI based solution. > > > > > > 3) Scalability > > > Although PKI does provide a much better scalability in key delivery, > > > for a managed VPN where each device has a secure channel to the > > > managing server, this advantage is less important. PSK can be > generated > > > and provisioned to each box via the management channel to the device > > > easily for a managed VPN, along with other IPsec tunnel parameter > > > settings. Under such a centralized managed VPN, PSK based solution has > > > a good scalability. > > > > > > We have implementations and operational experience that show that an > > > automated VPN management tool has no scalability difficulties managing > > > PSK for each tunnel. Therefore we believe that PSK is a viable choice > > > for VPN implementations and that PSK mode should be saved. > > > > -- > > > > Alex Alten > > Alten@Home.Com > > > > From owner-ipsec@lists.tislabs.com Thu Dec 6 10:22:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6IMb229504; Thu, 6 Dec 2001 10:22:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00965 Thu, 6 Dec 2001 12:34:47 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15375.44556.94153.413374@thomasm-u1.cisco.com> Date: Thu, 6 Dec 2001 09:42:36 -0800 (PST) To: Alex Alten Cc: "Wang, Cliff" , ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: <3.0.3.32.20011205192048.00bb2168@pop3.netvista.net> References: <4652644B98DFF34696801F8F3070D3FE011884A2@D2CSPEXM001.smart pipes.com> <3.0.3.32.20011205192048.00bb2168@pop3.netvista.net> 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 Alex Alten writes: > > I *strongly* 2nd this motion. It would be extremely foolish > to eliminate PSK support. Foolish in this case translates into > lots of extra expensive hardware, etc., for our poor customers. There are already two choices for keying IPsec SA's with pre-shared keys with IETF protocols: 1) IKEv1 2) KINK The latter can be used peer-peer as well, and fixes many of the problems with (1). Why then do we need to have yet another? Mike From owner-ipsec@lists.tislabs.com Thu Dec 6 10:27:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6IRB229883; Thu, 6 Dec 2001 10:27:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01004 Thu, 6 Dec 2001 12:48:15 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884A8@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Michael Thomas'" , Alex Alten Cc: "Wang, Cliff" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 17:57:21 -0000 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 Very simple reasons, IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to be standardized and it is not going to replace IKE. On the other hand, adding PSK support in IKEv2 is not an overkill, but provides much more flexibilities and more choices for service providers. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, December 06, 2001 12:43 PM To: Alex Alten Cc: Wang, Cliff; ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode Alex Alten writes: > > I *strongly* 2nd this motion. It would be extremely foolish > to eliminate PSK support. Foolish in this case translates into > lots of extra expensive hardware, etc., for our poor customers. There are already two choices for keying IPsec SA's with pre-shared keys with IETF protocols: 1) IKEv1 2) KINK The latter can be used peer-peer as well, and fixes many of the problems with (1). Why then do we need to have yet another? Mike From owner-ipsec@lists.tislabs.com Thu Dec 6 10:30:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6IUn200277; Thu, 6 Dec 2001 10:30:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00988 Thu, 6 Dec 2001 12:46:13 -0500 (EST) Message-Id: <200112061755.MAA05209@bcn.East.Sun.COM> Date: Thu, 6 Dec 2001 12:55:47 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IKEv2 & DoS protection To: ekr@rtfm.com, andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WVRXHHYxGk+fPefgP4NmvA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, it's easy to have IKEv2 have a stateless cookie in a 4 message exchange. Dan and Charlie and I argued about it. The way to do a 4 message exchange is to have Alice repeat her info from message 1 in message 3. We mentioned this in our paper, and I believe Ran's proposal also did that. I was actually arguing for that, but the arguments against it were: a) with DDOS, the cookie doesn't help much, so it would be a rare case where it mattered b) assuming the most common From owner-ipsec@lists.tislabs.com Thu Dec 6 10:52:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Iq5201519; Thu, 6 Dec 2001 10:52:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01039 Thu, 6 Dec 2001 12:57:44 -0500 (EST) Message-Id: <200112061807.NAA05328@bcn.East.Sun.COM> Date: Thu, 6 Dec 2001 13:07:23 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: IKEv2 & DoS protection (whoops. resend) To: ekr@rtfm.com, andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: a0MABMzmKtiWbPpTkvvECg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry about that. Somehow my computer assumed I'd said enough already and sent the message I was in the middle of typing. I hate computers. ************************** Actually, it's easy to have IKEv2 have a stateless cookie in a 4 message exchange. Dan and Charlie and I argued about it. The way to do a 4 message exchange is to have Alice repeat her info from message 1 in message 3. We mentioned this in our paper last year, and I believe Ran's proposal also did that. I was actually arguing for that, but the arguments against it were: a) with DDOS, the cookie doesn't help much, so it would be a rare case where it mattered b) assuming the most common case is where Bob doesn't request return of a stateless cookie, the 4-message protocol takes more bandwidth because message 3 is bigger c) we figured people wouldn't care about the extra round trip since at the time we were the only proposal and we figured people would be happy enough with decreasing the number of messages from 9 to usually 4 and occasionally 6. d) it makes the protocol a little harder to read and understand because there are more of these SA,KE, ... thingies to read. So the extra round trip vs a larger message 3 is completely a taste thing, and easy to change if that's what the WG wants. Radia From owner-ipsec@lists.tislabs.com Thu Dec 6 10:52:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6IqB201536; Thu, 6 Dec 2001 10:52:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01033 Thu, 6 Dec 2001 12:57:20 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15375.45988.959181.372324@thomasm-u1.cisco.com> Date: Thu, 6 Dec 2001 10:06:28 -0800 (PST) To: "Wang, Cliff" Cc: "'Michael Thomas'" , Alex Alten , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884A8@D2CSPEXM001.smartpipes.com> References: <4652644B98DFF34696801F8F3070D3FE011884A8@D2CSPEXM001.smartpipes.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 Wang, Cliff writes: > Very simple reasons, > > IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to be > standardized and it is not going to replace IKE. On the other hand, adding > PSK support in IKEv2 is not an overkill, but provides much more > flexibilities and more choices for service providers. KINK is very close to last call, and nobody's claiming that it will replace IKE. And "choice" is not necessarily a good thing. In fact, one of the major lessons of IKEv1 (taken to heart by KINK) was that "choice" is a distinctly *bad* thing. Simplicity and narrow purpose in security protocols is a *feature*, not a bug. Mike From owner-ipsec@lists.tislabs.com Thu Dec 6 11:03:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6J3J202245; Thu, 6 Dec 2001 11:03:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01080 Thu, 6 Dec 2001 13:04:33 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884A9@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Michael Thomas'" Cc: Alex Alten , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 18:13:40 -0000 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 If choice is a bad thing, then I am asking you who set the choice and what criteria is used to set the choice? Are you saying PSK is not a valid choice? Please listen to the field experience where IPsec boxes (lots of them are cisco boxes, :)) are deployed to set up VPNs. I agree with you IKEv1 has too many choices. Based on the smplified IKEv2 draft, adding PSK support won't be bad at all. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, December 06, 2001 1:06 PM To: Wang, Cliff Cc: 'Michael Thomas'; Alex Alten; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Wang, Cliff writes: > Very simple reasons, > > IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to be > standardized and it is not going to replace IKE. On the other hand, adding > PSK support in IKEv2 is not an overkill, but provides much more > flexibilities and more choices for service providers. KINK is very close to last call, and nobody's claiming that it will replace IKE. And "choice" is not necessarily a good thing. In fact, one of the major lessons of IKEv1 (taken to heart by KINK) was that "choice" is a distinctly *bad* thing. Simplicity and narrow purpose in security protocols is a *feature*, not a bug. Mike From owner-ipsec@lists.tislabs.com Thu Dec 6 11:26:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6JQH202895; Thu, 6 Dec 2001 11:26:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01179 Thu, 6 Dec 2001 13:33:09 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3A49@NS-CA> From: Michael Choung Shieh To: "'Wang, Cliff'" , "'Michael Thomas'" , Alex Alten Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 10:41:17 -0800 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 >From our experience more than 80% of VPN users are using PSK. While we are developing a standard to replace IKE v1, let's not leave the existing users behind. Although we may give many reasons that PKI provides more security and scalability, it's (relatively) easy config of PSK bring IKE to wide adoption. -------------------------------------------- Michael Shieh NetScreen Technologies, Inc -------------------------------------------- -----Original Message----- From: Wang, Cliff [mailto:CWang@smartpipes.com] Sent: Thursday, December 06, 2001 9:57 AM To: 'Michael Thomas'; Alex Alten Cc: Wang, Cliff; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Very simple reasons, IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to be standardized and it is not going to replace IKE. On the other hand, adding PSK support in IKEv2 is not an overkill, but provides much more flexibilities and more choices for service providers. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, December 06, 2001 12:43 PM To: Alex Alten Cc: Wang, Cliff; ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode Alex Alten writes: > > I *strongly* 2nd this motion. It would be extremely foolish > to eliminate PSK support. Foolish in this case translates into > lots of extra expensive hardware, etc., for our poor customers. There are already two choices for keying IPsec SA's with pre-shared keys with IETF protocols: 1) IKEv1 2) KINK The latter can be used peer-peer as well, and fixes many of the problems with (1). Why then do we need to have yet another? Mike From owner-ipsec@lists.tislabs.com Thu Dec 6 11:27:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6JR9202923; Thu, 6 Dec 2001 11:27:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01124 Thu, 6 Dec 2001 13:18:01 -0500 (EST) Message-Id: <200112061827.fB6IRfrX007286@kebe.east.sun.com> Subject: Re: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884A2@D2CSPEXM001.smartpipes.com> from "Wang, Cliff" at "Dec 5, 2001 08:27:49 pm" To: "Wang, Cliff" Date: Thu, 6 Dec 2001 13:27:41 -0500 (EST) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 1) Simplicity > Pre-shared key mode is simpler to support by eliminating the requirement of > supporting complex PKI. It's a myth that public-key implies you MUST have a PKI. Self-signed certs combined with explicit out-of-band trust models is just a non-cumbersome as pre-shared keys, IMHO, and they also offer IP-address-portability. (Henry Spencer, correct me if I'm wrong, but FreeSWAN has a self-signed cert model that works, right?) If we keep pre-shared, let's have a scalable way of identifying them. In a multi-homed world (esp. IPv6), pre-shared keys indexed by address pairs is as much hassle as PKI registration (it's just less snake-oil than most PKIs ;). For testing, I run server machines with self-signed certs. For small (10-100) numbers of clients, it works out _quite_ nicely, and w/o any of the PKI cruft. Peer-to-peer explosions is about the only case where PKI is really needed, and pre-shared won't help you any there either. It's just a matter of running certificate-generation, e-mail, and verifying hashes out-of-band. I'm not totally against nuking pre-shared. It's not, however, the panacea of simplicity many think it is, and simplicity arguments don't hold water. Dan From owner-ipsec@lists.tislabs.com Thu Dec 6 11:28:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6JSe202986; Thu, 6 Dec 2001 11:28:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01223 Thu, 6 Dec 2001 13:38:28 -0500 (EST) Message-Id: <200112061847.fB6IlsjM003590@thunk.east.sun.com> From: Bill Sommerfeld To: ipsec@lists.tislabs.com Subject: Please kill preshared key. In-Reply-To: Your message of "Thu, 06 Dec 2001 17:04:04 GMT." Reply-to: sommerfeld@east.sun.com Date: Thu, 06 Dec 2001 13:47:54 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since there are people arguing to save preshared key, I just wanted to reemphasize that: 0) it adds cryptographic complexity -- you essentially need a different cryptographic protocol for PSK vs. signature keys. Let's spend the cycles of our cryptographers on more important stuff than this. 1) it adds YET ONE MORE OPTION you need to test, one more knob you can misconfigure.. more time for customers spent fumbling around trying to figure out how to configure systems. 2) equivalent functionality can be found in preconfigured public keys and/or self-signed certificates. There's no need for it, it adds complexity. Kill it. - Bill From owner-ipsec@lists.tislabs.com Thu Dec 6 11:30:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6JUM203045; Thu, 6 Dec 2001 11:30:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01234 Thu, 6 Dec 2001 13:39:33 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884AA@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Dan McDonald'" Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 18:48:38 -0000 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 While I agree with you that self-signed cert plus out-of-band trust models may be an alternative way to deliver IKE credentials, I would like to see it in a more standardized format and a wider acceptance by the industry. On the other hand, PSK based IKE and PKI based IKE has been the main way people deploying VPN. Under that context, PSK is simpler to run than PKI. -----Original Message----- From: Dan McDonald [mailto:danmcd@east.sun.com] Sent: Thursday, December 06, 2001 1:28 PM To: Wang, Cliff Cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode > 1) Simplicity > Pre-shared key mode is simpler to support by eliminating the > requirement of supporting complex PKI. It's a myth that public-key implies you MUST have a PKI. Self-signed certs combined with explicit out-of-band trust models is just a non-cumbersome as pre-shared keys, IMHO, and they also offer IP-address-portability. (Henry Spencer, correct me if I'm wrong, but FreeSWAN has a self-signed cert model that works, right?) If we keep pre-shared, let's have a scalable way of identifying them. In a multi-homed world (esp. IPv6), pre-shared keys indexed by address pairs is as much hassle as PKI registration (it's just less snake-oil than most PKIs ;). For testing, I run server machines with self-signed certs. For small (10-100) numbers of clients, it works out _quite_ nicely, and w/o any of the PKI cruft. Peer-to-peer explosions is about the only case where PKI is really needed, and pre-shared won't help you any there either. It's just a matter of running certificate-generation, e-mail, and verifying hashes out-of-band. I'm not totally against nuking pre-shared. It's not, however, the panacea of simplicity many think it is, and simplicity arguments don't hold water. Dan From owner-ipsec@lists.tislabs.com Thu Dec 6 11:33:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6JX5203160; Thu, 6 Dec 2001 11:33:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01184 Thu, 6 Dec 2001 13:33:22 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Thu, 06 Dec 2001 11:43:17 -0700 From: "Tolga Acar" To: , Subject: Re: RFC 2628 Implementation ( Crypto API ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You might want to look at the PKCS#11 interface for a standardized Crypto API set. RFC 2628 undermines the inspectibility problem by encapsulating all operations under one API. You might find this limiting in secure systems that must go through certification and/or evaluation. Best, - Tolga >>> "Mahdavi" 12/2/01 3:06:45 >>> Hi. Does any body knows any Implementation of RFC 2628 ( crypto API )? I want to use it for abstracting cryptographic modules of IPSec. Thanks before mahdavi From owner-ipsec@lists.tislabs.com Thu Dec 6 12:52:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6KqC206805; Thu, 6 Dec 2001 12:52:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01486 Thu, 6 Dec 2001 15:09:06 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Radia Perlman - Boston Center for Networking'" Cc: Subject: RE: IKEv2 & DoS protection (whoops. resend) Date: Thu, 6 Dec 2001 15:15:19 -0500 Message-ID: <001201c17e92$bb07a550$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200112061807.NAA05328@bcn.East.Sun.COM> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > So the extra round trip vs a larger message 3 is completely a > taste thing, > and easy to change if that's what the WG wants. My antecedent message was agreeing with the design decision you eventually made, so there's no need to apologize for it. If the goal is to optimize the protocol then optimize the protocol. It would be silly not to take the average case into account. Repeating the info allows a 4 message exchange, I guess (as long as you don't require PFS and you don't accept ad hoc groups), but on average it takes more bandwidth for the same number of round trips. Of course, this pre-supposes a non-anarchistic future, in which everyone is not under DoS attack 24 hours a day... (What I sometimes bitch about is when people propose an optimization to the protocol but they candy-coat it by calling it a simplification... ) Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Radia Perlman - > Boston Center for Networking > Sent: Thursday, December 06, 2001 1:07 PM > To: ekr@rtfm.com; andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: Re: IKEv2 & DoS protection (whoops. resend) > > > Sorry about that. Somehow my computer assumed I'd said enough already > and sent the message I was in the middle of typing. I hate computers. > > > ************************** > Actually, it's easy to have IKEv2 have a stateless cookie in > a 4 message > exchange. Dan and Charlie and I argued about it. The way to > do a 4 message exchange is to have Alice repeat her info from > message 1 in message 3. We mentioned this in our paper last > year, and I > believe Ran's proposal also did that. I was actually arguing for > that, but the arguments against it were: > > a) with DDOS, the cookie doesn't help much, so it would be a rare > case where it mattered > b) assuming the most common case is where Bob doesn't request > return of a stateless cookie, the 4-message protocol takes more > bandwidth because message 3 is bigger > c) we figured people wouldn't care about the extra round trip since > at the time we were the only proposal and we figured people would > be happy enough with decreasing the number of messages from 9 > to usually > 4 and occasionally 6. > d) it makes the protocol a little harder to read and > understand because > there are more of these SA,KE, ... thingies to read. > > So the extra round trip vs a larger message 3 is completely a > taste thing, > and easy to change if that's what the WG wants. > > Radia > > From owner-ipsec@lists.tislabs.com Thu Dec 6 12:57:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6KvJ207148; Thu, 6 Dec 2001 12:57:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01398 Thu, 6 Dec 2001 14:44:00 -0500 (EST) Date: Thu, 6 Dec 2001 21:53:37 +0200 Message-Id: <200112061953.VAA19929@burp.tkv.asdf.org> From: Markku Savela To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200112051219.fB5CJDn01472@fatty.lounge.org> (message from Dan Harkins on Wed, 05 Dec 2001 04:19:13 -0800) Subject: Re: compare-jfk-sigma.txt References: <200112051219.fB5CJDn01472@fatty.lounge.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Dan Harkins > > Yes, it does need to know. To do as you suggest would result in undetectable > blackholes. In Alice's mind she's going to access 172.21/16 since that's > in her SPD. In Bob's mind Alice is only going to be allowed to send TCP > traffic to 172.21.74.113/28 since that's in his. If SPD information is > not conveyed then Alice's packets that are not TCP to 172.21.74.113/28 will > be dropped by Bob and there is no way for Bob to inform her of the problem > or for her to figure it out for herself. What would would happen, only keys are negotiated, is 1. Alice opens TCP connection to 172.21.74.113 (= Bob) 2. Alice KM contacts 172.21.74.113 negotiates one SA (Alice -> Bob), this succeeds, if they have commong algorithms (there is no policy checking!) 3. Alice sends IPSECed packets to Bob (172.21.74.113) 4. Bob receives the packet and packet is checked against the policy (as defined in rfc-2401). My starting point is, that if you want secure communications, the policies must be properly setup, and Alice surely knows that something is wrong on the Bob's end, if negotiation succeeds, but packets don't get processes. Secondly, a difference in selectors does not prevent communication, for example, if Alice: remote = 172.21/16 => use ESP with 3DES Bob: local = 172.21.74.113/28 => use ESP with 3DES there is no problem, Alice negotiates ESP with 3DES, and Bob's policy accepts packets to 172.21.74.113/28. Of course, if Alice sends outside 172.21.74.113/28, then Bob's policy does't allow it in (even through the negotiation of SA succeeds). If detecting the "black hole" situation is that important, I could be solved on other simpler ways, than complicating phase II SA negotiation (for example, if Alice and Bob still have Phase I up, why not just define some informal Notification message, which Bob sends to Alice when it drops packets from Alice). > We've had this discussion before (the last one in person at Nokia > Research Center in Helsinki) and I thought it was resolved. If this > is more than a religious issue can you explain what problem is > caused by having SPD information conveyed during SA establishment? It's not a religious issue, unless you consider having a strong opinion about what is good architecture a religion (it's sometimes close to it... :). Why I don't like the old IKE - RFC 2401 already dictates policy checking pretty thoroughly as mandatory within IPSEC kernel. It's unnecessary to do it in key management. (Similary, bundles and tunnel vs. transport is unnecessary information for the key negotiation). - the "old IKE" could not communicate the "policy" (selectors) properly. - required symmetric SA's - could not share SA's between bundles, for example dst = x, protocol = tcp => use AH+SHA1, ESP+DES3 dst = x, protocol = udp => use AH+SHA1 without IKE limitations, the AH SA could be shared - I'm not expert on judging the old Phase I, but I'm for simplifying (reducing) the phase II negotiation to simple unidirectional SA negotiation at request of kernel (for example, PFKEYv2 ACQUIRE). No policy, nothing else. In the end, I don't have a power to force this. I have just expressed my opinion on this list once in a while. I had already resigned to the reality that IKE is what the IPSEC key management will be, but only brought my view up once again, as I noticed that there might be possibility to get it changed. I will be silent for now, I hope I'm not considered the "Jim Fleming" of this list.. :-) -- Markku Savela From owner-ipsec@lists.tislabs.com Thu Dec 6 12:58:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Kwo207283; Thu, 6 Dec 2001 12:58:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01503 Thu, 6 Dec 2001 15:10:16 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15375.53966.77967.411018@pkoning.dev.equallogic.com> Date: Thu, 6 Dec 2001 15:19:26 -0500 (EST) From: Paul Koning To: CWang@smartpipes.com Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode References: <4652644B98DFF34696801F8F3070D3FE011884A8@D2CSPEXM001.smartpipes.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Wang," == Wang, Cliff writes: Wang,> Very simple reasons, IKEv1 is going to be replaced by IKEv2 in Wang,> the future and KINK has yet to be standardized and it is not Wang,> going to replace IKE. On the other hand, adding PSK support in Wang,> IKEv2 is not an overkill, but provides much more flexibilities Wang,> and more choices for service providers. Agreed. It makes no sense to call a protocol XYZv2 if you're removing from it one of the very widely used features of XYZv1. If you want a protocol without preshared keys, feel free, but then don't call it IKE and don't expect people to give up IKEv1. paul From owner-ipsec@lists.tislabs.com Thu Dec 6 13:26:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6LQQ208082; Thu, 6 Dec 2001 13:26:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01542 Thu, 6 Dec 2001 15:26:37 -0500 (EST) Message-Id: <200112061941.fB6JfOjM004355@thunk.east.sun.com> From: Bill Sommerfeld To: EKR cc: Hugo Krawczyk , Jan Vilhuber , IPsec WG Subject: Re: Son-of-IKE Performance In-Reply-To: Your message of "05 Dec 2001 16:36:27 PST." Reply-to: sommerfeld@east.sun.com Date: Thu, 06 Dec 2001 14:41:24 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The problem is that if the first encrypted packet arrives before the > responder establishes the SA then the packet will be dropped. Not necessarily. Before the sender can send anything on the SA, the receiver needs to have allocated the SPI that the sender will use. The receiver can thus buffer encrypted packets in a "larval" SA until the keying material arrives. Naturally, you need to apply reasonable limits for how much and how long you're willing to buffer, but this is going to be very similar to the buffering typically done while waiting for arp replies.. - Bill From owner-ipsec@lists.tislabs.com Thu Dec 6 13:30:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6LUC208226; Thu, 6 Dec 2001 13:30:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01573 Thu, 6 Dec 2001 15:47:05 -0500 (EST) Date: Thu, 6 Dec 2001 12:55:48 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: EKR , Hugo Krawczyk , IPsec WG Subject: Re: Son-of-IKE Performance In-Reply-To: <200112061941.fB6JfOjM004355@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 On Thu, 6 Dec 2001, Bill Sommerfeld wrote: > > The problem is that if the first encrypted packet arrives before the > > responder establishes the SA then the packet will be dropped. > > Not necessarily. > > Before the sender can send anything on the SA, the receiver needs to > have allocated the SPI that the sender will use. > > The receiver can thus buffer encrypted packets in a "larval" SA until > the keying material arrives. > > Naturally, you need to apply reasonable limits for how much and how > long you're willing to buffer, but this is going to be very similar to > the buffering typically done while waiting for arp replies.. > If you talk from the perspective of a workstation, this may be an option (although it's not one I like). If you start talking about gateways/routers that terminate large numbers of flows, caching packets for a LOT of budding flows just doesn't seem palatable, especially when the solution is so utterly simple: An ack. I believe this is optimizing in the wrong place. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 6 13:38:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Lcf208477; Thu, 6 Dec 2001 13:38:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01619 Thu, 6 Dec 2001 16:00:55 -0500 (EST) Message-ID: From: Joe MacLellan To: ipsec@lists.tislabs.com Subject: RE: Please kill preshared key. Date: Thu, 6 Dec 2001 16:10:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17E9A.627C2110" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17E9A.627C2110 Content-Type: text/plain I agree, IMHO if you want PSK support then use IKEv1. :Later -Joe -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] Sent: Thursday, December 06, 2001 1:48 PM To: ipsec@lists.tislabs.com Subject: Please kill preshared key. Since there are people arguing to save preshared key, I just wanted to reemphasize that: 0) it adds cryptographic complexity -- you essentially need a different cryptographic protocol for PSK vs. signature keys. Let's spend the cycles of our cryptographers on more important stuff than this. 1) it adds YET ONE MORE OPTION you need to test, one more knob you can misconfigure.. more time for customers spent fumbling around trying to figure out how to configure systems. 2) equivalent functionality can be found in preconfigured public keys and/or self-signed certificates. There's no need for it, it adds complexity. Kill it. - Bill ------_=_NextPart_001_01C17E9A.627C2110 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Please kill preshared key.

I agree, IMHO if you want PSK support then use = IKEv1. 

:Later
-Joe

-----Original Message-----
From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com]
Sent: Thursday, December 06, 2001 1:48 PM
To: ipsec@lists.tislabs.com
Subject: Please kill preshared key.


Since there are people arguing to save preshared key, = I just wanted to
reemphasize that:

 0) it adds cryptographic complexity -- you = essentially need a
different cryptographic protocol for PSK vs. = signature keys.  Let's
spend the cycles of our cryptographers on more = important stuff than
this.

 1) it adds YET ONE MORE OPTION you need to = test, one more knob you
can misconfigure.. more time for customers spent = fumbling around
trying to figure out how to configure = systems.

 2) equivalent functionality can be found in = preconfigured public keys
and/or self-signed certificates.

There's no need for it, it adds complexity.  = Kill it.

        =         =         =         =         - Bill

------_=_NextPart_001_01C17E9A.627C2110-- From owner-ipsec@lists.tislabs.com Thu Dec 6 13:38:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Lcx208507; Thu, 6 Dec 2001 13:38:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01594 Thu, 6 Dec 2001 15:57:34 -0500 (EST) Message-ID: <033d01c17e9a$071a1de0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <200112061847.fB6IlsjM003590@thunk.east.sun.com> Subject: Please kill public key Date: Thu, 6 Dec 2001 23:07:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's late night here I'm not at all serious in starting this thread but perhaps this helps us view the situation in a new light... i'm copying some of your text Bill, I hope you don't mind ;-) --- Since there are people arguing to save public key, I just wanted to reemphasize that: 0) it adds cryptographic complexity -- you essentially need a different cryptographic protocol for PSK vs. signature keys. Let's spend the cycles of our cryptographers on more important stuff than this. 1) it adds YET ONE MORE OPTION you need to test, one more knob you can misconfigure.. more time for customers spent fumbling around trying to figure out how to configure systems. 2) equivalent functionality can be found centralized configuration tools. 3) public keys use more CPU 4) according to information posted on this mailing list, 80% of users use preshared secrets. isn't that enough, why bother with the remaining 20% 5) this talk about IKE complexity... please! take a look at the implementations. IKE is propably in the order of 5-10% of the code, while public key and PKI (yes I know it is not mandatory) is nearer 50%. Guess where all the interoperability faults were in the latest bakeoff? 6) IETF hasn't done *anything* on fixing PKI complexity. We're cutting a few options from a protocol, while most IKE experts can't even remember the name of all the PKI protocols and formats they need to support. Where's the IESG ban on adding stuff to X.509 because it was never properly analyzed? There's no need for it, it adds complexity. Kill it. From owner-ipsec@lists.tislabs.com Thu Dec 6 13:48:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Lm0209202; Thu, 6 Dec 2001 13:48:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01638 Thu, 6 Dec 2001 16:07:38 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884B0@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'sommerfeld@east.sun.com'" , ipsec@lists.tislabs.com Subject: RE: Please kill preshared key. Date: Thu, 6 Dec 2001 21:16:49 -0000 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 We are not talking about adding something new. We are talking about whether deleting or saving PSK from IKE. Taking awaying a working feature used by many existing customers may never be a good idea, unless there is a severe security flaw. -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] Sent: Thursday, December 06, 2001 1:48 PM To: ipsec@lists.tislabs.com Subject: Please kill preshared key. Since there are people arguing to save preshared key, I just wanted to reemphasize that: 0) it adds cryptographic complexity -- you essentially need a different cryptographic protocol for PSK vs. signature keys. Let's spend the cycles of our cryptographers on more important stuff than this. 1) it adds YET ONE MORE OPTION you need to test, one more knob you can misconfigure.. more time for customers spent fumbling around trying to figure out how to configure systems. 2) equivalent functionality can be found in preconfigured public keys and/or self-signed certificates. There's no need for it, it adds complexity. Kill it. - Bill From owner-ipsec@lists.tislabs.com Thu Dec 6 13:50:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Lo8209370; Thu, 6 Dec 2001 13:50:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01606 Thu, 6 Dec 2001 16:00:14 -0500 (EST) X-Originating-IP: [172.167.138.127] From: "david chen" To: "Wang, Cliff" , , "Alex Alten" References: <3.0.3.32.20011205192048.00bb2168@pop3.netvista.net> Subject: Re: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 16:10:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 06 Dec 2001 21:09:27.0103 (UTC) FILETIME=[49C894F0:01C17E9A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, I have demo why the Pre-shared public key is better than pre-shared symmetric key. I don't want to repeat myself. However, you mention the social/political issues and 60's & 70's..., I have to remind you that the purpose of secruity and secrecy is to serve the *privacy*. The privacy is individual or a group of individual. The government is... well, a group of individuals. Regardless which side you chose to belong to, "the security is to serve privacy" is always true. Don't see scientific argument, analysis and inference here but religious. --- David ----- Original Message ----- From: "Alex Alten" To: "Wang, Cliff" ; Sent: Wednesday, December 05, 2001 10:20 PM Subject: Re: Please save the pre-shared key mode > > I *strongly* 2nd this motion. It would be extremely foolish > to eliminate PSK support. Foolish in this case translates into > lots of extra expensive hardware, etc., for our poor customers. > > Of course software can handle the complexity of key distribution, > thus eliminating the supposed advantage of PK v.s. PSK. > > Cliff, you need to understand the reason why PK is so popular > with the IP crowd here. Basically most of the older, influencial > developers/architects are very pro-privacy. They grew up in the 60's > and 70's during the height of the US Vietnam anti-war protests. > PK really fits into their group-think philosphy of distrusting the > government or whatever (dispite the fact that in the US, Europe and > Japan most governments are very representative of the people). > > Unfortunately for them, in the real world, IP routing layer > infrastructure is owned by corporate or governmental organizations, > not by individuals. Therefore privacy is being granted by the > organization to the individual in order to use and access network > resources owned by that organization. PK does *not* fit this model > very well. After all why does an individual need generate a private > key to access an organization's computers? Might as well just hand > him the private key, therefore PSK works just as well. > > The pity is that this heavy bias toward PK then blinds these guys > and gals to the real problems with PK, primarily that it is **dog > slow**, and tends to expand things (to the modulus size) thus making > it a pain-in-the-ass to stick into a protocol (especially one that > has to go over a slow, noisy wireless link). Basically PK is > the crypto world's equivalent of the networking world's ASN.1. > It will be with us always whether we like it or not. Ugh. > > BTW, AtHome made it very clear to me recently that I (or my ISP ATT/TCI) > had absolutely no rights to their network computers (like my email inbox > on one of their servers). A rather clear demonstration of the fact > that my network access is a privilege granted by an organization (in > exchange for money in this case), not a right. Therefore using PK for > it's secret private key advantage is rather useless. AtHome would > have cared less if I used PK or PSK with a VPN to access their email > server. > > - Alex > > > > > At 08:27 PM 12/5/2001 -0000, Wang, Cliff wrote: > > > > > > I have noticed that pre-shared key has been eliminated in the > > new key management protocol drafts. I understand the urge to > > simplify the existing IKE protocol. However, I do think that > > pre-shared key mode should be left as an option. There are a > > couple of reasons for that suggestion: > > > > 1) Simplicity > > Pre-shared key mode is simpler to support by eliminating the > > requirement of supporting complex PKI. Without the pre-shared > > key mode, are we forcing ourselves into using PKI system > > (assuming we are not using KINK)? If so, I would like to suggest > > that the new IKE replacement draft authors add the PSK options. > > There are many existing deployment of PSK based IPsec VPN and > > service providers are happy to keep the way it is without using > > PKI. > > > > 2) Cost > > Running PKI requires additional resources and increase the overall > > cost of VPN deployment for managed service providers, while end > > customer sees no increased benefits. If a customer out-sources his > > VPN and he only cares about site-to-site secure connection, he is > > probably not willing to choose a more costly PKI based solution. > > > > 3) Scalability > > Although PKI does provide a much better scalability in key delivery, > > for a managed VPN where each device has a secure channel to the > > managing server, this advantage is less important. PSK can be generated > > and provisioned to each box via the management channel to the device > > easily for a managed VPN, along with other IPsec tunnel parameter > > settings. Under such a centralized managed VPN, PSK based solution has > > a good scalability. > > > > We have implementations and operational experience that show that an > > automated VPN management tool has no scalability difficulties managing > > PSK for each tunnel. Therefore we believe that PSK is a viable choice > > for VPN implementations and that PSK mode should be saved. > > -- > > Alex Alten > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Thu Dec 6 14:30:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6MUs212548; Thu, 6 Dec 2001 14:30:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01697 Thu, 6 Dec 2001 16:48:45 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Michael Choung Shieh" , "'Wang, Cliff'" , "'Michael Thomas'" , "Alex Alten" Cc: References: <9D048F4A422CD411A56500B0D0209C5B028F3A49@NS-CA> Subject: Re: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 16:58:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 06 Dec 2001 21:57:57.0091 (UTC) FILETIME=[10458330:01C17EA1] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The logic goes like this: In the human history, before computer is used for secrecy, we all use paper, hands, eyeballs to achieve privacy. >From our last few thousand years epxerience, they work well; why computer even involes in this? Scientific advancement will help our civilization - not the existing majority experience which is certainly not the reason to stop the advancement. --- David ----- Original Message ----- From: "Michael Choung Shieh" To: "'Wang, Cliff'" ; "'Michael Thomas'" ; "Alex Alten" Cc: Sent: Thursday, December 06, 2001 1:41 PM Subject: RE: Please save the pre-shared key mode > > From our experience more than 80% of VPN users are using PSK. While we are > developing a standard to replace IKE v1, let's not leave the existing users > behind. Although we may give many reasons that PKI provides more security > and scalability, it's (relatively) easy config of PSK bring IKE to wide > adoption. > > -------------------------------------------- > Michael Shieh > NetScreen Technologies, Inc > -------------------------------------------- > > -----Original Message----- > From: Wang, Cliff [mailto:CWang@smartpipes.com] > Sent: Thursday, December 06, 2001 9:57 AM > To: 'Michael Thomas'; Alex Alten > Cc: Wang, Cliff; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > Very simple reasons, > > IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to be > standardized and it is not going to replace IKE. On the other hand, adding > PSK support in IKEv2 is not an overkill, but provides much more > flexibilities and more choices for service providers. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, December 06, 2001 12:43 PM > To: Alex Alten > Cc: Wang, Cliff; ipsec@lists.tislabs.com > Subject: Re: Please save the pre-shared key mode > > > Alex Alten writes: > > > > I *strongly* 2nd this motion. It would be extremely foolish > to > eliminate PSK support. Foolish in this case translates into > lots of > extra expensive hardware, etc., for our poor customers. > > There are already two choices for keying IPsec SA's > with pre-shared keys with IETF protocols: > > 1) IKEv1 > 2) KINK > > The latter can be used peer-peer as well, and > fixes many of the problems with (1). Why then > do we need to have yet another? > > Mike > From owner-ipsec@lists.tislabs.com Thu Dec 6 14:57:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6MvX214505; Thu, 6 Dec 2001 14:57:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01782 Thu, 6 Dec 2001 17:19:53 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: , References: <200112061847.fB6IlsjM003590@thunk.east.sun.com> Subject: Re: Please kill preshared key. Date: Thu, 6 Dec 2001 17:29:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 06 Dec 2001 22:29:03.0895 (UTC) FILETIME=[68F93270:01C17EA5] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agree, IKE is for 'key exchange'. It is *no* needs to change keys in pre-shared key mode. In the pre-share key model, the two devices can just go directly to phase 2 of IPSec. --- David ----- Original Message ----- From: "Bill Sommerfeld" To: Sent: Thursday, December 06, 2001 1:47 PM Subject: Please kill preshared key. > Since there are people arguing to save preshared key, I just wanted to > reemphasize that: > > 0) it adds cryptographic complexity -- you essentially need a > different cryptographic protocol for PSK vs. signature keys. Let's > spend the cycles of our cryptographers on more important stuff than > this. > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > can misconfigure.. more time for customers spent fumbling around > trying to figure out how to configure systems. > > 2) equivalent functionality can be found in preconfigured public keys > and/or self-signed certificates. > > There's no need for it, it adds complexity. Kill it. > > - Bill > From owner-ipsec@lists.tislabs.com Thu Dec 6 15:15:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6NFm215366; Thu, 6 Dec 2001 15:15:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01871 Thu, 6 Dec 2001 17:41:57 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15375.63067.104625.569813@thomasm-u1.cisco.com> Date: Thu, 6 Dec 2001 14:51:07 -0800 (PST) To: Paul Koning Cc: CWang@smartpipes.com, ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <15375.53966.77967.411018@pkoning.dev.equallogic.com> References: <4652644B98DFF34696801F8F3070D3FE011884A8@D2CSPEXM001.smartpipes.com> <15375.53966.77967.411018@pkoning.dev.equallogic.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 Paul Koning writes: > >>>>> "Wang," == Wang, Cliff writes: > > Wang,> Very simple reasons, IKEv1 is going to be replaced by IKEv2 in > Wang,> the future and KINK has yet to be standardized and it is not > Wang,> going to replace IKE. On the other hand, adding PSK support in > Wang,> IKEv2 is not an overkill, but provides much more flexibilities > Wang,> and more choices for service providers. > > Agreed. > > It makes no sense to call a protocol XYZv2 if you're removing from it > one of the very widely used features of XYZv1. > > If you want a protocol without preshared keys, feel free, but then > don't call it IKE and don't expect people to give up IKEv1. The name of protocol is irrelevant at this point. What is of primary importance is the requirements. "IKE" qua IKE is not one of the requirements. What to name that protocol can be decided after it is chosen, especially if people think it's misleading. Mike From owner-ipsec@lists.tislabs.com Thu Dec 6 15:49:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Nn9216252; Thu, 6 Dec 2001 15:49:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01905 Thu, 6 Dec 2001 18:02:20 -0500 (EST) Date: Thu, 6 Dec 2001 18:11:50 -0500 From: Theodore Tso To: Jayant Shukla Cc: ipsec@lists.tislabs.com Subject: Re: LAST CALL: NAT TRAVERSAL DRAFTS Message-ID: <20011206181149.T1848@thunk.org> References: <000001c179bb$4c70f140$9865fea9@TRLSHUKLA1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <000001c179bb$4c70f140$9865fea9@TRLSHUKLA1>; from jshukla@trlokom.com on Tue, Nov 27, 2001 at 09:13:04PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Nov 27, 2001 at 09:13:04PM -0800, Jayant Shukla wrote: > These drafts infringe on our pending patents, specifically the part about transport mode > ESP encapsulation. > > BTW, the original ESP-UDP proposal does not infringe on our IP. The modifications > that were made after the San Diego meeting (where we presented > our proposal) are the problem. Can you say a bit more about specifically which portions of the proposal infringe your pending patents? And did you disclose to the working group that you had patents pending on your proposal when you made your presentation? Many thanks, - Ted From owner-ipsec@lists.tislabs.com Thu Dec 6 15:56:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6Nu3216427; Thu, 6 Dec 2001 15:56:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01981 Thu, 6 Dec 2001 18:22:27 -0500 (EST) Date: Thu, 6 Dec 2001 15:31:30 -0800 (PST) From: Scott Fluhrer To: david chen cc: , Subject: Re: Please kill preshared key. 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, 6 Dec 2001, david chen wrote: > Agree, > > IKE is for 'key exchange'. > It is *no* needs to change keys in pre-shared key mode. > > In the pre-share key model, the two devices can just go directly to phase 2 > of > IPSec. Ummm, no. That's not how preshared keys work in IKEv1, and I don't think anyone is advocating such a feature for SOI/JFK/Whatever. Instead, with PSKs in IKEv1, devices authenticate each other by knowledge of the PSK -- without the PSK, a device is unable to compute the SKEYID, and thus will be unable to complete the final part of the IKE transaction. This means that knowledge of the PSK does not allow an attacker to decrypt a transcript of an IKE session authenticated via that PSK (unless he can solve the DH problem as well). > > --- David > > > > > ----- Original Message ----- > From: "Bill Sommerfeld" > To: > Sent: Thursday, December 06, 2001 1:47 PM > Subject: Please kill preshared key. > > > > Since there are people arguing to save preshared key, I just wanted to > > reemphasize that: > > > > 0) it adds cryptographic complexity -- you essentially need a > > different cryptographic protocol for PSK vs. signature keys. Let's > > spend the cycles of our cryptographers on more important stuff than > > this. > > > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > > can misconfigure.. more time for customers spent fumbling around > > trying to figure out how to configure systems. > > > > 2) equivalent functionality can be found in preconfigured public keys > > and/or self-signed certificates. > > > > There's no need for it, it adds complexity. Kill it. > > > > - Bill > > > From owner-ipsec@lists.tislabs.com Thu Dec 6 15:56:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB6NuU216480; Thu, 6 Dec 2001 15:56:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01975 Thu, 6 Dec 2001 18:22:14 -0500 (EST) Date: Thu, 6 Dec 2001 15:31:24 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. In-Reply-To: <200112061847.fB6IlsjM003590@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 I second that. jan On Thu, 6 Dec 2001, Bill Sommerfeld wrote: > Since there are people arguing to save preshared key, I just wanted to > reemphasize that: > > 0) it adds cryptographic complexity -- you essentially need a > different cryptographic protocol for PSK vs. signature keys. Let's > spend the cycles of our cryptographers on more important stuff than > this. > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > can misconfigure.. more time for customers spent fumbling around > trying to figure out how to configure systems. > > 2) equivalent functionality can be found in preconfigured public keys > and/or self-signed certificates. > > There's no need for it, it adds complexity. Kill it. > > - Bill > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 6 16:02:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7026216631; Thu, 6 Dec 2001 16:02:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02036 Thu, 6 Dec 2001 18:28:18 -0500 (EST) Date: Thu, 6 Dec 2001 15:37:26 -0800 (PST) From: Jan Vilhuber To: Michael Choung Shieh cc: "'Wang, Cliff'" , "'Michael Thomas'" , Alex Alten , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3A49@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 6 Dec 2001, Michael Choung Shieh wrote: > > >From our experience more than 80% of VPN users are using PSK. That's fine. For a user-interface, you can make a public-key system look EXACTLY like a pre-shared symmetric key system (maybe not exactly, but at least as simple). jan > While we are > developing a standard to replace IKE v1, let's not leave the existing users > behind. Although we may give many reasons that PKI provides more security > and scalability, it's (relatively) easy config of PSK bring IKE to wide > adoption. > > -------------------------------------------- > Michael Shieh > NetScreen Technologies, Inc > -------------------------------------------- > > -----Original Message----- > From: Wang, Cliff [mailto:CWang@smartpipes.com] > Sent: Thursday, December 06, 2001 9:57 AM > To: 'Michael Thomas'; Alex Alten > Cc: Wang, Cliff; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > Very simple reasons, > > IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to be > standardized and it is not going to replace IKE. On the other hand, adding > PSK support in IKEv2 is not an overkill, but provides much more > flexibilities and more choices for service providers. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, December 06, 2001 12:43 PM > To: Alex Alten > Cc: Wang, Cliff; ipsec@lists.tislabs.com > Subject: Re: Please save the pre-shared key mode > > > Alex Alten writes: > > > > I *strongly* 2nd this motion. It would be extremely foolish > to > eliminate PSK support. Foolish in this case translates into > lots of > extra expensive hardware, etc., for our poor customers. > > There are already two choices for keying IPsec SA's > with pre-shared keys with IETF protocols: > > 1) IKEv1 > 2) KINK > > The latter can be used peer-peer as well, and > fixes many of the problems with (1). Why then > do we need to have yet another? > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 6 16:08:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB708F216773; Thu, 6 Dec 2001 16:08:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02007 Thu, 6 Dec 2001 18:25:49 -0500 (EST) Date: Thu, 6 Dec 2001 15:34:47 -0800 (PST) From: Jan Vilhuber To: Alister Yap cc: Sara Bitan , "Wang, Cliff" , ipsec@lists.tislabs.com, Alex Alten Subject: RE: Please save the pre-shared key mode 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, 6 Dec 2001, Alister Yap wrote: > And I fourth that! :-) > > PSK should be option for now and the future. For now, the obvious reason is > interoperability between IPsec and PKI devices. PKI, at the moment, is still > too immature a technology. For example, We have found that the > implementation of certain standards vary between PKI vendors, IPsec CPE > devices and Directory (CRL) infrastructure even though it is supposed to be > based on 1 standard! > > Through much struggle, we have almost got a PKI system issuing certs and > CRLs to our IPsec devices. On the other hand, PSK was very simple to use. It > took us almost 6 months, numerous support cases and many sleepless nights to > get our PKI working with our IPsec devices! In that sense, PSK should be an > option for companies looking to go to market quickly and with as little > hassle as possible [with the understanding that it is much less secure]. > > Till PKI fully interworks with IPsec devices, only then should we decide > whether to drop PSK or not. > There are multiple ways of rolling out a pki, PKI, or PKi (yes, they are all different ;). They don't have to be PKIX-complex (is that a superset of NP-complete?). You can do it MUCH simpler, and still secure, and not need pre-shared symmetric keys. Use a pre-shared self-signed certificate, or pre-share the md5-signature of the key, and send it SSH style. There's simply no reason to have pre-shared symmetric keys. jan > Henry Spencer mentioned a non PKI mode. I don't see what benefit that it or > how much more secure that is compared with PSK. Could anyone elaborate on > that please? > > Alister > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sara Bitan > > Sent: 06 December 2001 08:48 > > To: Wang, Cliff; ipsec@lists.tislabs.com; Alex Alten > > Subject: Re: Please save the pre-shared key mode > > > > > > Well I guess I am the 3rd... > > - Pre shared keys don't necessarily mean manual installation. Kerberos > > creates a symmetric shared key between two principals, that can > > be used as a > > pre-shared key. There is a whole family of challenge response > > protocols that > > supply the parties with a symmetric key that can be used a pre-shared IKE > > authentication key (.e.g. 3GPP AKA protocol). > > - There are many market segments that don't want to use public key > > cryptography for pure efficiency reasons. Are we going to tell > > these guys : > > "give up efficiency because PK cryptography is more secure", or are we > > simply going to say to them "Don't use IKE and IPSec" ? > > - We've been in this game before. We said "we will not support legacy > > authentication because it is insecure". Well, the market thought us a > > lesson, and look where we are today... I don't think we want to > > see us three > > years ahead in time with new WGs struggling to integrate pre-shared keys > > authentication into a framework that wasn't meant to support it. > > - Integration of pre-shared keys authentication into IKEv2 and > > IKE-SIGMA is > > simple. I not that an expert to say if this can be done in JFK, > > but I think > > that the new version of IKE must support pre-shared keys authentication. > > > > Sara. > > > > ----- Original Message ----- > > From: Alex Alten > > To: Wang, Cliff ; > > Sent: Thursday, December 06, 2001 5:20 AM > > Subject: Re: Please save the pre-shared key mode > > > > > > > > > > I *strongly* 2nd this motion. It would be extremely foolish > > > to eliminate PSK support. Foolish in this case translates into > > > lots of extra expensive hardware, etc., for our poor customers. > > > > > > Of course software can handle the complexity of key distribution, > > > thus eliminating the supposed advantage of PK v.s. PSK. > > > > > > Cliff, you need to understand the reason why PK is so popular > > > with the IP crowd here. Basically most of the older, influencial > > > developers/architects are very pro-privacy. They grew up in the 60's > > > and 70's during the height of the US Vietnam anti-war protests. > > > PK really fits into their group-think philosphy of distrusting the > > > government or whatever (dispite the fact that in the US, Europe and > > > Japan most governments are very representative of the people). > > > > > > Unfortunately for them, in the real world, IP routing layer > > > infrastructure is owned by corporate or governmental organizations, > > > not by individuals. Therefore privacy is being granted by the > > > organization to the individual in order to use and access network > > > resources owned by that organization. PK does *not* fit this model > > > very well. After all why does an individual need generate a private > > > key to access an organization's computers? Might as well just hand > > > him the private key, therefore PSK works just as well. > > > > > > The pity is that this heavy bias toward PK then blinds these guys > > > and gals to the real problems with PK, primarily that it is **dog > > > slow**, and tends to expand things (to the modulus size) thus making > > > it a pain-in-the-ass to stick into a protocol (especially one that > > > has to go over a slow, noisy wireless link). Basically PK is > > > the crypto world's equivalent of the networking world's ASN.1. > > > It will be with us always whether we like it or not. Ugh. > > > > > > BTW, AtHome made it very clear to me recently that I (or my ISP ATT/TCI) > > > had absolutely no rights to their network computers (like my email inbox > > > on one of their servers). A rather clear demonstration of the fact > > > that my network access is a privilege granted by an organization (in > > > exchange for money in this case), not a right. Therefore using PK for > > > it's secret private key advantage is rather useless. AtHome would > > > have cared less if I used PK or PSK with a VPN to access their email > > > server. > > > > > > - Alex > > > > > > > > > > > > > > > At 08:27 PM 12/5/2001 -0000, Wang, Cliff wrote: > > > > > > > > > > > > I have noticed that pre-shared key has been eliminated in the > > > > new key management protocol drafts. I understand the urge to > > > > simplify the existing IKE protocol. However, I do think that > > > > pre-shared key mode should be left as an option. There are a > > > > couple of reasons for that suggestion: > > > > > > > > 1) Simplicity > > > > Pre-shared key mode is simpler to support by eliminating the > > > > requirement of supporting complex PKI. Without the pre-shared > > > > key mode, are we forcing ourselves into using PKI system > > > > (assuming we are not using KINK)? If so, I would like to suggest > > > > that the new IKE replacement draft authors add the PSK options. > > > > There are many existing deployment of PSK based IPsec VPN and > > > > service providers are happy to keep the way it is without using > > > > PKI. > > > > > > > > 2) Cost > > > > Running PKI requires additional resources and increase the overall > > > > cost of VPN deployment for managed service providers, while end > > > > customer sees no increased benefits. If a customer out-sources his > > > > VPN and he only cares about site-to-site secure connection, he is > > > > probably not willing to choose a more costly PKI based solution. > > > > > > > > 3) Scalability > > > > Although PKI does provide a much better scalability in key delivery, > > > > for a managed VPN where each device has a secure channel to the > > > > managing server, this advantage is less important. PSK can be > > generated > > > > and provisioned to each box via the management channel to the device > > > > easily for a managed VPN, along with other IPsec tunnel parameter > > > > settings. Under such a centralized managed VPN, PSK based solution has > > > > a good scalability. > > > > > > > > We have implementations and operational experience that show that an > > > > automated VPN management tool has no scalability difficulties managing > > > > PSK for each tunnel. Therefore we believe that PSK is a viable choice > > > > for VPN implementations and that PSK mode should be saved. > > > > > > -- > > > > > > Alex Alten > > > Alten@Home.Com > > > > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 6 16:23:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB70Nk217489; Thu, 6 Dec 2001 16:23:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02058 Thu, 6 Dec 2001 18:29:40 -0500 (EST) Date: Thu, 6 Dec 2001 15:38:44 -0800 (PST) From: Jan Vilhuber To: "Wang, Cliff" cc: "'Dan McDonald'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884AA@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 6 Dec 2001, Wang, Cliff wrote: > While I agree with you that self-signed cert plus out-of-band trust models > may be an alternative way to deliver IKE credentials, I would like to see it > in a more standardized format and a wider acceptance by the industry. Good idea. So let's expend out energy on that, instead of adding pre-shared symmetric keys to protocols. > On the > other hand, PSK based IKE and PKI based IKE has been the main way people > deploying VPN. Under that context, PSK is simpler to run than PKI. > I think that's the myth Dan was talking about. jan > > -----Original Message----- > From: Dan McDonald [mailto:danmcd@east.sun.com] > Sent: Thursday, December 06, 2001 1:28 PM > To: Wang, Cliff > Cc: ipsec@lists.tislabs.com > Subject: Re: Please save the pre-shared key mode > > > > 1) Simplicity > > Pre-shared key mode is simpler to support by eliminating the > > requirement of supporting complex PKI. > > It's a myth that public-key implies you MUST have a PKI. > > Self-signed certs combined with explicit out-of-band trust models is just a > non-cumbersome as pre-shared keys, IMHO, and they also offer > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > FreeSWAN has a self-signed cert model that works, right?) > > If we keep pre-shared, let's have a scalable way of identifying them. In a > multi-homed world (esp. IPv6), pre-shared keys indexed by address pairs is > as much hassle as PKI registration (it's just less snake-oil than most PKIs > ;). > > For testing, I run server machines with self-signed certs. For small > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any of the > PKI cruft. Peer-to-peer explosions is about the only case where PKI is > really needed, and pre-shared won't help you any there either. It's just a > matter of running certificate-generation, e-mail, and verifying hashes > out-of-band. > > I'm not totally against nuking pre-shared. It's not, however, the panacea > of simplicity many think it is, and simplicity arguments don't hold water. > > Dan > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 6 16:32:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB70W3218734; Thu, 6 Dec 2001 16:32:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02160 Thu, 6 Dec 2001 18:57:10 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Scott Fluhrer" Cc: , References: Subject: Re: Please kill preshared key. Date: Thu, 6 Dec 2001 19:07:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 07 Dec 2001 00:06:22.0143 (UTC) FILETIME=[00D724F0:01C17EB3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, The pre-shared key model uses 'out-of-band' secured channel to exchange asymmetric or symmetric keys. (so is self-signed cert :-) In this model, exchnage phase2's symmetric key through 'out-of-band' secured channel is possible. It is very effective for a small realm. (but can not reach out other realm, therefore not scalable). Off course, the pre-shared symmetric key is less scalable than pre-shared public key method. Yet, public key method is less effecient than symmetric key. (computation cost is prohibitive) On second thought, for large scale implemenation/inter-operation, I would imagine a effective model that uses pre-shared public key as id authentication basis for further exchange its symmetric key (and for a session only). --- David ----- Original Message ----- From: "Scott Fluhrer" To: "david chen" Cc: ; Sent: Thursday, December 06, 2001 6:31 PM Subject: Re: Please kill preshared key. > > > On Thu, 6 Dec 2001, david chen wrote: > > > Agree, > > > > IKE is for 'key exchange'. > > It is *no* needs to change keys in pre-shared key mode. > > > > In the pre-share key model, the two devices can just go directly to phase 2 > > of > > IPSec. > > Ummm, no. That's not how preshared keys work in IKEv1, and I don't think > anyone is advocating such a feature for SOI/JFK/Whatever. Instead, with > PSKs in IKEv1, devices authenticate each other by knowledge of the PSK -- > without the PSK, a device is unable to compute the SKEYID, and thus will > be unable to complete the final part of the IKE transaction. This means > that knowledge of the PSK does not allow an attacker to decrypt a > transcript of an IKE session authenticated via that PSK (unless he can > solve the DH problem as well). > > > > > --- David > > > > > > > > > > ----- Original Message ----- > > From: "Bill Sommerfeld" > > To: > > Sent: Thursday, December 06, 2001 1:47 PM > > Subject: Please kill preshared key. > > > > > > > Since there are people arguing to save preshared key, I just wanted to > > > reemphasize that: > > > > > > 0) it adds cryptographic complexity -- you essentially need a > > > different cryptographic protocol for PSK vs. signature keys. Let's > > > spend the cycles of our cryptographers on more important stuff than > > > this. > > > > > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > > > can misconfigure.. more time for customers spent fumbling around > > > trying to figure out how to configure systems. > > > > > > 2) equivalent functionality can be found in preconfigured public keys > > > and/or self-signed certificates. > > > > > > There's no need for it, it adds complexity. Kill it. > > > > > > - Bill > > > > > > > From owner-ipsec@lists.tislabs.com Thu Dec 6 17:15:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB71FR221486; Thu, 6 Dec 2001 17:15:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02230 Thu, 6 Dec 2001 19:29:19 -0500 (EST) Message-ID: <3C10104B.485198C@redcreek.com> Date: Thu, 06 Dec 2001 16:41:47 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I'm moving my position from 'in favor' to 'neutral' on saving a pre-shared key authentication mode. Its not PSK itself or even current look alike PSK functionality I'd like to see saved. There is a new feature I want to see added and that is interaction with legacy authentication systems in support of remote access users ala draft-ietf-ipsra-reqmts-04.txt. Whether we use a PSK authentication mode (which seemed an obvious fit to me) or a PK authentication mode (I'm willing to learn how if anyone suggests a way) is beside the point to me. All arguments about saving PSK because PSK is easier to test are bogus even if true. Having a test mode and an operational mode is dumb. All arguments that PSK is more or less secure than PK seem to have come out in a tie in my best estimation. Both depend upon secure practices. All arguments that PSK is not scalable enough seem to have fallen a little flat in the face of operational experience with very large scale PSK based authentication systems. Even if we do all think that PK could scale further, PSK seems to be good enough at scaling to have won a larger piece of the authentication world pie than PK. All arguments that a PK auth system can serve all the current capabilities of a PSK system miss the point of the request that we actually *add* new functionality to support remote access users. All arguments about wanting to simplify our key-exchange authentication system to just one mode seem great on the face of it. But we might have an opportunity to add functionality (remote access support) into the main branch of our key exchange system here. If so, the added functionality would justify an extra mode... if needed. The biggest question in my mind is if we have the will to add remote access support since we are now modifying IKE. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Thu Dec 6 17:41:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB71fs222894; Thu, 6 Dec 2001 17:41:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02284 Thu, 6 Dec 2001 20:05:25 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3A4E@NS-CA> From: Michael Choung Shieh To: "'Jan Vilhuber'" Cc: "'Wang, Cliff'" , "'Michael Thomas'" , Alex Alten , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 17:13:30 -0800 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 agree. User won't care if it's pre-shared or public-key system as long as they can easily configure it and make it work. However, I wonder if we can really make it as easy as PSK. IKEv1 has all the options of preshare symmetric vs. public-key but most admin just use PSK. self-signed cert won't work in a typical use case where system admin configures vpn then sends config to remote users. He will need to send them in clear or PKCS12. Before we dump PSK, can someone propose a way to deal with public key system other than PKI? I think we should examine the process before claiming PSK is dead. the claim of adding complexity or option is not a valid statement. After all PSK is most popular auth methold and comparably simple. The claim is beter suited for PKI(any objection?), but I won't complain about it since it provide my job security. -------------------------------------------- Michael Shieh -------------------------------------------- -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Thursday, December 06, 2001 3:37 PM To: Michael Choung Shieh Cc: 'Wang, Cliff'; 'Michael Thomas'; Alex Alten; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Thu, 6 Dec 2001, Michael Choung Shieh wrote: > > >From our experience more than 80% of VPN users are using PSK. That's fine. For a user-interface, you can make a public-key system look EXACTLY like a pre-shared symmetric key system (maybe not exactly, but at least as simple). jan > While we are > developing a standard to replace IKE v1, let's not leave the existing users > behind. Although we may give many reasons that PKI provides more security > and scalability, it's (relatively) easy config of PSK bring IKE to wide > adoption. > > -------------------------------------------- > Michael Shieh > NetScreen Technologies, Inc > -------------------------------------------- > > -----Original Message----- > From: Wang, Cliff [mailto:CWang@smartpipes.com] > Sent: Thursday, December 06, 2001 9:57 AM > To: 'Michael Thomas'; Alex Alten > Cc: Wang, Cliff; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > Very simple reasons, > > IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to be > standardized and it is not going to replace IKE. On the other hand, adding > PSK support in IKEv2 is not an overkill, but provides much more > flexibilities and more choices for service providers. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, December 06, 2001 12:43 PM > To: Alex Alten > Cc: Wang, Cliff; ipsec@lists.tislabs.com > Subject: Re: Please save the pre-shared key mode > > > Alex Alten writes: > > > > I *strongly* 2nd this motion. It would be extremely foolish > to > eliminate PSK support. Foolish in this case translates into > lots of > extra expensive hardware, etc., for our poor customers. > > There are already two choices for keying IPsec SA's > with pre-shared keys with IETF protocols: > > 1) IKEv1 > 2) KINK > > The latter can be used peer-peer as well, and > fixes many of the problems with (1). Why then > do we need to have yet another? > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 6 19:16:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB73GG227157; Thu, 6 Dec 2001 19:16:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02439 Thu, 6 Dec 2001 21:19:34 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Dec 2001 21:16:15 -0500 Message-Id: <20011207021615.340D17C01@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: >> >> Till PKI fully interworks with IPsec devices, only then should we decide >> whether to drop PSK or not. >> >There are multiple ways of rolling out a pki, PKI, or PKi (yes, they are all >different ;). They don't have to be PKIX-complex (is that a superset of >NP-complete?). You can do it MUCH simpler, and still secure, and not need >pre-shared symmetric keys. Use a pre-shared self-signed certificate, or >pre-share the md5-signature of the key, and send it SSH style. Obviously, I strongly agree with that. And the next person who claims that one needs a PKI to use public keys will have to stay late after the working group meeting and clean up any pixels that were spilled onto the floor... --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Thu Dec 6 19:49:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB73n4227996; Thu, 6 Dec 2001 19:49:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02514 Thu, 6 Dec 2001 22:08:13 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Dan Harkins Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Dec 2001 22:17:50 -0500 Message-Id: <20011207031750.B1C3B7B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200112061808.fB6I7t301682@fatty.lounge.org>, Dan Harkins writes: > Actually to compare apples-to-apples you should note that >JFK only produces a single key, Kir, for a single IPsec SA >(I'm assuming it's the initiator's outbound although it's >not specified). To end up with a pair of IPsec SAs, one in >each direction, you'd need: > > Protocol Initiator Responder Latency > ------------------------------------------------ > JFK(normal) 2 signature 2 signature 4 RTT > 4 verifies 2 verify > 2 DH agree 2 DH agree > > JFK(PFS)[2] 2 signature 4 signatures 4 RTT > 4 verifies 2 verify > 2 DH agree 2 DH agree > I'm afraid I don't understand what you're saying. JFK ends up with an authenticated DH exponential; we can clearly derive bidirectional keys from that. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Thu Dec 6 20:04:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB744Q228479; Thu, 6 Dec 2001 20:04:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02500 Thu, 6 Dec 2001 22:02:40 -0500 (EST) Message-Id: <200112061808.fB6I7t301682@fatty.lounge.org> To: Eric Rescorla Cc: ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-Reply-To: Your message of "Wed, 05 Dec 2001 14:33:11 PST." <200112052233.fB5MXB571034@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1679.1007662075.1@tibernian.com> Date: Thu, 06 Dec 2001 10:07:55 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually to compare apples-to-apples you should note that JFK only produces a single key, Kir, for a single IPsec SA (I'm assuming it's the initiator's outbound although it's not specified). To end up with a pair of IPsec SAs, one in each direction, you'd need: Protocol Initiator Responder Latency ------------------------------------------------ JFK(normal) 2 signature 2 signature 4 RTT 4 verifies 2 verify 2 DH agree 2 DH agree JFK(PFS)[2] 2 signature 4 signatures 4 RTT 4 verifies 2 verify 2 DH agree 2 DH agree Dan. On Wed, 05 Dec 2001 14:33:11 PST wrote > As background to the discussion, I thought it might be worth > looking at performance of the various IKE replacements. > The following table summarizes the performance behavior of > the major proposals as far as I can make out. > I've also added TLS for comparison. > > Protocol Initiator Responder Latency > ------------------------------------------------ > IKEv2 1 signature 1 signature 2 RTT > 1 verify 1 verify > 1 DH agree 1 DH agree > > IKEv2 1 signature 1 signature 3 RTT > (DoS mode) 1 verify 1 verify > 1 DH agree 1 DH agree > > SIGMA 1 signature 1 signature 1.5 RTT [1] > 1 verify 1 verify > 1 DH agree 1 DH agree > > SIGMA 1 signature 1 signature 2.5 RTT [1] > (DoS mode) 1 verify 1 verify > 1 DH agree 1 DH agree > > JFK(normal) 1 signature 1 signature 2 RTT > 2 verifies 1 verify > 1 DH agree 1 DH agree > > JFK(PFS)[2] 1 signature 2 signatures 2 RTT > 2 verifies 1 verify > 1 DH agree 1 DH agree > TLS (RSA)[3] 1 signature 1 decryption 2 RTT > 1 RSA encrypt 1 verify > > TLS (PFS)[3] 1 signature 1 signature 2 RTT > 1 verify 1 verify > 1 DH agree 1 DH agree > > Notes: > [0] I'm ignoring the following computational costs since > they're more or less constant across protocols and are > usually cheap. > > Digests, symmetric encryption, and PRFs. > Certificate verification (not cheap if DSS) > All of the PFS modes require an additional g^x mod p. > > [1] I'm dubious about the value of this. As Phill Hallam-Baker > argues, you'd probably want to use a 4-message handshake anyway. > > [2] In JFK, PFS mode is incompatible with DoS protection. > > [3] Note that TLS has an anonymous client mode which is even > faster: 1 RSA encrypt on the client and 1 RSA decrypt > on the server. > > [4] Here are some approximate timings for the various operations > (measured on a Celeron 300). All moduli are 1024-bit. > > RSA private key op 30 ms > RSA public key op 2 ms > DH key agree (1024-bit X) 100 ms > (256-bit X) 25 ms > DSA signature 17 ms > DSA verify 21 ms > > > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu Dec 6 20:44:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB74d8229256; Thu, 6 Dec 2001 20:39:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02656 Thu, 6 Dec 2001 22:51:36 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884B8@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , ipsec@lists.tislabs.com Subject: RE: Please kill preshared key. Date: Fri, 7 Dec 2001 04:00:47 -0000 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 IKE is for "key exchange" and derives the key for IPsec SA. Pre-shared key is for authentication in IKE SA. I think you have confused Phase 1 pre-shared key authentication with a pre-shared key IPsec SA (static key IPsec SA) which doesn't need key management. :(. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Thursday, December 06, 2001 5:30 PM To: sommerfeld@east.sun.com; ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. Agree, IKE is for 'key exchange'. It is *no* needs to change keys in pre-shared key mode. In the pre-share key model, the two devices can just go directly to phase 2 of IPSec. --- David ----- Original Message ----- From: "Bill Sommerfeld" To: Sent: Thursday, December 06, 2001 1:47 PM Subject: Please kill preshared key. > Since there are people arguing to save preshared key, I just wanted to > reemphasize that: > > 0) it adds cryptographic complexity -- you essentially need a > different cryptographic protocol for PSK vs. signature keys. Let's > spend the cycles of our cryptographers on more important stuff than > this. > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > can misconfigure.. more time for customers spent fumbling around > trying to figure out how to configure systems. > > 2) equivalent functionality can be found in preconfigured public keys > and/or self-signed certificates. > > There's no need for it, it adds complexity. Kill it. > > - Bill > From owner-ipsec@lists.tislabs.com Thu Dec 6 21:02:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB752Z229673; Thu, 6 Dec 2001 21:02:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02718 Thu, 6 Dec 2001 23:21:25 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884BB@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Jan Vilhuber'" Cc: "'Dan McDonald'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 04:30:31 -0000 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 >From the operation point of view, PSK is quick and easy to set up service. It works and customers are happy. It is more real than a myth. -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Thursday, December 06, 2001 6:39 PM To: Wang, Cliff Cc: 'Dan McDonald'; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode > On the > other hand, PSK based IKE and PKI based IKE has been the main way people > deploying VPN. Under that context, PSK is simpler to run than PKI. > I think that's the myth Dan was talking about. jan > > -----Original Message----- > From: Dan McDonald [mailto:danmcd@east.sun.com] > Sent: Thursday, December 06, 2001 1:28 PM > To: Wang, Cliff > Cc: ipsec@lists.tislabs.com > Subject: Re: Please save the pre-shared key mode > > > > 1) Simplicity > > Pre-shared key mode is simpler to support by eliminating the > > requirement of supporting complex PKI. > > It's a myth that public-key implies you MUST have a PKI. > > Self-signed certs combined with explicit out-of-band trust models is > just a non-cumbersome as pre-shared keys, IMHO, and they also offer > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > FreeSWAN has a self-signed cert model that works, right?) > > If we keep pre-shared, let's have a scalable way of identifying them. > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > pairs is as much hassle as PKI registration (it's just less snake-oil > than most PKIs ;). > > For testing, I run server machines with self-signed certs. For small > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > of the PKI cruft. Peer-to-peer explosions is about the only case > where PKI is really needed, and pre-shared won't help you any there > either. It's just a matter of running certificate-generation, e-mail, > and verifying hashes out-of-band. > > I'm not totally against nuking pre-shared. It's not, however, the > panacea of simplicity many think it is, and simplicity arguments don't > hold water. > > Dan > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 6 21:20:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB75KJ200177; Thu, 6 Dec 2001 21:20:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02690 Thu, 6 Dec 2001 23:12:55 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884B9@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , Scott Fluhrer Cc: ipsec@lists.tislabs.com Subject: RE: Please kill preshared key. Date: Fri, 7 Dec 2001 04:22:00 -0000 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 -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Thursday, December 06, 2001 7:07 PM To: Scott Fluhrer Cc: sommerfeld@east.sun.com; ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. >Well, >The pre-shared key model uses 'out-of-band' secured channel to exchange asymmetric or symmetric >keys. (so is self-signed cert :-) >In this model, exchnage phase2's symmetric key through 'out-of-band' secured channel is >possible. It is very effective for a small realm. (but can not reach out other realm, therefore >not scalable). I am really confused here. Are we talking about IKE or something else? All the discussions here are about IKE phase 1 authentication mode. The phase 2 key are derived from D-H exchange. Why phase 2 key needs to be exchanged "out of band"??? ----- Original Message ----- From: "Scott Fluhrer" To: "david chen" Cc: ; Sent: Thursday, December 06, 2001 6:31 PM Subject: Re: Please kill preshared key. > > > On Thu, 6 Dec 2001, david chen wrote: > > > Agree, > > > > IKE is for 'key exchange'. > > It is *no* needs to change keys in pre-shared key mode. > > > > In the pre-share key model, the two devices can just go directly to phase 2 > > of > > IPSec. > > Ummm, no. That's not how preshared keys work in IKEv1, and I don't > think anyone is advocating such a feature for SOI/JFK/Whatever. > Instead, with PSKs in IKEv1, devices authenticate each other by > knowledge of the PSK -- without the PSK, a device is unable to compute > the SKEYID, and thus will be unable to complete the final part of the > IKE transaction. This means that knowledge of the PSK does not allow > an attacker to decrypt a transcript of an IKE session authenticated > via that PSK (unless he can solve the DH problem as well). > > > > > --- David > > > > > > > > > > ----- Original Message ----- > > From: "Bill Sommerfeld" > > To: > > Sent: Thursday, December 06, 2001 1:47 PM > > Subject: Please kill preshared key. > > > > > > > Since there are people arguing to save preshared key, I just > > > wanted to reemphasize that: > > > > > > 0) it adds cryptographic complexity -- you essentially need a > > > different cryptographic protocol for PSK vs. signature keys. > > > Let's spend the cycles of our cryptographers on more important > > > stuff than this. > > > > > > 1) it adds YET ONE MORE OPTION you need to test, one more knob > > > you can misconfigure.. more time for customers spent fumbling > > > around trying to figure out how to configure systems. > > > > > > 2) equivalent functionality can be found in preconfigured public > > > keys and/or self-signed certificates. > > > > > > There's no need for it, it adds complexity. Kill it. > > > > > > - Bill > > > > > > > From owner-ipsec@lists.tislabs.com Thu Dec 6 21:33:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB75XZ200415; Thu, 6 Dec 2001 21:33:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02789 Thu, 6 Dec 2001 23:36:13 -0500 (EST) Date: Thu, 6 Dec 2001 23:45:15 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Please kill preshared key. In-Reply-To: <200112061847.fB6IlsjM003590@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 On Thu, 6 Dec 2001, Bill Sommerfeld wrote: > There's no need for it, it adds complexity. Kill it. The FreeS/WAN project concurs, especially about the "one more way for users to shoot themselves in the foot" part. One thing... As I've been known to rant about :-), many of the people arguing for its retention seem to confuse public keys with the horrors of PKI. It would be a service to mankind if we referred to the feature under discussion as "shared secret" or "preshared secret key", to distinguish it from healthier approaches like preshared public keys. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Dec 6 23:00:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB770u202754; Thu, 6 Dec 2001 23:00:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02989 Fri, 7 Dec 2001 01:19:32 -0500 (EST) Message-Id: <200112062124.fB6LOh301908@fatty.lounge.org> To: "Angelos D. Keromytis" Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-Reply-To: Your message of "Thu, 06 Dec 2001 22:21:38 EST." <200112070321.fB73Lcpv013394@coredump.cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1905.1007673883.1@tibernian.com> Date: Thu, 06 Dec 2001 13:24:43 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC2409 uses something not defined anywhere in JFK to expand keys (SKEYID_d) and two other things whose exact location can only be guessed at (the SPI and protocol fields of an "sa" structure which itself is not defined). If your students generated interoperable implementations they deserve either an A+ for their omniscience or an F for cheating. Dan. On Thu, 06 Dec 2001 22:21:38 EST you wrote > > At the end of JFK, you get the same key material as you get with any > of the other protocols (the result of a DH computation, mixed with > some other randomness --- the nonces). You can stretch that to your > heart's content, as has been done in all other protocols since the > dawn of history -- IKE, Photuris, TLS. The initial key derivation > process is intended to make the JFK session key and the application > key (e.g., IPsec) independent (a la SKEYID). You can then apply the > same PRF process to extend this to fit 3DES, AES, etc. > > In fact, that's what my students' reference implementations do (even > though I never mentioned PRF to them, they found it on RFC 2409 by > themselves). > -Angelos From owner-ipsec@lists.tislabs.com Thu Dec 6 23:01:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB771f202915; Thu, 6 Dec 2001 23:01:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA03021 Fri, 7 Dec 2001 01:27:17 -0500 (EST) Message-Id: <3.0.3.32.20011206223922.00ee9c28@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 06 Dec 2001 22:39:22 -0800 To: Michael Choung Shieh , "'Jan Vilhuber'" From: Alex Alten Subject: RE: Please save the pre-shared key mode Cc: "'Wang, Cliff'" , "'Michael Thomas'" , ipsec@lists.tislabs.com In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3A4E@NS-CA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's more than just complexity of configuring keys. It's also about speed of authentication. Not everyone is using hw cypto chip accelerators to do it. Not everyone has fast CPU's to do it. In my mind PSK should be the 1st choice, with PK the 2nd, optional choice. And don't respond with the usual bull about scalability, that doesn't cut any ice. - Alex At 05:13 PM 12/6/2001 -0800, Michael Choung Shieh wrote: > >I agree. User won't care if it's pre-shared or public-key system as long as >they can easily configure it and make it work. > >However, I wonder if we can really make it as easy as PSK. IKEv1 has all >the options of preshare symmetric vs. public-key but most admin just use >PSK. self-signed cert won't work in a typical use case where system admin >configures vpn then sends config to remote users. He will need to send them >in clear or PKCS12. > >Before we dump PSK, can someone propose a way to deal with public key system >other than PKI? I think we should examine the process before claiming PSK >is dead. > >the claim of adding complexity or option is not a valid statement. After >all PSK is most popular auth methold and comparably simple. The claim is >beter suited for PKI(any objection?), but I won't complain about it since it >provide my job security. > >-------------------------------------------- >Michael Shieh >-------------------------------------------- > >-----Original Message----- >From: Jan Vilhuber [mailto:vilhuber@cisco.com] >Sent: Thursday, December 06, 2001 3:37 PM >To: Michael Choung Shieh >Cc: 'Wang, Cliff'; 'Michael Thomas'; Alex Alten; ipsec@lists.tislabs.com >Subject: RE: Please save the pre-shared key mode > > >On Thu, 6 Dec 2001, Michael Choung Shieh wrote: > >> >> >From our experience more than 80% of VPN users are using PSK. > >That's fine. For a user-interface, you can make a public-key system look >EXACTLY like a pre-shared symmetric key system (maybe not exactly, but at >least as simple). > >jan > > >> While we are >> developing a standard to replace IKE v1, let's not leave the existing >users >> behind. Although we may give many reasons that PKI provides more security >> and scalability, it's (relatively) easy config of PSK bring IKE to wide >> adoption. >> >> -------------------------------------------- >> Michael Shieh >> NetScreen Technologies, Inc >> -------------------------------------------- >> >> -----Original Message----- >> From: Wang, Cliff [mailto:CWang@smartpipes.com] >> Sent: Thursday, December 06, 2001 9:57 AM >> To: 'Michael Thomas'; Alex Alten >> Cc: Wang, Cliff; ipsec@lists.tislabs.com >> Subject: RE: Please save the pre-shared key mode >> >> >> Very simple reasons, >> >> IKEv1 is going to be replaced by IKEv2 in the future and KINK has yet to >be >> standardized and it is not going to replace IKE. On the other hand, adding >> PSK support in IKEv2 is not an overkill, but provides much more >> flexibilities and more choices for service providers. >> >> -----Original Message----- >> From: Michael Thomas [mailto:mat@cisco.com] >> Sent: Thursday, December 06, 2001 12:43 PM >> To: Alex Alten >> Cc: Wang, Cliff; ipsec@lists.tislabs.com >> Subject: Re: Please save the pre-shared key mode >> >> >> Alex Alten writes: >> > >> > I *strongly* 2nd this motion. It would be extremely foolish > to >> eliminate PSK support. Foolish in this case translates into > lots of >> extra expensive hardware, etc., for our poor customers. >> >> There are already two choices for keying IPsec SA's >> with pre-shared keys with IETF protocols: >> >> 1) IKEv1 >> 2) KINK >> >> The latter can be used peer-peer as well, and >> fixes many of the problems with (1). Why then >> do we need to have yet another? >> >> Mike >> > > -- >Jan Vilhuber vilhuber@cisco.com >Cisco Systems, San Jose (408) 527-0847 > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Thu Dec 6 23:04:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB774W203462; Thu, 6 Dec 2001 23:04:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02959 Fri, 7 Dec 2001 01:05:14 -0500 (EST) Date: Fri, 07 Dec 2001 08:13:56 +0200 From: Sara Bitan Subject: Re: Please kill preshared key. To: sommerfeld@east.sun.com, ipsec@lists.tislabs.com Message-id: <00b601c17ee6$5ad3c390$9ba6003e@cs.technion.ac.il> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset=windows-1255 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200112061847.fB6IlsjM003590@thunk.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Bill! Let's try to look at the details: ----- Original Message ----- From: Bill Sommerfeld To: Sent: Thursday, December 06, 2001 8:47 PM Subject: Please kill preshared key. > Since there are people arguing to save preshared key, I just wanted to > reemphasize that: > > 0) it adds cryptographic complexity -- you essentially need a > different cryptographic protocol for PSK vs. signature keys. Let's > spend the cycles of our cryptographers on more important stuff than > this. IKE-SIGAM (and I think IKEv2 also, if PKS authentication is added) with pre-shared key authentication differ from signatures authentication is *exactly two points* 1) The calculation of SKEYID in IKE-SIGMA and of SKEYSEED in IKEv2. 2) If you are using signatures authentication you add a signature and signture verification on top of the hash calculation. > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > can misconfigure.. more time for customers spent fumbling around > trying to figure out how to configure systems. One option out of how many options? Is this really the one that will turn a product from an easy to configure one to a non-configurable? > > 2) equivalent functionality can be found in preconfigured public keys > and/or self-signed certificates. Is performance a non-issue? How many CPU cycles are consumed by HMAC-SHA1? How many are consumed by RSA/DSA signature? What about extra hardware I might need to add if public cryptography based authentication is a must? What if I am a cellular vendor? PDA? > > There's no need for it, it adds complexity. Kill it. > > - Bill There is a need. Yes, it adds one more option, but the (small amount of) complexity added here is justified, and we must support it, Sara From owner-ipsec@lists.tislabs.com Thu Dec 6 23:05:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB775N203612; Thu, 6 Dec 2001 23:05:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02974 Fri, 7 Dec 2001 01:08:23 -0500 (EST) Message-Id: <200112062113.fB6LDj301886@fatty.lounge.org> To: "Steven M. Bellovin" Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-Reply-To: Your message of "Thu, 06 Dec 2001 22:17:50 EST." <20011207031750.B1C3B7B55@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1883.1007673224.1@tibernian.com> Date: Thu, 06 Dec 2001 13:13:45 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, you can but I guess what I'm saying is that you're not. You can stretch it to produce bi-directional keys but such stretching is not specified anywhere in JFK. In <200112042306.BAA16872@burp.tkv.asdf.org> Markku Savela mentioned he preferred "a key negotiation [protocol] that only negotiates one directional SA as requested by the kernel side of the IPSEC." That is what JFK establishes today, a single session key for IPsec. If the intent, though, is that Kir should be stretched somehow to produce bi-directional keys I withdraw my comment, but you really should specify how. Leaving such things to the imagination of the implementor will probably result in disinteroperability. Dan. On Thu, 06 Dec 2001 22:17:50 EST you wrote > In message <200112061808.fB6I7t301682@fatty.lounge.org>, Dan Harkins writes: > > Actually to compare apples-to-apples you should note that > >JFK only produces a single key, Kir, for a single IPsec SA > >(I'm assuming it's the initiator's outbound although it's > >not specified). To end up with a pair of IPsec SAs, one in > >each direction, you'd need: > > > > Protocol Initiator Responder Latency > > ------------------------------------------------ > > JFK(normal) 2 signature 2 signature 4 RTT > > 4 verifies 2 verify > > 2 DH agree 2 DH agree > > > > JFK(PFS)[2] 2 signature 4 signatures 4 RTT > > 4 verifies 2 verify > > 2 DH agree 2 DH agree > > > > I'm afraid I don't understand what you're saying. JFK ends up with an > authenticated DH exponential; we can clearly derive bidirectional keys > from that. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > From owner-ipsec@lists.tislabs.com Thu Dec 6 23:10:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB77A8204515; Thu, 6 Dec 2001 23:10:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA03036 Fri, 7 Dec 2001 01:33:47 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Wang, Cliff" , References: <4652644B98DFF34696801F8F3070D3FE011884B8@D2CSPEXM001.smartpipes.com> Subject: Re: Please kill preshared key. Date: Fri, 7 Dec 2001 01:43:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 07 Dec 2001 06:43:00.0442 (UTC) FILETIME=[69BB63A0:01C17EEA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What I infered is that the pre-shared symmetric key can be used for both authentication and encryption without key-exchange (KE) since this key is exchnaged through 'out-of-band' secured channel and is *intended* for the two devices only. As for authentication purpose, I see the RSA asymmetric key is more appropriate than symmetric in two reason as we have discussed: 1) scalable (public key sharable among the realms) 2) the key is binded to device, not link Since this thread is 'kill preshared key', I would only agree take out pre-shared symmetric key but not pre-shared asymmetric key, such as self-signed cert. --- David ----- Original Message ----- From: "Wang, Cliff" To: "'david chen'" ; Sent: Thursday, December 06, 2001 11:00 PM Subject: RE: Please kill preshared key. > > IKE is for "key exchange" and derives the key for IPsec SA. > > Pre-shared key is for authentication in IKE SA. > > I think you have confused Phase 1 pre-shared key authentication with a > pre-shared key IPsec SA (static key IPsec SA) which doesn't need key > management. :(. > > -----Original Message----- > From: david chen [mailto:ietf_davidchen@hotmail.com] > Sent: Thursday, December 06, 2001 5:30 PM > To: sommerfeld@east.sun.com; ipsec@lists.tislabs.com > Subject: Re: Please kill preshared key. > > > Agree, > > IKE is for 'key exchange'. > It is *no* needs to change keys in pre-shared key mode. > > In the pre-share key model, the two devices can just go directly to phase 2 > of IPSec. > > --- David > > > > > ----- Original Message ----- > From: "Bill Sommerfeld" > To: > Sent: Thursday, December 06, 2001 1:47 PM > Subject: Please kill preshared key. > > > > Since there are people arguing to save preshared key, I just wanted to > > reemphasize that: > > > > 0) it adds cryptographic complexity -- you essentially need a > > different cryptographic protocol for PSK vs. signature keys. Let's > > spend the cycles of our cryptographers on more important stuff than > > this. > > > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > > can misconfigure.. more time for customers spent fumbling around > > trying to figure out how to configure systems. > > > > 2) equivalent functionality can be found in preconfigured public keys > > and/or self-signed certificates. > > > > There's no need for it, it adds complexity. Kill it. > > > > - Bill > > > From owner-ipsec@lists.tislabs.com Fri Dec 7 00:04:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB784g213791; Fri, 7 Dec 2001 00:04:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA03147 Fri, 7 Dec 2001 02:28:53 -0500 (EST) From: "Wen-Chi \(Alex\) Wang" To: "'Wang, Cliff'" , "'Jan Vilhuber'" Cc: "'Dan McDonald'" , Subject: RE: Please save the pre-shared key mode Date: Thu, 6 Dec 2001 23:37:14 -0800 Message-ID: <000401c17ef2$001b0240$261410ac@alex> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884BB@D2CSPEXM001.smartpipes.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 07 Dec 2001 07:38:04.0820 (UTC) FILETIME=[1B4B7540:01C17EF2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is some voice from the field. We usually use PSK based IKE to do test for VPN connectivity before we go further for any PKI based IKE roll out just because for field engineers sometimes it is better to use simple and easy setup process and procedure to implement a quick test before we start to tune up the connection. So I hope the high-level spec could at least keep PSK based IKE as an option for the sake of easy testing. Please don't drop it. Alex -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Wang, Cliff Sent: Thursday, December 06, 2001 8:31 PM To: 'Jan Vilhuber' Cc: 'Dan McDonald'; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode >From the operation point of view, PSK is quick and easy to set up service. It works and customers are happy. It is more real than a myth. -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Thursday, December 06, 2001 6:39 PM To: Wang, Cliff Cc: 'Dan McDonald'; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode > On the > other hand, PSK based IKE and PKI based IKE has been the main way people > deploying VPN. Under that context, PSK is simpler to run than PKI. > I think that's the myth Dan was talking about. jan > > -----Original Message----- > From: Dan McDonald [mailto:danmcd@east.sun.com] > Sent: Thursday, December 06, 2001 1:28 PM > To: Wang, Cliff > Cc: ipsec@lists.tislabs.com > Subject: Re: Please save the pre-shared key mode > > > > 1) Simplicity > > Pre-shared key mode is simpler to support by eliminating the > > requirement of supporting complex PKI. > > It's a myth that public-key implies you MUST have a PKI. > > Self-signed certs combined with explicit out-of-band trust models is > just a non-cumbersome as pre-shared keys, IMHO, and they also offer > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > FreeSWAN has a self-signed cert model that works, right?) > > If we keep pre-shared, let's have a scalable way of identifying them. > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > pairs is as much hassle as PKI registration (it's just less snake-oil > than most PKIs ;). > > For testing, I run server machines with self-signed certs. For small > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > of the PKI cruft. Peer-to-peer explosions is about the only case > where PKI is really needed, and pre-shared won't help you any there > either. It's just a matter of running certificate-generation, e-mail, > and verifying hashes out-of-band. > > I'm not totally against nuking pre-shared. It's not, however, the > panacea of simplicity many think it is, and simplicity arguments don't > hold water. > > Dan > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 00:29:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB78TD217440; Fri, 7 Dec 2001 00:29:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA03397 Fri, 7 Dec 2001 02:55:28 -0500 (EST) Message-Id: <200112070805.LAA07554@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Eric Rescorla , Dan Harkins Date: Fri, 7 Dec 2001 11:05:05 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Comments on IKEv2 CC: ipsec@lists.tislabs.com In-reply-to: <200112051242.fB5Cfon01516@fatty.lounge.org> References: Your message of "Wed, 05 Dec 2001 09:54:20 PST." <200112051754.fB5HsK570688@romeo.rtfm.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 5 Dec 01, at 4:41, Dan Harkins wrote: > > (3) S 2.9 says: > > > > The Responder is allowed to narrow the choices by selecting a subset > > of the traffic, for instance by eliminating one or more members of > > the set of traffic selectors provided the set does not become the > > NULL set. > > > > Can the responder widen the choices? If not, why not? > > We want the two sides to converge on the largest intersection of their > policy in the fewest possible number of messages. If the Responder added > things it might be unacceptable to the Initiator and result in more > round trips. Dan, on what criteria could responder base his decision to narrow TS? Assume the following situation: initiator offers wildcard TSS, while responder's SPD consists of several adjacent ranges. The very natural decision for him is to select and sent back to initiator one of these ranges. But which? He doesn't have enough information because initiator has no ability to tell him what exact packet she is trying to make SA for. If this information were provided by initiator (via special payload or by requiring the first TSS in TS to always represent the actual IP packet triggered this negotiation), this would increase robustness of the protocol. And one more comment. The peers seem to have no ability to inform each other about what kind of signature (RSA or DSA) they will use. Why so? This will require all implementation to support both (or even more if ECDSA come later) to be interoperable. Wouldn't it be better to negotiate this, as well as cipher, hash and group? Best regards, Smyslov Valery. From owner-ipsec@lists.tislabs.com Fri Dec 7 00:41:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB78fD218865; Fri, 7 Dec 2001 00:41:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03472 Fri, 7 Dec 2001 03:03:07 -0500 (EST) Message-Id: <200112070813.LAA08310@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: , , "Tolga Acar" Date: Fri, 7 Dec 2001 11:13:43 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RFC 2628 Implementation ( Crypto API ) In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 6 Dec 01, at 11:43, Tolga Acar wrote: We are using RFC2628 API in our products. > You might want to look at the PKCS#11 interface for a standardized > Crypto API set. RFC2628 is not a competitor to PKCS#11. It is much more simple and limited in functionality, yet providing more easier way to plug in new symmetric cipher algorithms. It was anticipated that this API to be used in kernel only. Regards, Valery Smyslov. > RFC 2628 undermines the inspectibility problem by encapsulating all > operations under one API. You might find this limiting in secure systems > that must go through certification and/or evaluation. > > Best, > - Tolga > > >>> "Mahdavi" 12/2/01 3:06:45 >>> > Hi. > > Does any body knows any Implementation of RFC 2628 ( crypto API )? > > I want to use it for abstracting cryptographic modules of IPSec. > > Thanks before > > mahdavi > > From owner-ipsec@lists.tislabs.com Fri Dec 7 02:13:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7ADd228666; Fri, 7 Dec 2001 02:13:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03653 Fri, 7 Dec 2001 04:28:54 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary Subject: Re: Comments on IKEv2 Date: Wed, 5 Dec 2001 18:35:59 -0500 Message-ID: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Thread-Topic: Comments on IKEv2 Thread-Index: AcF96aA4t7r1qOncEdWVVQCQJ2GH0w== From: "Jan Vilhuber" To: "Eric Rescorla" Cc: X-OriginalArrivalTime: 06 Dec 2001 00:07:49.0354 (UTC) FILETIME=[0A68BCA0:01C17DEA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk xŸ>"2äè€€Ñ #;\ €Ñ 9< €!A7F5BAB7DCE9D51195550090276187D3&ä0Eric Rescorla0 SMTP0ekr@rtfm.com0 @:CN  0SMTP:EKR@RTFM.COM :Eric Rescorla00ipsec@lists.tislabs.com0 SMTP00ipsec@lists.tislabs.com0 @:CN  0SMTP:IPSEC@LISTS.TISLABS.COM :0ipsec@lists.tislabs.comƒ@˜$IPM.NOTE&67,Re: Comments on IKEv2@9€Ù¿—å}Á= Re: p$Comments on IKEv2qÁ}é 8·ºõ¨éÜÕ•U'a‡Ó Jan Vilhuber$Comments on IKEv2 *&>LZFu¼$Ò rcpg125â2CtexA÷ÿ €¤ä€óPV?U²%Qchá Àset2Ã%ö3F·0,3ï ÷¶;05" `cP3 d36P ¦ O W €, 5 D¥ Ð01PE°R¡ ` w`°: ¢ „ €> IÏ  ±@@of àp– sPI °ok a@IKE2v@:)ÖÖ(1v) tà@$`y–.À.psp'!‘"@ "$F" †b$`$ðIMHOPÇÀ%€nceÖð€th PKIX!Pøhow (Ð"Q$v6 &r"P)`le÷')’e!Pp, þa,0 å)³(Ð*Á*¨ctu@l* nås Ày?# `,vd+€-00Ðpic-,±- ð0Ðk¨e-p!o‘- Pqts-à. ÐtOP1Q$p 4Pp¦o €@1.zjpQt --tJ‘Vñhub78Ÿ97Zv7@% ¡. m­tC:âQs°m!±ñ Jo9?>?>q°(408$ @73 (847t}@Ð5€ òó8Re%3A Comments on IKEv2.EML ô õ ö@0ÔÈ8 é}Á@003ñ£é}ÁÞ?ŸNß?ÿÿÿÿñ?ø?DInternet Mail Service (FLF960BH1)ù?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (FLF960BH1)ú?DInternet Mail Service (FLF960BH1)û?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (FLF960BH1)ý?ÿ@@0@&vilhuber@cisco.com1@&vilhuber@cisco.com8@HINTERNET MAIL CONNECTOR (FLF960BH1)9@&vilhuber@cisco.com ) #@‘ From owner-ipsec@lists.tislabs.com Fri Dec 7 02:14:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7AEP228807; Fri, 7 Dec 2001 02:14:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03667 Fri, 7 Dec 2001 04:41:05 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary Subject: Re: Son-of-IKE Performance Date: Wed, 5 Dec 2001 19:15:13 -0500 Message-ID: X-MS-TNEF-Correlator: Thread-Topic: Son-of-IKE Performance X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Thread-Index: AcF974MPvGQ8C+nhEdWnAACQJ3s5nw== From: "Eric Rescorla" To: Cc: Reply-To: "EKR" X-OriginalArrivalTime: 06 Dec 2001 00:57:19.0354 (UTC) FILETIME=[F4AAC5A0:01C17DF0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk xŸ>"äè€€Ñ  €Ñ .E €!0A3C64BCE1E9D511A7000090277B399F,00sommerfeld@east.sun.com0 SMTP00sommerfeld@east.sun.com0 @:n  0SMTP:SOMMERFELD@EAST.SUN.COM :0sommerfeld@east.sun.com00ipsec@lists.tislabs.com0 SMTP00ipsec@lists.tislabs.com0 @:n  0SMTP:IPSEC@LISTS.TISLABS.COM :0ipsec@lists.tislabs.comjPd &IPM.NOTE&676Re: Son-of-IKE Performance@9€¾×ë}Á= Re: PEKRp.Son-of-IKE PerformanceqÁ}d< éáÕ§'{9Ÿ Eric Rescorla.Son-of-IKE Performance &"ùLZFuS3½ rcpg125â2CtexA÷ÿ €¤ä€óPV?U²%Qchá Àset2Ã%ö3F·0,3ï ÷¶;05" `cP3 d36P ¦ B Sp€rfe ld w°sN: ¢ €pI'Ðl€ike to í ða ±@l ð` ¾  !h ð[ @ p °c@ovf"ó ày ÀÑnNg ð"Ñ ðd-!- %á °a°ncy.Ö ã €Y, p!pÿ Â"ñ& "ñ€`ÁÎb ð) hw(À!àÁ'Howev'Àæn*`€e'"1%€@½ €g  €!#m#ò÷€Àpe€0*Â@LjuÐ"Qsk!pn@y :) T[(Â(Ña !¥dfÿà) @&Ð ð ðr(@l?/À$ þp`!‘0A"1#‘÷!à-â €. /à+00A4,„ P#òApþu+° #a&•/Ðï ±2¡°m5E €- >aP pÐ(³(Ñgoüig"á! (!àÁ#1øqui"29ð%p!ëq Àn.=ð  ²A=Àcd.P2¡y'Âk. ðRÐo"Ñ8²KøAME8£'à1p&a(c™° _ °s_3w+‘$•°r`*!OXTOH'ÀBm;`h¿@)aD°ð 1pg-±w50'% A@)à(p_;P0#€%ÁÐh%cÿ‘6ƒ+°& ±4`þpB `P`%ð èSA?'IJ¡ €KýKÄL Ññ ðÀ#žsG%ð5EHu;@ÿ)P`OPDáJa(³G”Àw+A')a°oúk="o*‘"ò 3˜!ÿ"aD°=À"óq*pNÀ+*HPñJ‘Vhu÷)`ÀG“s JÑ'ÀÀÏ#Á/PG1 ð y`HóçJ%KÐ0n'(‘?47@Ý<r1à>*I$pûY0TÑwpJ¡!$ ÿJ2RUDT34<€7ÂûT#lJp1pC%#ÿ‘!á'à)Z‚7R b/¡¡>*-EkrcK-'%ô[Ecð¡ `×'fgžed @!9A] gžDàtp:¨//wk@.hæ/ }l€5@ òóBRe%3A Son-of-IKE Performance.EML ô õ ö@0ƒï}Á@0nnï}ÁÞ?ŸNß?ÿÿÿÿñ?ø?DInternet Mail Service (NJB140BH1)ù?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (NJB140BH1)ú?DInternet Mail Service (NJB140BH1)û?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (NJB140BH1)ü?ý?ÿ@@0@ekr@rtfm.com1@! ekr@rtfm com8@HINTERNET MAIL CONNECTOR (NJB140BH1)9@ekr@rtfm.com ) # ¶5 From owner-ipsec@lists.tislabs.com Fri Dec 7 02:41:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Afm200392; Fri, 7 Dec 2001 02:41:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03740 Fri, 7 Dec 2001 05:08:10 -0500 (EST) Reply-To: From: "Alister Yap" To: "Alex Alten" , "Michael Choung Shieh" , "'Jan Vilhuber'" Cc: "'Wang, Cliff'" , "'Michael Thomas'" , Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 10:13:43 -0000 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3.0.3.32.20011206223922.00ee9c28@pop3.netvista.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If I remember correctly, the HW accelerators only speed up the encryption process and not authentication. The testings we have done showed that, for the authentication phase, with the same CPU (Cisco 26xx), the ratio of pkts dropped for PSK to PK is 1 to 8 (PK setup is a hierarchical CA with RA & external CRL). Perhaps one needs to think about "What is the best way to handle real time traffic?" Alister > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > Sent: 07 December 2001 06:39 > To: Michael Choung Shieh; 'Jan Vilhuber' > Cc: 'Wang, Cliff'; 'Michael Thomas'; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > > It's more than just complexity of configuring keys. It's also about > speed of authentication. Not everyone is using hw cypto chip accelerators > to do it. Not everyone has fast CPU's to do it. In my mind PSK should > be the 1st choice, with PK the 2nd, optional choice. And don't respond > with the usual bull about scalability, that doesn't cut any ice. > > - Alex > > > At 05:13 PM 12/6/2001 -0800, Michael Choung Shieh wrote: > > > >I agree. User won't care if it's pre-shared or public-key > system as long as > >they can easily configure it and make it work. > > > >However, I wonder if we can really make it as easy as PSK. IKEv1 has all > >the options of preshare symmetric vs. public-key but most admin just use > >PSK. self-signed cert won't work in a typical use case where > system admin > >configures vpn then sends config to remote users. He will need > to send them > >in clear or PKCS12. > > > >Before we dump PSK, can someone propose a way to deal with > public key system > >other than PKI? I think we should examine the process before > claiming PSK > >is dead. > > > >the claim of adding complexity or option is not a valid statement. After > >all PSK is most popular auth methold and comparably simple. The claim is > >beter suited for PKI(any objection?), but I won't complain about > it since it > >provide my job security. > > > >-------------------------------------------- > >Michael Shieh > >-------------------------------------------- > > > >-----Original Message----- > >From: Jan Vilhuber [mailto:vilhuber@cisco.com] > >Sent: Thursday, December 06, 2001 3:37 PM > >To: Michael Choung Shieh > >Cc: 'Wang, Cliff'; 'Michael Thomas'; Alex Alten; ipsec@lists.tislabs.com > >Subject: RE: Please save the pre-shared key mode > > > > > >On Thu, 6 Dec 2001, Michael Choung Shieh wrote: > > > >> > >> >From our experience more than 80% of VPN users are using PSK. > > > >That's fine. For a user-interface, you can make a public-key system look > >EXACTLY like a pre-shared symmetric key system (maybe not exactly, but at > >least as simple). > > > >jan > > > > > >> While we are > >> developing a standard to replace IKE v1, let's not leave the existing > >users > >> behind. Although we may give many reasons that PKI provides > more security > >> and scalability, it's (relatively) easy config of PSK bring IKE to wide > >> adoption. > >> > >> -------------------------------------------- > >> Michael Shieh > >> NetScreen Technologies, Inc > >> -------------------------------------------- > >> > >> -----Original Message----- > >> From: Wang, Cliff [mailto:CWang@smartpipes.com] > >> Sent: Thursday, December 06, 2001 9:57 AM > >> To: 'Michael Thomas'; Alex Alten > >> Cc: Wang, Cliff; ipsec@lists.tislabs.com > >> Subject: RE: Please save the pre-shared key mode > >> > >> > >> Very simple reasons, > >> > >> IKEv1 is going to be replaced by IKEv2 in the future and KINK > has yet to > >be > >> standardized and it is not going to replace IKE. On the other > hand, adding > >> PSK support in IKEv2 is not an overkill, but provides much more > >> flexibilities and more choices for service providers. > >> > >> -----Original Message----- > >> From: Michael Thomas [mailto:mat@cisco.com] > >> Sent: Thursday, December 06, 2001 12:43 PM > >> To: Alex Alten > >> Cc: Wang, Cliff; ipsec@lists.tislabs.com > >> Subject: Re: Please save the pre-shared key mode > >> > >> > >> Alex Alten writes: > >> > > >> > I *strongly* 2nd this motion. It would be extremely foolish > to > >> eliminate PSK support. Foolish in this case translates into > lots of > >> extra expensive hardware, etc., for our poor customers. > >> > >> There are already two choices for keying IPsec SA's > >> with pre-shared keys with IETF protocols: > >> > >> 1) IKEv1 > >> 2) KINK > >> > >> The latter can be used peer-peer as well, and > >> fixes many of the problems with (1). Why then > >> do we need to have yet another? > >> > >> Mike > >> > > > > -- > >Jan Vilhuber > vilhuber@cisco.com > >Cisco Systems, San Jose > (408) 527-0847 > > > > > -- > > Alex Alten > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Fri Dec 7 05:12:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7DC8216316; Fri, 7 Dec 2001 05:12:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04136 Fri, 7 Dec 2001 07:34:26 -0500 (EST) Message-Id: <200112070321.fB73Lcpv013394@coredump.cs.columbia.edu> To: Dan Harkins Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-reply-to: Your message of "Thu, 06 Dec 2001 10:07:55 PST." <200112061808.fB6I7t301682@fatty.lounge.org> Date: Thu, 06 Dec 2001 22:21:38 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200112061808.fB6I7t301682@fatty.lounge.org>, Dan Harkins writes: > Actually to compare apples-to-apples you should note that >JFK only produces a single key, Kir, for a single IPsec SA >(I'm assuming it's the initiator's outbound although it's >not specified). To end up with a pair of IPsec SAs, one in >each direction, you'd need: > > Protocol Initiator Responder Latency > ------------------------------------------------ > JFK(normal) 2 signature 2 signature 4 RTT > 4 verifies 2 verify > 2 DH agree 2 DH agree > > JFK(PFS)[2] 2 signature 4 signatures 4 RTT > 4 verifies 2 verify > 2 DH agree 2 DH agree Now who's comparing apples to bananas ? :-) At the end of JFK, you get the same key material as you get with any of the other protocols (the result of a DH computation, mixed with some other randomness --- the nonces). You can stretch that to your heart's content, as has been done in all other protocols since the dawn of history -- IKE, Photuris, TLS. The initial key derivation process is intended to make the JFK session key and the application key (e.g., IPsec) independent (a la SKEYID). You can then apply the same PRF process to extend this to fit 3DES, AES, etc. In fact, that's what my students' reference implementations do (even though I never mentioned PRF to them, they found it on RFC 2409 by themselves). -Angelos From owner-ipsec@lists.tislabs.com Fri Dec 7 05:12:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7DCS216392; Fri, 7 Dec 2001 05:12:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04135 Fri, 7 Dec 2001 07:34:20 -0500 (EST) Message-Id: <200112070715.fB77FApv014233@coredump.cs.columbia.edu> To: Dan Harkins Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-reply-to: Your message of "Thu, 06 Dec 2001 13:24:43 PST." <200112062124.fB6LOh301908@fatty.lounge.org> Date: Fri, 07 Dec 2001 02:15:10 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200112062124.fB6LOh301908@fatty.lounge.org>, Dan Harkins writes: > RFC2409 uses something not defined anywhere in JFK to expand >keys (SKEYID_d) and two other things whose exact location can only >be guessed at (the SPI and protocol fields of an "sa" structure >which itself is not defined). If your students generated interoperable >implementations they deserve either an A+ for their omniscience or >an F for cheating. I think you're being a bit too literal. What they used was: K = K1 | K2 | K3 and K1 = HMAC({g^ir}(Ni,Nr,'1') K2 = HMAC(K1, Ni, Nr) K3 = HMAC(K2, Ni, Nr) -Angelos From owner-ipsec@lists.tislabs.com Fri Dec 7 05:12:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7DCU216405; Fri, 7 Dec 2001 05:12:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04119 Fri, 7 Dec 2001 07:33:17 -0500 (EST) Message-Id: <200112062130.fB6LUrpv003100@coredump.cs.columbia.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec@lists.tislabs.com Subject: Re: WG LAST CALL: draft-ietf-ipsec-sctp-02.txt Cc: kunzinge@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Dec 2001 16:30:53 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I have two comments: > >1. The formatting of the new ID_RECURSE is not yet defined, either in this >draft or in the DOI (RFC 2407). In particular, the interent draft should >cshow the format that would be used to list multiple "identities" within >the payload of the "ID_RECURSE": that is, does each individual ID entity >carry its own "type" and "length field". Stated differently, we need to >specify the format for what RFC 2407 calls the "Identification Data" to be >carried within the RECURSE_ID payload. Unless the RECURSE_ID formats are >defined in the DOI, I feel that the internet draft itself must include them >explicitly--otherwise, interoperability of implementations can not be >guaranteed. The included IDs do have their own type and length fields -- they're needed for parsing after all. Anyway, I'll add appropriate language in the draft. >2. (Nit picking) The name "ID_RECURSE" implies recursion, which is not >used. I would suggest using a name such as "ID_LIST", which is more >indicative of how this new field would be used. Ack. I've heard this from others, so I'll call it ID_LIST after all. Thanks, -Angelos From owner-ipsec@lists.tislabs.com Fri Dec 7 05:13:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7DDY216592; Fri, 7 Dec 2001 05:13:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04137 Fri, 7 Dec 2001 07:34:26 -0500 (EST) Message-Id: <200112070652.fB76qepv002274@coredump.cs.columbia.edu> To: Dan Harkins Cc: "Steven M. Bellovin" , Eric Rescorla , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-reply-to: Your message of "Thu, 06 Dec 2001 13:13:45 PST." <200112062113.fB6LDj301886@fatty.lounge.org> Date: Fri, 07 Dec 2001 01:52:40 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The draft leaves many things undefined; they are important, but given available time and effort, some things were more critical for inclusion in the draft. There's no reason why the PRF process or something similar cannot be used for two-SA key derivation. In message <200112062113.fB6LDj301886@fatty.lounge.org>, Dan Harkins writes: > Yes, you can but I guess what I'm saying is that you're not. You can >stretch it to produce bi-directional keys but such stretching is not >specified anywhere in JFK. > > In <200112042306.BAA16872@burp.tkv.asdf.org> Markku Savela mentioned >he preferred "a key negotiation [protocol] that only negotiates one >directional SA as requested by the kernel side of the IPSEC." That >is what JFK establishes today, a single session key for IPsec. > > If the intent, though, is that Kir should be stretched somehow to >produce bi-directional keys I withdraw my comment, but you really should >specify how. Leaving such things to the imagination of the implementor >will probably result in disinteroperability. > > Dan. > >On Thu, 06 Dec 2001 22:17:50 EST you wrote >> In message <200112061808.fB6I7t301682@fatty.lounge.org>, Dan Harkins writes: >> > Actually to compare apples-to-apples you should note that >> >JFK only produces a single key, Kir, for a single IPsec SA >> >(I'm assuming it's the initiator's outbound although it's >> >not specified). To end up with a pair of IPsec SAs, one in >> >each direction, you'd need: >> > >> > Protocol Initiator Responder Latency >> > ------------------------------------------------ >> > JFK(normal) 2 signature 2 signature 4 RTT >> > 4 verifies 2 verify >> > 2 DH agree 2 DH agree >> > >> > JFK(PFS)[2] 2 signature 4 signatures 4 RTT >> > 4 verifies 2 verify >> > 2 DH agree 2 DH agree >> > >> >> I'm afraid I don't understand what you're saying. JFK ends up with an >> authenticated DH exponential; we can clearly derive bidirectional keys >> from that. >> >> --Steve Bellovin, http://www.research.att.com/~smb >> Full text of "Firewalls" book now at http://www.wilyhacker.com >> >> From owner-ipsec@lists.tislabs.com Fri Dec 7 08:02:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7G23227143; Fri, 7 Dec 2001 08:02:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04452 Fri, 7 Dec 2001 10:06:34 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15376.56612.230403.971908@pkoning.dev.equallogic.com> Date: Fri, 7 Dec 2001 10:15:48 -0500 (EST) From: Paul Koning To: ipsec@lists.tislabs.com Subject: test X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Test (I have not seen several of my earlier posts to this list...) From owner-ipsec@lists.tislabs.com Fri Dec 7 08:02:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7G2n227393; Fri, 7 Dec 2001 08:02:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04511 Fri, 7 Dec 2001 10:27:22 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4087060EA@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: EKR , "IP Security List (E-mail)" Subject: RE: Some comments on JFK Date: Fri, 7 Dec 2001 07:37:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F35.14B97FE0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F35.14B97FE0 Content-Type: text/plain; charset="iso-8859-1" Eric, Ack! You are right, my appologies. I think we need to be very clear as to what the initial round trip is achieving. If al we need to do is to protect against the DoS attack then it is better to reconfigure the exchange so that DoS protection is an option for the responder if it discovers it is under DoS attack. The specification cannot force the responders to implement DoS protection, it can only require compliance with a certain message set. The cookie does not by itself provide DoS protection, only if the responder has some ability to filter out DoS attacks from particular IP addresses is there an actual protection against DoS. Sending the key exchange data in the initial exchange has the advantage of allowing the responder to make an informed decision as to whether to accept the request, defer it with a cookie challenge or reject it on the basis of the information in the request. I->R Request [x] R Are we under DoS attack? No perform key agreement, send R->I Response [x] Yes from specific sources Is I a specific source? Yes, send R->I Reject [x] No, send Response [x] Yes, from difuse source Send Challenge [x] This may appear to be complex, but that is the nature of a good DoS response. An implementation may still opt to implement challenges under all circumstances at the cost of always requiring an extra round trip. I reiterate the assertion that it is too early to go down grovelling at the bit level. We should look at the abstract protocol before getting into message size measuring contests. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Monday, December 03, 2001 2:10 PM > To: Hallam-Baker, Phillip > Cc: Angelos D. Keromytis; ipsec@lists.tislabs.com > Subject: Re: Some comments on JFK > > > "Hallam-Baker, Phillip" writes: > > > [1 ] > > > Yes, but purpose of forcing the initiator to spend cycles > before the > > > responder is for DoS prevention, not rate throttling of legitimate > > > initiators, no? > > > > Carefull, you don't 'force' the initiator to spend cycles before the > > responder. What you actually do is to force the initiator > to prove that > > it can recieve packets sent to the purported initiator > address before > > the responder spends cycles. > > > > The initiator can send any old junk to the respinder and > the responder > > will not know until the cycles are spent. > This was exactly my point. > > The draft says: > > The Initiator bears the initial computational burden > and must establish round-trip communication with the Responder > before the latter is required to perform expensive operations. > > This text suggests that the fact that the initiator performs > the DH operation first protects against DoS. As far as I can > tell it does not. > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > ------_=_NextPart_000_01C17F35.14B97FE0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F35.14B97FE0-- From owner-ipsec@lists.tislabs.com Fri Dec 7 08:30:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7GUF200254; Fri, 7 Dec 2001 08:30:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04539 Fri, 7 Dec 2001 10:49:53 -0500 (EST) From: ryuan@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A018908F9@email.quarrytech.com> To: sarab@cs.Technion.AC.IL, sommerfeld@east.sun.com, ipsec@lists.tislabs.com Subject: RE: Please kill preshared key. Date: Fri, 7 Dec 2001 10:58:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sara, Bill and All: I second the opinion to keep preshared symmetric key in IKEv2. * Shared secret authentication is simpler and works fine in a small domain. * As Sara pointed out, the performance is better. * Sure, it adds more complexity, but the same argument can be made for public key also. The key is to weigh the added complexity against the benefit it derives. IMHO, the benefit outweighs the complexity. * To rescind a working feature that is widely deployed is always problematic. If we further consider how authentication is being done in other applications, we see symmetric algorithms still being widely applied, they have not being replaced by asymmetric algorithms. --- Ruixi -----Original Message----- From: Sara Bitan [mailto:sarab@cs.Technion.AC.IL] Sent: Friday, December 07, 2001 1:14 AM To: sommerfeld@east.sun.com; ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. Hi Bill! Let's try to look at the details: ----- Original Message ----- From: Bill Sommerfeld To: Sent: Thursday, December 06, 2001 8:47 PM Subject: Please kill preshared key. > Since there are people arguing to save preshared key, I just wanted to > reemphasize that: > > 0) it adds cryptographic complexity -- you essentially need a > different cryptographic protocol for PSK vs. signature keys. Let's > spend the cycles of our cryptographers on more important stuff than > this. IKE-SIGAM (and I think IKEv2 also, if PKS authentication is added) with pre-shared key authentication differ from signatures authentication is *exactly two points* 1) The calculation of SKEYID in IKE-SIGMA and of SKEYSEED in IKEv2. 2) If you are using signatures authentication you add a signature and signture verification on top of the hash calculation. > > 1) it adds YET ONE MORE OPTION you need to test, one more knob you > can misconfigure.. more time for customers spent fumbling around > trying to figure out how to configure systems. One option out of how many options? Is this really the one that will turn a product from an easy to configure one to a non-configurable? > > 2) equivalent functionality can be found in preconfigured public keys > and/or self-signed certificates. Is performance a non-issue? How many CPU cycles are consumed by HMAC-SHA1? How many are consumed by RSA/DSA signature? What about extra hardware I might need to add if public cryptography based authentication is a must? What if I am a cellular vendor? PDA? > > There's no need for it, it adds complexity. Kill it. > > - Bill There is a need. Yes, it adds one more option, but the (small amount of) complexity added here is justified, and we must support it, Sara From owner-ipsec@lists.tislabs.com Fri Dec 7 09:06:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7H60202235; Fri, 7 Dec 2001 09:06:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04616 Fri, 7 Dec 2001 11:15:54 -0500 (EST) Message-ID: <3C10EC5D.CD2B4B6A@nortelnetworks.com> Date: Fri, 07 Dec 2001 11:20:45 -0500 From: "Marcus D. Leech" Organization: Nortel Networks: Information Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Bill Sommerfeld , ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The current PSK methods in IKEv1 lead to some horrible, insecure hacks in real implementations/deployments. I know of at least one VPN/Road-Warrior implementation where the server uses PSK to authenticate itself to a client--but it uses the SAME PSK for every member of a "group", where groups are very large. This means that anyone in the group can pretend to be a server to any other member of the group. This wouldn't happen in a self-signed PK-style pre-share. The client adds the PK self-signed pre-share to their "trusted" list, and only the real server (possessor of the private key) can convince a client of its authenticity. If symmetric PSKs are kept, it had better be possible to do it right, and rather hard to do it wrong. From owner-ipsec@lists.tislabs.com Fri Dec 7 09:28:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7HSb203436; Fri, 7 Dec 2001 09:28:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04679 Fri, 7 Dec 2001 11:55:01 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Marcus D. Leech" , "Jan Vilhuber" Cc: "Bill Sommerfeld" , References: <3C10EC5D.CD2B4B6A@nortelnetworks.com> Subject: Re: Please kill preshared key. Date: Fri, 7 Dec 2001 12:05:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 07 Dec 2001 17:04:14.0721 (UTC) FILETIME=[32EEFF10:01C17F41] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds like a good haker taget, can you share with everyone which is this entity? :-) --- David ----- Original Message ----- From: "Marcus D. Leech" To: "Jan Vilhuber" Cc: "Bill Sommerfeld" ; Sent: Friday, December 07, 2001 11:20 AM Subject: Re: Please kill preshared key. > The current PSK methods in IKEv1 lead to some horrible, insecure hacks > in real > implementations/deployments. > > I know of at least one VPN/Road-Warrior implementation where the server > uses > PSK to authenticate itself to a client--but it uses the SAME PSK for > every > member of a "group", where groups are very large. This means that > anyone in > the group can pretend to be a server to any other member of the group. > This wouldn't happen in a self-signed PK-style pre-share. The > client adds the PK self-signed pre-share to their "trusted" list, and > only the real server (possessor of the private key) can convince a > client > of its authenticity. > > If symmetric PSKs are kept, it had better be possible to do it right, > and > rather hard to do it wrong. > From owner-ipsec@lists.tislabs.com Fri Dec 7 09:29:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7HT6203476; Fri, 7 Dec 2001 09:29:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04666 Fri, 7 Dec 2001 11:45:39 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15376.62551.423979.312570@thomasm-u1.cisco.com> Date: Fri, 7 Dec 2001 08:54:47 -0800 (PST) To: Paul Koning Cc: mat@cisco.com, CWang@smartpipes.com, ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <15376.54947.458903.672254@pkoning.dev.equallogic.com> References: <4652644B98DFF34696801F8F3070D3FE011884A8@D2CSPEXM001.smartpipes.com> <15375.53966.77967.411018@pkoning.dev.equallogic.com> <15375.63067.104625.569813@thomasm-u1.cisco.com> <15376.54947.458903.672254@pkoning.dev.equallogic.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 The fundamental mistake you're making here is giving special status to the name of *a* non-working group draft which calls itself IKEv2. It's not decided whether the working group will take IKEv2 as the basis of SOI, nor is it clear that the WG will call it "IKEv2" even if it did. Again, what is important at this point is setting the requirements to evaluate all of the candidate protocols. The requirements currently do not say that SOI will be everything that IKEv1 is and more. If you want the requirements to specifically say this, I think you need to get WG consensus for that, which I doubt there currently is. Mike Paul Koning writes: > >>>>> "Michael" == Michael Thomas writes: > > Michael> Paul Koning writes: > >> >>>>> "Wang," == Wang, Cliff writes: > >> > >> Wang,> Very simple reasons, IKEv1 is going to be replaced by IKEv2 > >> in Wang,> the future and KINK has yet to be standardized and it is > >> not Wang,> going to replace IKE. On the other hand, adding PSK > >> support in Wang,> IKEv2 is not an overkill, but provides much more > >> flexibilities Wang,> and more choices for service providers. > >> > >> Agreed. > >> > >> It makes no sense to call a protocol XYZv2 if you're removing from > >> it one of the very widely used features of XYZv1. > >> > >> If you want a protocol without preshared keys, feel free, but then > >> don't call it IKE and don't expect people to give up IKEv1. > > Michael> The name of protocol is irrelevant at this point. > > I don't agree. > > Its name *is* relevant if it is a name that says "this is the second > version of a previously defined protocol, intended to supersede the > first version". And that is the name currently given to the draft. > > So... is the intent that this protocol is supposed to be viewed as a > replacement for the protocol defined in RFC 2408/2409? Or is it > supposed to be considered a new, unrelated, protocol? > > If the latter, then the requirements set is open. But if the former, > then the new protocol MUST include among its requirements all the > features of the earlier protocol that are important. It is clear from > looking at customer installations that pre-shared key is a critical > feature of IKE. > > Another point: if the problem with IKEv1 is that it has too many > options -- which is a fair point -- how does it help matters to define > yet another protocol that products will have to implement IN ADDITION > to the already existing complex protocol? Why bother? If the goal is > to improve matters for implementers and customers, the goal should be > to create a new protocol which is indeed a viable replacement for the > previous protocol, fully entitled to the name "IKE V2" because it > incorporates the capabilities for which there is a proven need while > cleaning up in other areas. > > So what are we doing? Creating more protocols that increase > everyone's burden, or making things simpler? > > paul > From owner-ipsec@lists.tislabs.com Fri Dec 7 09:39:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7HdQ204015; Fri, 7 Dec 2001 09:39:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04693 Fri, 7 Dec 2001 12:02:28 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698B5@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , "Hallam-Baker, Phillip" Cc: "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? Date: Fri, 7 Dec 2001 09:12:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F42.5DE08990" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F42.5DE08990 Content-Type: text/plain; charset="iso-8859-1" First let us be clear about the different types of dynamic address. In practice very few addresses are genuinely 'dynamic'. Second, in this I will talk about 'certificates' since they are what the group are familliar with. But remember that this is simply a shorthand for 'binding of data to a private key' and there might be a scheme such as XKMS supporting the use. 1) The Address is actually static but is dynamically reallocated for operational reasons. E.G. most cable modem addresses which rarely change (unless excite goes bankrupt that week). Can issue a certificate bound to the IP address If the IP address changes, revoke & reissue (note, probably want to use XKMS rather than CRLs!) 2) The Address is dynamic being allocated each time from a fixed pool. E.G. dial up access Here we have a number of approaches, A) Generate a key / cert for each address in the pool. When the initiator attempts to connect to the responder with the client credential, the request is intercepted at the POP. The POP first performs a key agreement using the key bound to the IP address, then once the tunnel is created forwards the client request through the tunnel. B) Use disposable key / cert pairs. The initiator applies for a pool of key/cert pairs which are cached. These are discarded after a single use. The disposable key/cert pair may not even be certified by a trusted third party, it may be self signed. C) Issue a certificate that has a wild card in it E.G. 18.23.1.* (think binary mask) While the cost of such systems may appear high the concealment of identity is inherently an expensive process IF DONE WELL. If the concealment is poor then better not to bother at all. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Wednesday, December 05, 2001 3:33 PM > To: Hallam-Baker, Phillip > Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com > Subject: Re: Son-of-IKE Selection Criteria? > > > Phill, > > "Hallam-Baker, Phillip" writes: > > > 1. Issue every device an IP identity credential bound to > its IP address. > > This is the ONLY form of identity that can provably prevent any > > additional disclosure of identity in an IP environment > since your > > IP address is known in any case. > > > > 2. Perform two sequential key agreements, ] > > first an IP address based agreement > > second an identity based agreement encrypted under the > key of (1). > > > > How would you cope with machines with dynamic IP address? > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > ------_=_NextPart_000_01C17F42.5DE08990 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F42.5DE08990-- From owner-ipsec@lists.tislabs.com Fri Dec 7 10:26:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7IQO205518; Fri, 7 Dec 2001 10:26:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04787 Fri, 7 Dec 2001 12:38:50 -0500 (EST) Message-Id: <200112070844.fB78iA600456@fatty.lounge.org> To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com Subject: Re: Comments on IKEv2 In-Reply-To: Your message of "Fri, 07 Dec 2001 11:05:05 +0300." <200112070805.LAA07554@relay1.trustworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <453.1007714650.1@tibernian.com> Date: Fri, 07 Dec 2001 00:44:10 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery, zdrastii! On Fri, 07 Dec 2001 11:05:05 +0300 you wrote > > on what criteria could responder base his decision to narrow TS? > Assume the following situation: initiator offers wildcard TSS, while > responder's SPD consists of several adjacent ranges. The very natural > decision for him is to select and sent back to initiator one of these > ranges. But which? He doesn't have enough information because > initiator has no ability to tell him what exact packet she is trying > to make SA for. If this information were provided by initiator (via > special payload or by requiring the first TSS in TS to always > represent the actual IP packet triggered this negotiation), this > would increase robustness of the protocol. The Responder could send back all of them. If the packet that triggered the Initiator's negotiation was not included in what the Responder sent back then those packets would not be sent after negotiation for the subset succeeded (I'd imagine that if the Initiator is a gateway it would send back some "administratively prohibited by filter" message back to the source). But that is what happens when the Responder does not allow the Initiator to access what she (the Initiator) wants to access. No way around that. Requiring the first TSS in the TS to always represent the actual IP packet triggering the negotiation is an interesting idea but it wouldn't solve the problem you described-- the packet matched a wildcard selector. Or are you suggesting that no negotiation should succeed? That is, the Responder says "no proposal chosen" instead of sending back a TS subset? > And one more comment. The peers seem to have no ability to inform > each other about what kind of signature (RSA or DSA) they will use. > Why so? This will require all implementation to support both (or even > more if ECDSA come later) to be interoperable. Wouldn't it be better > to negotiate this, as well as cipher, hash and group? Can't you infer what signature the peer supports? If you are using a pre-shared public key you know directly. If you are enrolled in a CA you should know what types of certs it will issue, no? If it issues certs for both RSA and DSA public keys then you have to support them both. If it issue certs for just one then you just have to support that one. I would imagine that people want to make their product as versatile as possible, though, and support them both regardless of whether a magic number is used to indicate up-front which signature will be used. Dan. From owner-ipsec@lists.tislabs.com Fri Dec 7 10:32:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7IWw205686; Fri, 7 Dec 2001 10:32:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04848 Fri, 7 Dec 2001 12:45:05 -0500 (EST) To: "Hallam-Baker, Phillip" Cc: "IP Security List (E-mail)" Subject: Re: Some comments on JFK References: <2F3EC696EAEED311BB2D009027C3F4F4087060EA@vhqpostal.verisign.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 07 Dec 2001 09:53:39 -0800 In-Reply-To: "Hallam-Baker, Phillip"'s message of "Fri, 7 Dec 2001 07:37:30 -0800" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hallam-Baker, Phillip" writes: > I think we need to be very clear as to what the initial round trip > is achieving. If al we need to do is to protect against the DoS attack then > it is better to reconfigure the exchange so that DoS protection is an option > for the responder if it discovers it is under DoS attack. I totally agree. My read of JFK, however, is that the first round trip also is required to provide identity protection (which you've said you don't much care for and I'm not sure I like either.) In this respect JFK differs from IKEv2 and SIGMA, both of which require an extra round trip in order to do DoS protection (because they don't have a faster "no PFS" mode). -Ekr From owner-ipsec@lists.tislabs.com Fri Dec 7 10:34:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7IYl205772; Fri, 7 Dec 2001 10:34:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04827 Fri, 7 Dec 2001 12:43:08 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15377.462.548877.629368@thomasm-u1.cisco.com> Date: Fri, 7 Dec 2001 09:52:14 -0800 (PST) To: "Hallam-Baker, Phillip" Cc: "'Derek Atkins'" , "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058698B5@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4058698B5@vhqpostal.verisign.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 I'm not sure whether this is applicable to this thread or not, but if we're talking about expectation of long lived IP addresses, I think that we better consider whether IP6's disposable addresses for privacy are an issue, not to mention renumbering. Mike Hallam-Baker, Phillip writes: > First let us be clear about the different types of dynamic address. In > practice very few addresses are genuinely 'dynamic'. > > Second, in this I will talk about 'certificates' since they are what the > group are familliar with. But remember that this is simply a shorthand for > 'binding of data to a private key' and there might be a scheme such as XKMS > supporting the use. > > 1) The Address is actually static but is dynamically reallocated for > operational reasons. > E.G. most cable modem addresses which rarely change (unless excite > goes bankrupt that week). > > Can issue a certificate bound to the IP address > > If the IP address changes, revoke & reissue (note, probably want to > use XKMS rather than CRLs!) > > 2) The Address is dynamic being allocated each time from a fixed pool. > E.G. dial up access > > Here we have a number of approaches, > > A) Generate a key / cert for each address in the pool. > When the initiator attempts to connect to the responder with the > client credential, the request is intercepted at the POP. The POP first > performs a key agreement using the key bound to the IP address, then once > the tunnel is created forwards the client request through the tunnel. > > B) Use disposable key / cert pairs. > The initiator applies for a pool of key/cert pairs which are cached. > These are discarded after a single use. The disposable key/cert pair may not > even be certified by a trusted third party, it may be self signed. > > C) Issue a certificate that has a wild card in it > E.G. 18.23.1.* (think binary mask) > > > While the cost of such systems may appear high the concealment of identity > is inherently an expensive process IF DONE WELL. If the concealment is poor > then better not to bother at all. > > Phill > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Wednesday, December 05, 2001 3:33 PM > > To: Hallam-Baker, Phillip > > Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com > > Subject: Re: Son-of-IKE Selection Criteria? > > > > > > Phill, > > > > "Hallam-Baker, Phillip" writes: > > > > > 1. Issue every device an IP identity credential bound to > > its IP address. > > > This is the ONLY form of identity that can provably prevent any > > > additional disclosure of identity in an IP environment > > since your > > > IP address is known in any case. > > > > > > 2. Perform two sequential key agreements, ] > > > first an IP address based agreement > > > second an identity based agreement encrypted under the > > key of (1). > > > > > > > How would you cope with machines with dynamic IP address? > > > > -derek > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > > From owner-ipsec@lists.tislabs.com Fri Dec 7 10:43:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7IhP206495; Fri, 7 Dec 2001 10:43:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04913 Fri, 7 Dec 2001 13:02:34 -0500 (EST) Message-ID: From: Jon Sjoberg x 158 To: ipsec@lists.tislabs.com Subject: RE: Please kill preshared key. Date: Fri, 7 Dec 2001 13:11:19 -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 Just a random thought, Would it help if we changed the terminology from Pre-Shared Key to Pre-Shared Information, as it seems that is all end-users care about. The type of the information (be it key or self-signed cert) that is shared should be of little interest to an end-user, so long as the performance and security characteristics are acceptable. All that is interesting to the end-user is that the ease of set-up obtained by being able to pre-share information with out engaging a third party. I think using PSK and PKI as terms may be feeding confusion, especially since using pre-shared certificates is not what most consider a Public Key Infrastructure. Food for thought, Jon -----Original Message----- From: Marcus D. Leech [mailto:mleech@nortelnetworks.com] Sent: Friday, December 07, 2001 11:21 AM To: Jan Vilhuber Cc: Bill Sommerfeld; ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. The current PSK methods in IKEv1 lead to some horrible, insecure hacks in real implementations/deployments. I know of at least one VPN/Road-Warrior implementation where the server uses PSK to authenticate itself to a client--but it uses the SAME PSK for every member of a "group", where groups are very large. This means that anyone in the group can pretend to be a server to any other member of the group. This wouldn't happen in a self-signed PK-style pre-share. The client adds the PK self-signed pre-share to their "trusted" list, and only the real server (possessor of the private key) can convince a client of its authenticity. If symmetric PSKs are kept, it had better be possible to do it right, and rather hard to do it wrong. From owner-ipsec@lists.tislabs.com Fri Dec 7 10:45:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Iix206631; Fri, 7 Dec 2001 10:44:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04919 Fri, 7 Dec 2001 13:02:43 -0500 (EST) Message-Id: <200112070908.fB798C600531@fatty.lounge.org> To: "Marcus D. Leech" Cc: ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. In-Reply-To: Your message of "Fri, 07 Dec 2001 11:20:45 EST." <3C10EC5D.CD2B4B6A@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <528.1007716092.1@tibernian.com> Date: Fri, 07 Dec 2001 01:08:12 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are a few that do that and the reason they do is that they want to use some legacy authentication technique to authenticate "the client". And the reason they are forced to do this insecure hack is because it was prohibited to add support for this type of authentication technique directly into IKE (e.g. CRACK). People will get what they want somehow someway. And giving someone something they don't want will force them to look for novel (and most likely insecure) ways to get what they want. We can make it hard to do it wrong by making it easy to do it right. Dan. On Fri, 07 Dec 2001 11:20:45 EST you wrote > The current PSK methods in IKEv1 lead to some horrible, insecure hacks > in real > implementations/deployments. > > I know of at least one VPN/Road-Warrior implementation where the server > uses > PSK to authenticate itself to a client--but it uses the SAME PSK for > every > member of a "group", where groups are very large. This means that > anyone in > the group can pretend to be a server to any other member of the group. > This wouldn't happen in a self-signed PK-style pre-share. The > client adds the PK self-signed pre-share to their "trusted" list, and > only the real server (possessor of the private key) can convince a > client > of its authenticity. > > If symmetric PSKs are kept, it had better be possible to do it right, > and > rather hard to do it wrong. From owner-ipsec@lists.tislabs.com Fri Dec 7 11:12:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7JCw208312; Fri, 7 Dec 2001 11:12:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04987 Fri, 7 Dec 2001 13:20:32 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698B8@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Michael Thomas'" , "Hallam-Baker, Phillip" Cc: "'Derek Atkins'" , "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? Date: Fri, 7 Dec 2001 10:30:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F4D.43139250" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F4D.43139250 Content-Type: text/plain; charset="iso-8859-1" Michael, Could you expand a bit more here? I do not follow IPv6 deployment is much detail and I suspect many other do not. What is the current staus of disposable addresses? Are they likely to be widely deployed? How does the mechanism work, does it depend on security properties in the key exchange? I am not opposed to identity concealment, but I am opposed to a scheme that cryptographically gives half a loaf. If we can push identity concealment out of the key exchange into another area and by doing so do the job properly I would be much happier. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, December 07, 2001 12:52 PM > To: Hallam-Baker, Phillip > Cc: 'Derek Atkins'; 'Walker, Jesse'; ipsec@lists.tislabs.com > Subject: RE: Son-of-IKE Selection Criteria? > > > > I'm not sure whether this is applicable to this > thread or not, but if we're talking about > expectation of long lived IP addresses, I think > that we better consider whether IP6's disposable > addresses for privacy are an issue, not to mention > renumbering. > > Mike > > Hallam-Baker, Phillip writes: > > First let us be clear about the different types of dynamic > address. In > > practice very few addresses are genuinely 'dynamic'. > > > > Second, in this I will talk about 'certificates' since > they are what the > > group are familliar with. But remember that this is simply > a shorthand for > > 'binding of data to a private key' and there might be a > scheme such as XKMS > > supporting the use. > > > > 1) The Address is actually static but is dynamically > reallocated for > > operational reasons. > > E.G. most cable modem addresses which rarely change > (unless excite > > goes bankrupt that week). > > > > Can issue a certificate bound to the IP address > > > > If the IP address changes, revoke & reissue (note, > probably want to > > use XKMS rather than CRLs!) > > > > 2) The Address is dynamic being allocated each time from a > fixed pool. > > E.G. dial up access > > > > Here we have a number of approaches, > > > > A) Generate a key / cert for each address in the pool. > > When the initiator attempts to connect to the responder with the > > client credential, the request is intercepted at the POP. > The POP first > > performs a key agreement using the key bound to the IP > address, then once > > the tunnel is created forwards the client request through > the tunnel. > > > > B) Use disposable key / cert pairs. > > The initiator applies for a pool of key/cert pairs > which are cached. > > These are discarded after a single use. The disposable > key/cert pair may not > > even be certified by a trusted third party, it may be self signed. > > > > C) Issue a certificate that has a wild card in it > > E.G. 18.23.1.* (think binary mask) > > > > > > While the cost of such systems may appear high the > concealment of identity > > is inherently an expensive process IF DONE WELL. If the > concealment is poor > > then better not to bother at all. > > > > Phill > > > > > > Phillip Hallam-Baker FBCS C.Eng. > > Principal Scientist > > VeriSign Inc. > > pbaker@verisign.com > > 781 245 6996 x227 > > > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > Sent: Wednesday, December 05, 2001 3:33 PM > > > To: Hallam-Baker, Phillip > > > Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com > > > Subject: Re: Son-of-IKE Selection Criteria? > > > > > > > > > Phill, > > > > > > "Hallam-Baker, Phillip" writes: > > > > > > > 1. Issue every device an IP identity credential bound to > > > its IP address. > > > > This is the ONLY form of identity that can > provably prevent any > > > > additional disclosure of identity in an IP environment > > > since your > > > > IP address is known in any case. > > > > > > > > 2. Perform two sequential key agreements, ] > > > > first an IP address based agreement > > > > second an identity based agreement encrypted under the > > > key of (1). > > > > > > > > > > How would you cope with machines with dynamic IP address? > > > > > > -derek > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > > warlord@MIT.EDU PGP key available > > > > > > ------_=_NextPart_000_01C17F4D.43139250 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F4D.43139250-- From owner-ipsec@lists.tislabs.com Fri Dec 7 11:15:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7JF2208356; Fri, 7 Dec 2001 11:15:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05033 Fri, 7 Dec 2001 13:24:26 -0500 (EST) Date: Fri, 7 Dec 2001 13:33:36 -0500 (EST) From: Henry Spencer To: "Wang, Cliff" cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884BB@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: >>> other hand, PSK based IKE and PKI based IKE has been the main way people >>> deploying VPN. Under that context, PSK is simpler to run than PKI. >> I think that's the myth Dan was talking about. > > From the operation point of view, PSK is quick and easy to set up service. > It works and customers are happy. It is more real than a myth. The myth being referred to is the notion that PSK is somehow unique in being quick and easy to set up, because public keys absolutely require PKI. That's wrong. It is just as quick and easy to set up with preshared *public* keys. You don't need a PKI to use public keys. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 11:22:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7JM6208614; Fri, 7 Dec 2001 11:22:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05125 Fri, 7 Dec 2001 13:41:24 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15377.3933.4072.980558@thomasm-u1.cisco.com> Date: Fri, 7 Dec 2001 10:50:05 -0800 (PST) To: "Hallam-Baker, Phillip" Cc: "'Michael Thomas'" , "'Derek Atkins'" , "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058698B8@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4058698B8@vhqpostal.verisign.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 Hallam-Baker, Phillip writes: > Michael, > > Could you expand a bit more here? I do not follow IPv6 deployment is > much detail and I suspect many other do not. > > What is the current staus of disposable addresses? Are they likely to be > widely deployed? How does the mechanism work, does it depend on security > properties in the key exchange? With IP6, the bottom 64 bits of the unicast address are, essentially, a host identifier. When a host configures an interface, it generally auto-configures its interface addresses for its link, site and global prefixes, usually using router advertisements to figure that out. It does this by taking the prefix and appending on something to the lower 64 bits. Those can be be a long-lived NAI (MAC address) which should be unique, or the host can create a temporary address(es) if it wants privacy. In all cases, it's required to do duplicate address detection to check for collisions. Theoretically, it can create as many private addresses as it wants, as often as it wants. This is purely an implementation issue of the host; I don't know whether certain well known OS vendors are implementing it in their v6 stack yet. Now, again, I'm not sure whether that's applicable here or not. My sense is that this is a worthwhile general discussion since we also should consider the implications of multihoming, mobility and renumbering which want to change the high 64 bits (eg, the prefix). As far as I understand, IPsec doesn't play very well with these (eg, would require separate sessions). I've been meaning to bring this up, but have been lacking on time... Mike From owner-ipsec@lists.tislabs.com Fri Dec 7 11:26:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7JQC208829; Fri, 7 Dec 2001 11:26:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05135 Fri, 7 Dec 2001 13:42:42 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884C1@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Henry Spencer'" Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 18:51:54 -0000 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 Unfortuanately, the pre-shared public key option is not widely avaialble in most products which service provider can use. Among the available solutions, PSK is easier, simpler, and more efficient to run than a PKI based solution. Is that also a myth? -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Friday, December 07, 2001 1:34 PM To: Wang, Cliff Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Wang, Cliff wrote: >>> other hand, PSK based IKE and PKI based IKE has been the main way people >>> deploying VPN. Under that context, PSK is simpler to run than PKI. >> I think that's the myth Dan was talking about. > > From the operation point of view, PSK is quick and easy to set up > service. It works and customers are happy. It is more real than a > myth. The myth being referred to is the notion that PSK is somehow unique in being quick and easy to set up, because public keys absolutely require PKI. That's wrong. It is just as quick and easy to set up with preshared *public* keys. You don't need a PKI to use public keys. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 12:08:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7K81210056; Fri, 7 Dec 2001 12:08:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05341 Fri, 7 Dec 2001 14:26:17 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3A53@NS-CA> From: Michael Choung Shieh To: "'Henry Spencer'" , "Wang, Cliff" Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 11:33:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about someone unwrap the myth. I don't care if it's PK or PSK as long as we can set it up as easy as setup PSK in IKE v1. Can someone show step-by-step procedure to set up PK? In a typical scenario, the HQ sys admin sets up vpn and sends config to his unknowledged remote offic peer to download to remote device. How do we do it when using PK without using PKI? Let's prove if it's as easy as setting up PSK. -------------------------------------------- Michael Shieh NetScreen Technologies, Inc 350 Oakmead Parkway Sunnyvale, CA 94085 TEL: (408)730-6060 FAX: (408)730-6050 Email: mshieh@netscreen.com -------------------------------------------- -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Friday, December 07, 2001 10:34 AM To: Wang, Cliff Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Wang, Cliff wrote: >>> other hand, PSK based IKE and PKI based IKE has been the main way people >>> deploying VPN. Under that context, PSK is simpler to run than PKI. >> I think that's the myth Dan was talking about. > > From the operation point of view, PSK is quick and easy to set up service. > It works and customers are happy. It is more real than a myth. The myth being referred to is the notion that PSK is somehow unique in being quick and easy to set up, because public keys absolutely require PKI. That's wrong. It is just as quick and easy to set up with preshared *public* keys. You don't need a PKI to use public keys. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 12:14:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KEm210336; Fri, 7 Dec 2001 12:14:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05380 Fri, 7 Dec 2001 14:37:15 -0500 (EST) Message-Id: <200112071042.fB7AgkG00861@fatty.lounge.org> To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: Your message of "Fri, 07 Dec 2001 08:54:47 PST." <15376.62551.423979.312570@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <858.1007721766.1@tibernian.com> Date: Fri, 07 Dec 2001 02:42:46 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The draft which calls itself IKEv2 _is_ a working group draft. Dan. On Fri, 07 Dec 2001 08:54:47 PST you wrote > > The fundamental mistake you're making here is > giving special status to the name of *a* > non-working group draft which calls itself IKEv2. > It's not decided whether the working group will > take IKEv2 as the basis of SOI, nor is it clear > that the WG will call it "IKEv2" even if it did. > > Again, what is important at this point is setting > the requirements to evaluate all of the candidate > protocols. The requirements currently do not say > that SOI will be everything that IKEv1 is and > more. If you want the requirements to > specifically say this, I think you need to get WG > consensus for that, which I doubt there currently > is. > > Mike > > > Paul Koning writes: > > >>>>> "Michael" == Michael Thomas writes: > > > > Michael> Paul Koning writes: > > >> >>>>> "Wang," == Wang, Cliff writes: > > >> > > >> Wang,> Very simple reasons, IKEv1 is going to be replaced by IKEv2 > > >> in Wang,> the future and KINK has yet to be standardized and it is > > >> not Wang,> going to replace IKE. On the other hand, adding PSK > > >> support in Wang,> IKEv2 is not an overkill, but provides much more > > >> flexibilities Wang,> and more choices for service providers. > > >> > > >> Agreed. > > >> > > >> It makes no sense to call a protocol XYZv2 if you're removing from > > >> it one of the very widely used features of XYZv1. > > >> > > >> If you want a protocol without preshared keys, feel free, but then > > >> don't call it IKE and don't expect people to give up IKEv1. > > > > Michael> The name of protocol is irrelevant at this point. > > > > I don't agree. > > > > Its name *is* relevant if it is a name that says "this is the second > > version of a previously defined protocol, intended to supersede the > > first version". And that is the name currently given to the draft. > > > > So... is the intent that this protocol is supposed to be viewed as a > > replacement for the protocol defined in RFC 2408/2409? Or is it > > supposed to be considered a new, unrelated, protocol? > > > > If the latter, then the requirements set is open. But if the former, > > then the new protocol MUST include among its requirements all the > > features of the earlier protocol that are important. It is clear from > > looking at customer installations that pre-shared key is a critical > > feature of IKE. > > > > Another point: if the problem with IKEv1 is that it has too many > > options -- which is a fair point -- how does it help matters to define > > yet another protocol that products will have to implement IN ADDITION > > to the already existing complex protocol? Why bother? If the goal is > > to improve matters for implementers and customers, the goal should be > > to create a new protocol which is indeed a viable replacement for the > > previous protocol, fully entitled to the name "IKE V2" because it > > incorporates the capabilities for which there is a proven need while > > cleaning up in other areas. > > > > So what are we doing? Creating more protocols that increase > > everyone's burden, or making things simpler? > > > > paul > > From owner-ipsec@lists.tislabs.com Fri Dec 7 12:16:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KGa210374; Fri, 7 Dec 2001 12:16:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05303 Fri, 7 Dec 2001 14:11:07 -0500 (EST) Date: Fri, 7 Dec 2001 14:20:19 -0500 (EST) From: Henry Spencer To: "Wang, Cliff" cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884C1@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: >> The myth being referred to is the notion that PSK is somehow unique in >> being quick and easy to set up, because public keys absolutely require PKI. >> That's wrong. It is just as quick and easy to set up with preshared >> *public* keys. You don't need a PKI to use public keys. > > Unfortuanately, the pre-shared public key option is not widely avaialble in > most products which service provider can use... The protocols which we are currently discussing are not widely available in most products, indeed they are not available at all in any products. We are discussing how a new protocol should be designed. Options which are not generally available in current protocols can be made generally available in new ones. > Among the available solutions, > PSK is easier, simpler, and more efficient to run than a PKI based solution. > Is that also a myth? No, it is merely irrelevant. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 12:25:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KPa210682; Fri, 7 Dec 2001 12:25:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05448 Fri, 7 Dec 2001 14:48:54 -0500 (EST) Date: Fri, 7 Dec 2001 11:57:40 -0800 (PST) From: Jan Vilhuber To: "Wang, Cliff" cc: "'Dan McDonald'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884BB@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: > >From the operation point of view, PSK is quick and easy to set up service. > It works and customers are happy. It is more real than a myth. > The myth is that nothing else works. PSK is a behind-the-scenes abstraction, that good programmers can hide from users altogether. A good UI can hide any other mechanism as well and make it as easy to configure. jan > > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Thursday, December 06, 2001 6:39 PM > To: Wang, Cliff > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > On the > > other hand, PSK based IKE and PKI based IKE has been the main way people > > deploying VPN. Under that context, PSK is simpler to run than PKI. > > > I think that's the myth Dan was talking about. > > jan > > > > > > > -----Original Message----- > > From: Dan McDonald [mailto:danmcd@east.sun.com] > > Sent: Thursday, December 06, 2001 1:28 PM > > To: Wang, Cliff > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Please save the pre-shared key mode > > > > > > > 1) Simplicity > > > Pre-shared key mode is simpler to support by eliminating the > > > requirement of supporting complex PKI. > > > > It's a myth that public-key implies you MUST have a PKI. > > > > Self-signed certs combined with explicit out-of-band trust models is > > just a non-cumbersome as pre-shared keys, IMHO, and they also offer > > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > > FreeSWAN has a self-signed cert model that works, right?) > > > > If we keep pre-shared, let's have a scalable way of identifying them. > > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > > pairs is as much hassle as PKI registration (it's just less snake-oil > > than most PKIs ;). > > > > For testing, I run server machines with self-signed certs. For small > > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > > of the PKI cruft. Peer-to-peer explosions is about the only case > > where PKI is really needed, and pre-shared won't help you any there > > either. It's just a matter of running certificate-generation, e-mail, > > and verifying hashes out-of-band. > > > > I'm not totally against nuking pre-shared. It's not, however, the > > panacea of simplicity many think it is, and simplicity arguments don't > > hold water. > > > > Dan > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 12:27:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KRg210828; Fri, 7 Dec 2001 12:27:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05370 Fri, 7 Dec 2001 14:35:25 -0500 (EST) Date: Fri, 7 Dec 2001 14:44:34 -0500 (EST) From: Henry Spencer To: david chen cc: ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. 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, 7 Dec 2001, david chen wrote: > What I infered is that > the pre-shared symmetric key can be used for both authentication and > encryption without key-exchange (KE) since this key is exchnaged through > 'out-of-band' secured channel and is *intended* for the two devices only. Your inference is incorrect. That is not how today's IPSec PSK works. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 12:29:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KTW210990; Fri, 7 Dec 2001 12:29:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05405 Fri, 7 Dec 2001 14:41:16 -0500 (EST) Message-ID: <29B5A21C13C8D51190F900805F65B4ECF19BB7@rndex50.ottawa.mitel.com> From: "Dilkie, Lee" To: "Hallam-Baker, Phillip" , "'Derek Atkins'" Cc: "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? Date: Fri, 7 Dec 2001 14:41:19 -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 see no reason to revoke a certificate just because you re-issued due to a name change. There was no comprimise of the original private key, so why would you need to go through the expense of revoking a certificate? Lee Dilkie Mitel Networks 350 Legget Drive Kanata, ON, Canada K2K 2W7 Phone: 1-613-592-5660 "It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day." - Homer Simpson (from "The Simpsons") -----Original Message----- From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] Sent: Friday, December 07, 2001 12:13 PM To: 'Derek Atkins'; Hallam-Baker, Phillip Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? First let us be clear about the different types of dynamic address. In practice very few addresses are genuinely 'dynamic'. Second, in this I will talk about 'certificates' since they are what the group are familliar with. But remember that this is simply a shorthand for 'binding of data to a private key' and there might be a scheme such as XKMS supporting the use. 1) The Address is actually static but is dynamically reallocated for operational reasons. E.G. most cable modem addresses which rarely change (unless excite goes bankrupt that week). Can issue a certificate bound to the IP address If the IP address changes, revoke & reissue (note, probably want to use XKMS rather than CRLs!) 2) The Address is dynamic being allocated each time from a fixed pool. E.G. dial up access Here we have a number of approaches, A) Generate a key / cert for each address in the pool. When the initiator attempts to connect to the responder with the client credential, the request is intercepted at the POP. The POP first performs a key agreement using the key bound to the IP address, then once the tunnel is created forwards the client request through the tunnel. B) Use disposable key / cert pairs. The initiator applies for a pool of key/cert pairs which are cached. These are discarded after a single use. The disposable key/cert pair may not even be certified by a trusted third party, it may be self signed. C) Issue a certificate that has a wild card in it E.G. 18.23.1.* (think binary mask) While the cost of such systems may appear high the concealment of identity is inherently an expensive process IF DONE WELL. If the concealment is poor then better not to bother at all. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Wednesday, December 05, 2001 3:33 PM > To: Hallam-Baker, Phillip > Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com > Subject: Re: Son-of-IKE Selection Criteria? > > > Phill, > > "Hallam-Baker, Phillip" writes: > > > 1. Issue every device an IP identity credential bound to > its IP address. > > This is the ONLY form of identity that can provably prevent any > > additional disclosure of identity in an IP environment > since your > > IP address is known in any case. > > > > 2. Perform two sequential key agreements, ] > > first an IP address based agreement > > second an identity based agreement encrypted under the > key of (1). > > > > How would you cope with machines with dynamic IP address? > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Fri Dec 7 12:32:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KWE211110; Fri, 7 Dec 2001 12:32:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05425 Fri, 7 Dec 2001 14:43:14 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15377.7666.566597.34133@thomasm-u1.cisco.com> Date: Fri, 7 Dec 2001 11:52:18 -0800 (PST) To: Dan Harkins Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: <200112071042.fB7AgkG00861@fatty.lounge.org> References: <15376.62551.423979.312570@thomasm-u1.cisco.com> <200112071042.fB7AgkG00861@fatty.lounge.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > The draft which calls itself IKEv2 _is_ a working group draft. Oh. I don't mean this in a disparaging way, but how did that happen? Do I read too much into the draft-ietf-ipsec-xxx? In any case, my real point is that he shouldn't be reading anything into the name since that's a function of the requirements. Mike > > Dan. > > On Fri, 07 Dec 2001 08:54:47 PST you wrote > > > > The fundamental mistake you're making here is > > giving special status to the name of *a* > > non-working group draft which calls itself IKEv2. > > It's not decided whether the working group will > > take IKEv2 as the basis of SOI, nor is it clear > > that the WG will call it "IKEv2" even if it did. > > > > Again, what is important at this point is setting > > the requirements to evaluate all of the candidate > > protocols. The requirements currently do not say > > that SOI will be everything that IKEv1 is and > > more. If you want the requirements to > > specifically say this, I think you need to get WG > > consensus for that, which I doubt there currently > > is. > > > > Mike > > > > > > Paul Koning writes: > > > >>>>> "Michael" == Michael Thomas writes: > > > > > > Michael> Paul Koning writes: > > > >> >>>>> "Wang," == Wang, Cliff writes: > > > >> > > > >> Wang,> Very simple reasons, IKEv1 is going to be replaced by IKEv2 > > > >> in Wang,> the future and KINK has yet to be standardized and it is > > > >> not Wang,> going to replace IKE. On the other hand, adding PSK > > > >> support in Wang,> IKEv2 is not an overkill, but provides much more > > > >> flexibilities Wang,> and more choices for service providers. > > > >> > > > >> Agreed. > > > >> > > > >> It makes no sense to call a protocol XYZv2 if you're removing from > > > >> it one of the very widely used features of XYZv1. > > > >> > > > >> If you want a protocol without preshared keys, feel free, but then > > > >> don't call it IKE and don't expect people to give up IKEv1. > > > > > > Michael> The name of protocol is irrelevant at this point. > > > > > > I don't agree. > > > > > > Its name *is* relevant if it is a name that says "this is the second > > > version of a previously defined protocol, intended to supersede the > > > first version". And that is the name currently given to the draft. > > > > > > So... is the intent that this protocol is supposed to be viewed as a > > > replacement for the protocol defined in RFC 2408/2409? Or is it > > > supposed to be considered a new, unrelated, protocol? > > > > > > If the latter, then the requirements set is open. But if the former, > > > then the new protocol MUST include among its requirements all the > > > features of the earlier protocol that are important. It is clear from > > > looking at customer installations that pre-shared key is a critical > > > feature of IKE. > > > > > > Another point: if the problem with IKEv1 is that it has too many > > > options -- which is a fair point -- how does it help matters to define > > > yet another protocol that products will have to implement IN ADDITION > > > to the already existing complex protocol? Why bother? If the goal is > > > to improve matters for implementers and customers, the goal should be > > > to create a new protocol which is indeed a viable replacement for the > > > previous protocol, fully entitled to the name "IKE V2" because it > > > incorporates the capabilities for which there is a proven need while > > > cleaning up in other areas. > > > > > > So what are we doing? Creating more protocols that increase > > > everyone's burden, or making things simpler? > > > > > > paul > > > From owner-ipsec@lists.tislabs.com Fri Dec 7 12:43:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KhI211457; Fri, 7 Dec 2001 12:43:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05463 Fri, 7 Dec 2001 14:51:07 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15377.8108.666731.266016@thomasm-u1.cisco.com> Date: Fri, 7 Dec 2001 11:59:40 -0800 (PST) To: Sara Bitan Cc: "Wang, Cliff" , ipsec@lists.tislabs.com, Alex Alten Subject: Re: Please save the pre-shared key mode In-Reply-To: <001201c17e32$ad0adf40$4ba6003e@cs.technion.ac.il> References: <3.0.3.32.20011205192048.00bb2168@pop3.netvista.net> <001201c17e32$ad0adf40$4ba6003e@cs.technion.ac.il> 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 Sara Bitan writes: > - There are many market segments that don't want to use public key > cryptography for pure efficiency reasons. Are we going to tell these guys : > "give up efficiency because PK cryptography is more secure", or are we > simply going to say to them "Don't use IKE and IPSec" ? This was the one of the main motivating factors for chartering KINK. It can be used peer-peer or as a trusted third party. I really don't think we need to reinvent this yet again. Mike From owner-ipsec@lists.tislabs.com Fri Dec 7 12:45:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Kjd211608; Fri, 7 Dec 2001 12:45:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05542 Fri, 7 Dec 2001 14:58:02 -0500 (EST) Message-Id: <200112071103.fB7B3OG00899@fatty.lounge.org> To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: Your message of "Fri, 07 Dec 2001 11:52:18 PST." <15377.7666.566597.34133@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <896.1007723004.1@tibernian.com> Date: Fri, 07 Dec 2001 03:03:24 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 07 Dec 2001 11:52:18 PST you wrote > Dan Harkins writes: > > The draft which calls itself IKEv2 _is_ a working group draft. > > I don't mean this in a disparaging way, but how did that happen? Uhm.... In the normal way, the chairs approved it. I'm surprised you're surprised. > Do I read too much into the draft-ietf-ipsec-xxx? Or perhaps you don't read enough into it. Dan. From owner-ipsec@lists.tislabs.com Fri Dec 7 12:54:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Ksm211937; Fri, 7 Dec 2001 12:54:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05562 Fri, 7 Dec 2001 15:02:39 -0500 (EST) Date: Fri, 7 Dec 2001 15:11:48 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: "Wang, Cliff" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3A53@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Michael Choung Shieh wrote: > How about someone unwrap the myth. I don't care if it's PK or PSK as long > as we can set it up as easy as setup PSK in IKE v1. > Can someone show step-by-step procedure to set up PK? In a typical > scenario, the HQ sys admin sets up vpn and sends config to his unknowledged > remote offic peer to download to remote device. How do we do it when using > PK without using PKI? The HQ sysadmin generates a public/private key pair for the new host/device, and that is sent to his remote peer as part of the config. Remote peer installs config (including key pair). Communication is established. Just like PSK. Alternatively, loading the config into the remote system includes generating a keypair, and the public key is then sent back to the HQ sysadmin for inclusion in his setup. Communication is established. The second approach is generally preferable, because it avoids ever transmitting secret information (the private key) between the sysadmins. But it does require a bit more savvy on the part of the remote sysadmin, and an extra sysadmin-to-sysadmin communications hop. If the remote sysadmin is really not up to much, and/or the software he is using is unhelpful, having the HQ sysadmin do the keypair generation may be preferable. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 12:55:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7KtA211969; Fri, 7 Dec 2001 12:55:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05624 Fri, 7 Dec 2001 15:11:38 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Hallam-Baker, Phillip" Cc: "'Derek Atkins'" , "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Selection Criteria? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 15:13:32 -0500 Message-Id: <20011207201332.302A37C07@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The real problem here is that it puts the local operator -- the ISP, the hotel, the conference LAN organizers -- in the critical path. If one needs an address-based certificate, one can't do *anything* without local operator co-operation. Apart from the fact that that doesn't scale very well -- between last Tuesday and next Friday, I'll have been in four different cities, have used or will use at least four different LANs (two of which used borrowed jacks and/or IP addresses), etc., and I'd have used more if airports and train stations (and, for that matter, airplanes and trains) had 802.11 or Ethernet available. Why should I need to go through that many ISPs instead of having a certificate (public key, actually) issued by my employer for VPN access? In message <2F3EC696EAEED311BB2D009027C3F4F4058698B5@vhqpostal.verisign.com>, " Hallam-Baker, Phillip" writes: > >First let us be clear about the different types of dynamic address. In >practice very few addresses are genuinely 'dynamic'. > >Second, in this I will talk about 'certificates' since they are what the >group are familliar with. But remember that this is simply a shorthand for >'binding of data to a private key' and there might be a scheme such as XKMS >supporting the use. > >1) The Address is actually static but is dynamically reallocated for >operational reasons. > E.G. most cable modem addresses which rarely change (unless excite >goes bankrupt that week). > > Can issue a certificate bound to the IP address > > If the IP address changes, revoke & reissue (note, probably want to >use XKMS rather than CRLs!) > >2) The Address is dynamic being allocated each time from a fixed pool. > E.G. dial up access > >Here we have a number of approaches, > >A) Generate a key / cert for each address in the pool. > When the initiator attempts to connect to the responder with the >client credential, the request is intercepted at the POP. The POP first >performs a key agreement using the key bound to the IP address, then once >the tunnel is created forwards the client request through the tunnel. > >B) Use disposable key / cert pairs. > The initiator applies for a pool of key/cert pairs which are cached. >These are discarded after a single use. The disposable key/cert pair may not >even be certified by a trusted third party, it may be self signed. > >C) Issue a certificate that has a wild card in it > E.G. 18.23.1.* (think binary mask) > > >While the cost of such systems may appear high the concealment of identity >is inherently an expensive process IF DONE WELL. If the concealment is poor >then better not to bother at all. From owner-ipsec@lists.tislabs.com Fri Dec 7 12:55:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Ktl212017; Fri, 7 Dec 2001 12:55:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05715 Fri, 7 Dec 2001 15:19:55 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698C1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Performance Date: Fri, 7 Dec 2001 12:30:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F5D.F26B7820" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F5D.F26B7820 Content-Type: text/plain; charset="iso-8859-1" Eric, Please add XKASS(Encrypt) 1 encrypt 1 encrypt 1 RTT 1 decrypt 1 decrypt XKASS(Sign+PFS) 1 signature 1 signature 1 RTT 1 verify 1 verify 1 DH agree 1 DH agree And if you must: XKASS(ID-Conceal) [as described on the list] 1 encrypt 1 encrypt 1 RTT 1 decrypt 1 decrypt 1 signature 1 signature 2 RTT 1 verify 1 verify 1 DH agree 1 DH agree Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Wednesday, December 05, 2001 5:33 PM > To: ipsec@lists.tislabs.com > Subject: Son-of-IKE Performance > > > As background to the discussion, I thought it might be worth > looking at performance of the various IKE replacements. > The following table summarizes the performance behavior of > the major proposals as far as I can make out. > I've also added TLS for comparison. > > Protocol Initiator Responder Latency > ------------------------------------------------ > IKEv2 1 signature 1 signature 2 RTT > 1 verify 1 verify > 1 DH agree 1 DH agree > > IKEv2 1 signature 1 signature 3 RTT > (DoS mode) 1 verify 1 verify > 1 DH agree 1 DH agree > > SIGMA 1 signature 1 signature 1.5 RTT [1] > 1 verify 1 verify > 1 DH agree 1 DH agree > > SIGMA 1 signature 1 signature 2.5 RTT [1] > (DoS mode) 1 verify 1 verify > 1 DH agree 1 DH agree > > JFK(normal) 1 signature 1 signature 2 RTT > 2 verifies 1 verify > 1 DH agree 1 DH agree > > JFK(PFS)[2] 1 signature 2 signatures 2 RTT > 2 verifies 1 verify > 1 DH agree 1 DH agree > > TLS (RSA)[3] 1 signature 1 decryption 2 RTT > 1 RSA encrypt 1 verify > > TLS (PFS)[3] 1 signature 1 signature 2 RTT > 1 verify 1 verify > 1 DH agree 1 DH agree > > Notes: > [0] I'm ignoring the following computational costs since > they're more or less constant across protocols and are > usually cheap. > > Digests, symmetric encryption, and PRFs. > Certificate verification (not cheap if DSS) > All of the PFS modes require an additional g^x mod p. > > [1] I'm dubious about the value of this. As Phill Hallam-Baker > argues, you'd probably want to use a 4-message handshake anyway. > > [2] In JFK, PFS mode is incompatible with DoS protection. > > [3] Note that TLS has an anonymous client mode which is even > faster: 1 RSA encrypt on the client and 1 RSA decrypt > on the server. > > [4] Here are some approximate timings for the various operations > (measured on a Celeron 300). All moduli are 1024-bit. > > RSA private key op 30 ms > RSA public key op 2 ms > DH key agree (1024-bit X) 100 ms > (256-bit X) 25 ms > DSA signature 17 ms > DSA verify 21 ms > > > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > ------_=_NextPart_000_01C17F5D.F26B7820 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F5D.F26B7820-- From owner-ipsec@lists.tislabs.com Fri Dec 7 12:58:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Kwi212214; Fri, 7 Dec 2001 12:58:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05702 Fri, 7 Dec 2001 15:19:32 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: ipsec@lists.tislabs.com Subject: UDP DoS attack in Win2k via IKE (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 15:27:46 -0500 Message-Id: <20011207202746.50E487B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This just moved on bugtraq. It seems relevant to what we're discussing. ------- Forwarded Message Message-ID: <001901c17f45$cb54fc60$0100a8c0@downstairs> From: "c0redump" To: Subject: UDP DoS attack in Win2k via IKE Date: Fri, 7 Dec 2001 17:37:07 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="Windows-1252" X-UIDL: 6efe10f9299eedf02227cee0d07fabfa UDP DoS in Win2k via IKE PROBLEM ======= A DoS attack can be carried out on Win2k machines running IKE (internet key exchange) by sending flooding IKE with UDP packets. This can cause the machine to lock up and render 99% of the CPU. EXPLOIT ====== Connect to port 500 (IKE) of the Win2k box and start sending UDP packets of more than 800 bytes continuously. The box will eventually stop responding and services will be denied due to 99% CPU usage from the packets. SOLUTION ======= Firewall port 500 off if IPSsec is not in use. c0redump@ackers.org.uk gridrun@spacebitch.com #hacktech @ undernet ------- End of Forwarded Message --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Fri Dec 7 13:02:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7L2j212567; Fri, 7 Dec 2001 13:02:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05633 Fri, 7 Dec 2001 15:11:47 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698BF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dilkie, Lee'" , "Hallam-Baker, Phillip" , "'Derek Atkins'" Cc: "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? Date: Fri, 7 Dec 2001 12:21:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F5C.CDF4DD20" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F5C.CDF4DD20 Content-Type: text/plain; charset="iso-8859-1" As I said in the pre-amble, you don't want your design to be constrained by what PKIX implementations achieve. XKMS is already deployed and is in process of being standardized. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Dilkie, Lee [mailto:Lee_Dilkie@Mitel.COM] > Sent: Friday, December 07, 2001 2:41 PM > To: Hallam-Baker, Phillip; 'Derek Atkins' > Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com > Subject: RE: Son-of-IKE Selection Criteria? > > > I see no reason to revoke a certificate just because you > re-issued due to a name change. There was no comprimise of > the original private key, so why would you need to go through > the expense of revoking a certificate? > > Lee Dilkie > > Mitel Networks > 350 Legget Drive > Kanata, ON, Canada > K2K 2W7 > > Phone: 1-613-592-5660 > > "It wasn't easy to juggle a pregnant wife and a troubled > child, but somehow I managed to fit in eight hours of TV a day." > - Homer Simpson (from "The Simpsons") > > > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Friday, December 07, 2001 12:13 PM > To: 'Derek Atkins'; Hallam-Baker, Phillip > Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com > Subject: RE: Son-of-IKE Selection Criteria? > > > First let us be clear about the different types of dynamic address. In > practice very few addresses are genuinely 'dynamic'. > > Second, in this I will talk about 'certificates' since they > are what the > group are familliar with. But remember that this is simply a > shorthand for > 'binding of data to a private key' and there might be a > scheme such as XKMS > supporting the use. > > 1) The Address is actually static but is dynamically reallocated for > operational reasons. > E.G. most cable modem addresses which rarely change > (unless excite > goes bankrupt that week). > > Can issue a certificate bound to the IP address > > If the IP address changes, revoke & reissue (note, > probably want to > use XKMS rather than CRLs!) > > 2) The Address is dynamic being allocated each time from a fixed pool. > E.G. dial up access > > Here we have a number of approaches, > > A) Generate a key / cert for each address in the pool. > When the initiator attempts to connect to the responder with the > client credential, the request is intercepted at the POP. The > POP first > performs a key agreement using the key bound to the IP > address, then once > the tunnel is created forwards the client request through the tunnel. > > B) Use disposable key / cert pairs. > The initiator applies for a pool of key/cert pairs > which are cached. > These are discarded after a single use. The disposable > key/cert pair may not > even be certified by a trusted third party, it may be self signed. > > C) Issue a certificate that has a wild card in it > E.G. 18.23.1.* (think binary mask) > > > While the cost of such systems may appear high the > concealment of identity > is inherently an expensive process IF DONE WELL. If the > concealment is poor > then better not to bother at all. > > Phill > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Wednesday, December 05, 2001 3:33 PM > > To: Hallam-Baker, Phillip > > Cc: 'Walker, Jesse'; ipsec@lists.tislabs.com > > Subject: Re: Son-of-IKE Selection Criteria? > > > > > > Phill, > > > > "Hallam-Baker, Phillip" writes: > > > > > 1. Issue every device an IP identity credential bound to > > its IP address. > > > This is the ONLY form of identity that can provably prevent any > > > additional disclosure of identity in an IP environment > > since your > > > IP address is known in any case. > > > > > > 2. Perform two sequential key agreements, ] > > > first an IP address based agreement > > > second an identity based agreement encrypted under the > > key of (1). > > > > > > > How would you cope with machines with dynamic IP address? > > > > -derek > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > > ------_=_NextPart_000_01C17F5C.CDF4DD20 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F5C.CDF4DD20-- From owner-ipsec@lists.tislabs.com Fri Dec 7 13:03:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7L3g212647; Fri, 7 Dec 2001 13:03:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05673 Fri, 7 Dec 2001 15:13:41 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698C0@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'EKR'" , Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: RE: discussion of SIGMA-IKE Date: Fri, 7 Dec 2001 12:23:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F5D.11AC5FC0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F5D.11AC5FC0 Content-Type: text/plain; charset="iso-8859-1" Hugo and myself both missed the deadline, largely because JFK itself only came out just before the deadline. XKASS was published long before JFK was released however and is still available on www.xmltrustcenter.org. The only thing that has not been available is the same document in plaintext form rather than pdf. I don't think anyone is suggesting that we should only discuss JFK because it is the only draft submitted to the working group before the cutoff for a single IETF meeting. Clearly we want the discussion at Salt Lake City to be as productive as possible and that is best achieved by discussing all the possible options. The key issues for me are 1) The extent to which JFK and SIGMA achieve identity concealment that is useful in a realistic application. 2) The extent to which identity concealment matter. If the group agrees with my position on either of these points then the reconfiguration of JFK so that it becomes a 2+4 message protocol becomes a no-brainer. In the process JFK becomes practically identical to XKASS. I take great issue with the attempt to claim SIGMA is three message. In order to achieve all you need to achieve you require a fourth message. As presently specified the initiator never knows: 1) IF the agreement completed 2) WHEN the agreement completed. So the initiator has to guess when to start sending packets authenticated using the key, it is a mess, it is unworkable, SIGMA is BROKEN (from a protocol design point of view, not cryptographic) without a fourth message - so might as well make good use of it. The comparison between JFK/XKASS and SIGMA then becomes 2/4 vs 4/6. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Wednesday, December 05, 2001 9:30 PM > To: Jan Vilhuber > Cc: ipsec@lists.tislabs.com > Subject: Re: discussion of SIGMA-IKE > > > Jan Vilhuber writes: > > I don't want this to sound the wrong way (but I'm sure it > will), but I don't > > think it's appropriate for this list to be discussing > SIGMA-IKE, because it's > > not an official draft yet. > This doesn't concern me overly. Based on the date on the draft, > I assume that Hugo just mised the I-D deadline. It's not like that's > never happened to anyone else :) > > > I say this because I've had several people already ask me > what this SIGMA-IKE > > was, and where they can find the draft. If the draft isn't > readily available > > from the IETF web-site, should we be discussing it as a > valid contender, if > > some part of the people on this list can't find it? > I don't see why not. It's not like we're going to make some > irrevocable decision on any of this stuff between now and next > week. Anyone who truly wants to read it shouldn't have much trouble > digging it up. It took me about a minute and a half to find. > > http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-si gma-00.txt -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ ------_=_NextPart_000_01C17F5D.11AC5FC0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F5D.11AC5FC0-- From owner-ipsec@lists.tislabs.com Fri Dec 7 13:03:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7L3q212673; Fri, 7 Dec 2001 13:03:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05744 Fri, 7 Dec 2001 15:26:07 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698C2@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dan Harkins'" , "Steven M. Bellovin" Cc: Eric Rescorla , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Performance Date: Fri, 7 Dec 2001 12:36:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F5E.C9849FD0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F5E.C9849FD0 Content-Type: text/plain; charset="iso-8859-1" Yes, but the obvious means of 'stretching' JFK ain't the way you did it. Once you have a mutually authenticated shared secret you can derive as many SAs in each direction as you like by obvious means. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@tibernian.com] > Sent: Thursday, December 06, 2001 4:14 PM > To: Steven M. Bellovin > Cc: Eric Rescorla; ipsec@lists.tislabs.com > Subject: Re: Son-of-IKE Performance > > > Yes, you can but I guess what I'm saying is that you're not. You can > stretch it to produce bi-directional keys but such stretching is not > specified anywhere in JFK. > > In <200112042306.BAA16872@burp.tkv.asdf.org> Markku Savela > mentioned > he preferred "a key negotiation [protocol] that only negotiates one > directional SA as requested by the kernel side of the IPSEC." That > is what JFK establishes today, a single session key for IPsec. > > If the intent, though, is that Kir should be stretched somehow to > produce bi-directional keys I withdraw my comment, but you > really should > specify how. Leaving such things to the imagination of the implementor > will probably result in disinteroperability. > > Dan. > > On Thu, 06 Dec 2001 22:17:50 EST you wrote > > In message <200112061808.fB6I7t301682@fatty.lounge.org>, > Dan Harkins writes: > > > Actually to compare apples-to-apples you should note that > > >JFK only produces a single key, Kir, for a single IPsec SA > > >(I'm assuming it's the initiator's outbound although it's > > >not specified). To end up with a pair of IPsec SAs, one in > > >each direction, you'd need: > > > > > > Protocol Initiator Responder Latency > > > ------------------------------------------------ > > > JFK(normal) 2 signature 2 signature 4 RTT > > > 4 verifies 2 verify > > > 2 DH agree 2 DH agree > > > > > > JFK(PFS)[2] 2 signature 4 signatures 4 RTT > > > 4 verifies 2 verify > > > 2 DH agree 2 DH agree > > > > > > > I'm afraid I don't understand what you're saying. JFK ends > up with an > > authenticated DH exponential; we can clearly derive > bidirectional keys > > from that. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > Full text of "Firewalls" book now at http://www.wilyhacker.com > > ------_=_NextPart_000_01C17F5E.C9849FD0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F5E.C9849FD0-- From owner-ipsec@lists.tislabs.com Fri Dec 7 13:07:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7L7d212923; Fri, 7 Dec 2001 13:07:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05655 Fri, 7 Dec 2001 15:12:36 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884C3@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Jan Vilhuber'" Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 20:21:40 -0000 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 This thread is talking about saving the pre-shared key mode, instead of saying nothing else works. I am not sure how you can hide a whole PKI system away under smart UI? I am also not sure how smart UI can solve the issue that on Cisco low end box PKI based IPsec performs much slower in comparison to PSK based IPsec. -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Friday, December 07, 2001 2:58 PM To: Wang, Cliff Cc: 'Dan McDonald'; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Wang, Cliff wrote: > >From the operation point of view, PSK is quick and easy to set up > >service. > It works and customers are happy. It is more real than a myth. > The myth is that nothing else works. PSK is a behind-the-scenes abstraction, that good programmers can hide from users altogether. A good UI can hide any other mechanism as well and make it as easy to configure. jan > > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Thursday, December 06, 2001 6:39 PM > To: Wang, Cliff > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > On the > > other hand, PSK based IKE and PKI based IKE has been the main way people > > deploying VPN. Under that context, PSK is simpler to run than PKI. > > > I think that's the myth Dan was talking about. > > jan > > > > > > > -----Original Message----- > > From: Dan McDonald [mailto:danmcd@east.sun.com] > > Sent: Thursday, December 06, 2001 1:28 PM > > To: Wang, Cliff > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Please save the pre-shared key mode > > > > > > > 1) Simplicity > > > Pre-shared key mode is simpler to support by eliminating the > > > requirement of supporting complex PKI. > > > > It's a myth that public-key implies you MUST have a PKI. > > > > Self-signed certs combined with explicit out-of-band trust models is > > just a non-cumbersome as pre-shared keys, IMHO, and they also offer > > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > > FreeSWAN has a self-signed cert model that works, right?) > > > > If we keep pre-shared, let's have a scalable way of identifying > > them. > > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > > pairs is as much hassle as PKI registration (it's just less snake-oil > > than most PKIs ;). > > > > For testing, I run server machines with self-signed certs. For > > small > > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > > of the PKI cruft. Peer-to-peer explosions is about the only case > > where PKI is really needed, and pre-shared won't help you any there > > either. It's just a matter of running certificate-generation, e-mail, > > and verifying hashes out-of-band. > > > > I'm not totally against nuking pre-shared. It's not, however, the > > panacea of simplicity many think it is, and simplicity arguments don't > > hold water. > > > > Dan > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 13:08:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7L8p213024; Fri, 7 Dec 2001 13:08:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05787 Fri, 7 Dec 2001 15:31:16 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Hallam-Baker, Phillip" Cc: "'EKR'" , Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: discussion of SIGMA-IKE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 15:40:46 -0500 Message-Id: <20011207204046.2613C7C00@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <2F3EC696EAEED311BB2D009027C3F4F4058698C0@vhqpostal.verisign.com>, " Hallam-Baker, Phillip" writes: > >I don't think anyone is suggesting that we should only discuss JFK because >it is the only draft submitted to the working group before the cutoff for a >single IETF meeting. Clearly we want the discussion at Salt Lake City to be >as productive as possible and that is best achieved by discussing all the >possible options. I certainly don't claim that. My understanding -- and my practice, in the groups I chair -- are that all drafts that are within charter and are the basis for WG disucssion are "official" WG documents, and can be named accordinglhy. It most emphatically does *not* imply any preferred status. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Fri Dec 7 13:09:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7L9k213106; Fri, 7 Dec 2001 13:09:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05806 Fri, 7 Dec 2001 15:32:06 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4087060EA@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4087060EA@vhqpostal.verisign.com> Date: Fri, 7 Dec 2001 12:41:18 -0800 To: "Hallam-Baker, Phillip" , EKR , "IP Security List (E-mail)" From: Paul Hoffman / VPNC Subject: RE: Some comments on JFK Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:37 AM -0800 12/7/01, Hallam-Baker, Phillip wrote: >If al we need to do is to protect against the DoS attack then >it is better to reconfigure the exchange so that DoS protection is an option >for the responder if it discovers it is under DoS attack. That point is not fully agreed on. The optional extra round trip adds complexity to the protocol because the initiator needs to be ready to handle two different types of responses. In the simple case, that's not a big deal, but what happens if a "not under DoS" response is delayed, the initiator sends the initial request again, and the responder says "this is fishy and DoS-like, I'm going to respons with a 'am under DoS' response". The initiator gets the delayed first response and replies to it. This is the kind of case where interoperability falls down in IKEv1, particularly when Vendor X is known to send weird messages at odd times so Vendors A through W write special code around it. But then Vendor X realizes the error of its way and doesn't make that mistake any more, but that special code hangs around forever. Every optional round trip and every optional message MUST be tightly scoped in the new protocol, or we can assume that the new protocol will fall to IKEv1's level of partial interoperability. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Dec 7 13:15:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LFd213414; Fri, 7 Dec 2001 13:15:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05868 Fri, 7 Dec 2001 15:39:45 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3A56@NS-CA> From: Michael Choung Shieh To: "'Henry Spencer'" , Michael Choung Shieh Cc: "Wang, Cliff" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 12:47:28 -0800 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 We have the point here. 2nd approach is definitely better. It's preferrable for us but it's not preferrable for the sys admin. If I am the sys admin to setup hundreds of devices for employee's at-home gateway, using PK in 2nd approach will kill me. 1st approach is easier for the admin. However, why use PK if we need to expose private-key. IKEv1 has option of PSK and PK but most users choose PSK. Before we kill it, let's think about the reason of PSK popularity. Why do we want to kill a feature which most users use? Is it insecure, or just because we (IPsec community) think PK is better? -------------------------------------------- Michael Shieh -------------------------------------------- -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Friday, December 07, 2001 12:12 PM To: Michael Choung Shieh Cc: Wang, Cliff; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Michael Choung Shieh wrote: > How about someone unwrap the myth. I don't care if it's PK or PSK as long > as we can set it up as easy as setup PSK in IKE v1. > Can someone show step-by-step procedure to set up PK? In a typical > scenario, the HQ sys admin sets up vpn and sends config to his unknowledged > remote offic peer to download to remote device. How do we do it when using > PK without using PKI? The HQ sysadmin generates a public/private key pair for the new host/device, and that is sent to his remote peer as part of the config. Remote peer installs config (including key pair). Communication is established. Just like PSK. Alternatively, loading the config into the remote system includes generating a keypair, and the public key is then sent back to the HQ sysadmin for inclusion in his setup. Communication is established. The second approach is generally preferable, because it avoids ever transmitting secret information (the private key) between the sysadmins. But it does require a bit more savvy on the part of the remote sysadmin, and an extra sysadmin-to-sysadmin communications hop. If the remote sysadmin is really not up to much, and/or the software he is using is unhelpful, having the HQ sysadmin do the keypair generation may be preferable. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 13:20:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LKQ213688; Fri, 7 Dec 2001 13:20:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05773 Fri, 7 Dec 2001 15:30:50 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Wang, Cliff" Cc: "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 15:39:01 -0500 Message-Id: <20011207203902.ECBD67B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <4652644B98DFF34696801F8F3070D3FE011884C3@D2CSPEXM001.smartpipes.com >, "Wang, Cliff" writes: > >This thread is talking about saving the pre-shared key mode, instead of >saying nothing else works. > >I am not sure how you can hide a whole PKI system away under smart UI? >I am also not sure how smart UI can solve the issue that on Cisco low end >box PKI based IPsec performs much slower in comparison to PSK based IPsec. Sorry to shout, but YOU DON"T NEED A PKI. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Fri Dec 7 13:20:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LKt213805; Fri, 7 Dec 2001 13:20:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05853 Fri, 7 Dec 2001 15:38:14 -0500 (EST) Date: Fri, 7 Dec 2001 12:47:07 -0800 (PST) From: Jan Vilhuber To: "Steven M. Bellovin" cc: "Hallam-Baker, Phillip" , "'EKR'" , ipsec@lists.tislabs.com Subject: Re: discussion of SIGMA-IKE In-Reply-To: <20011207204046.2613C7C00@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I certainly want the discussion to be as broad and with as many candidates as possible. My point was that lots of folks don't seem to be able to get the drafts to read them and take part in the discussion. As such we are loosing at least some voices in the discussion. Not everyone's mail-archive or web-searching skills are stellar ;) As such, if the group as such feels it's not a problem, I certainly don't want to exclude any proposals... jan On Fri, 7 Dec 2001, Steven M. Bellovin wrote: > In message <2F3EC696EAEED311BB2D009027C3F4F4058698C0@vhqpostal.verisign.com>, " > Hallam-Baker, Phillip" writes: > > > > >I don't think anyone is suggesting that we should only discuss JFK because > >it is the only draft submitted to the working group before the cutoff for a > >single IETF meeting. Clearly we want the discussion at Salt Lake City to be > >as productive as possible and that is best achieved by discussing all the > >possible options. > > I certainly don't claim that. My understanding -- and my practice, in > the groups I chair -- are that all drafts that are within charter and > are the basis for WG disucssion are "official" WG documents, and can be > named accordinglhy. It most emphatically does *not* imply any > preferred status. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 13:21:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LL0213830; Fri, 7 Dec 2001 13:21:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05827 Fri, 7 Dec 2001 15:35:33 -0500 (EST) Date: Fri, 7 Dec 2001 12:44:27 -0800 (PST) From: Jan Vilhuber To: "Wang, Cliff" cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884C3@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: > > This thread is talking about saving the pre-shared key mode, instead of > saying nothing else works. > > I am not sure how you can hide a whole PKI system away under smart UI? I'm not about to design your products for you, but several alternatives have been proposed, ranging from using self-signed pre-shared certs and using key-finger-prints in lieu of a pre-shared key. The rest is up to you. > I am also not sure how smart UI can solve the issue that on Cisco low end > box PKI based IPsec performs much slower in comparison to PSK based IPsec. > The last point seems completely off topic. I can't run linux on my wristwatch either. What's the point? New things may only work on newer boxes. jan > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Friday, December 07, 2001 2:58 PM > To: Wang, Cliff > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > On Fri, 7 Dec 2001, Wang, Cliff wrote: > > > >From the operation point of view, PSK is quick and easy to set up > > >service. > > It works and customers are happy. It is more real than a myth. > > > The myth is that nothing else works. PSK is a behind-the-scenes abstraction, > that good programmers can hide from users altogether. A good UI can hide any > other mechanism as well and make it as easy to configure. > > jan > > > > > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Thursday, December 06, 2001 6:39 PM > > To: Wang, Cliff > > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > > Subject: RE: Please save the pre-shared key mode > > > > > On the > > > other hand, PSK based IKE and PKI based IKE has been the main way people > > > deploying VPN. Under that context, PSK is simpler to run than PKI. > > > > > I think that's the myth Dan was talking about. > > > > jan > > > > > > > > > > > > -----Original Message----- > > > From: Dan McDonald [mailto:danmcd@east.sun.com] > > > Sent: Thursday, December 06, 2001 1:28 PM > > > To: Wang, Cliff > > > Cc: ipsec@lists.tislabs.com > > > Subject: Re: Please save the pre-shared key mode > > > > > > > > > > 1) Simplicity > > > > Pre-shared key mode is simpler to support by eliminating the > > > > requirement of supporting complex PKI. > > > > > > It's a myth that public-key implies you MUST have a PKI. > > > > > > Self-signed certs combined with explicit out-of-band trust models is > > > just a non-cumbersome as pre-shared keys, IMHO, and they also offer > > > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > > > FreeSWAN has a self-signed cert model that works, right?) > > > > > > If we keep pre-shared, let's have a scalable way of identifying > > > them. > > > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > > > pairs is as much hassle as PKI registration (it's just less snake-oil > > > than most PKIs ;). > > > > > > For testing, I run server machines with self-signed certs. For > > > small > > > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > > > of the PKI cruft. Peer-to-peer explosions is about the only case > > > where PKI is really needed, and pre-shared won't help you any there > > > either. It's just a matter of running certificate-generation, e-mail, > > > and verifying hashes out-of-band. > > > > > > I'm not totally against nuking pre-shared. It's not, however, the > > > panacea of simplicity many think it is, and simplicity arguments don't > > > hold water. > > > > > > Dan > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 13:21:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LLW213872; Fri, 7 Dec 2001 13:21:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05839 Fri, 7 Dec 2001 15:36:03 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698C3@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , "Hallam-Baker, Phillip" Cc: "'Derek Atkins'" , "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Selection Criteria? Date: Fri, 7 Dec 2001 12:46:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F60.331840E0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F60.331840E0 Content-Type: text/plain; charset="iso-8859-1" Steve, The problem here is that your risk model is still broken, you are assuming a risk that already means you have lost. If you can't trust your ISP to conceal your trafic then your trafic is already compromised. Using JFK as presently configured I can still trace the packets back to Steve Bellovin in your scenario: 1) I look at the IP header source address 2) I find the ISP who owns the source address 3) I cause the ISP to tell me who you are. Under your attack model (3) is easy. But it is under any realistic scenario, Ashcroft can (and will) simply issue a directive under the Patriot act to force the ISP to hand over the records, Al Qaeda would simply kidnap the Sysop's children and tell the sysop to give them the data. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Friday, December 07, 2001 3:14 PM > To: Hallam-Baker, Phillip > Cc: 'Derek Atkins'; 'Walker, Jesse'; ipsec@lists.tislabs.com > Subject: Re: Son-of-IKE Selection Criteria? > > > The real problem here is that it puts the local operator -- the ISP, > the hotel, the conference LAN organizers -- in the critical path. If > one needs an address-based certificate, one can't do > *anything* without > local operator co-operation. Apart from the fact that that doesn't > scale very well -- between last Tuesday and next Friday, I'll > have been > in four different cities, have used or will use at least four > different > LANs (two of which used borrowed jacks and/or IP addresses), > etc., and > I'd have used more if airports and train stations (and, for that > matter, airplanes and trains) had 802.11 or Ethernet available. Why > should I need to go through that many ISPs instead of having a > certificate (public key, actually) issued by my employer for > VPN access? > > > > In message > <2F3EC696EAEED311BB2D009027C3F4F4058698B5@vhqpostal.verisign.com>, " > Hallam-Baker, Phillip" writes: > > > > >First let us be clear about the different types of dynamic > address. In > >practice very few addresses are genuinely 'dynamic'. > > > >Second, in this I will talk about 'certificates' since they > are what the > >group are familliar with. But remember that this is simply a > shorthand for > >'binding of data to a private key' and there might be a > scheme such as XKMS > >supporting the use. > > > >1) The Address is actually static but is dynamically reallocated for > >operational reasons. > > E.G. most cable modem addresses which rarely change > (unless excite > >goes bankrupt that week). > > > > Can issue a certificate bound to the IP address > > > > If the IP address changes, revoke & reissue (note, > probably want to > >use XKMS rather than CRLs!) > > > >2) The Address is dynamic being allocated each time from a > fixed pool. > > E.G. dial up access > > > >Here we have a number of approaches, > > > >A) Generate a key / cert for each address in the pool. > > When the initiator attempts to connect to the responder with the > >client credential, the request is intercepted at the POP. > The POP first > >performs a key agreement using the key bound to the IP > address, then once > >the tunnel is created forwards the client request through the tunnel. > > > >B) Use disposable key / cert pairs. > > The initiator applies for a pool of key/cert pairs > which are cached. > >These are discarded after a single use. The disposable > key/cert pair may not > >even be certified by a trusted third party, it may be self signed. > > > >C) Issue a certificate that has a wild card in it > > E.G. 18.23.1.* (think binary mask) > > > > > >While the cost of such systems may appear high the > concealment of identity > >is inherently an expensive process IF DONE WELL. If the > concealment is poor > >then better not to bother at all. > > ------_=_NextPart_000_01C17F60.331840E0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F60.331840E0-- From owner-ipsec@lists.tislabs.com Fri Dec 7 13:33:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LXT214319; Fri, 7 Dec 2001 13:33:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05895 Fri, 7 Dec 2001 15:42:05 -0500 (EST) Date: Fri, 7 Dec 2001 14:51:04 -0600 (CST) From: Tylor Allison X-X-Sender: To: Michael Thomas cc: Paul Koning , , Subject: RE: Please save the pre-shared key mode In-Reply-To: <15376.62551.423979.312570@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Michael Thomas wrote: > The fundamental mistake you're making here is > giving special status to the name of *a* > non-working group draft which calls itself IKEv2. > It's not decided whether the working group will > take IKEv2 as the basis of SOI, nor is it clear > that the WG will call it "IKEv2" even if it did. > > Again, what is important at this point is setting > the requirements to evaluate all of the candidate > protocols. The requirements currently do not say > that SOI will be everything that IKEv1 is and > more. If you want the requirements to > specifically say this, I think you need to get WG > consensus for that, which I doubt there currently > is. > > Mike >From the recent posts is pretty clear that we will not get WG consensus on this issue. However, I don't agree that this means that PSK is out. One can look at it in two ways: we need to reach consensus for removing a feature from IKE/SOI, or we need to reach consensus for making PSK a requirement of SOI. I think one thing that we need to keep in mind is that SOI will be replacing IKEv1... and while it sounds great to start with a clean slate with SOI, we have to take into account how IKEv1 has been deployed. This includes large deployments where the end-users have used PSK. If SOI does not address the needs of the user community, it won't be adopted. And I'd much prefer to support a single SOI protocol which meets these needs then multiple protocols (IKEv1, SOI, KINK), each adding complexity to the overall VPN solution we present. ===================================================================== = Tylor Allison Secure Computing Corporation ========= = phone: 651.628.1554 e-mail: allison@securecomputing.com ========= ===================================================================== From owner-ipsec@lists.tislabs.com Fri Dec 7 13:38:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Lcx214462; Fri, 7 Dec 2001 13:38:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05935 Fri, 7 Dec 2001 15:52:45 -0500 (EST) Date: Fri, 7 Dec 2001 16:01:53 -0500 (EST) From: Henry Spencer To: "Wang, Cliff" cc: "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884C3@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: > This thread is talking about saving the pre-shared key mode, instead of > saying nothing else works. The justification being offered for saving it is "nothing else works" -- that is, that there is no other equally quick and simple way of setting up a simple connection. This is false. There are non-PKI approaches to public keys which are just as simple and easy as PSK. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 13:41:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LfA214535; Fri, 7 Dec 2001 13:41:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05997 Fri, 7 Dec 2001 16:00:33 -0500 (EST) Message-Id: <200112072110.fB7L9uG01024@fatty.lounge.org> To: "Hallam-Baker, Phillip" Subject: Re: Son-of-IKE Performance Cc: ipsec@lists.tislabs.com In-Reply-To: Your message of "Fri, 07 Dec 2001 12:36:02 PST." <2F3EC696EAEED311BB2D009027C3F4F4058698C2@vhqpostal.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1021.1007759396.1@tibernian.com> Date: Fri, 07 Dec 2001 13:09:56 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am well aware it is possible to derive keys for many SAs out of a mutually authenticated shared secret. My point is that just saying "by obvious means" is not good enough. After seeing how emminently reasonable people interpreted "by obvious means" differently during implementation of RFC2409 I think it is necessary to explain the means exactly. My stretching wasn't the "obvious" one? Well there's another person on this list who thought it was. Moreover, there is nothing in JFK to say it was the incorrect way or that what means "obvious" to you is the correct way. Do you see the problem? Dan. On Fri, 07 Dec 2001 12:36:02 PST you wrote > > Yes, but the obvious means of 'stretching' JFK ain't the way you did it. > > Once you have a mutually authenticated shared secret you can derive > as many SAs in each direction as you like by obvious means. > > > Phill > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@tibernian.com] > > Sent: Thursday, December 06, 2001 4:14 PM > > To: Steven M. Bellovin > > Cc: Eric Rescorla; ipsec@lists.tislabs.com > > Subject: Re: Son-of-IKE Performance > > > > > > Yes, you can but I guess what I'm saying is that you're not. You can > > stretch it to produce bi-directional keys but such stretching is not > > specified anywhere in JFK. > > > > In <200112042306.BAA16872@burp.tkv.asdf.org> Markku Savela > > mentioned > > he preferred "a key negotiation [protocol] that only negotiates one > > directional SA as requested by the kernel side of the IPSEC." That > > is what JFK establishes today, a single session key for IPsec. > > > > If the intent, though, is that Kir should be stretched somehow to > > produce bi-directional keys I withdraw my comment, but you > > really should > > specify how. Leaving such things to the imagination of the implementor > > will probably result in disinteroperability. > > > > Dan. > > > > On Thu, 06 Dec 2001 22:17:50 EST you wrote > > > In message <200112061808.fB6I7t301682@fatty.lounge.org>, > > Dan Harkins writes: > > > > Actually to compare apples-to-apples you should note that > > > >JFK only produces a single key, Kir, for a single IPsec SA > > > >(I'm assuming it's the initiator's outbound although it's > > > >not specified). To end up with a pair of IPsec SAs, one in > > > >each direction, you'd need: > > > > > > > > Protocol Initiator Responder Latency > > > > ------------------------------------------------ > > > > JFK(normal) 2 signature 2 signature 4 RTT > > > > 4 verifies 2 verify > > > > 2 DH agree 2 DH agree > > > > > > > > JFK(PFS)[2] 2 signature 4 signatures 4 RTT > > > > 4 verifies 2 verify > > > > 2 DH agree 2 DH agree > > > > > > > > > > I'm afraid I don't understand what you're saying. JFK ends > > up with an > > > authenticated DH exponential; we can clearly derive > > bidirectional keys > > > from that. > > > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > Full text of "Firewalls" book now at > http://www.wilyhacker.com > > > > > > > ------_=_NextPart_000_01C17F5E.C9849FD0 > Content-Type: application/octet-stream; > name="Phillip Hallam-Baker (E-mail).vcf" > Content-Disposition: attachment; > filename="Phillip Hallam-Baker (E-mail).vcf" > > BEGIN:VCARD > VERSION:2.1 > N:Hallam-Baker;Phillip > FN:Phillip Hallam-Baker (E-mail) > ORG:VeriSign > TITLE:Principal Consultant > TEL;WORK;VOICE:(781) 245-6996 x227 > EMAIL;PREF;INTERNET:hallam@verisign.com > REV:20010214T163732Z > END:VCARD > > ------_=_NextPart_000_01C17F5E.C9849FD0-- From owner-ipsec@lists.tislabs.com Fri Dec 7 13:45:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Lj4214650; Fri, 7 Dec 2001 13:45:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05957 Fri, 7 Dec 2001 15:55:25 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884C4@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Jan Vilhuber'" Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 21:04:36 -0000 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 bottom line is although smart UI can help user to simplify his task, it doesn't completely solve the complexity issue we are talking about. Otherwise there is no need for us to discuss this here anymore. -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Friday, December 07, 2001 3:44 PM To: Wang, Cliff Cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Wang, Cliff wrote: > > This thread is talking about saving the pre-shared key mode, instead > of saying nothing else works. > > I am not sure how you can hide a whole PKI system away under smart UI? I'm not about to design your products for you, but several alternatives have been proposed, ranging from using self-signed pre-shared certs and using key-finger-prints in lieu of a pre-shared key. The rest is up to you. > I am also not sure how smart UI can solve the issue that on Cisco low > end box PKI based IPsec performs much slower in comparison to PSK > based IPsec. > The last point seems completely off topic. I can't run linux on my wristwatch either. What's the point? New things may only work on newer boxes. jan > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Friday, December 07, 2001 2:58 PM > To: Wang, Cliff > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > On Fri, 7 Dec 2001, Wang, Cliff wrote: > > > >From the operation point of view, PSK is quick and easy to set up > > >service. > > It works and customers are happy. It is more real than a myth. > > > The myth is that nothing else works. PSK is a behind-the-scenes > abstraction, that good programmers can hide from users altogether. A > good UI can hide any other mechanism as well and make it as easy to > configure. > > jan > > > > > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Thursday, December 06, 2001 6:39 PM > > To: Wang, Cliff > > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > > Subject: RE: Please save the pre-shared key mode > > > > > On the > > > other hand, PSK based IKE and PKI based IKE has been the main way people > > > deploying VPN. Under that context, PSK is simpler to run than PKI. > > > > > I think that's the myth Dan was talking about. > > > > jan > > > > > > > > > > > > -----Original Message----- > > > From: Dan McDonald [mailto:danmcd@east.sun.com] > > > Sent: Thursday, December 06, 2001 1:28 PM > > > To: Wang, Cliff > > > Cc: ipsec@lists.tislabs.com > > > Subject: Re: Please save the pre-shared key mode > > > > > > > > > > 1) Simplicity > > > > Pre-shared key mode is simpler to support by eliminating the > > > > requirement of supporting complex PKI. > > > > > > It's a myth that public-key implies you MUST have a PKI. > > > > > > Self-signed certs combined with explicit out-of-band trust models > > > is just a non-cumbersome as pre-shared keys, IMHO, and they also > > > offer IP-address-portability. (Henry Spencer, correct me if I'm > > > wrong, but FreeSWAN has a self-signed cert model that works, > > > right?) > > > > > > If we keep pre-shared, let's have a scalable way of identifying > > > them. > > > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > > > pairs is as much hassle as PKI registration (it's just less snake-oil > > > than most PKIs ;). > > > > > > For testing, I run server machines with self-signed certs. For > > > small > > > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > > > of the PKI cruft. Peer-to-peer explosions is about the only case > > > where PKI is really needed, and pre-shared won't help you any there > > > either. It's just a matter of running certificate-generation, e-mail, > > > and verifying hashes out-of-band. > > > > > > I'm not totally against nuking pre-shared. It's not, however, the > > > panacea of simplicity many think it is, and simplicity arguments > > > don't hold water. > > > > > > Dan > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 13:46:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Lkq214760; Fri, 7 Dec 2001 13:46:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06064 Fri, 7 Dec 2001 16:09:10 -0500 (EST) Date: Fri, 7 Dec 2001 16:18:16 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: "Wang, Cliff" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3A56@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Michael Choung Shieh wrote: > We have the point here. 2nd approach is definitely better. It's > preferrable for us but it's not preferrable for the sys admin. If I am the > sys admin to setup hundreds of devices for employee's at-home gateway, using > PK in 2nd approach will kill me. As always, different people have different tradeoffs, and thus will need to use different solutions. > 1st approach is easier for the admin. However, why use PK if we need to > expose private-key. Because it avoids PSK-specific complications in the *protocol*. The 1st approach is administratively no better than PSK, but it's also no worse, so PSK can be eliminated without causing any major problems. > IKEv1 has option of PSK and PK but most users choose PSK. Before we kill > it, let's think about the reason of PSK popularity. Probably it's mostly because existing implementations tend to give you only two choices: PSK, and PKI/certificate/X.509 madness. FreeS/WAN offers a non-PKI public-key option and it is quite widely used. It would see still more use if there were a standard non-PKI/certificate/X.509 way to move RSA keys around; as it is, interoperability approaches nil because nobody *else* is willing to accept simple, unadorned RSA keys as a basis for signature authentication mode. > Why do we want to kill > a feature which most users use? Is it insecure, or just because we (IPsec > community) think PK is better? Because it is one more feature in a protocol which definitely has too many already, and badly needs cutting back. This one appears to be redundant and unnecessary, given the possibility of equally-simple-to-administer schemes using self-signed certs or bare public keys. Those schemes are not widely used at present because they are seldom provided as options, not because there is anything wrong with them. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 13:54:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7LsW215246; Fri, 7 Dec 2001 13:54:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06157 Fri, 7 Dec 2001 16:17:31 -0500 (EST) Date: Fri, 7 Dec 2001 16:26:38 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Son-of-IKE Performance In-Reply-To: <200112072110.fB7L9uG01024@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Dan Harkins wrote: > My point is that just saying "by obvious means" is not good enough. > After seeing how emminently reasonable people interpreted "by obvious > means" differently during implementation of RFC2409 I think it is > necessary to explain the means exactly. I concur. One thing that all too many IETF protocols suffer from is the inability to produce a fully interoperable implementation solely from the documents, without relying on a body of folklore to fill in details. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 13:54:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Lsn215281; Fri, 7 Dec 2001 13:54:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06118 Fri, 7 Dec 2001 16:14:13 -0500 (EST) Date: Fri, 7 Dec 2001 13:23:06 -0800 (PST) From: Jan Vilhuber To: "Wang, Cliff" cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884C4@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: > The bottom line is although smart UI can help user to simplify his task, it > doesn't completely solve the complexity issue we are talking about. What complexity issue? As has been pointed out over and over (and over) again: You don't need a complex PKI to do public keys. The rest is implementation details, and pre-shared self-signed certificates are no more complex than Pre-shared symmetric keys. jan > Otherwise there is no need for us to discuss this here anymore. > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Friday, December 07, 2001 3:44 PM > To: Wang, Cliff > Cc: ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > On Fri, 7 Dec 2001, Wang, Cliff wrote: > > > > > This thread is talking about saving the pre-shared key mode, instead > > of saying nothing else works. > > > > I am not sure how you can hide a whole PKI system away under smart UI? > > I'm not about to design your products for you, but several alternatives have > been proposed, ranging from using self-signed pre-shared certs and using > key-finger-prints in lieu of a pre-shared key. The rest is up to you. > > > I am also not sure how smart UI can solve the issue that on Cisco low > > end box PKI based IPsec performs much slower in comparison to PSK > > based IPsec. > > > The last point seems completely off topic. I can't run linux on my > wristwatch either. What's the point? New things may only work on newer > boxes. > > jan > > > > > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Friday, December 07, 2001 2:58 PM > > To: Wang, Cliff > > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > > Subject: RE: Please save the pre-shared key mode > > > > > > On Fri, 7 Dec 2001, Wang, Cliff wrote: > > > > > >From the operation point of view, PSK is quick and easy to set up > > > >service. > > > It works and customers are happy. It is more real than a myth. > > > > > The myth is that nothing else works. PSK is a behind-the-scenes > > abstraction, that good programmers can hide from users altogether. A > > good UI can hide any other mechanism as well and make it as easy to > > configure. > > > > jan > > > > > > > > > > > > > -----Original Message----- > > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > > Sent: Thursday, December 06, 2001 6:39 PM > > > To: Wang, Cliff > > > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > > > Subject: RE: Please save the pre-shared key mode > > > > > > > On the > > > > other hand, PSK based IKE and PKI based IKE has been the main way > people > > > > deploying VPN. Under that context, PSK is simpler to run than PKI. > > > > > > > I think that's the myth Dan was talking about. > > > > > > jan > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Dan McDonald [mailto:danmcd@east.sun.com] > > > > Sent: Thursday, December 06, 2001 1:28 PM > > > > To: Wang, Cliff > > > > Cc: ipsec@lists.tislabs.com > > > > Subject: Re: Please save the pre-shared key mode > > > > > > > > > > > > > 1) Simplicity > > > > > Pre-shared key mode is simpler to support by eliminating the > > > > > requirement of supporting complex PKI. > > > > > > > > It's a myth that public-key implies you MUST have a PKI. > > > > > > > > Self-signed certs combined with explicit out-of-band trust models > > > > is just a non-cumbersome as pre-shared keys, IMHO, and they also > > > > offer IP-address-portability. (Henry Spencer, correct me if I'm > > > > wrong, but FreeSWAN has a self-signed cert model that works, > > > > right?) > > > > > > > > If we keep pre-shared, let's have a scalable way of identifying > > > > them. > > > > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > > > > > pairs is as much hassle as PKI registration (it's just less snake-oil > > > > than most PKIs ;). > > > > > > > > For testing, I run server machines with self-signed certs. For > > > > small > > > > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > > > > of the PKI cruft. Peer-to-peer explosions is about the only case > > > > where PKI is really needed, and pre-shared won't help you any there > > > > either. It's just a matter of running certificate-generation, e-mail, > > > > > and verifying hashes out-of-band. > > > > > > > > I'm not totally against nuking pre-shared. It's not, however, the > > > > panacea of simplicity many think it is, and simplicity arguments > > > > don't hold water. > > > > > > > > Dan > > > > > > > > > > -- > > > Jan Vilhuber > vilhuber@cisco.com > > > Cisco Systems, San Jose (408) > 527-0847 > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 13:58:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Lwf215567; Fri, 7 Dec 2001 13:58:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06211 Fri, 7 Dec 2001 16:23:28 -0500 (EST) Date: Fri, 7 Dec 2001 16:32:23 -0500 (EST) From: Henry Spencer To: Alister Yap cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode 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, 6 Dec 2001, Alister Yap wrote: > Henry Spencer mentioned a non PKI mode. I don't see what benefit that it or > how much more secure that is compared with PSK. Could anyone elaborate on > that please? It can be operationally much the same as PSK, with similar levels of security, *without* requiring any special accommodations for PSK in the key-exchange protocol. So the protocol can be made simpler without making users' lives more difficult. Many people who say they want PSK just want its simple operations; they don't really care which flavor of keying is used. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 14:04:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7M43215986; Fri, 7 Dec 2001 14:04:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06232 Fri, 7 Dec 2001 16:28:48 -0500 (EST) Date: Fri, 7 Dec 2001 16:37:47 -0500 (EST) From: Henry Spencer To: Dan McDonald cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: <200112061827.fB6IRfrX007286@kebe.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 6 Dec 2001, Dan McDonald wrote: > It's a myth that public-key implies you MUST have a PKI. > > Self-signed certs combined with explicit out-of-band trust models is just a > non-cumbersome as pre-shared keys, IMHO, and they also offer > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > FreeSWAN has a self-signed cert model that works, right?) Simpler even than that: we just move RSA keys around, in RFC 2537 format. No certificates involved at all. Operationally it is essentially the same as self-signed certs, but the implementation is simpler and has less overhead. The only snag is that most other implementations can't do public-key-signature authentication at all without dragging in all the certificate goo. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 14:07:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7M7q216237; Fri, 7 Dec 2001 14:07:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06194 Fri, 7 Dec 2001 16:22:46 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884C5@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Henry Spencer'" Cc: "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 21:31:53 -0000 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 At least it is not my intention to say that nothings else works. Given the EXISTING options (IKEv1) made available by device vendors, PSK is easier to run. Anything makes the deployment of IPsec VPN easier should be the common goal of this working group. I will be more than glad to accept alternative ways to achieve that goal, after a concensus is reached that they are indeed better. Where are these alternative approaches documented in the form of internet draft? -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Friday, December 07, 2001 4:02 PM To: Wang, Cliff Cc: 'Jan Vilhuber'; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Wang, Cliff wrote: > This thread is talking about saving the pre-shared key mode, instead > of saying nothing else works. The justification being offered for saving it is "nothing else works" -- that is, that there is no other equally quick and simple way of setting up a simple connection. This is false. There are non-PKI approaches to public keys which are just as simple and easy as PSK. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 14:26:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7MQG217834; Fri, 7 Dec 2001 14:26:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06276 Fri, 7 Dec 2001 16:36:52 -0500 (EST) Date: Fri, 7 Dec 2001 16:45:52 -0500 (EST) From: Henry Spencer To: "Wang, Cliff" cc: "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884C5@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: >> The justification being offered for saving it is "nothing else works" -- >> that is, that there is no other equally quick and simple way of setting up a >> simple connection. This is false. There are non-PKI approaches to public >> keys which are just as simple and easy as PSK. > > ...Where are these alternative approaches documented in the form of > internet draft? I don't know that anyone has ever thought to document them in I-Ds, since mostly they are too simple to need much explaining. The hard part is deprogramming people from the "public key implies PKI" religion. Self-signed certs are a well-known concept, and fit naturally into existing cert machinery. RFC 3110 documents how to represent (in DNS) RSA public keys without involving any form of certificate. We used that as our representation. We preconfigure with public keys in much the same way that we preconfigure with shared secrets. What else is there to tell? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 14:30:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7MUs218226; Fri, 7 Dec 2001 14:30:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06407 Fri, 7 Dec 2001 16:53:00 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE011884C7@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Henry Spencer'" Cc: "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 22:01:53 -0000 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 documentation is not about how to generate self-signed cert. The document should cover the integration with IKEv2, security analysis, wire format, ..... Without a clear cut IETF documentation, it might be difficult for vendors to come to the same page and accept it. -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Friday, December 07, 2001 4:46 PM To: Wang, Cliff Cc: 'Jan Vilhuber'; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Wang, Cliff wrote: >> The justification being offered for saving it is "nothing else works" >> -- that is, that there is no other equally quick and simple way of >> setting up a simple connection. This is false. There are non-PKI >> approaches to public keys which are just as simple and easy as PSK. > > ...Where are these alternative approaches documented in the form of > internet draft? I don't know that anyone has ever thought to document them in I-Ds, since mostly they are too simple to need much explaining. The hard part is deprogramming people from the "public key implies PKI" religion. Self-signed certs are a well-known concept, and fit naturally into existing cert machinery. RFC 3110 documents how to represent (in DNS) RSA public keys without involving any form of certificate. We used that as our representation. We preconfigure with public keys in much the same way that we preconfigure with shared secrets. What else is there to tell? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 14:41:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Mff218535; Fri, 7 Dec 2001 14:41:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06463 Fri, 7 Dec 2001 16:58:35 -0500 (EST) Date: Fri, 7 Dec 2001 14:07:13 -0800 (PST) From: Jan Vilhuber To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: <3C10104B.485198C@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 6 Dec 2001, Ricky Charlet wrote: > Howdy, > > I'm moving my position from 'in favor' to 'neutral' on saving a > pre-shared key authentication mode. Its not PSK itself or even current > look alike PSK functionality I'd like to see saved. There is a new > feature I want to see added and that is interaction with legacy > authentication systems in support of remote access users ala > draft-ietf-ipsra-reqmts-04.txt. But then we should close down IPSRA, shouldn't we? Either we have IPSRA to take care of remote-access legacy methods, or we cancel that WG and fold the requirements back into the IPsec WG... jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 14:49:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7MnK218643; Fri, 7 Dec 2001 14:49:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06524 Fri, 7 Dec 2001 17:12:54 -0500 (EST) To: "Dilkie, Lee" Cc: "Hallam-Baker, Phillip" , "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Selection Criteria? References: <29B5A21C13C8D51190F900805F65B4ECF19BB7@rndex50.ottawa.mitel.com> From: Derek Atkins Date: 07 Dec 2001 17:22:29 -0500 In-Reply-To: "Dilkie, Lee"'s message of "Fri, 7 Dec 2001 14:41:19 -0500" Message-ID: Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Dilkie, Lee" writes: > I see no reason to revoke a certificate just because you re-issued > due to a name change. There was no comprimise of the original > private key, so why would you need to go through the expense of > revoking a certificate? Because a certificate is a binding of a Public/Private keypair to a name. If, as Phill is suggesting, you use the IP Address as the name, then every time you change IP Address you need to revoke and re-issue certificates. Note that this does not mean you need to change/revoke the Public/Private Keypair in use, you just need to revoke the binding to the old IP Address. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Dec 7 14:53:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Mrk219015; Fri, 7 Dec 2001 14:53:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06445 Fri, 7 Dec 2001 16:57:26 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698C7@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Henry Spencer'" , IP Security List Subject: RE: Son-of-IKE Performance Date: Fri, 7 Dec 2001 14:06:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17F6B.7003F3E0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17F6B.7003F3E0 Content-Type: text/plain; charset="iso-8859-1" Let us leave such discussions to the point where we have selected an algorithm to implement. My reason for calling foul was that an argument was made on performance grounds, not on the grounds that the specification is incomplete. We know that the specifications are incomplete. Those contributing to the discussion are all capable of filling in the abstracted elements. As it happens XKASS is faster than JFK, SIGMA or IKE, using fewer round trips and fewer cryptographic operations. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Friday, December 07, 2001 4:27 PM > To: IP Security List > Subject: Re: Son-of-IKE Performance > > > On Fri, 7 Dec 2001, Dan Harkins wrote: > > My point is that just saying "by obvious means" is not > good enough. > > After seeing how emminently reasonable people interpreted > "by obvious > > means" differently during implementation of RFC2409 I think it is > > necessary to explain the means exactly. > > I concur. One thing that all too many IETF protocols suffer > from is the > inability to produce a fully interoperable implementation > solely from the > documents, without relying on a body of folklore to fill in details. > > > Henry Spencer > > henry@spsystems.net > ------_=_NextPart_000_01C17F6B.7003F3E0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C17F6B.7003F3E0-- From owner-ipsec@lists.tislabs.com Fri Dec 7 14:54:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7Ms6219043; Fri, 7 Dec 2001 14:54:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06508 Fri, 7 Dec 2001 17:09:58 -0500 (EST) Message-Id: <200112052312.fB5NC5I00906@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-reply-to: Your message of "Wed, 05 Dec 2001 01:06:23 +0200." <200112042306.BAA16872@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Dec 2001 18:12:04 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Markku" == Markku Savela writes: Markku> If Key negotiation protocol is open for new ideas, I would Markku> strongly prefer a key negotiation that only negotiates one Markku> directional SA as requested by the kernel side of the IPSEC (in Markku> my case, key management is provided with the information about Markku> the required SA via PFKEYv2 ACQUIRE message). It does not need to Markku> know about selectors, it does not need to know even if the SA is Markku> for tunnel or transport mode! Also, note that key management Markku> doesn't need care about bundles either! That sounds great for outbound/initiator. How does one communicate selectors to the kernel of the responder? I frankly think that we need a lot more policy to be communicated (both negotiation style and agreement style). If you feel that this belongs in another protocol, I won't argue with that. But, I strongly think that it must exist. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPA6pw4qHRg3pndX9AQEkQQQApY8PWGeJSdlYwyQkqfGtuOcBbuPmHOm/ e1Op9ymZcLWSXblme6SsS041q81cIacyPSAb9/GhsXYT5yfDovHP6LX7VfVzdL49 cPHtc2fnpM1aC7q+LnXrYOyp6e70RQBM4Ihw21MRQnCE/+6+9gcCTcqIFnVJPYx0 IqXJm7U1M2c= =IPwR -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Dec 7 15:09:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7N9l219664; Fri, 7 Dec 2001 15:09:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06575 Fri, 7 Dec 2001 17:30:31 -0500 (EST) Date: Fri, 7 Dec 2001 14:39:38 -0800 (PST) From: Jan Vilhuber To: "Wang, Cliff" cc: "'Henry Spencer'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <4652644B98DFF34696801F8F3070D3FE011884C7@D2CSPEXM001.smartpipes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Wang, Cliff wrote: > The documentation is not about how to generate self-signed cert. The > document should cover the integration with IKEv2, security analysis, wire > format, ..... > There ARE no integration issues, nor is the security analysis any different (if you transfer a pre-shared symmetric key insecurely over an insecure network, then you're being stupid. Same is true for transferring an RSA keypair (pair!) over an insecure network, when (for example) pre-provisioning configs and sending them to the user. There's no difference that I can ascertain). On the wire format doesn't change. That's the whole point. IKEv2 and JFK define messages using rsa keys. That's all you need. The question is: How do you get and authenticate the RSA key. That's the part we're talking about. The main thrust some people are trying to get across is that you do not (again: NOT) need a PKI for this. There's several ways to get an RSA key distributed and authenticated, and there's plenty of alternative to a PKI. Hints: Look at SSH as one example. Freeswan's way of distributing RSA keys via DNS has also been documented (and discussed on this list. Check the archives). Consider saving the RSA fingerprint instead of the key, then compare the saved fingerprint to the key you received from the other side in a self-signed certificate (CERT payload in IKE and IKEv2). Etc... the variety is endless, and doesn't affect interoperability of the protocol itself (since the protocol only cares that you HAVE an RSA key you trust, and not how you got it, nor how you decided to trust it; it merely assumes you haven't been stupid and let some attacker see your secret). > Without a clear cut IETF documentation, it might be difficult for vendors to > come to the same page and accept it. > As Henry mentioned, most people thought this stuff was pretty simple and self-explanatory (and obvious). Maybe someone should write it up, since apparently not everyone sees the obvious (even after being told by several people multiple times). jan > > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Friday, December 07, 2001 4:46 PM > To: Wang, Cliff > Cc: 'Jan Vilhuber'; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > On Fri, 7 Dec 2001, Wang, Cliff wrote: > >> The justification being offered for saving it is "nothing else works" > >> -- that is, that there is no other equally quick and simple way of > >> setting up a simple connection. This is false. There are non-PKI > >> approaches to public keys which are just as simple and easy as PSK. > > > > ...Where are these alternative approaches documented in the form of > > internet draft? > > I don't know that anyone has ever thought to document them in I-Ds, since > mostly they are too simple to need much explaining. The hard part is > deprogramming people from the "public key implies PKI" religion. > > Self-signed certs are a well-known concept, and fit naturally into existing > cert machinery. > > RFC 3110 documents how to represent (in DNS) RSA public keys without > involving any form of certificate. We used that as our representation. > We preconfigure with public keys in much the same way that we preconfigure > with shared secrets. What else is there to tell? > > Henry Spencer > henry@spsystems.net > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 15:35:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB7NZ6220333; Fri, 7 Dec 2001 15:35:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06612 Fri, 7 Dec 2001 17:37:52 -0500 (EST) Date: Fri, 7 Dec 2001 17:47:02 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: compare-jfk-sigma.txt In-Reply-To: <200112052312.fB5NC5I00906@marajade.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 On Wed, 5 Dec 2001, Michael Richardson wrote: > I frankly think that we need a lot more policy to be communicated (both > negotiation style and agreement style). > If you feel that this belongs in another protocol, I won't argue with that. > But, I strongly think that it must exist. Agreed. IKE has been successful partly because it does meet this need, in a half-baked and sometimes-inadequate way. It is not unreasonable to argue that it should be in a separate protocol. But it *is* unreasonable to argue that it should be in a separate protocol *which is to be defined later*. If you want this taken out of son-of-IKE, you need to specify how the functionality is to be replaced. That means a protocol spec, not just a promise to write one someday. Personally I see no particular need to separate the two, and much harm that might result. I think this notion comes from the peculiar world-view of PFKEY, which solves half the problem and pretends that the other half doesn't exist. Yes, it makes the world simpler, but... Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 7 16:19:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB80JZ223918; Fri, 7 Dec 2001 16:19:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06782 Fri, 7 Dec 2001 18:29:53 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3A59@NS-CA> From: Michael Choung Shieh To: "'Jan Vilhuber'" , "Wang, Cliff" Cc: "'Henry Spencer'" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 15:37:29 -0800 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 Given the many methods of transfering PK without consesus, interoperability of protocol USE is an issue. If one chooses self-sign cert and freeswan uses DNS-SEC and you use fingerprint, the admin won't call it's interoperable even the protocol itself is interoperable. Then the draft should document it and require vendor to support certain scenarios, or it just move the complexity from protocol to real-world implemenation. The main reason to remove PSK is to reduce complexity. now what? -------------------------------------------- Michael Shieh -------------------------------------------- -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Friday, December 07, 2001 2:40 PM To: Wang, Cliff Cc: 'Henry Spencer'; ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode On Fri, 7 Dec 2001, Wang, Cliff wrote: > The documentation is not about how to generate self-signed cert. The > document should cover the integration with IKEv2, security analysis, wire > format, ..... > There ARE no integration issues, nor is the security analysis any different (if you transfer a pre-shared symmetric key insecurely over an insecure network, then you're being stupid. Same is true for transferring an RSA keypair (pair!) over an insecure network, when (for example) pre-provisioning configs and sending them to the user. There's no difference that I can ascertain). On the wire format doesn't change. That's the whole point. IKEv2 and JFK define messages using rsa keys. That's all you need. The question is: How do you get and authenticate the RSA key. That's the part we're talking about. The main thrust some people are trying to get across is that you do not (again: NOT) need a PKI for this. There's several ways to get an RSA key distributed and authenticated, and there's plenty of alternative to a PKI. Hints: Look at SSH as one example. Freeswan's way of distributing RSA keys via DNS has also been documented (and discussed on this list. Check the archives). Consider saving the RSA fingerprint instead of the key, then compare the saved fingerprint to the key you received from the other side in a self-signed certificate (CERT payload in IKE and IKEv2). Etc... the variety is endless, and doesn't affect interoperability of the protocol itself (since the protocol only cares that you HAVE an RSA key you trust, and not how you got it, nor how you decided to trust it; it merely assumes you haven't been stupid and let some attacker see your secret). > Without a clear cut IETF documentation, it might be difficult for vendors to > come to the same page and accept it. > As Henry mentioned, most people thought this stuff was pretty simple and self-explanatory (and obvious). Maybe someone should write it up, since apparently not everyone sees the obvious (even after being told by several people multiple times). jan > > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Friday, December 07, 2001 4:46 PM > To: Wang, Cliff > Cc: 'Jan Vilhuber'; ipsec@lists.tislabs.com > Subject: RE: Please save the pre-shared key mode > > > On Fri, 7 Dec 2001, Wang, Cliff wrote: > >> The justification being offered for saving it is "nothing else works" > >> -- that is, that there is no other equally quick and simple way of > >> setting up a simple connection. This is false. There are non-PKI > >> approaches to public keys which are just as simple and easy as PSK. > > > > ...Where are these alternative approaches documented in the form of > > internet draft? > > I don't know that anyone has ever thought to document them in I-Ds, since > mostly they are too simple to need much explaining. The hard part is > deprogramming people from the "public key implies PKI" religion. > > Self-signed certs are a well-known concept, and fit naturally into existing > cert machinery. > > RFC 3110 documents how to represent (in DNS) RSA public keys without > involving any form of certificate. We used that as our representation. > We preconfigure with public keys in much the same way that we preconfigure > with shared secrets. What else is there to tell? > > Henry Spencer > henry@spsystems.net > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 16:21:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB80LX224140; Fri, 7 Dec 2001 16:21:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06826 Fri, 7 Dec 2001 18:46:09 -0500 (EST) Message-Id: <200112072355.fB7NtsG01403@fatty.lounge.org> To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: Your message of "Fri, 07 Dec 2001 14:07:13 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1400.1007769354.1@tibernian.com> Date: Fri, 07 Dec 2001 15:55:54 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPSRA is doing a little bit more than legacy authentication support but you do have a point. Doing as Ricky suggests will also obviate that insecure hack that Marcus described today. What we're telling people who want to do legacy authentication in a standard way is that they have to do a 4-8 message exchange (depending on whether you want DOS protection and your legacy authentication token is not out of sync or in something like "Next Code Mode") and establish an authenticated Diffie-Hellman secret which you promptly throw away to do another 9-10 message exchange (IKEv1, phase 1 and phase 2 with the optional commit bit set) or 3-4 message exchange (assuming whatever the WG standardizes on for SOI looks something like what is being proposed today) and establish another authenticated Diffie-Hellman secret and IPsec SAs. Protocol Initiator Responder Latency ------------------------------------------------ PIC+IKE 1 signature 2 signatures 6.5-9 RTT + 1-2 RTs to legacy server 2 verifies 1 verify 2 DH agree 2 DH agree Worst case 22 messages, best case 14 messages, just to do legacy authentication!? No wonder people are devising hacks around that. For all the concern expressed over the number of roundtrips a protocol has I'm surprised that no one has harped on that before. Dan. On Fri, 07 Dec 2001 14:07:13 PST you wrote > On Thu, 6 Dec 2001, Ricky Charlet wrote: > > > Howdy, > > > > I'm moving my position from 'in favor' to 'neutral' on saving a > > pre-shared key authentication mode. Its not PSK itself or even current > > look alike PSK functionality I'd like to see saved. There is a new > > feature I want to see added and that is interaction with legacy > > authentication systems in support of remote access users ala > > draft-ietf-ipsra-reqmts-04.txt. > > But then we should close down IPSRA, shouldn't we? Either we have IPSRA to > take care of remote-access legacy methods, or we cancel that WG and fold the > requirements back into the IPsec WG... > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Fri Dec 7 16:56:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB80uo226140; Fri, 7 Dec 2001 16:56:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06882 Fri, 7 Dec 2001 19:18:39 -0500 (EST) Message-ID: <3C115F4B.803A3327@redcreek.com> Date: Fri, 07 Dec 2001 16:31:07 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > On Thu, 6 Dec 2001, Ricky Charlet wrote: > > > Howdy, > > > > I'm moving my position from 'in favor' to 'neutral' on saving a > > pre-shared key authentication mode. Its not PSK itself or even current > > look alike PSK functionality I'd like to see saved. There is a new > > feature I want to see added and that is interaction with legacy > > authentication systems in support of remote access users ala > > draft-ietf-ipsra-reqmts-04.txt. > > But then we should close down IPSRA, shouldn't we? Either we have IPSRA to > take care of remote-access legacy methods, or we cancel that WG and fold the > requirements back into the IPsec WG... > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 Let the consequenses be what they may. Does our working group have the will to include IPSRA requirements into second generation IKE directly? I hope so. (personally, I believe that IPSRA is close enough to finishing and the second generation IKE debate is new enough that we could get fielded implementations of PIC+IKEv1 which could inform our development of second generation IKE protocols). -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Fri Dec 7 16:57:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB80vA226168; Fri, 7 Dec 2001 16:57:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06888 Fri, 7 Dec 2001 19:19:02 -0500 (EST) Date: Sat, 8 Dec 2001 02:27:34 +0200 Message-Id: <200112080027.CAA22278@burp.tkv.asdf.org> From: Markku Savela To: mcr@sandelman.ottawa.on.ca CC: ipsec@lists.tislabs.com In-reply-to: <200112052312.fB5NC5I00906@marajade.sandelman.ottawa.on.ca> (message from Michael Richardson on Wed, 05 Dec 2001 18:12:04 -0500) Subject: Re: compare-jfk-sigma.txt References: <200112052312.fB5NC5I00906@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > That sounds great for outbound/initiator. > > How does one communicate selectors to the kernel of the responder? Policy is what gets handed down to you by a person (or a system) responsible for the security of the site or service you want to use and which is protected by IPSEC. One should be able to activate multiple policies for different services at same time. The combined policies form the IPSEC SPD. It would be be nice to have a common format for the policy transfer format. The format must cope with the fact that a user may access several independent services with different policies at same time, thus the format must be mergeable... But, anyways, in my view, the policy is outside the key negotiation. In normal case there is never a need to communicate the policies at this point. -- Markku Savela From owner-ipsec@lists.tislabs.com Fri Dec 7 17:13:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB81D8226610; Fri, 7 Dec 2001 17:13:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06958 Fri, 7 Dec 2001 19:32:09 -0500 (EST) Date: Fri, 7 Dec 2001 16:41:15 -0800 (PST) From: Jan Vilhuber To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode In-Reply-To: <3C115F4B.803A3327@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Ricky Charlet wrote: > Jan Vilhuber wrote: > > > > On Thu, 6 Dec 2001, Ricky Charlet wrote: > > > > > Howdy, > > > > > > I'm moving my position from 'in favor' to 'neutral' on saving a > > > pre-shared key authentication mode. Its not PSK itself or even current > > > look alike PSK functionality I'd like to see saved. There is a new > > > feature I want to see added and that is interaction with legacy > > > authentication systems in support of remote access users ala > > > draft-ietf-ipsra-reqmts-04.txt. > > > > But then we should close down IPSRA, shouldn't we? Either we have IPSRA to > > take care of remote-access legacy methods, or we cancel that WG and fold the > > requirements back into the IPsec WG... > > > > jan > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > Let the consequenses be what they may. Does our working group have the > will to include IPSRA requirements into second generation IKE directly? I've seen preciously little discussion about Cheryl's requirements document in general... jan > I hope so. > > (personally, I believe that IPSRA is close enough to finishing and the > second generation IKE debate is new enough that we could get fielded > implementations of PIC+IKEv1 which could inform our development of > second generation IKE protocols). > > > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." Benjamin Franklin > > Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 17:36:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB81aI227301; Fri, 7 Dec 2001 17:36:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07035 Fri, 7 Dec 2001 19:54:02 -0500 (EST) To: "Hallam-Baker, Phillip" Cc: "'Henry Spencer'" , IP Security List Subject: Re: Son-of-IKE Performance References: <2F3EC696EAEED311BB2D009027C3F4F4058698C7@vhqpostal.verisign.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 07 Dec 2001 17:03:04 -0800 In-Reply-To: "Hallam-Baker, Phillip"'s message of "Fri, 7 Dec 2001 14:06:36 -0800" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hallam-Baker, Phillip" writes: > Let us leave such discussions to the point where we have selected an > algorithm to implement. > > My reason for calling foul was that an argument was made on > performance grounds, not on the grounds that the specification > is incomplete. > > We know that the specifications are incomplete. Those contributing > to the discussion are all capable of filling in the abstracted > elements. I'm with Phill on this one. While it's true that it's a failing of many IETF protocols to be insufficiently specific, it's equally true that misplaced concreteness is a serious problem in the early design phases of many IETF protocols. Let's decide on the cryptographic skeleton first and once we've done that we can decide on the bits on the wire and the detailed key expansion transforms, both of which are largely orthogonal to the key agreement issue we're currently discussing. > As it happens XKASS is faster than JFK, SIGMA or IKE, using fewer > round trips and fewer cryptographic operations. I had noticed that :) -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri Dec 7 17:50:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB81oi228397; Fri, 7 Dec 2001 17:50:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07135 Fri, 7 Dec 2001 20:11:34 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Henry Spencer" Cc: References: Subject: Re: Please kill preshared key. Date: Fri, 7 Dec 2001 20:21:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 08 Dec 2001 01:20:48.0204 (UTC) FILETIME=[913BB8C0:01C17F86] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agree, It is is not what IPSec intended to work. :-) However, do you agree my statement make sense? --- David ----- Original Message ----- From: "Henry Spencer" To: "david chen" Cc: Sent: Friday, December 07, 2001 2:44 PM Subject: Re: Please kill preshared key. > On Fri, 7 Dec 2001, david chen wrote: > > What I infered is that > > the pre-shared symmetric key can be used for both authentication and > > encryption without key-exchange (KE) since this key is exchnaged through > > 'out-of-band' secured channel and is *intended* for the two devices only. > > Your inference is incorrect. That is not how today's IPSec PSK works. > > Henry Spencer > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Fri Dec 7 18:04:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB824o229440; Fri, 7 Dec 2001 18:04:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07353 Fri, 7 Dec 2001 20:30:54 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Henry Spencer" , "Michael Choung Shieh" Cc: "Wang, Cliff" , References: Subject: Re: Please save the pre-shared key mode Date: Fri, 7 Dec 2001 20:40:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 08 Dec 2001 01:40:08.0137 (UTC) FILETIME=[449B7390:01C17F89] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about a smart card (have private/public key pair) at remote system register its public key at HQ. --- David ----- Original Message ----- From: "Henry Spencer" To: "Michael Choung Shieh" Cc: "Wang, Cliff" ; Sent: Friday, December 07, 2001 3:11 PM Subject: RE: Please save the pre-shared key mode > On Fri, 7 Dec 2001, Michael Choung Shieh wrote: > > How about someone unwrap the myth. I don't care if it's PK or PSK as long > > as we can set it up as easy as setup PSK in IKE v1. > > Can someone show step-by-step procedure to set up PK? In a typical > > scenario, the HQ sys admin sets up vpn and sends config to his unknowledged > > remote offic peer to download to remote device. How do we do it when using > > PK without using PKI? > > The HQ sysadmin generates a public/private key pair for the new > host/device, and that is sent to his remote peer as part of the config. > Remote peer installs config (including key pair). Communication is > established. Just like PSK. > > Alternatively, loading the config into the remote system includes > generating a keypair, and the public key is then sent back to the HQ > sysadmin for inclusion in his setup. Communication is established. > > The second approach is generally preferable, because it avoids ever > transmitting secret information (the private key) between the sysadmins. > But it does require a bit more savvy on the part of the remote sysadmin, > and an extra sysadmin-to-sysadmin communications hop. If the remote > sysadmin is really not up to much, and/or the software he is using is > unhelpful, having the HQ sysadmin do the keypair generation may be > preferable. > > Henry Spencer > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Fri Dec 7 18:08:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB828X229737; Fri, 7 Dec 2001 18:08:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07103 Fri, 7 Dec 2001 20:08:11 -0500 (EST) Message-Id: <200112080117.fB81HN577344@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: JFK algorithm choice Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Dec 2001 17:17:23 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Apologies on advance for focusing on the bits on the wire over the cryptographic skeleton but I wanted to get some clarification on a few fine points of JFK. I'm not sure I understand how JFK chooses cryptographic algorithms. S 2.5 says: We also eliminate negotiation, in favor of ukases issued by the Responder. The Responder is providing a service; it is entitled to set its own requirements for that service. and later: Any cryptographic primitive mentioned by the Responder is acceptable; the Initiator can choose any it wishes. This information appear to be contained in the GRPIFOr TLV transmitted in Msg2, defined in S 4.2: grpInfo is expressed as a string of at least four octets. The first octet is the encryption algorithm ID, the second octet is the signature algorithm ID, and the third octet is the hash function used for session key derivation. Each remaining octet specifies an acceptable group number. As far as I can tell, the only way to express multiple digest and encryption algorithms (as the second excerpt suggests you can do) is for the Responder to send multiple GRPINFO payloads in Msg2. Is this what you intend? Section 4.2 also says that the SA payload is: SA tag Meaning 1 IPsec SA, as described in [RFC2409] What's not clear to me here is that the SA payload in RFC 2409 seems to (when you factor in 2407 and 2408) also include algorithm information. How is the SA payload intended to be used? Have I misread one of the specs? -Ekr From owner-ipsec@lists.tislabs.com Fri Dec 7 18:30:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB82Uv200833; Fri, 7 Dec 2001 18:30:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07382 Fri, 7 Dec 2001 20:44:41 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Dan Harkins Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 20:54:19 -0500 Message-Id: <20011208015419.C18F17B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200112072110.fB7L9uG01024@fatty.lounge.org>, Dan Harkins writes: > I am well aware it is possible to derive keys for many SAs out of >a mutually authenticated shared secret. > > My point is that just saying "by obvious means" is not good enough. >After seeing how emminently reasonable people interpreted "by obvious >means" differently during implementation of RFC2409 I think it is >necessary to explain the means exactly. > > My stretching wasn't the "obvious" one? Well there's another person >on this list who thought it was. Moreover, there is nothing in JFK >to say it was the incorrect way or that what means "obvious" to you >is the correct way. Do you see the problem? Dan -- if we were about to issue "Last Call" on JFK, I'd not only agree with you, I'd be leading the charge. We're not nearly at that stage yet. The purpose of the JFK draft was to describe a cryptographic protocol, not (yet) an implementation spec. Clearly, there are many ways to derive the four needed keys from the one exchange; equally clearly, a final spec *must* specify exactly one, in very precise form. If and when the WG agrees on JFK, we'll happily fill in those details. But those details are not nearly as controversial as JFK vs. IKEv2 vs. SIGMA vs. XKASS, and not even as controversial as the requirements on which we'll base that choice. This is, I think, obvious to everyone. Why are you beating on this point? Is there anyone here, with the possible exception of you, who thinks that this is the crucial criterion on which the WG is going to decide among the different proposals? To my mind, the next interesting issue is what the SA description should look like. I've heard many complaints that the current standard is a significant source of complexity and interoperability problems. In fact, I'd planned on writing a draft on that issue, but a number of things (including the events of September 11) interfered. (Inflammatory comments deleted.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Fri Dec 7 18:47:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB82lJ201331; Fri, 7 Dec 2001 18:47:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07428 Fri, 7 Dec 2001 20:50:41 -0500 (EST) Message-Id: <4.3.2.7.2.20011207174922.04b8b9c8@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Dec 2001 17:59:26 -0800 To: "Steven M. Bellovin" From: Barbara Fraser Subject: Re: discussion of SIGMA-IKE Cc: "Hallam-Baker, Phillip" , "'EKR'" , Jan Vilhuber , ipsec@lists.tislabs.com In-Reply-To: <20011207204046.2613C7C00@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree. We try to get the drafts in before the deadline because it makes it easier for interested people to access it but it doesn't mean we don't/can't discuss those that don't make IDs in time. It's important for us to discuss the Sigma draft along with the IKE-v2 and JFK docs. Barb At 12:40 PM 12/7/2001, Steven M. Bellovin wrote: >In message ><2F3EC696EAEED311BB2D009027C3F4F4058698C0@vhqpostal.verisign.com>, " >Hallam-Baker, Phillip" writes: > > > > >I don't think anyone is suggesting that we should only discuss JFK because > >it is the only draft submitted to the working group before the cutoff for a > >single IETF meeting. Clearly we want the discussion at Salt Lake City to be > >as productive as possible and that is best achieved by discussing all the > >possible options. > >I certainly don't claim that. My understanding -- and my practice, in >the groups I chair -- are that all drafts that are within charter and >are the basis for WG disucssion are "official" WG documents, and can be >named accordinglhy. It most emphatically does *not* imply any >preferred status. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at > http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Fri Dec 7 18:51:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB82pw201668; Fri, 7 Dec 2001 18:51:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07487 Fri, 7 Dec 2001 21:09:56 -0500 (EST) Date: Fri, 7 Dec 2001 18:19:05 -0800 (PST) From: Jan Vilhuber To: Barbara Fraser cc: "Steven M. Bellovin" , "Hallam-Baker, Phillip" , "'EKR'" , ipsec@lists.tislabs.com Subject: Re: discussion of SIGMA-IKE In-Reply-To: <4.3.2.7.2.20011207174922.04b8b9c8@mira-sjc5-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Barbara Fraser wrote: > I agree. We try to get the drafts in before the deadline because it makes > it easier for interested people to access it but it doesn't mean we > don't/can't discuss those that don't make IDs in time. It's important for > us to discuss the Sigma draft along with the IKE-v2 and JFK docs. > Obviously I agree, and now I also stand corrected as to procedure ;) jan > Barb > > At 12:40 PM 12/7/2001, Steven M. Bellovin wrote: > >In message > ><2F3EC696EAEED311BB2D009027C3F4F4058698C0@vhqpostal.verisign.com>, " > >Hallam-Baker, Phillip" writes: > > > > > > > >I don't think anyone is suggesting that we should only discuss JFK because > > >it is the only draft submitted to the working group before the cutoff for a > > >single IETF meeting. Clearly we want the discussion at Salt Lake City to be > > >as productive as possible and that is best achieved by discussing all the > > >possible options. > > > >I certainly don't claim that. My understanding -- and my practice, in > >the groups I chair -- are that all drafts that are within charter and > >are the basis for WG disucssion are "official" WG documents, and can be > >named accordinglhy. It most emphatically does *not* imply any > >preferred status. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > Full text of "Firewalls" book now at > > http://www.wilyhacker.com > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 19:57:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB83vM204210; Fri, 7 Dec 2001 19:57:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07650 Fri, 7 Dec 2001 22:16:44 -0500 (EST) Message-Id: <3.0.3.32.20011207192805.00f234d0@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 07 Dec 2001 19:28:05 -0800 To: Michael Choung Shieh , "'Henry Spencer'" , "Wang, Cliff" From: Alex Alten Subject: RE: Please save the pre-shared key mode Cc: ipsec@lists.tislabs.com In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3A53@NS-CA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And "setup" better include: 1. Key generation 2. Key distribution (in a trustworthy manner) 3. Key performance during the initial authentication of the session. Given these, PSK beats PK on #1 and #3 hands down. They are the same for #2. - Alex At 11:33 AM 12/7/2001 -0800, Michael Choung Shieh wrote: > >How about someone unwrap the myth. I don't care if it's PK or PSK as long >as we can set it up as easy as setup PSK in IKE v1. > >Can someone show step-by-step procedure to set up PK? In a typical >scenario, the HQ sys admin sets up vpn and sends config to his unknowledged >remote offic peer to download to remote device. How do we do it when using >PK without using PKI? > >Let's prove if it's as easy as setting up PSK. > >-------------------------------------------- >Michael Shieh >NetScreen Technologies, Inc >350 Oakmead Parkway >Sunnyvale, CA 94085 >TEL: (408)730-6060 >FAX: (408)730-6050 >Email: mshieh@netscreen.com >-------------------------------------------- > >-----Original Message----- >From: Henry Spencer [mailto:henry@spsystems.net] >Sent: Friday, December 07, 2001 10:34 AM >To: Wang, Cliff >Cc: ipsec@lists.tislabs.com >Subject: RE: Please save the pre-shared key mode > > >On Fri, 7 Dec 2001, Wang, Cliff wrote: >>>> other hand, PSK based IKE and PKI based IKE has been the main way people >>>> deploying VPN. Under that context, PSK is simpler to run than PKI. >>> I think that's the myth Dan was talking about. >> >> From the operation point of view, PSK is quick and easy to set up service. >> It works and customers are happy. It is more real than a myth. > >The myth being referred to is the notion that PSK is somehow unique in >being quick and easy to set up, because public keys absolutely require >PKI. That's wrong. It is just as quick and easy to set up with preshared >*public* keys. You don't need a PKI to use public keys. > > Henry Spencer > henry@spsystems.net > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Dec 7 20:00:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB840s204281; Fri, 7 Dec 2001 20:00:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07670 Fri, 7 Dec 2001 22:29:38 -0500 (EST) Message-Id: <3.0.3.32.20011207194130.00f234d0@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 07 Dec 2001 19:41:30 -0800 To: Jan Vilhuber , "Wang, Cliff" From: Alex Alten Subject: RE: Please save the pre-shared key mode Cc: ipsec@lists.tislabs.com In-Reply-To: References: <4652644B98DFF34696801F8F3070D3FE011884C3@D2CSPEXM001.smartpipes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, Cut it out. Going PK implies PKI, which in turn implies X.509. Don't try to BS the fact that X.509 is a beast to use. You got everything from signature chain checking to X.500 name space to all sorts of attribute extensions. Heck I'm into this stuff, and Microsoft did a good job with their email client GUI, yet I finally gave up signing my emails because there was always something I had to do to keep it going or to work around some stupid interoperability problem. - Alex At 12:44 PM 12/7/2001 -0800, Jan Vilhuber wrote: >On Fri, 7 Dec 2001, Wang, Cliff wrote: > >> >> This thread is talking about saving the pre-shared key mode, instead of >> saying nothing else works. >> >> I am not sure how you can hide a whole PKI system away under smart UI? > >I'm not about to design your products for you, but several alternatives have >been proposed, ranging from using self-signed pre-shared certs and using >key-finger-prints in lieu of a pre-shared key. The rest is up to you. > >> I am also not sure how smart UI can solve the issue that on Cisco low end >> box PKI based IPsec performs much slower in comparison to PSK based IPsec. >> >The last point seems completely off topic. I can't run linux on my wristwatch >either. What's the point? New things may only work on newer boxes. > >jan > > > > >> >> -----Original Message----- >> From: Jan Vilhuber [mailto:vilhuber@cisco.com] >> Sent: Friday, December 07, 2001 2:58 PM >> To: Wang, Cliff >> Cc: 'Dan McDonald'; ipsec@lists.tislabs.com >> Subject: RE: Please save the pre-shared key mode >> >> >> On Fri, 7 Dec 2001, Wang, Cliff wrote: >> >> > >From the operation point of view, PSK is quick and easy to set up >> > >service. >> > It works and customers are happy. It is more real than a myth. >> > >> The myth is that nothing else works. PSK is a behind-the-scenes abstraction, >> that good programmers can hide from users altogether. A good UI can hide any >> other mechanism as well and make it as easy to configure. >> >> jan >> >> >> > >> > >> > -----Original Message----- >> > From: Jan Vilhuber [mailto:vilhuber@cisco.com] >> > Sent: Thursday, December 06, 2001 6:39 PM >> > To: Wang, Cliff >> > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com >> > Subject: RE: Please save the pre-shared key mode >> > >> > > On the >> > > other hand, PSK based IKE and PKI based IKE has been the main way people >> > > deploying VPN. Under that context, PSK is simpler to run than PKI. >> > > >> > I think that's the myth Dan was talking about. >> > >> > jan >> > >> > >> > >> > > >> > > -----Original Message----- >> > > From: Dan McDonald [mailto:danmcd@east.sun.com] >> > > Sent: Thursday, December 06, 2001 1:28 PM >> > > To: Wang, Cliff >> > > Cc: ipsec@lists.tislabs.com >> > > Subject: Re: Please save the pre-shared key mode >> > > >> > > >> > > > 1) Simplicity >> > > > Pre-shared key mode is simpler to support by eliminating the >> > > > requirement of supporting complex PKI. >> > > >> > > It's a myth that public-key implies you MUST have a PKI. >> > > >> > > Self-signed certs combined with explicit out-of-band trust models is >> > > just a non-cumbersome as pre-shared keys, IMHO, and they also offer >> > > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but >> > > FreeSWAN has a self-signed cert model that works, right?) >> > > >> > > If we keep pre-shared, let's have a scalable way of identifying >> > > them. >> > > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address >> > > pairs is as much hassle as PKI registration (it's just less snake-oil >> > > than most PKIs ;). >> > > >> > > For testing, I run server machines with self-signed certs. For >> > > small >> > > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any >> > > of the PKI cruft. Peer-to-peer explosions is about the only case >> > > where PKI is really needed, and pre-shared won't help you any there >> > > either. It's just a matter of running certificate-generation, e-mail, >> > > and verifying hashes out-of-band. >> > > >> > > I'm not totally against nuking pre-shared. It's not, however, the >> > > panacea of simplicity many think it is, and simplicity arguments don't >> > > hold water. >> > > >> > > Dan >> > > >> > >> > -- >> > Jan Vilhuber vilhuber@cisco.com >> > Cisco Systems, San Jose (408) 527-0847 >> > >> >> -- >> Jan Vilhuber vilhuber@cisco.com >> Cisco Systems, San Jose (408) 527-0847 >> > > -- >Jan Vilhuber vilhuber@cisco.com >Cisco Systems, San Jose (408) 527-0847 > > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Dec 7 20:31:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB84Vg204756; Fri, 7 Dec 2001 20:31:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07691 Fri, 7 Dec 2001 22:33:47 -0500 (EST) Date: Fri, 7 Dec 2001 19:42:58 -0800 (PST) From: Jan Vilhuber To: Alex Alten cc: "Wang, Cliff" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <3.0.3.32.20011207194130.00f234d0@pop3.netvista.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Alex Alten wrote: > Jan, > > Cut it out. Going PK implies PKI, which in turn implies X.509. That's utter rubbish. jan > Don't try to BS the fact that X.509 is a beast to use. You got > everything from signature chain checking to X.500 name space to > all sorts of attribute extensions. Heck I'm into this stuff, > and Microsoft did a good job with their email client GUI, yet > I finally gave up signing my emails because there was always > something I had to do to keep it going or to work around some > stupid interoperability problem. > > - Alex > > At 12:44 PM 12/7/2001 -0800, Jan Vilhuber wrote: > >On Fri, 7 Dec 2001, Wang, Cliff wrote: > > > >> > >> This thread is talking about saving the pre-shared key mode, instead of > >> saying nothing else works. > >> > >> I am not sure how you can hide a whole PKI system away under smart UI? > > > >I'm not about to design your products for you, but several alternatives have > >been proposed, ranging from using self-signed pre-shared certs and using > >key-finger-prints in lieu of a pre-shared key. The rest is up to you. > > > >> I am also not sure how smart UI can solve the issue that on Cisco low end > >> box PKI based IPsec performs much slower in comparison to PSK based IPsec. > >> > >The last point seems completely off topic. I can't run linux on my wristwatch > >either. What's the point? New things may only work on newer boxes. > > > >jan > > > > > > > > > >> > >> -----Original Message----- > >> From: Jan Vilhuber [mailto:vilhuber@cisco.com] > >> Sent: Friday, December 07, 2001 2:58 PM > >> To: Wang, Cliff > >> Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > >> Subject: RE: Please save the pre-shared key mode > >> > >> > >> On Fri, 7 Dec 2001, Wang, Cliff wrote: > >> > >> > >From the operation point of view, PSK is quick and easy to set up > >> > >service. > >> > It works and customers are happy. It is more real than a myth. > >> > > >> The myth is that nothing else works. PSK is a behind-the-scenes > abstraction, > >> that good programmers can hide from users altogether. A good UI can hide > any > >> other mechanism as well and make it as easy to configure. > >> > >> jan > >> > >> > >> > > >> > > >> > -----Original Message----- > >> > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > >> > Sent: Thursday, December 06, 2001 6:39 PM > >> > To: Wang, Cliff > >> > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com > >> > Subject: RE: Please save the pre-shared key mode > >> > > >> > > On the > >> > > other hand, PSK based IKE and PKI based IKE has been the main way > people > >> > > deploying VPN. Under that context, PSK is simpler to run than PKI. > >> > > > >> > I think that's the myth Dan was talking about. > >> > > >> > jan > >> > > >> > > >> > > >> > > > >> > > -----Original Message----- > >> > > From: Dan McDonald [mailto:danmcd@east.sun.com] > >> > > Sent: Thursday, December 06, 2001 1:28 PM > >> > > To: Wang, Cliff > >> > > Cc: ipsec@lists.tislabs.com > >> > > Subject: Re: Please save the pre-shared key mode > >> > > > >> > > > >> > > > 1) Simplicity > >> > > > Pre-shared key mode is simpler to support by eliminating the > >> > > > requirement of supporting complex PKI. > >> > > > >> > > It's a myth that public-key implies you MUST have a PKI. > >> > > > >> > > Self-signed certs combined with explicit out-of-band trust models is > >> > > just a non-cumbersome as pre-shared keys, IMHO, and they also offer > >> > > IP-address-portability. (Henry Spencer, correct me if I'm wrong, but > >> > > FreeSWAN has a self-signed cert model that works, right?) > >> > > > >> > > If we keep pre-shared, let's have a scalable way of identifying > >> > > them. > >> > > In a multi-homed world (esp. IPv6), pre-shared keys indexed by address > >> > > pairs is as much hassle as PKI registration (it's just less snake-oil > >> > > than most PKIs ;). > >> > > > >> > > For testing, I run server machines with self-signed certs. For > >> > > small > >> > > (10-100) numbers of clients, it works out _quite_ nicely, and w/o any > >> > > of the PKI cruft. Peer-to-peer explosions is about the only case > >> > > where PKI is really needed, and pre-shared won't help you any there > >> > > either. It's just a matter of running certificate-generation, e-mail, > >> > > and verifying hashes out-of-band. > >> > > > >> > > I'm not totally against nuking pre-shared. It's not, however, the > >> > > panacea of simplicity many think it is, and simplicity arguments don't > >> > > hold water. > >> > > > >> > > Dan > >> > > > >> > > >> > -- > >> > Jan Vilhuber > vilhuber@cisco.com > >> > Cisco Systems, San Jose (408) > 527-0847 > >> > > >> > >> -- > >> Jan Vilhuber vilhuber@cisco.com > >> Cisco Systems, San Jose (408) 527-0847 > >> > > > > -- > >Jan Vilhuber vilhuber@cisco.com > >Cisco Systems, San Jose (408) 527-0847 > > > > > > > -- > > Alex Alten > Alten@Home.Com > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 20:40:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB84e8204867; Fri, 7 Dec 2001 20:40:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07712 Fri, 7 Dec 2001 22:43:48 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Steven M. Bellovin'" , "'Dan Harkins'" Cc: Subject: RE: Son-of-IKE Performance Date: Fri, 7 Dec 2001 22:50:05 -0500 Message-ID: <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <20011208015419.C18F17B55@berkshire.research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But those details are not nearly as controversial as JFK vs. > IKEv2 vs. > SIGMA vs. XKASS, and not even as controversial as the requirements on > which we'll base that choice. This is, I think, obvious to > everyone. > Why are you beating on this point? Is there anyone here, with the > possible exception of you, who thinks that this is the > crucial criterion > on which the WG is going to decide among the different proposals? It is a little misleading for a protocol which being presented as the 'simple alternative' to omit many of the so-called minor details. I personally doubt that the crytographic framework will really be the deciding factor in which protocol advances. It might make the difference between IKEv2 and SIGMA, but not JFK. JFK is not just a key exchange protocol; it's a political movement. Here's a question. Have the authors of JFK given any thought to how (if?) they will incorporate NAT-traversal? With IKEv2, the already completed drafts from IKEv1 can be presumably carried forward. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Fri Dec 7 20:41:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB84f0204890; Fri, 7 Dec 2001 20:41:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07728 Fri, 7 Dec 2001 22:49:47 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: andrew.krywaniuk@alcatel.com Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 22:59:26 -0500 Message-Id: <20011208035926.C4BB47B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com>, "Andrew Krywaniuk" writes: >> But those details are not nearly as controversial as JFK vs. >> IKEv2 vs. >> SIGMA vs. XKASS, and not even as controversial as the requirements on >> which we'll base that choice. This is, I think, obvious to >> everyone. >> Why are you beating on this point? Is there anyone here, with the >> possible exception of you, who thinks that this is the >> crucial criterion >> on which the WG is going to decide among the different proposals? > >It is a little misleading for a protocol which being presented as the >'simple alternative' to omit many of the so-called minor details. I >personally doubt that the crytographic framework will really be the deciding >factor in which protocol advances. It might make the difference between >IKEv2 and SIGMA, but not JFK. JFK is not just a key exchange protocol; it's >a political movement. > >Here's a question. Have the authors of JFK given any thought to how (if?) >they will incorporate NAT-traversal? With IKEv2, the already completed >drafts from IKEv1 can be presumably carried forward. JFK doesn't rely on IP addresses at all -- it can pass through NATs just fine. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Fri Dec 7 20:41:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB84f5204904; Fri, 7 Dec 2001 20:41:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07783 Fri, 7 Dec 2001 23:08:10 -0500 (EST) Message-Id: <200112080417.XAA12941@bcn.East.Sun.COM> Date: Fri, 7 Dec 2001 23:17:52 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: discussion of SIGMA-IKE To: ekr@rtfm.com, vilhuber@cisco.com, pbaker@verisign.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: R4O/4qMx3+1vIpE4KH8Skw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re: Phillip Hallam-Baker said JFK was the only draft submitted before the deadline: IKEv2 was submitted before the deadline also. Not that it matters, but just setting the record straight. :-) Radia From owner-ipsec@lists.tislabs.com Fri Dec 7 20:44:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB84io204953; Fri, 7 Dec 2001 20:44:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07795 Fri, 7 Dec 2001 23:11:39 -0500 (EST) Date: Fri, 7 Dec 2001 20:20:49 -0800 (PST) From: Jan Vilhuber To: Alex Alten cc: Michael Choung Shieh , "'Henry Spencer'" , "Wang, Cliff" , ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <3.0.3.32.20011207192805.00f234d0@pop3.netvista.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Alex Alten wrote: > And "setup" better include: > 1. Key generation > 2. Key distribution (in a trustworthy manner) > 3. Key performance during the initial authentication of the session. > > Given these, PSK beats PK on #1 and #3 hands down. > They are the same for #2. > Re #1: Actually, you stand a better chance of having a device generate a *good* RSA keypair, than coming up with a *good* pre-shared symmetric key by yourself (most people don't like machine generated random pre-shared keys). Most users pick dictionary words, so I'd say PK beats symmetric keys by a long shot. It may TAKE longer (in terms of processing power), but you're going to be more secure. But processing time doesn't mean a thing for key generation as it's a one-time thing, and not per-connection-setup. If #3 is a real concern, consider KINK... jan > - Alex > > At 11:33 AM 12/7/2001 -0800, Michael Choung Shieh wrote: > > > >How about someone unwrap the myth. I don't care if it's PK or PSK as long > >as we can set it up as easy as setup PSK in IKE v1. > > > >Can someone show step-by-step procedure to set up PK? In a typical > >scenario, the HQ sys admin sets up vpn and sends config to his unknowledged > >remote offic peer to download to remote device. How do we do it when using > >PK without using PKI? > > > >Let's prove if it's as easy as setting up PSK. > > > >-------------------------------------------- > >Michael Shieh > >NetScreen Technologies, Inc > >350 Oakmead Parkway > >Sunnyvale, CA 94085 > >TEL: (408)730-6060 > >FAX: (408)730-6050 > >Email: mshieh@netscreen.com > >-------------------------------------------- > > > >-----Original Message----- > >From: Henry Spencer [mailto:henry@spsystems.net] > >Sent: Friday, December 07, 2001 10:34 AM > >To: Wang, Cliff > >Cc: ipsec@lists.tislabs.com > >Subject: RE: Please save the pre-shared key mode > > > > > >On Fri, 7 Dec 2001, Wang, Cliff wrote: > >>>> other hand, PSK based IKE and PKI based IKE has been the main way people > >>>> deploying VPN. Under that context, PSK is simpler to run than PKI. > >>> I think that's the myth Dan was talking about. > >> > >> From the operation point of view, PSK is quick and easy to set up service. > >> It works and customers are happy. It is more real than a myth. > > > >The myth being referred to is the notion that PSK is somehow unique in > >being quick and easy to set up, because public keys absolutely require > >PKI. That's wrong. It is just as quick and easy to set up with preshared > >*public* keys. You don't need a PKI to use public keys. > > > > Henry Spencer > > henry@spsystems.net > > > > > -- > > Alex Alten > Alten@Home.Com > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 20:50:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB84oc205052; Fri, 7 Dec 2001 20:50:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07810 Fri, 7 Dec 2001 23:15:02 -0500 (EST) Date: Fri, 7 Dec 2001 20:24:13 -0800 (PST) From: Jan Vilhuber To: Andrew Krywaniuk cc: "'Steven M. Bellovin'" , "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: Son-of-IKE Performance In-Reply-To: <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Andrew Krywaniuk wrote: > > But those details are not nearly as controversial as JFK vs. > > IKEv2 vs. > > SIGMA vs. XKASS, and not even as controversial as the requirements on > > which we'll base that choice. This is, I think, obvious to > > everyone. > > Why are you beating on this point? Is there anyone here, with the > > possible exception of you, who thinks that this is the > > crucial criterion > > on which the WG is going to decide among the different proposals? > > It is a little misleading for a protocol which being presented as the > 'simple alternative' to omit many of the so-called minor details. I > personally doubt that the crytographic framework will really be the deciding > factor in which protocol advances. It might make the difference between > IKEv2 and SIGMA, but not JFK. JFK is not just a key exchange protocol; it's > a political movement. > > Here's a question. Have the authors of JFK given any thought to how (if?) > they will incorporate NAT-traversal? With IKEv2, the already completed > drafts from IKEv1 can be presumably carried forward. > That being said, how about we divert some of this energy to debating the requirements doc: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt The requirements do (I believe) talk about having to support Nat traversal (as well as a few other things that JFK doesn't address). If we all agree to the requirements, then we can continue debating whether JFK must add them. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 7 22:10:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB86AI206367; Fri, 7 Dec 2001 22:10:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08026 Sat, 8 Dec 2001 00:33:15 -0500 (EST) Date: Sat, 8 Dec 2001 00:42:30 -0500 From: Ran Canetti Message-Id: <200112080542.AAA25298@ornavella.watson.ibm.com> To: pbaker@verisign.com Subject: XCASS security Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phill, I've taken a look at the XCASS protocol (the PDF file on the site you pointed to, printed August 15, 2001, page 12, Fig 4). It seems that the protocol is susceptible to the following attack: Assume that an attacker managed to obtain the secret DH exponent of the initiator in some ill-protected session. This means that the attacker has the initiator's signature on some g^x, where the attacker knows x. >From now on, the attacker can impersonate this poor initiator in the eyes of any prospective responder, basically until the end of time. Is that true or am I confused? (One can ofcourse argue about the likelyhood of the attacker obtaining such an x. I can imagine some settings where this is not so unlikey...) I was trying to fix this without adding a flow or assuming that the initiator knows the responder's ID ahead of time, but couldn't see how. Ran From owner-ipsec@lists.tislabs.com Fri Dec 7 22:16:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB86Gd206647; Fri, 7 Dec 2001 22:16:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08050 Sat, 8 Dec 2001 00:40:32 -0500 (EST) Message-ID: <3C11AA45.5CAF5A93@storm.ca> Date: Sat, 08 Dec 2001 00:51:01 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode References: <4652644B98DFF34696801F8F3070D3FE011884C3@D2CSPEXM001.smartpipes.com> <3.0.3.32.20011207194130.00f234d0@pop3.netvista.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten wrote: > > Jan, > > Cut it out. Going PK implies PKI, which in turn implies X.509. Nonsense. Public key techniques can be used without any infrastructure at all, and without certificates. FreeS/WAN (www.freeswan.org) has been doing this, with RSA keys, for some time. There are no signatures on the keys. They are not embedded in certificates. This code is in widespread use, and works just fine. There are only two real problems with this. One is that you need to authenticate transferred public keys with some out-of-band method. This is much easier to do securely than transferring shared secrets, but can still require careful work, especially in a large network. The other is that the IPsec RFCs do not specify a format for RSA key exchange, so various implementers can make different choices and then have their products fail to interoperate. This can and should be fixed in a revised standard, or perhaps in a BCP RFC. It is also clearly possible to do more than this without going to a full PK infrastructure. Have one signing key, known to all players and controlled by an organisation's central admin folk. Require all keys used in IPsec to be signed by that key. This gives some advantages over the plain RSA keys, providing an authentication mechanism, without anything like the full complexity of PKI. From owner-ipsec@lists.tislabs.com Sat Dec 8 00:27:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB88RK220636; Sat, 8 Dec 2001 00:27:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08240 Sat, 8 Dec 2001 02:25:39 -0500 (EST) Message-Id: <200112080735.fB87ZFG01812@fatty.lounge.org> To: "Steven M. Bellovin" Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance In-Reply-To: Your message of "Fri, 07 Dec 2001 20:54:19 EST." <20011208015419.C18F17B55@berkshire.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1809.1007796915.1@tibernian.com> Date: Fri, 07 Dec 2001 23:35:15 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 07 Dec 2001 20:54:19 EST you wrote > > Dan -- if we were about to issue "Last Call" on JFK, I'd not only agree > with you, I'd be leading the charge. We're not nearly at that stage > yet. The purpose of the JFK draft was to describe a cryptographic > protocol, not (yet) an implementation spec. Clearly, there are many > ways to derive the four needed keys from the one exchange; equally > clearly, a final spec *must* specify exactly one, in very precise form. > If and when the WG agrees on JFK, we'll happily fill in those details. I would hope all the details (not just this one) were filled in before a decision is made. That's a little like buying a house sight unseen. The floorplan is what I wanted but the roof leaks, the doors don't close all the way, and a fuse is blown every time I turn the lights on. > But those details are not nearly as controversial as JFK vs. IKEv2 vs. > SIGMA vs. XKASS, and not even as controversial as the requirements on > which we'll base that choice. This is, I think, obvious to everyone. > Why are you beating on this point? Is there anyone here, with the > possible exception of you, who thinks that this is the crucial criterion > on which the WG is going to decide among the different proposals? I'm beating the point because people don't seem to understand what I'm trying to say. That is the only conclusion I can draw when Phillip responds to a post in which I acknowledge the well known fact that multiple keys can be derived from an authenticated Diffie-Hellman secret (although that was not the point of my post) by stating that it's possible to derive multiple keys from an authenticated Diffie-Hellman secret. Since he obviously missed the point I felt compelled to repeat it. Now I'm sorry for screaming but I MADE A MISTAKE! I mistook what you meant with what you wrote (apparently so did Markku Savela). > To my mind, the next interesting issue is what the SA description > should look like. I've heard many complaints that the current standard > is a significant source of complexity and interoperability problems. > In fact, I'd planned on writing a draft on that issue, but a number of > things (including the events of September 11) interfered. Complex yes. Interoperability problems? Not for the past few years. The interoperability problems today are not with SA construction or parsing. > (Inflammatory comments deleted.) Well that's nice, thanks. Dan. From owner-ipsec@lists.tislabs.com Sat Dec 8 07:47:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB8Flv226083; Sat, 8 Dec 2001 07:47:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08535 Sat, 8 Dec 2001 09:30:12 -0500 (EST) Date: Sat, 8 Dec 2001 09:39:26 -0500 From: Ran Canetti Message-Id: <200112081439.JAA25938@ornavella.watson.ibm.com> To: Charlie_Kaufman@iris.com, canetti@watson.ibm.com Subject: Re: compare-jfk-sigma.txt Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From canetti Sat Dec 8 02:41:02 2001 To: canetti@watson.ibm.com Charlie, This is good news. So it seems that we are moving towards settling for a 4-message protocol with built-in (non-optional) DOS protection. This indeed seems like a sound design choice. In this case, we could be down to two basic alternatives, the decision between which is primarily a requirements decision to be made by the WG: 1. The WG decides that it wants a protocol that protects the initiator's identity against active attacks (and is willing to pay the associated costs, ie, extra sig and sending the responder's ID in the clear). In this case JFK seems like a good choice. 2. The WG decides that it wants a protocol that protects the responder's ID against active attacks (or that it doesnt care about ID protection against active attacks one way or the other). In this case the protocol below seems like a good choice. (Just to reiterate - this protocol is basically the 4-msg variant of SIGMA, as proposed by Hugo a few days ago, with the HMAC being on the outside as done in IKEv2.) This should make the decision in SLC a bit easier... Ran BTW, regarding the fields under the signatures. Both in JFK and in the proposal below only the "cryptographically essential" fields were included. Personally, I have no problem with including more fields under the signature, if this helps implementation. Other people may feel differently though. > From Charlie_Kaufman@iris.com Fri Dec 7 10:34:06 2001 > > Ran Canetti wrote: > > > Remark: Indeed, this is the way IKEv2 does the authentication. But, > unlike > > IKEv2, I would make this an integral part of the protocol rather than > > invoking ESP. > > I apologize for the confusion. IKEv2 doesn't "run on top of ESP" or > anything > like that. I was merely trying to avoid spelling out how to do padding, > etc. > The ESP spec seemed to have a nice clean format for "integrity protect and > encrypt this blob", i.e., IV | data | padding | padding length | hmm | > integrity. > So rather than spelling that out, I meant "use the syntax from the ESP > spec". > So yes, it should be the way you say, and it should be specified that > way in the spec. (and that way we also don't inherit an unused byte > where ESP happens to put the "next header" field--where I marked "hmm".) > What I meant is exactly what you > wrote: First encrypt the message with Ke and then integrity protect it with > Ka using > HMAC. > > > In other words, do: > > > > Message 1, I->R: Ni,g^r > > > > Message 2, R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKe}(Ni, Nr, g^i, g^r) > > > > Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKe}(Ni, Nr, g^i, g^r), > > E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr)), > > > HMAC{ka}(E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr))) > > > > Message 4, R->I: E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa')), > > HMAC{ka}(E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa'))) > > > > (Ka is a key derived from g^ir in the same way as Ke.) > > The one remaining difference is the choice of bits being signed. The > protocol > above signs selected fields from the messages, while IKEv2 proposes > signing the entirety of messages 1 and 2 as they appear on the wire. (and > the entirety of all future messages are integrity protected, so all fields > in all messages are integrity protected.) The advantage of the > IKEv2 approach is that it captures all relevant fields in the messages > including > any extensions like vendor IDs. It's also easier to specify, since the SIG > above will have to specify exactly how the bits are encoded for signing > (TLV vs raw; payloads with or without headers, etc). > > --Charlie > > This footnote confirms that either (1) this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including computer > viruses, (2) this email message was sent by a virus that appends this > footnote, or (3) (most likely) the sender of this message is trying to > raise awareness of how foolish it would be to place any confidence in > footnotes like this. > > > From owner-ipsec@lists.tislabs.com Sat Dec 8 08:09:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB8G9L229482; Sat, 8 Dec 2001 08:09:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08571 Sat, 8 Dec 2001 10:26:29 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.13135.224414.597343@thomasm-u1.cisco.com> Date: Sat, 8 Dec 2001 07:35:43 -0800 (PST) To: Jan Vilhuber Cc: Andrew Krywaniuk , "'Steven M. Bellovin'" , "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Requirements, Please (was: Son-of-IKE Performance ) In-Reply-To: References: <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > That being said, how about we divert some of this energy to debating the > requirements doc: > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Hear, hear! It's pretty disheartening to see the sniping level go up here when it's plainly evident that there's a lot of convergent evolution going on. Instead of targeting other drafts weaknesses -- especially ones that are easily fixed -- we should be focusing most of our effort on what the protocols are suppposed to *DO*. JFK, for example, has made a fairly strong statement that symmetric pre-shared keys are a non-requirement. I haven't seen the IKEv2 take a strong position one way or the other. Thus the only way to *really* give the proper valuation on this subject is to get consensus reflected into the requirements draft. This also has the side benefit that we can talk about contentious issues in the abstract rather than impugning somebody's baby. Let's not snatch defeat from the jaws of victory! Mike From owner-ipsec@lists.tislabs.com Sat Dec 8 10:12:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB8ICk206226; Sat, 8 Dec 2001 10:12:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08911 Sat, 8 Dec 2001 12:29:54 -0500 (EST) Message-ID: <3C125088.2096C5C0@storm.ca> Date: Sat, 08 Dec 2001 12:40:24 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Selection Criteria? References: <10C8636AE359D4119118009027AE9987120B7F72@FMSMSX34> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Walker, Jesse" wrote: > > Suddenly we suffer an embarassment of riches. We have three thoughtful, very > well crafted, very credible proposals for Son-of-IKE, and we need to > establish some selection criteria to choose among them. I wish we didn't > have to choose, because all three have some very nice characteristics. Part of the criteria might be how well they deal with the various problems raised in analysis and critiques of the existing IKE. There's a list of such papers at: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#analysis If that list is incomplete, please let me know and I'll add to it. There is one critique I've added since the web version, Fate Lab's paper: http://www.fatelabs.com/loki-vpn.pdf Should we invite people who've commented om IKE to comment on proposed replacements? Are some of those authors on the list? If so, any comment on how your critiques do or don't apply to current cadidates? Or on new weaknesses they might introduce? From owner-ipsec@lists.tislabs.com Sat Dec 8 10:32:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB8IWY206603; Sat, 8 Dec 2001 10:32:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08951 Sat, 8 Dec 2001 13:00:22 -0500 (EST) Date: Sat, 8 Dec 2001 13:08:59 -0500 (EST) From: Henry Spencer To: Alex Alten cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <3.0.3.32.20011207194130.00f234d0@pop3.netvista.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Alex Alten wrote: > Cut it out. Going PK implies PKI, which in turn implies X.509. Is this your religion or something? We've been telling you and telling you that this is *NOT TRUE*. FreeS/WAN, for example, is a widely-deployed IPsec implementation using PK without PKI. Can you explain why you believe this to be impossible? > Don't try to BS the fact that X.509 is a beast to use. No argument there. But it's irrelevant to the discussion at hand, since PK does *NOT* imply PKI or X.509. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Dec 8 15:48:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB8Nma223856; Sat, 8 Dec 2001 15:48:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09291 Sat, 8 Dec 2001 17:55:31 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15378.13135.224414.597343@thomasm-u1.cisco.com> References: <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com> <15378.13135.224414.597343@thomasm-u1.cisco.com> Date: Sat, 8 Dec 2001 14:50:11 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Requirements, Please (was: Son-of-IKE Performance ) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:35 AM -0800 12/8/01, Michael Thomas wrote: > JFK, for example, has made a fairly strong statement > that symmetric pre-shared keys are a non-requirement. > I haven't seen the IKEv2 take a strong position one > way or the other. *Both* proposals do not pre-shared keys, and only support identification by signature using public keys, and *both* proposals could easily be changed to support pre-shared keys. That is, neither proposal generates keying material from the ID or the public key used in the authentication, so either could be changed to have two modes of identification with no change to the rest of the protocol. The question is, as this thread header states so well, is whether or not this is a requirement. If it is, either protocol can be changed to handle the requirement; if it is not, neither protocol needs to have it removed. > Thus the only way to *really* give > the proper valuation on this subject is to get > consensus reflected into the requirements draft. > This also has the side benefit that we can talk > about contentious issues in the abstract rather > than impugning somebody's baby. Exactly right. There are other features in draft -00 of Proposal A that are not in draft -00 of Proposal B, and vice versa, but that fact should not affect our discussion of those two proposals unless the features cannot be transferred. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Dec 8 15:51:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB8Npk224310; Sat, 8 Dec 2001 15:51:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09340 Sat, 8 Dec 2001 18:17:01 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200112080735.fB87ZFG01812@fatty.lounge.org> References: <200112080735.fB87ZFG01812@fatty.lounge.org> Date: Sat, 8 Dec 2001 15:26:35 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Interoperability issues in setting up SAs Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:35 PM -0800 12/7/01, Dan Harkins wrote: >Complex yes. Interoperability problems? Not for the past few years. The >interoperability problems today are not with SA construction or parsing. It depends on what you mean by "SA construction". There are rampant interoperability issues with traffic selection today. I see problems with this all the time in our conformance testing. There are three ways to describe a target that is a single IP address (IPV4_ADDR, IPV4_ADDR, IPV4_ADDR_RANGE, and IPV4_ADDR_SUBNET), and two ways to describe a target that is a typical network (IPV4_ADDR_RANGE and IPV4_ADDR_SUBNET). Some implementations are liberal in what they accept and interpolate between these three; most don't, and will reject offers that don't use the ID type that they prefer. Some implementations are only able to propose using one type. This makes sense from a UI standpoint: do you really want to try to get a typical IS person to know what the other side is going to require for ID type? After the WG has decided what it wants to do about SA specification, the WG should help increate interoperability by specifying that TheNextKeyExchangeAlgorithm *only* allow one type (probably range, the most flexible). No need to get into that now, other than to possibly disagree with the statement above about how wonderful interop is today on this. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Dec 8 18:10:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB92Am206894; Sat, 8 Dec 2001 18:10:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09490 Sat, 8 Dec 2001 20:32:23 -0500 (EST) Message-Id: <200112080722.fB87MPI03590@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: initiator and responder in JFK In-reply-to: Your message of "Thu, 06 Dec 2001 01:36:55 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 08 Dec 2001 00:22:25 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I want to dispute section 2.5 of the JFK draft that says: " We also eliminate negotiation, in favor of ukases issued by the Responder. The Responder is providing a service; it is entitled to set its own requirements for that service. Any cryptographic primitive mentioned by the Responder is acceptable; the Initiator can choose any it wishes. We thus eliminate complex rules for selecting the ``best'' choice from two different sets. We also eliminate state to be kept by the Responder; the Initiator can either accept the Responder's desires or restart the protocol. " This seems to assume that all initiators of keying are "clients" and that all responders are "servers". It seems to also be under this guise that identity protection for the responder has been eliminated. Sure, this works for web sites. So, btw, does NAT and SSL. IPsec is about so much more. Even if a straight VPN situation, connecting to offices, I don't see clients and servers. What I see is a tunnel being set up when there is traffic, and possibly torn down when there is no traffic and the keying expires. (We do in FreeSWAN with Opportunistic Encryption.) Note - in the absense of TCP keepalives or application keepalives, there is no reason why the tunnel need remain up (or that the gateway continue to have power for that matter) when there is no activity on the connection. After days of silence, the "server" may suddendly want to send a packet. In that scenario, the "client" is now the "responder" - how can it make a reasonable choice here? And why should it reveal its identity? Perhaps I misunderstand the draft. I read it this morning after skiing yesterday, and I neglected to take the altitude/oxygen factor into account. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBG/qoqHRg3pndX9AQFiPgQAjn+f3YQjUdEg1NbjiY4SUVRrWowmCZ4n jmY+r3hhfLdkmyyCsM9m3LsJLtSB4ERbDZgySUGG9KhnhlDdhyVdrcgJC+wAbHOp gYSBn4HZ5nTwXnn9EhDPBD7mcGHmZx4qfBJrAuxlL20Dtv0RScrIwvwBm3SbWjN6 jOJITBrwcQ4= =ZVaD -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Dec 8 21:37:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB95bG212238; Sat, 8 Dec 2001 21:37:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09653 Sat, 8 Dec 2001 23:30:55 -0500 (EST) Date: Sat, 8 Dec 2001 23:39:57 -0500 (EST) From: Henry Spencer To: david chen cc: ipsec@lists.tislabs.com Subject: Re: Please kill preshared key. 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, 7 Dec 2001, david chen wrote: > > > What I infered is that > > > the pre-shared symmetric key can be used for both authentication and > > > encryption without key-exchange (KE) ... > > Your inference is incorrect. That is not how today's IPSec PSK works. > > Agree,.. > However, do you agree my statement make sense? Only if the preshared key is fairly high quality, which it often isn't. Using a poor key only for gateway authentication exposes you to impersonation attacks, but those are typically much more difficult to mount than eavesdropping attacks, which are the dominant failure mode with a poor encryption key. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Dec 8 21:39:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB95dH212279; Sat, 8 Dec 2001 21:39:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09641 Sat, 8 Dec 2001 23:24:20 -0500 (EST) Date: Sat, 8 Dec 2001 23:33:21 -0500 (EST) From: Henry Spencer To: Michael Choung Shieh cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3A59@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 7 Dec 2001, Michael Choung Shieh wrote: > Given the many methods of transfering PK without consesus, interoperability > of protocol USE is an issue. If one chooses self-sign cert and freeswan > uses DNS-SEC and you use fingerprint, the admin won't call it's > interoperable even the protocol itself is interoperable. > Then the draft should document it and require vendor to support certain > scenarios, or it just move the complexity from protocol to real-world > implemenation. Right. It needs nailing down. But this need not take more than a paragraph or two in the spec, *and* it doesn't interact with the rest in any significant way. Big win over having a separate protocol mode. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sun Dec 9 12:08:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB9K8t218170; Sun, 9 Dec 2001 12:08:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10464 Sun, 9 Dec 2001 13:45:26 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15379.45929.625866.653580@thomasm-u1.cisco.com> Date: Sun, 9 Dec 2001 10:54:33 -0800 (PST) To: "Steven M. Bellovin" Cc: "Hallam-Baker, Phillip" , "'Derek Atkins'" , "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Selection Criteria? In-Reply-To: <20011207201332.302A37C07@berkshire.research.att.com> References: <20011207201332.302A37C07@berkshire.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 Steven M. Bellovin writes: > The real problem here is that it puts the local operator -- the ISP, > the hotel, the conference LAN organizers -- in the critical path. If > one needs an address-based certificate, one can't do *anything* without > local operator co-operation. Apart from the fact that that doesn't > scale very well -- between last Tuesday and next Friday, I'll have been > in four different cities, have used or will use at least four different > LANs (two of which used borrowed jacks and/or IP addresses), etc., and > I'd have used more if airports and train stations (and, for that > matter, airplanes and trains) had 802.11 or Ethernet available. Why > should I need to go through that many ISPs instead of having a > certificate (public key, actually) issued by my employer for VPN access? With IP4 this is something of a hopeless situation, but with IP6 things may be better. Instead of certifying the entire address, suppose you certified the suffix instead? That is, the identity is your NAI or whatever which is independent of your attachment point. As far as I can tell, this would solve this problem, though I suppose you could complain about the birthday paradox with djinned up private addresses. Mike From owner-ipsec@lists.tislabs.com Sun Dec 9 20:00:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBA40l211950; Sun, 9 Dec 2001 20:00:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11190 Sun, 9 Dec 2001 21:44:55 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Henry Spencer" Cc: References: Subject: Re: Please kill preshared key. Date: Sun, 9 Dec 2001 21:54:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 10 Dec 2001 02:54:12.0601 (UTC) FILETIME=[F28A5690:01C18125] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just for argument sake, what if these pre-shared symmetric keys are from the DH keys that generated off-line. (no real exchnage but using the same process to get the key) Although this is not DH key exchange's function, it does achieve the same key quality... It can be used as both authentication and encryption. (the key is distributed through 'out-of-band' secured channel) --- David ----- Original Message ----- From: "Henry Spencer" To: "david chen" Cc: Sent: Saturday, December 08, 2001 11:39 PM Subject: Re: Please kill preshared key. > On Fri, 7 Dec 2001, david chen wrote: > > > > What I infered is that > > > > the pre-shared symmetric key can be used for both authentication and > > > > encryption without key-exchange (KE) ... > > > Your inference is incorrect. That is not how today's IPSec PSK works. > > > > Agree,.. > > However, do you agree my statement make sense? > > Only if the preshared key is fairly high quality, which it often isn't. > Using a poor key only for gateway authentication exposes you to > impersonation attacks, but those are typically much more difficult to > mount than eavesdropping attacks, which are the dominant failure mode with > a poor encryption key. > > Henry Spencer > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Mon Dec 10 01:01:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBA91K205354; Mon, 10 Dec 2001 01:01:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11587 Mon, 10 Dec 2001 03:01:30 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Steven M. Bellovin'" Cc: Subject: RE: Son-of-IKE Performance Date: Mon, 10 Dec 2001 03:07:06 -0500 Message-ID: <000701c18151$c1f24a20$3cc6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20011208035926.C4BB47B55@berkshire.research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Here's a question. Have the authors of JFK given any thought > to how (if?) > >they will incorporate NAT-traversal? With IKEv2, the already > completed > >drafts from IKEv1 can be presumably carried forward. > > JFK doesn't rely on IP addresses at all -- it can pass through NATs > just fine. The issue is not whether JFK can pass through NATs. The problem is that ESP/AH traffic can't go through NATs. We just went through a long design process of extending IKE to help ESP get through NATs and I'm wondering how/if JFK will tackle this issue. Jan replied to ask why people aren't debating the requirements draft. I guess what I'm saying is that I think this is a requirement. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Mon Dec 10 03:19:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBABJb219116; Mon, 10 Dec 2001 03:19:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA11861 Mon, 10 Dec 2001 05:36:07 -0500 (EST) Message-Id: <200112101046.NAA03051@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Dan Harkins , ipsec@lists.tislabs.com Date: Mon, 10 Dec 2001 13:45:51 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Comments on IKEv2 In-reply-to: <200112070844.fB78iA600456@fatty.lounge.org> References: Your message of "Fri, 07 Dec 2001 11:05:05 +0300." <200112070805.LAA07554@relay1.trustworks.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 7 Dec 01, at 0:44, Dan Harkins wrote: > Valery, zdrastii! Dan, privet! > On Fri, 07 Dec 2001 11:05:05 +0300 you wrote > > > > on what criteria could responder base his decision to narrow TS? > > Assume the following situation: initiator offers wildcard TSS, while > > responder's SPD consists of several adjacent ranges. The very natural > > decision for him is to select and sent back to initiator one of these > > ranges. But which? He doesn't have enough information because > > initiator has no ability to tell him what exact packet she is trying > > to make SA for. If this information were provided by initiator (via > > special payload or by requiring the first TSS in TS to always > > represent the actual IP packet triggered this negotiation), this > > would increase robustness of the protocol. > > The Responder could send back all of them. If the packet that But what if responder's policy dictates to protect each of these ranges with a separate SA (say, for the purpose of following authorization)? In this case responder needs to send back only one range, but which? > triggered the Initiator's negotiation was not included in what the > Responder sent back then those packets would not be sent after > negotiation for the subset succeeded (I'd imagine that if the > Initiator is a gateway it would send back some "administratively > prohibited by filter" message back to the source). But that is what > happens when the Responder does not allow the Initiator to access > what she (the Initiator) wants to access. No way around that. I agree. But with current protocol design the situation when negotiation is not succeeded will be happen erroneously sometimes (e.g. when in fact it might succeed). > Requiring the first TSS in the TS to always represent the actual > IP packet triggering the negotiation is an interesting idea but it > wouldn't solve the problem you described-- the packet matched a > wildcard selector. Or are you suggesting that no negotiation should Why not? It will. Responder will take the very first TSS and match it upon her SPD. If no suitable selector is found (or if selector found dictates to discard packet), responder will return "invalid id information" (or "no proposal chosen", anything you like) - and in this case negotiation won't succeed. But, if he found suitable selector, he then will need to check whether this selector is a subset of the other TSSs from initiator's proposal. If it is, it will return it, if not, it will return back initial initiator's set of TSSs. In any case, either they will have an SA that is equal to or "narrower" than initiator's initial proposal, or no SA will be made. Note, that the latter will take place only if responder's policy does prohibit such a traffic, but not due to the protocol deficiencies. Note also, that I presume that responder may not only remove some TSS from initiator's set (as explicitly said in the draft), but also to modify them, provided resulting set of TSS is equal or "narrower" than original. For example, he can replace wildcard TSS with range TSS, or one range TSS with another (if the latter is completely included in the former). Am I right? > succeed? That is, the Responder says "no proposal chosen" instead > of sending back a TS subset? > > > And one more comment. The peers seem to have no ability to inform > > each other about what kind of signature (RSA or DSA) they will use. > > Why so? This will require all implementation to support both (or even > > more if ECDSA come later) to be interoperable. Wouldn't it be better > > to negotiate this, as well as cipher, hash and group? > > Can't you infer what signature the peer supports? If you are > using a pre-shared public key you know directly. If you are enrolled > in a CA you should know what types of certs it will issue, no? If > it issues certs for both RSA and DSA public keys then you have to > support them both.If it issue certs for just one then you just have > to support that one. I would imagine that people want to make their Nothing can stop any particular CA to start issuing certificates with new type of key sometime. So, in general you don't know what types of key CA supports, even if you know what he is supporting now. And that makes me nervous - that is one more place that can lead to incompatibility (artificial, I think). I'd prefer types of signature to be negotiated, moreover the protocol has everything ready for this. > product as versatile as possible, though, and support them both That effectively forces an implementation to support every type of signature, including ECDSA, ElGamal, GOST and so on, that may be inappropriate for resource-limited devices... > regardless of whether a magic number is used to indicate up-front > which signature will be used. > > Dan. Vsego horoshego (best regards), Smyslov Valery. From owner-ipsec@lists.tislabs.com Mon Dec 10 05:34:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBADYf202072; Mon, 10 Dec 2001 05:34:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12123 Mon, 10 Dec 2001 07:58:01 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.22073.715364.46210@ryijy.hel.fi.ssh.com> Date: Sat, 8 Dec 2001 20:04:41 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com, dharkins@tibernian.com, ckaufman@iris.com, radia.perlman@sun.com Subject: Some comments to draft-ietf-ipsec-ikev2-00.txt X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 55 min X-Total-Time: 61 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The Internet Key Exchange (IKE) Protocol > I think this draft has done good job of combining the tree rfcs together, and I think this is one step in to the right direction. I have just finished reading this, sigma and jfk, and this seems to be only one that is ready enought that I can comment it. > 2.2 Use of Sequence Numbers for Message ID ... > In the case where the IKE_SA_init is rejected (e.g. in order to > require a cookie), the second IKE_SA_init message will begin the > sequence over with Message #0. I assume it is also reset to zero every time the IKE SA is rekeyed using the create-child-sa for the IKE SA? > 3 The Phase 1 Exchange ... > HDR*, ID, AUTH, [CERT,] > SA, TSi, TSr --> Are the SA, TSi, TSr mandatory in each Phase 1 exchanges? Accordingly to the diagram they seems to be, but I think there are cases where we want to only create the IKE SA and not to create any IPsec SAs yet. One example would be pre-generating IKE SA between two hosts on boot, and keep that up all the time. Also can the phase 2 SA creation included in this message also include PFS, i.e can there also be KEi and KEr payloads? If I read correctly from the draft only payloads that has any kind of ordering restrictions are TSi and TSr payloads. I would really like to remove that ordering restriction too, i.e modify the payloads so that they itself identify which payload they are. Just a side note, that in road warrior cases the normal TSi and TSr are going to be the traffic selectors for the DHCP over ipsec SA which ise used to the get the internal ip address for the host. > 3.1 Generating Keying Material for the IKE-SA ... > SKEYSEED = prf(Ni | Nr, g^ir) As this is the only place where nonces are used their entropy is limited to the output of the PRF. I.e it is no use of using nonces whose combined entropy is more than 128 bits if we using the HMAC-MD5 as PRF, as the output of the SKEYSEED is going to be 128 bits. > SKEYSEED_d = prf(SKEYSEED, g^ir | CKY-I | CKY-R | 0) > SKEYSEED_a = prf(SKEYSEED, SKEYSEED_d | g^ir | CKY-I | CKY-R | 1) > SKEYSEED_e = prf(SKEYSEED, SKEYSEED_a | g^ir | CKY-I | CKY-R | 2) I think that could be fixed by adding the nonces to the above calculations also in addition of the cookies. > 4 The CREATE-CHILD-SA (Phase 2) Exchange ... > The CREATE_CHILD_SA response contains: > > <-- HDR*, SA, Nr, [KEr,] > TSi, TSr > > The Responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, optionally a Diffie-Hellman value in > the KE payload, and the traffic selectors for traffic to be sent on > that SA in the TS payloads, which may be a subset of what the > Initiator of the child-SA proposed. If I understand correctly the initiator cannot force responder to use PFS, i.e to send its own KEr payload as it is optional and the group selectors inside the SAs only identify the type of group used in the KEi payload. Is this correct? Also those diagrams above does not indicate that there can be ID payload included in the phase 2 exchange (accordingly to 7.5 it can be included there). I think it would be better to include optional payloads also in to the packet flow pictures. Or at least have appendix listing complete exchange including all optional payloads in all possible packet where they can exists. > 7 Header and Payload Formats > > 7.1 The IKE Header > > IKE messages use UDP port 500, with one IKE message per UDP datagram. > Information from the UDP header is largely ignored except that the IP > addresses from the headers are reversed and used for return packets. If we want to get NAT-T (NAT Traversal) to work using IKEv2 we also need to reverse ports, the source port is NOT going to be port 500, thus the reply MUST be sent back to the original source port of the incoming packet. This also means that both ends must remember the destination port number associated with the IKE SA. > 7.3.1 Proposal Substructure Proposal and transform substructures are missing the criticality flags included in all other generic payload headers. I think it would be better to have only one generic payload header format... > o SPI Size (1 byte) - During phase 1 negotiation this field > MUST be zero. During phase 2 negotiation it is equal to the > size, in bytes, of the SPI of the corresponding protocol > (4 for ESP and AH, 2 for IPcomp). SPI size can also be 8 bytes in case this is the IKE SA rekeying. The new IKE SA needs cookies that needs to be specified here (as said in the 4.2). > o SPI (variable) - The sending entity's SPI. Even if the SPI > Size is not a multiple of 4 bytes, there is no padding > applied to the payload. When the SPI Size field is zero, > this field is not present in the Security Association > payload. This case occurs when negotiating the IKE-SA. That case does not occur in case of the IKE SA rekey. > o Proposal # (1 byte) - Identifies the immediate proposal. The > first proposal has the number of one (1) and each subsequent > proposal has a number which is one greater than the last. > > o Proposal Length (2 bytes) - Length in bytes of the proposal > including all SA Attributes. > > o SA Attributes (variable length) - This field contains SA > attributes for the immediate transform. The SA Attributes > MUST be represented using the Transform Attributes format > described below. > > o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. These entries here are some extra junk. Some of those fields ware already explained earlier and some of those fields do not exists at all. > 7.3.2 Transform Substructure ... > o Transform-ID (2 bytes) - The specific instance of the transform > type being proposed. Transform-ID is specified to be 2 bytes (16 bits), but all numbers assume it to be only 8-bits. I.e all ranges below end at 255 instead of 65535: > values 12-240 are reserved to IANA. Values 241-255 are for > private use among mutually consenting parties. ... > For Transform Type 3 (Authentication Method), defined Transform-IDs > are: > > Name Number Defined In > RESERVED 0 > Methods in IKEv1 1 - 5 (RFC2409) > Authenticated Diffie-Hellman 6 (this memo) Why do we need methods for IKEv1 here? This is in completely separate place compared to the IKEv1, so compability cannot be the issue, especially when none of the numbers defined by the IKEv1 are not used here (and I don't assume any of the numbers are going to be used). > For Transform Type 7 (Window Size), the Transform-ID specifies the > window size a peer is contracting to support to handle overlapping > requests (see section 2.3). One thing that is missing is the negotiation of the tunnel/transport/UDP-encapsulated-tunnel/UDP-encapsulated-transport mode. Also RFC2407 allows negotiation of the key rounds, which is missing from the attributes from the appendix. > 7.6 Certificate Payload ... > o Certificate Encoding (1 byte) - This field indicates the type > of certificate or certificate-related information contained > in the Certificate Data field. > > Certificate Encoding Value > -------------------- ----- > NONE 0 > PKCS #7 wrapped X.509 certificate 1 > PGP Certificate 2 > DNS Signed Key 3 > X.509 Certificate - Signature 4 > X.509 Certificate - Key Exchange 5 > Kerberos Tokens 6 > Certificate Revocation List (CRL) 7 > Authority Revocation List (ARL) 8 > SPKI Certificate 9 > X.509 Certificate - Attribute 10 > RESERVED 11 - 255 Ok, can someone explain me again what is the X.509 Certificate - Key Exchange. If it still means the encryption capable key then I think we can either rename it or remove it as we do not need any encryption capable keys anymore (no public key encryption modes). It would be simplier to have only one number allocated for the X.509 keys. > 7.7 Certificate Request Payload ... > The Certificate Request Payload is processed by inspecting the "Cert > Encoding" field to determine whether the processor has any > certificates of this type. If so the "Certification Authority" field > is inspected to determine if the processor has any certificates which > can be validated up to the specified certification authority. This > can be a chain of certificates. If a certificate exists which > satisfies the criteria specified in the Certificate Request Payload > it MUST be sent back to the certificate requestor; if a certificate > chain exists which goes back to the certification authority specified > in the request the entire chain MUST be sent back to the certificate > requestor. If no certificates exist then no further processing is I think the "MUST" above is little too much. I would say "it MUST sends its own certificate, and it SHOULD send as much of the certificate chain it has". Long certificate chains just cause the IKE packets to be bigger thus causing fragmentation which then causes other problems. Also the common problem case in the IKEv1 should be documented here, i.e what the empty certificate request means or is it forbidden? > 7.10 Notify Payload ... > o Notification Data (variable length) - Informational or error data > transmitted in addition to the Notify Message Type. Values for > this field are message specific, see below. Why not using the same encoding that is defined in the draft-ietf-ipsec-notifymsg-04.txt? It makes some things much easier... For example the textual error message can be very usefull when it says that your "authentication failed, because the certificate you provided could not be verified because the crl for the CA could not be fetched". > INVALID-MESSAGE-ID 9 > > Sent when either an IKE MESSAGE-ID more that ten greater ^^^ I assume that should say negotiated window size. I think following three messages overlap: > INVALID-KEY-INFORMATION 17 > > The KE field is the wrong length. This can occur where there > is no error if the Initiator guesses incorrectly which > Diffie-Hellman group the Responder will accept. > Notification data contains the Transform Substructure > describing the chosen Diffie-Hellman group. ... > IKE-SA-INIT-REJECT 32 > > This notification is sent in an IKE-SA-RESPONSE to request > that the Initiator retry the request with the supplied > cookie (and optionally the supplied Diffie-Hellman group). > This is not really an error, but is processed like one in > that it indicates that the connection request was rejected. > The Notification Data, if present, contains the Transform > Substructure describing the preferred Diffie-Hellman group. > > INVALID-KE-PAYLOAD 33 > > This error indicates that the KE payload does not match the > chosen Diffie-Hellman group. It can occur legitimately in > either Phase 1 or Phase 2 if the Initiator supports multiple > Diffie-Hellman groups and incorrectly anticipates which one > the Responder will choose. If the KE payloads and the first group does not match which one of them to send? If it is first packet and we want to have cookie exchange then we send IKE-SA-INIT-REJECT, but otherwise we can send either INVALID-KEY-INFORMATION or INVALID-KE-PAYLOAD. I think we only need one... > SINGLE-PAIR-REQUIRED 34 > > This error indicates that a Phase 2 SA request is > unacceptable because the Responder requires a separate SA > for each source / destination address pair. The Initiator is > expected to respond by requesting an SA for only the > specific traffic he is trying to forward. This is usefull, but it would need the granularity level (i.e is it per-host or per-protocol or per-port which is required by the responder). > 7.11 Delete Payload > > The Delete Payload, denoted DEL in this memo, contains a protocol- ^^^ Actually I think it is D elsewhere in the document. > o Protocol-Id (1 byte) - Must be zero for an IKE-SA, [] for > ESP, [] for AH, and [] for IPcomp. I think there is something missing above ([])?. > 7.13.1 Traffic Selector Substructure ... > TS_IPV4_ADDR_SUBNET 4 > > An IPv4 subnet represented by a pair of four (4) byte > values. The first value is an IPv4 address. The second is > an IPv4 network mask. Note that ones (1s) in the network > mask indicate that the corresponding bit in the address is > fixed, while zeros (0s) indicate a "wildcard" bit. ... > TS_IPV6_ADDR_SUBNET 6 > > An IPv6 subnet represented by a pair sixteen (16) byte > values. The first value is an IPv6 address. The second is > an IPv6 network mask. Note that ones (1s) in the network > mask indicate that the corresponding bit in the address is > fixed, while zeros (0s) indicate a "wildcard" bit. I think it would be better to change the format of subnet selectors to be IPVx_ADDRESS + Number of bits in the mask. It would remove the problems what to do when the other end proposes mask 0xff00ff00? (According to above it is completely valid :-) > 9 Security Considerations ... > to determine the strength of a key for any of the defined groups. The > default Diffie-Hellman group (number two) when used with a strong > random number generator and an exponent no less than 160 bits is Is the group 2 still the "default" group? > Appendix A > > Attribute Assigned Numbers > > class value type > -------------------------------------------------------------- > RESERVED 0-5 > Group Prime/Irreducible Polynomial 6 V > Group Generator One 7 V > Group Generator Two 8 V > Group Curve A 9 V > Group Curve B 10 V > RESERVED 11-13 > Key Length 14 B > Field Size 15 B > Group Order 16 V > Block Size 17 B As I said earlier this is missing some of the attributes defined int he IPsec DOI... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 10 05:34:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBADYj202083; Mon, 10 Dec 2001 05:34:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12076 Mon, 10 Dec 2001 07:54:01 -0500 (EST) From: Charlie_Kaufman@iris.com Subject: Re: compare-jfk-sigma.txt To: Ran Canetti Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_10042001 October 04, 2001 Message-ID: Date: Thu, 6 Dec 2001 23:30:37 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 12/07/2001 10:34:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ran Canetti wrote: > Remark: Indeed, this is the way IKEv2 does the authentication. But, unlike > IKEv2, I would make this an integral part of the protocol rather than > invoking ESP. I apologize for the confusion. IKEv2 doesn't "run on top of ESP" or anything like that. I was merely trying to avoid spelling out how to do padding, etc. The ESP spec seemed to have a nice clean format for "integrity protect and encrypt this blob", i.e., IV | data | padding | padding length | hmm | integrity. So rather than spelling that out, I meant "use the syntax from the ESP spec". So yes, it should be the way you say, and it should be specified that way in the spec. (and that way we also don't inherit an unused byte where ESP happens to put the "next header" field--where I marked "hmm".) What I meant is exactly what you wrote: First encrypt the message with Ke and then integrity protect it with Ka using HMAC. > In other words, do: > > Message 1, I->R: Ni,g^r > > Message 2, R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKe}(Ni, Nr, g^i, g^r) > > Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKe}(Ni, Nr, g^i, g^r), > E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr)), > HMAC{ka}(E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr))) > > Message 4, R->I: E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa')), > HMAC{ka}(E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa'))) > > (Ka is a key derived from g^ir in the same way as Ke.) The one remaining difference is the choice of bits being signed. The protocol above signs selected fields from the messages, while IKEv2 proposes signing the entirety of messages 1 and 2 as they appear on the wire. (and the entirety of all future messages are integrity protected, so all fields in all messages are integrity protected.) The advantage of the IKEv2 approach is that it captures all relevant fields in the messages including any extensions like vendor IDs. It's also easier to specify, since the SIG above will have to specify exactly how the bits are encoded for signing (TLV vs raw; payloads with or without headers, etc). --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. From owner-ipsec@lists.tislabs.com Mon Dec 10 05:34:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBADYo202095; Mon, 10 Dec 2001 05:34:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12107 Mon, 10 Dec 2001 07:57:00 -0500 (EST) Message-Id: <200112081728.fB8HSWpv018169@coredump.cs.columbia.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Eric Rescorla Cc: ipsec@lists.tislabs.com Subject: Re: JFK algorithm choice In-reply-to: Your message of "Fri, 07 Dec 2001 17:17:23 PST." <200112080117.fB81HN577344@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Dec 2001 12:28:32 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200112080117.fB81HN577344@romeo.rtfm.com>, Eric Rescorla writes: > >I'm not sure I understand how JFK chooses cryptographic algorithms. Basically, the Responder chooses all algorithms; the only choice the Initiator is offered is a variety of DH groups. > Any cryptographic > primitive mentioned by the Responder is acceptable; the Initiator > can choose any it wishes. s/cryptographic primitive/DH group >As far as I can tell, the only way to express multiple digest and >encryption algorithms (as the second excerpt suggests you can do) >is for the Responder to send multiple GRPINFO payloads in Msg2. >Is this what you intend? No (per above). >Section 4.2 also says that the SA payload is: > > SA tag Meaning > 1 IPsec SA, as described in [RFC2409] > >What's not clear to me here is that the SA payload in RFC 2409 >seems to (when you factor in 2407 and 2408) also include >algorithm information. How is the SA payload intended to be used? >Have I misread one of the specs? The SA payload is application-specific (application = IPsec). As such, the JFK *cryptographic* protocol cannot (or at least, does not) mandate what's sent therein. Adding that line in Section 4.2 was the expedient way of letting people know *where* in the protocol IPsec SA information would be included. Whether we end up using RFC2409 SAs or something different is one of the questions to be answered by the WG. My personal feeling is that it is basically a reasonable choice. Why not for the JFK-options ? We believe it's not necessary; furthermore, it avoids the problem of non-interoperable implementations (I've seen that in the past, as a practical issue --- Paul Hoffman should share his experiences on the subject with the WG too). -Angelos From owner-ipsec@lists.tislabs.com Mon Dec 10 05:36:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBADaR202136; Mon, 10 Dec 2001 05:36:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12077 Mon, 10 Dec 2001 07:54:07 -0500 (EST) Date: Fri, 7 Dec 2001 20:19:10 +0100 From: Markus Friedl To: ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode Message-ID: <20011207201910.B20539@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think removing pre-shared key mode is a very good idea, because it not only makes things simpler but it will also show that you don't need a PKI if you want to use public keys (e.g. SSH). -markus From owner-ipsec@lists.tislabs.com Mon Dec 10 05:36:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBADag202150; Mon, 10 Dec 2001 05:36:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12057 Mon, 10 Dec 2001 07:53:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15376.54947.458903.672254@pkoning.dev.equallogic.com> Date: Fri, 7 Dec 2001 09:48:03 -0500 (EST) From: Paul Koning To: mat@cisco.com Cc: CWang@smartpipes.com, ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode References: <4652644B98DFF34696801F8F3070D3FE011884A8@D2CSPEXM001.smartpipes.com> <15375.53966.77967.411018@pkoning.dev.equallogic.com> <15375.63067.104625.569813@thomasm-u1.cisco.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> >>>>> "Wang," == Wang, Cliff writes: >> >> Wang,> Very simple reasons, IKEv1 is going to be replaced by IKEv2 >> in Wang,> the future and KINK has yet to be standardized and it is >> not Wang,> going to replace IKE. On the other hand, adding PSK >> support in Wang,> IKEv2 is not an overkill, but provides much more >> flexibilities Wang,> and more choices for service providers. >> >> Agreed. >> >> It makes no sense to call a protocol XYZv2 if you're removing from >> it one of the very widely used features of XYZv1. >> >> If you want a protocol without preshared keys, feel free, but then >> don't call it IKE and don't expect people to give up IKEv1. Michael> The name of protocol is irrelevant at this point. I don't agree. Its name *is* relevant if it is a name that says "this is the second version of a previously defined protocol, intended to supersede the first version". And that is the name currently given to the draft. So... is the intent that this protocol is supposed to be viewed as a replacement for the protocol defined in RFC 2408/2409? Or is it supposed to be considered a new, unrelated, protocol? If the latter, then the requirements set is open. But if the former, then the new protocol MUST include among its requirements all the features of the earlier protocol that are important. It is clear from looking at customer installations that pre-shared key is a critical feature of IKE. Another point: if the problem with IKEv1 is that it has too many options -- which is a fair point -- how does it help matters to define yet another protocol that products will have to implement IN ADDITION to the already existing complex protocol? Why bother? If the goal is to improve matters for implementers and customers, the goal should be to create a new protocol which is indeed a viable replacement for the previous protocol, fully entitled to the name "IKE V2" because it incorporates the capabilities for which there is a proven need while cleaning up in other areas. So what are we doing? Creating more protocols that increase everyone's burden, or making things simpler? paul From owner-ipsec@lists.tislabs.com Mon Dec 10 06:33:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAEXR206037; Mon, 10 Dec 2001 06:33:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12256 Mon, 10 Dec 2001 08:55:12 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.38155.49527.8799@ryijy.hel.fi.ssh.com> Date: Sun, 9 Dec 2001 00:32:43 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com, Charlie_Kaufman@iris.com, canetti@watson.ibm.com Subject: Re: compare-jfk-sigma.txt References: <200112081439.JAA25938@ornavella.watson.ibm.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk canetti@watson.ibm.com (Ran Canetti) writes: > 1. The WG decides that it wants a protocol that protects the initiator's > identity against active attacks (and is willing to pay the associated costs, > ie, extra sig and sending the responder's ID in the clear). > In this case JFK seems like a good choice. You forget one big thing associated with that also. If we want to protect initiator's identity against active attacks, it means that we can NEVER reverse the initiator and responder. I.e the original responder CANNOT EVER initiate to the initiator. We don't have initiator and responder we have server (whose identity is public and who always acts as a responder) and client (whose identity is always protected and who always acts as an initiator). If we allow changing the roles the attacker can fake to be a original responder trying to do rekey and then grab the original initiator's identity. > 2. The WG decides that it wants a protocol that protects the responder's ID > against active attacks (or that it doesnt care about ID protection against > active attacks one way or the other). In this case the protocol below seems > like a good choice. (Just to reiterate - this protocol is basically the > 4-msg variant of SIGMA, as proposed by Hugo a few days ago, with the HMAC > being on the outside as done in IKEv2.) Actually it really does not matter which ends identity is protected against active attacks unless we disallow changing of the direction of the negotiation. I myself think it is best to protect against passive attacks (and in this case I want protection to both ends identities). For active attacks you always have time to run when you notice that someone got your identity by active attack :-) Or you use double authentication, i.e authenticate machine first and then the user. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 10 07:54:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAFst211826; Mon, 10 Dec 2001 07:54:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12711 Mon, 10 Dec 2001 10:01:02 -0500 (EST) Message-ID: <030501c1818d$06512e80$32c02ca1@cisco.com> From: "Stephane Beaulieu" To: "Steven M. Bellovin" , "Dan Harkins" Cc: References: <20011208015419.C18F17B55@berkshire.research.att.com> Subject: Re: Son-of-IKE Performance Date: Mon, 10 Dec 2001 10:12:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I think most people are quite comfortable with the security properties of all the candidate proposals. Once we nail down the exact requirements (i.e. ID protection, PSK or NOT PSK, etc...), then the candidates who don't conform to the requirements will likely tweak their submissions. That part, oddly enough :) seems trivial. The larger problem is identifying all the corner cases. Rekeying, NAT traversal, Legacy auth, SA negotiation, lifetime handling, specifying selectors, retransmit handling, black hole detection / recovery, resource handling, etc........ OK. I admit, at this point, I could care less how the key is stretched. I have faith in the author(s) to adequately define this. The manageability issue bothers me though.... I think we need to start paying FAR MORE attention to the details. Stephane. ----- Original Message ----- From: "Steven M. Bellovin" To: "Dan Harkins" Cc: "Hallam-Baker, Phillip" ; Sent: Friday, December 07, 2001 8:54 PM Subject: Re: Son-of-IKE Performance > In message <200112072110.fB7L9uG01024@fatty.lounge.org>, Dan Harkins writes: > > I am well aware it is possible to derive keys for many SAs out of > >a mutually authenticated shared secret. > > > > My point is that just saying "by obvious means" is not good enough. > >After seeing how emminently reasonable people interpreted "by obvious > >means" differently during implementation of RFC2409 I think it is > >necessary to explain the means exactly. > > > > My stretching wasn't the "obvious" one? Well there's another person > >on this list who thought it was. Moreover, there is nothing in JFK > >to say it was the incorrect way or that what means "obvious" to you > >is the correct way. Do you see the problem? > > Dan -- if we were about to issue "Last Call" on JFK, I'd not only agree > with you, I'd be leading the charge. We're not nearly at that stage > yet. The purpose of the JFK draft was to describe a cryptographic > protocol, not (yet) an implementation spec. Clearly, there are many > ways to derive the four needed keys from the one exchange; equally > clearly, a final spec *must* specify exactly one, in very precise form. > If and when the WG agrees on JFK, we'll happily fill in those details. > > But those details are not nearly as controversial as JFK vs. IKEv2 vs. > SIGMA vs. XKASS, and not even as controversial as the requirements on > which we'll base that choice. This is, I think, obvious to everyone. > Why are you beating on this point? Is there anyone here, with the > possible exception of you, who thinks that this is the crucial criterion > on which the WG is going to decide among the different proposals? > > To my mind, the next interesting issue is what the SA description > should look like. I've heard many complaints that the current standard > is a significant source of complexity and interoperability problems. > In fact, I'd planned on writing a draft on that issue, but a number of > things (including the events of September 11) interfered. > > (Inflammatory comments deleted.) > > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > From owner-ipsec@lists.tislabs.com Mon Dec 10 08:33:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAGX6216620; Mon, 10 Dec 2001 08:33:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12917 Mon, 10 Dec 2001 10:48:31 -0500 (EST) Date: Mon, 10 Dec 2001 10:57:35 -0500 (EST) From: Henry Spencer To: Paul Koning cc: ipsec@lists.tislabs.com Subject: RE: Please save the pre-shared key mode In-Reply-To: <15376.54947.458903.672254@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 Fri, 7 Dec 2001, Paul Koning wrote: > [IKE replacement vs new protocol] > If the latter, then the requirements set is open. But if the former, > then the new protocol MUST include among its requirements all the > features of the earlier protocol that are important. It is clear from > looking at customer installations that pre-shared key is a critical > feature of IKE. No, it is clear from looking at customer installations that *some* form of easy-to-set-up self-contained authentication which does not rely on elaborate infrastructure is a critical feature. That is the strongest conclusion which can be drawn from the evidence. Whether that form has to be "pre-shared key" (better called "shared secret") is *not* clear. Most IKE implementations offer no self-contained alternative, so it is not possible to tell whether the requirement is for "pre-shared key" or just for *some sort* of self-contained authentication. The FreeS/WAN experience with preshared public keys suggests that most any form of simple standardized self-contained authentication would suffice, e.g. preshared public keys or self-signed certificates. > ...If the goal is > to improve matters for implementers and customers, the goal should be > to create a new protocol which is indeed a viable replacement for the > previous protocol, fully entitled to the name "IKE V2" because it > incorporates the capabilities for which there is a proven need while > cleaning up in other areas. Quite so. But we must be careful to identify those capabilities in the form of *requirements*, rather than jumping to conclusions about how those requirements are to be met. A requirement for a simple self-contained authentication method does not imply a requirement for "pre-shared key". Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 10 08:57:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAGvt218957; Mon, 10 Dec 2001 08:57:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13028 Mon, 10 Dec 2001 11:15:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15380.57809.834152.184217@pkoning.dev.equallogic.com> Date: Mon, 10 Dec 2001 11:24:49 -0500 (EST) From: Paul Koning To: mat@cisco.com Cc: dharkins@tibernian.com, ipsec@lists.tislabs.com Subject: Re: Please save the pre-shared key mode References: <15376.62551.423979.312570@thomasm-u1.cisco.com> <200112071042.fB7AgkG00861@fatty.lounge.org> <15377.7666.566597.34133@thomasm-u1.cisco.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> Dan Harkins writes: >> The draft which calls itself IKEv2 _is_ a working group draft. Michael> In any case, my real point is that he shouldn't be reading Michael> anything into the name since that's a function of the Michael> requirements. I don't think I'm reading much into the name. What I'm reading is the substance of the discussion surrounding these various new protocol proposals. The substance, as far as I can tell, is that (a) these are proposals for a protocol that is intended to REPLACE IKE -- as opposed to being an additional protocol intended to exist alongside IKE; (b) some of the people involved in the discussion believe that it is a requirement for this successor protocol NOT to contain the pre-shared key feature of IKE. I don't believe this makes any sense. You can have long theological discussions about the myths of PSK, and so forth. That doesn't really do anything useful. The reality is that PSK is widely deployed in current VPNs. It may be the most widely deployed, or not; I'm not interested in that, but I do know that it is a significant fraction. And yes, it is possible to deploy it insecurely -- just as it is possible to deploy ANY security technology insecurely. In my opinion, a proposed protocol requirements statement for the "successor to IKE" protocol that omits or deprecates or disallows pre-shared key is broken and will end up not being acceptable in the real world. paul From owner-ipsec@lists.tislabs.com Mon Dec 10 09:09:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAH9e219612; Mon, 10 Dec 2001 09:09:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13111 Mon, 10 Dec 2001 11:26:13 -0500 (EST) Message-ID: <001b01c18198$ae9643e0$7480ad40@sfanninglaptop> From: "Scott Fanning" To: "Stephane Beaulieu" , "Steven M. Bellovin" , "Dan Harkins" Cc: References: <20011208015419.C18F17B55@berkshire.research.att.com> <030501c1818d$06512e80$32c02ca1@cisco.com> Subject: Re: Son-of-IKE Performance Date: Mon, 10 Dec 2001 08:35:30 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Stephane. I think we need to debate the requirements draft first. I think this group needs that done first so that the rat holes (pre-shared key we do crawl into focus on the appropriate solution. In fact, if there are any providers of VPN services out there on the list, the requirements discussion would be a great time for their input. With the requirements agreed upon, the debate on the solution should go must faster. My suggestion would be to debate the requirements draft first, get buy in from the WG, then the IKEv2 candidates can present their solution. In fact, I would have the requirements the only thing on the agenda. No point putting the cart before the horse. Scott ----- Original Message ----- From: "Stephane Beaulieu" To: "Steven M. Bellovin" ; "Dan Harkins" Cc: Sent: Monday, December 10, 2001 7:12 AM Subject: Re: Son-of-IKE Performance > Steve, > > I think most people are quite comfortable with the security properties of > all the candidate proposals. Once we nail down the exact requirements (i.e. > ID protection, PSK or NOT PSK, etc...), then the candidates who don't > conform to the requirements will likely tweak their submissions. > > That part, oddly enough :) seems trivial. > > The larger problem is identifying all the corner cases. Rekeying, NAT > traversal, Legacy auth, SA negotiation, lifetime handling, specifying > selectors, retransmit handling, black hole detection / recovery, resource > handling, etc........ > > OK. I admit, at this point, I could care less how the key is stretched. I > have faith in the author(s) to adequately define this. The manageability > issue bothers me though.... I think we need to start paying FAR MORE > attention to the details. > > > Stephane. > > > > ----- Original Message ----- > From: "Steven M. Bellovin" > To: "Dan Harkins" > Cc: "Hallam-Baker, Phillip" ; > Sent: Friday, December 07, 2001 8:54 PM > Subject: Re: Son-of-IKE Performance > > > > In message <200112072110.fB7L9uG01024@fatty.lounge.org>, Dan Harkins > writes: > > > I am well aware it is possible to derive keys for many SAs out of > > >a mutually authenticated shared secret. > > > > > > My point is that just saying "by obvious means" is not good enough. > > >After seeing how emminently reasonable people interpreted "by obvious > > >means" differently during implementation of RFC2409 I think it is > > >necessary to explain the means exactly. > > > > > > My stretching wasn't the "obvious" one? Well there's another person > > >on this list who thought it was. Moreover, there is nothing in JFK > > >to say it was the incorrect way or that what means "obvious" to you > > >is the correct way. Do you see the problem? > > > > Dan -- if we were about to issue "Last Call" on JFK, I'd not only agree > > with you, I'd be leading the charge. We're not nearly at that stage > > yet. The purpose of the JFK draft was to describe a cryptographic > > protocol, not (yet) an implementation spec. Clearly, there are many > > ways to derive the four needed keys from the one exchange; equally > > clearly, a final spec *must* specify exactly one, in very precise form. > > If and when the WG agrees on JFK, we'll happily fill in those details. > > > > But those details are not nearly as controversial as JFK vs. IKEv2 vs. > > SIGMA vs. XKASS, and not even as controversial as the requirements on > > which we'll base that choice. This is, I think, obvious to everyone. > > Why are you beating on this point? Is there anyone here, with the > > possible exception of you, who thinks that this is the crucial criterion > > on which the WG is going to decide among the different proposals? > > > > To my mind, the next interesting issue is what the SA description > > should look like. I've heard many complaints that the current standard > > is a significant source of complexity and interoperability problems. > > In fact, I'd planned on writing a draft on that issue, but a number of > > things (including the events of September 11) interfered. > > > > (Inflammatory comments deleted.) > > > > > > --Steve Bellovin, http://www.research.att.com/~smb > > Full text of "Firewalls" book now at http://www.wilyhacker.com > > > > > From owner-ipsec@lists.tislabs.com Mon Dec 10 10:22:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAIMq223460; Mon, 10 Dec 2001 10:22:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13275 Mon, 10 Dec 2001 12:23:57 -0500 (EST) Message-Id: <200112100418.fBA4Itr01852@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: comments on jfk and ikev2 drafts Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 09 Dec 2001 21:18:55 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I had 24 comments about IKEv2, and 8 about JFK. As JFK has not yet defined how selectors are defined, and I regard this as the *MAJOR* reason for the marketplace to ask for a replacement for IKEv1, I consider the JFK draft to be a very rough -00 draft. The amount of text in it is very small, and would need to double or triple before it could be compared in any to the IKEv2 draft. As far as I can tell, neither proposal yet explains to me how to *add* new traffic to an existing IPsec SA without rekeying it. {If anyone is wondering if sendmail 8.11 pays attention to certificate expiry, I just discovered after ten minutes pondering why I can no longer relay email via my office mail server. It has been 365 days since I set the thing up. But, it did permit me to connect, just not to relay.} ikev2-00.txt 1. is the IKE_SA_init_reject forgeable? page 10 makes me nervous. actually, all of 2.6 makes me nervous. 2. section 2.4 provides an IKE ping, which is great! "null query" 3. Delete payloads are a MUST, which is also good. 4. IKE-SA must remain alive for duration of Child-SA. This is good. (gateways may not drop them) 5. section 2.4.. what about active Distributed Denial of Service attacks? Other than rate limits, I think that there is nothing we can do. 6. " In IKEv2, like IKEv1, both 8-byte cookies appear in the message, but in IKEv2 (unlike v1), the value chosen by the message recipient always appears first in the message. This change eliminates a flaw in IKEv1, as well as having other advantages (allowing the recipient to look up the SA based on a small, conveniently chosen value rather than a 16-byte pseudorandom value.)" I'm confused by this text. 7. recommend that the list of attacks be made explicit somewhere, perhaps with reference. Perhaps an appendix. (this will also make a good test suite) 8. end of section 2.7 (re. DH groups) suggests to me that each end would benefit from maintaining a per-IP/per-ID database of information learned from the other end. 9. section 2.8, " timing of rekeying requests should be dithered (delayed by a random amount of time)." Isn't the term here "jitter" appropriate? 10. 2.9: "IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of both addresses and ports, and allows the Responder to choose a subset of the requested traffic rather than simply responding "not acceptable". This would presumeably permit the initiator to propose: leftsubnet=mysubnet rightsubnet=0.0.0.0/0 and the responder could then fill in the subnet that it actually speaks for. This would permit OE to work more easily for subnets. The delegation records would also have to exist, but they would not need to be discovered. 11. comment retracted. 12. a) how big are typical messages for the exchanges? I am concerned about PMTU issues with IKE packets. What about an option to use SCTP? b) will we get some sample exchanges in hex with known keys? 13. 4.1: "A single child-SA negotiation results in two security associations-- one inbound and one outbound. Different Nonces and SPIs for each SA (one chosen by the Initiator, the other by the Responder) guarantee a different key for each direction. The SPI chosen by the destination of the SA and the Nonces (ordered source followed by destination) are used to derive KEYMAT for that SA." This suggests tome that the Nx are different, when they are in fact the same. It is just the SPId that are different, I think. Should we add something else to guarantee that choice of the same SPI# does not cause identical keying? I am concerned that SPI# choice is often from a low-entropy (PRNG) source. 14. section 5: "The other case in which there is no IKE-SA to protect the information is when a packet is received with an unknown SPI. In that case the notification of this condition will be sent in an informational exchange that is cryptographically unprotected." I would prefer to have birth certificates introduced here. I am unclear if an unprotected IKE-SA requires a response, particularly, an "unknown SPI" message. 15. section 7. I believe that for ESP/UDP/NAT purposes we must insist that we reverse the port numbers as well as the IP addresses. 16. section 7: "The Recipient SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers." Do you mean "single peer" here? Are IKE-SAs identified by: {sourceSPI, destSPI} or {sourceIP, sourceSPI, destIP, destSPI} or {sourceIP, sourcePort, sourceSPI, destIP, destPort, destSPI} 17. section 7.1: "R(eserved) (bits 5-7 of Flags) - These bit MUST be cleared in messages sent and received messages with these bits set MUST be rejected." Note that this in contradiction of the general rule given in section 2.5, last paragraph on page 9. It should be noted. 18. section 7.1: IV field is new to IKEv2. I would rather that it was documented identically as for IKEv1, and then the IV, etc. fields were placed in a seperate section afterward. 19. section 7.2: contrast to IKEv1. I think it is just the addition of the "Critical" bit in the former reserved field. 20. section 7.3: "A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm and the attribute would specify the key size. Most transforms do not have attributes." I would like to discourage use of attributes for key length. CAST-128 is very different from CAST-256, and a proposal for, say, CAST-255 would make no sense to most implementations. I think some implementations may be tempted to provide a slider here, which I think would make even less sense. The number of permutations of useable key length is just not that big in my opinion. 21. section 7.3.1 "Protocol-Id (1 byte) - Specifies the protocol identifier for the current negotiation. During phase 1 negotiation this field MUST be zero (0). During phase 2 it will be the protocol of the SA being established as assigned by IANA, for example, 50 for ESP, 51 for AH, and 108 for IPComp." Does this present a problem if we wish to negotiate keying materials for a protocol not at the network layer? e.g. anything running over TCP or UDP (BGP, HTTP, DNS, etc..) 22. please mark all ID fields which are identical to ones in IKEv1. (the CERT payload, for instance, appears to be the same) 23. section 7.8 isn't quite clear to me. I think that one sends an AUTH payload during the second exchange, signing both the first and second payloads (not including "HDR"?) that were sent. I assume that AUTH MUST be last? Is it encrypted? 24. IKEv2 notify payload is not compatible with IKEv1 payload. If one added the redundant "DOI" field, then I think that an IKEv1 implementation would be able to at least log a notify from an IKEv2. I don't know if this is worth it. 25. I think that VendorID should always have C=0. Further, given presence of C bit, a vendorID payload can now be used to identify whose private-use space is in use as C bit can tell receiver of message whether or not the information is important or not. Suggested text: The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. The Vendor ID payload is both an announcement from the sender of which space private payload types will come from, and also an announcement of the sort of private payloads it is willing to accept. The implementation sending the Vendor ID MAY make assumptions about private payloads that it may send, provided that all are not marked critical. Upon reception of a Vendor ID of like stature, a sender may then send critically marked payloads as as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all. A Vendor ID payload may be sent as part of any message. Reception of a familiar Vendor ID payload allows an implementation to make use of Private USE numbers described throughout this memo-- private payloads, private exchanges, private notifications, etc. Unfamiliar Vendor ID's MUST be ignored. Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts which gain acceptance and are standardized will be given "magic numbers" out of the Future Use range by IANA and the requirement to use a Vendor ID will go away. 26. section 7.13.1. Please include ICMP as a type that may be negotiated. Also SCTP. For ICMP, "port" data corresponds to concatenation of ICMP type and ICMP code values. But, why are we including network and transport layer selectors in one TSI? Why not have proper nesting of protocols? **** JFK ******* 1. "and the complexity of its specification. (This complexity has led to interoperability problems, so much so that, several years after its initial adoption by the IETF, there are still completely non-interoperating implementations.)" I'm not sure that I buy this statement. Proof sought. I agree that there are poor programmers. Are these really *COMPLIANT* implementations? TCP/IP is widely implemented, yet if you turn on PMTU, there are multiple networks with web servers which can not be accessed because they won't let the ICMPs through. All the implementations are "compliant", but the operators are idiots. Does this mean that TCP/IP is "complicated" and we should start over? 2. section 2.2 why is g^i and g^r repeated in message 3? Is this so that r need not store g^i? explained in the text, I see. Perhaps some more explanation should preceed the details. I think that in message 3, where you write: HMAC{HKr}(Ni, Nr, g^i, g^r) I take this to mean, repeat what you got from message 2, not that one should compute this. The text makes this clear, but the notation does not. 3. appears that a single exchange can only be used to generate keys for a single IPsec SA. This is, I guess, an implicit goal, but I think that you should tell me this. 4. seciton 2.2: write up is too dense. please use more whitespace and paragraph breaks. 5. section 2.5 has some LaTeX macros unexpanded. \mbox{ID}* 6. what is a "ukases" in section 2.5 paragraph 3? 7. section 2.5: I disagree that the responder is providing the service. This is far too client/server oriented. There are many cases where a packet may arrive at a gateway while leaving a "server" location by another route (multihoming of gateways) which would cause new keying to occur with the "client". 8. section 2.5, last paragraph. I reject the rejection of rekeying. Or, I just don't understand. I'd think that writing: s/3DES/AES/ s/high speed/very very high speed/ and we have to replace AES with something else. Of course, rekeying is still supported, but just not conveniently. If this is the point, then fine. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBQ3rIqHRg3pndX9AQGhagQAiWQe6C6nqaxf2dN4YfgzpSDF1WNelQz7 5ozyqBROy7jj5vfV+jBLdhD55DS5kSocAa1Z98me7rVHeCd3ytL9pTlk1jrC3fUs mwWhPkLfoZIlrTc7BJUpxcWMjEFaPToC7yha7CrDFUmd6Gtuoqp5qu62Y4tuOlfl mcPhW8g+3U4= =PvJE -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 10 10:26:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAIQq223562; Mon, 10 Dec 2001 10:26:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13326 Mon, 10 Dec 2001 12:46:14 -0500 (EST) Message-Id: <200112101745.fBAHjQW01013@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Some comments to draft-ietf-ipsec-ikev2-00.txt In-reply-to: Your message of "Sat, 08 Dec 2001 20:04:41 +0200." <15378.22073.715364.46210@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Dec 2001 10:45:26 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Just a side note, that in road warrior cases the normal TSi and TSr Tero> are going to be the traffic selectors for the DHCP over ipsec SA which Tero> ise used to the get the internal ip address for the host. Do you think that we need some special TSx to indicate this kind of situation? Tero> Proposal and transform substructures are missing the criticality flags Tero> included in all other generic payload headers. I think it would be Tero> better to have only one generic payload header format... I would agree. Even if we agree that proposals are never "critical" (not understanding a proposal means you do not select it), we should reserve the bit there. >> For Transform Type 3 (Authentication Method), defined Transform-IDs >> are: >> >> Name Number Defined In >> RESERVED 0 >> Methods in IKEv1 1 - 5 (RFC2409) >> Authenticated Diffie-Hellman 6 (this memo) Tero> Why do we need methods for IKEv1 here? This is in completely separate Tero> place compared to the IKEv1, so compability cannot be the issue, Tero> especially when none of the numbers defined by the IKEv1 are not used Tero> here (and I don't assume any of the numbers are going to be used). Just to keep the number of number spaces to a minimum? Tero> I think it would be better to change the format of subnet selectors to Tero> be IPVx_ADDRESS + Number of bits in the mask. It would remove the Tero> problems what to do when the other end proposes mask 0xff00ff00? Tero> (According to above it is completely valid :-) I think this is reasonable. It would be nice if we could have IPVx_ADDRESS+prefixlen be the ONLY format supported. But, it has to be the RANGE version, since that is the most general. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBT0tIqHRg3pndX9AQG6fAQAu5jYRm9zaeGSNyo3665i5dH8emeHqP5b eqckHoWzkq6DEBuJ5BrHMdJy9+JG8cvbdY9BUi78tgQr7pY21Pnd1KXmvv2QKIuR iG4KRfLQa1l41b5wwtkFwsc4g/ndewvOgMfH6Nkz0mgoyuwcFjHL+dmp7ZB7JvpY htvZRu/4yAo= =eg0z -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Dec 10 10:32:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAIWi223862; Mon, 10 Dec 2001 10:32:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13340 Mon, 10 Dec 2001 12:56:02 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: ipsec From: "Steven M. Bellovin" To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: comments on jfk and ikev2 drafts Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 10 Dec 2001 11:05:39 -0700 Message-Id: <20011210180539.80A107B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200112100418.fBA4Itr01852@marajade.sandelman.ottawa.on.ca>, Michael Richardson writes: >6. what is a "ukases" in section 2.5 paragraph 3? > >From www.m-w.com: Main Entry: ukase Pronunciation: yü-'kAs, -'kAz, 'yü-"; ü-'käz Function: noun Etymology: French & Russian; French, from Russian ukaz, from ukazat' to show, order; akin to Old Church Slavonic u- away, Latin au-, Sanskrit ava- and to Old Church Slavonic kazati to show Date: 1729 1 : a proclamation by a Russian emperor or government having the force of law 2 : EDICT We had definition 2 in mind.... From owner-ipsec@lists.tislabs.com Mon Dec 10 11:04:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAJ4u224720; Mon, 10 Dec 2001 11:04:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13388 Mon, 10 Dec 2001 13:22:49 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: UDP encapsulation of IKE for NAT traversal Organization: SSH Communications Security From: Markus Stenberg Date: 10 Dec 2001 19:44:57 +0200 Message-ID: <87wuzv2cme.fsf@porsas.hel.fi.ssh.com> Lines: 86 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA13297 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > As a result of the subsequent IKE exchange encryptor C has a SA between C > and S, and encryptor S has a SA between A and S (and not C and S). This > assumes of course that IP address A was present in the policy database of > encryptor S. > > Herein lies our confusion. Once the IPSec SA is setup between C and S, a > HTTP/TCP/IP packet from the web server destined for the client (i.e. > S,C:80,Pc) will result in encryptor S not being able to find a SA, since the > SA that was established was between A and S. > > One solution that we are considering is that the IKE/UDP/IP packet itself be > encapsulated in UDP so that the original IP addresses and ports are left > intact. Looking at draft-ietf-ipsec-nat-t-ike-01.txt it is not clear (at > least to us) whether this is the intention or not. Section 4.2 of the draft > states: It is not. > "In case of transport mode both ends SHOULD send the original source > address to the other end. For the tunnel mode both ends SHOULD NOT send > original source address to the other end." This means that the source addresses are sent in the NAT-OA payload, not that the IKE traffic would be encapsulated. Quote (from the same section): ,---- | The original source address of packets put to this transport mode IPsec | SA is sent to other end using NAT-OA (NAT Original Address) payload. `---- > We notice in draft-ietf-ipsec-udp-encaps-01.txt in section 5 headed "Usage > with Another Key Management Protocol" that the "...key management packet..." > is UDP encapsulated. Does this apply to the standard IKE as well? And does > the *key management packet* include the original IP/UDP headers? IKE isn't encapsulated. The current UDP encapsulation is defined so that it will seem like an invalid IKE packet. > Other solutions (and some of these are proprietary) are (i) that we use a > vendor specific payload in the IKE packet from C to S to inform S of the IP > address (as well as the Ethernet address) of C, (ii) that the policy > database that resides in S have an entry that relates IP addresses C and S > together with the NAT address A (a problem here is if the client C is using > DHCP to acquire its IP address - in this case, the policy cannot know the > private IP address behind the NAT), and (iii) that encryptor S brute force > the received NAT-D hash to try to determine which IP address and port in the > policy table initiated the IKE (again, useless for a DHCP host, and > problematic due to the possibility of hash collisions). The IPsec host behind NAT doesn't need to know much (only that it wants to negotiate using the UDP-tunnel mode instead of normal tunnel if the detection sequence fails). The responding host who gets traffic from clients behind NATs has to do either of the following: - in network with unique addresses, one can just use the QM IDs as addresses to use (Note: This can be also done with say, DHCP-over-IPsec to GET unique address and then use it in tunnel mode to communicate with the responder) - in network where clients addresses behind NAT may overlap, there's need for NAT action in the responder. The point being, when the initiator negotiates IPsec SA, the 'remote identity' handled by responder is done so that when the packet comes in it is translated to addressable form (if need be), and when packets are sent out they're translated to addressable form (if need be) and then sent forward. How this is done is an implementation issue, and I think it was addressed bit more in my earlier drafts on topic (but, I'm not sure if they should be in the draft anyway). > Any ideas? > > Graham Welling > Cryptek Secure Communications > gwelling@cryptek.com -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) Chief Engineer / SSH $B0O8k@h@8(B From owner-ipsec@lists.tislabs.com Mon Dec 10 13:43:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBALh5202547; Mon, 10 Dec 2001 13:43:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13659 Mon, 10 Dec 2001 15:44:14 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Michael Richardson'" , Subject: Michael's comments on ikev2 draft Date: Mon, 10 Dec 2001 15:35:50 -0500 Message-ID: <000d01c181bc$4fd505c0$01c7830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200112100418.fBA4Itr01852@marajade.sandelman.ottawa.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It would be helpful if named messages/payloads in the draft were always called the same thing. IKE_SA_init_response is sometimes called IKE-SA-RESPONSE. It makes it hard to search through the draft for multiple uses of the same keyword. > 1. is the IKE_SA_init_reject forgeable? > page 10 makes me nervous. > actually, all of 2.6 makes me nervous. Presumably, the IKE_SA_init_reject would contain the initiator cookie, so it's weakly DoS resistant, which is appropriate. > 3. Delete payloads are a MUST, which is also good. Agreed. Implementations which don't send deletes continue to be a source of interoperability problems. > 5. section 2.4.. what about active Distributed Denial of > Service attacks? > Other than rate limits, I think that there is nothing we can do. Not quite true. My earlier heartbeat method of dead peer detection is resistant to this type of attack, but requires extra IKE bandwidth. Most people didn't seem willing to trade the bandwidth for the DDoS resistance. > 13. 4.1: "A single child-SA negotiation results in two > security associations-- > one inbound and one outbound. Different Nonces > and SPIs for each SA > (one chosen by the Initiator, the other by the > Responder) guarantee a > different key for each direction. The SPI chosen > by the destination > of the SA and the Nonces (ordered source followed > by destination) are > used to derive KEYMAT for that SA." > > This suggests tome that the Nx are different, when they > are in fact the same. But won't the order of the nonces in the PRF be different since the sender & receiver are reversed for inbound and outbound SAs? This will cause the keys to be different even if the SPIs are the same. > 25. I think that VendorID should always have C=0. > Further, given presence of C bit, a vendorID payload > can now be used > to identify whose private-use space is in use as C bit can tell > receiver of message whether or not the information is > important or > not. > > Suggested text: > > The Vendor ID Payload contains a vendor defined constant. The > constant is used by vendors to identify and recognize remote > instances of their implementations. This mechanism allows a vendor > to experiment with new features while maintaining backwards > compatibility. > > The Vendor ID payload is both an announcement from the > sender of which > space private payload types will come from, and also an > announcement of > the sort of private payloads it is willing to accept. The > implementation > sending the Vendor ID MAY make assumptions about private > payloads that it > may send, provided that all are not marked critical. Upon > reception of a > Vendor ID of like stature, a sender may then send critically marked > payloads as as well. Multiple Vendor ID payloads MAY be sent. An > implementation is NOT REQUIRED to send any Vendor ID > payload at all. > > A Vendor ID payload may be sent as part of any message. > Reception of > a familiar Vendor ID payload allows an implementation to > make use of > Private USE numbers described throughout this memo-- private > payloads, private exchanges, private notifications, etc. Unfamiliar > Vendor ID's MUST be ignored. > > Writers of Internet-Drafts who wish to extend this protocol MUST > define a Vendor ID payload to announce the ability to implement the > extension in the Internet-Draft. It is expected that > Internet-Drafts > which gain acceptance and are standardized will be given "magic > numbers" out of the Future Use range by IANA and the requirement to > use a Vendor ID will go away. This is good text. I suggest that it be added to the draft. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Mon Dec 10 14:20:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBAMK9206492; Mon, 10 Dec 2001 14:20:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13694 Mon, 10 Dec 2001 16:29:46 -0500 (EST) To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: Re: Some comments to draft-ietf-ipsec-ikev2-00.txt In-Reply-To: Your message of "Sat, 08 Dec 2001 20:04:41 +0200." <15378.22073.715364.46210@ryijy.hel.fi.ssh.com> From: Dan Harkins MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25357.1008020372.1@SailPix.com> Date: Mon, 10 Dec 2001 13:39:32 -0800 Message-Id: <20011210213932.B366354C42@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 08 Dec 2001 20:04:41 +0200 you wrote > > I think it would be better to change the format of subnet selectors to > be IPVx_ADDRESS + Number of bits in the mask. It would remove the > problems what to do when the other end proposes mask 0xff00ff00? > (According to above it is completely valid :-) A mask of 0xff00ff00 _is_ completely valid. Dan. From owner-ipsec@lists.tislabs.com Mon Dec 10 19:55:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBB3tA228247; Mon, 10 Dec 2001 19:55:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14084 Mon, 10 Dec 2001 21:55:08 -0500 (EST) Message-Id: <200112110254.fBB2sFf00841@marajade.sandelman.ottawa.on.ca> To: Dan Harkins cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Some comments to draft-ietf-ipsec-ikev2-00.txt In-reply-to: Your message of "Mon, 10 Dec 2001 13:39:32 PST." <20011210213932.B366354C42@tailor.sailpix.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Dec 2001 19:54:15 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> On Sat, 08 Dec 2001 20:04:41 +0200 you wrote >> >> I think it would be better to change the format of subnet selectors to >> be IPVx_ADDRESS + Number of bits in the mask. It would remove the >> problems what to do when the other end proposes mask 0xff00ff00? >> (According to above it is completely valid :-) Dan> A mask of 0xff00ff00 _is_ completely valid. CIDR routing people would strongly disagree. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Dec 10 20:58:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBB4wj229943; Mon, 10 Dec 2001 20:58:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14169 Mon, 10 Dec 2001 23:16:57 -0500 (EST) Message-Id: <200112110318.fBB3ITk01102@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-reply-to: Your message of "Sat, 08 Dec 2001 02:27:34 +0200." <200112080027.CAA22278@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Dec 2001 20:18:29 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Markku" == Markku Savela writes: >> That sounds great for outbound/initiator. >> >> How does one communicate selectors to the kernel of the responder? Markku> Policy is what gets handed down to you by a person (or a system) Markku> responsible for the security of the site or service you want to use Markku> and which is protected by IPSEC. You've described an intra-organizational VPN. We are talking about IPsec. VPN is only one application of IPsec. Please remember 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 NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Dec 10 23:52:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBB7qu212329; Mon, 10 Dec 2001 23:52:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14645 Tue, 11 Dec 2001 01:49:44 -0500 (EST) Message-Id: <200112110700.KAA23816@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Michael Richardson , "Steven M. Bellovin" Date: Tue, 11 Dec 2001 09:58:55 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 8BIT Comments: Sender has elected to use 8-bit data in this message. If problems arise, refer to postmaster at sender's site. Subject: Re: comments on jfk and ikev2 drafts CC: ipsec@lists.tislabs.com In-reply-to: <20011210180539.80A107B55@berkshire.research.att.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 10 Dec 01, at 11:05, Steven M. Bellovin wrote: > In message <200112100418.fBA4Itr01852@marajade.sandelman.ottawa.on.ca>, Michael > Richardson writes: > > >6. what is a "ukases" in section 2.5 paragraph 3? > > > > From www.m-w.com: > > Main Entry: ukase > Pronunciation: yØ-'kAs, -'kAz, 'yØ-"; Ø-'kÄz > Function: noun > Etymology: French & Russian; French, from Russian ukaz, from ukazat' to > show, order; akin to Old Church Slavonic u- away, Latin au-, Sanskrit ava- > and to Old Church Slavonic kazati to show > Date: 1729 > 1 : a proclamation by a Russian emperor or government having the force of > law > 2 : EDICT > > We had definition 2 in mind.... Funny enough, but even being a native russian-speaking, I didn't understand this word either untill your explaination :-) In Russian it is rather unusual word for the context it has been used in. Probably it's better to change it to eliminate confusion. Best regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Tue Dec 11 00:56:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBB8uW220111; Tue, 11 Dec 2001 00:56:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA14731 Tue, 11 Dec 2001 02:59:45 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Tero Kivinen'" , , Subject: RE: Some comments to draft-ietf-ipsec-ikev2-00.txt Date: Tue, 11 Dec 2001 03:05:02 -0500 Message-ID: <000d01c1821a$aeada260$14c6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <15378.22073.715364.46210@ryijy.hel.fi.ssh.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 3.1 Generating Keying Material for the IKE-SA > ... > > SKEYSEED = prf(Ni | Nr, g^ir) > > As this is the only place where nonces are used their entropy is > limited to the output of the PRF. I.e it is no use of using nonces > whose combined entropy is more than 128 bits if we using the HMAC-MD5 > as PRF, as the output of the SKEYSEED is going to be 128 bits. > > > SKEYSEED_d = prf(SKEYSEED, g^ir | CKY-I | CKY-R | 0) > > SKEYSEED_a = prf(SKEYSEED, SKEYSEED_d | g^ir | > CKY-I | CKY-R | 1) > > SKEYSEED_e = prf(SKEYSEED, SKEYSEED_a | g^ir | > CKY-I | CKY-R | 2) > > I think that could be fixed by adding the nonces to the above > calculations also in addition of the cookies. Or by simply replacing the cookies with the nonces. That would be the *obvious* method ;-) Still, I notice that IKEv2 carries forward the "broken" phase 1 key stretching algorithm from IKEv1: K1 = prf(SKEYSEED_e, 0) K2 = prf(SKEYSEED_e, K1) K3 = prf(SKEYSEED_e, K2) As was noted from earlier discussions, g^xy ought to be reintroduced at each stage in order to preserve the full entropy of the key exchange. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Dec 11 02:14:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBAEB227429; Tue, 11 Dec 2001 02:14:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14935 Tue, 11 Dec 2001 04:29:23 -0500 (EST) Message-ID: <3C15D439.D1DA2BB@F-Secure.com> Date: Tue, 11 Dec 2001 11:39:05 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: comments on jfk and ikev2 drafts References: <200112100418.fBA4Itr01852@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2001 09:39:03.0807 (UTC) FILETIME=[ABA3F8F0:01C18227] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > Suggested text: > > The Vendor ID Payload contains a vendor defined constant. The > constant is used by vendors to identify and recognize remote > instances of their implementations. This mechanism allows a vendor > to experiment with new features while maintaining backwards > compatibility. > > The Vendor ID payload is both an announcement from the sender of which > space private payload types will come from, and also an announcement of > the sort of private payloads it is willing to accept. The implementation > sending the Vendor ID MAY make assumptions about private payloads that it > may send, provided that all are not marked critical. Upon reception of a =========== -> none are > Vendor ID of like stature, a sender may then send critically marked > payloads as as well. Multiple Vendor ID payloads MAY be sent. An > implementation is NOT REQUIRED to send any Vendor ID payload at all. I like this part. > > A Vendor ID payload may be sent as part of any message. Reception of > a familiar Vendor ID payload allows an implementation to make use of > Private USE numbers described throughout this memo-- private > payloads, private exchanges, private notifications, etc. Unfamiliar > Vendor ID's MUST be ignored. This would seem to prevent anyone from proposing a proprietary crypto algorithm in message 1. Is it intentional? Of course, not all usages of this existing mechanism are that nice (e.g. x-auth authentication type hack), but there are likely to be valid uses as well. The problem in IKEv1 is that it doesn't specify exactly what to do if a private use number exist in a proposal. Like with the x-auth authentication type, most vendors skip it and try to match the next one, some abort the negotiation. > > Writers of Internet-Drafts who wish to extend this protocol MUST > define a Vendor ID payload to announce the ability to implement the > extension in the Internet-Draft. It is expected that Internet-Drafts > which gain acceptance and are standardized will be given "magic > numbers" out of the Future Use range by IANA and the requirement to > use a Vendor ID will go away. There's no point in demanding something that can't be enforced, like this demand for making an ID about every VID. There should also be some text describing how the transition period when some products use the VID method and others use IANA assigned numbers should be handled. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Dec 11 02:16:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBAGN227484; Tue, 11 Dec 2001 02:16:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14891 Tue, 11 Dec 2001 04:04:04 -0500 (EST) Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_RE=3A_Please_save_the_pre-shared_key_mode?= To: Henry Spencer Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Romain BERRENDONNER" Date: Tue, 11 Dec 2001 10:13:29 +0100 X-MIMETrack: Serialize by Router on ESTUAIRE/SAGEM(Release 5.0.8 |June 18, 2001) at 11/12/2001 10:13:32 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The FreeS/WAN experience with preshared public keys suggests that most any > form of simple standardized self-contained authentication would suffice, > e.g. preshared public keys or self-signed certificates. SSH offers a very similar paradigm, and even provides PK bound to machines. SSH _is_ widely deployed. The IETF has got a WG working on the Secure Shell, which is likely be very similar to OpenSSH. I believe there's some convergence to come out. -Romain disclaimer: Opinions hereby expressed are not those of my employer From owner-ipsec@lists.tislabs.com Tue Dec 11 02:38:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBAcr229664; Tue, 11 Dec 2001 02:38:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14980 Tue, 11 Dec 2001 04:48:49 -0500 (EST) Message-ID: <3C15D8C7.3739870C@F-Secure.com> Date: Tue, 11 Dec 2001 11:58:31 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: ipsec@lists.tislabs.com, Charlie_Kaufman@iris.com, canetti@watson.ibm.com Subject: Re: compare-jfk-sigma.txt References: <200112081439.JAA25938@ornavella.watson.ibm.com> <15378.38155.49527.8799@ryijy.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2001 09:58:29.0409 (UTC) FILETIME=[6264B910:01C1822A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > > canetti@watson.ibm.com (Ran Canetti) writes: > > 1. The WG decides that it wants a protocol that protects the initiator's > > identity against active attacks (and is willing to pay the associated costs, > > ie, extra sig and sending the responder's ID in the clear). > > In this case JFK seems like a good choice. > > You forget one big thing associated with that also. If we want to > protect initiator's identity against active attacks, it means that we > can NEVER reverse the initiator and responder. I.e the original > responder CANNOT EVER initiate to the initiator. That is true. However, this can be fully enforced by the CLIENT implementation, and only if it wishes to do so. It is sufficient for SOI to acknowledge that some initiators MAY choose to not to respond, ever. I haven't thought this through, like would the initiator need to signal this somehow, and how. > > We don't have initiator and responder we have server (whose identity > is public and who always acts as a responder) and client (whose > identity is always protected and who always acts as an initiator). > > If we allow changing the roles the attacker can fake to be a original > responder trying to do rekey and then grab the original initiator's > identity. I think we should acknowledge that there are different scenarios, both peer2peer and client2server. The reality is like that, and if the protocol models the reality, it's more likely to succeed. I do think that protecting a CLIENT's identity against active attacks is a worthy goal. Not all initiators' identities, only those that wish to do so. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Dec 11 07:37:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBFb3223343; Tue, 11 Dec 2001 07:37:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15515 Tue, 11 Dec 2001 09:40:21 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <000701c17ddf$214d2f10$1e72788a@andrewk3.ca.newbridge.com> References: <000701c17ddf$214d2f10$1e72788a@andrewk3.ca.newbridge.com> Date: Tue, 11 Dec 2001 09:48:54 -0500 To: From: Stephen Kent Subject: RE: IKEv2 and SIGMA Cc: "'Hugo Krawczyk'" , "'IPsec WG'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:49 PM -0500 12/5/01, Andrew Krywaniuk wrote: >Hugo, you have talked about the importance of carefully choosing the inputs >to the authentication hash. I envision a situation where: > >Responder chooses Nr = SIG_r(Ni, g^xi, IDr, ...) >Initiator creates AUTHi = SIG_i(Ni, g^xy, Nr, ...) > >So now the initiator has been tricked into signing something which binds a >derivative of the responder's identity to the nonce and DH values from the >exchange. And the result is that the initiator can no longer repudiate the >exchange. > >Is this the kind of attack you are talking about? > >Andrew >------------------------------------------- >There are no rules, only regulations. Luckily, >history has shown that with time, hard work, >and lots of love, anyone can be a technocrat. Excuse me for this belated comment, as I am still working my way through the 1K+ messages that arrived last week while I was away on vacation. I think the term "repudiate" may be inappropriate in this context. IPsec does not offer NR as a security service for the traffic sent on an SA, so the opportunity to offer NR with regard to an IKE exchange may not be all that important. Is there general agreement that NR is a concern here? Steve From owner-ipsec@lists.tislabs.com Tue Dec 11 09:03:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBH3n202216; Tue, 11 Dec 2001 09:03:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15798 Tue, 11 Dec 2001 11:10:00 -0500 (EST) Date: Tue, 11 Dec 2001 11:19:06 -0500 (EST) Message-Id: <200112111619.LAA07109@wolfe.bbn.com> From: Charles Lynn To: Michael Richardson Cc: Dan Harkins , Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Re: Some comments to draft-ietf-ipsec-ikev2-00.txt In-Reply-To: <200112110254.fBB2sFf00841@marajade.sandelman.ottawa.on.ca> References: <20011210213932.B366354C42@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> I think it would be better to change the format of subnet selectors >> to be IPVx_ADDRESS + Number of bits in the mask. It would remove the >> problems what to do when the other end proposes mask 0xff00ff00? >> (According to above it is completely valid :-) Dan> A mask of 0xff00ff00 _is_ completely valid. Michael> CIDR routing people would strongly disagree. The format that the routing folk use to identify networks to be advertised has little to do with what IPsec uses to identify systems that may use a particular SA (other than both being aggregations of IP addresses). The two have different requirements. One could make the argument that it would simplify the jobs of the security admins and the O&M folk if IPsec were to use ranges -- as that frees the admins not to have to be as concerned with how they divide up their address space, what to do if a power of two block needs to include one more address, etc. (it also uses same number of bits as address+mask, but does have different aggregation characteristics). (another) Charlie From owner-ipsec@lists.tislabs.com Tue Dec 11 09:17:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBHHq203030; Tue, 11 Dec 2001 09:17:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15840 Tue, 11 Dec 2001 11:27:05 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Tue, 11 Dec 2001 00:08:26 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: ipsec@lists.tislabs.com Subject: IKEv2 and NAT traversal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does the current IKEv2 draft have a problem working with the current NAT traversal draft (or vice versa, depending on your viewpoint)? The UDP encapsulation draft assumes that IKE packets never begin with eight zero bytes, whereas in IKEv2 the first eight bytes are the recipient SPI (cookie) (which is potentially zero). Since IKEv2 also runs on port 500, this seems like a problem. Should IKEv2 change, or should the NAT traversal draft change? Is there harm in swapping the order of cookies in IKEv2 (I would think not)? That would fix this problem, since the cookie of the sender is never zero. -Sami From owner-ipsec@lists.tislabs.com Tue Dec 11 09:18:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBHI9203047; Tue, 11 Dec 2001 09:18:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15841 Tue, 11 Dec 2001 11:27:06 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Mon, 10 Dec 2001 23:51:32 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Interoperability issues in setting up SAs 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, >[...] > After the WG has decided what it wants to do about SA specification, > the WG should help increate interoperability by specifying that > TheNextKeyExchangeAlgorithm *only* allow one type (probably range, > the most flexible). No need to get into that now, other than to > possibly disagree with the statement above about how wonderful > interop is today on this. I agree on the interop issue from first hand experience... ;) There are also IKEv1 implementations that will choke if they get a pair of single IP address selectors in QM, when they are negotiating transport mode. Such payloads would, of course, be redundant, but may result from some generic policy lookup algorithm. An alternative to what you suggested is to have the specification say unambiguously which type must be used, and allowing just a single encoding for a given case. I.e., a single address MUST be encoded as a single address, a subnet or a range that can be represented as subnet MUST be encoded as a subnet, and others as ranges. The same should apply to e.g. IKEv2 attributes. The specification should (in my opinion) mandate a unique encoding for attributes (minimum length). I don't think has been a really big issue, though. (I think there was an implementation that didn't accept 3-byte attribute encodings, though.) In any case, specifying just one generic type (as you proposed) above seems like the best choice wrt selectors, since it's much simpler. -Sami From owner-ipsec@lists.tislabs.com Tue Dec 11 10:10:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBIAt205196; Tue, 11 Dec 2001 10:10:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15954 Tue, 11 Dec 2001 12:18:23 -0500 (EST) Date: Tue, 11 Dec 2001 12:27:25 -0500 (EST) From: Henry Spencer To: Valery Smyslov cc: Michael Richardson , "Steven M. Bellovin" , ipsec@lists.tislabs.com Subject: Re: comments on jfk and ikev2 drafts In-Reply-To: <200112110700.KAA23816@relay1.trustworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 11 Dec 2001, Valery Smyslov wrote: > > >6. what is a "ukases" in section 2.5 paragraph 3? > > We had definition 2 in mind.... > > Funny enough, but even being a native russian-speaking, I didn't > understand this word either untill your explaination :-) I understood it right off, and I only speak about two words of Russian. :-) It is a legitimate English word. However, it is a relatively obscure one, and as such is probably best avoided in technical specs. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Dec 11 11:34:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBJYo209499; Tue, 11 Dec 2001 11:34:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16137 Tue, 11 Dec 2001 13:35:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.21477.133881.499918@pkoning.dev.equallogic.com> Date: Tue, 11 Dec 2001 13:43:49 -0500 (EST) From: Paul Koning To: Ari.Huttunen@f-secure.com Cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: comments on jfk and ikev2 drafts References: <200112100418.fBA4Itr01852@marajade.sandelman.ottawa.on.ca> <3C15D439.D1DA2BB@F-Secure.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari> Michael Richardson wrote: >> Suggested text: >> >> The Vendor ID Payload contains a vendor defined constant. The >> constant is used by vendors to identify and recognize remote >> instances of their implementations. This mechanism allows a >> vendor to experiment with new features while maintaining backwards >> compatibility. >> >> The Vendor ID payload is both an announcement from the sender of >> which space private payload types will come from, and also an >> announcement of the sort of private payloads it is willing to >> accept. That is fine for some implementations but I believe this is more restrictive than necessary. The first part is clearly true: the Vendor ID identifies the number space of transmitted private payloads. And presumably that host will also understand inbound private payloads for that same vendor ID. But a host that sends vendor ID X may also understand and accept received private payloads from any number of other vendor IDs. In fact, this pretty much has to be true if you're experimenting cross-vendor with a new feature that's encoded in private payloads. So what I would say instead is: The Vendor ID payload indicates which space private payload types transmitted by this node are taken from. A node may be able to accept and understand private payloads from multiple vendors; in that case, it would use the received Vendor ID to identify the number space to which inbound private payload types belong. paul From owner-ipsec@lists.tislabs.com Tue Dec 11 12:09:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBK9C211606; Tue, 11 Dec 2001 12:09:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16209 Tue, 11 Dec 2001 14:13:29 -0500 (EST) Message-Id: <200112102204.fBAM4k05013337@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Charlie_Kaufman@iris.com Cc: Ran Canetti , ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-reply-to: Your message of "Thu, 06 Dec 2001 23:30:37 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Dec 2001 17:04:46 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Charlie_Kaufman@iris.com writes: > >The one remaining difference is the choice of bits being signed. The >protocol >above signs selected fields from the messages, while IKEv2 proposes >signing the entirety of messages 1 and 2 as they appear on the wire. (and >the entirety of all future messages are integrity protected, so all fields >in all messages are integrity protected.) The advantage of the >IKEv2 approach is that it captures all relevant fields in the messages >including >any extensions like vendor IDs. It's also easier to specify, since the SIG >above will have to specify exactly how the bits are encoded for signing >(TLV vs raw; payloads with or without headers, etc). Doing so for messages 1 and 2 would require keeping state at the responder on receipt of message 1. -Angelos From owner-ipsec@lists.tislabs.com Tue Dec 11 12:09:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBK9F211619; Tue, 11 Dec 2001 12:09:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16208 Tue, 11 Dec 2001 14:13:28 -0500 (EST) Message-Id: <200112102154.fBALsn05031324@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Tero Kivinen Cc: ipsec@lists.tislabs.com, Charlie_Kaufman@iris.com, canetti@watson.ibm.com Subject: Re: compare-jfk-sigma.txt In-reply-to: Your message of "Sun, 09 Dec 2001 00:32:43 +0200." <15378.38155.49527.8799@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Dec 2001 16:54:49 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <15378.38155.49527.8799@ryijy.hel.fi.ssh.com>, Tero Kivinen writes: > >Actually it really does not matter which ends identity is protected >against active attacks unless we disallow changing of the direction of >the negotiation. This is something that the implementation can do; on detecting an incoming Message 1 from a peer with whom I already have an SA or with whom I'm willing to establish an SA, I simply start a JFK exchange myself. It's simple enough to detect cases where both parties are not willing to reveal their identities (and avoid a Message-1-war). -Angelos From owner-ipsec@lists.tislabs.com Tue Dec 11 13:02:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBL2P215453; Tue, 11 Dec 2001 13:02:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16317 Tue, 11 Dec 2001 14:58:38 -0500 (EST) Message-Id: <200112111957.fBBJvIo02103@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Some comments to draft-ietf-ipsec-ikev2-00.txt In-reply-to: Your message of "Tue, 11 Dec 2001 11:19:06 EST." <200112111619.LAA07109@wolfe.bbn.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Dec 2001 12:57:17 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Charles" == Charles Lynn writes: >>> I think it would be better to change the format of subnet selectors >>> to be IPVx_ADDRESS + Number of bits in the mask. It would remove the >>> problems what to do when the other end proposes mask 0xff00ff00? >>> (According to above it is completely valid :-) Dan> A mask of 0xff00ff00 _is_ completely valid. Michael> CIDR routing people would strongly disagree. Charles> The format that the routing folk use to identify networks to be advertised Charles> has little to do with what IPsec uses to identify systems that may use a Charles> particular SA (other than both being aggregations of IP addresses). The Charles> two have different requirements. Maybe, but they use the same pieces of silicon. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Dec 11 13:08:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBL8l216163; Tue, 11 Dec 2001 13:08:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16381 Tue, 11 Dec 2001 15:16:42 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Stephen Kent'" Cc: "'Hugo Krawczyk'" , "'IPsec WG'" Subject: RE: IKEv2 and SIGMA Date: Tue, 11 Dec 2001 14:59:38 -0500 Message-ID: <001101c18281$9f77b8a0$2dc6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I suspect that most people on this list don't have a requirement for either repudiation or non-repudation. A financial institution would want non-repudation, but of the IPsec traffic as well, so I would agree with you that non-repudiation in IKE is not a very important property. However, some of the hardcore privacy advocates would probably not want to leave a trail of who they've been talking to, so repudiation could be an important property for them. The issue here is that one of the protocols (SIGMA) has been specifically designed to have repudiation in the phase 1. For JFK and IKEv2, I don't think either repudiation or non-repudiation were design constraints. JFK always provides non-repudiation, but that is most likely by convenience rather than by design. IKEv2 has repudiation in the normal case, but this can be thwarted by the responder (the attack I mentioned below). SIGMA has a more elaborate hash calculation in order to avoid the possibility of signing anything that the peer generated. However, the device still signs the peer's cookie (and it should be just as easy to lauch the attack with a cookie as with a nonce) so SIGMA doesn't actually prevent this attack either. Therefore, I think the more generic hash calculation from IKEv2 is preferable. I don't personally care whether we design for repudiation or non-repudiation or neither. However, I would like to know that if we are adding special constraints to the protocol then we are at least getting something for it. How many WG members would need to require a repudiatable exchange before this became a Son-of-IKE design requirement? BTW, Hugo, you never explained why it was essential for IKEv2 to sign the identity and I can't see any justification for this requirement. Is this because: a) It has not been proven secure not to sign the identity? b) It has been proven insecure not to sign the identity? Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > Sent: Tuesday, December 11, 2001 9:49 AM > To: andrew.krywaniuk@alcatel.com > Cc: 'Hugo Krawczyk'; 'IPsec WG' > Subject: RE: IKEv2 and SIGMA > > > At 5:49 PM -0500 12/5/01, Andrew Krywaniuk wrote: > >Hugo, you have talked about the importance of carefully > choosing the inputs > >to the authentication hash. I envision a situation where: > > > >Responder chooses Nr = SIG_r(Ni, g^xi, IDr, ...) > >Initiator creates AUTHi = SIG_i(Ni, g^xy, Nr, ...) > > > >So now the initiator has been tricked into signing something > which binds a > >derivative of the responder's identity to the nonce and DH > values from the > >exchange. And the result is that the initiator can no longer > repudiate the > >exchange. > > > >Is this the kind of attack you are talking about? > > > >Andrew > >------------------------------------------- > >There are no rules, only regulations. Luckily, > >history has shown that with time, hard work, > >and lots of love, anyone can be a technocrat. > > Excuse me for this belated comment, as I am still working my way > through the 1K+ messages that arrived last week while I was away on > vacation. > > I think the term "repudiate" may be inappropriate in this context. > IPsec does not offer NR as a security service for the traffic sent on > an SA, so the opportunity to offer NR with regard to an IKE exchange > may not be all that important. Is there general agreement that NR is > a concern here? > > Steve > From owner-ipsec@lists.tislabs.com Tue Dec 11 13:10:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBLAn216318; Tue, 11 Dec 2001 13:10:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16350 Tue, 11 Dec 2001 15:10:15 -0500 (EST) Message-Id: <200112112008.fBBK8vs02338@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal In-reply-to: Your message of "Tue, 11 Dec 2001 00:08:26 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Dec 2001 13:08:57 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sami" == Sami Vaarala writes: Sami> The UDP encapsulation draft assumes that IKE packets never begin with Sami> eight zero bytes, whereas in IKEv2 the first eight bytes are the recipient Sami> SPI (cookie) (which is potentially zero). Sami> Since IKEv2 also runs on port 500, this seems like a problem. Since that NAT people insisted on running on the same port using a terrible hack to get around a number of imaginary problems, frankly, I think that this is the NAT people's problem. BTW: if we pick JFK, and the JFK people appear to feel strongly that they should run on a different port than 500, all of the "use the same port" arguments have become moot. Further, I think that IKE has the right to change things with the cookie values at any time. You made this kludge, now lie in 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 NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBZn14qHRg3pndX9AQEsxwP/TXCbRsSK/79/8V52M4c5spYxiij6koky HGtnFFG4E/3ox3AeZxbomjRvhuTPfLzZXAxgkzRXUJCN8azlNGqbTxAryIgvbzET EdqpwLUIrVyenaTYPDEjfXzy0kXNa0nMg3W8KmlObW0aCVmIcXRwSTkvwIPGSuYA IZJNcHlPEGQ= =pwYd -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 11 13:13:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBLD0216440; Tue, 11 Dec 2001 13:13:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16389 Tue, 11 Dec 2001 15:20:55 -0500 (EST) Message-Id: <200112112019.fBBKJbM02615@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: vendorid text in ikev2 draft In-reply-to: Your message of "Tue, 11 Dec 2001 13:43:49 EST." <15382.21477.133881.499918@pkoning.dev.equallogic.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Dec 2001 13:19:37 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: Ari> Michael Richardson wrote: >>> Suggested text: >>> >>> The Vendor ID Payload contains a vendor defined constant. The >>> constant is used by vendors to identify and recognize remote >>> instances of their implementations. This mechanism allows a >>> vendor to experiment with new features while maintaining backwards >>> compatibility. >>> >>> The Vendor ID payload is both an announcement from the sender of >>> which space private payload types will come from, and also an >>> announcement of the sort of private payloads it is willing to >>> accept. Paul> That is fine for some implementations but I believe this is more Paul> restrictive than necessary. You may be right. The reason for the original text in v1 was because payloads that were not understood were cause of failure. With the Critical bit, this isn't as much of an issue anymore. The other purpose was for dealing with quirks. Paul> But a host that sends vendor ID X may also understand and accept Paul> received private payloads from any number of other vendor IDs. In Agreed. Paul> fact, this pretty much has to be true if you're experimenting Paul> cross-vendor with a new feature that's encoded in private payloads. yes. Paul> So what I would say instead is: Paul> The Vendor ID payload indicates which space private payload types Paul> transmitted by this node are taken from. A node may be able to Paul> accept and understand private payloads from multiple vendors; in Paul> that case, it would use the received Vendor ID to identify the Paul> number space to which inbound private payload types belong. Paul> paul I can not think of a reason why this won't work in IKEv2, but I'm still nervous. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBZqV4qHRg3pndX9AQFoKwP/f41RyTDgU2QWKuwSpuBlBDBUgJQPSXtH DZ+65Q2hNNVdJ/UapOPv1mw0sgvx25Bqk7D9xLjA/zgzV/JAkZU4gDIwm7BkK1i5 mwyLBhW9ol9J4ad6qmqJCWAvfFPjd/NePPP53vJ3rEA4NBu9mCuH3AGb9StzVhw7 6hcU3CB0kfc= =ljKr -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 11 13:18:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBLIN216620; Tue, 11 Dec 2001 13:18:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16423 Tue, 11 Dec 2001 15:30:08 -0500 (EST) Date: Tue, 11 Dec 2001 15:36:55 -0500 (EST) From: Henry Spencer To: Markku Savela cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-Reply-To: <200112080027.CAA22278@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 8 Dec 2001, Markku Savela wrote: > > That sounds great for outbound/initiator. > > How does one communicate selectors to the kernel of the responder? > > Policy is what gets handed down to you by a person (or a system) > responsible for the security of the site or service you want to use > and which is protected by IPSEC. Assuming that both you and the site/service you want to use are under the same administration. Which is by no means universally true. There is also the desirability of checking for errors. Even under a common administration, just because the two ends are *supposed* to agree on security policy does not mean they do, and a silent failure of agreement can result in no communication and no clear indication of why. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Dec 11 15:34:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBNY8227569; Tue, 11 Dec 2001 15:34:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16718 Tue, 11 Dec 2001 17:53:41 -0500 (EST) Message-Id: <3.0.3.32.20011211150520.0107a570@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 11 Dec 2001 15:05:20 -0800 To: "Steven M. Bellovin" , andrew.krywaniuk@alcatel.com From: Alex Alten Subject: Re: Son-of-IKE Performance Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com In-Reply-To: <20011208035926.C4BB47B55@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:59 PM 12/7/2001 -0500, Steven M. Bellovin wrote: >In message <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com>, "Andrew >Krywaniuk" writes: >> >>Here's a question. Have the authors of JFK given any thought to how (if?) >>they will incorporate NAT-traversal? With IKEv2, the already completed >>drafts from IKEv1 can be presumably carried forward. > >JFK doesn't rely on IP addresses at all -- it can pass through NATs >just fine. > Wow! Now I am interested in reading the draft. Since IP addresses are so ephemeral and insecure this, if designed correctly, would be a fundamental step forward. - Alex -- Alex Alten Alten@NetVista.Com From owner-ipsec@lists.tislabs.com Tue Dec 11 15:37:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBBNbT227729; Tue, 11 Dec 2001 15:37:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16664 Tue, 11 Dec 2001 17:39:16 -0500 (EST) To: ipsec@lists.tislabs.com From: dharkins@tibernian.com Subject: suggestion for JFK MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1933.1008110944.1@SailPix.com> Date: Tue, 11 Dec 2001 14:49:04 -0800 Message-Id: <20011211224904.B94E354C48@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In JFK the responder sends, in message 2, a token (the HMAC{Hkr}(blah) payload) back to the initiator which binds the initiator to a nonce he supplied in message 1. The responder doesn't create any state though. Someone could send a message 1 to obtain a valid token and then construct several hundred bogus message 3's with the valid nonce and token forcing the responder to exponentiate in an attempt to decrypt a garbage packet. This would require no exponentiation or encryption on the part of the attacker and none of the bogus packets need to be sourced from his IP address. The responder should rate limit these messages, of course, and could scan an input queue for the bad token to eliminate these bogus packets before any serious work is done on them but there is no way to locate the offender. If the IP address of the initiator that sent message 1 was included in the token calculation-- i.e. HMAC{Hkr}(Ni, Nr, g^i, g^r, addr)-- it would force such an attacker to reveal his IP address. I think this would be a good thing. Dan. From owner-ipsec@lists.tislabs.com Tue Dec 11 16:15:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0F7229170; Tue, 11 Dec 2001 16:15:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16915 Tue, 11 Dec 2001 18:28:58 -0500 (EST) Date: Wed, 12 Dec 2001 01:39:12 +0200 (IST) From: Hugo Krawczyk To: Stephen Kent cc: andrew.krywaniuk@alcatel.com, "'IPsec WG'" Subject: RE: IKEv2 and SIGMA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My personal opinion on non-repudiation is that this should be a requireent only from applications where the semantics of what is signed are explicit and clear to the signer (and where all the legal implications of signing are also explicit and clear). This is not the case with IKE (or ipsec in general) where one is signing all type of formatted and un-formatted information (such as IDs and nonces). Signatures in a key exchange protocol are used for two-party authentication, not for leaving provable traces for use by third parties. And apropos not leaving provable traces of communications, I see this as a good property of a key-exchange protocol, but NOT an essential requirement. In particular SIGMA is not designed specifically to meet this requirement. You get it as a free bonus since the protocol (for other GOOD reasons) does not sign the peer's id. Hugo On Tue, 11 Dec 2001, Stephen Kent wrote: > At 5:49 PM -0500 12/5/01, Andrew Krywaniuk wrote: > >Hugo, you have talked about the importance of carefully choosing the inputs > >to the authentication hash. I envision a situation where: > > > >Responder chooses Nr = SIG_r(Ni, g^xi, IDr, ...) > >Initiator creates AUTHi = SIG_i(Ni, g^xy, Nr, ...) > > > >So now the initiator has been tricked into signing something which binds a > >derivative of the responder's identity to the nonce and DH values from the > >exchange. And the result is that the initiator can no longer repudiate the > >exchange. > > > >Is this the kind of attack you are talking about? > > > >Andrew > >------------------------------------------- > >There are no rules, only regulations. Luckily, > >history has shown that with time, hard work, > >and lots of love, anyone can be a technocrat. > > Excuse me for this belated comment, as I am still working my way > through the 1K+ messages that arrived last week while I was away on > vacation. > > I think the term "repudiate" may be inappropriate in this context. > IPsec does not offer NR as a security service for the traffic sent on > an SA, so the opportunity to offer NR with regard to an IKE exchange > may not be all that important. Is there general agreement that NR is > a concern here? > > Steve > From owner-ipsec@lists.tislabs.com Tue Dec 11 16:19:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0J0229312; Tue, 11 Dec 2001 16:19:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16909 Tue, 11 Dec 2001 18:28:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6092.0 Content-Class: urn:content-classes:message Subject: RE: UDP DoS attack in Win2k via IKE (fwd) Date: Tue, 11 Dec 2001 15:35:09 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1045451DE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: UDP DoS attack in Win2k via IKE (fwd) Thread-Index: AcF/Xu9YPMkEj9ruTwWDP0knt7lf5QDPZpNw From: "William Dixon" To: "Steve Bellovin" , X-OriginalArrivalTime: 11 Dec 2001 23:35:10.0053 (UTC) FILETIME=[790DA150:01C1829C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Steve. We are investigating. Wm William Dixon Program Manager - Network Security, IPSec Windows Networking Microsoft w (425)-703-8729 email: wdixon@windows.microsoft.com -----Original Message----- From: Steve Bellovin [mailto:smb@research.att.com] Sent: Friday, December 07, 2001 12:28 PM To: ipsec@lists.tislabs.com Subject: UDP DoS attack in Win2k via IKE (fwd) This just moved on bugtraq. It seems relevant to what we're discussing. ------- Forwarded Message Message-ID: <001901c17f45$cb54fc60$0100a8c0@downstairs> From: "c0redump" To: Subject: UDP DoS attack in Win2k via IKE Date: Fri, 7 Dec 2001 17:37:07 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="Windows-1252" X-UIDL: 6efe10f9299eedf02227cee0d07fabfa UDP DoS in Win2k via IKE PROBLEM ======= A DoS attack can be carried out on Win2k machines running IKE (internet key exchange) by sending flooding IKE with UDP packets. This can cause the machine to lock up and render 99% of the CPU. EXPLOIT ====== Connect to port 500 (IKE) of the Win2k box and start sending UDP packets of more than 800 bytes continuously. The box will eventually stop responding and services will be denied due to 99% CPU usage from the packets. SOLUTION ======= Firewall port 500 off if IPSsec is not in use. c0redump@ackers.org.uk gridrun@spacebitch.com #hacktech @ undernet ------- End of Forwarded Message --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Tue Dec 11 16:22:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0Mm229424; Tue, 11 Dec 2001 16:22:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16944 Tue, 11 Dec 2001 18:34:02 -0500 (EST) Date: Wed, 12 Dec 2001 01:44:00 +0200 (IST) From: Hugo Krawczyk To: "Angelos D. Keromytis" cc: Charlie_Kaufman@iris.com, Ran Canetti , ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-Reply-To: <200112102204.fBAM4k05013337@nyarlathotep.keromytis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a good point, Angelos! Let me take this opportunity to say that there is no need at all for R to sign message 1 (but only include the nonce sent by I under its own signature). The way I see the question of what should be signed is as follows: a party should sign (i.e include under its own authentication) ALL the information it sends PLUS freshness information from the peer (such as a nonce). The motivation for this is that each party needs to verify that ALL the information it received was really sent by the peer, and is fresh, i.e. generated in this run of the protocol and not replayed from a previous one. SO I do not recommend a too selective signing as done in IKEv1 and JFK (which may leave unauthenticated information in the protocol -- as actually happens in IKEv1), and I do not recommend Tero's hash where EVERY bit in the protocol (regardless of who sent it) is signed, but rather the middle way where each party signs everything she sent plus the peer's nonce. (For example, signing everythingin IKEv2 or SIGMA would lead to everyone signing the peer's ID which has no security advantage, and has some privacy disadvantages). BTW, there is another reason not to go for a "sign message 1 and message 2" as in IKEv2: if you do that then the security of the protocol depends on what exactly you sent in these messages. As an example, if one sends g^i in the third message of the protocol (this makes sense if the responder does not keep state anyway after message 1) then the protocol becomes INSECURE since the signature of I on g^x is fundamental for the security of the protocol. [Note that g^i in msg 1 serves also to tell R what is the prefered group by I, but if R does not keep state then it would be sufficient for I to send in msg 1 a simple group descriptor rather than 1Kb+ of DH exponential]. If, instead, each party signs all the information she sent then it is guaranteed to include g^x regardless of the message where it was sent. Hugo On Mon, 10 Dec 2001, Angelos D. Keromytis wrote: > > In message in>, Charlie_Kaufman@iris.com writes: > > > >The one remaining difference is the choice of bits being signed. The > >protocol > >above signs selected fields from the messages, while IKEv2 proposes > >signing the entirety of messages 1 and 2 as they appear on the wire. (and > >the entirety of all future messages are integrity protected, so all fields > >in all messages are integrity protected.) The advantage of the > >IKEv2 approach is that it captures all relevant fields in the messages > >including > >any extensions like vendor IDs. It's also easier to specify, since the SIG > >above will have to specify exactly how the bits are encoded for signing > >(TLV vs raw; payloads with or without headers, etc). > > Doing so for messages 1 and 2 would require keeping state at the responder > on receipt of message 1. > -Angelos > From owner-ipsec@lists.tislabs.com Tue Dec 11 16:29:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0Tg200227; Tue, 11 Dec 2001 16:29:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16964 Tue, 11 Dec 2001 18:36:42 -0500 (EST) Date: Wed, 12 Dec 2001 01:46:57 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'Stephen Kent'" , "'IPsec WG'" Subject: RE: IKEv2 and SIGMA In-Reply-To: <001101c18281$9f77b8a0$2dc6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 11 Dec 2001, Andrew Krywaniuk wrote: [....] > > The issue here is that one of the protocols (SIGMA) has been specifically > designed to have repudiation in the phase 1. For JFK and IKEv2, I don't SIGMA was NOT specifically designed for this. Every bit in SIGMA has a role in the provability of the core security properties. The non-transferable proofs are a nice side-effect and, as you pointed out, it cannot always be guaranteed if the peer is malicious. > think either repudiation or non-repudiation were design constraints. JFK > always provides non-repudiation, but that is most likely by convenience > rather than by design. IKEv2 has repudiation in the normal case, but this > can be thwarted by the responder (the attack I mentioned below). > > SIGMA has a more elaborate hash calculation in order to avoid the > possibility of signing anything that the peer generated. However, the device > still signs the peer's cookie (and it should be just as easy to lauch the > attack with a cookie as with a nonce) so SIGMA doesn't actually prevent this > attack either. Therefore, I think the more generic hash calculation from > IKEv2 is preferable. The hash calculation of SIGMA is to make sure you MAC (or prf) the ID. This same MAC can go outside the signature; it just saves space if you put it inside. Again, the fundamental issue is that you make absolutely sure to include the sender's ID under the MAC. > > I don't personally care whether we design for repudiation or non-repudiation > or neither. However, I would like to know that if we are adding special > constraints to the protocol then we are at least getting something for it. > How many WG members would need to require a repudiatable exchange before > this became a Son-of-IKE design requirement? > > BTW, Hugo, you never explained why it was essential for IKEv2 to sign the > identity and I can't see any justification for this requirement. Is this > because: > > a) It has not been proven secure not to sign the identity? > b) It has been proven insecure not to sign the identity? It has been proven INSECURE not to MAC the identity. If you sign the identity but do not include a MAC the protocol is insecure. This uses a 10+ year (simple but non-obvious) attack discovered by Diffie, van Oorschot and Wiener, and a main motivation behind SIGMA's (and IKE) design. Sara Bitan will be making a presentation at the ipsec meeting where hopefully some of these crypto issues will be clarified. Hugo > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > > Sent: Tuesday, December 11, 2001 9:49 AM > > To: andrew.krywaniuk@alcatel.com > > Cc: 'Hugo Krawczyk'; 'IPsec WG' > > Subject: RE: IKEv2 and SIGMA > > > > > > At 5:49 PM -0500 12/5/01, Andrew Krywaniuk wrote: > > >Hugo, you have talked about the importance of carefully > > choosing the inputs > > >to the authentication hash. I envision a situation where: > > > > > >Responder chooses Nr = SIG_r(Ni, g^xi, IDr, ...) > > >Initiator creates AUTHi = SIG_i(Ni, g^xy, Nr, ...) > > > > > >So now the initiator has been tricked into signing something > > which binds a > > >derivative of the responder's identity to the nonce and DH > > values from the > > >exchange. And the result is that the initiator can no longer > > repudiate the > > >exchange. > > > > > >Is this the kind of attack you are talking about? > > > > > >Andrew > > >------------------------------------------- > > >There are no rules, only regulations. Luckily, > > >history has shown that with time, hard work, > > >and lots of love, anyone can be a technocrat. > > > > Excuse me for this belated comment, as I am still working my way > > through the 1K+ messages that arrived last week while I was away on > > vacation. > > > > I think the term "repudiate" may be inappropriate in this context. > > IPsec does not offer NR as a security service for the traffic sent on > > an SA, so the opportunity to offer NR with regard to an IKE exchange > > may not be all that important. Is there general agreement that NR is > > a concern here? > > > > Steve > > > > From owner-ipsec@lists.tislabs.com Tue Dec 11 16:53:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC0re202372; Tue, 11 Dec 2001 16:53:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16894 Tue, 11 Dec 2001 18:26:40 -0500 (EST) Date: Wed, 12 Dec 2001 01:36:47 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'Tero Kivinen'" , IPsec WG , dharkins@tibernian.com Subject: RE: Some comments to draft-ietf-ipsec-ikev2-00.txt In-Reply-To: <000d01c1821a$aeada260$14c6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 11 Dec 2001, Andrew Krywaniuk wrote: > > > 3.1 Generating Keying Material for the IKE-SA > > ... > > > SKEYSEED = prf(Ni | Nr, g^ir) > > > > As this is the only place where nonces are used their entropy is > > limited to the output of the PRF. I.e it is no use of using nonces > > whose combined entropy is more than 128 bits if we using the HMAC-MD5 > > as PRF, as the output of the SKEYSEED is going to be 128 bits. > > > > > SKEYSEED_d = prf(SKEYSEED, g^ir | CKY-I | CKY-R | 0) > > > SKEYSEED_a = prf(SKEYSEED, SKEYSEED_d | g^ir | > > CKY-I | CKY-R | 1) > > > SKEYSEED_e = prf(SKEYSEED, SKEYSEED_a | g^ir | > > CKY-I | CKY-R | 2) > > > > I think that could be fixed by adding the nonces to the above > > calculations also in addition of the cookies. > > > Or by simply replacing the cookies with the nonces. That would be the > *obvious* method ;-) Introducing the nones would be ok, though I do not believe it would practically make any difference (since they are already included under the SKEYID computation). The reason to have the cookies is since they act as a"session identifier" and it is good practice (and analytical advantage) to bind the keying material to the specific session. > > Still, I notice that IKEv2 carries forward the "broken" phase 1 key > stretching algorithm from IKEv1: > > K1 = prf(SKEYSEED_e, 0) > K2 = prf(SKEYSEED_e, K1) > K3 = prf(SKEYSEED_e, K2) > > As was noted from earlier discussions, g^xy ought to be reintroduced at each > stage in order to preserve the full entropy of the key exchange. This is not broken. There is no need to re-introduce g^xy in each computation. Quite the opposite, from an analytical point of view, it would be broken to re-introduce g^xy into the computation. As a general pricniple, if you have two keys k and k' where k' was derived from k then applying prf(k', k) (here k' is the key to the prf and k the input) may be insecure even if prf is an excelent pseudorandom function family (see the book of Goldreich on the Foundations of Cryptography). The same is the case if k' is derived from k through a chain of derivations: in our case g^xy -> SKEYSEED -> SKEYSEED_e so if you appply now prf(SKEYSEED_e, g^xy ....) as you suggest then the theoretical anlysis is broken. And it makes no difference for the above argument if your prf is generic or specifically HMAC as used in both JFK and IKEv2 Hugo > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > From owner-ipsec@lists.tislabs.com Tue Dec 11 19:10:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC3Au208910; Tue, 11 Dec 2001 19:10:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17334 Tue, 11 Dec 2001 21:30:01 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: andrew.krywaniuk@alcatel.com Cc: "'Stephen Kent'" , "'Hugo Krawczyk'" , "'IPsec WG'" Subject: Re: IKEv2 and SIGMA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Dec 2001 19:39:38 -0700 Message-Id: <20011212023938.D165F7B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <001101c18281$9f77b8a0$2dc6830c@andrewk3.ca.newbridge.com>, "Andrew Krywaniuk" writes: >The issue here is that one of the protocols (SIGMA) has been specifically >designed to have repudiation in the phase 1. For JFK and IKEv2, I don't >think either repudiation or non-repudiation were design constraints. JFK >always provides non-repudiation, but that is most likely by convenience >rather than by design. Correct -- it never entered our discussions, one way or another. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Tue Dec 11 19:46:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC3kI210274; Tue, 11 Dec 2001 19:46:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17373 Tue, 11 Dec 2001 22:09:23 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" Cc: "'IPsec WG'" Subject: RE: Some comments to draft-ietf-ipsec-ikev2-00.txt Date: Tue, 11 Dec 2001 22:11:21 -0500 Message-ID: <000901c182bb$48f7f730$2dc6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > As a general pricniple, > if you have two keys k and k' where k' was derived from k > then applying prf(k', k) (here k' is the key to the prf and k > the input) > may be insecure even if prf is an excelent pseudorandom > function family Okay, I believe you. But both of these issues deal with key stretching, although in one case the input is public information and in one case the input is private information. If SKEYSEED = prf(Ni | Nr, g^ir) and we use the generic stretching algorithm then it does no good to make Ni and Nr any bigger than the output of the hash. If that is the case then many of us ought to be changing our code to use smaller nonces, since large nonces are merely wasting entropy and bandwidth. (And the draft ought to talk about how to choose an appropriate length nonce.) In the case of: K1 = prf(SKEYSEED_e, 0) K2 = prf(SKEYSEED_e, K1) K3 = prf(SKEYSEED_e, K2) The problem is that no matter how large you make your DH exponent, the entropy in your key(s) is limited by the output of your hash. This was brought up a couple of times in reference to IKEv1 and I had assumed that we would be fixing it in IKEv2. Isn't there a way to get around this problem, or do we all need to go and implement SHA-2 solely for the purpose of key stretching? Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Dec 11 19:46:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC3kL210287; Tue, 11 Dec 2001 19:46:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17379 Tue, 11 Dec 2001 22:09:26 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" Cc: "'IPsec WG'" Subject: RE: IKEv2 and SIGMA Date: Tue, 11 Dec 2001 22:14:27 -0500 Message-ID: <000a01c182bb$4b4bd240$2dc6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk *HARDCORE PRIVACY ADVOCATES* Alright... that ought to be enough to prevent my message from being sent to tfs@ebsdr.com. > > BTW, Hugo, you never explained why it was essential for > IKEv2 to sign the > > identity and I can't see any justification for this > requirement. Is this > > because: > > > > a) It has not been proven secure not to sign the identity? > > b) It has been proven insecure not to sign the identity? > > It has been proven INSECURE not to MAC the identity. If you sign the > identity but do not include a MAC the protocol is insecure. > This uses a > 10+ year (simple but non-obvious) attack discovered by Diffie, van > Oorschot and Wiener, and a main motivation behind SIGMA's (and IKE) > design. When I said "sign the identity", what I really meant was "include the identity in the data which is signed." *Of course* you MAC it first. But in in IKEv2, you only MAC the identity; in SIGMA, you MAC the identity and then sign it. Let's try this again... You never explained why it was essential for IKEv2 to *sign* the MAC of the identity and I can't see any justification for this requirement. Is this because: a) It has not been proven secure not to sign the MAC of the identity? b) It has been proven insecure not to sign the MAC of the identity? c) It saves space to put just a signature in message 3 instead of a signature and a MAC. Answering (c) would be a cop-out, since that wouldn't be "essential for security"... Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Dec 11 19:58:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC3wk210566; Tue, 11 Dec 2001 19:58:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17424 Tue, 11 Dec 2001 22:25:13 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" Cc: Subject: RE: compare-jfk-sigma.txt Date: Tue, 11 Dec 2001 22:30:40 -0500 Message-ID: <000c01c182bd$7f8e8140$2dc6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > BTW, there is another reason not to go for a "sign message 1 > and message > 2" as in IKEv2: if you do that then the security of the > protocol depends > on what exactly you sent in these messages. When it says "sign messages 1&2" in IKEv2, I would hazzard a guess that this only applies when you are not using stateless DoS protection. When you are using stateless DoS protection then you sign messages 3&4 instead. ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Dec 11 20:25:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC4Pk211797; Tue, 11 Dec 2001 20:25:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17436 Tue, 11 Dec 2001 22:33:20 -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: Some comments to draft-ietf-ipsec-ikev2-00.txt Date: 12 Dec 2001 03:41:52 GMT Organization: University of California, Berkeley Lines: 5 Distribution: isaac Message-ID: <9v6jm0$94p$1@abraham.cs.berkeley.edu> References: <000901c182bb$48f7f730$2dc6830c@andrewk3.ca.newbridge.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1008128512 9369 128.32.45.153 (12 Dec 2001 03:41:52 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 12 Dec 2001 03:41:52 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 Andrew Krywaniuk wrote: >The problem is that no matter how large you make your DH exponent, the >entropy in your key(s) is limited by the output of your hash. Why is this a problem? Are you worried about 2^160 work attacks? From owner-ipsec@lists.tislabs.com Tue Dec 11 21:35:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC5Zr213561; Tue, 11 Dec 2001 21:35:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17641 Tue, 11 Dec 2001 23:46:43 -0500 (EST) Message-Id: <200112120455.fBC4tv552139@romeo.rtfm.com> To: ipsec@lists.tislabs.com Subject: More Son-of-IKE Performance Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Dec 2001 20:55:57 -0800 From: Eric Rescorla Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've made another pass through the verious son-of-IKE contenders and generated a more complete performance table. This version includes latency estimates from the perspective of the initiator and responder. In general, these protocols all have the property that the responder has a completed SA before the initiator. Protocol Initiator Responder Init. Latency Resp. Latency ----------------------------------------------------------------------------- IKEv2 1 signature 1 signature 2 RTT 1 RTT 1 verify 1 verify 1 DH agree 1 DH agree 1 DH agree 1 DH agree 2 signs 1 sign 2 verify 1 verify IKEv2 1 signature 1 signature 3 RTT 2 RTT (DoS mode) 1 verify 1 verify 1 DH agree 1 DH agree 1 DH agree 1 DH agree 2 signs 1 sign 2 verify 1 verify SIGMA [1] 1 signature 1 signature 2 RTT 1 RTT 1 verify 1 verify 2 sign 2 verify 1 DH agree 1 DH agree 2 DH key agree 2 DH key agree SIGMA [1] 1 signature 1 signature 3 RTT 2 RTT (DoS mode) 1 verify 1 verify 2 sign 2 verify 1 DH agree 1 DH agree 2 DH key agree 2 DH key agree JFK(normal) 1 signature 1 signature 2 RTT 1 RTT 2 verifies 1 verify 2 DH agree 2 DH agree 1 DH agree 1 DH agree 2 sign 1 verify 2 verify JFK(PFS) [2] 1 signature 2 signature 2 RTT 1 RTT 2 verifies 1 verify 2 DH agree 2 DH agree 1 DH agree 1 DH agree 3 sign 1 sign 2 verify 1 verify XKASS 1 RSA enc. 1 RSA enc. 1 RTT 0 RTT (encryption) 1 RSA dec. 1 RSA dec. 2 RSA enc. 1 RSA enc. 2 RSA dec. 1 RSA dec. XKASS 1 signature 1 signature 1 RTT 0 RTT 1 verify 1 verify 2 sign 1 DH agree 2 verify 1 verify 1 DH agree Notes: [0] I'm ignoring the following computational costs since they're more or less constant across protocols and are usually cheap. Digests, symmetric encryption, and PRFs. Certificate verification (not cheap if DSS) All of the PFS modes require an additional g^x mod p. [1] I'm assuming a SIGMA variant with an essentially empty ACK as the fourth message. [2] In JFK, PFS mode is incompatible with DoS protection. [3] Here are some approximate timings for the various operations (measured on a Celeron 300). All moduli are 1024-bit. RSA private key op 30 ms RSA public key op 2 ms DH key agree (1024-bit X) 100 ms (256-bit X) 25 ms DSA signature 17 ms DSA verify 21 ms [4] IKEv2 can perform the key exchange operation in parallel and the client and server. It's a little hard to figure whether XKASS as written can but it could certainly be made to do so. The table above assumes it does. -Ekr From owner-ipsec@lists.tislabs.com Wed Dec 12 01:57:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBC9v0211246; Wed, 12 Dec 2001 01:57:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18227 Wed, 12 Dec 2001 03:57:26 -0500 (EST) Date: Wed, 12 Dec 2001 04:07:02 -0500 (EST) From: "D. Hugh Redelmeier" Reply-To: To: IPsec List Subject: rushed comments on IKEv2 draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just read draft-ietf-ipsec-ikev2-00.txt for the first time. Here are my detailed comments on what I read. Disclaimers: I read and wrote too quickly. I haven't read others comments. I'm rushing to get this out before the IETF sessions that will deal with this draft. I liked much about the draft, but I'm not going to say anything about the parts that I agree with. So this is full of complaints. This document is ordered to match the text it comments on. The complaints are very mixed in importance. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 IKEv2 is not close enough to IKE v1 to be considered just a version change. Many changes are nice but not important. On the other hand, it carries a lot of baggage from IKE v1. A blank-page design could be a lot cleaner and simpler. I'd say that it falls between these two stools. As such, I would not support its adoption until it goes one way or the other. Global: - I think all occurrences of "byte" should be replaced with "octet". Somewhere: - I don't see anything to address the well-known race condition between setting up IPsec SAs and using them. A third message in Phase 2 serves admirably. I am not consciously arguing for a commit bit :-) - [3.1? 4.1? 7.4?] The draft should spell out how bignums are to be represented as octets. Big-endian is obvious. Not so obvious is that the number of octets to be used does not depend on the length of the value but on the length of the modulus. This makes a difference when converting values to octets for keying material and hashes. - in IKEv1, there are a few constraints on payload order. In our interop testing, we think all implementations sent payloads in the order used in the RFC. So this was useless freedom, causing more test cases, ones that have probably never been exercised! I suggest that the payload order be fully specified. 1.1 The IKE Protocol - viewing all IKE messages as fitting into request/response pairs may be a straightjacket. Each message that is neither the first nor the last could be designed as as a response to the previous message AND a request for the next. On the other hand, the pure request/response view may be easier to understand. - As described in draft-spencer-ipsec-ike-implementation-01.txt section 3.2 I think that a more symmetric retransmission logic is better. It does not depend on who is the Initiator and who is the Responder: (1) if a reply is expected, retransmit only if it does not appear before a timeout (2) if a reply is not expected (last message of the exchange), retransmit only on receiving a retransmission of the previous message. If DOS evasion is being attempted, and we just sent the second message, (1) should be suppressed -- part of being stateless. - The description of the anti-DOS steps could be improved by making them more formal. An example of a question not answered by the text: may the Responder delay the Initiator indefinitely with a series of IKE_SA_init_reject messages? 1.2 Changes from IKEv1 - I'd like to add two goals: + Eliminate race conditions in setting up or replacing an IPsec SA group (those SAs created by a single exchange). + to standardise rekeying (replacement of SAs). 2.1 Use of Retransmission Timers - see comments on 1.1. Interesting that this is covered two places in the document. 2.2 Use of Sequence Numbers for Message ID - In IKEv1, (non-zero) message IDs are used only after Phase 1. Am I right in interpreting this section as saying all messages Have message IDs, and only the first pair of Phase 1 messages have zero message IDs? This isn't completely clear. "In the case where the IKE_SA_init is rejected (e.g. in order to require a cookie), the second IKE_SA_init message will begin the sequence over with Message #0." Does an the second IKE_SA_init message start both sides Message ID at zero? Surely yes, but this isn't clear. When an IKE SA is rekeyed, does the Message ID start at 0 again? In summary, I think that the counter should be local to the IKE SA and should start at 0 for each new IKE SA. I am not sure that this is what is being proposed. 2.3 Window Size for overlapping requests - "An IKE endpoint SHOULD be capable of processing incoming requests out of order to maximize performance in the event of network failures or packet reordering." Does this make sense if request n logically requires n-1? - Are there race conditions to be considered? For example: Since child-SAs are inherited by the replacing IKE SA, would it be legal for an apparently-subsequent delete notification to come under the protection of the superseded IKE SA? 2.6 Cookies "Unlike ESP and AH where only the recipient's SA identifier appears in the message, in IKE, the sender's IKE SA identifier is also sent in every message. In IKEv1 the IKE-SA identifier consisted of the pair (Initiator cookie, Responder cookie), whereas in IKEv2, the SA is uniquely defined by the recipient's SA identifier even though both are included in the IKEv2 header." - since only the recipient's cookie matters, why not expand it to fill the whole space formerly used for the pair of cookies? A larger cookie might have advantages and there would seem to be no worse compatibility problems. - The SA is uniquely identified (not defined) by the recipient's SA identifier AND IP address, I think. This is analogous to the IPsec case. If not "IP address", some system identifier -- we cannot assume that the SA identifier is globally unique. 2.8 Rekeying - Negotiation of a new IKE SA within an IKE SA is not well described and that description seems to be in the wrong place. + 2.8 says: To rekey an IKE-SA, establish a new equivalent IKE-SA (see section 4 and 4.2 below) with the peer to whom the old IKE-SA is shared using a Phase 2 negotiation within the existing IKE-SA. An IKE-SA so created inherits all of the original IKE-SA's child SAs. Use the new IKE-SA for all control messages needed to maintain the child-SAs created by the old IKE-SA, and delete the old IKE-SA. + IKE SA creation is not mentioned in section 4. It only talks about child SAs -- I don't think that an IKE SA is a child. Besides, the TS payloads (mandatory) have no meaning for an IKE SA. Ahh: the syntax described in 4 is wrong for 4.2, but no diagram appears in 4.2. Somehow, 4 should be generalized to cover IKE and IPsec SA negotiation; perhaps it needs to be split. + The title of 4.2 "Generating Keying Material for IKE-SAs from a create-child exchange" is misleading. It should be called something like "Replacing [rekeying?] an IKE SA using a create-child exchange". More than generating keying material is going on: SPIs are being changed, msgids are starting over (I think), lifetimes are probably being reset. Apparently Phase 1 IDs are not being changed. 2.9 Traffic Selector Negotiation - the description doesn't suggest that Traffic Selectors can include protocol as a selector. Surely they can. - "The Responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating one or more members of the set of traffic selectors provided the set does not become the NULL set." This concerns me. I don't know that this negotiation can be guaranteed to satisfy the Initiators needs. Yet the Initiator cannot express this. I don't know what negotiation makes sense here -- I don't have a counterproposal. 3 The Phase 1 Exchange - "identities are hidden from eavesdroppers." It would be good to point out that an active attack can reveal identities. - HDR*, ID, AUTH, [CERT,] SA, TSi, TSr --> This diagram, as I read it, is wrong: the "SA, TSi, TSr" is optional. I suggest: HDR*, ID, AUTH, [CERT,] [ SA, TSi, TSr ] --> Similar adjustment is needed to the response syntax. It would be good to actually write the two messages/response pairs separately since the optional payloads in the first message determine whether the optional payloads are forbidden or required in the response. - what happens if the IKE SA negotiation would succeed but the piggybacked IPsec SA group negotiation would fail? How is that communicated? 4 The CREATE-CHILD-SA (Phase 2) Exchange - "A phase 2 exchange is one request/response pair, and can be used to create or delete a child-SA, delete the IKE-SA, or deliver information such as error conditions." I think that it can be used to create a new IKE SA too. - there are two kinds of PFS. This should be discussed somewhere -- here? - If the Initiator includes a KE, must the Responder? If the Initiator does not include a KE, must the Responder not include a KE? I don't think that this is specified. 4.1 Generating Keying Material for IPsec SAs - "A single child-SA negotiation results in two security associations-- one inbound and one outbound." This is not always true -- there may be as many as 6. This is an example of why I wish to introduce a term for the collection of IPSEC SAs arising from a single negotiation. For now, I use "group". 5 Informational (Phase 2) Exchange - There needs to be a name for the collection of IPsec SAs negotiated at once. With this name, the concept can be recognized as important. I will use "group" for now. - A delete should delete a whole group at once. Nothing else makes sense. How to refer to the group? By the message-ID of the Phase 2 that negotiated the group (there should be an equivalent for piggyback-negotiated groups). No fuss, no muss (no problem with some but not all SAs of a group being deleted, no problem with referring to an ipcomp SA, no problem with implied reference to outbound SAs). No delete should refer to an SPI. To delete an IKE SA, you must issue the delete under the protection of that SA. So the SA can be implicit, as long as the protocol 0 is specified. So what protocol should be used for the IPsec SA group? Why not 1 (the old DOI)? - "ESP, AH, and IPcomp SAs always exist in pairs, with one SA in each direction." This should be qualified by "created through IKE". - "When SAs are nested" I think that this would be more accurately described using the "group" concept. 6 Error Handling - "There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service attack based on forged messages." There is also a risk of disclosing compromising information. 7.1 The IKE Header - the HDR is unprotected (unauthenticated, unencrypted). Everything that can be moved out should be moved out to be protected: + next payload + exchange type + flags (except *possibly* E(ncrypted)) + message ID + length The explicit IV makes it possible to hide more than would otherwise be the case. The SPI aka cookies ought to be enough. If IKEv1 is going to be catered to, make up a plausible header, but don't trust or use it. - "Payloads are processed in the order in which they appear in an IKE message" It isn't clear what this is meant to say. Is this only talking about parsing the message, or is something more going on? - "It is therefore possible for a single instance of IKE to multiplex distinct sessions with multiple peers." I think that each session involves only one pair of peers. The sentence suggests otherwise. 7.2 Generic Payload Header - "critical" bit should have the other sense. Unless a payload is marked "ignore if you don't understand", it should be treated as critical. This default (critical) should be represented as 0. 7.3 Security Association Payload - SA payload description is opaque. My I suggest BNF-like notation as a supplement? But not just the description is complex -- the actual structure is complex. Much more should be said about this, but I'm not yet up to speed on it. - does it make sense to combine IKE and other protocols in one SA Payload? Is that how the IKE SA's encryption and authentication is negotiated? How does the context (kind of SA being negotiated) affect the SA Proposal? 7.3.1 Proposal Substructure - "the first four bytes of the Proposal structure are designed to look somewhat like the header of a Payload" In what sense "somewhat"? Are they not identical? - Why are there two bullets about "Proposal Length"? Why are there two bullets about "Proposal #"? Why are there two bullets about "RESERVED"? 7.3.2 Transform Substructure - "For Transform Type 7 (Window Size), the Transform-ID specifies the window size a peer is contracting to support to handle overlapping requests (see section 2.3)." This seems a little ugly when every other Transform-ID is essentially an enumerated type. 7.3.4 Mandatory Transform-IDs - "Some transforms are mandatory to support" What does that mean? If they are proposed, must they be accepted (assuming nothing else is proposed)? Must they be proposed? - AES is good. With it comes a need for stronger D-H group, hash, and PRF, I think. 7.3.4 Transform Attributes - the number 7.3.4 is used twice. - "Attribute Length (2 bytes) - Length in bytes of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 bytes and the Attribute Length field is not present." This is clear, and appropriate, but a surprise is lurking. In payloads, the length includes the header. In attributes, the length excludes the header. It would be a kindness to point this out to the reader. 7.3.5 Attribute Negotiation - "implementers of this protocol SHOULD accept values which they deem to supply greater security." I think that the implementation may wish to say no to prevent overloading. I think that "SHOULD" is too strong. 7.5 Identification Payload - If Phase 2 IDs have any meaning, they probably need their own authentication. Unless they are only selector specifications, in which case they should be moved into Traffic Selector. Just what is the semantic content of a Phase 2 ID? - how does one specify a Phase 2 ID when the IPsec negotiation has been piggybacked within the Phase 1 negotiation (section 3)? - should the strings in id payloads be ASCII? UTF8? Reference an RFC about FQDNs and user@FQDNS? 7.8 Authentication Payload - "initial unprotected IKE-SA-INIT" I presume that this means the second pair if DOS avoidance happened. - is the Signature Payload representation the same as in IKEv1? Both use PKCS#1, but I'm not sure that they are using it the same way. - "using the cryptographic hash and signature algorithms chosen by the signer". If I've understood, there is a common hash, but the signature algorithms may differ because they reflect the respective public keys. 7.10.1 Notify Message Types - [about INVALID-MESSAGE-ID] "Sent when either an IKE MESSAGE-ID more that ten greater than the highest acknowledged MESSAGE-ID." Where does the magic number 10 come from? - [about ADDRESS-NOTIFICATION] "Don't understand." I don't understand this description. - [about INITIAL_CONTACT] "This notification MUST NOT be sent by an entity that may be replicated (e.g. a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time)." How can this be enforced? How can one tell if an entity may be replicated? The problem goes the other way too: it should not be sent to an entity that may be replicated. 7.11 Delete Payload - "NOTE: What's the deal with IPcomp SAs. This mechanism is probably not appropriate for deleting them!!" One example of why deleting a group makes sense. 7.13 Traffic Selector Payload - the SUBNET forms of TS are redundant: the RANGE forms can handle the same choice. I think that this redundancy adds complexity with no benefit. 8 Diffie-Hellman Groups - group 1 and DES are described as being "for historic purposes only". For use by Civil War Re-enactors? We should not have them in a yet-to-be-adopted standard. - I think that there are patents that affect support for EC2N D-H groups. This should be noted. - "nor is there anything which will dilute the strength obtained from stronger groups" I am not a cryptographer, but I think that the width of the PRF will limit the strength obtained from stronger groups. Appendix A - "Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MUST NOT be encoded as basic even if their value can fit into two bytes. NOTE: This is a change from IKEv1, where increased flexibility may have simplified the composer of messages but certainly complicated the parser." I didn't fine that it complicated my parser. The new rule is a bit awkward since I will feel compelled to enforce it. But only for v2. From owner-ipsec@lists.tislabs.com Wed Dec 12 02:00:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCA0f211717; Wed, 12 Dec 2001 02:00:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18283 Wed, 12 Dec 2001 04:20:37 -0500 (EST) Message-ID: <3C1723AD.F7D0C18C@F-Secure.com> Date: Wed, 12 Dec 2001 11:30:21 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal References: <200112112008.fBBK8vs02338@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2001 09:30:20.0367 (UTC) FILETIME=[9E0F1DF0:01C182EF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > >>>>> "Sami" == Sami Vaarala writes: > Sami> The UDP encapsulation draft assumes that IKE packets never begin with > Sami> eight zero bytes, whereas in IKEv2 the first eight bytes are the recipient > Sami> SPI (cookie) (which is potentially zero). > > Sami> Since IKEv2 also runs on port 500, this seems like a problem. > > Since that NAT people insisted on running on the same port using a terrible > hack to get around a number of imaginary problems, frankly, I think that this > is the NAT people's problem. Err.. no. "NAT people" didn't specify this encapsulation draft, at least I deny any connection to "NAT people" :). "NAT people" produced RSIP, we "IPsec people" just try to get around the NAT problems the best we can.. (I dislike dividing people into categories, but that discussion is not for this list.) > BTW: if we pick JFK, and the JFK people appear to feel strongly that they > should run on a different port than 500, all of the "use the same port" > arguments have become moot. For almost a year there has been discussion of whether to move this common IKE and ESPUDP used in the encapsulation draft to a different port than 500, this is among the authors and hasn't appeared on the list. The reason is that all the methods, given the constraints, were worse than the method used in the current draft. So what are/were the constraints? The biggest one is that IKEv1 designed to traverse NATs must start on port 500, because it has no clue whether the other end can do ESPUDP. So if IKE is then to move to another port after finding out that the peer supports ESPUDP and/or that a NAT is actually found to be present, complicates the protocol enormously. Like, consider what happens when a port is changed in the middle of an exchange and packets get lost, like in one alternative we briefly considered. The second constraint was the attempt to save bandwidth by reducing the amount of NAT keepalive packets by using one port, instead of a two port model, like I presented in my first draft a year ago. Unfortunately the constraint of not being able to change IKE causes ESPUDP traffic encapsulation to be inefficient and IKE traffic to be efficient, which is the wrong way. If we are free to consider a model for IKEv2 where the whole protocol is moved to a port that is non-500, we can devise a much better encapsulation method, which is described in the encapsulation draft under "5.2. Alternative Encapsulation Method 1 - Common Port". This also demands that all IKEv2 implementations support this method, at least as far as encapsulating IKEv2 packets themselves is concerned. There's another reason than IKEv2 swapping the cookies to use a port that is not 500. It's that many of the NAT boxes seem to attempt to do intelligent stuff for IKE, and this causes them to break when ESPUDP is flowing through them, because they get confused with 'zero cookies'. My American co-authors have more exact information about this. > > Further, I think that IKE has the right to change things with the cookie > values at any time. This is an interesting question. I also used to consider a protocol just a contract between Ari and Bob, who wish to communicate. However, there's Ned in the middle who wishes to 'do stuff' to the protocol while it is in transit. If we consider that doing NAT is a valid thing to do, are Ari and Bob free to change the protocol so that Ned's implementation fails? Ari > > You made this kludge, now lie in 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 NetBSD/notebook using, kernel hacking, security guy"); [ > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Finger me for keys > > iQCVAwUBPBZn14qHRg3pndX9AQEsxwP/TXCbRsSK/79/8V52M4c5spYxiij6koky > HGtnFFG4E/3ox3AeZxbomjRvhuTPfLzZXAxgkzRXUJCN8azlNGqbTxAryIgvbzET > EdqpwLUIrVyenaTYPDEjfXzy0kXNa0nMg3W8KmlObW0aCVmIcXRwSTkvwIPGSuYA > IZJNcHlPEGQ= > =pwYd > -----END PGP SIGNATURE----- -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Dec 12 02:06:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCA62211859; Wed, 12 Dec 2001 02:06:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18309 Wed, 12 Dec 2001 04:31:31 -0500 (EST) Message-ID: <3C17263C.7E0FC9B2@F-Secure.com> Date: Wed, 12 Dec 2001 11:41:16 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Alten CC: "Steven M. Bellovin" , andrew.krywaniuk@alcatel.com, "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: Son-of-IKE Performance References: <3.0.3.32.20011211150520.0107a570@pop3.netvista.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2001 09:41:15.0232 (UTC) FILETIME=[24639600:01C182F1] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten wrote: > > At 10:59 PM 12/7/2001 -0500, Steven M. Bellovin wrote: > >In message <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com>, > "Andrew > >Krywaniuk" writes: > >> > >>Here's a question. Have the authors of JFK given any thought to how (if?) > >>they will incorporate NAT-traversal? With IKEv2, the already completed > >>drafts from IKEv1 can be presumably carried forward. > > > >JFK doesn't rely on IP addresses at all -- it can pass through NATs > >just fine. > > > > Wow! Now I am interested in reading the draft. Since IP addresses are so > ephemeral and insecure this, if designed correctly, would be a fundamental > step forward. IKEv1 also goes through NATs just fine when you don't use IP address based identities; it's ESP and AH that don't. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Dec 12 06:02:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCE2C202983; Wed, 12 Dec 2001 06:02:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18814 Wed, 12 Dec 2001 08:10:53 -0500 (EST) Message-Id: <200112120111.fBC1BHKo030085@coredump.cs.columbia.edu> To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: Re: suggestion for JFK In-reply-to: Your message of "Tue, 11 Dec 2001 17:07:20 PST." <20011212010720.1156E54C59@tailor.sailpix.com> Date: Tue, 11 Dec 2001 20:11:17 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20011212010720.1156E54C59@tailor.sailpix.com>, Dan Harkins writes: > > Your case (c) was what I was suggesting-- if decryption fails then do >not process anymore packets with that token. I'm not saying that a >well-written JFK implementation would crash or peg a CPU or whatever, >just that in the event of an attack it would be a benefit to know where >that attack is coming from. True, this would be architecturally impure, >but I'd swap cleanliness for some added information to send to syslog >in the event of an attack. Ah, I misunderstood what you said then. Except that adding the IP in the HMAC doesn't help you in getting more information for syslog purposes --- you can verify that you didn't give the HMAC to the IP address that it claims it came from, but you don't know who you gave it to (unless you keep state after Msg 1). As for the NAT case, s/NAT/mobility or SCTP or multi-homed hosts or... -Angelos From owner-ipsec@lists.tislabs.com Wed Dec 12 06:04:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCE45203292; Wed, 12 Dec 2001 06:04:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18808 Wed, 12 Dec 2001 08:10:01 -0500 (EST) To: "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: Re: suggestion for JFK In-Reply-To: Your message of "Tue, 11 Dec 2001 18:46:04 EST." <200112112346.fBBNk405011681@nyarlathotep.keromytis.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3539.1008119240.1@SailPix.com> Date: Tue, 11 Dec 2001 17:07:20 -0800 From: Dan Harkins Message-Id: <20011212010720.1156E54C59@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk NAT wouldn't break because the IP address included in the calculation would be that of the NAT box the initiator is behind. Your case (c) was what I was suggesting-- if decryption fails then do not process anymore packets with that token. I'm not saying that a well-written JFK implementation would crash or peg a CPU or whatever, just that in the event of an attack it would be a benefit to know where that attack is coming from. True, this would be architecturally impure, but I'd swap cleanliness for some added information to send to syslog in the event of an attack. Dan. On Tue, 11 Dec 2001 18:46:04 EST you wrote > > In message <20011211224904.B94E354C48@tailor.sailpix.com>, dharkins@tibernian >.c > om writes: > >address. > > > > The responder should rate limit these messages, of course, and could > >scan an input queue for the bad token to eliminate these bogus packets > >before any serious work is done on them but there is no way to locate the > >offender. > > > > If the IP address of the initiator that sent message 1 was included > >in the token calculation-- i.e. HMAC{Hkr}(Ni, Nr, g^i, g^r, addr)-- it > >would force such an attacker to reveal his IP address. I think this would > >be a good thing. > > Except that: > a) this would break in the presence of things like NAT boxes > b) it's architecturally "unclean" (there's no other place in the protocol > where addresses are used) > > Now, there are 3 cases with lots-and-lots of message 3's: > a) The HMAC is not valid --- in which case, they'll be dropped immediately > upon computing the HMAC. > > b) They are all valid (both the HMAC and the contents); in that case, the > Responder will do the work for the first one (after all, it's a valid > message), and return that for the rest of them. > Further rate-limiting may be added at your pleasure. > > c) If the HMAC is valid, but the rest of the message is not (e.g., the certs > don't verify, or the encryption is garbage, etc.), then the responder > "blacklists" the HMAC value (not the IP address); on receiving a new > message 3, the HMAC is looked-up; if it matches, the message is dropped. > If it passes the lookup (i.e., it's not found in the black list), the HMAC > is verified; if it passes *that*, you go on processing the message. > > One can use a Patricia Trie do do this, which has a cost of O(w) --- where > w is the length of the key in bits (in the case of HMAC, 96) --- regardles >s > of the number of entries. Of course, the more entries in the blacklist, th >e > more memory expended. However, the blacklist can be wiped out when HKr is > changed (which the Responder can do whenever he chooses). > > One cannot blacklist IP addresses in the same manner, because that will allow > an attacker to deny JFK service to any IP address of his or her choosing (get > a > valid HMAC, then send a spoofed packet from victim-IP and voila -- victim-IP >is > blacklisted at the Responder). > -Angelos > > From owner-ipsec@lists.tislabs.com Wed Dec 12 06:04:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCE4v203443; Wed, 12 Dec 2001 06:04:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18921 Wed, 12 Dec 2001 08:16:01 -0500 (EST) Date: Wed, 12 Dec 2001 15:26:14 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'IPsec WG'" Subject: RE: IKEv2 and SIGMA In-Reply-To: <000a01c182bb$4b4bd240$2dc6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, I am glad you keep insisting in understanding this, and I am sorry for not being clear. Below is another try > > > BTW, Hugo, you never explained why it was essential for > > IKEv2 to sign the > > > identity and I can't see any justification for this > > requirement. Is this > > > because: > > > > > > a) It has not been proven secure not to sign the identity? > > > b) It has been proven insecure not to sign the identity? > > > > It has been proven INSECURE not to MAC the identity. If you sign the > > identity but do not include a MAC the protocol is insecure. > > This uses a > > 10+ year (simple but non-obvious) attack discovered by Diffie, van > > Oorschot and Wiener, and a main motivation behind SIGMA's (and IKE) > > design. > > When I said "sign the identity", what I really meant was "include the > identity in the data which is signed." *Of course* you MAC it first. But in > in IKEv2, you only MAC the identity; in SIGMA, you MAC the identity and then > sign it. I repeat: the "essential" thing is to have the ID under the MAC. I did not say, and never said before that it is a must to have the ID or MAC under the signature! > > Let's try this again... > > You never explained why it was essential for IKEv2 to *sign* the MAC of the > identity and I can't see any justification for this requirement. Is this Indeed, I never explained why signing the MAC of the identity is essential. You know why? Because it is NOT. (And I never said it was.) The only ESSENTIAL thing is that the MAC be applied to the identity! And yes, I put the MAC under the signature in IKE for convenience (both space saving and uniformity of HASH derivation for the different authentication modes). I still find it more convenient to do so in the context of SIGMA and IKEv2: for example, to allow the use of ESP mechanisms for the SOLE purpose of identity protection (rather than for key exchange authenttication as currently specified in IKEv2-00 draft.) But as I recently said in the discussions concerning the SIGMA-4 proposal (2 RTs with built-in DoS and defense of responder's identity against active attacks), it is ok with me to put the MAC outside. Just make sure you cover the ID of the sender with the MAC (regardless of whether we provide identity protection or which message in the protocol transports the ID) > because: > > a) It has not been proven secure not to sign the MAC of the identity? > b) It has been proven insecure not to sign the MAC of the identity? > c) It saves space to put just a signature in message 3 instead of a > signature and a MAC. > > Answering (c) would be a cop-out, since that wouldn't be "essential for > security"... Please read again my answer to you in the previous message and the above (re-iterated) statements: the security requirement is "MAC the ID", whether the MAC goes under the signature or outside is immaterial for provable security. It may make a difference for bandwidth and for other design issues (e.g. re-use of ESP for identity protection, robustness of the security to future changes such as optional ID protection, etc), but NOT to the core security of the key exchange. Hugo PS: It may help to pay attention to the following (at least for mnemonics): SIGMA stands for SIGN-and-MAC; it does NOT stand for SIGN-the-MAC. ^^^ ^^^ ^^^ > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > From owner-ipsec@lists.tislabs.com Wed Dec 12 06:05:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCE5t203602; Wed, 12 Dec 2001 06:05:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18915 Wed, 12 Dec 2001 08:15:46 -0500 (EST) Date: Wed, 12 Dec 2001 15:25:57 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'IPsec WG'" Subject: RE: Some comments to draft-ietf-ipsec-ikev2-00.txt In-Reply-To: <000901c182bb$48f7f730$2dc6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Two comments on your questions at the end: 1) I repea Dave Wagner's accurate answer: Why is this a problem? Are you worried about 2^160 work attacks? 2) Note that other mechanisms based on HMAC to derive keys from g^xy (in particular, as done in JFK) present the same issue. That is, when you perform HMAC-SHA1{g^xy}(...) what happens is that g^xy is FIRST hashed via SHA-1 [1] and this hashed value is then used as the actual key to HMAC. This is the case IF g^xy is longer than the hash output which is the common case. [1] See section 3 of RFC 2104. In particular: The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength. (A longer key may be advisable if the randomness of the key is considered weak.) Hugo PS: the above paragraph about the pre-hashing of long keys in HMAC also gives you a partial answer on your other question about what's the benefit of using nonces that are longer than the hash output size: while the extra length is not strictly needed, and can even be considered a "waste" if the nonce bits are TRULY random, the extra length may potentially help in the typical case that these bits are generated out of a weaker source of (pseudo) randomness. On Tue, 11 Dec 2001, Andrew Krywaniuk wrote: > > As a general pricniple, > > if you have two keys k and k' where k' was derived from k > > then applying prf(k', k) (here k' is the key to the prf and k > > the input) > > may be insecure even if prf is an excelent pseudorandom > > function family > > Okay, I believe you. > > But both of these issues deal with key stretching, although in one case the > input is public information and in one case the input is private > information. > > If SKEYSEED = prf(Ni | Nr, g^ir) and we use the generic stretching algorithm > then it does no good to make Ni and Nr any bigger than the output of the > hash. If that is the case then many of us ought to be changing our code to > use smaller nonces, since large nonces are merely wasting entropy and > bandwidth. (And the draft ought to talk about how to choose an appropriate > length nonce.) > > > In the case of: > > K1 = prf(SKEYSEED_e, 0) > K2 = prf(SKEYSEED_e, K1) > K3 = prf(SKEYSEED_e, K2) > > The problem is that no matter how large you make your DH exponent, the > entropy in your key(s) is limited by the output of your hash. This was > brought up a couple of times in reference to IKEv1 and I had assumed that we > would be fixing it in IKEv2. Isn't there a way to get around this problem, > or do we all need to go and implement SHA-2 solely for the purpose of key > stretching? > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > From owner-ipsec@lists.tislabs.com Wed Dec 12 06:23:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCENt204771; Wed, 12 Dec 2001 06:23:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18807 Wed, 12 Dec 2001 08:09:56 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal Organization: SSH Communications Security From: Markus Stenberg Date: 12 Dec 2001 01:39:26 +0200 Message-ID: <87d71lba35.fsf@porsas.hel.fi.ssh.com> Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA16899 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk mcr@sandelman.ottawa.on.ca (Michael Richardson) writes: > >>>>> "Sami" == Sami Vaarala writes: > Sami> The UDP encapsulation draft assumes that IKE packets never begin with > Sami> eight zero bytes, whereas in IKEv2 the first eight bytes are the recipient > Sami> SPI (cookie) (which is potentially zero). > > Sami> Since IKEv2 also runs on port 500, this seems like a problem. > Since that NAT people insisted on running on the same port using a > terrible hack to get around a number of imaginary problems, frankly, I > think that this is the NAT people's problem. I'm tired of reiterating same stupid arguments over and over. See draft-ietf-ipsec-udp-encaps-justification-00.txt section 7.2. > BTW: if we pick JFK, and the JFK people appear to feel strongly that they > should run on a different port than 500, all of the "use the same port" > arguments have become moot. No. See above. > Further, I think that IKE has the right to change things with the cookie > values at any time. > > You made this kludge, now lie in it. NAT-traversing IPsec is IETF-sancioned kludge to deal with another IETF-sanctioned kludge (NATs). I'd find the world a lot happier place without NATs. However, I find it likely that IPsec is the one to die if it doesn't live with NATs, and not the NATs, regrettably. > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) Chief Engineer / SSH $B0O8k@h@8(B From owner-ipsec@lists.tislabs.com Wed Dec 12 07:07:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCF79208111; Wed, 12 Dec 2001 07:07:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18806 Wed, 12 Dec 2001 08:09:56 -0500 (EST) Message-Id: <200112112346.fBBNk405011681@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: dharkins@tibernian.com Cc: ipsec@lists.tislabs.com Subject: Re: suggestion for JFK In-reply-to: Your message of "Tue, 11 Dec 2001 14:49:04 PST." <20011211224904.B94E354C48@tailor.sailpix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Dec 2001 18:46:04 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20011211224904.B94E354C48@tailor.sailpix.com>, dharkins@tibernian.c om writes: >address. > > The responder should rate limit these messages, of course, and could >scan an input queue for the bad token to eliminate these bogus packets >before any serious work is done on them but there is no way to locate the >offender. > > If the IP address of the initiator that sent message 1 was included >in the token calculation-- i.e. HMAC{Hkr}(Ni, Nr, g^i, g^r, addr)-- it >would force such an attacker to reveal his IP address. I think this would >be a good thing. Except that: a) this would break in the presence of things like NAT boxes b) it's architecturally "unclean" (there's no other place in the protocol where addresses are used) Now, there are 3 cases with lots-and-lots of message 3's: a) The HMAC is not valid --- in which case, they'll be dropped immediately upon computing the HMAC. b) They are all valid (both the HMAC and the contents); in that case, the Responder will do the work for the first one (after all, it's a valid message), and return that for the rest of them. Further rate-limiting may be added at your pleasure. c) If the HMAC is valid, but the rest of the message is not (e.g., the certs don't verify, or the encryption is garbage, etc.), then the responder "blacklists" the HMAC value (not the IP address); on receiving a new message 3, the HMAC is looked-up; if it matches, the message is dropped. If it passes the lookup (i.e., it's not found in the black list), the HMAC is verified; if it passes *that*, you go on processing the message. One can use a Patricia Trie do do this, which has a cost of O(w) --- where w is the length of the key in bits (in the case of HMAC, 96) --- regardless of the number of entries. Of course, the more entries in the blacklist, the more memory expended. However, the blacklist can be wiped out when HKr is changed (which the Responder can do whenever he chooses). One cannot blacklist IP addresses in the same manner, because that will allow an attacker to deny JFK service to any IP address of his or her choosing (get a valid HMAC, then send a spoofed packet from victim-IP and voila -- victim-IP is blacklisted at the Responder). -Angelos From owner-ipsec@lists.tislabs.com Wed Dec 12 07:09:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCF93208153; Wed, 12 Dec 2001 07:09:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18992 Wed, 12 Dec 2001 08:25:46 -0500 (EST) Date: Wed, 12 Dec 2001 15:36:08 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: compare-jfk-sigma.txt In-Reply-To: <000c01c182bd$7f8e8140$2dc6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 11 Dec 2001, Andrew Krywaniuk wrote: > > BTW, there is another reason not to go for a "sign message 1 > > and message > > 2" as in IKEv2: if you do that then the security of the > > protocol depends > > on what exactly you sent in these messages. > > When it says "sign messages 1&2" in IKEv2, I would hazzard a guess that this > only applies when you are not using stateless DoS protection. When you are > using stateless DoS protection then you sign messages 3&4 instead. This is correct for IKEv2. But Angelos correct observation, to which I added the above, was in the context of a protocol that does not have an optional round of DoS protection but rather includes this protection already in the 4-message protocol. Hugo > > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > From owner-ipsec@lists.tislabs.com Wed Dec 12 08:34:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCGYX216777; Wed, 12 Dec 2001 08:34:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19351 Wed, 12 Dec 2001 10:33:28 -0500 (EST) Date: Wed, 12 Dec 2001 10:42:36 -0500 (EST) From: Henry Spencer To: Markus Stenberg cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal In-Reply-To: <87d71lba35.fsf@porsas.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 12 Dec 2001, Markus Stenberg wrote: > > Since that NAT people insisted on running on the same port using a > > terrible hack to get around a number of imaginary problems, frankly, I > > think that this is the NAT people's problem. > > I'm tired of reiterating same stupid arguments over and over. See > draft-ietf-ipsec-udp-encaps-justification-00.txt section 7.2. Perhaps you need to come up with some non-stupid arguments, because section 7.2 is pretty feeble justification for such a gut-wrenchingly bad design. (I distinguish here between the requirement and the proposed solution. NAT traversal, although somewhat distasteful, is defensible. Committing unspeakable acts on an existing port in the name of NAT traversal is not.) Speaking as an implementor, I would much rather solve the problems noted in section 8.4 than the ones perpetrated in section 7.2. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 12 10:35:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCIZY224878; Wed, 12 Dec 2001 10:35:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19536 Wed, 12 Dec 2001 12:34:19 -0500 (EST) Date: Wed, 12 Dec 2001 12:43:36 -0500 (EST) From: Henry Spencer To: Ari Huttunen cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal In-Reply-To: <3C1723AD.F7D0C18C@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Dec 2001, Ari Huttunen wrote: > The second constraint was the attempt to save bandwidth by reducing the amount > of NAT keepalive packets by using one port, instead of a two port model, like > I presented in my first draft a year ago... I'm puzzled by why an optimization attempt -- in my opinion, a severely misguided one -- is considered a "constraint". Was there some requirement on the design which absolutely precluded the extra keepalive traffic? If not, then this is *not* a constraint, but merely a preference, which can and should be sacrificed if it causes more trouble than it's worth (which it does). > > Further, I think that IKE has the right to change things with the cookie > > values at any time. > > This is an interesting question. I also used to consider a protocol just > a contract between Ari and Bob, who wish to communicate. However, there's > Ned in the middle who wishes to 'do stuff' to the protocol while it is > in transit. If we consider that doing NAT is a valid thing to do, are > Ari and Bob free to change the protocol so that Ned's implementation fails? It depends on whether Ned's implementation is relying on undocumented -- and thus *not* promised by contract -- aspects of the protocol. Nobody has ever promised that the first four bytes of packets from IKE *and* all successors to it will be non-zero. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 12 10:54:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCIsb225659; Wed, 12 Dec 2001 10:54:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19671 Wed, 12 Dec 2001 13:09:28 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Wed, 12 Dec 2001 20:16:52 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: Henry Spencer cc: Markus Stenberg , ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal 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, 12 Dec 2001, Henry Spencer wrote: > On 12 Dec 2001, Markus Stenberg wrote: > > > Since that NAT people insisted on running on the same port using a > > > terrible hack to get around a number of imaginary problems, frankly, I > > > think that this is the NAT people's problem. > > > > I'm tired of reiterating same stupid arguments over and over. See > > draft-ietf-ipsec-udp-encaps-justification-00.txt section 7.2. > > Perhaps you need to come up with some non-stupid arguments, because > section 7.2 is pretty feeble justification for such a gut-wrenchingly bad > design. Without going into the question of whether the current traversal draft should go forward as is, could one of the ikev2 authors comment on this? Is there a specific reason why IKEv2 *needs* to break the current traversal draft? I don't see a reason myself; why not swap the order of the cookie (SPI) fields? (It is actually more common to have the sender SPI/cookie/port first anyway.) -Sami From owner-ipsec@lists.tislabs.com Wed Dec 12 11:10:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCJAZ226443; Wed, 12 Dec 2001 11:10:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19714 Wed, 12 Dec 2001 13:28:04 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt In-Reply-To: Your message of "Mon, 19 Nov 2001 08:29:07 -0500" <200111191329.IAA26802@ietf.org> References: <200111191329.IAA26802@ietf.org> X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011213033745S.sakane@kame.net> Date: Thu, 13 Dec 2001 03:37:45 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Title : The HMAC-SHA-256-96 Algorithm and Its Use With IPsec > Author(s) : S. Frankel, S. Kelly > Filename : draft-ietf-ipsec-ciph-sha-256-00.txt > Pages : 8 > Date : 16-Nov-01 the section 5 in RFC2104 says, We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker). is that ok to truncate into 96bit ? From owner-ipsec@lists.tislabs.com Wed Dec 12 11:48:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCJmG228749; Wed, 12 Dec 2001 11:48:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19825 Wed, 12 Dec 2001 14:08:00 -0500 (EST) Message-Id: <200112121655.fBCGtNfe017705@coredump.cs.columbia.edu> To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: Re: suggestion for JFK In-reply-to: Your message of "Wed, 12 Dec 2001 08:40:27 PST." <20011212164027.0558C54C42@tailor.sailpix.com> Date: Wed, 12 Dec 2001 11:55:23 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20011212164027.0558C54C42@tailor.sailpix.com>, Dan Harkins writes: > >the token. Only if the two match do you try to decrypt the following >encrypted data. This check has to be done regardless, right? Correct. >If the addresss is included and token is corrrect but the encrypted data >is garbage you will know who sent you the garbage. If you don't include >the IP address all you know is you got garbage. For clarification: The attack scenario you described in the first email was that a valid HMAC would be used from a large number of other IP addresses; if the IP address is included in the HMAC cookie, and since the address does not appear inside the protocol explicitly (as the nonces and exponentials do), the Responder would only be able to tell that the HMAC was not given to that IP address. You still don't know who you gave it to originally (unless state is kept). Logging the false IP is not very useful, especially if you're under a DDoS (you then introduce another DDoS, on your logging facility). If you include the IP address as a protocol payload, then you can tell who you gave the cookie to (you could encode the address as part of the cookie, to avoid extra payloads). Otherwise, hashing the IP address along with the rest only helps you to detect entities that use their own IP address to send you malformed message 3's (with valid HMACs). In any case, I think we're beating a dead horse here. >> As for the NAT case, s/NAT/mobility or SCTP or multi-homed hosts or... > >JFK will be creating an outbound IPsec SA to that IP address anyway. >Why does binding that IP address to the exchange that created the key >break things? This is equivalent to some implementations' fallacious source-IP address checking for incoming ESP packets -- it unnecessarily binds the SA (in this case, the exchange) to one particular IP address which breaks mobility (and perhaps other things too). All you really care about is whether the peer knows the shared key (in JFK, all you really care about is whether they know the cookie). As for the IPsec SAs, they may well be bound to different/more IP addresses (again, think SCTP). -Angelos From owner-ipsec@lists.tislabs.com Wed Dec 12 11:55:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCJt9229609; Wed, 12 Dec 2001 11:55:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19860 Wed, 12 Dec 2001 14:09:01 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal References: Organization: SSH Communications Security From: Markus Stenberg Date: 12 Dec 2001 20:12:18 +0200 In-Reply-To: Message-ID: <87667c9ukd.fsf@porsas.hel.fi.ssh.com> Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA19629 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk henry@spsystems.net (Henry Spencer) writes: > On 12 Dec 2001, Markus Stenberg wrote: > > > Since that NAT people insisted on running on the same port using a > > > terrible hack to get around a number of imaginary problems, frankly, I > > > think that this is the NAT people's problem. > > > > I'm tired of reiterating same stupid arguments over and over. See > > draft-ietf-ipsec-udp-encaps-justification-00.txt section 7.2. > Perhaps you need to come up with some non-stupid arguments, because > section 7.2 is pretty feeble justification for such a gut-wrenchingly bad > design. It minimizes complexity, which is important consideration. > (I distinguish here between the requirement and the proposed solution. > NAT traversal, although somewhat distasteful, is defensible. Committing > unspeakable acts on an existing port in the name of NAT traversal is not.) > > Speaking as an implementor, I would much rather solve the problems noted > in section 8.4 than the ones perpetrated in section 7.2. Don't hesitate to send your own draft if you have solutions to those. The current one's conclusion of maybe two years of collaboration between multiple companies' people, and there HAS been thought on the 8.4 also. I'd like to find the perfect solution also, which wouldn't need any overhead, complexity or anything else either; this involves assassinating few NAT people/vendors, though. (Or the 'second coming of ', aka total IPv6) > Henry Spencer > henry@spsystems.net -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) Chief Engineer / SSH $B0O8k@h@8(B From owner-ipsec@lists.tislabs.com Wed Dec 12 11:56:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCJuC229649; Wed, 12 Dec 2001 11:56:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19818 Wed, 12 Dec 2001 14:07:01 -0500 (EST) To: "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: Re: suggestion for JFK In-Reply-To: Your message of "Tue, 11 Dec 2001 20:11:17 EST." <200112120111.fBC1BHKo030085@coredump.cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8781.1008175226.1@SailPix.com> Date: Wed, 12 Dec 2001 08:40:27 -0800 From: Dan Harkins Message-Id: <20011212164027.0558C54C42@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Except that adding the IP in the HMAC doesn't help you in getting more > information for syslog purposes --- you can verify that you didn't > give the HMAC to the IP address that it claims it came from, but you > don't know who you gave it to (unless you keep state after Msg 1). Upon receipt of message 3 the token has to be checked for correctness. That is, upon receipt of message 3 the nonces and exponentials are run through the HMAC keyed with HKr and the result is checked against the token. Only if the two match do you try to decrypt the following encrypted data. This check has to be done regardless, right? If the addresss is included and token is corrrect but the encrypted data is garbage you will know who sent you the garbage. If you don't include the IP address all you know is you got garbage. You don't need to keep any state after message 1. > As for the NAT case, s/NAT/mobility or SCTP or multi-homed hosts or... JFK will be creating an outbound IPsec SA to that IP address anyway. Why does binding that IP address to the exchange that created the key break things? Dan. From owner-ipsec@lists.tislabs.com Wed Dec 12 12:38:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCKcg202354; Wed, 12 Dec 2001 12:38:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19983 Wed, 12 Dec 2001 14:54:33 -0500 (EST) Message-Id: <200112121952.fBCJqa509314@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal In-reply-to: Your message of "Wed, 12 Dec 2001 11:30:21 +0200." <3C1723AD.F7D0C18C@F-Secure.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Dec 2001 12:52:35 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ari" == Ari Huttunen writes: Ari> For almost a year there has been discussion of whether to move this common Ari> IKE and ESPUDP used in the encapsulation draft to a different port than 500, I do not dispute that IKE must stay on port 500. But, if JFK does not also run on port 500, then you have PRECISELY the same problem that ESPUDP had with running NAT-IKE and/or ESPUDP on a different port. Ari> The second constraint was the attempt to save bandwidth by reducing the amount Ari> of NAT keepalive packets by using one port, instead of a two port model, like Ari> I presented in my first draft a year ago. Unfortunately the constraint of not So, if you solve the JFK is on a different port and you need to try both IKEv1 and JFK and figure out also if you have NAT in the way, then you still have this two-port problem and restarting stuff. Of course, JFK with no phase 1 to keepalive can just let the NAT time out on that. If the answer is "of course you know by policy whether to use JFK or IKEv2", then I would ask why your policy doesn't tell you lots of other things, like if you have NAT or not. The pre-arrangement argument only applies to road warrior scenarios. Ari> There's another reason than IKEv2 swapping the cookies to use a port that is Ari> not 500. It's that many of the NAT boxes seem to attempt to do intelligent Ari> stuff for IKE, and this causes them to break when ESPUDP is flowing through them, Ari> because they get confused with 'zero cookies'. My American co-authors have more Ari> exact information about this. What a hoot! The NATs are screwing up kludge used by ESPUDP! That wouldn't happen if the data was kept seperate. Kludges are kludges are kludges. As the ESPUDP drafts are not RFCs yet, I also accept that it has been "IETF sanctioned" yet. Ari> This is an interesting question. I also used to consider a protocol just Ari> a contract between Ari and Bob, who wish to communicate. However, there's Ari> Ned in the middle who wishes to 'do stuff' to the protocol while it is Ari> in transit. If we consider that doing NAT is a valid thing to do, are Ari> Ari and Bob free to change the protocol so that Ned's implementation fails? End-to-end model arguments applies. Good protocol design arguments applies. This is just another reason to get ESPUDP off of port 500. (And to get JFK onto port 500, even if the HDR is totally phony) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBe1goqHRg3pndX9AQEC2QQAkizaMokJ6tBoOOP7pPTmM9sgzYVQAm8D CELGvLpwchjhbc772q5ua39HckIbcpR1j/zVmjfXqiRdi6tOUZLtCL33KimlpN0E CopPK6BrCyPCJK62IZNBatxxdPfuDRDlLHB+NXmVwerg927PqmZlCfclZCI7/0TY kx5sJXCRs/E= =ItYQ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 12 12:44:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCKi0203025; Wed, 12 Dec 2001 12:44:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20042 Wed, 12 Dec 2001 15:04:14 -0500 (EST) Message-Id: <200112122002.fBCK2HH09409@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: suggestion for JFK In-reply-to: Your message of "Tue, 11 Dec 2001 17:07:20 PST." <20011212010720.1156E54C59@tailor.sailpix.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Dec 2001 13:02:17 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan Harkins writes: Dan> NAT wouldn't break because the IP address included in the calculation Dan> would be that of the NAT box the initiator is behind. If I understand the suggestion, you are both right :-) For the case where the initiator is behind the NAT, things work fine, as the responder knows the address on the outside, while the initiator does not. But, the initiator is not asked to check the HMAC{HKr} calculation (he can't), just echo it. The responder, as I understand things, is going to use info replicated in message #3 to recalculate this value and check that the initiator echoed the right info. As I understand Dan's suggestion, including the IP address means that the initiator can't bounce around to different IPs - I don't get what it buys though. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBe3x4qHRg3pndX9AQHTOwP+P9TIyFrDSIlfTbxBmhlsQ6Z2xqtl1NLM WjE4HuS2Zn+okHTVqvbcwWOtXwFjTh2nQ1VYJIVp1WrXrn6SJVVwyP9vwyrLvjDh YzebkRCOlNSuYd2jLiU9S+tANnKjT086orpWwus3yJEy++Ol4XZ2kty+B5ugcq// V+5/nb+ahfI= =IBCc -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 12 13:08:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCL8U205012; Wed, 12 Dec 2001 13:08:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20113 Wed, 12 Dec 2001 15:23:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15383.48863.893728.721499@pkoning.dev.equallogic.com> Date: Wed, 12 Dec 2001 15:32:31 -0500 (EST) From: Paul Koning To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt References: <200111191329.IAA26802@ietf.org> <20011213033745S.sakane@kame.net> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Shoichi" == Shoichi Sakane writes: >> Title : The HMAC-SHA-256-96 Algorithm and Its Use With IPsec >> Author(s) : S. Frankel, S. Kelly Filename : >> draft-ietf-ipsec-ciph-sha-256-00.txt Pages : 8 Date : 16-Nov-01 Shoichi> the section 5 in RFC2104 says, > We recommend that the output length t be not less than half > the length of the hash output (to match the birthday attack > bound) and not less than 80 bits (a suitable lower bound on > the number of bits that need to be predicted by an > attacker). Shoichi> is that ok to truncate into 96bit ? Applying the text from 2104 says "no" and the length should instead be 128 or more. Which makes me wonder: why was 96 chosen for the original 2 HMACs and not 80? 80 would be the minimum value that satisfies the guideline from RFC 2104. Should therefore the SHA-2 based HMAC use a length greater than 128 bits? paul From owner-ipsec@lists.tislabs.com Wed Dec 12 13:45:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCLjj206895; Wed, 12 Dec 2001 13:45:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20252 Wed, 12 Dec 2001 16:06:46 -0500 (EST) Message-Id: <3.0.3.32.20011212131833.0116dd18@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 12 Dec 2001 13:18:33 -0800 To: Ari Huttunen From: Alex Alten Subject: Re: Son-of-IKE Performance Cc: "Steven M. Bellovin" , andrew.krywaniuk@alcatel.com, "'Dan Harkins'" , ipsec@lists.tislabs.com In-Reply-To: <3C17263C.7E0FC9B2@F-Secure.com> References: <3.0.3.32.20011211150520.0107a570@pop3.netvista.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:41 AM 12/12/2001 +0200, Ari Huttunen wrote: >Alex Alten wrote: >> >> At 10:59 PM 12/7/2001 -0500, Steven M. Bellovin wrote: >> >In message <001a01c17f9b$6d251610$1e72788a@andrewk3.ca.newbridge.com>, >> "Andrew >> >Krywaniuk" writes: >> >> >> >>Here's a question. Have the authors of JFK given any thought to how (if?) >> >>they will incorporate NAT-traversal? With IKEv2, the already completed >> >>drafts from IKEv1 can be presumably carried forward. >> > >> >JFK doesn't rely on IP addresses at all -- it can pass through NATs >> >just fine. >> > >> >> Wow! Now I am interested in reading the draft. Since IP addresses are so >> ephemeral and insecure this, if designed correctly, would be a fundamental >> step forward. > >IKEv1 also goes through NATs just fine when you don't use IP address based >identities; it's ESP and AH that don't. > RATS! I forgot about them. - Alex > > -- Alex Alten Alten@NetVista.Com From owner-ipsec@lists.tislabs.com Wed Dec 12 14:13:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMDv207927; Wed, 12 Dec 2001 14:13:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20369 Wed, 12 Dec 2001 16:26:15 -0500 (EST) Message-Id: <3.0.3.32.20011212133807.0116dd18@pop3.netvista.net> X-Sender: alten@pop3.netvista.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 12 Dec 2001 13:38:07 -0800 To: Markus Stenberg , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: IKEv2 and NAT traversal Cc: nat@ietf.org In-Reply-To: <87d71lba35.fsf@porsas.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >I'd find the world a lot happier place without NATs. However, I find it >likely that IPsec is the one to die if it doesn't live with NATs, and not >the NATs, regrettably. > That's because from a customer perspective IPsec is component to a solution not a solution in and of itself. By comparison NAT is a solution to the problem of a dwindling set of IPv4 addresses, so it will always be a more important technology than IPsec in customers minds. BTW, although IPv6 is a more "pure" way to solve the address space problem, certainly NAT is a good, practical solution. By knowing the context of the in-flight packet (either in the sender's or receiver private net or out on the public Internet), it allows the effective address space to expand and yet preserves backwards compatability with the legacy public IPv4 address space. I actually really like its elegant tradeoffs. This is what good engineering is all about, preserving the old customers capital investment yet finding an effective away to scale the technology to allow new customers to use it. My hat's off to the NAT WG. - Alex -- Alex Alten Alten@NetVista.Com From owner-ipsec@lists.tislabs.com Wed Dec 12 14:35:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMZ7209819; Wed, 12 Dec 2001 14:35:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20473 Wed, 12 Dec 2001 16:52:52 -0500 (EST) Date: Wed, 12 Dec 2001 23:02:09 +0100 (MET) From: Bart Preneel To: Paul Koning cc: Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt In-Reply-To: <15383.48863.893728.721499@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 There are 2 conflicting concerns here: 1. having a longer MAC implies that each MAC leaks more information on the MAC key (in an information theoretic sense, but for some weaker MAC functions such information can be exploited - there are no indications that this is the case for HMAC, but it never hurts to be careful). 2. having a shorter MAC means that the MAC string may be easier to predict for a given message (for example, it may be that one can predict the first 80 bits of a MAC easily, but not the full 128 bits). Personally I believe that the first concern is more important, as it deals with key leakage while the second concern is about forging a single MAC. The "optimal" choice from this viewpoint (based on birthday attacks) is that the size of the MAC should be exactly half the size of the hash function output, and that the size of the key should be the size of the hash output. This would lead to choosing a 128-bit output for SHA-256. For obvious reasons, it does not make sense to choose a MAC length longer than the key (the opponent just guesses the key rather than the MAC value). If I remember correctly, 96 bits was chosen over 80 bits because of word alignment issues (and because some people worried more about concern 2). For choosing MAC parameters, one has to take into account the lifetime during which the system will be used (rather than the lifetime of a single key). I believe that 80-bit MACs are sufficient for 20 years or more. A MAC of 96 bits may be chosen for the alignment reasons mentioned above. A MAC of 128 bits is fine but probably too conservative; anything larger is certainly overkill and may even harm security in the long run. Bart Preneel On Wed, 12 Dec 2001, Paul Koning wrote: > >>>>> "Shoichi" == Shoichi Sakane writes: > > >> Title : The HMAC-SHA-256-96 Algorithm and Its Use With IPsec > >> Author(s) : S. Frankel, S. Kelly Filename : > >> draft-ietf-ipsec-ciph-sha-256-00.txt Pages : 8 Date : 16-Nov-01 > > Shoichi> the section 5 in RFC2104 says, > > > We recommend that the output length t be not less than half > > the length of the hash output (to match the birthday attack > > bound) and not less than 80 bits (a suitable lower bound on > > the number of bits that need to be predicted by an > > attacker). > > Shoichi> is that ok to truncate into 96bit ? > > Applying the text from 2104 says "no" and the length should instead be > 128 or more. > > Which makes me wonder: why was 96 chosen for the original 2 HMACs and > not 80? 80 would be the minimum value that satisfies the guideline > from RFC 2104. Should therefore the SHA-2 based HMAC use a length > greater than 128 bits? > > paul > From owner-ipsec@lists.tislabs.com Wed Dec 12 14:36:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMap210091; Wed, 12 Dec 2001 14:36:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20437 Wed, 12 Dec 2001 16:49:43 -0500 (EST) Message-Id: <200112122051.fBCKplj10053@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal In-reply-to: Your message of "Wed, 12 Dec 2001 12:52:35 MST." <200112121952.fBCJqa509314@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Dec 2001 13:51:46 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- {my appologies for typing too fast and not proofing enough} >>>>> "Michael" == Michael Richardson writes: Michael> So, if you solve the JFK is on a different port and you need to try both ^problem^ Michael> As the ESPUDP drafts are not RFCs yet, I also accept that it Michael> has been "IETF sanctioned" yet. I do *not* accept that this kludge has IETF sanction yet. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBfDYIqHRg3pndX9AQF5BAP/VEsGEpDOw8pmJAEi5Pd9YjWSZqDHFPqV PCFFYkzDymScVTsPCQFtR8olWOM0mqiTowumHHSOUM/O2JSm0SOvxc82XIjnjceI niAe7iLUP2Gq6AsJ034Yv0Ut2PP0LhfDLTBGEaPriqMrfZxi8UKMg/ycdk0dafzJ ftQtrMgBooQ= =+aOx -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 12 14:44:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMiv211260; Wed, 12 Dec 2001 14:44:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20512 Wed, 12 Dec 2001 17:07:05 -0500 (EST) Message-Id: <200112122205.fBCM50P00660@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: JFK, IKEv2 and ESPUDP Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Dec 2001 15:04:58 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I was going to ask: "if we adopt JFK do we need a new ESPUDP draft?" Before I could post that message I talked to Angelos. Within the realm of JFK, Angelos said, "run it (JFK) on port 500 if you like" This makes me happier about JFK. While I dislike the kludge which is ESPUDP, and I am very saddened that it has put constraints on future keying protocols, I believe that we do need a solution to ESP getting through NAT. It also answer the question of what we do with ESPUDP if adopt JFK on a port other than 500. { I prefer: IPv4/ESP/IPv6/shipworm-UDP/IPv4 this devolves to IPv4/ESP/IPv6 when NAT vendors deploy v6 via 6to4, or when native IPv6 is available. Putting 6to4 support into gateways is really easy, so don't tell me that IPv6 won't be available on many gateways.} ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBfUiIqHRg3pndX9AQHvAQP+KOjq56ZkpgK/CCwGpuw3EjBQdcbimtL/ VcxMr8aP0iM7rQPCGBXJUzN5yD+RhElCg9hlPcWYJPW78BfWwu/CRUzfevVzuLl7 lPHl9DNZNIvTEXjojWOsrnMccigrAYfZaxxR/vc6kQ9PMfCI1U5TqKXHgXyvyd4h 0R4PaJ/MnC4= =qRik -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 12 14:54:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCMsk211590; Wed, 12 Dec 2001 14:54:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20602 Wed, 12 Dec 2001 17:21:20 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Bart Preneel Cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Dec 2001 15:31:04 -0700 Message-Id: <20011212223105.EE6167B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Bart Preneel writes: > >For choosing MAC parameters, one has to take into account the >lifetime during which the system will be used (rather than the >lifetime of a single key). I believe that 80-bit MACs are >sufficient for 20 years or more. A MAC of 96 bits may be chosen >for the alignment reasons mentioned above. A MAC of 128 bits is >fine but probably too conservative; anything larger is certainly >overkill and may even harm security in the long run. What do you mean by "sufficient for 20 years or more"? That that's how long you expect that it will be safe to use such MACs for new connections? Obviously, a MAC only has to resist attack while it's still accepted, unlike a confidentiality key. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Wed Dec 12 15:04:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCN4O213120; Wed, 12 Dec 2001 15:04:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20625 Wed, 12 Dec 2001 17:26:49 -0500 (EST) To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: JFK, IKEv2 and ESPUDP References: <200112122205.fBCM50P00660@marajade.sandelman.ottawa.on.ca> From: Derek Atkins Date: 12 Dec 2001 17:36:36 -0500 In-Reply-To: Michael Richardson's message of "Wed, 12 Dec 2001 15:04:58 -0700" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > While I dislike the kludge which is ESPUDP, and I am very saddened that > it has put constraints on future keying protocols, I believe that we do need > a solution to ESP getting through NAT. > > It also answer the question of what we do with ESPUDP if adopt JFK on a > port other than 500. > > { I prefer: > IPv4/ESP/IPv6/shipworm-UDP/IPv4 > > this devolves to IPv4/ESP/IPv6 when NAT vendors deploy v6 via 6to4, or when > native IPv6 is available. Putting 6to4 support into gateways is really easy, > so don't tell me that IPv6 won't be available on many gateways.} We have a similar issue with KINK -- the answer is that you need to make room in the keying protocol to transmit ESPoUDP data within the "keying" stream. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Dec 12 15:43:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCNhw214963; Wed, 12 Dec 2001 15:43:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20725 Wed, 12 Dec 2001 17:51:31 -0500 (EST) Date: Thu, 13 Dec 2001 00:00:44 +0100 (MET) From: Bart Preneel To: "Steven M. Bellovin" cc: Bart Preneel , Paul Koning , Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt In-Reply-To: <20011212223105.EE6167B55@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry for being unclear. It means that you can use this system till 2021 without problems. The length of a MAC key depends on the lifetime of the system (rather than the lifetime of a single MAC key). One can have a key search machine trying keys by exhaustive search; if the MAC key is modified, the search is restarted. The success probability then depends on the lifetime of the system rather than on the lifetime of a single MAC key (which can be seconds). For MAC output lengths, the concern is that somebody may insert packets with random MACs. The question is: what is the damage that can be done (or value that can be gained) by a single injected packet? - I am not going to answer this one, but I guess that there are few applications where this is very high. If you worry that from 2020 onwards the expected value: (number of attempts * value of successful attempt)/2**80 gets too large, you can indeed start adding MAC bits at that time (there is no need to do this now). - you just need to be sure that you can update the standards and the implementations when necessary. Bart Preneel On Wed, 12 Dec 2001, Steven M. Bellovin wrote: > In message > , Bart Preneel writes: > > > > >For choosing MAC parameters, one has to take into account the > >lifetime during which the system will be used (rather than the > >lifetime of a single key). I believe that 80-bit MACs are > >sufficient for 20 years or more. A MAC of 96 bits may be chosen > >for the alignment reasons mentioned above. A MAC of 128 bits is > >fine but probably too conservative; anything larger is certainly > >overkill and may even harm security in the long run. > > What do you mean by "sufficient for 20 years or more"? That that's how long > you expect that it will be safe to use such MACs for new connections? > Obviously, a MAC only has to resist attack while it's still accepted, > unlike a confidentiality key. > > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > From owner-ipsec@lists.tislabs.com Wed Dec 12 15:46:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBCNk4215151; Wed, 12 Dec 2001 15:46:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20798 Wed, 12 Dec 2001 18:04:42 -0500 (EST) Date: Wed, 12 Dec 2001 16:16:33 -0700 (MST) From: Jan Vilhuber X-Sender: vilhuber@localhost To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: comments on jfk and ikev2 drafts In-Reply-To: <200112100418.fBA4Itr01852@marajade.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 -----BEGIN PGP SIGNED MESSAGE----- On Sun, 9 Dec 2001, Michael Richardson wrote: > | Pretty Good Privacy(tm) Version 6.5.8 > | (c) 1999 Network Associates Inc. > | Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc. > | Export of this software may be restricted by the U.S. government. > | > | File is signed. signature not checked. > | Signature made 2001/12/10 04:19 GMT > | key does not meet validity threshold. > | > | WARNING: Because this public key is not certified with a trusted > | signature, it is not known with high confidence that this public key > | actually belongs to: "(KeyID: 0xE99DD5FD)". > > > I had 24 comments about IKEv2, and 8 about JFK. > > As JFK has not yet defined how selectors are defined, and I regard this as the > *MAJOR* reason for the marketplace to ask for a replacement for IKEv1, I > consider the JFK draft to be a very rough -00 draft. The amount of text in it > is very small, and would need to double or triple before it could be compared > in any to the IKEv2 draft. > > As far as I can tell, neither proposal yet explains to me how to *add* new > traffic to an existing IPsec SA without rekeying it. > I wasn't aware it was supposed to, although it's a feature of huge personal interest. Is there some text in the drafct I missed? Can you point it out? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQCVAwUBPBflVVTl7/VM5L39AQHoMwP+Lma4pDHYpXCRYgu5cjzpwpgcDdQb2JuZ 7wRcVq4OJX/q6fa/Tr6sQwMK7lkk2HhiuGrvv9LY9nAcdwP0/JlcKsY2Rq51F4cz 42T/0O1wjtPZpurYjIgee9AjVH/CaXO5/O5xhYbJ65CPNLzISx6RQHJnviWuE9QX nv4CqRGFw9Y= =5XRr -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 12 16:22:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBD0MI216634; Wed, 12 Dec 2001 16:22:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20966 Wed, 12 Dec 2001 18:41:50 -0500 (EST) Message-Id: <200112122339.fBCNdbG01989@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: comments on jfk and ikev2 drafts In-reply-to: Your message of "Wed, 12 Dec 2001 16:16:33 MST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Dec 2001 16:39:37 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jan" == Jan Vilhuber writes: mcr> As far as I can tell, neither proposal yet explains to me how to *add* new mcr> traffic to an existing IPsec SA without rekeying it. Jan> I wasn't aware it was supposed to, although it's a feature of huge personal Jan> interest. Is there some text in the drafct I missed? Can you point it out? The key is that the protocol has some way to establish a new SA independantly of setting the traffic selectors. Perhaps Cheryl can add a section to her draft about selectors and adding/subtracting of selectors. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBfqt4qHRg3pndX9AQEnSAQApoYfO2nZHrM/tQHs9Cpt66NWxqBhP8VP vF9pnY5VPq0q2o/I++ISHeEHV7D6Z4dA7KtLj1MAQiW3SmQkDuUytQjIeQVYhBHH HnVpqhtyxIS5qks3ulxoMqjZ18xwXt08lhFUS96Q1DQn/svIkvwLp9jKsnOLBOk/ T1XAKolJ/tE= =n/TB -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 12 16:54:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBD0sb220090; Wed, 12 Dec 2001 16:54:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21002 Wed, 12 Dec 2001 18:51:31 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Thu, 13 Dec 2001 01:46:15 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: ipsec@lists.tislabs.com Subject: fragmentation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since you can't rely on getting an icmp when your packet is too large, and you can't be certain that frags pass through routers, what is left? What if the IPsec endpoints used the DF-bit and an MTU discovery that *didn't* rely on icmp? One could use e.g. encrypted ping packets (of varying sizes, with df set) to ensure that the route between the endpoints is capable of handling them. This way, there is no need to rely on unprotected icmps (if you would happen to get them), or on the behavior of the routers in between. An ordinary MTU discovery mechanism can be implemented on top of the encrypted ping. (Maybe this has already been suggested?) -Sami From owner-ipsec@lists.tislabs.com Wed Dec 12 20:09:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBD497227306; Wed, 12 Dec 2001 20:09:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21407 Wed, 12 Dec 2001 22:14:47 -0500 (EST) Message-Id: <200112130312.fBD3CRS00909@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: fragmentation In-reply-to: Your message of "Thu, 13 Dec 2001 01:46:15 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 12 Dec 2001 20:12:26 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sami" == Sami Vaarala writes: Sami> Since you can't rely on getting an icmp when your packet Sami> is too large, and you can't be certain that frags pass Sami> through routers, what is left? I have proposed to do PMTU for the tunnel itself by having the receiving gateway observe the size of received fragments. {It turns out on linux, that is has become trivial to do, since transport protocols are now forced to linearize fragments themselves. This was done so that TCP could avoid a copy, and actually causes lossage on the current FreeSWAN release with 2.4.4+. On other non-BITS implementations, this would require some additional booking to be provided in the mbuf header} Periodically and when it sees a number larger than it has seen before, it would send an ICMP fragment needed *through* the tunnel, to the originator. The source address could be forge as coming from the destination of the packet. (This guarantees that the ICMP packet fits into the tunnel. If fails for per-protocol or per-port tunnels. I think that rfc2401bis will have to address this and make ICMP explicitely allowed for them) This fails if there is ICMP hole between the near gateway and the originator. This is actually a very common occurance when one has an extruded host/subnet (i.e. the default route for the road warrior is through the tunnel) since the "other side" is the entire Internet. This produces sub-optimal values if the fragmentation is done by dividing in two. It does work however. Sami> An ordinary MTU discovery mechanism can be implemented Sami> on top of the encrypted ping. Sami> (Maybe this has already been suggested?) There are various blackhole discovery protocols that have been written about. I don't have reference on them, sorry. The problem is usually that the stupid web-hosting company that you are trying to reach isn't clueful enough to turn it on. Part of the problem is education - a NetBSD hacker is in the process of setting up a web site on which one can register sites which seem to have PMTU on, but have ICMP off. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBgcmYqHRg3pndX9AQHQXgP/fmadl/+WtNIRE8aPaQgGaQ40AGSP8OUn PFioyWZJ8yH5L9eE2zh20eMFITQw6GSGhddEiO8RiK20Li+UOvzN3zav6vocDdZg eCdkLPLxRgHtUwD7JhEZmwVeISvR8xxDBfdt/e3KQvIIEXu2VLUdcQ8Sr9eAdbbb pGGWfjJK8Oc= =GKLu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 12 22:51:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBD6pm202419; Wed, 12 Dec 2001 22:51:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA21843 Thu, 13 Dec 2001 01:12:02 -0500 (EST) To: Michael Richardson Cc: ipsec@lists.tislabs.com From: dharkins@tibernian.com Subject: Re: suggestion for JFK In-Reply-To: Your message of "Wed, 12 Dec 2001 13:02:17 MST." <200112122002.fBCK2HH09409@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13672.1008224513.1@SailPix.com> Date: Wed, 12 Dec 2001 22:21:53 -0800 Message-Id: <20011213062153.EB51054C55@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Dec 2001 13:02:17 MST you wrote > > As I understand Dan's suggestion, including the IP address means that the > initiator can't bounce around to different IPs - I don't get what it buys tho >ugh. What it buys is a guarantee that there is only one case in which a token would be valid but the encrypted data is garbage-- when message 3 was sent by the same IP address which optained the token in message 2. If the token is correct in message 3 then the responder does work. It would be nice (to me at least) to know who is trying to make me do some work for no reason. Right now all I know is that someone is doing this thing to me, not who. In addition, by not including the IP address in the hash calculation JFK opens itself up to a varient of Simpson's "cookie jar" attack. What happens is I send a JFK implementation X message 1's with different nonces and g^i's and receive X valid tokens in response. Provided that message 1 and message X obtained a token based on the same HKr (I'll know this if the signed g^r is the same) I can then send X message 3's with bogus source IP addresses and the responder will use up his CPU exponentiating to decrypt lots and lots of garbage. And he has know idea where the person is who is doing this to him. I will now stop beating this horse since I am the only person who thinks it is not dead yet. Dan. From owner-ipsec@lists.tislabs.com Thu Dec 13 09:20:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDHKf205203; Thu, 13 Dec 2001 09:20:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23137 Thu, 13 Dec 2001 11:13:13 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: dharkins@tibernian.com Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: suggestion for JFK Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 09:22:56 -0700 Message-Id: <20011213162257.A2B447B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20011213062153.EB51054C55@tailor.sailpix.com>, dharkins@tibernian.c om writes: >On Wed, 12 Dec 2001 13:02:17 MST you wrote >> >> As I understand Dan's suggestion, including the IP address means that the >> initiator can't bounce around to different IPs - I don't get what it buys th >o >>ugh. > >What it buys is a guarantee that there is only one case in which a token >would be valid but the encrypted data is garbage-- when message 3 was sent >by the same IP address which optained the token in message 2. > >If the token is correct in message 3 then the responder does work. It would >be nice (to me at least) to know who is trying to make me do some work for >no reason. Right now all I know is that someone is doing this thing to me, >not who. > >In addition, by not including the IP address in the hash calculation JFK >opens itself up to a varient of Simpson's "cookie jar" attack. What happens >is I send a JFK implementation X message 1's with different nonces and g^i's >and receive X valid tokens in response. Provided that message 1 and message >X obtained a token based on the same HKr (I'll know this if the signed g^r >is the same) I can then send X message 3's with bogus source IP addresses >and the responder will use up his CPU exponentiating to decrypt lots and >lots of garbage. And he has know idea where the person is who is doing this >to him. > >I will now stop beating this horse since I am the only person who thinks >it is not dead yet. > I'm not convinced one way or another -- your note arrived during the IETF, which is not a time I find conducive to analyzing cryptographic protocols. (My first reaction was "this breaks NAT transparency", which was of course wrong -- and a perfect reason why I'm going to defer thinking about it.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Thu Dec 13 10:00:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDI0n207208; Thu, 13 Dec 2001 10:00:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23253 Thu, 13 Dec 2001 12:15:38 -0500 (EST) Message-Id: <200112131722.fBDHMHG01587@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: ikev2 questions arising from Radia's presentation Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 13 Dec 2001 10:22:15 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- 1) she explained that they are using the entire ESP format. (It wasn't clear to me that the auth header was at the end) Radia explained that they would ignore the next header bytes. It actually seems to me that using it would be better to use this value rather than the one from the ISAKMP header. (is that a fair name for that initial block from the ISAKMP rfc?) 2) when I initially read the document, I got the impression that the ISAKMP header was not protected by anything. I think that DHR also believed this. After Radia's comments about ESP, I'm wondering if the AUTH header would in fact cover the ISAKMP header as well? Hugh Redelmeier had some concerns about this that he had posted. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBjjxIqHRg3pndX9AQFfCAP8CET5VZdf7xeP5KXxRIF0lB11XnYYNG4L YFI4+QXckAxfJSiJLxjWl7QNGzbrUh7F9Wuqg44FHa3KvltmVEAL6BuDsYm/5/Si zeOHaBJgN57p69qrAff1GnKCGnLzPI38PSpe0gSj1Olpu0wVxMBT4v1Awul23dCb 4cO1YM7F21w= =Ovbq -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Dec 13 12:51:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDKpn218158; Thu, 13 Dec 2001 12:51:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23656 Thu, 13 Dec 2001 15:01:24 -0500 (EST) Date: Thu, 13 Dec 2001 22:11:13 +0200 Message-Id: <200112132011.WAA11175@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com cc: henry@spsystems.net cc: mcr@sandelman.ottawa.on.ca In-reply-to: <200112110318.fBB3ITk01102@marajade.sandelman.ottawa.on.ca> (message from Michael Richardson on Mon, 10 Dec 2001 20:18:29 -0700) Subject: Re: compare-jfk-sigma.txt References: <200112110318.fBB3ITk01102@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Concerning ... > From: Michael Richardson > Markku> Policy is what gets handed down to you by a person (or a system) > Markku> responsible for the security of the site or service you want to use > Markku> and which is protected by IPSEC. > You've described an intra-organizational VPN. and ... > From: Henry Spencer > Assuming that both you and the site/service you want to use are > under the same administration. How an earth did you end up with this conlusion (VPN/same administration)? I must try to express myself once more... Preamble... - I'm only discussing about matters related "Phase 2" SA's. I'm not concerned with Phase 1 SAs - my claim: phase 2 SA negotiation does not require and should not include the selector information. It does include the SA fields present in SAD in RFC-2401 sense (but these have nothing to do with "policy" in my terminology). I assume a host has a policy database which is maintained by the USER of the host. This user decides what policies apply to his/her host! For example, if there is a web server (= 10.0.0.1) that requires ESP (3DES) to access the pages, then user *ADDS* the following line to the policy database remote=10.0.0.1, remote_port=80 => use ESP (3DES, remote_port, local) and the server host would have the following policy line (no IP address required, anything to port 80 needs IPSEC) local_port = 80 => use ESP (3DES, local_port, remote) The 'local/remote_port' and 'local/remote' are flags which tell what information from the triggering packet is to be present in the resulting SA. I'm decoupling the SA template specification from the selector specifation. You could have line protocol=tcp => use ESP(3DES+SHA1, local_port, remote_port) which would negotiate a separate SA for each different TCP connection. If the same user has a POP or IMAP mailbox on some other or on same server host, he would just add the appropiate selector lines with the stated policy requirements into his policy database. If the same user, in addition, need to use VPN connections from different administrations, he will just add the new selectors to the local policy data. Having the selector information in the phase 2 negotiation just adds complexity, and is *TOTALLY* unnecessary for the functioning of IPSEC. The policy *IS* fully enforced by the kernel SPD (as per RFC-2401). The only consequence of the selector information is interoperability problems and limitations, how selectors can be defined. > From: Henry Spencer > There is also the desirability of checking for errors. Even under a > common administration, just because the two ends are *supposed* to > agree on security policy does not mean they do, and a silent failure > of agreement can result in no communication and no clear indication > of why. So far, this is about only useful thing that might result from the passed policy information in phase 2 SA. HOWEVER, I think the same result would be achieved in much simpler way: - don't use selectors in phase 2 negotiations, - instead, have a notification payload, that can be used notify about the problem A host noticing that it is dropping packets from some host due to policy rule, could send this notification with appropriate information, if it has phase 1 SA for that host. Finally, above only concerned the policy relating to the phase 2 SA's. This is simple. The true difficulties are in transfering the required information for establishing the phase 1 connection. They are much more complex, including the public keys and so on. What I would like to see, for example, extending the web server example: enable "pay for use" (or otherwise restricted) access web server. You would need to base the phase 1 negotiation on possesion of server certified private key, without any binding to clients current address. When ISAKMP (or whatever) can do this, things will get interesting. People could buy/or be given "access rights" to the server. -- Markku Savela From owner-ipsec@lists.tislabs.com Thu Dec 13 13:13:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDLDW219655; Thu, 13 Dec 2001 13:13:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23743 Thu, 13 Dec 2001 15:27:44 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: ipsec@lists.tislabs.com Subject: my attitude towards IKEv2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 13:37:30 -0700 Message-Id: <20011213203730.70B7E7B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There seems to be some confusion about my (personal) attitude towards IKEv2 and its creators. I do not think that it's a bad job, or that the work was poorly done, and if I gave anyone the impression that I do feel that way, I humbly apologize. I think that the authors did a very good job of simplifying a too-complex protocol, and a marvelous job of combining three complex documents into a single much-simpler document. Where they and I (and, I think, the other JFK designers) differ is in a basic axiom. IKEv2 is based on the assumption that as much as possible of the current IKE structure (and perhaps code) should be preserved. I (we) don't agree. In my opinion, we'll end up with a much better result if we start with a slate wiped clean except for the lessons we've all learned from the failures (and successes) of IKEv1. Again, if anyone is offended, I apologize. I hope we can all work together on the rest of this issue. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Thu Dec 13 14:19:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDMJ2222097; Thu, 13 Dec 2001 14:19:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23936 Thu, 13 Dec 2001 16:20:54 -0500 (EST) From: "Jayant Shukla" To: "'Ari Huttunen'" , "'Michael Richardson'" Cc: Subject: RE: IKEv2 and NAT traversal Date: Thu, 13 Dec 2001 13:27:25 -0800 Message-ID: <000001c1841c$f596dc60$0101a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3C1723AD.F7D0C18C@F-Secure.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Ari Huttunen > > Err.. no. "NAT people" didn't specify this encapsulation draft, at least I > deny > any connection to "NAT people" :). "NAT people" produced RSIP, we "IPsec > people" > just try to get around the NAT problems the best we can.. (I dislike > dividing > people into categories, but that discussion is not for this list.) > Didn't your original draft use RSIP? From the section 6 of your original draft (expired Jan 2001), it seems to me that it is based on RSIP principle and UDP encapsulation. So you cannot deny a connection to "NAT people"! Of course your new drafts have gotten rid of RSIP. > > For almost a year there has been discussion of whether to move this common > IKE and ESPUDP used in the encapsulation draft to a different port than > 500, > this is among the authors and hasn't appeared on the list. The reason is > that > all the methods, given the constraints, were worse than the method used in > the current draft. > > So what are/were the constraints? The biggest one is that IKEv1 designed > to traverse NATs must start on port 500, because it has no clue whether > the > other end can do ESPUDP. So if IKE is then to move to another port after > finding out that the peer supports ESPUDP and/or that a NAT is actually > found > to be present, complicates the protocol enormously. Like, consider what > happens when a port is changed in the middle of an exchange and packets > get lost, > like in one alternative we briefly considered. > Why does IKE have to move to another port? This is your kludge which forces you to do nasty stuff like this. Your solution is not a proper NAT traversal solution and because you use IKE to help in NAT traversal, you have all these weird problems. To me this solution is as bad as the port 80 punch thru. > The second constraint was the attempt to save bandwidth by reducing the > amount > of NAT keepalive packets by using one port, instead of a two port model, > like > I presented in my first draft a year ago. Unfortunately the constraint of > not > being able to change IKE causes ESPUDP traffic encapsulation to be > inefficient > and IKE traffic to be efficient, which is the wrong way. > > If we are free to consider a model for IKEv2 where the whole protocol is > moved > to a port that is non-500, we can devise a much better encapsulation > method, > which is described in the encapsulation draft under "5.2. Alternative > Encapsulation > Method 1 - Common Port". This also demands that all IKEv2 implementations > support > this method, at least as far as encapsulating IKEv2 packets themselves is > concerned. > > There's another reason than IKEv2 swapping the cookies to use a port that > is > not 500. It's that many of the NAT boxes seem to attempt to do intelligent > stuff for IKE, and this causes them to break when ESPUDP is flowing > through them, > because they get confused with 'zero cookies'. My American co-authors have > more > exact information about this. > That brings up another good point. Isn't that solution based on the NAT boxes (ones with IPsec pass thru) examining the IKE messages and storing the information about SPI, local host, and remote host? This information can be used to re-direct the subsequent IPsec packets to the appropriate local host. Clearly your proposed solution will break a lot of these NAT boxes and that is not good! > > > > Further, I think that IKE has the right to change things with the > cookie > > values at any time. > > This is an interesting question. I also used to consider a protocol just > a contract between Ari and Bob, who wish to communicate. However, there's > Ned in the middle who wishes to 'do stuff' to the protocol while it is > in transit. If we consider that doing NAT is a valid thing to do, are > Ari and Bob free to change the protocol so that Ned's implementation > fails? > > Ari > > > > > > You made this kludge, now lie in it. > > True! ~Jayant Trlokom, Inc. p.s.: BTW, I have notified IETF about your new drafts infringing on our intellectual property. From owner-ipsec@lists.tislabs.com Thu Dec 13 14:21:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBDMLx222214; Thu, 13 Dec 2001 14:21:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23993 Thu, 13 Dec 2001 16:33:09 -0500 (EST) Message-Id: <200112132139.fBDLdgH01262@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: compare-jfk-sigma.txt In-reply-to: Your message of "Thu, 13 Dec 2001 22:11:13 +0200." <200112132011.WAA11175@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 13 Dec 2001 14:39:41 -0700 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Markku" == Markku Savela writes: Markku> I assume a host has a policy database which is maintained by the USER Markku> of the host. This user decides what policies apply to his/her host! If we had that level of coordination then we wouldn't even need a key manager. Markku> For example, Markku> if there is a web server (= 10.0.0.1) that requires ESP (3DES) to Markku> access the pages, then user *ADDS* the following line to the policy Markku> database So, you are proposing HOSTS.TXT. let's preconfigure everything. Forget about distributing policy, or discovering you. You figure we have time/memory/knowledge to configure policy for all 2^32 (2^128 in v6) hosts out there. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBkgGoqHRg3pndX9AQF87gP/S/TUM/aP3GGcFnawl9trRl+83pZpQiR2 iZ7rMSPrvpfH1RLmxFHFrWDzmTJsjfk8OZdAYNyFeLFz+3AaIC4HZrLBWzCYdjHp HJrUPQ/igY5jBjvY/oZiY9oHkLduPGbcN89uBFuC6IkdBUEguUnP/P118GI+eDZy NPnTEmdJ9cI= =lQtX -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Dec 13 16:22:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE0Mf229726; Thu, 13 Dec 2001 16:22:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24302 Thu, 13 Dec 2001 18:34:03 -0500 (EST) Message-Id: <200112132343.fBDNhrXt016351@thunk.east.sun.com> From: Bill Sommerfeld To: ipsec@lists.tislabs.com Subject: IKEv2 traffic selector subsetting. Reply-to: sommerfeld@east.sun.com Date: Thu, 13 Dec 2001 18:43:53 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Section 2.9 of draft-ietf-ipsec-ikev2-00.txt says: The Responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating one or more members of the set of traffic selectors provided the set does not become the NULL set. In many (most) cases, the Initiator is initiating because it has a packet it needs to send and doesn't have an appropriate SA for it. Given this, it's not immediately clear how the responder is supposed to select a meaningful subset of the initiator-proposed traffic selectors. If you want to support a capability like this, it seems like the traffic selector payload should also include the actual packet field values in the packet which triggered the exchange, so the responder can select a *useful* subset if it's not prepared to accept the entire selector set.. - Bill From owner-ipsec@lists.tislabs.com Thu Dec 13 16:46:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE0k3201370; Thu, 13 Dec 2001 16:46:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24356 Thu, 13 Dec 2001 19:03:54 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Thu, 13 Dec 2001 17:54:47 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: fragmentation In-Reply-To: <200112130312.fBD3CRS00909@marajade.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 Michael, > This fails if there is ICMP hole between the near gateway and the > originator. This is actually a very common occurance when one has an extruded > host/subnet (i.e. the default route for the road warrior is through the > tunnel) since the "other side" is the entire Internet. I see I misread this before, you are talking about a different problem than I was. What I meant originally is to fix the problem that occurs between IPsec endpoints, not between the actual sender and receiver. -Sami From owner-ipsec@lists.tislabs.com Thu Dec 13 16:46:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE0k6201380; Thu, 13 Dec 2001 16:46:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24361 Thu, 13 Dec 2001 19:04:00 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Thu, 13 Dec 2001 17:39:05 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: fragmentation In-Reply-To: <200112130312.fBD3CRS00909@marajade.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 Michael, > >>>>> "Sami" == Sami Vaarala writes: > Sami> Since you can't rely on getting an icmp when your packet > Sami> is too large, and you can't be certain that frags pass > Sami> through routers, what is left? >[...] > This fails if there is ICMP hole between the near gateway and the > originator. This is actually a very common occurance when one has an extruded > host/subnet (i.e. the default route for the road warrior is through the > tunnel) since the "other side" is the entire Internet. Exactly. What I was saying was that maybe we shouldn't rely on icmp. Yes, you can always say it's the clueless X that's the fault, but the end result is that the tunnel isn't working as it's supposed to be. What I proposed was using an encrypted, ping-like protocol. Don't rely on any icmp information (or lack of it) that you get from between the IPsec endpoints. Instead, to ensure that you can pass a packet of 1234 bytes between the endpoints, send an encrypted ping (or whatever) of that size; if you get a reply, you can do that. Otherwise, you can't (have to send a few retries, of course). No need to rely on icmp. > There are various blackhole discovery protocols that have been written > about. I don't have reference on them, sorry. The problem is usually that the > stupid web-hosting company that you are trying to reach isn't clueful enough > to turn it on. Yes, exactly. For IPsec purposes, maybe one shouldn't rely too much on the behavior of a third party. Moreover, icmp is unprotected, so you will have to have heuristics for dealing with fake icmp messages. I'm not too comfortable with defining a new mechanism that has a function similar to an existing one. Yet, having dealt with enough problems of this nature in practice, it is starting to seem attractive. -Sami From owner-ipsec@lists.tislabs.com Thu Dec 13 16:58:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE0w8202566; Thu, 13 Dec 2001 16:58:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24412 Thu, 13 Dec 2001 19:22:19 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B01F29370@NS-CA> From: Gregory Lebovitz To: ipsec@lists.tislabs.com Subject: RE: my attitude towards IKEv2 Date: Thu, 13 Dec 2001 16:30:48 -0800 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 In the spirit of "all working together", the best final son-of-ike will probably come not from one of the current 3 proposals exclusively, but from best elements of the three, combined. We ought take the excellent thinking done in the propopsed works combined to create the best final protocol. Clearly we will need to use one proposal as the base, but from their we have the flexibility to cut and paste from the others. This may save turf wars, and produce better quality for us all. > -----Original Message----- > From: Steve Bellovin [mailto:smb@research.att.com] > Sent: Thursday, December 13, 2001 12:38 PM > To: ipsec@lists.tislabs.com > Subject: my attitude towards IKEv2 > > > There seems to be some confusion about my (personal) attitude towards > IKEv2 and its creators. I do not think that it's a bad job, or that > the work was poorly done, and if I gave anyone the impression > that I do > feel that way, I humbly apologize. > > I think that the authors did a very good job of simplifying a > too-complex protocol, and a marvelous job of combining three complex > documents into a single much-simpler document. Where they > and I (and, > I think, the other JFK designers) differ is in a basic axiom. > IKEv2 is based on the assumption that as much as possible of the > current IKE structure (and perhaps code) should be preserved. I (we) > don't agree. In my opinion, we'll end up with a much better > result if > we start with a slate wiped clean except for the lessons we've all > learned from the failures (and successes) of IKEv1. > > Again, if anyone is offended, I apologize. I hope we can all work > together on the rest of this issue. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at > http://www.wilyhacker.com > > From owner-ipsec@lists.tislabs.com Thu Dec 13 17:22:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE1ML204046; Thu, 13 Dec 2001 17:22:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24447 Thu, 13 Dec 2001 19:37:52 -0500 (EST) MIME-Version: 1.0 x-receiver: m.gratton@adga.ca Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <200112132343.fBDNhrXt016351@thunk.east.sun.com> From: "Bill Sommerfeld" To: Subject: IKEv2 traffic selector subsetting. Reply-To: Date: Thu, 13 Dec 2001 18:43:53 -0500 X-OriginalArrivalTime: 14 Dec 2001 00:47:52.0828 (UTC) FILETIME=[F64BC3C0:01C18438] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Section 2.9 of draft-ietf-ipsec-ikev2-00.txt says: The Responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating one or more members of the set of traffic selectors provided the set does not become the NULL set. In many (most) cases, the Initiator is initiating because it has a packet it needs to send and doesn't have an appropriate SA for it. Given this, it's not immediately clear how the responder is supposed to select a meaningful subset of the initiator-proposed traffic selectors. If you want to support a capability like this, it seems like the traffic selector payload should also include the actual packet field values in the packet which triggered the exchange, so the responder can select a *useful* subset if it's not prepared to accept the entire selector set.. - Bill From owner-ipsec@lists.tislabs.com Fri Dec 14 00:17:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE8Hf226885; Fri, 14 Dec 2001 00:17:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA25406 Fri, 14 Dec 2001 02:23:01 -0500 (EST) Message-Id: <200112140733.KAA26901@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com, sommerfeld@east.sun.com Date: Fri, 14 Dec 2001 10:32:41 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: IKEv2 traffic selector subsetting. In-reply-to: <200112132343.fBDNhrXt016351@thunk.east.sun.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 13 Dec 01, at 18:43, Bill Sommerfeld wrote: Bill, > Section 2.9 of draft-ietf-ipsec-ikev2-00.txt says: > The Responder is allowed to narrow the choices by selecting a subset > of the traffic, for instance by eliminating one or more members of > the set of traffic selectors provided the set does not become the > NULL set. > > In many (most) cases, the Initiator is initiating because it has a > packet it needs to send and doesn't have an appropriate SA for it. > > Given this, it's not immediately clear how the responder is supposed > to select a meaningful subset of the initiator-proposed traffic > selectors. That's exactly what I was talking about in my post to this list a few days ago. > If you want to support a capability like this, it seems like the > traffic selector payload should also include the actual packet field > values in the packet which triggered the exchange, so the responder > can select a *useful* subset if it's not prepared to accept the entire > selector set.. I can see two ways to achieve this. 1) It is possible to introduce new payload type, similar in format to TS payload, that will contain actual packet field values. 2) Instead of increasing number of payload types, it is possible to require, that the very first TSS in TS payload must always contain actual packet field values in the packet, which triggered the exchange. > - Bill Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Fri Dec 14 01:04:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE94M202527; Fri, 14 Dec 2001 01:04:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25569 Fri, 14 Dec 2001 03:27:35 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Michael Richardson'" , Subject: RE: ikev2 questions arising from Radia's presentation Date: Fri, 14 Dec 2001 01:36:02 -0500 Message-ID: <000401c1847a$110102c0$44c6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200112131722.fBDHMHG01587@marajade.sandelman.ottawa.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 2) when I initially read the document, I got the impression that > the ISAKMP header was not protected by anything. I think that > DHR also believed this. > > After Radia's comments about ESP, I'm wondering if the AUTH > header would in fact cover the ISAKMP header as well? I thought this was apparent from the draft. See appendix B: The encryption and integrity protection algorithms are the same as those available to the ESP protocol, through their application is slightly different. Whereas in ESP the header that is integrity protected but not encrypted is a total of 8 bytes (SPI+Sequence #) plus the IV, in IKE it is the IKE Header which is 28 bytes plus the IV (see section 7.1). Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Fri Dec 14 01:04:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE94j202599; Fri, 14 Dec 2001 01:04:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25563 Fri, 14 Dec 2001 03:27:29 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" Cc: "'IPsec WG'" Subject: Re: Comment regarding Nonce size Date: Fri, 14 Dec 2001 01:35:49 -0500 Message-ID: <000301c1847a$0ddedb30$44c6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > PS: the above paragraph about the pre-hashing of long keys in > HMAC also > gives you a partial answer on your other question > about what's the benefit of using nonces that are longer than the hash > output size: while the extra length is not strictly needed, and can > even be considered a "waste" if the nonce bits are TRULY random, > the extra length may potentially help in the typical case > that these bits > are generated out of a weaker source of (pseudo) randomness. It seems to me that this is only an advantage if you have a weak RNG but you don't know it. If you think you have a weak RNG, wouldn't a better solution be to generate a large nonce with sufficient entropy and then hash it down to the size of the HMAC output? That would save bits on the wire, with no apparent drawbacks. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Fri Dec 14 01:05:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE952202651; Fri, 14 Dec 2001 01:05:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25551 Fri, 14 Dec 2001 03:27:16 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: comment on draft-spencer-ipsec-ike-implementation-01.txt Date: Thu, 13 Dec 2001 20:04:35 -0500 Message-ID: <000001c1847a$070aa820$44c6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I read the Freeswan IKE implementation draft which Michael mentioned at the IPsec meeting and I found to be very lucid. I have disagreed with some Freeswan implementers on the past on issues like deletes, dead peer detection, rekeying, and the meaning of the word "unique", but I was surprised to discover that I agreed with pretty much everything they write in this draft. I think this could be a good starting point for a BCP. I encourage people to read it. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Fri Dec 14 01:13:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE9DV203779; Fri, 14 Dec 2001 01:13:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25559 Fri, 14 Dec 2001 03:27:26 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'David Wagner'" , Subject: Re: Comments regarding key stretching algorithm Date: Fri, 14 Dec 2001 01:35:41 -0500 Message-ID: <000201c1847a$0bb125c0$44c6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <9v6jm0$94p$1@abraham.cs.berkeley.edu> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >The problem is that no matter how large you make your DH > exponent, the > >entropy in your key(s) is limited by the output of your hash. > > Why is this a problem? Are you worried about 2^160 work attacks? My line of reasoning is this: Every year, the guidelines for N year secrecy go up. This necessitates the use of stronger and stronger ciphers. MAC algorithms don't typically require N year secrecy so we can get away with SHA1-96. However, PRF algorithms do need N year secrecy when the PRF is used to create the encryption key. I agree that just because you use AES-128 that doesn't mean you need 128 bits of security. However, if you are using AES with 192 or 256 bit keys, it's presumably because you require more than 128 bits of effective security. In order to match key strengths, you have to increase your DH group size *AND* you need to either choose a different PRF algorithm or you have to change the key stretching alrgorithm. The question I am asking is do we have to upgrade to SHA2 or TIGER solely for the purpose of key stretching, or could the protocol be fixed in another way? ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Fri Dec 14 01:17:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE9HQ204309; Fri, 14 Dec 2001 01:17:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25576 Fri, 14 Dec 2001 03:27:52 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: IKEv2 traffic selector subsetting. Date: Fri, 14 Dec 2001 02:55:50 -0500 Message-ID: <000a01c1847a$1bb4e100$44c6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200112132343.fBDNhrXt016351@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To add to this conversation, I would like to debunk this myth that the IPsec SADB selectors need to match the IPsec policy. The SPD, not the SADB, is supposed to enforce IPsec policy. As someone noted, it does no good to repeat the information in the SPD in the SA selectors, since that traffic will be filtered out by the SPD anyway. If you wish to avoid sending traffic that will be filtered out by the peer then that would be best accomplished by an IPSP protocol. The point of the phase 2 selectors is to enforce that (often ignored) 3rd aspect of network security: authorization. We want to bind the phase 2 selectors to the phase 1 identity so that authenticated peers cannot impersonate each other. The use of the phase 2 selectors allows the per-packet SPD check to proceed without consulting the SADB (because the initial SADB check is sufficient for verifying that the phase 1 id is appropriate). This is an *OPTIMIZATION*. It is feasible to negotiate wildcard SAs (or transport mode SAs for an IP-in-IP tunnel) *iff* you do a phase 1 identity check on every packet (i.e. pass the SA context information up the stack). Port-constrained SAs make sense in the case of a multi-user UNIX machine where the phase 1 id associated with port FOO is not necessarily the same as the id on port BAR. Port-constrained selectors are NOT the best mechanism for implementing packet filtering. In the vast majority of VPN scenarios, a list of subnets would be appropriate for expressing phase 2 selectors. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Fri Dec 14 01:31:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE9Vl205369; Fri, 14 Dec 2001 01:31:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25682 Fri, 14 Dec 2001 03:55:35 -0500 (EST) Message-ID: <005201c1847d$d4c6eeb0$69f77a90@bilten.metu.edu.tr> From: =?iso-8859-1?Q?Kerem_=D6nal?= To: Date: Fri, 14 Dec 2001 11:00:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C1848E.9849A430" 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C1848E.9849A430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, My question is about ike. In quick mode, why do we have to send an = information about the oakley groups if we have already sent it in main = mode and use it for quick mode also? Am I right? Thanks in advance Kerem=20 ------=_NextPart_000_004F_01C1848E.9849A430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
My question is about ike. In quick = mode, why do we=20 have to send an information about the oakley groups if we have already = sent it=20 in main mode and use it for quick mode also? Am I right?
 
Thanks in advance
Kerem 
 
------=_NextPart_000_004F_01C1848E.9849A430-- From owner-ipsec@lists.tislabs.com Fri Dec 14 01:39:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE9dQ205908; Fri, 14 Dec 2001 01:39:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25701 Fri, 14 Dec 2001 04:00:48 -0500 (EST) Message-ID: <007901c1847e$8f5b0fe0$69f77a90@bilten.metu.edu.tr> From: =?iso-8859-1?Q?Kerem_=D6nal?= To: Subject: redundant oakley group in quick mode Date: Fri, 14 Dec 2001 11:06:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C1848F.52D93180" 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C1848F.52D93180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Sorry I forgot to put a subject in my previous email. repeating my previous question: "My question is about ike. In quick mode, why do we have to send an = information about the oakley groups if we have already sent it in main = mode and use it for quick mode also? Am I right?" =20 Thanks in advance Kerem=20 ------=_NextPart_000_0076_01C1848F.52D93180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Sorry I forgot to put a subject in my previous email.
 
repeating my previous question:
"My question is about ike. In quick = mode, why do we=20 have to send an information about the oakley groups if we have already = sent it=20 in main mode and use it for quick mode also? Am I right?"
 
Thanks in advance
Kerem 
------=_NextPart_000_0076_01C1848F.52D93180-- From owner-ipsec@lists.tislabs.com Fri Dec 14 01:45:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBE9jW206990; Fri, 14 Dec 2001 01:45:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25762 Fri, 14 Dec 2001 04:11:41 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" Cc: "'IPsec WG'" Subject: RE: IKEv2 and SIGMA Date: Fri, 14 Dec 2001 04:17:19 -0500 Message-ID: <001a01c18480$3a8d3ea0$44c6830c@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Andrew, I am glad you keep insisting in understanding this, > and I am sorry for not being clear. Below is another try ... > Indeed, I never explained why signing the MAC of the identity is > essential. You know why? Because it is NOT. (And I never said > it was.) The > only ESSENTIAL thing is that the MAC be applied to the identity! I went back through the archives to try to determine the source of this confusion. Dan said: > In this case IDi would be signed by each party. Since you're proposing > putting all things, including IDi, into the signed hash anyway why is it > dangerous to add just IDi to the mix of exponentials and nonces? and you replied: > IT IS VERY DANGEROUS! DOING WHAT YOU SUGGEST IS INSECURE! In this case, a buffer containing IDi would be signed by each party, but using the PCKS#1 format which also involves a hashing step. Wouldn't this be secure? (I see from the context that this discussion was relating to the potential "outer id", rather than the "inner id"). Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Fri Dec 14 03:22:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEBMG218486; Fri, 14 Dec 2001 03:22:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25986 Fri, 14 Dec 2001 05:42:15 -0500 (EST) Date: Fri, 14 Dec 2001 12:51:50 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'David Wagner'" , ipsec@lists.tislabs.com Subject: Re: Comments regarding key stretching algorithm In-Reply-To: <000201c1847a$0bb125c0$44c6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 14 Dec 2001, Andrew Krywaniuk wrote: > > >The problem is that no matter how large you make your DH > > exponent, the > > >entropy in your key(s) is limited by the output of your hash. > > > > Why is this a problem? Are you worried about 2^160 work attacks? > > > My line of reasoning is this: > > Every year, the guidelines for N year secrecy go up. This necessitates the > use of stronger and stronger ciphers. MAC algorithms don't typically require > N year secrecy so we can get away with SHA1-96. However, PRF algorithms do > need N > year secrecy when the PRF is used to create the encryption key. > > I agree that just because you use AES-128 that doesn't mean you need 128 > bits of security. However, if you are using AES with 192 or 256 bit keys, > it's presumably because you require more than 128 bits of effective > security. In order to match key strengths, you have to increase your DH > group size *AND* you need to either choose a different PRF algorithm or you > have to change the key stretching alrgorithm. > > The question I am asking is do we have to upgrade to SHA2 or TIGER solely > for the purpose of key stretching, or could the protocol be fixed in another > way? The protocol does not need any fix. If someone decides to use in its own implementation LONG DH groups and beyond 128-bit ciphers then that someone will also use SHA2, TIGER or whatever for the prf. Nothing in the protocol prevents that. But asking everyone to use this overkill hashes when they feel perfectly comfortable with Rijndael-128 makes no sense. Hugo From owner-ipsec@lists.tislabs.com Fri Dec 14 03:23:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEBN1218613; Fri, 14 Dec 2001 03:23:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25992 Fri, 14 Dec 2001 05:43:59 -0500 (EST) Date: Fri, 14 Dec 2001 12:53:48 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'IPsec WG'" Subject: Re: Comment regarding Nonce size In-Reply-To: <000301c1847a$0ddedb30$44c6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, I agree with what you say below except for one caveat: how much you trust the randomness of your peer's nonces? If you form the prf key as Ni|Nr as currently done in IKE then you are assuming goos (pseudo) randomness of both nonces. An option is to replace Ni|Nr with Ni XOR Nr which means that it suffices for one of the nonces to be random for the result to be random too. The reason that we did not use this in IKE is due to nonce length consideration (bandwidth) and also the concern that by doing Ni XOR Nr the responder could actually (maliciously) set Ni XOR Nr to whatever value it wants (e.g. 0). However, this may not be a concern that we should address since if R is malicious and tries to weaken the exchange it has many other ways to do it (e.g. choosing its DH exponent as g^2 or posting the exchanged key in the web :). So the two main options I see are: 1) YOu trust the nonce randomness of both sides (yours and your peer) and then you put the length of the nonce to be 1/2 the length of the prf key (e.g., 80 in the case of HMAC-SHA1) and concatenate Ni|Nr in the key derivation part. 2) You do not necessarily trust the randomness of your peer and then each chooses a nonce of the full length of the prf key (160 in the case of HMAC-SHA1) and put the key to be Ni XOR Nr. If bandwidth considerations are significant the first (current IKE method) seems good enough to me. Hugo On Fri, 14 Dec 2001, Andrew Krywaniuk wrote: > > PS: the above paragraph about the pre-hashing of long keys in > > HMAC also > > gives you a partial answer on your other question > > about what's the benefit of using nonces that are longer than the hash > > output size: while the extra length is not strictly needed, and can > > even be considered a "waste" if the nonce bits are TRULY random, > > the extra length may potentially help in the typical case > > that these bits > > are generated out of a weaker source of (pseudo) randomness. > > > It seems to me that this is only an advantage if you have a weak RNG but you > don't know it. If you think you have a weak RNG, wouldn't a better solution > be to generate a large nonce with sufficient entropy and then hash it down > to the size of the HMAC output? That would save bits on the wire, with no > apparent drawbacks. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > From owner-ipsec@lists.tislabs.com Fri Dec 14 03:32:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEBW3221028; Fri, 14 Dec 2001 03:32:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26034 Fri, 14 Dec 2001 05:57:09 -0500 (EST) Date: Fri, 14 Dec 2001 13:06:58 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'IPsec WG'" Subject: RE: IKEv2 and SIGMA In-Reply-To: <001a01c18480$3a8d3ea0$44c6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Beating a dead horse. I said it far too many times: the concern is to make sure the MAC covers the ID. For cleanliness and robustness I preferred the ID to appear as an explicit input to the MAC, but if people are content with having the ID under the ciphertext and the latter is MACed (with SKEYID_a/SKEYSEED_a) that's fine too. Just MAKE SURE that in the design process the ID stays there. Also make sure that the spec clearly documents the need for this ID to be there. BTW, as for my emphatic response to Dan as you quote, what it means is that covering the ID by the signature is no replacement for covering it with the MAC. SIgnature and MAC have different roles here. Hugo On Fri, 14 Dec 2001, Andrew Krywaniuk wrote: > > Andrew, I am glad you keep insisting in understanding this, > > and I am sorry for not being clear. Below is another try > > ... > > > Indeed, I never explained why signing the MAC of the identity is > > essential. You know why? Because it is NOT. (And I never said > > it was.) The > > only ESSENTIAL thing is that the MAC be applied to the identity! > > > I went back through the archives to try to determine the source of this > confusion. > > Dan said: > > > In this case IDi would be signed by each party. Since you're proposing > > putting all things, including IDi, into the signed hash anyway why is it > > dangerous to add just IDi to the mix of exponentials and nonces? > > and you replied: > > > IT IS VERY DANGEROUS! DOING WHAT YOU SUGGEST IS INSECURE! > > In this case, a buffer containing IDi would be signed by each party, but > using the PCKS#1 format which also involves a hashing step. Wouldn't this be > secure? > > (I see from the context that this discussion was relating to the potential > "outer id", rather than the "inner id"). > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > From owner-ipsec@lists.tislabs.com Fri Dec 14 04:38:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBECc1224810; Fri, 14 Dec 2001 04:38:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26138 Fri, 14 Dec 2001 06:52:41 -0500 (EST) Message-ID: <001301c18498$15dfabc0$d7204789@skeisamd01> From: "Suresh Singh K." To: =?iso-8859-1?Q?Kerem_=D6nal?= , References: <005201c1847d$d4c6eeb0$69f77a90@bilten.metu.edu.tr> Subject: Re: Date: Fri, 14 Dec 2001 17:38:37 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C184C6.298A6010" 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C184C6.298A6010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Karem, The IKE author's have given more flexibility in which = the Key Exchange protocol can be different for Both Phase (I & = II),providing different level of security. Other than that I believe = it's redundancy.=20 Suresh ----- Original Message -----=20 From: Kerem =D6nal=20 To: ipsec@lists.tislabs.com=20 Sent: Friday, December 14, 2001 2:30 PM Hi, My question is about ike. In quick mode, why do we have to send an = information about the oakley groups if we have already sent it in main = mode and use it for quick mode also? Am I right? =20 Thanks in advance Kerem=20 ------=_NextPart_000_000E_01C184C6.298A6010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Hi Karem,
          &nbs= p;     =20 The IKE author's have given more flexibility in which the Key Exchange = protocol=20 can be different for Both Phase (I & II),providing different = level of=20 security. Other than that I believe it's redundancy. =
 
 Suresh
----- Original Message -----
From:=20 Kerem =D6nal
To: ipsec@lists.tislabs.com
Sent: Friday, December 14, 2001 = 2:30=20 PM

Hi,
 
My question is about ike. In quick = mode, why do=20 we have to send an information about the oakley groups if we have = already sent=20 it in main mode and use it for quick mode also? Am I = right?
 
Thanks in advance
Kerem 
 
------=_NextPart_000_000E_01C184C6.298A6010-- From owner-ipsec@lists.tislabs.com Fri Dec 14 06:12:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEECi201246; Fri, 14 Dec 2001 06:12:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26274 Fri, 14 Dec 2001 08:27:36 -0500 (EST) Reply-To: From: "Awan Kumar" To: "IpsecMailingList (E-mail)" Subject: IPSec and Cryptograhic accelerator Date: Fri, 14 Dec 2001 19:03:20 +0530 Message-Id: <001c01c184a3$e6035bc0$0702060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anybody provide some pointers to the API's avaliable for the use of IPSec with the cryptograhic processor. Are there any standard API's available which the vendors implement. If not, is there any plan to use API's similar to the one specified in RFC 2628. I would be thankful if anybody could provide me some information regarding the same. Thanks and Regards, Awan ---------------------------- Awan Kumar Sharma Future Software Ltd., Chennai, India. Ph: 4330 550 Extn: 437 (www.futsoft.com) ------------------------------ From owner-ipsec@lists.tislabs.com Fri Dec 14 06:48:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEEm7203774; Fri, 14 Dec 2001 06:48:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26432 Fri, 14 Dec 2001 09:11:46 -0500 (EST) Message-ID: <3C1A0AA1.FD78A4EE@F-Secure.com> Date: Fri, 14 Dec 2001 16:20:17 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jayant Shukla CC: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT traversal References: <000001c1841c$f596dc60$0101a8c0@trlhpc1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2001 14:20:17.0488 (UTC) FILETIME=[74609D00:01C184AA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant Shukla wrote: > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > > On Behalf Of Ari Huttunen > Didn't your original draft use RSIP? From the section 6 of your original > draft (expired Jan 2001), it seems to me that it is based on RSIP > principle and UDP encapsulation. So you cannot deny a connection to "NAT > people"! Of course your new drafts have gotten rid of RSIP. No RSIP was implied in that or any later draft. RSIP requires co-operation by NAT boxes, and we've assumed that NAT boxes are 'hostile' entities that don't want to co-operate. It's not that way in some cases, but in a hotel room type of scenario it will be. > Why does IKE have to move to another port? This is your kludge which > forces you to do nasty stuff like this. It doesn't, that's why it's not specified in the drafts right now. The whole point is that *IF* IKEv2 moves to a non-500 port, we can optimize the encapsulation. The reason to move should not be NAT traversal, but other possible reasons. I'm not claiming there are such, but it seemed to be implied. > p.s.: BTW, I have notified IETF about your new drafts infringing on our > intellectual property. Well, drafts or RFCs do not 'infringe' on patents. Patent applications on the other hand are not yet even 'intellectual property', they're just applications. Only products can infringe on patents. In any case, when I see that statement I can add a generic reference to it in the encapsulation draft. If it has an affect to the acceptance of our drafts is not a question for me to worry about. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Fri Dec 14 11:16:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBEJG4221861; Fri, 14 Dec 2001 11:16:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27710 Fri, 14 Dec 2001 13:08:17 -0500 (EST) Date: Fri, 14 Dec 2001 13:17:38 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: IKEv2 traffic selector subsetting. In-Reply-To: <000a01c1847a$1bb4e100$44c6830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 14 Dec 2001, Andrew Krywaniuk wrote: > ...If you > wish to avoid sending traffic that will be filtered out by the peer then > that would be best accomplished by an IPSP protocol. I.e., "by some hypothetical protocol yet to be defined". It's better to solve the problem than to pretend that someone somehow will deliver a solution when required. IKE has demonstrated that simple solutions are adequate for many purposes. Deliberately excluding this from son-of-IKE may be ideologically preferable but makes no sense as a matter of practical engineering. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sun Dec 16 16:39:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH0dr203736; Sun, 16 Dec 2001 16:39:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03083 Sun, 16 Dec 2001 18:39:47 -0500 (EST) Message-Id: <200112152108.fBFL8sx01727@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: ikev2 questions arising from Radia's presentation In-reply-to: Your message of "Fri, 14 Dec 2001 01:36:02 EST." <000401c1847a$110102c0$44c6830c@andrewk3.ca.newbridge.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 15 Dec 2001 16:08:54 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> I thought this was apparent from the draft. See appendix B: Andrew> The encryption and integrity protection algorithms are the same as Andrew> those available to the ESP protocol, through their application is Andrew> slightly different. Whereas in ESP the header that is integrity Andrew> protected but not encrypted is a total of 8 bytes (SPI+Sequence #) Andrew> plus the IV, in IKE it is the IKE Header which is 28 bytes plus the Andrew> IV (see section 7.1). okay, so it is covered. It should probably be covered in the body. "The ESP-like AUTH header covers the entire message, including the IKE header" ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Sun Dec 16 16:39:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH0dr203738; Sun, 16 Dec 2001 16:39:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03084 Sun, 16 Dec 2001 18:39:48 -0500 (EST) Message-Id: <200112152013.fBFKDcc01013@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: fragmentation In-reply-to: Your message of "Thu, 13 Dec 2001 17:54:47 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 15 Dec 2001 15:13:37 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sami" == Sami Vaarala writes: >> This fails if there is ICMP hole between the near gateway and the >> originator. This is actually a very common occurance when one has an extruded >> host/subnet (i.e. the default route for the road warrior is through the >> tunnel) since the "other side" is the entire Internet. Sami> I see I misread this before, you are talking about a different problem Sami> than I was. What I meant originally is to fix the problem that occurs Sami> between IPsec endpoints, not between the actual sender and receiver. If you can fix the MTU between the endpoints (taking into account the tunnel), then you solve the problem with the tunnel. I agree that fixing this may be impossible. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Sun Dec 16 16:39:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH0ds203758; Sun, 16 Dec 2001 16:39:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03096 Sun, 16 Dec 2001 18:40:58 -0500 (EST) Message-Id: <200112152017.fBFKHAo01063@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: draft minutes from second session Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 15 Dec 2001 15:17:09 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk {sorry, I mistyped tislabs on Thursday when I sent this out the first time} IETF #52 - IPsec WG meeting Thursday December 13th Salt Lake City Meeting opened at 9:06am in Grand B. 1) JFK presentation from Steve Bellovin (draft-ietf-ipsec-jfk-00.txt) a) JFK design process presentation. Clarification that "pre-shared key" (PSK) refers to pre-shared SECRET key. b) JFK details presentation from Angelos Keromytis (clarification: one slide has both g^i/g^r and g^x/g^y. Let i=x, r=y.) code for Java/C/Perl implementations was done. Java versions interoperated, but not with C/Perl due to crypto library issues. Overview of LBJ (Less Bulky-Joint) protocol. Eric R: JFK makes a tradeoff - imperfect forward secrecy. if you want PFS, then you have to keep state on message 1. AK: you do not need to keep state. You do need to take a DH hit each time, but with hardware that may be okay. Eric: that's not PFS really. AK: agreed. Comparison conversation cut short. PM: what about performance Unknown: would IKEv1 be able to maintain code on the payload basis? AK: the protocol itself has not mandated any particular payload encoding. PHK: identity protection - you can work it out from the IPs. SB: general question, moved later. Unknown: there is a perception that the only thing that phase 2 is good for is rekey. There is also Delete, Notify, dead-peer detection. Amortization is benefit. SB: goes back to requirements. 2) IKEv2 presentation - Radia Perlman (draft-ietf-ipsec-ikev2-00.txt) HO: the stateless cookie concern? Has anyone done an analysis of stateless vs stateful cookies. only a back of the envelope one. HO: rekeying of each IKE SA should be done with PFS? RP: you could do that, of course, but they key is that you don't have to delete child SAs. SB: other working groups have found that the critical bit often encourages vendors to gratuitously set it to cause interop problems. RP: you can always make broken implementations. 3) SIGMA: SIGN-and-MAC. Crypto rationale and proposals presented by Sara Bitman http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt 4) Engineering Tradeoffs in keying systems Charlie Kaufman There was a discussion about whether or not JFK could negotiate on algorithms. SB asserts that if it wasn't clear from the document that this is bug in the document - the protocol does support it. 5) performance numbers Eric Rescorla 6) overview of protocol requirements Cheryl Madson 7) open mic Jeff Forum - there should not be too much policy provisioning in IKE. - it should only be related to the IPsec tunnel being established. CM: e.g. the address of the WINS server should be necessary to get a tunnel up. HO: move all policy stuff into a seperate protocol. (ipsp) WD: this is the most important discussion. Different scenarios provide different requirements. If we can ever replace TLS, then clearly responder identity protection is not important there. But other responders may want MT: my observations is that the problems with IKE are protocol problems, not cryptographic problems. The presentations this morning suggest the opposite. Being able to recover from reboot avalanche at concentrator boxes is a very important thing. Being able to amortize work across the duration of the user is important. PHK: designing the protocol is the easy part, getting the requirements right is the hard part. XCASS is a serious proposal in the XML world. May not match the IPsec requirements - identity protection may be a meaningless requirement if the credentials are not related to identity. PH: thanks Cheryl. There will be a transition time when this comes out. A requirement is co-existance with IKEv1. SB: we think that the crypto needed attention as well as the protocol. I had hoped to have a draft on interop for IKEv1 on the protocol level. K: it seems that IKEv2 and JFK have different mechanisms for negotiating SAs. Were there different requirements among the groups? SB: i'd rather the working group decide what the requirements are. JFK wants to do: "I: this is what I want. R: yes/no-explanation." IKEv2 is a good start towards this as well. JFK wants to get rid of negotiations that are not necessary. e.g: Let's not have 16 ways to do IP addresses RP: all of this can be worked out. An even simpler way is TLS - here are four suites, rather than 16 combinations. If we can lock down one suite, then that would win, but seems too non-flexible. WD: counter example to website. Microsoft home employee systems are being targetted, so they don't want to reveal that they are in fact employees. (CB response that agrees) unknown: response to PM, if not co-existence, then a transition document. ER: the documents seem to all be willing to mutate. traditional approach has been to start with Crypto and build a protocol. Let's start the other way - do the protocol first, and then install the crypto. unknown: authentication requirement for asymmetric non-public key is important. unknown: scoping is important. is the list everything? Or just a start? do we know where IKE is not useful for? CB: I've put the ones we have to deal with. Often if a protocol doesn't have security, then they should use IPsec, keyed by IKE. But this isn't always the right answer. CK: parable of the Donkey who starved himselves because he was standing precisely between two bails of hay. raises issue of choice of encoding. negotiation of parameters - IKEv1 99,000 possibilities. JFK was precise. SB said that they could do negotiation. Raises question about whether this will be secure. Suggests that we should have a suite approach (we would specify suite 1 in this spec). Vanity crypto could do vendor-ID. CB: if we did things by suites, analysis would be easier. unknown: credential management and delivery. It is important that we carry credentials in the protocol. We can do PSK or certificate usage. No difference to us. On the other side, when we try to deploy the service, we get problems. We chose PSK because it was cheap and simple. JI: we are no closer to getting requirements than a hour ago. There are three sets of (meta)-requirements: - cryptographic requirements (PK, PSK, etc..) - operational requirements (rekeying, blackhole detection, etc..) - policy requirements (how to negotiate things) Barbara: this is a useful thing. DH: the proposals were very complex because we wanted to support very complicated underlying things. JS: sees good work. "parable of the WG who sat between two proposals whose AD eventually shut it down." considers asking for Minneapolis deadline, but sees that realistic. AD asks for plan from chairs. "We want to see results" Meeting closed at 11:35. ER = Eric Rescorla HO = Hilerie Orman AK = Angelos Keromytis SB = Stephen Bellovin PHK= Phillip Hallam-Baker PM = Perry Metzger SRB= Sara Bitman CM = Cheryl Madson WD = William Dixon MT = Michael Thomas PH = Paul Hoffman K = Katherine $Id: ipsec-meeting2-minutes.txt,v 1.1 2001/12/13 18:36:33 mcr Exp mcr $ From owner-ipsec@lists.tislabs.com Sun Dec 16 16:39:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH0ds203759; Sun, 16 Dec 2001 16:39:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03095 Sun, 16 Dec 2001 18:40:56 -0500 (EST) Message-Id: <200112152010.fBFKAMg00948@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: fragmentation In-reply-to: Your message of "Thu, 13 Dec 2001 17:39:05 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 15 Dec 2001 15:10:21 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sami" == Sami Vaarala writes: Sami> Since you can't rely on getting an icmp when your packet Sami> is too large, and you can't be certain that frags pass Sami> through routers, what is left? >> [...] >> This fails if there is ICMP hole between the near gateway and the >> originator. This is actually a very common occurance when one has an extruded >> host/subnet (i.e. the default route for the road warrior is through the >> tunnel) since the "other side" is the entire Internet. Sami> Exactly. What I was saying was that maybe we shouldn't rely on Sami> icmp. Yes, you can always say it's the clueless X that's the fault, Sami> but the end result is that the tunnel isn't working as it's supposed Sami> to be. In further in person discussion with William Dixon in the lounge, we discussed the various things to do. To recap: My proposal was to have the receiving (decap end) of the tunnel note the largest sized fragment received. {If there are fragment loss issues where every fragmented packet is lost (due to stupid midcom boxes), then perhaps this should be done in general - note the largest packet received period.} This information would be sent *through* the tunnel via ICMP Datagram Too Big message to the originator of the packets to get them to reduce their MTU. This packet would fit (policy-wise) by forging the source address (if necessary) to be that of the destination address seen. As discussed in this thread, there are often ICMP blackholes on the that are between the end nodes and the gateway, so this doesn't guarantee that the MTU will be reduced. The further proposal is that one might ignore the DF bit, fragment the packet going into the tunnel first (before ESP processing), producing ESP packets that do not need to be fragmented. The question is then, what is the MTU of the tunnel, given that all fragments get lost, and that ICMPs generated from DF-set are filtered, etc. Sami> What I proposed was using an encrypted, ping-like protocol. Don't Sami> rely on any icmp information (or lack of it) that you get from between Sami> the IPsec endpoints. Instead, to ensure that you can pass a packet Sami> of 1234 bytes between the endpoints, send an encrypted ping (or whatever) Sami> of that size; if you get a reply, you can do that. Otherwise, you Sami> can't (have to send a few retries, of course). No need to rely on icmp. That's an idea, but I suggest that one fragments actual data. Start with a permitted MTU of 576. The above mechanism (of putting ICMP Datagram too big into the tunnel periodically by the decap end) can be used. There are several choices here: a) put a second ICMP in, addressed to the sending gateway. (problem - doesn't fit into the tunnel policy). The quoted of the packet would be constructed to show the SPI of the sender. b) have the sender eavesdrop on decapsulated packets, looking for ICMP Need Fragments. c) have the information sent in an IKE notify. a/b have the advantage that they apply to all tunnels, not just IPsec ones. This would really be a revision to RFC2003. Whereas (c) is key daemon specific. In general, this is easy for BITS implementations as they have to deal with the fragments anyway. For implementations that get their ESP packets at a transport layer interface, then changes to the stack may be required to note the fragment information. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPBuuLIqHRg3pndX9AQHTtAQAmLMHCPyHbOzRkpXvzlegT2+w3Y36bslp nx5pCy90pM0KOKL1vaP/s9i+hStbu3+W62TBG6mCKQi8amwo5IJ2tn/yMZBI3pTr 28p3425e/1sd6Mwt5DhuZydSFusukAYCiLS98GOOWUkirlIl0TlGzK9VYl1g87po L38F58fJC8g= =RZ4r -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Dec 16 18:37:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH2bY208713; Sun, 16 Dec 2001 18:37:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03479 Sun, 16 Dec 2001 20:55:53 -0500 (EST) Message-Id: <200112170205.VAA02738@bcn.East.Sun.COM> Date: Sun, 16 Dec 2001 21:05:48 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Should Alice say who she wants to talk to? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2f7SUz94oS0njNl2e9oA7A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was wondering about how IPsec might support having a bunch of services hosted at the same IP address, or even hosted behind a firewall, but all accessible through the firewall's IP address. SSL/TLS doesn't do this either, but it seems like it might be a useful thing. The idea is that there would be a whole bunch of services, all reachable to the world through a single IP address. IKE would have some port (500 say). It can connect Alice to a bunch of services, say foo and bar. When Alice connects to port 500 she says (probably in message 1 of the handshake), "I'd like to talk to service foo", and the IKE process (which must have certificates and keys for each of the services) uses that to know what certificate and key to use, i.e., which "Bob" persona to take on. And if people are worried about plausible deniability, Alice need not sign Bob's name (IKEv2 says "sign everything in messages 1 and 2, but that's because Bob's name isn't there right now...if it were, then Alice could sign everything except Bob's name, and add Bob's name into the integrity check in message 3). This would be an optional field in message 1, and obviously won't hide Bob's identity. Note that HTTP 1.1 has this feature of allowing Alice to say who she wants to talk to. Radia From owner-ipsec@lists.tislabs.com Sun Dec 16 21:02:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBH529211276; Sun, 16 Dec 2001 21:02:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03812 Sun, 16 Dec 2001 23:06:03 -0500 (EST) To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? References: <200112170205.VAA02738@bcn.East.Sun.COM> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Dec 2001 20:15:15 -0800 In-Reply-To: Radia Perlman - Boston Center for Networking's message of "Sun, 16 Dec 2001 21:05:48 -0500 (EST)" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking writes: > I was wondering about how IPsec might support having a bunch > of services hosted at the same IP address, or even hosted > behind a firewall, but all accessible through the firewall's IP address. > SSL/TLS doesn't do this either, but it seems like it might be > a useful thing. This is probably the number one requested extension to SSL/TLS and is currently winding it's way through the standards process. It seems to me that this would be a nice feature to have in IPsec. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Dec 17 09:29:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHHTc213689; Mon, 17 Dec 2001 09:29:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05617 Mon, 17 Dec 2001 11:22:34 -0500 (EST) Message-Id: <200112171632.fBHGWSXt023442@thunk.east.sun.com> From: Bill Sommerfeld To: Radia Perlman - Boston Center for Networking cc: ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-Reply-To: Your message of "Sun, 16 Dec 2001 21:05:48 EST." <200112170205.VAA02738@bcn.East.Sun.COM> Reply-to: sommerfeld@east.sun.com Date: Mon, 17 Dec 2001 11:32:27 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I was wondering about how IPsec might support having a bunch > of services hosted at the same IP address, or even hosted > behind a firewall, but all accessible through the firewall's IP address. This is a reasonable request. For one take on this in the IKEv1 context, see draft-keromytis-ike-id-00.txt. Disclaimer: I'm a co-author. Claimer: I've heard interest in this from other folks. - Bill From owner-ipsec@lists.tislabs.com Mon Dec 17 12:31:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHKVV222337; Mon, 17 Dec 2001 12:31:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06070 Mon, 17 Dec 2001 14:25:40 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698D8@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ipsec@lists.tislabs.com Subject: RE: IKEv2 and NAT traversal Date: Mon, 17 Dec 2001 11:36:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18732.10B13CD0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C18732.10B13CD0 Content-Type: text/plain; charset="iso-8859-1" I am attempting to get down to the core argument here. It appears to me that the significance of Son of IKE wrt NAT is that it is an oppotunity to do the right thing ab initio, and hence avoid much of the complexity of retrospective NAT fixes for IKE. The ability to support NAT reliably is likely to become the main value add that son-of-IKE provides to end users. This is because support for NAT translates into 'ability to use the ethernet connection in a hotel room or the 802.11B in the Red Carpet Club and Starbucks'. It is disappointing that there is still a faction still peddling the 'if you are NAT on the NET you are not on the NET' dogma. NAT is what you get when you architect a network with a built in upper bound of 4 billion addresses on a planet with a human population of ten billion, it fixes a bug in the design of the Internet that was introduced so that an IP address would fit in a register on a long defunct machine, end of story. The core problem with NAT is that packets appear from an IP address which is not the one that the sender expects. This causes other fields on the packet to arrive damaged, including the checksum. One solution to this that occurs to me is to modify the key agreement so that the sender tells the reciever the IP address that they believe that they are using and the responder tells the sender the one that it sees. This information is stored in the SA/SPD or NTLA (New Three Letter Acronym), permitting the responder to affect repairs to the said damaged packets. The main issue here is whether commonly deployed NATs perform any harm to the packets that cannot be repaired with knowledge of the IP address. I am less bothered by the secondary points in the requirements document about applications that rely on IP addresses embedded in protocols. I suspect that such protocols break anyway when they pass through the current generation of NAT. The only way to make them work well would be to devise some protocol to support requests from a client to open up ports on the NAT - which would typically be left turned off because NAT boxes are often serving as firewalls. The other security issue to consider is that NAT is often installed specifically to conceal the details of the internal network configuration from external parties. This is not a solution that is open if you are not already messing with the key agreement. Once the key agreement is on the table however it is important to take the opportunity to do the right thing. At present we do not have a true IPSEC deployment, we have a VPN deployment that uses IPSEC in a network, but we are not at the 'network of netowrks' level, still less anywhere close to an Internet secured at the packet layer (which is a necessary but not sufficient condition for a secure internet). I suspect that before we get to ubiquitous deployment of IPSEC that the protocol will morph in several ways, replacement of IKE being one, dropping AH mode being another, junking the vanity crypto (or at least the unnecessarily complex negotiation mechanisms support for vanity crypto requires). Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > ------_=_NextPart_000_01C18732.10B13CD0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C18732.10B13CD0-- From owner-ipsec@lists.tislabs.com Mon Dec 17 13:45:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHLj9227082; Mon, 17 Dec 2001 13:45:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06344 Mon, 17 Dec 2001 16:06:24 -0500 (EST) Date: Mon, 17 Dec 2001 23:15:07 +0200 From: Sara Bitan Subject: Re: Should Alice say who she wants to talk to? To: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Message-id: <002c01c1873f$e8541b00$f24c5ac2@commagine.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200112170205.VAA02738@bcn.East.Sun.COM> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia - why aren't the (IKEv2 analog to) phase II IDs sufficient to handle that scenario you are describing? Does each one of the services/ the hosts behind the firewall have a distinct private/public key pair? And another comment: if you move IDr to message number 1, and the initiator doesn't sign it since you want to avoid introducing NR, then the protocol is exposed to the DVW attack. As you said, the simple algorithm that IKEv2 uses "sign messages 1 and 2, and integrity protect messages 3 and 4" doesn't work any more, hence you must add the responder's identity explicitly to the MAC calculation in message 3. I think that the option that you are proposing to add to IKEv2 is a good motivation to adopt SIGMA's way of explicitly MACing the identities. If the protocol specifies all the components that ensure the correctness of the key exchange cryptographic protocol (i.e. the MAC'd identities and signed public exponent and nonces) explicitly, then you have the advantage of moving IDs and exponents (almost) freely between messages without the risk of breaking the protocol. If we will not include the identities explicitly under the MAC we will have to always twick the protocol to keep it secure, and ask the cryptographers to prove that the twicks are indeed not breaking the protocol. Sara. ----- Original Message ----- From: Radia Perlman - Boston Center for Networking To: Sent: Monday, December 17, 2001 4:05 AM Subject: Should Alice say who she wants to talk to? > I was wondering about how IPsec might support having a bunch > of services hosted at the same IP address, or even hosted > behind a firewall, but all accessible through the firewall's IP address. > SSL/TLS doesn't do this either, but it seems like it might be > a useful thing. > > The idea is that there would be a whole bunch of services, all reachable > to the world through a single IP address. IKE would have some > port (500 say). It can connect Alice to a bunch of services, say > foo and bar. When Alice connects to port 500 she says (probably > in message 1 of the handshake), "I'd > like to talk to service foo", and the IKE process (which must have > certificates and keys for each of the services) uses that to know > what certificate and key to use, i.e., which "Bob" persona to take on. > > And if people are worried about plausible deniability, Alice need not > sign Bob's name (IKEv2 says "sign everything in messages 1 and 2, but > that's because Bob's name isn't there right now...if it were, then Alice could > sign everything except Bob's name, and add Bob's name into the > integrity check in message 3). > > This would be an optional field in message 1, and obviously won't > hide Bob's identity. > > Note that HTTP 1.1 has this feature of allowing Alice to say who she > wants to talk to. > > Radia > From owner-ipsec@lists.tislabs.com Mon Dec 17 13:45:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHLjI227093; Mon, 17 Dec 2001 13:45:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06290 Mon, 17 Dec 2001 15:32:45 -0500 (EST) Date: Mon, 17 Dec 2001 15:42:10 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: IKEv2 and NAT traversal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058698D8@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Dec 2001, Hallam-Baker, Phillip wrote: > The ability to support NAT reliably is likely to become the main value add > that son-of-IKE provides to end users. I think that's only one of several issues, and would note better performance and explicit support for more complex tunnel endpoints (not just a single subnet on each end) as others. But NAT traversal certainly is significant. > It is disappointing that there is still a faction still peddling the 'if you > are NAT on the NET you are not on the NET' dogma. NAT is what you get when > you architect a network with a built in upper bound of 4 billion addresses > on a planet with a human population of ten billion, it fixes a bug in the > design of the Internet... Uh, no. The bug is *fixed* by larger addresses, e.g. IPv6. NAT is a kludge, a workaround, with serious disadvantages. That said, it is (unfortunately) a popular and widespread kludge which cannot be ignored, much though that would simplify life. >that was introduced so that an IP address >would fit in a register on a long defunct machine... The Internet infrastructure machines at the introduction of IPv4 did not have 32-bit registers. Try 16. The size of the IPv4 address was set by considerations of design, not implementation. Unfortunately, the design situation looked very different then than it does now, and tradeoffs which seemed good then are proving problematic now. > One solution to this that occurs to me is to modify the key agreement so > that the sender tells the reciever the IP address that they believe that > they are using and the responder tells the sender the one that it sees... > permitting the responder to affect repairs to the said damaged packets. Care would be needed to avoid chicken-and-egg problems here -- the information needed to make repairs can't be exchanged by mechanisms which assume repair is already possible! That said, this has potential. > I am less bothered by the secondary points in the requirements document > about applications that rely on IP addresses embedded in protocols. I > suspect that such protocols break anyway when they pass through the current > generation of NAT... No, they don't, because current-generation NAT software contains special kludges to fix the packets of such protocols. This is not easy to do, and it relies on imperfect heuristics, but it works well enough that (like NAT itself) it cannot be ignored. Note that FTP is among the affected protocols. However, in most IPsec situations there is little that can be done about it. There simply is no way to do benign surgery on packet innards without causing IPsec authentication failures, even if you have access to the innards at all, which you don't if they're encrypted. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 14:13:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMDs227930; Mon, 17 Dec 2001 14:13:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06377 Mon, 17 Dec 2001 16:25:15 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15390.25837.375560.453985@thomasm-u1.cisco.com> Date: Mon, 17 Dec 2001 13:34:37 -0800 (PST) To: ipsec@lists.tislabs.com Subject: authentication state capture 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 At the meeting, I questioned the design decision of JFK to simplify by doing away with Main/Quick modes in favor of a single exchange which always reauthentictes. The problem that I brought up is that it's not just rekeying which matters. DELETE's, dead peer detection and restart avalanches are also a concern. I also mentioned that neither IKEv1/v2 or JFK deal with restart avalanches very well. I think there's middle ground here as demonstrated by KINK. KINK has single round trip SA operations which always use symmetric key authenticators, even if initial authentication was done using public key operations (eg PKINIT). Since KINK uses Kerberos, it benefits from Kerberos' ticket issuing mechanism which effectively captures the public key initial authentication into a state blob which the client holds, and can sign authenticators against. This ability gives KINK much better restart avalanche behavior since a server/KDC going down does not require expensive public key crypto to perform the authentication phase again so long as a ticket is valid. I think that SOI would be greatly facilitated by taking a similar middle ground. I don't care whether it uses Kerberos mechanisms as it's the technique that's important, not the bit encoding. Thus, I think there should be a requirement: "The protocol MUST provide a facility to capture expensive authentication operations into state blobs created by the responder and held by the initiator, which can be used in subsequent SOI protocol operations such as rekeying, SA maintenance, etc, and MUST be usable for a configurable length of time even if the responder loses state or reboots." Mike From owner-ipsec@lists.tislabs.com Mon Dec 17 14:20:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMKp228278; Mon, 17 Dec 2001 14:20:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06395 Mon, 17 Dec 2001 16:31:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <000a01c1847a$1bb4e100$44c6830c@andrewk3.ca.newbridge.com> References: <000a01c1847a$1bb4e100$44c6830c@andrewk3.ca.newbridge.com> Date: Mon, 17 Dec 2001 16:38:23 -0500 To: From: Stephen Kent Subject: RE: IKEv2 traffic selector subsetting. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:55 AM -0500 12/14/01, Andrew Krywaniuk wrote: >To add to this conversation, I would like to debunk this myth that the IPsec >SADB selectors need to match the IPsec policy. > >The SPD, not the SADB, is supposed to enforce IPsec policy. As someone >noted, it does no good to repeat the information in the SPD in the SA >selectors, since that traffic will be filtered out by the SPD anyway. If you >wish to avoid sending traffic that will be filtered out by the peer then >that would be best accomplished by an IPSP protocol. > >The point of the phase 2 selectors is to enforce that (often ignored) 3rd >aspect of network security: authorization. We want to bind the phase 2 >selectors to the phase 1 identity so that authenticated peers cannot >impersonate each other. The use of the phase 2 selectors allows the >per-packet SPD check to proceed without consulting the SADB (because the >initial SADB check is sufficient for verifying that the phase 1 id is >appropriate). > >This is an *OPTIMIZATION*. It is feasible to negotiate wildcard SAs (or >transport mode SAs for an IP-in-IP tunnel) *iff* you do a phase 1 identity >check on every packet (i.e. pass the SA context information up the stack). I think this is a critical optimization, and in the next rev of 2401, I plan to use a processing model that caches selector info from a (de-correlated) SPD. Searching the SPD for each new outbound packet, or for inbound packets after processing, is not attractive (maybe not even feasible) at very high speeds. > >Port-constrained SAs make sense in the case of a multi-user UNIX machine >where the phase 1 id associated with port FOO is not necessarily the same as >the id on port BAR. Port-constrained selectors are NOT the best mechanism >for implementing packet filtering. In the vast majority of VPN scenarios, a >list of subnets would be appropriate for expressing phase 2 selectors. I disagree. Port filtering is appropriate in IPsec for the same reasons it is appropriate in a firewall, i.e., a reasonable security policy may wish to constrain traffic from a specified source to a specific destination relative to a set of services offered by the destination. So, for example, I may wish to bypass traffic from any outside source directed to my SMTP server, but I want all such traffic to be SMTP traffic, to reduce the likelihood that the server can be attacked by external sources sending other types of traffic. Steve From owner-ipsec@lists.tislabs.com Mon Dec 17 14:27:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMR8228580; Mon, 17 Dec 2001 14:27:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06414 Mon, 17 Dec 2001 16:40:41 -0500 (EST) Message-Id: <200112172150.fBHLo7Xt026599@thunk.east.sun.com> From: Bill Sommerfeld To: Sara Bitan cc: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-Reply-To: Your message of "Mon, 17 Dec 2001 23:15:07 +0200." <002c01c1873f$e8541b00$f24c5ac2@commagine.net> Reply-to: sommerfeld@east.sun.com Date: Mon, 17 Dec 2001 16:50:07 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Does each one of the services/ the hosts behind the firewall have a distinct > private/public key pair? potentially, yes. - Bill From owner-ipsec@lists.tislabs.com Mon Dec 17 14:27:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMRl228607; Mon, 17 Dec 2001 14:27:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06434 Mon, 17 Dec 2001 16:45:52 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698DB@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Henry Spencer'" , IP Security List Subject: RE: IKEv2 and NAT traversal Date: Mon, 17 Dec 2001 13:55:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18745.94FEE330" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C18745.94FEE330 Content-Type: text/plain; charset="iso-8859-1" > On Mon, 17 Dec 2001, Hallam-Baker, Phillip wrote: > > The ability to support NAT reliably is likely to become the main value add > > that son-of-IKE provides to end users. > > I think that's only one of several issues, and would note better > performance and explicit support for more complex tunnel > endpoints (not just a single subnet on each end) as others. But NAT > traversal certainly > is significant. People typically deploy new versions of software because they need to rather than for performance alone. > Uh, no. The bug is *fixed* by larger addresses, e.g. IPv6. NAT is a > kludge, a workaround, with serious disadvantages. That said, it is > (unfortunately) a popular and widespread kludge which cannot > be ignored, > much though that would simplify life. A fix is deployable. NAT appeared because IPv6 was not deployable when the consequences of address depletion began to be felt. > >that was introduced so that an IP address > >would fit in a register on a long defunct machine... > > The Internet infrastructure machines at the introduction of > IPv4 did not > have 32-bit registers. Try 16. The size of the IPv4 address > was set by > considerations of design, not implementation. According to Tom Knight who attended the relevant meeting the size of the registers in a particular model of PDP was used to justify the address size, against protests that it was insufficient. > No, they don't, because current-generation NAT software > contains special > kludges to fix the packets of such protocols. This is not > easy to do, and > it relies on imperfect heuristics, but it works well enough > that (like NAT > itself) it cannot be ignored. Note that FTP is among the > affected protocols. I find it somewhat anoying that people who complain about the 'evils' of HTTP can ignore the obvious limitations and inefficiency of FTP which is actually worse on every scale than HTTP requiring two TCP connections and multiple round trips to negotiate a single file transfer. > However, in most IPsec situations there is little that can be > done about > it. There simply is no way to do benign surgery on packet > innards without > causing IPsec authentication failures, even if you have access to the > innards at all, which you don't if they're encrypted. I think that we need to focus on the parts of a protocol that can reasonably be expected to work through a NAT box and those which simply should not be expected to work without specific configuration of the NAT box and possibly the application. Nobody should expect to be able to run an FTP server over IPSEC that is behind a NAT box for example. But running an FTP client for direct retrieval is reasonable. Phill ------_=_NextPart_000_01C18745.94FEE330 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C18745.94FEE330-- From owner-ipsec@lists.tislabs.com Mon Dec 17 14:45:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMjd201163; Mon, 17 Dec 2001 14:45:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06508 Mon, 17 Dec 2001 17:09:05 -0500 (EST) Date: Mon, 17 Dec 2001 17:18:28 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: IKEv2 and NAT traversal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058698DB@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Dec 2001, Hallam-Baker, Phillip wrote: > People typically deploy new versions of software because they need > to rather than for performance alone. Performance is sometimes a "need to" issue, especially when the issue is not throughput but response time. > > Uh, no. The bug is *fixed* by larger addresses, e.g. IPv6. NAT is a > > kludge, a workaround, with serious disadvantages [although important] > > A fix is deployable. NAT appeared because IPv6 was not deployable > when the consequences of address depletion began to be felt. Fixes often are not deployable immediately. That's why we have the very concept of a workaround! A fix generally provides the same functionality as the thing it is fixing. NAT does not. For example, it is basically impractical to put a system with servers behind a NAT. (Remember that "server" doesn't have to mean a huge public utility -- the service it offers can be as minor as accepting SMTP mail for one address.) > > The Internet infrastructure machines at the introduction of > > IPv4 did not have 32-bit registers. Try 16. The size of the > > IPv4 address was set by > > considerations of design, not implementation. > > According to Tom Knight who attended the relevant meeting > the size of the registers in a particular model of PDP was > used to justify the address size, against protests that it > was insufficient. I think you may be misremembering what he said. There were no PDPs with 32-bit registers. None, ever. 12, 16, 18, and 36, yes, but not 32. And it's a matter of public record that the original IMPs were 16-bit machines (and were not PDPs). > I think that we need to focus on the parts of a protocol that > can reasonably be expected to work through a NAT box... Agreed. > Nobody should expect to be able to run an FTP server over IPSEC > that is behind a NAT box for example. But running an FTP client > for direct retrieval is reasonable. And equally impossible, if the packets are encrypted so the NAT box cannot edit them. This is a significant issue for IPsec-NAT combinations, perhaps somewhat mitigated by the now-widespread use of HTTP for anonymous file transfer and SSH for private file transfer. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 14:48:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMm4201351; Mon, 17 Dec 2001 14:48:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06487 Mon, 17 Dec 2001 17:01:14 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058698DB@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4058698DB@vhqpostal.verisign.com> Date: Mon, 17 Dec 2001 17:06:49 -0500 To: "Hallam-Baker, Phillip" From: Stephen Kent Subject: RE: IKEv2 and NAT traversal Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As one of the folks who was involved in the address space size decisions in the late 70s and early 80s, I can confirm that the 32 bit size was chosen because of register/word sizes in current machines, including IBM, DEC, and others. Danny Cohen, at ISI, tried to persuade folks of the wisdom of variable length IP addresses, but we were very concerned about the performance hit of dealing with variable length addresses, especially in routers. 32 bits seems like a lot back then. remember that we has class A, B, and C nets, which also reflected our mode of how networking would be deployed, based on the ARPANET, Ethernet, and several satellite and packet radio net experiences. needless to say, if we had to do it again ... Steve From owner-ipsec@lists.tislabs.com Mon Dec 17 14:55:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHMtt201547; Mon, 17 Dec 2001 14:55:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06539 Mon, 17 Dec 2001 17:19:30 -0500 (EST) Date: Mon, 17 Dec 2001 17:28:53 -0500 (EST) From: Henry Spencer To: Bill Sommerfeld cc: Sara Bitan , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-Reply-To: <200112172150.fBHLo7Xt026599@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 On Mon, 17 Dec 2001, Bill Sommerfeld wrote: > > Does each one of the services/ the hosts behind the firewall have a distinct > > private/public key pair? > > potentially, yes. In particular, this potentially makes recovery from key compromise much less disruptive, because compromise and recovery affect the users of only one service/host. It's definitely preferable for a server to be able to authenticate itself as the provider of a particular service. For example, for our Opportunistic Encryption (draft-richardson-ipsec-opportunistic-03.txt), we would much prefer to have a separate authentication key for each host the security gateway might represent, but we can't do that with IKE because in Phase 1, the responding security gateway doesn't yet know which host we want a connection to. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 15:11:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHNBe203562; Mon, 17 Dec 2001 15:11:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06588 Mon, 17 Dec 2001 17:33:19 -0500 (EST) MIME-Version: 1.0 x-receiver: m.gratton@adga.ca Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <200112172150.fBHLo7Xt026599@thunk.east.sun.com> From: "Bill Sommerfeld" To: "Sara Bitan" Cc: "Radia Perlman - Boston Center for Networking" , Subject: Re: Should Alice say who she wants to talk to? In-Reply-To: Your message of "Mon, 17 Dec 2001 23:15:07 +0200." <002c01c1873f$e8541b00$f24c5ac2@commagine.net> Reply-To: Date: Mon, 17 Dec 2001 16:50:07 -0500 X-OriginalArrivalTime: 17 Dec 2001 22:43:14.0734 (UTC) FILETIME=[36A82CE0:01C1874C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Does each one of the services/ the hosts behind the firewall have a distinct > private/public key pair? potentially, yes. - Bill From owner-ipsec@lists.tislabs.com Mon Dec 17 15:18:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHNIN203724; Mon, 17 Dec 2001 15:18:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06601 Mon, 17 Dec 2001 17:35:20 -0500 (EST) Date: Mon, 17 Dec 2001 17:44:43 -0500 (EST) From: Henry Spencer To: Stephen Kent cc: "Hallam-Baker, Phillip" , IP Security List Subject: RE: IKEv2 and NAT traversal 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, 17 Dec 2001, Stephen Kent wrote: > As one of the folks who was involved in the address space size > decisions in the late 70s and early 80s, I can confirm that the 32 > bit size was chosen because of register/word sizes in current > machines, including IBM, DEC, and others... I don't dispute that given the hardware of the time (which I worked with extensively, although not in the context of IP), it was clearly imperative to make fixed-width addresses a multiple of 8, strongly preferable to make them a multiple of 16, and definitely desirable to make them a multiple of 32. And obvious considerations of both network bandwidth and processing power meant that they shouldn't be longer than "necessary"... This is rather different from the assertion that the registers of one particular machine (especially the nonexistent 32-bit PDP) dictated the choice, which is the claim I was responding to. Interestingly enough, when Xerox designed XNS, not very much later, they chose 48. (Which is why Ethernet addresses are 48 -- they were intended to be identical to XNS addresses.) Would that have sufficed for IP? An interesting although now academic question... It certainly wouldn't have permitted some of the clever tricks the IPv6 folk have come up with for using their enormous address space, but those can be seen as side issues rather than necessities. > needless to say, if we had to do it again ... Well, we have... with, so far, uncertain success. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 15:27:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHNRN203966; Mon, 17 Dec 2001 15:27:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06649 Mon, 17 Dec 2001 17:46:17 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698DC@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Henry Spencer'" , Stephen Kent Cc: "Hallam-Baker, Phillip" , IP Security List Subject: RE: IKEv2 and NAT traversal Date: Mon, 17 Dec 2001 14:56:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1874E.0C6F3CA0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1874E.0C6F3CA0 Content-Type: text/plain; charset="iso-8859-1" My point is not the exact history of why we got here. My point is that the IETF as a whole is not in a position to complain about the introduction of NAT. Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, December 17, 2001 5:45 PM > To: Stephen Kent > Cc: Hallam-Baker, Phillip; IP Security List > Subject: RE: IKEv2 and NAT traversal > > > On Mon, 17 Dec 2001, Stephen Kent wrote: > > As one of the folks who was involved in the address space size > > decisions in the late 70s and early 80s, I can confirm that the 32 > > bit size was chosen because of register/word sizes in current > > machines, including IBM, DEC, and others... > > I don't dispute that given the hardware of the time (which I > worked with > extensively, although not in the context of IP), it was > clearly imperative > to make fixed-width addresses a multiple of 8, strongly > preferable to make > them a multiple of 16, and definitely desirable to make them > a multiple of > 32. And obvious considerations of both network bandwidth and > processing > power meant that they shouldn't be longer than "necessary"... > > This is rather different from the assertion that the registers of one > particular machine (especially the nonexistent 32-bit PDP) > dictated the > choice, which is the claim I was responding to. > > Interestingly enough, when Xerox designed XNS, not very much > later, they > chose 48. (Which is why Ethernet addresses are 48 -- they > were intended > to be identical to XNS addresses.) Would that have sufficed > for IP? An > interesting although now academic question... It certainly > wouldn't have > permitted some of the clever tricks the IPv6 folk have come > up with for > using their enormous address space, but those can be seen as > side issues > rather than necessities. > > > needless to say, if we had to do it again ... > > Well, we have... with, so far, uncertain success. > > > Henry Spencer > > henry@spsystems.net > ------_=_NextPart_000_01C1874E.0C6F3CA0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1874E.0C6F3CA0-- From owner-ipsec@lists.tislabs.com Mon Dec 17 15:56:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBHNuZ205119; Mon, 17 Dec 2001 15:56:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06772 Mon, 17 Dec 2001 18:18:11 -0500 (EST) Message-ID: <20011217232806.65316.qmail@web21003.mail.yahoo.com> Date: Mon, 17 Dec 2001 15:28:06 -0800 (PST) From: Yang Xiao Reply-To: YangXiao@ieee.org Subject: CFP for an Invited section of SCI2002:Modeling, Analysis, Simulation, QoS Issues of Wireless LANs and Mobile Ad Hoc Networks To: ipsec@lists.tislabs.com, end2end-interest@postel.org, manet@itd.nrl.navy.mil, cabernet-events@ncl.ac.uk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Our apologies if you receive multiple copies of this CFP.] Call for Papers An invited session in the 6th World Multi-Conference on Systemics, Cybernetics and Informatics, (SCI 2002) Orlando, Florida, USA, July 14 -18, 2002 Session Title: Modeling, Analysis, Simulation, QoS Issues of Wireless LANs and Mobile Ad Hoc Networks Topics of Interest Wireless LANs & Mobile Ad Hoc Networks (including but not limited to) • Simulation, modeling and performance evaluation of Wireless LANs, such as IEEE 802.11, HIPERLAN, and Ad Hoc Networks. • Quality-of-service issues in Wireless LANs (IEEE 802.11e, HIPERLAN /2, etc.) and Ad Hoc Networks. • Power consumption issues • Higher data rates • Bluetooth Technology • 3G/4G-WLAN • Quality of service in Wireless • Differentiated Services for Wireless LANs • Co-existence of IEEE 802.11 and 802.15 • Resource management • Routing Protocols • Quality of Service (QoS) models, Link Performance Models Deadlines Submission of Extended Abstracts: February 05, 2002 Notification of Acceptance: March 05, 2002 Camera Ready Copies: April 03, 2002 Session Co-Organizers/Co-Chairs Dr. Yang Xiao, Micro Linear, USA Dr. Bin Wang, Wright State University, USA Instructions For Submission Submission should be in the form of extended abstracts up to 4 pages long. All submitted contributions will be subject to peer review on the basis of technical correctness, quality, relevance, originality, significance, and presentation clarity. Abstracts should be in MS Word, PDF or PS format. Submissions should be sent to the session's co-organizers. Successful submissions will be asked to submit full papers. Full papers must be formatted according to IEEE-CS guidelines Electronic Submission: Dr. Yang Xiao: YangXiao@IEEE.ORG Dr. Bin Wang: bwang@cs.wright.edu For more details check at http://www.iiis.org/sci2002/ Last updated 12/17/01 __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ipsec@lists.tislabs.com Mon Dec 17 16:05:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI05e205365; Mon, 17 Dec 2001 16:05:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06766 Mon, 17 Dec 2001 18:17:56 -0500 (EST) Date: Mon, 17 Dec 2001 15:27:19 -0800 (PST) From: Jan Vilhuber To: Sara Bitan cc: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-Reply-To: <002c01c1873f$e8541b00$f24c5ac2@commagine.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Dec 2001, Sara Bitan wrote: > Radia - why aren't the (IKEv2 analog to) phase II IDs sufficient to handle > that scenario you are describing? Because they are way too late in the exchange to be of any use in picking which identity a server may want to pose as. > Does each one of the services/ the hosts behind the firewall have a distinct > private/public key pair? > Yes. > And another comment: if you move IDr to message number 1, and the initiator > doesn't sign it since you want to avoid introducing NR, then the protocol is > exposed to the DVW attack. As you said, the simple algorithm that IKEv2 uses > "sign messages 1 and 2, and integrity protect messages 3 and 4" doesn't work > any more, hence you must add the responder's identity explicitly to the MAC > calculation in message 3. > I think that the option that you are proposing to add to IKEv2 is a good > motivation to adopt SIGMA's way of explicitly MACing the identities. > If the protocol specifies all the components that ensure the correctness of > the key exchange cryptographic protocol (i.e. the MAC'd identities and > signed public exponent and nonces) explicitly, then you have the advantage > of moving IDs and exponents (almost) freely between messages without the > risk of breaking the protocol. > If we will not include the identities explicitly under the MAC we will have > to always twick the protocol to keep it secure, and ask the cryptographers > to prove that the twicks are indeed not breaking the protocol. > Nit: s/twicks/tweaks/g jan > Sara. > ----- Original Message ----- > From: Radia Perlman - Boston Center for Networking > To: > Sent: Monday, December 17, 2001 4:05 AM > Subject: Should Alice say who she wants to talk to? > > > > I was wondering about how IPsec might support having a bunch > > of services hosted at the same IP address, or even hosted > > behind a firewall, but all accessible through the firewall's IP address. > > SSL/TLS doesn't do this either, but it seems like it might be > > a useful thing. > > > > The idea is that there would be a whole bunch of services, all reachable > > to the world through a single IP address. IKE would have some > > port (500 say). It can connect Alice to a bunch of services, say > > foo and bar. When Alice connects to port 500 she says (probably > > in message 1 of the handshake), "I'd > > like to talk to service foo", and the IKE process (which must have > > certificates and keys for each of the services) uses that to know > > what certificate and key to use, i.e., which "Bob" persona to take on. > > > > And if people are worried about plausible deniability, Alice need not > > sign Bob's name (IKEv2 says "sign everything in messages 1 and 2, but > > that's because Bob's name isn't there right now...if it were, then Alice > could > > sign everything except Bob's name, and add Bob's name into the > > integrity check in message 3). > > > > This would be an optional field in message 1, and obviously won't > > hide Bob's identity. > > > > Note that HTTP 1.1 has this feature of allowing Alice to say who she > > wants to talk to. > > > > Radia > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Dec 17 16:40:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI0eO207803; Mon, 17 Dec 2001 16:40:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06914 Mon, 17 Dec 2001 18:54:15 -0500 (EST) Message-ID: <002101c18757$73b8a5f0$7480ad40@sfanninglaptop> From: "Scott Fanning" To: "IETF-IPSec" Subject: IKE v2 Requirements and backwards compatability Date: Mon, 17 Dec 2001 16:03:41 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C18714.65661890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C18714.65661890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Should there be a requirement that IKEv2 be able to interoperate with = IKEv1? There is a large deployed base, and a migration path to the new = version should be an requirement. I understand this might increase the = complexity, but I am sure people using IKE today will not swap out all = their equipment overnight. Comments? Scott ------=_NextPart_000_001E_01C18714.65661890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Should there be a requirement that = IKEv2 be able to=20 interoperate with IKEv1? There is a large deployed base, and a migration = path to=20 the new version should be an requirement. I understand this might = increase the=20 complexity, but I am sure people using IKE today will not swap out all = their=20 equipment overnight.
 
Comments?
 
Scott
------=_NextPart_000_001E_01C18714.65661890-- From owner-ipsec@lists.tislabs.com Mon Dec 17 16:45:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI0j1207948; Mon, 17 Dec 2001 16:45:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06934 Mon, 17 Dec 2001 18:58:16 -0500 (EST) Date: Mon, 17 Dec 2001 19:07:30 -0500 (EST) From: Henry Spencer To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: fragmentation In-Reply-To: <200112152010.fBFKAMg00948@marajade.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 On Sat, 15 Dec 2001, Michael Richardson wrote: > The further proposal is that one might ignore the DF bit, fragment the > packet going into the tunnel first (before ESP processing), producing ESP > packets that do not need to be fragmented... There's a potential problem here: you'd need to remember, somehow, whether this has been done. You want to reassemble such force-fragmented packets, because somebody's sure to have conniptions if a DF packet shows up in pieces. However, you *don't* want to try to reassemble packets which are already fragmented when they reach you, because in the event of multiple paths, you might never see all the fragments. What you need, in effect, is a "link level" fragmentation mechanism for your virtual wires, logically independent of IP fragmentation. > The question is then, what is the > MTU of the tunnel, given that all fragments get lost, and that ICMPs > generated from DF-set are filtered, etc. The MTU of a wire is the largest packet which can pass through without *end-host-visible* fragmentation. All kinds of things go on behind the scenes on some links, e.g. the atrocities inflicted by ATM. So in this case, I think the answer is "pick a number". Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 17:18:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI1I3209664; Mon, 17 Dec 2001 17:18:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07021 Mon, 17 Dec 2001 19:28:03 -0500 (EST) Date: Mon, 17 Dec 2001 19:37:21 -0500 (EST) From: Henry Spencer To: Scott Fanning cc: IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <002101c18757$73b8a5f0$7480ad40@sfanninglaptop> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Dec 2001, Scott Fanning wrote: > Should there be a requirement that IKEv2 be able to interoperate with > IKEv1? There is a large deployed base, and a migration path to the new > version should be an requirement. The migration path, clearly, is "support both". That's trivial if they are using different ports, although less so if IKEv2 stays on UDP/500. There is no way to require the two *protocols* to be interchangeable without sacrificing most of the benefits we hope to see from IKEv2. But it is implementations, not protocols, which interoperate. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 17:30:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI1U0210039; Mon, 17 Dec 2001 17:30:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07088 Mon, 17 Dec 2001 19:37:30 -0500 (EST) Message-ID: <004101c1875d$802d1130$7480ad40@sfanninglaptop> From: "Scott Fanning" To: "Henry Spencer" Cc: "IETF-IPSec" References: Subject: Re: IKE v2 Requirements and backwards compatability Date: Mon, 17 Dec 2001 16:46:59 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, whatever we do, the next protocol will have to use a different UDP port? Should that be a requirement, or is that too protocol specific? Scott ----- Original Message ----- From: "Henry Spencer" To: "Scott Fanning" Cc: "IETF-IPSec" Sent: Monday, December 17, 2001 4:37 PM Subject: Re: IKE v2 Requirements and backwards compatability > On Mon, 17 Dec 2001, Scott Fanning wrote: > > Should there be a requirement that IKEv2 be able to interoperate with > > IKEv1? There is a large deployed base, and a migration path to the new > > version should be an requirement. > > The migration path, clearly, is "support both". That's trivial if they > are using different ports, although less so if IKEv2 stays on UDP/500. > > There is no way to require the two *protocols* to be interchangeable > without sacrificing most of the benefits we hope to see from IKEv2. But > it is implementations, not protocols, which interoperate. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Dec 17 17:39:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI1dT210439; Mon, 17 Dec 2001 17:39:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07165 Mon, 17 Dec 2001 19:55:33 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: suggestion for JFK Date: Mon, 17 Dec 2001 18:58:04 -0500 Message-ID: <000001c1875f$9623dc60$8e2cb440@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <20011213062153.EB51054C55@tailor.sailpix.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In addition, by not including the IP address in the hash > calculation JFK > opens itself up to a varient of Simpson's "cookie jar" > attack. ... > I will now stop beating this horse since I am the only person > who thinks > it is not dead yet. I wasn't able to follow this thread in real time, but I think Dan has a good point. After all, the ability to be able to trace a DoS attack back to its source is often a more effective countermeasure than an attempt to stop it 'on the wire'. This attack is clearly non-intuitive (it took a while for Dan to explain it), so it is better not to leave it as an implementation detail. (speaking as someone who has seen some very poor implementations of the original Karn-Simpson cookies...) Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Mon Dec 17 17:48:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI1m9211274; Mon, 17 Dec 2001 17:48:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07217 Mon, 17 Dec 2001 20:06:34 -0500 (EST) Date: Mon, 17 Dec 2001 20:15:50 -0500 (EST) From: Henry Spencer To: Scott Fanning cc: IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <004101c1875d$802d1130$7480ad40@sfanninglaptop> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Dec 2001, Scott Fanning wrote: > So, whatever we do, the next protocol will have to use a different UDP port? > Should that be a requirement, or is that too protocol specific? I think the requirement needs to be written a bit more broadly, although that may be the preferred way of satisfying it. Perhaps like so: (a) An IKE1/IKE2 responder must be able to determine, from the first packet received, which protocol the initiator wishes to use. (b) An IKE1-only responder must reliably reject attempts to use IKE2 to it. (c) Preferably, an IKE1/IKE2 initiator should be able to easily determine which protocol(s) the responder can handle. Requirement (a) doesn't necessarily mean separate ports, so long as the packets of the two protocols are different enough. Requirement (b) means that if a separate port is not used, the packet differences must be obvious enough that an IKE1-only responder will reliably decide that the packet is junk and should be discarded. Fortunately, ISAKMP includes a version number and mandates rejecting packets with unknown versions, so both of these are trivial to meet, if care is taken that an IKE2 packet has its version number in exactly the same place as an IKE1 version number (you might think this would be an obvious necessity for a multi-version protocol, but there have been protocols which have botched it). Requirement (c) is harder. (With multiple ports, getting an ICMP Port Unreachable message might be felt to satisfy it... but do you trust that message, which after all is unauthenticated?) Fortunately it's also less critical. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 18:34:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI2Yv213540; Mon, 17 Dec 2001 18:34:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07382 Mon, 17 Dec 2001 20:39:37 -0500 (EST) Message-ID: <3C1EA02C.9040000@moquijo.com> Date: Mon, 17 Dec 2001 20:47:24 -0500 From: Paul Cardon User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Scott Fanning CC: IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability References: <002101c18757$73b8a5f0$7480ad40@sfanninglaptop> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fanning wrote: > Should there be a requirement that IKEv2 be able to interoperate with > IKEv1? There is a large deployed base, and a migration path to the new > version should be an requirement. I understand this might increase the > complexity, but I am sure people using IKE today will not swap out all > their equipment overnight. If IKEv2 can interoperate with IKEv1 then it IS IKEv1. -paul From owner-ipsec@lists.tislabs.com Mon Dec 17 19:04:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI34q214080; Mon, 17 Dec 2001 19:04:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07460 Mon, 17 Dec 2001 20:54:12 -0500 (EST) Message-ID: <007601c18768$3676d2f0$7480ad40@sfanninglaptop> From: "Scott Fanning" To: "Paul Cardon" Cc: "IETF-IPSec" References: <002101c18757$73b8a5f0$7480ad40@sfanninglaptop> <3C1EA02C.9040000@moquijo.com> Subject: Re: IKE v2 Requirements and backwards compatability Date: Mon, 17 Dec 2001 18:03:39 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unless IKEv2 is a subset of IKEv1 which would simplify things, but that seem not to be the approach of the WG. So, am I correct in saying that any attempts to simplify IKEv1 by tightening the language, removing AH, COMMIT BIT, and a "mode" would not make IKEv1 better, and less complex? How about pre-defining protection suites to avoid negotiation explosions? I am sure this has all been discussed on the list. I will check the achieves. How about describing how certs and IKE should work (Multiple roots, cert requests, chains etc). Maybe including DPD and the hash fixes, and the current NAT work, and that may make an excellent IKEv2. That being said, if even the above does not meet the requirements, then IKEv1, in any form, would not fly. Glad to see that the requirements are framing the debate. Thanks Scott ----- Original Message ----- From: "Paul Cardon" To: "Scott Fanning" Cc: "IETF-IPSec" Sent: Monday, December 17, 2001 5:47 PM Subject: Re: IKE v2 Requirements and backwards compatability > Scott Fanning wrote: > > > Should there be a requirement that IKEv2 be able to interoperate with > > IKEv1? There is a large deployed base, and a migration path to the new > > version should be an requirement. I understand this might increase the > > complexity, but I am sure people using IKE today will not swap out all > > their equipment overnight. > > > If IKEv2 can interoperate with IKEv1 then it IS IKEv1. > > -paul > From owner-ipsec@lists.tislabs.com Mon Dec 17 19:40:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI3ew214730; Mon, 17 Dec 2001 19:40:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07626 Mon, 17 Dec 2001 21:53:33 -0500 (EST) Date: Mon, 17 Dec 2001 21:57:31 -0500 (EST) From: Henry Spencer To: Scott Fanning cc: IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <007601c18768$3676d2f0$7480ad40@sfanninglaptop> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Dec 2001, Scott Fanning wrote: > Unless IKEv2 is a subset of IKEv1 which would simplify things, but that seem > not to be the approach of the WG. So, am I correct in saying that any > attempts to simplify IKEv1 by tightening the language, removing AH, COMMIT > BIT, and a "mode" would not make IKEv1 better, and less complex? Better and less complex, yes, but quite possibly not worth the trouble. And there would still be interoperability issues, since a simplified IKE could not reliably interoperate with the original. (In many ways this is worse than a new protocol, because it would sometimes interoperate and sometimes not.) > How about > pre-defining protection suites to avoid negotiation explosions? draft-spencer-ipsec-ike-implementation-00.txt attempts this in a small way, but more as a record of successful experience than as an attempt at laying down the law for the future -- it's something that has not been much of a problem in practice, because when it comes to things like algorithm choices, in fact there is a small subset that almost everyone implements and which you can propose fairly confidently. It's numeric values like lifetimes which cause more trouble. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 19:41:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI3ex214740; Mon, 17 Dec 2001 19:40:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07634 Mon, 17 Dec 2001 21:55:54 -0500 (EST) Date: Mon, 17 Dec 2001 22:05:03 -0500 (EST) From: Henry Spencer To: Scott Fanning cc: IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wrote: > draft-spencer-ipsec-ike-implementation-00.txt attempts this... Oops, correction, make that -01. -00 is incomplete and out of date. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 17 21:30:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI5Ud217300; Mon, 17 Dec 2001 21:30:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07894 Mon, 17 Dec 2001 23:44:33 -0500 (EST) From: "Jayant Shukla" To: "'Henry Spencer'" , "'IP Security List'" Subject: RE: IKEv2 and NAT traversal Date: Mon, 17 Dec 2001 20:50:30 -0800 Message-ID: <000001c1877f$85955fc0$0101a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Henry Spencer > > > One solution to this that occurs to me is to modify the key agreement so > > that the sender tells the reciever the IP address that they believe that > > they are using and the responder tells the sender the one that it > sees... > > permitting the responder to affect repairs to the said damaged packets. > > Care would be needed to avoid chicken-and-egg problems here -- the > information needed to make repairs can't be exchanged by mechanisms which > assume repair is already possible! That said, this has potential. > Very interesting! This is the approach that I had proposed @ San Diego. Essentially you can take two* approaches to solving the NAT problem. First approach is to prevent the NATs from modifying the part of the packet that you care about. The second approach is to let NATs modify the packet and just reverse the effect of NATs at the receiver. ESP-UDP is the former approach and ours is the latter approach. The way we have designed the solution, you don't need any modifications to IKE. Our solution is a more general NAT traversal solution, and non-IPsec people can also use it. The solution is ready and hopefully we will be ready to release it by March-April 2002. > > However, in most IPsec situations there is little that can be done about > it. There simply is no way to do benign surgery on packet innards without > causing IPsec authentication failures, even if you have access to the > innards at all, which you don't if they're encrypted. > ;-) > Henry Spencer > henry@spsystems.net ~Jayant Shukla Trlokom, Inc. * Third approach is to change NAT! :-) From owner-ipsec@lists.tislabs.com Mon Dec 17 22:53:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBI6r3219146; Mon, 17 Dec 2001 22:53:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08103 Tue, 18 Dec 2001 00:58:52 -0500 (EST) Date: Tue, 18 Dec 2001 01:08:11 -0500 (EST) From: Henry Spencer To: Andrew Krywaniuk cc: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: Re: Michael's comments on ikev2 draft In-Reply-To: <000d01c181bc$4fd505c0$01c7830c@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 10 Dec 2001, Andrew Krywaniuk wrote: > > 3. Delete payloads are a MUST, which is also good. > > Agreed. Implementations which don't send deletes continue to be a source of > interoperability problems. Which indicates foolish assumptions on the other end, since delivery of Delete is unreliable and most aspects of Delete support are optional. However, the deeper point -- that too many significant things in IKE are unreliable or optional or both, and this needs fixing -- is valid. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Dec 18 03:16:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIBGj222972; Tue, 18 Dec 2001 03:16:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08863 Tue, 18 Dec 2001 05:25:11 -0500 (EST) Message-ID: <3C1F1BD7.3B230861@F-Secure.com> Date: Tue, 18 Dec 2001 12:35:03 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jayant Shukla CC: "'Henry Spencer'" , "'IP Security List'" Subject: Re: IKEv2 and NAT traversal References: <000001c1877f$85955fc0$0101a8c0@trlhpc1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2001 10:35:06.0308 (UTC) FILETIME=[A8BD2840:01C187AF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant Shukla wrote: > Very interesting! This is the approach that I had proposed @ San Diego. > Essentially you can take two* approaches to solving the NAT problem. > First approach is to prevent the NATs from modifying the part of the > packet that you care about. The second approach is to let NATs modify > the packet and just reverse the effect of NATs at the receiver. > > ESP-UDP is the former approach and ours is the latter approach. There are some things that one should stay away from, but I just can't resist.. SSH already has a patent (application?) for that latter approach as well. I don't have the number right now, but it was applied for in Finland, and some years back. I seem to remember that it was granted. I just mention this because you said you had some patent application.. Purely technically, my view is that ignoring NAT effects is simpler than trying to compensate. It's also quite sufficient to solve the problem. > The way we have designed the solution, you don't need any modifications > to IKE. Our solution is a more general NAT traversal solution, and > non-IPsec people can also use it. The solution is ready and hopefully we > will be ready to release it by March-April 2002. This WG is about making interoperable protocols. Why would the release date of your company's product be significant? Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Dec 18 03:16:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIBGn222992; Tue, 18 Dec 2001 03:16:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08891 Tue, 18 Dec 2001 05:33:52 -0500 (EST) Message-ID: <3C1F1DE0.B791995D@F-Secure.com> Date: Tue, 18 Dec 2001 12:43:44 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Sara Bitan , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2001 10:43:47.0720 (UTC) FILETIME=[DF865080:01C187B0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > On Mon, 17 Dec 2001, Sara Bitan wrote: > > > Radia - why aren't the (IKEv2 analog to) phase II IDs sufficient to handle > > that scenario you are describing? > > Because they are way too late in the exchange to be of any use in picking > which identity a server may want to pose as. > > > Does each one of the services/ the hosts behind the firewall have a distinct > > private/public key pair? > > > Yes. If the recipient ID was in plaintext, the firewall could also just forward the IKE packet to some internal address, thus the private keys would be in different boxes. This'd be a fancy form of NAT :). But it'd be secure. Is this necessary? That is the question. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Dec 18 06:31:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIEV4206614; Tue, 18 Dec 2001 06:31:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09262 Tue, 18 Dec 2001 08:51:50 -0500 (EST) Message-Id: <200112180333.fBI3XeoO001573@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-reply-to: Your message of "Sun, 16 Dec 2001 21:05:48 EST." <200112170205.VAA02738@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Dec 2001 22:33:40 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, this is precisely what the "suggested ID" draft Bill Sommerfeld and I have, which Bill discussed briefly on the Wednesday session. The name is draft-keromytis-ike-id-00.txt. This was for IKEv1, and mostly intended for bidirectional user-keying, but it can be used for what you want it. For any of the SoI proposals, the same extension can be made --- and, as you point out, it makes the Responder's identity public (in IKEv1 it does not, because of the 6 messages in Phase 1). -Angelos In message <200112170205.VAA02738@bcn.East.Sun.COM>, Radia Perlman - Boston Cen ter for Networking writes: >I was wondering about how IPsec might support having a bunch >of services hosted at the same IP address, or even hosted >behind a firewall, but all accessible through the firewall's IP address. >SSL/TLS doesn't do this either, but it seems like it might be >a useful thing. > >The idea is that there would be a whole bunch of services, all reachable >to the world through a single IP address. IKE would have some >port (500 say). It can connect Alice to a bunch of services, say >foo and bar. When Alice connects to port 500 she says (probably >in message 1 of the handshake), "I'd >like to talk to service foo", and the IKE process (which must have >certificates and keys for each of the services) uses that to know >what certificate and key to use, i.e., which "Bob" persona to take on. > >And if people are worried about plausible deniability, Alice need not >sign Bob's name (IKEv2 says "sign everything in messages 1 and 2, but >that's because Bob's name isn't there right now...if it were, then Alice could >sign everything except Bob's name, and add Bob's name into the >integrity check in message 3). > >This would be an optional field in message 1, and obviously won't >hide Bob's identity. > >Note that HTTP 1.1 has this feature of allowing Alice to say who she >wants to talk to. > >Radia From owner-ipsec@lists.tislabs.com Tue Dec 18 08:53:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIGrX218108; Tue, 18 Dec 2001 08:53:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09815 Tue, 18 Dec 2001 11:00:26 -0500 (EST) From: Charlie_Kaufman@iris.com Subject: authentication state capture To: ipsec@lists.tislabs.com Cc: Michael Thomas X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: Date: Tue, 18 Dec 2001 00:16:27 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 12/18/2001 11:12:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas wrote: > I think that SOI would be greatly facilitated by > taking a similar middle ground. I don't care > whether it uses Kerberos mechanisms as it's the > technique that's important, not the bit encoding. > Thus, I think there should be a requirement: > > "The protocol MUST provide a facility to capture > expensive authentication operations into state > blobs created by the responder and held by the > initiator, which can be used in subsequent SOI > protocol operations such as rekeying, SA > maintenance, etc, and MUST be usable for a > configurable length of time even if the responder > loses state or reboots." It seems reasonable to do something along these lines, but I'm concerned about the exact requirement. In particular, the wording above creates an asymmetry between the initiator and the responder. If the responder crashes, restart will be quick; but if the initiator crashes with lots of outstanding connections, it would have to go the expensive route. This makes sense in the scenario where lots of clients each make a single connection into a large server, but not where there is a star topology with lots of firewalls talking to one another. It also doesn't help if everything crashes at once (say, due to a site-wide power glitch). Being able to restart without public key cryptography is somewhat at odds with perfect forward secrecy. There must be information on stable storage at the site that crashes and restarts which if stolen would allow decryption of the session. For KINK, this is the server's secret key; KINK provides no forward secrecy at all. Rather than have such a long term powerful secret, I would recommend having the IKE SA keys cached in stable storage (and erased from stable storage when the IKE SA is closed). This would effectively mean that the IKE SA could survive crashes of one or both endpoints. During restart, a node could attempt to restart the IKE SA. If the other end had not timed it out (and the timeout interval could be arbitrarily long), the IKE SA could recover without any public key cryptography. To support this, we would have to design a mechanism for the IKE SA to somehow agree on sequence numbers after a crash. Another way of getting a similar result would be for an IKE SA to go through a rekeying exchange but *not* immediately close the old IKE SA and start using the new IKE SA. Instead, the new IKE SA keys and state could be stored in stable storage on both ends and use of it could begin if something happened to the original IKE SA (like it was destroyed by a timeout during a crash). Do any of these ideas sound reasonable? --Charlie Kaufman (charlie_kaufman@iris.com) From owner-ipsec@lists.tislabs.com Tue Dec 18 09:23:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIHNP219987; Tue, 18 Dec 2001 09:23:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09931 Tue, 18 Dec 2001 11:36:31 -0500 (EST) Message-Id: <200112181646.fBIGkHXt006589@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: Scott Fanning , IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: Your message of "Mon, 17 Dec 2001 20:15:50 EST." Reply-to: sommerfeld@east.sun.com Date: Tue, 18 Dec 2001 11:46:17 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > (b) An IKE1-only responder must reliably reject attempts to use IKE2 > to it. Retroactive specification is such fun. Do you mean: a *correctly-implemented* IKE1-only responder or "all commonly-used IKE1 implementations" ? - Bill From owner-ipsec@lists.tislabs.com Tue Dec 18 10:19:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIIJ4221923; Tue, 18 Dec 2001 10:19:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10090 Tue, 18 Dec 2001 12:31:06 -0500 (EST) MIME-Version: 1.0 x-receiver: m.gratton@adga.ca Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <200112181646.fBIGkHXt006589@thunk.east.sun.com> From: "Bill Sommerfeld" To: "Henry Spencer" Cc: "Scott Fanning" , "IETF-IPSec" Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: Your message of "Mon, 17 Dec 2001 20:15:50 EST." Reply-To: Date: Tue, 18 Dec 2001 11:46:17 -0500 X-OriginalArrivalTime: 18 Dec 2001 17:41:15.0156 (UTC) FILETIME=[30F5BD40:01C187EB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > (b) An IKE1-only responder must reliably reject attempts to use IKE2 > to it. Retroactive specification is such fun. Do you mean: a *correctly-implemented* IKE1-only responder or "all commonly-used IKE1 implementations" ? - Bill From owner-ipsec@lists.tislabs.com Tue Dec 18 13:08:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIL8N200924; Tue, 18 Dec 2001 13:08:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10636 Tue, 18 Dec 2001 15:03:39 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15391.41773.970840.85991@pkoning.dev.equallogic.com> Date: Tue, 18 Dec 2001 15:12:29 -0500 (EST) From: Paul Koning To: henry@spsystems.net Cc: ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability References: <004101c1875d$802d1130$7480ad40@sfanninglaptop> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Henry" == Henry Spencer writes: Henry> On Mon, 17 Dec 2001, Scott Fanning wrote: >> So, whatever we do, the next protocol will have to use a different >> UDP port? Should that be a requirement, or is that too protocol >> specific? Henry> I think the requirement needs to be written a bit more Henry> broadly, although that may be the preferred way of satisfying Henry> it. Perhaps like so: Henry> (a) An IKE1/IKE2 responder must be able to determine, from the Henry> first packet received, which protocol the initiator wishes to Henry> use. Henry> (b) An IKE1-only responder must reliably reject attempts to Henry> use IKE2 to it. Henry> (c) Preferably, an IKE1/IKE2 initiator should be able to Henry> easily determine which protocol(s) the responder can handle. Henry>... Henry> Requirement (c) is harder. (With multiple ports, getting an Henry> ICMP Port Unreachable message might be felt to satisfy Henry> it... but do you trust that message, which after all is Henry> unauthenticated?) Fortunately it's also less critical. I wouldn't agree that it is less critical, unless you believe that the improvements in IKEv2 are minor enough that it doesn't matter much if you end up using IKEv1 instead of IKEv2 "by accident". Assuming there are good reasons why an initiator would want to use IKEv2 if it is available, you need a good mechanism that allows you to do both of these: a. Perform an IKEv2 exchange without undue delay. b. Discover that IKEv2 is not available, without undue delay, so you can fall back to IKEv1. The inclusion of "without undue delay" is intentional. For example, if IKEv2 uses a different port, timeout could be taken as evidence that IKEv2 is not supported, but that would not satisfy "without undue delay". ICMP Port Unreachable might be satisfactory, but ICMP is often tossed by firewalls. Given that IKEv1 has a version number, and a correctly stated version check rule, the answer is easy: use the same port, and a higher version number. This does not restrict IKEv2 at all -- it can be 100% different from IKEv1, the only detail is that the first message must contain a value larger than 1 at the offset where IKEv1 has its version number. paul From owner-ipsec@lists.tislabs.com Tue Dec 18 14:13:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIMDV204507; Tue, 18 Dec 2001 14:13:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10848 Tue, 18 Dec 2001 16:32:02 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15391.47111.780340.816077@thomasm-u1.cisco.com> Date: Tue, 18 Dec 2001 13:41:27 -0800 (PST) To: "Scott Fanning" Cc: "Henry Spencer" , "IETF-IPSec" Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <004101c1875d$802d1130$7480ad40@sfanninglaptop> References: <004101c1875d$802d1130$7480ad40@sfanninglaptop> 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 Scott Fanning writes: > So, whatever we do, the next protocol will have to use a different UDP port? > Should that be a requirement, or is that too protocol specific? Dan felt pretty strongly that KINK should be on a different port. I suspect that many of his reasons apply here as the protocols being described only bear a passing resemblance to IKEv1. It may also be worthwhile to consider that one might want to shield via access control the various IPsec key management schemes from gateways and/or clients. Mike From owner-ipsec@lists.tislabs.com Tue Dec 18 14:21:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIMLw204884; Tue, 18 Dec 2001 14:21:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10858 Tue, 18 Dec 2001 16:34:30 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Henry Spencer'" , "'IP Security List'" Subject: RE: IKEv2 traffic selector subsetting. Date: Tue, 18 Dec 2001 02:29:10 -0500 Message-ID: <001d01c1880c$aa0146c0$8e2cb440@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > ...If you > > wish to avoid sending traffic that will be filtered out by > the peer then > > that would be best accomplished by an IPSP protocol. > > I.e., "by some hypothetical protocol yet to be defined". > > It's better to solve the problem than to pretend that someone > somehow will > deliver a solution when required. IKE has demonstrated that simple > solutions are adequate for many purposes. Deliberately excluding this > from son-of-IKE may be ideologically preferable but makes no > sense as a > matter of practical engineering. Being idealistic is something that I am rarely accused of. My point is that there is a difference between phase 2 traffic selectors (which represent an IP->identity binding), and policy (which can be complex, ordered, and asymmetric). The IP->id binding is something that needs to be agreed upon, because it verifies that the peers agree on which protected subnets are behind which gateway (or which user is logged into the remote computer). The bindings are relatively static and they could be obtained from trusted sources like a configuration file or a DNS record. The policy rules, on the other hand, are basically a re-implementation of firewalling. They don't need to be negotiated; they simply need to be enforced at each end. The fact that we negotiated an SA from A to B doesn't mean that I'm going to accept all UDP traffic to port 17 at 5:15 am on odd-numbered Tuesdays. The policy can change at any time and it need not be shared with the peer ahead of time. The bindings need to be agreed upon, whereas the two policies are ukases (which should be merged independently at each side); this is the key distinction between them. In IKEv1, the responder couldn't change the traffic selectors so they had to be preshared (this is inappropriate for policy). In IKEv2, the responder can narrow the traffic selectors but there are still potential issues (like what happens if the responder's narrow selectors don't include the packet that triggered the negotiation). The problem stems from the attempt to merge the bindings and the traffic selectors. The bindings are essential for security, whereas the policy is merely an optimization which allows you to avoid forwarding packets that the peer has informed you he intends to drop. Although I said that traffic filtering would be best accomplished by an IPSP protocol, I don't personally care whether that protocol is run as a separate negotiation stage or tacked onto IKE (although the complexity-Nazis may take issue with that). My main comment is that it would be better to have a separate policy payload rather than overloading to traffic selectors to do two different things. I suppose if you wanted to, you could use a second set of traffic selectors in the quick mode to express policy, but I don't think that's a very good idea. The traffic selectors in IKE don't do a very good job of expressing every useful policy. Having a policy payload allows you to use an SA for multiple non-adjacent traffic selectors. Plus, you could dynamically add/delete selectors or conditions to an SA. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Dec 18 14:38:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIMcW205511; Tue, 18 Dec 2001 14:38:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10867 Tue, 18 Dec 2001 16:34:43 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Stephen Kent'" Cc: Subject: RE: IKEv2 traffic selector subsetting. Date: Tue, 18 Dec 2001 16:33:46 -0500 Message-ID: <002001c1880c$b1b79c70$8e2cb440@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >This is an *OPTIMIZATION*. It is feasible to negotiate > wildcard SAs (or > >transport mode SAs for an IP-in-IP tunnel) *iff* you do a > phase 1 identity > >check on every packet (i.e. pass the SA context information > up the stack). > I think this is a critical optimization, and in the next rev of 2401, > I plan to use a processing model that caches selector info from a > (de-correlated) SPD. Searching the SPD for each new outbound packet, > or for inbound packets after processing, is not attractive (maybe not > even feasible) at very high speeds. Well, I think you misunderstood which aspect of the processing was an optimization. In the paragraph you responded to, I said that the use of the selectors for IP-id binding was an optimization. Yes, cacheing the SPD is another optimization, but it doesn't rely on negotiating the phase 2 selectors for its effectiveness. > >Port-constrained SAs make sense in the case of a multi-user > UNIX machine > >where the phase 1 id associated with port FOO is not > necessarily the same as > >the id on port BAR. Port-constrained selectors are NOT the > best mechanism > >for implementing packet filtering. In the vast majority of > VPN scenarios, a > >list of subnets would be appropriate for expressing phase 2 > selectors. > > I disagree. Port filtering is appropriate in IPsec for the same > reasons it is appropriate in a firewall, i.e., a reasonable security > policy may wish to constrain traffic from a specified source to a > specific destination relative to a set of services offered by the > destination. So, for example, I may wish to bypass traffic from any > outside source directed to my SMTP server, but I want all such > traffic to be SMTP traffic, to reduce the likelihood that the server > can be attacked by external sources sending other types of traffic. I don't disagree that port filtering is appropriate; I just disagree with your model. I think it's an SA to a specific destination with a port-constrained policy. One implementation of this model could be an SA with a back-reference to a decorrelated SPD entry. Another is a topology-aware IPsec layer with a completely separate firewalling module. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > Sent: Monday, December 17, 2001 4:38 PM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: IKEv2 traffic selector subsetting. > > > At 2:55 AM -0500 12/14/01, Andrew Krywaniuk wrote: > >To add to this conversation, I would like to debunk this > myth that the IPsec > >SADB selectors need to match the IPsec policy. > > > >The SPD, not the SADB, is supposed to enforce IPsec policy. > As someone > >noted, it does no good to repeat the information in the SPD in the SA > >selectors, since that traffic will be filtered out by the > SPD anyway. If you > >wish to avoid sending traffic that will be filtered out by > the peer then > >that would be best accomplished by an IPSP protocol. > > > >The point of the phase 2 selectors is to enforce that (often > ignored) 3rd > >aspect of network security: authorization. We want to bind > the phase 2 > >selectors to the phase 1 identity so that authenticated peers cannot > >impersonate each other. The use of the phase 2 selectors allows the > >per-packet SPD check to proceed without consulting the SADB > (because the > >initial SADB check is sufficient for verifying that the phase 1 id is > >appropriate). > > > >This is an *OPTIMIZATION*. It is feasible to negotiate > wildcard SAs (or > >transport mode SAs for an IP-in-IP tunnel) *iff* you do a > phase 1 identity > >check on every packet (i.e. pass the SA context information > up the stack). > > I think this is a critical optimization, and in the next rev of 2401, > I plan to use a processing model that caches selector info from a > (de-correlated) SPD. Searching the SPD for each new outbound packet, > or for inbound packets after processing, is not attractive (maybe not > even feasible) at very high speeds. > > > > >Port-constrained SAs make sense in the case of a multi-user > UNIX machine > >where the phase 1 id associated with port FOO is not > necessarily the same as > >the id on port BAR. Port-constrained selectors are NOT the > best mechanism > >for implementing packet filtering. In the vast majority of > VPN scenarios, a > >list of subnets would be appropriate for expressing phase 2 > selectors. > > I disagree. Port filtering is appropriate in IPsec for the same > reasons it is appropriate in a firewall, i.e., a reasonable security > policy may wish to constrain traffic from a specified source to a > specific destination relative to a set of services offered by the > destination. So, for example, I may wish to bypass traffic from any > outside source directed to my SMTP server, but I want all such > traffic to be SMTP traffic, to reduce the likelihood that the server > can be attacked by external sources sending other types of traffic. > > Steve > From owner-ipsec@lists.tislabs.com Tue Dec 18 14:43:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBIMh8205678; Tue, 18 Dec 2001 14:43:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10978 Tue, 18 Dec 2001 17:02:50 -0500 (EST) Date: Tue, 18 Dec 2001 17:12:07 -0500 (EST) From: Henry Spencer To: Bill Sommerfeld cc: Scott Fanning , IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <200112181646.fBIGkHXt006589@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 On Tue, 18 Dec 2001, Bill Sommerfeld wrote: > > (b) An IKE1-only responder must reliably reject attempts to use IKE2 > > to it. > > Retroactive specification is such fun. > Do you mean: > a *correctly-implemented* IKE1-only responder > or > "all commonly-used IKE1 implementations" > ? I would say that the former is essential and the latter is highly desirable. You're right, there is a difference... Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Dec 18 17:50:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJ1om215933; Tue, 18 Dec 2001 17:50:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11499 Tue, 18 Dec 2001 19:54:57 -0500 (EST) Date: Tue, 18 Dec 2001 19:04:18 -0600 (CST) From: Tylor Allison X-X-Sender: To: Henry Spencer cc: Bill Sommerfeld , Scott Fanning , IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability 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, 18 Dec 2001, Henry Spencer wrote: > On Tue, 18 Dec 2001, Bill Sommerfeld wrote: > > > (b) An IKE1-only responder must reliably reject attempts to use IKE2 > > > to it. > > > > Retroactive specification is such fun. > > Do you mean: > > a *correctly-implemented* IKE1-only responder > > or > > "all commonly-used IKE1 implementations" > > ? > > I would say that the former is essential and the latter is highly desirable. > You're right, there is a difference... > > Henry Spencer > henry@spsystems.net Well, one has to ask the question, what should a "correctly-implemented" IKEv1 responder do? Unfortunately the RFC is not explicit... >From rfc.2408, section 5.2 ISAKMP Header Processing: " 3. Check the Major and Minor Version fields to confirm they are correct (see section 3.1). If the Version field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID ISAKMP VERSION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-MAJOR-VERSION or INVALID-MINOR- VERSION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy." What complicates the matter more is that even if the responder sends back a notify with the proper INVALID-MAJOR-REVISION set... this notify cannot be authenticated, and is not guaranteed to be delivered. This does not constitute a "reliable rejection" by the responder... atleast not a rejection that can be determined by the initiator. My point: IKEv1 does not adequately specify what must be done in error conditions during each step of the negotiation. Should this be a requirement for SOI? I believe that it should. Think of all the states the IKE/SOI engine can enter during a negotiation, and how one would go about aborting the negotiation in each of these states. Some examples: 1) the example above, where the responder rejects the first packet from the initiator and no state exists between peers. 2) when the initiator instantiates the SKEYID and sends an outbound packet, but the peer (responder) rejects inbound packet. 3) Initiator sends first round of Quick Mode and responder rejects proposal. These are just a few examples... Bottom line: Error handling in current IKE implementations is erratic and very vendor-specific. To our user community, this is very frustrating when VPNs fail to establish without a clear indication of what went wrong. ===================================================================== = Tylor Allison Secure Computing Corporation ========= = phone: 651.628.1554 e-mail: allison@securecomputing.com ========= ===================================================================== From owner-ipsec@lists.tislabs.com Tue Dec 18 17:51:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJ1pM215966; Tue, 18 Dec 2001 17:51:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11545 Tue, 18 Dec 2001 20:08:19 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Henry Spencer'" Cc: "'Michael Richardson'" , Subject: RE: Michael's comments on ikev2 draft Date: Tue, 18 Dec 2001 17:25:18 -0500 Message-ID: <002901c1882a$86f54730$8e2cb440@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Agreed. Implementations which don't send deletes continue > to be a source of > > interoperability problems. > > Which indicates foolish assumptions on the other end, since > delivery of > Delete is unreliable and most aspects of Delete support are optional. The problem is that the WG never standardized on an interoperable rekeying behaviour. We follow the now-expired Tim Jenkins rekeying draft, but others have invented at least 3 other distinct rekeying techniques. Fortunately, where incompatibilities exist, they are mostly fixed by the reception of a delete. The delete may be unreliable, but it still gets there most of the time. (I should point out that if the ADs had let us evolve IKE 3 years ago, we would have all implemented acknowledged deletes by now.) Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Henry Spencer > Sent: Tuesday, December 18, 2001 1:08 AM > To: Andrew Krywaniuk > Cc: 'Michael Richardson'; ipsec@lists.tislabs.com > Subject: Re: Michael's comments on ikev2 draft > > > On Mon, 10 Dec 2001, Andrew Krywaniuk wrote: > > > 3. Delete payloads are a MUST, which is also good. > > > > Agreed. Implementations which don't send deletes continue > to be a source of > > interoperability problems. > > Which indicates foolish assumptions on the other end, since > delivery of > Delete is unreliable and most aspects of Delete support are optional. > > However, the deeper point -- that too many significant things > in IKE are > unreliable or optional or both, and this needs fixing -- is valid. > > > Henry Spencer > > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Tue Dec 18 19:23:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJ3NH219369; Tue, 18 Dec 2001 19:23:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11742 Tue, 18 Dec 2001 21:40:35 -0500 (EST) From: "Jayant Shukla" To: "'IP Security List'" Subject: RE: IKEv2 and NAT traversal Date: Tue, 18 Dec 2001 18:47:16 -0800 Message-ID: <000001c18837$788f2370$0101a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3C1F1BD7.3B230861@F-Secure.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Ari Huttunen > > There are some things that one should stay away from, but I just can't > resist.. SSH already has a patent (application?) for that latter > approach as well. I don't have the number right now, but it was > applied for in Finland, and some years back. I seem to remember that > it was granted. I just mention this because you said you had some > patent application.. > There was nothing in my e-mail about the patent application. That e-mail was about various approaches to solving the NAT problem. If you cannot resist, then please start a separate thread instead of changing the direction of the discussion of this thread. If SSH approach is same as ours and their patent/application precedes ours, I will gracefully accept that. However, looking at what has been published so far, I very seriously doubt what they have done is anywhere near us. Anyway all this is speculation until we see their approach. You have already seen part of our approach at San Diego and the remainder will be presented at the next IETF meeting. > Purely technically, my view is that ignoring NAT effects is simpler > than trying to compensate. It's also quite sufficient to solve the > problem. > It may seem simpler but has a lot of problems. I did point out the issue with existing NATs that support IPsec pass thru. Not to mention problems with other networking protocols and standards. > > The way we have designed the solution, you don't need any > > modifications to IKE. Our solution is a more general NAT traversal > > solution, and non-IPsec people can also use it. The solution is > > ready and hopefully we will be ready to release it by March-April > > 2002. > > This WG is about making interoperable protocols. Why would the release > date of your company's product be significant? > The reason is very simple; instead of just describing it in a 10-20 min talk we want to show it working (in various configurations and with third party NAT boxes, even the ones with IPsec pass thru). Regards, Jayant From owner-ipsec@lists.tislabs.com Tue Dec 18 19:31:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJ3VY219566; Tue, 18 Dec 2001 19:31:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11774 Tue, 18 Dec 2001 21:53:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <002001c1880c$b1b79c70$8e2cb440@andrewk3.ca.newbridge.com> References: <002001c1880c$b1b79c70$8e2cb440@andrewk3.ca.newbridge.com> Date: Tue, 18 Dec 2001 21:28:31 -0500 To: From: Stephen Kent Subject: RE: IKEv2 traffic selector subsetting. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >> >Port-constrained SAs make sense in the case of a multi-user >> UNIX machine >> >where the phase 1 id associated with port FOO is not >> necessarily the same as >> >the id on port BAR. Port-constrained selectors are NOT the >> best mechanism >> >for implementing packet filtering. In the vast majority of >> VPN scenarios, a >> >list of subnets would be appropriate for expressing phase 2 >> selectors. >> >> I disagree. Port filtering is appropriate in IPsec for the same >> reasons it is appropriate in a firewall, i.e., a reasonable security >> policy may wish to constrain traffic from a specified source to a >> specific destination relative to a set of services offered by the >> destination. So, for example, I may wish to bypass traffic from any >> outside source directed to my SMTP server, but I want all such >> traffic to be SMTP traffic, to reduce the likelihood that the server >> can be attacked by external sources sending other types of traffic. > >I don't disagree that port filtering is appropriate; I just disagree with >your model. I think it's an SA to a specific destination with a >port-constrained policy. One implementation of this model could be an SA >with a back-reference to a decorrelated SPD entry. Another is a >topology-aware IPsec layer with a completely separate firewalling module. > Andrew, I don't know what the phrase "topology-aware IPsec layer" means, so I'm not sure what you are proposing. We have maintained that the SA binding for a packet must be maintained to ensure that the firewall-style rule checks are applied to packets in the context of the SAs with which the rules are associated. Steve From owner-ipsec@lists.tislabs.com Tue Dec 18 19:39:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJ3d1219985; Tue, 18 Dec 2001 19:39:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11800 Tue, 18 Dec 2001 22:03:52 -0500 (EST) Date: Tue, 18 Dec 2001 22:11:54 -0500 (EST) From: Henry Spencer To: Tylor Allison cc: IETF-IPSec Subject: Re: IKE v2 Requirements and backwards compatability 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, 18 Dec 2001, Tylor Allison wrote: > > > > (b) An IKE1-only responder must reliably reject attempts to use IKE2 > > > > to it. > > What complicates the matter more is that even if the responder sends back a > notify with the proper INVALID-MAJOR-REVISION set... this notify cannot be > authenticated, and is not guaranteed to be delivered. This does not > constitute a "reliable rejection" by the responder... atleast not a > rejection that can be determined by the initiator. It's rare that an IKE rejection can be determined by the initiator, so I was not considering that a requirement. The intended requirement is that it be 100% certain (i.e., reliable) that an IKE1-only responder will not misinterpret an IKE2 message as calling for some random set of IKE1 operations. > My point: IKEv1 does not adequately specify what must be done in error > conditions during each step of the negotiation. Should this be a > requirement for SOI? I believe that it should... This would certainly be helpful. More helpful yet would be some reliable way of notifying the other end about such problems... but that is most likely too much to hope for. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Dec 18 19:41:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJ3fW220127; Tue, 18 Dec 2001 19:41:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11809 Tue, 18 Dec 2001 22:06:35 -0500 (EST) Date: Tue, 18 Dec 2001 22:15:47 -0500 (EST) From: Henry Spencer To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: Michael's comments on ikev2 draft In-Reply-To: <002901c1882a$86f54730$8e2cb440@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 18 Dec 2001, Andrew Krywaniuk wrote: > The problem is that the WG never standardized on an interoperable rekeying > behaviour. We follow the now-expired Tim Jenkins rekeying draft, but others > have invented at least 3 other distinct rekeying techniques. Fortunately, > where incompatibilities exist, they are mostly fixed by the reception of a > delete. The delete may be unreliable, but it still gets there most of the > time... This I will agree with. While I believe that any implementation which relies on getting Deletes is unquestionably and inarguably broken -- not just different but verifiably *wrong* -- I concur that (a) such defective implementations do exist, (b) sending Delete improves interoperability with them, (c) much grief would have been avoided had these issues received proper attention in the standard, and (d) the next standard should not repeat the mistake. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 19 02:57:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJAv6228651; Wed, 19 Dec 2001 02:57:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12771 Wed, 19 Dec 2001 05:06:42 -0500 (EST) Date: Wed, 19 Dec 2001 11:13:25 +0100 From: Giaretta Gerardo Subject: Oakley groups To: ipsec@lists.tislabs.com Message-id: <9A761F39C9097F42977EAD1565F77E0920428F@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-type: text/plain; charset="iso-8859-1" Thread-Topic: Oakley groups Thread-Index: AcGIdRKly7LTbJkwS3OefKo6M0rYiwAAKpWg content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA12765 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, Oakley introduces some improvements to increase security in Diffie-Hellman algorithm (nonces, cookies etc.) It defines five groups with the global parameters of the algorithm, too: which advantages do these groups bring? Is there a security issue or it's only for a "standardization reason"? Thank you in advance Gerardo From owner-ipsec@lists.tislabs.com Wed Dec 19 02:57:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJAvD228662; Wed, 19 Dec 2001 02:57:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12785 Wed, 19 Dec 2001 05:11:46 -0500 (EST) Reply-To: From: "Masafumi Tsuruta" To: Subject: Reason of the Authentication Only Bit Date: Wed, 19 Dec 2001 19:15:00 +0900 Message-ID: <002101c18876$0533e4d0$8300a8c0@tsuruta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. According to some previous messages, I knew the reason why Authentication Only Bit was made is for "Key Recovery". But I can't understand why Authentication Only Bit is made good use of the Key Recovery. The translated book into Japanese; "IPSec: The New Security Standard for the Internet, Intranets, and Virtual Private Networks" by Naganand Doraswamy and Dan Harkins described as below in the section "Other IKE Exchanges". Informational Exchange messages don't need ACK answer from another entity, so once Initiator/Responder sent a Informational Exchange message, ISAKMP SA doesn't need to hold some information such as SKEYID_d or SKEYID_a. So ISAKMP SA clears these information. According to the description, I think if any information which is not concerned with the Informational Exchange message, those are remained in the ISAKMP SA. Is it correct? If my thinking for this question is correct, is the reason why Authentication Only Bit existence for the key recovery? I can't know correct contents of the book by the authors, which is described above, because I don't have original English book. However if these reasons are correct, where are the grounds for these arguments? If someone knows such information, please tell me the URL. Thank you and sorry for my broken English. Masafumi Tsuruta tsuruta@insi.co.jp -------------------------------------- International Network Security Inc. 3rd Yamada Building, 22Aizumi-cho, Shijyuku Tokyo, JAPAN Dept of Tech Masafumi Tsuruta http://www.insi.co.jp From owner-ipsec@lists.tislabs.com Wed Dec 19 07:23:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJFNO227041; Wed, 19 Dec 2001 07:23:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13674 Wed, 19 Dec 2001 09:24:46 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 19 Dec 2001 09:22:36 -0500 To: IETF-IPSec From: Paul Hoffman / VPNC Subject: Re: IKE v2 Requirements and backwards compatability Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:15 PM -0500 12/17/01, Henry Spencer wrote: >Fortunately, ISAKMP includes a >version number and mandates rejecting packets with unknown versions, Well, it's a SHOULD, not a MUST. RFC 2408, section 3.1: Implementations SHOULD never accept packets with a major version number larger than its own. But I think we can ignore that difference and assume that if any implementation does accept packets with a version higher than 1 are poorly designed. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Dec 19 07:27:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJFRG227148; Wed, 19 Dec 2001 07:27:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13679 Wed, 19 Dec 2001 09:24:48 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <007601c18768$3676d2f0$7480ad40@sfanninglaptop> References: <002101c18757$73b8a5f0$7480ad40@sfanninglaptop> <3C1EA02C.9040000@moquijo.com> <007601c18768$3676d2f0$7480ad40@sfanninglaptop> Date: Wed, 19 Dec 2001 09:22:36 -0500 To: "IETF-IPSec" From: Paul Hoffman / VPNC Subject: Re: IKE v2 Requirements and backwards compatibility Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:03 PM -0800 12/17/01, Scott Fanning wrote: >Unless IKEv2 is a subset of IKEv1 which would simplify things, but that seem >not to be the approach of the WG. Right. If you leave the version number the same, and SOI implementation implement a subset of IKEv1, then an SOI implementation and a IKEv1 implementation won't be able to interact well. The IKEv1 implementation will offer lots of things that the SOI implementation will not understand. To make a simplification, you need to signal to the old implementation "I'm doing something you don't expect". Version numbers are a good way to do that. This debate rages in many areas of the IETF, particularly the applications area. The two camps have the following basic features. Same port, different version number: - Works better through firewalls because no new port needs to be opened up - Faster migration because the admin of an older version sees an increasing error log entries over time for attempts to negotiate using the new version and feels bad about it Different port: - Cleaner, particularly if you can't be sure that older versions will fail gracefully when seeing the initial message in a new version on the old port - No extra round trip for falling back to the old version in dual-version systems In the case of revising IKEv1, I think that the "same port, different version number" model works well. SOI implementors should have initiators keep a cache of responders known to not use the higher version, and should put a reasonable TTL on the cache so that when the responder upgrades, the initiator will try the new version in a reasonable time. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Dec 19 08:15:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJGFP203258; Wed, 19 Dec 2001 08:15:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13849 Wed, 19 Dec 2001 10:19:21 -0500 (EST) Date: Wed, 19 Dec 2001 10:28:49 -0500 (EST) From: Henry Spencer To: Paul Koning cc: ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <15391.41773.970840.85991@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 Tue, 18 Dec 2001, Paul Koning wrote: > Assuming there are good reasons why an initiator would want to use > IKEv2 if it is available, you need a good mechanism that allows you to... > b. Discover that IKEv2 is not available, without undue delay, so you > can fall back to IKEv1. > Given that IKEv1 has a version number, and a correctly stated version > check rule, the answer is easy: use the same port, and a higher > version number... That's only the easy part of the answer, however. Assuming competent design, it is trivial for the responder to recognize (e.g. by the version number) that the incoming packet is for a protocol it doesn't know. The hard part is: *how is this communicated back to the initiator*? Especially, how is this communicated back by an existing implementation? There is a large bonus for having a "no IKE2 at the other end" recognition algorithm which doesn't require explicit help from the other end, so it can deal with old IKE1 implementations. About the only way to do this is to use a different port, and to put at least some level of trust in the ICMP Port Unreachable message. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 19 08:45:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJGjV205235; Wed, 19 Dec 2001 08:45:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14002 Wed, 19 Dec 2001 10:59:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15392.47983.271146.185793@pkoning.dev.equallogic.com> Date: Wed, 19 Dec 2001 11:08:15 -0500 (EST) From: Paul Koning To: allison@securecomputing.com Cc: ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability References: X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tylor" == Tylor Allison writes: Tylor> Well, one has to ask the question, what should a Tylor> "correctly-implemented" IKEv1 responder do? Unfortunately the Tylor> RFC is not explicit... >> From rfc.2408, section 5.2 ISAKMP Header Processing: Tylor> " 3. Check the Major and Minor Version fields to confirm they Tylor> are correct (see section 3.1). If the Version field Tylor> validation fails, the message is discarded and the following Tylor> actions are taken: Tylor> (a) The event, INVALID ISAKMP VERSION, MAY be logged in the Tylor> appropriate system audit file. Tylor> (b) An Informational Exchange with a Notification payload Tylor> containing the INVALID-MAJOR-VERSION or INVALID-MINOR- VERSION Tylor> message type MAY be sent to the transmitting entity. This Tylor> action is dictated by a system security policy." That's explicit enough. Unfortunately, it's also the not the answer you'd want to see. In order to deal with IKEv1 vs. IKEv2 "without undue delay" as I suggested should be the requirement, you need a timely way to recognize a V1-only implementation. If the "invalid version number" message were mandatory, this could be done (modulo the issue of lack of authentication). Given that the message is optional, the version number field has no value. It sounds like we're stuck with timeout as the mechanism for detecting V1-only implementations. Yuck. If that's right, then there is no reason to stick with the old port number. paul From owner-ipsec@lists.tislabs.com Wed Dec 19 09:57:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJHvX207977; Wed, 19 Dec 2001 09:57:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14210 Wed, 19 Dec 2001 12:10:04 -0500 (EST) To: Stephen Kent Cc: , Subject: Re: IKEv2 traffic selector subsetting. References: <002001c1880c$b1b79c70$8e2cb440@andrewk3.ca.newbridge.com> From: Derek Atkins Date: 19 Dec 2001 12:20:04 -0500 In-Reply-To: Stephen Kent's message of "Tue, 18 Dec 2001 21:28:31 -0500" Message-ID: Lines: 31 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Stephen Kent writes: > We have maintained that the SA binding for a packet must be > maintained to ensure that the firewall-style rule checks are applied > to packets in the context of the SAs with which the rules are > associated. What I don't understand is why this 'binding' needs to be agreed upon? The binding of the packet to the SA is quite easy -- the packet is encrypted/signed under the ESP/AH key negotiated earlier. If the "firewall" rules are locally defined, then isn't it sufficient to know within the IPsec/firewall processing that a particular inbound packet is associated with SA #x? What do traffic selectors really buy you in the face of locally-defined firewalling rules? I suppose it can be a "request" of your peer not to send you traffic that you plan to drop/ignore. But that's just a convenience for your sake; you still have to check every packet against your local inbound rules. > Steve -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Dec 19 10:07:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJI74208696; Wed, 19 Dec 2001 10:07:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14298 Wed, 19 Dec 2001 12:22:51 -0500 (EST) To: Henry Spencer Cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Michael's comments on ikev2 draft References: From: Derek Atkins Date: 19 Dec 2001 12:32:13 -0500 In-Reply-To: Henry Spencer's message of "Tue, 18 Dec 2001 22:15:47 -0500 (EST)" Message-ID: Lines: 30 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > This I will agree with. While I believe that any implementation which > relies on getting Deletes is unquestionably and inarguably broken -- not > just different but verifiably *wrong* -- I concur that (a) such defective > implementations do exist, (b) sending Delete improves interoperability > with them, (c) much grief would have been avoided had these issues > received proper attention in the standard, and (d) the next standard > should not repeat the mistake. Having a _reliable_ delete notification is, IMHO, a good idea. REQUIRING deletes to happen is certainly wrong. However there are times when I know I want to _shut down_ ipsec and there is no way to reliably do that remotely. I know that my particular case is relatively wackball (I unfortunately can't go into the details online). But suffice it to say that if I had a reliable delete notification it would have saved a lot of hand-editing and meant that my server never needed to be touched. > Henry Spencer > henry@spsystems.net -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Dec 19 10:33:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJIXN211017; Wed, 19 Dec 2001 10:33:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14417 Wed, 19 Dec 2001 12:49:45 -0500 (EST) Date: Wed, 19 Dec 2001 12:59:12 -0500 (EST) From: Henry Spencer To: Derek Atkins cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 traffic selector subsetting. 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 19 Dec 2001, Derek Atkins wrote: > What do traffic selectors really buy you in the face of > locally-defined firewalling rules? I suppose it can be a "request" of > your peer not to send you traffic that you plan to drop/ignore. But > that's just a convenience for your sake; you still have to check every > packet against your local inbound rules. For the peer, it's more than just a convenience -- it's a guarantee that errors of various kinds will not send packets into a black hole. The peer has to decide *somehow* which packets go into the tunnel, and having that independently configured on the two ends is asking for trouble. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 19 10:49:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJIng211353; Wed, 19 Dec 2001 10:49:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14507 Wed, 19 Dec 2001 13:04:20 -0500 (EST) To: Henry Spencer Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 traffic selector subsetting. References: From: Derek Atkins Date: 19 Dec 2001 13:13:51 -0500 In-Reply-To: Henry Spencer's message of "Wed, 19 Dec 2001 12:59:12 -0500 (EST)" Message-ID: Lines: 31 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On 19 Dec 2001, Derek Atkins wrote: > > What do traffic selectors really buy you in the face of > > locally-defined firewalling rules? I suppose it can be a "request" of > > your peer not to send you traffic that you plan to drop/ignore. But > > that's just a convenience for your sake; you still have to check every > > packet against your local inbound rules. > > For the peer, it's more than just a convenience -- it's a guarantee that > errors of various kinds will not send packets into a black hole. The peer > has to decide *somehow* which packets go into the tunnel, and having that > independently configured on the two ends is asking for trouble. Why? I send you what I plan to accept; you send me what you plan to accept. Nothing says that these two statements of acceptance have to agree, and nothing states that you have to actually comply. Basically, you're saying that I need to send you the equivalent of all the firewall rules that affect you? > Henry Spencer > henry@spsystems.net -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Dec 19 11:00:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJJ0s211653; Wed, 19 Dec 2001 11:00:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14531 Wed, 19 Dec 2001 13:12:46 -0500 (EST) Message-Id: <200112191822.NAA16054@bcn.East.Sun.COM> Date: Wed, 19 Dec 2001 13:22:43 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Should Alice say who she wants to talk to? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zHJvRS2d89aC6EXX8MF7RA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos Keromytis said: >> Actually, this is precisely what the "suggested ID" draft Bill Sommerfeld >> and I have, which Bill discussed briefly on the Wednesday session. The name >> is draft-keromytis-ike-id-00.txt. >> This was for IKEv1, and mostly intended for bidirectional user-keying, but it >> can be used for what you want it. Yup. Great draft! I like short. But I printed it double-sided and went searching through other people's bins to see what happened to the rest of my printout :-) Never before saw a draft that fit on one page. Radia From owner-ipsec@lists.tislabs.com Wed Dec 19 11:35:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJJZN213287; Wed, 19 Dec 2001 11:35:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14633 Wed, 19 Dec 2001 13:47:30 -0500 (EST) Date: Wed, 19 Dec 2001 13:56:58 -0500 (EST) From: Henry Spencer To: Derek Atkins cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 traffic selector subsetting. 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 19 Dec 2001, Derek Atkins wrote: > > For the peer, it's more than just a convenience -- it's a guarantee that > > errors of various kinds will not send packets into a black hole. The peer > > has to decide *somehow* which packets go into the tunnel, and having that > > independently configured on the two ends is asking for trouble. > > Why? I send you what I plan to accept; you send me what you plan to > accept. Nothing says that these two statements of acceptance have to > agree, and nothing states that you have to actually comply. Except that if they don't, or you don't, then the connection *doesn't work* and it's very hard to figure out why. IPsec is already far too prone to this sort of mysterious problem. What you say is correct, but is relevant only in a perfect world. In the real world, protocols which *check* that the two ends are in agreement on the details are far more practical, robust, and usable. There is also a definite possibility, as in our Opportunistic Encryption proposal (draft-richardson-ipsec-opportunistic-03.txt), that one end doesn't even *know* what packets the other end wants until the other end proposes the connection. Yes, these problems can be solved by using hypothetical policy protocols to negotiate all of this, but (a) that adds unnecessary complications, and (b) proposals for practical protocols should not invoke the Tooth Fairy to solve all the hard problems. > Basically, you're saying that I need to send you the equivalent of all > the firewall rules that affect you? You should tell me what packets you will accept, and what packets you propose to send, so that I can check that against my understanding of what the connection is supposed to be, and verify that the connection can be established *successfully*. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Dec 19 15:53:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBJNrV228847; Wed, 19 Dec 2001 15:53:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15406 Wed, 19 Dec 2001 17:49:07 -0500 (EST) Message-ID: <89680B404BA1DD419E6D93B28B41899B034631@01mail.nomadix.com> From: Amit Paunikar To: "'ipsec@lists.tislabs.com'" Subject: IPSEC with PAT and Rekeying Issues Date: Wed, 19 Dec 2001 14:49:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C188DF.7D07EB00" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C188DF.7D07EB00 Content-Type: text/plain; charset="iso-8859-1" Hi, We are in a process of implementing IPSEC thru a PAT device. After initial implementation with ISAKMP over source port 500/ destination port 500 we moved to implementation of ISAKMP over source port /500 implementation to enable certain VPN servers to allow multiple connections coming from the same client IP address. Since they rely on different source ports to identify different clients coming from the same IP address. The problem however is that it fails on a rekey. When the client is inactive (not sending any traffic) the rekey fails 100 %. In case the client is active (ftp traffic) then rekey succeeds about 33%.. Any ideas? Is it that servers want rekey to happen at 500/500 only? Does the server doesnt like me fiddling with the port numbers? (we are using tunnel mode ESP) the logs of interaction are below. I observe that the reason for failure is that there are 0 Phase 1 SAs currently in the system Any help woudl be appreciated, Thanks, Amit 696 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 64.209.75.174 697 16:31:01.367 12/18/01 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 64.209.75.174 698 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x63000018 Deleting IPsec SA: (OUTBOUND SPI = CFD7402 INBOUND SPI = AB1B734D) 699 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x6300002F Received ISAKMP packet: peer = 64.209.75.174 700 16:31:01.367 12/18/01 Sev=Info/4 IKE/0x63000014 RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 64.209.75.174 701 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x6300003C Received a DELETE payload for IKE SA with Cookies = 400539EC1B31FA0F86EBBAE9D13B58B1 702 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x63000017 Marking IKE SA for deletion (COOKIES = 400539EC1B31FA0F 86EBBAE9D13B58B1) reason = DEL_REASON_PEER_DELETION 703 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0x4d731bab 704 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x6370000C Key deleted by SPI 0x4d731bab 705 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x63700013 Delete internal key with SPI=0x0274fd0c 706 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x6370000C Key deleted by SPI 0x0274fd0c 707 16:31:03.080 12/18/01 Sev=Info/5 IKE/0x63000055 Received a key request from Driver for IP address 255.255.255.255, GW IP = 64.209.75.174 708 16:31:03.080 12/18/01 Sev=Warning/3 IKE/0xE3000062 Could not find an IKE SA for 64.209.75.174. KEY_REQ aborted. 709 16:31:03.420 12/18/01 Sev=Info/4 IPSEC/0x63700010 Created a new key structure 710 16:31:04.923 12/18/01 Sev=Info/4 CM/0x63100013 Phase 1 SA deleted cause by DEL_REASON_PEER_DELETION. 0 Phase 1 SA currently in the system ------_=_NextPart_001_01C188DF.7D07EB00 Content-Type: text/html; charset="iso-8859-1"
Hi,
We are in a process of implementing IPSEC thru a PAT device.
After initial implementation with ISAKMP over source port 500/ destination port 500 we moved to
implementation of ISAKMP over source port <PATed port>/500 implementation to enable certain
VPN servers to allow multiple connections coming from the same client IP address. Since they rely on
different source ports to identify different clients coming from the same IP address.
 
The problem however is that it fails on a rekey. When the client is inactive (not sending any traffic)
the rekey fails 100 %. In case the client is active (ftp traffic) then rekey succeeds about 33%..
 
Any ideas?
Is it that servers want rekey to happen at 500/500 only?
Does the server doesnt like me fiddling with the port numbers? (we are using tunnel mode ESP)
 
the logs of interaction are below. I observe that the reason for failure is that
there are 0 Phase 1 SAs currently in the system
 
Any help woudl be appreciated,
Thanks,
Amit
 

696 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 64.209.75.174

697 16:31:01.367 12/18/01 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 64.209.75.174

698 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x63000018

Deleting IPsec SA: (OUTBOUND SPI = CFD7402 INBOUND SPI = AB1B734D)

699 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 64.209.75.174

700 16:31:01.367 12/18/01 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 64.209.75.174

701 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x6300003C

Received a DELETE payload for IKE SA with Cookies = 400539EC1B31FA0F86EBBAE9D13B58B1

702 16:31:01.367 12/18/01 Sev=Info/5 IKE/0x63000017

Marking IKE SA for deletion (COOKIES = 400539EC1B31FA0F 86EBBAE9D13B58B1) reason = DEL_REASON_PEER_DELETION

703 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x63700013

Delete internal key with SPI=0x4d731bab

704 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x6370000C

Key deleted by SPI 0x4d731bab

705 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x63700013

Delete internal key with SPI=0x0274fd0c

706 16:31:01.417 12/18/01 Sev=Info/4 IPSEC/0x6370000C

Key deleted by SPI 0x0274fd0c

707 16:31:03.080 12/18/01 Sev=Info/5 IKE/0x63000055

Received a key request from Driver for IP address 255.255.255.255, GW IP = 64.209.75.174

708 16:31:03.080 12/18/01 Sev=Warning/3 IKE/0xE3000062

Could not find an IKE SA for 64.209.75.174. KEY_REQ aborted.

709 16:31:03.420 12/18/01 Sev=Info/4 IPSEC/0x63700010

Created a new key structure

710 16:31:04.923 12/18/01 Sev=Info/4 CM/0x63100013

Phase 1 SA deleted cause by DEL_REASON_PEER_DELETION. 0 Phase 1 SA currently in the system

------_=_NextPart_001_01C188DF.7D07EB00-- From owner-ipsec@lists.tislabs.com Wed Dec 19 17:11:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK1Bk203186; Wed, 19 Dec 2001 17:11:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15723 Wed, 19 Dec 2001 19:29:30 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Stephen Kent'" Cc: Subject: RE: IKEv2 traffic selector subsetting. Date: Wed, 19 Dec 2001 19:07:47 -0500 Message-ID: <005701c188ee$478f4450$8e2cb440@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I don't know what the phrase "topology-aware IPsec layer" means, so > I'm not sure what you are proposing. I assume that something in the IPsec layer (i.e. IKE) knows enough about the topology to know which subnets are behind which gateways. > We have maintained that the SA binding for a packet must be > maintained to ensure that the firewall-style rule checks are applied > to packets in the context of the SAs with which the rules are > associated. What I am saying is that there are basically 3 different levels at which the SA binding can be done: 1) Do NO filtering at the SADB and pass the SA context information up to the firewall ala draft-touch. 2) Do the SA binding at the SADB and do the firewall filtering at the firewall. 3) Do BOTH the SA binding and firewall filtering at the SADB, which is what it seems you are proposing. My claim was that if you ensure that the phase 2 selectors enforce the IP->identity bindings (i.e. which subnets are behind which gateways & which roaming clients are at which IPs), then (2) will suffice since your firewall can be assured that the SA binding of any packet it receives has already been vetted. Note that I have no objection to (and actually endorse) an integrated IPsec-firewall component (if you integrate the two then the above distinctions are moot). But your objection is always "what if the SADB and firewall are on different machines?" It seems to me that 2401 is trying to skirt the issue by integrating the functionality of a very basic firewall into IPsec (thus *causing* the SADB and firewall to be on the same machine). But it is an incomplete solution because you may still need an external firewall. I just prefer a different solution, in which IPsec cooperates with (or merges with) the firewall rather than duplicating one part of its functionality. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed Dec 19 20:41:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK4fF209149; Wed, 19 Dec 2001 20:41:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16142 Wed, 19 Dec 2001 22:42:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0 Content-Class: urn:content-classes:message Subject: RE: Should Alice say who she wants to talk to? Date: Wed, 19 Dec 2001 19:50:04 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE6972@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Should Alice say who she wants to talk to? thread-index: AcGIyy6wfijgm64SQ2CeQ3ck5jO62gAOyQZQ From: "William Dixon" To: "Radia Perlman - Boston Center for Networking" , X-OriginalArrivalTime: 20 Dec 2001 03:50:04.0656 (UTC) FILETIME=[68A6D700:01C18909] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The idea in the draft that Angelos & Bill have proposed is very much needed for proper responder policy processing based on ID. If I have 2 IPSec aware services on the same box, the responder needs to use the right MM configuration to reply, at a minimum the right credential to reply based on the ID requested/expected by the initiator. Yes Radia, we should design to accommodate a better credential system for web service use. I think there is sufficient support for a DOS mode that prevents attacks on DH. So we should do the DH first to protect against passive listening ID exposure. That is the bigger threat I see. Say that one service uses a Public PKI Root/credential for trust, and the other service uses a corporate root/credential for trust - then you would need to know the initiator's intended service ID early, so the proper CRP negotiation could be sent by the responder, allowing the initiator to pick the right credential. As I said in in my comments at the mike, we need to be able to do responder authentication first if it's a published service, or initiator authentication first if it's a private service. A structure/usage specified for the ID will ensure interoperability of policy systems - so you can distinguish between a request to authenticate machine, service or user. Example use cases that achieve specific scenarios is also needed to ensure interop. Note that selection of auth method may be dependent on the ID requested, because that ID may only have 1 auth method available to it. Perhaps there is some part of trust negotiation research that is not encumbered could be useful here. -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@Sun.COM] Sent: Wednesday, December 19, 2001 10:23 AM To: ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? Angelos Keromytis said: >> Actually, this is precisely what the "suggested ID" draft Bill Sommerfeld >> and I have, which Bill discussed briefly on the Wednesday session. >>The name >> is draft-keromytis-ike-id-00.txt. >> This was for IKEv1, and mostly intended for bidirectional >>user-keying, but it >> can be used for what you want it. Yup. Great draft! I like short. But I printed it double-sided and went searching through other people's bins to see what happened to the rest of my printout :-) Never before saw a draft that fit on one page. Radia From owner-ipsec@lists.tislabs.com Wed Dec 19 20:41:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK4fJ209161; Wed, 19 Dec 2001 20:41:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16135 Wed, 19 Dec 2001 22:41:20 -0500 (EST) Message-Id: <200112200349.fBK3nI422092@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 traffic selector subsetting. In-reply-to: Your message of "Wed, 19 Dec 2001 19:07:47 EST." <005701c188ee$478f4450$8e2cb440@andrewk3.ca.newbridge.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Dec 2001 22:49:17 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> What I am saying is that there are basically 3 different levels Andrew> at which the SA binding can be done: Andrew> 1) Do NO filtering at the SADB and pass the SA context Andrew> information up to the firewall ala draft-touch. Andrew> 2) Do the SA binding at the SADB and do the firewall filtering at Andrew> the firewall. Andrew> 3) Do BOTH the SA binding and firewall filtering at the SADB, Andrew> which is what it seems you are proposing. I guess I just don't get the problem. I must say that I was lost during Joe's presentation as well. Unless you are a BITS/BITW, then I don't see why you have both an SPD/SADB and a firewall. Sure, there are time-to-market issues why you do both for awhile. There are also political issues (turf wars) too. But, if you can architect from scratch, rfc2401 is simply "IETF standard firewall". It happens to include strong source origination checking. It is lacking any kind of support for stateful fragment or connection tracking, but it doesn't forbid that. In the *BSD world, people talk about combining IPF and the KAME SPD. In the FreeSWAN world, we plan to use the Netfilter system to implement our SPD. (Yes, there is an ordering constraint issue, but decorolation solves it, and our UI isn't compliant about the ordering constraint at this time anyway) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPCFfuoqHRg3pndX9AQH0awP/Z4EDTSQyCAFGTtOdPmDDhjb5v8kFYjyw ZjLDPnI03+FvQtXm41lWNLtOaN2I6CUztQBUWATZBZafuZ/XFaIhAB5CMaybeeSn LX3JXaFDkvxqtK6Nf0IlVhDbE47S+aV+7mJqCmBm6N197XaObQpLiVUy/veZ2/w1 EvKbA13GFUI= =7zy2 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 19 21:25:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBK5P5210003; Wed, 19 Dec 2001 21:25:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16293 Wed, 19 Dec 2001 23:49:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" x-receiver: m.gratton@adga.ca Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Class: urn:content-classes:message Subject: RE: Should Alice say who she wants to talk to? Date: Wed, 19 Dec 2001 19:50:04 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE6972@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Should Alice say who she wants to talk to? thread-index: AcGIyy6wfijgm64SQ2CeQ3ck5jO62gAOyQZQ From: "William Dixon" To: "Radia Perlman - Boston Center for Networking" , X-OriginalArrivalTime: 20 Dec 2001 03:50:04.0656 (UTC) FILETIME=[68A6D700:01C18909] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The idea in the draft that Angelos & Bill have proposed is very much needed for proper responder policy processing based on ID. If I have 2 IPSec aware services on the same box, the responder needs to use the right MM configuration to reply, at a minimum the right credential to reply based on the ID requested/expected by the initiator. Yes Radia, we should design to accommodate a better credential system for web service use. I think there is sufficient support for a DOS mode that prevents attacks on DH. So we should do the DH first to protect against passive listening ID exposure. That is the bigger threat I see. Say that one service uses a Public PKI Root/credential for trust, and the other service uses a corporate root/credential for trust - then you would need to know the initiator's intended service ID early, so the proper CRP negotiation could be sent by the responder, allowing the initiator to pick the right credential. As I said in in my comments at the mike, we need to be able to do responder authentication first if it's a published service, or initiator authentication first if it's a private service. A structure/usage specified for the ID will ensure interoperability of policy systems - so you can distinguish between a request to authenticate machine, service or user. Example use cases that achieve specific scenarios is also needed to ensure interop. Note that selection of auth method may be dependent on the ID requested, because that ID may only have 1 auth method available to it. Perhaps there is some part of trust negotiation research that is not encumbered could be useful here. -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@Sun.COM] Sent: Wednesday, December 19, 2001 10:23 AM To: ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? Angelos Keromytis said: >> Actually, this is precisely what the "suggested ID" draft Bill Sommerfeld >> and I have, which Bill discussed briefly on the Wednesday session. >>The name >> is draft-keromytis-ike-id-00.txt. >> This was for IKEv1, and mostly intended for bidirectional >>user-keying, but it >> can be used for what you want it. Yup. Great draft! I like short. But I printed it double-sided and went searching through other people's bins to see what happened to the rest of my printout :-) Never before saw a draft that fit on one page. Radia From owner-ipsec@lists.tislabs.com Thu Dec 20 06:38:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKEch203888; Thu, 20 Dec 2001 06:38:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17438 Thu, 20 Dec 2001 08:38:39 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15393.54557.737364.744047@ryijy.hel.fi.ssh.com> Date: Thu, 20 Dec 2001 14:10:05 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: pkoning@equallogic.com Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: pkoning@equallogic.com's message of "Wed, 19 Dec 2001 17:27:16 +0000 (UTC)" References: <15392.47983.271146.185793@pkoning.dev.equallogic.com> X-Mailer: Gnus v5.7/Emacs 20.7 X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk pkoning@equallogic.com (Paul Koning) writes: > In order to deal with IKEv1 vs. IKEv2 "without undue delay" as I > suggested should be the requirement, you need a timely way to > recognize a V1-only implementation. If the "invalid version number" > message were mandatory, this could be done (modulo the issue of lack > of authentication). In some cases there is no way to know if the other end talks IKE at all without timeouts. > It sounds like we're stuck with timeout as the mechanism for detecting > V1-only implementations. Yuck. If that's right, then there is no > reason to stick with the old port number. I don't think we are stuck with timeouts in common case. There are implementations out there that WILL send the notification. This means that if you start IKEv2 negotiation with them they will send notification back and you can immediately fall back to IKEv1. If the other end is one of those which does not send the notification then you have to wait until the timeout expires, but I think more IKEv1 implementations will start sending those notifications when IKEv2 starts get used, even if they do not support any other notifications, just to get rid of those timeouts. I.e if you notice that when I use vendor A products it immediately notices IKEv2 is not understood and falls back to IKEv1 without timeout, and for vendor B products you have to wait until timeout expires I think most of the users will consider the vendor A product better, thus vendor B will fix its code to send notifications. Also current installed base is mostly VPNs and there you can preconfigure that the other end only supports IKEv1 to get rid of timeout. For oppurtunistic encryption case etc where you don't know anything about the other end you might want to put that kind of information to the TXT record containing the public key itself... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 20 06:38:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKEcu203902; Thu, 20 Dec 2001 06:38:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17445 Thu, 20 Dec 2001 08:39:38 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15393.55014.882682.533509@ryijy.hel.fi.ssh.com> Date: Thu, 20 Dec 2001 14:17:42 +0200 From: Tero Kivinen To: IPsec List Subject: Re: rushed comments on IKEv2 draft In-Reply-To: hugh@mimosa.com's message of "Wed, 12 Dec 2001 10:44:51 +0000 (UTC)" References: X-Mailer: Gnus v5.7/Emacs 20.7 X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hugh@mimosa.com ("D. Hugh Redelmeier") writes: > - in IKEv1, there are a few constraints on payload order. In our > interop testing, we think all implementations sent payloads in the > order used in the RFC. So this was useless freedom, causing > more test cases, ones that have probably never been exercised! > I suggest that the payload order be fully specified. I disagree. I think it is easier to say that payloads can be any order. I would like to remove all payload ordering dependecies from the IKE. > - viewing all IKE messages as fitting into request/response > pairs may be a straightjacket. Each message that is neither the > first nor the last could be designed as as a response to the > previous message AND a request for the next. On the other hand, the > pure request/response view may be easier to understand. I think the pure request/response view is so much easier to understand and implement the retransmission of the packets correctly that it justifies its use. There are quite a lot of different things you have to do properly when doing retranimssions in current IKE that it is very hard to get them right (and to test all wierd cases). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 20 06:42:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKEgb203963; Thu, 20 Dec 2001 06:42:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17429 Thu, 20 Dec 2001 08:36:39 -0500 (EST) Message-Id: <200112200546.fBK5kmq5026608@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: "William Dixon" Cc: "Radia Perlman - Boston Center for Networking" , ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-reply-to: Your message of "Wed, 19 Dec 2001 19:50:04 PST." <2E33960095B58E40A4D3345AB9F65EC102EE6972@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Dec 2001 00:46:48 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, I guess we should rename the draft in the draft-ietf-ipsec-* workspace, fill in the few blanks (explicitly show where the suggested ID is included in the HASH) and be done with this ? One question I have: how would current implementations handle receiving an IKEv1 message 3 which had an extra payload ? Would they ignore it, or loudly complain and refuse to proceed ? The draft says that the Responder may ignore the suggested ID (so the Initiator cannot depend on the suggested value being returned), which is great if implementations ignore extra payloads. (I'm trying to avoid having to bump the minor version number.) -Angelos In message <2E33960095B58E40A4D3345AB9F65EC102EE6972@win-msg-01.wingroup.windep loy.ntdev.microsoft.com>, "William Dixon" writes: >The idea in the draft that Angelos & Bill have proposed is very much >needed for proper responder policy processing based on ID. If I have 2 >IPSec aware services on the same box, the responder needs to use the >right MM configuration to reply, at a minimum the right credential to >reply based on the ID requested/expected by the initiator. Yes Radia, >we should design to accommodate a better credential system for web >service use. I think there is sufficient support for a DOS mode that >prevents attacks on DH. So we should do the DH first to protect against >passive listening ID exposure. That is the bigger threat I see. > >Say that one service uses a Public PKI Root/credential for trust, and >the other service uses a corporate root/credential for trust - then you >would need to know the initiator's intended service ID early, so the >proper CRP negotiation could be sent by the responder, allowing the >initiator to pick the right credential. > >As I said in in my comments at the mike, we need to be able to do >responder authentication first if it's a published service, or initiator >authentication first if it's a private service. > >A structure/usage specified for the ID will ensure interoperability of >policy systems - so you can distinguish between a request to >authenticate machine, service or user. Example use cases that achieve >specific scenarios is also needed to ensure interop. Note that >selection of auth method may be dependent on the ID requested, because >that ID may only have 1 auth method available to it. > >Perhaps there is some part of trust negotiation research that is not >encumbered could be useful here. > >-----Original Message----- >From: Radia Perlman - Boston Center for Networking >[mailto:Radia.Perlman@Sun.COM] >Sent: Wednesday, December 19, 2001 10:23 AM >To: ipsec@lists.tislabs.com >Subject: Re: Should Alice say who she wants to talk to? > > > >Angelos Keromytis said: >>> Actually, this is precisely what the "suggested ID" draft Bill >Sommerfeld >>> and I have, which Bill discussed briefly on the Wednesday >session. >>The >name >>> is draft-keromytis-ike-id-00.txt. > >>> This was for IKEv1, and mostly intended for bidirectional >>>user-keying, >but it >>> can be used for what you want it. > >Yup. Great draft! I like short. But I printed it double-sided and went >searching through other people's bins to see what happened to the rest >of my printout :-) Never before saw a draft that fit on one page. > >Radia > From owner-ipsec@lists.tislabs.com Thu Dec 20 10:03:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKI3s216895; Thu, 20 Dec 2001 10:03:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18020 Thu, 20 Dec 2001 12:06:51 -0500 (EST) Date: Thu, 20 Dec 2001 12:16:12 -0500 (EST) From: Henry Spencer To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: IKEv2 traffic selector subsetting. In-Reply-To: <005701c188ee$478f4450$8e2cb440@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Dec 2001, Andrew Krywaniuk wrote: > It seems to me that 2401 is trying to skirt the issue by integrating the > functionality of a very basic firewall into IPsec (thus *causing* the SADB > and firewall to be on the same machine). Exactly! This is never advertised as such in the IPsec documents for some unfathomable reason -- much confusion would be saved if it were made more explicit -- but they basically include a specification for an Internet-standard minimum firewall mechanism. Firewalls are, very obviously when you think about it, a vital part of IP security. And that's what "IPsec" stands for; it's not just encryption. > But it is an incomplete solution > because you may still need an external firewall. Why? Note that the IPsec specs set a minimum requirement only; they don't prohibit adding any further functionality you may need. > I just prefer a different > solution, in which IPsec cooperates with (or merges with) the firewall > rather than duplicating one part of its functionality. Why do you assume that this is a different solution? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Dec 20 15:07:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBKN7k203184; Thu, 20 Dec 2001 15:07:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18691 Thu, 20 Dec 2001 17:01:53 -0500 (EST) Message-ID: <3C226189.736A8882@certicom.com> Date: Thu, 20 Dec 2001 17:09:13 -0500 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Andrew Krywaniuk CC: "'IP Security List'" Subject: Re: IKEv2 traffic selector subsetting. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This mail is not exactly about traffic selector subsetting, but it's related to traffic selectors very much, so I didn't want to start a new thread. I've been thinking about Phase 1 and Phase 2 exchanges in IKEv2 and it looks that IKE negotiation might be simplified for traffic selectors and number of IKE messages to complete IKE negotiation between the initiator and responder. The IKE negotiation as it stands in IKEv2 document now is following - Phase 1 exchange Initiator Responder ----------- ----------- HDR, SA, KE, Ni [,CERTREQ] --> <-- HDR, SA, KE, Nr [,CERTREQ] HDR*, ID, AUTH, [CERT,] SA, TSi, TSr --> <-- HDR*, ID, AUTH, [CERT,] SA, TSi, TSr then The CREATE_CHILD_SA exchange (Phase 2): Initiator Responder ----------- ----------- HDR*, SA, Ni, [KEi,] TSi, TSr --> <-- HDR*, SA, Nr, [KEr,] TSi, TSr I think instead of having two phases we might be able to achive the same traffic selections by reducing the IKE negotiation to only one exchange - Phase 1 exchange Initiator Responder ----------- ----------- HDR, SA, KE, Ni [,CERTREQ] --> <-- HDR, SA, KE, Nr [,CERTREQ] HDR*, ID, AUTH, [CERT,] [KEi,] SA, TSi, TSr [SA0, TSi0, TSr0,] [SA1, TSi1, TSr1, ...] --> <-- HDR*, ID, AUTH, [CERT,] [KEr,] SA, TSi, TSr [SA0, TSi0, TSr0,] [SA1, TSi1, TSr1, ...] So, the intiator will propose all rules for traffic selectors. The key derivation will not change. So, Phase 2 is not required in this case. I know that the second messages are a bit overloaded, but there is no duplication of traffic selectors in Phase 1 and Phase 2 and number of messages (4) is minimal. Still, the initiator/responder can use CREATE_CHILD_SA exchange for rekeying. We can also add extra nonces in the second messages if we want. I might have missed something here, but I thought it would be useful to write down this idea. Other idea is to move initiator's [,CERTREQ] payload to initiator's second message since responder's certificate is sent in responder's second message. For developers it would be easier to implement the latter, otherwise the responder would have to keep a state between initiator's first message and responder's second message. It's not a big deal, the developers will adapt, but it would be nice to get rid of the [,CERTREQ] state for the responder. Thanks, Yuri Poeluev Andrew Krywaniuk wrote: > > > > ...If you > > > wish to avoid sending traffic that will be filtered out by > > the peer then > > > that would be best accomplished by an IPSP protocol. > > > > I.e., "by some hypothetical protocol yet to be defined". > > > > It's better to solve the problem than to pretend that someone > > somehow will > > deliver a solution when required. IKE has demonstrated that simple > > solutions are adequate for many purposes. Deliberately excluding this > > from son-of-IKE may be ideologically preferable but makes no > > sense as a > > matter of practical engineering. > > Being idealistic is something that I am rarely accused of. My point is that > there is a difference between phase 2 traffic selectors (which represent an > IP->identity binding), and policy (which can be complex, ordered, and > asymmetric). > > The IP->id binding is something that needs to be agreed upon, because it > verifies that the peers agree on which protected subnets are behind which > gateway (or which user is logged into the remote computer). The bindings > are > relatively static and they could be obtained from trusted sources like a > configuration file or a DNS record. > > The policy rules, on the other hand, are basically a re-implementation of > firewalling. They don't need to be negotiated; they simply need to be > enforced at each end. The fact that we negotiated an SA from A to B doesn't > mean that I'm going to accept all UDP traffic to port 17 at 5:15 am on > odd-numbered Tuesdays. The policy can change at any time and it need not be > shared with the peer ahead of time. > > The bindings need to be agreed upon, whereas the two policies are ukases > (which should be merged independently at each side); this is the key > distinction between them. In IKEv1, the responder couldn't change the > traffic selectors so they had to be preshared (this is inappropriate for > policy). In IKEv2, the responder can narrow the traffic selectors but there > are still potential issues (like what happens if the responder's narrow > selectors don't include the packet that triggered the negotiation). > > The problem stems from the attempt to merge the bindings and the traffic > selectors. The bindings are essential for security, whereas the policy is > merely an optimization which allows you to avoid forwarding packets that > the > peer has informed you he intends to drop. > > Although I said that traffic filtering would be best accomplished by an > IPSP > protocol, I don't personally care whether that protocol is run as a > separate > negotiation stage or tacked onto IKE (although the complexity-Nazis may > take > issue with that). My main comment is that it would be better to have a > separate policy payload rather than overloading to traffic selectors to do > two different things. > > I suppose if you wanted to, you could use a second set of traffic selectors > in the quick mode to express policy, but I don't think that's a very good > idea. The traffic selectors in IKE don't do a very good job of expressing > every useful policy. Having a policy payload allows you to use an SA for > multiple non-adjacent traffic selectors. Plus, you could dynamically > add/delete selectors or conditions to an SA. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Dec 20 16:42:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBL0gq207107; Thu, 20 Dec 2001 16:42:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18859 Thu, 20 Dec 2001 19:03:15 -0500 (EST) Message-ID: <3C227DFD.76FF5A5F@certicom.com> Date: Thu, 20 Dec 2001 19:10:37 -0500 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "'IP Security List'" Subject: Re: IKEv2 traffic selector subsetting. References: <8607AF172D7DF05D85256B28007C5976.007C620D85256B28@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, I made a mistake with KE payloads in the second messages. What I meant was - Phase 1 exchange Initiator Responder ----------- ----------- HDR, SA, KE, Ni [,CERTREQ] --> <-- HDR, SA, KE, Nr [,CERTREQ] HDR*, ID, AUTH, [CERT,] SA, [KEi,] TSi, TSr [SA0, [KEi0,] TSi0, TSr0,] [SA1, [KEi1,] TSi1, TSr1, ...] --> <-- HDR*, ID, AUTH, [CERT,] SA, [KEr,] TSi, TSr [SA0, [KEr0,] TSi0, TSr0,] [SA1, [KEr1,] TSi1, TSr1, ...] which looks even scarier than the previous version, doesn't it :-) Thanks, Yuri Yuri Poeluev wrote: > > This mail is not exactly about traffic selector subsetting, but it's > related to traffic selectors very much, so I didn't want to start a > new thread. > > I've been thinking about Phase 1 and Phase 2 exchanges in IKEv2 and it > looks > that IKE negotiation might be simplified for traffic selectors and number > of > IKE messages to complete IKE negotiation between the initiator and > responder. > The IKE negotiation as it stands in IKEv2 document now is following - > > Phase 1 exchange > > Initiator Responder > ----------- ----------- > HDR, SA, KE, Ni [,CERTREQ] --> > <-- HDR, SA, KE, Nr [,CERTREQ] > > HDR*, ID, AUTH, [CERT,] > SA, TSi, TSr --> > <-- HDR*, ID, AUTH, [CERT,] > SA, TSi, TSr > > then > > The CREATE_CHILD_SA exchange (Phase 2): > > Initiator Responder > ----------- ----------- > HDR*, SA, Ni, [KEi,] > TSi, TSr --> > <-- HDR*, SA, Nr, [KEr,] > TSi, TSr > > I think instead of having two phases we might be able to achive the same > traffic selections by reducing the IKE negotiation to only one exchange - > > Phase 1 exchange > > Initiator Responder > ----------- ----------- > HDR, SA, KE, Ni [,CERTREQ] --> > <-- HDR, SA, KE, Nr [,CERTREQ] > > HDR*, ID, AUTH, [CERT,] > [KEi,] > SA, TSi, TSr > [SA0, TSi0, TSr0,] > [SA1, TSi1, TSr1, ...] --> > <-- HDR*, ID, AUTH, [CERT,] > [KEr,] > SA, TSi, TSr > [SA0, TSi0, TSr0,] > [SA1, TSi1, TSr1, ...] > > So, the intiator will propose all rules for traffic selectors. > The key derivation will not change. So, Phase 2 is not required > in this case. I know that the second messages are a bit overloaded, > but there is no duplication of traffic selectors in Phase 1 and Phase 2 > and number of messages (4) is minimal. Still, the initiator/responder can > use > CREATE_CHILD_SA exchange for rekeying. We can also add extra nonces in > the second messages if we want. > > I might have missed something here, but I thought it would be useful to > write down this idea. > > Other idea is to move initiator's [,CERTREQ] payload to initiator's second > message since responder's certificate is sent in responder's second > message. > For developers it would be easier to implement the latter, otherwise > the responder would have to keep a state between initiator's first > message and responder's second message. It's not a big deal, the developers > will adapt, but it would be nice to get rid of the [,CERTREQ] state for the > responder. > > Thanks, > Yuri Poeluev > > Andrew Krywaniuk wrote: > > > > > > ...If you > > > > wish to avoid sending traffic that will be filtered out by > > > the peer then > > > > that would be best accomplished by an IPSP protocol. > > > > > > I.e., "by some hypothetical protocol yet to be defined". > > > > > > It's better to solve the problem than to pretend that someone > > > somehow will > > > deliver a solution when required. IKE has demonstrated that simple > > > solutions are adequate for many purposes. Deliberately excluding this > > > from son-of-IKE may be ideologically preferable but makes no > > > sense as a > > > matter of practical engineering. > > > > Being idealistic is something that I am rarely accused of. My point is > that > > there is a difference between phase 2 traffic selectors (which represent > an > > IP->identity binding), and policy (which can be complex, ordered, and > > asymmetric). > > > > The IP->id binding is something that needs to be agreed upon, because it > > verifies that the peers agree on which protected subnets are behind which > > gateway (or which user is logged into the remote computer). The bindings > > are > > relatively static and they could be obtained from trusted sources like a > > configuration file or a DNS record. > > > > The policy rules, on the other hand, are basically a re-implementation of > > firewalling. They don't need to be negotiated; they simply need to be > > enforced at each end. The fact that we negotiated an SA from A to B > doesn't > > mean that I'm going to accept all UDP traffic to port 17 at 5:15 am on > > odd-numbered Tuesdays. The policy can change at any time and it need not > be > > shared with the peer ahead of time. > > > > The bindings need to be agreed upon, whereas the two policies are ukases > > (which should be merged independently at each side); this is the key > > distinction between them. In IKEv1, the responder couldn't change the > > traffic selectors so they had to be preshared (this is inappropriate for > > policy). In IKEv2, the responder can narrow the traffic selectors but > there > > are still potential issues (like what happens if the responder's narrow > > selectors don't include the packet that triggered the negotiation). > > > > The problem stems from the attempt to merge the bindings and the traffic > > selectors. The bindings are essential for security, whereas the policy is > > merely an optimization which allows you to avoid forwarding packets that > > the > > peer has informed you he intends to drop. > > > > Although I said that traffic filtering would be best accomplished by an > > IPSP > > protocol, I don't personally care whether that protocol is run as a > > separate > > negotiation stage or tacked onto IKE (although the complexity-Nazis may > > take > > issue with that). My main comment is that it would be better to have a > > separate policy payload rather than overloading to traffic selectors to > do > > two different things. > > > > I suppose if you wanted to, you could use a second set of traffic > selectors > > in the quick mode to express policy, but I don't think that's a very good > > idea. The traffic selectors in IKE don't do a very good job of expressing > > every useful policy. Having a policy payload allows you to use an SA for > > multiple non-adjacent traffic selectors. Plus, you could dynamically > > add/delete selectors or conditions to an SA. > > > > Andrew > > ------------------------------------------- > > There are no rules, only regulations. Luckily, > > history has shown that with time, hard work, > > and lots of love, anyone can be a technocrat. -- Yuri Poeluev VPN Development Manager Certicom Corp. 5520 Explorer Drive, 4th Floor Mississauga, ON Canada L4W 5L1 E-mail: ypoeluev@certicom.com Tel: (905) 501-3862 Web site: http://www.certicom.com Fax: (905) 507-4230 From owner-ipsec@lists.tislabs.com Thu Dec 20 19:57:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBL3v4212783; Thu, 20 Dec 2001 19:57:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21392 Thu, 20 Dec 2001 22:06:29 -0500 (EST) Date: Thu, 20 Dec 2001 20:07:39 -0700 From: Shane Amante To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability Message-ID: <20011220200739.F1426@nike.amante.org> Mail-Followup-To: Tero Kivinen , ipsec@lists.tislabs.com References: <15392.47983.271146.185793@pkoning.dev.equallogic.com> <15393.54557.737364.744047@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15393.54557.737364.744047@ryijy.hel.fi.ssh.com>; from kivinen@ssh.fi on Thu, Dec 20, 2001 at 02:10:05PM +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Aside from whatever method is ultimately decided upon for automagic detection of a remote peer's IKE version number, would it be too much to ask for a knob in IKEv2 implementations that allow operators/users to manually configure the remote peer as being IKEv1 or IKEv2? (Presumably, the default would be automagic detection and a user would manually configure a remote IKE version number if they knew what they were doing). Could this be added to the requirements for the next IKE successor? -shane On Thu, Dec 20, 2001 at 02:10:05PM +0200, Tero Kivinen wrote: > pkoning@equallogic.com (Paul Koning) writes: > > In order to deal with IKEv1 vs. IKEv2 "without undue delay" as I > > suggested should be the requirement, you need a timely way to > > recognize a V1-only implementation. If the "invalid version number" > > message were mandatory, this could be done (modulo the issue of lack > > of authentication). > > In some cases there is no way to know if the other end talks IKE at > all without timeouts. > > > It sounds like we're stuck with timeout as the mechanism for detecting > > V1-only implementations. Yuck. If that's right, then there is no > > reason to stick with the old port number. > > I don't think we are stuck with timeouts in common case. There are > implementations out there that WILL send the notification. This means > that if you start IKEv2 negotiation with them they will send > notification back and you can immediately fall back to IKEv1. If the > other end is one of those which does not send the notification then > you have to wait until the timeout expires, but I think more IKEv1 > implementations will start sending those notifications when IKEv2 > starts get used, even if they do not support any other > notifications, just to get rid of those timeouts. > > I.e if you notice that when I use vendor A products it immediately > notices IKEv2 is not understood and falls back to IKEv1 without > timeout, and for vendor B products you have to wait until timeout > expires I think most of the users will consider the vendor A product > better, thus vendor B will fix its code to send notifications. > > Also current installed base is mostly VPNs and there you can > preconfigure that the other end only supports IKEv1 to get rid of > timeout. For oppurtunistic encryption case etc where you don't know > anything about the other end you might want to put that kind of > information to the TXT record containing the public key itself... > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Thu Dec 20 22:01:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBL61I214714; Thu, 20 Dec 2001 22:01:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA21639 Fri, 21 Dec 2001 00:08:31 -0500 (EST) Date: Fri, 21 Dec 2001 00:17:47 -0500 (EST) From: Henry Spencer To: Shane Amante cc: ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <20011220200739.F1426@nike.amante.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 Dec 2001, Shane Amante wrote: > Aside from whatever method is ultimately decided upon for automagic > detection of a remote peer's IKE version number, would it be too much > to ask for a knob in IKEv2 implementations that allow operators/users > to manually configure the remote peer as being IKEv1 or IKEv2? Perhaps. This amounts to requiring that every IKE2 implementation also implement IKE1. Initially, that is probably a reasonable thing to do... but it may not remain so. IKE1 shouldn't be a mandatory part of IKE2. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Dec 21 00:18:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBL8IK227927; Fri, 21 Dec 2001 00:18:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21894 Fri, 21 Dec 2001 02:25:46 -0500 (EST) Date: Fri, 21 Dec 2001 00:27:01 -0700 From: Shane Amante To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Message-ID: <20011221002701.G1426@nike.amante.org> Mail-Followup-To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The following comments and suggestions relate to requirements offered in: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt. 7. Improve Simplicity [NOTE: this is kind of touched upon in Section 6 "Documenting Errors", but I think the following point needs to be called out in specific detail in Section 7.] There MUST be clear, concise definition of errors reported to end-users during or after a failed IKE negotiation. I recommend something along of the lines of SMTP or HTTP status codes be tailored specifically to the IKE state machine and its transactions. Furthermore, an end-user should NOT have to enable IKE debugging on a IPSec device in order to expose the specific reason (IKE status code) why an IKE negotiation failed. The goal here is to _consistently_ deliver clear, concise messages to the "common [wo]man" to make it easy to spot, relay and/or troubleshoot error messages. A.1 + A.2: "Policy". I think this really needs to be expanded upon, and clear requirements set forth. Although RFC2401 section 4.4.1 (SPD) refers to 3 choices wrt to "Policy", there really are four choices: - packet matches, encrypt - packet matches, bypass (don't encrypt) - packet doesn't match, drop - packet doesn't match, bypass (only in OUTBOUND case) The last case applies to either the telecommuter (site-to-site tunnel) or the mobile remote-access (RAS) client scenarios. In those cases, there are two choices for the site security administrator to make: 1) Allow the "client" to only be single-homed, thus ALL traffic needs to traverse the IPSec tunnel to the "hub" location. In the case of traffic legitimately destined for the Internet, this could add significant latency and might raise other security policy concerns. 2) Allow the "client" to be dual-homed. Encrypted traffic goes to the "hub"; Internet traffic bypasses the tunnel and goes immediately to the Internet. There are legitimate reasons for organizations to implement either #1 or #2. Thus, in order to retain flexibility IKE SHOULD have the ability to push/pull a policy to the client. (Ideally, this push/pull of a full policy could be avoided by exchanging a HASH of the whole SPD or a HASH for each rule that makes up the SPD -- obviously, only if it doesn't match does a transfer of the policy elements begin). Appendix A, General Comment: Another piece missing from each of the scenarios proposed is: IPSec's relationship with firewalls and/or midcom-devices. In particular, how is an IPSec gateway, at say a headquarters/hub location, deployed in relationship to a firewall (assuming the firewall and IPSec gateway are not co-located on the same physical device)? Three answers: a) On the public-side of the firewall, (e.g.: serially, sharing the same forwarding path); b) Beside the firewall, (e.g.: in parallel, creating separate forwarding paths as well as two, separate entry-points into the same 'internal' LAN); c) On the private-side of the firewall. Could either be serially, as in case (a), or off on a DMZ port of the firewall. All raise interesting security issues not only for protecting the IPSec gateway from the outside world, but also for protecting the internal LAN from traffic emerging from an IPSec tunnel. (Some may argue that the "SPD" on the IPSec gateway is good enough to protect the internal LAN, but I say to them: "no, it's not" if you believe in 'defense-in-depth'). To further complicate things, in case (c) what happens if the IPSec/IKE gateway is assigned an RFC1918 address on the internal LAN and the firewall is performing static NAT translation? Is this a supported configuration? Or, should it be the case that this is a gross hack and, therefore, will not be supported? Ideally, all this should be documented in a BCP, but consideration of firewalls needs to be accounted for now just as are NAT's. A.1 VPN Site-to-Site Tunnels "Operational Characteristics": I recommend updating the first sentence to the following: VPN Site-to-Site Tunnels may be between two, or more, devices ... ^^^^^^ ^^^^^^^ I agree that one tunnel will only exist between two SG's, but if you're talking about multiple tunnels you can create more complex toplogies. Finally, one last requirement: IKE/IPSec gateways SHOULD support "hot-standby" fail-over. No, this is NOT an end-user application problem, particularly if IPSec is to be considered a serious contender in the VPN space where SLAs are all about uptime. As an example of how serious uptime is to operators take a look at the Routing Area. Within the last year, IS-IS, OSPF + BGP all have proposals to keep the forwarding plane operational even if the control plane goes awry: http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-01.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-01.txt If hot-standby fail-over isn't considered as part of the first round of IKEv2, then at least consider what extensibility will be required to allow this in the future witout much pain. -shane From owner-ipsec@lists.tislabs.com Fri Dec 21 00:25:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBL8Pg229292; Fri, 21 Dec 2001 00:25:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21952 Fri, 21 Dec 2001 02:48:33 -0500 (EST) Date: Fri, 21 Dec 2001 00:49:51 -0700 From: Shane Amante To: Henry Spencer Cc: ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability Message-ID: <20011221004951.H1426@nike.amante.org> Mail-Followup-To: Henry Spencer , ipsec@lists.tislabs.com References: <20011220200739.F1426@nike.amante.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henry@spsystems.net on Fri, Dec 21, 2001 at 12:17:47AM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Dec 21, 2001 at 12:17:47AM -0500, Henry Spencer wrote: > On Thu, 20 Dec 2001, Shane Amante wrote: > > Aside from whatever method is ultimately decided upon for automagic > > detection of a remote peer's IKE version number, would it be too much > > to ask for a knob in IKEv2 implementations that allow operators/users > > to manually configure the remote peer as being IKEv1 or IKEv2? > > Perhaps. This amounts to requiring that every IKE2 implementation also > implement IKE1. Not necessarily, unless I'm overlooking something. Two solutions: 1) Only expose the knob, and let end-users configure it, on devices that have both IKE1 + IKE2 implementations. 2) Always expose the knob in all combinations of IKE implementations and let the end-user possibly shoot themself in the foot. (This is the point of a non-default, manual configuration. :-) As long as one of the two scenarios is agreed upon by the group and clearly documented shouldn't it be "caveat emptor"? > Initially, that is probably a reasonable thing to do... > but it may not remain so. IKE1 shouldn't be a mandatory part of IKE2. -shane From owner-ipsec@lists.tislabs.com Fri Dec 21 07:55:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLFto205907; Fri, 21 Dec 2001 07:55:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22977 Fri, 21 Dec 2001 09:53:54 -0500 (EST) Message-Id: <200112210052.fBL0qN3D973424@jurassic.eng.sun.com> Date: Thu, 20 Dec 2001 16:52:23 -0800 (PST) From: "Renee L. Danson" Reply-To: "Renee L. Danson" Subject: Connectathon 2002 reminder To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jyQw9Tb7BmV5xkpprTC5QQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_31 SunOS 5.9 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a reminder...if you're interested in attending Connectathon 2002 in February, the deadline for the discounted registration is December 31. Registration is still open until February 7, but the early bird rates will not be available after December 31. If you have any questions, please feel free to contact me! Renee Danson Connectathon 2002 IPsec Coordinator +++++ The Connectathon team is delighted to announce its 16th annual event will take place as scheduled. Connectathon 2002, an interoperability testing event for engineers only, will be held Feb. 28-Mar. 7, 2002 in San Jose, California. Sponsored by Sun Microsystems, Inc., Connectathon hosts over 50 companies from around the globe in an effort to test and debug source code. Currently, the following technologies and protocols are on the agenda: NFS versions 2, 3 and 4 NFS over RDMA WebNFS Lock Manager NIS/NIS+ Automounter Kerberos IPv6 IPsec Mobile IPv4 Mobile IPv6 Secure Shell NDMP Based on demand, in addition we are considering to offer: Service Location Protocol Diameter/AAA CIFS ATM If you are interested in testing any of the above 4 protocols, please send a note to Cthon@Sun.com and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 7, 2002. An Early Bird Discount on station fees is available to those who register and pay by December 31, 2001. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 16th annual Connectathon event! Audrey Van Belleghem Connectathon Manager From owner-ipsec@lists.tislabs.com Fri Dec 21 12:54:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLKsC224707; Fri, 21 Dec 2001 12:54:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23790 Fri, 21 Dec 2001 15:12:42 -0500 (EST) Message-Id: <200112212022.fBLKMdXt010454@thunk.east.sun.com> From: Bill Sommerfeld To: Shane Amante cc: ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: Your message of "Fri, 21 Dec 2001 00:17:47 EST." Reply-to: sommerfeld@east.sun.com Date: Fri, 21 Dec 2001 15:22:39 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Aside from whatever method is ultimately decided upon for automagic > detection of a remote peer's IKE version number, would it be too much > to ask for a knob in IKEv2 implementations that allow operators/users > to manually configure the remote peer as being IKEv1 or IKEv2? What this could comes down to is that your IPsec policy engine needs to include a knob to select amongst one of several different key management protocols (or an order in which to attempt them). I've been of the opinion for a while that the successor-to-ike (whether it be IKEv2, JFK, or something we haven't thought of) should run on a different port, for the simple reason that, on many platforms, this more easily allows implementors to start from a blank slate should they so desire, while permitting coexistance with IKEv1. On most of the systems I've worked with, it's generally significantly easier to allow a single application to listen on two ports, than to share a single port between two applications. - Bill From owner-ipsec@lists.tislabs.com Fri Dec 21 12:55:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLKtp224740; Fri, 21 Dec 2001 12:55:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23745 Fri, 21 Dec 2001 14:57:52 -0500 (EST) From: rks@cisco.com Date: Fri, 21 Dec 2001 12:07:16 -0800 (PST) To: "Shriver, John" cc: , Cheryl Madson , Bret Harrison , Narasimha , "'Leo Temoshenko'" Subject: Re: discussion of IPsec MIB requirements and goals, and my review of IPsec Flow Monitoring MIB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi - Thanks for outlining the goals of your MIB design and your very useful critique of the Flow MIB. The Flow MIB, which has been in design for a few years now, had two primary goals: G1) to provide manageability to the protocol arrived at by the IPsec WG (and not merely "MIBify" the protocol definition) G2) to provide abstractions to aid NMS applications involved in managing IPsec based networks. G3) to reduce the cost of polling the tables from the NMS While (G1) and (G3) were critical, (G2) was our overarching goal. The initial draft (defined by the IBM Nways group a few years ago) has been costantly revised based on the evolution of the protocol as well as updated use cases from the field. From: "Shriver, John" Date: Thu, 8 Nov 2001 14:10:10 -0800 Message-ID: >The claim that there are "major differences" doesn't ring >completely true to me. There are many key similarities, often >hidden by different terminology. The Flow MIB is fundamentally different from the IPsec Monitoring MIB. A MIB is essentially a model or an abstraction set forth using rules of SMI. The basic abstraction defined by the Flow MIB is a "tunnel" or a "traffic flow". A "tunnel" is the set of SAs created by successive QMs that share the same Phase 2 ID and hence go to sustain a specified traffic flow. This is illustrated in the figures accompanying Section 2. This abstraction is the central to the MIB; all counters and tables are centered around it. Practically, such the "flow" abstraction is essential to monitoring the state and performance of IPsec sessions. It is on flows that SLAs can be meaningfully defined and evaluated. To see a similarity between the SA-level MIB and the Flow MIB would be to miss this central idea. The superficial similarities you note arise because the two MIBs are, after all, instrumenting the same protocol. The counters defined by the Flow MIB correspond to an aggregated traffic flow while those defined by the IPsec Monitoring MIB are too level to be made use of by performance monitoring applications. Now, to your objections about the "structural" problems in the Flow MIB: 1. Phase 2 proxy ID types restricted in EndPt table =================================================== One of our design goals was to minimize the SNMP traffic required to complete a query. Hence, we chose not to normalize tables even where it would have seemed theoretically elegant. The restriction on the identity types in the End Point table is a consequence of of this goal as well the feeling that only address based identities make sense in this context. >The addition of a new identity type breaks it. It is to be expected that a MIB that instruments a protocol must be revised with any significant revision to the protocol. Addition of a new Phase 2 identity type is a significant revision to the protocol and in practice, a rare occurrence. The only way to avoid such revisions would be make the MIB a look up table of raw values: a MIB as a lookup table is not very appealing and seems to add very little value. Another disadvantage of the IPsec Monitoring MIB (and similarly the IKE MIB) is that the amount of polling required to complete a query would be high, due to the number of cross-table correlations. More on this later. The points (2), (3) and (4) are quite valid and my responses below. 2. ikePeerLocalValue size cannot accomodate arbitrarily large values ================================================================= >The Flow Monitoring MIB ikePeerTable runs into a structural problem. >It can't be validly implemented. The reason is that when >ikePeerLocalType and/or ikePeerRemoteType is id_dn, ikePeerLocalValue >and/or ikePeerRemoteValue may very readily be so long that the >Object Identifier will exceed the maximum number of sub-identifiers >(230 if I remember). It is true that a very large Phase I identity string cannot be accomodated in the ikePeerTable. A large identity string will be truncated: but this causes no ambiguity in indexes due to the disambiguating internal index in the table. However, in practice how often is likely to see such large identity strings? >This is why our IKE MIB has the ikeEndpointTable. This is a table of >endpoints, indexed by an arbitrary indexes (violating our own no-search >rules), containing the endpoint data. Then we can use this arbitrary >index to index other tables that need to be indexed by endpoint. This solution may fit the bill in theory; in practice, as I said earlier, traversal of your tables will lead to costly SNMP polls. 3. No way to pinpoint a peer address other than by searching ================================================================== >there's no way short of table search to find an IKE Phase 1 SA >by the IP addresses. We have that in index of the saTable in >the ISAKMP MIB, and it's sparsely-augmented partner ikeSaTable >in the IKE MIB. This is a valid point; but we felt that keying based on Phase I IDs would compensate for this. 4. IKE has been made mandatory keying protocol ============================================== This probelm arises merely because IKE groups have been made mandatory in the module compliance. This needs to be fixed and defining a brand new MIB is I think an overkill. 5. No way to identify new or negotiated DH grps =============================================== >The variable ikeTunDiffHellmanGrp does not allow for private groups or >as-yet-undefined groups), yet IKE does. Unless IKE Version 2 plans to >delete this, I think my saOakleyGroupDesc/saOakleyGroup variables meet >the goal of supporting what the spec allows. It also avoids obsolescence >problems. Remember that the supporting modpGroupTable, ecpGroupTable and >ec2nGroupTable are only required if you actually choose to support >negotiating new groups. The MIB was not designed to reveal every nut and bolt of the SAs. I am not sure if the WG expects a MIB that faithfully models every bit of the protocol. Identitifying that a new group has been negotiated for a specific SA is useful (using a new textual convention element "private"). You consider the following elements either obsolete or extraneous to this MIB definition. 6. XAUTH and mode-config should be separated out 7. IPsec over UDP should not be a part of this MIB Deleting obsoleted elements is trivial, if the corresponding drafts are indeed dead. With regards to layering: traversing normalized tables can cause a lot of SNMP traffic. With goal (G3) in mind, we have included metrics closely related to IKE/IPsec tunnels in this MIB even if it appeared that they could be layered out. In addition you have listed a number of cosmetic problems such as those pertaining to the type of TrapStatus, making descriptions more rigorous and documentation of encoding types if certain ID types. I will take these up in a separate mail. >I think by the time one changes the indices on the tables that have >"structural problems", and allow more extensibility, the tables start to >look a lot like the ones Tim and I have been working on for a few years. >I think if we prune some things, maybe merge ISAKMP/IKE, and decide if >we want an IPsec proper MIB, we can merge the excellent counters with >the basic table strategy that has been evolving over two years. This statement is entirely incorrect: the approach of the two MIBs is entirely different. You have attempted to faithfully reflect every aspect of the WG's output in the protocol and hence you instrument the protocol at the SA level. For this reason alone, your MIBs provide a low level view of the managed network. The second concern I have about your draft is that in monitoring large networks, traversing tables in your MIBs will result in quite a lot of SNMP polling. The Flow MIB, on the other hand, was designed considering numerous use-cases from the field. It defines an important abstraction, defines counters and tables around this view and provides limited archives to capture trends of traffic and failures. Its time to merge the best aspects of the two MIBs. That will be my next step. Thanks for your thorough review. --- S Ramakrishnan, Cisco SYstems Inc., San Jose, Ca From owner-ipsec@lists.tislabs.com Fri Dec 21 13:55:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLLtS228362; Fri, 21 Dec 2001 13:55:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23898 Fri, 21 Dec 2001 16:12:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <200112212022.fBLKMdXt010454@thunk.east.sun.com> From: "Bill Sommerfeld" To: "Shane Amante" Cc: Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: Your message of "Fri, 21 Dec 2001 00:17:47 EST." Reply-To: Date: Fri, 21 Dec 2001 15:22:39 -0500 X-OriginalArrivalTime: 21 Dec 2001 21:22:33.0625 (UTC) FILETIME=[9AC89090:01C18A65] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Aside from whatever method is ultimately decided upon for automagic > detection of a remote peer's IKE version number, would it be too much > to ask for a knob in IKEv2 implementations that allow operators/users > to manually configure the remote peer as being IKEv1 or IKEv2? What this could comes down to is that your IPsec policy engine needs to include a knob to select amongst one of several different key management protocols (or an order in which to attempt them). I've been of the opinion for a while that the successor-to-ike (whether it be IKEv2, JFK, or something we haven't thought of) should run on a different port, for the simple reason that, on many platforms, this more easily allows implementors to start from a blank slate should they so desire, while permitting coexistance with IKEv1. On most of the systems I've worked with, it's generally significantly easier to allow a single application to listen on two ports, than to share a single port between two applications. - Bill From owner-ipsec@lists.tislabs.com Fri Dec 21 14:43:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLMhJ229796; Fri, 21 Dec 2001 14:43:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24012 Fri, 21 Dec 2001 17:05:34 -0500 (EST) Date: Fri, 21 Dec 2001 14:15:02 -0800 (PST) From: Jan Vilhuber To: Shane Amante cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt In-Reply-To: <20011221002701.G1426@nike.amante.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 21 Dec 2001, Shane Amante wrote: > The following comments and suggestions relate to requirements offered > in: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt. > > > 7. Improve Simplicity > > [NOTE: this is kind of touched upon in Section 6 "Documenting Errors", > but I think the following point needs to be called out in specific > detail in Section 7.] > > There MUST be clear, concise definition of errors reported to > end-users during or after a failed IKE negotiation. I recommend > something along of the lines of SMTP or HTTP status codes be tailored > specifically to the IKE state machine and its transactions. > > Furthermore, an end-user should NOT have to enable IKE debugging on a > IPSec device in order to expose the specific reason (IKE status code) > why an IKE negotiation failed. > > The goal here is to _consistently_ deliver clear, concise messages to > the "common [wo]man" to make it easy to spot, relay and/or > troubleshoot error messages. > Surely you don't think that belongs on a protocol spec. However you choose to implement this is up to you. I certainly don't object to clarifying error codes, but a protocol spec doesn't need to spell out how these should be displayed to the user. jan > > A.1 + A.2: > > "Policy". I think this really needs to be expanded upon, and clear > requirements set forth. Although RFC2401 section 4.4.1 (SPD) refers > to 3 choices wrt to "Policy", there really are four choices: > - packet matches, encrypt > - packet matches, bypass (don't encrypt) > - packet doesn't match, drop > - packet doesn't match, bypass (only in OUTBOUND case) > > The last case applies to either the telecommuter (site-to-site tunnel) > or the mobile remote-access (RAS) client scenarios. In those cases, there > are two choices for the site security administrator to make: > 1) Allow the "client" to only be single-homed, thus ALL traffic needs > to traverse the IPSec tunnel to the "hub" location. In the case > of traffic legitimately destined for the Internet, this could add > significant latency and might raise other security policy concerns. > 2) Allow the "client" to be dual-homed. Encrypted traffic goes to the > "hub"; Internet traffic bypasses the tunnel and goes immediately > to the Internet. > > There are legitimate reasons for organizations to implement either #1 > or #2. Thus, in order to retain flexibility IKE SHOULD have the > ability to push/pull a policy to the client. (Ideally, this push/pull > of a full policy could be avoided by exchanging a HASH of the whole > SPD or a HASH for each rule that makes up the SPD -- obviously, only > if it doesn't match does a transfer of the policy elements begin). > > > > Appendix A, General Comment: > > Another piece missing from each of the scenarios proposed is: IPSec's > relationship with firewalls and/or midcom-devices. > > In particular, how is an IPSec gateway, at say a headquarters/hub > location, deployed in relationship to a firewall (assuming the > firewall and IPSec gateway are not co-located on the same physical > device)? Three answers: > > a) On the public-side of the firewall, (e.g.: serially, sharing the > same forwarding path); > b) Beside the firewall, (e.g.: in parallel, creating separate > forwarding paths as well as two, separate entry-points into the > same 'internal' LAN); > c) On the private-side of the firewall. Could either be serially, as > in case (a), or off on a DMZ port of the firewall. > > All raise interesting security issues not only for protecting the > IPSec gateway from the outside world, but also for protecting the > internal LAN from traffic emerging from an IPSec tunnel. (Some may > argue that the "SPD" on the IPSec gateway is good enough to protect > the internal LAN, but I say to them: "no, it's not" if you believe in > 'defense-in-depth'). > > To further complicate things, in case (c) what happens if the > IPSec/IKE gateway is assigned an RFC1918 address on the internal LAN > and the firewall is performing static NAT translation? Is this a > supported configuration? Or, should it be the case that this is a > gross hack and, therefore, will not be supported? > > Ideally, all this should be documented in a BCP, but consideration of > firewalls needs to be accounted for now just as are NAT's. > > > > A.1 VPN Site-to-Site Tunnels > > "Operational Characteristics": I recommend updating the first sentence > to the following: > VPN Site-to-Site Tunnels may be between two, or more, devices ... > ^^^^^^ ^^^^^^^ > I agree that one tunnel will only exist between two SG's, but if > you're talking about multiple tunnels you can create more complex > toplogies. > > > > Finally, one last requirement: > > IKE/IPSec gateways SHOULD support "hot-standby" fail-over. No, this > is NOT an end-user application problem, particularly if IPSec is to be > considered a serious contender in the VPN space where SLAs are all > about uptime. > > As an example of how serious uptime is to operators take a look at the > Routing Area. Within the last year, IS-IS, OSPF + BGP all have > proposals to keep the forwarding plane operational even if the control > plane goes awry: > http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-01.txt > > If hot-standby fail-over isn't considered as part of the first round > of IKEv2, then at least consider what extensibility will be required > to allow this in the future witout much pain. > > -shane > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 21 14:48:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBLMmG229881; Fri, 21 Dec 2001 14:48:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24020 Fri, 21 Dec 2001 17:07:11 -0500 (EST) Date: Fri, 21 Dec 2001 14:16:41 -0800 (PST) From: Jan Vilhuber To: Shane Amante cc: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: IKE v2 Requirements and backwards compatability In-Reply-To: <20011220200739.F1426@nike.amante.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 Dec 2001, Shane Amante wrote: > Aside from whatever method is ultimately decided upon for automagic > detection of a remote peer's IKE version number, would it be too much > to ask for a knob in IKEv2 implementations that allow operators/users > to manually configure the remote peer as being IKEv1 or IKEv2? > > (Presumably, the default would be automagic detection and a user would > manually configure a remote IKE version number if they knew what they > were doing). > > Could this be added to the requirements for the next IKE successor? > Again, this is not something that belongs in a protocol spec. That's an implementation detail. Good programmers will probably do something like the above, but let's not clutter a protocol spec with implementation details (unless they are internal error handling hints, but please no UI stuff). jan > -shane > > > > On Thu, Dec 20, 2001 at 02:10:05PM +0200, Tero Kivinen wrote: > > pkoning@equallogic.com (Paul Koning) writes: > > > In order to deal with IKEv1 vs. IKEv2 "without undue delay" as I > > > suggested should be the requirement, you need a timely way to > > > recognize a V1-only implementation. If the "invalid version number" > > > message were mandatory, this could be done (modulo the issue of lack > > > of authentication). > > > > In some cases there is no way to know if the other end talks IKE at > > all without timeouts. > > > > > It sounds like we're stuck with timeout as the mechanism for detecting > > > V1-only implementations. Yuck. If that's right, then there is no > > > reason to stick with the old port number. > > > > I don't think we are stuck with timeouts in common case. There are > > implementations out there that WILL send the notification. This means > > that if you start IKEv2 negotiation with them they will send > > notification back and you can immediately fall back to IKEv1. If the > > other end is one of those which does not send the notification then > > you have to wait until the timeout expires, but I think more IKEv1 > > implementations will start sending those notifications when IKEv2 > > starts get used, even if they do not support any other > > notifications, just to get rid of those timeouts. > > > > I.e if you notice that when I use vendor A products it immediately > > notices IKEv2 is not understood and falls back to IKEv1 without > > timeout, and for vendor B products you have to wait until timeout > > expires I think most of the users will consider the vendor A product > > better, thus vendor B will fix its code to send notifications. > > > > Also current installed base is mostly VPNs and there you can > > preconfigure that the other end only supports IKEv1 to get rid of > > timeout. For oppurtunistic encryption case etc where you don't know > > anything about the other end you might want to put that kind of > > information to the TXT record containing the public key itself... > > -- > > kivinen@ssh.fi > > SSH Communications Security http://www.ssh.fi/ > > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 21 16:07:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBM07W205069; Fri, 21 Dec 2001 16:07:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24197 Fri, 21 Dec 2001 18:30:10 -0500 (EST) From: "sankar ramamoorthi" To: "Jan Vilhuber" , "Shane Amante" Cc: Subject: RE: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Date: Fri, 21 Dec 2001 15:43:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > Sent: Friday, December 21, 2001 2:15 PM > To: Shane Amante > Cc: ipsec@lists.tislabs.com > Subject: Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt > > > > On Fri, 21 Dec 2001, Shane Amante wrote: > > > The following comments and suggestions relate to requirements offered > > in: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt. > > > > > > 7. Improve Simplicity > > > > [NOTE: this is kind of touched upon in Section 6 "Documenting Errors", > > but I think the following point needs to be called out in specific > > detail in Section 7.] > > > > There MUST be clear, concise definition of errors reported to > > end-users during or after a failed IKE negotiation. I recommend > > something along of the lines of SMTP or HTTP status codes be tailored > > specifically to the IKE state machine and its transactions. > > > > Furthermore, an end-user should NOT have to enable IKE debugging on a > > IPSec device in order to expose the specific reason (IKE status code) > > why an IKE negotiation failed. > > > > The goal here is to _consistently_ deliver clear, concise messages to > > the "common [wo]man" to make it easy to spot, relay and/or > > troubleshoot error messages. > > > > Surely you don't think that belongs on a protocol spec. However you > choose to implement this is up to you. > > I certainly don't object to clarifying error codes, but a protocol > spec doesn't need to spell out how these should be displayed to the > user. > > jan > You are right in that a protocol spec need not spell out how the error message should be displayed to the user, but it could define a message format that enables better trouble-shooting. For example the notification message can be format 'error code + error string', where the string allows the sender to add more error detail. For example today a notification such as 'no proposal chosen' does not exactly convey why the proposal was rejected. An error string could furthur identify the problem such as group or lifetime attribute is not acceptable.. -- sankar -- From owner-ipsec@lists.tislabs.com Sat Dec 22 23:01:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBN718206651; Sat, 22 Dec 2001 23:01:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA27169 Sun, 23 Dec 2001 00:51:49 -0500 (EST) Date: Sat, 22 Dec 2001 22:51:22 -0700 From: Shane Amante To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Message-ID: <20011222225122.A963@nike.amante.org> Mail-Followup-To: Jan Vilhuber , ipsec@lists.tislabs.com References: <20011221002701.G1426@nike.amante.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vilhuber@cisco.com on Fri, Dec 21, 2001 at 02:15:02PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, I am suggesting that, in whatever protocol is chosen as the successor to IKEv1, it needs to have granular status and error codes -- the more granular the better. Along those lines, I also recommended that, if possible, error and status codes in the spec be classified hierarchically to make diagnosing, and fixing, errors as easy as possible. Moreso than many protocols the IETF works on, IKEv1 and its successor are *highly* visible to end-users, in particular non-technical telecommuters and road-warriors. Granted, non-technical end-users may not be directly responsible for troubleshooting problems with the protocol, but for them to be able to relay specific information to more technical security admins is absolutely necessary, particularly if IKE's successor is to be wildly successful. -shane On Fri, Dec 21, 2001 at 02:15:02PM -0800, Jan Vilhuber wrote: > On Fri, 21 Dec 2001, Shane Amante wrote: > > The following comments and suggestions relate to requirements offered > > in: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt. [ snip ] > > 7. Improve Simplicity [ snip ] > > There MUST be clear, concise definition of errors reported to > > end-users during or after a failed IKE negotiation. I recommend > > something along of the lines of SMTP or HTTP status codes be tailored > > specifically to the IKE state machine and its transactions. [ snip ] > > Surely you don't think that belongs on a protocol spec. However you > choose to implement this is up to you. > > I certainly don't object to clarifying error codes, but a protocol > spec doesn't need to spell out how these should be displayed to the > user. > > jan From owner-ipsec@lists.tislabs.com Sun Dec 23 09:23:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBNHN0229656; Sun, 23 Dec 2001 09:23:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28129 Sun, 23 Dec 2001 11:26:13 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20011222225122.A963@nike.amante.org> References: <20011221002701.G1426@nike.amante.org> <20011222225122.A963@nike.amante.org> Date: Sun, 23 Dec 2001 11:17:34 -0500 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:51 PM -0700 12/22/01, Shane Amante wrote: >I am suggesting that, in whatever protocol is chosen as the successor >to IKEv1, it needs to have granular status and error codes -- the more >granular the better. Note that JFK has taken the opposite approach: almost no "error messages", and those that it has are concise and let the other side know exactly what the other side should do to get around the error. This is an important consideration for the eventual successor protocol. IKEv1 has many under-defined error messages. In many cases, it is not at all clear what the side receiving an error message should do with the error. The -00 draft of IKEv2 has given more definition to some of the error messages, but there are still lots of messages that are of no value other than to log them in the debugging interface. The -00 draft of JFK has no error messages, but simply has two responses that are used to say "you should try again, and here are some reasonable values to try with if you feel like it". Either of the two protocols could be changed to use different type of error reporting, depending on what the WG wants. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun Dec 23 21:50:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBO5o7226298; Sun, 23 Dec 2001 21:50:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA29226 Sun, 23 Dec 2001 23:54:40 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Henry Spencer'" , "'Andrew Krywaniuk'" Cc: Subject: RE: IKEv2 traffic selector subsetting. Date: Sun, 23 Dec 2001 23:56:32 -0500 Message-ID: <005601c18c37$fc76ab50$692db440@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > It seems to me that 2401 is trying to skirt the issue by > integrating the > > functionality of a very basic firewall into IPsec (thus > *causing* the SADB > > and firewall to be on the same machine). > Exactly! This is never advertised as such in the IPsec > documents for some > unfathomable reason -- much confusion would be saved if it > were made more > explicit -- but they basically include a specification for an > Internet-standard minimum firewall mechanism. Which brings us right back to the original point of the thread. Traditional firewalls enforce a policy without advertising it. IPsec SPD firewalls add this extra 'selector negotiation' feature. However, the IPsec selectors are not adequate to express the entire spectrum of what a fully featured firewall can use. I prefer the model in which each side merely enforces its own policy. If you desire the capability to detect and avoid black holes (a feature not found in traditional firewalls), then it would be preferable for both peers to issue ukases describing what types of traffic they are willing to accept. This avoids the aforementioned problem where the responder chooses selectors that don't match the triggering packet, and it makes it easy to add or delete policies without renegotiating the SA. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Thursday, December 20, 2001 12:16 PM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: RE: IKEv2 traffic selector subsetting. > > > On Wed, 19 Dec 2001, Andrew Krywaniuk wrote: > > It seems to me that 2401 is trying to skirt the issue by > integrating the > > functionality of a very basic firewall into IPsec (thus > *causing* the SADB > > and firewall to be on the same machine). > > Exactly! This is never advertised as such in the IPsec > documents for some > unfathomable reason -- much confusion would be saved if it > were made more > explicit -- but they basically include a specification for an > Internet-standard minimum firewall mechanism. > > Firewalls are, very obviously when you think about it, a > vital part of IP > security. And that's what "IPsec" stands for; it's not just > encryption. > > > But it is an incomplete solution > > because you may still need an external firewall. > > Why? Note that the IPsec specs set a minimum requirement > only; they don't > prohibit adding any further functionality you may need. > > > I just prefer a different > > solution, in which IPsec cooperates with (or merges with) > the firewall > > rather than duplicating one part of its functionality. > > Why do you assume that this is a different solution? > > > Henry Spencer > > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Mon Dec 24 10:34:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBOIYO227419; Mon, 24 Dec 2001 10:34:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00274 Mon, 24 Dec 2001 12:25:59 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <005601c18c37$fc76ab50$692db440@andrewk3.ca.newbridge.com> References: <005601c18c37$fc76ab50$692db440@andrewk3.ca.newbridge.com> Date: Mon, 24 Dec 2001 12:29:22 -0500 To: From: Stephen Kent Subject: RE: IKEv2 traffic selector subsetting. Cc: "'Henry Spencer'" , "'Andrew Krywaniuk'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:56 PM -0500 12/23/01, Andrew Krywaniuk wrote: > > > It seems to me that 2401 is trying to skirt the issue by >> integrating the >> > functionality of a very basic firewall into IPsec (thus >> *causing* the SADB >> > and firewall to be on the same machine). > >> Exactly! This is never advertised as such in the IPsec >> documents for some >> unfathomable reason -- much confusion would be saved if it >> were made more >> explicit -- but they basically include a specification for an >> Internet-standard minimum firewall mechanism. > > >Which brings us right back to the original point of the thread. Traditional >firewalls enforce a policy without advertising it. IPsec SPD firewalls add >this extra 'selector negotiation' feature. However, the IPsec selectors are >not adequate to express the entire spectrum of what a fully featured >firewall can use. I prefer the model in which each side merely enforces its >own policy. > >If you desire the capability to detect and avoid black holes (a feature not >found in traditional firewalls), then it would be preferable for both peers >to issue ukases describing what types of traffic they are willing to accept. >This avoids the aforementioned problem where the responder chooses selectors >that don't match the triggering packet, and it makes it easy to add or >delete policies without renegotiating the SA. There are a few ways in which what we do in IPsec differs from the functionality of a basic firewall: - first, we have the option to use crypto-authenticated symbolic identities (e.g., DNS names, RFC822 addresses, DNs, etc.), not just NOT addresses, and to have these identities mapped to IP source/destination addresses when an SA is estyablished. This can be done irrespective of the availability of DNS security, although it would be even better with DNSSEC. this more powerful feature makes use of an SA management protocol, e.g. IKE or its successors. - we have the ability to map different traffic streams to different crypto protection suites, or to the same suite but with different SAs. I don't think one can achieve the same effect with a separate firewall capability. also, SPD mismatches here could be very confusing and hard to detect and resolve. - if one did try to make the firewall capability very separate, the there would be a new management problem, i.e., ensuring synch between the SPD and the firewall database, which could be especially difficult when symbolic SPD entries are used. - fundamentally, when an initiator creates an SA to a responder, if the initiator fail to advertise what traffic will be sent over the SA, and what traffic would be accepted via the SA, the responder is at a disadvantage in terms of processing the inbound traffic, and the responder may have a harder task of mapping outbound traffic to the SA. (This is because the responder does not know what range of traffic the initiator expected would be mapped to the SA. This can occur when two sites have SPDs that allow different classes of traffic to be exchanged between them, but may want different SAs for the different classes of traffic.) Much of our recent discussion on this list has focused on how to improve the manageability of IPsec, to facilitate more widespread adoption. This underlies the debate about pre-shared keys, for example. I think the goal of quickly detecting mismatches in SPD configuration and providing feedback that allows site security administrators to resolve such mismatches, is consistent with the goal of trying to make IPsec easier to use, and thus we should retain the negotiation of SA traffic selectors as part of any IKE replacement. Steve From owner-ipsec@lists.tislabs.com Mon Dec 24 12:21:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBOKL1200627; Mon, 24 Dec 2001 12:21:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00518 Mon, 24 Dec 2001 14:42:19 -0500 (EST) Date: Mon, 24 Dec 2001 14:51:51 -0500 (EST) From: Henry Spencer To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: IKEv2 traffic selector subsetting. In-Reply-To: <005601c18c37$fc76ab50$692db440@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 23 Dec 2001, Andrew Krywaniuk wrote: > > [the IPsec specs] basically include a specification for an > > Internet-standard minimum firewall mechanism. > > Which brings us right back to the original point of the thread. Traditional > firewalls enforce a policy without advertising it. Indeed so. And based on our experience with FreeS/WAN, this is *easily* the biggest single source of confusion for people trying to get IPsec working: their IKE or ESP packets don't get through, they don't know why, and there's no easy way to troubleshoot it, because it's a firewall configuration problem. We should be trying to reduce the number of places where such unannounced non-negotiable policy can block packets, not adding yet another. > IPsec SPD firewalls add > this extra 'selector negotiation' feature. However, the IPsec selectors are > not adequate to express the entire spectrum of what a fully featured > firewall can use. Indeed they don't, but they provide a highly useful subset. > I prefer the model in which each side merely enforces its > own policy. How is that policy arrived at? By manual configuration? That's fine for a VPN environment, where all tunnels are essentially preconfigured, but not all IPsec applications are VPNs. And even when manual configuration is practical, it's grossly error-prone. > If you desire the capability to detect and avoid black holes (a feature not > found in traditional firewalls), then it would be preferable for both peers > to issue ukases describing what types of traffic they are willing to accept. I'm having trouble envisioning how this would work, especially in a non-VPN environment where the policies are quite generic and what's permissible on a specific tunnel has to be inferred. It sounds complicated, and I don't see the benefit. It seems far simpler for one side to say what it wants and have the other side say "yes" or "no". > This avoids the aforementioned problem where the responder chooses selectors > that don't match the triggering packet... If the responder says "yes" to the initiator's request, then it should set up selectors which match the initiator's request! Anything else is a bug. If the responder cannot comply *fully* with the request, its answer should be "no". > ...and it makes it easy to add or > delete policies without renegotiating the SA. And thus easy to break the tunnel without notifying the other end, which is exactly what some of us want to avoid. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Dec 24 15:47:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBONlq208237; Mon, 24 Dec 2001 15:47:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00795 Mon, 24 Dec 2001 17:48:54 -0500 (EST) Date: Tue, 25 Dec 2001 00:58:16 +0200 Message-Id: <200112242258.AAA18651@burp.tkv.asdf.org> From: Markku Savela To: henry@spsystems.net CC: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com In-reply-to: (message from Henry Spencer on Mon, 24 Dec 2001 14:51:51 -0500 (EST)) Subject: Re: IKEv2 traffic selector subsetting. References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Henry Spencer > If the responder says "yes" to the initiator's request, then it should set > up selectors which match the initiator's request! Anything else is a bug. > If the responder cannot comply *fully* with the request, its answer should > be "no". Hmm.. then, any sensible responder will have to say "NO" to any other selectors, except at most the one that specifies exactly one pair of hosts (initiator - responder). As a responder, I wouldn't want a random initiator to dictate my security requirements for any other host. (If I did that, someone could just declare itself as a security gateway for 192/8 (any any random range of addreses) and get all my traffict routed to itself...) I must be missing something? What? From owner-ipsec@lists.tislabs.com Mon Dec 24 15:52:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBONq2208654; Mon, 24 Dec 2001 15:52:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00828 Mon, 24 Dec 2001 18:16:18 -0500 (EST) Date: Mon, 24 Dec 2001 18:25:49 -0500 (EST) From: Henry Spencer To: Markku Savela cc: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 traffic selector subsetting. In-Reply-To: <200112242258.AAA18651@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Dec 2001, Markku Savela wrote: > > If the responder says "yes" to the initiator's request, then it should set > > up selectors which match the initiator's request! Anything else is a bug. > > If the responder cannot comply *fully* with the request, its answer should > > be "no". > > Hmm.. then, any sensible responder will have to say "NO" to any other > selectors, except at most the one that specifies exactly one pair of > hosts (initiator - responder). I don't see how this follows. Certainly the responder will have to know which hosts it can act on behalf of, and which hosts a particular initiator can plausibly act on behalf of, and limit itself to tunnels which fit those constraints. But those sets don't have to include only the responder and initiator themselves. > As a responder, I wouldn't want a random initiator to dictate my > security requirements for any other host. (If I did that, someone > could just declare itself as a security gateway for 192/8 (any any > random range of addreses) and get all my traffict routed to itself...) Indeed so. But that just says that the responder has to have either some knowledge of which hosts are behind which initiators, or some way to ask for validation of a particular initiator request. There is nothing conceptually difficult about this. Moreover, I don't see how you avoid such a requirement in any case. How do you know which traffic you can safely route into a particular tunnel without knowing which hosts are *legitimately* on the other end? This would seem to be a fundamental necessity regardless. It is outside the scope of IPsec only if you decide that the routing is somebody else's problem -- that is, if a crucial part of IP security is not IPsec's business. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Dec 27 06:31:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBREVb221392; Thu, 27 Dec 2001 06:31:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05756 Thu, 27 Dec 2001 08:32:36 -0500 (EST) Message-Id: <200112271342.fBRDg5c00804@fatty.lounge.org> To: sommerfeld@east.sun.com Cc: "Sara Bitan" , "Radia Perlman - Boston Center for Networking" , ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-Reply-To: Your message of "Mon, 17 Dec 2001 16:50:07 EST." <200112172150.fBHLo7Xt026599@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <801.1009460525.1@tibernian.com> Date: Thu, 27 Dec 2001 05:42:05 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shouldn't this be done in some application layer security protocol then? Dan. On Mon, 17 Dec 2001 16:50:07 EST you wrote > > Does each one of the services/ the hosts behind the firewall have a distinc >t > > private/public key pair? > > potentially, yes. > > - Bill > From owner-ipsec@lists.tislabs.com Thu Dec 27 06:50:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBREoU223494; Thu, 27 Dec 2001 06:50:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05793 Thu, 27 Dec 2001 09:09:39 -0500 (EST) Message-Id: <200112271419.fBREJMc00995@fatty.lounge.org> To: "Angelos D. Keromytis" Cc: "William Dixon" , "Radia Perlman - Boston Center for Networking" , ipsec@lists.tislabs.com Subject: Re: Should Alice say who she wants to talk to? In-Reply-To: Your message of "Thu, 20 Dec 2001 00:46:48 EST." <200112200546.fBK5kmq5026608@nyarlathotep.keromytis.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <992.1009462762.1@tibernian.com> Date: Thu, 27 Dec 2001 06:19:22 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Aren't we all still prohibited from "changing IKE"? I have a draft I'd like to rename in the draft-ietf-ipsec-* workspace :-) Dan. On Thu, 20 Dec 2001 00:46:48 EST you wrote > > So, I guess we should rename the draft in the draft-ietf-ipsec-* > workspace, fill in the few blanks (explicitly show where the suggested > ID is included in the HASH) and be done with this ? > > One question I have: how would current implementations handle receiving an > IKEv1 message 3 which had an extra payload ? Would they ignore it, or loudly > complain and refuse to proceed ? The draft says that the Responder may ignore > the suggested ID (so the Initiator cannot depend on the suggested value being > returned), which is great if implementations ignore extra payloads. > > (I'm trying to avoid having to bump the minor version number.) > -Angelos > From owner-ipsec@lists.tislabs.com Thu Dec 27 23:28:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBS7Sb208226; Thu, 27 Dec 2001 23:28:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06882 Fri, 28 Dec 2001 01:19:41 -0500 (EST) Date: Thu, 27 Dec 2001 23:20:31 -0700 From: Shane Amante To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ikev2-00.txt Message-ID: <20011227232031.A934@nike.amante.org> Mail-Followup-To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As for some general comments: - I'm impressed with the overall integration of RFCs 2407-2409 into a single document -- it provides for a compact, single-source specification of IKE. - Would it be possible in just one section of the draft to coalesce all timers listed throughout the draft (e.g.: SA Lifetime, timeout interval, retransmission interval, proactive rekeying time, aliveness checks, etc.), their intended use, their relationship with other timers, whether they should/must count upward/downward, etc.? - As a follow-up to the previous suggestion, why aren't intervals for timers at least recommended as SHOULDs in the spec? Surely, there are some timers (e.g.: timeout and retransmission interval) where it would be useful to have a common standard among multiple, different implementations for "typical" deployment scenario(s). Is this supposed to be left for Informational RFCs or as torture to developers/end-users to figure out on their own? :-) As for specific comments on the draft itself, here goes: 1.2 Changes from IKEv1 I like this section describing the design goals of IKEv2. However, it might also be useful to describe a few of the major similarities IKEv2 has to IKEv1, (e.g.: preserving payload type/formats, error codes, etc.) 2.1 Use of Retransmission Timers Just an idea here, is it advisable/recommended that IKE gateways store RTT values for IKE request/responses, and then potentially use a multipler of RTT as the Retransmission Interval? 2.2. Use of Sequence Numbers for Message ID Does it matter if the Message ID integer ALWAYS starts at zero and increments upward by 1 after each successful transaction? What I'm curious about is replay attacks or guessing a predictable sequence number, as in TCP ISNs, and spoofing messages. If this is a concern, should/must Message ID be randomized for its ISN and then increment by 1 after each successful transaction? In either case, could this be documented? 2.4 State Synchronization and Connection Timeouts ... An IKE endpoint SHOULD send a Delete payload indicating that it has closed the IKE-SA. Why not a MUST here as well? This avoids the race condition where one side falsely thinks an IKE-SA is up and still tries to use the IKE-SA for some (theoretically finite, but perhaps long) period of time. 2.6 Cookies The term "cookies" originates with Karn and Simpson [RFC 2522] in Photurus, an early proposal for key managment with IPsec. It has persisted because the IETF has never rejected an offer involving cookies. I like the above humor :-) My observation is that Paragraph 6 ("It may be convenient for the IKE-SA identifier ...") seems to be adding more complexity, rather than promoting the stated goal of reducing it. Is it too onerous to get rid of the feature described in Paragraph 6? 2.8 Rekeying Paragraph 6, "The form of re-keying ...", last sentence: The node that initiated the rekeying SHOULD delete the older SA after the new one is established. This is a little vague to me. Does this mean the initiator should only delete its local copy of the old SA, and not worry about its peer? Or, should the initiator send a DELETE-SA payload to its peer telling them to delete the old-SA, wait for positive confirmation and then destroy its local copy of the SA? 2.9 Traffic Selector Negotiation Could the directionality of IKE-SA's and CHILD-SA's be called out explicitly in the draft, (e.g.: IKE-SAs are bi-directional and CHILD-SAs are uni-directional)? Also, could the reasoning/history for why IKE-SAs are bi-directional and CHILD-SAs are uni-directional be documented in the draft? So, if CHILD-SA's are uni-directional, Traffic Selectors are also presumably uni-directional as well? Is there any expectation that Traffic Selectors exchanged between two peers be symmetric, for instance to represent a bi-directional conversation between two nodes? In paragraph 2, "The TS payload consists of a set of individual traffic selectors ..." Can a single TS payload simultaneously represent multiple IPv4 networks + ports under a single SA? Could you add text clarifying this? 3 The Phase 1 Exchange Payloads, such as CERTREQ and CERT, can appear 0 or more times in a particular message. Which other payloads may appear 1 or more times in a message? Regardless, can all payloads be expressed in the diagrams in Phase 1 + 2 in terms of the number of times they may appear in a message, perhaps using regular expressions? If no payloads may appear more than once, can a brief note be added indicating such? [NOTE: if you agree to using regexps to diagram the exchange, then a new character would have to be chosen instead of '*' to indicate encrypted IKE messages in further exchanges. Perhaps parentheses will be a good indicator of encryption?] Also, there really are two different SAs in Phase 1 (this section): IKE-SA (sent in the first round-trip to select transforms, etc. for IKE) and CHILD-SA (sent during the second round-trip to select transforms, etc. IPSec). Can the diagrams and text be cleaned up to reflect the different SAs? Perhaps this terminology will do: (HDR), SAi_ike, KEi, Ni, [,CERTREQi] --> <-- (HDR), SAr_ike, KEr, Nr [,CERTREQr] (HDR), IDi, AUTHi, [CERTi,] SAi_child, TSi, TSr --> <-- (HDR), IDr, AUTHr, [CERTr,] SAr_child, TSi, TSr 4 The CREATE-CHILD-SA (Phase 2) Exchange Third paragraph, second sentence: spelling mistake. CREAT_CHILD_SA should be CREATE_CHILD_SA. 4.1 Generating Keying Material for IPsec SAs There seems to be a discontinuity between the diagrams in section 4 and the text/diagrams in section 4.1. Specifically, in section 4 Nonces are referred to as Ni, Nr, but in section 4.1 Nonces are referred to as Ns, Nd. I'd recommend picking one term and sticking with it in both sections 4 + 4.1. Third paragraph, "In either case, 'protocol', and 'SPI', are from the SA payload ..." With respect to protocol, it is also from the SA accepted by the destination, correct? If so, could the diagram be updated to say "protocol_d"? Second question: what is used for "protocol_d" if there is multiple protocols -- either a discontiguous set of protocols or a range of protocols -- specified, and accepted, in an SA? 5 Informational (Phase 2) Exchange The diagram re-uses the letter 'N' to signify NOTIFY, whereas above it signifies a Nonce. Is it possible to change this as follows: (HDR), [NOTIFY,]* [DELETE]* --> <-- (HDR), [NOTIFY,]* [DELETE]* 6 Error Handling First paragraph, last sentence. You should add that these informational responses SHOULD be rate-limited (to some reasonable level), so as not to DoS a potential third-party with an overwhelming number of, possibly, unsolicited responses. Referring back to the first paragraph in this section: "(e.g. the node is getting ESP messages on a non-existent SPI), the node SHOULD initiate an Informational Exchange with a Notify payload describing the problem." ... because of the "SHOULD", there could potentially be blackholing of traffic if one side crashes, reboots, or there is temporary network congestion/partitioning. This is one of, if not thee most, significant problems with IKEv1 today that should get rectified in IKEv2. So far, the "birth certificate" proposal seems like the best remedy to this problem. Can it be shoehorned in? 7.1 The IKE Header This is in regards to the difference between the fields contained in the Generic Payload Header and the sole 'Next Payload' field in the IKE header. Aside from the inconsistency between them, how does an IKEv2 recipient know where the first payload is if there is a variable-length "Initialization Vector" in the IKE header? It would be nice to at least document this fact. (Note, all other fields in the IKE header are of fixed length so this seems like the only place where the recipient needs to store more state and/or do more work to figure out where is the first IKE payload). 7.2 Generic Payload Header Just out of curiousity, what was the original reasoning, and the reasoning today, for the 'Next Payload' field that lists the payload type for the payload following the present payload, (e.g.: payload+1)? Why not stick with a simpler TLV encoding that simply references the payload which immediately follows the payload header? Also, in what real-world deployment scenarios would the 'Critical' bit be used in IKEv2? In particular, this section says the 'Critical' bit is 0 for all payloads defined in this document [IKEv2] and if it's 0 then the sender doesn't mind if the receiver skips this payload. (Again, this begs the question of why not use a simpler TLV-encoding style for payloads and always skip the payloads you don't understand.) 7.3.3 Mandatory Transform Types The draft currently lists the following mandatory + optional types that IKE MUST support: Protocol Mandatory Types Optional Types IKE 1, 2, 3, 5, 7 ... however, in the "Transform Type Values" section above in section 7.3.2, Transform Type #4 "Integrity Algorithm" seems to be mandatory for IKE. Can you update 7.3.3, or 7.3.2, to make this consistent? 7.5 Identification Payload On SGs that implement Virtual Routers (VRs), it would be useful to have an additional ID Type designated that could identify the specific virtual router that the request is sourced from. The problem is one chassis may have multiple VRs that all hide behind a single public IP address. In addition, each of those VRs may have RFC1918 IP addresses on the "private" side that overlap with one or more VRs within the same chassis. Thus, it's difficult to uniquely ID a specific VR in IKE. While it's arguable how to represent a VR in a "standard" way, I recommend RFC2685 "Virtual Private Networks Identifier" as a possible solution and recommend creating an ID attribute for it in IKEv2. 7.7 Certificate Request Payload Last sentence in this section: "If no certificates exist then no further processing is performed-- this is not an error condition of the protocol." I recommend that this be considered an error in IKEv2, otherwise how is the sender of the CERTREQ going to know what was the specific problem with it's request? I recommend the following language: If no certificates exist, no further processing is performed. A NOTIFY MUST be sent to the sender of the CERTREQ informing them of this fact using an appropriate error code, (defined below in the "error codes" section of IKEv2 memo). 7.10.1 Notify Message Types Is it recommended that multiple NOTIFY payloads be packed into a single Informational exchange? Or, should multiple NOTIFY payloads be put in their own, separate IKE messages? Here are a few more suggestions, which are probably going to be quite controversial since they go against the grain of re-using as much of IKEv1 as possible: 1) Is it possible to review and revamp the error-codes in this section to perhaps group them and/or make them hierarchical? For instance, it would be nice to, perhaps numerically, indicate error codes along the lines of: WHERE-WHY-WHAT. In other words, which payload type(s) caused the problem and what was the problem with them. With regard to the "WHERE", it would be nice to break down the specific payload type(s) that caused the problem: IKE header, generic payload header, SA, proposal, transform, etc. (If there are multiple proposals, then it'd be nice to know the proposal number. In addition, if there are multiple transforms it'd also be nice to know the transform number). With respect to the "WHY", it would be useful to break them down into a few different categories: INVALID/FATAL, INVALID/INFORMATIONAL, UNSUPPORTED/FATAL, UNSUPPORTED/INFORMATIONAL or MALFORMED/FATAL. Finally, the "WHAT" could, if necessary, convey the specific field(s) and/or values in those fields that caused the problem. 2) Under Notification Data, I would add: "Upon receiving a NOTIFY payload, both the Notification Message Type AND Notification Data SHOULD be audited/logged." Perhaps additional text could be added suggesting that most of the time, it is insufficent just to see the Notification Message Type to troubleshoot a problem. Seeing what's in the Notification Data, possibly with some interpolation by the IKE implementation, will (hopefully) tell the specific reason for failure and aid quicker resolution. 3) Aside from sending an error code to the originator, it would be _extremely_ useful to also send a list of values/types that the receiver supports. This might be considered a "HOW" appended on to the "WHERE-WHY-WHAT" above in suggestion #1. For instance, if a IKE peer sends the NOTIFY payload "INVALID-ID-INFORMATION" it MUST also send a list of ID Types that it does support. This would also be extremely useful for the initiator in cases of "ATTRIBUTES-NOT-SUPPORTED" and "NO-PROPOSAL-CHOSEN" error codes. In short, it's not enough to know that something failed, but also how to fix it. 7.13.1 Traffic Selector Substructure Would it be too much to ask for an addition TS payload that is able to recognize one or more DS-Byte values? Presumably, DS-Byte could be used by itself or in conjunction with IPv4 addresses to provide a selector into the SPD? A second question wrt Traffic Selectors is specifying security services on a single pair of CHILD-SAs for a group of IPv4 addresses and/or subnets. Assume the following scenario: |> private LAN-A <| |> private LAN-B <| 192.168.0.0/24 ---+ +------+ +------+ +--- 192.168.4.0/24 |---| SG-A |----| SG-B |---| 192.168.1.0/24 ---+ +------+ +------+ +--- 192.168.5.0/24 When SG-A and SG-B want to establish a pair of IPSec SAs to protect all traffic on their private LANs, must they explicitly send all subnets that comprise the SA inside Traffic Selector payloads? In other words, is SG-A required to send 192.168.0.0/24 + 192.168.1.0/24 to SG-B? Or, can SG-A shortcut this process and send a single summary network, e.g.: 192.168.0.0/23, or even 0.0.0.0/0 to SG-B? I recommend that each subnet of the SA, (e.g.: both /24's), be sent in Traffic Selectors to avoid any confusion on either end. Regardless, whaever is decided, it needs to be called out explicitly in the spec because I have personally witnessed multiple interpretations by multiple vendors, which ultimately results in a lack of interoperability. -shane From owner-ipsec@lists.tislabs.com Fri Dec 28 00:41:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBS8fP218160; Fri, 28 Dec 2001 00:41:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA07058 Fri, 28 Dec 2001 03:01:50 -0500 (EST) Date: Fri, 28 Dec 2001 01:02:43 -0700 From: Shane Amante To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-jfk-00.txt Message-ID: <20011228010243.B934@nike.amante.org> Mail-Followup-To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 2.2 Protocol 1) In message 2, IDr is sent from the Responder back to the Initiator. However, on a chassis that implements VRs (Virtual Routers) how does the responder know the specific VR the initiator is trying to establish an SA with at this point in the exchange? (Assume that the VR box has a single public IP address and multiple VRs each with overlapping, private RFC1918 addrs contained within them). 2) Also IDr, the Identity of the Responder, is transmitted in the clear. In case a VR chassis is a Responder, an operator may want to actually protect the Identity of the Responder VR. Is there an option/modification to JFK to protect the Responder's ID (please, say "yes" :-) or is this strictly forbidden under the mandate of "protocol simplification"? 2.5 What JFK Avoids Third paragraph, "We also eliminate negotiation, in favor of ukases issued by the Responder." What is 'ukases'? Can you change that word to something more understandable? :-) Again, third paragraph: ... Any cryptographic primitive mentioned by the Responder is acceptable; the Initiator can choose any it wishes. We thus eliminate complex rules for selecting the ``best'' choice from two different sets. Just a comment: I much prefer the aforementioned behavior of JFK where the Initiator is in control, whereas in IKE the Initiator is ultimately at the mercy of the Responder. 4.1 Structure Each message is a string of tag-length-value elements concatenated together. Tags are one octet. Lengths are two octets, and specify the number of octets of the value. Values are always integral numbers of octets. All octets are in big-endian order. ... because 'tags' are 1 byte and 'lengths' are two bytes, doesn't this screw-up alignment on 32-bit boundaries? If so, is this a big deal to implementors, especially purveyors of hardware/ASICs? Aside from those specific comments, I think this draft is a good start towards specification of an simple, secure keying protocol. That said, the devil is in the details. I'd like to see more information in this spec wrt actual packet/payload formats, more granular error codes, aliveness-checks/birth-certificates, notifications (for errors), coordinated deletion of SAs/keys between two peers, timeouts, re-xmit intervals, SA lifetimes, etc. -shane From owner-ipsec@lists.tislabs.com Mon Dec 31 07:14:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBVFEB306573; Mon, 31 Dec 2001 07:14:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11793 Mon, 31 Dec 2001 09:08:37 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15406.55898.329047.676214@ryijy.hel.fi.ssh.com> Date: Sun, 30 Dec 2001 11:11:54 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: shane@amante.org (Shane Amante) Subject: Re: draft-ietf-ipsec-ikev2-00.txt References: <20011227232031.A934@nike.amante.org> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 35 min X-Total-Time: 38 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk shane@amante.org (Shane Amante) writes: > 2.6 Cookies > My observation is that Paragraph 6 ("It may be convenient for the > IKE-SA identifier ...") seems to be adding more complexity, rather > than promoting the stated goal of reducing it. Is it too onerous to > get rid of the feature described in Paragraph 6? Actually the feature that allows the responder to change the cookie also fixes one denial of service attack for the active attacker, which can listen all packets, and can send packets, but cannot remove packets in transit. The attack is as following (ci = initiators cookie, cr = responders cookie, ca = attackers cookie): Initiator Attacker Responder 1. HDR(0,ci), SA, KE, Ni --> (attacker sees that and sends fake packet init-reject packet to request cookie from the Initiator) 2. <-- HDR(ci,ca), N(IKE-SA-INIT-REJECT) (the original packet is received by the responder, it replies to it) 3. <-- HDR(ci,cr), SA, KE, Nr (Initiator replies to the attackers packet) 4. HDR(ca,ci), SA, KE, Ni --> (Responder will ignore this packet as the cookie ca does not match). (When the initiator sees the responders reply packet, it notices that the responder has received its 2nd packet and seems to have changed his cookie, thus it sends next packet) 5. HDR*(cr,ci), ID, AUTH --> (and the exchange continues). Of course the attacker could also always send other error notifications instead, but they are hopefully ignored by the initiator when he sees the real reply packet from the responder (i.e the if IKE end receives error notification without any protection it should wait for a while for real packet to arrive before acting based on the unauthenticated notification). Also if the initiator receives a valid 2nd packet with cookies, and then another packet with another cookie, it should reply to both packets with same data (i.e retransmit packet but change the recipient cookie). This will fix the attack where the attacker sends valid reply packets but with wrong cookie, thus causing the initiator to use wrong cookie, and exchange to fail. The second attack is like this: Initiator Attacker Responder 1. HDR(0,ci), SA, KE, Ni --> 2. <-- HDR(ci,ca), SA, KE, Nr 3. HDR*(ca,ci), ID, AUTH 4. <-- HDR(ci,cr), SA, KE, Nr After that the exchange fails, as the initiator has wrong responder cookie. The fixed exchange is like this: Initiator Attacker Responder 1. HDR(0,ci), SA, KE, Ni --> 2. <-- HDR(ci,ca), SA, KE, Nr 3. HDR*(ca,ci), ID, AUTH 4. <-- HDR(ci,cr), SA, KE, Nr 5. HDR*(cr,ci), ID, AUTH 6. <-- HDR*(ci,cr), ID, AUTH Perhaps the cookies should be renamed to addresses and their usage changed to so that source address, is ignored when packet is received, and when reply is sent to packet it is sent to the source address of the incoming packet to which this is reply (i.e the source and destination address (was cookies) are simply always swapped). The other end can change its address at any time. > Also, in what real-world deployment scenarios would the 'Critical' bit > be used in IKEv2? In particular, this section says the 'Critical' bit > is 0 for all payloads defined in this document [IKEv2] and if it's 0 > then the sender doesn't mind if the receiver skips this payload. I assume the the critical bit for IKEv2 defined payloads is 0 because they are not extensions they are part of the base protocol. It also keeps the most of the payload bit-by-bit compatible with IKEv1 payloads... > 7.7 Certificate Request Payload > > Last sentence in this section: "If no certificates exist then no > further processing is performed-- this is not an error condition of > the protocol." I recommend that this be considered an error in > IKEv2, otherwise how is the sender of the CERTREQ going to know > what was the specific problem with it's request? I recommend the > following language: > If no certificates exist, no further processing is performed. A > NOTIFY MUST be sent to the sender of the CERTREQ informing them of > this fact using an appropriate error code, (defined below in the > "error codes" section of IKEv2 memo). I hope that you mean that the negotiation still continues as normally, we just include that notification payload to the reply packet, but do not consider it as an error condition of the protocol. I think it must be warning condition only not error condition. There are quite a lot of cases where the other end cannot fullfill the certificate requests the other end sent, but the authentication can still succeed as the other end can use some other means to fetch the certificate. > 7.10.1 Notify Message Types > > Is it recommended that multiple NOTIFY payloads be packed into a > single Informational exchange? Or, should multiple NOTIFY payloads be > put in their own, separate IKE messages? > > Here are a few more suggestions, which are probably going to be quite > controversial since they go against the grain of re-using as much > of IKEv1 as possible: I think we should use the format described in the draft-ietf-ipsec-notifymsg-04.txt (which seems to have expired). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/