From owner-ipsec@lists.tislabs.com Sun Jun 2 13:44:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g52Kitg28606; Sun, 2 Jun 2002 13:44:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21489 Sun, 2 Jun 2002 15:38:58 -0400 (EDT) Message-Id: <3.0.3.32.20020602125529.01372aa0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 02 Jun 2002 12:55:29 -0700 To: Stephen Kent From: Alex Alten Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, At 08:10 PM 5/29/2002 -0400, Stephen Kent wrote: >At 4:43 PM -0700 5/24/02, Alex Alten wrote: >>Steve, >> >>I'm not talking about a host's local database. We need a way to uniquely >>AND SECURELY identify any host worldwide from any other host. You don't >>want to replicate this information to every host, you'd have over 100 million >>entries to distribute to each one! > >Oh, well, you've moved the problem well beyond the bounds of the >IPsec WG, given this description of what you are looking for. Also, >given my earlier comments about the desirability of not creating new >ID forms for use in access control systems, I think we have a >fundamental disagreement here. > Fair enough. I firmly believe that IPsec cannot operate in a vacuum, there has to be a supporting infrastructure that works well with it. The two are necessarily intertwined with design decisions recursively effecting each other. But this may be beyond the IPsec WG charter, although I would argue that it should be a vital part of it. >>I like DNS too, a nice simple hierarchy, it is easy to uniquely name hosts, >>and a simple distributed model for managing the address space. But it has a >>crippling drawback from a security perspective. A DNS name cannot be any >>better >>at identifying a host than it's resolved IP address. >>And we know how >>ephemeral IP addresses can be given the rise of DHCP and NAT. The only >>secure way to absolutely identify a host is to assign it a (randomly) unique >>crypto key. But before you can pull the correct key (RSA or AES) you need to >>find it. For this you need a unique number that doesn't keep being changed >>underneath you. So unfortunately DNS doesn't make the cut. No amount of >>wishful >>thinking is going to make it work properly for us. > >I think your argument above is faulty. If I choose to use DNS names >as a basis for access control decisions, and if I have credentials >(e.g., certificates) that allow a machine or person to verify that >the entity at the other end of a key management exchange is the >entity with the DNS name in question, then I can dynamically bind the >name to the current address at the time an SA is created and I have >achieved the access control goals without needing to introduce the >sort of new ID scheme to which you are alluding. > > Let's follow your arguement through. I need to establish an IPsec connection to www.kent.com. It is currently assigned to machine A which has an address of 200.200.200.1. The next morning the admin decides to change the DNS entry to point to machine B at 200.200.200.2. Now my IPsec connection will fail, even though machine A at 200.200.200.1 is still active! Why? Because the key is residing on A not on B. So using a cert with a DNS name bound to the key is useless. Any system relying on it will quickly run into the problem of how do you keep DNS names and keys in synch across multiple machines. And it is *not* good security practice to keep transferring private authentication keys (either AES or RSA) from machine to machine every time a DNS entry changes. It makes a mockery of using a key to automate the authentication of a particular machine. So certs are useless, you need the flexibility of reassigning a new DNS name to A's key! But how can I find the new DNS name for A in order to get the correct key? To solve this problem, if you don't allow the DNS name www.kent.com to change to B then you defeat one of the main reasons to use DNS. A catch-22 results. Therefore PKI certs & DNS don't mix. Also, if you require DNS as the ID, then how do we address machines without a DNS name? To anticipate your answer, then use a cert bound to an IP address. But even then we still have the problem of dynamically assigned IP addresses via NAT or DHCP. Again another catch-22 results. So it turns out that neither DNS nor IP addresses can satisfy our need to be able to reliably get the proper key needed to start up the IPsec connection. I am arguing that the key should be bound to the machine itself, regardless of it's address(es). The ID I speak of is really a key ID assigned to that machine, in a sense very similar to a PGP key ID. But with the significant difference that we assign an ID to the key, rather than generating it from the key. >>To reiterate my position: IPsec needs to have a global, secure address space >>that uniquely identifies every participating host. It needs to be simple to >>understand, distributable, and easy to manage. And it needs to be able to >>dynamically map into the IP address space on demand, including private >>network non-routable addresses. >> >>That's the requirements as I see them. Anything less than this means >>you can't use IPsec unencumbered across the Internet. > >we don't need a global, secure address space. we need secure means of >mapping IDs to credentials, and mapping those IDs to SA, in real >time, as you note immediately above. These two notions are not the >same. > Right, I had already agreed with Ken Brown earlier that global and secure are not required. However global would simplify the problem significantly. In fact I would argue it would be almost impossible to build a world-wide system among many organizations using IPsec otherwise. Secure doesn't actually make sense since the ID is being used to bootstrap getting the key. So the ID cannot be secure in and of itself. The IPsec system must be able to carefully bootstrap from an insecure state to a secure state. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sun Jun 2 17:37:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g530bYg01964; Sun, 2 Jun 2002 17:37:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21817 Sun, 2 Jun 2002 19:51:12 -0400 (EDT) Message-ID: <08e101c20a92$2e7fddf0$1f02a8c0@entrust.com> From: "Greg Carter" To: References: <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020602125529.01372aa0@mail> Subject: Re: addresses and IKEv2 Date: Sun, 2 Jun 2002 20:04:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Alex Alten" To: "Stephen Kent" Cc: Sent: Sunday, June 02, 2002 3:55 PM Subject: Re: addresses and IKEv2 > Let's follow your arguement through. I need to establish an IPsec > connection to www.kent.com. It is currently assigned to machine A which > has an address of 200.200.200.1. The next morning the admin decides to > change the DNS entry to point to machine B at 200.200.200.2. Now my > IPsec connection will fail, even though machine A at 200.200.200.1 is > still active! Why? Because the key is residing on A not on B. So using > a cert with a DNS name bound to the key is useless. Any system relying > on it will quickly run into the problem of how do you keep DNS names and > keys in synch across multiple machines. And it is *not* good security > practice to keep transferring private authentication keys (either AES or > RSA) from machine to machine every time a DNS entry changes. It makes a > mockery of using a key to automate the authentication of a particular > machine. So certs are useless, you need the flexibility of reassigning a > new DNS name to A's key! But how can I find the new DNS name for A in order > to get the correct key? To solve this problem, if you don't allow the DNS > name www.kent.com to change to B then you defeat one of the main reasons to > use DNS. A catch-22 results. Therefore PKI certs & DNS don't mix. > There is no reason why the connection would fail to B. B would (well at least should) have been assigned a new certificate which contains the desired DNS name, as part of the process of bringing it on line. So when you attempt to connect to B, IKE goes through the motions, you get B's certificate (not A's) during phase one with the DNS name kent.com in it and everything will validate. There is no need to "share" a key pair across the two machines. If it is the administrators desire to have A remain active for a time then yes two machines will have certificates that contain the same DNS name. If it is not then the administrator revokes A's certificate at the same time he takes A off line and puts B on. Greg From owner-ipsec@lists.tislabs.com Mon Jun 3 00:07:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5377eg18821; Mon, 3 Jun 2002 00:07:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA22440 Mon, 3 Jun 2002 02:24:54 -0400 (EDT) X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD093D69@mailserver.sylantro.com> From: "Eric Nielsen" To: "'Greg Carter '" , "'ipsec@lists.tislabs.com '" Subject: RE: Public Keys to initiate IPsec. Date: Sun, 2 Jun 2002 23:31:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10E5D2D8572151-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the pointers. After reading thru PKIX and SCEP, and being reinforced by Alex Alten's message today RE: addresses and IKEv2, it is clear a key element of my problem is associating the application's endpoint name with the security key, but not the dynamically provided IP address. The endpoint name is not in DNS, and customer premise DHCP is outside of our control. When the endpoint's IP address changes the client app. reregisters. Upon each regstriation a new session key and SA should be created. At all other times the secure session needs to be up 24x7x365. It looks like the regsitration process must always be initiated without security so that an entry can be put into the IPsecConfig updating the new mapping of IP address to key. It also seems like a potential DoS mechanism to act based on this unauthenticated registration message. It would be best that prior to registration a new SA is created that links the (non-DNS) endpoint name to a shared private or public key. Extra work and changes to configurations would not be needed based on unauthenticated messages. It looks like SCEP is about the right weight for key management using LDAP for storage. But then anoterh protocol is required, and all intervening firewalls need to allow it. More possibilities for error. It would be nice if this level of key management could be performed over the IPsec link. Can a public certificate be associated with an application name/URI that does not exist in DNS? Eric -----Original Message----- From: Greg Carter To: ipsec@lists.tislabs.com Sent: 5/31/02 8:18 PM Subject: Re: Public Keys to initiate IPsec. ----- Original Message ----- From: "Eric Nielsen" Subject: Public Keys to initiate IPsec. >They may be symmetric keys for ESP or a private/public key pair for AH. AH uses symmetric based cryptography. > ======================================================================== > All that said, is there a streamlined process like this I can implement > within IPsec/IKE/IKEv2/JFK today? Not really, at least not in IKE v1. >Are there key differences or security > holes that may or may not make it possible to use this kind of process? What you have describe as your phase one is in essence a PKI and enrolling a client into that PKI with the one time password. IKE assumes that you already have the trust relationship in place, either through a shared key or via a certified public key. All(!)you are doing in IKE is verifying the identity, you are not managing the identities credentials within your trust 'hierarchy'. Combining the two operations would unnecessarily complicate IKE. Check out the PKIX working group, specifically RFC 2510, and/or RFC 2797. But I would look into finding more about SCEP before implementing 2797 if you want an "on line" enrolment protocol. Bye. Greg. From owner-ipsec@lists.tislabs.com Mon Jun 3 10:34:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53HYeg09372; Mon, 3 Jun 2002 10:34:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23661 Mon, 3 Jun 2002 12:47:34 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: Specification of tunnel/transport attribute in IKEv2 To: "'ipsec list'" X-Mailer: Lotus Notes Build V60_M13_04242002 Pre-release 2 April 24, 2002 Message-ID: Date: Sat, 1 Jun 2002 22:54:35 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_05292002|May 29, 2002) at 06/03/2002 11:43:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Returning to the original posting under this subject line, Andrew Krywaniuk asked: > I remember reading a posting on the list recently about the confusion > surrounding the specification of tunnel mode with SA bundles (i.e. if you > are doing ESP+AH, should you specify tunnel mode for one and transport for > the other or tunnel for both). At the bakeoffs, we decided that you should > put tunnel mode in both protocols. Also, we decided that the ordering of the > protocols in the proposal shouldn't matter, since the only ordering that > makes sense is [AH][ESP][IPCOMP]. Seems like this should be pinned down. My inclination is to say that the order in the proposal *does* matter, and therefore if the above is the only order that makes sense then that is the only order allowed in the proposal. Markku Savela claimed there was a legitimate use for a different composition. I'll confess I didn't understand the rationale, but I'm reluctant to delete functionality if it's implemented and doesn't get in anyone's way. Would people accept making it explicit that the order in the proposal MUST match the order of headers in the resulting packets with mention that implementations of combinations SHOULD use the order [AH][ESP][IPCOMP]? Currently, no composition of AH and ESP is mandatory to implement, and I would expect that it would be unusual for anyone to support it in a single bundle. (They might exist in a single packet when tunnels are nested, but such would not be an issue for IKE). Is there an expectation that people are actually going to do this? > > I figured we should make sure that these ambiguities are cleared up in the > Son-of-IKE candidates. However, in perusing through the IKEv2 draft, I can > find no mention of tunnel mode or transport mode at all. Are the authors > assuming that one of the modes is going to be eliminated before we > standardize SOI, or is this just an oversight? It was not an oversight, though it may have been a mistake. I assumed that tunnel vs transport mode did not need to be negotiated nor be an attribute of the SA, but rather that every SA would be capable of carrying both transport mode and tunnel mode packets. In the extreme, a single SA might carry both types where tunnel mode is used when the inner IP addresses don't match the outer IP addresses. I can see how this might cause confusion through NATs, but it's not clear how adding tunnel vs. transport mode to the negotiation helps in that case. Could someone give an example of when it's not "obvious" what mode should be used and how the endnodes can manage to negotiate the right thing in that case? > Also, it might be nice to > mention that the ordering of the protocols within the proposal does not > affect the order in which they are applied to IPsec packets. > > A final issue is where to specify the group number if (god forbid) you are > using PFS. I think we decided that it should be specified in both the ESP > and AH protocols and optionally in IPCOMP. I wish I could find the > antecedent message (I think it was by Joern), but nothing on this subject > has been posted in the last few days. My reading of the current draft is that if the group number differs from the group of the phase 1 exchange, then it MUST be specified in both the ESP and AH proposals and MUST NOT be specified in IPCOMP (since IPCOMP does not use keying material derived from the D-H exchange). If people think the spec is unclear or this is the wrong thing to do, please propose alternative wording. --Charlie From owner-ipsec@lists.tislabs.com Mon Jun 3 10:35:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53HZdg09409; Mon, 3 Jun 2002 10:35:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23655 Mon, 3 Jun 2002 12:46:34 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: addresses and IKEv2 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_M13_04242002 Pre-release 2 April 24, 2002 Message-ID: Date: Sat, 1 Jun 2002 19:02:27 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_05292002|May 29, 2002) at 06/03/2002 11:43:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I apologize for the formatting mishap in my last posting. Some people received it correctly; others with all the EOLs stripped out. I haven't figured out why. I hope it doesn't happen again with this message. I'm trying to figure out whether we reached any implementable conclusions on this topic. The IKEv2 spec doesn't say what an IKE implementation should do if it gets a message with a recognized SPI but an unexpected source (or destination) address. I think the conclusion from this string was that an implementation MUST ignore both addresses, and base its processing solely on the SPI. Does anyone object to that? The IKEv2 spec says "An implementation MUST accept incoming connection requests even if not received from UDP port 500, and should respond to the address and port from which the request was received." (Section 2.11). I propose that language be extended to say that the source IP address and port should be remembered with the connection state and that all messages subsequent to connection setup be sent to the IP address and port associated with the connection (ignoring the source of subsequent messages). Does anyone object to that? I am sympathetic to Francis Dumont's suggestion that there be a new optional payload that securely tells the other end that its address is changing and that all future IKE, ESP, and AH traffic to this entity should be directed to a new IP address and possibly port. This would allow a better and more secure integration with MobileIP allowing connections to stay up when nodes move without introducing yet another layer of headers. But I'm reluctant to specify it without at least consulting with MobileIP savvy people and what I'd really like is for someone to express an intent to implement it. What do people think? --Charlie From owner-ipsec@lists.tislabs.com Mon Jun 3 13:33:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53KX8g16930; Mon, 3 Jun 2002 13:33:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24332 Mon, 3 Jun 2002 15:42:19 -0400 (EDT) X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD0174AA0C@mailserver.sylantro.com> From: "Eric Nielsen" To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: addresses and IKEv2 Date: Mon, 3 Jun 2002 12:48:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10E517A7580659-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Charlie_Kaufman@notesdev.ibm.com Sent: Saturday, June 01, 2002 4:02 PM > I think the conclusion from this string was that an implementation > MUST ignore both addresses, and base its processing solely on the SPI. Does > anyone object to that? I believe that IKE should allow some sort of policy be applied regarding how to respond to the message. There needs to include the ability to perform some external check, too. Example: If "A" was to reboot and come up at IP "1.1.1.3" it would need to retain the SPI context over reboots. This is possible. The real problem is upon initial connection, or if the SPI is lost. The mechanism for startup should be the same as it is for ongoing address changes. In this example assume there is an endpoint named "A@domain" expected to be deployed at IP address 1.1.1.1. Also assume manual symmetric keys are used. The server needs to be pre-configured saying that "A" is at IP address "1.1.1.1" with key "KEY_A". However, when unit "A" is plugged in DHCP gives "A" the address "1.1.1.123". There is no way that the server can know to match "A"'s communications with "KEY_A" unless the installer calls back to the server to reconfigure it. There should be an optional generic way to link the security key to information other than IP address and/or port. If I also have an endpoint "B@domain.com" at address 1.1.1.2, I do not want "A" to be able to send spoofed but authenticated packets that say that packet came from "B" at IP address ".2". There needs to be some policy limiting whether to accept this packet. Possibly a hook for a third-party check would go nicely to handle this case. Eric -----Original Message----- From: Charlie_Kaufman@notesdev.ibm.com [mailto:Charlie_Kaufman@notesdev.ibm.com] Sent: Saturday, June 01, 2002 4:02 PM To: ipsec@lists.tislabs.com Subject: Re: addresses and IKEv2 I apologize for the formatting mishap in my last posting. Some people received it correctly; others with all the EOLs stripped out. I haven't figured out why. I hope it doesn't happen again with this message. I'm trying to figure out whether we reached any implementable conclusions on this topic. The IKEv2 spec doesn't say what an IKE implementation should do if it gets a message with a recognized SPI but an unexpected source (or destination) address. I think the conclusion from this string was that an implementation MUST ignore both addresses, and base its processing solely on the SPI. Does anyone object to that? The IKEv2 spec says "An implementation MUST accept incoming connection requests even if not received from UDP port 500, and should respond to the address and port from which the request was received." (Section 2.11). I propose that language be extended to say that the source IP address and port should be remembered with the connection state and that all messages subsequent to connection setup be sent to the IP address and port associated with the connection (ignoring the source of subsequent messages). Does anyone object to that? I am sympathetic to Francis Dumont's suggestion that there be a new optional payload that securely tells the other end that its address is changing and that all future IKE, ESP, and AH traffic to this entity should be directed to a new IP address and possibly port. This would allow a better and more secure integration with MobileIP allowing connections to stay up when nodes move without introducing yet another layer of headers. But I'm reluctant to specify it without at least consulting with MobileIP savvy people and what I'd really like is for someone to express an intent to implement it. What do people think? --Charlie From owner-ipsec@lists.tislabs.com Mon Jun 3 15:07:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53M72g19289; Mon, 3 Jun 2002 15:07:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24449 Mon, 3 Jun 2002 17:09:55 -0400 (EDT) Date: 3 Jun 2002 17:10:42 -0400 Message-ID: <000901c20b43$1faed0e0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Charlie Kaufman'" , " 'ipsec list'" Subject: RE: Specification of tunnel/transport attribute in IKEv2 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Charlie, Thanks for returning this thread back to the original topic. > > At the bakeoffs, we decided that you > should > > put tunnel mode in both protocols. Also, we decided that > the ordering of > the > > protocols in the proposal shouldn't matter, since the only > ordering that > > makes sense is [AH][ESP][IPCOMP]. > Seems like this should be pinned down. My inclination is to > say that the > order in the proposal *does* matter, and therefore if the > above is the only > order that makes sense then that is the only order allowed in > the proposal. What we discovered at the bakeoffs is that nature seeks out diversity. If you don't specify stuff like this explicitly in the RFCs then people will somehow manage to not interoperate. There is a trap that programmers often fall into, which is to try to find a meaning in any arbitrary sequence of bits. For IKEv1, most people had no desire to do anything other than [AH][ESP][IPCOMP]. Since accepting the transforms in any order and interpreting them as [AH][ESP] appears to give you the greatest probability of interoperating (you weren't going to interoperate with someone doing [ESP][AH] anyway), people implemented it that way. > Markku Savela claimed there was a legitimate use for a different > composition. I'll confess I didn't understand the rationale, but I'm > reluctant > to delete functionality if it's implemented and doesn't get > in anyone's > way. I didn't really understand it either. Apparently, an attacker might try to surrepticiously change the non-mutable fields of the IP header, but they won't do it if you're using AH because then the attack would be detected. So by putting AH inside ESP you can bait the attacker into thinking they can launch the attack undetected. My gut reaction is "fine, then let them," although I'm sure Markku is going to reply anyway. You wouldn't be deleting functionality. You are adding functionality, since Markku's IKEv1 doesn't interoperate with others in this regard. (There was a straw poll at a bakeoff, the result being that ESP+AH should be interpreted as [AH][ESP], and people have been implementing it that way ever since.) I don't mind if the spec allows arbitrary combinations, as long as anything other than the standard ordering is relegated to a MAY. Our policy definition language does not allow the user to control the order of the transforms, and I hope to not change this. > Currently, no composition of AH and ESP is mandatory to implement, and > I would expect that it would be unusual for anyone to support it in a > single > bundle. (They might exist in a single packet when tunnels are > nested, but > such would not be an issue for IKE). Is there an expectation > that people > are actually going to do this? Sadly, people do want to do this. Authentication was added to ESP more than 3 years ago, and I still get frequent questions from people that either a) don't realize that ESP can provide authentication, b) believe that authenticating the header is important [even in tunnel mode], or c) want that "extra level of security" that comes from doing authentication in both ESP and AH. I don't know why, but it just seems like we're just not getting the message out. You've even got it in the draft: (page 32) For example, an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR (ESP w/MD5 and 3DES). > > I can > > find no mention of tunnel mode or transport mode at all. > Are the authors > > assuming that one of the modes is going to be eliminated before we > > standardize SOI, or is this just an oversight? > > It was not an oversight, though it may have been a mistake. I assumed > that tunnel vs transport mode did not need to be negotiated nor be an > attribute of the SA, but rather that every SA would be capable of > carrying both transport mode and tunnel mode packets. In the extreme, > a single SA might carry both types where tunnel mode is used when the > inner IP addresses don't match the outer IP addresses. I can see how > this might cause confusion through NATs, but it's not clear how adding > tunnel vs. transport mode to the negotiation helps in that case. I was merely wondering, since this is a departure from IKEv1 (encapsulation modes are defined on page 13 of the DOI). The obvious problem is NATs. With the existing NAT-T drafts, we use the encapsulation mode attribute to specify either UDP+transport or UDP+tunnel. Also, there is a special OA (original address) payload that is only sent for UDP+transport mode and which allows the effects of the NAT to be reversed. Also, I wonder what the effects of the tunnel/transport ambiguity might be for hardware (or even optimized software) implementations of IPsec. The SA or SA bundle "object" may be a streamlined code path that is tuned to the specific attributes of the SA. We have some deployed products that would not take kindly to transport and tunnel being mixed on the same SA. This could obviously be changed, but I wanted to point out that this update to IKE is also going to have an affect on people's packet-level IPsec implementations. > My reading of the current draft is that if the group number > differs from > the > group of the phase 1 exchange, then it MUST be specified in both the > ESP and AH proposals and MUST NOT be specified in IPCOMP (since > IPCOMP does not use keying material derived from the D-H exchange). Okay, it took me awhile to find the text you are referring to, but I assume you mean: Diffie-Hellman Group 5 (IKE and optional in AH and ESP) I think your interpretation is that same one that I would make, but others may disagree. Some people take RFC wording very literally (the word "unique" comes to mind). Remember that this was an interop problem with IKEv1, so obviously not everyone interpreted the original RFCs the same way. 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 > Charlie_Kaufman@notesdev.ibm.com > Sent: Saturday, June 01, 2002 10:55 PM > To: 'ipsec list' > Subject: Re: Specification of tunnel/transport attribute in IKEv2 > > > > > > > Returning to the original posting under this subject line, > Andrew Krywaniuk > asked: > > > I remember reading a posting on the list recently about the > confusion > > surrounding the specification of tunnel mode with SA > bundles (i.e. if you > > are doing ESP+AH, should you specify tunnel mode for one > and transport > for > > the other or tunnel for both). At the bakeoffs, we decided that you > should > > put tunnel mode in both protocols. Also, we decided that > the ordering of > the > > protocols in the proposal shouldn't matter, since the only > ordering that > > makes sense is [AH][ESP][IPCOMP]. > > Seems like this should be pinned down. My inclination is to > say that the > order in the proposal *does* matter, and therefore if the > above is the only > order that makes sense then that is the only order allowed in > the proposal. > Markku Savela claimed there was a legitimate use for a different > composition. I'll confess I didn't understand the rationale, but I'm > reluctant > to delete functionality if it's implemented and doesn't get > in anyone's > way. > > Would people accept making it explicit that the order in the proposal > MUST match the order of headers in the resulting packets with mention > that implementations of combinations SHOULD use the order > [AH][ESP][IPCOMP]? > > Currently, no composition of AH and ESP is mandatory to implement, and > I would expect that it would be unusual for anyone to support it in a > single > bundle. (They might exist in a single packet when tunnels are > nested, but > such would not be an issue for IKE). Is there an expectation > that people > are actually going to do this? > > > > > I figured we should make sure that these ambiguities are > cleared up in > the > > Son-of-IKE candidates. However, in perusing through the > IKEv2 draft, I > can > > find no mention of tunnel mode or transport mode at all. > Are the authors > > assuming that one of the modes is going to be eliminated before we > > standardize SOI, or is this just an oversight? > > It was not an oversight, though it may have been a mistake. I assumed > that tunnel vs transport mode did not need to be negotiated nor be an > attribute of the SA, but rather that every SA would be capable of > carrying both transport mode and tunnel mode packets. In the extreme, > a single SA might carry both types where tunnel mode is used when the > inner IP addresses don't match the outer IP addresses. I can see how > this might cause confusion through NATs, but it's not clear how adding > tunnel vs. transport mode to the negotiation helps in that case. > > Could someone give an example of when it's not "obvious" what mode > should be used and how the endnodes can manage to negotiate the > right thing in that case? > > > Also, it might be nice to > > mention that the ordering of the protocols within the > proposal does not > > affect the order in which they are applied to IPsec packets. > > > > A final issue is where to specify the group number if (god > forbid) you > are > > using PFS. I think we decided that it should be specified > in both the ESP > > and AH protocols and optionally in IPCOMP. I wish I could find the > > antecedent message (I think it was by Joern), but nothing > on this subject > > has been posted in the last few days. > > My reading of the current draft is that if the group number > differs from > the > group of the phase 1 exchange, then it MUST be specified in both the > ESP and AH proposals and MUST NOT be specified in IPCOMP (since > IPCOMP does not use keying material derived from the D-H exchange). > > If people think the spec is unclear or this is the wrong thing to do, > please > propose alternative wording. > > --Charlie > From owner-ipsec@lists.tislabs.com Mon Jun 3 15:28:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53MSQg19659; Mon, 3 Jun 2002 15:28:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24573 Mon, 3 Jun 2002 17:47:21 -0400 (EDT) Date: 3 Jun 2002 17:48:07 -0400 Message-ID: <000c01c20b48$5a2a07d0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Eric Nielsen'" , " 'Charlie Kaufman'" , " 'list'" Subject: RE: addresses and IKEv2 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD0174AA0C@mailserver.sylantro.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The IKEv2 spec doesn't say what an IKE implementation should > do if it gets > a message with a recognized SPI but an unexpected source (or > destination) > address. I think the conclusion from this string was that an > implementation > MUST ignore both addresses, and base its processing solely on > the SPI. Does > anyone object to that? Isn't this more of a question for the SPD spec? If you're talking about a message with recognized cookies, but an unexpected source, that is something we could handle in SOI. > If I also have an endpoint "B@domain.com" at address 1.1.1.2, > I do not want "A" to be able to send spoofed but authenticated > packets that say that packet came from "B" at IP address ".2". > There needs to be some policy limiting whether to accept this > packet. Possibly a hook for a third-party check would go > nicely to handle this case. Yes, this is an important case. Currently we perform this check during SA establishment. Doing it via a user mode callback could be a much more expensive proposition, especially if someone got their hands on a captured packet and started replaying it from thousands of different IPs. > I am sympathetic to Francis Dumont's suggestion that there be a new > optional payload that securely tells the other end that its address is > changing and that all future IKE, ESP, and AH traffic to this > entity should > be directed to a new IP address and possibly port. There is an allusion to this issue in the requirements document. Having an IKE message for updating the mobile IP makes a lot of sense. It seems to be the only good way to securely deliver the update to the right place in the stack without introducing a lot of extra overhead (e.g. a new phase 1 negotiation). 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 Eric Nielsen > Sent: Monday, June 03, 2002 3:49 PM > To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com > Subject: RE: addresses and IKEv2 > > > From: Charlie_Kaufman@notesdev.ibm.com > Sent: Saturday, June 01, 2002 4:02 PM > > I think the conclusion from this string was that an implementation > > MUST ignore both addresses, and base its processing solely > on the SPI. > Does > > anyone object to that? > > I believe that IKE should allow some sort of policy > be applied regarding how to respond to the message. > There needs to include the ability to perform some > external check, too. > > > Example: > > If "A" was to reboot and come up at IP "1.1.1.3" it would > need to retain the SPI context over reboots. This is possible. > The real problem is upon initial connection, or if the SPI > is lost. The mechanism for startup should be the same as it > is for ongoing address changes. > > In this example assume there is an endpoint named "A@domain" > expected to be deployed at IP address 1.1.1.1. Also assume > manual symmetric keys are used. > > The server needs to be pre-configured saying that "A" is > at IP address "1.1.1.1" with key "KEY_A". However, when > unit "A" is plugged in DHCP gives "A" the address > "1.1.1.123". There is no way that the server can know to > match "A"'s communications with "KEY_A" unless the installer > calls back to the server to reconfigure it. > > There should be an optional generic way to link the security > key to information other than IP address and/or port. > > If I also have an endpoint "B@domain.com" at address 1.1.1.2, > I do not want "A" to be able to send spoofed but authenticated > packets that say that packet came from "B" at IP address ".2". > There needs to be some policy limiting whether to accept this > packet. Possibly a hook for a third-party check would go > nicely to handle this case. > > Eric > > > -----Original Message----- > From: Charlie_Kaufman@notesdev.ibm.com > [mailto:Charlie_Kaufman@notesdev.ibm.com] > Sent: Saturday, June 01, 2002 4:02 PM > To: ipsec@lists.tislabs.com > Subject: Re: addresses and IKEv2 > > > > > > > I apologize for the formatting mishap in my last posting. Some people > received it correctly; others with all the EOLs stripped out. > I haven't > figured out why. I hope it doesn't happen again with this message. > > I'm trying to figure out whether we reached any implementable > conclusions > on this topic. > > The IKEv2 spec doesn't say what an IKE implementation should > do if it gets > a message with a recognized SPI but an unexpected source (or > destination) > address. I think the conclusion from this string was that an > implementation > MUST ignore both addresses, and base its processing solely on > the SPI. Does > anyone object to that? > > The IKEv2 spec says "An implementation MUST accept incoming connection > requests even if not received from UDP port 500, and should > respond to the > address and port from which the request was received." > (Section 2.11). I > propose that language be extended to say that the source IP > address and > port should be remembered with the connection state and that > all messages > subsequent to connection setup be sent to the IP address and port > associated with the connection (ignoring the source of subsequent > messages). Does anyone object to that? > > I am sympathetic to Francis Dumont's suggestion that there be a new > optional payload that securely tells the other end that its address is > changing and that all future IKE, ESP, and AH traffic to this > entity should > be directed to a new IP address and possibly port. This would allow a > better and more secure integration with MobileIP allowing > connections to > stay up when nodes move without introducing yet another layer > of headers. > But I'm reluctant to specify it without at least consulting > with MobileIP > savvy people and what I'd really like is for someone to > express an intent > to implement it. > > What do people think? > > --Charlie > > From owner-ipsec@lists.tislabs.com Mon Jun 3 16:28:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53NSsg20724; Mon, 3 Jun 2002 16:28:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24699 Mon, 3 Jun 2002 18:46:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD093D69@mailserver.sylantro.com> References: <79FEAA5FABA7D411BF580001023D1BBD093D69@mailserver.sylantro.com> Date: Mon, 3 Jun 2002 18:59:07 -0400 To: "Eric Nielsen" From: Stephen Kent Subject: RE: Public Keys to initiate IPsec. Cc: "'ipsec@lists.tislabs.com '" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric, It sounds like you want to assign some name to an app that will be meaningful to folks trying to reach a set of apps, and which can be configured into the SPDs to the clients trying to reach the apps. Presumably this is for IPsec implementations in end systems, not gateways. Is there some way for a client to assert which app it is trying to contact, or is the client restructed to contacting only those apps that are listed in its SPD? Absent one or the other of these measures it seems unlikely that IPsec can control access (from the client perspective) in a meaningful way. You've explained some things about mechanisms constraints, but I'm not sure I understand the security goals of using Ipsec here, which makes it hard to figure out what solutions might be applicable. Steve From owner-ipsec@lists.tislabs.com Mon Jun 3 16:55:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Ntsg21230; Mon, 3 Jun 2002 16:55:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24741 Mon, 3 Jun 2002 19:19:47 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15611.64649.32764.797517@thomasm-u1.cisco.com> Date: Mon, 3 Jun 2002 16:32:25 -0700 (PDT) To: andrew.krywaniuk@alcatel.com Cc: "'Charlie Kaufman'" , " 'ipsec list'" Subject: RE: Specification of tunnel/transport attribute in IKEv2 In-Reply-To: <000901c20b43$1faed0e0$1e72788a@ca.alcatel.com> References: <000901c20b43$1faed0e0$1e72788a@ca.alcatel.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 Andrew Krywaniuk writes: > Sadly, people do want to do this. Authentication was added to ESP more than > 3 years ago, and I still get frequent questions from people that either a) > don't realize that ESP can provide authentication, b) believe that > authenticating the header is important [even in tunnel mode], or c) want > that "extra level of security" that comes from doing authentication in both > ESP and AH. I don't know why, but it just seems like we're just not getting > the message out. Choose one: o RFC2402 IP Authentication Header S. Kent, R. Atkinson November 1998 ASCII Obsoletes RFC1826 Historic o RFC2402 IP Authentication Header S. Kent, R. Atkinson November 1998 ASCII Obsoletes RFC1826 Updated by RFC2406 :-) Mike From owner-ipsec@lists.tislabs.com Mon Jun 3 19:12:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g542CBg23956; Mon, 3 Jun 2002 19:12:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25166 Mon, 3 Jun 2002 21:30:24 -0400 (EDT) X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD0174ABA7@mailserver.sylantro.com> From: "Eric Nielsen" To: "Stephen Kent" cc: "'ipsec@lists.tislabs.com '" Subject: RE: Public Keys to initiate IPsec. Date: Mon, 3 Jun 2002 18:37:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10E2C649586735-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, We build a call control application using MGCP. IPsec is the standard for securing MGCP in RFC 2705. The RFC says nothing about what that really means. Our call control agent receives only MGCP on specific UDP ports. Each MGCP endpoint has a name, similar to a SIP URI. The name is the key to all actions that are invoked, what keys are used, etc. The endpoint name is in the header of MGCP message, but I need to relate it to the secure communications. I cannot allow one trusted endpoint to spoof another, and I cannot control IP addresses for endpoint devices. And of course, if the power goes out, I need to provide service to huge numbers of endpoints without spending all of the server's resources re-setting up security associations. Encryption is not necessary. It looks like transport mode AH with aggressive mode IKE is the direction I am heading. I am now trying to connect the ISAKMP id_key_id parameter to my application settings. Somehow get the endpointname == id_key_id, use that to look up the key. In the end, this is a multi-vendor effort, so I must stay within accepted standards yet meet some high performance and simple administration requirements. Eric -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, June 03, 2002 3:59 PM To: Eric Nielsen Cc: 'ipsec@lists.tislabs.com ' Subject: RE: Public Keys to initiate IPsec. Eric, It sounds like you want to assign some name to an app that will be meaningful to folks trying to reach a set of apps, and which can be configured into the SPDs to the clients trying to reach the apps. Presumably this is for IPsec implementations in end systems, not gateways. Is there some way for a client to assert which app it is trying to contact, or is the client restructed to contacting only those apps that are listed in its SPD? Absent one or the other of these measures it seems unlikely that IPsec can control access (from the client perspective) in a meaningful way. You've explained some things about mechanisms constraints, but I'm not sure I understand the security goals of using Ipsec here, which makes it hard to figure out what solutions might be applicable. Steve From owner-ipsec@lists.tislabs.com Tue Jun 4 05:51:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Cpog13754; Tue, 4 Jun 2002 05:51:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26321 Tue, 4 Jun 2002 08:10:46 -0400 (EDT) Date: Tue, 04 Jun 2002 18:23:34 +0800 From: Jerry Yao Subject: A question about Nat traversing To: ipsec_forum Message-id: <003c01c20bb2$07d355d0$0100a8c0@server> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_YnFjJX0YBSkuFFQ0FGM2Jg)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_YnFjJX0YBSkuFFQ0FGM2Jg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT +----+ | | +----+ \ Ari's \ Laptop \ 10.1.2.3 \ +----+ \ / +----+ | |-----+-----------------| | +----+ / \ +----+ Bob's NATDEV Server Laptop 10.1.2.4 what is the outbound SA on Server like? the IP address in the SA is 10.1.2.* or the address of NATDEV. How did the ipsec on Server pick out the SA for Ari and Bob? --Boundary_(ID_YnFjJX0YBSkuFFQ0FGM2Jg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT +----+ | | +----+ \ Ari's \ Laptop \ 10.1.2.3 \ +----+ \ / +----+ | |-----+-----------------| | +----+ / \ +----+ Bob's NATDEV Server Laptop 10.1.2.4 what is the outbound SA on Server like? the IP address in the SA is 10.1.2.* or the address of NATDEV. How did the ipsec on Server pick out the SA for Ari and Bob? --Boundary_(ID_YnFjJX0YBSkuFFQ0FGM2Jg)-- From owner-ipsec@lists.tislabs.com Tue Jun 4 05:56:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Cuhg14482; Tue, 4 Jun 2002 05:56:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26324 Tue, 4 Jun 2002 08:10:49 -0400 (EDT) Message-Id: <200206041143.HAA23300@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-soi-features-01.txt Date: Tue, 04 Jun 2002 07:43:05 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Features of Proposed Successors to IKE Author(s) : P. Hoffman Filename : draft-ietf-ipsec-soi-features-01.txt Pages : Date : 03-Jun-02 This document describes many features of the proposals for the successor to IKEv1. The purpose of the document is to help the IPsec Working Group decide which features they want for the next protocol. The document focuses on how those features are instantiated in two proposals, IKEv2 and JFK, but other ideas for features and options are also included. Most of the material in this document comes from many of the authors of the JFK and IKEv2 proposals. This document is meant to help the Working Group choose which features it finds important for the successor to IKE. It should be short-lived and is not expected to become an RFC. This document is meant to help the Working Group choose which features it finds important for the successor to IKE. It should be short-lived and is not expected to become an RFC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-soi-features-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-soi-features-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-soi-features-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: <20020603125254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-soi-features-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-soi-features-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020603125254.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 4 05:59:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54CxEg14845; Tue, 4 Jun 2002 05:59:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26312 Tue, 4 Jun 2002 08:09:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3.0.3.32.20020602125529.01372aa0@mail> References: <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020602125529.01372aa0@mail> Date: Mon, 3 Jun 2002 18:45:48 -0400 To: Alex Alten From: Stephen Kent Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1188978119==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1188978119==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Alex, > SNIP > > >>I think your argument above is faulty. If I choose to use DNS names >>as a basis for access control decisions, and if I have credentials >>(e.g., certificates) that allow a machine or person to verify that >>the entity at the other end of a key management exchange is the >>entity with the DNS name in question, then I can dynamically bind the >>name to the current address at the time an SA is created and I have >>achieved the access control goals without needing to introduce the >>sort of new ID scheme to which you are alluding. >> >> > >Let's follow your arguement through. I need to establish an IPsec >connection to www.kent.com. It is currently assigned to machine A which >has an address of 200.200.200.1. The next morning the admin decides to >change the DNS entry to point to machine B at 200.200.200.2. Now my >IPsec connection will fail, even though machine A at 200.200.200.1 is >still active! Why? Because the key is residing on A not on B. So using >a cert with a DNS name bound to the key is useless. Any system relying >on it will quickly run into the problem of how do you keep DNS names and >keys in synch across multiple machines. And it is *not* good security >practice to keep transferring private authentication keys (either AES or >RSA) from machine to machine every time a DNS entry changes. It makes a >mockery of using a key to automate the authentication of a particular >machine. So certs are useless, you need the flexibility of reassigning a >new DNS name to A's key! But how can I find the new DNS name for A in order >to get the correct key? To solve this problem, if you don't allow the DNS >name www.kent.com to change to B then you defeat one of the main reasons to >use DNS. A catch-22 results. Therefore PKI certs & DNS don't mix. My experience suggests that your examples are not representative. The DNS names for my personal computers remain constant over time, even across hardware changes. If I had to tran sfer private keys every time I got a new computer to which i would assign the same DNS name, I'd have to do that maybe once every 18-24 months. At that rate, I could easily afford to revoke the old cert and issue a new one, in case security provisions made it hard to transfer private keys from one machine to the next. Also, if I need to authenticate a person, vs. a machine, then I would use of RFC822 address form of name, and implement it in a fashion consistent with personal mobility, e.g., see the SACRED work. So, no, I don't agree with your conclusion above, and I don't think you have provided a convincing example to support that conclusion. >Also, if you require DNS as the ID, then how do we address machines without >a DNS name? To anticipate your answer, then use a cert bound to an IP >address. But even then we still have the problem of dynamically assigned IP >addresses via NAT or DHCP. Again another catch-22 results. If I want to authenticate a person, vs. a machine, I would use a cert with an RFC822 address. If I want to authenticate a machine with no DNS name, then I could use other name forms, even distinguished names. But, to decide what sort of names are needed here, i think you need to provide some good examples of what machines have no DNS names, but I need to authenticate them, so that we can better understand the real problem. >So it turns out that neither DNS nor IP addresses can satisfy our need to be >able to reliably get the proper key needed to start up the IPsec connection. > >I am arguing that the key should be bound to the machine itself, regardless >of it's address(es). The ID I speak of is really a key ID assigned to that >machine, in a sense very similar to a PGP key ID. But with the significant >difference that we assign an ID to the key, rather than generating it from >the key. Key IDs for machines seem useless to me, in isolation. They are meaningless, initially, and one would have to establish a scheme for mapping them to names that we do use and understand, in order to make use of them for access control purposes. As an analogy I have a passport number that uniquely identifies me among all US passport holders, but it is generally useless as an identifier because I am not known by that 9-digit number, to anyone but the State dept., U.S. Immigrations, and the like. But the creation of a mapping of the sort you would need is a tremendous undertaking, and it is not clear how it would be done and how it would be better than the sort of alternatives we were discussing above. > >>To reiterate my position: IPsec needs to have a global, secure >address space >>>that uniquely identifies every participating host. It needs to be simple to >>>understand, distributable, and easy to manage. And it needs to be able to >>>dynamically map into the IP address space on demand, including private >>>network non-routable addresses. >>> >>>That's the requirements as I see them. Anything less than this means >>>you can't use IPsec unencumbered across the Internet. >> >>we don't need a global, secure address space. we need secure means of > >mapping IDs to credentials, and mapping those IDs to SA, in real >>time, as you note immediately above. These two notions are not the >>same. >> > >Right, I had already agreed with Ken Brown earlier that global and secure are >not required. However global would simplify the problem significantly. In >fact I would argue it would be almost impossible to build a world-wide system >among many organizations using IPsec otherwise. Secure doesn't actually make >sense since the ID is being used to bootstrap getting the key. So the ID >cannot be secure in and of itself. The IPsec system must be able to carefully >bootstrap from an insecure state to a secure state. Absent a better definition of "secure" I can't tell what you mean here. Steve --============_-1188978119==_ma============ Content-Type: text/html; charset="us-ascii" Alex, > SNIP >> >>I think your argument above is faulty. If I choose to use DNS names >>as a basis for access control decisions, and if I have credentials >>(e.g., certificates) that allow a machine or person to verify that >>the entity at the other end of a key management exchange is the >>entity with the DNS name in question, then I can dynamically bind the >>name to the current address at the time an SA is created and I have >>achieved the access control goals without needing to introduce the >>sort of new ID scheme to which you are alluding. >> >> > >Let's follow your arguement through. I need to establish an IPsec >connection to www.kent.com. It is currently assigned to machine A which >has an address of 200.200.200.1. The next morning the admin decides to >change the DNS entry to point to machine B at 200.200.200.2. Now my >IPsec connection will fail, even though machine A at 200.200.200.1 is >still active! Why? Because the key is residing on A not on B. So using >a cert with a DNS name bound to the key is useless. Any system relying >on it will quickly run into the problem of how do you keep DNS names and >keys in synch across multiple machines. And it is *not* good security >practice to keep transferring private authentication keys (either AES or >RSA) from machine to machine every time a DNS entry changes. It makes a >mockery of using a key to automate the authentication of a particular >machine. So certs are useless, you need the flexibility of reassigning a >new DNS name to A's key! But how can I find the new DNS name for A in order >to get the correct key? To solve this problem, if you don't allow the DNS >name www.kent.com to change to B then you defeat one of the main reasons to >use DNS. A catch-22 results. Therefore PKI certs & DNS don't mix. My experience suggests that your examples are not representative. The DNS names for my personal computers remain constant over time, even across hardware changes. If I had to tran sfer private keys every time I got a new computer to which i would assign the same DNS name, I'd have to do that maybe once every 18-24 months. At that rate, I could easily afford to revoke the old cert and issue a new one, in case security provisions made it hard to transfer private keys from one machine to the next. Also, if I need to authenticate a person, vs. a machine, then I would use of RFC822 address form of name, and implement it in a fashion consistent with personal mobility, e.g., see the SACRED work. So, no, I don't agree with your conclusion above, and I don't think you have provided a convincing example to support that conclusion. >Also, if you require DNS as the ID, then how do we address machines without >a DNS name? To anticipate your answer, then use a cert bound to an IP >address. But even then we still have the problem of dynamically assigned IP >addresses via NAT or DHCP. Again another catch-22 results. If I want to authenticate a person, vs. a machine, I would use a cert with an RFC822 address. If I want to authenticate a machine with no DNS name, then I could use other name forms, even distinguished names. But, to decide what sort of names are needed here, i think you need to provide some good examples of what machines have no DNS names, but I need to authenticate them, so that we can better understand the real problem. >So it turns out that neither DNS nor IP addresses can satisfy our need to be >able to reliably get the proper key needed to start up the IPsec connection. > >I am arguing that the key should be bound to the machine itself, regardless >of it's address(es). The ID I speak of is really a key ID assigned to that >machine, in a sense very similar to a PGP key ID. But with the significant >difference that we assign an ID to the key, rather than generating it from >the key. Key IDs for machines seem useless to me, in isolation. They are meaningless, initially, and one would have to establish a scheme for mapping them to names that we do use and understand, in order to make use of them for access control purposes. As an analogy I have a passport number that uniquely identifies me among all US passport holders, but it is generally useless as an identifier because I am not known by that 9-digit number, to anyone but the State dept., U.S. Immigrations, and the like. But the creation of a mapping of the sort you would need is a tremendous undertaking, and it is not clear how it would be done and how it would be better than the sort of alternatives we were discussing above. >>>To reiterate my position: IPsec needs to have a global, secure address space >>>that uniquely identifies every participating host. It needs to be simple to >>>understand, distributable, and easy to manage. And it needs to be able to >>>dynamically map into the IP address space on demand, including private >>>network non-routable addresses. >>> >>>That's the requirements as I see them. Anything less than this means >>>you can't use IPsec unencumbered across the Internet. >> >>we don't need a global, secure address space. we need secure means of >>mapping IDs to credentials, and mapping those IDs to SA, in real >>time, as you note immediately above. These two notions are not the >>same. >> > >Right, I had already agreed with Ken Brown earlier that global and secure are >not required. However global would simplify the problem significantly. In >fact I would argue it would be almost impossible to build a world-wide system >among many organizations using IPsec otherwise. Secure doesn't actually make >sense since the ID is being used to bootstrap getting the key. So the ID >cannot be secure in and of itself. The IPsec system must be able to carefully >bootstrap from an insecure state to a secure state. Absent a better definition of "secure" I can't tell what you mean here. Steve --============_-1188978119==_ma============-- From owner-ipsec@lists.tislabs.com Tue Jun 4 07:15:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54EFtg19697; Tue, 4 Jun 2002 07:15:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26563 Tue, 4 Jun 2002 09:34:48 -0400 (EDT) Message-ID: From: "DesJardins, Nisan" To: "'ipsec@lists.tislabs.com'" Subject: Remove from Email List Date: Tue, 4 Jun 2002 09:49:32 -0400 Importance: high X-Priority: 1 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 wish to be removed from the email list. Thanks From owner-ipsec@lists.tislabs.com Tue Jun 4 09:10:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54GA8g29132; Tue, 4 Jun 2002 09:10:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26865 Tue, 4 Jun 2002 11:22:56 -0400 (EDT) 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: <15612.56881.690370.239486@ryijy.hel.fi.ssh.com> Date: Tue, 4 Jun 2002 18:35:13 +0300 From: Tero Kivinen To: "'Eric Nielsen'" , andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk"), Subject: Re: addresses and IKEv2 References: <000c01c20b48$5a2a07d0$1e72788a@ca.alcatel.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes: > Yes, this is an important case. Currently we perform this check during SA > establishment. Doing it via a user mode callback could be a much more > expensive proposition, especially if someone got their hands on a captured > packet and started replaying it from thousands of different IPs. Note, that only first of those packets is valid, all others fail the replay check, and are discarded, thus the callback would be called only once for all those replayed packet. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 4 09:10:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54GACg29143; Tue, 4 Jun 2002 09:10:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26887 Tue, 4 Jun 2002 11:32:02 -0400 (EDT) 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: <15612.57427.387953.974582@ryijy.hel.fi.ssh.com> Date: Tue, 4 Jun 2002 18:44:19 +0300 From: Tero Kivinen To: Eric.Nielsen@sylantro.com ("Eric Nielsen"), "Stephen Kent" , Subject: Re: Public Keys to initiate IPsec. References: <79FEAA5FABA7D411BF580001023D1BBD0174ABA7@mailserver.sylantro.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric.Nielsen@sylantro.com ("Eric Nielsen") writes: > And of course, if the power goes out, I need to provide > service to huge numbers of endpoints without spending > all of the server's resources re-setting up security > associations. Easiest way is to store SA information to some kind of stable storage, meaning on disk, on flash etc. How often you back them up to the stable storage affects how much work you need to do when the power goes down... You most likely need to have some kind of stable storage on the device anyways for the logs, accounting and that kind of things. The only problematic issues is the replay counters, as you do not want to write stuff to stable storage every time the replay counter is changed. One option is to take the new replay counter value from the first packet received that is bigger than the value in the stable storage, and accept that you could be accepting few replayed packets after reset (which should not be so often). For IKEv1 there is not really that problem, as it does not have replay counters. IKEv2 SAs there is sequence number, but if you have IKEv2 exchange going on during the reset, then that state is most likely gone, and the other end will timeout and restart the IKEv2 phase 1 from the beginning. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 4 09:23:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54GNWg29551; Tue, 4 Jun 2002 09:23:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26908 Tue, 4 Jun 2002 11:41:03 -0400 (EDT) To: DesJardinsN@plymart.com Cc: ipsec@lists.tislabs.com Date: Tue, 4 Jun 2002 11:52:10 -0400 Subject: Re: Remove from Email List Message-ID: <20020604.115211.1644.5.paul.a.ford@juno.com> X-Mailer: Juno 5.0.33 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0,2-5 From: Paul A Ford Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I also wish to be removed from the email list. On Tue, 4 Jun 2002 09:49:32 -0400 "DesJardins, Nisan" writes: > I wish to be removed from the email list. > > Thanks > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-ipsec@lists.tislabs.com Tue Jun 4 10:02:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54H2Gg00791; Tue, 4 Jun 2002 10:02:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27017 Tue, 4 Jun 2002 12:23:38 -0400 (EDT) Date: Tue, 4 Jun 2002 19:29:19 +0400 From: Eugene Lisovy <4rester@aikon.com.ua> X-Mailer: The Bat! (v1.60c) Reply-To: Eugene Lisovy <4rester@aikon.com.ua> Organization: Aikon Service X-Priority: 3 (Normal) Message-ID: <18527164227.20020604192919@aikon.com.ua> To: "'ipsec @ lists . tislabs . com'" Subject: Remove from Email List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wish to be removed from the email list. From owner-ipsec@lists.tislabs.com Tue Jun 4 10:19:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54HJ5g01453; Tue, 4 Jun 2002 10:19:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27078 Tue, 4 Jun 2002 12:42:48 -0400 (EDT) Date: Tue, 4 Jun 2002 12:55:04 -0400 From: "Theodore Ts'o" To: Paul A Ford Cc: DesJardinsN@plymart.com, ipsec@lists.tislabs.com Subject: Re: Remove from Email List Message-ID: <20020604165504.GA819@think.thunk.org> References: <20020604.115211.1644.5.paul.a.ford@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020604.115211.1644.5.paul.a.ford@juno.com> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jun 04, 2002 at 11:52:10AM -0400, Paul A Ford wrote: > I also wish to be removed from the email list. > On Tue, 4 Jun 2002 09:49:32 -0400 "DesJardins, Nisan" > writes: > > I wish to be removed from the email list. As a reminder to everyone --- like many mailing lists on the Internet, the IPSEC mailing list uses the standard internet conventions that the administration address for the mailing list foo-list@host.domain is foo-list-request@host.domain. In this case, the IPSEC mailing list is run using majordomo, so sending mail to ipsec-request@lists.tislabs.com with the word "unsubscribe" in the message body will do the trick. In general, the other part of the standard internet mailing convention is that it is very bad form to send e-mail to the mailing list asking to be removed from the list. This only annoys the hundreds of peoeple on the mailing list who can't help you, and proves that you don't know how to help yourself. Just a word to the wise, if you don't want to be seen as a clueless internet newbie.... - Ted From owner-ipsec@lists.tislabs.com Tue Jun 4 12:47:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54Jl3g08423; Tue, 4 Jun 2002 12:47:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27416 Tue, 4 Jun 2002 15:04:58 -0400 (EDT) Message-Id: <3.0.3.32.20020604122011.015abda8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 04 Jun 2002 12:20:11 -0700 To: Stephen Kent From: Alex Alten Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20020602125529.01372aa0@mail> <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020602125529.01372aa0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Whom are you kidding? Just because *you* don't change a DNS name bound to a machine for 18 months doesn't mean that Yahoo doesn't on-the-fly direct your HTTP post to one of 50 different servers depending on query loads, etc. When one designs a system one has to account for many types of usage. But at the same time you have to decide what to not support. For example should IPsec identify either a user or a host? I would argue that only a host, and possibly a port, should be identified, since IPsec is operating between the routing and transport layers. For you it may be simple to juggle multiple types of addresses (DNS, IP, email, whatever). But to establish and manage IPsec sessions reliably across millions of machines and tens of thousands of organizations, day after day, year in and year out, with software written by hundred's of protocol programmers in many companies and countries, is in practice a nightmare. It took 3 years for the industry to be able to interoperate with 3DES, some firms had to go through certification half a dozen times. Is that what you want the industry to go through again by requiring multiple ways of addressing hosts? To be successful, IPsec needs a simple way to retrieve the key that actually does the work of authenticating the host. Neither DNS nor IP address are designed to do this well, they do their respective existing jobs only too well. Neither an IP address nor a DNS name will work because they are too ephemeral. Binding them into a certificate is just a snapshot of a transient address to host key binding. All it does is introduce more complexity, with certs littered about containing outdated host addresses, not to mention yet another interoperability headache with certificate authorities, revocation lists, etc. BTW, quit asking for a definition of "security". You know damn well it's self referential. It's like asking for a definition of "money" or "time". For that matter, so is the definition of an IPsec host "address". - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Tue Jun 4 12:54:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54JsEg08693; Tue, 4 Jun 2002 12:54:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27448 Tue, 4 Jun 2002 15:18:00 -0400 (EDT) Message-Id: <200206041403.KAA29149@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: On the Use of SCTP with IPsec to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 04 Jun 2002 10:03:49 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider On the Use of SCTP with IPsec as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 18, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-03.txt From owner-ipsec@lists.tislabs.com Tue Jun 4 13:37:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54KbPg10132; Tue, 4 Jun 2002 13:37:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27553 Tue, 4 Jun 2002 15:57:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200206041143.HAA23300@ietf.org> References: <200206041143.HAA23300@ietf.org> Date: Tue, 4 Jun 2002 13:10:18 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: I-D ACTION:draft-ietf-ipsec-soi-features-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Only a very small number of people have posted to the list what they think they need for the successor-to-IKE protocol. This new draft incorporates pointers to the "need to think about" items in the scenarios in Cheryl's requirements document. The idea here is to help stimulate discussion so we can reach closure on the required features. Surely, more people than the samll handful who have commented so far must have strong views on what they need/want from successor-to-IKE. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 4 14:18:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54LIDg11376; Tue, 4 Jun 2002 14:18:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27619 Tue, 4 Jun 2002 16:39:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3.0.3.32.20020604122011.015abda8@mail> References: <3.0.3.32.20020602125529.01372aa0@mail> <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail> <3.0.3.32.20020602125529.01372aa0@mail> <3.0.3.32.20020604122011.015abda8@mail> Date: Tue, 4 Jun 2002 16:52:26 -0400 To: Alex Alten From: Stephen Kent Subject: Re: addresses and IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, >Steve, > >Whom are you kidding? Just because *you* don't change a DNS name bound >to a machine for 18 months doesn't mean that Yahoo doesn't on-the-fly >direct your HTTP post to one of 50 different servers depending on query >loads, etc. When one designs a system one has to account for many >types of usage. But at the same time you have to decide what to not >support. For example should IPsec identify either a user or a host? >I would argue that only a host, and possibly a port, should be >identified, since IPsec is operating between the routing and transport >layers. I could easily ask who do you think YOU are kidding with a claim that a new globally unique ID scheme for computers is either needed of feasible. I don't care to which Yahoo machine I connect. I care only that the machine represents Yahoo, period. And, if one wanted to use IPsec for HTTP (vs. SSL) many folks have suggested that the right answer is to terminate the SAs at a load balancer in front of the servers, not within each server. The argument about what granularity of authentication IPsec should provide is an old one on this list. if I have a single user system, then the mapping from machine to person is 1-1 at any time and thus is makes as much sense to authenticate the person as the machine. There is no human being layer in the TCP/IP stack, or in the OSI model. It may be desirable to use higher layer authentication for identifying individuals in some cases, but it's quite reasonable to perform this authentication at the lowest layer offering an end-to-end service, i.e., the IP layer, when the machine where the SA terminates is under the control of a single user. >For you it may be simple to juggle multiple types of addresses (DNS, IP, >email, whatever). But to establish and manage IPsec sessions reliably >across millions of machines and tens of thousands of organizations, day >after day, year in and year out, with software written by hundred's of >protocol programmers in many companies and countries, is in practice a >nightmare. It took 3 years for the industry to be able to interoperate >with 3DES, some firms had to go through certification half a dozen times. >Is that what you want the industry to go through again by requiring >multiple ways of addressing hosts? To be successful, IPsec needs a simple >way to retrieve the key that actually does the work of authenticating the >host. Neither DNS nor IP address are designed to do this well, they do >their respective existing jobs only too well. Most of the preceding commentary is completely irrelevant to our discussion. But, what you seem to be proposing is to embark on the creation of a new class of IDs for machines that, by themselves, have no utility in managing access, since they are not meaningful to the people who have to manage all of this. It seem to me that your vague proposal flies in the face of the management concerns you allude to above. >Neither an IP address nor a DNS name will work because they are too >ephemeral. Binding them into a certificate is just a snapshot of a >transient address to host key binding. All it does is introduce more >complexity, with certs littered about containing outdated host addresses, >not to mention yet another interoperability headache with certificate >authorities, revocation lists, etc. In the vast majority of cases we don't care which machine is being used to connect anywhere. We care about the binding of the machine to a human user or some sort of an organizational affiliation. That's what various forms of IDs, managed at levels higher that machine IDs and address, do for us. >BTW, quit asking for a definition of "security". You know damn well it's >self referential. It's like asking for a definition of "money" or "time". > >For that matter, so is the definition of an IPsec host "address". I don't recall asking you what security meant. The reason for asking Eric was to determine what the underlying requirement are in terms of standard security services (confidentiality, integrity, authentication, access control, ...) so that I could better understand what Eric was looking for. If you think security is an undefinable term, maybe that explains why you are unable to articulate a clear reason for the form of ID you believe is needed. Steve From owner-ipsec@lists.tislabs.com Tue Jun 4 14:18:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54LIDg11377; Tue, 4 Jun 2002 14:18:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27620 Tue, 4 Jun 2002 16:39:42 -0400 (EDT) Message-ID: <6F0AA176DA68704884B7507AE6907E18081836@snake012.odetics.com> From: Christina Helbig To: "'Eric Nielsen'" , Stephen Kent Cc: "'ipsec@lists.tislabs.com '" Subject: RE: Public Keys to initiate IPsec. Date: Tue, 4 Jun 2002 13:51:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric, I understand that you like to setup IPSec SAs for pairs of identities (server name, endpoint name). In my opinion, this it not what RFC 2705 means with using IPSec for MGCP. There you need really the IP addresses to build SAs and you get secure IP links. The next open question for me is, do you like to secure IP packets or MGCP commands and responses? You wrote, that the endpoint name is in the header of MGCP messages, but is the endpoint name in the payload of every IP packet? If not, there is no way to lookup the SA from outbound IP packets with help of this endpoint name. So, it looks like you want to adapt IPSec to the MGCP application layer. This should be possible, but is this "stay with accepted standards"? Please correct me, if I understand you wrong. Christina > -----Original Message----- > From: Eric Nielsen [mailto:Eric.Nielsen@sylantro.com] > Sent: Monday, June 03, 2002 6:37 PM > To: Stephen Kent > Cc: 'ipsec@lists.tislabs.com ' > Subject: RE: Public Keys to initiate IPsec. > > > Steve, > > We build a call control application using MGCP. > IPsec is the standard for securing MGCP in RFC 2705. > The RFC says nothing about what that really means. > > Our call control agent receives only MGCP on specific > UDP ports. Each MGCP endpoint has a name, similar to > a SIP URI. The name is the key to all actions that > are invoked, what keys are used, etc. > > The endpoint name is in the header of MGCP message, > but I need to relate it to the secure communications. > I cannot allow one trusted endpoint to spoof another, > and I cannot control IP addresses for endpoint devices. > > And of course, if the power goes out, I need to provide > service to huge numbers of endpoints without spending > all of the server's resources re-setting up security > associations. > > Encryption is not necessary. It looks like transport > mode AH with aggressive mode IKE is the direction I am > heading. I am now trying to connect the ISAKMP id_key_id > parameter to my application settings. Somehow get the > endpointname == id_key_id, use that to look up the key. > > In the end, this is a multi-vendor effort, so I must stay > within accepted standards yet meet some high performance > and simple administration requirements. > > Eric > > > > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, June 03, 2002 3:59 PM > To: Eric Nielsen > Cc: 'ipsec@lists.tislabs.com ' > Subject: RE: Public Keys to initiate IPsec. > > > Eric, > > It sounds like you want to assign some name to an app that will be > meaningful to folks trying to reach a set of apps, and which can be > configured into the SPDs to the clients trying to reach the apps. > Presumably this is for IPsec implementations in end systems, not > gateways. Is there some way for a client to assert which app it is > trying to contact, or is the client restructed to contacting only > those apps that are listed in its SPD? Absent one or the other of > these measures it seems unlikely that IPsec can control access (from > the client perspective) in a meaningful way. You've explained some > things about mechanisms constraints, but I'm not sure I understand > the security goals of using Ipsec here, which makes it hard to figure > out what solutions might be applicable. > > > Steve > From owner-ipsec@lists.tislabs.com Tue Jun 4 14:41:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54LfFg11816; Tue, 4 Jun 2002 14:41:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27655 Tue, 4 Jun 2002 16:58:50 -0400 (EDT) Date: 4 Jun 2002 16:59:54 -0400 Message-ID: <003c01c20c0a$c86f0340$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Tero Kivinen'" , " 'list'" Subject: RE: addresses and IKEv2 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15612.56881.690370.239486@ryijy.hel.fi.ssh.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Note, that only first of those packets is valid, all others fail the > replay check, and are discarded, thus the callback would be called > only once for all those replayed packet. Well, maybe, assuming you have anti-replay protection on and you have implemented it in the manner suggested by the RFC (there are other reasonable ways of doing it that are not RFC compliant). But even so, when you receive a valid IPsec packet from a bogus IP, what are you supposed to do? The RFC says that you must not update the receive window until you have integrity-checked the packet. This appears to be a valid packet with a spoofed IP. If it is really spoofed then we may receive a duplicate packet with a valid IP at some point. So what is the best course of action? a) Discard the packet and update the receive window. b) Process the packet as if it came from the original IP and update the receive window. c) Discard the packet and don't update the receive window. I'm assuming that this is a transport mode packet, so the outer IP does matter. 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: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Tuesday, June 04, 2002 11:35 AM > To: 'Eric Nielsen'; "Andrew Krywaniuk"; ipsec@lists.tislabs.com > Subject: Re: addresses and IKEv2 > > > andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes: > > Yes, this is an important case. Currently we perform this > check during SA > > establishment. Doing it via a user mode callback could be a > much more > > expensive proposition, especially if someone got their > hands on a captured > > packet and started replaying it from thousands of different IPs. > > Note, that only first of those packets is valid, all others fail the > replay check, and are discarded, thus the callback would be called > only once for all those replayed packet. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Tue Jun 4 15:07:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54M7Dg12321; Tue, 4 Jun 2002 15:07:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27772 Tue, 4 Jun 2002 17:30:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD0174ABA7@mailserver.sylantro.com> References: <79FEAA5FABA7D411BF580001023D1BBD0174ABA7@mailserver.sylantro.com> Date: Tue, 4 Jun 2002 17:41:38 -0400 To: "Eric Nielsen" From: Stephen Kent Subject: RE: Public Keys to initiate IPsec. Cc: "'ipsec@lists.tislabs.com '" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:37 PM -0700 6/3/02, Eric Nielsen wrote: >Steve, > >We build a call control application using MGCP. >IPsec is the standard for securing MGCP in RFC 2705. >The RFC says nothing about what that really means. > >Our call control agent receives only MGCP on specific >UDP ports. Each MGCP endpoint has a name, similar to >a SIP URI. The name is the key to all actions that >are invoked, what keys are used, etc. I suggest you put that name in a cert and use it to make access control decisions in the SPD. presumably you can make it into a DN. >The endpoint name is in the header of MGCP message, >but I need to relate it to the secure communications. >I cannot allow one trusted endpoint to spoof another, >and I cannot control IP addresses for endpoint devices. This sounds like a problem re using IPsec. After establishing an SA, we check inbound traffic on the SA (from the peer) to make sure it is consistent with the parameters for the SA. We can check only the 5 fields that are defined as traffic selectors. So, you could be spoofed by a peer who authenticates as one MGCP endpoint ID, then sends a message with a different MGCP name in the MCGP message. This is outside the realm of what IPsec can do for you. You would have to remember the MGCP name from the SA establishment for later application layer checking, and there is no standard interface that passes that info to your application. >And of course, if the power goes out, I need to provide >service to huge numbers of endpoints without spending >all of the server's resources re-setting up security >associations. If who's power goes out? If you SA lose state at our end you have no option but to reestablish the SAs, and that takes time. Perhaps a UPS is a good investment here :-). >Encryption is not necessary. It looks like transport >mode AH with aggressive mode IKE is the direction I am >heading. I am now trying to connect the ISAKMP id_key_id >parameter to my application settings. Somehow get the >endpointname == id_key_id, use that to look up the key. Frankly, we're trying to get rid of AH in general, and certainly for this sort of use. ESP in integrity only mode will provide better performance and the same set of secruity services. >In the end, this is a multi-vendor effort, so I must stay >within accepted standards yet meet some high performance >and simple administration requirements. > the hardest part probably is the issuing of certs to your peers, and I don't know enough about the context to be able to say how easy or hard that is. in general you can boot strap cert issuance over any initial authentication mechanism you deem suitable for your application context. Steve From owner-ipsec@lists.tislabs.com Tue Jun 4 16:21:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g54NLJg14002; Tue, 4 Jun 2002 16:21:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27919 Tue, 4 Jun 2002 18:37:52 -0400 (EDT) Date: 4 Jun 2002 18:38:59 -0400 Message-ID: <004201c20c18$9f303400$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Thomas'" , " 'list'" Subject: RE: SOI schizophrenia 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15586.62572.905659.469261@thomasm-u1.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > To a degree I agree about Andrew's observation > about the devil we know, but what I think often > gets lost in this mostly-VPN-centric group is that > IKE -- and I'm afraid IKEv2 as well -- is large, My comment about the devil we know is not just a general purpose aphorism. IKE is a widely deployed protocol with a number of well-known use cases. It is true that IKE was mostly developed by VPN vendors, but then again, they did their best to accomodate the host to host case. When someone proposes an alternative that doesn't address the use cases we already have (not to mention the ones we can foresee), but punts them off to some unspecified future protocol, it is not much of an alternative. JFK says that "[X and Y and Z] should be accomplished by protocols defined for that purpose. By excluding these protocols for JFK, we can exclude them from our security analysis." This strikes me as a bit disingenuous. In practice, I can choose to exclude whatever features I want from my security analysis. I could state that "Authentication should be accomplished by a protocol defined for that purpose. By excluding authentication from our key agreement protocol, we can exclude it from our analysis." To an untrained eye, that text doesn't look any less reasonable than the quoted text from [JFK]. My point is that the determination of what features impact what other features cannot be divorced from common sense. Separating every feature into its own protocol doesn't necessarily make the analysis simpler, nor does it necessarily make your code size smaller. (I recall hearing comments at the last MSec meeting about the decision to separate GDOI from rekeying being a mistake.) We have to rely on human judgement to assess whether features X and Y interact, and this will usually be independent of whether they are implemented together or as separate protocols. IMHO, the easiest way to simplify your analysis is to refer to an unspecified protocol TBD. You can call this my golden rule of protocol analysis. Any protocol that doesn't currently exist is always simpler than all existing alternatives. (Also, redesigning this software module from scratch will be easier than fixing it, and if we redesign our "process" then our projects will be completed on time, etc) To return to my original thread, IKE has been widely deployed in remote access scenarios, mostly using the pseudo-standard Config Mode protocol. JFK was specifically designed to rule out any heretic vendor extensions such as these. But even if one uses the IESG-sanctioned DHCPv4 Configuration of IPsec Tunnel Mode (which was no doubt excluded from the analysis), it is not clear how to proceed. I imagine you do one JFK exchange with IP=0.0.0.0 then another JFK exchange with your DHCP-assigned address, and then a third JFK exchange to delete the SA to 0.0.0.0. (Either that, or there will be a new protocol TBD for secure DHCP address assignment.) I find it ironic that one of the driving factors behind the development of JFK was to reduce the number of round trips, and yet if you compare today's deployed remote access clients to a proposed solution doing PIC + (3 x JFK), you find that the number of roundtrips has actually increased dramatically. Is this we call progress? 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 Michael Thomas > Sent: Wednesday, May 15, 2002 7:51 PM > To: ipsec@lists.tislabs.com > Subject: SOI schizophrenia > > > > I admit it. I'm having a real hard time deciding > which design philosophy is actually more > appropriate for SOI. I've vacillated quite a few > times and it doesn't seem like it's about to abate > any time soon. What Paul's document tells me > (which pretty jibes with my own judgement) is that > both protocols are vast improvements over IKE, and > they seem to reach quite similar conclusions on > the basic message exchanges. Both put effort into > DoS, and simplify the on-wire combinatorial > explosion of SA establishment. All in all, they > both seem competent. > > While Paul points out some of the differences in > design choices such as quick mode, pre-shared > keys, etc, what it seems to me that makes this so > difficult is that there are two different design > philosophies at work here: > > 1) Lean, compact public key identity keying (JFK) > 2) General purpose (IKEv2) > > To a degree I agree about Andrew's observation > about the devil we know, but what I think often > gets lost in this mostly-VPN-centric group is that > IKE -- and I'm afraid IKEv2 as well -- is large, > and difficult to put into cheap, embedded > devices. This isn't usually an issue for the > windoze-VPN-to-corporate-edge, but IKE's size is a > pretty hard sell for little widgets with > constrained memory footprints. I've heard all the > arguments about how the hardware folks are being > unreasonable (and heck, beating up on hardware > folks is just clean fun anyway), but I'm not > overstating the difficulty. > > So from that standpoint, JFK's hardline stand on > limiting complexity and creature feep is > heartening. I've done some experiements writing a > JFK-like protocol (same in spirit, slightly > different wire format) using raw public key > identities and the results are very heartening; if > the memory police balk at its size, they are just > being obstructionist. This is implementable; no > excuses. Thus for simple widgets which operate in > star topologies to a few well known servers where > the traffic needs transport mode IPsec, JFK is > quite attractive. Maybe other uses too. > > On the other hand, VPN's do add a lot of > complexity, and I think that JFK understates > that complexity. While some of that complexity is > certainly gratuitous, I think that there's an > unspoken truth here: VPN's are fundamentally more > complicated than point to point transport mode > SA's, and they drag all kinds of crufty legacy > junk into the mix like legacy authentication, > autoconfiguration, and all the rest. Is it needed? > At some level of course it's "needed"; I doubt > many of us are here for the shear fun of making > Frankenprotocols. > > So what to do? What to choose? I'm at a loss. We > could flip a coin to decide the pre-shared and QM > debate, but what I don't see is how to preseve the > different design philosophies which appeal > differently to different audiences. Specifically, > I'm having a real hard time seeing how we can have > a single lean unbloated protocol like JFK without > specific bloat-resistant design constraints... > which violates the VPN desire for generality at > the expense of simplicity and footprint. > > Time for some more shock therapy, I guess. > > Mike > From owner-ipsec@lists.tislabs.com Tue Jun 4 17:00:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5500dg15017; Tue, 4 Jun 2002 17:00:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28092 Tue, 4 Jun 2002 19:19:28 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.19960.911915.806008@thomasm-u1.cisco.com> Date: Tue, 4 Jun 2002 16:32:08 -0700 (PDT) To: Stephen Kent Cc: "Eric Nielsen" , "'ipsec@lists.tislabs.com '" Subject: RE: Public Keys to initiate IPsec. In-Reply-To: References: <79FEAA5FABA7D411BF580001023D1BBD0174ABA7@mailserver.sylantro.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 Stephen Kent writes: > This sounds like a problem re using IPsec. After establishing an SA, > we check inbound traffic on the SA (from the peer) to make sure it is > consistent with the parameters for the SA. We can check only the 5 > fields that are defined as traffic selectors. So, you could be > spoofed by a peer who authenticates as one MGCP endpoint ID, then > sends a message with a different MGCP name in the MCGP message. This > is outside the realm of what IPsec can do for you. You would have to > remember the MGCP name from the SA establishment for later > application layer checking, and there is no standard interface that > passes that info to your application. This is why I keep saying that it would be rilly, rilly nice to have this interface from the kernel (ideally, but could be with the keying daemon too). Nor do I see this as "outside" of what IPsec can do for you in the sense you seem to be using "outside". It's a missing feature on what my kernel/key daemon can do for me. There's nothing *wrong* with sending the credentials associated with a particular message up the stack. I'm just about ornery enough hack this into our Altiga shim just to prove it can be done and is -- ta da -- useful for all of the reasons that Eric brought up. Mike From owner-ipsec@lists.tislabs.com Tue Jun 4 19:43:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g552hVg18414; Tue, 4 Jun 2002 19:43:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28537 Tue, 4 Jun 2002 21:58:13 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15613.29516.535881.627524@thomasm-u1.cisco.com> Date: Tue, 4 Jun 2002 19:11:24 -0700 (PDT) To: andrew.krywaniuk@alcatel.com Cc: "'Michael Thomas'" , " 'list'" Subject: RE: SOI schizophrenia In-Reply-To: <004201c20c18$9f303400$1e72788a@ca.alcatel.com> References: <15586.62572.905659.469261@thomasm-u1.cisco.com> <004201c20c18$9f303400$1e72788a@ca.alcatel.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 Andrew Krywaniuk writes: > > > To a degree I agree about Andrew's observation > > about the devil we know, but what I think often > > gets lost in this mostly-VPN-centric group is that > > IKE -- and I'm afraid IKEv2 as well -- is large, > > My comment about the devil we know is not just a general purpose aphorism. > IKE is a widely deployed protocol with a number of well-known use cases. It > is true that IKE was mostly developed by VPN vendors, but then again, they > did their best to accomodate the host to host case. When someone proposes an > alternative that doesn't address the use cases we already have (not to > mention the ones we can foresee), but punts them off to some unspecified > future protocol, it is not much of an alternative. Andrew, "Alternate" also involves things whose keying solution is currently the null set. As currently instantiated, it will almost certainly remain the null set for a long time to come for many cheap devices unless we do something about the heft of IKE. What is their alternative? That's why I think the generally JFK proposition of keeping things simple has merit; it can be aimed at a class of problem that _doesn't_ have a viable alternative. To date, IKEv2's focus has been fixing many problems, but its general direction has also been to add new features too. I don't have an issue with that, fwiw, so long as the problems have been generalized, but it flies pretty much in the face of the desire for simplicity. > JFK says that "[X and Y and Z] should be accomplished by protocols defined > for that purpose. By excluding these protocols for JFK, we can exclude them > from our security analysis." This strikes me as a bit disingenuous. It could be disingenuous if it just postpones a necessary requirement for _any_ protocol for which there isn't a ready answer elsewhere. I don't really see this as going on here: if you want public key based IPsec SA establishment, JFK or something very close to JFK is sufficient and does not require external protocols. True, it's not a forklift replacement for the current IKE, but then again, I didn't sense that that was the authors intent. Which is why I brought this all up: is there really two different problem spaces here? > My point is that the determination of what features impact what other > features cannot be divorced from common sense. Separating every feature into > its own protocol doesn't necessarily make the analysis simpler, nor does it > necessarily make your code size smaller. Of course we don't want balkanized standards here, but that doesn't mean we need a *single* standard either, especially when that single standard isn't a viable choice for a potentially large user base. > IMHO, the easiest way to simplify your analysis is to refer to an > unspecified protocol TBD. You can call this my golden rule of protocol > analysis. Any protocol that doesn't currently exist is always simpler than > all existing alternatives. (Also, redesigning this software module from > scratch will be easier than fixing it, and if we redesign our "process" then > our projects will be completed on time, etc) FWIW, I've actually written something that really keys real SA's using something that looks a great deal like JFK. It works. It's really small. As in no excuses small. So, I don't think this is quite as much vaporware as your letting on here. > To return to my original thread, IKE has been widely deployed in remote > access scenarios, mostly using the pseudo-standard Config Mode protocol. JFK > was specifically designed to rule out any heretic vendor extensions such as > these. Uh, it's using TLV's. Naughtiness is just an unassigned TLV type away. > But even if one uses the IESG-sanctioned DHCPv4 Configuration of > IPsec Tunnel Mode (which was no doubt excluded from the analysis), it is not > clear how to proceed. I imagine you do one JFK exchange with IP=0.0.0.0 then > another JFK exchange with your DHCP-assigned address, and then a third JFK > exchange to delete the SA to 0.0.0.0. (Either that, or there will be a new > protocol TBD for secure DHCP address assignment.) This assumes that JFK has to be The substitute for remote access. What if we just say it isn't? Heck, what if we say it's just for transport only! My entire point was that maybe bifurcation of the problem space is warrented, essentially split down the lines of "remote access/security gateways" and "host-host SA's." Mike From owner-ipsec@lists.tislabs.com Wed Jun 5 06:32:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g55DWUg09363; Wed, 5 Jun 2002 06:32:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29974 Wed, 5 Jun 2002 08:23:27 -0400 (EDT) Message-ID: From: "DesJardins, Nisan" To: "'Paul A Ford'" , "DesJardins, Nisan" Cc: ipsec@lists.tislabs.com Subject: RE: Remove from Email List Date: Tue, 4 Jun 2002 13:15:59 -0400 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 reminder to everyone --- like many mailing lists on the Internet, the IPSEC mailing list uses the standard internet conventions that the administration address for the mailing list foo-list@host.domain is foo-list-request@host.domain. In this case, the IPSEC mailing list is run using majordomo, so sending mail to ipsec-request@lists.tislabs.com with the word "unsubscribe" in the message body will do the trick. -----Original Message----- From: Paul A Ford [mailto:paul.a.ford@juno.com] Sent: Tuesday, June 04, 2002 11:52 AM To: DesJardinsN@plymart.com Cc: ipsec@lists.tislabs.com Subject: Re: Remove from Email List I also wish to be removed from the email list. On Tue, 4 Jun 2002 09:49:32 -0400 "DesJardins, Nisan" writes: > I wish to be removed from the email list. > > Thanks > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-ipsec@lists.tislabs.com Wed Jun 5 06:32:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g55DWUg09362; Wed, 5 Jun 2002 06:32:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00036 Wed, 5 Jun 2002 08:31:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 4 Jun 2002 19:01:49 -0400 To: Charlie_Kaufman@notesdev.ibm.com From: Stephen Kent Subject: Re: Specification of tunnel/transport attribute in IKEv2 Cc: "'ipsec list'" Content-Type: multipart/alternative; boundary="============_-1188890667==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1188890667==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Charlie, >Returning to the original posting under this subject line, Andrew Krywaniuk >asked: > >> I remember reading a posting on the list recently about the confusion >> surrounding the specification of tunnel mode with SA bundles (i.e. if you >> are doing ESP+AH, should you specify tunnel mode for one and transport >for >> the other or tunnel for both). At the bakeoffs, we decided that you >should >> put tunnel mode in both protocols. Also, we decided that the ordering of >the >> protocols in the proposal shouldn't matter, since the only ordering that >> makes sense is [AH][ESP][IPCOMP]. > >Seems like this should be pinned down. My inclination is to say that the >order in the proposal *does* matter, and therefore if the above is the only >order that makes sense then that is the only order allowed in the proposal. >Markku Savela claimed there was a legitimate use for a different >composition. I'll confess I didn't understand the rationale, but I'm >reluctant >to delete functionality if it's implemented and doesn't get in anyone's >way. > >Would people accept making it explicit that the order in the proposal >MUST match the order of headers in the resulting packets with mention >that implementations of combinations SHOULD use the order >[AH][ESP][IPCOMP]? > >Currently, no composition of AH and ESP is mandatory to implement, and >I would expect that it would be unusual for anyone to support it in a >single >bundle. (They might exist in a single packet when tunnels are nested, but >such would not be an issue for IKE). Is there an expectation that people >are actually going to do this? 2401 does mandate support in transport mode for [IP1][AH][ESP] but says to not do [IP1][ESP][AH]. I suspect that's why folks thought the order didn't matter. I agree, though, that we should state that ordering does matter. On the other hand, I assume that we will depricate the use of AH in general and we can kill of that combination as a MUST. > >> >> I figured we should make sure that these ambiguities are cleared up in >the >> Son-of-IKE candidates. However, in perusing through the IKEv2 draft, I >can >> find no mention of tunnel mode or transport mode at all. Are the authors >> assuming that one of the modes is going to be eliminated before we >> standardize SOI, or is this just an oversight? > >It was not an oversight, though it may have been a mistake. I assumed >that tunnel vs transport mode did not need to be negotiated nor be an >attribute of the SA, but rather that every SA would be capable of >carrying both transport mode and tunnel mode packets. In the extreme, >a single SA might carry both types where tunnel mode is used when the >inner IP addresses don't match the outer IP addresses. I can see how >this might cause confusion through NATs, but it's not clear how adding >tunnel vs. transport mode to the negotiation helps in that case. > >Could someone give an example of when it's not "obvious" what mode >should be used and how the endnodes can manage to negotiate the >right thing in that case? There are different opinions here. I believe that one should negotiate the mode and the other end should enforce it when parsing a packet. Dan McDonald (Sun) believe that it makes no difference. Steve --============_-1188890667==_ma============ Content-Type: text/html; charset="us-ascii" Charlie, >Returning to the original posting under this subject line, Andrew Krywaniuk >asked: > >> I remember reading a posting on the list recently about the confusion >> surrounding the specification of tunnel mode with SA bundles (i.e. if you >> are doing ESP+AH, should you specify tunnel mode for one and transport >for >> the other or tunnel for both). At the bakeoffs, we decided that you >should >> put tunnel mode in both protocols. Also, we decided that the ordering of >the >> protocols in the proposal shouldn't matter, since the only ordering that >> makes sense is [AH][ESP][IPCOMP]. > >Seems like this should be pinned down. My inclination is to say that the >order in the proposal *does* matter, and therefore if the above is the only >order that makes sense then that is the only order allowed in the proposal. >Markku Savela claimed there was a legitimate use for a different >composition. I'll confess I didn't understand the rationale, but I'm >reluctant >to delete functionality if it's implemented and doesn't get in anyone's >way. > >Would people accept making it explicit that the order in the proposal >MUST match the order of headers in the resulting packets with mention >that implementations of combinations SHOULD use the order >[AH][ESP][IPCOMP]? > >Currently, no composition of AH and ESP is mandatory to implement, and >I would expect that it would be unusual for anyone to support it in a >single >bundle. (They might exist in a single packet when tunnels are nested, but >such would not be an issue for IKE). Is there an expectation that people >are actually going to do this? 2401 does mandate support in transport mode for [IP1][AH][ESP] but says to not do [IP1][ESP][AH]. I suspect that's why folks thought the order didn't matter. I agree, though, that we should state that ordering does matter. On the other hand, I assume that we will depricate the use of AH in general and we can kill of that combination as a MUST. >> >> I figured we should make sure that these ambiguities are cleared up in >the >> Son-of-IKE candidates. However, in perusing through the IKEv2 draft, I >can >> find no mention of tunnel mode or transport mode at all. Are the authors >> assuming that one of the modes is going to be eliminated before we >> standardize SOI, or is this just an oversight? > >It was not an oversight, though it may have been a mistake. I assumed >that tunnel vs transport mode did not need to be negotiated nor be an >attribute of the SA, but rather that every SA would be capable of >carrying both transport mode and tunnel mode packets. In the extreme, >a single SA might carry both types where tunnel mode is used when the >inner IP addresses don't match the outer IP addresses. I can see how >this might cause confusion through NATs, but it's not clear how adding >tunnel vs. transport mode to the negotiation helps in that case. > >Could someone give an example of when it's not "obvious" what mode >should be used and how the endnodes can manage to negotiate the >right thing in that case? There are different opinions here. I believe that one should negotiate the mode and the other end should enforce it when parsing a packet. Dan McDonald (Sun) believe that it makes no difference. Steve --============_-1188890667==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jun 5 08:46:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g55Fkvg18673; Wed, 5 Jun 2002 08:46:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00343 Wed, 5 Jun 2002 10:25:57 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60285C4E8@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-soi-features-01.txt Date: Wed, 5 Jun 2002 10:06:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20C9A.277AFD46" 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_01C20C9A.277AFD46 Content-Type: text/plain; charset="iso-8859-1" Thanks Paul for your help in sorting out the features. The response to your newest draft may be limited because those interested in the next version of IKE like what they read in the current IKEv2 draft. My view is, and has been, that the draft is a complete protocol solution. Perhaps others view it the same way. I have your most recent draft regarding features. It is well written. Regards, Dennis Beard -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, June 04, 2002 4:10 PM To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-soi-features-01.txt Only a very small number of people have posted to the list what they think they need for the successor-to-IKE protocol. This new draft incorporates pointers to the "need to think about" items in the scenarios in Cheryl's requirements document. The idea here is to help stimulate discussion so we can reach closure on the required features. Surely, more people than the samll handful who have commented so far must have strong views on what they need/want from successor-to-IKE. --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C20C9A.277AFD46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-ipsec-soi-features-01.txt Thanks Paul for your help in sorting out the = features. The response to your newest draft may be limited = because those interested in the next version of IKE like what they read = in the current IKEv2 draft. My view is, and has been, that the = draft is a complete protocol solution. Perhaps others view it the = same way. I have your most recent draft regarding = features. It is well written. Regards, Dennis Beard -----Original Message----- From: Paul Hoffman / VPNC [<3d.htm>mailto:paul.hoffman@vpnc.org]<= /FONT> Sent: Tuesday, June 04, 2002 4:10 PM To: ipsec@lists.tislabs.com Subject: Re: I-D = ACTION:draft-ietf-ipsec-soi-features-01.txt Only a very small number of people have posted to the = list what they think they need for the successor-to-IKE protocol. = This new draft incorporates pointers to the "need to think = about" items in the scenarios in Cheryl's requirements document. The = idea here is to help stimulate discussion so we can reach closure on the = required features. Surely, more people than the samll handful who have = commented so far must have strong views on what they need/want from = successor-to-IKE. --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C20C9A.277AFD46-- From owner-ipsec@lists.tislabs.com Wed Jun 5 09:47:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g55Gldn23184; Wed, 5 Jun 2002 09:47:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00528 Wed, 5 Jun 2002 11:02:25 -0400 (EDT) Message-Id: <5.1.0.14.0.20020605111029.00b098c8@pop.gw.tislabs.com> X-Sender: susan@pop.gw.tislabs.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Jun 2002 11:11:20 -0400 To: ipsec@lists.tislabs.com From: Susan Fleming Subject: Mailing List Server Outage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk List Administration Announcement The server lists.tislabs.com will be offline from approximately 10am EDT to 2pm EDT, Friday, June 7, 2002. Any messages sent to lists on this server will be queued on another Mail Exchanger system, and thus will not be lost. But postings will not be distributed until the system is back online. We apologize for any inconvenience this may cause. We are moving office locations, and this time is needed to change Internet routing and transport the server. Note that NO server names or IP addresses will change as a part of this move, it is only a physical location move. -NAILabs Majordomo Administration From owner-ipsec@lists.tislabs.com Wed Jun 5 15:45:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g55Mj4n07760; Wed, 5 Jun 2002 15:45:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01374 Wed, 5 Jun 2002 17:55:36 -0400 (EDT) X-Originating-IP: [66.31.70.172] From: "IETF_DavidChen" To: "Hallam-Baker, Phillip" , "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" , "Davenport Michael" Cc: References: <2F3EC696EAEED311BB2D009027C3F4F405869AD9@vhqpostal.verisign.com> Subject: Re: [saag] Re: Date: Wed, 5 Jun 2002 18:10:53 -0400 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: 05 Jun 2002 22:08:30.0410 (UTC) FILETIME=[868712A0:01C20CDD] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phil, Agreed most of your observations. In addition to that, I would like to point out that RSVP is bandwidth reservation protocol for guarantee IP packet delivery in timely fashion. It can be used for 1-to-1 or 1-to-many and initiated by the receiver to set up a simplex flow. Each hop along the RSVP reserved path has to commit the bandwidth. For IP security point of view, each hop along the reserved/requested path have to trust each other for the bandwidth committed is vital to the router's behavior. The (D)DOS attack to any RSVPable router can not be protected by IPSec v1. For other sec protection, IPSec's secured data channel has to be established first before RSVP signaling message. It has to be done hop by hop - not just between flow sender and receiver. As for protecting flow itself (after RSVP has set up the flow), IPSec can set up only between sender and receiver... However, I don't think this is what this thread is interested. Scalability could be an issue to setup IPSec channel for all hops along the requested/flow path. If "no IPSec -> no RSVP" is not an issue, it seems ok. :-) --- David ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" ; "Davenport Michael" Cc: Sent: Thursday, May 30, 2002 11:08 AM Subject: RE: [saag] Re: > > > Mike > > > > I believe most big vendors are looking at it right now, see > > I don't. I know of more major platform vendors who are stating that they > have no intention of further work on CORBA than are platform members of OMG. > The only major companies with Platform membership of OMG at this stage are > Motorola, Rockwell Collins and DaimlerChrysler. These are not names I > usually associate with IP routing. > > > The best approach in my view is to use CORBA and CORBsec to deal with path > > messages, I believe if CORBA routers can be realized very soon, most of > your > > IPsec shortcomings will be resolved. > > How? > > There are several companies that have built Web Services SOAP routers. It is > not immediately apparent to me how any of their products is relevant to this > problem. > > > The problem is essentially caused by the introduction of a feature that > requires a degree of trust in what is considered by the IPSEC threat model > to be an untrusted device. > > I suspect that the QoS problem cannot be solved through application of the > end-to-end principle. This should not be a great suprise since the > end-to-end principle is a conclusion, not an axiom. Those that treat it as > an axiom are likely to get overly ideological about the issue. > > The end-to-end argument was originally an argument about complexity. > Complexity is easier to manage at the edge of the network rather than the > middle. This morphed into a subtly different security argument that the > security context of a message should be managed 'end-to-end'. This is a > problematic argument since a transaction may have many messages and the > 'ends' of the transaction may not align with the 'ends' of the constituent > messages. > > While it is nice to build theoretical models in which the only trusted > parties are the end points, QoS inherently depends on the end points > trusting each of the intermediate routers to meet the necessary QoS > characteristic. > > Furthermore the routers must trust the originator of any QoS messages since > otherwise a malicious user may perform a DoS attack against the entire > network by issuing bogus QoS reservation messages. > > [Observation, QoS is not an issue if the network resources are not > constrained in some manner] > > This latter problem indicates to me that it is not feasible to support QoS > on an unrestricted public network without some form of resource management > mechanism (probably related to monetary payment) to support it. What could > be a tricky problem of trust is thus simplified, instead of the hard problem > of 'is it Alice' we have the easier problem of 'can she pay'. The trust > relationships precisely align to the relationship between resource > allocators. > > The resulting business models may or may not turn out to be 'all you can > eat'. I suspect however that some incentive is required. > > > This problem appears to me to require the following components: > > 1) Trustworthy routing information > 2) Means by which a router may determine that a reservation message > is signed by a trustworthy actor. > 3) Means by which a router may notify charging mechanism > > The end-to-end principle indicates that the routers should certainly not be > performing heavyweight crypto. > > The model I would favor would involve some form of bandwidth reservations > actor that can perform processing of the bandwidth reservation request then > issue RSVP messages tagged with MAC authenticators and Kerberos tickets for > each of the routers concerned. > > > Phill > From owner-ipsec@lists.tislabs.com Thu Jun 6 08:38:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56Fc6n18032; Thu, 6 Jun 2002 08:38:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02800 Thu, 6 Jun 2002 10:50:31 -0400 (EDT) From: "Hannes Tschofenig" To: "IETF_DavidChen" , "Hallam-Baker, Phillip" , "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" , "Davenport Michael" Cc: Subject: RE: [saag] Re: Date: Thu, 6 Jun 2002 17:07:08 +0200 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi david > Phil, > > Agreed most of your observations. > > In addition to that, I would like to point out that > RSVP is bandwidth reservation protocol for guarantee IP packet delivery in > timely fashion. actually it is a signaling protocol. it does not really reserve bandwidth or any other qos things. this is the purpose of the underlying qos mechanisms. > It can be used for 1-to-1 or 1-to-many and initiated by the > receiver to set > up a simplex flow. good point. so far we haven't mentioned the rsvp multicast implications for security. > Each hop along the RSVP reserved path has to commit the bandwidth. > For IP security point of view, each hop along the reserved/requested path > have to trust each other > for the bandwidth committed is vital to the router's behavior. i would like to add that not all nodes have to trust each other directly. instead the chain-of-trust principle uses the transitive trust relationship between the individual nodes along the path to establish the end-to-end trust rel.. > > The (D)DOS attack to any RSVPable router can not be protected by IPSec v1. to which dos attack are you exactly referring? > For other sec protection, IPSec's secured data channel has to be > established first > before RSVP signaling message. yes. > It has to be done hop by hop - not just between flow sender and receiver. true, it cannot be done end-to-end because of various reasons including: - rsvp message modification along the path - route pinning etc. > > As for protecting flow itself (after RSVP has set up the flow), IPSec can > set up only between sender and receiver... > However, I don't think this is what this thread is interested. yes - the protection of data traffic after the rsvp signaling took place using ipsec is a different issue. > > Scalability could be an issue to setup IPSec channel for all hops > along the > requested/flow path. the question of scalability depends how many rsvp aware nodes along the path you have. futhermore ipsec (in a hop-by-hop manner) may also be used for a specific part in the network (for example between two network providers) whereas other parts use the rsvp built-in integrity object. > If "no IPSec -> no RSVP" is not an issue, it seems ok. :-) i am not quite sure what you mean with this statement. ciao hannes From owner-ipsec@lists.tislabs.com Thu Jun 6 10:56:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56Hudn28554; Thu, 6 Jun 2002 10:56:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03117 Thu, 6 Jun 2002 13:12:32 -0400 (EDT) X-Originating-IP: [66.31.70.172] From: "IETF_DavidChen" To: "Hannes Tschofenig" , "Hallam-Baker, Phillip" , "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" , "Davenport Michael" Cc: References: Subject: Re: [saag] Re: Date: Thu, 6 Jun 2002 13:27:26 -0400 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 Jun 2002 17:25:14.0082 (UTC) FILETIME=[1E56FC20:01C20D7F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hannes, My reply to your particular question is in-line. --- David ----- Original Message ----- From: "Hannes Tschofenig" To: "IETF_DavidChen" ; "Hallam-Baker, Phillip" ; "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" ; "Davenport Michael" Cc: Sent: Thursday, June 06, 2002 11:07 AM Subject: RE: [saag] Re: > hi david > > > Phil, > > > > Agreed most of your observations. > > > > In addition to that, I would like to point out that > > RSVP is bandwidth reservation protocol for guarantee IP packet delivery in > > timely fashion. > > actually it is a signaling protocol. it does not really reserve bandwidth or > any other qos things. this is the purpose of the underlying qos mechanisms. > > > It can be used for 1-to-1 or 1-to-many and initiated by the > > receiver to set > > up a simplex flow. > > good point. so far we haven't mentioned the rsvp multicast implications for > security. > > > Each hop along the RSVP reserved path has to commit the bandwidth. > > For IP security point of view, each hop along the reserved/requested path > > have to trust each other > > for the bandwidth committed is vital to the router's behavior. > > i would like to add that not all nodes have to trust each other directly. > instead the chain-of-trust principle uses the transitive trust relationship > between the individual nodes along the path to establish the end-to-end > trust rel.. Without IPSec (or similar security model), the RSVPable routers have to reject any RSVP message from unknown routers - practically everyone. (all kinds of attack could happen :-) All the RSVPable routers along the flow path have to be at the same level of IPSec protection. Furthermore, all the routers that have been requested resource (for RSVPable router) have to be at the same level of IPSec protection. I suppose the members of the chain-of-trust are those RSVPable routers. > > > > > The (D)DOS attack to any RSVPable router can not be protected by IPSec v1. > > to which dos attack are you exactly referring? Current IKE of IPSec can not protect (Distributed) Denial of Service attack... and don't mention about RSVP depends on it to setup a secured channel. > > > For other sec protection, IPSec's secured data channel has to be > > established first > > before RSVP signaling message. > > yes. > > > It has to be done hop by hop - not just between flow sender and receiver. > > true, it cannot be done end-to-end because of various reasons including: > - rsvp message modification along the path > - route pinning > etc. > > > > > As for protecting flow itself (after RSVP has set up the flow), IPSec can > > set up only between sender and receiver... > > However, I don't think this is what this thread is interested. > > yes - the protection of data traffic after the rsvp signaling took place > using ipsec is a different issue. > > > > > Scalability could be an issue to setup IPSec channel for all hops > > along the > > requested/flow path. > > the question of scalability depends how many rsvp aware nodes along the path > you have. > futhermore ipsec (in a hop-by-hop manner) may also be used for a specific > part in the network (for example between two network providers) whereas > other parts use the rsvp built-in integrity object. > > > If "no IPSec -> no RSVP" is not an issue, it seems ok. :-) > i am not quite sure what you mean with this statement. If it requires IPSec to protect RSVP then it needs to ask all RSVPable routers must have IPSec. This is an issue if RSVPable router is in the 'cloud'. The IPSec is expected to implement on edge of the 'cloud' for effeciency. This also bring up an important issue about how effective the RSVP is when NOT all the router along the flow path is RSVPable router. The worest case will be only the 2 RSVPable routers are on the edge of 'IP cloud' that are sender side and receiver side respectively. :-) The IPSec (or security issue) is just one more factor to complicate the effectiveness of RSVP in the public IP network. It seems that a secured channel between the RSVPable router can help the 'trusted router resource allocation' issue. However, if RSVPable routers are in the cloud (which will increase the effectiveness of the purpose of IP QoS), then the secured comm level is better on the RSVP message level - not IP level. (i.e. other than IPSec ;-) > > ciao > hannes > > > From owner-ipsec@lists.tislabs.com Thu Jun 6 13:34:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56KYXn06345; Thu, 6 Jun 2002 13:34:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03367 Thu, 6 Jun 2002 15:52:59 -0400 (EDT) Message-ID: <20020606200549.19878.qmail@web21303.mail.yahoo.com> Date: Thu, 6 Jun 2002 13:05:49 -0700 (PDT) From: SatishK Amara Subject: Re: [saag] Re: To: IETF_DavidChen , Hannes Tschofenig , "Hallam-Baker, Phillip" , "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" , Davenport Michael Cc: ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Please look for my inline comments .. --- IETF_DavidChen wrote: > Hannes, > My reply to your particular question is in-line. > --- David > > ----- Original Message ----- > From: "Hannes Tschofenig" > > To: "IETF_DavidChen" ; > "Hallam-Baker, Phillip" > ; "'Prof. Ahmed Bin Abbas Ahmed > Ali Adas'" > ; "Davenport Michael" > > Cc: > Sent: Thursday, June 06, 2002 11:07 AM > Subject: RE: [saag] Re: > > > > hi david > > > > > Phil, > > > > > > Agreed most of your observations. > > > > > > In addition to that, I would like to point out > that > > > RSVP is bandwidth reservation protocol for > guarantee IP packet delivery > in > > > timely fashion. > > > > actually it is a signaling protocol. it does not > really reserve bandwidth > or > > any other qos things. this is the purpose of the > underlying qos > mechanisms. > > > > > It can be used for 1-to-1 or 1-to-many and > initiated by the > > > receiver to set > > > up a simplex flow. > > > > good point. so far we haven't mentioned the rsvp > multicast implications > for > > security. > > > > > Each hop along the RSVP reserved path has to > commit the bandwidth. > > > For IP security point of view, each hop along > the reserved/requested > path > > > have to trust each other > > > for the bandwidth committed is vital to the > router's behavior. > > > > i would like to add that not all nodes have to > trust each other directly. > > instead the chain-of-trust principle uses the > transitive trust > relationship > > between the individual nodes along the path to > establish the end-to-end > > trust rel.. > > Without IPSec (or similar security model), the > RSVPable routers have to > reject any RSVP message > from unknown routers - practically everyone. (all > kinds of attack could > happen :-) > > All the RSVPable routers along the flow path have to > be at the same level of > IPSec protection. > > Furthermore, all the routers that have been > requested resource (for RSVPable > router) have > to be at the same level of IPSec protection. > > I suppose the members of the chain-of-trust are > those RSVPable routers. > > > > > > > > > The (D)DOS attack to any RSVPable router can not > be protected by IPSec > v1. > > > > to which dos attack are you exactly referring? > > Current IKE of IPSec can not protect (Distributed) > Denial of Service > attack... and don't mention about > RSVP depends on it to setup a secured channel. > IKEv2/JFK addresses DOS attacks > > > > > For other sec protection, IPSec's secured data > channel has to be > > > established first > > > before RSVP signaling message. > > > > yes. > > > > > It has to be done hop by hop - not just between > flow sender and > receiver. > > > > true, it cannot be done end-to-end because of > various reasons including: > > - rsvp message modification along the path > > - route pinning > > etc. > > > > > > > > As for protecting flow itself (after RSVP has > set up the flow), IPSec > can > > > set up only between sender and receiver... > > > However, I don't think this is what this thread > is interested. > > > > yes - the protection of data traffic after the > rsvp signaling took place > > using ipsec is a different issue. > > > > > > > > Scalability could be an issue to setup IPSec > channel for all hops > > > along the > > > requested/flow path. > > > > the question of scalability depends how many rsvp > aware nodes along the > path > > you have. > > futhermore ipsec (in a hop-by-hop manner) may also > be used for a specific > > part in the network (for example between two > network providers) whereas > > other parts use the rsvp built-in integrity > object. > > > > > If "no IPSec -> no RSVP" is not an issue, it > seems ok. :-) > > i am not quite sure what you mean with this > statement. > > If it requires IPSec to protect RSVP then it needs > to ask all RSVPable > routers must > have IPSec. This is an issue if RSVPable router is > in the 'cloud'. > The IPSec is expected to implement on edge of the > 'cloud' for effeciency. > This also bring up an important issue about how > effective the RSVP is when > NOT all the router along the flow path is RSVPable > router. > The worest case will be only the 2 RSVPable routers > are on the edge of 'IP > cloud' that are sender side and receiver side > respectively. :-) > The IPSec (or security issue) is just one more > factor to complicate the > effectiveness of RSVP in the public IP network. > > It seems that a secured channel between the RSVPable > router can help the > 'trusted router resource allocation' issue. > However, if RSVPable routers are in the cloud (which > will increase the > effectiveness of the purpose of IP QoS), > then the secured comm level is better on the RSVP > message level - not IP > level. (i.e. other than IPSec ;-) > I agree with you the security for RSVP should be at message level rather than IP level. I think this is due to couple of reasons. IPSEC cannot address the security aspects of RSVP RSVP next hop is determined dynamically. RSVP messages changes from hop to hop Need for both hop to hop and end to end security mechanism for RSVP Satish Amara > > > > ciao > > hannes > > > > > > __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ipsec@lists.tislabs.com Thu Jun 6 14:20:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56LKVn07535; Thu, 6 Jun 2002 14:20:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03430 Thu, 6 Jun 2002 16:31:18 -0400 (EDT) X-Originating-IP: [66.31.70.172] From: "IETF_DavidChen" To: "SatishK Amara" , "Hannes Tschofenig" , "Hallam-Baker, Phillip" , "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" , "Davenport Michael" Cc: References: <20020606200549.19878.qmail@web21303.mail.yahoo.com> Subject: Re: [saag] Re: Date: Thu, 6 Jun 2002 16:45:51 -0400 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 Jun 2002 20:43:38.0187 (UTC) FILETIME=[D5BD41B0:01C20D9A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Satish, Agreed, Let's work on RSVPSec. :-) --- David ----- Original Message ----- From: "SatishK Amara" To: "IETF_DavidChen" ; "Hannes Tschofenig" ; "Hallam-Baker, Phillip" ; "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" ; "Davenport Michael" Cc: Sent: Thursday, June 06, 2002 4:05 PM Subject: Re: [saag] Re: > Hi, > Please look for my inline comments .. > --- IETF_DavidChen wrote: > > Hannes, > > My reply to your particular question is in-line. > > --- David > > > > ----- Original Message ----- > > From: "Hannes Tschofenig" > > > > To: "IETF_DavidChen" ; > > "Hallam-Baker, Phillip" > > ; "'Prof. Ahmed Bin Abbas Ahmed > > Ali Adas'" > > ; "Davenport Michael" > > > > Cc: > > Sent: Thursday, June 06, 2002 11:07 AM > > Subject: RE: [saag] Re: > > > > > > > hi david > > > > > > > Phil, > > > > > > > > Agreed most of your observations. > > > > > > > > In addition to that, I would like to point out > > that > > > > RSVP is bandwidth reservation protocol for > > guarantee IP packet delivery > > in > > > > timely fashion. > > > > > > actually it is a signaling protocol. it does not > > really reserve bandwidth > > or > > > any other qos things. this is the purpose of the > > underlying qos > > mechanisms. > > > > > > > It can be used for 1-to-1 or 1-to-many and > > initiated by the > > > > receiver to set > > > > up a simplex flow. > > > > > > good point. so far we haven't mentioned the rsvp > > multicast implications > > for > > > security. > > > > > > > Each hop along the RSVP reserved path has to > > commit the bandwidth. > > > > For IP security point of view, each hop along > > the reserved/requested > > path > > > > have to trust each other > > > > for the bandwidth committed is vital to the > > router's behavior. > > > > > > i would like to add that not all nodes have to > > trust each other directly. > > > instead the chain-of-trust principle uses the > > transitive trust > > relationship > > > between the individual nodes along the path to > > establish the end-to-end > > > trust rel.. > > > > Without IPSec (or similar security model), the > > RSVPable routers have to > > reject any RSVP message > > from unknown routers - practically everyone. (all > > kinds of attack could > > happen :-) > > > > All the RSVPable routers along the flow path have to > > be at the same level of > > IPSec protection. > > > > Furthermore, all the routers that have been > > requested resource (for RSVPable > > router) have > > to be at the same level of IPSec protection. > > > > I suppose the members of the chain-of-trust are > > those RSVPable routers. > > > > > > > > > > > > > The (D)DOS attack to any RSVPable router can not > > be protected by IPSec > > v1. > > > > > > to which dos attack are you exactly referring? > > > > Current IKE of IPSec can not protect (Distributed) > > Denial of Service > > attack... and don't mention about > > RSVP depends on it to setup a secured channel. > > > IKEv2/JFK addresses DOS attacks > > > > > > > > For other sec protection, IPSec's secured data > > channel has to be > > > > established first > > > > before RSVP signaling message. > > > > > > yes. > > > > > > > It has to be done hop by hop - not just between > > flow sender and > > receiver. > > > > > > true, it cannot be done end-to-end because of > > various reasons including: > > > - rsvp message modification along the path > > > - route pinning > > > etc. > > > > > > > > > > > As for protecting flow itself (after RSVP has > > set up the flow), IPSec > > can > > > > set up only between sender and receiver... > > > > However, I don't think this is what this thread > > is interested. > > > > > > yes - the protection of data traffic after the > > rsvp signaling took place > > > using ipsec is a different issue. > > > > > > > > > > > Scalability could be an issue to setup IPSec > > channel for all hops > > > > along the > > > > requested/flow path. > > > > > > the question of scalability depends how many rsvp > > aware nodes along the > > path > > > you have. > > > futhermore ipsec (in a hop-by-hop manner) may also > > be used for a specific > > > part in the network (for example between two > > network providers) whereas > > > other parts use the rsvp built-in integrity > > object. > > > > > > > If "no IPSec -> no RSVP" is not an issue, it > > seems ok. :-) > > > i am not quite sure what you mean with this > > statement. > > > > If it requires IPSec to protect RSVP then it needs > > to ask all RSVPable > > routers must > > have IPSec. This is an issue if RSVPable router is > > in the 'cloud'. > > The IPSec is expected to implement on edge of the > > 'cloud' for effeciency. > > This also bring up an important issue about how > > effective the RSVP is when > > NOT all the router along the flow path is RSVPable > > router. > > The worest case will be only the 2 RSVPable routers > > are on the edge of 'IP > > cloud' that are sender side and receiver side > > respectively. :-) > > The IPSec (or security issue) is just one more > > factor to complicate the > > effectiveness of RSVP in the public IP network. > > > > It seems that a secured channel between the RSVPable > > router can help the > > 'trusted router resource allocation' issue. > > However, if RSVPable routers are in the cloud (which > > will increase the > > effectiveness of the purpose of IP QoS), > > then the secured comm level is better on the RSVP > > message level - not IP > > level. (i.e. other than IPSec ;-) > > > I agree with you the security for RSVP should be at > message level rather than IP level. I think this is > due to couple of reasons. IPSEC cannot address the > security aspects of RSVP > RSVP next hop is determined dynamically. > RSVP messages changes from hop to hop > Need for both hop to hop and end to end security > mechanism for RSVP > > Satish Amara > > > > > > > ciao > > > hannes > > > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > From owner-ipsec@lists.tislabs.com Fri Jun 7 05:42:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57CgMn01288; Fri, 7 Jun 2002 05:42:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04762 Fri, 7 Jun 2002 07:49:11 -0400 (EDT) Message-ID: <025901c20dfe$d2a5f120$446015ac@T23KEMPF> From: "James Kempf" To: , Subject: BOF on Securing Neighbor Discovery at IETF 54 Date: Fri, 7 Jun 2002 01:39:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tues. afternoon 13:00-14:00 at IETF 54, a BOF will be held to discuss securing IPv6 Neighbor Discovery. A BOF description including a reading list and mailing list will appear shortly when the agenda is posted. If you are interested in this problem, please attend. If you would like to speak, please send email to me or Pekka Nikkander (Pekka.Nikander@nomadiclab.com). We are especially interested in getting people who have implemented an IPsec solution or think they have a solution using IPsec, as a major issue that has come up with using IPsec is how to do key distribution given that IKE would require using Neighbor Discovery and manual keying is inconvenient for a large public access network. jak From owner-ipsec@lists.tislabs.com Sun Jun 9 20:37:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5A3bvn11411; Sun, 9 Jun 2002 20:37:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03942 Sun, 9 Jun 2002 22:24:34 -0400 (EDT) Message-Id: <200206100226.LAA10521@csnet1.cs.tsinghua.edu.cn> Date: Mon, 10 Jun 2002 10:38:57 +0800 From: "=?GB2312?Q?=B6=AD=CF=FE=BB=A2?=" Reply-To: dongcat@csnet1.cs.tsinghua.edu.cn To: "ipsec@lists.tislabs.com" Subject: What if another ISAKMP sa is being negotiated for two peers? Organization: =?GB2312?Q?=C7=E5=BB=AA=B4=F3=D1=A7=BC=C6=CB=E3=BB=FA=CF=B5?= X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi: Consider below situation: There is an ISAKMP SA between peer A and peer B. Peer A has two interface to which two ip address, say A1 and A2, are binded. But peer B doesn't know A2 belongs to peer A. Now peer B wants to communicate with the host with address A2 securely. He initiates a negotiation with phase one's first msg des. How does peer A act when he receives this initial msg? Dong Xiaohu Tsinghua University, Beijing, China dongcat@csnet1.cs.tsinghua.edu.cn From owner-ipsec@lists.tislabs.com Mon Jun 10 04:20:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ABKTn26065; Mon, 10 Jun 2002 04:20:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04616 Mon, 10 Jun 2002 06:28:16 -0400 (EDT) Message-Id: <5.1.0.14.0.20020610153416.00a3d5d0@172.16.1.10> X-Sender: lokeshnb@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Jun 2002 16:04:25 +0530 To: ipsec@lists.tislabs.com From: Lokesh Subject: PMTU and NAT-Traversal problem Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, Is there anybody who implemented following in a security Gateway? 1. draft-ietf-ipsec-nat-t-ike-01.txt and draft-ietf-ipsec-udp-encaps-01.txt 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). if so, how did you solve following problem?......... For Unauthenticated ICMP PMTU message processing: The PMTU processing bound to fail, since ICMP PMTU error message would include only IP Hdr and 64 bits of IPsec Hdr information. Since UDP Encaps and NAT Traversal drafts encapsulate ipsec packets in UDP and put a 8 byte NON IKE marker,(totalling 16 bytes) PMTU error message returned will not have enough information to find the SA's at the receiving Security Gateway. How to solve this problem? any suggestions? any help in this regard is highly appreciated. Thanks Lokesh From owner-ipsec@lists.tislabs.com Mon Jun 10 07:40:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AEe4n07732; Mon, 10 Jun 2002 07:40:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04968 Mon, 10 Jun 2002 09:59:05 -0400 (EDT) Message-Id: <200206101116.HAA28186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt Date: Mon, 10 Jun 2002 07:16:30 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, H. Herbert Filename : draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt Pages : 11 Date : 07-Jun-02 A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for mes- sages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.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-ciph-aes-xcbc-mac-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607132522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607132522.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jun 10 07:41:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AEfMn07788; Mon, 10 Jun 2002 07:41:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04950 Mon, 10 Jun 2002 09:57:05 -0400 (EDT) Message-ID: <3D04A889.F9ACD7E9@steria.se> Date: Mon, 10 Jun 2002 15:24:25 +0200 From: Joachim =?iso-8859-1?Q?Abrahms=E9n?= Organization: IT Security, Steria AB X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec mailing list Subject: IPComp CA and IPsec SA negotiations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We're about to implement support for compression into our VPN-product, but can't quite figure out how to extend the IKE negotiation in order to include IPComp. RFC 3173 section 4.1 says "For IPComp in the context of IP Security, IKE provides the necessary mechanisms and guidelines for establishing IPCA. Using IKE, IPComp can be negotiated as stand-alone or in conjunction with other IPsec protocols." What I want is to _use_ IPComp in conjuntion with other IPsec (in my case ESP) protocols. If I interpret this correctly I may do it either way; negotiating them as two separate SA, possibly as two SA payloads in the same QM negotiation, or as a SA boundle with ESP and IPComp in the same proposal. I would prefer to negotiate them separately, since I don't wan't the whole negotiation to fail because the peer doesn't support IPComp, and I would prefer not to duplicate my proposals (with and without IPComp). What is common practise? Thanks in advance -Joachim From owner-ipsec@lists.tislabs.com Mon Jun 10 07:46:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AEkIn07999; Mon, 10 Jun 2002 07:46:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04947 Mon, 10 Jun 2002 09:57:04 -0400 (EDT) Subject: RE: PMTU and NAT-Traversal problem From: Jan Backman To: ipsec@lists.tislabs.com Date: Mon, 10 Jun 2002 13:59:55 +0200 X-Mailer: NIMS ModWeb Module X-Sender: jan.backman@home.se MIME-Version: 1.0 Message-ID: <1023710395.48f4bcc0jan.backman@home.se> 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 HAA04716 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Store the information about the encountered MTU in the NAT and use it to reply an ICMP when the next packet in the flow arrives (that is larger than the MTU). regards /// Jan > -----Original Message----- > From: Lokesh [mailto:lokeshnb@intotoinc.com] > Sent: Monday, June 10, 2002 12:34 PM > To: ipsec@lists.tislabs.com > Subject: PMTU and NAT-Traversal problem > > > Hi all, > Is there anybody who implemented following in a security Gateway? > 1. draft-ietf-ipsec-nat-t-ike-01.txt and > draft-ietf-ipsec-udp-encaps-01.txt > 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). > if so, how did you solve following problem?......... > > For Unauthenticated ICMP PMTU message processing: > > The PMTU processing bound to fail, since ICMP PMTU error > message would > include > only IP Hdr and 64 bits of IPsec Hdr information. Since UDP > Encaps and NAT > Traversal drafts encapsulate ipsec packets in UDP and put a 8 > byte NON IKE > marker,(totalling 16 bytes) > PMTU error message returned will not have enough information > to find the > SA's at the receiving > Security Gateway. How to solve this problem? any suggestions? > any help in this regard is highly appreciated. > Thanks > Lokesh > From owner-ipsec@lists.tislabs.com Tue Jun 11 03:20:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BAKin21234; Tue, 11 Jun 2002 03:20:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA06663 Tue, 11 Jun 2002 05:22:16 -0400 (EDT) Message-Id: <5.1.0.14.0.20020611140750.00a40700@172.16.1.10> X-Sender: lokeshnb@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Jun 2002 14:28:19 +0530 To: Jan Backman , ipsec@lists.tislabs.com From: Lokesh Subject: RE: PMTU and NAT-Traversal problem In-Reply-To: <1023710395.48f4bcc0jan.backman@home.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello jan, Thanks, but that is not the answer to my question. problem is information for SA look up is not present in the returned ICMP PMTU message. Hence sender cannot determine in which SA to update returned MTU. I think I should explain it bit more clearly. When a IPSec packet with DF bit set, cannot be transmitted over a link with less MTU, the router would send ICMP PMTU error packet back to sender which contains IP header and 64 bits of IPSec headers of faulting packet as data. sender uses the SPI and other packet selectors in the 64 bit information to look up SA's and adjust their MTU with the returned MTU value in the ICMP PMTU message. Now, in case where NAT Traversal is supported, IPSec packets will be encapsulated in UDP packets and 8 bytes of NON -IKE marker, the 64 bit info after IP hdr will only contain UDP header using which sender cannot determine SA's over which original faulting packet was sent. Is there any solution exists for this problem? Thanks Lokesh At 01:59 PM 6/10/02 +0200, Jan Backman wrote: >Hi, >Store the information about the encountered MTU in the NAT and use it to >reply an ICMP when the next packet in the flow arrives (that is larger >than the MTU). > >regards /// Jan > > > -----Original Message----- > > From: Lokesh [mailto:lokeshnb@intotoinc.com] > > Sent: Monday, June 10, 2002 12:34 PM > > To: ipsec@lists.tislabs.com > > Subject: PMTU and NAT-Traversal problem > > > > > > Hi all, > > Is there anybody who implemented following in a security Gateway? > > 1. draft-ietf-ipsec-nat-t-ike-01.txt and > > draft-ietf-ipsec-udp-encaps-01.txt > > 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). > > if so, how did you solve following problem?......... > > > > For Unauthenticated ICMP PMTU message processing: > > > > The PMTU processing bound to fail, since ICMP PMTU error > > message would > > include > > only IP Hdr and 64 bits of IPsec Hdr information. Since UDP > > Encaps and NAT > > Traversal drafts encapsulate ipsec packets in UDP and put a 8 > > byte NON IKE > > marker,(totalling 16 bytes) > > PMTU error message returned will not have enough information > > to find the > > SA's at the receiving > > Security Gateway. How to solve this problem? any suggestions? > > any help in this regard is highly appreciated. > > Thanks > > Lokesh > > From owner-ipsec@lists.tislabs.com Tue Jun 11 06:37:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BDbCn02554; Tue, 11 Jun 2002 06:37:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07225 Tue, 11 Jun 2002 08:57:06 -0400 (EDT) Message-ID: <014d01c21143$77860cb0$0b00a8c0@BGABAYT20> From: "Benzy Gabay" To: Subject: strange behavior (of Cisco VPN) after 2 re-keys Date: Tue, 11 Jun 2002 14:28:18 +0200 Organization: Maya Software Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0149_01C21154.3ADAFB70"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0149_01C21154.3ADAFB70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_014A_01C21154.3ADAFB70" ------=_NextPart_001_014A_01C21154.3ADAFB70 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Clear DayHi, I'm not sure if this question is suppose to be in this list. I'm trying my client against Cisco 3000 vpn. After doing successfully IKE (AM, QM) I'm getting after 2 rekeys a = packet filled with "0" only. I could not find anywhere in the IKE RFC's that it suppose to happened. Did I missed something or is it Cisco propriety behavior? Thanks =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Benzy Gabay R&D Maya Software Technologies Ltd. http://www.maya-st.com Tel: + 972 9 956 01 35 Fax: + 972 9 955 96 54 mailto: bgabay@maya-st.com ------=_NextPart_001_014A_01C21154.3ADAFB70 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable BODY { MARGIN-TOP: 25px; FONT-SIZE: 10pt; MARGIN-LEFT: 10px; COLOR: #0033cc; = FONT-FAMILY: Arial, Helvetica } Hi, I'm not sure if this question is suppose to be in this list. I'm trying my client against Cisco 3000 vpn. After doing successfully IKE (AM, QM) I'm getting after 2 rekeys a = packet=20 filled with "0" only. I could not find anywhere in the IKE RFC's that it suppose to=20 happened. Did I missed something or is it Cisco propriety behavior? Thanks =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Benzy Gabay R&D Maya=20 Software Technologies Ltd. <3d.htm>http://www.maya-st.com Tel: + 972 = 9 956 01=20 35 Fax: + 972 9 955 96 54 mailto: <3d.htm>bgabay@maya-st.com ------=_NextPart_001_014A_01C21154.3ADAFB70-- ------=_NextPart_000_0149_01C21154.3ADAFB70 Content-Type: application/octet-stream; name="Clear Day Bkgrd.JPG" Content-Transfer-Encoding: base64 Content-ID: <014801c21143$7745cf60$0b00a8c0@BGABAYT20> /9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAD9wAAAAEAAACAAAAAgAAAAYAAAMAAAAAD2wAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 9LSS7JlWLMolMkkmpXSTpIqUnCinCQQySTSknWilJkpSQtKxSlJJBKk6ZOkFP//Q9LlJMnVZmVCY qRUUCpSRKUpkErSpBRhOkClkCkmCcJ1rVQmUk0JKUm7p0kEqSTSkUrU//9H0kKQUU8qoCzlclRTy opEqC6SSSSVwlokkihScJAJwEgEKCRTpiE6lLJJJkFLJJJJq5//S9JTJ0ypthcJJkpSUukklqipS kmhSARAQVBJOE6ctWCdJIooYlRKkSok6ppXBSRSCcodEv//T9JSSThVGwxITKZTQhSrUE6QCdOCC uEkySKF5Ugop0QgrpikSokokqCxTKSaEwrlBP8Eyfskh/9T0lSUSkCVUZ2SSYKSKFkkkgipSSdMU lLpFMmJStVLykmlOhaVJJAJ4RQslKSZBL//V9JTwkkqjOunUU4KchSQTpJKWJSTEppQtNLkpkk8I bqUAnSTIqZJSmSRQsmUlEoFIf//W9KCSSdVWdZIJQkkplKZNKSNopc6qMKSZBKycFOkB4pUq1JJ4 CUI0i1kydMUClUpkkkEv/9kAOEJJTQQGAAAAAAAHAAMAAAABAQD//gAnRmlsZSB3cml0dGVuIGJ5 IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9iZQBkAAAAAAH/2wCEAAoHBwcIBwoICAoPCggK DxINCgoNEhQQEBIQEBQRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBCwwMFRMV IhgYIhQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DP/AABEIASwBLAMBEQACEQEDEQH/3QAEACb/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJ CgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSES MUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaD CQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhI WGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20B AAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMI CQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eH l6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhED EQA/AOoZluG1hQ3TArqYpaxQ7fCrROKGtsVcadsVdthVvamBXYpcBgQ3TFk7FW8Vdtirgu+BV6rQ 1xSuGRZN0GKtU3+WFFOpirVBiq04UNYUOxVo4q49cVawoaritt1xVo4q7FDqHFLqHFW+ONpbpgta f//Q6jmU4bRGFXVxQ1XFXVxVquFDVcVawq7FXYq3gVvFXDFK4YEuOKrcKG8VXLgKQvGRZN4Eurir VcNIdXFXVxVrFDRwq7FWsULcKGjhQ1irWFXDFVwwJbxV2KXDArfbFX//0eo5lOI44ULcKHYqtOKH YVaxV2KHYpbwK3irhilvFXYEuOKGsKt4quGBK4HAluuBLWFXYENYVdXFWq4obrilrFDROFWsKGiM VawodTArsKuwKuGBLeKXYq3ir//S6kMynEaOKFuSQ7FVpxQ1hV2KHYpbwKuAxS7FXYq7FXYq1ire KuxVsYEt1wJbrirsVarih2KtHCrVcUN1xS6uKtE4UNVxV1cVbxVrFXYq7FDhilcMCW8Vdir/AP/T 6l2zKcRo4oaOFWsKHUwKtIwodhV1MCt0xS2MCuwq7FXYq0cUNVxVuuKXVxVsHFW8CXDFW8CXYodi rRwq1hQ7FXYq1ihrFWxilvFWsVdih2KtjAlvFLsVXYEv/9TqNcynDaJwq1hVvArqYq7FDVMVdhVr FXYq3irsVccCrckhrFWq4otuuK2uU4GTeBLYxVdgS1ih2KuphVxGKVuFi7FWqYq6mKt4q7FVuKGx ilumBXYVdgS4nCh1dq4rb//V6hXMtw2sKuxVsYFbwK6mKXEYoaOFVuFDWKG8Ut4q0Tiq3ChaThYt YVbGBV4OBkurkUtg4pdXFXVxVcMCXYq44qtOFDWFDsUuxV2KuxQ1TFWwMVbGBLsVaOKHYUNUHjil /9bp+Zjht4FdTFXYq2MCt4paOKrThQ1hQ7FDsUuJxVbhQ0ThQtwodireBV2BLsUrgcCW8VdilsHA q7Al2KtHFDVMKupirqYq1hQ7FXYq7FXYq7FXHAq3Ch1Ril//1+nVzMcJvFW8CXYq2MCt4paOKrTh YtYVdXFWq4odirWFWiMLFqmKupirsVbxS3gVvFK6uRS7CrYwJbwK3til2KupirWKGsKtYq6mKHYV dirVcVdXFDsVaxVrCr//0OmVzNcFcMCW8VXDAlumBLsVaJwqsJwsWsKGsVdirsVdirsUOxV1MUup irqYq7FW8CtnFXDFK4HAlvFXYFXDFLsCrTkkNYq7FXYq1hVo4oaxQ7FXYq7CrWKv/9HpmZrgNg4E rsUrhkWTZxVrFC0nChbkkNYodirsUupirsVdireKtgYFbxS1ihrFXDFW8UuGKrhgS3irYGBLeBXH Cqw4UNYq7CrsVdirsULcKGsVdirsVawof//S6Xmc69sYGS8ZFK7Al2FWq4qtOFC3ChrChvArsUt4 FdirsVdireKXYq7FWjihwxVvFLeKrsCW6YEtjFXYEtHChacKHUxV1MVdTFWsKuxQtwoW4UOrirsV bwK//9PpWZzr2wcCVwOBK6uBLq4q0ThVrChbXChquKGwcUt4FcMUt4FdireKt4pdirWKupirdMCu pirdMUrhgS3gV2KW6Yq1TChaRirsUOxV2FVuKGicKrThQ7FDVMKt4Fdil//U6Xmc69rFW64Et1xW 3VxS6uKuOKFuFDsVdiq4YEuxV1cVcMUrsCWxgV2KtYVbxVsYEt0wK3TFLeBXYpbGKt4pdTAq0jJI apihxxVZhQ7ChacUNYVdireKuxVrFX//1el5nOvdilo4odXFXVxVsHFLeBWqYVdih2KXYq7FXUxV vAlvFWwcCW64FdhVsDAlsDAldgV2KXYq7FWxirYwJbxVojFWqYULSMKFpwoaOKFuFDsKuwK2Bilx xVb3wsX/1ulkZnOA1ihxxVrCrsVbwK2MUt4EupirsVdihqmFW8CXYq7FDsUtjAq7FK4YEtjAlvAl vFXYq6mKtgYFbxS7FXYq0cVWnChaRkkLTixW4UOxVwGKrsUtHFVtMLF//9fphzNcBrCho4q1hQ4Y q3XAlsYpbwK6uKXYq7FDsUuxQ7FXYq7FVwwMlwwJbAwJXAYEt0xVumBXUxS6mKuGKt4q7FXYq0cV W4ULTkmKwnChrCh1cCrhgS7Cl2KGu+KH/9DpmZrgOOKrDhQ1hQ3irhgS3irq4q6uKt1xVsYEuxS7 FXYq3irYGBK4DAlumBVwxS2MCW8VdgS3irsVaxVvFXYq1XFWicKFhOFitOFC0nJIaxQ7FK8YEhdT Alo4qt74WL//0emZmuC7FC0jChrCrsVbwK1XFXYVdihwwJXDFLeBLeKuxVcBgS3TAlvAlvFW8Cux S2DirYwJbxV2KuxV2KuOKrScKFpOFC0nChaThQtwodireKrgMCV2RS474VW8TXrhtFP/0umHM1wG jhV2KupirqYq0RihrCrWKHYq3ileMilsDAlcMCXYpbAxVdgS6mKuGKt4Fdirq4VXA5FLeKXYq3gV 2KWjhQsyTEqZOSYra4ocThVrFW8Ct0xSuGBLeBWiaYVW8sNIt//T6YRma4LsUOxV2KXYq0cUNEYU NYVaxQuGBK7AyXDAlvAlvFW8VbGBLsVdirq4q1ihsYpXDAldgS7FXYq7FWicKrGwsSsOFitySGsV bwK7FVwwJbril1cVccVW079sNof/1OmGtMzXAarhVvAlcBgV1MVawq1TFDVMK07jja06mKtjAlcM CW8CW8Vdirq4q3XFXYFdirsVbxSuGBK7AlwxVxxVquKrSckxWnChbhVo4oapih2KuxVvFWxgS3TF LqYFaoOnbwySH//V6Z45muA0BhVcBgSuGRS7CrRxVrCh2KuwK7CrgMCrsUuxV2KuxV1cCuxVdgS3 il2KuxVcMCW8Ut1wK0Tiq2uFDRwoW4UNYVdih2KtUxQ6mKupirYwJXDAlvFKygrXvhYP/9bpmw+e ZrguxVcMCW8VdirsVdTArVMKHYq7FW8UuxV2KuxVrFW6YFdhVdgS3gS7FW8CuxS6uKt1xVquFDVc VW1woawodirsVdirsVdirhgV2KrhgS2TQVxSs2rywsX/1+m5muC1iq4YEt4q7FXYpdih2KupgV1M VdhV2KuxV2KuxV2KW6YFbxV2BW8Ut4FdirRwq1XFDq4VarirWFDsVdTArsKt0wJdirWFDsVdilvA rm3FBiFLu+Kv/9DpprXMxwGsKVwwK7FW8UuxV2Kt0wJbpirsVW4q7Ch2BLYxVumKtUxVvFXYFdhV 1cCt4pdirROKtYUNYUOxV2KuxV2KXYFXYq7ArVMKuxV2Ku7Yq1irt6e+KH//0emnrma4LWKuxVvF W64FdilcMCVwwJccVawoaxVrFW8VbwK2MUuxV1MVaxQ1hVvFXVwK6uFVtcUNVwq1XFDYxS3irsCt 0xS3TFXUwK3ilrFDRwq1hQ7FXYq7FX//0um9zma4LsVaxV2Kt4FbGKVwwJbwK3ilo4oawq1hQ2MC VwGBLsVdirsVaOFDWKt4q0cVW1woaJwoaxQ7FK4YEt4q3gS3irYwJbwK7FWjhVacKGsKGsVdXFXV xV//0+m5muA1ilvArsVbxVvFLYwJXYEuxVo4oW5JXYobGBK4YEuxV1cVaxQ44VW4q3XFWicKFuFD WKHYpdiq4YEt4q2MCW8Vb6YEt4EuOFC04oW4UOwq1irWKHdsVf/U6bma4LsVbwK6mKXAYq3irYwJ XYEuxVo4oaphV1MVdTFVwwJcTiq2uFDq4q7FWsUNE4VawoaxV2Kt4FbAxS3irYwJdTFW8Ct1xS1X FDq4pdhQtwoaxVonCh2Kt4Ff/9XpmZrgtjArYxS3irsVdirYwJbrirq4FbxS4jFWsUNjFLsVaOKF pwoarhVuuBWicKtYUNYq7FW8VbpgS3irsVcDgVuuKW8VaxV1cVbrirWKupirVMULSMkhrFW8Vf/W 6Zma4LYwK3il2Kt4q7FXYq6uBWxilcMCW8CtEYVaxVvFWjhQsJwsVuFW8VdirsVdgVumKXUxV2Kt 4q7FWsVbxVvAlrFXYq7CrsUN1wJaxVo4ULcKHYof/9fpmZrgtjpgVvFLeKuxVrFXYq1ihcMCVwwJ XYGTsUNYVdiq04QhZkmLWKHYpdirsVbwKuGBLsKuxV2KuxV2KtYq3irsUuxV2KHYq7FXYq1XFWsK GsVf/9DpoGZjgt4q7FLq4odil2Kt4qtxQ2MUrxgSuyKXYqtrhV2KHHCq0jChbhQ7FWsVbxV2KuxV sHAreKXYq7FXYq7FXYq7FLsCuwoaxVxOKGsKuxVrFXYq/wD/0emjpmY4LeKuxV2KuxS7FXVxVrFD YxSuGBK6uBLVcUOwq7FWicVawoaOKtUxQ3TFWqYq7CrWKt4quGRS7ClsDArqYq7FWsKuwK3irRxQ 1hQtOFXYodirsUuxV//S6dmY4LsVdTFW6YEtHCrWKHYq7CrYwK3iybrgV1cVawq3gVrCh2KuxV2K uxV2KtHFDWFXAYFXDAluhGLJvAh2KtHCrWFWxgVxxVaSMKGsKGsVdTFXHFDsVdil/9Pp1MzHCbAx V2BXYVaOKtYodirsVcMVXVxS6uKuqMVdUYq7FXYq1irq4q7FWxgV2FLsUNEV2xQuQb79sBLIBcSS SCMCW9sCt7YpawoWmlcVcAK4UNbYqtNKYUNbYodirsKuxV1MCXYUOxV//9TqG2ZbhuxV2BXYVccV LWFDRxVrfFDsKtYq2OuKuHfFWx0wK75YpbFMCu2xV2KtbYVbxVv4cCW9sVb22wJbwJdhVoVxQ3ir RxVw98Vawq12xQ44q0cKtHFDWKGsKt4EtiuKt4q//9k= ------=_NextPart_000_0149_01C21154.3ADAFB70-- From owner-ipsec@lists.tislabs.com Tue Jun 11 06:37:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BDbKn02575; Tue, 11 Jun 2002 06:37:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07219 Tue, 11 Jun 2002 08:55:06 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Mon Jun 10 16:10:17 2002 Subject: RE: PMTU and NAT-Traversal problem From: Jan Backman To: ipsec@lists.tislabs.com Date: Mon, 10 Jun 2002 13:59:55 +0200 X-Mailer: NIMS ModWeb Module X-Sender: jan.backman@home.se MIME-Version: 1.0 Message-ID: <1023710395.48f4bcc0jan.backman@home.se> 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 HAA04716 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Store the information about the encountered MTU in the NAT and use it to reply an ICMP when the next packet in the flow arrives (that is larger than the MTU). regards /// Jan > -----Original Message----- > From: Lokesh [mailto:lokeshnb@intotoinc.com] > Sent: Monday, June 10, 2002 12:34 PM > To: ipsec@lists.tislabs.com > Subject: PMTU and NAT-Traversal problem > > > Hi all, > Is there anybody who implemented following in a security Gateway? > 1. draft-ietf-ipsec-nat-t-ike-01.txt and > draft-ietf-ipsec-udp-encaps-01.txt > 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). > if so, how did you solve following problem?......... > > For Unauthenticated ICMP PMTU message processing: > > The PMTU processing bound to fail, since ICMP PMTU error > message would > include > only IP Hdr and 64 bits of IPsec Hdr information. Since UDP > Encaps and NAT > Traversal drafts encapsulate ipsec packets in UDP and put a 8 > byte NON IKE > marker,(totalling 16 bytes) > PMTU error message returned will not have enough information > to find the > SA's at the receiving > Security Gateway. How to solve this problem? any suggestions? > any help in this regard is highly appreciated. > Thanks > Lokesh > From owner-ipsec@lists.tislabs.com Tue Jun 11 10:18:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BHIxn16425; Tue, 11 Jun 2002 10:18:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07717 Tue, 11 Jun 2002 12:36:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <15613.19960.911915.806008@thomasm-u1.cisco.com> References: <79FEAA5FABA7D411BF580001023D1BBD0174ABA7@mailserver.sylantro.com> <15613.19960.911915.806008@thomasm-u1.cisco.com> Date: Tue, 11 Jun 2002 12:47:38 -0400 To: Michael Thomas From: Stephen Kent Subject: RE: Public Keys to initiate IPsec. Cc: "'ipsec@lists.tislabs.com '" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:32 PM -0700 6/4/02, Michael Thomas wrote: >Stephen Kent writes: > > This sounds like a problem re using IPsec. After establishing an SA, > > we check inbound traffic on the SA (from the peer) to make sure it is > > consistent with the parameters for the SA. We can check only the 5 > > fields that are defined as traffic selectors. So, you could be > > spoofed by a peer who authenticates as one MGCP endpoint ID, then > > sends a message with a different MGCP name in the MCGP message. This > > is outside the realm of what IPsec can do for you. You would have to > > remember the MGCP name from the SA establishment for later > > application layer checking, and there is no standard interface that > > passes that info to your application. > >This is why I keep saying that it would be rilly, >rilly nice to have this interface from the kernel >(ideally, but could be with the keying daemon >too). Nor do I see this as "outside" of what IPsec >can do for you in the sense you seem to be using >"outside". It's a missing feature on what my >kernel/key daemon can do for me. There's nothing >*wrong* with sending the credentials associated >with a particular message up the stack. > >I'm just about ornery enough hack this into our >Altiga shim just to prove it can be done and is -- >ta da -- useful for all of the reasons that Eric >brought up. > > Mike Mike, I used the term "outside" in two senses: First, the IPsec standards, like most of those in the IETF, focus on interoperability between systems, not on APIs within a system. Second, the checking that could be done if an API provided the authentication data is outside of the scope of IPsec, i.e., it has become the responsibility of the application. I did not mean to suggest that there is no benefit to having this sort of API, just pointing out that APIs for IPsec are not currently within scope for the WG. Steve From owner-ipsec@lists.tislabs.com Tue Jun 11 11:07:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BI7Ln20969; Tue, 11 Jun 2002 11:07:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07847 Tue, 11 Jun 2002 13:27:29 -0400 (EDT) From: "Theodore Ts'o" To: jis@mit.edu, smb@research.att.com cc: byfraser@cisco.com, ipsec@lists.tislabs.com cc: ietf-secretariat@ietf.org Subject: draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt Phone: (781) 391-3464 Message-Id: Date: Tue, 11 Jun 2002 13:39:52 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jeff, Steve, draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt has gone through working group last call, and is ready to be submitted for IETF last call and to the IESG for consideration as an Proposed Standard. Could you please inform the secretariat to kick off the process for this draft? Many thanks! n.b. The other cipher I-D's, draft-ietf-ipsec-ciph-aes-cbc-03.txt, draft-ietf-ipsec-ciph-sha-256-00.txt are currently expired. We are currently waiting on Sheila to update the test vectors and make a few other minor changes. At that point the revised I-D's will be going to working group last call. - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Jun 11 11:24:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BIOdn21900; Tue, 11 Jun 2002 11:24:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07881 Tue, 11 Jun 2002 13:41:41 -0400 (EDT) Message-ID: <3D06395A.D87D7D9D@cisco.com> Date: Tue, 11 Jun 2002 10:54:34 -0700 From: Thien Do Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: GF field elements for AES Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I am having difficulty in generating the field elements as specified by the AES standard. I seem to have the elements repeating itself at the 51th place. If anyone has any experiences with this please let me know. Thanks -Thien From owner-ipsec@lists.tislabs.com Tue Jun 11 11:50:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BIosn22423; Tue, 11 Jun 2002 11:50:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07920 Tue, 11 Jun 2002 14:13:06 -0400 (EDT) From: "Theodore Ts'o" To: jis@mit.edu, smb@research.att.com cc: byfraser@cisco.com, ipsec@lists.tislabs.com, ietf-secretariat@ietf.org cc: kivinen@ssh.fi Subject: Ready for IETF last call: draft-ietf-ipsec-ike-modp-groups-04.txt Phone: (781) 391-3464 Message-Id: Date: Tue, 11 Jun 2002 14:25:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Jeff, The I-D draft-ietf-ipsec-ike-modp-groups-04.txt has been through working group last call, and with no comments against it, it is ready to go to IETF last call and for consideration by the IESG for Proposed Standard. The draft is still missing IANA assignments for some of the groups in the document, which we asked Tero to work on obtaining from the IANA. This has not been accomplished yet, but we believe this can be addressed in parallel with the IETF last call and IESG consideration period. - Ted From owner-ipsec@lists.tislabs.com Tue Jun 11 12:09:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BJ9nn22773; Tue, 11 Jun 2002 12:09:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07975 Tue, 11 Jun 2002 14:31:15 -0400 (EDT) Message-ID: <3D064501.7020306@juniper.net> Date: Tue, 11 Jun 2002 11:44:17 -0700 From: Abraham Shacham User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020209 X-Accept-Language: en-us MIME-Version: 1.0 To: Joachim =?ISO-8859-1?Q?Abrahms=E9n?= CC: ipsec mailing list , ippcp@external.cisco.com Subject: Re: IPComp CA and IPsec SA negotiations References: <3D04A889.F9ACD7E9@steria.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by merlot.juniper.net id g5BIiIm04756 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA07970 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joachim, From following the interoperabilty tests of IPComp in the context of IPsec, it seems that very few implementations support the negotiation of a standalone IPComp, and most support the negotiation with ESP in a Protection Suite, i.e. a bundle. Regards, avram Joachim Abrahmsén wrote: > We're about to implement support for compression into our VPN-product, > but can't quite figure out how to extend the IKE negotiation in order to > include IPComp. > > RFC 3173 section 4.1 says > "For IPComp in the context of IP Security, IKE provides the necessary > mechanisms and guidelines for establishing IPCA. Using IKE, IPComp > can be negotiated as stand-alone or in conjunction with other IPsec > protocols." > > What I want is to _use_ IPComp in conjuntion with other IPsec (in my > case ESP) protocols. > > If I interpret this correctly I may do it either way; negotiating them > as two separate SA, possibly as two SA payloads in the same QM > negotiation, or as a SA boundle with ESP and IPComp in the same > proposal. > I would prefer to negotiate them separately, since I don't wan't the > whole negotiation to fail because the peer doesn't support IPComp, and I > would prefer not to duplicate my proposals (with and without IPComp). > > What is common practise? > > Thanks in advance > > -Joachim > > > > From owner-ipsec@lists.tislabs.com Tue Jun 11 13:54:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BKsmn27235; Tue, 11 Jun 2002 13:54:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08261 Tue, 11 Jun 2002 16:09:41 -0400 (EDT) Message-ID: <20020611202232.75100.qmail@web13105.mail.yahoo.com> Date: Tue, 11 Jun 2002 16:22:32 -0400 (EDT) From: Ken E Subject: IPSec management via pf_key To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am evaluating the PF_KEY protocol to use with an IPSec implementation / IKE Daemon and have the following questions. - There are no provisions in the SADB_ACQUIRE to pass phase 1 specific parameters to the IKE Daemon (i.e. shared secret, cert related data). Have there been any developments in PF_KEY (or related protocols) to accomodate this? - There doesn't appear to be any support for SA bundles? - Looking through the archives, it appears that some vendors have implemented / suggested using proprietary extensions to PF_KEY. What is the preferred method of adding extension messages that will not overlap with other proprietary implementations? This will obviously break any interoperability!! - There was some mention in the archives of a PF_POLICY protocol to interact with the SPD - any update on this? Obviously, I can go ahead and define my own proprietary protocol / extension to cater for my requirements, but would prefer to use any existing standard, if available. Any help on this will be appreciated. Thanks in advance... Ken ______________________________________________________________________ Movies, Music, Sports, Games! http://entertainment.yahoo.ca From owner-ipsec@lists.tislabs.com Tue Jun 11 18:07:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C17cn03167; Tue, 11 Jun 2002 18:07:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08730 Tue, 11 Jun 2002 20:25:07 -0400 (EDT) Date: Tue, 11 Jun 2002 17:37:46 -0700 (PDT) From: Brett Eldridge X-X-Sender: beldridg@argon.lo0.org To: ipsec@lists.tislabs.com Cc: beldridg@pobox.com Subject: draft-ietf-ipsec-properties Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, i'm not sure where else to go since the draft has expired and i tried writing the author at the address given in the draft, but they must have changed addresses. : host ns02.newbridge.com[192.75.23.75] said: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) does anybody have a copy of draft-ietf-ipsec-properties-02.txt or know where i can reach the author? - brett From owner-ipsec@lists.tislabs.com Tue Jun 11 18:31:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C1Vun03791; Tue, 11 Jun 2002 18:31:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08819 Tue, 11 Jun 2002 20:52:08 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: Son of IKE: A proposal for moving forward Phone: (781) 391-3464 Message-Id: Date: Tue, 11 Jun 2002 21:04:55 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few weeks ago, a group of people composed of folks from the IKEv2 and JFK camps, plus one or two interested observers (such as Paul Hoffman) got together and created a "SOI-features" document. This document was supposed to contain a comparison of the two proposals, and a set of alternatives which the IPSEC working group was supposed to consider and select between. Once the IPSEC wg had answers the questions contained in this draft, this design team had promised to craft a combined, compromise protocol which reflected the desire of the working group with respect to certain key requirements questions. Unfortunately, there has not been much in the way of responses to this draft. In attempt to try to drive this process forward, Barbara and I have distilled a set of short, succinct questions which were implicit in the soi-features I-D. We have also correlated implications from the IKE requirements documents as listed in section 9 of the soi-features I-D. (Some of the highlighted links in section didn't really make sense to us when we did this exercise, but we just cut and pasted from section 9 to the relevant set of questions from sections 2 through 6. If folks could help us fill in the "implications from scenarios" section with references to Cheryl Madson's requirements document, we would greatly appreciate it. Ideally for each question and each sceario, we should be able to state whether a particular scenario requires a "yes", "no", or "don't care' answer for each question. Help in providing these answers will make the working group's job much easier.) What we next propose to do is to feed these questions to the working group in piece meal fashion --- every day, we will send one or more subsection's worth of questions to the mailing list, and we will expect the working group to look at these questions (which hopefully will be a little more digestible than the original soi-features draft) and provide answers to them. If we do not receive answers, Barbara and I reserve the right to choose answers to these questions ourselves, possibly using a coin flip if we feel so motivated. :-) Before we start this process, we would like the working group to look over this overall set of questions, and tell us if we have properly distilled them from the soi-features draft, and whether any questions might be missing from this set. There are a few places where the soi-features draft went in very great detail about how JFK or IKEv2 implemented a particular feature, but we wouldn't see any real difference between the two design choices. Hence, there was no real question to be asked by the working group. If the JFK or IKE teams feel that we have missed some point about how their proposal is overwhelmingly superior, please tell us what we missed, and please suggest an alternate question for that subsection. Please send us comments by the end of this week (i.e., June 14th) if at all possible; we'd like to start the process of feeding individual questions to the ipsec mailing list next week (i.e., starting Monday, June 17th) - Ted and Barbara ---------------------------- Questions derived from the SOI Features document Created by Barbara Fraser and Theodore Ts'o 2. Cryptographic features 2.1 Identity protection: who is protected, kinds of attacks 2.1.A.) Does SOI need to provide protection against passive attacks for the initiator? 2.1.B.) Does SOI need to provide protection against active attacks for the initiator? 2.1.C.) Does SOI need to provide protection against passive attacks for the responder? 2.1.D.) Does SOI need to provide protection against active attacks for the responder? Implications from the Scenarios: VPN: <<>> [[[2.1]]] End-to-End: <<>> [[[2.1]]] ----------------------------------------------------------- 2.2 Perfect forward secrecy (PFS) 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward secrecy" by trading off performance versus the level of PFS provided. The funcitonality provided is roughly identical. Does anyone care about the details of how IKEv2 versus JFK provides this functionality? Should we just flip a coin? Implications from the Scenarios: [none] ----------------------------------------------------------- 2.3 Authentication styles 2.3.A.) Does SOI need to natively support "legacy authentication systems"? 2.3.B.) Does SOI need to natively support some kind of "shared secret" scheme? (Note. If SOI is provides cert-only, then one would need to use another protocol to bootstrap certificates from a legacy authentication or shared secret scheme.) Implications from the Scenarios: VPN: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] ----------------------------------------------------------- 2.4 Number of crypto operations 2.4.A) JFK requires substantially more cryptographic operations for rekeying (two more signatures, two more signature validations, and three more hashes). Is this a problem? More generally, does SOI need to be able to support "fast" rekeying? ----------------------------------------------------------- 2.5) Plausible denaibility 2.5.A) Does SOI need to provide "plausible deniability" (the opposite of "non-repudiation") for the initiator? 2.5.B) Does SOI need to provide "plausible deniability" (the opposite of "non-repudiation") for the responder? Implications from the Scenarios: [none] ----------------------------------------------------------- 2.6 Formal proofs of security 2.6.A) Does SOI need to provide a formal proof of security? (Is this a "must have" or a "nice to have"? What are we willing to trade-off for having a formal proof of security?) Implications from the Scenarios: [none] ------------------------------------------------------------- 3. Protocol mechanics 3.1 DoS protection 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more important to always keep the message count at 4, or is it acceptable to add an additional roundtrip of messages when the responder thinks he's under attack? 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide basically equivalent protection. Does anyone care about the details of how JFK or IKEv2 provide this functionality. 3.1.C) Is it important to have precomputation of exponentials available for use as a mechanism for protecting against cpu consumption attacks? Implications from the scenarios: [none] -------------------------------------- 3.2 Number of messages in all scenarios 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in message one. In IKEv2 if Bob doesn't accept what Alice offers the negotiation starts again. In JFK if Bob doesn't accept what Alice offers but Alice can live with what Bob offers, they continue. Otherwise they start over. Is this an important feature for SOI? Implications from the scenarios: SRA: <<>> [[[3]]] See also 4.2, 2.4 -------------------------------------- 3.3 Size of messages There is no significant difference in the size of messages in the two protocols. Implications from the scenarios: [none] -------------------------------------- 3.4 Preferred ID for responder 3.4.A) In JFK and IKEv2, the initiator can include a payload is an indication to the responder as to what identity (and corresponding key material) the responder should use to authenticate to the initiator. In JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent in the clear in message 1, thereby allowing a passive attack on the responder's likely identity. Is it important to encrypt this identity? Implications from the scenarios: [none] -------------------------------------- 3.5 Birth certificates See 4.3 for discussion on this and DPD ----------------------------------------------------------- 4. One or two phases 4.1 Control channel vs. separate protocols 4.1.A) [Meta question, that will be answered by the other questions in section 4.] Does SOI need a control channel for SA management? Or is it acceptable to piggy back SA management as a part of other parts of the SOI protocol? Implications from the Scenarios: VPN: <<>> [[[4.1]]] ----------------------------------------------------------- 4.2 Creating multiple SAs for a single pair of entities 4.2.A) How important is it that SOI be able to create multiple SA's between a pair of entities "cheaply"? 4.2.B) How often will usage scenarios of SOI need to generate multiple SA's between a single pair of entites? Implications from the Scenarios: VPN: <<>> [[[4.2]]] VPN, End-to-END, SRA : <<>> [[[4.2]]] SRA: <<>> [[[4.2]]] SRA: <<>> [[[4.2]]] ----------------------------------------------------------- 4.3 Dead peer detection 4.3.A) Both JFK and IKEv2 provide dead peer detection via a "keep-alive" mechanism. The functionality provided is roughly identical. Does anyone care about how low-level implementation details of IKEv2 and JFK? 4.3.B) Should the working group consider other schemes which provide the same functionality as dead peer detection? (i.e., birth certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) Implications from the Scenarios: [none] ----------------------------------------------------------- 4.4 SA deletion 4.4.A) Both JFK and IKEv2 provide SA deletion. The functionality provided is roughly identical. Does anyone care about how low-level implementation details of IKEv2 and JFK? Implications from the Scenarios: [none] ----------------------------------------------------------- 4.5 SA rekeying 4.5.A) Both JFK and IKEv2 provide SA rekeying. The functionality provided is roughly identical, although JFK requires more cryptographic operations to do rekeying (see 2.4). Does anyone care about how low-level implementation details of IKEv2 and JFK? Implications from the Scenarios: [none] ----------------------------------------------------------- 4.6 Authenticated error messages 4.6.A) Both JFK and IKEv2 provide authenticated error messages. The functionality provided is roughly identical, although details very different due to the lack of a 2 phase protocol in JFK. Does anyone care about how low-level implementation details of IKEv2 and JFK? Implications from the Scenarios: [none] ----------------------------------------------------------- 4.7 Authenticated informational messages 4.7.A) Does SOI need to provide authenticated informational messages after an IKE SA has been set up? (What sort of informational messages might be needed? Do they need to be protected in a different key than the SA key?) Implications from the Scenarios: [none] ----------------------------------------------------------- 5. SA creation style 5.1 Cryptographic agreement 5.1.A)Is negotiation for the algorithm suite required or not? 5.1.B) Is there ever a case when you want the initiator to have the "last word"? Implications from the scenarios: [none] -------------------------------------- 5.1.2 Agreement of IPsec SA cryptographic algorithms JFK's SA negotiation uses pre-defined suites, and Bob presents a single suite to Alice. In IKEv2 SA negotiation allows the two parties to agree on the most preferred parameters, the same as it does for key negotiation. 5.1.2.A) Is it important to allow negotiation of the SA algorithms? Implications from the scenarios: [none] -------------------------------------- 5.2 Scope of proposals 5.2.A) Is it important to have predefined suites or a la carte selection of parameters? Implications from the scenarios: [none] -------------------------------------- 5.3 SPD entries 5.3.A) Is it important in SOI to allow the the responder to accept a subset of the proposed SA, or should it be an all or nothing acceptance? 5.3.B) Should the SOI offer multiple selectors with specific ports and addresses, or a single selector with a range of ports and range of addresses? (complicated boolean complexity!) Implications from the scenarios: <<>> [[[5.3]]] -------------------------------------- 6. Wire protocol issues 6.1 Message encoding 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 byte boundaries? 6.1.B) Should SOI tag its protocol with version numbers? 6.1.C) Should SOI format be roughly the same as IKEv1? (See discussion in section 6.4, re: code preserving) Implications from the Scenarios: ----------------------------------------------------------- 6.2 Port number 6.2.A) Should SOI use the same port as IKEv1? (See discussion in soi-features-01 the tradeoffs in this question). Implications from the Scenarios: [none] ----------------------------------------------------------- 6.3 Future versions of the protocols 6.3.A) Should SOI have a mechanism for demanding/requesting that a peer use a particular version of IKE/SOI to allow upgrading to new versions? Implications from the Scenarios: [none] ----------------------------------------------------------- 6.4 Code-preservingness 6.4.A) Is it important that SOI allow some amounts of an IKEv1 implementation be reusable when creating an SOI implementation? Implications from the Scenarios: IPS: <<<[ietf-ips-security-xx.txt] discusses resource constraints, calling out the size for both code footprint and data as the most important criteria.>>> [[[6]]] ----------------------------------------------------------- 6.5 Extensibility of the protocols 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI protocol? 6.5.B) Should SOI need a way to mark new extensions as critical? (i.e. If you don't understand a critical extension you must fail the entire negotiation) Implications from the Scenarios: VPN, End-to-End, : <<>> [[[6.5]]] IPS: <<>> [[[6.5]]] PPVPN/MPLS: <<>> [[[6.5]]] Implications from the Scenarios: [none] ----------------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Jun 11 18:47:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C1ljn04082; Tue, 11 Jun 2002 18:47:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08847 Tue, 11 Jun 2002 20:59:13 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Tue Jun 11 19:18:48 2002 Message-ID: <3D06395A.D87D7D9D@cisco.com> Date: Tue, 11 Jun 2002 10:54:34 -0700 From: Thien Do Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: GF field elements for AES Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I am having difficulty in generating the field elements as specified by the AES standard. I seem to have the elements repeating itself at the 51th place. If anyone has any experiences with this please let me know. Thanks -Thien From owner-ipsec@lists.tislabs.com Wed Jun 12 07:26:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CEQvn00706; Wed, 12 Jun 2002 07:26:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10268 Wed, 12 Jun 2002 09:33:21 -0400 (EDT) Reply-To: From: "mohiniclj" To: Subject: IPSec support for IPv6 Date: Wed, 12 Jun 2002 16:58:19 +0530 Message-Id: <002b01c21204$41c824c0$3706140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C21232.5B8060C0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C21232.5B8060C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, I'm trying to do interop with IPv6 with IPSec support. I'm using Cisco 2600 series with IOS version 12.2 T. It has support for IPv6. But I couldn't find commands for configuring IPSec for IPv6. For example configuring the peer address using the set peer command. The link http://www.cisco.com/univercd/cc/td/doc/pcat/iossw.htm#xtocid7 says that one of the Key Benefits of IPv6 is Integrated support for IP Security (IPSec) and mobile IP as "native" IPv6 features. I would like to know what is the Cisco IOS version I'm supposed to use, to support IPSec for IPv6 datagrams if anyone has tried this. Any help in this regard is highly appreciated. thanks in advance, Mohini *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_002C_01C21232.5B8060C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 All, I'm = trying to do=20 interop with IPv6 with IPSec support. I'm using Cisco 2600 series with = IOS=20 version 12.2 T. It has support for IPv6. But I couldn't find commands = for=20 configuring IPSec for IPv6. For example configuring the=20 peer address using the set peer = command. The = link=20 <3d.htm>h= ttp://www.cisco.com/univercd/cc/td/doc/pcat/iossw.htm#xtocid7 says that one of the Key Benefits of = IPv6 is=20 Integrated=20 support for IP Security (IPSec) and mobile IP as "native" IPv6=20 features. I = would like to know=20 what is the Cisco IOS version I'm supposed to use, to support IPSec = for=20 IPv6 datagrams if anyone has tried this. Any = help in this=20 regard is highly appreciated. thanks = in=20 advance, Mohini ------=_NextPart_000_002C_01C21232.5B8060C0-- From owner-ipsec@lists.tislabs.com Wed Jun 12 07:27:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CER2n00728; Wed, 12 Jun 2002 07:27:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10254 Wed, 12 Jun 2002 09:31:21 -0400 (EDT) Message-ID: <00ff01c211f4$1a1fa890$0b00a8c0@BGABAYT20> From: "Benzy Gabay" To: Subject: strange behavior (of Cisco VPN) after 2 re-keys Date: Wed, 12 Jun 2002 11:32:42 +0200 Organization: Maya Software Technologies Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Clear Day Hi, I'm not sure if this question is suppose to be in this list. I'm trying my client against Cisco 3000 VPN. After doing successfully IKE (AM, QM) I'm getting after 2 rekeys a packet filled with "0" only. I could not find anywhere in the IKE RFC's that it suppose to happened. Did I missed something or is it Cisco propriety behavior? Thanks ============================== Benzy Gabay R&D Maya Software Technologies Ltd. http://www.maya-st.com Tel: + 972 9 956 01 35 Fax: + 972 9 955 96 54 mailto: bgabay@maya-st.com From owner-ipsec@lists.tislabs.com Wed Jun 12 10:17:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CHHOn10275; Wed, 12 Jun 2002 10:17:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10581 Wed, 12 Jun 2002 12:31:21 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.31302.924268.658298@thomasm-u1.cisco.com> Date: Wed, 12 Jun 2002 09:43:50 -0700 (PDT) To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Son of IKE: A proposal for moving forward In-Reply-To: References: 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 Ted, The one thing I don't see here is any consideration of the very basic question of whether there are in fact two different problem spaces. The slant of this working group is very VPN-centric, much to the burden of things which aren't especially interested in remote access, amortization of authentication expense, etc, etc. While this doesn't directly speak to favoring JFK or IKEv2, the design decisions of JFK are much more favorable to producing a streamlined key management protocol. The problem I see here is that almost any question you ask which implies added functionality is going to have _some_ constituency who is going to be extremely vocal about keeping their favorite feature (cf pre-shared keys, quick mode...). What is completely lost here is those implementations which *don't* need the added functionality and *don't* want the added cost both of complexity and footprint. As far as I can tell, this side of the argument is essentially voiceless. Mike Theodore Ts'o writes: > > A few weeks ago, a group of people composed of folks from the IKEv2 and > JFK camps, plus one or two interested observers (such as Paul Hoffman) > got together and created a "SOI-features" document. This document was > supposed to contain a comparison of the two proposals, and a set of > alternatives which the IPSEC working group was supposed to consider and > select between. Once the IPSEC wg had answers the questions contained > in this draft, this design team had promised to craft a combined, > compromise protocol which reflected the desire of the working group with > respect to certain key requirements questions. > > Unfortunately, there has not been much in the way of responses to this > draft. In attempt to try to drive this process forward, Barbara and I > have distilled a set of short, succinct questions which were implicit in > the soi-features I-D. We have also correlated implications from the IKE > requirements documents as listed in section 9 of the soi-features I-D. > (Some of the highlighted links in section didn't really make sense to us > when we did this exercise, but we just cut and pasted from section 9 to > the relevant set of questions from sections 2 through 6. If folks could > help us fill in the "implications from scenarios" section with references > to Cheryl Madson's requirements document, we would greatly appreciate > it. Ideally for each question and each sceario, we should be able to > state whether a particular scenario requires a "yes", "no", or "don't > care' answer for each question. Help in providing these answers will > make the working group's job much easier.) > > What we next propose to do is to feed these questions to the working > group in piece meal fashion --- every day, we will send one or more > subsection's worth of questions to the mailing list, and we will expect > the working group to look at these questions (which hopefully will be a > little more digestible than the original soi-features draft) and provide > answers to them. If we do not receive answers, Barbara and I reserve > the right to choose answers to these questions ourselves, possibly using > a coin flip if we feel so motivated. :-) > > Before we start this process, we would like the working group to look > over this overall set of questions, and tell us if we have properly > distilled them from the soi-features draft, and whether any questions > might be missing from this set. There are a few places where the > soi-features draft went in very great detail about how JFK or IKEv2 > implemented a particular feature, but we wouldn't see any real > difference between the two design choices. Hence, there was no real > question to be asked by the working group. If the JFK or IKE teams feel > that we have missed some point about how their proposal is > overwhelmingly superior, please tell us what we missed, and please > suggest an alternate question for that subsection. > > Please send us comments by the end of this week (i.e., June 14th) if at > all possible; we'd like to start the process of feeding individual > questions to the ipsec mailing list next week (i.e., starting Monday, > June 17th) > > - Ted and Barbara > > ---------------------------- > > Questions derived from the SOI Features document > Created by Barbara Fraser and Theodore Ts'o > > 2. Cryptographic features > > 2.1 Identity protection: who is protected, kinds of attacks > > 2.1.A.) Does SOI need to provide protection against passive > attacks for the initiator? > > 2.1.B.) Does SOI need to provide protection against active > attacks for the initiator? > > 2.1.C.) Does SOI need to provide protection against passive > attacks for the responder? > > 2.1.D.) Does SOI need to provide protection against active > attacks for the responder? > > Implications from the Scenarios: > > VPN: << protection of both IPsec endpoints is important.>>> [[[2.1]]] > > End-to-End: << desirable.>>> [[[2.1]]] > > > ----------------------------------------------------------- > 2.2 Perfect forward secrecy (PFS) > > 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward > secrecy" by trading off performance versus the level of PFS provided. > The funcitonality provided is roughly identical. Does anyone care > about the details of how IKEv2 versus JFK provides this functionality? > Should we just flip a coin? > > Implications from the Scenarios: > > [none] > > > ----------------------------------------------------------- > > 2.3 Authentication styles > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? > > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? > > (Note. If SOI is provides cert-only, then one would need to use > another protocol to bootstrap certificates from a legacy > authentication or shared secret scheme.) > > Implications from the Scenarios: > > VPN: << addresses cannot be used as phase 1 identifiers. This also means that > the authentication material cannot be chosen based upon the IP address > in the packet.>>> [[[2.3]]] > > SRA: << this policy information before the IPsec tunnel is constructed.>>> > [[[2.3]]] > > SRA: << accommodate re-authentication based on the RAS or authentication > server site security policy>>> [[[2.3]]] > > SRA: << location of the authentication server relative to the client and the > RAS. In many scenarios, server tends to be "behind" the RAS device, in > the domain that is being secured by the RAS, which may be problematic > for bootstrapping the user authentication for the client-to-RAS > connection.>>> [[[2.3]]] > > > ----------------------------------------------------------- > > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? > > ----------------------------------------------------------- > > 2.5) Plausible denaibility > > 2.5.A) Does SOI need to provide "plausible deniability" (the opposite > of "non-repudiation") for the initiator? > > 2.5.B) Does SOI need to provide "plausible deniability" (the opposite > of "non-repudiation") for the responder? > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 2.6 Formal proofs of security > > 2.6.A) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) > > Implications from the Scenarios: > > [none] > > ------------------------------------------------------------- > > 3. Protocol mechanics > > 3.1 DoS protection > > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more > important to always keep the message count at 4, or is it acceptable to add > an additional roundtrip of messages when the responder thinks he's under > attack? > > 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide > basically equivalent protection. Does anyone care about the details of how > JFK or IKEv2 provide this functionality. > > 3.1.C) Is it important to have precomputation of exponentials available for > use as a mechanism for protecting against cpu consumption attacks? > > Implications from the scenarios: > > [none] > > -------------------------------------- > > 3.2 Number of messages in all scenarios > > 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in > message one. In IKEv2 if Bob doesn't accept what Alice offers the > negotiation starts again. In JFK if Bob doesn't accept what Alice offers > but Alice can live with what Bob offers, they continue. Otherwise they > start over. Is this an important feature for SOI? > > Implications from the scenarios: > > SRA: << rapidly establish both the SOI and IPsec connections, without undue > impact on CPU and memory overhead. It's also desirable for each > exchange to have as few messages as possible, to help alleviate the > burst load on the RAS.>>> [[[3]]] See also 4.2, 2.4 > > > -------------------------------------- > > 3.3 Size of messages > > There is no significant difference in the size of messages in the two > protocols. > > Implications from the scenarios: > > [none] > > -------------------------------------- > > > 3.4 Preferred ID for responder > > 3.4.A) In JFK and IKEv2, the initiator can include a payload is an > indication to the responder as to what identity (and corresponding key > material) the responder should use to authenticate to the initiator. In > JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent > in the clear in message 1, thereby allowing a passive attack on the > responder's likely identity. Is it important to encrypt this identity? > > Implications from the scenarios: > > [none] > > -------------------------------------- > > > 3.5 Birth certificates > > See 4.3 for discussion on this and DPD > > > ----------------------------------------------------------- > > 4. One or two phases > > 4.1 Control channel vs. separate protocols > > 4.1.A) [Meta question, that will be answered by the other questions in > section 4.] Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? > > Implications from the Scenarios: > > VPN: << SOI, or a single-phased approach that is sufficiently fast, where > "fast" represents an optimal combination of "number of messages" and > "computational expenditure".>>> [[[4.1]]] > > > > ----------------------------------------------------------- > > 4.2 Creating multiple SAs for a single pair of entities > > 4.2.A) How important is it that SOI be able to create multiple SA's > between a pair of entities "cheaply"? > > 4.2.B) How often will usage scenarios of SOI need to generate multiple > SA's between a single pair of entites? > > Implications from the Scenarios: > > VPN: << total cost; this will be different for different mechanisms, which > results in a decision of scalability -vs- processing overhead. In > certain cases, it may be desirable to amortize the cost of the key > management across multiple tunnels.>>> [[[4.2]]] > > VPN, End-to-END, SRA : << tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels > needs to accommodate QoS information, predominantly in the set of > selectors used to identify the contents of any particular IPsec > tunnel.>>> [[[4.2]]] > > SRA: << within the SOI exchange, it's strongly encouraged that the protocol > directly or indirectly associate a single user authentication exchange > with a group of IPsec tunnels between a client and an RAS.>>> > [[[4.2]]] > > SRA: << client to present its identity (or some "blob of bits" that the server > can correctly map to an identity) early in the exchange.>>> [[[4.2]]] > > ----------------------------------------------------------- > > > 4.3 Dead peer detection > > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a > "keep-alive" mechanism. The functionality provided is roughly > identical. Does anyone care about how low-level implementation > details of IKEv2 and JFK? > > 4.3.B) Should the working group consider other schemes which provide > the same functionality as dead peer detection? (i.e., birth > certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 4.4 SA deletion > > 4.4.A) Both JFK and IKEv2 provide SA deletion. The functionality > provided is roughly identical. Does anyone care about how low-level > implementation details of IKEv2 and JFK? > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 4.5 SA rekeying > > 4.5.A) Both JFK and IKEv2 provide SA rekeying. The functionality > provided is roughly identical, although JFK requires more > cryptographic operations to do rekeying (see 2.4). Does anyone care > about how low-level implementation details of IKEv2 and JFK? > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 4.6 Authenticated error messages > > 4.6.A) Both JFK and IKEv2 provide authenticated error messages. The > functionality provided is roughly identical, although details very > different due to the lack of a 2 phase protocol in JFK. Does anyone > care about how low-level implementation details of IKEv2 and JFK? > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 4.7 Authenticated informational messages > > 4.7.A) Does SOI need to provide authenticated informational messages > after an IKE SA has been set up? (What sort of informational messages > might be needed? Do they need to be protected in a different key than > the SA key?) > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 5. SA creation style > > 5.1 Cryptographic agreement > > 5.1.A)Is negotiation for the algorithm suite required or not? > > 5.1.B) Is there ever a case when you want the initiator to have the "last > word"? > > Implications from the scenarios: > > [none] > > -------------------------------------- > > 5.1.2 Agreement of IPsec SA cryptographic algorithms > > JFK's SA negotiation uses pre-defined suites, and Bob presents a single > suite to Alice. In IKEv2 SA negotiation allows the two parties to agree on > the most preferred parameters, the same as it does for key negotiation. > > 5.1.2.A) Is it important to allow negotiation of the SA algorithms? > > Implications from the scenarios: > > [none] > > -------------------------------------- > > 5.2 Scope of proposals > > > 5.2.A) Is it important to have predefined suites or a la carte selection of > parameters? > > > Implications from the scenarios: > > [none] > > -------------------------------------- > > 5.3 SPD entries > > > 5.3.A) Is it important in SOI to allow the the responder to accept a subset > of the proposed SA, or should it be an all or nothing acceptance? > > 5.3.B) Should the SOI offer multiple selectors with specific ports and > addresses, or a single selector with a range of ports and range of > addresses? (complicated boolean complexity!) > > Implications from the scenarios: > > << subnets, a mechanism that allowed the negotiation of a list of phase 2 > identities will help to alleviate the number of IPsec tunnels that must > be created.>>> [[[5.3]]] > > -------------------------------------- > > 6. Wire protocol issues > > 6.1 Message encoding > > 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 > byte boundaries? > > 6.1.B) Should SOI tag its protocol with version numbers? > > 6.1.C) Should SOI format be roughly the same as IKEv1? (See > discussion in section 6.4, re: code preserving) > > Implications from the Scenarios: > > ----------------------------------------------------------- > > 6.2 Port number > > 6.2.A) Should SOI use the same port as IKEv1? (See discussion in > soi-features-01 the tradeoffs in this question). > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 6.3 Future versions of the protocols > > 6.3.A) Should SOI have a mechanism for demanding/requesting that a > peer use a particular version of IKE/SOI to allow upgrading to new > versions? > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- > > 6.4 Code-preservingness > > 6.4.A) Is it important that SOI allow some amounts of an IKEv1 > implementation be reusable when creating an SOI implementation? > > > Implications from the Scenarios: > > IPS: <<<[ietf-ips-security-xx.txt] discusses resource constraints, > calling out the size for both code footprint and data as the most > important criteria.>>> [[[6]]] > > > ----------------------------------------------------------- > > 6.5 Extensibility of the protocols > > 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI > protocol? > > 6.5.B) Should SOI need a way to mark new extensions as critical? > (i.e. If you don't understand a critical extension you must fail the > entire negotiation) > > Implications from the Scenarios: > > VPN, End-to-End, : << parameters are needed in order to negotiate QoS characteristics for > the various tunnels.>>> [[[6.5]]] > > IPS: << requirements for an API, in order to provide a means of pushing > authentication information to the application (e.g. "this peer was > authenticated with this cert"), so the application can decide what types > of transactions are allowed by this peer.>>> [[[6.5]]] > > PPVPN/MPLS: << identifiers to also support an MPLS/VPN identifier (so the entity > doing the SPD check can be separated from the entity doing the > encapsulation).>>> [[[6.5]]] > > Implications from the Scenarios: > > [none] > > ----------------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Jun 12 11:06:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CI6Yn12722; Wed, 12 Jun 2002 11:06:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10850 Wed, 12 Jun 2002 13:28:08 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.34715.623477.799435@thomasm-u1.cisco.com> Date: Wed, 12 Jun 2002 10:40:43 -0700 (PDT) To: uri@bell-labs.com Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: <200206121732.NAA21623@nwmail.wh.lucent.com> References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <200206121732.NAA21623@nwmail.wh.lucent.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 You get a self-fulfilling prophecy if your idea of "practical applicability" == "VPN". Which is exactly my point. Nobody's even considering any of the other intended applicability of IPsec when making decisions about how large the keying kitchen sink needs to be. Mike Uri Blumenthal writes: > On Wednesday 12 June 2002 12:43, Michael Thomas wrote: > > ......The slant of this working group is very > > VPN-centric, much to the burden of things which > > aren't especially interested in remote access, > > amortization of authentication expense, etc, etc. > > I'd rather say - the slant of this WG is towards the practical > industry-applicable, in other words usable in the field stuff, > for the *common* applications (such as VPN, remote access, > etc. etc). > > > While this doesn't directly speak to favoring JFK > > or IKEv2, the design decisions of JFK are much > > more favorable to producing a streamlined key > > management protocol. > > My personal first priority is usability+practicality, > streamlined-ness - only the second (that dies if > contradicts the first one). > > > What is completely lost here is those implementations > > which *don't* need the added functionality and > > *don't* want the added cost............ > > Most of the *practical* implementations need most of the features > that IKEv2 offers. [those features are there *for a reason*.] > > > Maybe another protocol should be designed - an extremely streamlined > almost-no-features protocol to satisfy your application needs? [I for > one won't implement it, but if market shares your need, there will > be room for it.] > -- > Regards, > Uri-David > -=-=-<>-=-=- > From owner-ipsec@lists.tislabs.com Wed Jun 12 11:12:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CICpn12889; Wed, 12 Jun 2002 11:12:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10861 Wed, 12 Jun 2002 13:29:05 -0400 (EDT) Message-Id: <200206121732.NAA21623@nwmail.wh.lucent.com> Content-Type: text/plain; charset="iso-8859-1" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Michael Thomas Subject: Re: Son of IKE: A proposal for moving forward Date: Wed, 12 Jun 2002 13:31:27 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: <15623.31302.924268.658298@thomasm-u1.cisco.com> In-Reply-To: <15623.31302.924268.658298@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA10764 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 12 June 2002 12:43, Michael Thomas wrote: > ......The slant of this working group is very > VPN-centric, much to the burden of things which > aren't especially interested in remote access, > amortization of authentication expense, etc, etc. I'd rather say - the slant of this WG is towards the practical industry-applicable, in other words usable in the field stuff, for the *common* applications (such as VPN, remote access, etc. etc). > While this doesn't directly speak to favoring JFK > or IKEv2, the design decisions of JFK are much > more favorable to producing a streamlined key > management protocol. My personal first priority is usability+practicality, streamlined-ness - only the second (that dies if contradicts the first one). > What is completely lost here is those implementations > which *don't* need the added functionality and > *don't* want the added cost............ Most of the *practical* implementations need most of the features that IKEv2 offers. [those features are there *for a reason*.] Maybe another protocol should be designed - an extremely streamlined almost-no-features protocol to satisfy your application needs? [I for one won't implement it, but if market shares your need, there will be room for it.] -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Wed Jun 12 11:46:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIk2n13602; Wed, 12 Jun 2002 11:46:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10935 Wed, 12 Jun 2002 13:56:19 -0400 (EDT) To: Michael Thomas Cc: uri@bell-labs.com, ipsec@lists.tislabs.com, guttman@mitre.org (Joshua D. Guttman) Subject: Re: Son of IKE: A proposal for moving forward Reply-To: guttman@mitre.org (Joshua D. Guttman disp: current) References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <200206121732.NAA21623@nwmail.wh.lucent.com> <15623.34715.623477.799435@thomasm-u1.cisco.com> From: guttman@mitre.org (Joshua D. Guttman) Date: 12 Jun 2002 14:08:39 -0400 In-Reply-To: <15623.34715.623477.799435@thomasm-u1.cisco.com> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > > You get a self-fulfilling prophecy if your idea of > "practical applicability" == "VPN". Which is > exactly my point. Nobody's even considering any of > the other intended applicability of IPsec when > making decisions about how large the keying > kitchen sink needs to be. I think it would be useful (certainly to me, but probably to others as well) to have a few quick descriptions of the other scenarios you've got in mind. That would help me understand what protocol features would count for the broader notion of "practical applicability". Or if several have already been described somewhere, then a pointer would do the trick. Thanks -- Joshua -- Joshua D. Guttman MITRE, Mail Stop S119 Office: +1 781 271 2654 202 Burlington Rd. Cell: +1 781 526 5713 Bedford, MA 01730-1420 USA Fax: +1 781 271 8953 From owner-ipsec@lists.tislabs.com Wed Jun 12 12:49:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJnXn16458; Wed, 12 Jun 2002 12:49:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11068 Wed, 12 Jun 2002 15:10:07 -0400 (EDT) Message-Id: <200206121902.PAA13460@nwmail.wh.lucent.com> Content-Type: text/plain; charset="iso-8859-1" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Michael Thomas Subject: Re: Son of IKE: A proposal for moving forward Date: Wed, 12 Jun 2002 15:02:02 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: <200206121732.NAA21623@nwmail.wh.lucent.com> <15623.34715.623477.799435@thomasm-u1.cisco.com> In-Reply-To: <15623.34715.623477.799435@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA11025 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 12 June 2002 13:40, Michael Thomas wrote: > You get a self-fulfilling prophecy if your idea of > "practical applicability" == "VPN". My idea of "practical applicability" is "it must support VPN". Not "equal" but "includes". And if your idea of applicabilty excludes VPN, we are not on the same page. -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Wed Jun 12 12:50:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJo2n16479; Wed, 12 Jun 2002 12:50:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11045 Wed, 12 Jun 2002 15:04:04 -0400 (EDT) Date: Wed, 12 Jun 2002 12:16:48 -0700 (PDT) From: Jan Vilhuber To: "Joshua D. Guttman" cc: Michael Thomas , , Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Cheryl tried to put together a requirements/scenario document. You can find it here. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt It tries to list all scenarios we could think of. Some of the are mutually exclusive, but there for completeness. Feel free to provide feedback and comments on any scenarios there or add some if we missed any. jan On 12 Jun 2002, Joshua D. Guttman wrote: > Michael Thomas writes: > > > > > You get a self-fulfilling prophecy if your idea of > > "practical applicability" == "VPN". Which is > > exactly my point. Nobody's even considering any of > > the other intended applicability of IPsec when > > making decisions about how large the keying > > kitchen sink needs to be. > > I think it would be useful (certainly to me, but probably to others as > well) to have a few quick descriptions of the other scenarios you've > got in mind. That would help me understand what protocol features > would count for the broader notion of "practical applicability". > > Or if several have already been described somewhere, then a pointer > would do the trick. > > Thanks -- > > Joshua > -- > Joshua D. Guttman > MITRE, Mail Stop S119 Office: +1 781 271 2654 > 202 Burlington Rd. Cell: +1 781 526 5713 > Bedford, MA 01730-1420 USA Fax: +1 781 271 8953 > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Wed Jun 12 13:28:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CKS1n18567; Wed, 12 Jun 2002 13:28:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11154 Wed, 12 Jun 2002 15:49:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15623.31302.924268.658298@thomasm-u1.cisco.com> References: <15623.31302.924268.658298@thomasm-u1.cisco.com> Date: Wed, 12 Jun 2002 13:02:09 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Son of IKE: A proposal for moving forward Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:43 AM -0700 6/12/02, Michael Thomas wrote: >The one thing I don't see here is any >consideration of the very basic question of >whether there are in fact two different problem >spaces. There are certainly more than two. Michael is correct here in that we cannot evaluate the WG questions for the general problem of keying all possible uses of IPsec. Well, we can try, but it would be a waste of time (but typical of many IETF Working Groups...). At the end of the effort, we would probably have no general agreement on the significant questions. Having said that, and showing my obvious bias towards VPNs, I propose that as we answer the questions, we do so with today's VPN customers in mind. These folks mostly do two things: a) gateway-to-gateway, with each gateway possibly connecting to many other gateways b) access over modems (or faster) from remote single-user computers Let's get SOI done right for these customers. Doing so doesn't prevent work from a different key exchange mechanism that addresses a different use case; the most obvious one that probably won't match with the use case above is remote access where there is a need for very quick keying, or where the remote parties have relatively slow CPUs, or where the remote parties have only small amounts of program memory, or some combination of these. The work we have done in the past few months can help focus the feature sets for each of these efforts, as well as for other efforts that might arise later. But let's not pretend that we can do it all at once in a single protocol -- we know we can't, and we have good evidence that we can waste a lot of time trying. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 12 14:32:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLWHn20052; Wed, 12 Jun 2002 14:32:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11314 Wed, 12 Jun 2002 16:55:01 -0400 (EDT) Date: Wed, 12 Jun 2002 17:06:25 -0400 From: "Theodore Ts'o" To: Jan Vilhuber Cc: "Joshua D. Guttman" , Michael Thomas , uri@bell-labs.com, ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward Message-ID: <20020612210625.GA824@think.thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jun 12, 2002 at 12:16:48PM -0700, Jan Vilhuber wrote: > Cheryl tried to put together a requirements/scenario document. You can > find it here. > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt > > It tries to list all scenarios we could think of. Some of the are > mutually exclusive, but there for completeness. Feel free to provide > feedback and comments on any scenarios there or add some if we missed > any. Absolutely. This document has been available for quite some time, and it is indeed designed to be a way in which the working group is supposed to judge SOI proposals. To that end, it's hard for me to credit the claims that the entire working group is VPN-centric, given that the document analyzes several scenarios, of which VPN is only one. > > Michael Thomas writes: > > > You get a self-fulfilling prophecy if your idea of > > > "practical applicability" == "VPN". Which is > > > exactly my point. Nobody's even considering any of > > > the other intended applicability of IPsec when > > > making decisions about how large the keying > > > kitchen sink needs to be. It is true that there is tension here, but I found it instructive that Michael's original message both talked about how the ipsec working group had made life for the remote access folks by considering certain things out of scope (after all, that's why we have the ipsra working group), and in the very next paragraph, he was worrying that the protocol might be including too much so that it's might be too complex for certain small devices. One of the things that a public speaker or a teacher quickly learns is that if half your audience thinks you're going too fast, and half of your audience thinks that you're going too slow, you probably have your judge your pace appropriately. So I'd like to think that we're at least trying to hold in tension the mutually exclusive goals of not being too wide or too narrow. It's also the case that thanks to Moore's law, the amount of processor and memory in a "small device" continues to become bigger and bigger. After all, these days, a 386 is sometimes used as an embedded processor, and design choices which cripped telnet encryption's security because people were worried about the performance on Macintoshes running 68000's would today be considered completely stupid/silly choices. So I'm not sure whether kitchen sink worry is really going to turn out to be a real concern, but it's certainly something which I believe we should continue to ask ourselves as we go through the SOI requirements debate. All this being said, it may very well be that if people really want to use a very specialized key exchange protocol for a very specific use, it might be possible to make a profile of SOI where certain "MUST"'s are turned into "MAY"'s. You couldn't call it IPSEC, which would be OK, since the missing features would very likely result in interoperability with other IPSEC implementation. However, if some hypotentical telephony or other application protocol really needs to be implementable in an 8 bit processor with 2k of RAM and 8k of ROM, then that particular application protocol specification could reference the SOI specification and describe how it should be stripped down. (Heck, if you have an 8-bit processor with 2k of RAM and 8k of ROM, you probably can't afford much beyond a fixed key passed directly to ESP/AH, and you might have to dispense with key management altogether. :-) - Ted From owner-ipsec@lists.tislabs.com Wed Jun 12 14:46:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLk0n20403; Wed, 12 Jun 2002 14:46:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11355 Wed, 12 Jun 2002 17:07:19 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15623.47878.784520.278749@thomasm-u1.cisco.com> Date: Wed, 12 Jun 2002 14:20:06 -0700 (PDT) To: uri@bell-labs.com Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: <200206121902.PAA13460@nwmail.wh.lucent.com> References: <200206121732.NAA21623@nwmail.wh.lucent.com> <15623.34715.623477.799435@thomasm-u1.cisco.com> <200206121902.PAA13460@nwmail.wh.lucent.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 Uri Blumenthal writes: > On Wednesday 12 June 2002 13:40, Michael Thomas wrote: > > You get a self-fulfilling prophecy if your idea of > > "practical applicability" == "VPN". > > My idea of "practical applicability" is "it must support VPN". > > Not "equal" but "includes". > > And if your idea of applicabilty excludes VPN, we are not on the same > page. Indeed, maybe we're not. I'll point out that TLS doesn't support VPN's either, but seems to have quite a bit of applicability even with its impoverished feature set. TLS's biggest weakness is that it doesn't work with connectionless transports. IPsec does, of course. This is why I wonder if there isn't two different problem spaces. Mike From owner-ipsec@lists.tislabs.com Wed Jun 12 15:12:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CMCOn20923; Wed, 12 Jun 2002 15:12:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11460 Wed, 12 Jun 2002 17:33:28 -0400 (EDT) Message-ID: <3D07E915.996DB5DC@storm.ca> Date: Wed, 12 Jun 2002 17:36:37 -0700 From: Sandy Harris X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > Cheryl tried to put together a requirements/scenario > document. You can find it here. > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt > > It tries to list all scenarios we could think of. You missed opportunistic encryption: http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-09.txt From owner-ipsec@lists.tislabs.com Wed Jun 12 15:45:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CMjRn21573; Wed, 12 Jun 2002 15:45:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11521 Wed, 12 Jun 2002 18:04:48 -0400 (EDT) Date: Wed, 12 Jun 2002 18:17:45 -0400 From: "Theodore Ts'o" To: Sandy Harris Cc: ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward Message-ID: <20020612221745.GE824@think.thunk.org> References: <3D07E915.996DB5DC@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D07E915.996DB5DC@storm.ca> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jun 12, 2002 at 05:36:37PM -0700, Sandy Harris wrote: > Jan Vilhuber wrote: > > > > Cheryl tried to put together a requirements/scenario > > document. You can find it here. > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt > > > > It tries to list all scenarios we could think of. > > You missed opportunistic encryption: > > http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-09.txt Sandy, Would you or one of the freeswan folks care to write up some text for the soneofike-tqts document describing the requirements for SOI in that particular scenario? If after your analysis, it turns out that they are identical to the VPN or the end-to-end scenario, we could just include a note that the relevant scenario also covers opportunistic encryption. - Ted From owner-ipsec@lists.tislabs.com Wed Jun 12 17:49:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D0nAn24549; Wed, 12 Jun 2002 17:49:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11640 Wed, 12 Jun 2002 19:11:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20020612154043.0218dad0@mira-sjcm-4.cisco.com> X-Sender: cmadson@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jun 2002 16:23:54 -0700 To: "Theodore Ts'o" From: Cheryl Madson Subject: Re: Son of IKE: A proposal for moving forward Cc: Jan Vilhuber , "Joshua D. Guttman" , Michael Thomas , uri@bell-labs.com, ipsec@lists.tislabs.com In-Reply-To: <20020612210625.GA824@think.thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:06 PM 6/12/2002, Theodore Ts'o wrote: >On Wed, Jun 12, 2002 at 12:16:48PM -0700, Jan Vilhuber wrote: > > Cheryl tried to put together a requirements/scenario document. You can > > find it here. > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt > > > > It tries to list all scenarios we could think of. Some of the are > > mutually exclusive, but there for completeness. Feel free to provide > > feedback and comments on any scenarios there or add some if we missed > > any. > >Absolutely. This document has been available for quite some time, and >it is indeed designed to be a way in which the working group is >supposed to judge SOI proposals. To that end, it's hard for me to >credit the claims that the entire working group is VPN-centric, given >that the document analyzes several scenarios, of which VPN is only one. Something that the WG is *supposed* to be doing is looking through the scenarios and deciding which ones are important enough to be covered by SOI (in other words, if we don't properly accommodate some core set of scenarios, we have not succeeded). It's obvious to all of us that we can't support everything. But we aren't even willing to discuss what we *should* support. [It's been 6 months since the initial draft, and three months since the more comprehensive draft, and the number of folks willing to think about/talk about it is depressingly small. [Apart from my reviewers, the only direct substantive comment came after the first draft, something along the lines of "why didn't you include scenario ?".] What scenarios are still needed? What scenarios are we willing to exclude (and why)? [IMO, VPN+remote access *aren't* enough.] And are the pieces I call out as "important" in each scenario a reasonable representation of the problem space (in other words, do we understand the problem space enough to figure out what it is that we need to solve)? It's much easier to weigh the relative priorities of the various requirements once we agree to the scope of the problem we want to solve with SOI. But we can't even seem to take the first step, which to me seems much easier to tackle than the priority weighting exercise (unless you punt almost everything, of course). You can't optimize (I'm talking in an abstract sense here) a protocol for everything, but ideally that protocol should be optimized for the important things. Yes, this is hard. But it's very hard to design a good protocol without doing such an exercise. To be blunt, the lack of such scoping is one of the big reasons we got into this mess in the first place (we shouldn't have had to shoehorn in remote access into a preexisting protocol, but most people weren't willing to think about that problem space at all -- much less grasp the problems it would introduce -- soon enough). I realize it's much easier to talk about point features/capabilities. Heck, it's more fun. But if we haven't agreed as to the problems we need to solve, it's somewhat of an academic exercise. And we're beyond trying to build a toy protocol here; there are lots of people dependent upon these things being real and useful. There is another consideration, which is actually more of a design issue (and is actually talked about in more depth in the earlier draft -- which has since expired -- I got a little too "simplification-happy ;-)" with the second draft): + If a protocol is designed with a reasonable amount of modularity, it should be possible to provide building blocks for other key management protocols to use. In other words, we don't have to solve the world's problems, but if with the building blocks we aren't forcing other groups to invent new KM protocols from scratch. [One example: if we have a good key agreement mechanism, it might be usable by lots of different protocols. Another example in this space is KINK, which used some of the pieces from IKE while replacing the key agreement mechanism.] + We need to weigh modularity against the complexity of having to manage lots of separate pieces. This is especially true if the separate pieces are actually separate protocols. The point here is that hopefully we can choose some happy medium on the modularity continuum, we can provide useful mechanisms for others to use. thx - C ==================================== Cheryl Madson Core IP Engineering; Security and Services Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec@lists.tislabs.com Thu Jun 13 06:40:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDexn19243; Thu, 13 Jun 2002 06:40:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13175 Thu, 13 Jun 2002 08:58:17 -0400 (EDT) Date: Wed, 12 Jun 2002 22:16:36 -0400 From: Mouse Subject: Re: Son of IKE: A proposal for moving forward In-reply-to: <4.3.2.7.2.20020612154043.0218dad0@mira-sjcm-4.cisco.com> To: ipsec@lists.tislabs.com Reply-to: uri@optonline.net Message-id: <0GXM003W2GZQSF@mta4.srv.hcvlny.cv.net> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <4.3.2.7.2.20020612154043.0218dad0@mira-sjcm-4.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Without quoting Cheryl's excellent posting, I want to express my full agreement and support for it. -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Jun 13 06:41:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDf6n19271; Thu, 13 Jun 2002 06:41:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13184 Thu, 13 Jun 2002 09:00:18 -0400 (EDT) Message-Id: <200206131124.HAA07312@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-udp-encaps-03.txt Date: Thu, 13 Jun 2002 07:24:55 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen et al. Filename : draft-ietf-ipsec-udp-encaps-03.txt Pages : Date : 12-Jun-02 This draft defines methods to encapsulate and decapsulate ESP packets inside UDP packets for the purpose of traversing NATs. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using IKE, as defined in [Kiv02]. The design choices are documented in [Dixon00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-udp-encaps-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020612145307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020612145307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jun 13 06:41:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDfOn19310; Thu, 13 Jun 2002 06:41:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13169 Thu, 13 Jun 2002 08:57:17 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-ID: <3D07BF7D.F7352EC8@optonline.net> Date: Wed, 12 Jun 2002 17:39:09 -0400 From: Uri Blumenthal X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-4GB i686) X-Accept-Language: ru, ja, de, zh, en MIME-Version: 1.0 To: Michael Thomas Original-CC: ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward References: <200206121732.NAA21623@nwmail.wh.lucent.com> <15623.34715.623477.799435@thomasm-u1.cisco.com> <200206121902.PAA13460@nwmail.wh.lucent.com> <15623.47878.784520.278749@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas wrote: > > And if your idea of applicabilty excludes VPN, we are > > not on the same page. > > Indeed, maybe we're not. I'll point out that TLS > doesn't support VPN's either, but seems to have > quite a bit of applicability even with its > impoverished feature set. TLS's biggest weakness > is that it doesn't work with connectionless > transports. IPsec does, of course. This is why > I wonder if there isn't two different problem > spaces. Then maybe what you need is something like connection-less TLS? -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Jun 13 06:52:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDqpn20557; Thu, 13 Jun 2002 06:52:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13257 Thu, 13 Jun 2002 09:14:24 -0400 (EDT) Message-Id: <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 09:14:20 -0400 To: ipsec@lists.tislabs.com From: Stuart Jacobs Subject: Re: Son of IKE: A proposal for moving forward Cc: paul.hoffman@vpnc.org In-Reply-To: References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <15623.31302.924268.658298@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If this group restricts their focus primarily on the VPN scenarios below then they are ignoring a major role that IPsec is expected to fill by large enterprises. Verizon is in the process of developing the security architecture for it's next generation networks. Given the magnitude of these networks and FCC requirements for open access, we must have the ability to universally establish strongly authenticated identities of communicating network elements. This authentication must be able to span many trust domains, be continuous to avoid any chance of session hi-jacking and scale to millions of nodes. IPsec, coupled with PKI, is the only technology that can even begin to meet our needs. We are relying on this WG to include in it's scope mechanisms that allow two network elements, regardless of their functions within a network, to be able to use IKE and ISAKMP, with PKI based X.509 certs, to establish one or more SAs that these two elements can then use to continuously authenticate, and optionally encrypt for confidentiality, UDP, TCP or SCTP transport layer communication sessions. This fundmental capability is critical for our use of IP technology for the transport of SS7 traffic, VoIP application signalling, (G)MPLS control plane signalling and OAM&P traffic. Without the ability of using IPsec we will be forced to use stove-pipe TSL methods that rarely interoperate, have never been proven to scale the the number of subjects we must contend with, will significantly increas complexity of operational controls, and increas management expense. Stu Jacobs Verizon Network Security Architecture At 6/12/02 01:02 PM, you wrote: >At 9:43 AM -0700 6/12/02, Michael Thomas wrote: >>The one thing I don't see here is any >>consideration of the very basic question of >>whether there are in fact two different problem >>spaces. > >There are certainly more than two. > >Michael is correct here in that we cannot evaluate the WG questions for >the general problem of keying all possible uses of IPsec. Well, we can >try, but it would be a waste of time (but typical of many IETF Working >Groups...). At the end of the effort, we would probably have no general >agreement on the significant questions. > >Having said that, and showing my obvious bias towards VPNs, I propose that >as we answer the questions, we do so with today's VPN customers in mind. >These folks mostly do two things: > >a) gateway-to-gateway, with each gateway possibly connecting to many other >gateways > >b) access over modems (or faster) from remote single-user computers > >Let's get SOI done right for these customers. > >Doing so doesn't prevent work from a different key exchange mechanism that >addresses a different use case; the most obvious one that probably won't >match with the use case above is remote access where there is a need for >very quick keying, or where the remote parties have relatively slow CPUs, >or where the remote parties have only small amounts of program memory, or >some combination of these. > >The work we have done in the past few months can help focus the feature >sets for each of these efforts, as well as for other efforts that might >arise later. But let's not pretend that we can do it all at once in a >single protocol -- we know we can't, and we have good evidence that we can >waste a lot of time trying. > >--Paul Hoffman, Director >--VPN Consortium ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com ========================== From owner-ipsec@lists.tislabs.com Thu Jun 13 07:51:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DEpIn22627; Thu, 13 Jun 2002 07:51:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13515 Thu, 13 Jun 2002 10:00:54 -0400 (EDT) Message-Id: <200206131405.KAA22918@nwmail.wh.lucent.com> Content-Type: text/plain; charset="iso-8859-1" From: Uri Blumenthal Reply-To: uri@bell-labs.com To: Stuart Jacobs , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward Date: Thu, 13 Jun 2002 10:05:02 -0400 X-Mailer: KMail [version 1.3.2] References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> In-Reply-To: <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> Organization: Lucent Technologies / Bell Labs MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA13490 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 13 June 2002 09:14, Stuart Jacobs wrote: > If this group restricts their focus primarily on the VPN scenarios > below then they are ignoring a major role that IPsec is expected to > fill by large enterprises. Stu, the point is not to LIMIT the protocol to VPN scenarios! The point is that VPN scenarios MUST BE INCLUDED/SUPPORTED, mentioned because (as I understood) some argued that it's unnecessary. As I understood Michael, he doesn't want the overhead involved with VPN functionality support. But in my view (and in view of some other WG members) - cutting it out will reduce the protocol to unusable. > We are relying on this WG to include in it's scope mechanisms that > allow two network elements, regardless of their functions within a > network, to be able to use IKE and ISAKMP, with PKI based X.509 > certs, to establish one or more SAs that these two elements can then > use to continuously authenticate, and optionally encrypt for > confidentiality, UDP, TCP or SCTP transport layer communication > sessions. This fundmental capability is critical for our use of IP > technology for the transport of SS7 traffic, VoIP application > signalling, (G)MPLS control plane signalling and OAM&P traffic. I personally would expect this scenario to be fully supported. I'm not quite sure why you need ISAKMP here, but other than that - ... -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Jun 13 08:30:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DFUTn25256; Thu, 13 Jun 2002 08:30:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13641 Thu, 13 Jun 2002 10:47:19 -0400 (EDT) From: Atul.Sharma@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? Date: Thu, 13 Jun 2002 10:59:55 -0400 Message-ID: Thread-Topic: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? Thread-Index: AcIS6vqhyJ1iocmtSpik7noSPx9LBQ== To: Cc: , X-OriginalArrivalTime: 13 Jun 2002 14:59:57.0051 (UTC) FILETIME=[FB79DCB0:01C212EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA13637 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Recently while interopertaing Nokia IPxxx boxes' IPsec with FreeBSD Kame IPsec we found problems with AH, (while Nokia interoperated with Cisco and Win2k for all modes). Looking at the Kame code there are following problems: (1) for IPv4 mutable fields TOS, Flags, Fragment offset are not zeroed out before calculating ICV like RFC 2402 says. (2) AH tunnel mode is not supported. Even though the code is there, AH tunnel mode is switched off stating that we cannot consider the inner IP packet as really authenticated, as it could have been tampered with between the host and the tunnel endpoint. It is just the outer IP packet which can be considered authenticated. Should we make an implementation un-interoperable because of this concern? Interestingly, AH tunnel for IPv6 still works, despite an attempt to switch it off, because of the way SPD for IPv6 case is setup.!! I think for such widely distributed software, we should correct above problems. Could please somebody from Kame comment/take note? Thanks, Atul From owner-ipsec@lists.tislabs.com Thu Jun 13 09:41:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DGfkn01097; Thu, 13 Jun 2002 09:41:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13778 Thu, 13 Jun 2002 11:52:54 -0400 (EDT) To: Atul.Sharma@nokia.com Cc: ipsec@lists.tislabs.com, DG.IPD-IPSEC@nokia.com, ipsec-project@iprg.nokia.com In-reply-to: Atul.Sharma's message of Thu, 13 Jun 2002 10:59:55 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? From: itojun@iijlab.net Date: Fri, 14 Jun 2002 01:05:10 +0900 Message-ID: <8841.1023984310@itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > (1) for IPv4 mutable fields TOS, Flags, Fragment offset are not zeroed out before > calculating ICV like RFC 2402 says. they are properly cleared on ICV computation (otherwise we won't interoperate with others). see sys/netinet6/ah_core.c:ah4_calccksum(). > (2) AH tunnel mode is not supported. > > Even though the code is there, AH tunnel mode is switched off stating that we > cannot consider the inner IP packet as really authenticated, as it could have been > tampered with between the host and the tunnel endpoint. It is just the outer IP packet > which can be considered authenticated. > > Should we make an implementation un-interoperable because of this concern? this is a documented caveat. "not supported" (your wording) is a incorrect assertion. KAME box can generate AH tunnel mode packet, and accept AH tunnel mode packet. our policy engine do not consider packets inside AH tunnel mode packet as "trusted", therefore, we do not permit them to go through if ipsec policy is set to "required". from ipsec(4): >> AH and tunnel mode encapsulation may not work as you might expect. If >> you configure inbound ``require'' policy against AH tunnel or any IPsec >> encapsulating policy with AH (like ``esp/tunnel/A-B/use >> ah/transport/A-B/require''), tunnelled packets will be rejected. This is >> because we enforce policy check on inner packet on reception, and AH au- >> thenticates encapsulating (outer) packet, not the encapsulated (inner) >> packet (so for the receiving kernel there's no sign of authenticity). >> The issue will be solved when we revamp our policy engine to keep all the >> packet decapsulation history. > Interestingly, AH tunnel for IPv6 still works, despite an attempt to switch it off, because > of the way SPD for IPv6 case is setup.!! i don't believe so. AH tunnel mode for IPv6 has the same restriction. itojun From owner-ipsec@lists.tislabs.com Thu Jun 13 09:48:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DGmSn01527; Thu, 13 Jun 2002 09:48:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13805 Thu, 13 Jun 2002 12:00:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <15623.31302.924268.658298@thomasm-u1.cisco.com> <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> Date: Thu, 13 Jun 2002 09:13:22 -0700 To: Stuart Jacobs , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Son of IKE: A proposal for moving forward Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stuart, how does the scenarios you describe *not* fit into the VPN scenarios listed in the requirements document? I don't see anything in your requirements that wouldn't be considered a pretty typical VPN. At 9:14 AM -0400 6/13/02, Stuart Jacobs wrote: >Verizon is in the process of developing the security architecture >for it's next generation networks. Given the magnitude of these >networks and FCC requirements for open access, we must have the >ability to universally establish strongly authenticated identities >of communicating network elements. This authentication must be able >to span many trust domains, be continuous to avoid any chance of >session hi-jacking and scale to millions of nodes. IPsec, coupled >with PKI, is the only technology that can even begin to meet our >needs. > >We are relying on this WG to include in it's scope mechanisms that >allow two network elements, regardless of their functions within a >network, to be able to use IKE and ISAKMP, with PKI based X.509 >certs, to establish one or more SAs that these two elements can then >use to continuously authenticate, and optionally encrypt for >confidentiality, UDP, TCP or SCTP transport layer communication >sessions. This fundmental capability is critical for our use of IP >technology for the transport of SS7 traffic, VoIP application >signalling, (G)MPLS control plane signalling and OAM&P traffic. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 13 10:15:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHFWn02449; Thu, 13 Jun 2002 10:15:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13886 Thu, 13 Jun 2002 12:30:07 -0400 (EDT) From: Atul.Sharma@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? Date: Thu, 13 Jun 2002 12:42:13 -0400 Message-ID: Thread-Topic: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? Thread-Index: AcIS9CumsV7CozISQbCQzUyBGnZ2tgAAbMEg To: Cc: , , X-OriginalArrivalTime: 13 Jun 2002 16:42:14.0543 (UTC) FILETIME=[45B4D1F0:01C212F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA13883 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With very best regards, the comments are inline ("Atul>"). Atul -----Original Message----- From: ext itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: Thursday, June 13, 2002 12:05 PM To: Sharma Atul (NIC/Boston) Cc: ipsec@lists.tislabs.com; IPD-IPSEC DG; ipsec-project@iprg.nokia.com Subject: Re: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? > (1) for IPv4 mutable fields TOS, Flags, Fragment offset are not zeroed out before > calculating ICV like RFC 2402 says. they are properly cleared on ICV computation (otherwise we won't interoperate with others). see sys/netinet6/ah_core.c:ah4_calccksum(). Atul> I looked at the same routine, the code looks like(lines 1232-1236 on Atul> FreeBSD 4.5 RELEASE): Atul> Atul> iphdr.ip_ttl = 0; Atul> iphdr.ip_sum = htons(0); Atul> if (ip4_ah_cleartos) Atul> iphdr.ip_tos = 0; Atul> iphdr.ip_off = htons(ntohs(iphdr.ip_off) & ip4_ah_offsetmask); Atul> Atul> So ip_tos and ip_off are not unconditionally zeroed like RFC 2402 says. Atul> The interoperability problem shall come when we have fragments and/or Atul> non-zero tos field. For all other traffic one shall not see the difference. > (2) AH tunnel mode is not supported. > > Even though the code is there, AH tunnel mode is switched off stating that we > cannot consider the inner IP packet as really authenticated, as it could have been > tampered with between the host and the tunnel endpoint. It is just the outer IP packet > which can be considered authenticated. > > Should we make an implementation un-interoperable because of this concern? this is a documented caveat. "not supported" (your wording) is a incorrect assertion. KAME box can generate AH tunnel mode packet, and accept AH tunnel mode packet. our policy engine do not consider packets inside AH tunnel mode packet as "trusted", therefore, we do not permit them to go through if ipsec policy is set to "required". from ipsec(4): >> AH and tunnel mode encapsulation may not work as you might expect. If >> you configure inbound ``require'' policy against AH tunnel or any IPsec >> encapsulating policy with AH (like ``esp/tunnel/A-B/use >> ah/transport/A-B/require''), tunnelled packets will be rejected. This is >> because we enforce policy check on inner packet on reception, and AH au- >> thenticates encapsulating (outer) packet, not the encapsulated (inner) >> packet (so for the receiving kernel there's no sign of authenticity). >> The issue will be solved when we revamp our policy engine to keep all the >> packet decapsulation history. Atul> I must admit that I did not try without "required" in the policy. I shall Atul> give it a try. Many thanks for pointing that out. > Interestingly, AH tunnel for IPv6 still works, despite an attempt to switch it off, because > of the way SPD for IPv6 case is setup.!! i don't believe so. AH tunnel mode for IPv6 has the same restriction. Atul> IPv6 seems to have same restriction, but it seems to work. I traced it and the Atul> reason is that in ip6_input() ipsec6_in_reject() returns 0, because eventually Atul> in ipsec_in_reject() sp->policy is IPSEC_POLICY_BYPASS or IPSEC_POLICY_NONE Atul> and a 0 is returned. In the case of IPv4 in ipsec_in_reject() sp->policy Atul> hits IPSEC_POLICY_IPSEC, and the last if statement in this routine is hit Atul> as (need_auth && !(m->m_flags & M_AUTHIPHDR) is TRUE and a 1 is returned... Atul> and it fails in ip_input(). Atul> Atul> My IPv6 IPsec policy looks like: Atul> # IPv6 Atul> spdadd 1101::1/128 1101::2/128 any -P out ipsec ah/tunnel/1101::1-1101::2/require; Atul> spdadd 1101::2/128 1101::1/128 any -P out ipsec ah/tunnel/1101::2-1101::1/require; itojun From owner-ipsec@lists.tislabs.com Thu Jun 13 10:19:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHJtn02526; Thu, 13 Jun 2002 10:19:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13939 Thu, 13 Jun 2002 12:38:21 -0400 (EDT) To: Atul.Sharma@nokia.com Cc: ipsec@lists.tislabs.com, DG.IPD-IPSEC@nokia.com, ipsec-project@iprg.nokia.com In-reply-to: Atul.Sharma's message of Thu, 13 Jun 2002 12:42:13 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? From: itojun@iijlab.net Date: Fri, 14 Jun 2002 01:51:30 +0900 Message-ID: <18497.1023987090@itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> I looked at the same routine, the code looks like(lines 1232-1236 on >> FreeBSD 4.5 RELEASE): >> >> iphdr.ip_ttl = 0; >> iphdr.ip_sum = htons(0); >> if (ip4_ah_cleartos) >> iphdr.ip_tos = 0; >> iphdr.ip_off = htons(ntohs(iphdr.ip_off) & ip4_ah_offsetmask); >> So ip_tos and ip_off are not unconditionally zeroed like RFC 2402 says. >> The interoperability problem shall come when we have fragments and/or >> non-zero tos field. For all other traffic one shall not see the difference. ip4_ah_cleartos is 1 by default, and ip4_ah_offsetmask is 0 by default. therefore, TOS and fragment offset fields will be correctly cleared. these tunable variables are provided as older revisions of RFC was not very clear about how we should compute ICV. it may seem redundant, but was useful during past interoperability tests. we don't expect anyone to modify the variable. itojun From owner-ipsec@lists.tislabs.com Thu Jun 13 10:20:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHK5n02543; Thu, 13 Jun 2002 10:20:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13940 Thu, 13 Jun 2002 12:38:22 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.52526.918067.188334@thomasm-u1.cisco.com> Date: Thu, 13 Jun 2002 09:49:50 -0700 (PDT) To: uri@bell-labs.com Cc: Stuart Jacobs , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: <200206131405.KAA22918@nwmail.wh.lucent.com> References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> <200206131405.KAA22918@nwmail.wh.lucent.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 Uri Blumenthal writes: > On Thursday 13 June 2002 09:14, Stuart Jacobs wrote: > > If this group restricts their focus primarily on the VPN scenarios > > below then they are ignoring a major role that IPsec is expected to > > fill by large enterprises. > > Stu, the point is not to LIMIT the protocol to VPN scenarios! The > point is that VPN scenarios MUST BE INCLUDED/SUPPORTED, > mentioned because (as I understood) some argued that it's unnecessary. > > As I understood Michael, he doesn't want the overhead involved > with VPN functionality support. But in my view (and in view of some > other WG members) - cutting it out will reduce the protocol to unusable. Uri, I'm not sure that that's what I meant, but I can see how it would be construed that way. As I said, I'm rather schizophrenic about this issue. We really, really need to enable strong auth on the next gen of IP widgets -- ie, things that aren't going to have 80GB disks and 512MB of ram to fritter away. Ted's right that Moore's law eventually solves this, but that's a rather facile arguement if it solves it *too late*. That is, if the next gen of widgets either do without strong auth altogether, or find something like WEP which is "easier" to implement at the cost of near complete insecurity, we're not doing the user base any favors. Frankly, I don't think that we're really at the point where we can handwave things away with Moore's law: there's a whole new generation of cheap wireless widgets on the horizon and they have a hard time swallowing IKE as it's currently defined. Nor do they seem to need a lot of what IKE has to offer: cell phones seem to work pretty OK with simple SIM based authentication. That is, their needs seem simplier than your average road warrior. This is why I wonder if there are two problem spaces. You've taken this to mean my suggesting that the split should VPN/not-VPN, but that's just one way to carve the problem space up. Another might be to differentiate via remote access, or some other split. A third way to deal with this is to potentially legitimize "profiles" where we have a very slim inner protocol which can and should be implemented by *everything* where you have additional functionality layered on through, say, different standard's track RFC's, or whatever. The bottom line is that I'm much more interested that this issue is considered seriously than any particular way to solve it. When I floated the JFK/IKEv2 split, it was mainly because I can see how to make JFK a very light weight -- but still useful -- means of establishing transport and tunnel mode SA's. I like IPsec, generally, because it opens a lot of options. It would be really nice to have a base level keying mechanism which would be shameful not to implement. I think that's within reach right now, even if the kitchen sink is not. Mike From owner-ipsec@lists.tislabs.com Thu Jun 13 10:21:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHLtn02630; Thu, 13 Jun 2002 10:21:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13955 Thu, 13 Jun 2002 12:40:19 -0400 (EDT) To: Atul.Sharma@nokia.com Cc: ipsec@lists.tislabs.com, DG.IPD-IPSEC@nokia.com, ipsec-project@iprg.nokia.com In-reply-to: Atul.Sharma's message of Thu, 13 Jun 2002 12:42:13 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? From: itojun@iijlab.net Date: Fri, 14 Jun 2002 01:52:50 +0900 Message-ID: <19321.1023987170@itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> My IPv6 IPsec policy looks like: >> # IPv6 >> spdadd 1101::1/128 1101::2/128 any -P out ipsec ah/tunnel/1101::1-1101::2/require; >> spdadd 1101::2/128 1101::1/128 any -P out ipsec ah/tunnel/1101::2-1101::1/require; your configuration is wrong. you are not enforcing inbound policy, therefore, the node will accept traffic regardless from the presense of AH. itojun From owner-ipsec@lists.tislabs.com Thu Jun 13 10:26:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHQon02693; Thu, 13 Jun 2002 10:26:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14002 Thu, 13 Jun 2002 12:43:20 -0400 (EDT) From: "Theodore Ts'o" To: jis@mit.edu, smb@research.att.com cc: byfraser@cisco.com, ipsec@lists.tislabs.com, ietf-secretariat@ietf.org cc: kivinen@ssh.fi Subject: Ready for IETF last call: draft-ietf-ipsec-ike-modp-groups-04.txt Phone: (781) 391-3464 Message-Id: Date: Tue, 11 Jun 2002 14:25:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Jeff, The I-D draft-ietf-ipsec-ike-modp-groups-04.txt has been through working group last call, and with no comments against it, it is ready to go to IETF last call and for consideration by the IESG for Proposed Standard. The draft is still missing IANA assignments for some of the groups in the document, which we asked Tero to work on obtaining from the IANA. This has not been accomplished yet, but we believe this can be addressed in parallel with the IETF last call and IESG consideration period. - Ted From owner-ipsec@lists.tislabs.com Thu Jun 13 10:38:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHc0n02906; Thu, 13 Jun 2002 10:38:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14036 Thu, 13 Jun 2002 12:54:29 -0400 (EDT) From: Atul.Sharma@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? Date: Thu, 13 Jun 2002 13:05:52 -0400 Message-ID: Thread-Topic: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? Thread-Index: AcIS+scOsfRdEYAyT32dDhX9G5ODogAAYyNQ To: Cc: , , X-OriginalArrivalTime: 13 Jun 2002 17:05:53.0861 (UTC) FILETIME=[93AF8F50:01C212FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA14027 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Many thanks for clarifying everything! Best Regards, Atul -----Original Message----- From: ext itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: Thursday, June 13, 2002 12:53 PM To: Sharma Atul (NIC/Boston) Cc: ipsec@lists.tislabs.com; IPD-IPSEC DG; ipsec-project@iprg.nokia.com Subject: Re: NonConforming IPsec implementation from FreeBSD(Kame) IPsec? >> My IPv6 IPsec policy looks like: >> # IPv6 >> spdadd 1101::1/128 1101::2/128 any -P out ipsec ah/tunnel/1101::1-1101::2/require; >> spdadd 1101::2/128 1101::1/128 any -P out ipsec ah/tunnel/1101::2-1101::1/require; your configuration is wrong. you are not enforcing inbound policy, therefore, the node will accept traffic regardless from the presense of AH. itojun From owner-ipsec@lists.tislabs.com Thu Jun 13 11:21:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DILgn04223; Thu, 13 Jun 2002 11:21:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14195 Thu, 13 Jun 2002 13:33:04 -0400 (EDT) Message-Id: <5.1.0.14.2.20020613123019.026171f0@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 12:30:37 -0400 To: ipsec@lists.tislabs.com From: Stuart Jacobs Subject: Fwd: Re: Son of IKE: A proposal for moving forward Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Paul, > >We can no longer consider the cabling within our COs as secure given that >we are mandated to allow non-Verizon personnel access to, and within, >these facilities. Consequently we need end-to-end SAs between our network >elements with the SAs originating/terminating directly on the net >interfaces within the elements. A VPN approach typically is deployed to >interconnect two trusted networks over an untrusted third network. Given >that a very high percentage of attachs are initiated by insiders (as >documented over the last few years in the CSI surveys) we cannot assume >any network is inherently trustable. Does that clarify the situation? > >Stu > >At 6/13/02 09:13 AM, you wrote: >>Stuart, how does the scenarios you describe *not* fit into the VPN >>scenarios listed in the requirements document? I don't see anything in >>your requirements that wouldn't be considered a pretty typical VPN. >> >>At 9:14 AM -0400 6/13/02, Stuart Jacobs wrote: >>>Verizon is in the process of developing the security architecture for >>>it's next generation networks. Given the magnitude of these networks >>>and FCC requirements for open access, we must have the ability to >>>universally establish strongly authenticated identities of communicating >>>network elements. This authentication must be able to span many trust >>>domains, be continuous to avoid any chance of session hi-jacking and >>>scale to millions of nodes. IPsec, coupled with PKI, is the only >>>technology that can even begin to meet our needs. >>> >>>We are relying on this WG to include in it's scope mechanisms that allow >>>two network elements, regardless of their functions within a network, to >>>be able to use IKE and ISAKMP, with PKI based X.509 certs, to establish >>>one or more SAs that these two elements can then use to continuously >>>authenticate, and optionally encrypt for confidentiality, UDP, TCP or >>>SCTP transport layer communication sessions. This fundmental capability >>>is critical for our use of IP technology for the transport of SS7 >>>traffic, VoIP application signalling, (G)MPLS control plane signalling >>>and OAM&P traffic. >> >>--Paul Hoffman, Director >>--VPN Consortium > >========================== >Stuart Jacobs CISSP >PMTS - Sr. Technologist >Verizon Laboratories >40 Sylvan Road Waltham, MA 02451-1128 USA >telephone: (781) 466-3076 fax: (781) 466-2838 >stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com >========================== ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com ========================== From owner-ipsec@lists.tislabs.com Thu Jun 13 11:46:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DIkmn04729; Thu, 13 Jun 2002 11:46:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14342 Thu, 13 Jun 2002 14:04:37 -0400 (EDT) Date: Thu, 13 Jun 2002 14:17:35 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Fwd: Re: Son of IKE: A proposal for moving forward In-Reply-To: <5.1.0.14.2.20020613123019.026171f0@pophost.gte.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 13 Jun 2002, Stuart Jacobs wrote: >...we need end-to-end SAs between our network >elements with the SAs originating/terminating directly on the net >interfaces within the elements. A VPN approach typically is deployed to >interconnect two trusted networks over an untrusted third network... There is no reason why the two trusted "networks" can't be single hosts -- that's just a degenerate case. It involves both minor complications and minor simplifications, and is, as Paul said, a common VPN situation. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 13 12:36:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJaVn06858; Thu, 13 Jun 2002 12:36:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14557 Thu, 13 Jun 2002 14:52:16 -0400 (EDT) Message-Id: <200206131904.g5DJ4YZs004605@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: IP Security List Subject: Re: Fwd: Re: Son of IKE: A proposal for moving forward In-Reply-To: Your message of "Thu, 13 Jun 2002 14:17:35 EDT." Reply-to: sommerfeld@east.sun.com Date: Thu, 13 Jun 2002 15:04:33 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There is no reason why the two trusted "networks" can't be single hosts -- > that's just a degenerate case. It involves both minor complications and > minor simplifications, and is, as Paul said, a common VPN situation. there are certain obvious scaling problems with this approach. direct use of transport mode is likely to be easier to manage, require fewer addresses, and be simpler with large numbers of hosts. - Bill From owner-ipsec@lists.tislabs.com Thu Jun 13 12:56:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJuln08454; Thu, 13 Jun 2002 12:56:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14643 Thu, 13 Jun 2002 15:17:36 -0400 (EDT) Date: Thu, 13 Jun 2002 15:30:20 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Fwd: Re: Son of IKE: A proposal for moving forward In-Reply-To: <200206131904.g5DJ4YZs004605@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, 13 Jun 2002, Bill Sommerfeld wrote: > > There is no reason why the two trusted "networks" can't be single hosts -- > > that's just a degenerate case... > > there are certain obvious scaling problems with this approach. > direct use of transport mode is likely to be easier to manage, require > fewer addresses, and be simpler with large numbers of hosts. You're making unwarranted assumptions about what a VPN is. It's perfectly possible to have a VPN in which the "wires" are private but the addresses are not. (Indeed, even VPNs with non-degenerate ends do not necessarily use private addresses.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 13 14:05:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DL5Vn09784; Thu, 13 Jun 2002 14:05:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14771 Thu, 13 Jun 2002 16:21:07 -0400 (EDT) Message-Id: <200206132034.g5DKY2Zs007056@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: IP Security List Subject: Re: Fwd: Re: Son of IKE: A proposal for moving forward In-Reply-To: Your message of "Thu, 13 Jun 2002 15:30:20 EDT." Reply-to: sommerfeld@east.sun.com Date: Thu, 13 Jun 2002 16:34:02 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > You're making unwarranted assumptions about what a VPN is. It's perfectly > possible to have a VPN in which the "wires" are private but the addresses > are not. you're also making unwarranted assumptions. we're clearly talking past each other. > (Indeed, even VPNs with non-degenerate ends do not necessarily use > private addresses.) where did I say "private addresses"? - Bill From owner-ipsec@lists.tislabs.com Thu Jun 13 14:50:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DLoVn11244; Thu, 13 Jun 2002 14:50:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14856 Thu, 13 Jun 2002 17:09:35 -0400 (EDT) Message-Id: <200206132121.g5DLLdk27941@trpz.com> To: Michael Thomas cc: uri@bell-labs.com, Stuart Jacobs , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: Your message of "Thu, 13 Jun 2002 09:49:50 PDT." <15624.52526.918067.188334@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <875.1024003290.1@tibernian.com> Date: Thu, 13 Jun 2002 14:21:30 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, On Thu, 13 Jun 2002 09:49:50 PDT you wrote > > I'm not sure that that's what I meant, but I can > see how it would be construed that way. As I said, > I'm rather schizophrenic about this issue. We > really, really need to enable strong auth on the > next gen of IP widgets -- ie, things that aren't > going to have 80GB disks and 512MB of ram to > fritter away. The problem with such hyperbole is that it tends to get traction. No key management protocol under consideration requires 80GB disks or 512MB or any kind of "frittering". And in fact, IKE has been implemented on such small IP widgets as PDAs and cellphones. > Ted's right that Moore's law eventually solves > this, but that's a rather facile arguement if it > solves it *too late*. That is, if the next gen of > widgets either do without strong auth altogether, > or find something like WEP which is "easier" to > implement at the cost of near complete insecurity, > we're not doing the user base any favors. > > Frankly, I don't think that we're really at the > point where we can handwave things away with > Moore's law: there's a whole new generation of > cheap wireless widgets on the horizon and they > have a hard time swallowing IKE as it's currently > defined. Nor do they seem to need a lot of what > IKE has to offer: cell phones seem to work pretty > OK with simple SIM based authentication. That is, > their needs seem simplier than your average road > warrior. Right, they need what IEEE802.1x and the EAP WG are providing. Although I find it hard to understand arguments that talk about the bulk of IKE but suggest that EAPoL (several state machines) encapsulated EAP packets (another state machine) which encapsulate (sometimes fragmented!!!) TLS packets (another huge state machine), supporting all the certificate infrastructure that requires, is somehow less bulky. That's a monsterous amount of interconnected code. But somehow that's OK while IKE is bloatware. The handwaving is not over Moore's Law, it's over some vague "cheap wireless widget on the horizon". In fact, it's almost beyond handwaving to outright fearmongering. Both of the protocols under consideration are less heavy-weight than IKE and IKE has been implemented on PDAs and cellphones. > This is why I wonder if there are two problem > spaces. You've taken this to mean my suggesting > that the split should VPN/not-VPN, but that's > just one way to carve the problem space up. > Another might be to differentiate via remote > access, or some other split. A third way to deal > with this is to potentially legitimize "profiles" > where we have a very slim inner protocol which can > and should be implemented by *everything* where > you have additional functionality layered on > through, say, different standard's track RFC's, > or whatever. > > The bottom line is that I'm much more interested > that this issue is considered seriously than any > particular way to solve it. When I floated the > JFK/IKEv2 split, it was mainly because I can see > how to make JFK a very light weight -- but still > useful -- means of establishing transport and > tunnel mode SA's. I like IPsec, generally, because > it opens a lot of options. It would be really nice > to have a base level keying mechanism which would > be shameful not to implement. I think that's > within reach right now, even if the kitchen sink > is not. You can't "make JFK very light weight"; it is not an extensible protocol. You have mutual, public-key based authentication, period. No SIM card authentication is possible. You can't take some and leave some, and you definitely can't add some. It's not that kind of protocol. If the widget you describe above is happy with SIM-based authentication then it will not be happy with JFK just as it is not happy with IKE, as you claim. Dan. From owner-ipsec@lists.tislabs.com Thu Jun 13 15:14:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DMEwn11670; Thu, 13 Jun 2002 15:14:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14900 Thu, 13 Jun 2002 17:32:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15625.4712.269000.725052@gargle.gargle.HOWL> Date: Thu, 13 Jun 2002 17:45:12 -0400 From: Paul Koning To: sommerfeld@east.sun.com Cc: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: Fwd: Re: Son of IKE: A proposal for moving forward References: <200206131904.g5DJ4YZs004605@thunk.east.sun.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 13 June 2002) by Bill Sommerfeld: > > There is no reason why the two trusted "networks" can't be single hosts -- > > that's just a degenerate case. It involves both minor complications and > > minor simplifications, and is, as Paul said, a common VPN situation. > > there are certain obvious scaling problems with this approach. > > direct use of transport mode is likely to be easier to manage, require > fewer addresses, and be simpler with large numbers of hosts. Tunnel mode does not *require* more addresses than transport mode -- though it allows them. paul From owner-ipsec@lists.tislabs.com Thu Jun 13 15:15:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DMF1n11691; Thu, 13 Jun 2002 15:15:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14888 Thu, 13 Jun 2002 17:30:37 -0400 (EDT) Date: Thu, 13 Jun 2002 17:43:25 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Fwd: Re: Son of IKE: A proposal for moving forward In-Reply-To: <200206132034.g5DKY2Zs007056@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, 13 Jun 2002, Bill Sommerfeld wrote: > > You're making unwarranted assumptions about what a VPN is. It's perfectly > > possible to have a VPN in which the "wires" are private but the addresses > > are not. > > you're also making unwarranted assumptions... > where did I say "private addresses"? Then I guess I don't follow. You're going to have to explain why you think there are "certain obvious scaling problems" and why "direct use of transport mode is likely to be easier to manage, require fewer addresses, and be simpler with large numbers of hosts". I don't see any scaling problems, obvious or otherwise, that are not shared by both approaches. I don't see any significant difference in complexity or ease of management. And I see no reason why there would be any difference in the number of addresses required. (Note that when I said "private addresses", I meant "addresses not accessible on the public network", not "addresses from the RFC 1918 blocks". A host needs one address to be accessible by network at all. There is no reason why it can't use that address on both the public network and the private network. No extras are necessary.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 13 17:43:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E0hQn14731; Thu, 13 Jun 2002 17:43:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15145 Thu, 13 Jun 2002 20:02:17 -0400 (EDT) Date: Thu, 13 Jun 2002 20:15:02 -0400 From: "Theodore Ts'o" To: Dan Harkins Cc: Michael Thomas , uri@bell-labs.com, Stuart Jacobs , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward Message-ID: <20020614001502.GC612@think.thunk.org> References: <15624.52526.918067.188334@thomasm-u1.cisco.com> <200206132121.g5DLLdk27941@trpz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206132121.g5DLLdk27941@trpz.com> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jun 13, 2002 at 02:21:30PM -0700, Dan Harkins wrote: > > The handwaving is not over Moore's Law, it's over some vague > "cheap wireless widget on the horizon". In fact, it's almost beyond > handwaving to outright fearmongering. Both of the protocols under > consideration are less heavy-weight than IKE and IKE has been > implemented on PDAs and cellphones. > Michael, If you could give us some specifics about what sorts of CPU/memory resources you think these "cheap wireless widgets" will have, that would be very helpful. Given that StrongARM and PPC processors are regularly used in embedded devices, and very sophisticated systems have been implemented on embedded devices (including full Linux systems and full IKEv1 systems --- heck, IBM demonstrated Linux running on a wristwatch! :-), without some quantifiable limitations of these future wireless devices, it's very hard to move forward. - Ted From owner-ipsec@lists.tislabs.com Fri Jun 14 06:07:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ED7Vn04276; Fri, 14 Jun 2002 06:07:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16296 Fri, 14 Jun 2002 08:30:59 -0400 (EDT) Date: Fri, 14 Jun 2002 18:06:44 +0530 (IST) From: Lokesh N B X-Sender: lokeshnb@brahma.intotoind.com To: Ari Huttunen cc: Jan Backman , ipsec@lists.tislabs.com Subject: Re: PMTU and NAT-Traversal problem In-Reply-To: <3D09E1F6.37BE08EB@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Implementing version 2 of UDP encaps draft doesn't solve the problem either. -Lokesh On Fri, 14 Jun 2002, Ari Huttunen wrote: > Note that draft-ietf-ipsec-udp-encaps-02.txt is different in this respect > because the 8 byte non-IKE marker was changed to a 4 byte non-ESP marker. > Still the UDP header itself is 64 bits. > > You shouldn't be implementing the -01 version in any case. > > Ari > > Lokesh wrote: > > > > Hello jan, > > Thanks, but that is not the answer to my question. > > problem is information for SA look up is not present in the returned ICMP > > PMTU message. > > Hence sender cannot determine in which SA to update returned MTU. > > I think I should explain it bit more clearly. > > When a IPSec packet with DF bit set, cannot be transmitted over a link with > > less MTU, > > the router would send ICMP PMTU error packet back to sender which > > contains IP header and 64 bits of IPSec headers of faulting packet as data. > > sender uses the SPI and other packet selectors in the 64 bit information to > > look up SA's and adjust their MTU with the returned MTU value in the ICMP > > PMTU message. > > Now, in case where NAT Traversal is supported, IPSec packets will be > > encapsulated in UDP packets and 8 bytes of NON -IKE marker, the 64 bit info > > after IP hdr will only contain UDP header using which sender cannot > > determine SA's over which original faulting packet was sent. > > Is there any solution exists for this problem? > > Thanks > > Lokesh > > > > At 01:59 PM 6/10/02 +0200, Jan Backman wrote: > > >Hi, > > >Store the information about the encountered MTU in the NAT and use it to > > >reply an ICMP when the next packet in the flow arrives (that is larger > > >than the MTU). > > > > > >regards /// Jan > > > > > > > -----Original Message----- > > > > From: Lokesh [mailto:lokeshnb@intotoinc.com] > > > > Sent: Monday, June 10, 2002 12:34 PM > > > > To: ipsec@lists.tislabs.com > > > > Subject: PMTU and NAT-Traversal problem > > > > > > > > > > > > Hi all, > > > > Is there anybody who implemented following in a security Gateway? > > > > 1. draft-ietf-ipsec-nat-t-ike-01.txt and > > > > draft-ietf-ipsec-udp-encaps-01.txt > > > > 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). > > > > if so, how did you solve following problem?......... > > > > > > > > For Unauthenticated ICMP PMTU message processing: > > > > > > > > The PMTU processing bound to fail, since ICMP PMTU error > > > > message would > > > > include > > > > only IP Hdr and 64 bits of IPsec Hdr information. Since UDP > > > > Encaps and NAT > > > > Traversal drafts encapsulate ipsec packets in UDP and put a 8 > > > > byte NON IKE > > > > marker,(totalling 16 bytes) > > > > PMTU error message returned will not have enough information > > > > to find the > > > > SA's at the receiving > > > > Security Gateway. How to solve this problem? any suggestions? > > > > any help in this regard is highly appreciated. > > > > Thanks > > > > Lokesh > > > > > > -- > > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F(ully)-Secure products: Securing the Mobile Enterprise > From owner-ipsec@lists.tislabs.com Fri Jun 14 06:10:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EDALn04619; Fri, 14 Jun 2002 06:10:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16227 Fri, 14 Jun 2002 08:16:52 -0400 (EDT) Message-ID: <3D09E1F6.37BE08EB@F-Secure.com> Date: Fri, 14 Jun 2002 15:30:46 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lokesh CC: Jan Backman , ipsec@lists.tislabs.com Subject: Re: PMTU and NAT-Traversal problem References: <5.1.0.14.0.20020611140750.00a40700@172.16.1.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2002 12:30:48.0008 (UTC) FILETIME=[4FD80480:01C2139F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that draft-ietf-ipsec-udp-encaps-02.txt is different in this respect because the 8 byte non-IKE marker was changed to a 4 byte non-ESP marker. Still the UDP header itself is 64 bits. You shouldn't be implementing the -01 version in any case. Ari Lokesh wrote: > > Hello jan, > Thanks, but that is not the answer to my question. > problem is information for SA look up is not present in the returned ICMP > PMTU message. > Hence sender cannot determine in which SA to update returned MTU. > I think I should explain it bit more clearly. > When a IPSec packet with DF bit set, cannot be transmitted over a link with > less MTU, > the router would send ICMP PMTU error packet back to sender which > contains IP header and 64 bits of IPSec headers of faulting packet as data. > sender uses the SPI and other packet selectors in the 64 bit information to > look up SA's and adjust their MTU with the returned MTU value in the ICMP > PMTU message. > Now, in case where NAT Traversal is supported, IPSec packets will be > encapsulated in UDP packets and 8 bytes of NON -IKE marker, the 64 bit info > after IP hdr will only contain UDP header using which sender cannot > determine SA's over which original faulting packet was sent. > Is there any solution exists for this problem? > Thanks > Lokesh > > At 01:59 PM 6/10/02 +0200, Jan Backman wrote: > >Hi, > >Store the information about the encountered MTU in the NAT and use it to > >reply an ICMP when the next packet in the flow arrives (that is larger > >than the MTU). > > > >regards /// Jan > > > > > -----Original Message----- > > > From: Lokesh [mailto:lokeshnb@intotoinc.com] > > > Sent: Monday, June 10, 2002 12:34 PM > > > To: ipsec@lists.tislabs.com > > > Subject: PMTU and NAT-Traversal problem > > > > > > > > > Hi all, > > > Is there anybody who implemented following in a security Gateway? > > > 1. draft-ietf-ipsec-nat-t-ike-01.txt and > > > draft-ietf-ipsec-udp-encaps-01.txt > > > 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). > > > if so, how did you solve following problem?......... > > > > > > For Unauthenticated ICMP PMTU message processing: > > > > > > The PMTU processing bound to fail, since ICMP PMTU error > > > message would > > > include > > > only IP Hdr and 64 bits of IPsec Hdr information. Since UDP > > > Encaps and NAT > > > Traversal drafts encapsulate ipsec packets in UDP and put a 8 > > > byte NON IKE > > > marker,(totalling 16 bytes) > > > PMTU error message returned will not have enough information > > > to find the > > > SA's at the receiving > > > Security Gateway. How to solve this problem? any suggestions? > > > any help in this regard is highly appreciated. > > > Thanks > > > Lokesh > > > -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Fri Jun 14 08:23:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EFMxn10756; Fri, 14 Jun 2002 08:22:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16627 Fri, 14 Jun 2002 10:10:17 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-ID: <3D090376.3678935B@optonline.net> Date: Thu, 13 Jun 2002 16:41:26 -0400 From: Uri Blumenthal X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-4GB i686) X-Accept-Language: ru, ja, de, zh, en MIME-Version: 1.0 To: Michael Thomas Original-CC: ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> <200206131405.KAA22918@nwmail.wh.lucent.com> <15624.52526.918067.188334@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas wrote: > > Stu, the point is not to LIMIT the protocol to VPN scenarios! The > > point is that VPN scenarios MUST BE INCLUDED/SUPPORTED, > > mentioned because (as I understood) some argued that it's unnecessary. > > > > As I understood Michael, he doesn't want the overhead involved > > with VPN functionality support. But in my view (and in view of some > > other WG members) - cutting it out will reduce the protocol to unusable. > > I'm not sure that that's what I meant, but I can > see how it would be construed that way.......... > .....You've taken this to mean my suggesting > that the split should VPN/not-VPN, but that's > just one way to carve the problem space up. My point - I *don't* want/care to carve the space. I see a basic minimal set of requirements that a key mgmt protocol must support in order to be usable vs. just mathematically correct. It appears to me that your minimal set is even smaller, and what you consider still usable - isn't usable for me and other members because it doesn't cover scenarios that we belieev are essential. -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Fri Jun 14 08:23:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EFNDn10770; Fri, 14 Jun 2002 08:23:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16634 Fri, 14 Jun 2002 10:11:16 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Thu Jun 13 14:54:04 2002 Message-Id: <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 09:14:20 -0400 To: ipsec@lists.tislabs.com From: Stuart Jacobs Subject: Re: Son of IKE: A proposal for moving forward Cc: paul.hoffman@vpnc.org In-Reply-To: References: <15623.31302.924268.658298@thomasm-u1.cisco.com> <15623.31302.924268.658298@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If this group restricts their focus primarily on the VPN scenarios below then they are ignoring a major role that IPsec is expected to fill by large enterprises. Verizon is in the process of developing the security architecture for it's next generation networks. Given the magnitude of these networks and FCC requirements for open access, we must have the ability to universally establish strongly authenticated identities of communicating network elements. This authentication must be able to span many trust domains, be continuous to avoid any chance of session hi-jacking and scale to millions of nodes. IPsec, coupled with PKI, is the only technology that can even begin to meet our needs. We are relying on this WG to include in it's scope mechanisms that allow two network elements, regardless of their functions within a network, to be able to use IKE and ISAKMP, with PKI based X.509 certs, to establish one or more SAs that these two elements can then use to continuously authenticate, and optionally encrypt for confidentiality, UDP, TCP or SCTP transport layer communication sessions. This fundmental capability is critical for our use of IP technology for the transport of SS7 traffic, VoIP application signalling, (G)MPLS control plane signalling and OAM&P traffic. Without the ability of using IPsec we will be forced to use stove-pipe TSL methods that rarely interoperate, have never been proven to scale the the number of subjects we must contend with, will significantly increas complexity of operational controls, and increas management expense. Stu Jacobs Verizon Network Security Architecture At 6/12/02 01:02 PM, you wrote: >At 9:43 AM -0700 6/12/02, Michael Thomas wrote: >>The one thing I don't see here is any >>consideration of the very basic question of >>whether there are in fact two different problem >>spaces. > >There are certainly more than two. > >Michael is correct here in that we cannot evaluate the WG questions for >the general problem of keying all possible uses of IPsec. Well, we can >try, but it would be a waste of time (but typical of many IETF Working >Groups...). At the end of the effort, we would probably have no general >agreement on the significant questions. > >Having said that, and showing my obvious bias towards VPNs, I propose that >as we answer the questions, we do so with today's VPN customers in mind. >These folks mostly do two things: > >a) gateway-to-gateway, with each gateway possibly connecting to many other >gateways > >b) access over modems (or faster) from remote single-user computers > >Let's get SOI done right for these customers. > >Doing so doesn't prevent work from a different key exchange mechanism that >addresses a different use case; the most obvious one that probably won't >match with the use case above is remote access where there is a need for >very quick keying, or where the remote parties have relatively slow CPUs, >or where the remote parties have only small amounts of program memory, or >some combination of these. > >The work we have done in the past few months can help focus the feature >sets for each of these efforts, as well as for other efforts that might >arise later. But let's not pretend that we can do it all at once in a >single protocol -- we know we can't, and we have good evidence that we can >waste a lot of time trying. > >--Paul Hoffman, Director >--VPN Consortium ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com ========================== From owner-ipsec@lists.tislabs.com Fri Jun 14 10:45:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EHjbn16017; Fri, 14 Jun 2002 10:45:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16908 Fri, 14 Jun 2002 12:57:18 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B0B@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: ipsec@lists.tislabs.com Subject: RE: Son of IKE: A proposal for moving forward Date: Fri, 14 Jun 2002 10:11:42 -0700 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 Actually Moore's law is irrelevant here, or rather a corollary is more relevant. No matter how fast desktop machines become the number of 8 bit processors based on Z-80 and 6502 cores in use increases at the same rate as processor speed, number of circuits or any other factor you might want to consider. The reason for this is that 8 bit processors get cheaper and cheaper and get put into more and more stuff. At some point they will be put into light bulbs and such, they are already in some rechargable batteries. The real question is what point are you going to make the cut off. I think that we can actually be fairly precise here, anything that needs IPSEC is going to also need the ability to communicate via IP. That immediately excludes processors with 64Kb memory spaces from rational consideration (yes I do know about the Media lab HTTP server built on a single hydrogren atom etc.). For the majority of interesting cases adding communication to a device is likely to mean adding some form of wireless. At this point my bet is that Bluetooth is irrelevant and 802.11b is likely the only standard we need to consider which gives us a reasonably high CPU power to work from. Phill > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Thursday, June 13, 2002 8:15 PM > To: Dan Harkins > Cc: Michael Thomas; uri@bell-labs.com; Stuart Jacobs; > ipsec@lists.tislabs.com > Subject: Re: Son of IKE: A proposal for moving forward > > > On Thu, Jun 13, 2002 at 02:21:30PM -0700, Dan Harkins wrote: > > > > The handwaving is not over Moore's Law, it's over some vague > > "cheap wireless widget on the horizon". In fact, it's almost beyond > > handwaving to outright fearmongering. Both of the protocols under > > consideration are less heavy-weight than IKE and IKE has been > > implemented on PDAs and cellphones. > > > > Michael, > > If you could give us some specifics about what sorts of CPU/memory > resources you think these "cheap wireless widgets" will have, that > would be very helpful. Given that StrongARM and PPC processors are > regularly used in embedded devices, and very sophisticated systems > have been implemented on embedded devices (including full Linux > systems and full IKEv1 systems --- heck, IBM demonstrated Linux > running on a wristwatch! :-), without some quantifiable limitations > of these future wireless devices, it's very hard to move forward. > > - Ted > From owner-ipsec@lists.tislabs.com Fri Jun 14 10:54:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EHsvn16667; Fri, 14 Jun 2002 10:54:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16961 Fri, 14 Jun 2002 13:10:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PMTU and NAT-Traversal problem Date: Fri, 14 Jun 2002 10:23:38 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1077DD2B7@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: PMTU and NAT-Traversal problem Thread-Index: AcITor5Zm27K4gX0TbqONM8DlVfBzgAJQ96w From: "Brian Swander" To: "Lokesh N B" , "Ari Huttunen" Cc: "Jan Backman" , X-OriginalArrivalTime: 14 Jun 2002 17:23:39.0374 (UTC) FILETIME=[3931B0E0:01C213C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA16958 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There aren't too many choices here. General Ipsec policy securing all traffic may disallow untrusted ICMPs from intermediate routers, so this isn't necessarily a new problem. The obvious solution is black hole detection, where TCP gradually bumps down the MTU when it doesn't get a response. The other choice is to bump the MTU for all connections to the peer if the ICMP actually makes it. bs -----Original Message----- From: Lokesh N B [mailto:lokeshnb@intotoinc.com] Sent: Friday, June 14, 2002 5:37 AM To: Ari Huttunen Cc: Jan Backman; ipsec@lists.tislabs.com Subject: Re: PMTU and NAT-Traversal problem Implementing version 2 of UDP encaps draft doesn't solve the problem either. -Lokesh On Fri, 14 Jun 2002, Ari Huttunen wrote: > Note that draft-ietf-ipsec-udp-encaps-02.txt is different in this > respect because the 8 byte non-IKE marker was changed to a 4 byte > non-ESP marker. Still the UDP header itself is 64 bits. > > You shouldn't be implementing the -01 version in any case. > > Ari > > Lokesh wrote: > > > > Hello jan, > > Thanks, but that is not the answer to my question. > > problem is information for SA look up is not present in the returned > > ICMP PMTU message. Hence sender cannot determine in which SA to > > update returned MTU. I think I should explain it bit more clearly. > > When a IPSec packet with DF bit set, cannot be transmitted over a link with > > less MTU, > > the router would send ICMP PMTU error packet back to sender which > > contains IP header and 64 bits of IPSec headers of faulting packet as data. > > sender uses the SPI and other packet selectors in the 64 bit information to > > look up SA's and adjust their MTU with the returned MTU value in the ICMP > > PMTU message. > > Now, in case where NAT Traversal is supported, IPSec packets will be > > encapsulated in UDP packets and 8 bytes of NON -IKE marker, the 64 bit info > > after IP hdr will only contain UDP header using which sender cannot > > determine SA's over which original faulting packet was sent. > > Is there any solution exists for this problem? > > Thanks > > Lokesh > > > > At 01:59 PM 6/10/02 +0200, Jan Backman wrote: > > >Hi, > > >Store the information about the encountered MTU in the NAT and use > > >it to reply an ICMP when the next packet in the flow arrives (that > > >is larger than the MTU). > > > > > >regards /// Jan > > > > > > > -----Original Message----- > > > > From: Lokesh [mailto:lokeshnb@intotoinc.com] > > > > Sent: Monday, June 10, 2002 12:34 PM > > > > To: ipsec@lists.tislabs.com > > > > Subject: PMTU and NAT-Traversal problem > > > > > > > > > > > > Hi all, > > > > Is there anybody who implemented following in a security Gateway? > > > > 1. draft-ietf-ipsec-nat-t-ike-01.txt and > > > > draft-ietf-ipsec-udp-encaps-01.txt > > > > 2. Section 6 [ PMTU processing by IPSEC] of IPSec RFC (2401). if > > > > so, how did you solve following problem?......... > > > > > > > > For Unauthenticated ICMP PMTU message processing: > > > > > > > > The PMTU processing bound to fail, since ICMP PMTU error > > > > message would include > > > > only IP Hdr and 64 bits of IPsec Hdr information. Since UDP > > > > Encaps and NAT > > > > Traversal drafts encapsulate ipsec packets in UDP and put a 8 > > > > byte NON IKE > > > > marker,(totalling 16 bytes) > > > > PMTU error message returned will not have enough information > > > > to find the > > > > SA's at the receiving > > > > Security Gateway. How to solve this problem? any suggestions? > > > > any help in this regard is highly appreciated. > > > > Thanks > > > > Lokesh > > > > > > -- > > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F(ully)-Secure products: Securing the Mobile Enterprise > From owner-ipsec@lists.tislabs.com Fri Jun 14 11:54:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EIsZn20007; Fri, 14 Jun 2002 11:54:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17093 Fri, 14 Jun 2002 14:10:49 -0400 (EDT) Date: Fri, 14 Jun 2002 14:24:04 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: low end (was RE: Son of IKE...) In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869B0B@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 14 Jun 2002, Hallam-Baker, Phillip wrote: > ...we can actually be fairly precise here, anything that needs IPSEC is > going to also need the ability to communicate via IP. That immediately > excludes processors with 64Kb memory spaces from rational consideration... A rash statement, and not well founded in fact. Even disregarding certain historical examples which are arguably no longer relevant, TCP/IP is now showing up in the embedded-computing market. 8-bit processors, some with noticeably *less* than 64KB memory space, are now speaking IP, TCP, even HTTP, over RS232 or even Ethernet, in very large numbers... and many of those applications are at least potentially interested in security. Whether those applications are interested in IKE is a slightly different question. Many of them do intermittent, low-volume communications in a fairly static topology, and their needs could probably be met quite well with manual keying (in more ambitious cases, perhaps by a manually-keyed master connection used to communicate new session keys for application- specific connections). This doesn't mean that they aren't *interested* in IKE, mind you, only that accommodating their fairly-severe constraints is probably a "nice to have" rather than a firm requirement for IKE. Systems consisting, roughly, of a 33MHz 486 (no FPU) with 1MB each of RAM and ROM run embedded variants of Linux, and are of strong interest to the high-end embedded community, not least for their TCP/IP capabilities. That's definitely within our sphere of interest. There is a large region between those two levels, where there is also quite a bit of networking going on. But I can't claim recent familiarity with it and hence can't comment on it informatively. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jun 17 09:03:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HG3ln15136; Mon, 17 Jun 2002 09:03:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21953 Mon, 17 Jun 2002 10:57:31 -0400 (EDT) From: annelies.van_moffaert@alcatel.be Subject: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? To: ipsec@lists.tislabs.com Cc: Stephen Kent Date: Mon, 17 Jun 2002 17:10:27 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 06/17/2002 17:10:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, Some time ago I posted a comment on the list regarding the new IPsec AH and ESP I-Ds draft-ietf-ipsec-rfc2402bis-00.txt and draft-ietf-ipsec-esp-v3-02.txt In these drafts it is stated that for multicast the SPI in combination with the destination IP address is used to select an SA. This can however lead to ambiguity problems for SSM SAs (SSM = Source Specific Multicast). A range of multicast IP addresses is reserved for SSM. In SSM a group is characterized by the pair (source IP address, destination IP address) and every source can freely choose a destination IP address from the SSM range. This means that it is possible that two different sources use the same group address as IP destination address. If the group controllers of the 2 would happen to choose the same SPI value then the common receivers cannot distinguish between the SAs for the 2 different groups since they have the smae SPI and the same destination IP address. I think a good solution would be to include also the source address in the SA selector for multicast SAs. This would also be very useful to protect IGMP messages by means of IPsec AH. Steve Kent, author of the I-Ds, replied to me that it is up to the WG to discuss this, hence my email... So I have to questions for the group: Is the above mentioned problem already solved for the IPsec AH and ESP I-Ds? and Could the source IP address be included as SA selector? Kind regards, Lies Van Moffaert. Stephen Kent on 03/05/2002 22:44:03 To: Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL cc: ipsec@lists.tislabs.com Subject: At 2:51 PM +0200 4/30/02, annelies.van_moffaert@alcatel.be wrote: >Hi Steven and all, > >I read the new IP Authentication Header I-D and I have a small question or >remark about the multicast SAs. I saw that these are identified by the >destination IP address >and the SPI value and optionally, the protocol ID. >I'm not sure whether this rules out all possible ambiguity for SSM. For SSM >the IP destination address does not need to be unique (if I remember >correctly). A group session is in SSM identified by the pair (Source IP, >Destination IP) and it is possible that 2 different sources choose the same >SSM group address as Destination IP address. The group controller of each >will pick independently an SPI number. It's of course very unlikely but I >think that it is then strictly speaking possible to have the same (SPI, >Destination IP) pair for 2 different SSM sessions. In this case the >receiver cannot differentiate between two different SAs since they have the >same identification pair (Destion IP, SPI). Is this correct or did I >overlook something? > >Kind regards, > Lies From owner-ipsec@lists.tislabs.com Mon Jun 17 12:10:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HJAPn24741; Mon, 17 Jun 2002 12:10:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22360 Mon, 17 Jun 2002 14:28:55 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15630.11628.390252.673452@thomasm-u1.cisco.com> Date: Mon, 17 Jun 2002 11:41:48 -0700 (PDT) To: Dan Harkins Cc: Michael Thomas , uri@bell-labs.com, Stuart Jacobs , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: <200206132121.g5DLLdk27941@trpz.com> References: <15624.52526.918067.188334@thomasm-u1.cisco.com> <200206132121.g5DLLdk27941@trpz.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 Dan Harkins writes: > Mike, > > On Thu, 13 Jun 2002 09:49:50 PDT you wrote > > > > I'm not sure that that's what I meant, but I can > > see how it would be construed that way. As I said, > > I'm rather schizophrenic about this issue. We > > really, really need to enable strong auth on the > > next gen of IP widgets -- ie, things that aren't > > going to have 80GB disks and 512MB of ram to > > fritter away. > > The problem with such hyperbole is that it tends to get > traction. > > No key management protocol under consideration requires 80GB disks > or 512MB or any kind of "frittering". And in fact, IKE has been > implemented on such small IP widgets as PDAs and cellphones. > > > Ted's right that Moore's law eventually solves > > this, but that's a rather facile arguement if it > > solves it *too late*. That is, if the next gen of > > widgets either do without strong auth altogether, > > or find something like WEP which is "easier" to > > implement at the cost of near complete insecurity, > > we're not doing the user base any favors. > > > > Frankly, I don't think that we're really at the > > point where we can handwave things away with > > Moore's law: there's a whole new generation of > > cheap wireless widgets on the horizon and they > > have a hard time swallowing IKE as it's currently > > defined. Nor do they seem to need a lot of what > > IKE has to offer: cell phones seem to work pretty > > OK with simple SIM based authentication. That is, > > their needs seem simplier than your average road > > warrior. > > Right, they need what IEEE802.1x and the EAP WG are providing. > Although I find it hard to understand arguments that talk > about the bulk of IKE but suggest that EAPoL (several state > machines) encapsulated EAP packets (another state machine) which > encapsulate (sometimes fragmented!!!) TLS packets (another huge > state machine), supporting all the certificate infrastructure that > requires, is somehow less bulky. That's a monsterous amount of > interconnected code. But somehow that's OK while IKE is > bloatware. > > The handwaving is not over Moore's Law, it's over some vague > "cheap wireless widget on the horizon". In fact, it's almost beyond > handwaving to outright fearmongering. Both of the protocols under > consideration are less heavy-weight than IKE and IKE has been > implemented on PDAs and cellphones. > > > This is why I wonder if there are two problem > > spaces. You've taken this to mean my suggesting > > that the split should VPN/not-VPN, but that's > > just one way to carve the problem space up. > > Another might be to differentiate via remote > > access, or some other split. A third way to deal > > with this is to potentially legitimize "profiles" > > where we have a very slim inner protocol which can > > and should be implemented by *everything* where > > you have additional functionality layered on > > through, say, different standard's track RFC's, > > or whatever. > > > > The bottom line is that I'm much more interested > > that this issue is considered seriously than any > > particular way to solve it. When I floated the > > JFK/IKEv2 split, it was mainly because I can see > > how to make JFK a very light weight -- but still > > useful -- means of establishing transport and > > tunnel mode SA's. I like IPsec, generally, because > > it opens a lot of options. It would be really nice > > to have a base level keying mechanism which would > > be shameful not to implement. I think that's > > within reach right now, even if the kitchen sink > > is not. > > You can't "make JFK very light weight"; it is not an extensible > protocol. You have mutual, public-key based authentication, > period. No SIM card authentication is possible. You can't take > some and leave some, and you definitely can't add some. It's not > that kind of protocol. If the widget you describe above is happy > with SIM-based authentication then it will not be happy with JFK > just as it is not happy with IKE, as you claim. Dan, Rather than going down the lines of debating fell creatures like EAP-TLS (ack, ptui), maybe it would be better to go the constructive route here and see whether we can make a SOI such that there just can't be any realistic arguments why a widget vendors can't implement it. As I've said, I've done some experimenting and I can fit a usable keying + crypto solution into about 30-40kb of code including the crypto and modular arithmetic libraries. This is down about an order of magnitude from a typical IPsec/IKE stack. At that cost, I cannot see how a reasonable widget maker could balk. At 10 times the cost, I have seen them balk many, many times. And as you know, I work for an employer who doesn't have a particularly good record of, er, keeping bloat down, so I imagine that at shops where pennies are the difference between negative and positive margins, it would be even harder. How did I do this? 1) Cut the complexity of the state machine by not having to deal with phases 2) Cut the complexity of SA keying and general accrued kruftiness 3) Cut the number of required identity modes to exactly one (eg, using raw DH public identities, though RSA could be added for about a 5kb cost). So, it just so happens that after I did this (I whimsically called it SPUNK -- StopgaP Ugly Network Keying), I noticed that it ended up looking a whole lot like JFK, and then proceeded to see if I could transmogrify it into JFK, which was relatively straightforward. So the real question to you is whether you can do something similar with IKEv2, and whether we can structure SOI such that we can have a base level standards compliant keying mechanism which is extremely hard for vendors to blow off because it costs too much -- and then proceed to implement junk like WEP and other lame L2 isms. My gut level feeling is that IKEv2 could certainly be trimmed down considerably if we you took similar measures as I did above. I doubt it will be as small as what I managed, but _here_ discussions of Moore's law might be relevant because the difference between 30-40k and 50-60k might not be large enough to quibble about (unlike the perceived cost of 500k). After all, if the end result is a single protocol which has these space savings, I'm certainly not going to complain. But then I'm not sure if this is even achievable with IKEv2 -- or whether you and your other authors think this is just a load of hooey, which might bring us back to my original question of whether there really are two incompatible problem spaces. Mike From owner-ipsec@lists.tislabs.com Mon Jun 17 12:35:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HJZVn26603; Mon, 17 Jun 2002 12:35:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22458 Mon, 17 Jun 2002 14:55:14 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15630.13170.558413.453174@thomasm-u1.cisco.com> Date: Mon, 17 Jun 2002 12:07:30 -0700 (PDT) To: "Theodore Ts'o" Cc: Dan Harkins , Michael Thomas , uri@bell-labs.com, Stuart Jacobs , ipsec@lists.tislabs.com Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: <20020614001502.GC612@think.thunk.org> References: <15624.52526.918067.188334@thomasm-u1.cisco.com> <200206132121.g5DLLdk27941@trpz.com> <20020614001502.GC612@think.thunk.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 Theodore Ts'o writes: > If you could give us some specifics about what sorts of CPU/memory > resources you think these "cheap wireless widgets" will have, that > would be very helpful. Given that StrongARM and PPC processors are > regularly used in embedded devices, and very sophisticated systems > have been implemented on embedded devices (including full Linux > systems and full IKEv1 systems --- heck, IBM demonstrated Linux > running on a wristwatch! :-), without some quantifiable limitations > of these future wireless devices, it's very hard to move forward. I can't give any specifics, just the my general observation of watching this play out in real life. What you're missing here is not whether it _could_ be included, but whether including it means that perceived revenue generating features will have to be foregone because of security. The unfortunate fact is that security is not generally seen as an offseting feature; it's just a cost, not a product differentiator. Half of the problem of getting pervasive crypto is just getting it into things. Lowering the energy barrier here would change a lot of the dynamics that I've seen, and as I said to Dan, I work for a company where bloat isn't one of the major cultural evils -- unlike consumer electronics companies where those pennies add up. Mike From owner-ipsec@lists.tislabs.com Tue Jun 18 06:28:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IDSqn22861; Tue, 18 Jun 2002 06:28:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24136 Tue, 18 Jun 2002 08:39:29 -0400 (EDT) Subject: No acceptable Oakley Transform From: Neil Dombrowski To: ipsec@lists.tislabs.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 13:22:56 -0700 Message-Id: <1024086176.7369.25.camel@brain.ebuilt.net> Mime-Version: 1.0 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a linux (Mandrake 8.2) system that I have installed FreeS/WAN 1.97 and am trying to establish a tunnel with a Symantec Velociraptor(?) IPSEC server. He can only do D-H groups 1 and 2, freewans does only 2 and 5. Will this work? I keep getting "no preshared key found" and "no acceptable Oakley Transform. I need to get this up, but my counterpart and I are up against a wall. Any hints what we can do to get this working? Thanks, Neil ----------------------- Jun 14 13:01:47 lake Pluto[6988]: | **parse ISAKMP Message: Jun 14 13:01:47 lake Pluto[6988]: | initiator cookie: Jun 14 13:01:47 lake Pluto[6988]: | 37 a8 ff bf fd d0 a9 e5 Jun 14 13:01:47 lake Pluto[6988]: | responder cookie: Jun 14 13:01:47 lake Pluto[6988]: | f7 c3 a0 c5 0d 26 89 c4 Jun 14 13:01:47 lake Pluto[6988]: | next payload type: ISAKMP_NEXT_SA Jun 14 13:01:47 lake Pluto[6988]: | ISAKMP version: ISAKMP Version 1.0 Jun 14 13:01:47 lake Pluto[6988]: | exchange type: ISAKMP_XCHG_IDPROT Jun 14 13:01:47 lake Pluto[6988]: | flags: none Jun 14 13:01:47 lake Pluto[6988]: | message ID: 00 00 00 00 Jun 14 13:01:47 lake Pluto[6988]: | length: 113 Jun 14 13:01:47 lake Pluto[6988]: | ICOOKIE: 37 a8 ff bf fd d0 a9 e5 Jun 14 13:01:47 lake Pluto[6988]: | RCOOKIE: f7 c3 a0 c5 0d 26 89 c4 Jun 14 13:01:47 lake Pluto[6988]: | peer: d8 22 c5 d7 Jun 14 13:01:47 lake Pluto[6988]: | state hash entry 23 Jun 14 13:01:47 lake Pluto[6988]: | state object not found Jun 14 13:01:47 lake Pluto[6988]: | ICOOKIE: 37 a8 ff bf fd d0 a9 e5 Jun 14 13:01:47 lake Pluto[6988]: | RCOOKIE: 00 00 00 00 00 00 00 00 Jun 14 13:01:48 lake Pluto[6988]: | peer: d8 22 c5 d7 Jun 14 13:01:48 lake Pluto[6988]: | state hash entry 26 Jun 14 13:01:48 lake Pluto[6988]: | state object #1 found, in STATE_MAIN_I1 Jun 14 13:01:48 lake Pluto[6988]: | ***parse ISAKMP Security Association Payload: Jun 14 13:01:48 lake Pluto[6988]: | next payload type: ISAKMP_NEXT_VID Jun 14 13:01:48 lake Pluto[6988]: | length: 52 Jun 14 13:01:48 lake Pluto[6988]: | DOI: ISAKMP_DOI_IPSEC Jun 14 13:01:48 lake Pluto[6988]: | ***parse ISAKMP Vendor ID Payload: Jun 14 13:01:48 lake Pluto[6988]: | next payload type: ISAKMP_NEXT_NONE Jun 14 13:01:48 lake Pluto[6988]: | length: 33 Jun 14 13:01:48 lake Pluto[6988]: "phs" #1: ignoring Vendor ID payload Jun 14 13:01:48 lake Pluto[6988]: | VID: 52 61 70 74 6f 72 20 50 6f 77 65 72 56 70 6e 20 Jun 14 13:01:48 lake Pluto[6988]: | 53 65 72 76 65 72 20 5b 56 36 2e 35 5d Jun 14 13:01:48 lake Pluto[6988]: | ****parse IPsec DOI SIT: Jun 14 13:01:48 lake Pluto[6988]: | IPsec DOI SIT: SIT_IDENTITY_ONLY Jun 14 13:01:48 lake Pluto[6988]: | ****parse ISAKMP Proposal Payload: Jun 14 13:01:48 lake Pluto[6988]: | next payload type: ISAKMP_NEXT_NONE Jun 14 13:01:48 lake Pluto[6988]: | length: 40 Jun 14 13:01:48 lake Pluto[6988]: | proposal number: 0 Jun 14 13:01:48 lake Pluto[6988]: | protocol ID: PROTO_ISAKMP Jun 14 13:01:48 lake Pluto[6988]: | SPI size: 0 Jun 14 13:01:48 lake Pluto[6988]: | number of transforms: 1 Jun 14 13:01:48 lake Pluto[6988]: | *****parse ISAKMP Transform Payload (ISAKMP): Jun 14 13:01:48 lake Pluto[6988]: | next payload type: ISAKMP_NEXT_NONE Jun 14 13:01:48 lake Pluto[6988]: | length: 32 Jun 14 13:01:48 lake Pluto[6988]: | transform number: 1 Jun 14 13:01:48 lake Pluto[6988]: | transform ID: KEY_IKE Jun 14 13:01:48 lake Pluto[6988]: | ******parse ISAKMP Oakley attribute: Jun 14 13:01:48 lake Pluto[6988]: | af+type: OAKLEY_LIFE_TYPE Jun 14 13:01:48 lake Pluto[6988]: | length/value: 1 Jun 14 13:01:48 lake Pluto[6988]: | [1 is OAKLEY_LIFE_SECONDS] Jun 14 13:01:48 lake Pluto[6988]: | ******parse ISAKMP Oakley attribute: Jun 14 13:01:48 lake Pluto[6988]: | af+type: OAKLEY_LIFE_DURATION Jun 14 13:01:48 lake Pluto[6988]: | length/value: 3600 Jun 14 13:01:48 lake Pluto[6988]: | ******parse ISAKMP Oakley attribute: Jun 14 13:01:48 lake Pluto[6988]: | af+type: OAKLEY_ENCRYPTION_ALGORITHM Jun 14 13:01:48 lake Pluto[6988]: | length/value: 5 Jun 14 13:01:48 lake Pluto[6988]: | [5 is OAKLEY_3DES_CBC] Jun 14 13:01:48 lake Pluto[6988]: | ******parse ISAKMP Oakley attribute: Jun 14 13:01:48 lake Pluto[6988]: | af+type: OAKLEY_HASH_ALGORITHM Jun 14 13:01:48 lake Pluto[6988]: | length/value: 1 Jun 14 13:01:48 lake Pluto[6988]: | [1 is OAKLEY_MD5] Jun 14 13:01:48 lake Pluto[6988]: | ******parse ISAKMP Oakley attribute: Jun 14 13:01:48 lake Pluto[6988]: | af+type: OAKLEY_AUTHENTICATION_METHOD Jun 14 13:01:48 lake Pluto[6988]: | length/value: 1 Jun 14 13:01:48 lake Pluto[6988]: | [1 is OAKLEY_PRESHARED_KEY] Jun 14 13:01:48 lake Pluto[6988]: "phs" #1: Can't authenticate: no preshared key found for `x.x.x.x' and `y.y.y.y'. Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 13:01:48 lake Pluto[6988]: "phs" #1: no acceptable Oakley Transform Jun 14 13:01:48 lake Pluto[6988]: | state transition function for STATE_MAIN_I1 failed: NO_PROPOSAL_CHOSEN Jun 14 13:01:48 lake Pluto[6988]: | next event EVENT_RETRANSMIT in 12 seconds for #1 -- Neil Dombrowski IS Manager eBuilt, Inc 3540 Howard Way Costa Mesa, CA 92626 949-609-4757 From owner-ipsec@lists.tislabs.com Tue Jun 18 06:29:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IDTPn22888; Tue, 18 Jun 2002 06:29:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24132 Tue, 18 Jun 2002 08:39:27 -0400 (EDT) Message-Id: <5.1.1.6.0.20020614105529.0282c6e0@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 14 Jun 2002 13:38:30 -0400 To: cmadson@cisco.com, ipsec@lists.tislabs.com From: Stuart Jacobs Subject: Re: Son of IKE: A proposal for moving forward In-Reply-To: References: <5.1.0.14.2.20020613085307.025f7880@pophost.gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As an aid to expressing my concerns and needs let me provide a context for my prior comments. Verizon is currently developing the architecture for a Next Generation Network (NGN) that is based on non-TDM technologies. This NGN will serve as Verizon's core network infrastructure well into the 21st century and must be a highly available, reliable and trustable infrastructure that will scale to 100,000s of intermediate nodes, 10,000s of server platforms and millions of customers across the globe. Given the scaling issues in such a network we want to use IPsec, coupled with PKI technology, within our NGN. Although not specifically an IPsec issue, we also have to contend with different trust domains within Verizon, between Verizon and peer carriers and between Verizon and our customers and would establish a hierarchy of CAs for issuing X.509 certificates to Verizon network elements as well as to Verizon, and non-Verizon, people and organizations. Our NGN, from a control and management perspective, is a "green field" deployment and our proposed approach would use IPv6, with mandatory IPsec, for all control, signaling and management traffic within our NGN infrastructure. We are concerned with protecting control plane, management plane and application-specific signaling traffic within our NGN on an end-node to end-node basis. The protection needed is primarily authentication with some traffic (specifically billing info, customer profiles and user application log-in identifiers/passwords) requiring confidentiality. We intend to use control plane protocols, such as RSVP-TE or CR-LDP, between all intermediate nodes. These nodes (such as GMPLS controlled optical switches, (G)MPLS enabled routers, SONET-ADMs, etc.) will need to continuously communicate with each other where all exchanged information must be strongly authenticated. This will necessitate SAs that are basically permanent yet either re-keyable or replaceable in a controlled and synchronized manner. The traffic flowing over these SAs require authentication either by AH or null-encrypted ESP. At this point we do not see one approach (AH or null-encrypted ESP) as significantly better that the other. We would most likely use transport mode for efficiency and do not have to worry about NAT given an IPv6 based addressing and inter-networking architecture within our infrastructure. Control plane interaction at trust domain boundaries will utilize an OIF-UNI approach, not peering, so we can make necessary access control decisions on NGN usage requests. Some of our management layer applications (OAM&P) we will be developing in-house and some of these applications we will be purchasing from vendors. Our element and network management OAM&P applications operate on a 7 by 24 basis. Many of our NGN system and business management OAM&P applications will also have to operate 7 by 24 to support customer and peer carrier self-provisioning/management dynamic requests. The OAM&P protocols will include SNMPvX, CORBA, Telnet (with TL1), Xterm, FTP, HTTP/HTML and in some cases TFTP where unavoidable. The use of XML will grow over time. Given the wide variety of protocols here we cannot afford to use protocol specific security approaches that are managed independently and would be very difficult and expensive to manage and maintain in an infrastructure as large as our NGN will be. IPsec is the only approach available that is protocol neutral and centrally manageable. Since the use of SNMP and CORBA will be continuous between managed elements and element/network managers we would anticipate using the same type of basically permanent SAs described above for control plane protocols. The Telnet (with TL1), Xterm, FTP and TFTP protocols we would want to use with dynamic SAs that are negotiated at TCP session setup and torn down when the TCP sessions end. The use of HTTP/HTML and XML would incur significant overhead if secured via dynamic SAs, yet do not really require use of permanent SAs, so I would propose the ability to establish semi-permanent SAs that have a defined lifetime and are torn down when their lifetime is reached unless recently used within the last XXX seconds or minutes. Thus we need three types of SAs that can be established between two communication nodes: a) permanent SAs that can be established with specified destination nodes, when either node boots/reboots, and can be rekeyed, or replaced with new SAs, after specified time periods have elapsed in a controlled and synchronized manner. b) semi-permanent, or static, SAs that exist for specified time periods and can be used by applications. An application needing to communicate with a corresponding application in another node can request use of a static SA and the IPsec portion of the protocol stack will use one if it exists or establish one if none currently exist. When one of these static SAs has reached/exceeded its specified life-span of time it would be torn down provided it has not been used within the last XXX seconds or minutes. c) dynamic SAs that are negotiated at TCP session setup and torn down when the TCP sessions end. These SAs could possibly exist for long periods of time (eg. long Xterm sessions or very large file transfers) so they should be able to be rekeyed, or replaced with new SAs, after specified time periods have elapsed in a controlled and synchronized manner. From a usability perspective, there should be some type of data structure that can be configured to contain default and maximum values for all SAs created by the network element. I would proposed that some of these values include: - maximum SA time before re-keying - preferred authentication mechanism (AH or null-encryption ESP) - minimum allowed algorithm for AH - preferred algorithm for AH - minimum allowed algorithm for null-encryption ESP - preferred algorithm for null-encryption ESP - Applications will most likely use a socket based mechanism to establish a communications path to another network node and should be able to easily specify the type of SA, if any, desired. I would like to see an application be able to state it wants no SA, a permanent SA, a static SA or a dynamic SA used. An application should be able to ask for an SA based on the network element default values, yet on the other hand be able to request an SA with values that over ride the network element default values. Forgive me for possibly being long-winded. My intent is simply to assist the WG in understanding what kinds of capabilities we want IPsec to provide. May this serve as input to section 4.3 of draft-ietf-ipsec-sonofike-rqts-00.txt Stu t 6/13/02 12:05 PM, you wrote: >I urge you to review >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt >and provide feedback. This groups lacks a lot of real-world customer >feedback and Cheryl would appreciate having any feedback. > >jan > > >On Thu, 13 Jun 2002, Stuart Jacobs wrote: > > > If this group restricts their focus primarily on the VPN scenarios below > > then they are ignoring a major role that IPsec is expected to fill by large > > enterprises. > > > > Verizon is in the process of developing the security architecture for it's > > next generation networks. Given the magnitude of these networks and FCC > > requirements for open access, we must have the ability to universally > > establish strongly authenticated identities of communicating network > > elements. This authentication must be able to span many trust domains, be > > continuous to avoid any chance of session hi-jacking and scale to millions > > of nodes. IPsec, coupled with PKI, is the only technology that can even > > begin to meet our needs. > > > > We are relying on this WG to include in it's scope mechanisms that allow > > two network elements, regardless of their functions within a network, to be > > able to use IKE and ISAKMP, with PKI based X.509 certs, to establish one or > > more SAs that these two elements can then use to continuously authenticate, > > and optionally encrypt for confidentiality, UDP, TCP or SCTP transport > > layer communication sessions. This fundmental capability is critical for > > our use of IP technology for the transport of SS7 traffic, VoIP application > > signalling, (G)MPLS control plane signalling and OAM&P traffic. > > > > Without the ability of using IPsec we will be forced to use stove-pipe TSL > > methods that rarely interoperate, have never been proven to scale the the > > number of subjects we must contend with, will significantly increas > > complexity of operational controls, and increas management expense. > > > > Stu Jacobs > > Verizon Network Security Architecture > > > > > > At 6/12/02 01:02 PM, you wrote: > > >At 9:43 AM -0700 6/12/02, Michael Thomas wrote: > > >>The one thing I don't see here is any > > >>consideration of the very basic question of > > >>whether there are in fact two different problem > > >>spaces. > > > > > >There are certainly more than two. > > > > > >Michael is correct here in that we cannot evaluate the WG questions for > > >the general problem of keying all possible uses of IPsec. Well, we can > > >try, but it would be a waste of time (but typical of many IETF Working > > >Groups...). At the end of the effort, we would probably have no general > > >agreement on the significant questions. > > > > > >Having said that, and showing my obvious bias towards VPNs, I propose that > > >as we answer the questions, we do so with today's VPN customers in mind. > > >These folks mostly do two things: > > > > > >a) gateway-to-gateway, with each gateway possibly connecting to many other > > >gateways > > > > > >b) access over modems (or faster) from remote single-user computers > > > > > >Let's get SOI done right for these customers. > > > > > >Doing so doesn't prevent work from a different key exchange mechanism that > > >addresses a different use case; the most obvious one that probably won't > > >match with the use case above is remote access where there is a need for > > >very quick keying, or where the remote parties have relatively slow CPUs, > > >or where the remote parties have only small amounts of program memory, or > > >some combination of these. > > > > > >The work we have done in the past few months can help focus the feature > > >sets for each of these efforts, as well as for other efforts that might > > >arise later. But let's not pretend that we can do it all at once in a > > >single protocol -- we know we can't, and we have good evidence that we can > > >waste a lot of time trying. > > > > > >--Paul Hoffman, Director > > >--VPN Consortium > > > > ========================== > > Stuart Jacobs CISSP > > PMTS - Sr. Technologist > > Verizon Laboratories > > 40 Sylvan Road Waltham, MA 02451-1128 USA > > telephone: (781) 466-3076 fax: (781) 466-2838 > > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > > ========================== > > > > -- >Jan Vilhuber vilhuber@cisco.com >Cisco Systems, San Jose (408) 527-0847 > >http://www.eff.org/cafe ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com ========================== From owner-ipsec@lists.tislabs.com Tue Jun 18 06:45:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IDjgn23688; Tue, 18 Jun 2002 06:45:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24202 Tue, 18 Jun 2002 08:59:31 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <200206101116.HAA28186@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;; Cc: ipsec@lists.tislabs.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt Date: Mon, 10 Jun 2002 07:16:30 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, H. Herbert Filename : draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt Pages : 11 Date : 07-Jun-02 A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for mes- sages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.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-ciph-aes-xcbc-mac-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607132522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607132522.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 18 06:46:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IDkHn23724; Tue, 18 Jun 2002 06:46:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24208 Tue, 18 Jun 2002 08:59:34 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E602A81871@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: ipsec@lists.tislabs.com Subject: Sidetracked Date: Mon, 17 Jun 2002 14:45:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2162F.1730BAFE" 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_01C2162F.1730BAFE Content-Type: text/plain; charset="iso-8859-1" Hello Barbara, Ted et al, At the conclusion of the last meeting, there was some talk to merge the two next version of IKE drafts, though I don't know how seriously this was pursued. Paul Hoffman's Features document was, I believe, a valid attempt of doing something to combine the 2 groups. Paul took the lead and asked each team of authors to take certain sections to help him come up with the draft we have today. In the spirit of cooperation to advance the next version of the IKE protocol, I will solicit the opinions of my security colleagues in regards to the questions in Ted's e-mail sent earlier last week. The efforts made by Paul Hoffman and Cheryl Madson to frame the issue are commendable and it must be frustrating that the response has been minimal, at least to this point in time. It would have been time well spent if prior to the first version of IKE, this sort of requirement analysis and features review had been conducted before the protocol was written and then ultimately accepted and now implemented around the globe. But that is history. Given the fact that we are discussing the approval for the next generation of an existing protocol, can we agree that the implementers and users of IKE know what scenario best suits their needs. If that be so, one could suppose that the usage scenarios, whatever they may be for different user organizations, are known and in play. I would then propose that these users are seeking a better, more efficient IKE protocol that allows them some amount of compatibility with their initial investment as well as code reuse. Protocol functionality and interoperability, in my humble opinion, trump features tied to specific scenarios. We are therefore tasked as a WG, with delivering the next version of a protocol, not the next scenario of how that protocol might or might not be used. Which brings us all back to where we were in December in Salt Lake City - we have two concepts written for the next version of IKE. The basic merits of each should be the focus of a review with final acceptance being the goal. Previously, I have argued in favor of the draft known as IKEv2 because of its completeness and very thorough attention to details. It is thorough enough as written (December 2001 version) that my company is well on the way to having it implemented in one of our best known products. That being said, there are good merits with the Just Fast Keys (JFK) draft and the subsequent revisions. Today, in June 2002, there really isn't a big difference in complexity between JFK and IKEv2. The IKEv2 spec is longer, but mostly because the authors included a lot of tutorial material (e.g., cookies), perhaps unnecessarily. If you read the draft, the design itself is not significantly more complex. The main additional functionality is retaining the 2nd phase, which is useful for creating multiple SAs, and for having a cryptographically protected informational channel. IKEv2 also includes explicit support for rekeying, which also seems to have a significant constituency. If support of these features make IKEv2 more complex, it might be reasonable to consider two protocols; a simpler one for where these features are not required, and the more complete protocol where they are required. In reality there isn't a great deal more complexity with either draft. However, the world is certainly simpler if we go with a single well-designed protocol that provides the functionality that users need. Again, I would like to refocus our attention to approving one of the two next generation drafts as written. It is my strong conviction that there will not be a clearly articulated "features wish list" from the current exercise of consultation. There may be marginal direction one way or the other, but no over riding direction. A quick look at the comments coming from the list in the last few days is an indication of non-focused consensus. I would encourage the membership and it's leaders to call for definitive approval of one of the two drafts as currently written while we are in Yokohama. We can research this protocol into perpetual churn. Rather, we must be bold enough to make a decision, live with the consequences and move on knowing that not all parties will be 100% pleased by any decision. The authors of both drafts have invested lots of their time as well as incorporated a year's worth of comments and suggestions from the membership. It is now incumbent upon the membership to step up to the plate and decide. Best regards, Dennis Beard ------_=_NextPart_001_01C2162F.1730BAFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sidetracked

Hello Barbara, Ted et = al,

At the conclusion of the last = meeting, there was some talk to merge the two next version of IKE = drafts, though I don't know how seriously this was pursued.  Paul = Hoffman's Features document was, I believe, a valid attempt of doing = something to combine the 2 groups. Paul took the lead and asked each = team of authors to take certain sections to help him come up with the = draft we have today.  In the spirit of cooperation to advance the = next version of the IKE protocol, I will solicit the opinions of my = security colleagues in regards to the questions in Ted's e-mail sent = earlier last week.  The efforts made by Paul Hoffman and Cheryl = Madson to frame the issue are commendable and it must be frustrating = that the response has been minimal, at least to this point in = time.  It would have been time well spent if prior to the first = version of IKE, this sort of requirement analysis and features review = had been conducted before the protocol was written and then ultimately = accepted and now implemented around the globe.  But that is = history.

Given the fact that we are = discussing the approval for the next generation of an existing = protocol, can we agree that the implementers and users of IKE know what = scenario best suits their needs.  If that be so, one could suppose = that the usage scenarios, whatever they may be for different user = organizations, are known and in play.  I would then propose that = these users are seeking a better, more efficient IKE protocol that = allows them some amount of compatibility with their initial investment = as well as code reuse.  Protocol functionality and = interoperability, in my humble opinion, trump features tied to specific = scenarios.  We are therefore tasked as a WG, with delivering the = next version of a protocol, not the next scenario of how that protocol = might or might not be used.  Which brings us all back to where we = were in December in Salt Lake City - we have two concepts written for = the next version of IKE.  The basic merits of each should be the = focus of a review with final acceptance being the goal.

Previously, I have argued in = favor of the draft known as IKEv2 because of its completeness and very = thorough attention to details.  It is thorough enough as written = (December 2001 version) that my company is well on the way to having it = implemented in one of our best known products.  That being said, = there are good merits with the Just Fast Keys (JFK) draft and the = subsequent revisions.  Today, in June 2002, there really isn't a = big difference in complexity between JFK and IKEv2.  The IKEv2 = spec is longer, but mostly because the authors included a lot of = tutorial material (e.g., cookies), perhaps unnecessarily.  If you = read the draft, the design itself is not significantly more complex. = The main additional functionality is retaining the 2nd phase, which is = useful for creating multiple SAs, and for having a cryptographically = protected informational channel. IKEv2 also includes explicit support = for rekeying, which also seems to have a significant = constituency. 

If support of these features = make IKEv2 more complex, it might be reasonable to consider two = protocols; a simpler one for where these features are not required, and = the more complete protocol where they are required.  In reality = there isn't a great deal more complexity with either draft. However, = the world is certainly simpler if we go with a single well-designed = protocol that provides the functionality that users need.

Again, I would like to = refocus our attention to approving one of the two next generation = drafts as written.  It is my strong conviction that there will not = be a clearly articulated "features wish list" from the = current exercise of consultation.  There may be marginal direction = one way or the other, but no over riding direction.  A quick look = at the comments coming from the list in the last few days is an = indication of  non-focused consensus.  I would encourage the = membership and it's leaders to call for definitive approval of one of = the two drafts as currently written while we are in Yokohama.  We = can research this protocol into perpetual churn.  Rather, we must = be bold enough to make a decision, live with the consequences and move = on knowing that not all parties will be 100% pleased by any = decision.  The authors of both drafts have invested lots of their = time as well as incorporated a year's worth of comments and suggestions = from the membership.  It is now incumbent upon the membership to = step up to the plate and decide. 

Best regards,

Dennis Beard





------_=_NextPart_001_01C2162F.1730BAFE-- From owner-ipsec@lists.tislabs.com Tue Jun 18 12:41:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IJfOn14520; Tue, 18 Jun 2002 12:41:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24872 Tue, 18 Jun 2002 14:39:00 -0400 (EDT) Date: 18 Jun 2002 14:39:35 -0400 Message-ID: <000801c216f7$7f3b6f90$5570e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Thomas'" Cc: ipsec@lists.tislabs.com Subject: RE: Son of IKE: A proposal for moving forward 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <15630.11628.390252.673452@thomasm-u1.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, to reply to this message and some of your earlier comments: > FWIW, I've actually written something that really > keys real SA's using something that looks a great > deal like JFK. It works. It's really small. As in > no excuses small. So, I don't think this is quite > as much vaporware as your letting on here. The vaporware is not JFK. The vaporware is all the anciliary protocols that we already have for IKEv1, from remote access to NAT traversal. > As I've said, I've > done some experimenting and I can fit a usable > keying + crypto solution into about 30-40kb of > code including the crypto and modular arithmetic > libraries. This is down about an order of > magnitude from a typical IPsec/IKE stack. But you're doing something unfair. You are comparing your own prototype KMP, which has been specifically optimized for size, with a "typical" IPsec/IKE stack (which doesn't make sense... are you comparing IKE+IPsec to SPUNK+IPsec or just SPUNK?). I think we all have the ability to build scaled down versions of our products if we want (strip out 90% of the crypto, etc). About the only fundamental difference is the 1 vs 2 phase issue, and that can hardly account for a factor of 10 increase in size. > The one thing I don't see here is any > consideration of the very basic question of > whether there are in fact two different problem > spaces. The slant of this working group is very > VPN-centric, much to the burden of things which > aren't especially interested in remote access, > amortization of authentication expense, etc, etc. In a sense, I agree with you. I think that everybody here knows there is a rift in the working group, as there has been for as long as I can remember. Perhaps the reason that people are reluctant to make constructive comments on this list, particularly in reference to the requirements document, is that there is very little chance of achieving consensus (I admit to being guilty in this regard). If the goal is simply to provide a specialized KMP for widgets, then I wonder why the JFK team didn't merely start an alternate WG like KINK did. (Speaking of which, I wonder why you are so interested in SOI; are you unhappy with the way KINK turned out?) But clearly JFK was not really aimed at widgets; it was aimed at PCs and servers. The VPN vendors popularized IPsec, and secure remote access is not going away anytime soon (as it turns out, I'm using it to send this message). With IPsec now standard in most computer OSs, it doesn't make sense for SOI to not support a popular and legitimate usage scenario. > A third way to deal > with this is to potentially legitimize "profiles" > where we have a very slim inner protocol which can > and should be implemented by *everything* where > you have additional functionality layered on > through, say, different standard's track RFC's, > or whatever. I agree with the concept of profiles. I think it is completely valid for a community with a specific requirement to define a subset of the standard for one specific purpose. There are a few very vocal WG members who say that if it doesn't do all the MUSTs then it's not IPsec (and you can't even call it IPsec-lite or Ipsec-foo). If the IWC defines one profile and the ILC defines a different one, then my IPsec-enabled wristwatch may not be able to talk to my IPsec-enabled lawnmower, but as long as they can both talk to my home PC I'll be happy. If, in the future, someone wants to develop a standardized protocol for wristwatches to talk directly to lawnmowers then I imagine that coordinating the KMP will be the least of their problems. Speaking of widgets, can you explain to me how a widget where "the profit margin is pennies" is going to do group 5 with 2048 bit RSA keys? The point is that any deployment involving widgets is going to require a specialized IPsec policy, anyway. If the widget wants to talk to a server, you can't expect the server to automatically think "oh, well since I'm talking to a widget then I guess group 1 with 512 bit RSA is okay". Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Jun 18 13:45:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IKjQn16467; Tue, 18 Jun 2002 13:45:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25028 Tue, 18 Jun 2002 15:44:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <000801c216f7$7f3b6f90$5570e640@ca.alcatel.com> References: <000801c216f7$7f3b6f90$5570e640@ca.alcatel.com> Date: Tue, 18 Jun 2002 12:57:14 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Son of IKE: A proposal for moving forward Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:39 PM -0400 6/18/02, Andrew Krywaniuk wrote: >But you're doing something unfair. You are comparing your own prototype KMP, >which has been specifically optimized for size, with a "typical" IPsec/IKE >stack (which doesn't make sense... are you comparing IKE+IPsec to >SPUNK+IPsec or just SPUNK?). I think we all have the ability to build scaled >down versions of our products if we want (strip out 90% of the crypto, etc). >About the only fundamental difference is the 1 vs 2 phase issue, and that >can hardly account for a factor of 10 increase in size. Another thing that might be considered unfair is the fact that we haven't seen an Internet Draft describing the protocol so we can see what it does and does not do. If such a draft existed, and the WG thought it was worth even scant attention, I could have included it in the features list document that we are using as the basis for this thread. [[ I certainly hope Ted and Barbara are not waiting for a new Internet Draft from Michael before they start asking the questions one at a time as they said they would start doing this week. ]] If Michael comes out with a draft, we can see how it matches or doesn't match the responses we get to the features that are going to be enumerated in the WG Real Soon Now. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 18 14:21:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ILLjn18485; Tue, 18 Jun 2002 14:21:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25094 Tue, 18 Jun 2002 16:32:06 -0400 (EDT) Message-ID: <019d01c21709$0691acf0$10a36b80@amer.cisco.com> From: "Scott Fanning" To: , "Paul Hoffman / VPNC" References: <000801c216f7$7f3b6f90$5570e640@ca.alcatel.com> Subject: Re: Son of IKE: A proposal for moving forward Date: Tue, 18 Jun 2002 13:45:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So I am assuming that the requirements outlined by Cheryls and your document have been agreed to (in general) by the community at large and can be used as the criteria to evaluate the proposed protocols? I am starting to wonder if the VPN problem and the Key Exchange problem may present different criteria, and thus without knowing (or agreeing on) the problem scope, evaluating what protocol is SOI may be difficult. Scott ----- Original Message ----- From: "Paul Hoffman / VPNC" To: Sent: Tuesday, June 18, 2002 12:57 PM Subject: RE: Son of IKE: A proposal for moving forward > At 2:39 PM -0400 6/18/02, Andrew Krywaniuk wrote: > >But you're doing something unfair. You are comparing your own prototype KMP, > >which has been specifically optimized for size, with a "typical" IPsec/IKE > >stack (which doesn't make sense... are you comparing IKE+IPsec to > >SPUNK+IPsec or just SPUNK?). I think we all have the ability to build scaled > >down versions of our products if we want (strip out 90% of the crypto, etc). > >About the only fundamental difference is the 1 vs 2 phase issue, and that > >can hardly account for a factor of 10 increase in size. > > Another thing that might be considered unfair is the fact that we > haven't seen an Internet Draft describing the protocol so we can see > what it does and does not do. If such a draft existed, and the WG > thought it was worth even scant attention, I could have included it > in the features list document that we are using as the basis for this > thread. > > [[ I certainly hope Ted and Barbara are not waiting for a new > Internet Draft from Michael before they start asking the questions > one at a time as they said they would start doing this week. ]] > > If Michael comes out with a draft, we can see how it matches or > doesn't match the responses we get to the features that are going to > be enumerated in the WG Real Soon Now. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 18 15:04:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IM4dn22961; Tue, 18 Jun 2002 15:04:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25171 Tue, 18 Jun 2002 17:19:21 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: Introduction to the IPSEC SOI feature questions Phone: (781) 391-3464 Message-Id: Date: Tue, 18 Jun 2002 17:31:49 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As Barbara and I wrote last week, what we're going to try do is to start sending out approximately 3 questions each day, in an attempt to start discussion, and hopefully give the necessary input to the design team consisting of people from the JFK and IKE teams. If we were following the strict waterfall design methodology, we would wait until the ipsec-son-of-ike-protocol-reqts requirements document were done. However, comments on the requirements document have been minimal. Part of that may be that people were not necessarily clear on what the tradeoffs/costs of the various scenarios were. So, we're going to try an iterative approach. We will start by asking design various questions drawn from the soi-features-00 document. Ideally, folks should answer these questions based on the scenarios listed in the son-of-ike-protocol-reqts-00 document. If you believe that some scenario is missing from that document, please go into detail about what the requirements of that scenario, and why it's important. On the other hand, if you believe that some scenario should not be considered important (and hence why the answer to some design question is "no"), please explain why you believe that. Hence, it may be that by trying to answer these design questions, we'll be able to get a better handle on the true requirements that we have for son-of-ike. - Ted From owner-ipsec@lists.tislabs.com Tue Jun 18 15:38:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IMc1n24776; Tue, 18 Jun 2002 15:38:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25234 Tue, 18 Jun 2002 17:55:00 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.1 Identity protection questions? Phone: (781) 391-3464 Message-Id: Date: Tue, 18 Jun 2002 18:07:53 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Notes from the wg chair: Protecting *both* the identity the initiator and the responder against active attacks is very difficult --- and probably impossible. In most cases, the client identity is much more important to protect than the responder, since often the responder is identified by its DNS name and fixed IP address. Some people believe that that there will be applications where the responder's identity may need to be protected (i.e., the home Windows NT server on a cable modem). One way of handling this is to introduce an extra half-round-trip by having the responder request that the initiator and responder "switch roles", so that where previously the responder would reveal its identity, the initiator would be forced to reveal its identity first instead. If the initiator isn't happy with this state of affairs, it can always decide to abort the authentication exchange at that point. Of course, adding a feature like this does add complexity to the entire protocol, so one of the first tradeoffs we'll need to tackle is whether supporting this kind of flexibility is warranted. OK, that should kick off the discussion. IPSEC wg, please answer the questions: 2.1.A.) Does SOI need to provide protection against passive attacks for the initiator? 2.1.B.) Does SOI need to provide protection against active attacks for the initiator? 2.1.C.) Does SOI need to provide protection against passive attacks for the responder? 2.1.D.) Does SOI need to provide protection against active attacks for the responder? Implications from the Scenarios: VPN: <<>> [[[2.1]]] End-to-End: <<>> [[[2.1]]] From owner-ipsec@lists.tislabs.com Tue Jun 18 15:44:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IMiTn24937; Tue, 18 Jun 2002 15:44:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25261 Tue, 18 Jun 2002 18:05:06 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) Phone: (781) 391-3464 Message-Id: Date: Tue, 18 Jun 2002 18:17:14 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Notes from the chair: This question is one where when I looked at the soi-features-00 document, I saw a great amount of discussion about the details of how IKEv2 and JFK accomplished their (partial) PFS capabilities. However, in terms of the actual functionality offered, I really couldn't see much differece between the two approaches. (If an JFK or IKE designer would beg to differ, please do so.) In the past, the working group has pretty much decided that perfect forwrd secrecy as a possiblity is a requirement, so that isn't a uestion here. The concept of being able to trade off performance with the level of PFS provided is a relative new possibility. - Ted 2.2 Perfect forward secrecy (PFS) 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward secrecy" by trading off performance versus the level of PFS provided. The funcitonality provided is roughly identical. Does anyone care about the details of how IKEv2 versus JFK provides this functionality? Should we just flip a coin? Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Tue Jun 18 15:53:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IMr7n25190; Tue, 18 Jun 2002 15:53:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25281 Tue, 18 Jun 2002 18:18:09 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) Phone: (781) 391-3464 Message-Id: Date: Tue, 18 Jun 2002 18:30:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Notes from the chair: As we had noted earlier, the "implications from the scenarios" only loosely seem to correlate with the questions implicit the soi-features document. Fundamentally, this is about a philosophical question of whether policy-related functionality (especially those which are related to the Secure Remote Access scenario) should be part of "Son of Ike", or whether it should be separated into another protocol. The fact that there is an IPSRA working group is a fairly strong argument that remote-access specific functionality should be handled by another protocol. This would also have the advantage of keeping the core key management protocol small, such that applications which were not specifically about remote access (i.e., iSCSI, secure telephony, pure VPN applications, end-to-end authentication using IPSEC, etc.) would not have to their implementations bloated by functionality that they don't need. On the other hand, there seems to be a very strong remote access contingent in this working group who seems to be very concerned about the protocol overhead inherent in separating remote access functionality from the core key management protocol. Again, IPSEC working group --- please discuss: 2.3.A.) Does SOI need to natively support "legacy authentication systems"? 2.3.B.) Does SOI need to natively support some kind of "shared secret" scheme? (Note. If SOI is provides cert-only, then one would need to use another protocol to bootstrap certificates from a legacy authentication or shared secret scheme.) Implications from the Scenarios: VPN: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] From owner-ipsec@lists.tislabs.com Tue Jun 18 16:01:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IN1an25448; Tue, 18 Jun 2002 16:01:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25302 Tue, 18 Jun 2002 18:23:13 -0400 (EDT) Date: 18 Jun 2002 18:23:40 -0400 Message-ID: <000a01c21716$ccf76580$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Paul Hoffman / VPNC'" , " " Subject: RE: Son of IKE: A proposal for moving forward 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I could be wrong, but I don't think Michael is proposing that SPUNK should be considered as a SOI candidate. I think he was just saying that SPUNK was sufficiently similar to JFK that all the same arguments apply. At least that's the assumption I was going on in my reply. 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 Paul Hoffman / VPNC > Sent: Tuesday, June 18, 2002 3:57 PM > To: ipsec@lists.tislabs.com > Subject: RE: Son of IKE: A proposal for moving forward > > > At 2:39 PM -0400 6/18/02, Andrew Krywaniuk wrote: > >But you're doing something unfair. You are comparing your > own prototype KMP, > >which has been specifically optimized for size, with a > "typical" IPsec/IKE > >stack (which doesn't make sense... are you comparing IKE+IPsec to > >SPUNK+IPsec or just SPUNK?). I think we all have the ability > to build scaled > >down versions of our products if we want (strip out 90% of > the crypto, etc). > >About the only fundamental difference is the 1 vs 2 phase > issue, and that > >can hardly account for a factor of 10 increase in size. > > Another thing that might be considered unfair is the fact that we > haven't seen an Internet Draft describing the protocol so we can see > what it does and does not do. If such a draft existed, and the WG > thought it was worth even scant attention, I could have included it > in the features list document that we are using as the basis for this > thread. > > [[ I certainly hope Ted and Barbara are not waiting for a new > Internet Draft from Michael before they start asking the questions > one at a time as they said they would start doing this week. ]] > > If Michael comes out with a draft, we can see how it matches or > doesn't match the responses we get to the features that are going to > be enumerated in the WG Real Soon Now. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Tue Jun 18 17:11:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J0Bfn26978; Tue, 18 Jun 2002 17:11:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25481 Tue, 18 Jun 2002 19:25:48 -0400 (EDT) From: rcharlet@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: history and why does IKE need a successor Date: Tue, 18 Jun 2002 16:39:14 -0700 Message-ID: <7B8824D690092B4B90B0EF4674750A650419CF8D@USEXCH3.us.sonicwall.com> Thread-Topic: history and why does IKE need a successor Thread-Index: AcIXIVsX0u4MZApGS2mPTyAs08mxCQ== To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA25478 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, This thread may be a bad idea, but I'm just curious... How did this working group come to the place where decided to replace IKE with something? As best as I can reconstruct history, it goes something like this... IKE was originally developed as a committee driven consensus product. This led to what some feel was an over inclusion of options. Field experience has since shown that some of the most confusion-causing options are rarely used. Peer review from security experts has taken IKE to task for its option explosion. Implementers have all struggled through the three cross-referential, non-terminology consistent, key management docs which force you through layer upon layer of options and thought to them selves "this could be better". All of the above forms only a general level of discontent which all participants were probably prepared to accept. No one was seriously thinking to them selves "I'll rewrite our key management protocol and show the world how it should be done" (except for a few nutty types who like to tinker with security protocols as their personal hobby. More on them later) But, while the level of discontent was at a safe equilibrium, there was another sub-plot brewing in the working group. Once upon a time there was a mulit-IETF meeting debate going on about how this working group should 'do' legacy authentication for remote access. VPN vendors wanted this feature because we were getting customer driven requests. The XAUTH proposal was earliest and became widely implemented. But 'non-consensus' in the working group centered around (probably invalid) arguments about its security properties, its efficiency properties, and its non-encouragement-of-PKI properties. Another VPN vendor entered a competing draft about how to do legacy auth. Dan Harkens entered a draft about how to do legacy auth in IKE directly. Some folks showed a way to use L2TP auth and IPsec for privacy only. Non-VPN IPsec'ers were asking why do this at all? PKI proponents were asking why do this at all? Debate was 'lively'. Interops showed XAUTH to work. A sub-working group was spun off to handle the question of the 'remote access scenario'. It came to a head at the Washington DC IETF (46th) when ! the working group was attempting to re-write its charter. At that meeting, the security ADs announced a policy of "no changes to IKE will be standards track". This effectively killed all current proposals and the working group found new chairs and recharted with this mandate in mind. It came up with two new, compliment proposals, PIC and GET-CERT, eventually picking PIC. But the "must not change IKE" policy also turned up that underlying discontent level a few notches and many folks 'questioned' the AD's wisdom on the matter. (now this next part I am most unsure about, I've probably got the principles all wrong. Please correct me gently) In the background, Kaufman and Perlman had been working on an SA and key management protocol which aimed to greatly reduce the numbers of options. They recruited Harkins to their efforts and presented a draft, IKEv2. In the background, Bellovin and Krawczyk, had been working on a key management protocol which aimed to greatly simplify key management in particular and did not really consider the question of SA management. They recruited several notables to their efforts and presented a draft, JFK. (Oh, and about that "nutty types" reference... I mean that only in jest and hold all these contributors in great respect. I'm quiet jeleous of their abilities). Neither of these drafts directly addressed the remote access debate. But since the possibility to 'change IKE' seems to be back on the table not many implementers are actually implementing PIC. Madson introduced a requirements draft which included a scenario about legacy auth based remote access. It appears that a successor to IKE may be allowed to address the largest remaining area of non-interoperability. But neither draft takes up this task yet and this was not the aim of any of the draft authors/contributers. So, where we stand now is that the market has solved the remote access problem by intrumenting with the only pragmatically available mechanisms XAUTH or L2TP over IPsec. We have a complicated protocol which is at great strains to do remote access user authentication from a radius or NT domain database. Yet this complicated and strained protocol is widely implemented in the market place. Both new IKE successor protocols are demonstrably more simple/efficient at authentication but neither directly solves a problem which IKE does not solve. Both protocols may be more trustable from a security perspective. But trust is a fickle thing. They would have to be "more-trustable-enough" to overcome the distrust the market will have for anything new. That is a high standard to raise to. So why bother? What "Good Thing" will we write down on our brochures for customers about the IKE successor? Who would be interested in buying the IKE successor who would not be satisfied with IKE? -- Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 From owner-ipsec@lists.tislabs.com Tue Jun 18 17:36:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J0amn27678; Tue, 18 Jun 2002 17:36:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25557 Tue, 18 Jun 2002 20:01:55 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.3 Authentication styles Phone: (781) 391-3464 Message-Id: Date: Tue, 18 Jun 2002 20:14:49 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Sorry, I screwed up the subject line on my last e-mail message; So I've re-issued the question in the hopes of reducing confusion....] Notes from the chair: As we had noted earlier, the "implications from the scenarios" only loosely seem to correlate with the questions implicit the soi-features document. Fundamentally, the implications are really about a philosophical question of whether policy-related functionality (especially those which are related to the Secure Remote Access scenario) should be part of "Son of Ike", or whether it should be separated into another protocol. The fact that there is an IPSRA working group is a fairly strong argument that remote-access specific functionality should be handled by another protocol. This would also have the advantage of keeping the core key management protocol small, such that applications which were not specifically about remote access (i.e., iSCSI, secure telephony, pure VPN applications, end-to-end authentication using IPSEC, etc.) would not have to their implementations bloated by functionality that they don't need. On the other hand, there seems to be a very strong remote access contingent in this working group who seems to be very concerned about the protocol overhead inherent in separating remote access functionality from the core key management protocol. Again, IPSEC working group --- please discuss: 2.3.A.) Does SOI need to natively support "legacy authentication systems"? 2.3.B.) Does SOI need to natively support some kind of "shared secret" scheme? (Or just certificates-only?) (Note. If SOI is provides cert-only, then one would need to use another protocol to bootstrap certificates from a legacy authentication or shared secret scheme.) Implications from the Scenarios: VPN: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] SRA: <<>> [[[2.3]]] From owner-ipsec@lists.tislabs.com Tue Jun 18 18:05:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J15hn29192; Tue, 18 Jun 2002 18:05:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25724 Tue, 18 Jun 2002 20:27:06 -0400 (EDT) From: rcharlet@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SOI QUESTIONS: 2.3 Authentication styles Date: Tue, 18 Jun 2002 17:40:03 -0700 Message-ID: <7B8824D690092B4B90B0EF4674750A65022DF635@USEXCH3.us.sonicwall.com> Thread-Topic: SOI QUESTIONS: 2.3 Authentication styles Thread-Index: AcIXKLZM7g8TVnCbR9WzXRT2U9pUsgAAC8dQ To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA25706 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I do not see the (real) "simplification" effect of our proposed successors to be a strong enough justification to replace the widely deployed IKE. If the successors would work toward inclusion of legacy auth capabilities for roaming remote access then perhaps we might be able to convince customers to adopt a new KM. But even then it may not fly. Perhaps there are other problems yet out there to solve which would justify an IKE replacement. Legacy Auth has been solved in the market place by XAUTH and by L2TP+IPsec. My crystal ball does not show PIC showing up out there anytime soon. (But then again, my crystal ball is notoriously bad). -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Tuesday, June 18, 2002 5:15 PM > To: ipsec@lists.tislabs.com > Subject: SOI QUESTIONS: 2.3 Authentication styles > > > > [Sorry, I screwed up the subject line on my last e-mail > message; So I've > re-issued the question in the hopes of reducing confusion....] > > Notes from the chair: > > As we had noted earlier, the "implications from the scenarios" only > loosely seem to correlate with the questions implicit the soi-features > document. > > Fundamentally, the implications are really about a philosophical > question of whether policy-related functionality (especially > those which > are related to the Secure Remote Access scenario) should be > part of "Son > of Ike", or whether it should be separated into another protocol. > > The fact that there is an IPSRA working group is a fairly strong > argument that remote-access specific functionality should be > handled by > another protocol. This would also have the advantage of keeping the > core key management protocol small, such that applications which were > not specifically about remote access (i.e., iSCSI, secure telephony, > pure VPN applications, end-to-end authentication using IPSEC, etc.) > would not have to their implementations bloated by functionality that > they don't need. > > On the other hand, there seems to be a very strong remote access > contingent in this working group who seems to be very concerned about > the protocol overhead inherent in separating remote access > functionality > from the core key management protocol. > > Again, IPSEC working group --- please discuss: > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? > > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) > > (Note. If SOI is provides cert-only, then one would need to use > another protocol to bootstrap certificates from a legacy > authentication or shared secret scheme.) > > Implications from the Scenarios: > > VPN: << addresses cannot be used as phase 1 identifiers. This also > means that > the authentication material cannot be chosen based upon the IP address > in the packet.>>> [[[2.3]]] > > SRA: << this policy information before the IPsec tunnel is constructed.>>> > [[[2.3]]] > > SRA: << accommodate re-authentication based on the RAS or authentication > server site security policy>>> [[[2.3]]] > > SRA: << location of the authentication server relative to the client and the > RAS. In many scenarios, server tends to be "behind" the RAS device, in > the domain that is being secured by the RAS, which may be > problematic > for bootstrapping the user authentication for the client-to-RAS > connection.>>> [[[2.3]]] > From owner-ipsec@lists.tislabs.com Tue Jun 18 18:52:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J1qrn01254; Tue, 18 Jun 2002 18:52:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25857 Tue, 18 Jun 2002 21:16:22 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15631.56924.944793.136263@thomasm-u1.cisco.com> Date: Tue, 18 Jun 2002 18:29:00 -0700 (PDT) To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: RE: Son of IKE: A proposal for moving forward In-Reply-To: References: <000801c216f7$7f3b6f90$5570e640@ca.alcatel.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 ARRRRRGGGGHHHH. I am not proposing this for anything. I was just giving background as to how I arrived at making something that was really small and looked a lot like JFK. It was an _experiment_. Mike Paul Hoffman / VPNC writes: > At 2:39 PM -0400 6/18/02, Andrew Krywaniuk wrote: > >But you're doing something unfair. You are comparing your own prototype KMP, > >which has been specifically optimized for size, with a "typical" IPsec/IKE > >stack (which doesn't make sense... are you comparing IKE+IPsec to > >SPUNK+IPsec or just SPUNK?). I think we all have the ability to build scaled > >down versions of our products if we want (strip out 90% of the crypto, etc). > >About the only fundamental difference is the 1 vs 2 phase issue, and that > >can hardly account for a factor of 10 increase in size. > > Another thing that might be considered unfair is the fact that we > haven't seen an Internet Draft describing the protocol so we can see > what it does and does not do. If such a draft existed, and the WG > thought it was worth even scant attention, I could have included it > in the features list document that we are using as the basis for this > thread. > > [[ I certainly hope Ted and Barbara are not waiting for a new > Internet Draft from Michael before they start asking the questions > one at a time as they said they would start doing this week. ]] > > If Michael comes out with a draft, we can see how it matches or > doesn't match the responses we get to the features that are going to > be enumerated in the WG Real Soon Now. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 18 19:18:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J2Iwn01793; Tue, 18 Jun 2002 19:18:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25941 Tue, 18 Jun 2002 21:38:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15631.56924.944793.136263@thomasm-u1.cisco.com> References: <000801c216f7$7f3b6f90$5570e640@ca.alcatel.com> <15631.56924.944793.136263@thomasm-u1.cisco.com> Date: Tue, 18 Jun 2002 18:40:45 -0700 To: Michael Thomas From: Paul Hoffman / VPNC Subject: RE: Son of IKE: A proposal for moving forward Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:29 PM -0700 6/18/02, Michael Thomas wrote: >ARRRRRGGGGHHHH. Tell us how you really feel. :-) >I am not proposing this for anything. I was just >giving background as to how I arrived at making >something that was really small and looked a lot >like JFK. It was an _experiment_. No problem, and sorry about my misunderstanding. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 18 20:40:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J3eIn03631; Tue, 18 Jun 2002 20:40:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26048 Tue, 18 Jun 2002 22:56:40 -0400 (EDT) Date: Tue, 18 Jun 2002 23:09:53 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 18 Jun 2002, Theodore Ts'o wrote: > Protecting *both* the identity the initiator and the responder against > active attacks is very difficult... I agree with the argument that protection of the initiator is usually more important. If nothing else, the fundamental asymmetry of the relationship points that way: the initiator can be anywhere, but it had to know how to reach the responder, which often implies some degree of public knowledge of the responder. I'd prefer to see the initiator protected against active attacks, not just passive. And I'd go along with the idea of allowing the responder to ask for an exchange of roles, preferably in the simplest way possible. (NB: I've left the FreeS/WAN project, and hence speak only for myself.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jun 18 20:40:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J3ean03650; Tue, 18 Jun 2002 20:40:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26071 Tue, 18 Jun 2002 23:02:40 -0400 (EDT) Date: Tue, 18 Jun 2002 23:15:34 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: JFK draft editing error? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unless I have missed something, both jfk-02 and jfk-03 omit the actual description of the JFKi protocol -- they go straight from notation to JFKr, describing JFKr as "the second variant" without ever having described the first variant! (Apologies if this has already been noted.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jun 18 20:55:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J3ten03856; Tue, 18 Jun 2002 20:55:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26093 Tue, 18 Jun 2002 23:18:42 -0400 (EDT) Date: Tue, 18 Jun 2002 23:31:23 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 18 Jun 2002, Theodore Ts'o wrote: > In the past, the working group has pretty much decided that > perfect forwrd secrecy as a possiblity is a requirement, so that isn't a > uestion here. The concept of being able to trade off performance > with the level of PFS provided is a relative new possibility... I have no strong feelings about the details of that, but I do want to put in a plug on a slightly related point: however the details work, two conforming implementations should interoperate (policy permitting) without prearranged agreement on PFS mode. This is one place where IKE falls down badly. The choice of PFS or no PFS is neither negotiated nor announced in the protocol, yet the two ends must agree exactly or communication mysteriously fails. (This is an empirical fact; I haven't examined the details to sort out just how it happens.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jun 18 23:10:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J6AMn06890; Tue, 18 Jun 2002 23:10:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26423 Wed, 19 Jun 2002 01:34:19 -0400 (EDT) Message-Id: <200206190546.g5J5kLr23037@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-reply-to: Your message of "Tue, 18 Jun 2002 18:17:14 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Jun 2002 01:46:21 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would prefer to see PFS as not optional. From owner-ipsec@lists.tislabs.com Tue Jun 18 23:14:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J6Eln07236; Tue, 18 Jun 2002 23:14:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26411 Wed, 19 Jun 2002 01:30:19 -0400 (EDT) Message-Id: <200206190542.g5J5gUJ22983@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? In-reply-to: Your message of "Tue, 18 Jun 2002 18:07:53 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Jun 2002 01:42:29 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> Protecting *both* the identity the initiator and the responder against Theodore> active attacks is very difficult --- and probably impossible. In most Theodore> cases, the client identity is much more important to protect than the Theodore> responder, since often the responder is identified by its DNS name and Theodore> fixed IP address. Please use different terminology here. If you wish, you may use "client" and "server" here. Initiator and Responder refers to who sends the first keying message. Client and Server refers to who is active and who is passive in their intent to communicate. The initiator is not always the client. We are VERY frequently dealing with cases where the client, having no preconceived policy, may well start communication with the server in the clear, and the server, having a policy will, initiate to the client in order to send its reply. Some servers have well known DNS names and fixed IP addresses. But that does not apply to responders. - --- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> 2.1.A.) Does SOI need to provide protection against passive Theodore> attacks for the initiator? YES. Theodore> 2.1.B.) Does SOI need to provide protection against active Theodore> attacks for the initiator? YES. Theodore> 2.1.C.) Does SOI need to provide protection against passive Theodore> attacks for the responder? YES. Theodore> 2.1.D.) Does SOI need to provide protection against active Theodore> attacks for the responder? It is highly desireable, but it is understood that this may be difficult. If it can not be done, then, at the expense of additional exchanges, there should be a way for the responder to indicate that it wishes to either change its identity, or to create a sub-exchange in which the identity is different. The latter would permit two multi-user systems to authenticate first the hosts, and later, authenticate on behalf of a particular user. ] 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 iQCVAwUBPRAZwYqHRg3pndX9AQEHZAP/SifjpH+A5qDRxAOP8n1jsYld2EM7lf4i dMz9NbzSk6/yS7Wjdaz9nj+NHJwR8HYHp78MbDmIPlCiejWPKUnNSkHJL3v8SNRv PxVncj4sbOpPpAv06iaqsN79bHkiMtX81bDqz2AfZtqVOkpYWJiZ84Oo1SOkFZKc SgNA+cyaGuo= =cZZH -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jun 18 23:22:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5J6MYn07894; Tue, 18 Jun 2002 23:22:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26436 Wed, 19 Jun 2002 01:42:22 -0400 (EDT) Message-Id: <200206190555.g5J5sws23180@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-reply-to: Your message of "Tue, 18 Jun 2002 18:30:19 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Jun 2002 01:54:58 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> 2.3.A.) Does SOI need to natively support "legacy authentication Theodore> systems"? No. cf. Bellovin Enrollment suggestions. Theodore> 2.3.B.) Does SOI need to natively support some kind of "shared Theodore> secret" scheme? Not anymore. I believe that it was necessary in IKEv1 because there was no other useful patent free authentication system. We should do RSA as common protocol. We MUST define the ASCII format of the raw RSA keys, and mandate that they be loadable to the trusted store. Theodore> Implications from the Scenarios: Theodore> VPN: << addresses cannot be used as phase 1 identifiers. This also means that Theodore> the authentication material cannot be chosen based upon the IP address Theodore> in the packet.>>> [[[2.3]]] Theodore> SRA: << this policy information before the IPsec tunnel is constructed.>>> Theodore> [[[2.3]]] Theodore> SRA: << accommodate re-authentication based on the RAS or authentication Theodore> server site security policy>>> [[[2.3]]] Theodore> SRA: << location of the authentication server relative to the client and the Theodore> RAS. In many scenarios, server tends to be "behind" the RAS device, in Theodore> the domain that is being secured by the RAS, which may be problematic Theodore> for bootstrapping the user authentication for the client-to-RAS connection.> [[[2.3]]] Note that these are different questions than strict what is said above. Supporting things like pushing the policy down SHOULD be done. ] 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 iQCVAwUBPRAcsIqHRg3pndX9AQG8wwP8CwLNxN0Hp2C2EZpy6hDSixVk9zkZeIkU BDCmB7rsHsZTCsUeQuuyIRTmMzun98X5ww9HPznjlCn8YvU8wGxkWXL15fU7xpLL eGi3EKiMLge6hW+y1NRYa03L3npmLrjgwfRHEUft0DsAvIallLxuKL9I6qOJmUxV mAgsFHVpnSA= =Geud -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jun 19 08:00:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JF0Qn16748; Wed, 19 Jun 2002 08:00:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27314 Wed, 19 Jun 2002 10:06:36 -0400 (EDT) Message-Id: <3.0.3.32.20020619072145.01384220@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 19 Jun 2002 07:21:45 -0700 To: rcharlet@SonicWALL.com, From: Alex Alten Subject: Re: history and why does IKE need a successor In-Reply-To: <7B8824D690092B4B90B0EF4674750A650419CF8D@USEXCH3.us.sonicw all.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky, I'd add the Catherine Meadow's analysis of IKE to your history. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Wed Jun 19 08:31:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JFVnn19183; Wed, 19 Jun 2002 08:31:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27371 Wed, 19 Jun 2002 10:46:46 -0400 (EDT) Date: 19 Jun 2002 10:46:57 -0400 Message-ID: <002301c217a0$2a1d3a80$1b6ce640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Ricky Charlet'" , " 'list'" Subject: RE: history and why does IKE need a successor 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <7B8824D690092B4B90B0EF4674750A650419CF8D@USEXCH3.us.sonicwall.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky, I can't say I agree with all aspects of your story, but it's as good a yarn as any. I remain convinced that we would have avoided all these problems and finished a lot sooner had we simply proceeded with the original IKEv2 draft (circa 1999). As I remember it, people had already started implementing it at some of the later bakeoffs. We might not have had the compact, 3-in-1 superdraft, but we could still have solved all the same problems with the protocol without the 3 year delay. 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 Jun 19 10:26:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JHQun24545; Wed, 19 Jun 2002 10:26:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27515 Wed, 19 Jun 2002 12:33:39 -0400 (EDT) Message-Id: <200206191646.g5JGk3401633@marajade.sandelman.ottawa.on.ca> To: uri@bell-labs.com cc: ipsec@lists.tislabs.com Subject: legacy authentication support In-reply-to: Your message of "Wed, 19 Jun 2002 10:51:28 EDT." <200206191452.KAA11013@nwmail.wh.lucent.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Jun 2002 12:46:01 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Uri" == Uri Blumenthal writes: Uri> On Wednesday 19 June 2002 01:54, Michael Richardson wrote: >>> Theodore> 2.3.A.) Does SOI need to natively support "legacy >>> authentication systems"? >> >> No. cf. Bellovin Enrollment suggestions. Uri> I don't find that suggestion practical enough to justify following it Uri> now. The TODAY's reality is - non-PK auth systems are wide-spread and Uri> are NOT going away. Not to support it natively simply complicates both Uri> the protocol and the implementations. If you had said this in 1996, I'd have bought this line of thought. EVERY SINGLE legacy auth vendor has some set of web CGIs that let you authenticate web pages. An authenticated POST operation is just a couple of lines in some scripting language. Even VirusBuilder could do it. >> Not anymore. Uri> Absolutely yes - "shared secret" is a-must. I'm saying that RSA should be MUST, and should be the interop algorithm. If there is shared secret, make it MAY. Uri> This was not just a patent issue!! Practically all the remote access Uri> is based on some kind of non-PK approach. Well, the only legacy systems that can directly use shared-secret instead of are time based systems like SecurID. All of the X9.9 stuff (which I've done lots of work with in various guises) is challenge/response based. {It also uses 1DES} Uri> Technically it is simpler to support non-PK natively, than to have TWO Uri> interoperable protocols - one to retrieve the "credentials" and the Uri> other one to actually use them (and then to worry to scramble those Uri> retrieved credentials - lest somebody else "borrows" 'em later on)... Debugging two simple protocols is a lot easier than debugging one complicated protocol. >> We MUST define the ASCII format of the raw RSA keys, and mandate >> that they be loadable to the trusted store. Uri> What if there is no trusted store? Look outside your concept box. Then I guess you'll get a blank screen when you turn stuff on :-) I understand that you mean that all authentication is provided by the user on a detached device. No GSM cell phone has this problem, no iPAQ or PDA. I doubt that even water meters will have this problem. ] 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 iQCVAwUBPRC1RoqHRg3pndX9AQEJtgP+O7btcmROqZ+0tiD2kXTc/stBRuAjv0vj fuSu4c3L1ZPrbsV6oVU7Iyqcu1Qc04mj/CcNU8Apnu03Goq2xNANvyHZ3TzZPMVL O+24nwsW8XVdKM0r6+kL1fiBFkRxzQS90doCrJvXBq0jLOgo4/PISGz/c3+DGt4P Lnz7xhSWZ9Y= =Y19j -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jun 19 10:51:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JHpqn26164; Wed, 19 Jun 2002 10:51:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27613 Wed, 19 Jun 2002 13:10:00 -0400 (EDT) From: rcharlet@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: history and why does IKE need a successor Date: Wed, 19 Jun 2002 10:22:50 -0700 Message-ID: <7B8824D690092B4B90B0EF4674750A65022DF638@USEXCH3.us.sonicwall.com> Thread-Topic: history and why does IKE need a successor Thread-Index: AcIXofE/5yL0K6KvTe6okuJSJGzVDQAEmjuA To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA27610 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy > -----Original Message----- > From: Andrew Krywaniuk [mailto:andrew.krywaniuk@alcatel.com] > Sent: Wednesday, June 19, 2002 7:47 AM > To: Ricky Charlet; 'list' > Subject: RE: history and why does IKE need a successor > > > Ricky, I can't say I agree with all aspects of your story, > but it's as good > a yarn as any. > Thanks. And why don't I take this opportunity to say to the list that my recollection of history is as guaranteed to be flawed as any single humans and even more so since I am not really a principle in the events. But historical context drives my question: None of us like the option explosion presently in IKE. Some of us want more new features in any successor to IKE (remote access support). Yet IKE got itself widley deployed with some non-standards track options while we took a multi-year time-out. Why do we need to replace IKE at all? It will cost customers time and effort to deploy. What benefit will it offer? The historical accounting I did probably only serves as a major distraction from the qeustion at the bottom. But I could not withstand the curiosity of seeing what other peoples perspective was about how we got here. Please do not construe me as saying that I like the current state of affairs. But it is tolerable. And deployed. (am I harping on that or what?) From owner-ipsec@lists.tislabs.com Wed Jun 19 11:12:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JICPn26908; Wed, 19 Jun 2002 11:12:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27680 Wed, 19 Jun 2002 13:32:12 -0400 (EDT) From: rcharlet@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: history and why does IKE need a successor Date: Wed, 19 Jun 2002 10:45:14 -0700 Message-ID: <7B8824D690092B4B90B0EF4674750A65022DF63A@USEXCH3.us.sonicwall.com> Thread-Topic: history and why does IKE need a successor Thread-Index: AcIXofE/5yL0K6KvTe6okuJSJGzVDQAFoR4A To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA27677 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, > I remain convinced that we would have avoided all these problems and > finished a lot sooner had we simply proceeded with the > original IKEv2 draft > (circa 1999). As I remember it, people had already started > implementing it > at some of the later bakeoffs. We might not have had the > compact, 3-in-1 > superdraft, but we could still have solved all the same > problems with the > protocol without the 3 year delay. > > Andrew Wow, I missed the son-of-ike work in my history. That was pretty blind of me. Sorry Dan. And if that effort to simplify IKE had moved quickly, I agree that we would not have had such a cost-of-redeployment issue to contend with today. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 From owner-ipsec@lists.tislabs.com Wed Jun 19 11:15:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JIFHn26983; Wed, 19 Jun 2002 11:15:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27686 Wed, 19 Jun 2002 13:33:12 -0400 (EDT) Date: 19 Jun 2002 13:33:51 -0400 Message-ID: <000001c217b7$7c06f540$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" , " 'list'" Subject: RE: SOI QUESTIONS: 2.1 - 2.3 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 V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, What will be the procedure for deciding on this stuff? Will the moderated discussions be followed by a straw poll? What will happen if we can't acheive consensus on an issue? > 2.1.) Does SOI need to provide identity protection This is an issue where the idea that the requirements should dictate the protocol goes out the window. What we should do is determined by what we can do. I think it's a given that we want some form of PFS for the protocol so identity protection comes "for free." Protection against passive attacks should be the priority. We should protect one side against active attacks simply because we can (without screwing up the protocol). I feel there are equal arguments for protecting either side. Since the initiator can conceivably request which identity he wants to talk to (at the cost of repudiation, I guess), I would tend to protect the initiator (but I don't really care). If people want to do a fancy thing where you can negotiate which side gets more protection, that should be a MAY. > 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward > secrecy" by trading off performance versus the level of PFS provided. > The funcitonality provided is roughly identical. Does anyone care > about the details of how IKEv2 versus JFK provides this functionality? > Should we just flip a coin? I have posted many ideas on how to improve PFS in IKE, but no one really seems interested so I won't do it again. I like the PFS interval approach better than having a Boolean. It is silly to do PFS always (esp. in a 2-phase system), but possibly undesirable to bind it to phase 1 rekeying. I don't particularly like the way the PFS interval is integral to the design of JFK. In IKEv2, it is at least just a modular feature. On the other hand, the method in IKEv2 is still inefficient on the wire (and in memory usage) because you have to cache the peer's last key. I don't much like the trial-and-error option for PFS mismatch either. The IKEv2 technique allows a tuneable optimization for either time or memory, but I can't help thinking that an acknowledged notify message would give you both. > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? Of course let's not forget that legacy authentication is a pejorative term. For an obsolete technology, it's strange how I still use it almost every day. I, for one, don't believe that token cards are going away any time soon. Public key-based smartcards will see some use, but the downside is that you have to physically connect them to the computer. I'm not about to type in a 1024 bit signature by hand. It would be nice for the token authentication to be done directly within SOI, but that's not possible with Radius because the KMP doesn't have access to the password. However, this is not an insurmountable limitation (you don't absolutely have to use Radius). I'd like to leave this possibility open. > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) I think that once we abandon the fancy key derivation mess from IKEv1, the authentication method just becomes another plug-and-playable crypto algorithm. As has been noted many times before, the only thing that made shared secrets complicated in IKEv1 was the crufty "choose any two of {main mode, preshared key, mobile client}" problem. By definition, plug-and-play authentication doesn't complicate the base protocol. There is no downside, unless you happen to have a political agenda. It allows a password (or "legacy authentication") in one direction with RSA sigs in the other. With one extra payload (ID_KEY_ID), we could do SRP. It even allows no authentication (or "anonymous authentication" as Michael calls it). Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed Jun 19 11:49:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JInin29791; Wed, 19 Jun 2002 11:49:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27783 Wed, 19 Jun 2002 14:03:37 -0400 (EDT) Date: Wed, 19 Jun 2002 11:16:13 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was no technical reason given for rejecting L2TP+IPsec as a remote access security solution in this working group. I wonder if there is any technical reason for requesting adding remote access functionality to SOI now. thanks, chinna On Tue, 18 Jun 2002, Theodore Ts'o wrote: > > [Sorry, I screwed up the subject line on my last e-mail message; So I've > re-issued the question in the hopes of reducing confusion....] > > Notes from the chair: > > As we had noted earlier, the "implications from the scenarios" only > loosely seem to correlate with the questions implicit the soi-features > document. > > Fundamentally, the implications are really about a philosophical > question of whether policy-related functionality (especially those which > are related to the Secure Remote Access scenario) should be part of "Son > of Ike", or whether it should be separated into another protocol. > > The fact that there is an IPSRA working group is a fairly strong > argument that remote-access specific functionality should be handled by > another protocol. This would also have the advantage of keeping the > core key management protocol small, such that applications which were > not specifically about remote access (i.e., iSCSI, secure telephony, > pure VPN applications, end-to-end authentication using IPSEC, etc.) > would not have to their implementations bloated by functionality that > they don't need. > > On the other hand, there seems to be a very strong remote access > contingent in this working group who seems to be very concerned about > the protocol overhead inherent in separating remote access functionality > from the core key management protocol. > > Again, IPSEC working group --- please discuss: > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? > > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) > > (Note. If SOI is provides cert-only, then one would need to use > another protocol to bootstrap certificates from a legacy > authentication or shared secret scheme.) > > Implications from the Scenarios: > > VPN: << addresses cannot be used as phase 1 identifiers. This also means that > the authentication material cannot be chosen based upon the IP address > in the packet.>>> [[[2.3]]] > > SRA: << this policy information before the IPsec tunnel is constructed.>>> > [[[2.3]]] > > SRA: << accommodate re-authentication based on the RAS or authentication > server site security policy>>> [[[2.3]]] > > SRA: << location of the authentication server relative to the client and the > RAS. In many scenarios, server tends to be "behind" the RAS device, in > the domain that is being secured by the RAS, which may be problematic > for bootstrapping the user authentication for the client-to-RAS > connection.>>> [[[2.3]]] > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Wed Jun 19 11:58:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JIwtn00911; Wed, 19 Jun 2002 11:58:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27810 Wed, 19 Jun 2002 14:16:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 19 Jun 2002 10:53:35 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the typical VPN scenario (either gateway-to-gateway or remote-access WAN): - PFS is a real requirement for some but not all user scenarios --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 19 11:59:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JIxDn00960; Wed, 19 Jun 2002 11:59:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27809 Wed, 19 Jun 2002 14:16:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 19 Jun 2002 10:48:52 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the typical VPN scenario (either gateway-to-gateway or remote-access WAN): - protection against passive attacks on the identities of each party is very important because you don't know who is going to initiate - protection against active attacks against the identity of either party is useful, but not nearly as important as protection from passive attacks - if a protocol can offer protection against active attack for only one of the two parties, protecting the identity of the responder is more important to prevent wandering identity sniffers --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 19 11:59:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JIxUn01006; Wed, 19 Jun 2002 11:59:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27811 Wed, 19 Jun 2002 14:16:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 19 Jun 2002 11:25:31 -0700 To: "Theodore Ts'o" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:14 PM -0400 6/18/02, Theodore Ts'o wrote: >The fact that there is an IPSRA working group is a fairly strong >argument that remote-access specific functionality should be handled by >another protocol. As the co-chair of that WG, I strongly disagree with that statement. The IPSRA WG was created because of mandate from the Security Area Directors to deal with the remote access problem for IKEv1 without touching IKEv1. The current discussion about SOI would only be related to the IPSRA work if people felt that the protocol that came out of IPSRA (namely PIC) was efficient, robust, and useful in SOI. Few, if any, people have said that. > This would also have the advantage of keeping the >core key management protocol small, such that applications which were >not specifically about remote access (i.e., iSCSI, secure telephony, >pure VPN applications, end-to-end authentication using IPSEC, etc.) >would not have to their implementations bloated by functionality that >they don't need. That would be a real consideration if dealing with remote access added much complexity or bloat. For example, if people said "we must add an XAUTH-like Phase 1.5", then it would be a real concern. However, there are proposals that allow reasonably-flexible remote access (with or without legacy authentication, which people often feel is an important part of remote access) that do not add significant complexity. >On the other hand, there seems to be a very strong remote access >contingent in this working group who seems to be very concerned about >the protocol overhead inherent in separating remote access functionality >from the core key management protocol. For those of us who believe that remote access is inherently part of the VPN scenario for IPsec because our customers tell us it is, yes. >2.3.A.) Does SOI need to natively support "legacy authentication >systems"? As draft-ietf-ipsec-revised-identity points out, if SOI supports preshared secrets that are not tied to IP addresses (that is, where each party says what ID is associated with the preshared secret it is using), legacy authentication comes for free. The only requirement on the legacy authentication system is that it returns authentication proof that is large enough to be broken into an ID and a preshared secret, and that the preshared secret part is not susceptible to a dictionary attack. >2.3.B.) Does SOI need to natively support some kind of "shared >secret" scheme? (Or just certificates-only?) Cryptographically: no. Practically: yes. "Certificates-only" implies one of three scenarios: - an actual PKI with a trust anchor - self-signed certificates - a mixture of both We all know that expecting IPsec administrators to understand even the minimum required set of intricacies of PKIX is silly. Quite frankly, many of the messages on this mailing list from a few years ago when we were trying to come up with a PKIX profile for IPsec shows that many of the implementers here don't understand PKIX all that well. Passing around keys for self-signed certificates has all of the scaling problems of preshared secrets, but the keys are probably much longer and easier to type in wrong. Self-signed certificates have a definite advantage over preshared keys: it is much less likely that the owner of the private key would lose it or even know how to tell someone what it was. However, they have the disadvantage that they are significantly harder to use when a WAN administrator purposely wants to set up a small network with all nodes having the same key. Going to one method of identity is cleaner than having two, but both JFK and IKEv2 show that the complexity can be much less than it was in IKEv1. Even though JFK doesn't have a pre-shared secret mode, it would be trivial to add one in (use an HMAC instead of a signature on the identity-protected information in messages 3 and 4). In summary, it would not serve us well to turn our back on many of today's VPN users simply to make an argument of purity. Doing so would almost certainly assure that many users would not want to adopt SOI: why would they want to if it made their life harder? Further, we can use shared secrets to include legacy authentication for free with no additional protocol overhead. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 19 12:03:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JJ3In01436; Wed, 19 Jun 2002 12:03:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27860 Wed, 19 Jun 2002 14:22:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <7B8824D690092B4B90B0EF4674750A65022DF638@USEXCH3.us.sonicwall.com> References: <7B8824D690092B4B90B0EF4674750A65022DF638@USEXCH3.us.sonicwall.com> Date: Wed, 19 Jun 2002 11:35:41 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: history and why does IKE need a successor Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:22 AM -0700 6/19/02, rcharlet@SonicWALL.com wrote: >Why do we need to replace IKE at all? It will cost customers time >and effort to deploy. What benefit will it offer? Of course we don't "need" to. But we have the opportunity to make IPsec much easier to use for our customers. We can get rid of many of the current limitations and create a better basis for interoperability. For many people, those are sufficient reasons, regardless of the sordid history that got us here. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 19 12:08:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JJ8ln01819; Wed, 19 Jun 2002 12:08:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27872 Wed, 19 Jun 2002 14:28:50 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.3 Authentication styles Date: Wed, 19 Jun 2002 14:41:23 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? Yes. > > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) Undecided. Realistic IKEv2 deployments are years away (iron out requirements, x draft revisions, commitment from major vendors, bakeoffs, product hardening, etc...). To make matters worse, most major vendors have worked around most of IKEv1's shortcomings (remote access solutions, NAT transparency, DPD, etc...). Some of these solutions are (somewhat) interoperable, some are 100% proprietary. It may be a hard sell... and IKEv2's properties will have to be much better to sell them on it. The biggest thing that IKEv2 will buy us is interoperability and (hopefully)better security properties (DoS resistance comes to mind). Point is, by the time customers are willing to deploy IKEv2, the PKI landscape may have evolved (crossed fingers). Those customers who have not yet deployed IKEv2, may be satisfied with running IKEv1 to get the shared secret feature. At the same time, I think that an IKEv2 that supports the Hybrid (from Checkpoint) or CRACK (from Dan et al.) style legacy-auth in conjuction with a very simple PKI (self-signed certs perhaps) would gladly do away with pre-shared key. I think most customers that use pre-shared key today fall in 2 categories: either they have a small number of lan boxes (pre-shared keys are manageable, self signed certs would also be manageable), or they're doing remote access and are using pre-shared key with XAUTH or some other proprietary IPsec+legacy auth method (replace this with Hybrid/CRACK). So, I believe that if we had Hybrid or CRACK, we could probably get away with getting rid of pre-shared key. > > (Note. If SOI is provides cert-only, then one would need to use > another protocol to bootstrap certificates from a legacy > authentication or shared secret scheme.) > > Implications from the Scenarios: > > VPN: << addresses cannot be used as phase 1 identifiers. This also means that > the authentication material cannot be chosen based upon the IP address > in the packet.>>> [[[2.3]]] > > SRA: << this policy information before the IPsec tunnel is constructed.>>> > [[[2.3]]] > > SRA: << accommodate re-authentication based on the RAS or authentication > server site security policy>>> [[[2.3]]] > > SRA: << location of the authentication server relative to the client and the > RAS. In many scenarios, server tends to be "behind" the RAS device, in > the domain that is being secured by the RAS, which may be problematic > for bootstrapping the user authentication for the client-to-RAS > connection.>>> [[[2.3]]] From owner-ipsec@lists.tislabs.com Wed Jun 19 12:41:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JJfPn02773; Wed, 19 Jun 2002 12:41:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27921 Wed, 19 Jun 2002 14:54:03 -0400 (EDT) Date: Wed, 19 Jun 2002 12:06:44 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Paul Hoffman / VPNC cc: "Theodore Ts'o" , Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002, Paul Hoffman / VPNC wrote: > At 8:14 PM -0400 6/18/02, Theodore Ts'o wrote: > >On the other hand, there seems to be a very strong remote access > >contingent in this working group who seems to be very concerned about > >the protocol overhead inherent in separating remote access functionality > >from the core key management protocol. > > For those of us who believe that remote access is inherently part of > the VPN scenario for IPsec because our customers tell us it is, yes. > AFAIK, no customer has told the WG this yet. I wonder why our customers tell us a different thing. chinna From owner-ipsec@lists.tislabs.com Wed Jun 19 12:50:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JJoen02942; Wed, 19 Jun 2002 12:50:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27955 Wed, 19 Jun 2002 15:04:11 -0400 (EDT) From: "Stephane Beaulieu" To: , Subject: RE: history and why does IKE need a successor Date: Wed, 19 Jun 2002 15:17:16 -0400 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: <7B8824D690092B4B90B0EF4674750A650419CF8D@USEXCH3.us.sonicwall.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ricky, Leaving all the history stuff aside, I believe that SOI will (hopefully) offer more than IKEv1++ (IKEv1 + proprietary extensions that make it useable) does today. Let's assume that we could finally get agreement on the following for IKEv1: - remote access - DPD / Keepalives / Heartbeats - rekeying - Continuous Channel mode vs. dangling - NAT traversal - INITIAL-CONTACT / Birth Certificates - etc... I think we'd probably still need to at least have a new mode (Base Mode, Hybrid, CRACK, etc...) to solve other issues that can't be solved without major changes to IKEv1. Once you cram all the things listed above in IKEv1, it starts to look a heck of a lot like IKEv2 (except of course for the controversial remote access issues). However, things like DoS protection can't easily be put in IKEv1 without making new modes (and then more or less rewriting much of your code anyway). Identity protection is another issue that comes to mind that may not fit well into IKEv1. I fully understand where you're coming from... if, once we nail down the requirements, we decide that any new additions can be reasonably easily inserted into IKEv1, then I fully agree with you. However, I don't think the requirements will fall that way. At least not the kind of requirements I'm hoping to get... Stephane. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > rcharlet@SonicWALL.com > Sent: Tuesday, June 18, 2002 7:39 PM > To: ipsec@lists.tislabs.com > Subject: history and why does IKE need a successor > > > Howdy, > > This thread may be a bad idea, but I'm just curious... > > How did this working group come to the place where decided > to replace IKE with something? As best as I can reconstruct > history, it goes something like this... > > IKE was originally developed as a committee driven > consensus product. This led to what some feel was an over > inclusion of options. Field experience has since shown that some > of the most confusion-causing options are rarely used. Peer > review from security experts has taken IKE to task for its option > explosion. Implementers have all struggled through the three > cross-referential, non-terminology consistent, key management > docs which force you through layer upon layer of options and > thought to them selves "this could be better". > > All of the above forms only a general level of discontent > which all participants were probably prepared to accept. No one > was seriously thinking to them selves "I'll rewrite our key > management protocol and show the world how it should be done" > (except for a few nutty types who like to tinker with security > protocols as their personal hobby. More on them later) > > But, while the level of discontent was at a safe > equilibrium, there was another sub-plot brewing in the working group. > > Once upon a time there was a mulit-IETF meeting debate > going on about how this working group should 'do' legacy > authentication for remote access. VPN vendors wanted this feature > because we were getting customer driven requests. The XAUTH > proposal was earliest and became widely implemented. But > 'non-consensus' in the working group centered around (probably > invalid) arguments about its security properties, its efficiency > properties, and its non-encouragement-of-PKI properties. Another > VPN vendor entered a competing draft about how to do legacy auth. > Dan Harkens entered a draft about how to do legacy auth in IKE > directly. Some folks showed a way to use L2TP auth and IPsec for > privacy only. Non-VPN IPsec'ers were asking why do this at all? > PKI proponents were asking why do this at all? Debate was > 'lively'. Interops showed XAUTH to work. A sub-working group was > spun off to handle the question of the 'remote access scenario'. > It came to a head at the Washington DC IETF (46th) whe! > n ! > the working group was attempting to re-write its charter. > > At that meeting, the security ADs announced a policy of "no > changes to IKE will be standards track". This effectively killed > all current proposals and the working group found new chairs and > recharted with this mandate in mind. It came up with two new, > compliment proposals, PIC and GET-CERT, eventually picking PIC. > But the "must not change IKE" policy also turned up that > underlying discontent level a few notches and many folks > 'questioned' the AD's wisdom on the matter. > > (now this next part I am most unsure about, I've probably > got the principles all wrong. Please correct me gently) > In the background, Kaufman and Perlman had been working on > an SA and key management protocol which aimed to greatly reduce > the numbers of options. They recruited Harkins to their efforts > and presented a draft, IKEv2. In the background, Bellovin and > Krawczyk, had been working on a key management protocol which > aimed to greatly simplify key management in particular and did > not really consider the question of SA management. They recruited > several notables to their efforts and presented a draft, JFK. > (Oh, and about that "nutty types" reference... I mean that only > in jest and hold all these contributors in great respect. I'm > quiet jeleous of their abilities). > > Neither of these drafts directly addressed the remote > access debate. But since the possibility to 'change IKE' seems to > be back on the table not many implementers are actually > implementing PIC. Madson introduced a requirements draft which > included a scenario about legacy auth based remote access. It > appears that a successor to IKE may be allowed to address the > largest remaining area of non-interoperability. But neither draft > takes up this task yet and this was not the aim of any of the > draft authors/contributers. > > So, where we stand now is that the market has solved the > remote access problem by intrumenting with the only pragmatically > available mechanisms XAUTH or L2TP over IPsec. We have a > complicated protocol which is at great strains to do remote > access user authentication from a radius or NT domain database. > Yet this complicated and strained protocol is widely implemented > in the market place. Both new IKE successor protocols are > demonstrably more simple/efficient at authentication but neither > directly solves a problem which IKE does not solve. > > Both protocols may be more trustable from a security > perspective. But trust is a fickle thing. They would have to be > "more-trustable-enough" to overcome the distrust the market will > have for anything new. That is a high standard to raise to. > > So why bother? What "Good Thing" will we write down on our > brochures for customers about the IKE successor? Who would be > interested in buying the IKE successor who would not be satisfied > with IKE? > > > > > -- > > Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 From owner-ipsec@lists.tislabs.com Wed Jun 19 13:26:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JKQWn04049; Wed, 19 Jun 2002 13:26:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28007 Wed, 19 Jun 2002 15:47:49 -0400 (EDT) Date: Wed, 19 Jun 2002 16:00:43 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002, Paul Hoffman / VPNC wrote: > As draft-ietf-ipsec-revised-identity points out, if SOI supports > preshared secrets that are not tied to IP addresses (that is, where > each party says what ID is associated with the preshared secret it is > using), legacy authentication comes for free... I must say that although I've never been a legacy-authentication fan in general, if the details of this work out right, it sounds very attractive. There are a lot of users who want legacy authentication to work *somehow*. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 19 13:42:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JKgun05564; Wed, 19 Jun 2002 13:42:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28027 Wed, 19 Jun 2002 15:59:52 -0400 (EDT) Message-Id: <200206191452.KAA11013@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) Date: Wed, 19 Jun 2002 10:51:28 -0400 X-Mailer: KMail [version 1.3.2] References: <200206190555.g5J5sws23180@marajade.sandelman.ottawa.on.ca> In-Reply-To: <200206190555.g5J5sws23180@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA27349 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 19 June 2002 01:54, Michael Richardson wrote: >> >> Theodore> 2.3.A.) Does SOI need to natively support "legacy >> authentication systems"? > > No. cf. Bellovin Enrollment suggestions. I don't find that suggestion practical enough to justify following it now. The TODAY's reality is - non-PK auth systems are wide-spread and are NOT going away. Not to support it natively simply complicates both the protocol and the implementations. And see below. >> Theodore> 2.3.B.) Does SOI need to natively support some kind of >> "shared secret" scheme? > > Not anymore. Absolutely yes - "shared secret" is a-must. > I believe that it was necessary in IKEv1 because there was no other > useful patent free authentication system. This was not just a patent issue!! Practically all the remote access is based on some kind of non-PK approach. Technically it is simpler to support non-PK natively, than to have TWO interoperable protocols - one to retrieve the "credentials" and the other one to actually use them (and then to worry to scramble those retrieved credentials - lest somebody else "borrows" 'em later on)... I understand "PK purists" - but in no way sympathize with their position. > We should do RSA as common protocol. You mean "common algorithm", for the protocol cannot care less with what crypto function the bit-sequence is signed. I'm against limiting the algorithms to RSA-only, or even to PK-only, for the above reasons. > We MUST define the ASCII format of the raw RSA keys, and mandate > that they be loadable to the trusted store. What if there is no trusted store? Look outside your concept box. > Supporting things like pushing the policy down SHOULD be done. Yeah, but is this IKE job? -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Wed Jun 19 13:43:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JKh6n05599; Wed, 19 Jun 2002 13:43:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28042 Wed, 19 Jun 2002 16:00:53 -0400 (EDT) Message-Id: <200206191459.KAA13291@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) Date: Wed, 19 Jun 2002 10:59:27 -0400 X-Mailer: KMail [version 1.3.2] References: <200206190546.g5J5kLr23037@marajade.sandelman.ottawa.on.ca> In-Reply-To: <200206190546.g5J5kLr23037@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA27368 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 19 June 2002 01:46, Michael Richardson wrote: > I would prefer to see PFS as not optional. Since there is performance impact, I'd prefer to have a computationally inexpensive key agreement path, sacrificing PFS if necessary. -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Wed Jun 19 13:55:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JKt6n05906; Wed, 19 Jun 2002 13:55:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28076 Wed, 19 Jun 2002 16:11:59 -0400 (EDT) Message-Id: <200206192024.g5JKOnk27366@trpz.com> To: Paul Hoffman / VPNC cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Your message of "Wed, 19 Jun 2002 11:25:31 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <791.1024518272.1@tibernian.com> Date: Wed, 19 Jun 2002 13:24:32 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002 11:25:31 PDT you wrote > > >2.3.A.) Does SOI need to natively support "legacy authentication > >systems"? > > As draft-ietf-ipsec-revised-identity points out, if SOI supports > preshared secrets that are not tied to IP addresses (that is, where > each party says what ID is associated with the preshared secret it is > using), legacy authentication comes for free. The only requirement on > the legacy authentication system is that it returns authentication > proof that is large enough to be broken into an ID and a preshared > secret, and that the preshared secret part is not susceptible to a > dictionary attack. That's not necessarily true. IKEv2 supports pre-shared key authentication but the Responder has to have access to the Initiator's secret to authenticate her. In popular remote access scenarios that is not the case. The secret is known by some backend server (like a RADIUS server) which is not part of the exchange and the Responder would only pass a blob off to the server and get back a yea, nea or continue. Basically a remote access solution requires that the Initiator present her credentials and not just prove possession of them. This also means that the Responder should authenticate first to establish a secure channel in which she can place them. It would be easier to graft legacy authentication support onto JFK than IKEv2 since in JFK the Responder authenticates first but it would not be hard to do it with IKEv2 either. CRACK did it for IKEv1 and something similar could do it with IKEv2. To answer Ted's question though I think this is absolutely necessary. Lots of problems with IKEv1 had to do with the fact that we ignored this subject and people attempted to add it in various ways after the fact, some more clumsily than others. That tends to work against interoperability and for single vendor solutions. We made a mistake by ignoring this the first time and it would be a mistake to do so again. PIC is not a solution to this problem. Dan. From owner-ipsec@lists.tislabs.com Wed Jun 19 14:43:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JLhon08142; Wed, 19 Jun 2002 14:43:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28234 Wed, 19 Jun 2002 17:00:26 -0400 (EDT) Message-ID: From: "Childs, Jonathan (Jonathan)" To: ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.3 Authentication styles Date: Wed, 19 Jun 2002 17:13:20 -0400 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 couldn't agree more with Dan's assertion. We were more or less forced to add Xauth to support customer needs. After some interop problems they are finally happy using it as is. To remove something that they count on rather heavily would make IKEv2 a non starter for them. If we don't support some kind of built in legacy auth I have a feeling I will be implementing some non-standard Xauthv2 draft in the future. To answer Ted's question though I think this is absolutely necessary. Lots of problems with IKEv1 had to do with the fact that we ignored this subject and people attempted to add it in various ways after the fact, some more clumsily than others. That tends to work against interoperability and for single vendor solutions. We made a mistake by ignoring this the first time and it would be a mistake to do so again. PIC is not a solution to this problem. Dan. From owner-ipsec@lists.tislabs.com Wed Jun 19 16:09:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JN9gn13671; Wed, 19 Jun 2002 16:09:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28348 Wed, 19 Jun 2002 18:19:44 -0400 (EDT) Date: Wed, 19 Jun 2002 15:32:35 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Uri Blumenthal cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: <3D10EBC3.5C56D110@optonline.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002, Uri Blumenthal wrote: > "Chinna N.R. Pellacuru" wrote: > > > >On the other hand, there seems to be a very strong remote access > > > >contingent in this working group who seems to be very concerned about > > > >the protocol overhead inherent in separating remote access functionality > > > >from the core key management protocol. > > > > > > For those of us who believe that remote access is inherently part of > > > the VPN scenario for IPsec because our customers tell us it is, yes. > > > > > > > AFAIK, no customer has told the WG this yet. > > I am a "customer" of Remote Access and I'm telling the WG this right > now. > > > I wonder why our customers tell us a different thing. > > Don't know what customers you asked, and how your question to them was > phrased :-] Real customers don't speak up in this forum. My guess is that, it is because of some theories that were floated about them in the past, especially when it came to remote access. I don't think you are a real customer :-) If you think you are a real customer, I will try my survey on remote access security and IKE with you :-) chinna From owner-ipsec@lists.tislabs.com Wed Jun 19 16:09:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JN9gn13670; Wed, 19 Jun 2002 16:09:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28368 Wed, 19 Jun 2002 18:26:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 19 Jun 2002 18:34:46 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:16 AM -0700 6/19/02, Chinna N.R. Pellacuru wrote: >There was no technical reason given for rejecting L2TP+IPsec as a remote >access security solution in this working group. > >I wonder if there is any technical reason for requesting adding remote >access functionality to SOI now. > > thanks, > chinna > Chinna, Could you confirm that later RFCs from the L2TP WG have imposed constraints on L2TP devices that add back the access control features of IPsec that are lost due to the way that L2TP uses IPsec? If so, can you provide the RFC # (s) of the document(s)? Thanks, Steve From owner-ipsec@lists.tislabs.com Wed Jun 19 16:19:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JNJmn14031; Wed, 19 Jun 2002 16:19:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28398 Wed, 19 Jun 2002 18:35:48 -0400 (EDT) Date: Wed, 19 Jun 2002 15:49:12 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Can you please elaborate on what access control features IPsec provides. I think we discussed the access control features of IPsec not very long ago in this forum, and decided that we acknowledge that IPsec doesn't provide much of any access control features. thanks, chinna On Wed, 19 Jun 2002, Stephen Kent wrote: > At 11:16 AM -0700 6/19/02, Chinna N.R. Pellacuru wrote: > >There was no technical reason given for rejecting L2TP+IPsec as a remote > >access security solution in this working group. > > > >I wonder if there is any technical reason for requesting adding remote > >access functionality to SOI now. > > > > thanks, > > chinna > > > > Chinna, > > Could you confirm that later RFCs from the L2TP WG have imposed > constraints on L2TP devices that add back the access control features > of IPsec that are lost due to the way that L2TP uses IPsec? If so, > can you provide the RFC # (s) of the document(s)? > > Thanks, > > Steve > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Wed Jun 19 16:35:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JNZLn14347; Wed, 19 Jun 2002 16:35:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28442 Wed, 19 Jun 2002 18:51:50 -0400 (EDT) Message-Id: <200206192304.g5JN4Ck03868@trpz.com> To: "Chinna N.R. Pellacuru" cc: Paul Hoffman / VPNC , "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Your message of "Wed, 19 Jun 2002 12:06:44 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1093.1024527835.1@tibernian.com> Date: Wed, 19 Jun 2002 16:03:55 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Maybe because they're afraid of being flamed. Dan. On Wed, 19 Jun 2002 12:06:44 PDT you wrote > On Wed, 19 Jun 2002, Paul Hoffman / VPNC wrote: > > > At 8:14 PM -0400 6/18/02, Theodore Ts'o wrote: > > >On the other hand, there seems to be a very strong remote access > > >contingent in this working group who seems to be very concerned about > > >the protocol overhead inherent in separating remote access functionality > > >from the core key management protocol. > > > > For those of us who believe that remote access is inherently part of > > the VPN scenario for IPsec because our customers tell us it is, yes. > > > > AFAIK, no customer has told the WG this yet. I wonder why our customers > tell us a different thing. > > chinna > From owner-ipsec@lists.tislabs.com Wed Jun 19 16:48:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JNm3n14581; Wed, 19 Jun 2002 16:48:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28454 Wed, 19 Jun 2002 18:58:49 -0400 (EDT) Date: Wed, 19 Jun 2002 16:12:00 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Dan Harkins cc: Paul Hoffman / VPNC , "Theodore Ts'o" , Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: <200206192304.g5JN4Ck03868@trpz.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't know... This is not technical anymore... Anyway, look who's talking about flaming. I don't beleive this mail has come from Dan, unless I see a PGP signature :-) chinna On Wed, 19 Jun 2002, Dan Harkins wrote: > Maybe because they're afraid of being flamed. > > Dan. > > On Wed, 19 Jun 2002 12:06:44 PDT you wrote > > On Wed, 19 Jun 2002, Paul Hoffman / VPNC wrote: > > > > > At 8:14 PM -0400 6/18/02, Theodore Ts'o wrote: > > > >On the other hand, there seems to be a very strong remote access > > > >contingent in this working group who seems to be very concerned about > > > >the protocol overhead inherent in separating remote access functionality > > > >from the core key management protocol. > > > > > > For those of us who believe that remote access is inherently part of > > > the VPN scenario for IPsec because our customers tell us it is, yes. > > > > > > > AFAIK, no customer has told the WG this yet. I wonder why our customers > > tell us a different thing. > > > > chinna > > > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Wed Jun 19 16:50:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JNofn14683; Wed, 19 Jun 2002 16:50:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28525 Wed, 19 Jun 2002 19:12:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 19 Jun 2002 19:12:23 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:49 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote: >Hi Steve, > >Can you please elaborate on what access control features IPsec provides. > >I think we discussed the access control features of IPsec not very long >ago in this forum, and decided that we acknowledge that IPsec doesn't >provide much of any access control features. > > thanks, > chinna > You dismissed the value of having IPsec enforce static packet filtering firewall rules on traffic, but I don't consider your position on this to be representative of the WG's consensus. There were a number of rebuttals of your position from multiple, regular contributors to the list to suggest that your position was in the minority. So, my question still stands. if you're uncertain about the features in question, look at 2401, especially sections 4.4 and 5. Steve From owner-ipsec@lists.tislabs.com Wed Jun 19 17:27:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K0R7n15367; Wed, 19 Jun 2002 17:27:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28673 Wed, 19 Jun 2002 19:31:59 -0400 (EDT) Date: Wed, 19 Jun 2002 16:44:47 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002, Stephen Kent wrote: > At 3:49 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote: > >Hi Steve, > > > >Can you please elaborate on what access control features IPsec provides. > > > >I think we discussed the access control features of IPsec not very long > >ago in this forum, and decided that we acknowledge that IPsec doesn't > >provide much of any access control features. > > > > thanks, > > chinna > > > > > You dismissed the value of having IPsec enforce static packet > filtering firewall rules on traffic, but I don't consider your > position on this to be representative of the WG's consensus. There > were a number of rebuttals of your position from multiple, regular > contributors to the list to suggest that your position was in the > minority. > > So, my question still stands. if you're uncertain about the features > in question, look at 2401, especially sections 4.4 and 5. > > Steve As I saw it, a minority of implementors who build high end security gateways, complained about not just the value of minimal access control in IPsec, but also about the inefficiency of doing this in IPsec and having to do it in the firewall feature processing anyway (because firewall provides extensive and true access control and intrution detection). There was also a concern from a sizable minority, that the majority is imposing inefficiencies that they are not concerned about, on everyone. Due to the layer violations that IPsec does when doing limited 'static packet filtering', by having to look into the transport (TCP/UDP) headers, this limited benefit introduces a serious design hurdle for modularity and scalability. There was a request from the sizable minority to the majority that, all inefficiencies, and layer violations be revisited, and possibly make these implementation details not mandatory by the standards. chinna __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Wed Jun 19 17:29:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K0Tpn15400; Wed, 19 Jun 2002 17:29:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28721 Wed, 19 Jun 2002 19:49:06 -0400 (EDT) Message-ID: <3D111B6D.6E5FC6F3@bstormnetworks.com> Date: Wed, 19 Jun 2002 17:01:49 -0700 From: "Scott G. Kelly" Organization: Black Storm Networks X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: "Theodore Ts'o" Subject: Re: SOI QUESTIONS: 2.3 Authentication styles References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > The fact that there is an IPSRA working group is a fairly strong > argument that remote-access specific functionality should be handled by > another protocol. I don't agree with this assertion. I believe the ipsra wg was formed because some members the ipsec wg deemed the work to be outside the scope of ipsec proper. The existence of ipsra does not provide any basis for the argument that remote access should be handled by another protocol; rather, it is evidence that some influential folks believed this to be the case. > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? I too vote for native support for remote access authentication mechanisms. In an ideal world, PKI-based mechanisms (such as PIC) should suffice. But many users rely upon RADIUS and similar passphrase-based mechanisms, and the market will simply not embrace a solution which does not support these mechanisms. Requiring PKI add-ons will only work if vendors nearly-unamimously agree to build such mechanisms, and if RADIUS vendors agree to add front-ends for such mechanisms. Since virtually all VPN vendors of consequence have implemented xauth, l2tp, or both, this likely amounts to nothing more than wishful thinking. I think a native adaptation of Dan's crack proposal is the way to go. > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) I think we either need a shared secret scheme or vendors need to support public key mechanisms which work without CA certificates (as well as with them). The second alternative seems simpler from an operational perspective, as it could likely be piggy-backed onto an existing mode (e.g. RSA-SIG), perhaps with minimal impact. Scott From owner-ipsec@lists.tislabs.com Wed Jun 19 18:07:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K17hn16890; Wed, 19 Jun 2002 18:07:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28890 Wed, 19 Jun 2002 20:25:16 -0400 (EDT) Date: Wed, 19 Jun 2002 20:38:22 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002, Chinna N.R. Pellacuru wrote: > As I saw it, a minority of implementors who build high end security > gateways, complained about not just the value of minimal access control in > IPsec, but also about the inefficiency of doing this in IPsec and having > to do it in the firewall feature processing anyway (because firewall > provides extensive and true access control and intrution detection). As has been noted before, the IPsec standards specify the results, not the implementation, and there is no reason why the filtering called for by the IPsec specifications can't be done by a firewall mechanism. There is *no* requirement that the filtering be located within some arbitrary box labeled "IPsec", so long as it gets done somewhere. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 19 18:53:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K1rSn19217; Wed, 19 Jun 2002 18:53:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28943 Wed, 19 Jun 2002 21:11:17 -0400 (EDT) Date: Wed, 19 Jun 2002 18:23:56 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Henry Spencer cc: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002, Henry Spencer wrote: > On Wed, 19 Jun 2002, Chinna N.R. Pellacuru wrote: > > As I saw it, a minority of implementors who build high end security > > gateways, complained about not just the value of minimal access control in > > IPsec, but also about the inefficiency of doing this in IPsec and having > > to do it in the firewall feature processing anyway (because firewall > > provides extensive and true access control and intrution detection). > > As has been noted before, the IPsec standards specify the results, not the > implementation, and there is no reason why the filtering called for by the > IPsec specifications can't be done by a firewall mechanism. There is *no* > requirement that the filtering be located within some arbitrary box > labeled "IPsec", so long as it gets done somewhere. > > Henry Spencer > henry@spsystems.net Is that the majority opinion? The WG consensus? Do, most regular contributors to this forum agree to this? thanks, chinna From owner-ipsec@lists.tislabs.com Wed Jun 19 19:10:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K2A1n19508; Wed, 19 Jun 2002 19:10:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA29029 Wed, 19 Jun 2002 21:28:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 19 Jun 2002 21:40:55 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:44 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote: >On Wed, 19 Jun 2002, Stephen Kent wrote: > >> At 3:49 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote: >> >Hi Steve, >> > >> >Can you please elaborate on what access control features IPsec provides. >> > >> >I think we discussed the access control features of IPsec not very long >> >ago in this forum, and decided that we acknowledge that IPsec doesn't >> >provide much of any access control features. >> > >> > thanks, >> > chinna >> > >> >> >> You dismissed the value of having IPsec enforce static packet >> filtering firewall rules on traffic, but I don't consider your >> position on this to be representative of the WG's consensus. There >> were a number of rebuttals of your position from multiple, regular >> contributors to the list to suggest that your position was in the >> minority. >> >> So, my question still stands. if you're uncertain about the features >> in question, look at 2401, especially sections 4.4 and 5. >> >> Steve > >As I saw it, a minority of implementors who build high end security >gateways, complained about not just the value of minimal access control in >IPsec, but also about the inefficiency of doing this in IPsec and having >to do it in the firewall feature processing anyway (because firewall >provides extensive and true access control and intrution detection). I guess I should start by asking who you think builds high assurance security gateways? (or by "high end" do you just mean big and fast?) I know quite a bit about high assurance security system, having worked on such systems for over 2 decades. I can think of only 2 companies whose firewall products fall into this area. Both, to the best of my knowledge, implement IPsec and understand the benefits of employing IPsec authentication for traffic from authenticated sources. Thise benefits are not present if the firewall processing is independent of IPsec, e.g., if implemented in a separate machine. If the features are all in the same box, and SA information is used to maintain the binding between packets and the negotiated SAs, then that counts as an IPsec security gateway and we have no argument. I agree that proxy firewalls can offer better security than packet filtering firewalls, assuming suitable care is applied to the proxies, and for certain classes of applications. But, absent crypto-based security for authentication and integrity, proxy firewalls are not all that secure in the grand scheme of things. As for "intrution detection" this is not an intrinsic firewall feature. There are various approaches to ID, and many are completely independent of firewall filtering, so this is a red herring. Finally, re performance, I have played an advisory role in the development of very high speed (10 Gb/s) IPsec technology that will be coming to the market over the next 6-12 months. That argues against the inefficiency arguments you make. >There was also a concern from a sizable minority, that the majority is >imposing inefficiencies that they are not concerned about, on everyone. >Due to the layer violations that IPsec does when doing limited 'static >packet filtering', by having to look into the transport (TCP/UDP) headers, >this limited benefit introduces a serious design hurdle for modularity and >scalability. You keep harping on layer violations. Certainly this means that when you talk about the superior security offered by firewalls vs. IPsec, you are NOT referring to proxy firewalls, which certainly qualify as layer violating devices! I have long been a champion of not violating layering. I suspect my activity in this regard significantly predates any of your involvement in the Internet. But, one has to understand why layering exists and what are its merits and not make arbitrary decisions about what is or is not legitimate processing at an intermediate system. Today we are awash in intermediate systems that one might think should only examine IP headers, but which instead examine transport layer headers and make decisions based on these headers. Worse still, we have many examples of such systems that modify transport layer headers. Against this backdrop, I cannot take your complaint seriously that having a security gateway examine the port fields transport headers is a bad thing. Especially since the paragons of security you allude to in the first paragraph (firewalls that do more than static packet filtering) MUST by definition be examining these headers (or more) in their operation. >There was a request from the sizable minority to the majority that, all >inefficiencies, and layer violations be revisited, and possibly make these >implementation details not mandatory by the standards. We obviously have different recollections of the traffic on this matter. I defer to the WG chairs to keep count. Steve P.S. You still have not answered my question, so I assume the answer is not one that supports your suggestion that IPsec delegate responsibility for remote access security to the L2TP WG. From owner-ipsec@lists.tislabs.com Wed Jun 19 19:53:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K2rvn20250; Wed, 19 Jun 2002 19:53:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29090 Wed, 19 Jun 2002 22:06:27 -0400 (EDT) Date: Wed, 19 Jun 2002 19:19:05 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jun 2002, Stephen Kent wrote: > If the features are all in the same box, and SA information is used to > maintain the binding between packets and the negotiated SAs, then that > counts as an IPsec security gateway and we have no argument. > > Steve So, the limited 'static packet filtering' in IPsec is optional (if the binding can be maintained between the data source authentication and the packet, untill the firewall does the access control checks). > > P.S. You still have not answered my question, so I assume the answer > is not one that supports your suggestion that IPsec delegate > responsibility for remote access security to the L2TP WG. > In the L2TP+IPsec scenario the above observation was what we decided on and I think we convinced you then too, that we have no argument. That is why I beleive that there was no technical reason for rejecting the L2TP+IPsec proposal. Did I miss anything else? chinna From owner-ipsec@lists.tislabs.com Thu Jun 20 00:44:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K7iPn10124; Thu, 20 Jun 2002 00:44:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA29385 Thu, 20 Jun 2002 02:53:54 -0400 (EDT) Date: Thu, 20 Jun 2002 09:06:54 +0200 (MET DST) Message-Id: <200206200706.JAA06948@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? In-Reply-To: References: Organization: =?UTF-8?B?RHFJ?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi ! My 2 cents contribution (as a student): > 2.1.A.) Does SOI need to provide protection against passive > attacks for the initiator? YES > 2.1.B.) Does SOI need to provide protection against active > attacks for the initiator? YES > 2.1.C.) Does SOI need to provide protection against passive > attacks for the responder? YES ; Though I don't believe this to be usefull in VPNs ou Remote Access scenarios, it is desirable to provide a least a weak identity protection of each party. > 2.1.D.) Does SOI need to provide protection against active > attacks for the responder? NO ; IMHO, that is too strong a protection for host to host scenarios, and often meaningless for other scenarios (involving a well know gateway). -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Thu Jun 20 00:46:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5K7kpn10461; Thu, 20 Jun 2002 00:46:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29444 Thu, 20 Jun 2002 03:04:54 -0400 (EDT) Date: Thu, 20 Jun 2002 09:18:20 +0200 (MET DST) Message-Id: <200206200718.JAA07037@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-Reply-To: References: Organization: =?UTF-8?B?RA==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Paul Hoffman / VPNC wrote: > In the typical VPN scenario (either gateway-to-gateway or remote-access WAN): > > - PFS is a real requirement for some but not all user scenarios I agree. PFS support is, IMO, a requirement for scenarios involving gateways, especially in VPNs. But not everybody will need PFS, and we can expect (in some scenarios) the SA lifetime to be big enough for their use and no key derivation required. Should'nt PFS / Imperfect PFS / No PFS be negotiated in the exchanges of IKEv2 ? If not, I stand for PFS as a requirement. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Thu Jun 20 03:31:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KAVVn28499; Thu, 20 Jun 2002 03:31:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29665 Thu, 20 Jun 2002 05:49:12 -0400 (EDT) Date: Thu, 20 Jun 2002 12:02:31 +0200 (MET DST) Message-Id: <200206201002.MAA09000@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: References: Organization: =?UTF-8?B?RA==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Again, IPSEC working group --- please discuss: > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? YES. If SOI does not provide native support for this, we can expect some *ugly* solution to come out for it. Thus, a genuine standard is desirable (and it seems PIC will not do). Note that legacy auth may help to support a kind of 'null/public authentication', like ftp's ("anonymous", "root@127.0.0.1" ;-) login. Still there is the question of the how; should we consider some kind of EAP tunnel in SOI ? > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) NO. I understand it as ``Does SOI need to natively support some kind of "administrative laziness" scheme ? (Or just minded admistration only ?)'' ...'hope this does not sound like a flame. What is the value added by shared secret that certificates cannot provide ? Use of certificates is realistic even in light scenarios, without a *huge* PKI infrastructure behind, and it helps to foresee growth in the deployment. Such a feature (shared secret) must not be "needed" (but "may" be supported). -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Thu Jun 20 05:29:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KCTqn06985; Thu, 20 Jun 2002 05:29:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29777 Thu, 20 Jun 2002 07:44:23 -0400 (EDT) Message-ID: <3D11C350.E3532D23@F-Secure.com> Date: Thu, 20 Jun 2002 14:58:08 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2002 11:58:18.0391 (UTC) FILETIME=[C4429270:01C21851] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > OK, that should kick off the discussion. IPSEC wg, please answer the > questions: > > 2.1.A.) Does SOI need to provide protection against passive > attacks for the initiator? > YES > 2.1.B.) Does SOI need to provide protection against active > attacks for the initiator? > YES > 2.1.C.) Does SOI need to provide protection against passive > attacks for the responder? > YES > 2.1.D.) Does SOI need to provide protection against active > attacks for the responder? NO Note that this has implications for re-keying: the responder may not be able to initiate re-keying if that implies re-authenticating. I know some gateway vendors for some reason wish to do that. Henry Spencer wrote: > I'd prefer to see the initiator protected against active attacks, not just > passive. And I'd go along with the idea of allowing the responder to ask > for an exchange of roles, preferably in the simplest way possible. I'm a bit uneasy with this. Having this capability opens up a security risk, either by someone forging this 'reversal' packet, or by some very popular server turning that 'reversal' feature on. It also implies a user-interface option for the client: allow/disallow 'reversal'. No user's going to understand that option. A better way to protect a responder's identity is to assign that responder some pseudo-identity that's no use for the attacker. A pseudo-identity will protect the identity against valid inititators also. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Thu Jun 20 05:49:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KCnen07450; Thu, 20 Jun 2002 05:49:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29835 Thu, 20 Jun 2002 08:06:28 -0400 (EDT) Message-ID: <3D11C8AA.5822C21D@F-Secure.com> Date: Thu, 20 Jun 2002 15:20:58 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2002 12:21:09.0960 (UTC) FILETIME=[F5C76480:01C21854] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > Again, IPSEC working group --- please discuss: > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? > > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) > > (Note. If SOI is provides cert-only, then one would need to use > another protocol to bootstrap certificates from a legacy > authentication or shared secret scheme.) Legacy authentication is important, but I have a feeling that it would be even more important to support "no authentication". I'm unhappy with the fact that even though we've had IPsec for years, most of the actual traffic in the Internet is not protected by it. We should try to enable protecting all traffic, even though we can't force it. As to the actual question at hand, I'd prefer SOI to have an integrated method for doing legacy authentication, maybe similar to CRACK. I did quite a lot of X-Auth implementing at one point, and it's biggest failures were the inconvenient location at phase 1.5 of IKE, and the specifications changing all the time. L2TP/IPsec is not the solution, because it requires implementing two new protocol layers: L2TP and PPP, which could be fine for VPN but probably not for other uses. Answer to 2.3.B. is just a corollary of how the legacy authentication can be graften onto SOI. If it doesn't require shared secrets but can be done with self-signed certificates, all the better. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Thu Jun 20 06:55:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KDtrn10195; Thu, 20 Jun 2002 06:55:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29915 Thu, 20 Jun 2002 09:16:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15633.55521.843000.242864@gargle.gargle.HOWL> Date: Thu, 20 Jun 2002 09:30:09 -0400 From: Paul Koning To: pcn@cisco.com Cc: henry@spsystems.net, ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 19 June 2002) by Chinna N.R. Pellacuru: > On Wed, 19 Jun 2002, Henry Spencer wrote: > > As has been noted before, the IPsec standards specify the results, not the > > implementation... > > Is that the majority opinion? The WG consensus? Do, most regular > contributors to this forum agree to this? I believe yes, yes, and yes. ALL correctly written protocol standards specify results and not implementation. That's a fundamental rule of how you do standardization and protocol specification. paul From owner-ipsec@lists.tislabs.com Thu Jun 20 07:00:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KE0An10749; Thu, 20 Jun 2002 07:00:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29909 Thu, 20 Jun 2002 09:14:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15633.55357.917000.252177@gargle.gargle.HOWL> Date: Thu, 20 Jun 2002 09:27:25 -0400 From: Paul Koning To: pcn@cisco.com Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 19 June 2002) by Chinna N.R. Pellacuru: > As I saw it, a minority of implementors who build high end security > gateways, complained about not just the value of minimal access control in > IPsec, but also about the inefficiency of doing this in IPsec and having > to do it in the firewall feature processing anyway (because firewall > provides extensive and true access control and intrution detection). As one who worked on a product that arguably fits in this category, I'd have to disagree. There certainly is overlap between the classification processes done in IPsec, in firewalls, in traffic managers, and so on. That doesn't mean things have to be inefficient. Instead, it means you have the opportunity to provide all three functions through a single classification step. That requires more care in implementation, but it certainly is possible. paul From owner-ipsec@lists.tislabs.com Thu Jun 20 07:49:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KEnGn12618; Thu, 20 Jun 2002 07:49:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29980 Thu, 20 Jun 2002 10:08:01 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Thu, 20 Jun 2002 09:21:08 -0500 (CDT) From: Tylor Allison X-X-Sender: To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 18 Jun 2002, Theodore Ts'o wrote: > Again, IPSEC working group --- please discuss: > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? Absolutely yes... for the same reasons everyone has stated. > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? Yes... again for stated reasons. I just want to add the following... Many customers have deployed with pre-shared key authentication ... will these customers roll to IKEv2 if this authentication is not supported? What is their migration path? If pre-shared key authentication is not supported, is this WG going to define a minimal set of how PKI is to be used with VPNs? How keys/certs are generated and distributed (and the various formats for keys/certs) must be considered. If certs are used, a standard profile must be developed for IPSEC and all vendors MUST support it. Issues regarding which identities are used during the exchange and whether or not certs are passed in-line must also be addressed. Bottom-line: PKI is complicated, even if you are trying to only implement a subset of the functionality. IMO, this is one of the reasons pre-shared keys have such a wide deployment. Just my $.02. ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Thu Jun 20 07:56:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KEuDn13508; Thu, 20 Jun 2002 07:56:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00032 Thu, 20 Jun 2002 10:15:03 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-ID: <3D10EBC3.5C56D110@optonline.net> Date: Wed, 19 Jun 2002 16:38:27 -0400 From: Uri Blumenthal X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-4GB i686) X-Accept-Language: ru, ja, de, zh, en MIME-Version: 1.0 To: "Chinna N.R. Pellacuru" Original-CC: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" wrote: > > >On the other hand, there seems to be a very strong remote access > > >contingent in this working group who seems to be very concerned about > > >the protocol overhead inherent in separating remote access functionality > > >from the core key management protocol. > > > > For those of us who believe that remote access is inherently part of > > the VPN scenario for IPsec because our customers tell us it is, yes. > > > > AFAIK, no customer has told the WG this yet. I am a "customer" of Remote Access and I'm telling the WG this right now. > I wonder why our customers tell us a different thing. Don't know what customers you asked, and how your question to them was phrased :-] -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Jun 20 07:56:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KEuDn13506; Thu, 20 Jun 2002 07:56:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00044 Thu, 20 Jun 2002 10:16:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 20 Jun 2002 07:34:36 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1187549552==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1187549552==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:19 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote: >On Wed, 19 Jun 2002, Stephen Kent wrote: > >> If the features are all in the same box, and SA information is used to >> maintain the binding between packets and the negotiated SAs, then that >> counts as an IPsec security gateway and we have no argument. >> >> Steve > >So, the limited 'static packet filtering' in IPsec is optional (if the >binding can be maintained between the data source authentication and the >packet, untill the firewall does the access control checks). No, it is not optional. If a product (which I would usually define as a device or collection of software sold by one vendor as a distinct entity) performs all of the operations that IPsec requires, crypto and otherwise, then that product can rightfully claim to implement IPsec. If the functions are spread across multiple products, then none of these products can individually, claim to implement IPsec. > > P.S. You still have not answered my question, so I assume the answer > > is not one that supports your suggestion that IPsec delegate >> responsibility for remote access security to the L2TP WG. >> > >In the L2TP+IPsec scenario the above observation was what we decided on >and I think we convinced you then too, that we have no argument. Convinced me? No. I have steadfastly maintained that vague assertions about what most L2TP products may do is not a substitute for an RFC that mandates the functionality of IPsec re packet filtering in this context. If two distinct products were used, one for IPsec and one for L2TP, and if standard interfaces are used between them, the overall functionality would not be equivalent to that of a single product implementing IPsec, for the reasons I articulated long ago. Steve --============_-1187549552==_ma============ Content-Type: text/html; charset="us-ascii" Re: SOI QUESTIONS: 2.3 Authentication styles
At 7:19 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote:
On Wed, 19 Jun 2002, Stephen Kent wrote:

> If the features are all in the same box, and SA information is used to
> maintain the binding between packets and the negotiated SAs, then that
> counts as an IPsec security gateway and we have no argument.
>
> Steve

So, the limited 'static packet filtering' in IPsec is optional (if the
binding can be maintained between the data source authentication and the
packet, untill the firewall does the access control checks).

No, it is not optional. If a product (which I would usually define as a device or collection of software sold by one vendor as a distinct entity) performs all of the operations that IPsec requires, crypto and otherwise, then that product can rightfully claim to implement IPsec.  If the functions are spread across multiple products, then none of these products can individually, claim to implement IPsec.  

> P.S.  You still have not answered my question, so I assume the answer
> is not one that supports your suggestion that IPsec delegate
> responsibility for remote access security to the L2TP WG.
>

In the L2TP+IPsec scenario the above observation was what we decided on
and I think we convinced you then too, that we have no argument.

Convinced me? No. I have steadfastly maintained that vague assertions about what most L2TP products may do is not a substitute for an RFC that mandates the functionality of IPsec re packet filtering in this context. If two distinct products were used, one for IPsec and one for L2TP, and if standard interfaces are used between them, the overall functionality would not be equivalent to that of a single product implementing IPsec, for the reasons I articulated long ago.

Steve
--============_-1187549552==_ma============-- From owner-ipsec@lists.tislabs.com Thu Jun 20 07:56:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KEuDn13507; Thu, 20 Jun 2002 07:56:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00026 Thu, 20 Jun 2002 10:14:02 -0400 (EDT) Cc: uri@bell-labs.com, ipsec@lists.tislabs.com Message-ID: <3D10E983.8C8E4952@optonline.net> Date: Wed, 19 Jun 2002 16:28:51 -0400 From: Uri Blumenthal X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-4GB i686) X-Accept-Language: ru, ja, de, zh, en MIME-Version: 1.0 To: Michael Richardson Original-CC: uri@bell-labs.com, ipsec@lists.tislabs.com Subject: Re: legacy authentication support References: <200206191646.g5JGk3401633@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > Uri> I don't find that suggestion practical enough to justify following it > Uri> now. The TODAY's reality is - non-PK auth systems are wide-spread and > Uri> are NOT going away. Not to support it natively simply complicates both > Uri> the protocol and the implementations. > > If you had said this in 1996, I'd have bought this line of thought. > > EVERY SINGLE legacy auth vendor has some set of web CGIs that let you > authenticate web pages. An authenticated POST operation is just a couple > of lines in some scripting language. Even VirusBuilder could do it. I don't know what you mean by "legacy auth VENDOR". All I know is that legacy auth SYSTEMS AS DEPLOYED NOW do NOT do that Web CGI. For example, try Lucent, AT&T, IBM. I saw the system that you described - but it's (a) rather unreliable [I myself helped one person to get through - that's how I know of it], and (b) NOT widely deployed - just exists. Oh, and (c) - it's even more pain in the butt than the "normal" say, SecureID card. > I'm saying that RSA should be MUST, and should be the interop algorithm. > If there is shared secret, make it MAY. I agree with RSA-MUST. I require shared-secret MUST also. > Uri> This was not just a patent issue!! Practically all the remote access > Uri> is based on some kind of non-PK approach. > > Well, the only legacy systems that can directly use shared-secret instead > of are time based systems like SecurID. All of the X9.9 stuff (which I've > done lots of work with in various guises) is challenge/response based. Yeah - so...? It usually *is* either time-based or challenge-response... > {It also uses 1DES} (:-) > > Uri> Technically it is simpler to support non-PK natively, than to have TWO > Uri> interoperable protocols - one to retrieve the "credentials" and the > Uri> other one to actually use them (and then to worry to scramble those > Uri> retrieved credentials - lest somebody else "borrows" 'em later on)... > > Debugging two simple protocols is a lot easier than debugging one > complicated protocol. 1. They both aren't THAT simple. 2. Debugging COOPERATION of "simple" protocols suddenly stops beg simple. 3. Now you need to deploy/administer/etc two (at least :-) protocols. 4. There's no point in it tobegin with, as the extra complexity of non-PK is nil cryptographically, and close to nil implementation-wise (and if you consider that if you don't put it in this protocol, it will have to be put in in some other more complicated shape or form - I don't see the arguing point). > >> We MUST define the ASCII format of the raw RSA keys, and mandate > >> that they be loadable to the trusted store. > > Uri> What if there is no trusted store? Look outside your concept box. > > Then I guess you'll get a blank screen when you turn stuff on :-) Thank you so much! (:-) > I understand that you mean that all authentication is provided by the > user on a detached device. No GSM cell phone has this problem, no iPAQ > or PDA. I doubt that even water meters will have this problem. It's worse than just a "detached" device - it may be a public device. It may be a device with (a) no secure store worth of talking about, (b) not owned by the user... And again, the complexity of doing it the proposed way is nil. The whole argument is pure political. Why are we debating it?! -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Jun 20 08:16:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KFGkn16181; Thu, 20 Jun 2002 08:16:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00102 Thu, 20 Jun 2002 10:35:13 -0400 (EDT) Date: 20 Jun 2002 10:36:05 -0400 Message-ID: <002301c21867$cfac0310$5f76e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Ari Huttunen'" Cc: "'IP Security List'" Subject: RE: SOI QUESTIONS: 2.1 Identity protection questions? 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <3D11C350.E3532D23@F-Secure.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 2.1.D.) Does SOI need to provide protection against active > > attacks for the responder? > NO > > Note that this has implications for re-keying: the responder may > not be able to initiate re-keying if that implies re-authenticating. > I know some gateway vendors for some reason wish to do that. Without a responder lifetime notify or some kind of negotiated lifetimes, you can't control who rekeys first. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Jun 20 08:24:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KFOpn16578; Thu, 20 Jun 2002 08:24:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00125 Thu, 20 Jun 2002 10:42:16 -0400 (EDT) Date: Thu, 20 Jun 2002 10:54:57 -0400 From: "Theodore Ts'o" To: Ari Huttunen Cc: Henry Spencer , IP Security List Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? Message-ID: <20020620145457.GA13288@think.thunk.org> References: <3D11C350.E3532D23@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D11C350.E3532D23@F-Secure.com> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jun 20, 2002 at 02:58:08PM +0300, Ari Huttunen wrote: I'm a > bit uneasy with this. Having this capability opens up a security > risk, either by someone forging this 'reversal' packet, or by some > very popular server turning that 'reversal' feature on. It also > implies a user-interface option for the client: allow/disallow > 'reversal'. No user's going to understand that option. Well, I was thinking config-option where "reversal" was off by default. One of the interesting questions which is hiding here is what sort of validation and authorization checks "client" on the cert chain? Will it be the https/SSL-style checks where there is a set of "trusted roots" for which the browser will ask no questions, and the name embedded in the certificate must be a DNS name (hidden inside the e-mail name component of the x.509 cert) which must match what the client thought it was connecting to? Or will it be something else? > A better way to protect a responder's identity is to assign that responder > some pseudo-identity that's no use for the attacker. A pseudo-identity will > protect the identity against valid inititators also. How are you assuming the the pseudo-identity would be constructed? If we're assuming certificates, will it just be a self-signed certificate? In any case, the above question about how should the initiator decide whether or not to trust this certificate becomes highly relevant. Even if it is issued by some CA (at $29.95 a pop) with some bogus name, so that its pedigree can be checked, the name in the certificate needs to be relevant enough so that the initiator will accept the name. (One of the other problems here is that in the case of a home server behind a cable modem, the user may not have a valid ip address or dns server name.) - Ted From owner-ipsec@lists.tislabs.com Thu Jun 20 08:30:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KFUbn16708; Thu, 20 Jun 2002 08:30:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00186 Thu, 20 Jun 2002 10:51:30 -0400 (EDT) Date: Thu, 20 Jun 2002 11:04:37 -0400 From: "Theodore Ts'o" To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? Message-ID: <20020620150437.GB13288@think.thunk.org> References: <200206190542.g5J5gUJ22983@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206190542.g5J5gUJ22983@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jun 19, 2002 at 01:42:29AM -0400, Michael Richardson wrote: > Initiator and Responder refers to who sends the first keying message. > > Client and Server refers to who is active and who is passive in their > intent to communicate. The initiator is not always the client. > > We are VERY frequently dealing with cases where the client, having no > preconceived policy, may well start communication with the server in the > clear, and the server, having a policy will, initiate to the client in order > to send its reply. This is assuming your "opportunistic encryption" scenario, right? This is why it would be useful to do a formal write up of the security assumptions and requirements of your scenario. See the questions which I asked ari on this thread with respect to assunmptions about whether or not the "client" has a fixed IP address or even a DNS server name, and what sort of naming assumptions which you are making. These sorts of questions are relatively well understood for the VPN and road-warrier to corporate gateway scearios. But I believe that they are not quite so well understood (or at least with everyone having the same assumptions) for some of the other usage scenarios. - Ted From owner-ipsec@lists.tislabs.com Thu Jun 20 08:42:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KFgJn17020; Thu, 20 Jun 2002 08:42:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00160 Thu, 20 Jun 2002 10:49:26 -0400 (EDT) Reply-To: From: "Darren Dukes" To: "Dan Harkins" , "Paul Hoffman / VPNC" Cc: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.3 Authentication styles Date: Thu, 20 Jun 2002 11:02:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200206192024.g5JKOnk27366@trpz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So Dan et al., as long as the support for legacy auth in IKEv2 continues should we expect a CRACK-like addition to the next IKEv2 draft? From: Dan Harkins > > On Wed, 19 Jun 2002 11:25:31 PDT you wrote > > > > >2.3.A.) Does SOI need to natively support "legacy authentication > > >systems"? > > > > As draft-ietf-ipsec-revised-identity points out, if SOI supports > > preshared secrets that are not tied to IP addresses (that is, where > > each party says what ID is associated with the preshared secret it is > > using), legacy authentication comes for free. The only requirement on > > the legacy authentication system is that it returns authentication > > proof that is large enough to be broken into an ID and a preshared > > secret, and that the preshared secret part is not susceptible to a > > dictionary attack. > > That's not necessarily true. IKEv2 supports pre-shared key authentication > but the Responder has to have access to the Initiator's secret to > authenticate her. In popular remote access scenarios that is not the case. > The secret is known by some backend server (like a RADIUS server) which > is not part of the exchange and the Responder would only pass a blob off > to the server and get back a yea, nea or continue. > > Basically a remote access solution requires that the Initiator present > her credentials and not just prove possession of them. This also means > that the Responder should authenticate first to establish a secure > channel in which she can place them. > > It would be easier to graft legacy authentication support onto JFK > than IKEv2 since in JFK the Responder authenticates first but it > would not be hard to do it with IKEv2 either. CRACK did it for IKEv1 > and something similar could do it with IKEv2. > > To answer Ted's question though I think this is absolutely necessary. > Lots of problems with IKEv1 had to do with the fact that we ignored this > subject and people attempted to add it in various ways after the fact, > some more clumsily than others. That tends to work against > interoperability > and for single vendor solutions. > > We made a mistake by ignoring this the first time and it would be > a mistake > to do so again. PIC is not a solution to this problem. > > Dan. > > From owner-ipsec@lists.tislabs.com Thu Jun 20 08:46:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KFkcn17110; Thu, 20 Jun 2002 08:46:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00259 Thu, 20 Jun 2002 11:05:36 -0400 (EDT) Date: Thu, 20 Jun 2002 11:18:27 -0400 From: "Theodore Ts'o" To: Uri Blumenthal Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Message-ID: <20020620151827.GC13288@think.thunk.org> References: <200206190109.VAA17843@nwmail.wh.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206190109.VAA17843@nwmail.wh.lucent.com> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jun 18, 2002 at 09:08:57PM -0400, Uri Blumenthal wrote: > On Tuesday 18 June 2002 20:14, Theodore Ts'o wrote: > > The fact that there is an IPSRA working group is a fairly strong > > argument that remote-access specific functionality should be handled > > by another protocol. This would also have the advantage of keeping > > the core key management protocol small, ........ > > I strongly disagree with the last statement, and consider it > technically incorrect. Remote access does not add perceptible overhead > (unless you want to first retrieve your PK and then run a "normal" key > exchange, but leave out how practical it is. Suffeces to say that > "legacy auth" today fits well enough into the standard IKE). The overhead I was referring to here is protocol complexity overhead and implementation size overhead. The latter can be solved by making the legacy/remote access features optional, although that doesn't help the protocol complexity issue. - Ted From owner-ipsec@lists.tislabs.com Thu Jun 20 08:47:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KFlhn17143; Thu, 20 Jun 2002 08:47:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00247 Thu, 20 Jun 2002 11:04:35 -0400 (EDT) Message-Id: <200206201516.g5KFGLt16060@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-reply-to: Your message of "Thu, 20 Jun 2002 09:21:08 CDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jun 2002 11:16:21 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tylor" == Tylor Allison writes: Tylor> On Tue, 18 Jun 2002, Theodore Ts'o wrote: >> Again, IPSEC working group --- please discuss: >> >> 2.3.A.) Does SOI need to natively support "legacy authentication >> systems"? Tylor> Absolutely yes... for the same reasons everyone has stated. >> 2.3.B.) Does SOI need to natively support some kind of "shared >> secret" scheme? Tylor> Yes... again for stated reasons. I just want to add the following... Tylor> Many customers have deployed with pre-shared key authentication Tylor> ... will Tylor> these customers roll to IKEv2 if this authentication is not Tylor> supported? Tylor> What is their migration path? They migrate from distributing opaque blobs of hex digits that must be kept private to distributing opaque blobs of base64 digits that do not benefit from staying private, but it doesn't hurt them either. Can they tell the difference? The length is a bit longer. Tylor> If pre-shared key authentication is not supported, is this WG Tylor> going to Tylor> define a minimal set of how PKI is to be used with VPNs? How Tylor> keys/certs PK, yes. PKI, no. It is a PKIX problem. Everyone please repeat: PK does not require I to be useful. ] 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 iQCVAwUBPRHxw4qHRg3pndX9AQEqgAP9FjwRSGSgnh1SicMesvng4XAMN4Ytcduf Z5dewx6olu6Rn3ThZ5QmKAOVXwMHK8uMHog17/TV6R8Vv2T03IiV7jJt3CI8LsAA nT5KoT13/IRJL1qCSRvsKylY857qZ+aa30zSiHkw9n03ygovxhD9QSV8BV1ULkr6 Cf44v+aSFTc= =jDuR -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 20 09:13:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KGDGn17810; Thu, 20 Jun 2002 09:13:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00309 Thu, 20 Jun 2002 11:27:04 -0400 (EDT) Message-Id: <200206201539.g5KFdik00795@trpz.com> To: ddukes@cisco.com cc: "Paul Hoffman / VPNC" , "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Your message of "Thu, 20 Jun 2002 11:02:32 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <499.1024587566.1@tibernian.com> Date: Thu, 20 Jun 2002 08:39:26 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Darren, Support for legacy authentication is not continuing; it has not even started yet. That's what this discussion is about, determining whether there is support for legacy authentication. At the end of this discussion we'll know whether there is WG consensus to support legcay authentication. Some CRACK-like extension won't be added unless the WG supports it. If you feel strongly one way or the other please make your opinion known. Dan. On Thu, 20 Jun 2002 11:02:32 EDT you wrote > So Dan et al., as long as the support for legacy auth in IKEv2 continues > should we expect a CRACK-like addition to the next IKEv2 draft? > > From: Dan Harkins > > > > On Wed, 19 Jun 2002 11:25:31 PDT you wrote > > > > > > >2.3.A.) Does SOI need to natively support "legacy authentication > > > >systems"? > > > > > > As draft-ietf-ipsec-revised-identity points out, if SOI supports > > > preshared secrets that are not tied to IP addresses (that is, where > > > each party says what ID is associated with the preshared secret it is > > > using), legacy authentication comes for free. The only requirement on > > > the legacy authentication system is that it returns authentication > > > proof that is large enough to be broken into an ID and a preshared > > > secret, and that the preshared secret part is not susceptible to a > > > dictionary attack. > > > > That's not necessarily true. IKEv2 supports pre-shared key authentication > > but the Responder has to have access to the Initiator's secret to > > authenticate her. In popular remote access scenarios that is not the case. > > The secret is known by some backend server (like a RADIUS server) which > > is not part of the exchange and the Responder would only pass a blob off > > to the server and get back a yea, nea or continue. > > > > Basically a remote access solution requires that the Initiator present > > her credentials and not just prove possession of them. This also means > > that the Responder should authenticate first to establish a secure > > channel in which she can place them. > > > > It would be easier to graft legacy authentication support onto JFK > > than IKEv2 since in JFK the Responder authenticates first but it > > would not be hard to do it with IKEv2 either. CRACK did it for IKEv1 > > and something similar could do it with IKEv2. > > > > To answer Ted's question though I think this is absolutely necessary. > > Lots of problems with IKEv1 had to do with the fact that we ignored this > > subject and people attempted to add it in various ways after the fact, > > some more clumsily than others. That tends to work against > > interoperability > > and for single vendor solutions. > > > > We made a mistake by ignoring this the first time and it would be > > a mistake > > to do so again. PIC is not a solution to this problem. > > > > Dan. > > > > > From owner-ipsec@lists.tislabs.com Thu Jun 20 09:36:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KGatn18253; Thu, 20 Jun 2002 09:36:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00362 Thu, 20 Jun 2002 11:57:25 -0400 (EDT) Date: Thu, 20 Jun 2002 09:10:42 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles 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, 20 Jun 2002, Stephen Kent wrote: > At 7:19 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote: > >On Wed, 19 Jun 2002, Stephen Kent wrote: > > > >> If the features are all in the same box, and SA information is used to > >> maintain the binding between packets and the negotiated SAs, then that > >> counts as an IPsec security gateway and we have no argument. > >> > >> Steve > > > >So, the limited 'static packet filtering' in IPsec is optional (if the > >binding can be maintained between the data source authentication and the > >packet, untill the firewall does the access control checks). > > No, it is not optional. If a product (which I would usually define as a > device or collection of software sold by one vendor as a distinct > entity) performs all of the operations that IPsec requires, crypto and > otherwise, then that product can rightfully claim to implement IPsec. > If the functions are spread across multiple products, then none of these > products can individually, claim to implement IPsec. It is optional in IPsec, not optional on the whole. It is not necessary to do it in IPsec if we do it elsewhere. Doing it in IPsec is inefficient for the minimal benefit. > > > > P.S. You still have not answered my question, so I assume the answer > > > is not one that supports your suggestion that IPsec delegate > >> responsibility for remote access security to the L2TP WG. > >> > > > >In the L2TP+IPsec scenario the above observation was what we decided on > >and I think we convinced you then too, that we have no argument. > > Convinced me? No. I have steadfastly maintained that vague assertions > about what most L2TP products may do is not a substitute for an RFC that > mandates the functionality of IPsec re packet filtering in this context. > If two distinct products were used, one for IPsec and one for L2TP, and > if standard interfaces are used between them, the overall functionality > would not be equivalent to that of a single product implementing IPsec, > for the reasons I articulated long ago. > > Steve Acknwoledging that the minimal 'static packet filtering' provided by IPsec is useless is much better than saying that IPsec mandates this minimal 'static packet filtering' and everyone has to do it in IPsec. chinna __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Thu Jun 20 09:38:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KGcYn18304; Thu, 20 Jun 2002 09:38:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00350 Thu, 20 Jun 2002 11:53:24 -0400 (EDT) Date: Thu, 20 Jun 2002 09:06:26 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Paul Koning cc: kent@bbn.com, Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: <15633.55357.917000.252177@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 Jun 2002, Paul Koning wrote: > Excerpt of message (sent 19 June 2002) by Chinna N.R. Pellacuru: > > As I saw it, a minority of implementors who build high end security > > gateways, complained about not just the value of minimal access control in > > IPsec, but also about the inefficiency of doing this in IPsec and having > > to do it in the firewall feature processing anyway (because firewall > > provides extensive and true access control and intrution detection). > > As one who worked on a product that arguably fits in this category, > I'd have to disagree. There certainly is overlap between the > classification processes done in IPsec, in firewalls, in traffic > managers, and so on. That doesn't mean things have to be > inefficient. Instead, it means you have the opportunity to provide > all three functions through a single classification step. That > requires more care in implementation, but it certainly is possible. > > paul > Because we do the packet classification once, we test the result in multiple places and that is not inefficient. Someone has to sync the policies of all these modules so that the policies of all the modules play nicely with every other module that does the exact same functionality. I think these assumptions are lacking practical experience and large scale deployment headaches. chinna From owner-ipsec@lists.tislabs.com Thu Jun 20 10:05:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KH5Cn20349; Thu, 20 Jun 2002 10:05:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00470 Thu, 20 Jun 2002 12:22:42 -0400 (EDT) Date: Thu, 20 Jun 2002 12:35:32 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles 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, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > ...is much better than saying that IPsec mandates this minimal > 'static packet filtering' and everyone has to do it in IPsec. What does it mean to do something "in IPsec"? IPsec is a set of protocols, not a hardware box or a software module. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 20 10:32:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHVxn21575; Thu, 20 Jun 2002 10:31:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00553 Thu, 20 Jun 2002 12:49:02 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.4 Number of crypto operations Phone: (781) 391-3464 Message-Id: Date: Thu, 20 Jun 2002 13:02:27 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question..... 2.4 Number of crypto operations 2.4.A) JFK requires substantially more cryptographic operations for rekeying (two more signatures, two more signature validations, and three more hashes). Is this a problem? More generally, does SOI need to be able to support "fast" rekeying? From owner-ipsec@lists.tislabs.com Thu Jun 20 10:35:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHZrn21632; Thu, 20 Jun 2002 10:35:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00567 Thu, 20 Jun 2002 12:50:04 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.5 Plausible denaibility Phone: (781) 391-3464 Message-Id: Date: Thu, 20 Jun 2002 13:03:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question..... (for more discussion and a clear definition of "plausible denaibility", please see section 2.5 of the soi-features I-D). 2.5) Plausible denaibility 2.5.A) Does SOI need to provide "plausible deniability" (the opposite of "non-repudiation") for the initiator? 2.5.B) Does SOI need to provide "plausible deniability" (the opposite of "non-repudiation") for the responder? Implications from the Scenarios: [none given] From owner-ipsec@lists.tislabs.com Thu Jun 20 10:36:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHaGn21646; Thu, 20 Jun 2002 10:36:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00573 Thu, 20 Jun 2002 12:51:00 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.6 Formal proofs of security Phone: (781) 391-3464 Message-Id: Date: Thu, 20 Jun 2002 13:04:24 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question..... 2.6 Formal proofs of security 2.6.) Does SOI need to provide a formal proof of security? (Is this a "must have" or a "nice to have"? What are we willing to trade-off for having a formal proof of security?) Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Thu Jun 20 10:37:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHbqn21675; Thu, 20 Jun 2002 10:37:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00551 Thu, 20 Jun 2002 12:48:59 -0400 (EDT) Date: 20 Jun 2002 12:48:41 -0400 Message-ID: <000201c2187a$5625f4c0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Dan Harkins'" , " " Cc: ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.3 Authentication styles 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <200206201539.g5KFdik00795@trpz.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Guys, can we try to avoid debating semantics. Darren said "as long as [public] support for legacy auth in IKEv2 continues". Dan said "[protocol] support for legacy authentication is not continuing." Both are valid uses of the word "support". Dan, you even used both meanings in the paragraph below. This isn't ukases. 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 Dan Harkins > Sent: Thursday, June 20, 2002 11:39 AM > To: ddukes@cisco.com > Cc: Paul Hoffman / VPNC; Theodore Ts'o; ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.3 Authentication styles > > > Darren, > > Support for legacy authentication is not continuing; it has not even > started yet. That's what this discussion is about, determining whether > there is support for legacy authentication. At the end of > this discussion > we'll know whether there is WG consensus to support legcay > authentication. > Some CRACK-like extension won't be added unless the WG supports it. > > If you feel strongly one way or the other please make your > opinion known. > > Dan. > > On Thu, 20 Jun 2002 11:02:32 EDT you wrote > > So Dan et al., as long as the support for legacy auth in > IKEv2 continues > > should we expect a CRACK-like addition to the next IKEv2 draft? > > > > From: Dan Harkins > > > > > > On Wed, 19 Jun 2002 11:25:31 PDT you wrote > > > > > > > > >2.3.A.) Does SOI need to natively support "legacy > authentication > > > > >systems"? > > > > > > > > As draft-ietf-ipsec-revised-identity points out, if SOI supports > > > > preshared secrets that are not tied to IP addresses > (that is, where > > > > each party says what ID is associated with the > preshared secret it is > > > > using), legacy authentication comes for free. The only > requirement on > > > > the legacy authentication system is that it returns > authentication > > > > proof that is large enough to be broken into an ID and > a preshared > > > > secret, and that the preshared secret part is not > susceptible to a > > > > dictionary attack. > > > > > > That's not necessarily true. IKEv2 supports pre-shared > key authentication > > > but the Responder has to have access to the Initiator's secret to > > > authenticate her. In popular remote access scenarios that > is not the case. > > > The secret is known by some backend server (like a RADIUS > server) which > > > is not part of the exchange and the Responder would only > pass a blob off > > > to the server and get back a yea, nea or continue. > > > > > > Basically a remote access solution requires that the > Initiator present > > > her credentials and not just prove possession of them. > This also means > > > that the Responder should authenticate first to establish a secure > > > channel in which she can place them. > > > > > > It would be easier to graft legacy authentication support onto JFK > > > than IKEv2 since in JFK the Responder authenticates first but it > > > would not be hard to do it with IKEv2 either. CRACK did > it for IKEv1 > > > and something similar could do it with IKEv2. > > > > > > To answer Ted's question though I think this is > absolutely necessary. > > > Lots of problems with IKEv1 had to do with the fact that > we ignored this > > > subject and people attempted to add it in various ways > after the fact, > > > some more clumsily than others. That tends to work against > > > interoperability > > > and for single vendor solutions. > > > > > > We made a mistake by ignoring this the first time and it would be > > > a mistake > > > to do so again. PIC is not a solution to this problem. > > > > > > Dan. > > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Jun 20 10:41:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHfvn22139; Thu, 20 Jun 2002 10:41:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00612 Thu, 20 Jun 2002 12:56:05 -0400 (EDT) Message-Id: <200206201708.g5KH8Cd17334@marajade.sandelman.ottawa.on.ca> To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? In-reply-to: Your message of "Thu, 20 Jun 2002 11:04:37 EDT." <20020620150437.GB13288@think.thunk.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jun 2002 13:08:11 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: >> Initiator and Responder refers to who sends the first keying message. >> >> Client and Server refers to who is active and who is passive in their >> intent to communicate. The initiator is not always the client. >> >> We are VERY frequently dealing with cases where the client, having no >> preconceived policy, may well start communication with the server in the >> clear, and the server, having a policy will, initiate to the client in >> order >> to send its reply. Theodore> This is assuming your "opportunistic encryption" scenario, right? No, not necessarily. It certainly happens a lot more often for us. In fact, has a number of very nice operational advantages for easing deployment. I can trivially think of hot-failover or load-balancing RW VPN scenarios where this could happen. Take, for instance, a situation where the backup machine, having been made aware of the policy that on the primary machine, gets a packet that needs encryption (the other box just died and vrrp kicked in) and decides it has to initiate. The simpler situation is byte or packet based rekeying. If you assume your model of RW=client, HQ=server, then I'll bet the data flow is very assymmetric, and so the HQ/server end will want to rekey first. Any protocol that does not maintain a phase 1 will have to reveal identities in the other direction to rekey. Theodore> This is why it would be useful to do a formal write up of the Theodore> security Theodore> assumptions and requirements of your scenario. Well, I'm at section 6 of the Madison draft, and I do intend to post when I finish reading, but your questions are a very good proceedure for us to do. Theodore> See the questions which I asked ari on this thread with respect Theodore> to assunmptions about whether or not the "client" has a fixed Theodore> IP address or even a DNS server name, and what sort of naming Theodore> assumptions which you are making. Theodore> These sorts of questions are relatively well understood for the Theodore> VPN and road-warrier to corporate gateway scearios. But I Theodore> believe that they are not quite so well understood (or at least Theodore> with everyone having the same assumptions) for some of the Theodore> other usage scenarios. I am trying to say that, even without OE, there really can be no assumption made about relationships like "client=initiator" and "server=responder". This is particularly clear to me in the absense of a phase 1. === Paul's comments about protecting the responder against even active attacks are particularly well taken to me. Again, I'll re-interate that I'd prefer to have an optional phase 1 exchange where secondary identities can be exchanged. If the identities that are revealed (particularly by responders) on the first pass are always IPV4 identities that can be checked by a lookup in the reverse map, there is really no additional information gleamed to even an active attacker. This goes a long way towards making it easier for people to less more ephermeral IDs on the outside. Vs, doing a phase 1 exchange and receiving a cert that says, e.g: "Foo Corp Financial Transaction processing Server Gateway" with a Verisign Financial Server signer. I know I just found a bank-like entity based upon who signed it. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPRIL+IqHRg3pndX9AQEhBAP+Lik6DhzzwocIptFbhGVXadhtxrww6JFO UrT+Ka7xlkDW6zrugkpJEZSkFFPab8zQql16hAq7sVj5n68NsU4XXFc7M5Xit1cA kDGePwJeeoyZziwRXHN3KVZaS9MQVenEPpTNOxf81H4UcGoYOMBJYVlI/6kMyQOx PIRQXZ7bfv4= =2rR9 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 20 10:43:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHhLn22314; Thu, 20 Jun 2002 10:43:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00564 Thu, 20 Jun 2002 12:49:59 -0400 (EDT) Message-Id: <200206201702.g5KH2wpw007976@kebe.east.sun.com> Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-Reply-To: from "Theodore Ts'o" at "Jun 18, 2002 06:30:19 pm" To: ipsec@lists.tislabs.com Date: Thu, 20 Jun 2002 13:02:58 -0400 (EDT) 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 > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? Absolutely not! As pointed out by Ted, there is an IPSRA working group for such problems. As such, people interested in remote access should be hanging out there. IKE is for much more than remote access. While a very important application of IPsec technologies, remote access shouldn't hijack control of what can and should be a general-purpose security toolset. > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? > > (Note. If SOI is provides cert-only, then one would need to use > another protocol to bootstrap certificates from a legacy > authentication or shared secret scheme.) If self-signed certificates are supported, how is this different from a shared-secret? My answer is if we don't support shared-secret, we MUST support self-signed certificates. > VPN: << addresses cannot be used as phase 1 identifiers. This also means that > the authentication material cannot be chosen based upon the IP address > in the packet.>>> [[[2.3]]] Self-signed certificates solve this problem, while not invoking the cost of a PKI. > SRA: << this policy information before the IPsec tunnel is constructed.>>> > [[[2.3]]] Two words: Transport mode! You can perform an IPsec-protected transport mode exchange to get tunnel plumbing information, and then feed that into the local tunnel-plumbing code. > SRA: << accommodate re-authentication based on the RAS or authentication > server site security policy>>> [[[2.3]]] Again, this can be done with transport mode. Have a daemon/agent running that responds to requests for re-authentication. > SRA: << location of the authentication server relative to the client and the > RAS. In many scenarios, server tends to be "behind" the RAS device, in > the domain that is being secured by the RAS, which may be problematic > for bootstrapping the user authentication for the client-to-RAS > connection.>>> [[[2.3]]] IMHO, you should use a certificate or something else for the IPsec part of RAS. If you use a legacy authentication for even the bootstrapping phase, you are weakening the overall security of your IKE exchange, and hence your IPsec SAs as well. Dan From owner-ipsec@lists.tislabs.com Thu Jun 20 11:00:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KI0on24698; Thu, 20 Jun 2002 11:00:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00707 Thu, 20 Jun 2002 13:18:18 -0400 (EDT) Message-Id: <200206201731.g5KHVlrn008168@kebe.east.sun.com> Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security In-Reply-To: from "Theodore Ts'o" at "Jun 20, 2002 01:04:24 pm" To: ipsec@lists.tislabs.com Date: Thu, 20 Jun 2002 13:31:47 -0400 (EDT) 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 > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) A formal proof of security is a "very nice to have". It will calm some people down immensely. Dan From owner-ipsec@lists.tislabs.com Thu Jun 20 11:06:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KI6Bn25438; Thu, 20 Jun 2002 11:06:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00753 Thu, 20 Jun 2002 13:28:27 -0400 (EDT) Reply-To: From: "Darren Dukes" To: "Dan Harkins" Cc: "Paul Hoffman / VPNC" , "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.3 Authentication styles Date: Thu, 20 Jun 2002 13:41:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200206201539.g5KFdik00795@trpz.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I should have preceded 'support' with 'WG', regardless you answered my question. Thanks, Darren > -----Original Message----- > From: Dan Harkins [mailto:dharkins@tibernian.com] > Sent: Thursday, June 20, 2002 11:39 AM > To: ddukes@cisco.com > Cc: Paul Hoffman / VPNC; Theodore Ts'o; ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.3 Authentication styles > > > Darren, > > Support for legacy authentication is not continuing; it has not even > started yet. That's what this discussion is about, determining whether > there is support for legacy authentication. At the end of this discussion > we'll know whether there is WG consensus to support legcay authentication. > Some CRACK-like extension won't be added unless the WG supports it. > > If you feel strongly one way or the other please make your > opinion known. > > Dan. > > On Thu, 20 Jun 2002 11:02:32 EDT you wrote > > So Dan et al., as long as the support for legacy auth in IKEv2 continues > > should we expect a CRACK-like addition to the next IKEv2 draft? > > > > From: Dan Harkins > > > > > > On Wed, 19 Jun 2002 11:25:31 PDT you wrote > > > > > > > > >2.3.A.) Does SOI need to natively support "legacy authentication > > > > >systems"? > > > > > > > > As draft-ietf-ipsec-revised-identity points out, if SOI supports > > > > preshared secrets that are not tied to IP addresses (that is, where > > > > each party says what ID is associated with the preshared > secret it is > > > > using), legacy authentication comes for free. The only > requirement on > > > > the legacy authentication system is that it returns authentication > > > > proof that is large enough to be broken into an ID and a preshared > > > > secret, and that the preshared secret part is not susceptible to a > > > > dictionary attack. > > > > > > That's not necessarily true. IKEv2 supports pre-shared key > authentication > > > but the Responder has to have access to the Initiator's secret to > > > authenticate her. In popular remote access scenarios that is > not the case. > > > The secret is known by some backend server (like a RADIUS > server) which > > > is not part of the exchange and the Responder would only pass > a blob off > > > to the server and get back a yea, nea or continue. > > > > > > Basically a remote access solution requires that the Initiator present > > > her credentials and not just prove possession of them. This also means > > > that the Responder should authenticate first to establish a secure > > > channel in which she can place them. > > > > > > It would be easier to graft legacy authentication support onto JFK > > > than IKEv2 since in JFK the Responder authenticates first but it > > > would not be hard to do it with IKEv2 either. CRACK did it for IKEv1 > > > and something similar could do it with IKEv2. > > > > > > To answer Ted's question though I think this is absolutely necessary. > > > Lots of problems with IKEv1 had to do with the fact that we > ignored this > > > subject and people attempted to add it in various ways after the fact, > > > some more clumsily than others. That tends to work against > > > interoperability > > > and for single vendor solutions. > > > > > > We made a mistake by ignoring this the first time and it would be > > > a mistake > > > to do so again. PIC is not a solution to this problem. > > > > > > Dan. > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Jun 20 11:07:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KI7Yn25640; Thu, 20 Jun 2002 11:07:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00754 Thu, 20 Jun 2002 13:28:32 -0400 (EDT) Date: Thu, 20 Jun 2002 10:41:39 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I really don't understand the reasoning behing IPsec trying to mandate a minimal useless 'static packet filtering'. The problem of access control and intrusion detection, as far as I can see belongs in the firewall functionality. The philosophy that if I am not having a problem, in my implementation, and if you are having a problem in your implementation and deployment, then it is probably an implemetation defect, rather than a larger problem, is a recurring theme in this WG. I guess the assumption is that all IPsec implemetations are being deployed in exactly the same way that your implementation is being deployed/not deployed. We have seen it a lot for a very very long time WRT IKE. Now for some reason the IKE fort was brought down (kink?), and we are actually discussing a successor to IKE after a long period of denial, and accusations and flaming. I hope the RFC 2401 fort also comes down sometime in the near future, and there is some acknowlegement to practical problems and deployment headaches. chinna On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > On Thu, 20 Jun 2002, Stephen Kent wrote: > > > At 7:19 PM -0700 6/19/02, Chinna N.R. Pellacuru wrote: > > >On Wed, 19 Jun 2002, Stephen Kent wrote: > > > > > >> If the features are all in the same box, and SA information is used to > > >> maintain the binding between packets and the negotiated SAs, then that > > >> counts as an IPsec security gateway and we have no argument. > > >> > > >> Steve > > > > > >So, the limited 'static packet filtering' in IPsec is optional (if the > > >binding can be maintained between the data source authentication and the > > >packet, untill the firewall does the access control checks). > > > > No, it is not optional. If a product (which I would usually define as a > > device or collection of software sold by one vendor as a distinct > > entity) performs all of the operations that IPsec requires, crypto and > > otherwise, then that product can rightfully claim to implement IPsec. > > If the functions are spread across multiple products, then none of these > > products can individually, claim to implement IPsec. > > It is optional in IPsec, not optional on the whole. It is not necessary to > do it in IPsec if we do it elsewhere. Doing it in IPsec is inefficient for > the minimal benefit. > > > > > > > P.S. You still have not answered my question, so I assume the answer > > > > is not one that supports your suggestion that IPsec delegate > > >> responsibility for remote access security to the L2TP WG. > > >> > > > > > >In the L2TP+IPsec scenario the above observation was what we decided on > > >and I think we convinced you then too, that we have no argument. > > > > Convinced me? No. I have steadfastly maintained that vague assertions > > about what most L2TP products may do is not a substitute for an RFC that > > mandates the functionality of IPsec re packet filtering in this context. > > If two distinct products were used, one for IPsec and one for L2TP, and > > if standard interfaces are used between them, the overall functionality > > would not be equivalent to that of a single product implementing IPsec, > > for the reasons I articulated long ago. > > > > Steve > > Acknwoledging that the minimal 'static packet filtering' provided by IPsec > is useless is much better than saying that IPsec mandates this minimal > 'static packet filtering' and everyone has to do it in IPsec. > > chinna > __ > chinna narasimha reddy pellacuru > "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, > it is the repudiation of moral equivalence." > > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Thu Jun 20 11:14:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIEYn26291; Thu, 20 Jun 2002 11:14:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00735 Thu, 20 Jun 2002 13:27:24 -0400 (EDT) Date: 20 Jun 2002 13:28:06 -0400 Message-ID: <000301c2187f$d7c7e470$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Dan Harkins'" Cc: "'Darren'" , " 'list'" Subject: RE: SOI QUESTIONS: 2.3 Authentication styles 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <200206201715.g5KHFKk05506@trpz.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well about 10 people have so far spoken up in favour of legacy auth. Unless 11 people are waiting until the last minute to voice their opposition to legacy auth, I'd say the support is there. 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: Dan Harkins [mailto:dharkins@tibernian.com] > Sent: Thursday, June 20, 2002 1:15 PM > To: andrew.krywaniuk@alcatel.com > Cc: ddukes@cisco.com; ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.3 Authentication styles > > > You're putting (different!) words in both our sentences and then > unsurprisingly coming to an incorrect conclusion that this is a > issue of semantics. Stop doing that. > > What I said was that we have not yet determined whether the thing > Darren assumes exists (and is continuing) in fact exists. This is > a process issue. > > Dan. > > On 20 Jun 2002 12:48:41 EDT you wrote > > Guys, can we try to avoid debating semantics. Darren said > "as long as > > [public] support for legacy auth in IKEv2 continues". Dan > said "[protocol] > > support for legacy authentication is not continuing." Both > are valid uses of > > the word "support". Dan, you even used both meanings in the > paragraph below. > > This isn't ukases. > > > > 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 Dan Harkins > > > Sent: Thursday, June 20, 2002 11:39 AM > > > To: ddukes@cisco.com > > > Cc: Paul Hoffman / VPNC; Theodore Ts'o; ipsec@lists.tislabs.com > > > Subject: Re: SOI QUESTIONS: 2.3 Authentication styles > > > > > > > > > Darren, > > > > > > Support for legacy authentication is not continuing; it > has not even > > > started yet. That's what this discussion is about, > determining whether > > > there is support for legacy authentication. At the end of > > > this discussion > > > we'll know whether there is WG consensus to support legcay > > > authentication. > > > Some CRACK-like extension won't be added unless the WG > supports it. > > > > > > If you feel strongly one way or the other please make your > > > opinion known. > > > > > > Dan. > > > > > > On Thu, 20 Jun 2002 11:02:32 EDT you wrote > > > > So Dan et al., as long as the support for legacy auth in > > > IKEv2 continues > > > > should we expect a CRACK-like addition to the next IKEv2 draft? > > > > > > > > From: Dan Harkins > > > > > > > > > > On Wed, 19 Jun 2002 11:25:31 PDT you wrote > > > > > > > > > > > > >2.3.A.) Does SOI need to natively support "legacy > > > authentication > > > > > > >systems"? > > > > > > > > > > > > As draft-ietf-ipsec-revised-identity points out, if > SOI supports > > > > > > preshared secrets that are not tied to IP addresses > > > (that is, where > > > > > > each party says what ID is associated with the > > > preshared secret it is > > > > > > using), legacy authentication comes for free. The only > > > requirement on > > > > > > the legacy authentication system is that it returns > > > authentication > > > > > > proof that is large enough to be broken into an ID and > > > a preshared > > > > > > secret, and that the preshared secret part is not > > > susceptible to a > > > > > > dictionary attack. > > > > > > > > > > That's not necessarily true. IKEv2 supports pre-shared > > > key authentication > > > > > but the Responder has to have access to the > Initiator's secret to > > > > > authenticate her. In popular remote access scenarios that > > > is not the case. > > > > > The secret is known by some backend server (like a RADIUS > > > server) which > > > > > is not part of the exchange and the Responder would only > > > pass a blob off > > > > > to the server and get back a yea, nea or continue. > > > > > > > > > > Basically a remote access solution requires that the > > > Initiator present > > > > > her credentials and not just prove possession of them. > > > This also means > > > > > that the Responder should authenticate first to > establish a secure > > > > > channel in which she can place them. > > > > > > > > > > It would be easier to graft legacy authentication > support onto JFK > > > > > than IKEv2 since in JFK the Responder authenticates > first but it > > > > > would not be hard to do it with IKEv2 either. CRACK did > > > it for IKEv1 > > > > > and something similar could do it with IKEv2. > > > > > > > > > > To answer Ted's question though I think this is > > > absolutely necessary. > > > > > Lots of problems with IKEv1 had to do with the fact that > > > we ignored this > > > > > subject and people attempted to add it in various ways > > > after the fact, > > > > > some more clumsily than others. That tends to work against > > > > > interoperability > > > > > and for single vendor solutions. > > > > > > > > > > We made a mistake by ignoring this the first time and > it would be > > > > > a mistake > > > > > to do so again. PIC is not a solution to this problem. > > > > > > > > > > Dan. > > > > > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Jun 20 11:26:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIQqn27068; Thu, 20 Jun 2002 11:26:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00832 Thu, 20 Jun 2002 13:43:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15634.5954.4000.837554@gargle.gargle.HOWL> Date: Thu, 20 Jun 2002 13:56:18 -0400 From: Paul Koning To: mcr@sandelman.ottawa.on.ca Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) References: <200206201516.g5KFGLt16060@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 20 June 2002) by Michael Richardson: > Tylor> Many customers have deployed with pre-shared key authentication > Tylor> ... will > Tylor> these customers roll to IKEv2 if this authentication is not > Tylor> supported? > Tylor> What is their migration path? > > They migrate from distributing opaque blobs of hex digits that must be > kept private to distributing opaque blobs of base64 digits that do not > benefit from staying private, but it doesn't hurt them either. > > Can they tell the difference? The length is a bit longer. A LOT longer. Long enough that -- unlike preshared keys -- you cannot enter them manually. > Tylor> If pre-shared key authentication is not supported, is this WG > Tylor> going to > Tylor> define a minimal set of how PKI is to be used with VPNs? How > Tylor> keys/certs > > PK, yes. > > PKI, no. It is a PKIX problem. > > Everyone please repeat: PK does not require I to be useful. True. But PK, even if all you ever use is selfsigned certs, still needs a lot more near-incomprehensible concepts than preshared keys do. paul From owner-ipsec@lists.tislabs.com Thu Jun 20 11:28:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KISOn27144; Thu, 20 Jun 2002 11:28:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00849 Thu, 20 Jun 2002 13:47:45 -0400 (EDT) Message-ID: <3D12192B.7050801@nortelnetworks.com> Date: Thu, 20 Jun 2002 14:04:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.4 Number of crypto operations References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > Please discuss and answer this question..... > > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? > Fast rekeying *is* important in SOI. More specifically, a secure SA management channel can be used for sending Informational, Delete or error messages. It is more efficient and scales better (e.g. in the VPN and remote access scenarios). cheers, Lakshminath > From owner-ipsec@lists.tislabs.com Thu Jun 20 11:30:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIULn27230; Thu, 20 Jun 2002 11:30:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00880 Thu, 20 Jun 2002 13:52:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 20 Jun 2002 11:06:00 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:04 PM -0400 6/20/02, Theodore Ts'o wrote: >2.6.) Does SOI need to provide a formal proof of security? (Is this >a "must have" or a "nice to have"? What are we willing to trade-off >for having a formal proof of security?) In the typical VPN scenario (either gateway-to-gateway or remote-access WAN), this is not important. It is nice to have, of course, but only to keep ourselves happy. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 20 11:30:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIUNn27250; Thu, 20 Jun 2002 11:30:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00863 Thu, 20 Jun 2002 13:50:44 -0400 (EDT) Message-ID: <3D1219DF.70605@nortelnetworks.com> Date: Thu, 20 Jun 2002 14:07:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > Please discuss and answer this question..... > > 2.6 Formal proofs of security > > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) It is important that the protocol goes through some level of formal analysis. For example, Cathy Meadows did an analysis of GDOI (using NRL protocol analyzer?) and helped identify some security holes. A similar analysis would be very useful in case of SOI as well. best, Lakshminath > > Implications from the Scenarios: > > [none] > > From owner-ipsec@lists.tislabs.com Thu Jun 20 11:32:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIWan27354; Thu, 20 Jun 2002 11:32:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00886 Thu, 20 Jun 2002 13:53:46 -0400 (EDT) Date: Thu, 20 Jun 2002 14:06:22 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles 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, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > I really don't understand the reasoning behing IPsec trying to mandate a > minimal useless 'static packet filtering'. The problem of access control > and intrusion detection, as far as I can see belongs in the firewall > functionality. IPsec, being about IP *security*, not just IP encryption and authentication, includes a specification for minimal firewall functionality, since that is a necessary part of secure IP. Implementations are, of course, free to provide more sophisticated firewall mechanisms, and to implement the IPsec- mandated functionality using that more sophisticated mechanism. (I have long thought it a mistake that RFC 2401 does not explicitly say something like the previous paragraph. It's important, and people often overlook it or misunderstand it.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 20 11:34:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIYSn27408; Thu, 20 Jun 2002 11:34:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00898 Thu, 20 Jun 2002 13:54:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 20 Jun 2002 11:07:33 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: SOI QUESTIONS: 2.5 Plausible denaibility Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >2.5.A) Does SOI need to provide "plausible deniability" (the opposite >of "non-repudiation") for the initiator? > >2.5.B) Does SOI need to provide "plausible deniability" (the opposite >of "non-repudiation") for the responder? In the typical VPN scenario (either gateway-to-gateway or remote-access WAN), neither of these are important. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 20 11:49:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KInNn27908; Thu, 20 Jun 2002 11:49:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00632 Thu, 20 Jun 2002 13:03:09 -0400 (EDT) Message-Id: <200206201715.g5KHFKk05506@trpz.com> To: andrew.krywaniuk@alcatel.com cc: ddukes@cisco.com, ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Your message of "20 Jun 2002 12:48:41 EDT." <000201c2187a$5625f4c0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <792.1024593301.1@tibernian.com> Date: Thu, 20 Jun 2002 10:15:01 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You're putting (different!) words in both our sentences and then unsurprisingly coming to an incorrect conclusion that this is a issue of semantics. Stop doing that. What I said was that we have not yet determined whether the thing Darren assumes exists (and is continuing) in fact exists. This is a process issue. Dan. On 20 Jun 2002 12:48:41 EDT you wrote > Guys, can we try to avoid debating semantics. Darren said "as long as > [public] support for legacy auth in IKEv2 continues". Dan said "[protocol] > support for legacy authentication is not continuing." Both are valid uses of > the word "support". Dan, you even used both meanings in the paragraph below. > This isn't ukases. > > 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 Dan Harkins > > Sent: Thursday, June 20, 2002 11:39 AM > > To: ddukes@cisco.com > > Cc: Paul Hoffman / VPNC; Theodore Ts'o; ipsec@lists.tislabs.com > > Subject: Re: SOI QUESTIONS: 2.3 Authentication styles > > > > > > Darren, > > > > Support for legacy authentication is not continuing; it has not even > > started yet. That's what this discussion is about, determining whether > > there is support for legacy authentication. At the end of > > this discussion > > we'll know whether there is WG consensus to support legcay > > authentication. > > Some CRACK-like extension won't be added unless the WG supports it. > > > > If you feel strongly one way or the other please make your > > opinion known. > > > > Dan. > > > > On Thu, 20 Jun 2002 11:02:32 EDT you wrote > > > So Dan et al., as long as the support for legacy auth in > > IKEv2 continues > > > should we expect a CRACK-like addition to the next IKEv2 draft? > > > > > > From: Dan Harkins > > > > > > > > On Wed, 19 Jun 2002 11:25:31 PDT you wrote > > > > > > > > > > >2.3.A.) Does SOI need to natively support "legacy > > authentication > > > > > >systems"? > > > > > > > > > > As draft-ietf-ipsec-revised-identity points out, if SOI supports > > > > > preshared secrets that are not tied to IP addresses > > (that is, where > > > > > each party says what ID is associated with the > > preshared secret it is > > > > > using), legacy authentication comes for free. The only > > requirement on > > > > > the legacy authentication system is that it returns > > authentication > > > > > proof that is large enough to be broken into an ID and > > a preshared > > > > > secret, and that the preshared secret part is not > > susceptible to a > > > > > dictionary attack. > > > > > > > > That's not necessarily true. IKEv2 supports pre-shared > > key authentication > > > > but the Responder has to have access to the Initiator's secret to > > > > authenticate her. In popular remote access scenarios that > > is not the case. > > > > The secret is known by some backend server (like a RADIUS > > server) which > > > > is not part of the exchange and the Responder would only > > pass a blob off > > > > to the server and get back a yea, nea or continue. > > > > > > > > Basically a remote access solution requires that the > > Initiator present > > > > her credentials and not just prove possession of them. > > This also means > > > > that the Responder should authenticate first to establish a secure > > > > channel in which she can place them. > > > > > > > > It would be easier to graft legacy authentication support onto JFK > > > > than IKEv2 since in JFK the Responder authenticates first but it > > > > would not be hard to do it with IKEv2 either. CRACK did > > it for IKEv1 > > > > and something similar could do it with IKEv2. > > > > > > > > To answer Ted's question though I think this is > > absolutely necessary. > > > > Lots of problems with IKEv1 had to do with the fact that > > we ignored this > > > > subject and people attempted to add it in various ways > > after the fact, > > > > some more clumsily than others. That tends to work against > > > > interoperability > > > > and for single vendor solutions. > > > > > > > > We made a mistake by ignoring this the first time and it would be > > > > a mistake > > > > to do so again. PIC is not a solution to this problem. > > > > > > > > Dan. > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Jun 20 11:50:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIoln27956; Thu, 20 Jun 2002 11:50:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00940 Thu, 20 Jun 2002 14:06:57 -0400 (EDT) Message-Id: <200206201819.g5KIJaZs021503@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: "'Ari Huttunen'" , "'IP Security List'" Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? In-Reply-To: Your message of "20 Jun 2002 10:36:05 EDT." <002301c21867$cfac0310$5f76e640@ca.alcatel.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 20 Jun 2002 14:19:36 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Note that this has implications for re-keying: the responder may > > not be able to initiate re-keying if that implies re-authenticating. > > I know some gateway vendors for some reason wish to do that. > > Without a responder lifetime notify or some kind of negotiated lifetimes, > you can't control who rekeys first. Tying this together with 2.2 (PFS): You can't really be said to have forward-secrecy properties unless you have an idea of when the peer's going to destroy the last of the keying material. Note that explicit SA deletion requests are not sufficient for this, because one or both of the peers could have transient or unreliable connectivity and deletion might not be possible or might not succeed. - Bill From owner-ipsec@lists.tislabs.com Thu Jun 20 12:11:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJBHn28801; Thu, 20 Jun 2002 12:11:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01014 Thu, 20 Jun 2002 14:30:17 -0400 (EDT) Date: 20 Jun 2002 14:30:58 -0400 Message-ID: <000901c21888$9f992d30$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Bill'" Cc: "'IP Security List'" Subject: RE: SOI QUESTIONS: 2.1 Identity protection questions? 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <200206201819.g5KIJaZs021503@thunk.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Without a responder lifetime notify or some kind of > negotiated lifetimes, > > you can't control who rekeys first. > > Tying this together with 2.2 (PFS): > > You can't really be said to have forward-secrecy properties unless you > have an idea of when the peer's going to destroy the last of the > keying material. That's why I had previously suggested tying the PFS interval to the phase 2 lifetime. This gives you the best performance for fast rekeying without sacrificing PFS. As an example, let's say that you have a phase 1 with a peer that keys 3 different phase 2s. Set the phase 2 lifetime to 1 hour and the PFS interval to 1:10. 1:00 - establish phase 1 1:01 - establish first phase 2 1:02 - establish second phase 2 ------------------------------------------- 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: sommerfeld@east.sun.com [mailto:sommerfeld@east.sun.com] > Sent: Thursday, June 20, 2002 2:20 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Ari Huttunen'; 'IP Security List' > Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? > > > > > Note that this has implications for re-keying: the responder may > > > not be able to initiate re-keying if that implies > re-authenticating. > > > I know some gateway vendors for some reason wish to do that. > > > > Without a responder lifetime notify or some kind of > negotiated lifetimes, > > you can't control who rekeys first. > > Tying this together with 2.2 (PFS): > > You can't really be said to have forward-secrecy properties unless you > have an idea of when the peer's going to destroy the last of the > keying material. > > Note that explicit SA deletion requests are not sufficient for this, > because one or both of the peers could have transient or unreliable > connectivity and deletion might not be possible or might not succeed. > > - Bill > From owner-ipsec@lists.tislabs.com Thu Jun 20 12:19:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJJen29068; Thu, 20 Jun 2002 12:19:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01038 Thu, 20 Jun 2002 14:35:20 -0400 (EDT) Message-Id: <200206201848.g5KImZZs021746@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: "'Dan Harkins'" , "'Darren'" , " 'list'" Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Your message of "20 Jun 2002 13:28:06 EDT." <000301c2187f$d7c7e470$1e72788a@ca.alcatel.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 20 Jun 2002 14:48:35 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Well about 10 people have so far spoken up in favour of legacy auth. Unless > 11 people are waiting until the last minute to voice their opposition to > legacy auth, I'd say the support is there. I'd like to see a modular, GetCert/PIC-like, approach to legacy auth. - Bill From owner-ipsec@lists.tislabs.com Thu Jun 20 12:21:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJLIn29113; Thu, 20 Jun 2002 12:21:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01050 Thu, 20 Jun 2002 14:37:20 -0400 (EDT) Date: 20 Jun 2002 14:35:47 -0400 Message-ID: <000c01c21889$4bf8fbf0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Bill'" Cc: "'IP Security List'" Subject: [resend] -- RE: SOI QUESTIONS: 2.1 Identity protection questions? 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <200206201819.g5KIJaZs021503@thunk.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Without a responder lifetime notify or some kind of > negotiated lifetimes, > > you can't control who rekeys first. > > Tying this together with 2.2 (PFS): > > You can't really be said to have forward-secrecy properties unless you > have an idea of when the peer's going to destroy the last of the > keying material. That's why I had previously suggested tying the PFS interval to the phase 2 lifetime. This gives you the best performance for fast rekeying without sacrificing PFS. As an example, let's say that you have a phase 1 with a peer that keys 3 different phase 2s. Set the phase 2 lifetime to 1 hour (with a bit of jitter) and the PFS interval to 1 hour as well. 1:00 - establish phase 1 1:01 - establish first phase 2 1:02 - establish second phase 2 1:03 - establish third phase 2 1:52 - rekey first phase 2 1:54 - rekey second phase 2 1:56 - rekey third phase 2 2:00 - delete DH exponent 2:46 - rekey first phase 2 w/ PFS folded back into phase 1 [or just rekey phase 1] 6 phase 2s for the price of one DH without sacrificing PFS. 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: sommerfeld@east.sun.com [mailto:sommerfeld@east.sun.com] > Sent: Thursday, June 20, 2002 2:20 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Ari Huttunen'; 'IP Security List' > Subject: Re: SOI QUESTIONS: 2.1 Identity protection questions? > > > > > Note that this has implications for re-keying: the responder may > > > not be able to initiate re-keying if that implies > re-authenticating. > > > I know some gateway vendors for some reason wish to do that. > > > > Without a responder lifetime notify or some kind of > negotiated lifetimes, > > you can't control who rekeys first. > > Tying this together with 2.2 (PFS): > > You can't really be said to have forward-secrecy properties unless you > have an idea of when the peer's going to destroy the last of the > keying material. > > Note that explicit SA deletion requests are not sufficient for this, > because one or both of the peers could have transient or unreliable > connectivity and deletion might not be possible or might not succeed. > > - Bill > From owner-ipsec@lists.tislabs.com Thu Jun 20 12:45:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJj5n29936; Thu, 20 Jun 2002 12:45:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01176 Thu, 20 Jun 2002 15:00:44 -0400 (EDT) Message-Id: <200206201914.g5KJECZs022049@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Koning cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: replacing preshared keys In-Reply-To: Your message of "Thu, 20 Jun 2002 13:56:18 EDT." <15634.5954.4000.837554@gargle.gargle.HOWL> Reply-to: sommerfeld@east.sun.com Date: Thu, 20 Jun 2002 15:14:12 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > A LOT longer. Long enough that -- unlike preshared keys -- you cannot > enter them manually. how about either hash-of-public-key (i.e., key fingerprint) or hash-of-selfsigned-cert or as the user-visible identification blob? with truncated hashes, you can trade off security vs. ease-of-use. > True. But PK, even if all you ever use is selfsigned certs, still > needs a lot more near-incomprehensible concepts than preshared keys > do. user runs a program to generate the node key and the self-signed cert and it spits out the hash-of-key or hash-of-cert which is exchanged out of band with peers. i don't see particularly hard concepts there in terms of explaining what you have to do.. - Bill From owner-ipsec@lists.tislabs.com Thu Jun 20 12:46:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJkmn29973; Thu, 20 Jun 2002 12:46:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01162 Thu, 20 Jun 2002 14:59:43 -0400 (EDT) Message-Id: <200206201911.g5KJBXi18770@marajade.sandelman.ottawa.on.ca> To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.4 Number of crypto operations In-reply-to: Your message of "Thu, 20 Jun 2002 13:02:27 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jun 2002 15:11:32 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> 2.4 Number of crypto operations Theodore> 2.4.A) JFK requires substantially more cryptographic operations Theodore> for rekeying (two more signatures, two more signature Theodore> validations, and three more hashes). Is this a problem? More Theodore> generally, does SOI need to be able to support "fast" rekeying? That's not everything that needs to occur. I want to understand how I do authenticated Deletes. ] 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: GnuPG v1.0.7 (NetBSD) Comment: Finger me for keys iQCVAwUBPRIo4oqHRg3pndX9AQHdqgQAs31UjSdIEIP83b8uBobGo8Om4M0PjrMo V7G2XHQ+eDZ0pMy8LPXEeYeGWmPAqXnVqoU2Nc4o8o61R59ZKmEZvupVNSFXscXF GEv7TwwqvONYRT7XatoslHswaaLrkhZC/A4QkXLTdKDA3vYD8pLksc6Fpz099WiC mNWiLx/VSlg= =Bre4 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 20 12:46:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJknn29983; Thu, 20 Jun 2002 12:46:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01193 Thu, 20 Jun 2002 15:03:45 -0400 (EDT) Date: 20 Jun 2002 14:59:25 -0400 Message-ID: <000d01c2188c$99e7f980$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" , " 'list'" Subject: RE: SOI QUESTIONS: 2.4-2.6 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 V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? I think fast rekeying is a good thing, but the more important consideration is the case where we need to have multiple SAs between two peers (e.g. QoS). There is a kludge to speed this up in JFK (cache the DH and the cert verification), but you still have to do one extra RSA signature+validation. Also, it is a kludge, and kludges hardly simplify the protocol. There is also the case of dynamic selectors where you need to either create a new SA or (better) update the selectors on an existing SA. This is much faster if you already have a control channel. Finally, let us not ignore MSec. That WG has based their GDOI protocol on IKEv1, presumably with the assumption that they could migrate seamlessly to SOI. There is a high probability that many of the same devices which currently do IKE will also want to do GDOI, so it doesn't make sense to divorce the two. MSec is likely to require much more frequent rekeying than SOI, and the rekeying may be based on LKH, in which case doing an extra DH would be a complete waste of time. Fast rekeying is a MUST for MSec. > 2.5) Plausible denaibility I think plausible deniability is a "nice to have," but not a requirement. There might be some cases where you would want NR instead. However, plausible deniability appears to be easy to include in all the cryptographic cores we have seen, so I think we should do it. > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) I think formal proofs of security are highly overrated. The formal proof in JFK is basically just a bunch of hand-waving and appeals to cryptographic common knowledge. In reality, we can be confident in the base security of the protocols because the cryptographic cores use well-established techniques. The problem with formal analyses is that you only find the problems you are looking for. What happens when the problem turns out to be something unexpected (e.g. you hadn't considered DoS attacks). Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Jun 20 12:48:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJmWn00125; Thu, 20 Jun 2002 12:48:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01141 Thu, 20 Jun 2002 14:57:40 -0400 (EDT) Date: Thu, 20 Jun 2002 15:10:12 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-Reply-To: <15634.5954.4000.837554@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 Jun 2002, Paul Koning wrote: > > They migrate from distributing opaque blobs of hex digits that must be > > kept private to distributing opaque blobs of base64 digits that do not > > benefit from staying private, but it doesn't hurt them either. > > Can they tell the difference? The length is a bit longer. > > A LOT longer. Long enough that -- unlike preshared keys -- you cannot > enter them manually. Although, as has been noted before, it's quite conceivable to generate RSA keys from preshared keys in some standard, systematic way. There are two separate issues here: the bits on the wire, and the user interface. Wanting a simple shared-secret user interface doesn't mean it has to be reflected in the on-the-wire protocol. > > Everyone please repeat: PK does not require I to be useful. > > True. But PK, even if all you ever use is selfsigned certs, still > needs a lot more near-incomprehensible concepts than preshared keys > do. How many are required if all you ever use is RSA keys? (PK does not require certificates either -- they are an artifact of the "I" part.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 20 12:56:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KJuKn00242; Thu, 20 Jun 2002 12:56:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01217 Thu, 20 Jun 2002 15:07:48 -0400 (EDT) Message-Id: <200206201919.g5KJJr518875@marajade.sandelman.ottawa.on.ca> To: Paul Koning cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-reply-to: Your message of "Thu, 20 Jun 2002 13:56:18 EDT." <15634.5954.4000.837554@gargle.gargle.HOWL> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jun 2002 15:19:53 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: >> They migrate from distributing opaque blobs of hex digits that must be >> kept private to distributing opaque blobs of base64 digits that do not >> benefit from staying private, but it doesn't hurt them either. >> >> Can they tell the difference? The length is a bit longer. Paul> A LOT longer. Long enough that -- unlike preshared keys -- you Paul> cannot enter them manually. Not compared to a decent shared secret. If you want to do passwords, fine. However, since they do not need to be kept secret, you can cut and paste. For the client system, typing stuff in is not the end of the world. Here is a 1024 bit public key: AwEAAZ7PeJWDMO69GjPbXWaN0UnHnNj3lANETIAtluJbpLfVeVpRubsYTru4kYxU K999Ga/23/Aw7mZrI+wQ3uhF36Tuxw76ls3FsgJuWxqdzLxlZxM8r/lXNGUftLPk fxbTwXgsfKcqhJCfraPLFH0QhCRVN56EW3Y91YCIMMyRAHbR I wouldn't want to do that every day, but it is doable. Babble format would do an even better job. Paul> True. But PK, even if all you ever use is selfsigned certs, still Paul> needs a lot more near-incomprehensible concepts than preshared keys Paul> do. Only if you write a poor interface. ] 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: GnuPG v1.0.7 (NetBSD) Comment: Finger me for keys iQCVAwUBPRIq14qHRg3pndX9AQHuqwP/QWhev3cT8CCiMqpYUTZQSqda6oZHeUMr DYlfu4FkFiXoYx5HWuj2MUEyZzabscvgwAIXlwCdnYlMD3QjFSgSeVpXm+RoXAON ZV915lqWjHmp5CjN9wg/MxhmMVvmfjoOQROVydr16ju0o163DnsVHlrhCueU5j1a tgb5ZMzZgC0= =4x2T -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 20 14:24:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KLOvn04516; Thu, 20 Jun 2002 14:24:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01410 Thu, 20 Jun 2002 16:29:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15634.15959.402666.816813@pkoning.dev.equallogic.com> Date: Thu, 20 Jun 2002 16:43:03 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "VPNC" == VPNC writes: VPNC> At 1:04 PM -0400 6/20/02, Theodore Ts'o wrote: >> 2.6.) Does SOI need to provide a formal proof of security? (Is >> this a "must have" or a "nice to have"? What are we willing to >> trade-off for having a formal proof of security?) VPNC> In the typical VPN scenario (either gateway-to-gateway or VPNC> remote-access WAN), this is not important. It is nice to have, VPNC> of course, but only to keep ourselves happy. I disagree. The scenarios are irrelevant to this question. The point is: what level of assurance do we want that there aren't design errors in the protocol? Some people build "security" protocols that don't provide security. Some of the errors made are obvious to casual observers; some are not. It would be good for IPsec/IKE to be secure in reality. Formal analysis is part of the QA that helps confirm this property. Without it, you may still be secure, and you may have caught most bugs by informal analysis, but the level of assurance is less. So I would rate it as "very desirable". paul From owner-ipsec@lists.tislabs.com Thu Jun 20 14:39:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KLdtn04732; Thu, 20 Jun 2002 14:39:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01357 Thu, 20 Jun 2002 15:54:22 -0400 (EDT) Message-Id: <200206202007.g5KK7SZs022471@thunk.east.sun.com> From: Bill Sommerfeld To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-Reply-To: Your message of "Tue, 18 Jun 2002 18:17:14 EDT." Reply-to: sommerfeld@east.sun.com Date: Thu, 20 Jun 2002 16:07:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 2.2 Perfect forward secrecy (PFS) > > 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward > secrecy" by trading off performance versus the level of PFS provided. > The funcitonality provided is roughly identical. Does anyone care > about the details of how IKEv2 versus JFK provides this functionality? > Should we just flip a coin? I think the specs need to be clear about what the forward-secrecy guarantees are. In particular, in order to provide forward-secrecy guarantees to the users of IPsec, SA keying material needs agreed-upon "destroy-after" dates. I believe this requires protocol-visible IPsec SA and DH exchange keying material lifetimes. I don't believe a separate DH exchange is needed for each SA; I'm agnostic about whether a separate DH exponent key is required per peer; i.e., I think the IKE vs JFK differences are immaterial for this. - Bill From owner-ipsec@lists.tislabs.com Thu Jun 20 14:43:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KLhrn04791; Thu, 20 Jun 2002 14:43:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01363 Thu, 20 Jun 2002 15:57:23 -0400 (EDT) Date: Thu, 20 Jun 2002 16:10:46 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: SOI QUESTIONS: 2.4-2.6 In-Reply-To: <000d01c2188c$99e7f980$1e72788a@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 20 Jun 2002, Andrew Krywaniuk wrote: > The problem with formal analyses is that you only find the problems you are > looking for. What happens when the problem turns out to be something > unexpected (e.g. you hadn't considered DoS attacks). Real formal analyses -- formal ones, not handwaving ones -- are actually fairly good at finding problems that are implicit in the design but hard to spot. You can often prove incorrectness even if you can't prove correctness, so to speak... The problem is that they're always done by reference to a specification, so they can't find things that the specification writer didn't think of or couldn't find a way to formalize. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 20 15:43:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KMhAn05639; Thu, 20 Jun 2002 15:43:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01589 Thu, 20 Jun 2002 17:58:18 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Thu, 20 Jun 2002 17:11:25 -0500 (CDT) From: Tylor Allison X-X-Sender: To: Michael Richardson cc: Paul Koning , Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-Reply-To: <200206201919.g5KJJr518875@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 Thu, 20 Jun 2002, Michael Richardson wrote: > >>>>> "Paul" == Paul Koning writes: > >> They migrate from distributing opaque blobs of hex digits that must be > >> kept private to distributing opaque blobs of base64 digits that do not > >> benefit from staying private, but it doesn't hurt them either. > >> > >> Can they tell the difference? The length is a bit longer. > > Paul> A LOT longer. Long enough that -- unlike preshared keys -- you > Paul> cannot enter them manually. > > Not compared to a decent shared secret. If you want to do passwords, fine. > However, since they do not need to be kept secret, you can cut and paste. > For the client system, typing stuff in is not the end of the world. Here is > a 1024 bit public key: > > AwEAAZ7PeJWDMO69GjPbXWaN0UnHnNj3lANETIAtluJbpLfVeVpRubsYTru4kYxU > K999Ga/23/Aw7mZrI+wQ3uhF36Tuxw76ls3FsgJuWxqdzLxlZxM8r/lXNGUftLPk > fxbTwXgsfKcqhJCfraPLFH0QhCRVN56EW3Y91YCIMMyRAHbR > > I wouldn't want to do that every day, but it is doable. Babble format > would do an even better job. > > Paul> True. But PK, even if all you ever use is selfsigned certs, still > Paul> needs a lot more near-incomprehensible concepts than preshared keys > Paul> do. > > Only if you write a poor interface. But that's the point... it's very possible to design a bad interface for handling public keys (and innumerable ways to design a good one). Without a clear and concise mandate from this WG on the minimum requirements for PK/PKI, there will be interoperability problems (NOTE: this is not a bits-on-the-wire issue but a deployment issue).... IKEv1 should serve as an example for that! The same really can't be said for pre-shared keys... they are simple, straight-forward, and almost guaranteed to interoperate between any two vendors. Why throw it away? > ] 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"); [ ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Thu Jun 20 15:44:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KMiVn05675; Thu, 20 Jun 2002 15:44:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01606 Thu, 20 Jun 2002 18:03:17 -0400 (EDT) Date: 20 Jun 2002 18:03:14 -0400 Message-ID: <001401c218a6$47a2e210$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Richardson'" , " 'Paul Koning'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <200206201919.g5KJJr518875@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >> Can they tell the difference? The length is a bit longer. > > Paul> A LOT longer. Long enough that -- unlike preshared > keys -- you > Paul> cannot enter them manually. > > Not compared to a decent shared secret. We're talking factor of 10 here. Let's say someone impersonates the responder and gets an HMAC keyed with your password. How many bits of entropy do you need to feel secure? 80? 90? Remember that we normally truncate HMACs at 96 bits anyway. Passwords don't need 20 year effective security. For good token-based auth where the password is time-based, I would feel secure with 20 bits of entropy. That's a factor of 50 compared to a public key. 20-40 bits is very easy to type in, and I do it every day. 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 Michael Richardson > Sent: Thursday, June 20, 2002 3:20 PM > To: Paul Koning > Cc: ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Paul" == Paul Koning writes: > >> They migrate from distributing opaque blobs of hex > digits that must be > >> kept private to distributing opaque blobs of base64 > digits that do not > >> benefit from staying private, but it doesn't hurt them either. > >> > >> Can they tell the difference? The length is a bit longer. > > Paul> A LOT longer. Long enough that -- unlike preshared > keys -- you > Paul> cannot enter them manually. > > Not compared to a decent shared secret. If you want to do > passwords, fine. > However, since they do not need to be kept secret, you can > cut and paste. > For the client system, typing stuff in is not the end of the > world. Here is > a 1024 bit public key: > > > AwEAAZ7PeJWDMO69GjPbXWaN0UnHnNj3lANETIAtluJbpLfVeVpRubsYTru4kYxU > > K999Ga/23/Aw7mZrI+wQ3uhF36Tuxw76ls3FsgJuWxqdzLxlZxM8r/lXNGUftLPk > fxbTwXgsfKcqhJCfraPLFH0QhCRVN56EW3Y91YCIMMyRAHbR > > I wouldn't want to do that every day, but it is doable. Babble format > would do an even better job. > > Paul> True. But PK, even if all you ever use is > selfsigned certs, still > Paul> needs a lot more near-incomprehensible concepts > than preshared keys > Paul> do. > > Only if you write a poor interface. > > ] 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: GnuPG v1.0.7 (NetBSD) > Comment: Finger me for keys > > iQCVAwUBPRIq14qHRg3pndX9AQHuqwP/QWhev3cT8CCiMqpYUTZQSqda6oZHeUMr > DYlfu4FkFiXoYx5HWuj2MUEyZzabscvgwAIXlwCdnYlMD3QjFSgSeVpXm+RoXAON > ZV915lqWjHmp5CjN9wg/MxhmMVvmfjoOQROVydr16ju0o163DnsVHlrhCueU5j1a > tgb5ZMzZgC0= > =4x2T > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Thu Jun 20 16:17:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KNH1n06265; Thu, 20 Jun 2002 16:17:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01688 Thu, 20 Jun 2002 18:30:28 -0400 (EDT) Date: 20 Jun 2002 18:31:07 -0400 Message-ID: <001501c218aa$2cb19e20$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'IP Security List'" Subject: PFS + rekeying interconnection 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <000c01c21889$4bf8fbf0$1e72788a@ca.alcatel.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 1:00 - establish phase 1 > 1:01 - establish first phase 2 > 1:02 - establish second phase 2 > 1:03 - establish third phase 2 > 1:52 - rekey first phase 2 > 1:54 - rekey second phase 2 > 1:56 - rekey third phase 2 > 2:00 - delete DH exponent > 2:46 - rekey first phase 2 w/ PFS folded back into phase 1 > [or just rekey > phase 1] I had a few requests to clarify some aspects of this timeline. > 2:00 - delete DH exponent It's not the DH exponent that matters here, it's SKEYID_d. You can delete the DH exponent at 1:01 if you wish. Sorry about being unclear. > 2) how long do you retain keys derived from the shared secret (one way > hash of the DH-generated secret). For upto the PFS interval. The key here is to assume that the PRF is not reversable. > 1:00 - establish phase 1 > 1:52 - rekey first phase 2 > 2:00 - delete DH exponent If someone breaks into your box at 1:59, they can get key1 and key2 and SKEYID_d, but your PFS interval hasn't elapsed yet so only 1 hour's worth of data is compromised. If someone breaks into your box at 2:01, they can only get key2, which has only been used for 9 minutes. You can continue to use key 2 up until 2:52 without violating your PFS interval. > 3) how long after the declared expiration time do you keep the SA > alive to catch stragglers. I assume that you delete the SA as soon as it expires. To avoid stragglers, you rekey in advance. > > 6 phase 2s for the price of one DH without sacrificing PFS. > > admittedly the long-term steady-state here will be more like 3 phase > 2's per DH It depends. If your jitter is completely random then the phase 2s will eventually end up being distributed randomly through the timeline and you will get 4 phase 2s per DH steady state. If you tweak the jitter so the rekeys are distributed within a fixed window then you can get 6 rekeys per DH steady state. > All the phase 2 sessions may not fall in the same > intervel. In you example all the phase 2 connections > are started approximatetly at same time. In normal > case the sessions are distributed evenly in the > intervel. Let me know if I am missing anything ... > 2:00 - delete DH exponent > 2:46 - rekey first phase 2 w/ PFS folded back into phase 1 In the example above, the host had no SKEYID_d for 46 minutes. If you needed to negotiate an SA earlier than that, you would negotiate a new key sometime between 2:00 and 2:46. As I mentioned above, this might result in you getting 4 SAs per DH rather than 6. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Jun 20 16:21:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KNLEn06577; Thu, 20 Jun 2002 16:21:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01708 Thu, 20 Jun 2002 18:40:22 -0400 (EDT) Date: Thu, 20 Jun 2002 18:53:28 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) 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, 20 Jun 2002, Tylor Allison wrote: > ...Without > a clear and concise mandate from this WG on the minimum requirements for > PK/PKI, there will be interoperability problems... Yes, and this is a problem... why, exactly? This just means that such a solution must include such a clear and concise specification of how to proceed. That doesn't seem contrary to the laws of physics; surely it can be done. > ...The same really can't be said for pre-shared keys... > they are simple, straight-forward, and almost guaranteed to interoperate > between any two vendors. Why throw it away? Because there is a price, one that may not be worth paying. I would be happier about adding/retaining a second authentication scheme if it paid for itself in some other way too, e.g. the suggestion that a well-designed shared-secret authentication scheme could also handle most of the legacy-authentication problem. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 20 17:44:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L0iWn03307; Thu, 20 Jun 2002 17:44:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01799 Thu, 20 Jun 2002 19:55:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 20 Jun 2002 19:58:38 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.5 Plausible denaibility Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:03 PM -0400 6/20/02, Theodore Ts'o wrote: >Please discuss and answer this question..... (for more discussion and a >clear definition of "plausible denaibility", please see section 2.5 of >the soi-features I-D). > >2.5) Plausible denaibility > >2.5.A) Does SOI need to provide "plausible deniability" (the opposite >of "non-repudiation") for the initiator? > > >2.5.B) Does SOI need to provide "plausible deniability" (the opposite >of "non-repudiation") for the responder? IPsec has never advertised NR as a service, and the only issue here is whether signed authentication could be used to "prove" that a connection was established between two parties. I don't think it worthwhile to focus significant design effort, or to add complexity to SOI to support this "feature." Steve From owner-ipsec@lists.tislabs.com Thu Jun 20 17:46:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L0kNn03875; Thu, 20 Jun 2002 17:46:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01805 Thu, 20 Jun 2002 19:56:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 20 Jun 2002 19:47:15 -0400 To: Henry Spencer From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:06 PM -0400 6/20/02, Henry Spencer wrote: >On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote: >> I really don't understand the reasoning behing IPsec trying to mandate a >> minimal useless 'static packet filtering'. The problem of access control >> and intrusion detection, as far as I can see belongs in the firewall >> functionality. > >IPsec, being about IP *security*, not just IP encryption and authentication, >includes a specification for minimal firewall functionality, since that is >a necessary part of secure IP. Implementations are, of course, free to >provide more sophisticated firewall mechanisms, and to implement the IPsec- >mandated functionality using that more sophisticated mechanism. > >(I have long thought it a mistake that RFC 2401 does not explicitly say >something like the previous paragraph. It's important, and people often >overlook it or misunderstand it.) Henry, I will put words to this effect in 2401 bis, to help clarify this matter. Mind if I use yours, with an acknowledgement? Steve From owner-ipsec@lists.tislabs.com Thu Jun 20 17:46:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L0kwn04055; Thu, 20 Jun 2002 17:46:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01798 Thu, 20 Jun 2002 19:55:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 20 Jun 2002 19:57:15 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:41 AM -0700 6/20/02, Chinna N.R. Pellacuru wrote: >I really don't understand the reasoning behing IPsec trying to mandate a >minimal useless 'static packet filtering'. The problem of access control >and intrusion detection, as far as I can see belongs in the firewall >functionality. ID is not an aspect of IPsec, so the above statement is either confused, or confusing, your choice. Also, as I noted, ID is not intrinsically a firewall function. For example, people often want a network-based ID capability that focuses on traffic inside the enterprise network, to catch attacks launched from machines inside the firewall, as well as attacks via the firewall path. >The philosophy that if I am not having a problem, in my implementation, >and if you are having a problem in your implementation and deployment, >then it is probably an implemetation defect, rather than a larger problem, >is a recurring theme in this WG. I guess the assumption is that all IPsec >implemetations are being deployed in exactly the same way that your >implementation is being deployed/not deployed. what I think you have heard is that other folks are NOT having a problem with putting access control features in their IPsec products, even when those products have other firewall functionality, and that this suggests that maybe the fault lies in YOUR implementation (to paraphrase Shakespeare.) >We have seen it a lot for a very very long time WRT IKE. Now for some >reason the IKE fort was brought down (kink?), and we are actually >discussing a successor to IKE after a long period of denial, and >accusations and flaming. > >I hope the RFC 2401 fort also comes down sometime in the near future, and >there is some acknowlegement to practical problems and deployment >headaches. Don't hold your breath waiting for the access control features to be pulled from 2401. No, on second thought, please do hold YOUR breath. Steve From owner-ipsec@lists.tislabs.com Thu Jun 20 17:49:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L0nTn04797; Thu, 20 Jun 2002 17:49:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01797 Thu, 20 Jun 2002 19:55:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 20 Jun 2002 19:38:40 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:06 AM -0700 6/20/02, Chinna N.R. Pellacuru wrote: >On Thu, 20 Jun 2002, Paul Koning wrote: > >> Excerpt of message (sent 19 June 2002) by Chinna N.R. Pellacuru: >> > As I saw it, a minority of implementors who build high end security >> > gateways, complained about not just the value of minimal access control in >> > IPsec, but also about the inefficiency of doing this in IPsec and having >> > to do it in the firewall feature processing anyway (because firewall >> > provides extensive and true access control and intrution detection). >> >> As one who worked on a product that arguably fits in this category, >> I'd have to disagree. There certainly is overlap between the >> classification processes done in IPsec, in firewalls, in traffic >> managers, and so on. That doesn't mean things have to be >> inefficient. Instead, it means you have the opportunity to provide >> all three functions through a single classification step. That >> requires more care in implementation, but it certainly is possible. >> >> paul >> > >Because we do the packet classification once, we test the result in >multiple places and that is not inefficient. Someone has to sync the >policies of all these modules so that the policies of all the modules play >nicely with every other module that does the exact same functionality. I >think these assumptions are lacking practical experience and large scale >deployment headaches. > > chinna Your response sounds like a characterization of problems you face due to your implementation choices. Paul's response suggests that other implementation choices do not suffer as a result, and may benefit. I rest my case. Steve From owner-ipsec@lists.tislabs.com Thu Jun 20 19:11:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L2B2n29467; Thu, 20 Jun 2002 19:11:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01965 Thu, 20 Jun 2002 21:06:43 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Thu Jun 20 20:58:33 2002 Message-Id: <200206201911.g5KJBXi18770@marajade.sandelman.ottawa.on.ca> To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.4 Number of crypto operations In-reply-to: Your message of "Thu, 20 Jun 2002 13:02:27 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jun 2002 15:11:32 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> 2.4 Number of crypto operations Theodore> 2.4.A) JFK requires substantially more cryptographic operations Theodore> for rekeying (two more signatures, two more signature Theodore> validations, and three more hashes). Is this a problem? More Theodore> generally, does SOI need to be able to support "fast" rekeying? That's not everything that needs to occur. I want to understand how I do authenticated Deletes. ] 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: GnuPG v1.0.7 (NetBSD) Comment: Finger me for keys iQCVAwUBPRIo4oqHRg3pndX9AQHdqgQAs31UjSdIEIP83b8uBobGo8Om4M0PjrMo V7G2XHQ+eDZ0pMy8LPXEeYeGWmPAqXnVqoU2Nc4o8o61R59ZKmEZvupVNSFXscXF GEv7TwwqvONYRT7XatoslHswaaLrkhZC/A4QkXLTdKDA3vYD8pLksc6Fpz099WiC mNWiLx/VSlg= =Bre4 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 20 19:17:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L2Hpn01893; Thu, 20 Jun 2002 19:17:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02020 Thu, 20 Jun 2002 21:35:47 -0400 (EDT) Date: Thu, 20 Jun 2002 18:49:10 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk minimal 'static packet filtering' in IPsec is useless. chinna On Thu, 20 Jun 2002, Stephen Kent wrote: > At 10:41 AM -0700 6/20/02, Chinna N.R. Pellacuru wrote: > >I really don't understand the reasoning behing IPsec trying to mandate a > >minimal useless 'static packet filtering'. The problem of access control > >and intrusion detection, as far as I can see belongs in the firewall > >functionality. > > ID is not an aspect of IPsec, so the above statement is either > confused, or confusing, your choice. Also, as I noted, ID is not > intrinsically a firewall function. For example, people often want a > network-based ID capability that focuses on traffic inside the > enterprise network, to catch attacks launched from machines inside > the firewall, as well as attacks via the firewall path. > > >The philosophy that if I am not having a problem, in my implementation, > >and if you are having a problem in your implementation and deployment, > >then it is probably an implemetation defect, rather than a larger problem, > >is a recurring theme in this WG. I guess the assumption is that all IPsec > >implemetations are being deployed in exactly the same way that your > >implementation is being deployed/not deployed. > > what I think you have heard is that other folks are NOT having a > problem with putting access control features in their IPsec products, > even when those products have other firewall functionality, and that > this suggests that maybe the fault lies in YOUR implementation (to > paraphrase Shakespeare.) > > >We have seen it a lot for a very very long time WRT IKE. Now for some > >reason the IKE fort was brought down (kink?), and we are actually > >discussing a successor to IKE after a long period of denial, and > >accusations and flaming. > > > >I hope the RFC 2401 fort also comes down sometime in the near future, and > >there is some acknowlegement to practical problems and deployment > >headaches. > > Don't hold your breath waiting for the access control features to be > pulled from 2401. > > No, on second thought, please do hold YOUR breath. > > Steve > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Thu Jun 20 19:20:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L2KKn02649; Thu, 20 Jun 2002 19:20:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02019 Thu, 20 Jun 2002 21:35:46 -0400 (EDT) Date: Thu, 20 Jun 2002 18:48:20 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is not a problem it is an inefficiency. chinna On Thu, 20 Jun 2002, Stephen Kent wrote: > At 9:06 AM -0700 6/20/02, Chinna N.R. Pellacuru wrote: > >On Thu, 20 Jun 2002, Paul Koning wrote: > > > >> Excerpt of message (sent 19 June 2002) by Chinna N.R. Pellacuru: > >> > As I saw it, a minority of implementors who build high end security > >> > gateways, complained about not just the value of minimal access control in > >> > IPsec, but also about the inefficiency of doing this in IPsec and having > >> > to do it in the firewall feature processing anyway (because firewall > >> > provides extensive and true access control and intrution detection). > >> > >> As one who worked on a product that arguably fits in this category, > >> I'd have to disagree. There certainly is overlap between the > >> classification processes done in IPsec, in firewalls, in traffic > >> managers, and so on. That doesn't mean things have to be > >> inefficient. Instead, it means you have the opportunity to provide > >> all three functions through a single classification step. That > >> requires more care in implementation, but it certainly is possible. > >> > >> paul > >> > > > >Because we do the packet classification once, we test the result in > >multiple places and that is not inefficient. Someone has to sync the > >policies of all these modules so that the policies of all the modules play > >nicely with every other module that does the exact same functionality. I > >think these assumptions are lacking practical experience and large scale > >deployment headaches. > > > > chinna > > Your response sounds like a characterization of problems you face due > to your implementation choices. Paul's response suggests that other > implementation choices do not suffer as a result, and may benefit. > > I rest my case. > > Steve > > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Thu Jun 20 19:36:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L2aUn07512; Thu, 20 Jun 2002 19:36:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02061 Thu, 20 Jun 2002 21:52:49 -0400 (EDT) Date: Thu, 20 Jun 2002 19:06:04 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unless that is your standard of security! chinna On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > minimal 'static packet filtering' in IPsec is useless. > > chinna > > On Thu, 20 Jun 2002, Stephen Kent wrote: > > > At 10:41 AM -0700 6/20/02, Chinna N.R. Pellacuru wrote: > > >I really don't understand the reasoning behing IPsec trying to mandate a > > >minimal useless 'static packet filtering'. The problem of access control > > >and intrusion detection, as far as I can see belongs in the firewall > > >functionality. > > > > ID is not an aspect of IPsec, so the above statement is either > > confused, or confusing, your choice. Also, as I noted, ID is not > > intrinsically a firewall function. For example, people often want a > > network-based ID capability that focuses on traffic inside the > > enterprise network, to catch attacks launched from machines inside > > the firewall, as well as attacks via the firewall path. > > > > >The philosophy that if I am not having a problem, in my implementation, > > >and if you are having a problem in your implementation and deployment, > > >then it is probably an implemetation defect, rather than a larger problem, > > >is a recurring theme in this WG. I guess the assumption is that all IPsec > > >implemetations are being deployed in exactly the same way that your > > >implementation is being deployed/not deployed. > > > > what I think you have heard is that other folks are NOT having a > > problem with putting access control features in their IPsec products, > > even when those products have other firewall functionality, and that > > this suggests that maybe the fault lies in YOUR implementation (to > > paraphrase Shakespeare.) > > > > >We have seen it a lot for a very very long time WRT IKE. Now for some > > >reason the IKE fort was brought down (kink?), and we are actually > > >discussing a successor to IKE after a long period of denial, and > > >accusations and flaming. > > > > > >I hope the RFC 2401 fort also comes down sometime in the near future, and > > >there is some acknowlegement to practical problems and deployment > > >headaches. > > > > Don't hold your breath waiting for the access control features to be > > pulled from 2401. > > > > No, on second thought, please do hold YOUR breath. > > > > Steve > > > > __ > chinna narasimha reddy pellacuru > "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, > it is the repudiation of moral equivalence." > > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Thu Jun 20 20:47:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L3lOn01021; Thu, 20 Jun 2002 20:47:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02180 Thu, 20 Jun 2002 23:01:03 -0400 (EDT) Date: Thu, 20 Jun 2002 23:13:33 -0400 (EDT) From: Henry Spencer To: Stephen Kent cc: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles 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, 20 Jun 2002, Stephen Kent wrote: > >IPsec, being about IP *security*... > > I will put words to this effect in 2401 bis, to help clarify this > matter. Mind if I use yours, with an acknowledgement? By all means go ahead, if you think they fit well. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 20 20:47:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L3lOn01025; Thu, 20 Jun 2002 20:47:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02192 Thu, 20 Jun 2002 23:07:02 -0400 (EDT) Date: Thu, 20 Jun 2002 23:19:55 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles 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, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > It is not a problem it is an inefficiency. An inefficiency in your implementation, not in IPsec. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 20 21:08:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L48tn07565; Thu, 20 Jun 2002 21:08:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02216 Thu, 20 Jun 2002 23:25:12 -0400 (EDT) Message-Id: <200206210337.g5L3bln23920@marajade.sandelman.ottawa.on.ca> To: Tylor Allison cc: Paul Koning , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) In-reply-to: Your message of "Thu, 20 Jun 2002 17:11:25 CDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jun 2002 23:37:46 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tylor" == Tylor Allison writes: Tylor> But that's the point... it's very possible to design a bad Tylor> interface for handling public keys (and innumerable ways to design Tylor> a good one). Without a clear and concise mandate from this WG on Tylor> the minimum requirements for PK/PKI, there will be Tylor> interoperability problems (NOTE: this is not a bits-on-the-wire Tylor> issue but a deployment issue).... IKEv1 should serve as an example Tylor> for that! The same really can't be said for pre-shared keys... Tylor> they are simple, straight-forward, and almost guaranteed to Tylor> interoperate between any two vendors. Why throw it away? You'd think so, wouldn't you, yet I've seen some pretty bad interfaces. No, the only reason why the pre-shared key interface was simple was because developers used it for testing. They never used PKI stuff except at bakeoffs, because few *developers* know how to setup the PKI stuff, let alone have a budget to buy a copy of something with a manual. ] 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 Thu Jun 20 21:21:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L4L3n11266; Thu, 20 Jun 2002 21:21:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02231 Thu, 20 Jun 2002 23:31:12 -0400 (EDT) Date: Thu, 20 Jun 2002 20:44:02 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Henry Spencer cc: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Not an inefficiency if you don't run a firewall in your implementation, and your standard of security is only what is provided by a 'static packet filter'. We call that ACL functionality, not even a firewall functionality. chinna On Thu, 20 Jun 2002, Henry Spencer wrote: > On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > > It is not a problem it is an inefficiency. > > An inefficiency in your implementation, not in IPsec. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Thu Jun 20 21:28:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L4SGn13408; Thu, 20 Jun 2002 21:28:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02276 Thu, 20 Jun 2002 23:48:18 -0400 (EDT) Message-ID: <011201c218d8$4a3b2d70$95f4220a@amer.cisco.com> From: "Scott Fanning" To: "Tylor Allison" , "Michael Richardson" Cc: "Paul Koning" , References: <200206210337.g5L3bln23920@marajade.sandelman.ottawa.on.ca> Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) Date: Thu, 20 Jun 2002 21:01:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alot of times, its just the user community not understanding how a PKI (or even PK) works. IKE/IPsec should not be targeted for the knowledgeable user, but also for those who know they need security, but want it easy (SOHO environments come to mind). The "Super-duper secret password" is easy to figure out. If we can support PSK (which is my vote) and PKI (or just PK), then as the user becomes more comfortable with the technology, then the move to PKI will be a less painful one (if the CA vendors make their CAs easy to use). I like the MUST for PK and a SHOULD for PSK. Maybe Dan can re-publish his PSK draft again :-) As for PFS, if its there, it has to be negotiated. I would prefer that it be optional so that the widest possible platforms can support IKE/IPsec (CPU constraints, memory etc). I think these kind of discussions (which in most cases seem quite focused) is very useful. Keep those cards and letter coming :-) Regards Scott ----- Original Message ----- From: "Michael Richardson" To: "Tylor Allison" Cc: "Paul Koning" ; Sent: Thursday, June 20, 2002 8:37 PM Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) > > >>>>> "Tylor" == Tylor Allison writes: > Tylor> But that's the point... it's very possible to design a bad > Tylor> interface for handling public keys (and innumerable ways to design > Tylor> a good one). Without a clear and concise mandate from this WG on > Tylor> the minimum requirements for PK/PKI, there will be > Tylor> interoperability problems (NOTE: this is not a bits-on-the-wire > Tylor> issue but a deployment issue).... IKEv1 should serve as an example > Tylor> for that! The same really can't be said for pre-shared keys... > Tylor> they are simple, straight-forward, and almost guaranteed to > Tylor> interoperate between any two vendors. Why throw it away? > > You'd think so, wouldn't you, yet I've seen some pretty bad interfaces. > > No, the only reason why the pre-shared key interface was simple was because > developers used it for testing. They never used PKI stuff except at bakeoffs, > because few *developers* know how to setup the PKI stuff, let alone have > a budget to buy a copy of something with a manual. > > ] 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 Thu Jun 20 22:42:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L5g2n04252; Thu, 20 Jun 2002 22:42:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02378 Fri, 21 Jun 2002 00:59:25 -0400 (EDT) Date: Fri, 21 Jun 2002 01:12:03 -0400 From: Ran Canetti Message-Id: <200206210512.BAA31720@ornavella.watson.ibm.com> To: allison@securecomputing.com, mcr@sandelman.ottawa.on.ca, sfanning@cisco.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) Cc: ipsec@lists.tislabs.com, pkoning@equallogic.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Not necessarily. In JFK each party locally tunes its own PFS interval (from full session-by-session PFS to no PFS at all), independently of the other side, and without need for negotiation. (You can mandate that a party reveals its PFS policy to the peer, so that the peer will be able to make its respective policy decisions. But this is not necessary for interoperability.) The same can be done with IKEv2, with the exception of the question whether the phase 2 exchange should support PFS. This seems to require negotiation. (Please correct me if I'm wrong here.) Ran > From: "Scott Fanning" > > As for PFS, if its there, it has to be negotiated. I would prefer that it be > optional so that the widest possible platforms can support IKE/IPsec (CPU > constraints, memory etc). > From owner-ipsec@lists.tislabs.com Thu Jun 20 22:42:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L5g2n04251; Thu, 20 Jun 2002 22:42:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02372 Fri, 21 Jun 2002 00:57:24 -0400 (EDT) Date: Thu, 20 Jun 2002 22:10:24 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Henry Spencer cc: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk By IPsec I mean in the context of RFC 2401. In any design review, this minimal 'static packet filtering' is brought up as a mandatory requirement of "IPsec", and the rest of the folks who don't know IPsec intimately, start scratching their heads, and generally ask WHY?, and we generally say, it is mandatory, just don't ask why. We just play the RFC 2401 card, just like it is done so efficiently in this forum, without answering why it is required. chinna On Thu, 20 Jun 2002, Henry Spencer wrote: > On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > > ...is much better than saying that IPsec mandates this minimal > > 'static packet filtering' and everyone has to do it in IPsec. > > What does it mean to do something "in IPsec"? IPsec is a set of > protocols, not a hardware box or a software module. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Thu Jun 20 23:48:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L6mrn04335; Thu, 20 Jun 2002 23:48:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA02496 Fri, 21 Jun 2002 02:04:36 -0400 (EDT) Reply-To: From: "Rajesh Mohan" To: , "'IP Security List'" Subject: RE: PFS + rekeying interconnection Date: Fri, 21 Jun 2002 11:47:01 +0530 Message-Id: <001e01c218eb$42344c20$7b06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001501c218aa$2cb19e20$1e72788a@ca.alcatel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would like to know what PFS in Ikev2 tries to acheive. Option 1: When a key is compromised, then the data send in that PFS interval is compromised. Data send during previous interval is safe. It seems to me that this can be achieved by having Phase 2 lifetime less than PFS Interval and Phase 1 lifetime equal to PFS interval. In this case, we do not need PFS in IKEv2. Option 2: When Phase 1 SA's SKEYID_d is compromised, this does not mean that Phase 2 keys are compromised. If we want this, then PFS is required. -Rajesh M -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk Sent: Friday, June 21, 2002 4:01 AM To: 'IP Security List' Subject: PFS + rekeying interconnection > 1:00 - establish phase 1 > 1:01 - establish first phase 2 > 1:02 - establish second phase 2 > 1:03 - establish third phase 2 > 1:52 - rekey first phase 2 > 1:54 - rekey second phase 2 > 1:56 - rekey third phase 2 > 2:00 - delete DH exponent > 2:46 - rekey first phase 2 w/ PFS folded back into phase 1 > [or just rekey > phase 1] I had a few requests to clarify some aspects of this timeline. > 2:00 - delete DH exponent It's not the DH exponent that matters here, it's SKEYID_d. You can delete the DH exponent at 1:01 if you wish. Sorry about being unclear. > 2) how long do you retain keys derived from the shared secret (one way > hash of the DH-generated secret). For upto the PFS interval. The key here is to assume that the PRF is not reversable. > 1:00 - establish phase 1 > 1:52 - rekey first phase 2 > 2:00 - delete DH exponent If someone breaks into your box at 1:59, they can get key1 and key2 and SKEYID_d, but your PFS interval hasn't elapsed yet so only 1 hour's worth of data is compromised. If someone breaks into your box at 2:01, they can only get key2, which has only been used for 9 minutes. You can continue to use key 2 up until 2:52 without violating your PFS interval. > 3) how long after the declared expiration time do you keep the SA > alive to catch stragglers. I assume that you delete the SA as soon as it expires. To avoid stragglers, you rekey in advance. > > 6 phase 2s for the price of one DH without sacrificing PFS. > > admittedly the long-term steady-state here will be more like 3 phase > 2's per DH It depends. If your jitter is completely random then the phase 2s will eventually end up being distributed randomly through the timeline and you will get 4 phase 2s per DH steady state. If you tweak the jitter so the rekeys are distributed within a fixed window then you can get 6 rekeys per DH steady state. > All the phase 2 sessions may not fall in the same > intervel. In you example all the phase 2 connections > are started approximatetly at same time. In normal > case the sessions are distributed evenly in the > intervel. Let me know if I am missing anything ... > 2:00 - delete DH exponent > 2:46 - rekey first phase 2 w/ PFS folded back into phase 1 In the example above, the host had no SKEYID_d for 46 minutes. If you needed to negotiate an SA earlier than that, you would negotiate a new key sometime between 2:00 and 2:46. As I mentioned above, this might result in you getting 4 SAs per DH rather than 6. 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. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ipsec@lists.tislabs.com Fri Jun 21 00:36:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L7amn25350; Fri, 21 Jun 2002 00:36:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA02608 Fri, 21 Jun 2002 02:56:48 -0400 (EDT) Date: Fri, 21 Jun 2002 09:09:44 +0200 (MET DST) Message-Id: <200206210709.JAA17279@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.4 Number of crypto operations In-Reply-To: References: Organization: =?UTF-8?B?RA==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 Jun 2002 13:02:27 -0400 "Theodore Ts'o" wrote: > > Please discuss and answer this question..... > > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? What is the purpose of "fast" rekeying ? Is the expense of more cryptographic operations significant for the use of the protocol ? How fast should it be to support msec' GDOI ? Can rekeying operations be used in dos/ddos actions ? I don't know if this point is a priority. Let's say it should be as fast as possible, considering that some other requirements may have priority on it. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Fri Jun 21 01:01:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L81vn08641; Fri, 21 Jun 2002 01:01:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02682 Fri, 21 Jun 2002 03:13:48 -0400 (EDT) Date: Fri, 21 Jun 2002 09:26:34 +0200 (MET DST) Message-Id: <200206210726.JAA17380@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.5 Plausible denaibility In-Reply-To: References: Organization: =?UTF-8?B?RGFubmluZw==?= folder (IETF/IPsec)... X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > 2.5.A) Does SOI need to provide "plausible deniability" (the opposite > of "non-repudiation") for the initiator? > > 2.5.B) Does SOI need to provide "plausible deniability" (the opposite > of "non-repudiation") for the responder? This nice feature does no worth the expense it involves. Current SOI should not become a way of doing a kind of network diplomacy/politics. May be for the next really-in-the-future generation IKEvN (N>=3) ? -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Fri Jun 21 01:08:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5L88gn12194; Fri, 21 Jun 2002 01:08:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02708 Fri, 21 Jun 2002 03:24:50 -0400 (EDT) Date: Fri, 21 Jun 2002 09:37:34 +0200 (MET DST) Message-Id: <200206210737.JAA17440@hugo.int-evry.fr> From: Jean-Jacques Puig To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security In-Reply-To: References: Organization: =?UTF-8?B?RA==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Theodore Ts'o" wrote: > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) It is strongly nice to have, for the protocol of course, but also for its advertizing. It will have some trade-off though. Of which ones were you thinking about ? -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Fri Jun 21 05:11:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LCBZn25954; Fri, 21 Jun 2002 05:11:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03069 Fri, 21 Jun 2002 07:30:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 21 Jun 2002 07:39:50 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:06 PM -0700 6/20/02, Chinna N.R. Pellacuru wrote: >Unless that is your standard of security! > > chinna > >On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > >> minimal 'static packet filtering' in IPsec is useless. >> > > chinna >> repetition of value judgements without substantiation, as above, is useless Steve From owner-ipsec@lists.tislabs.com Fri Jun 21 05:20:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LCKVn26091; Fri, 21 Jun 2002 05:20:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03075 Fri, 21 Jun 2002 07:31:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 21 Jun 2002 07:42:29 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: Henry Spencer , IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:44 PM -0700 6/20/02, Chinna N.R. Pellacuru wrote: >Not an inefficiency if you don't run a firewall in your implementation, >and your standard of security is only what is provided by a 'static packet >filter'. We call that ACL functionality, not even a firewall >functionality. > > chinna > The term "ACL" is well understood in the information security literature for over 30 years. It is quaint that Cisco (I assume the "we" above) has adopted that term for a particilaur functionality in their products, but Cisco's effective monopoly status in the router product arena does not confer and special status on the neologistic use of the term. Steve From owner-ipsec@lists.tislabs.com Fri Jun 21 06:55:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LDtMn28384; Fri, 21 Jun 2002 06:55:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03273 Fri, 21 Jun 2002 09:11:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15635.10528.437987.508586@pkoning.dev.equallogic.com> Date: Fri, 21 Jun 2002 09:24:48 -0400 From: Paul Koning To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.5 Plausible denaibility References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Theodore" == Theodore Ts'o writes: Theodore> Please discuss and answer this question..... (for more Theodore> discussion and a clear definition of "plausible Theodore> denaibility", please see section 2.5 of the soi-features Theodore> I-D). Theodore> 2.5) Plausible denaibility Theodore> 2.5.A) Does SOI need to provide "plausible deniability" Theodore> (the opposite of "non-repudiation") for the initiator? Theodore> 2.5.B) Does SOI need to provide "plausible deniability" Theodore> (the opposite of "non-repudiation") for the responder? No. (As for discussion, I'm not sure what there is to discuss. Perhaps "what conceivable purpose would it serve?") paul From owner-ipsec@lists.tislabs.com Fri Jun 21 06:55:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LDtMn28386; Fri, 21 Jun 2002 06:55:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03255 Fri, 21 Jun 2002 09:07:23 -0400 (EDT) Message-ID: <3D13287C.1AC9DF25@F-Secure.com> Date: Fri, 21 Jun 2002 16:22:04 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) References: <200206201516.g5KFGLt16060@marajade.sandelman.ottawa.on.ca> <15634.5954.4000.837554@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2002 13:22:07.0197 (UTC) FILETIME=[A41338D0:01C21926] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > Excerpt of message (sent 20 June 2002) by Michael Richardson: > > Tylor> Many customers have deployed with pre-shared key authentication > > Tylor> ... will > > Tylor> these customers roll to IKEv2 if this authentication is not > > Tylor> supported? > > Tylor> What is their migration path? > > > > They migrate from distributing opaque blobs of hex digits that must be > > kept private to distributing opaque blobs of base64 digits that do not > > benefit from staying private, but it doesn't hurt them either. > > > > Can they tell the difference? The length is a bit longer. > > A LOT longer. Long enough that -- unlike preshared keys -- you cannot > enter them manually. Why not just make a hash of the public key of the peer and compare it with the hash that's defined by the user? (The probability of generating two PK key pairs with public keys that hash to the same value must be low? Maybe you could even get along by reducing the hash length?) Of course SOI will need to send the public key on-the-wire for this to work. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Fri Jun 21 06:55:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LDtNn28391; Fri, 21 Jun 2002 06:55:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03274 Fri, 21 Jun 2002 09:11:27 -0400 (EDT) Reply-To: From: "Darren Dukes" To: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.3 Authentication styles Date: Fri, 21 Jun 2002 09:24:17 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? Absolutely. I don't believe PIC will be acceptable after customers have become used to XAUTH with IKEv1. NOTE: I'm not suggesting XAUTHv2 be written, rather IKEv2 must provide the functionality (maybe CRACK?) so XAUTHv2 is not written. > > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) Short answer: No but MUST support native legacy authentication if shared secrets don't exist. Long answer: The goal should be to provide a mechanism with the simplicity of shared secrets. Self-signed certificates do not provide all the simplicity of a shared secret but I can't think of anything that comes closer. For LAN-LAN VPN self-signed certs would likely suffice since the peers are relatively static so cert distribution could be minimal and simple (if well specified and implemented). For Remote Access VPN the clients could use a legacy authentication mechanism to supply a simple UN/PW that would provide a similar deployment experiance to shared secrets. > > (Note. If SOI is provides cert-only, then one would need to use > another protocol to bootstrap certificates from a legacy > authentication or shared secret scheme.) > > Implications from the Scenarios: > > VPN: << addresses cannot be used as phase 1 identifiers. This also means that > the authentication material cannot be chosen based upon the IP address > in the packet.>>> [[[2.3]]] > > SRA: << this policy information before the IPsec tunnel is constructed.>>> > [[[2.3]]] > > SRA: << accommodate re-authentication based on the RAS or authentication > server site security policy>>> [[[2.3]]] > > SRA: << location of the authentication server relative to the client and the > RAS. In many scenarios, server tends to be "behind" the RAS device, in > the domain that is being secured by the RAS, which may be problematic > for bootstrapping the user authentication for the client-to-RAS > connection.>>> [[[2.3]]] From owner-ipsec@lists.tislabs.com Fri Jun 21 07:00:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LE0Kn28545; Fri, 21 Jun 2002 07:00:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03303 Fri, 21 Jun 2002 09:20:26 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Fri, 21 Jun 2002 08:33:19 -0500 (CDT) From: Tylor Allison X-X-Sender: To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTIONS: 2.4 Number of crypto operations 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, 20 Jun 2002, Theodore Ts'o wrote: > Please discuss and answer this question..... > > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? Yes, SOI should support fast rekeying. Others have mentioned the need for a secure management channel. I agree with this. I also feel that SOI will scale better if we provide fast rekeying. Awefully expensive if you have hundreds or thousands of clients all rekeying and performing the full crypto exponentiation for each rekey. ===================================================================== = Tylor Allison Secure Computing Corporation ========= ===================================================================== From owner-ipsec@lists.tislabs.com Fri Jun 21 07:20:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LEKbn00300; Fri, 21 Jun 2002 07:20:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03367 Fri, 21 Jun 2002 09:38:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20020620095850.02bdb738@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Jun 2002 10:00:22 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-Reply-To: <200206190546.g5J5kLr23037@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk PFS is not needed by everyone. For that reason, I think it should be optional. Russ From owner-ipsec@lists.tislabs.com Fri Jun 21 08:29:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LFTNn05193; Fri, 21 Jun 2002 08:29:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03521 Fri, 21 Jun 2002 10:40:57 -0400 (EDT) Message-Id: <200206201613.MAA06473@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: "Theodore Ts'o" Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Date: Thu, 20 Jun 2002 12:13:03 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: <200206190109.VAA17843@nwmail.wh.lucent.com> <20020620151827.GC13288@think.thunk.org> In-Reply-To: <20020620151827.GC13288@think.thunk.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA00373 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 20 June 2002 11:18, Theodore Ts'o wrote: > > I strongly disagree with the last statement, and consider it > > technically incorrect. Remote access does not add perceptible > > overhead (unless you want to first retrieve your PK and then run a > > "normal" key exchange, but leave out how practical it is. Suffeces > > to say that "legacy auth" today fits well enough into the standard > > IKE). > > The overhead I was referring to here is protocol complexity overhead > and implementation size overhead. My point exactly: there is no perceptible extra protocol complexity for adding "legacy auth". Neither cryptographic, nor protocol-wise. Perhaps, configuration-wise... -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Fri Jun 21 08:36:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LFa9n05344; Fri, 21 Jun 2002 08:36:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03534 Fri, 21 Jun 2002 10:50:00 -0400 (EDT) Date: 21 Jun 2002 10:50:51 -0400 Message-ID: <001301c21933$0a6d0aa0$e369e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Jean-Jacques Puig'" , " 'list'" Subject: RE: SOI QUESTIONS: 2.5 Plausible denaibility MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200206210726.JAA17380@hugo.int-evry.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This nice feature does no worth the expense it involves. I had a section explaining this in draft-ipsec-properties (which has expired and I haven't gotten around to resubmitting). "8.2 Repudiation Authentication using either pre-shared keys or public key encryption has the repudiation property. Either side is capable of forging the entire exchange; therefore there is no reliable way to prove that the transaction took place. Authentication using public key signatures does not provide full repudiation, but it doesn’t provide explicit non-repudiation either. When Bob generates a signature, it proves that he talked to somebody. It is possible for Alice to encode a signed hash of her identity into a payload that will be signed by Bob during the course of the exchange. This would prove that Bob talked to Alice (or someone colluding with Alice), although not necessarily on purpose. Note that this does not prove to a third party that any data sent with the negotiated keys is genuine. So for all intents and purposes, IKE provides repudiation of the phase 1 exchange, no matter which mode of authentication you use." The point being that all the original IKEv1 modes had repudiation almost by accident. I'll be the first to admit that it's not a very important feature, but there is no expense involved. 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 Jun 21 09:01:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LG1In05795; Fri, 21 Jun 2002 09:01:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03614 Fri, 21 Jun 2002 11:19:13 -0400 (EDT) Date: Fri, 21 Jun 2002 08:32:07 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, If you think the RFC 2401 issue that you bring up is a technical reason for rejecting L2TP+IPsec, think again. For the benefit of people who didn't go through this discussion I would like to say that, IMHO, this issue of RFC 2410 and L2TP+IPsec not being able to mandate 'static packet filtering', is not only NOT a technical issue, but also the most absurd issue that we(all supporters of L2TP+IPsec) had to put up with, in the discussion. It should be amply clear to anyone who is reading this thread that there is no consistency in Steve's argument. Ofcourse there are always some people who want to take credit for everything, and even take credit for the fact that something useful was rejected! We had so much of technical discussion, but in the end, it just felt like there was any technical reason that we did not address. We may not have had the moral majority, but a lot of stuff that goes on here doesn't have it too. I think, RFC 2401 is the single biggest hurdle for IPsec technology. How can we document 'IPsec architecture' in a single document 5 years ago. IPsec is being used in so many different scenarios, and in so many different and creative ways. To think that we can provide so much useless information in an RFC, and still make it useful is beyond me. I generally advice people who want to start on IPsec to just skip RFC 2401, and come back to it only after they know IPsec a little bit, so that they can weed out the useless stuff efficiently. I think the duality of this WG, not being able to decide whether 'remote access' belongs here or not, is somewhat due to our closed definition of 'IPsec architecture'. chinna On Fri, 21 Jun 2002, Stephen Kent wrote: > At 8:44 PM -0700 6/20/02, Chinna N.R. Pellacuru wrote: > >Not an inefficiency if you don't run a firewall in your implementation, > >and your standard of security is only what is provided by a 'static packet > >filter'. We call that ACL functionality, not even a firewall > >functionality. > > > > chinna > > > > The term "ACL" is well understood in the information security > literature for over 30 years. It is quaint that Cisco (I assume the > "we" above) has adopted that term for a particilaur functionality in > their products, but Cisco's effective monopoly status in the router > product arena does not confer and special status on the neologistic > use of the term. > > Steve > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Fri Jun 21 09:05:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LG5Pn05929; Fri, 21 Jun 2002 09:05:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03628 Fri, 21 Jun 2002 11:24:14 -0400 (EDT) Date: Fri, 21 Jun 2002 08:37:39 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec mailling list Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Putting it in your own words... "I agree that proxy firewalls can offer better security than packet filtering firewalls, assuming suitable care is applied to the..." chinna On Fri, 21 Jun 2002, Stephen Kent wrote: > At 7:06 PM -0700 6/20/02, Chinna N.R. Pellacuru wrote: > >Unless that is your standard of security! > > > > chinna > > > >On Thu, 20 Jun 2002, Chinna N.R. Pellacuru wrote: > > > >> minimal 'static packet filtering' in IPsec is useless. > >> > > > chinna > >> > > repetition of value judgements without substantiation, as above, is useless > > Steve > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Fri Jun 21 10:21:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LHLZn08822; Fri, 21 Jun 2002 10:21:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03812 Fri, 21 Jun 2002 12:35:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20020621092355.05069218@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jun 2002 09:46:46 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: SOI Discussion Cc: byfraser@cisco.com, tytso@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Folks, Ted and I are really pleased to see the active dialog on the list. We have been reviewing the discussion and have noticed, however, that many responses are incomplete from the standpoint of being able to use the response to help us arrive at a set of features. We need more specificity so that we can support decisions about a feature. It would really help if when you answer a question you provide specific scenarios for when the answer to a given question is yes, no, or maybe. To freshen everyone's memory, the following list of scenarios was culled from Cheryl's document (draft-ietf-ipsec-sonofike-rqts-00.txt) plus Michael Thomas' VoIP/small device scenario. Everyone knows this is an incomplete list, but if we can deal with these, we'll be going along way to truly establishing the set of requirements, and therefore features, that SOI must support. Virtual Private Network Site-to-Site Tunnels' Secure Remote Access End-to-End Security IP Storage PPVPN/MPLS Mobile IP/Wireless Multiple and Changing Addresses: IPv6, SCTP and MobileIP Delay Sensitive Applications VoIP/small device BTW, if anyone feels moved and wants to try to match all the questions from our posting on June 11 (subj: Son of IKE: A proposal for moving forward) to one (or more.... we're optimists) of the scenarios please drop Ted and I a note so we can track activities and avoid duplication. Barb From owner-ipsec@lists.tislabs.com Fri Jun 21 11:41:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LIfFn14892; Fri, 21 Jun 2002 11:41:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03959 Fri, 21 Jun 2002 13:53:42 -0400 (EDT) Message-Id: <5.1.0.14.2.20020621135939.02cdbab8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 14:06:17 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: Re: SOI QUESTIONS: 2.5 Plausible deniability Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:03 PM -0400 6/20/02, Theodore Ts'o wrote: >Please discuss and answer this question..... (for more discussion and a >clear definition of "plausible denaibility", please see section 2.5 of >the soi-features I-D). > >2.5) Plausible denaibility > >2.5.A) Does SOI need to provide "plausible deniability" (the opposite >of "non-repudiation") for the initiator? > > >2.5.B) Does SOI need to provide "plausible deniability" (the opposite >of "non-repudiation") for the responder? Non-repudiation is a service that is normally associated with the application layer. So, this characterization is not quite right, but I think we all get the point. The only IPsec issue seems to be private key operations that are subsequently used to prove the participation of a particular party in the symmetric key management exchange. I do not think that we should expend any effort (and certainly we should not add complexity) to provide "plausible deniability" for either party. Russ From owner-ipsec@lists.tislabs.com Fri Jun 21 11:44:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LIiin15139; Fri, 21 Jun 2002 11:44:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03960 Fri, 21 Jun 2002 13:53:43 -0400 (EDT) Message-Id: <5.1.0.14.2.20020621135315.02cddb68@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 13:57:56 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: Re: SOI QUESTIONS: 2.4 Number of crypto operations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 Jun 2002, Ted Ts'o wrote: > Please discuss and answer this question..... > > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? Ted: This one cannot be discussed in isolation. It has may interrelationships with other aspects of key management. PFS is an obvious one. As I said earlier, there are many environments where PFS is not needed, so I believe it should be optional. Those that need it can expend the effort to get it. Those that do not need it, can do things more efficiently, including derive fresh SA keys from previously established secrets. Russ From owner-ipsec@lists.tislabs.com Fri Jun 21 11:55:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LIsxn15320; Fri, 21 Jun 2002 11:54:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03995 Fri, 21 Jun 2002 14:13:47 -0400 (EDT) From: Gary Grebus USG Message-Id: <200206202211.SAA0000020056@fddimax.zk3.dec.com> X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.7 #1[UCI] To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-reply-to: Your message of "Tue, 18 Jun 2002 18:17:14 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jun 2002 18:11:18 -0400 X-Mts: smtp Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 2.2 Perfect forward secrecy (PFS) > The ability to trade the level of PFS (amount of traffic potentially exposed) vs. overhead is a useful approach. As long as it does not introduce a new way to create a misconfiguration, either approach seems acceptable. -- Gary Grebus Hewlett-Packard Company Tru64 UNIX Base OS Networking Gary.Grebus@hp.com From owner-ipsec@lists.tislabs.com Fri Jun 21 11:55:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LIt7n15333; Fri, 21 Jun 2002 11:55:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04014 Fri, 21 Jun 2002 14:14:48 -0400 (EDT) From: Gary Grebus USG Message-Id: <200206202229.SAA0000020080@fddimax.zk3.dec.com> X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.7 #1[UCI] To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-reply-to: Your message of "Tue, 18 Jun 2002 20:14:49 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jun 2002 18:29:19 -0400 X-Mts: smtp Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? As a requirement, absolutely not. The question is what is the appropriate key exchange protocol to support the security that should be present in every IP stack on every device that support IP. Implementations that need to support external authentication protocols should do so a modular, external protocol. > > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) > While I don't see anything wrong with shared secrets for authentication, requiring support for public-key based authentication seems like an acceptable compromise between requiring shared secrets and requiring full certificates (even self-signed). The requirement to replace pre-shared secrets used with IKEv1 with simply generated public-keys for IKEv2 doesn't seem like a major hurdle in an upgrade path. -- Gary Grebus Hewlett-Packard Company Tru64 UNIX Base OS Networking Gary.Grebus@hp.com From owner-ipsec@lists.tislabs.com Fri Jun 21 11:55:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LItPn15345; Fri, 21 Jun 2002 11:55:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04016 Fri, 21 Jun 2002 14:14:57 -0400 (EDT) X-Envelope-To: sommerfeld@east.sun.com Message-ID: <4B1D0072D16AD4118B88009027DC884B7DA421@csuk-nt-pat.cybersafe.com> From: Tim Alsop To: "'sommerfeld@east.sun.com'" , "'Paul Koning'" Cc: "'mcr@sandelman.ottawa.on.ca'" , "'ipsec@lists.tislabs.com'" Subject: RE: replacing preshared keys Date: Fri, 21 Jun 2002 15:46:17 +0100 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have been watching this discussion develop over the last few days. I don't know if anybody has considered it, but it looks like what is needed is a way to combine the best of PK technology (not necessarily PKI) and a shared secret mechanism and perhaps also a key management solution is needed to help with secret key deployment ? I may not have summarised it very well and I appologise for this, but it looks like the answer may already exist - See PKINIT (Internet Draft for PK authentication with Kerberos) and Kerberos (RFC1510). I also suggest that the standards that CableLabs (www.cablelabs) have agreed upon for the worldwide PacketCable and CableHome initiatives for the cable network industry are allready taking advantage of IKE, IPSEC, Kerberos and PKINIT together - this is a real example of these technologies being used together to achieve the desire results - perhaps these discussions can learn something from this ? Once again, sorry if I haven't explained this and for mentioning this so late in the discussions. I hope it sparks of some new ideas ? Thanks, Tim. -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] Sent: 20 June 2002 20:14 To: Paul Koning Cc: mcr@sandelman.ottawa.on.ca; ipsec@lists.tislabs.com Subject: replacing preshared keys > A LOT longer. Long enough that -- unlike preshared keys -- you cannot > enter them manually. how about either hash-of-public-key (i.e., key fingerprint) or hash-of-selfsigned-cert or as the user-visible identification blob? with truncated hashes, you can trade off security vs. ease-of-use. > True. But PK, even if all you ever use is selfsigned certs, still > needs a lot more near-incomprehensible concepts than preshared keys > do. user runs a program to generate the node key and the self-signed cert and it spits out the hash-of-key or hash-of-cert which is exchanged out of band with peers. i don't see particularly hard concepts there in terms of explaining what you have to do.. - Bill From owner-ipsec@lists.tislabs.com Fri Jun 21 11:56:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LIu4n15364; Fri, 21 Jun 2002 11:56:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04015 Fri, 21 Jun 2002 14:14:51 -0400 (EDT) From: Gary Grebus USG Message-Id: <200206202243.SAA0000020102@fddimax.zk3.dec.com> X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.7 #1[UCI] To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security In-reply-to: Your message of "Thu, 20 Jun 2002 13:04:24 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jun 2002 18:43:25 -0400 X-Mts: smtp Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 2.6 Formal proofs of security > I haven't seen any specific claim that something would have to be traded off to get a formal proof of security of at least the core cryptographic protocol. It would seem prudent to use whatever formal methods are available to check for protocol errors. Especially in light of past "security protocols" that were shown to be insecure. -- Gary Grebus Hewlett-Packard Company Tru64 UNIX Base OS Networking Gary.Grebus@hp.com From owner-ipsec@lists.tislabs.com Fri Jun 21 12:32:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LJW6w16847; Fri, 21 Jun 2002 12:32:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04133 Fri, 21 Jun 2002 14:42:12 -0400 (EDT) Date: 21 Jun 2002 14:42:36 -0400 Message-ID: <000801c21953$6a850e40$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Barbara Fraser'" , " 'list'" Subject: Scenario-Question matrix 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <4.3.2.7.2.20020621092355.05069218@mira-sjc5-4.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not really keen on this question format. I feel that I can give more insightful answers when left to my own devices. I guess these should supplement the answers I already gave. > 2.1.) Does SOI need to provide identity protection (For the initiator) > Virtual Private Network Site-to-Site Tunnels' - no > Secure Remote Access - yes > End-to-End Security - yes > IP Storage - ? > PPVPN/MPLS - ? > Mobile IP/Wireless - yes > Multiple and Changing Addresses: IPv6, SCTP and MobileIP - yes > Delay Sensitive Applications - ? > VoIP/small device - ? > 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward > secrecy" by trading off performance versus the level of PFS provided. > The funcitonality provided is roughly identical. Does anyone care > about the details of how IKEv2 versus JFK provides this functionality? > Should we just flip a coin? I don't think this is scenario-specific. Everyone should use PFS unless they only need manual keying. > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? > Virtual Private Network Site-to-Site Tunnels' - no > Secure Remote Access - yes > End-to-End Security - no > IP Storage - ? > PPVPN/MPLS - ? > Mobile IP/Wireless - yes > Multiple and Changing Addresses: IPv6, SCTP and MobileIP - ? > Delay Sensitive Applications - ? > VoIP/small device - ? > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? (Or just certificates-only?) > Virtual Private Network Site-to-Site Tunnels' - yes > Secure Remote Access - yes > End-to-End Security - yes > IP Storage - ? > PPVPN/MPLS - ? > Mobile IP/Wireless - ? > Multiple and Changing Addresses: IPv6, SCTP and MobileIP - ? > Delay Sensitive Applications - ? > VoIP/small device - ? > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? > Virtual Private Network Site-to-Site Tunnels' - yes > Secure Remote Access - yes > End-to-End Security - yes > IP Storage - ? > PPVPN/MPLS - yes > Mobile IP/Wireless - yes > Multiple and Changing Addresses: IPv6, SCTP and MobileIP - yes > Delay Sensitive Applications - ? > VoIP/small device - ? > 2.5) Plausible denaibility > Virtual Private Network Site-to-Site Tunnels' - no > Secure Remote Access - no > End-to-End Security - ? > IP Storage - no > PPVPN/MPLS - no > Mobile IP/Wireless - no > Multiple and Changing Addresses: IPv6, SCTP and MobileIP - no > Delay Sensitive Applications - no > VoIP/small device - no > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) no. 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 Barbara Fraser > Sent: Friday, June 21, 2002 12:47 PM > To: ipsec@lists.tislabs.com > Cc: byfraser@cisco.com; tytso@mit.edu > Subject: SOI Discussion > > > Hi Folks, > > Ted and I are really pleased to see the active dialog on the > list. We have > been reviewing the discussion and have noticed, however, that many > responses are incomplete from the standpoint of being able to use the > response to help us arrive at a set of features. We need more > specificity > so that we can support decisions about a feature. It would > really help if > when you answer a question you provide specific scenarios for > when the > answer to a given question is yes, no, or maybe. To freshen > everyone's > memory, the following list of scenarios was culled from > Cheryl's document > (draft-ietf-ipsec-sonofike-rqts-00.txt) plus Michael Thomas' > VoIP/small > device scenario. Everyone knows this is an incomplete list, > but if we can > deal with these, we'll be going along way to truly > establishing the set of > requirements, and therefore features, that SOI must support. > Virtual Private Network Site-to-Site Tunnels' > Secure Remote Access > End-to-End Security > IP Storage > PPVPN/MPLS > Mobile IP/Wireless > Multiple and Changing Addresses: IPv6, SCTP and MobileIP > Delay Sensitive Applications > VoIP/small device > > BTW, if anyone feels moved and wants to try to match all the > questions from > our posting on June 11 (subj: Son of IKE: A proposal for > moving forward) to > one (or more.... we're optimists) of the scenarios please > drop Ted and I a > note so we can track activities and avoid duplication. > > Barb > > From owner-ipsec@lists.tislabs.com Fri Jun 21 12:44:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LJiWw17286; Fri, 21 Jun 2002 12:44:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04219 Fri, 21 Jun 2002 14:56:33 -0400 (EDT) Message-ID: <6F0AA176DA68704884B7507AE6907E18081854@snake012.odetics.com> From: Christina Helbig To: "'Jean-Jacques Puig'" , ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) Date: Fri, 21 Jun 2002 12:08:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, IMO there is a mix of the issue of PFS and rekeying in the discussion. 1. Rekeying is needed if the amount of with the same key encrypted data goes beyond specific values, because of some passive attacks against the encrypted data (dependable also of the encryption algorithm and its mode) and the active attack of replaying by ESP after the sequence number counter has started again. 2. The need for PFS by the process of rekeying is not based on protection against this attacks under 1. 3. The property of PFS is an advantage in the case of unauthorized access to secret information used to generate the communication keys. If this secret information can be secured against unauthorized access then rekeying can be done without the property of PFS. 4. On the other hand there is always a need by IKE to protect secret information against unauthorized access used for phase 1 authentication. If the protection of this secret information in the system is sufficient why should there the protection of an other secret information be insufficient? My proposal is: Rekeying is necessary under specific circumstances, which should be described. PFS is not needed if the secret information used to generate different communication keys is protected against unauthorized access in the same manner like the phase 1 authentication secret. Greetings, Christina > -----Original Message----- > From: Jean-Jacques Puig [mailto:jean-jacques.puig@int-evry.fr] > Sent: Thursday, June 20, 2002 12:18 AM > To: ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) > > > Hi, > > Paul Hoffman / VPNC wrote: > > > In the typical VPN scenario (either gateway-to-gateway or > remote-access WAN): > > > > - PFS is a real requirement for some but not all user scenarios > > I agree. PFS support is, IMO, a requirement for scenarios > involving gateways, especially in VPNs. > But not everybody will need PFS, and we can expect (in some > scenarios) the SA lifetime to be big enough for their use and > no key derivation required. > > Should'nt PFS / Imperfect PFS / No PFS be negotiated in > the exchanges of IKEv2 ? > > If not, I stand for PFS as a requirement. > > -- > Jean-Jacques Puig > From owner-ipsec@lists.tislabs.com Fri Jun 21 13:12:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKCcw18206; Fri, 21 Jun 2002 13:12:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04309 Fri, 21 Jun 2002 15:24:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 21 Jun 2002 15:35:18 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:37 AM -0700 6/21/02, Chinna N.R. Pellacuru wrote: >Putting it in your own words... > > >"I agree that proxy firewalls can offer better security than packet >filtering firewalls, assuming suitable care is applied to the..." > > chinna > yes, my own words, but still not sufficient to support your ill-articulated assertions. for example, in deriding simple packet filtering vs. other firewall access controls, you have never described which other firewall controls you are using as a reference. you also started including references to IDS, which is irrelevant to the discussion. do you really not understand the difference between the poor security offered by a router filter which makes access control decisions based on packet header fields that are from an UNAUTHENTICATED souce and which have NO INTEGRITY PROTECTION, vs. making the same checks in an IPsec context where we have authenticated the source and provided integrity for these fields? Steve From owner-ipsec@lists.tislabs.com Fri Jun 21 13:17:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKHow18381; Fri, 21 Jun 2002 13:17:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04329 Fri, 21 Jun 2002 15:33:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 21 Jun 2002 15:30:50 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: SOI QUESTIONS: 2.3 Authentication styles Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:32 AM -0700 6/21/02, Chinna N.R. Pellacuru wrote: >Steve, > >If you think the RFC 2401 issue that you bring up is a technical reason >for rejecting L2TP+IPsec, think again. > >For the benefit of people who didn't go through this discussion I would >like to say that, IMHO, this issue of RFC 2410 and L2TP+IPsec not being >able to mandate 'static packet filtering', is not only NOT a technical >issue, but also the most absurd issue that we(all supporters of >L2TP+IPsec) had to put up with, in the discussion. It should be amply >clear to anyone who is reading this thread that there is no consistency in >Steve's argument. > >Ofcourse there are always some people who want to take credit for >everything, and even take credit for the fact that something useful was >rejected! > >We had so much of technical discussion, but in the end, it just felt like >there was any technical reason that we did not address. We may not have >had the moral majority, but a lot of stuff that goes on here doesn't have >it too. > >I think, RFC 2401 is the single biggest hurdle for IPsec technology. How >can we document 'IPsec architecture' in a single document 5 years ago. >IPsec is being used in so many different scenarios, and in so many >different and creative ways. To think that we can provide so much useless >information in an RFC, and still make it useful is beyond me. I generally >advice people who want to start on IPsec to just skip RFC 2401, and come >back to it only after they know IPsec a little bit, so that they can weed >out the useless stuff efficiently. I think the duality of this WG, not >being able to decide whether 'remote access' belongs here or not, is >somewhat due to our closed definition of 'IPsec architecture'. > > chinna I hope few people take any advice from you, given the above exhortation to create non-complaint implementations. There is a disturbing trend in your messages, which I expect most list members have noted as well. You begin to raise technical issues, but when the claims are challenged or the assertions refuted, you transition to different arguments, never fully responding to the original challenges or rebuttals. This may be a good debate technique before an naive audience, but it fails for a technical audience such as this mailing list. Steve From owner-ipsec@lists.tislabs.com Fri Jun 21 13:30:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKU1w18906; Fri, 21 Jun 2002 13:30:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04387 Fri, 21 Jun 2002 15:50:18 -0400 (EDT) Date: Fri, 21 Jun 2002 16:03:24 -0400 From: "Theodore Ts'o" To: Andrew Krywaniuk Cc: "'Barbara Fraser'" , "'list'" Subject: Re: Scenario-Question matrix Message-ID: <20020621200324.GB708@think.thunk.org> References: <4.3.2.7.2.20020621092355.05069218@mira-sjc5-4.cisco.com> <000801c21953$6a850e40$1e72788a@ca.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c21953$6a850e40$1e72788a@ca.alcatel.com> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Jun 21, 2002 at 02:42:36PM -0400, Andrew Krywaniuk wrote: > I'm not really keen on this question format. I feel that I can give more > insightful answers when left to my own devices. I guess these should > supplement the answers I already gave. Well, I sent out the questions a week before we started feeding them to the list, a few questions at a time, hoping that folks would help improve the questions before we started this whole process. This is still possible; if you have any suggestions on how any of the questions which we haven't gotten to yet could be improved, please let us know! As for the format of dribbling out a few questions every day or so, the reason why we did this was that the working group didn't seem to be making a lot of progress on deciding these questions left to its own devices. This was an experiment to see if we could help the process a long with just a little bit more formality. As Barbara suggested, if someone would like to take some time and effort into evaluating the entire set of questions against one or more scenarios, that would also be useful, and would be a great cross-check to the existing discussion. Just let us know that you're willing to work on such a (sub-)document, so we can make sure we don't have multiple people working on the same scenario. In the meantime, though, since we're getting a lot of useful discussion with this particular format, it seems to me like it would be useful to continue this experiment. As always, comments and suggestions are always appreciated. - Ted From owner-ipsec@lists.tislabs.com Fri Jun 21 13:30:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKU5w18919; Fri, 21 Jun 2002 13:30:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04353 Fri, 21 Jun 2002 15:43:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Fri, 21 Jun 2002 15:54:23 -0400 To: IP Security List From: Stephen Kent Subject: apology Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It was brought to my attention that Chinna is just one of several Cisco employee participating in the IPsec discussions, and that his "unique" perspective on matters ought not be viewed as representative of the organization. BBN is now part of a very large organization, and I am sensitive to the difference between individual and corporate positions. So, despite the use of "we" by Chinna in his postings, I will not assume that his postings represent a corporate stance, and thus refrain from criticizing the organization as a whole. That said, there is also probably no need to continue the debate with Chinna as an individual. Steve From owner-ipsec@lists.tislabs.com Fri Jun 21 13:33:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKXdw19052; Fri, 21 Jun 2002 13:33:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04365 Fri, 21 Jun 2002 15:47:17 -0400 (EDT) Date: Fri, 21 Jun 2002 12:59:57 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: IP Security List Subject: Re: SOI QUESTIONS: 2.3 Authentication styles 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, 21 Jun 2002, Stephen Kent wrote: > At 8:32 AM -0700 6/21/02, Chinna N.R. Pellacuru wrote: > >Steve, > > > >If you think the RFC 2401 issue that you bring up is a technical reason > >for rejecting L2TP+IPsec, think again. > > > >For the benefit of people who didn't go through this discussion I would > >like to say that, IMHO, this issue of RFC 2410 and L2TP+IPsec not being > >able to mandate 'static packet filtering', is not only NOT a technical > >issue, but also the most absurd issue that we(all supporters of > >L2TP+IPsec) had to put up with, in the discussion. It should be amply > >clear to anyone who is reading this thread that there is no consistency in > >Steve's argument. > > > >Ofcourse there are always some people who want to take credit for > >everything, and even take credit for the fact that something useful was > >rejected! > > > >We had so much of technical discussion, but in the end, it just felt like > >there was any technical reason that we did not address. We may not have > >had the moral majority, but a lot of stuff that goes on here doesn't have > >it too. > > > >I think, RFC 2401 is the single biggest hurdle for IPsec technology. How > >can we document 'IPsec architecture' in a single document 5 years ago. > >IPsec is being used in so many different scenarios, and in so many > >different and creative ways. To think that we can provide so much useless > >information in an RFC, and still make it useful is beyond me. I generally > >advice people who want to start on IPsec to just skip RFC 2401, and come > >back to it only after they know IPsec a little bit, so that they can weed > >out the useless stuff efficiently. I think the duality of this WG, not > >being able to decide whether 'remote access' belongs here or not, is > >somewhat due to our closed definition of 'IPsec architecture'. > > > > chinna > > I hope few people take any advice from you, given the above > exhortation to create non-complaint implementations. > > There is a disturbing trend in your messages, which I expect most > list members have noted as well. You begin to raise technical issues, > but when the claims are challenged or the assertions refuted, you > transition to different arguments, never fully responding to the > original challenges or rebuttals. This may be a good debate technique > before an naive audience, but it fails for a technical audience such > as this mailing list. > > Steve This is exactly what you are doing. I couldn't articulate what you are doing any better, so I'll let your words stand for what you are doing. chinna > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Fri Jun 21 13:35:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKZ8w19108; Fri, 21 Jun 2002 13:35:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04375 Fri, 21 Jun 2002 15:49:18 -0400 (EDT) Date: Fri, 21 Jun 2002 13:02:02 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec mailling list Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The issue is not about authentication. I think it is amply clear to everyone that no one is debating about authentication here, but where to do the access control, and should IPsec RFC 2401 mandate a 'static packet filter'. Nice try to divert the topic as if we are debating authentictaion. chinna On Fri, 21 Jun 2002, Stephen Kent wrote: > At 8:37 AM -0700 6/21/02, Chinna N.R. Pellacuru wrote: > >Putting it in your own words... > > > > > >"I agree that proxy firewalls can offer better security than packet > >filtering firewalls, assuming suitable care is applied to the..." > > > > chinna > > > > yes, my own words, but still not sufficient to support your > ill-articulated assertions. for example, in deriding simple packet > filtering vs. other firewall access controls, you have never > described which other firewall controls you are using as a reference. > you also started including references to IDS, which is irrelevant to > the discussion. > > do you really not understand the difference between the poor security > offered by a router filter which makes access control decisions based > on packet header fields that are from an UNAUTHENTICATED souce and > which have NO INTEGRITY PROTECTION, vs. making the same checks in an > IPsec context where we have authenticated the source and provided > integrity for these fields? > > Steve > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Fri Jun 21 13:40:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKeew19303; Fri, 21 Jun 2002 13:40:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04417 Fri, 21 Jun 2002 15:58:22 -0400 (EDT) Date: 21 Jun 2002 15:58:53 -0400 Message-ID: <001001c2195e$12c955c0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Gary Grebus USG'" , " 'list'" Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <200206202243.SAA0000020102@fddimax.zk3.dec.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For some flawed security protocols, the problem was that the authors didn't have any technically savvy people review them. A security proof might give you some confidence in those protocols by virtue of the fact that they had to hire/enlist an expert to write the security proof. For IKEv1, there are lots of minor flaws that people knew about for a long time. These are not issues that slipped through the cracks because we didn't have a formal analysis. They are design tradeoffs that, in hindsight, were probably ill-advised. Some examples: 1. Problem: Some payloads are not included in the phase 1 authentication hash. Cause: Hash was constructed in such a way as to have (subjectively) better repudiation properties. 2. Problem: IKE is vulnerable to time & state DoS in aggressive mode and state DoS in main mode, even though 3 antecedent documents (Photuris, Oakley, and Isakmp) discuss the problem. Cause: An optimization. Some list members wanted to reduce round trips, even at the expense of DoS prevention. These are problems by design. A formal analysis doesn't help. In problem 1, the protocol was designed by cryptographers, and I doubt that most people understood at the time that this was the tradeoff (a statement of design rationale might have helped). In problem 2, the tradeoff was a conscious choice by list members. But what about non-obvious problems that may lay dormant for years? Here are the two newest security flaws that were discussed on this list: 3. Problem: IKE key stretching truncates the entropy of the DH shared secret. I'm speculating here, but this is the kind of thing that a formal analysis might find. However when it was posted, a large number of list members (including some advocates of formal analysis) said that it was not really a flaw at all, since it is not practical to exploit it. 4. Problem: Non-random IVs allow an active attack against IPsec traffic. Would a formal analysis have discovered this problem? I highly doubt it. The scenario in which this attack is feasible was discussed on the list several times last year and no one ever noticed the attack until recently. In order to discover the attack by formal analysis, you first have to postulate the existance of the attack and add it to your list of axioms. An explanation of design rationale is a good thing if it prevents us from making flawed design tradeoffs. A formal analysis using predicate logic and/or state machines can't hurt, but it may give us a false sense of security. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gary Grebus USG > Sent: Thursday, June 20, 2002 6:43 PM > To: ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security > > > > > > 2.6 Formal proofs of security > > > > I haven't seen any specific claim that something would have > to be traded off to get a > formal proof of security of at least the core cryptographic > protocol. It > would seem prudent to use whatever formal methods are > available to check for > protocol errors. Especially in light of past "security > protocols" that were > shown to be insecure. > > -- > Gary Grebus > Hewlett-Packard Company > Tru64 UNIX Base OS Networking > Gary.Grebus@hp.com > From owner-ipsec@lists.tislabs.com Fri Jun 21 13:48:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LKmJw19740; Fri, 21 Jun 2002 13:48:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04474 Fri, 21 Jun 2002 16:08:29 -0400 (EDT) Date: 21 Jun 2002 16:09:14 -0400 Message-ID: <001101c2195f$8539cb20$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" Cc: "'Barbara Fraser'" , " 'list'" Subject: RE: Scenario-Question matrix 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <20020621200324.GB708@think.thunk.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On Fri, Jun 21, 2002 at 02:42:36PM -0400, Andrew Krywaniuk wrote: > > I'm not really keen on this question format. I feel that I > can give more > > insightful answers when left to my own devices. I guess these should > > supplement the answers I already gave. > > Well, I sent out the questions a week before we started feeding them > to the list, a few questions at a time, hoping that folks would help > improve the questions before we started this whole process. Okay, allow me to rephrase. I'm not really keen on Barbara's request to always refer the answers back to the scenarios. I was doing fine just answering the individual questions in a free form way, but trying to come up with an answer for how PFS applies to delay-sensitive devices and PPVPN/MPLS is just too hard. 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 Jun 21 14:10:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LLA3w21264; Fri, 21 Jun 2002 14:10:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04547 Fri, 21 Jun 2002 16:29:43 -0400 (EDT) Message-Id: <200206212042.g5LKfvn04795@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-reply-to: Your message of "Fri, 21 Jun 2002 09:24:17 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 21 Jun 2002 16:41:57 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Darren" == Darren Dukes writes: >> 2.3.B.) Does SOI need to natively support some kind of "shared >> secret" scheme? (Or just certificates-only?) Darren> Short answer: No but MUST support native legacy authentication if Darren> shared secrets don't exist. As far as I understand XAUTH, the need for shared secrets is simply to be able to get past the IKEv1 phase 1 exchange so that legacy auth can be done. At no time does the legacy auth stuff get *used* as the shared secret. (Radius doesn't support returning the "password" to the gateway machine, so you can't do things that way, and there is no password for lots of systems) So, XAUTH could have just as easily defined a group-shared RSA private key, or SOI could define a single direction authentication system (gateway->client). If possible, I'd like to see reuse of the SecSH userauth protocol, carried in SOI's phase1 instead. ] 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 iQCVAwUBPROPkIqHRg3pndX9AQHP4QQAhTH/M58nGvi1QWBU/4uxRRTXvPFbK+Y6 BCRJkmJRZszgivg8d04ycsEp/pDZnxzOu9eDwCY1JLgtNeZBpK2b4v/kU0NPD8og Ws1qjCE0CvT4IsoT4Jf1ovC7FyF5C+MyGankz85YJUf0yYH4BJyIBRoqZ7GsmL9y 8teUfPA3ZCA= =eVBT -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jun 21 14:18:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LLI7w21629; Fri, 21 Jun 2002 14:18:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04584 Fri, 21 Jun 2002 16:37:45 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 3.1 DoS protection Phone: (781) 391-3464 Message-Id: Date: Fri, 21 Jun 2002 16:51:04 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Notes from the chair: This next set of questions address the issues listed in section 3 of the soi-features I-D, "Protocol Mechanics". Please discuss and answer: 3.1 DoS protection 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more important to always keep the message count at 4, or is it acceptable to add an additional roundtrip of messages when the responder thinks he's under attack? 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide basically equivalent protection. Does anyone care about the details of how JFK or IKEv2 provide this functionality. 3.1.C) Is it important to have precomputation of exponentials available for use as a mechanism for protecting against cpu consumption attacks? Implications from the scenarios: [none] From owner-ipsec@lists.tislabs.com Fri Jun 21 14:26:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LLQ1w22509; Fri, 21 Jun 2002 14:26:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04611 Fri, 21 Jun 2002 16:43:48 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 3.2 Number of messages in all scenarios Phone: (781) 391-3464 Message-Id: Date: Fri, 21 Jun 2002 16:56:31 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Notes from the chair: Fundamentally, this a philosophical issue about how negotiations should be handled. Please discuss and answer: 3.2 Number of messages in all scenarios 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in message one. In IKEv2 if Bob doesn't accept what Alice offers the negotiation starts again. In JFK if Bob doesn't accept what Alice offers but Alice can live with what Bob offers, they continue. Otherwise they start over. Is this an important feature for SOI? Implications from the scenarios: SRA: <<>> [[[3]]] See also 4.2, 2.4 From owner-ipsec@lists.tislabs.com Fri Jun 21 14:31:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LLV6w23123; Fri, 21 Jun 2002 14:31:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04627 Fri, 21 Jun 2002 16:49:49 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 3.3 Size of messages Phone: (781) 391-3464 Message-Id: Date: Fri, 21 Jun 2002 17:02:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Notes from the chair: >From reviewing the discussion in section 3.3 of the soi-features document, it did not appear there were any material differences in the message sizes between IKE or JFK. If others disagree with this assessment, please state why, and why you think this is important for a particular scenario. 3.3 Size of messages There is no significant difference in the size of messages in the two protocols. Implications from the scenarios: [none] From owner-ipsec@lists.tislabs.com Fri Jun 21 15:16:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LMGCw25008; Fri, 21 Jun 2002 15:16:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04689 Fri, 21 Jun 2002 17:32:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15635.40577.322000.456233@gargle.gargle.HOWL> Date: Fri, 21 Jun 2002 17:45:37 -0400 From: Paul Koning To: grebus@fddimax.zk3.dec.com Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security References: <200206202243.SAA0000020102@fddimax.zk3.dec.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 20 June 2002) by Gary Grebus USG: > > > > 2.6 Formal proofs of security > > > > I haven't seen any specific claim that something would have to be traded off to get a > formal proof of security of at least the core cryptographic protocol. It > would seem prudent to use whatever formal methods are available to check for > protocol errors. Especially in light of past "security protocols" that were > shown to be insecure. Good point. In fact, if some feature were proposed that appeared to require trading off the ability to do a security proof, I would tend to view that as evidence that the feature in question is a bad idea and should not be included. paul From owner-ipsec@lists.tislabs.com Fri Jun 21 15:25:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LMPfw25321; Fri, 21 Jun 2002 15:25:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04719 Fri, 21 Jun 2002 17:46:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15635.41384.262000.328471@gargle.gargle.HOWL> Date: Fri, 21 Jun 2002 17:59:04 -0400 From: Paul Koning To: andrew.krywaniuk@alcatel.com Cc: grebus@fddimax.zk3.dec.com, ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security References: <200206202243.SAA0000020102@fddimax.zk3.dec.com> <001001c2195e$12c955c0$1e72788a@ca.alcatel.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 21 June 2002) by Andrew Krywaniuk: > For some flawed security protocols, the problem was that the authors didn't > have any technically savvy people review them. A security proof might give > you some confidence in those protocols by virtue of the fact that they had > to hire/enlist an expert to write the security proof. That's true for some flawed protocols. Some were so flawed that it only took knowledge at the level of Crypto 101 to spot the holes. But what you say does not apply to all flawed protocols. There's the classic example of the initial Needham-Schroeder protocol, yet I don't think many people would want to describe those two authors as "not technically savvy". paul From owner-ipsec@lists.tislabs.com Fri Jun 21 17:30:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5M0Uvw29595; Fri, 21 Jun 2002 17:30:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04925 Fri, 21 Jun 2002 19:50:34 -0400 (EDT) Message-Id: <200206220002.g5M02WM06790@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-reply-to: Your message of "Thu, 20 Jun 2002 10:00:22 EDT." <5.1.0.14.2.20020620095850.02bdb738@exna07.securitydynamics.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 21 Jun 2002 20:02:30 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Housley," == Housley, Russ writes: Housley> PFS is not needed by everyone. For that reason, I think it Housley> should be optional. As Ted/Barbara asked, citing a scenario where it is not needed is useful. Devices which very short call durations may never be online long enough for it to matter. But, the issue is not "is not needed by everyone", so make it optional. The questions is, what is better: - forcing everyone to implement it vs - quadrupling the number of test cases by making it optional. (2x because it may be offered or not, 2x because you may accept it or not) Remember, even devices which do not support it will have to test the case that it is offered and they decline! Remember also that options have severe impacts on proofs. ] 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 iQCVAwUBPRO+lIqHRg3pndX9AQFx5wP+Omv2/q/mSc4MUy9h4Lq+e7GnDvlpgjgX ccGltdXVOQdzUYZqudHdTDGgV8sPEyKiPSqA5/dl4TJzwq/GTuMsMs6NRCOwYvkC otCMTyAdVC2tOxsGk5zoqcxvj2sB2qvFZWyjLRna3ufau81DzyAguiCxXQ1B5USe 2FXFjPu7u2A= =YATu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jun 21 18:57:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5M1vXw02535; Fri, 21 Jun 2002 18:57:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05052 Fri, 21 Jun 2002 20:54:47 -0400 (EDT) Date: Fri, 21 Jun 2002 18:01:39 -0700 (MST) From: Joel M Snyder Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-reply-to: "Your message dated Fri, 21 Jun 2002 20:02:30 -0400" <200206220002.g5M02WM06790@marajade.sandelman.ottawa.on.ca> To: Michael Richardson Cc: ipsec@lists.tislabs.com Message-id: <01KJ79QWA3J8939294@Opus1.COM> Organization: Opus One - +1 520 324 0494 MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Fruit-of-the-day: Mexican Breadfruit References: <5.1.0.14.2.20020620095850.02bdb738@exna07.securitydynamics.com> Comments: Telecommunications and Information Technology Services Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Michael here on this. >From a cryptographic point of view, PFS seems like a great idea. From an IKE testing-and-interoperability point of view, PFS (or rather the optional nature of same) is a bad idea. It would be better if PFS were either REQUIRED (in which case some devices would be hard-pressed to make lots of SAs, like perhaps Palm Pilots or cell phones) or REMOVED. Is removal a bad thing? No. In the short-lived SA scenario (generally called "remote access"), you're not on long enough nor do you send enough traffic to care about PFS. You probably won't even rekey. In the long-lived SA scenario, you have two options. If you like the effect of PFS, then you can simply make your IKE SA lifetime the same as your IPsec SA lifetime (or whatever they're called in SOI) and you get a new DH for each rekey. If you don't care, then you make your IKE SA lifetime longer than your IPSEC SA lifetime, and you have multiple keys derived from the same original SKEYID. Since the recommended ratio of IPSEC-to-IKE for most vendors is 1 hour-8 hours, it's not like there is a huge change in the window anyway. I think that PFS should be mandatory (if you don't like to do D-Hs, then use group 1 and it won't be so bad); if people simply cannot live with that, then I'd rather see it removed than made optional. jms >>>>>> "Housley," == Housley, Russ writes: > Housley> PFS is not needed by everyone. For that reason, I think it > Housley> should be optional. > As Ted/Barbara asked, citing a scenario where it is not needed is useful. > Devices which very short call durations may never be online long enough >for it to matter. > But, the issue is not "is not needed by everyone", so make it optional. > The questions is, what is better: > - forcing everyone to implement it >vs > - quadrupling the number of test cases by making it optional. > (2x because it may be offered or not, 2x because you may accept it > or not) > Remember, even devices which do not support it will have to test the >case that it is offered and they decline! > Remember also that options have severe impacts on proofs. >] 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 >iQCVAwUBPRO+lIqHRg3pndX9AQFx5wP+Omv2/q/mSc4MUy9h4Lq+e7GnDvlpgjgX >ccGltdXVOQdzUYZqudHdTDGgV8sPEyKiPSqA5/dl4TJzwq/GTuMsMs6NRCOwYvkC >otCMTyAdVC2tOxsGk5zoqcxvj2sB2qvFZWyjLRna3ufau81DzyAguiCxXQ1B5USe >2FXFjPu7u2A= >=YATu >-----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Jun 22 08:40:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5MFelw06062; Sat, 22 Jun 2002 08:40:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06142 Sat, 22 Jun 2002 10:50:39 -0400 (EDT) Message-Id: <200206221503.g5MF3rZs017848@thunk.east.sun.com> From: Bill Sommerfeld To: Joel M Snyder cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) In-Reply-To: Your message of "Fri, 21 Jun 2002 18:01:39 PDT." <01KJ79QWA3J8939294@Opus1.COM> Reply-to: sommerfeld@east.sun.com Date: Sat, 22 Jun 2002 11:03:53 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let's be careful to distinguish between: 1) the forward-secrecy properties of IPsec key management 2) the optional second DH exchange done in IKEv1 phase 2, which is what many people think of when they hear "PFS". I don't believe that there's a need for every SA to have a separate DH exchange; what is important is for the spec to allow a user of the protocol to know what the forward-secrecy properties are, and that requires protocol-visible lifetimes for keying material. - Bill From owner-ipsec@lists.tislabs.com Sun Jun 23 11:02:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5NI2Xw26472; Sun, 23 Jun 2002 11:02:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08016 Sun, 23 Jun 2002 12:53:50 -0400 (EDT) Message-ID: <3D1627DC.A12023FD@storm.ca> Date: Sun, 23 Jun 2002 12:56:12 -0700 From: Sandy Harris X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tylor Allison wrote: > But that's the point... it's very possible to design a bad interface for > handling public keys (and innumerable ways to design a good one). Without > a clear and concise mandate from this WG on the minimum requirements for > PK/PKI, there will be interoperability problems (NOTE: this is not a > bits-on-the-wire issue but a deployment issue).... IKEv1 should serve as > an example for that! Yes, but I think that's an argument for including a spec for PK in SOI, in particular for specifying a format for exchange of RSA keys. If my implementation cannot export a public key in a format yours can read, then we cannot interoperate. Methinks the standard must specify, as a MUST, a text format usable for such export/import operations on public keys. (Perhaps it should handle export/import of private keys as well, for the case where you want a central server to create keys for a bunch of lesser devices such as point-of-sale terminals which might lack the CPU power or random number generator to do it themselves. This is a separate issue; perhaps a SHOULD in the standard?) > The same really can't be said for pre-shared keys... > they are simple, straight-forward, and almost guaranteed to interoperate > between any two vendors. Why throw it away? Compared to public key methods, they have several disadvantages. See: http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/adv_config.html#adv-pk In particular, they require secure out-of-band communication of the secrets, which adds both cost and risk, and they scale much less well. For an n-way mesh, you need n(n-1)/2 shared secrets, but only n public/private key pairs. If we get public key right, we can scrap shared secret. KISS in this case means use one good technique, From owner-ipsec@lists.tislabs.com Sun Jun 23 11:06:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5NI60w26584; Sun, 23 Jun 2002 11:06:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08103 Sun, 23 Jun 2002 13:16:53 -0400 (EDT) Message-Id: <200206231729.g5NHTwGF000604@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: new I-D Date: Sun, 23 Jun 2002 19:29:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've just submitted a new I-D about the "transient pseudo-NAT" attack which was discovered for mobility signaling but applies to IKE with a "NAT traversal" facility. My plan is to revise my IPsec vs. Mobile IPv6 I-D and to add a section about IKEv2 with: - an optional protection for transport headers (i.e., real source and destination addresses) - a discussion about to use or not addresses in identities (cf. the "addresses and IKEv2" thread) - a generalized cookie request mechanism (return routability check) - etc. Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Jun 23 23:11:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5O6Bmw00968; Sun, 23 Jun 2002 23:11:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA08852 Mon, 24 Jun 2002 01:17:43 -0400 (EDT) Date: 24 Jun 2002 01:17:55 -0400 Message-ID: <003c01c21b3e$80181760$bc68e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Paul Koning'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <15635.41384.262000.328471@gargle.gargle.HOWL> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Was the Needham-Schroeder flaw discovered by a formal proof? (I got the impression it was discovered via machine simulation.) It would be nice if we had some kind of magical Turing machine that would read in an RFC and tell us if the protocol was secure, but in reality the formal methods are imperfect because they rely on too much human input. Yes, we should continue to analyze the protocol and improve the machine analysis tools. However, the question Ted posed is what are we willing to trade off in order to get a security proof. I don't think we need to dumb down the protocol to cater to the limitations of formal analysis. I would trust a logical analsis more than a formalized one at this point. 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 Paul Koning > Sent: Friday, June 21, 2002 5:59 PM > To: andrew.krywaniuk@alcatel.com > Cc: grebus@fddimax.zk3.dec.com; ipsec@lists.tislabs.com > Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security > > > Excerpt of message (sent 21 June 2002) by Andrew Krywaniuk: > > For some flawed security protocols, the problem was that > the authors didn't > > have any technically savvy people review them. A security > proof might give > > you some confidence in those protocols by virtue of the > fact that they had > > to hire/enlist an expert to write the security proof. > > That's true for some flawed protocols. Some were so flawed that it > only took knowledge at the level of Crypto 101 to spot the holes. > > But what you say does not apply to all flawed protocols. There's the > classic example of the initial Needham-Schroeder protocol, yet I don't > think many people would want to describe those two authors as "not > technically savvy". > > paul > From owner-ipsec@lists.tislabs.com Mon Jun 24 00:10:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5O7Apw02961; Mon, 24 Jun 2002 00:10:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08924 Mon, 24 Jun 2002 02:26:47 -0400 (EDT) Date: 24 Jun 2002 02:27:08 -0400 Message-ID: <003d01c21b48$2b8f44c0$bc68e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" , " 'list'" Subject: RE: SOI QUESTION: 3.1 DoS protection 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 V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3.1 DoS protection > > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, > is it more > important to always keep the message count at 4, or is it > acceptable to add > an additional roundtrip of messages when the responder thinks > he's under > attack? The additional round-trip approach is better. Since we don't expect to be under DoS attack most of the time, the average message count will still be 4. When under attack, we should expect severe performance degredation anyway. The noise to signal ratio will be so high that it won't make a difference if there are 6 messages or 4. The additional round-trip makes the protocol less intricate and more modular. This is just good protocol design. > 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 > and JFK provide > basically equivalent protection. Does anyone care about the > details of how > JFK or IKEv2 provide this functionality. Not really. It's a neat idea, but I'm not sure everyone will implement it. > 3.1.C) Is it important to have precomputation of exponentials > available for > use as a mechanism for protecting against cpu consumption attacks? Yes and no. Should you precompute exponentials? Yes, by all means. However, that is a local implementation matter that has nothing to do with the protocol. Do we need to use the technique specified in JFK? No, since that was only needed to accomplish feature 3.1.A. As I mentioned above, doing DoS protection in 6 messages makes the protocol less intricate and more modular. > 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in > message one. In IKEv2 if Bob doesn't accept what Alice offers the > negotiation starts again. In JFK if Bob doesn't accept what > Alice offers > but Alice can live with what Bob offers, they continue. > Otherwise they > start over. Is this an important feature for SOI? This is an area where SOI has the potential to be harder to implement than IKEv1. In IKEv1, aggressive mode always caused problems in expressing policy. With main mode, the exchange was self-contained (it could fully negotiate all features). With both IKEv2 and JFK it sounds like a meta-negotiator class/state-machine (which will retry with new parameters) will now be mandatory. Of course there are other reasons why one might want a meta-negotiator, so this could be a good thing. The JFK draft makes the argument that ukases are preferable to negotiation of parameters. I disagree, in the sense that the ukases must be handled by a meta-negotiator. There is no negotiation within the JFK exchange, but there is negotiation within the meta-exchange. > 3.3 Size of messages > > There is no significant difference in the size of messages in the two > protocols. The repetition of parameters in JFK in order to achieve feature 3.1.A is a little bit wasteful. But I agree that there is no significant difference. 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 Jun 24 00:24:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5O7OYw03395; Mon, 24 Jun 2002 00:24:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08949 Mon, 24 Jun 2002 02:41:51 -0400 (EDT) Date: 24 Jun 2002 02:42:12 -0400 Message-ID: <003e01c21b4a$45f32e10$bc68e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Bill'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <200206221503.g5MF3rZs017848@thunk.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, this is an area where list members like to debate a semantic issue without agreeing on what the terms mean (the other being preshared key/preshared secret/password). Let us remember that the original forward secrecy requirement for this WG was that compromise of the RSA private key should not endanger the session keys. The forward secrecy across phase 2 rekeys was added later. The description of one type of forward secrecy as "perfect" sounds like marketing jargon. If you negotiate 3 SAs at the same time, there is no reason to use 3 different DH keys, and using only one DH key does not make the forward secrecy any less perfect. 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 Bill Sommerfeld > Sent: Saturday, June 22, 2002 11:04 AM > To: Joel M Snyder > Cc: Michael Richardson; ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.2 Perfect forward secrecy (PFS) > > > Let's be careful to distinguish between: > > 1) the forward-secrecy properties of IPsec key management > > 2) the optional second DH exchange done in IKEv1 phase 2, which is > what many people think of when they hear "PFS". > > I don't believe that there's a need for every SA to have a separate DH > exchange; what is important is for the spec to allow a user of the > protocol to know what the forward-secrecy properties are, and that > requires protocol-visible lifetimes for keying material. > > - Bill > From owner-ipsec@lists.tislabs.com Mon Jun 24 01:02:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5O82tw04639; Mon, 24 Jun 2002 01:02:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA09043 Mon, 24 Jun 2002 03:23:03 -0400 (EDT) Date: Mon, 24 Jun 2002 09:36:18 +0200 (MET DST) Message-Id: <200206240736.JAA03525@hugo.int-evry.fr> From: Jean-Jacques Puig To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.5 Plausible denaibility In-Reply-To: <001301c21933$0a6d0aa0$e369e640@ca.alcatel.com> References: <200206210726.JAA17380@hugo.int-evry.fr> <001301c21933$0a6d0aa0$e369e640@ca.alcatel.com> Organization: =?UTF-8?B?RGAwISAiQW5kcmV3?= Krywaniuk" X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > The point being that all the original IKEv1 modes had repudiation almost by > accident. I'll be the first to admit that it's not a very important feature, > but there is no expense involved. > You're right. I was unclear about it (I have some difficulties with English language), but I did not meant a protocol expense. It is more a specification and use expense. The fact is I believe the next IKE version should assert most of peers intentions, and it should be possible to prove many properties of these intentions (the fact they were, at least in the beginning, willing to set an SA...). The hability of doing 'plausible deniability' contradicts this, and opens a way for doing what I formely call 'diplomacy/politics': "I may want to communicate, but may be I don't and may be it is not me but you, or may be I was forced to answer you". This is an expense of precautions which does not help (at least in real life) for communication. In the PK answering instance (where Bob may not answer to Alice on purpose, and thus a third party does not have evidence the data sent is genuine), we certainly have a proof of Bob talking to Alice, though we can reach to no conclusion about peers 'higher' intentions. Lastly, we can also invoke a kind of '(un)plausible deniability' from the collision property of the hash function. But we have to cope with this one. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Mon Jun 24 06:47:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ODl2w19493; Mon, 24 Jun 2002 06:47:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09736 Mon, 24 Jun 2002 08:40:38 -0400 (EDT) From: icon2002@sp.edu.sg Subject: Call for Participation - IEEE International Conference on Networks 2002 To: icon00-01g@sp.edu.sg, icon00-01h@sp.edu.sg, icon00-01i@sp.edu.sg, icon00-01j@sp.edu.sg X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Sat, 22 Jun 2002 12:28:56 +0800 X-MIMETrack: Serialize by Router on SSPWS010/SP/SP_SF(Release 5.0.2b (Intl)|16 December 1999) at 22/06/2002 12:31:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ****************************************************************************************** Our apology if you receive multiple copies of this message. We highly appreciate your help to publicize the Call for Participation locally. ******************************************************************************************* CALL FOR PARTICIPATION IEEE INTERNATIONAL CONFERENCE ON NETWORKS 2002 Tues, August 27 - Fri, August 30, 2002, Singapore Organised by Computer Chapter, IEEE Singapore School of EEE, Singapore Polytechnic In Cooperation with National University of Singapore Nanyang Technological University Laboratories for Information Technology Supported by the Singapore Exhibition and Convention Bureau. Conference Theme: Towards Network Superiority This is an invitation to participate in ICON2002: IEEE International Conference on Networks (August 27-30, 2002, Singapore). For detailed information of the conference and registration, please visit our web site: http://icon2002.calendarone.com The International Conference on Networks provides an international forum for experts from all over the world to promote, share and discuss various issues and developments in the broad field of computer and communication networks. A total of 119 papers were received from 25 countries and 82 papers were accepted. They will be presented in 14 technical sessions covering the most important topics in computer and communication network technology. They include Optical Networks, QoS and Routing, Teletraffic Engineering, Multimedia Networking, Wireless Protocols and Networks, Adhoc and Active Networks, Network Security and Management, and Internet Applications and Protocols. Six tutorials have also been planned: Tutorial 1 : Evolution of Core Networks from GSM to UMTS and Beyond Tutorial 2 : Generalized Multi-Protocol Label Switching (GMPLS) and Its Applications Tutorial 3 : Bluetooth Technology and Applications Tutorial 4 : Photonics and DWDM Technologies Tutorial 5 : Threats to TCP/IP Networks & Intrusion Detection System Tutorial 6 : Voice Over IP Many well-respected academics and leading specialists in the field will be attending this conference. We look forward to your participation in this prestigious event. IMPORTANT DATES Advance registration closing date: 31 July 2002 Sincerely, ICON2002 Organising Committee From owner-ipsec@lists.tislabs.com Mon Jun 24 06:47:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ODl6w19505; Mon, 24 Jun 2002 06:47:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09793 Mon, 24 Jun 2002 09:03:43 -0400 (EDT) Message-Id: <200206241148.HAA00781@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-pki-profile-00.txt Date: Mon, 24 Jun 2002 07:48:58 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security PKI Profile of ISAKMP and PKIX Author(s) : B. Korver, E. Rescorla Filename : draft-ietf-ipsec-pki-profile-00.txt Pages : 33 Date : 21-Jun-02 ISAKMP and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of ISAKMP and PKIX that defines the requirements for using PKI technology in the context of IPsec. The document compliments protocol specifications such as IKE, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-pki-profile-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-pki-profile-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020621135417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-profile-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-profile-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621135417.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jun 24 07:55:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OEtIw27272; Mon, 24 Jun 2002 07:55:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10156 Mon, 24 Jun 2002 10:15:17 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Date: Mon, 24 Jun 2002 10:28:36 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Please discuss and answer this question..... > > 2.6 Formal proofs of security > > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) I've never heard of any potential users turning away IKEv1 because it didin't have a formal proof. Then again, I don't speak to customers on a daily basis. A formal proof would be "nice to have", but not if it means rendering the protocol unuseable. > > Implications from the Scenarios: > > [none] From owner-ipsec@lists.tislabs.com Mon Jun 24 07:56:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OEu0w27524; Mon, 24 Jun 2002 07:56:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10131 Mon, 24 Jun 2002 10:05:14 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.4 Number of crypto operations Date: Mon, 24 Jun 2002 10:18:33 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Please discuss and answer this question..... > > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? Yes. To be more precise, SOI should have a 2 phases. This will help with fast rekeying, fast tunnel setup (for multiple tunnels), and better tunnel management (this was the BIGGEST problem with IKEv1, IMO). From owner-ipsec@lists.tislabs.com Mon Jun 24 08:05:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OF5Aw01681; Mon, 24 Jun 2002 08:05:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10172 Mon, 24 Jun 2002 10:25:21 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 3.1 DoS protection Date: Mon, 24 Jun 2002 10:38:38 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Notes from the chair: > > This next set of questions address the issues listed in section 3 of the > soi-features I-D, "Protocol Mechanics". > > > Please discuss and answer: > > 3.1 DoS protection > > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more > important to always keep the message count at 4, or is it > acceptable to add > an additional roundtrip of messages when the responder thinks he's under > attack? Avoid DoS attacks, whatever the cost. In my mind, the question should be, SOI *will* provide DoS protection. Do we want the option of reducing the exchange from 6 messages to 4 when boxes don't feel they are threatened by DoS attacks (add complexity to achieve speed (via less round trips) in most cases) From owner-ipsec@lists.tislabs.com Mon Jun 24 08:26:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OFQcw10094; Mon, 24 Jun 2002 08:26:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10184 Mon, 24 Jun 2002 10:45:25 -0400 (EDT) Date: Mon, 24 Jun 2002 10:09:54 -0400 From: Mouse Subject: Re: SOI QUESTIONS: 2.3 Authentication styles In-reply-to: <200206201848.g5KImZZs021746@thunk.east.sun.com> To: sommerfeld@east.sun.com Cc: ipsec@lists.tislabs.com Reply-to: uri@optonline.net Message-id: <0GY7006CDRELH1@mta6.srv.hcvlny.cv.net> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 7BIT References: <200206201848.g5KImZZs021746@thunk.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 20 June 2002 14:48, Bill Sommerfeld wrote: > > Well about 10 people have so far spoken up in favour of legacy > > auth. Unless 11 people are waiting until the last minute to voice > > their opposition to legacy auth, I'd say the support is there. > > I'd like to see a modular, GetCert/PIC-like, approach to legacy auth. My crystal ball says - it ain't gonna happen (and it adds: "for practicality reasons"). -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Mon Jun 24 08:38:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OFcnw10614; Mon, 24 Jun 2002 08:38:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10229 Mon, 24 Jun 2002 10:59:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.14051.535820.12715@pkoning.dev.equallogic.com> Date: Mon, 24 Jun 2002 11:12:35 -0400 From: Paul Koning To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security References: <15635.41384.262000.328471@gargle.gargle.HOWL> <003c01c21b3e$80181760$bc68e640@ca.alcatel.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> Was the Needham-Schroeder flaw discovered by a formal proof? I don't know. My reference to it was prompted by reading about it in DEC SRC report 39, "A logic of authentication" (Burrows, Abadi, Needham). Andrew> (I got the impression it was discovered via machine Andrew> simulation.) It would be nice if we had some kind of magical Andrew> Turing machine that would read in an RFC and tell us if the Andrew> protocol was secure, but in reality the formal methods are Andrew> imperfect because they rely on too much human input. True, but they can still tell us things we didn't previously know. The DEC report I just mentioned describes its analysis of the Yahalom protocol, and the fact that this analysis discovered some non-obvious properties that came as a surprise both to the analysts and to the inventor of the protocol. (In this case, they were not flaws, but they were still properties that were important to be aware of.) Andrew> Yes, we should continue to analyze the protocol and improve Andrew> the machine analysis tools. However, the question Ted posed Andrew> is what are we willing to trade off in order to get a Andrew> security proof. I don't think we need to dumb down the Andrew> protocol to cater to the limitations of formal analysis. I Andrew> would trust a logical analsis more than a formalized one at Andrew> this point. I wouldn't want to push one at the exclusion of the other. As for "dumbing down" the protocol to accommodate formal analysis, is that speculation at this point or do we have concrete examples where this applies? If the latter, what are they? As I said earlier, I would tend to start out suspicious of features so complex that they aren't amenable to formal analysis. paul From owner-ipsec@lists.tislabs.com Mon Jun 24 09:45:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OGjOw13273; Mon, 24 Jun 2002 09:45:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10358 Mon, 24 Jun 2002 11:56:02 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.17443.795001.338930@thomasm-u1.cisco.com> Date: Mon, 24 Jun 2002 09:09:07 -0700 (PDT) To: andrew.krywaniuk@alcatel.com Cc: "'Theodore Ts'o'" , " 'list'" Subject: RE: SOI QUESTION: 3.1 DoS protection In-Reply-To: <003d01c21b48$2b8f44c0$bc68e640@ca.alcatel.com> References: <003d01c21b48$2b8f44c0$bc68e640@ca.alcatel.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 Andrew Krywaniuk writes: > > 3.1 DoS protection > > > > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, > > is it more > > important to always keep the message count at 4, or is it > > acceptable to add > > an additional roundtrip of messages when the responder thinks > > he's under > > attack? > > The additional round-trip approach is better. Since we don't expect to be > under DoS attack most of the time, the average message count will still be > 4. When under attack, we should expect severe performance degredation > anyway. The noise to signal ratio will be so high that it won't make a > difference if there are 6 messages or 4. The fact that JFK only requires 4 round trips ever is certainly an advantage because you don't need to figure out when you're under attack (you always are :-), and it simplifies the state machine. The real question is what advantage the IKEv2 4/6 message exchange confers. As far as I remember -- correct me if I'm wrong -- is that the advantage was only that cipher suite negotiation was deferred until after you have a key. This is different than the ukases stance of JFK. However, if you're willing to reveal the cipher transforms in the clear (like JFK), you can still have a 4 message exchange with JFK-like DOS resistance. See below. > The JFK draft makes the argument that ukases are preferable to negotiation > of parameters. I disagree, in the sense that the ukases must be handled by a > meta-negotiator. There is no negotiation within the JFK exchange, but there > is negotiation within the meta-exchange. One of my suggestions to the JFK authors was to relax the no-negotiation stance and adopt an offer/answer model. That is, with JFK Bob states which unilateral decision it has made and Alice either lives with that decision, or gives up. With an offer/answer mechanism Alice would enumerate a list of transforms it's willing to do, and Bob chooses one. The advantage here is that offer/answer greatly mitigates the need for the meta-negotiator. This is obviously not much different than IKE's QM, of course, but I think the biggest mistake in IKE's current scheme is trying to negotiate each individual transform rather than aggregating them into a single offer. In reality, there's only a few interesting transform combinations (eg AES-128-CBC-SHA1) so I think any worries of combinatorial explosion are overblown. To my mind, this strikes a more sensible balance (didn't Dan et al do this in ikev2?). Voice has an almost identical set of issues with codec agreement. H.245 is the moral equivalent of IKE QM conjugates, and SDP is the moral equivalent of JFK ukases. In the end, both got it wrong. SDP+offer/answer is the middle and eminently more reasonable path, IMO. Mike From owner-ipsec@lists.tislabs.com Mon Jun 24 09:53:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OGrMw13581; Mon, 24 Jun 2002 09:53:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10408 Mon, 24 Jun 2002 12:10:12 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.18284.540151.162309@thomasm-u1.cisco.com> Date: Mon, 24 Jun 2002 09:23:08 -0700 (PDT) To: "Stephane Beaulieu" Cc: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.4 Number of crypto operations In-Reply-To: References: 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 Stephane Beaulieu writes: > > Please discuss and answer this question..... > > > > 2.4 Number of crypto operations > > > > 2.4.A) JFK requires substantially more cryptographic operations for > > rekeying (two more signatures, two more signature validations, and > > three more hashes). Is this a problem? More generally, does SOI need > > to be able to support "fast" rekeying? > > Yes. > > To be more precise, SOI should have a 2 phases. This will help with fast > rekeying, fast tunnel setup (for multiple tunnels), and better tunnel > management (this was the BIGGEST problem with IKEv1, IMO). Perhaps a more sensible balance would be have the initial exchange be able to produce a real IPsec SA (ie self-contained), and be able to specify a zero life for the SOI SA. That way, a compliant implementation could choose not to implement "quick mode" where there's no particular need. I propose the following requirement: "If SOI defines subsequent SOI exchanges derived by the shared state of an initial SOI exchange, the protocol MUST make these subsequent exchanges optional to both parties. A minimal SOI implementation MUST NOT be required to implement the subsequent exchanges." Mike From owner-ipsec@lists.tislabs.com Mon Jun 24 10:07:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OH7Bw14590; Mon, 24 Jun 2002 10:07:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10455 Mon, 24 Jun 2002 12:23:16 -0400 (EDT) From: "Stephane Beaulieu" To: "Michael Thomas" Cc: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.4 Number of crypto operations Date: Mon, 24 Jun 2002 12:36:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15639.18284.540151.162309@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Please discuss and answer this question..... > > > > > > 2.4 Number of crypto operations > > > > > > 2.4.A) JFK requires substantially more cryptographic operations for > > > rekeying (two more signatures, two more signature validations, and > > > three more hashes). Is this a problem? More generally, > does SOI need > > > to be able to support "fast" rekeying? > > > > Yes. > > > > To be more precise, SOI should have a 2 phases. This will > help with fast > > rekeying, fast tunnel setup (for multiple tunnels), and better tunnel > > management (this was the BIGGEST problem with IKEv1, IMO). > > Perhaps a more sensible balance would be have the > initial exchange be able to produce a real IPsec > SA (ie self-contained), and be able to specify a > zero life for the SOI SA. That way, a compliant > implementation could choose not to implement > "quick mode" where there's no particular need. > > I propose the following requirement: > > "If SOI defines subsequent SOI exchanges derived > by the shared state of an initial SOI exchange, > the protocol MUST make these subsequent exchanges > optional to both parties. A minimal SOI > implementation MUST NOT be required to implement > the subsequent exchanges." That would defeat the purpose of the Management Channel I spoke of. If your SOI SA goes away immediately (or doesn't get created at all), it gets much harder to detect / correct error conditions (black holes for example), without opening yourself up to a bunch of DoS attacks. We have lots of bad experiences with this in IKEv1, which is why (I think...) that Dan et al, added a mgt channel to IKEv2. Dangling SAs (what you're advocating) and Mgt Channel (what I'm advocating) don't play together very well (at least not in the real world, where packets get dropped, and VPN boxes reboot). > > Mike From owner-ipsec@lists.tislabs.com Mon Jun 24 10:12:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OHCBw14885; Mon, 24 Jun 2002 10:12:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10474 Mon, 24 Jun 2002 12:29:20 -0400 (EDT) To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security 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: 24 Jun 2002 09:44:02 -0700 In-Reply-To: "Theodore Ts'o"'s message of "Thu, 20 Jun 2002 13:04:24 -0400" Message-ID: Lines: 34 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Theodore Ts'o" writes: > Please discuss and answer this question..... > > 2.6 Formal proofs of security > > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) I haven't decided how to answer this question, but I'd like to amplify one of its possibly unnoticed consequences: In many cases, the cryptographic primitives used by security protocols do not have formal proofs of security either. In particular, IKEv2 [0] includes PKCS-1 by reference for digital signature. There are no good formal proofs of security for PKCS-1 signature mode. Does this mean we should cut over to one of the provably secure signature schemes such as PSS? [1] I suspect that similar comments apply the the key expansion prfs used by IKEv2. It seems to me that if we're going to argue that protocols need proofs of security that it probably follows that the primitives need proofs of security to the extent possible. -Ekr [0] JFK doesn't specify how signatures are performed but it seems like a likely guess that they're PKCS-1. [1] It's true we don't have a formal proof of security for RSA but PKCS-1 isn't even known to be as strong as RSA. -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Mon Jun 24 10:23:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OHNAw15380; Mon, 24 Jun 2002 10:23:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10519 Mon, 24 Jun 2002 12:40:22 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40CC89E35@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: andrew.krywaniuk@alcatel.com, "'Paul Koning'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Date: Mon, 24 Jun 2002 09:55:06 -0700 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 > Was the Needham-Schroeder flaw discovered by a formal proof? > (I got the > impression it was discovered via machine simulation.) It > would be nice if we > had some kind of magical Turing machine that would read in an > RFC and tell > us if the protocol was secure, but in reality the formal methods are > imperfect because they rely on too much human input. I have yet to see a really convincing Formal Method for proving a protocol is secure. I very much doubt that such a calculus could exist. The problem being the definition of 'security'. It is certainly possible to generate a calculus that will allow a protocol to be analysed to determine whether it has a particular given property, e.g. deadlock freedom, livelock freedom, 'perfect' forward secrecy under a certain set of assumptions e.g. we have a cipher suite with certain properties. The problem is that all formal methods can do is to determine that a specification has certain properties and security problems are very often caused by failing to understand the requirements. I believe that the value from formal methods comes from addressing a problem in an appropriate formalism so that the human brain needs to do less work to interpolate the gap from requirements to specification. I think there is a lot that the IETF could do to improve the quality of the standards it produces. However formal methods are a very long way down on my list, even though I studied them for my thesis. First off, there have been tremendous progress in typography since the invention of the teletype. Typography is a very important tool for formatting information in a manner in which the human brain can best receive it. The RFC plaintext format is an amateurish anacronism. Not only does it make producing RFCs tedious, it makes reading and verifying them considerably more error prone. I for one have no intention of reading someone's formal proof of a specification in RFC plaintext format. I know this is IETF heresy but there is a reason that Don Knuth spent all that time developing TeX. Marshall Rose has been doing some good stuff with XML, use it. Secondly before adopting formal methods for proof, adopt appropriate formal notations for clarity. If a standard describes a statefull protocol there should be a description of the state machine. Preferably this would be in a notation such as CSP which is formally grounded. Finally, adopt a mechanism for clearly labelling the individual requirements in a requirements document and the individual components of an architectural specification. That will expose the correspondence between the specification and the requirements. So requirements that are not addressed become obvious, as do architectural features that do not address a requirement. Phill From owner-ipsec@lists.tislabs.com Mon Jun 24 10:28:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OHSTw15584; Mon, 24 Jun 2002 10:28:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10534 Mon, 24 Jun 2002 12:44:25 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.20336.804519.83000@thomasm-u1.cisco.com> Date: Mon, 24 Jun 2002 09:57:20 -0700 (PDT) To: "Stephane Beaulieu" Cc: "Michael Thomas" , "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.4 Number of crypto operations In-Reply-To: References: <15639.18284.540151.162309@thomasm-u1.cisco.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 Stephane Beaulieu writes: > > > > > Please discuss and answer this question..... > > > > > > > > 2.4 Number of crypto operations > > > > > > > > 2.4.A) JFK requires substantially more cryptographic operations for > > > > rekeying (two more signatures, two more signature validations, and > > > > three more hashes). Is this a problem? More generally, > > does SOI need > > > > to be able to support "fast" rekeying? > > > > > > Yes. > > > > > > To be more precise, SOI should have a 2 phases. This will > > help with fast > > > rekeying, fast tunnel setup (for multiple tunnels), and better tunnel > > > management (this was the BIGGEST problem with IKEv1, IMO). > > > > Perhaps a more sensible balance would be have the > > initial exchange be able to produce a real IPsec > > SA (ie self-contained), and be able to specify a > > zero life for the SOI SA. That way, a compliant > > implementation could choose not to implement > > "quick mode" where there's no particular need. > > > > I propose the following requirement: > > > > "If SOI defines subsequent SOI exchanges derived > > by the shared state of an initial SOI exchange, > > the protocol MUST make these subsequent exchanges > > optional to both parties. A minimal SOI > > implementation MUST NOT be required to implement > > the subsequent exchanges." > > That would defeat the purpose of the Management Channel I spoke of. If your > SOI SA goes away immediately (or doesn't get created at all), it gets much > harder to detect / correct error conditions (black holes for example), > without opening yourself up to a bunch of DoS attacks. Huh? The DoS protection is conferred by the phase 1 DoS protection. All I'm saying is that phase 1 should be necessary and sufficient in SOI. This is not the case in IKE, but is part of the SOI requirements. Thus there is no reason for phase 2 to be mandatory. > We have lots of bad experiences with this in IKEv1, which is why (I > think...) that Dan et al, added a mgt channel to IKEv2. IKE has a "management" channel, it's just that it was poorly designed. That channel is Quick Mode. > Dangling SAs (what you're advocating) and Mgt Channel (what I'm advocating) > don't play together very well (at least not in the real world, where packets > get dropped, and VPN boxes reboot). I'm advocating no such thing. If you have a problem which is only solvable by having a phase 2, you haven't met the necessary and sufficient requirements for phase 1. Mike From owner-ipsec@lists.tislabs.com Mon Jun 24 10:53:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OHr1w16701; Mon, 24 Jun 2002 10:53:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10556 Mon, 24 Jun 2002 12:59:29 -0400 (EDT) Message-Id: <200206241713.g5OHD4b18576@sydney.East.Sun.COM> Date: Mon, 24 Jun 2002 13:13:04 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: SOI QUESTION: 3.1 DoS protection To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q6Jvs/qfDBbM4QEHrRRp2g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas asks: The real question is what advantage the IKEv2 4/6 message exchange confers. It's easy to make the IKEv2 exchange 4 messages all the time, but it doesn't come for free, so we made an arbitrary decision to do it that way. The costs of doing it always as 4 messages are: a) it makes message 3 always longer (so if most of the time you can run without needing to ask for a stateless cookie, there will be fewer bits on the wire) b) it makes the encoding messier, because part of message 3 has to be encrypted and part of it in the clear c) it makes it hard to protect against a fragmentation DOS attack. *********** The fragmentation DOS attack we described in the IKEv2 spec. The relevant snippet is: Note that one of the denial of service attacks that cookies are designed to thwart is exhaustion of state at the target by creating half-open connections. This defense would be ineffective if there were another equally easy way for an attacker to consume state at the target. IKE runs over UDP, and may send messages sufficiently large that they must be fragmented. But accumulating fragments of UDP packets consumes state at the target, so if an IKE responder were required to accept and reassemble UDP packets from unknown sources, another equally easy denial of service attack would be possible. To thwart the UDP reassembly buffer attack, the IKE responder SHOULD, when it detects that it is under attack, have a mechanism to inform IP reassembly to only accept UDP fragments from IP addresses from which it has received a valid cookie and to refuse to accept UDP fragments from all other IP addresses. To facilitate this, the IKE_SA_init message SHOULD be kept under 500 octets and responders MAY reject fragmented IKE_SA_init messages. Basically, with avoiding sending large stuff like certificates until the cookie has been returned, it allows a fairly simple way that implementations can be organized in order to avoid attackers swamping memory with needing-to-be-reassembled packets. I'm not sure anyone has worried about this attack yet, but this design would enable conversations using IPsec, and which have returned valid cookies, to get preferential treatment. It does require some layer violation in order for IKE to tell the reassembly code which IP addresses to give preferential treatment to. Note that none of the proposed protocols are "always" 4 messages. They all expand, for instance, if Alice, in message 1, chooses a Diffie-Hellman group that Bob does not support. As it happens, I was arguing for the folding-in- everything-in-4-messages variant from the start, but was (good-naturedly) outvoted by the other authors who were saying having it sometimes 6 messages for stateless cookies wasn't a big deal, because it could also sometimes need to be 6 messages for other reasons. But when Charlie came out with the fragmentation attack argument, it convinced me that I like it this way better. I don't think it's a big deal either way (unless fragmentation attacks become the next annoying DOS, in which case it would be nice to prepare for it). But changing over into the 4 message variant is easy enough to do. Radia From owner-ipsec@lists.tislabs.com Mon Jun 24 10:54:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OHsuw16782; Mon, 24 Jun 2002 10:54:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10605 Mon, 24 Jun 2002 13:08:34 -0400 (EDT) From: "Stephane Beaulieu" To: "Michael Thomas" Cc: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.4 Number of crypto operations Date: Mon, 24 Jun 2002 13:21:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15639.20336.804519.83000@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > > > > Please discuss and answer this question..... > > > > > > > > > > 2.4 Number of crypto operations > > > > > > > > > > 2.4.A) JFK requires substantially more cryptographic > operations for > > > > > rekeying (two more signatures, two more signature > validations, and > > > > > three more hashes). Is this a problem? More generally, > > > does SOI need > > > > > to be able to support "fast" rekeying? > > > > > > > > Yes. > > > > > > > > To be more precise, SOI should have a 2 phases. This will > > > help with fast > > > > rekeying, fast tunnel setup (for multiple tunnels), and > better tunnel > > > > management (this was the BIGGEST problem with IKEv1, IMO). > > > > > > Perhaps a more sensible balance would be have the > > > initial exchange be able to produce a real IPsec > > > SA (ie self-contained), and be able to specify a > > > zero life for the SOI SA. That way, a compliant > > > implementation could choose not to implement > > > "quick mode" where there's no particular need. > > > > > > I propose the following requirement: > > > > > > "If SOI defines subsequent SOI exchanges derived > > > by the shared state of an initial SOI exchange, > > > the protocol MUST make these subsequent exchanges > > > optional to both parties. A minimal SOI > > > implementation MUST NOT be required to implement > > > the subsequent exchanges." > > > > That would defeat the purpose of the Management Channel I > spoke of. If your > > SOI SA goes away immediately (or doesn't get created at all), > it gets much > > harder to detect / correct error conditions (black holes for example), > > without opening yourself up to a bunch of DoS attacks. > > Huh? The DoS protection is conferred by the > phase 1 DoS protection. All I'm saying is that > phase 1 should be necessary and sufficient in > SOI. This is not the case in IKE, but is part > of the SOI requirements. Thus there is no > reason for phase 2 to be mandatory. The DoS attack comment I made was unrelated to the DoS attack of getting peers initiating to you (which is the phase 1 DoS protection). It was in reference to past experiences with IKEv1 where you don't have a mgt channel. For example, what do you do if you receive an ESP packet with an invalid SPI and don't have an IKE SA? You can send an unauthenticated INVALID-SPI message and pray the other peer corrects the error (opening him up to DoS), or you can try and initiate and IKE SA so you can send INITIAL-CONTACT (which consumes resources, and opens you up to DoS) or you can ignore it, which leads to a peeved customer. Anyways, just trying to point out the value of having a management channel around. The channel can exist whether you have 1 or 2 phases (as you pointed out). However, I still say that fast rekeying is important, and that implies having 2 phases. If phase 2 can be made to be self sufficient management wise, then your proposal would work. However, I don't think that most people on this list (including myself) would like to have mgt properties in a phase 2 SA. > > > We have lots of bad experiences with this in IKEv1, which is why (I > > think...) that Dan et al, added a mgt channel to IKEv2. > > IKE has a "management" channel, it's just that > it was poorly designed. That channel is Quick > Mode. IKE didn't have a *mandatory* management channel. This is where interoperability took a turn for the worse. Some people kept their phase 1 SAs to handle INVALID-SPI, etc..., some people tossed it to save on resources. Throw in DELETEs that can get lost on the wire, and you have a management nightmare. BTW: The Quick Mode comment was a typo right? > > > Dangling SAs (what you're advocating) and Mgt Channel (what > I'm advocating) > > don't play together very well (at least not in the real world, > where packets > > get dropped, and VPN boxes reboot). > > I'm advocating no such thing. If you have a > problem which is only solvable by having a > phase 2, you haven't met the necessary and > sufficient requirements for phase 1. OK. Perhaps. Or maybe we just disagree on the requirements. Some of my requirements are fast rekey, fast tunnel setup (for single & multiple tunnels), and good error detection / handling. I haven't figured out how to handle all this in 1 phase. Hopefully, at the end of the day, we can agree on these requirements. If not, then I guess our votes will cancel each other out ;) Stephane. > > Mike From owner-ipsec@lists.tislabs.com Mon Jun 24 12:08:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OJ89w20297; Mon, 24 Jun 2002 12:08:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10747 Mon, 24 Jun 2002 14:17:16 -0400 (EDT) Date: Mon, 24 Jun 2002 11:30:49 -0700 (PDT) From: Jan Vilhuber To: Andrew Krywaniuk cc: "'Theodore Ts'o'" , "'list'" Subject: RE: SOI QUESTION: 3.1 DoS protection In-Reply-To: <003d01c21b48$2b8f44c0$bc68e640@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ditto :) jan On 24 Jun 2002, Andrew Krywaniuk wrote: > > 3.1 DoS protection > > > > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, > > is it more > > important to always keep the message count at 4, or is it > > acceptable to add > > an additional roundtrip of messages when the responder thinks > > he's under > > attack? > > The additional round-trip approach is better. Since we don't expect to be > under DoS attack most of the time, the average message count will still be > 4. When under attack, we should expect severe performance degredation > anyway. The noise to signal ratio will be so high that it won't make a > difference if there are 6 messages or 4. > > The additional round-trip makes the protocol less intricate and more > modular. This is just good protocol design. > > > > 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 > > and JFK provide > > basically equivalent protection. Does anyone care about the > > details of how > > JFK or IKEv2 provide this functionality. > > Not really. It's a neat idea, but I'm not sure everyone will implement it. > > > > 3.1.C) Is it important to have precomputation of exponentials > > available for > > use as a mechanism for protecting against cpu consumption attacks? > > Yes and no. > > Should you precompute exponentials? Yes, by all means. However, that is a > local implementation matter that has nothing to do with the protocol. > > Do we need to use the technique specified in JFK? No, since that was only > needed to accomplish feature 3.1.A. As I mentioned above, doing DoS > protection in 6 messages makes the protocol less intricate and more modular. > > > > 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in > > message one. In IKEv2 if Bob doesn't accept what Alice offers the > > negotiation starts again. In JFK if Bob doesn't accept what > > Alice offers > > but Alice can live with what Bob offers, they continue. > > Otherwise they > > start over. Is this an important feature for SOI? > > This is an area where SOI has the potential to be harder to implement than > IKEv1. In IKEv1, aggressive mode always caused problems in expressing > policy. With main mode, the exchange was self-contained (it could fully > negotiate all features). With both IKEv2 and JFK it sounds like a > meta-negotiator class/state-machine (which will retry with new parameters) > will now be mandatory. Of course there are other reasons why one might want > a meta-negotiator, so this could be a good thing. > > The JFK draft makes the argument that ukases are preferable to negotiation > of parameters. I disagree, in the sense that the ukases must be handled by a > meta-negotiator. There is no negotiation within the JFK exchange, but there > is negotiation within the meta-exchange. > > > > 3.3 Size of messages > > > > There is no significant difference in the size of messages in the two > > protocols. > > The repetition of parameters in JFK in order to achieve feature 3.1.A is a > little bit wasteful. But I agree that there is no significant difference. > > > 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. > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Mon Jun 24 12:22:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OJMfw20932; Mon, 24 Jun 2002 12:22:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10770 Mon, 24 Jun 2002 14:35:21 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B1A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: EKR , "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Date: Mon, 24 Jun 2002 11:50:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In many cases, the cryptographic primitives used by security protocols > do not have formal proofs of security either. In particular, > IKEv2 [0] includes PKCS-1 by reference for digital signature. There > are no good formal proofs of security for PKCS-1 signature mode. Does > this mean we should cut over to one of the provably secure signature > schemes such as PSS? [1] I suspect that similar comments apply > the the key expansion prfs used by IKEv2. I think that the two issues are separable. Any proof of security properties for the protocol should start from certain assumptions about the algorithms used. I think that the proof of correctness of the algorithm should be separated from the protocol. It is likely that the proof techniques used will be completely different. However I would also suggest that as a matter of good practice any introduction of an incompatible protocol change is a good time to deprecate or eliminate obsolete algorithms from the cipher suites. IP issues being equal I would say nuke PKCS#1 and select a single wrapping algorithm that provides the best security we know of today. Phill From owner-ipsec@lists.tislabs.com Mon Jun 24 12:23:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OJNTw20971; Mon, 24 Jun 2002 12:23:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10771 Mon, 24 Jun 2002 14:35:22 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B1B@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: RE: SOI QUESTION: 3.1 DoS protection Date: Mon, 24 Jun 2002 11:50:08 -0700 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 > Basically, with avoiding sending large stuff like certificates > until the cookie has been returned, it allows a fairly simple way that > implementations can be organized in order to avoid attackers swamping > memory with needing-to-be-reassembled packets. The protocol should provide the option of referencing the key authentication data independently of the key exchange. Moving certificates in-band is sometimes necessary but it should not be the default, particularly if you want to use UDP as a transport. In most VPN examples the IPSEC gateway can either be pre-populated with certificates or obtain them from a certificate location service (directory or XKMS). In XML Signature we developed the KeyInfo structure to serve as a very flexible structure that would allow any key authentication mechanism to be referenced. Exchanging certificate chains is very limiting, it requires the client to anticipate the roots of trust of the server. I can't see how PGP could be used in that circumstance and it would be very painful to try to use X.509 cross-certificates. In XML Signature the KeyInfo can specify a URL that provides a retrieval location for the key authentication info. This could be profitably adapted to IPSEC with a couple of tweaks to make very sure we stay within our UDP packet size 'budget'. The retreival method structure would have 3 fields as follows: 1) LOCATOR URL of the key authentication information 2) KEY_DIGEST One way function of the key parameter values 3) TYPE One way function of the KeyInfo URL that specifies the type of key information I am attempting to save IANA cycles here by re-using the existing W3C registry of KeyInfo parameter types. The Key_DIGEST may well be unnecessary, however some folk may prefer to be able to instantly verify that the info they get from the location service is that intended by the presenting party (avoid certain DoS modes). A typical locator URL should take up no more then 64 bytes. e.g. http://certs.company.test/cert/q2502qawoiu20a9350w9== If this was a real squeeze compression could be added. So the total locator package would be only 64 + 20 + 20 + packing = 110 bytes total Once again certs inband have their place, however they should not be the only mechanism. IKEv2 is a good opportunity to take advantage of progress in the PKI space. I believe that the larger requirement that IKEv2 should address is filling in the gaps that have led to IPSEC being limited to stovepipe VPN deployment. I think the time has come to set out a comprehensive statement on how an Internet wide IPSEC deployment could be achieved. I believe that certificates are likely to have a role in such a deployment, however we should also anticipate that DNSSEC and XKMS would play substantial roles as well. Phill From owner-ipsec@lists.tislabs.com Mon Jun 24 13:12:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OKCSw22838; Mon, 24 Jun 2002 13:12:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10895 Mon, 24 Jun 2002 15:22:38 -0400 (EDT) Message-ID: <3D176E2A.4030005@isi.edu> Date: Mon, 24 Jun 2002 12:08:26 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ppvpn@ppvpn.francetelecom.com, ipsec-vpn@puck.nether.net, Joe Touch Subject: ID update: draft-touch-ipsec-vpn-04.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050607080500010801080702" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms050607080500010801080702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, we have just submitted an update to draft-touch-ipsec-vpn-04.txt ("Use of IPsec Transport Mode for Dynamic Routing"). We consider this the final version of the ID, and have also requested publication as an (individual) Informational RFC, in preparation of 2401bis. If the mirrors haven't picked it up yet, it is also available at http://www.isi.edu/larse/papers/draft-touch-ipsec-vpn-04.txt Lars -- Lars Eggert USC Information Sciences Institute --------------ms050607080500010801080702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNDE5MDgyOFowIwYJKoZIhvcNAQkEMRYEFAXddP9ACrcW fuQW4rnQGFrr/H/SMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCK/SFQSGCj31YxsBhH6EL4eqyFgQE1PjlrXG2xu/9CurKM TkP/9T6aFB+jMN+DhFBy6LJUKE6vo1M/m0yX2WwzwAISDWafj9cFnaPj7qX6YmUmJ2Le+Qoe Z2mmsYeZZIva4QjbHr945tu+dBwHJ08/bAAG23ziLh5jVsK+R6cZZgAAAAAAAA== --------------ms050607080500010801080702-- From owner-ipsec@lists.tislabs.com Mon Jun 24 18:27:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5P1Rtw06105; Mon, 24 Jun 2002 18:27:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11473 Mon, 24 Jun 2002 20:49:20 -0400 (EDT) Date: 24 Jun 2002 20:49:36 -0400 Message-ID: <000701c21be2$2e9c4fb0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Thomas'" Cc: "'list'" Subject: RE: SOI QUESTION: 3.1 DoS protection 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <15639.17443.795001.338930@thomasm-u1.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The fact that JFK only requires 4 round trips > ever is certainly an advantage because you > don't need to figure out when you're under > attack (you always are :-), and it simplifies > the state machine. Does it? The extra check on the responder is very unobtrusive, so I wouldn't say that the state machine is complicated. For both protocols, the initiator already has to have a meta-negotiator which handles "retry with this additional parameter" messages, of which this is just a specific instance. > The real question is what advantage the IKEv2 > 4/6 message exchange confers. As far as I > remember -- correct me if I'm wrong -- is that > the advantage was only that cipher suite > negotiation was deferred until after you have a > key. No. (And why would that be an advantage -- See Radia's reply) a) it makes message 3 always longer (so if most of the time you can run without needing to ask for a stateless cookie, there will be fewer bits on the wire) [b and c omitted] To which I would also add: d) if you repeat every payload from message 1 in message 3 then you also have to parse each payload twice. I can only speak for my implementation, but I find this burdensome. > However, if you're willing to reveal > the cipher transforms in the clear (like JFK), > you can still have a 4 message exchange with > JFK-like DOS resistance. I think this is a red herring. Simple logic tells you that you have to reveal which encryption algorithm and DH group you are using before you can send an encrypted message. Therefore, the cipher transforms *MUST* be sent in the clear. I suppose you could try to be sneaky by using AES in SOI and 3DES in ESP, but let's try to be realistic. This is NOT the point of the 4/6 message exchange. > One of my suggestions to the JFK authors was to > relax the no-negotiation stance and adopt > an offer/answer model. That is, with JFK Bob > states which unilateral decision it has made > and Alice either lives with that decision, or > gives up. With an offer/answer mechanism Alice > would enumerate a list of transforms it's willing > to do, and Bob chooses one. Forgive me for being blunt, but have you read the drafts/RFCs? What you describe below is almost the exact opposite of the situation as it exists today. > The advantage here is that offer/answer greatly > mitigates the need for the meta-negotiator. Offer/answer is what IKEv1's Main Mode already does. Main Mode has no explicit requirement for a meta-negotiator, since all parameters are negotiated. > This is > obviously not much different than IKE's QM, of Or any of the IKE modes. Main mode would have been a better example, since both Aggressive mode and Quick mode have the DH group negotiation problem which necessitates the meta-negotiator in JFK and IKEv2. > course, but I think the biggest mistake in > IKE's current scheme is trying to negotiate each > individual transform rather than aggregating them > into a single offer. Sorry, but IKE does aggregate all the transforms into a single offer. It's not a numbered ciphersuite, but it's still a single offer. > In reality, there's only a > few interesting transform combinations (eg > AES-128-CBC-SHA1) so I think any worries of > combinatorial explosion are overblown. Dream on. You may think that agreeing on a ciphersuite is easy, but the fun starts right off the bat when half the vendors want PFS off by default and half want it on. Now add payload compression, which needs to be optional (another factor of two). Some IPsec clients with restricted GUIs will send up to 20 proposals by default. Ciphersuites in TLS worked out no better; they had so many requests for permutations that IANA refused to manage the registry. I'm an advocate of named ciphersuites, as specified in Paul's draft. It allows full flexibilty on the wire while allowing some consistency across every vendor's GUI. > To my > mind, this strikes a more sensible balance > (didn't Dan et al do this in ikev2?). No. IKEv2 actually does it both ways, but the preferred method is to negotiate each transform separately. I like this idea. I can propose: AES+SHA1+LZS // preferred ciphersuite, for which I have an optimized code path or {AES|3DES}+{SHA1|MD5}+{LZS|none} // any permutation of these 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 Jun 24 18:27:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5P1Rxw06124; Mon, 24 Jun 2002 18:27:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11459 Mon, 24 Jun 2002 20:48:19 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Mon Jun 24 17:49:09 2002 From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.18284.540151.162309@thomasm-u1.cisco.com> Date: Mon, 24 Jun 2002 09:23:08 -0700 (PDT) To: "Stephane Beaulieu" Cc: "Theodore Ts'o" , Subject: RE: SOI QUESTIONS: 2.4 Number of crypto operations In-Reply-To: References: 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 Stephane Beaulieu writes: > > Please discuss and answer this question..... > > > > 2.4 Number of crypto operations > > > > 2.4.A) JFK requires substantially more cryptographic operations for > > rekeying (two more signatures, two more signature validations, and > > three more hashes). Is this a problem? More generally, does SOI need > > to be able to support "fast" rekeying? > > Yes. > > To be more precise, SOI should have a 2 phases. This will help with fast > rekeying, fast tunnel setup (for multiple tunnels), and better tunnel > management (this was the BIGGEST problem with IKEv1, IMO). Perhaps a more sensible balance would be have the initial exchange be able to produce a real IPsec SA (ie self-contained), and be able to specify a zero life for the SOI SA. That way, a compliant implementation could choose not to implement "quick mode" where there's no particular need. I propose the following requirement: "If SOI defines subsequent SOI exchanges derived by the shared state of an initial SOI exchange, the protocol MUST make these subsequent exchanges optional to both parties. A minimal SOI implementation MUST NOT be required to implement the subsequent exchanges." Mike From owner-ipsec@lists.tislabs.com Mon Jun 24 19:43:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5P2hew08843; Mon, 24 Jun 2002 19:43:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11559 Mon, 24 Jun 2002 21:51:35 -0400 (EDT) Date: 24 Jun 2002 21:51:59 -0400 Message-ID: <000a01c21bea$e60e28a0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Hallam-Baker, Phillip'" , " 'Paul Koning'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40CC89E35@vhqpostal.verisign.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I have yet to see a really convincing Formal Method for > proving a protocol is secure. I very much doubt that such > a calculus could exist. I don't doubt that it could exist, but I am certain that we don't have it (at least not for any comprehensive definition of "secure"). > I believe that the value from formal methods comes from > addressing a problem in an appropriate formalism so that the > human brain needs to do less work to interpolate the gap > from requirements to specification. I think we shouldn't understate the fact that we are building a new protocol out of building blocks of existing protocols. The fact that we aren't doing anything revolutionary is more comfort to me than a formal proof. You start by just following sound cryptographic principles: 1. Start with a fully vetted cryptographic core. 2. Ensure that all inputs to the MAC are encoded in an unambiguous form. 3. Add entropy explicitly through a nonce, rather than assuming that some parameters are pseudo-random. 4. Don't use the same key for multiple things. Then add some lessons we have learned from experience: 5. Hash all payloads, not just some payloads so that new, optional payloads will automatically be included. 6. Use stateless cookies. 7. Build dead peer detection into the protocol. 8. Clearly state the security properties of the protocol so the reader doesn't get any false impressions. I have a high degree of confidence that what we produce will be secure. > True, but they can still tell us things we didn't previously know. > The DEC report I just mentioned describes its analysis of the Yahalom > protocol, and the fact that this analysis discovered some non-obvious > properties that came as a surprise both to the analysts and to the > inventor of the protocol. (In this case, they were not flaws, but > they were still properties that were important to be aware of.) In other words, they weren't design constraints. This just re-enforces my earlier point that the problem with formal analysis is that you won't find a problem unless you are specifically looking for it. > As for "dumbing down" the protocol to accommodate formal analysis, is > that speculation at this point or do we have concrete examples where > this applies? If the latter, what are they? As I said earlier, I > would tend to start out suspicious of features so complex that they > aren't amenable to formal analysis. In the not too distant past, "X is too complicated" was the catch-all technique that list members had for criticizing any idea they didn't like. This led to various amusing threads, such as the infamous "Puh-leeze". Anyway, some people claim that a 2-phase protocol is by nature too complex; others say that a 9 message protocol is too complex; still others state that IKE is really 12 protocols and that is too complex. I find some of these arguments lacking. For one thing, I have noticed that longer protocols are generally easier to analyze than shorter ones [that accomplish the same thing], and I can give you plenty of examples within IKE (I've posted them to this list before, so I won't do it again unless you're particularly interested). Also, if you have a protocol with 4 Boolean options then a formal analysis has to handle 16 different permutations, but a human may be able to determine that none of the options actually interact with each other so the analysis isn't actually that complicated. You can't test every permutation, but if your implementation is modular enough then you can test enough to get full coverage. I once knew a guy who wanted to verify the correctness of his 3DES implementation by testing every possible key. That still makes me laugh. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Jun 25 05:46:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PCk8w17558; Tue, 25 Jun 2002 05:46:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12495 Tue, 25 Jun 2002 08:03:40 -0400 (EDT) Message-ID: <3D17DCAC.2594DF67@briank.com> Date: Mon, 24 Jun 2002 19:59:57 -0700 From: Brian Korver X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: new draft: draft-ietf-ipsec-pki-profile-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, We interrupt your previously scheduled programming to introduce the somewhat sticky topic of how to use PKI with ISAKMP/IKE. Those who you have had the pleasure of reading the IKE documents have no doubt noticed that they're a little vague on a number of PKI-related topics, including: (1) What sorts of identifiers should appear in certificates. (2) What the various payloads mean. (3) How to interpret the mess of certificates that you get from the peer. This doesn't promote interoperability. Some of these questions can be answered by careful exegesis of the relevant documents, but it's not at all straightforward and experience shows that different implementors often come up with different "obvious" answers. Thus, we think it would be worthwhile to have a consensus on how things work. This draft is an attempt to nudge us towards that consensus. This is a first draft and is intended to spark discussion (rather than striving for accuracy or completeness). This draft covers some of the same territory as the expired draft-ietf-ipsec-pki-req-04.txt but is rather more complete and detailed and benefits from another year or two of implementation experience. While the primary target of this draft is IKE, it's also applicable to IKEv2 and to some extent to JFK, since the same sorts of issues arise whenever you use certs and IPsec together. -brian briank@briank.com From owner-ipsec@lists.tislabs.com Tue Jun 25 06:54:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PDs9w22212; Tue, 25 Jun 2002 06:54:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12620 Tue, 25 Jun 2002 09:13:53 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 3.4 Preferred ID for responder Phone: (781) 391-3464 Message-Id: Date: Tue, 25 Jun 2002 09:27:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 3.4 Preferred ID for responder 3.4.A) In JFK and IKEv2, the initiator can include a payload is an indication to the responder as to what identity (and corresponding key material) the responder should use to authenticate to the initiator. In JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent in the clear in message 1, thereby allowing a passive attack on the responder's likely identity. Is it important to encrypt this identity? Implications from the scenarios: [none] From owner-ipsec@lists.tislabs.com Tue Jun 25 07:11:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PEBSw23381; Tue, 25 Jun 2002 07:11:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12661 Tue, 25 Jun 2002 09:30:57 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities Phone: (781) 391-3464 Message-Id: Date: Tue, 25 Jun 2002 09:43:57 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 4.2 Creating multiple SAs for a single pair of entities 4.2.A) How important is it that SOI be able to create multiple SA's between a pair of entities "cheaply"? 4.2.B) How often will usage scenarios of SOI need to generate multiple SA's between a single pair of entites? Implications from the Scenarios: VPN: <<>> [[[4.2]]] VPN, End-to-END, SRA : <<>> [[[4.2]]] SRA: <<>> [[[4.2]]] SRA: <<>> [[[4.2]]] From owner-ipsec@lists.tislabs.com Tue Jun 25 07:13:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PED0w23481; Tue, 25 Jun 2002 07:13:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12649 Tue, 25 Jun 2002 09:29:57 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.1 Control channel vs. separate protocols Phone: (781) 391-3464 Message-Id: Date: Tue, 25 Jun 2002 09:42:54 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Notes from the chair: This question basically introduces the various questions raised by section 4 of the soi-features document, which goes to one of the biggest differences to the JFK and IKEv2 approach. 4. One or two phases 4.1 Control channel vs. separate protocols 4.1.A) [Meta question, that will be answered by the other questions in section 4.] Does SOI need a control channel for SA management? Or is it acceptable to piggy back SA management as a part of other parts of the SOI protocol? Implications from the Scenarios: VPN: <<>> [[[4.1]]] From owner-ipsec@lists.tislabs.com Tue Jun 25 07:18:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PEIvw23742; Tue, 25 Jun 2002 07:18:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12703 Tue, 25 Jun 2002 09:42:09 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.3 Dead peer detection Phone: (781) 391-3464 Message-Id: Date: Tue, 25 Jun 2002 09:55:36 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 4.3 Dead peer detection 4.3.A) Both JFK and IKEv2 provide dead peer detection via a "keep-alive" mechanism. The functionality provided is roughly identical. Does anyone care about how low-level implementation details of IKEv2 and JFK? 4.3.B) Should the working group consider other schemes which provide the same functionality as dead peer detection? (i.e., birth certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Tue Jun 25 07:41:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PEfgw26206; Tue, 25 Jun 2002 07:41:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12791 Tue, 25 Jun 2002 10:04:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 25 Jun 2002 10:16:10 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:43 AM -0400 6/25/02, Theodore Ts'o wrote: >Please discuss and answer this question: > > >4.2 Creating multiple SAs for a single pair of entities > >4.2.A) How important is it that SOI be able to create multiple SA's >between a pair of entities "cheaply"? If the cost of creating multiple SAs between two entities is too high, it will discourage use of separate keys for distinct traffic flows that should receive separate SAs, e.g., for security reasons or for QoS reasons. For this reason I feel that this is an important requirement. >4.2.B) How often will usage scenarios of SOI need to generate multiple >SA's between a single pair of entites? > >Implications from the Scenarios: > >VPN: <<total cost; this will be different for different mechanisms, which >results in a decision of scalability -vs- processing overhead. In >certain cases, it may be desirable to amortize the cost of the key >management across multiple tunnels.>>> [[[4.2]]] good example. >VPN, End-to-END, SRA : <<tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels >needs to accommodate QoS information, predominantly in the set of >selectors used to identify the contents of any particular IPsec >tunnel.>>> [[[4.2]]] another good example. Steve From owner-ipsec@lists.tislabs.com Tue Jun 25 08:04:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PF4kw26806; Tue, 25 Jun 2002 08:04:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12807 Tue, 25 Jun 2002 10:24:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 25 Jun 2002 10:32:35 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: SOI QUESTION: 4.1 Control channel vs. separate protocols Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:42 AM -0400 6/25/02, Theodore Ts'o wrote: >Notes from the chair: > >This question basically introduces the various questions raised by >section 4 of the soi-features document, which goes to one of the biggest >differences to the JFK and IKEv2 approach. > > >4. One or two phases > >4.1 Control channel vs. separate protocols > >4.1.A) [Meta question, that will be answered by the other questions in >section 4.] Does SOI need a control channel for SA management? Or is >it acceptable to piggy back SA management as a part of other parts of >the SOI protocol? having a separate control channel allows one to better amortize the cost of keep alive and other site-to-site messages between two sites that have multiple SAs. So, to the extent that one believes in the likelihood of multiple SAs between sites, having a long-lived control channel is preferable, irrespective of the efficiency of the protocol in establishing new SAs. Steve From owner-ipsec@lists.tislabs.com Tue Jun 25 08:06:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PF6Qw26871; Tue, 25 Jun 2002 08:06:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12819 Tue, 25 Jun 2002 10:28:26 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 3.4 Preferred ID for responder Date: Tue, 25 Jun 2002 10:41:34 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Please discuss and answer this question: > > 3.4 Preferred ID for responder > > 3.4.A) In JFK and IKEv2, the initiator can include a payload is an > indication to the responder as to what identity (and corresponding key > material) the responder should use to authenticate to the initiator. In > JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent > in the clear in message 1, thereby allowing a passive attack on the > responder's likely identity. Is it important to encrypt this identity? Isn't this the same question as 2.1.C? or am I just reading it wrong? > > Implications from the scenarios: > > [none] From owner-ipsec@lists.tislabs.com Tue Jun 25 08:17:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PFH4w27334; Tue, 25 Jun 2002 08:17:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12834 Tue, 25 Jun 2002 10:38:31 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 4.1 Control channel vs. separate protocols Date: Tue, 25 Jun 2002 10:51:40 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Notes from the chair: > > This question basically introduces the various questions raised by > section 4 of the soi-features document, which goes to one of the biggest > differences to the JFK and IKEv2 approach. > > > 4. One or two phases > > 4.1 Control channel vs. separate protocols > > 4.1.A) [Meta question, that will be answered by the other questions in > section 4.] Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? My belief is that a control channel would work best. > > Implications from the Scenarios: > > VPN: << SOI, or a single-phased approach that is sufficiently fast, where > "fast" represents an optimal combination of "number of messages" and > "computational expenditure".>>> [[[4.1]]] > > From owner-ipsec@lists.tislabs.com Tue Jun 25 08:17:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PFHrw27441; Tue, 25 Jun 2002 08:17:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12846 Tue, 25 Jun 2002 10:41:32 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 4.3 Dead peer detection Date: Tue, 25 Jun 2002 10:54:05 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Please discuss and answer this question: > > > 4.3 Dead peer detection > > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a > "keep-alive" mechanism. The functionality provided is roughly > identical. Does anyone care about how low-level implementation > details of IKEv2 and JFK? SOI MUST be able to handle black-hole detection & resource recovery. If a DPD type mechanism is the best way to handle that, then that's what we need to do. On a side note, I believe both JFK and IKEv2 use more of a "ping" than a "keep-alive" mechanism. The expression "keep-alive" tends to cause a knee-jerk reaction as developers tend to equate it to a "make-dead" mechanism. > > 4.3.B) Should the working group consider other schemes which provide > the same functionality as dead peer detection? (i.e., birth > certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) I was under the impression that birth certificates were more of an INITIAL-CONTACT replacement than DPD. In any case, to directly answer the question, we need to consider ALL schemes, as long as they address the requirements. > > Implications from the Scenarios: > > [none] From owner-ipsec@lists.tislabs.com Tue Jun 25 08:18:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PFIew27492; Tue, 25 Jun 2002 08:18:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12858 Tue, 25 Jun 2002 10:43:32 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities Date: Tue, 25 Jun 2002 10:56:30 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Please discuss and answer this question: > > > 4.2 Creating multiple SAs for a single pair of entities > > 4.2.A) How important is it that SOI be able to create multiple SA's > between a pair of entities "cheaply"? For scenarios like QoS, this could be very important. > > 4.2.B) How often will usage scenarios of SOI need to generate multiple > SA's between a single pair of entites? > > Implications from the Scenarios: > > VPN: << total cost; this will be different for different mechanisms, which > results in a decision of scalability -vs- processing overhead. In > certain cases, it may be desirable to amortize the cost of the key > management across multiple tunnels.>>> [[[4.2]]] > > VPN, End-to-END, SRA : << tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels > needs to accommodate QoS information, predominantly in the set of > selectors used to identify the contents of any particular IPsec > tunnel.>>> [[[4.2]]] > > SRA: << within the SOI exchange, it's strongly encouraged that the protocol > directly or indirectly associate a single user authentication exchange > with a group of IPsec tunnels between a client and an RAS.>>> > [[[4.2]]] > > SRA: << client to present its identity (or some "blob of bits" that the server > can correctly map to an identity) early in the exchange.>>> [[[4.2]]] From owner-ipsec@lists.tislabs.com Tue Jun 25 08:50:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PFoYw00122; Tue, 25 Jun 2002 08:50:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12922 Tue, 25 Jun 2002 11:12:58 -0400 (EDT) Message-Id: <5.1.0.14.2.20020625111939.02cc1e00@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 11:23:29 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: Re: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Please discuss and answer this question: > > >4.2 Creating multiple SAs for a single pair of entities > >4.2.A) How important is it that SOI be able to create multiple SA's >between a pair of entities "cheaply"? This is very important. I assume that "cheaply" means that cracking the keying material associated with one of these related SAs MIGHT disclose information that could help the attacker learn the keying material associated with the other related SAs. That is, there is no PFS. In my view, the scenarios provide justification. Russ From owner-ipsec@lists.tislabs.com Tue Jun 25 08:52:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PFqvw00380; Tue, 25 Jun 2002 08:52:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12934 Tue, 25 Jun 2002 11:17:58 -0400 (EDT) Message-ID: <3D188DB6.4040904@nortelnetworks.com> Date: Tue, 25 Jun 2002 11:35:18 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > Please discuss and answer this question: > > > 4.2 Creating multiple SAs for a single pair of entities > > 4.2.A) How important is it that SOI be able to create multiple SA's > between a pair of entities "cheaply"? Very. The two applications already pointed out on the list, viz., multi-level security (e.g. auth only channel and a separate auth+enc channel between the same two sites), and QoS, suggest that amortizing the cost of multiple SA establishment is a very important feature. Multi-channel multicast (for reliability and QoS) is another application that comes to mind. best, Lakshminath > > 4.2.B) How often will usage scenarios of SOI need to generate multiple > SA's between a single pair of entites? > > Implications from the Scenarios: > > VPN: << total cost; this will be different for different mechanisms, which > results in a decision of scalability -vs- processing overhead. In > certain cases, it may be desirable to amortize the cost of the key > management across multiple tunnels.>>> [[[4.2]]] > > VPN, End-to-END, SRA : << tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels > needs to accommodate QoS information, predominantly in the set of > selectors used to identify the contents of any particular IPsec > tunnel.>>> [[[4.2]]] > > SRA: << within the SOI exchange, it's strongly encouraged that the protocol > directly or indirectly associate a single user authentication exchange > with a group of IPsec tunnels between a client and an RAS.>>> > [[[4.2]]] > > SRA: << client to present its identity (or some "blob of bits" that the server > can correctly map to an identity) early in the exchange.>>> [[[4.2]]] > > From owner-ipsec@lists.tislabs.com Tue Jun 25 09:07:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PG7gw01565; Tue, 25 Jun 2002 09:07:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12947 Tue, 25 Jun 2002 11:24:58 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40CC8A022@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: andrew.krywaniuk@alcatel.com, "'Hallam-Baker, Phillip'" , "'Paul Koning'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Date: Tue, 25 Jun 2002 08:38:59 -0700 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 have yet to see a really convincing Formal Method for > > proving a protocol is secure. I very much doubt that such > > a calculus could exist. > > I don't doubt that it could exist, but I am certain that we > don't have it > (at least not for any comprehensive definition of "secure"). The lack of a comprehensive definition of secure is the problem. Sure we can develop a calculus that can be used to prove that code is free of buffer overrun bugs, but that is not the only type of bug. At the specification level things get much harder and the approach is still 'prove that the spec has every security property in the set X', but no way to know that the set X is complete. > > I believe that the value from formal methods comes from > > addressing a problem in an appropriate formalism so that the > > human brain needs to do less work to interpolate the gap > > from requirements to specification. > > I think we shouldn't understate the fact that we are building > a new protocol > out of building blocks of existing protocols. The fact that > we aren't doing > anything revolutionary is more comfort to me than a formal > proof. You start > by just following sound cryptographic principles: I don't find re-use of existing blocks all that comforting. Many security problems come from applying a security control out of the domain in which it has been demonstrated effective. Consider the arguments used to justify use of four digit pins on the Internet by analogy to ATM machines. > 1. Start with a fully vetted cryptographic core. > 2. Ensure that all inputs to the MAC are encoded in an > unambiguous form. > 3. Add entropy explicitly through a nonce, rather than > assuming that some > parameters are pseudo-random. > 4. Don't use the same key for multiple things. I agree that we probably know how to build a key agreement protocol. Certainly I think we know enough at this point to be able to develop new key agreements that are no more likely to fail than existing ones. > You can't test every permutation, but if your implementation > is modular > enough then you can test enough to get full coverage. I once > knew a guy who > wanted to verify the correctness of his 3DES implementation > by testing every > possible key. That still makes me laugh. Why? The approach works just fine for DES... Phill From owner-ipsec@lists.tislabs.com Tue Jun 25 09:16:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PGGiw02317; Tue, 25 Jun 2002 09:16:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13012 Tue, 25 Jun 2002 11:41:05 -0400 (EDT) Message-ID: <3D18930B.4090700@nortelnetworks.com> Date: Tue, 25 Jun 2002 11:58:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 4.1 Control channel vs. separate protocols References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > Notes from the chair: > > This question basically introduces the various questions raised by > section 4 of the soi-features document, which goes to one of the biggest > differences to the JFK and IKEv2 approach. > > > 4. One or two phases > > 4.1 Control channel vs. separate protocols > > 4.1.A) [Meta question, that will be answered by the other questions in > section 4.] Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? Yes, we need a control channel for SA management. Having to start a complete IKE exchange to delete an SA and for other similar tasks, is inefficient. Lakshminath > > Implications from the Scenarios: > > VPN: << SOI, or a single-phased approach that is sufficiently fast, where > "fast" represents an optimal combination of "number of messages" and > "computational expenditure".>>> [[[4.1]]] > > > > From owner-ipsec@lists.tislabs.com Tue Jun 25 09:52:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PGqXw04011; Tue, 25 Jun 2002 09:52:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18125 Tue, 25 Jun 2002 12:14:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15640.39432.549213.318699@pkoning.dev.equallogic.com> Date: Tue, 25 Jun 2002 12:27:52 -0400 From: Paul Koning To: pbaker@verisign.com Cc: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security References: <2F3EC696EAEED311BB2D009027C3F4F40CC8A022@vhqpostal.verisign.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Phill" == Hallam-Baker, Phillip writes: >> > I have yet to see a really convincing Formal Method for > >> proving a protocol is secure. I very much doubt that such > a >> calculus could exist. >> >> I don't doubt that it could exist, but I am certain that we don't >> have it (at least not for any comprehensive definition of >> "secure"). Phill> The lack of a comprehensive definition of secure is the Phill> problem. Phill> Sure we can develop a calculus that can be used to prove that Phill> code is free of buffer overrun bugs, but that is not the only Phill> type of bug. At the specification level things get much harder Phill> and the approach is still 'prove that the spec has every Phill> security property in the set X', but no way to know that the Phill> set X is complete. True. Correctness proofs in general are a tough thing to attempt. In my view, the value isn't necessarily in a complete proof of security, but rather in the fact that a formal analysis will turn up bugs that had not been found by other methods. paul From owner-ipsec@lists.tislabs.com Tue Jun 25 09:53:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PGrww04094; Tue, 25 Jun 2002 09:53:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18139 Tue, 25 Jun 2002 12:17:31 -0400 (EDT) Date: Tue, 25 Jun 2002 12:30:07 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTION: 4.3 Dead peer detection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Jun 2002, Theodore Ts'o wrote: > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a > "keep-alive" mechanism. No, only IKEv2 provides this. JFK claims that this functionality can be provided using an ordinary ping, which is incorrect. (It suggests that an implementation could allow only SAs which permitted suitable pings -- a restriction so severe that it would cripple interoperability. This is not a solution, it's an attempt to avoid providing a solution.) Also, speaking of this as a "keep-alive" is misleading (and likely to produce unnecessary adverse reactions). Dead-peer detection need not be used as a keep-alive. It is conceivable, indeed preferable, to probe the status of the peer only when there is specific evidence that something may be wrong, e.g. receipt of an unauthenticated error report suggesting that the peer's host has been rebooted. It might be better to refer to this feature as "dead-SA detection". That's the real issue. > The functionality provided is roughly > identical. Does anyone care about how low-level implementation > details of IKEv2 and JFK? Do I care how it's done? Not so long as it works, which JFK's current approach doesn't. Do I care whether it is precisely specified? *Yes*; it's important. JFK falls down again here. draft-ietf-ipsec-ikev2-02.txt section 6 nails down just how dead-SA detection is done, which is most welcome. The JFK draft needs equivalent detail; even if "let them send pings" was a workable way to probe the peer, probing is only one part of the solution, and the rest needs to be specified. > 4.3.B) Should the working group consider other schemes which provide > the same functionality as dead peer detection? (i.e., birth > certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) The crucial requirement is a way of reliably propagating authenticated information about the demise of SAs. Whether this is done in one step (authenticated error report or reboot report) or two (unauthenticated report followed by authenticated probe/response) is unimportant. It does seem to me, though, that the added protocol complexity of an authenticated probe/response facility is so slight that it is probably the most expedient solution. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jun 25 10:01:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PH1aw04260; Tue, 25 Jun 2002 10:01:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18153 Tue, 25 Jun 2002 12:25:33 -0400 (EDT) Date: Tue, 25 Jun 2002 12:38:26 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTION: 4.1 Control channel vs. separate protocols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Jun 2002, Theodore Ts'o wrote: > ...Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? Although JFK's simplicity is attractive, I fear a control channel is a practical necessity. "Other parts of the SOI protocol" simply aren't always available at the necessary times. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jun 25 10:31:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PHVuw04939; Tue, 25 Jun 2002 10:31:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18188 Tue, 25 Jun 2002 12:52:50 -0400 (EDT) Message-ID: <6F0AA176DA68704884B7507AE6907E18081858@snake012.odetics.com> From: Christina Helbig To: "'Theodore Ts'o'" , ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.4 Number of crypto operations Date: Tue, 25 Jun 2002 10:06:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I assume (correct me if I'm wrong) fast rekeying in the context of IKE is "...derive fresh SA keys from previously established secrets" and this is per definition without the property of PFS and in case of IKEv1 without a DH exponentiation but with additional exchanges of nonces. 1. IMO you can do that (fast rekeying without PFS) if the used established secret is secure against unauthorized access. 2. You must do that (fast rekeying without DH exponentiation) if you come with DH exponentiation to a computational border. I found different statements about the CPU time necessary for one exponentiation between 30ms and some seconds. In the draft-ietf-ips-security-13.txt it's time for rekeying for one SA by 10Gbps and 3DES in CBC mode all 27.5s or before 2^35 bytes are sent. Assume the case of some hundred SAs per peer with permanently irregularly distributed traffic between the SAs. Then rekeying at time is necessary for every SA all 27.5 s. This looks like a computational border, so you must have amount-based rekeying in this case and encrypted bytes or blocks must be counted for every SA. Is that a computational border too? 3. By the way, you can furthermore do fast rekeying without exchanges, that means with other protocols than Basic Quick Mode if you see exchanges as source of mistakes and DoS attacks. We have developed a protocol for fast rekeying without exchanges and would be happy if some folks could have a look at this and say if it makes sense or not () 4. So, finally I support the proposed formulation of Michael Thomas from June 24, about zero life for SOI SA to get a chance for using fast rekeying protocols outside of SOI. Outside of this question: There is another scenario for SOI: FC SAN > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Thursday, June 20, 2002 10:02 AM > To: ipsec@lists.tislabs.com > Subject: SOI QUESTIONS: 2.4 Number of crypto operations > > > > Please discuss and answer this question..... > > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? > From owner-ipsec@lists.tislabs.com Tue Jun 25 10:43:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PHhCw05162; Tue, 25 Jun 2002 10:43:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18203 Tue, 25 Jun 2002 13:04:02 -0400 (EDT) Date: 25 Jun 2002 13:04:26 -0400 Message-ID: <001601c21c6a$5d3fd250$0e6be640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" , " 'list'" Subject: SOI QUESTIONS: 3.4 - 4.3 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 V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3.4.A) In JFK and IKEv2, the initiator can include a payload is an > indication to the responder as to what identity (and > corresponding key > material) the responder should use to authenticate to the > initiator. In > JFKr and IKEv2, this value is encrypted in message 3; in > JFKi, it is sent > in the clear in message 1, thereby allowing a passive attack on the > responder's likely identity. Is it important to encrypt this identity? I think it depends on the WG's answer to 2.1.C. I would give the same answer: yes, because we can. > 4.1.A) [Meta question, that will be answered by the other questions in > section 4.] Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? Yes, I think we need a control channel. I don't think the control channel absolutely has to be a phase 1 SA, however that seems like the logical solution. An alternative would be a dedicated phase 2 SA, but I don't think anyone is proposing that. > 4.2.A) How important is it that SOI be able to create multiple SA's > between a pair of entities "cheaply"? "How fast should the protocol be?" is not really a yes or no question. We need to make optimizations wherever they will be useful. There are lots of scenarios where amortization of SA negotiation can be useful: a) When you negotiate multiple SAs at the same time. The use of multiple SAs can be replaced by a single SA with complex selectors in some cases, but QoS is an obvious counter-example. b) Handling protocols which use dynamic port assignment. Here you may either want to negotiate a new SA or update the selectors of an existing SA (aka policy agreement). Either case requires a management channel of some kind. c) In the remote access case, you use the DHCP configuration of tunnel mode protocol to setup an initial SA (or one of the forbidden protocols), and then immediately create a new SA with updated selectors. d) Just for speeding up phase 2 rekeying. I already explained in a previous thread how you can use a PFS interval to negotiate 2 SAs for the price of one DH (steady-state). > 4.2.B) How often will usage scenarios of SOI need to generate multiple > SA's between a single pair of entites? It certainly depends on the usage scenario. At this point, we can only speculate how widely QoS will be used in the future. Remote access will require it consistently. Some scenarios won't require it at all. > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a > "keep-alive" mechanism. The functionality provided is roughly > identical. Does anyone care about how low-level implementation > details of IKEv2 and JFK? Well yes, I care. I think that just "do a ping whenever you want" is a little too freeform. There should be some guidelines. Also, the messages should be replay-protected, which is done automatically in IKEv2 and optionally in JFK. Finally, piggybacking on data SAs is not exactly ideal. I think there should be a separate control channel. > 4.3.B) Should the working group consider other schemes which provide > the same functionality as dead peer detection? (i.e., birth > certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) Sure, let's consider them. Birth certificates handle one type of DPD, but they are not a self-contained solution. If a peer reboots and comes up at a different address then the system won't detect the failure. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Tue Jun 25 14:55:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PLtAw16437; Tue, 25 Jun 2002 14:55:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18578 Tue, 25 Jun 2002 17:10:04 -0400 (EDT) Reply-To: From: "Darren Dukes" To: "Michael Richardson" , Subject: RE: SOI QUESTIONS: 2.3 Authentication styles Date: Tue, 25 Jun 2002 17:22:44 -0400 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200206212042.g5LKfvn04795@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You are correct about XAUTH, but I was not suggesting XAUTH be used with IKEv2. What a legacy auth mechanism would permit is a SGW implementation with a local definition of a PW similar in appearance to a shared secret. While not being the same as a shared-secret it is likely similar enough for vendors to use if they have customers requiring a human-readable secret be distributed to many users/peers. Darren > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Friday, June 21, 2002 4:42 PM > To: ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 2.3 Authentication styles > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Darren" == Darren Dukes writes: > >> 2.3.B.) Does SOI need to natively support some kind of "shared > >> secret" scheme? (Or just certificates-only?) > Darren> Short answer: No but MUST support native legacy > authentication if > Darren> shared secrets don't exist. > > As far as I understand XAUTH, the need for shared secrets is > simply to be > able to get past the IKEv1 phase 1 exchange so that legacy auth > can be done. > > At no time does the legacy auth stuff get *used* as the shared secret. > > (Radius doesn't support returning the "password" to the gateway > machine, so > you can't do things that way, and there is no password for lots > of systems) > > So, XAUTH could have just as easily defined a group-shared RSA private > key, or SOI could define a single direction authentication system > (gateway->client). > > If possible, I'd like to see reuse of the SecSH userauth > protocol, carried > in SOI's phase1 instead. > > ] 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 > > iQCVAwUBPROPkIqHRg3pndX9AQHP4QQAhTH/M58nGvi1QWBU/4uxRRTXvPFbK+Y6 > BCRJkmJRZszgivg8d04ycsEp/pDZnxzOu9eDwCY1JLgtNeZBpK2b4v/kU0NPD8og > Ws1qjCE0CvT4IsoT4Jf1ovC7FyF5C+MyGankz85YJUf0yYH4BJyIBRoqZ7GsmL9y > 8teUfPA3ZCA= > =eVBT > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jun 25 17:28:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q0S0w25858; Tue, 25 Jun 2002 17:28:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18804 Tue, 25 Jun 2002 19:47:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20020625165013.04af4480@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jun 2002 16:59:27 -0700 To: ipsec@lists.tislabs.com From: Mark Baugher Subject: M-ID replaced by zero in QM Hash(3) of RFC 2409 Cc: dharkins@tibernian.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm having trouble accessing the ipsec archives so pardon the fact that I'm taking this question to the list: Why does the MAC/hash of the third Quick Mode message on p. 18 of http://www.ietf.org/rfc/rfc2409.txt use zero where the first two messages use the message id? thanks, Mark From owner-ipsec@lists.tislabs.com Tue Jun 25 19:27:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q2RAw29928; Tue, 25 Jun 2002 19:27:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19077 Tue, 25 Jun 2002 21:47:19 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Tue Jun 25 16:39:42 2002 Message-Id: <5.1.0.14.2.20020625111939.02cc1e00@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 11:23:29 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: Re: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Please discuss and answer this question: > > >4.2 Creating multiple SAs for a single pair of entities > >4.2.A) How important is it that SOI be able to create multiple SA's >between a pair of entities "cheaply"? This is very important. I assume that "cheaply" means that cracking the keying material associated with one of these related SAs MIGHT disclose information that could help the attacker learn the keying material associated with the other related SAs. That is, there is no PFS. In my view, the scenarios provide justification. Russ From owner-ipsec@lists.tislabs.com Tue Jun 25 19:27:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q2RBw29935; Tue, 25 Jun 2002 19:27:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19030 Tue, 25 Jun 2002 21:38:06 -0400 (EDT) Date: Tue, 25 Jun 2002 21:51:20 -0400 From: Ran Canetti Message-Id: <200206260151.VAA28430@ornavella.watson.ibm.com> To: ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please excuse the length of this note. I've been following this thread (the need for analysis) with great interest, and would like to make some remarks from the point of of view of a person who spent much of the past 13 years or so trying to analyze the security of protocols (and to understand what security means in the first place). The bottom line is that "security analysis" is not a binary do-it-and-be-done-with-it process. No single analysis of IKE/SOI is likely to ever be perfect or complete. Still, security analysis is indispensible. (There are so many protocols that were designed by smart and experienced people and were later found insecure via more careful analysis. STS is just one very relevant example.) It is thus crucial to obtain as many analyses of IKE as possbible, using as many tools as possible. And it is imperative to write the spec in a clear way that is conducive to analysis. A couple of more specific points: 1. IETF RFCs only provide the essentials for interoperabiltiy, plus maybe some implementation tips. They do NOT give a complete specification of a protocol. So even if a standard is "secure" in the sense that it is possible to implement it in a perfectly secure way, it is still possible (and easy...) to implement it in a fully compliant, yet grossly insecure way. This basic fact has two immediate consequences: -Being compliant with a "secure" IETF standard does NOT guarantee security. An implementation of the standard that wants to verify its security must use its own shrink and undergo its own analysis. -This of course does not mean that there is no point in analyzing the security of IKE/SOI. (If the standard is insecure then implementations have no hope of being secure.) However, what it does mean is that in analyzing IKE/SOI it is important to analyze the principles of the protocol design rather than the implementation details. Such higher-level analysis will be easier to apply to complying implementations. 2. There are numerous quite different approaches to analyzing security of protocols, where each approach has its own strong and weak points. Here are three main trends, going from the abstract to the concrete: * "Formal methods" style analysis. Here the protocol is first written in an abstract language where the basic cryptographic primitives (such as signature, encryption, hashing) are modeled as "ideal boxes". Next, this abstract protocol is run through an automatic state-analyzer that makes sure that no attacker can reach a state that was designated as udesired. The main strength of this approach is that it allows for automated (or semi-automated) proofs, and is thus less susceptible to human error. However, these methods provide only very partial security guarantee. One main discrepancy with "real-life" protocols is that the abstractions of the cryptographic primitives are often overly strong, and assume properties that are not obtainable by actual algorithms (such as RSA, DH, SHA1, etc). Thus, while this method is good in finding flaws in the overall structure of the protocol, it cannot guarantee security. * Cryptographic analysis. Here the protocol is represented in a much less abstract way, and the cryptographic primitives are represented in a way that is proven to be realizable via actual algorithms (under appropriate computational intractability assumptions). Consequently, here proofs of security are coonsiderably more meaningful and apply more directly to the actual "real-life" protocol. The down side of this analysis style is that it is inherently complex. Moreover to date we have no automation technology here, so proofs are hand-written and thus more susceptible to human errors. * Implementation analysis. Even the cryptographic approach typically makes numerous abstractions while representing and analyzing protocols. Typical axamples include implementation issues such as interaction with the operating system and the protocol stack, various buffer overflows, memory backups and erasures, auditing, etc. Unfortunately, experience shows us that many security flaws result from such issues. Thus direct analysis of the implementation is essential. Here, however, we have no complete analysis tools. Our only hope is to keep finding and fixing those flaws, and hope to do it faster than the rate in which new flaws are found... Clearly, IKE/SOI can benefit from analysis on all three levels described above, and the more the better. This holds both to the standard itself and to actual implementations of the standard. (And, even if it may seem that customers dont care about security analysis, I believe it is our duty and responsibility to seek it. Otherwise, lets just replace all crytographic operations with empty procedures. This way we'll have a very efficient and highly interoperable standard... ) Ran PS. The above note did not even touch the issue of what security properties should cryptographic (or formal-methods) analysis try to assert. This is a whole other can of worms... From owner-ipsec@lists.tislabs.com Tue Jun 25 19:29:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q2TEw29971; Tue, 25 Jun 2002 19:29:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19066 Tue, 25 Jun 2002 21:47:10 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Tue Jun 25 17:07:58 2002 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40CC8A022@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: andrew.krywaniuk@alcatel.com, "'Hallam-Baker, Phillip'" , "'Paul Koning'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Date: Tue, 25 Jun 2002 08:38:59 -0700 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 have yet to see a really convincing Formal Method for > > proving a protocol is secure. I very much doubt that such > > a calculus could exist. > > I don't doubt that it could exist, but I am certain that we > don't have it > (at least not for any comprehensive definition of "secure"). The lack of a comprehensive definition of secure is the problem. Sure we can develop a calculus that can be used to prove that code is free of buffer overrun bugs, but that is not the only type of bug. At the specification level things get much harder and the approach is still 'prove that the spec has every security property in the set X', but no way to know that the set X is complete. > > I believe that the value from formal methods comes from > > addressing a problem in an appropriate formalism so that the > > human brain needs to do less work to interpolate the gap > > from requirements to specification. > > I think we shouldn't understate the fact that we are building > a new protocol > out of building blocks of existing protocols. The fact that > we aren't doing > anything revolutionary is more comfort to me than a formal > proof. You start > by just following sound cryptographic principles: I don't find re-use of existing blocks all that comforting. Many security problems come from applying a security control out of the domain in which it has been demonstrated effective. Consider the arguments used to justify use of four digit pins on the Internet by analogy to ATM machines. > 1. Start with a fully vetted cryptographic core. > 2. Ensure that all inputs to the MAC are encoded in an > unambiguous form. > 3. Add entropy explicitly through a nonce, rather than > assuming that some > parameters are pseudo-random. > 4. Don't use the same key for multiple things. I agree that we probably know how to build a key agreement protocol. Certainly I think we know enough at this point to be able to develop new key agreements that are no more likely to fail than existing ones. > You can't test every permutation, but if your implementation > is modular > enough then you can test enough to get full coverage. I once > knew a guy who > wanted to verify the correctness of his 3DES implementation > by testing every > possible key. That still makes me laugh. Why? The approach works just fine for DES... Phill From owner-ipsec@lists.tislabs.com Tue Jun 25 19:32:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q2WYw00134; Tue, 25 Jun 2002 19:32:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19097 Tue, 25 Jun 2002 21:54:09 -0400 (EDT) Date: Tue, 25 Jun 2002 19:06:59 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 4.1 Control channel vs. separate protocols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Jun 2002, Theodore Ts'o wrote: > > Notes from the chair: > > This question basically introduces the various questions raised by > section 4 of the soi-features document, which goes to one of the biggest > differences to the JFK and IKEv2 approach. > > > 4. One or two phases > > 4.1 Control channel vs. separate protocols > > 4.1.A) [Meta question, that will be answered by the other questions in > section 4.] Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? > As has been pointed out, if you believe that there will be a need for multiple SA's between two peers, then an SA management channel is required to amortize the cost of the authentication. Based on the requirements document (Qos issues raised in several places, multiple tunnels between two SGW's, PE-to-PE encryption (which is similar to 'multiple tunnels between two SGW's), etc), I believe multiple SA's between peers is going to be needed. It also simplifies keepalives, delete notifications, and anything else needed to try to keep an ipsec connection healthy, which would otherwise have to be implemented in some other way (which seems more dangerous. I'd rather analyze a single protocol, than a suite of protocols). jan > Implications from the Scenarios: > > VPN: << SOI, or a single-phased approach that is sufficiently fast, where > "fast" represents an optimal combination of "number of messages" and > "computational expenditure".>>> [[[4.1]]] > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Jun 25 19:37:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q2bsw00223; Tue, 25 Jun 2002 19:37:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19115 Tue, 25 Jun 2002 22:00:10 -0400 (EDT) Date: Tue, 25 Jun 2002 19:13:51 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ditto. I seem to also remember (not an expert on this by any means) that IP storage had some requirements that pretty much required multiple IPsec tunnels, one for each iscsi connection, between iscsi hosts (or iscsi gateways?). See section 4.4.1.1 in cheryl's document. Also, section 4.5.1 PE-to-PE IPsec is in the fore-front of my mind, but is essentially the 'multiple tunnels between SGW's' scenario restated. jan On Tue, 25 Jun 2002, Stephen Kent wrote: > At 9:43 AM -0400 6/25/02, Theodore Ts'o wrote: > >Please discuss and answer this question: > > > > > >4.2 Creating multiple SAs for a single pair of entities > > > >4.2.A) How important is it that SOI be able to create multiple SA's > >between a pair of entities "cheaply"? > > If the cost of creating multiple SAs between two entities is too > high, it will discourage use of separate keys for distinct traffic > flows that should receive separate SAs, e.g., for security reasons or > for QoS reasons. For this reason I feel that this is an important > requirement. > > >4.2.B) How often will usage scenarios of SOI need to generate multiple > >SA's between a single pair of entites? > > > >Implications from the Scenarios: > > > >VPN: << >total cost; this will be different for different mechanisms, which > >results in a decision of scalability -vs- processing overhead. In > >certain cases, it may be desirable to amortize the cost of the key > >management across multiple tunnels.>>> [[[4.2]]] > > good example. > > >VPN, End-to-END, SRA : << >tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels > >needs to accommodate QoS information, predominantly in the set of > >selectors used to identify the contents of any particular IPsec > >tunnel.>>> [[[4.2]]] > > another good example. > > > Steve > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Jun 25 19:49:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q2nlw00407; Tue, 25 Jun 2002 19:49:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19174 Tue, 25 Jun 2002 22:12:14 -0400 (EDT) Date: Tue, 25 Jun 2002 19:25:32 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTIONS: 2.6 Formal proofs of security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would like to see a good analysis of the protocol done. That's valuable. 'Proofs' don't convince me personally, and could conceivably mislead the uninitiated. As Andrew pointed out, a proof finds only the problems you're looking for. Maybe I'm just not enough of a cryptographer or academic to be convinced of the value of the proofs in security... I'd rather see a protocol analysis. jan On Thu, 20 Jun 2002, Theodore Ts'o wrote: > > Please discuss and answer this question..... > > 2.6 Formal proofs of security > > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) > > Implications from the Scenarios: > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Jun 25 19:50:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q2oBw00433; Tue, 25 Jun 2002 19:50:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19162 Tue, 25 Jun 2002 22:09:11 -0400 (EDT) Date: Tue, 25 Jun 2002 19:21:58 -0700 (PDT) From: Jan Vilhuber To: Stephane Beaulieu cc: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 4.3 Dead peer detection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Jun 2002, Stephane Beaulieu wrote: > > > > > > > Please discuss and answer this question: > > > > > > 4.3 Dead peer detection > > > > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a > > "keep-alive" mechanism. The functionality provided is roughly > > identical. Does anyone care about how low-level implementation > > details of IKEv2 and JFK? > > SOI MUST be able to handle black-hole detection & resource recovery. If a > DPD type mechanism is the best way to handle that, then that's what we need > to do. > > On a side note, I believe both JFK and IKEv2 use more of a "ping" than a > "keep-alive" mechanism. The expression "keep-alive" tends to cause a > knee-jerk reaction as developers tend to equate it to a "make-dead" > mechanism. > In fact JFK (at least in the versions I've read. I haven't been able to keep up; I'm sure someone will correct me if I'm wrong) specifies EXACTLY using IP pings, requiring the IPsec SA to cover ICMP packets (or alternatively you establish a separate IPsec SA just for the pings, I guess). So to answer Ted's question: yes, I care about the details of implementation of IKEv2 and JFK. I don't much care for the hand-waving ping approach suggested by JFK, whereas IKEv2's approach is closer to the DPD mechanism suggested by Geoff Huang et.al. (now expired, looking for a home). If you believe (as I do) that multiple tunnels are needed between peers, then an IKE-level 'ping'/DPD/keepalive/whatever covers all IPsec Sa's created between the peers, which is more efficient. Another thought in the JFK approach: Assuming people still charge per-packet or bandwidth used, pings may (or may not; depends on the customer) need to be excluded from the 'charging/accounting'. This makes the ipsec code more complex, too. > > > > > 4.3.B) Should the working group consider other schemes which provide > > the same functionality as dead peer detection? (i.e., birth > > certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) > > I was under the impression that birth certificates were more of an > INITIAL-CONTACT replacement than DPD. In any case, to directly answer the > question, we need to consider ALL schemes, as long as they address the > requirements. > I was also under the impression that birth-certificates were more akin to Initial-contact, rather than real-time detection of connectivity problems. The two aren't necessarily the same. I seem to recall talking to folks who thought initial-contact together with DPD would be really nice and robust. Whether we replace initial-contact with birth-certificates, I don't really care about. jan > > > > Implications from the Scenarios: > > > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Jun 25 20:02:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q32Cw00610; Tue, 25 Jun 2002 20:02:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19199 Tue, 25 Jun 2002 22:20:20 -0400 (EDT) Date: Tue, 25 Jun 2002 19:33:12 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 3.3 Size of messages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William Dixon has pointed out the problems of large UDP packets in IKE (usually due to certificates) a few times. Although this isn't quite what the question below is about, I think we need to look at how we might handle large packets like this. I assume this would be an issue in either protocol (IKEv2 or JFK), so this would have to be a generalized debate. Some (note very good) thoughts: - Provide a URL for a certificate instead of the certificate (thus removing the certificate from the actual packet, making it smaller). - Provide some SOI fragmentation mechanism, so we don't have to rely on IP fragmentation. Yuck. I don't even want to think about this. jan On Fri, 21 Jun 2002, Theodore Ts'o wrote: > > Notes from the chair: > > >From reviewing the discussion in section 3.3 of the soi-features > document, it did not appear there were any material differences in the > message sizes between IKE or JFK. If others disagree with this > assessment, please state why, and why you think this is important for a > particular scenario. > > > 3.3 Size of messages > > There is no significant difference in the size of messages in the two > protocols. > > Implications from the scenarios: > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Jun 25 20:04:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q34sw00650; Tue, 25 Jun 2002 20:04:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19233 Tue, 25 Jun 2002 22:28:23 -0400 (EDT) Date: Tue, 25 Jun 2002 19:41:26 -0700 (PDT) From: Jan Vilhuber To: Stephane Beaulieu cc: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 3.4 Preferred ID for responder In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Jun 2002, Stephane Beaulieu wrote: > > > > > > > Please discuss and answer this question: > > > > 3.4 Preferred ID for responder > > > > 3.4.A) In JFK and IKEv2, the initiator can include a payload is an > > indication to the responder as to what identity (and corresponding key > > material) the responder should use to authenticate to the initiator. In > > JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent > > in the clear in message 1, thereby allowing a passive attack on the > > responder's likely identity. Is it important to encrypt this identity? > > Isn't this the same question as 2.1.C? or am I just reading it wrong? > It's certainly related. There have been cases (which I promised Dan I'd flesh out in more detail) where it's nice to have the initiator tell the responder who HE (the initiator) thinks the responder is. Does this blow the responder's cover? Maybe.... Example (as best I remember): You may want to host multiple 'domains' on a single SGW, but you don't want to burn up one IP address per virtual domain. The initiator may want to tell the responder which service they are trying to reach, so that the responder can reply with the appropriate credentials... I thought Charlie came up with a cute moniker for this, but I can't now remember what it was. I remember being for this, but it would be nice if we had some more concrete examples which could be debated... jan > > > > > Implications from the scenarios: > > > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Jun 25 20:48:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q3mLw01330; Tue, 25 Jun 2002 20:48:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19280 Tue, 25 Jun 2002 23:10:29 -0400 (EDT) Date: Tue, 25 Jun 2002 23:23:05 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: SOI QUESTION: 4.3 Dead peer detection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Jun 2002, Jan Vilhuber wrote: > ...I don't much care for the hand-waving > ping approach suggested by JFK, whereas IKEv2's approach is closer to > the DPD mechanism suggested by Geoff Huang et.al. (now expired... Also to what's suggested in draft-spencer-ipsec-ike-implementation-02.txt. > I was also under the impression that birth-certificates were more akin > to Initial-contact, rather than real-time detection of connectivity > problems. The two aren't necessarily the same. Birth certificates tackle the problem slightly differently: they permit authenticated, believable error reports from the other end. This isn't quite as useful as an IKE-level query/response mechanism, but it does address the primary problem, dead-SA detection. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jun 25 21:08:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q48Mw01581; Tue, 25 Jun 2002 21:08:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19365 Tue, 25 Jun 2002 23:32:33 -0400 (EDT) Date: 25 Jun 2002 23:33:15 -0400 Message-ID: <000e01c21cc2$35b01300$986de640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Jan Vilhuber'" Cc: "'list'" Subject: RE: SOI QUESTION: 3.3 Size of messages 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 V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Some (note very good) thoughts: > > - Provide a URL for a certificate instead of the certificate (thus > removing the certificate from the actual packet, making it smaller). Let us not forget that Paul already published a [IMHO very satisfactory] draft on how to do this. 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 Jan Vilhuber > Sent: Tuesday, June 25, 2002 10:33 PM > To: Theodore Ts'o > Cc: ipsec@lists.tislabs.com > Subject: Re: SOI QUESTION: 3.3 Size of messages > > > William Dixon has pointed out the problems of large UDP packets in IKE > (usually due to certificates) a few times. > > Although this isn't quite what the question below is about, I think we > need to look at how we might handle large packets like this. I assume > this would be an issue in either protocol (IKEv2 or JFK), so this > would have to be a generalized debate. > > Some (note very good) thoughts: > > - Provide a URL for a certificate instead of the certificate (thus > removing the certificate from the actual packet, making it smaller). > > - Provide some SOI fragmentation mechanism, so we don't have to rely > on IP fragmentation. Yuck. I don't even want to think about this. > > jan > > > On Fri, 21 Jun 2002, Theodore Ts'o wrote: > > > > > Notes from the chair: > > > > >From reviewing the discussion in section 3.3 of the soi-features > > document, it did not appear there were any material > differences in the > > message sizes between IKE or JFK. If others disagree with this > > assessment, please state why, and why you think this is > important for a > > particular scenario. > > > > > > 3.3 Size of messages > > > > There is no significant difference in the size of messages > in the two > > protocols. > > > > Implications from the scenarios: > > > > [none] > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > http://www.eff.org/cafe > From owner-ipsec@lists.tislabs.com Tue Jun 25 21:10:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q4ANw01633; Tue, 25 Jun 2002 21:10:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19350 Tue, 25 Jun 2002 23:30:32 -0400 (EDT) Date: 25 Jun 2002 23:31:03 -0400 Message-ID: <000d01c21cc1$e70a1a20$986de640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Housley, Russ'" , " 'list'" Subject: RE: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <5.1.0.14.2.20020625111939.02cc1e00@exna07.securitydynamics.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >4.2.A) How important is it that SOI be able to create multiple SA's > >between a pair of entities "cheaply"? > > This is very important. I assume that "cheaply" means that > cracking the > keying material associated with one of these related SAs > MIGHT disclose > information that could help the attacker learn the keying material > associated with the other related SAs. That is, there is no PFS. Actually, not necessarily. Typically, we have: skeyseed = PRF(g^xy, etc) key1 = PRF(skeyseed, nonce1, etc) key2 = PRF(skeyseed, nonce2, etc) key1 and key2 are both outputs of a one-way function, so assuming you delete skeyseed at some point then key1 and key2 are effectively unrelated. Therefore, as long as you delete skeyseed at some point, you will have PFS. (According to conventional wisdom, there is no reason to believe that it will be easier to reverse a PRF than to crack a DH.) Incidentally, IKEv1 had a feature (which no one implemented) where you could do bulk negotiation of SAs. This is not preserved in IKEv2, but it lets you trade off memory vs CPU or memory vs PFS. Theoretically, you could negotiate 10 keys in advance, delete skeyseed, and then use a modified quick mode to assign these keys to new SAs (thus giving you full PFS across rekeys without incurring any additional DHs). 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 Jun 26 07:22:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QEMZw12296; Wed, 26 Jun 2002 07:22:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20313 Wed, 26 Jun 2002 09:28:43 -0400 (EDT) Message-Id: <200206261040.GAA10253@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-nat-t-ike-03.txt Date: Wed, 26 Jun 2002 06:40:32 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Negotiation of NAT-Traversal in the IKE Author(s) : T. Kivinen et al. Filename : draft-ietf-ipsec-nat-t-ike-03.txt Pages : 11 Date : 25-Jun-02 This document describes how to detect one or more NATs between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-03.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-nat-t-ike-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020625141620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-t-ike-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625141620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jun 26 07:25:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QEPWw12484; Wed, 26 Jun 2002 07:25:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20325 Wed, 26 Jun 2002 09:32:46 -0400 (EDT) From: "Housley, Russ" To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020626093925.02c3f720@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Jun 2002 09:45:19 -0400 Subject: RE: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities In-Reply-To: <000d01c21cc1$e70a1a20$986de640@ca.alcatel.com> References: <5.1.0.14.2.20020625111939.02cc1e00@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew: > > >4.2.A) How important is it that SOI be able to create multiple SA's > > >between a pair of entities "cheaply"? > > > > This is very important. I assume that "cheaply" means that cracking the > > keying material associated with one of these related SAs MIGHT disclose > > information that could help the attacker learn the keying material > > associated with the other related SAs. That is, there is no PFS. > >Actually, not necessarily. Typically, we have: > >skeyseed = PRF(g^xy, etc) >key1 = PRF(skeyseed, nonce1, etc) >key2 = PRF(skeyseed, nonce2, etc) > >key1 and key2 are both outputs of a one-way function, so assuming you delete >skeyseed at some point then key1 and key2 are effectively unrelated. >Therefore, as long as you delete skeyseed at some point, you will have PFS. >(According to conventional wisdom, there is no reason to believe that it >will be easier to reverse a PRF than to crack a DH.) My point was that your keying material is vulnerable (from a PFS perspective) until both ends have deleted the shared secret values (skeyseed in your example) used to derive it. If the attacker learns skeyseed (from either end), then deriving the associated keying material is straightforward. However, once both ends have securely deleted skeyseed, it should be computationally infeasible to learn key1 or skeyseed from key2. Russ From owner-ipsec@lists.tislabs.com Wed Jun 26 07:51:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QEpew14077; Wed, 26 Jun 2002 07:51:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20428 Wed, 26 Jun 2002 10:08:59 -0400 (EDT) Message-Id: <200206261422.g5QEMHb21503@sydney.East.Sun.COM> Date: Wed, 26 Jun 2002 10:22:17 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: SOI QUESTION: 3.4 Preferred ID for responder To: stephane@cisco.com, vilhuber@cisco.com Cc: tytso@mit.edu, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ApoQhoVykxX7ZUElu/QcVw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan said: I thought Charlie came up with a cute moniker for this, but I can't now remember what it was. It was actually Hugh Daniel who came up with the cute moniker. It was "You Tarzan. Me Jane" Radia From owner-ipsec@lists.tislabs.com Wed Jun 26 08:49:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QFnRw16772; Wed, 26 Jun 2002 08:49:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20636 Wed, 26 Jun 2002 11:02:30 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B1D@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Ran Canetti'" , ipsec@lists.tislabs.com Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Date: Wed, 26 Jun 2002 08:16:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In response to Ran's note I suspect that all the people in the thread actually have a mutually compatible view of what formal methods can do and what should be required. Some of the negativity in my posts probably comes from the fact that having seen Formal methods massively oversold I think it is important to set expectations. Clearly formal methods can add significant value. However what people have been cautioning against is setting the bar to SOI to be a formal 'proof of security' ignoring the fact that what consitutes a proof of security is highly debatable (even in forums other than IETF mailing lists where anything is highly debatable), and the fact that we did not put IKE through that analysis. I think it would be quite reasonable to state specific empirical tests that a SOI protocol should pass, provided that the analysis methods involved do not introduce arbitrary constraints into the solution space whose only purpose is to allow the analysis. Phill From owner-ipsec@lists.tislabs.com Thu Jun 27 08:17:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RFH0w28163; Thu, 27 Jun 2002 08:17:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22822 Thu, 27 Jun 2002 10:16:38 -0400 (EDT) Date: Thu, 27 Jun 2002 16:29:38 +0200 (MET DST) Message-Id: <200206271429.QAA04365@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 3.1 DoS protection In-Reply-To: References: Organization: =?UTF-8?B?RA==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more > important to always keep the message count at 4, or is it acceptable to add > an additional roundtrip of messages when the responder thinks he's under > attack? Unless the 6 messages approach allows to shorten some messages (mess 3, more accurately) enough to prevent from udp fragmentation DOS, I don't see it's advantage for 'ip level' DOS protection: 4 messages should be enough for it. A 6 messages scenario may help to reduce the protocol complexity and to provide better understanding. As I like the paranoid position of thinking we are always under attack, and because I believe SOI should be as stupid as possible, I wonder if even the 4 messages + 1 roundtrip under attack is not already too complex by introducing a variant. In a nutshell, my question is: Is it costly to do systematically with 6 messages ? Have we got a sufficient experience/feedback on ike main mode to know if 6 is usually too many, or if it is always bearable ? I am sorry if it has been discussed before, but I could not find any piece of information which would help me to make up my opinion on this point. I think Phill's advise about using a locator url in order to retrieve auth info should be considered in order to tackle mess 3 length' problem. But care must be taken that it does not allow to work indirect attack against the url. Using locator url may also enable DOS thanks to DNS poisonning, but it may happen also when using certificates (with a pki). > 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide > basically equivalent protection. Does anyone care about the details of how > JFK or IKEv2 provide this functionality. I don't care about the details, but as I think some layer violation is likely to happen, this violation should be as ``clean'' as possible (I know that's a bit unclear, sorry). > 3.1.C) Is it important to have precomputation of exponentials available for > use as a mechanism for protecting against cpu consumption attacks? I think it is an implementation matter, though it should usually be a good idea. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Thu Jun 27 08:17:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RFH0w28160; Thu, 27 Jun 2002 08:17:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22852 Thu, 27 Jun 2002 10:32:43 -0400 (EDT) Date: Thu, 27 Jun 2002 16:45:35 +0200 (MET DST) Message-Id: <200206271445.QAA04450@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 3.2 Number of messages in all scenarios In-Reply-To: References: Organization: =?UTF-8?B?RA==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3.2 Number of messages in all scenarios > > 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in > message one. In IKEv2 if Bob doesn't accept what Alice offers the > negotiation starts again. In JFK if Bob doesn't accept what Alice offers > but Alice can live with what Bob offers, they continue. Otherwise they > start over. Is this an important feature for SOI? Bob's fail-back offer will help if it has no significant impact on the whole end protocol complexity. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Thu Jun 27 08:29:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RFTOw03966; Thu, 27 Jun 2002 08:29:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22935 Thu, 27 Jun 2002 10:51:10 -0400 (EDT) Date: Thu, 27 Jun 2002 17:04:30 +0200 (MET DST) Message-Id: <200206271504.RAA04593@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 3.4 Preferred ID for responder In-Reply-To: References: Organization: =?UTF-8?B?RDhY?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3.4 Preferred ID for responder > > 3.4.A) In JFK and IKEv2, the initiator can include a payload is an > indication to the responder as to what identity (and corresponding key > material) the responder should use to authenticate to the initiator. In > JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent > in the clear in message 1, thereby allowing a passive attack on the > responder's likely identity. Is it important to encrypt this identity? Identity protection against passive attack is the least we may want (IMO), and we should encrypt this identity (at a cost for message 3 length), though it may have no meaning at all to the eavesdropper. I fear that hosting several ids on a single host/gw and allowing the initiator to express an identity choice for the responder may be a bit messy. For me, it can be again politics/diplomacy, so I would like some concrete examples presented me too. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Thu Jun 27 11:40:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RIe2w17047; Thu, 27 Jun 2002 11:40:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23305 Thu, 27 Jun 2002 13:57:14 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.7 Authenticated informational messages Phone: (781) 391-3464 Message-Id: Date: Thu, 27 Jun 2002 14:10:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 4.7 Authenticated informational messages 4.7.A) Does SOI need to provide authenticated informational messages after an IKE SA has been set up? (What sort of informational messages might be needed? Do they need to be protected in a different key than the SA key?) Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Thu Jun 27 11:41:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RIfnw17904; Thu, 27 Jun 2002 11:41:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23287 Thu, 27 Jun 2002 13:56:08 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.4 SA deletion Phone: (781) 391-3464 Message-Id: Date: Thu, 27 Jun 2002 14:09:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 4.4 SA deletion 4.4.A) Both JFK and IKEv2 provide SA deletion. The functionality provided is roughly identical. Does anyone care about how low-level implementation details of IKEv2 and JFK? Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Thu Jun 27 11:41:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RIfrw17946; Thu, 27 Jun 2002 11:41:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23303 Thu, 27 Jun 2002 13:57:09 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.5 SA rekeying Phone: (781) 391-3464 Message-Id: Date: Thu, 27 Jun 2002 14:09:47 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 4.5 SA rekeying 4.5.A) Both JFK and IKEv2 provide SA rekeying. The functionality provided is roughly identical, although JFK requires more cryptographic operations to do rekeying (see 2.4). Does anyone care about how low-level implementation details of IKEv2 and JFK? Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Thu Jun 27 11:42:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RIg6w18062; Thu, 27 Jun 2002 11:42:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23304 Thu, 27 Jun 2002 13:57:11 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.6 Authenticated error messages Phone: (781) 391-3464 Message-Id: Date: Thu, 27 Jun 2002 14:10:06 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 4.6 Authenticated error messages 4.6.A) Both JFK and IKEv2 provide authenticated error messages. The functionality provided is roughly identical, although details very different due to the lack of a 2 phase protocol in JFK. Does anyone care about how low-level implementation details of IKEv2 and JFK? Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Thu Jun 27 11:43:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RIhQw18653; Thu, 27 Jun 2002 11:43:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23317 Thu, 27 Jun 2002 13:58:12 -0400 (EDT) Message-ID: <00d401c21e06$3641bc70$a9f22b42@mv.lucent.com> From: "David Faucher" To: Subject: Re: SOI QUESTION: 3.1 DoS protection Date: Thu, 27 Jun 2002 13:10:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | | Notes from the chair: | | This next set of questions address the issues listed in section 3 of the | soi-features I-D, "Protocol Mechanics". | | | Please discuss and answer: | | 3.1 DoS protection | | 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more | important to always keep the message count at 4, or is it acceptable to add | an additional roundtrip of messages when the responder thinks he's under | attack? | Optionally adding an additional round trip creates another path through the negotiation that is similar to providing different modes (e.g. main and aggressive). I'm not opposed to the additional round trip, just the fact that it is optional. | 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide | basically equivalent protection. Does anyone care about the details of how | JFK or IKEv2 provide this functionality. | Not sure I understand how they provide protection. With IKEv2 as soon as an attacker witnesses an exchange it can then begin to flood the node with fragments that look as if they came from one of the nodes in the exchange. With JFK once a valid fragment has been seen, the id field can then be used to send invalid fragments. Am I missing something here? | 3.1.C) Is it important to have precomputation of exponentials available for | use as a mechanism for protecting against cpu consumption attacks? | Implementation detail. | Implications from the scenarios: | | [none] | From owner-ipsec@lists.tislabs.com Thu Jun 27 11:44:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RIiew19205; Thu, 27 Jun 2002 11:44:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23316 Thu, 27 Jun 2002 13:58:10 -0400 (EDT) Message-ID: <00d501c21e06$37e162b0$a9f22b42@mv.lucent.com> From: "David Faucher" To: Subject: Re: SOI QUESTION: 4.3 Dead peer detection Date: Thu, 27 Jun 2002 13:11:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | | Please discuss and answer this question: | | | 4.3 Dead peer detection | | 4.3.A) Both JFK and IKEv2 provide dead peer detection via a | "keep-alive" mechanism. The functionality provided is roughly | identical. Does anyone care about how low-level implementation | details of IKEv2 and JFK? | Details of this type of functionality is absolutely necessary for interoperability. For example, with JFK what would be the inner addresses of the ping for a tunnel setup between two gateways? | 4.3.B) Should the working group consider other schemes which provide | the same functionality as dead peer detection? (i.e., birth | certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) | Yes, a more proactive solution would help speed up the recovery process after a system crash. Note that for those systems that do not have a way of storing incrarnation numbers across a reboot, the initial-contact message would be acceptable. | Implications from the Scenarios: | | [none] From owner-ipsec@lists.tislabs.com Thu Jun 27 14:56:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RLujw29783; Thu, 27 Jun 2002 14:56:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23699 Thu, 27 Jun 2002 17:15:05 -0400 (EDT) Date: Thu, 27 Jun 2002 14:28:29 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: IP Security List Subject: Re: apology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, unless you are a conspiracy theorist or something, this is pretty much common knowledge. No one represents the corporation cisco, like no one represents bbn. So, people brought this to your attention! Wonder why you think "we" meant cisco and not just people who agree with me. If some one puts out a draft and the author is from cisco, does it mean the proposal is from cisco?! chinna On Fri, 21 Jun 2002, Stephen Kent wrote: > It was brought to my attention that Chinna is just one of several > Cisco employee participating in the IPsec discussions, and that his > "unique" perspective on matters ought not be viewed as representative > of the organization. BBN is now part of a very large organization, > and I am sensitive to the difference between individual and corporate > positions. So, despite the use of "we" by Chinna in his postings, I > will not assume that his postings represent a corporate stance, and > thus refrain from criticizing the organization as a whole. > > That said, there is also probably no need to continue the debate with > Chinna as an individual. > > Steve > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Thu Jun 27 18:39:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5S1dSw19362; Thu, 27 Jun 2002 18:39:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23995 Thu, 27 Jun 2002 20:59:00 -0400 (EDT) Date: 27 Jun 2002 20:59:33 -0400 Message-ID: <001201c21e3f$11a2cc90$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'David Faucher'" , " 'list'" Subject: RE: SOI QUESTION: 3.1 DoS protection 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <00d401c21e06$3641bc70$a9f22b42@mv.lucent.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Optionally adding an additional round trip creates another > path through > the negotiation that is similar to providing different modes > (e.g. main > and aggressive). I'm not opposed to the additional round > trip, just the > fact that it is optional. Actually, it is more akin to the "abort and retry with new parameters" condition that is already present in both protocols. > Not sure I understand how they provide protection. With IKEv2 > as soon as > an attacker witnesses an exchange it can then begin to flood > the node with > fragments that look as if they came from one of the nodes in > the exchange. Just like cookies, this feature is aimed at the class of DoS attacks where the attacker cannot sniff along the data path. Therefore, the attacker cannot "witness an exchange". ------------------------------------------- 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 David Faucher > Sent: Thursday, June 27, 2002 2:10 PM > To: ipsec@lists.tislabs.com > Subject: Re: SOI QUESTION: 3.1 DoS protection > > > | > | Notes from the chair: > | > | This next set of questions address the issues listed in > section 3 of the > | soi-features I-D, "Protocol Mechanics". > | > | > | Please discuss and answer: > | > | 3.1 DoS protection > | > | 3.1.A) WRT DOS attacks that exhaust memory or CPU > resources, is it more > | important to always keep the message count at 4, or is it > acceptable to > add > | an additional roundtrip of messages when the responder > thinks he's under > | attack? > | > > Optionally adding an additional round trip creates another > path through > the negotiation that is similar to providing different modes > (e.g. main > and aggressive). I'm not opposed to the additional round > trip, just the > fact that it is optional. > > | 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 > and JFK provide > | basically equivalent protection. Does anyone care about the > details of how > | JFK or IKEv2 provide this functionality. > | > > Not sure I understand how they provide protection. With IKEv2 > as soon as > an attacker witnesses an exchange it can then begin to flood > the node with > fragments that look as if they came from one of the nodes in > the exchange. > With JFK once a valid fragment has been seen, the id field > can then be used > to send invalid fragments. Am I missing something here? > > | 3.1.C) Is it important to have precomputation of > exponentials available > for > | use as a mechanism for protecting against cpu consumption attacks? > | > > Implementation detail. > > | Implications from the scenarios: > | > | [none] > | > > From owner-ipsec@lists.tislabs.com Thu Jun 27 20:06:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5S36Nw17968; Thu, 27 Jun 2002 20:06:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24117 Thu, 27 Jun 2002 22:29:07 -0400 (EDT) Date: 27 Jun 2002 22:29:38 -0400 Message-ID: <001301c21e4b$a74ac1b0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" , " 'list'" Subject: RE: SOI QUESTIONS: 4.4 - 4.7 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 V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 4.4.A) Both JFK and IKEv2 provide SA deletion. The functionality > provided is roughly identical. Does anyone care about how low-level > implementation details of IKEv2 and JFK? This is pretty much a Boolean feature. You can either delete SAs or you can't. Of course, the difference is that IKEv2 deletes SAs using an already existant control channel. Do I care about the low-level details? Of course I do. I object to the method described in JFK due to its obvious kludginess. I can't imagine how someone would prefer to negotiate an SA with identitical selectors but protocol ESP_BYPASS rather than to just say "please delete the ESP SA with SPI X". > 4.5.A) Both JFK and IKEv2 provide SA rekeying. The functionality > provided is roughly identical, although JFK requires more > cryptographic operations to do rekeying (see 2.4). Does anyone care > about how low-level implementation details of IKEv2 and JFK? I care about the details of rekeying as it relates to PFS, but we covered that with an earlier thread. I also think we need to learn from the problems we experienced with rekeying in IKEv1. IKEv2 mandates continuous channel mode, so that solves one big issue. I would also like SOI to prescribe a more deterministic timeline for SA switchover, so we can eliminate some of the problematic race conditions. E.g.: 1:00:00 - negotiate original SAs (with local lifetime of 1 hour) 1:52:07 - new negotiation begins at jittered rekey threshhold 1:52:09 - negotiation completes and new SAs are installed (but initially inactive) 1:52:39 - switch over to new SAs after grace window to allow for lost IKE packets 1:53:09 - delete old SAs after grace window to allow for delayed IPsec packets > 4.6.A) Both JFK and IKEv2 provide authenticated error messages. The > functionality provided is roughly identical, although details very > different due to the lack of a 2 phase protocol in JFK. Does anyone > care about how low-level implementation details of IKEv2 and JFK? Do they? Correct me if I'm wrong, but I didn't see anything about authenticated error messages in the JFK draft. As far as I know, "reject info to message 1" is not authenticated. As for message 3, I searched through the draft for quite a while and mused on the subject. You are supposed to cache the authenticator for message 3 in order to detect replays, and if message 3 is rejected then you are supposed to cache the GRPINFO along with the authenticator so you can reply quickly. Presumably you don't want to recalculate the DH key in this case, so that implies to me that the error message is not authenticated. But I could be wrong... I'm not sure anyone has actually thought this through before. To me, the important distinction is the number of possible error messages in the protocol. The messages in IKEv1 weren't perfect, but I don't see that as justification for removing them altogether. I'd like to be able to give some indication of the error to the peer. JFK provides no opportunity for this, except in the case of an algorithm mismatch. In reality, the danger that we will act as an oracle is very slight. Overall, I think the exact specification of the error definitions still needs some work, and this is something I hope to clarify after we finalize the general approach. > 4.7.A) Does SOI need to provide authenticated informational messages > after an IKE SA has been set up? (What sort of informational messages > might be needed? Do they need to be protected in a different key than > the SA key?) I'm not totally sure why this is a different issue from 4.6.A. In the past, we had Delete, Initial Contact, Responder Lifetime, and Replay Enabled. There were also some proprietary IKE pings using the notify messages and the ever-quixotic "Notify Like When Is That Ever Right", whose ultimate intent I never did discern. I guess the Responder Lifetime notify is now obsolete, but the others shouldn't be. Also, in an ealier thread I proposed a new Delete Keymat notify which would allow the peers to coordinate when to refresh the DH exponential. Informational messages are such a multifaceted and forward-looking feature that I really wouldn't like to see them deprecated. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Jun 27 20:06:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5S36gw18083; Thu, 27 Jun 2002 20:06:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24137 Thu, 27 Jun 2002 22:32:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 27 Jun 2002 22:37:30 -0400 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: apology Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:28 PM -0700 6/27/02, Chinna N.R. Pellacuru wrote: >Steve, unless you are a conspiracy theorist or something, this is pretty >much common knowledge. No one represents the corporation cisco, like no >one represents bbn. So, people brought this to your attention! Wonder why >you think "we" meant cisco and not just people who agree with me. If some >one puts out a draft and the author is from cisco, does it mean the >proposal is from cisco?! > > chinna > Since it has become clear that most of your colleagues are embarrassed by your postings on this list and that you do not represent your employer's position in any way, I see no point in wasting time responding to your rants. Steve From owner-ipsec@lists.tislabs.com Thu Jun 27 20:28:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5S3Sdw26909; Thu, 27 Jun 2002 20:28:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24178 Thu, 27 Jun 2002 22:49:07 -0400 (EDT) Date: Thu, 27 Jun 2002 20:02:07 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: IP Security List Subject: Re: apology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'll take your word for it, but none of "my colleagues" told me so. So, you will respond to only those who represent their employer's position? How do you determine that? Probably those who agree with you, represent their employers! everyone else don't! I really don't see why we should bring this discussion to a personal level or a corporate level. Anyway thanks a lot for letting me know what "my colleages" are thinking about me. Without you being honest, I would have never known what "my colleagues" are thinking about me and my discussions on this list. I hope you continue doing this in the future too, and to everyone on this list. It is really helpful to know the truth. chinna On Thu, 27 Jun 2002, Stephen Kent wrote: > At 2:28 PM -0700 6/27/02, Chinna N.R. Pellacuru wrote: > >Steve, unless you are a conspiracy theorist or something, this is pretty > >much common knowledge. No one represents the corporation cisco, like no > >one represents bbn. So, people brought this to your attention! Wonder why > >you think "we" meant cisco and not just people who agree with me. If some > >one puts out a draft and the author is from cisco, does it mean the > >proposal is from cisco?! > > > > chinna > > > > Since it has become clear that most of your colleagues are > embarrassed by your postings on this list and that you do not > represent your employer's position in any way, I see no point in > wasting time responding to your rants. > > Steve > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Fri Jun 28 02:57:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5S9vVw11700; Fri, 28 Jun 2002 02:57:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA24845 Fri, 28 Jun 2002 05:14:31 -0400 (EDT) From: jsjoberg@toplayer.com Message-ID: To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: apology Date: Fri, 28 Jun 2002 05:28:07 -0400 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 The technical input of this thread is absolutely riveting. Steve, thank you for starting this thread and helping make this whole process work! Jon > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, June 27, 2002 10:38 PM > To: Chinna N.R. Pellacuru > Cc: IP Security List > Subject: Re: apology > > > At 2:28 PM -0700 6/27/02, Chinna N.R. Pellacuru wrote: > >Steve, unless you are a conspiracy theorist or something, > this is pretty > >much common knowledge. No one represents the corporation > cisco, like no > >one represents bbn. So, people brought this to your > attention! Wonder why > >you think "we" meant cisco and not just people who agree > with me. If some > >one puts out a draft and the author is from cisco, does it mean the > >proposal is from cisco?! > > > > chinna > > > > Since it has become clear that most of your colleagues are > embarrassed by your postings on this list and that you do not > represent your employer's position in any way, I see no point in > wasting time responding to your rants. > > Steve > From owner-ipsec@lists.tislabs.com Fri Jun 28 05:52:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SCqFw11700; Fri, 28 Jun 2002 05:52:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25115 Fri, 28 Jun 2002 08:08:47 -0400 (EDT) Message-ID: <001d01c21e9e$a3840700$a9f22b42@mv.lucent.com> From: "David Faucher" To: , " 'list'" References: <001201c21e3f$11a2cc90$1e72788a@ca.alcatel.com> Subject: Re: SOI QUESTION: 3.1 DoS protection Date: Fri, 28 Jun 2002 07:23:34 -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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Andrew Krywaniuk" | > Optionally adding an additional round trip creates another | > path through | > the negotiation that is similar to providing different modes | > (e.g. main | > and aggressive). I'm not opposed to the additional round | > trip, just the | > fact that it is optional. | | Actually, it is more akin to the "abort and retry with new parameters" | condition that is already present in both protocols. | I can see you point but, I'm still opposed to it being optional. | | > Not sure I understand how they provide protection. With IKEv2 | > as soon as | > an attacker witnesses an exchange it can then begin to flood | > the node with | > fragments that look as if they came from one of the nodes in | > the exchange. | | Just like cookies, this feature is aimed at the class of DoS attacks where | the attacker cannot sniff along the data path. Therefore, the attacker | cannot "witness an exchange". | Now I understand. Thanks for the clarification. | ------------------------------------------- | 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 David Faucher | > Sent: Thursday, June 27, 2002 2:10 PM | > To: ipsec@lists.tislabs.com | > Subject: Re: SOI QUESTION: 3.1 DoS protection | > | > | > | | > | Notes from the chair: | > | | > | This next set of questions address the issues listed in | > section 3 of the | > | soi-features I-D, "Protocol Mechanics". | > | | > | | > | Please discuss and answer: | > | | > | 3.1 DoS protection | > | | > | 3.1.A) WRT DOS attacks that exhaust memory or CPU | > resources, is it more | > | important to always keep the message count at 4, or is it | > acceptable to | > add | > | an additional roundtrip of messages when the responder | > thinks he's under | > | attack? | > | | > | > Optionally adding an additional round trip creates another | > path through | > the negotiation that is similar to providing different modes | > (e.g. main | > and aggressive). I'm not opposed to the additional round | > trip, just the | > fact that it is optional. | > | > | 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 | > and JFK provide | > | basically equivalent protection. Does anyone care about the | > details of how | > | JFK or IKEv2 provide this functionality. | > | | > | > Not sure I understand how they provide protection. With IKEv2 | > as soon as | > an attacker witnesses an exchange it can then begin to flood | > the node with | > fragments that look as if they came from one of the nodes in | > the exchange. | > With JFK once a valid fragment has been seen, the id field | > can then be used | > to send invalid fragments. Am I missing something here? | > | > | 3.1.C) Is it important to have precomputation of | > exponentials available | > for | > | use as a mechanism for protecting against cpu consumption attacks? | > | | > | > Implementation detail. | > | > | Implications from the scenarios: | > | | > | [none] | > | | > | > | From owner-ipsec@lists.tislabs.com Fri Jun 28 06:37:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SDbow27529; Fri, 28 Jun 2002 06:37:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29890 Fri, 28 Jun 2002 08:42:54 -0400 (EDT) Message-ID: <003501c21ea3$6d37c830$a9f22b42@mv.lucent.com> From: "David Faucher" To: Subject: JFK negotiation Date: Fri, 28 Jun 2002 07:57:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For JFK negotiations shouldn't message 4 contain as its first field, Ni (to differentiate between different parallel sessions)? David From owner-ipsec@lists.tislabs.com Fri Jun 28 08:39:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SFd2w08723; Fri, 28 Jun 2002 08:39:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00042 Fri, 28 Jun 2002 10:25:30 -0400 (EDT) X-Authentication-Warning: kaakeli.ssh.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15639.9155.804488.510224@kaakeli.ssh.fi> Date: Mon, 24 Jun 2002 16:50:59 +0300 From: Tero Kivinen To: tytso@mit.edu ("Theodore Ts'o"), ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 3.1, 3.2. X-Mailer: VM 7.00 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 33 min X-Total-Time: 39 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 2.1.A.) Does SOI need to provide protection against passive > attacks for the initiator? Yes. > 2.1.B.) Does SOI need to provide protection against active > attacks for the initiator? No. > 2.1.C.) Does SOI need to provide protection against passive > attacks for the responder? Yes. > 2.1.D.) Does SOI need to provide protection against active > attacks for the responder? Yes, because of the identity sniffing attack. > 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward > secrecy" by trading off performance versus the level of PFS provided. > The funcitonality provided is roughly identical. Does anyone care > about the details of how IKEv2 versus JFK provides this functionality? Yes, PFS is important, details are not that important. > 2.3.A.) Does SOI need to natively support "legacy authentication > systems"? I think, that we do need to do something for the legacy authentication. I really want to get rid of xauth, and if we don't have some solution, I fear that we will see the xauthv2... So, some kind of solution should be in the SOI. I think something like rsa signatures authentication for the server/gateway and legacy authentication for client/remote user. > 2.3.B.) Does SOI need to natively support some kind of "shared > secret" scheme? No. It could be usefull for the debugging and very small scale testing, but same can be archived with raw RSA keys (or self signed certificates). For the legacy authentication I think we need strong RSA signatures based authentication for the gateway/server, thus this is not useable for it. > 2.4 Number of crypto operations > > 2.4.A) JFK requires substantially more cryptographic operations for > rekeying (two more signatures, two more signature validations, and > three more hashes). Is this a problem? More generally, does SOI need > to be able to support "fast" rekeying? I think number of crypto operation is very important for small devices, and they will be more and more common. The fewer operations we have the smaller devices we can use... Fast rekeying is important on some scenarios, for example it could have uses for cases where we move lots of data (iSCSI?). Also if rekeying requires new authentication that means that for legacy authentication support we need user to do something to perform the authentication. > 2.5) Plausible denaibility > > 2.5.A) Does SOI need to provide "plausible deniability" (the opposite > of "non-repudiation") for the initiator? No. > 2.5.B) Does SOI need to provide "plausible deniability" (the opposite > of "non-repudiation") for the responder? No. > 2.6 Formal proofs of security > > 2.6.) Does SOI need to provide a formal proof of security? (Is this > a "must have" or a "nice to have"? What are we willing to trade-off > for having a formal proof of security?) Formal analysis are nice to have, so we can say to customers that yes this is "secure" protocol. I don't really think trust those very much. Also most of the security problems are going to be in the implementations anyways so for me as an implementator it really doesn't help to have formal proof... > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more > important to always keep the message count at 4, or is it acceptable to add > an additional roundtrip of messages when the responder thinks he's under > attack? I think it is acceptable to add more roundtrips when responder thinks he is under attack. > 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide > basically equivalent protection. Does anyone care about the details of how > JFK or IKEv2 provide this functionality. I think the best approach is to try to keep the packets small, but otherwise it really does not matter. > 3.1.C) Is it important to have precomputation of exponentials available for > use as a mechanism for protecting against cpu consumption attacks? For some scenarios yes, but I actually think this is more or less implementation issue (our IKEv1 implementation can precompute Diffie-Hellman exponentations even now). > 3.2 Number of messages in all scenarios > > 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in > message one. In IKEv2 if Bob doesn't accept what Alice offers the > negotiation starts again. In JFK if Bob doesn't accept what Alice offers > but Alice can live with what Bob offers, they continue. Otherwise they > start over. Is this an important feature for SOI? I don't think that is going to be that common case that we need to optimize for it. I think it is fine to just send back a error notification listing allowed groups. Implementations should try to remember those lists, and try those groups next time first. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Jun 28 10:10:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SHAsw09643; Fri, 28 Jun 2002 10:10:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00326 Fri, 28 Jun 2002 12:28:06 -0400 (EDT) Message-Id: <3.0.3.32.20020628094306.01399370@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 28 Jun 2002 09:43:06 -0700 To: "Chinna N.R. Pellacuru" , Stephen Kent From: Alex Alten Subject: Re: apology Cc: IP Security List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:02 PM 6/27/2002 -0700, Chinna N.R. Pellacuru wrote: >On Thu, 27 Jun 2002, Stephen Kent wrote: Steve, I find that when I get into a thread arguement with you that you tend to beat around the bush. I don't know where you find the time to be so prolific with your email responses. I had to give up on the last thread about host identities & keys because I have work to do. I can't keep up the tit-for-tat with you on this list. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Jun 28 10:47:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SHlVw21606; Fri, 28 Jun 2002 10:47:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00392 Fri, 28 Jun 2002 13:07:22 -0400 (EDT) X-Authentication-Warning: kaakeli.acr.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15644.38974.691238.698338@kaakeli.acr.fi> Date: Fri, 28 Jun 2002 20:09:18 +0300 From: Tero Kivinen To: tytso@mit.edu ("Theodore Ts'o"), ipsec@lists.tislabs.com Subject: SOI QUESTIONS: 3.4, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7 X-Mailer: VM 7.00 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 31 min X-Total-Time: 38 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3.4 Preferred ID for responder > 3.4.A) In JFK and IKEv2, the initiator can include a payload is an > indication to the responder as to what identity (and corresponding key > material) the responder should use to authenticate to the initiator. In > JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent > in the clear in message 1, thereby allowing a passive attack on the > responder's likely identity. Is it important to encrypt this identity? If it is going to used as server-id / virtual-host-id then it should encrypted. This causes that we cannot make policy decisions based on that identity, but for IKEv2 that doesn't really matter as the policy decisions done before that affect the phase 1 SA only, the IPsec SA can do decisions based on the "you tarzan" message. > 4. One or two phases > 4.1 Control channel vs. separate protocols > 4.1.A) [Meta question, that will be answered by the other questions in > section 4.] Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? I think we do need control channel. > 4.2 Creating multiple SAs for a single pair of entities > 4.2.A) How important is it that SOI be able to create multiple SA's > between a pair of entities "cheaply"? I think there are multiple different scenarios where it is needed. One that hasn't yet been mentioned is the multi-user unix host running per user authenticated IPsec connections out. This means that in IKEv2 there needs to be Phase 1 SA for each user, and as the implementation might not support username as a IPsec selector, it might want to create new IPsec SA for each TCP/IP port pair the user is using (i.e when user starts new TCP/IP connection that port pair is added to the policy and tied to the this phase 1 SA). This requires fast IPsec SA setups. One of the requirements is also that IF we are going to support legacy authentication the creation of the new IPsec SA or rekeying existing SA SHOULD not require reauthentication of the user, because that authentication step might need for example typing in password or secure id code etc. If you have rekey limit of 100 MB and you are transferring data over 100 MBit/s ethernet you do not want to type in password every 10 seconds... > 4.2.B) How often will usage scenarios of SOI need to generate multiple > SA's between a single pair of entites? In some scenarios almost always... > 4.3 Dead peer detection > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a > "keep-alive" mechanism. The functionality provided is roughly > identical. Does anyone care about how low-level implementation > details of IKEv2 and JFK? If we are going to have multiple IPsec SAs between hosts, then the DPD should be done on the upper level than IPsec SA (not to waste resources). I.e either on Phase 1 or per host basis. > 4.3.B) Should the working group consider other schemes which provide > the same functionality as dead peer detection? (i.e., birth > certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt) I think birth certificates are much better than initial contact. Both of them have problem that if the ip-address (for example because of nat or dhcp) of the other end changes then the initial-contact or birth-certificate is not tied to the proper host. Both of those should propably be tied to something else than IP-address. For example they could be tied to the ID the host is using when authenticating, i.e if it uses IP-address then they should tied to IP-address, if it uses dns name then it should be tied to dns-name. The ID is usefull as an authentication id only if it somehow static, thus remains constant even if the ip-address etc changes. BTW, you don't need necessarely stable storage for the birth-certificates, you can also use clock for that, and all hosts using certificates DO need to get proper time before they can start using the certificates (otherwise they cannot verify the validity period). > 4.4 SA deletion > > 4.4.A) Both JFK and IKEv2 provide SA deletion. The functionality > provided is roughly identical. Does anyone care about how low-level > implementation details of IKEv2 and JFK? One of the issues that have raised lately has been different kind of load balancing servers and one very usefull feature there is to be able to pregenerate delete notification for the SAs. This way if you have two hosts balancing the load they can both have their own SAs, but each one sends the another node pregenerated delete (or birth-certificate) notifications. Now if one node for some reason crashes the other node can quickly delete all the SAs used by it and force all clients using the other node to rekey to him. The reason why they do not share the actual SAs is that it would require lots of syncronization for the replay counters (in environments where replay detection cannot be disabled for security reasons). If I understand correctly neither one of the protocols currently allow this kind of pregenerated delete notifications. The IKEv1 did allow that, but because we do not know the proper message id to be used for the delete we cannot pregenerate the IKEv2 delete notification beforehand. Of course we could fix in IKEv2 this by saying that message id 0xffffffff must always be accepted and the only contents it can have is to have delete notification for the IKE SA. For JFK we need to share the actual authentication private key in both nodes, to be able to send the deletes, and for each deletes we need to do full signature + diffie-hellman... > 4.5 SA rekeying > > 4.5.A) Both JFK and IKEv2 provide SA rekeying. The functionality > provided is roughly identical, although JFK requires more > cryptographic operations to do rekeying (see 2.4). Does anyone care > about how low-level implementation details of IKEv2 and JFK? See my comments earlier about not requiring the legacy system authentication to be done for each rekey. > 4.6 Authenticated error messages > 4.6.A) Both JFK and IKEv2 provide authenticated error messages. The > functionality provided is roughly identical, although details very > different due to the lack of a 2 phase protocol in JFK. Does anyone > care about how low-level implementation details of IKEv2 and JFK? The problem with IKEv1 was that NO-PROPOSAL-CHOSEN error could not be authenticated for the Phase 1, as there was not cryptographic context when sendind that. I think this is also the case for the IKEv2. > 4.7 Authenticated informational messages > > 4.7.A) Does SOI need to provide authenticated informational messages > after an IKE SA has been set up? (What sort of informational messages > might be needed? Do they need to be protected in a different key than > the SA key?) For example the SCTP might need some control message which adds new addresses to existing SA or deletes some addresses there. I don't know if it would be actually informational message or some other kind of exchange (new IPsec SA creation without Diffie-Hellman?). -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Jun 28 11:17:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SIHvw02012; Fri, 28 Jun 2002 11:17:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00442 Fri, 28 Jun 2002 13:34:41 -0400 (EDT) Date: Fri, 28 Jun 2002 10:48:13 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Alex Alten cc: Stephen Kent , IP Security List Subject: Re: apology In-Reply-To: <3.0.3.32.20020628094306.01399370@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ever wonder why customers feel that "Is this a standard?" is a throw away question, just like one would ask "How are you?" in a party. I agree they haven't stopped asking the question. On Fri, 28 Jun 2002, Alex Alten wrote: > At 08:02 PM 6/27/2002 -0700, Chinna N.R. Pellacuru wrote: > >On Thu, 27 Jun 2002, Stephen Kent wrote: > > Steve, > > I find that when I get into a thread arguement with you that > you tend to beat around the bush. I don't know where you find > the time to be so prolific with your email responses. I had > to give up on the last thread about host identities & keys > because I have work to do. I can't keep up the tit-for-tat > with you on this list. > > - Alex > -- > > Alex Alten > Alten@ATTBI.com > __ chinna narasimha reddy pellacuru "Moral Clarity: Def. When you do it, it is moral relativism, when I do it, it is the repudiation of moral equivalence." From owner-ipsec@lists.tislabs.com Fri Jun 28 12:42:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SJgaw01605; Fri, 28 Jun 2002 12:42:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00513 Fri, 28 Jun 2002 15:01:24 -0400 (EDT) Date: Fri, 28 Jun 2002 15:14:51 -0400 From: Ran Canetti Message-Id: <200206281914.PAA32168@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, ipsec@lists.tislabs.com, pbaker@verisign.com Subject: RE: SOI QUESTIONS: 2.6 Formal proofs of security Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phill, I'm glad we're in agreement. The reason that I went into this long exposition of security analysis methods is that I got the feeling from the discussion that some people may be mistakenly equating "rigorous analysis of protocols" with "formal methods". A good set of empirical tests is always welcome. But I fear that any set of specific empirical tests would be unable to provide the desired level of confidence. (what if there is another attack that we didnt think of.) I personally favor cryptographic analysis. Here you can rigorously claim that the protocol cannot be broken - by *any* attacker - unless you actually break the underlying computational assumption. (This is done by showing how to turn *any* attacker that breaks the protocol into an algorithm that solves the underlying intractable problem.) Ran BTW, in this vein, there is a paper by Hugo and me in the upcoming crypto conference that rigorously proves the security of the cryptographic protocol that stands at the core of both IKEv1 (sig modes), IKEv2 (sig mode), and JFKr. This is not intended as full analysis of either of those protocols, but it demonstrates that the core of those protocols is secure. > From pbaker@verisign.com Wed Jun 26 11:15:41 2002 > > In response to Ran's note I suspect that all the people in the thread > actually have a mutually compatible view of what formal methods can do and > what should be required. > > Some of the negativity in my posts probably comes from the fact that having > seen Formal methods massively oversold I think it is important to set > expectations. > > Clearly formal methods can add significant value. However what people have > been cautioning against is setting the bar to SOI to be a formal 'proof of > security' ignoring the fact that what consitutes a proof of security is > highly debatable (even in forums other than IETF mailing lists where > anything is highly debatable), and the fact that we did not put IKE through > that analysis. > > I think it would be quite reasonable to state specific empirical tests that > a SOI protocol should pass, provided that the analysis methods involved do > not introduce arbitrary constraints into the solution space whose only > purpose is to allow the analysis. > > Phill > ipsec@lists.tislabs.com Thu Jun 27 14:30:19 2002 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) with ESMTP id OAA33530 for ; Thu, 27 Jun 2002 14:30:18 -0400 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [9.2.250.12]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5RIUIL29468; Thu, 27 Jun 2002 14:30:18 -0400 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5RIUC228526; Thu, 27 Jun 2002 14:30:12 -0400 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23303 Thu, 27 Jun 2002 13:57:09 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 4.5 SA rekeying Phone: (781) 391-3464 Message-Id: Date: Thu, 27 Jun 2002 14:09:47 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 4.5 SA rekeying 4.5.A) Both JFK and IKEv2 provide SA rekeying. The functionality provided is roughly identical, although JFK requires more cryptographic operations to do rekeying (see 2.4). Does anyone care about how low-level implementation details of IKEv2 and JFK? Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Fri Jun 28 13:08:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SK8nw06245; Fri, 28 Jun 2002 13:08:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00549 Fri, 28 Jun 2002 15:32:38 -0400 (EDT) Date: Fri, 28 Jun 2002 12:45:33 -0700 (PDT) From: Jan Vilhuber