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.t