From owner-ietf-ipsra Wed Mar 24 11:13:24 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA16952 for ietf-ipsra-bks; Wed, 24 Mar 1999 11:13:24 -0800 (PST) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA16948 for ; Wed, 24 Mar 1999 11:13:22 -0800 (PST) Message-Id: <4.2.0.32.19990324111230.0099c930@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Wed, 24 Mar 1999 11:12:33 -0800 To: ietf-ipsra@vpnc.org From: Paul Hoffman Subject: Starting the ietf-ipsra mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Welcome to the IP Security Remote Access mailing list. Over the next week, Roy Pereira will be posting a proposed charter as well as a FAQ. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra Wed Mar 24 11:14:16 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA16970 for ietf-ipsra-bks; Wed, 24 Mar 1999 11:14:16 -0800 (PST) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA16966 for ; Wed, 24 Mar 1999 11:14:15 -0800 (PST) Message-Id: <4.2.0.32.19990324111323.00aecb50@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Wed, 24 Mar 1999 11:13:25 -0800 To: ietf-ipsra@vpnc.org From: Paul Hoffman Subject: Starting the ietf-ipsra mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Welcome to the IP Security Remote Access mailing list. Over the next week, Roy Pereira will be posting a proposed charter as well as a FAQ. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra Thu Mar 25 04:05:06 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id EAA18024 for ietf-ipsra-bks; Thu, 25 Mar 1999 04:05:06 -0800 (PST) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id EAA18020 for ; Thu, 25 Mar 1999 04:05:04 -0800 (PST) Received: from wigeon.shiva.com (wigeon.shiva.com [140.248.194.223]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id HAA08326 for ; Thu, 25 Mar 1999 07:05:24 -0500 (EST) Received: from shiva.com by wigeon.shiva.com (SMI-8.6/SMI-SVR4) id HAA04476; Thu, 25 Mar 1999 07:08:02 -0500 Message-ID: <36FA2722.558C5D8A@shiva.com> Date: Thu, 25 Mar 1999 07:08:02 -0500 From: Jesse Walker Organization: Shiva Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ietf-ipsra@vpnc.org Subject: Re: Configuration of mobile users References: <199903180455.WAA00739@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Michael: > I've just re-read draft-ietf-ipsec-dhcp-01.txt and > draft-ietf-ipsec-isakmp-mode-cfg-04.txt. They are both good documents with a lot of good ideas, but the problem we have so far in this working group is we have not agreed on a set of requirements, so we have no common basis from which to evaluate either these or other ideas. The documents address one of several configuration problems that occur in the context of a remote access IPSec client and an IPSec security gateway. The IPSec client and security gateway are attempting to coordinate to provide a pair of IPSec security associations between the client and a subnet protected by the security gateway. Following established practice, I will abuse terminology and call this pair of security associations an IPSec tunnel. The client and security gateway use a phase 2 IKE exchange to negotiate this IPSec tunnel. Since by assumption the security gateway is negotiating the tunnel on behalf of a protected subnet, the phase 2 IKE negotiation, to meet the IKE access control requirements, must specify the subnets or addresses permitted to traverse the tunnel. The two tunnel endpoints specify these addresses as ID payloads. So the first issue becomes: how does the client know the protected subnet to specify in its phase 2 ID payloads? and how does it know how the address to specify for itself? A second issue is very closely related to the address the client must specify for itself. Once the tunnel becomes operational, any responses to IP datagrams the client sends down its tunnel need to be routed from the responder on the protected subnet back to the security gateway, so they can return via the tunnel instead of along another path, which is not guaranteed to be secure. Since remote access clients typically do not have fixed IP addresses, static routing cannot be used to accomplish this. There are at least two ways to address this issue: either the security gateway can run a routing protocol, advertising the reachability of the client, or it can conspire to assign an IP address from one of its own subnets to the client, in which case it can use something like proxy ARP as the routing mechanism for the return trip. The collective wisdom of the IPSec community seems to be that the latter case is usually preferable, and, to avoid the contortions and complexity that arise with NAT, the security gateway must relay this new IP address to the client, and the client must use the address for all datagrams it sends through the tunnel. But for this model to work with IKE, it is necessary for the client to specify the newly assigned IP address as one of the phase 2 ID payloads. Obviously it cannot do this until it knows the IP address assigned to it for use with this tunnel. A third issue is also closely related, viz., once IPSec is used in this way to give the client a virtual presence on one of the security gateway's protected subnets, how is the rest of the client's TCP/IP stack (routes, DNS, etc.) configured? Finally, there has been ample sentiment on the IPSec mailing list that IKE is complicated enough, and that it consumes too many resources already, so we want to to avoid anything that adds more complexity or overhead if we can. > To compare/contrast, I think the major advantage of isakmp-mode-cfg > is that one doesn't burn entropy from the DH making an IPsec SA that > is only used for three or four packets. Secondly, it isn't clear that > all "VPN" SAs will necessarily have selectors that permit the DHCP > traffic. In my mind the advantages of the IKECFG message also extend to the fact that it can identify the protected subnet(s) the client is authorized to use as well, and this exchange occurs before the client attempts to negotiate phase 2. The disadvantage of the IKECFG approach is that it requires new protocol for phase 1.5. This introduces new complexity into the IKE implementation. It also will need quite a bit of work if it is to be used to configure more general TCP/IP parameters within the tunneled environment, but this can be obviated by using DHCP Inform messages. > The major advantage of ipsec-dhcp is that it reuses existing > protocol definitions, infra-structure, and DHCP has a clear mechanism > for extensions. The advantage of the DHCP approach is that it can configure any TCP/IP parameter needed, and it is easy to build the client so that it can utilize the native DHCP support of its host operating system. The disadvantage of the DHCP approach is that it requires the use of an auxiliary tunnel to convey the DHCP exchange, adding unnecessary overhead. It also provides no standardized way of specifying the authorized protected subnet the client may specify in the phase 2 ID payloads although I suppose we could agree by convention to interpret the static routes a DHCP Ack can convey; the security gateway would have to compose or edit the DHCP Ack message in this case. I think this discussion says that both protocols meet most but not all of the requirements. This means either we have to relax the requirements, or we have to find a different approach. > I would like to suggest a compromise/hybrid solution: let's define a > payload/exchange type which carries DHCP payloads within ISAKMP. > > This has all the advantages of isakmp-mode-cfg: > 1. no seperate SA > 2. the ISAKMP learns about the parameters directly I can't help wondering whether we can meet all of the configuration requirements posed by this particular locus of problems in another way that adds nothing to RFC 2409, but would probably require most (all?) of us to enhance our security gateway implementations. The key to what I have in mind is to limit one of the degrees of freedom allowed in RFC 2409, at least for the remote access case. To make everything work "correctly" without introducing any new protocol, observe that according to RFC 2409 the phase 2 initiator does not have to be the phase 1 initiator. Indeed, suppose the phase 2 initiator is the phase 1 responder. In the case under discussion, the phase 1 responder is by definition the security gateway, since we are talking about remote access, and a remote access tunnel is set up only when the client asks for it. If the security gateway were to initiate the phase 2 IKE negotiation, it is certainly in a position to propose an IP address that the client would be assigned; it can use the appropriate phase 2 ID payload to do this. For the phase 2 IKE negotiation to succeed, the client has to accept the proposed ID payload. If the client were to blindly accept the ID payloads it receives from the gateway, then the client will have an appropriate IP address to use as its own source address in traffic it sends through the tunnel. This mechanism will only succeed in configuring the ID payloads and addressing for the tunnel; in particular, just like IKECFG, it contributes little in the way toward configuring the client's TCP/IP stack to operate within the tunneled environment. The most direct way to address this latter need is for the security gateway to send a DHCP Inform message to the client after the tunnel is established. Obviously some type of retry mechanism is needed to make this reliable. And there is the matter that DHCP Informs sent from the gateway don't match the tunnel IDs, but this feels like an eminently solvable problem. Since hosts typically already know how to respond to DHCP Inform messages, this again adds no new protocol to the IKE itself. There is another potential advantage (?) with this method as well. The client can (but does not have to) blindly accept the phase 2 security association parameters. This uses the phase 2 negotiation as a policy delivery vehicle for the client, obviating the need for other channels to provide this function and potentially simplifying the client user interface. Obviously, this delivery mechanism will not work with clients trying to access foreign administrative domains, and equally it contributes nothing to a solution to the problem of how the client decides to propose the "right" phase 1 parameters, but those are separate problems the BOF/WG should consider on other threads anyway. So the proposal is to adopt a convention that the security gateway becomes the phase 2 initiator when its peer is a remote access client, at least immediately after a phase 1 negotiation in which the client asserts INITIAL-CONTACT in its phase 1 negotiation. I can think of at least four problems with this mechanism: a. It leads to inefficiencies, because there is no reason to negotiate all the SAs the client is authorized to use. That is, if the policy at the security gateway allows the client to access, say, five hundred different subnetworks, then the security gateway either has to negotiate all five hundred, simply because it does not know which one the client is really trying to access, or it has to negotiate one selected at random or by some other policy. It is not clear that this is a fatal flaw, but then again, it is not apparent that it isn't. b. There is no way for IKE at the security gateway to know when it is negotiating with a client or when a different kind of device, for which the traditional style of negotiation (i.e., where the phase 1 and phase 2 initiators are the same) may be more appropriate. This strikes me as the real issue, but then again, in retrospect both IKECFG and DHCP suffer from the same defect, too. Either the administrator can configure this information as part of the policy for this particular device ("any device that authenticates as Joe.User@mysite.com is a client"), or else we need some standardized mechanism within IKE for clients to identify themselves as such. Adding a new mechanism is new protocol, something I think we'd like to avoid if possible. c. Continuing on from the last point, it would be nice if the IKE responder could treat the IKE initiator uniformly, and my suspicion is the community would like to use the traditional model for LAN-LAN and end-to-end communications. So the proposal does not work very well with this desire. d. Since most (all?) security gateway implementations do not work this way today, this is equivalent to requiring the community to implement new protocol; it's just a portion of IKE that few if anyone has ever implemented. Hence, it might be a more expensive implementation effort than going with IKECFG or DHCP. What do other people think? > The speaker on Monday from Microsoft (Bernard I think) expressed the > belief that many of the PPP configuration options should have been > done via a DHCP Inform. I'm not qualified to agree or disagree with > this statement, but if true, would tend to support using DHCP. > > In addition, DHCP leases need to be renewed periodically. This > provides a *NATURAL* keep alive message for road warriors. Further, > DHCP says specific things about what a host is supposed to do as it > shuts down wrt sending out DHCP releases. Keepalives or other resource recovery mechanisms are also something we should discuss in the working group, but in another thread. The suggestion to DHCP as a keepalive mechanism has some merit, but overall doss not appear to be a very good candidate for keepalives for two reasons. First it is not possible to assume that administrators will configure short enough DHCP leases to be useful as a mechanism to recover tunnels. Second, I think we want to be wary about building request/response mechanisms into our system whenever possible, lest we provide mechanism an attacker knows will be available to use the responder as an oracle for the tunnel keys. From owner-ietf-ipsra Thu Mar 25 18:34:10 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id SAA18703 for ietf-ipsra-bks; Thu, 25 Mar 1999 18:34:10 -0800 (PST) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id SAA18699 for ; Thu, 25 Mar 1999 18:34:09 -0800 (PST) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id GYBZV8J8; Thu, 25 Mar 1999 18:37:59 -0800 Message-ID: <36FAF31C.AFE20DEA@redcreek.com> Date: Thu, 25 Mar 1999 18:38:20 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ipsra@vpnc.org Subject: [Fwd: concerns regarding work load] Content-Type: multipart/mixed; boundary="------------E7FCC6D28D499824CB8CA592" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. --------------E7FCC6D28D499824CB8CA592 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------E7FCC6D28D499824CB8CA592 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <36FA7262.1ABA2730@redcreek.com> Date: Thu, 25 Mar 1999 09:29:06 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ipsra@vpnc.org CC: "Pereira, Roy" , ipsec@lists.tislabs.com Subject: concerns regarding work load References: <199903180455.WAA00739@pzero.sandelman.ottawa.on.ca> <36FA2722.558C5D8A@shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Monday, I sent an email to Roy expressing some concerns I have regarding getting ipsra going. I wanted to cc this list, but didn't think the list was up and running yet. I'm also cc'ing the ipsec list with this, in case some folks that are interested in ipsra haven't had a chance to subscribe yet. I've cut and pasted some of the text from my original email below, with some contextual modifications. I assume that we'll get an acceptable charter hammered out, and ipsra will become a working group. I have no doubt that the security policy working group will also go forward, and it will be a very substantial undertaking. I have 2 concerns as a result: first, the policy group will produce much important work, and so will be very involved and very time consuming. This will impact upon Roy's ability to devote the required attention to ipsra. Second, Roy has a bit of a stake in which remote access mechanism we select, given that he has 2 drafts out detailing his company's implementation. While I don't think either of these issues should rule Roy out as chair for ipsra, I would be much more comfortable if he had a co-chair who could help with the workload, and who might openly entertain alternative approaches. It may be that his proposed mechanisms will turn out to be the best, but we need an open debate to determine this. I'd be willing to co-chair with Roy if everyone is comfortable with this. If for some reason this is not acceptable, then I'd like an opportunity to nominate someone else. Scott --------------E7FCC6D28D499824CB8CA592-- From owner-ietf-ipsra Sat Mar 27 13:44:06 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id NAA21390 for ietf-ipsra-bks; Sat, 27 Mar 1999 13:44:06 -0800 (PST) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA21386 for ; Sat, 27 Mar 1999 13:44:01 -0800 (PST) Received: from istari.sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id QAA16489 for ; Sat, 27 Mar 1999 16:48:34 -0500 (EST) Received: from istari.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by istari.sandelman.ottawa.on.ca (8.8.7/8.7.3) with ESMTP id QAA06686 for ; Sat, 27 Mar 1999 16:48:33 -0500 (EST) Date: Sat, 27 Mar 1999 16:48:33 -0500 (EST) From: "Michael C. Richardson" Message-Id: <199903272148.QAA06686@istari.sandelman.ottawa.on.ca> Replied: Sat, 27 Mar 1999 16:48:23 -0500 Replied: "owner-ietf-ipsra@vpnc.org " Replied: Sat, 27 Mar 1999 16:46:27 -0500 Replied: "Jesse Walker ietf-ipsra@vpnc.org" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >From jwalker@shiva.com Mon Mar 22 17: 53:19 1999 Return-Path: Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA07698 for ; Mon, 22 Mar 1999 17:53:13 -0500 (EST) Received: from wigeon.shiva.com (wigeon.shiva.com [140.248.194.223]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id RAA19805; Mon, 22 Mar 1999 17:49:14 -0500 (EST) Received: from shiva.com by wigeon.shiva.com (SMI-8.6/SMI-SVR4) id RAA03143; Mon, 22 Mar 1999 17:52:00 -0500 Sender: jwalker@shiva.com Message-ID: <36F6C990.184857B7@shiva.com> Date: Mon, 22 Mar 1999 17:52:00 -0500 From: Jesse Walker Organization: Shiva Corporation X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Michael Richardson CC: ietf-ipsra@vpnc.arg Subject: Re: Configuration of mobile users References: <199903180455.WAA00739@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Filtered-By: NoCeM-E v0.6 (http://www.novia.net/~doumakes) Resent-To: ietf-ipsra@vpnc.org Resent-Date: Sat, 27 Mar 1999 16:48:32 -0500 Resent-From: "Michael C. Richardson" Michael: > I've just re-read draft-ietf-ipsec-dhcp-01.txt and > draft-ietf-ipsec-isakmp-mode-cfg-04.txt. It would be useful for us to try to articulate the remote access client configuration problem before we try to decide which approach is better. The lack of this precision about our goals certainly bugged me from the BOF, as we are trying to debate solutions before agreeing on what the problem is. This is one of several configuration problems that occur in the context of a remote access IPSec client and an IPSec security gateway. The IPSec client and security gateway are attempting to coordinate to provide a pair of IPSec security associations between the client and a subnet protected by the security gateway. Following established practice, I will abuse terminology and call this pair of security associations an IPSec tunnel. The client and security gateway use a phase 2 IKE exchange to negotiate this IPSec tunnel. Since the security gateway is negotiating the tunnel on behalf of a protected subnet, the phase 2 IKE negotiation, to meet the IKE access control requirements, must specify the subnets or addresses permitted to traverse the tunnel. The two tunnel endpoints specify these addresses as ID payloads. So the first problem becomes: how does the client know the protected subnet to specify in its phase 2 ID payloads? and how does it know how the address to specify for itself? A second problem is very closely related to the address the client must specify for itself. Any responses to IP datagrams the client sends down its tunnel need to be routed from the responder back to the security gateway, so they can return via the tunnel instead of along another path, which is not guaranteed to be secure. Since remote access clients typically do not have fixed IP addresses, static routing cannot be used here. There are at least two ways to solve this problem: either the security gateway can run a routing protocol, advertising the reachability of the client, or it can conspire to assign an IP address from one of its own subnets to the client, in which case it can use something like proxy ARP as the routing mechanism for the return trip. The collective wisdom of the IPSec community seems to be that the latter case is usually preferable, and, to avoid the problems that arise with NAT, the security gateway must relay this new IP address to the client, and the client should use the address for all datagrams it sends through the tunnel. But for this model to work with IKE, it is necessary for the client to specify the newly assigned IP address as one of the phase 2 ID payloads. Obviously it cannot do this until it knows the IP address assigned to it for use with this tunnel. A third problem is also closely related, viz., once IPSec is used in this way to give the client a virtual presence on one of the security gateway's protected subnets, how is the rest of the client's TCP/IP stack (routes, DNS, etc.) configured? A final problem addressed in the BOF's discussion was to make IPSec technology more accessible to the general user. Right now most IPSec client implementations require a very high degree of networking prowess and security expertese on behalf of the client's end user. Experience demonstrates that the complications of the phase 2 ID payload specification and the TCP/IP stack configuration issue removes use of IPSec client technology from the grasp of most users. > To compare/contrast, I think the major advantage of isakmp-mode-cfg > is that one doesn't burn entropy from the DH making an IPsec SA that > is only used for three or four packets. Secondly, it isn't clear that > all "VPN" SAs will necessarily have selectors that permit the DHCP > traffic. > > The major advantage of ipsec-dhcp is that it reuses existing > protocol definitions, infra-structure, and DHCP has a clear mechanism > for extensions. In my mind the advantages of the IKECFG message also extend to the fact that it can identify the protected subnet(s) the client is authorized to use as well, and this exchange occurs before the client attempts to negotiate phase 2. The disadvantage of the IKECFG approach is that it requires the client to learn a new protocol, which is spoken at phase 1.5. This introduces new complexity into the IKE implementation. It also will need quite a bit of work if it is to be used to configure more general TCP/IP parameters within the tunneled environment The advantage of the DHCP approach is that it can configure any TCP/IP parameter needed, and it is easy to build the client so that it can utilize the native DHCP support of its host operating system. The disadvantage of the DHCP approach is that it requires the use of an auxiliary tunnel (or, more to the point, "burn entropy," as you elloquently put it) to convey the DHCP exchange, and it provides no standardized way of specifying the authorized protected subnet the client may specify in the phase 2 ID payloads (although we could agree to interpret the static routes DHCP can convey in this manner). Hence, I think neither the IKECFG nor the DHCP proposal really addresses all the requirements. > I would like to suggest a compromise/hybrid solution: let's define a > payload/exchange type which carries DHCP payloads within ISAKMP. > > This has all the advantages of isakmp-mode-cfg: > 1. no seperate SA > 2. the ISAKMP learns about the parameters directly > > The speaker on Monday from Microsoft (Bernard I think) expressed the > belief that many of the PPP configuration options should have been > done via a DHCP Inform. I'm not qualified to agree or disagree with > this statement, but if true, would tend to support using DHCP. This does seem to address all the requirements for the problems at hand, and I am not adverse to this. On the other hand, if we are to invent something new, I also can't help thinking we can meet all of the configuration requirements posed by this particular locus of problems in another way that adds nothing to RFC 2409, but would probably require most (all?) of us to enhance our security gateway implementations. The key to what I have in mind is to limit one of the degrees of freedom allowed in RFC 2409, at least for the remote access case. To make everything work "correctly" without introducing any new protocol, observe that according to RFC 2409 the phase 2 initiator does not have to be the phase 1 initiator. Indeed, suppose the phase 2 initiator is the phase 1 responder. In the case under discussion, the phase 1 responder is by definition the security gateway, since we are talking about remote access, and a remote access tunnel is set up only when the client asks for it. If the security gateway were to initiates the phase 2 IKE negotiation, it is certainly in a position to propose an IP address that the client would be assigned; it can use the appropriate phase 2 ID payload to do this. For the phase 2 IKE negotiation to succeed, the client has to accept the proposed ID payload. If the client were to blindly accept the ID payloads it receives from the gateway, then the client will have an appropriate IP address to use as its own source address in traffic it sends through the tunnel. This mechanism will only succeed in configuring the ID payloads and addressing for the tunnel; in particular, it contributes nothing toward configuring the client's TCP/IP stack to operate within the tunneled environment. The most direct way to address this latter need is for the security gateway to send a DHCP Inform message to the client after the tunnel is established (obviously some type of retry mechanism is needed to make this reliable). Since hosts typically already know how to respond to DHCP Inform messages, this again adds no new protocol to the mix. There is another potential advantage (?) with this method as well. The client can (but does not have to) blindly accept the phase 2 security association parameters. This uses the phase 2 negotiation as a policy delivery vehicle for the client, obviating the need for other channels to provide this function and potentially simplifying the client user interface. Obviously, this delivery mechanism will not work with clients trying to access foreign administrative domains, and equally it contributes nothing to a solution to the problem of how the client decides to propose the "right" phase 1 parameters, but those are separate problems the BOF/WG should consider at other times. Let's examine some of the problems with this approach; I trust other people will identify other problems it might present. a. This mechanism leads to inefficiencies, because there is no reason to negotiate all the SAs the client is authorized to use. That is, if the policy at the security gateway allows the client to access, say, five different subnetworks, then the security gateway either has to negotiate all five, simply because it does not know which one the client is really trying to access, or it has to negotiate one selected at random or by some other policy. This is certainly a true observation as far as it goes, but my conjecture, based on empirical observation of lots of IPSec client users, is that the objection does not have much force, because the overwhelming majority of clients are configured to access to a single subnet, even in very large organizations. Maybe my empirical evidence is based on an inadequate sample, or others can present compelling arguments as to why this will change, etc. b. There is no way for IKE at the security gateway to know when it is negotiating with a client or when a different kind of device, for which the traditional style of negotiation (i.e., where the phase 1 and phase 2 initiators are the same) may be more appropriate. This strikes me as the real issue. Either the administrator can configure this information as part of the policy for this particular device ("any device that authenticates as Joe.User@mysite.com is a client"), or else we need some standardized mechanism within IKE for clients to identify themselves as such. Adding a new mechanism is new protocol, something I think we'd like to avoid if possible. Also, it would be nice if the IKE responder could treat the IKE initiator uniformly, and my reading of the tea leaves is the community would like to use the traditional model for LAN-LAN and end-to-end communications. So the proposal does not work very well with this desire. What have I missed? What do other people think about doing something like this? > In addition, DHCP leases need to be renewed periodically. This > provides a *NATURAL* keep alive message for road warriors. Further, > DHCP says specific things about what a host is supposed to do as it > shuts down wrt sending out DHCP releases. -- Jesse Walker Intel Network Systems voice: 781-687-1719 fax: 781-687-1437 e-mail: jwalker@shiva.com From owner-ietf-ipsra Sat Mar 27 13:42:17 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id NAA21377 for ietf-ipsra-bks; Sat, 27 Mar 1999 13:42:17 -0800 (PST) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA21373 for ; Sat, 27 Mar 1999 13:42:13 -0800 (PST) Received: from istari.sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id QAA16435; Sat, 27 Mar 1999 16:46:34 -0500 (EST) Received: from istari.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by istari.sandelman.ottawa.on.ca (8.8.7/8.7.3) with ESMTP id QAA06521; Sat, 27 Mar 1999 16:46:27 -0500 (EST) Message-Id: <199903272146.QAA06521@istari.sandelman.ottawa.on.ca> To: Jesse Walker CC: ietf-ipsra@vpnc.org Subject: Re: Configuration of mobile users In-Reply-To: Your message of "Mon, 22 Mar 1999 17:52:00 EST." <36F6C990.184857B7@shiva.com> Date: Sat, 27 Mar 1999 16:46:27 -0500 From: "Michael C. Richardson" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jesse" == Jesse Walker writes: >> I've just re-read draft-ietf-ipsec-dhcp-01.txt and >> draft-ietf-ipsec-isakmp-mode-cfg-04.txt. Jesse> It would be useful for us to try to articulate the remote access Jesse> client configuration problem before we try to decide which Jesse> approach is better. The lack of this precision about our goals Jesse> certainly bugged me from the BOF, as we are trying to debate Jesse> solutions before agreeing on what the problem is. Well, I think I hear someone volunteering to write a requirements documentation. Jesse> A third problem is also closely related, viz., once IPSec is used Jesse> in this way to give the client a virtual presence on one of the Jesse> security gateway's protected subnets, how is the rest of the Jesse> client's TCP/IP stack (routes, DNS, etc.) configured? This is why I suggest DHCP. It solve these problems already. We may have to add things to configure additional routes. The reality is that the client has to know that it is supposed to run IPsec/IKE in the first place. I.e. you have to have some initial configuration to even cause IKE to even start up and ask for more configuration. If the IP addresses which you want to talk to are publically routable (which we hope will be the case for all IPv6 addresses) then the client can use SPS to discover if it should be creating a tunnel at all, and if so, with what parameters. If the address is not publically routable, but the client has been configured with a security server that is publically routable, then it could send an SPS request to the security policy server to ask it what it thinks. That SPS message may cause tunnels to be created, since the SPS box may be behind a gateway. I do not believe that IPSRA is supposed to solve this problem. I think that the scope is far more limited: it presumes that the client has been preconfigured via some non-IPSRA mechanism (could be SPS, or manual) with routes to the secure subnets with indications that it needs to build a tunnel. IPSRA needs to solve the problem of: What's my inner tunnel IP? What kind of encryption does the gateway expect me to offer? (may not be in the form of "DES" vs "CAST", but rather in the form of "at least 128bit") What's my DNS, WinS, POP mail server, SMTP server? :!mcr!: | Network and security consulting/contract programming Michael Richardson | IPsec, VPN, Firewalls, PKI, network design, Unix admin Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQDVAwUBNv1RqXMJp3VWzPepAQEQ2QX+MIc2nPG/72SRW0gqpJiX23TNcfq98Jln doK6YHm7Ukg7zGolCKekz1FdUYF59su7hRY2PfpqytSFAg5bJKA65ZEBrVFo1l8Q AOcHeJr67lRsfMcTmYM4lJ+kuNSjUunG3xw5klg80HqGOQj4fmhGc3Ggt4Cd/u6Y P9p79MRFGRnRPoBXSHpJoD0s6VUTdM2hdjqU2Zutl4BduYdd5+Xu+gwfFs+8k6Z4 e2C6n29+uzZPvoJ/n1DSIc8+oQSkXS8D =DAVc -----END PGP SIGNATURE----- From owner-ietf-ipsra Sun Apr 4 20:00:27 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id UAA02054 for ietf-ipsra-bks; Sun, 4 Apr 1999 20:00:27 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id UAA02050 for ; Sun, 4 Apr 1999 20:00:13 -0700 (PDT) Received: from istari.sandelman.ottawa.on.ca (istari.sandelman.ottawa.on.ca [209.151.24.30]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id XAA03034; Sun, 4 Apr 1999 23:05:10 -0400 (EDT) Received: from istari.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by istari.sandelman.ottawa.on.ca (8.8.7/8.7.3) with ESMTP id XAA07281; Sun, 4 Apr 1999 23:04:57 -0400 (EDT) Message-Id: <199904050304.XAA07281@istari.sandelman.ottawa.on.ca> To: ietf-ipsra@vpnc.org CC: smamros@nortelnetworks.com Subject: Re: Configuration of mobile users In-Reply-To: Your message of "Fri, 19 Mar 1999 10:45:46 EST." <3.0.32.19990319104545.00a50c00@bl-mail1.corpeast.baynetworks.com> Date: Sun, 04 Apr 1999 23:04:57 -0400 From: "Michael C. Richardson" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "Shawn" == Shawn Mamros writes: Shawn> First, a question: Am I correct in assuming that Shawn> ietf-ipsra@vpnc.org is the mailing list for the IP Security Remote Shawn> Access BOF? If so, how does one subscribe, and is there an Yes, majodomo@. Shawn> Keep in mind, though, that DHCP is inherently IPv4-only; there are Shawn> fixed length four octet fields in the header for IP addresses. Shawn> There is a draft for a DHCP for IPv6, which I haven't looked at in Shawn> a while, but the last I knew of it, the message format and even Shawn> most/all of the protocol exchanges were radically different from Shawn> DHCPv4. a) but the structure and concept is the same, is it not? b) a major reason to need a different inside tunnel address vs outside tunnel address is because the client may need to be on some specific network due to routing and private address issues at the enterprise end... if you are doing IPv6, then you really shouldn't be dealing with these issues. >> The speaker on Monday from Microsoft (Bernard I think) expressed the >> belief that many of the PPP configuration options should have been >> done via a DHCP Inform. I'm not qualified to agree or disagree with >> this statement, but if true, would tend to support using DHCP. Shawn> At the time PPP was being done, the DHCPINFORM message didn't Shawn> exist. That one's a fairly recent invention, which was added when Shawn> DHCP was rev'd up to Draft Standard in RFC 2131. Even if that Shawn> weren't the case, DHCP's large header size (236 octets, inherited Shawn> from BOOTP) wouldn't be a good thing for a serial line Shawn> environment, where every byte adds latency. Uh, but you only do it once at startup, so I don't see the problem. >> In addition, DHCP leases need to be renewed periodically. This >> provides a *NATURAL* keep alive message for road warriors. Further, >> DHCP says specific things about what a host is supposed to do as it >> shuts down wrt sending out DHCP releases. Shawn> Lease times only apply when DHCP is used for address acquisition. Shawn> If one already has an address and goes the DHCPINFORM route, it Shawn> really won't make an effective keepalive, at least not from the Shawn> IPSec gateway server's perspective. I'm not sure I understand this. I'm not suggesting that DHCPInform is the way to go, but that the MS-PPP people think it would have been better. I was thinking of straight DHCP Request/Accept messages. :!mcr!: | Network and security consulting/contract programming Michael Richardson | IPsec, VPN, Firewalls, PKI, network design, Unix admin Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ietf-ipsra Mon Apr 26 18:36:22 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id SAA03704 for ietf-ipsra-bks; Mon, 26 Apr 1999 18:36:22 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id SAA03700 for ; Mon, 26 Apr 1999 18:36:20 -0700 (PDT) Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id SAA09874 for ; Mon, 26 Apr 1999 18:36:21 -0700 (PDT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 26 Apr 1999 18:36:21 -0700 Message-ID: <01C843625423D211AC3F00A0C969E8900199FD73@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: "'ietf-ipsra@vpnc.org'" Subject: Have'nt seen any drafts yet Date: Mon, 26 Apr 1999 18:36:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Has anybody posted a requirements draft or solution drafts to problems discussed at the last IETF. If not, is something in the works? I have'nt seen much activity since signing up on this mailing list and was wondering as to how we can make progress on end-to-end tunnel configuration issues. Prakash Iyer Intel Architecture Labs Email: Prakash.Iyer@intel.com From owner-ietf-ipsra Tue May 18 08:30:45 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id IAA21324 for ietf-ipsra-bks; Tue, 18 May 1999 08:30:45 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA21320 for ; Tue, 18 May 1999 08:30:42 -0700 (PDT) Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id LAA27931 for ; Tue, 18 May 1999 11:29:54 -0400 (EDT) Received: from kanata-mh1.ca.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 18 May 1999 15:31:41 UT Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Tue, 18 May 1999 11:31:38 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 18 May 1999 11:34:16 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA96AB7@exchange> From: Stephane Beaulieu To: ipsec , ipsra , internet-drafts@ietf.org Subject: New XAUTH draft Date: Tue, 18 May 1999 11:34:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings, An updated revision of the Extended Authentication within ISAKMP/Oakley draft is now available. The URL is Comments are welcome. Stephane Beaulieu TimeStep Corporation sbeaulieu@timestep.com http://www.timestep.com (613) 599-3610 x4709 Fax: (613) 599-3617 From owner-ietf-ipsra Thu May 20 09:46:44 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id JAA26242 for ietf-ipsra-bks; Thu, 20 May 1999 09:46:44 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA26238 for ; Thu, 20 May 1999 09:46:42 -0700 (PDT) Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id MAA06527 for ; Thu, 20 May 1999 12:46:12 -0400 (EDT) Received: from kanata-mh1.ca.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 20 May 1999 16:48:01 UT Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 20 May 1999 12:47:59 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Thu, 20 May 1999 12:50:32 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA9715B@exchange> From: Stephane Beaulieu To: canetti , ipsec@lists.tislabs.com Cc: ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 12:50:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > > I'd like to add a voice in favor of separating the legacy user > authentication mechanisms from IKE. There are several arguments > supporting this separation: > > * First and foremost, IKE is hard to analyze and implement correctly > as is. Adding modes and functionalities will only make it harder. > KISS (keep is simple and secure)! > IKE is hard to implement, and it took a long time to get it right. However, the problem is that we need to provide a secure, easy to use way of providing legacy system authentication. So, what's the *best* way to do this? > * IKE/IPSEC is primarily meant for host-to-host protection. User > authentication seems to be best done on top of IKE/IPSEC, > not as a part of it. > I believe that user authentication IS part of IKE. Don't let the user into your network until he's been authenticated. > * Having relatively simple and separate modules is a nice > feature of the > IPSEC suite, as opposed to other, monolythic security > protocols. Let's keep > it this way. > > > A seemingly "natural" alternative to XAUTH is to first do > IKE, and then > complete the user authentication via the IPSEC-protected connection > (using either AH or ESP). Are there overwhelming arguments to > not do it > this way, and break the modularity of IPSEC? > I have heard many say that this is a bad alternative for several reasons. One of those reasons is that you end up setting up multiple IPSec SAs which should only live for a few minutes. Let's suppose that you need to talk to 3 different devices in order to authenticate / manage a remote user. For example, a user might need to talk to a DHCP server, a RADIUS accounting server, and an SDI server. Then, the SG might need to set up 3 IPSec SAs before he's given full access to the network. This not only takes away from the entropy of the phase 1, but creates SA management nightmares as well as slow down an edge device. If your device is supporting ten thousand remote users, setting up all these SAs is very expensive. Also, many people are adverse to letting anyone onto their network at all until they are fully authenticated. Setting up special conditions for management / authentication servers would require special care, and would require that all of these servers are invulnerable to attacks. P.S Hopefully we can resolve all of these issues at the IPSRA BOF in Oslo :) regards, Stephane. From owner-ietf-ipsra Thu May 20 10:02:12 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id KAA26275 for ietf-ipsra-bks; Thu, 20 May 1999 10:02:12 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA26271 for ; Thu, 20 May 1999 10:02:10 -0700 (PDT) Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id NAA08425 for ; Thu, 20 May 1999 13:01:45 -0400 (EDT) Received: from kanata-mh1.ca.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 20 May 1999 17:03:34 UT Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 20 May 1999 13:03:31 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Thu, 20 May 1999 13:06:05 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA9716B@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 13:06:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Scott, comments below... > > We understand that we would all eventually like to do away > with some of > > these legacy systems, however, for the time being, our > customers demand that > > we support them. XAUTH allows for us to do this by using > IKE to secure it. > > Yes, our customers are placing similar pressures on us, and > we also use > a mechanism similar to xauth to enable radius authentication for the > time being. > > > This provides a nice, easy migration path to those who would like to > > eventually fully deploy IPSec with a PKI, but for now are > limited to using > > their existing infrastructures. XAUTH also ensures that > these legacy system > > transactions enjoy the full security that IPSec provides. > > I don't quite agree with this. I do agree that integrating radius (and > perhaps other "legacy" mechanisms) smoothes the transition to > IPSec, but > I have the feeling that making it too easy will breed > complacency. Also, > I think the statement about enjoying the "full security that IPSec > provides" is questionable. These mechanisms add much in the way of > complexity to IKE, and they basically reduce the authentication > mechanism to a plain-language passphrase which probably isn't too hard > to guess - meaning they *reduce* the security IPSec provides. I hope Tim's comment cleared this up. > > I agree with Steve Kent's comments regarding IKE's need for some > mechanism by which to verify user identity, but think we must make the > distinction between which IKE implementation we're referring to, and > what exactly we mean. To elaborate, in the scenarios in which xauth is > currently being employed, i.e. remote access, it is only the remote > client's IKE which has a real need to interact with the user with > respect to identity verification. To explain, let me present > an example. > > Imagine a policy which permits any client to access a radius server > behind the sgw, but limits all other access. When a client wishes to > access the protected net, it forms a radius-only SA, and through this > authenticates with the radius server. The radius server then interacts > with a local CA (perhaps co-located) to generate a > short-lived identity > cert, and this is returned to the client as an extended radius > attribute, or something. The client then uses this cert, for which the > sgw has corresponding policy, to access the network. > > What are the problems with this approach? Well, for one, the radius > server needs to know how to interact with a CA, but that's a > straightforward problem. For another, the radius server may now be > attackable through the SA. I've heard people argue that there is yet > another drawback, that being the added overhead associated with the > radius-only SA, but I think that security is not free, and > you get what > you pay for. > > Back to my original point, though, note an interesting > characteristic of > this approach: the sgw need know nothing about radius, or any other > secondary authentication protocol - this effectively moves the > complexity outward, away from the security device, which I think is > probably a good thing. I'd be interested to hear other's thoughts on > this, and I have a feeling I will :-) > > Scott > I'm all for having to implement less functionality in our SG. I could sure use the rest :) However our first consideration has to be what's the most secure, most usable solution for our customers. I've expressed my concerns about setting up "special SAs" for authentication / managment servers in my response to Ran's email. I'd like to know what others think. Regards, Stephane. From owner-ietf-ipsra Thu May 20 10:14:06 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA26332 for ietf-ipsra-bks; Thu, 20 May 1999 10:14:06 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA26328 for ; Thu, 20 May 1999 10:14:05 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 25QQPSHX; Thu, 20 May 1999 10:15:47 -0700 Message-ID: <37444331.746657BD@redcreek.com> Date: Thu, 20 May 1999 10:15:29 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: canetti , ipsec@lists.tislabs.com, ipsra Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA9715B@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Stephane Beaulieu wrote: > > A seemingly "natural" alternative to XAUTH is to first do > > IKE, and then > > complete the user authentication via the IPSEC-protected connection > > (using either AH or ESP). Are there overwhelming arguments to > > not do it > > this way, and break the modularity of IPSEC? > > > > I have heard many say that this is a bad alternative for several reasons. > One of those reasons is that you end up setting up multiple IPSec SAs which > should only live for a few minutes. Let's suppose that you need to talk to > 3 different devices in order to authenticate / manage a remote user. For > example, a user might need to talk to a DHCP server, a RADIUS accounting > server, and an SDI server. Then, the SG might need to set up 3 IPSec SAs > before he's given full access to the network. This not only takes away from > the entropy of the phase 1, but creates SA management nightmares as well as > slow down an edge device. If your device is supporting ten thousand remote > users, setting up all these SAs is very expensive. Since I just suggested something similar in a related post, I'll try to address a few of these points. I agree that there is added overhead to this approach, along with added security. However, I'm not sure that any argument is strong enough to compel us to standardize "budget" security. I would also add that the alternative is to implement proxies for these servers within IKE, which with high probability reduces the security of the IKE implementation. Regarding the comment regarding the phase 1 entropy, I'm missing the point, I guess. If you re-use the same key material for more than one SA under *any* circumstances, you are using up some of the entropy, and I guess all I'm really hearing is the same overhead argument again. Am I missing something? Regarding the cost of setting up the SAs, I agree that it's expensive, but would present the "budget" security point again, and add that this if this is the cost of doing business, then it simply means we have to design our products to deliver. > > Also, many people are adverse to letting anyone onto their network at all > until they are fully authenticated. Setting up special conditions for > management / authentication servers would require special care, and would > require that all of these servers are invulnerable to attacks. > I think this is a good point, and this is the problem to solve with respect to my (and Ran Canetti's) previous suggestion. Scott From owner-ietf-ipsra Thu May 20 10:19:07 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA26345 for ietf-ipsra-bks; Thu, 20 May 1999 10:19:07 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA26341 for ; Thu, 20 May 1999 10:19:05 -0700 (PDT) Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id NAA09507 for ; Thu, 20 May 1999 13:18:39 -0400 (EDT) Received: from kanata-mh1.ca.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 20 May 1999 17:20:29 UT Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 20 May 1999 13:20:26 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Thu, 20 May 1999 13:22:59 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA97178@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Tim Jenkins Cc: Stephane Beaulieu , ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 13:22:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Scott, comments below... > > Hi Tim, > > Tim Jenkins wrote: > > > > > Are you perhaps mixing up XAUTH with the hybrid draft? > > > > The only way XAUTH reduces the existing authentication of IKE is if > > the sysadmin use pre-shared key authentication and share it > everywhere > > or set it to null (if that's even possible). > > > > Hybrid, on the other hand, does allow one end to drop the > existing forms > > of authentication. But even then, the problem it's trying > to solve does > > have a place with customers. > > Actually, I wasn't referring only to the strength of the > authentication, > although I think it's a valid thing to discuss. Presumably, secondary > authentication is considered valuable because the primary mechanism is > somehow at risk, e.g. the client's cert is in software, someone might > walk off with the smart card, etc. In these cases, assume the > worst has > happened, and now I'm trying to access your network. If all I > have to do > is guess a passphrase, attacking your network seems something more > doable, when compared to, say, breaking a private/public > keypair. On the > other hand, I know there are bolstering mechanisms (e.g. repeated > challenge + rsp, secureid-type token generators, etc) which > may mitigate > this risk. The purpose of using secondary authentication is mostly for a migration path. ISPs for example have databases with hundreds of thousands of users. If they want to introduce IPSec, they are not going to simply tell everyone to switch to digital certificates overnight. It might take years to do so. We hope that those network admins don't get complacent and take IKE authentication too loosely when they do deploy just because they are still using their legacy systems. That being said XAUTH does provide a form of secondary authentication. Granted that it's no where near as secure as IPSec, it does *add* some security. Hopefully your RADIUS (or whatever other) server would be set up to deny a user who has submitted X number of consecutive bad passwords. > > Perhaps more importantly, I was also referring to the stability, > analyzability, and other security-related properties of IKE. I think > adding proxy servers for even 1 (let alone 16) secondary > authentication > protocols substantially impacts upon the security > characteristics of the > implementation. As does setting up X SAs for each remote user. Regards, Stephane. From owner-ietf-ipsra Thu May 20 10:26:59 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA26363 for ietf-ipsra-bks; Thu, 20 May 1999 10:26:59 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA26359 for ; Thu, 20 May 1999 10:26:57 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 25QQPS2H; Thu, 20 May 1999 10:28:42 -0700 Message-ID: <37444639.90CCA7B2@redcreek.com> Date: Thu, 20 May 1999 10:28:25 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: Tim Jenkins , ipsec@lists.tislabs.com, ipsra Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA97178@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Stephane Beaulieu wrote: > > Perhaps more importantly, I was also referring to the stability, > > analyzability, and other security-related properties of IKE. I think > > adding proxy servers for even 1 (let alone 16) secondary > > authentication > > protocols substantially impacts upon the security > > characteristics of the > > implementation. > > As does setting up X SAs for each remote user. > I'm missing the point again, I think. What is it about setting up multiple SAs (2 in this case) which is insecure, and how is this different than rekeying? Scott From owner-ietf-ipsra Thu May 20 10:53:56 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA26446 for ietf-ipsra-bks; Thu, 20 May 1999 10:53:56 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA26442 for ; Thu, 20 May 1999 10:53:55 -0700 (PDT) Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id NAA12717 for ; Thu, 20 May 1999 13:53:29 -0400 (EDT) Received: from kanata-mh1.ca.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 20 May 1999 17:55:18 UT Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 20 May 1999 13:55:16 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Thu, 20 May 1999 13:57:49 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA971B4@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 13:57:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > > Perhaps more importantly, I was also referring to the stability, > > analyzability, and other security-related properties of IKE. I think > > adding proxy servers for even 1 (let alone 16) secondary > > authentication > > protocols substantially impacts upon the security > > characteristics of the > > implementation. I assume that by this you mean that if a Phase 1 SA is used to secure XAUTH messages, then the Phase 1 SA becomes more susceptible to attack as more XAUTH data is encrypted. If not, please elaborate. > I'm missing the point again, I think. What is it about setting up > multiple SAs (2 in this case) which is insecure, and how is this > different than rekeying? If I did interprate your above comment correctly... My point was that whether you secure an XAUTH transaction with a Phase 1 SA or whether you use a Phase 1 SA to spawn a Phase 2 SA to secure an XAUTH transaction your reducing the lifetime of a Phase 1 SA. Thanks, Stephane. From owner-ietf-ipsra Thu May 20 11:05:10 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA26465 for ietf-ipsra-bks; Thu, 20 May 1999 11:05:10 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA26461 for ; Thu, 20 May 1999 11:05:09 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 25QQPSK9; Thu, 20 May 1999 11:06:54 -0700 Message-ID: <37444F2D.1496E565@redcreek.com> Date: Thu, 20 May 1999 11:06:37 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: ipsec@lists.tislabs.com, ipsra Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA971B4@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Stephane, Stephane Beaulieu wrote: > > > > > Perhaps more importantly, I was also referring to the stability, > > > analyzability, and other security-related properties of IKE. I think > > > adding proxy servers for even 1 (let alone 16) secondary > > > authentication > > > protocols substantially impacts upon the security > > > characteristics of the > > > implementation. > > > I assume that by this you mean that if a Phase 1 SA is used to secure XAUTH > messages, then the Phase 1 SA becomes more susceptible to attack as more > XAUTH data is encrypted. If not, please elaborate. > No, actually I'm referring to stability, analyzability, and other security characteristics. Adding more complexity and states to IKE makes it harder to analyze, and more susceptible to a variety of attacks. There are a number of people better qualified to discuss this than I am who might want to jump in here... > > > I'm missing the point again, I think. What is it about setting up > > multiple SAs (2 in this case) which is insecure, and how is this > > different than rekeying? > > > If I did interprate your above comment correctly... My point was that > whether you secure an XAUTH transaction with a Phase 1 SA or whether you use > a Phase 1 SA to spawn a Phase 2 SA to secure an XAUTH transaction your > reducing the lifetime of a Phase 1 SA. Okay, I agree that you're consuming phase 1 entropy, but it's only insecure if you don't have enough entropy to begin with, which can be remedied in a number of ways, including starting with more, or rekeying, right? Scott From owner-ietf-ipsra Thu May 20 11:18:24 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA26491 for ietf-ipsra-bks; Thu, 20 May 1999 11:18:24 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from nsa-mail.us.newbridge.com (nsa-mail.us.newbridge.com [209.58.11.226]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA26487 for ; Thu, 20 May 1999 11:18:22 -0700 (PDT) Received: from nsa-gw1.us.newbridge.com (nsa-gw1 [209.58.11.225]) by nsa-mail.us.newbridge.com (8.9.3/8.9.3) with SMTP id OAA14709 for ; Thu, 20 May 1999 14:17:56 -0400 (EDT) Received: from kanata-mh1.ca.newbridge.com by nsa-gw1.us.newbridge.com via smtpd (for nsa-mail.us.newbridge.com [209.58.11.226]) with SMTP; 20 May 1999 18:19:45 UT Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 20 May 1999 14:19:44 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Thu, 20 May 1999 14:22:17 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA971E3@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 14:22:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Scott, > No, actually I'm referring to stability, analyzability, and other > security characteristics. Adding more complexity and states > to IKE makes > it harder to analyze, and more susceptible to a variety of attacks. > There are a number of people better qualified to discuss this > than I am > who might want to jump in here... > I see, sorry for the confusion. Please disregard my comments about reducing the entropy. I don't see how XAUTH complicates IKE to a level where IKE might become unstable. IKE simply goes from Phase1 - Phase2, to Phase1 - XAUTH - Phase2. The only other solution to the problem I've heard is Phase1 - Phase2(but only special phase2's destined to Authentication servers) - Phase2. This seems even more complicated to me. Not to mention it seems easier to make a configuration / implementation mistake here. Once again, sorry for the confusion. Stephane. From owner-ietf-ipsra Mon May 24 06:08:29 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id GAA03962 for ietf-ipsra-bks; Mon, 24 May 1999 06:08:29 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206253200-36.ricochet.net [206.253.200.36]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA03958 for ; Mon, 24 May 1999 06:08:16 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id GAA17764; Mon, 24 May 1999 06:02:30 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Stephane Beaulieu'" , "'canetti'" , Cc: "'ipsra'" Subject: RE: New XAUTH draft Date: Mon, 24 May 1999 06:19:41 -0700 Message-ID: <000001bea5e8$15f7a720$268939cc@internaut.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFA9715B@exchange> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >For example, a user might need to talk to a DHCP server, a RADIUS accounting >server, and an SDI server. The RADIUS protocol (RFC 2138 and 2139) does not involve users interacting with RADIUS authentication or accounting servers. Rather, the peer speaks PPP to a NAS device, which then uses RADIUS to communicate with a central server. Rather than including RADIUS as an authentication method in XAUTH, the draft should be revised to include EAP as the authentication method. EAP supports extended authentication methods, including SDI and CHAP (EAP-MD5) so that the draft could be simplified by doing this. I would also argue that the draft needs to include GSS_API as a method. I would agree that a user might need to "talk" to a DHCP server, for example, via DHCP INFORM. This is the right architecture, since doing otherwise (as IKECFG does), would eventually lead you down the road of duplicating the existing DHCP options. From owner-ietf-ipsra Mon May 24 06:15:58 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id GAA03978 for ietf-ipsra-bks; Mon, 24 May 1999 06:15:58 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206253200-36.ricochet.net [206.253.200.36]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA03974 for ; Mon, 24 May 1999 06:15:46 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id GAA17771; Mon, 24 May 1999 06:09:10 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Stephane Beaulieu'" , "'Scott G. Kelly'" Cc: , "'ipsra'" Subject: RE: New XAUTH draft Date: Mon, 24 May 1999 06:26:22 -0700 Message-ID: <000101bea5e9$04aa8680$268939cc@internaut.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFA9716B@exchange> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > Imagine a policy which permits any client to access a radius server > behind the sgw, but limits all other access. According to RFC 2138, clients do not access RADIUS servers. This is not possible within the RADIUS protocol. Perhaps you mean that the client speaks EAP to the tunnel server, which then speaks RADIUS to the RADIUS server? >When a client wishes to access the protected net, it forms >a radius-only SA, and through this authenticates with the >radius server. This scenario makes no sense. Again, under RFC 2138, clients do not interact with RADIUS servers. If this is really what you have in mind (I think you mean EAP instead), can you explain what the client is supposed to do with the RADIUS authorizations that come back in the Access-Accept? What if the server sends a Filter-ID attribute? Is this used to influence IPSEC filter policy? Enforcement of security-related RADIUS attributes on the client does not make sense. From owner-ietf-ipsra Tue Jun 15 07:33:24 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id HAA19640 for ietf-ipsra-bks; Tue, 15 Jun 1999 07:33:24 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.internet-zahav.net [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id HAA19636 for ; Tue, 15 Jun 1999 07:33:21 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id RAA04366 for ; Tue, 15 Jun 1999 17:36:55 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA27353; Tue, 15 Jun 99 17:37:03 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma027351; Tue, 15 Jun 99 17:36:56 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id RAA05671; Tue, 15 Jun 1999 17:37:42 +0200 Message-Id: <376665C5.E475CFA2@radguard.com> Date: Tue, 15 Jun 1999 17:40:06 +0300 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: ipsra Subject: XAUTH and CFG conflict Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >From the ISAKMP configuration draft: A "Configuration Transaction" is defined as two configuration exchanges, the first being either a Set or a Request and the second being either an Acknowledge or a Reply, respectively. A common identifier is used to identify the transaction between exchanges. XAUTH consists of at least four configuration exchanges. Is XAUTH several configuration transactions? If the answer is yes, it means that it would have several configuration transaction identifiers and that the XAUTH transaction does not have an identifier. I assume this was not the intent and therefor we need clarifications in the draft(s). From owner-ietf-ipsra Tue Jun 15 07:43:43 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id HAA19651 for ietf-ipsra-bks; Tue, 15 Jun 1999 07:43:43 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id HAA19647 for ; Tue, 15 Jun 1999 07:43:41 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19370; Tue, 15 Jun 1999 10:47:05 -0400 (EDT) Message-Id: <199906151447.KAA19370@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gupta-ipsec-remote-access-02.txt Date: Tue, 15 Jun 1999 10:47:03 -0400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure, Remote Access over the Internet using IPSec Author(s) : V. Gupta Filename : draft-gupta-ipsec-remote-access-02.txt Pages : 18 Date : 14-Jun-99 This memo describes the use of IPSec [KeAt98a-c] for secure access to protected networks by authorized users connected to the Internet. An example target scenario is a corporate employee on the road accessing resources on his company's Intranet. It addresses firewall traversal, user authentication, data confidentiality and the use of private address spaces (the latter impacts routing and name lookups). A comparison to other mechanisms such as those based on Layer-2 tunneling or session layer security, is also included. This memo draws upon several ideas from [Dora97,Mosk98] and would not have been possible without the contributions of the IETF working groups on IP Security (IPSec) and Network Address Translation (NAT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt 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-gupta-ipsec-remote-access-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-gupta-ipsec-remote-access-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: <19990614112446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gupta-ipsec-remote-access-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-gupta-ipsec-remote-access-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990614112446.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra Tue Jun 15 07:57:52 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id HAA19674 for ietf-ipsra-bks; Tue, 15 Jun 1999 07:57:52 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id HAA19670 for ; Tue, 15 Jun 1999 07:57:50 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id LAA24955 for ietf-ipsra@vpnc.org; Tue, 15 Jun 1999 11:01:44 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76) via SMTP by ns.newbridge.com, id smtpdAAAa24932; Tue Jun 15 11:01:34 1999 Received: from kanata-mh1.ca.newbridge.com by portal1.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 15 Jun 1999 15:06:31 UT Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Tue, 15 Jun 1999 11:00:34 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 15 Jun 1999 11:03:23 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB3C3B9@exchange> From: Stephane Beaulieu To: Yael Dayan , ipsra Subject: RE: XAUTH and CFG conflict Date: Tue, 15 Jun 1999 11:03:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: There is some text in the XAUTH draft which relates to this. 3 Extensions to ISAKMP-Config This protocol uses the mechanisms described in ISAKMP-Config [IKECFG] to accomplish its authentication transaction. All ISAKMP-Config messages in an extended authentication transaction MUST contain the same ISAKMP-Config message ID. This protocol can therefore be used in conjunction with any existing basic ISAKMP authentication method as defined in [IKE]. Therefore, an "XAUTH transaction" is made up of several "configuration exchanges", and all exchanges within the XAUTH transaction use the same ISAKMP-Config message ID. I see that it still may be a little confusing though. I will add more detail in the next rev. Thanks, Stephane. > -----Original Message----- > From: Yael Dayan [mailto:yael@radguard.com] > Sent: Tuesday, June 15, 1999 10:40 AM > To: ipsra > Subject: XAUTH and CFG conflict > > > > From the ISAKMP configuration draft: > A "Configuration Transaction" is defined as two configuration > exchanges, the first being either a Set or a Request and the second > being either an Acknowledge or a Reply, respectively. A common > identifier is used to identify the transaction between exchanges. > > XAUTH consists of at least four configuration exchanges. > Is XAUTH several configuration transactions? > If the answer is yes, it means that it would have several > configuration > transaction identifiers and that the XAUTH transaction does > not have an > identifier. > I assume this was not the intent and therefor we need > clarifications in > the draft(s). > > > From owner-ietf-ipsra Tue Jun 15 08:15:12 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id IAA19702 for ietf-ipsra-bks; Tue, 15 Jun 1999 08:15:12 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.internet-zahav.net [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA19698 for ; Tue, 15 Jun 1999 08:15:09 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id SAA12283; Tue, 15 Jun 1999 18:17:16 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA27599; Tue, 15 Jun 99 18:17:37 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma027596; Tue, 15 Jun 99 18:17:17 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id SAA08725; Tue, 15 Jun 1999 18:18:03 +0200 Message-Id: <37666F3B.288FABA0@radguard.com> Date: Tue, 15 Jun 1999 18:20:27 +0300 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: Stephane Beaulieu Cc: ipsra Subject: Re: XAUTH and CFG conflict References: <319A1C5F94C8D11192DE00805FBBADDFB3C3B9@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Stephane, Maybe it's the configuration transaction definition in the CFG draft that needs a fix. Stephane Beaulieu wrote: > There is some text in the XAUTH draft which relates to this. > > 3 Extensions to ISAKMP-Config > > This protocol uses the mechanisms described in ISAKMP-Config > [IKECFG] to accomplish its authentication transaction. > > All ISAKMP-Config messages in an extended authentication > transaction MUST contain the same ISAKMP-Config message ID. > > This protocol can therefore be used in conjunction with any > existing basic ISAKMP authentication method as defined in [IKE]. > > Therefore, an "XAUTH transaction" is made up of several "configuration > exchanges", and all exchanges within the XAUTH transaction use the same > ISAKMP-Config message ID. > > I see that it still may be a little confusing though. I will add more > detail in the next rev. > > Thanks, > Stephane. > > > -----Original Message----- > > From: Yael Dayan [mailto:yael@radguard.com] > > Sent: Tuesday, June 15, 1999 10:40 AM > > To: ipsra > > Subject: XAUTH and CFG conflict > > > > > > > > From the ISAKMP configuration draft: > > A "Configuration Transaction" is defined as two configuration > > exchanges, the first being either a Set or a Request and the second > > being either an Acknowledge or a Reply, respectively. A common > > identifier is used to identify the transaction between exchanges. > > > > XAUTH consists of at least four configuration exchanges. > > Is XAUTH several configuration transactions? > > If the answer is yes, it means that it would have several > > configuration > > transaction identifiers and that the XAUTH transaction does > > not have an > > identifier. > > I assume this was not the intent and therefor we need > > clarifications in > > the draft(s). > > > > > > From owner-ietf-ipsra Tue Jun 22 19:54:20 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id TAA07701 for ietf-ipsra-bks; Tue, 22 Jun 1999 19:54:20 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from trinc.com (steffi.trinc.com [206.40.37.34] (may be forged)) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id TAA07697 for ; Tue, 22 Jun 1999 19:54:18 -0700 (PDT) Received: from intotoinc.com by trinc.com (8.8.7/SMI-SVR4) id TAA16727; Tue, 22 Jun 1999 19:52:56 -0700 (PDT) Message-ID: <37704DF3.311FAC5A@intotoinc.com> Date: Tue, 22 Jun 1999 20:01:08 -0700 From: Srinivasa Rao Addepalli Organization: TRI X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ietf-ipsra@vpnc.org Subject: Authentication for remote access clients Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, Whenever IKE receives phase1 first message, it selects IKE policy from the database of IKE policies, based on the remote IP address ( Which can be read from the UDP layer ) and selects the transform and sends second message. In case of Remote Clients ( whose IP address keeps changing ), the NAS ( Network Access Server) should be configured with the default policy so that any phase1 exchange initiated by the remote client will use this default policy. If my above assumption is right, then we can have only one policy on NAS ie default policy. That means I can have only one preshared key which will be known to all remote access users. In this case, for further authentication, extended auth schme can be used. Now my question is, is this OK to share preshared key with all remote access users? I may be wrong in my assumptions. Can somebody clarify this? Thanks in advance Srini From owner-ietf-ipsra Wed Jun 23 00:58:57 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id AAA07922 for ietf-ipsra-bks; Wed, 23 Jun 1999 00:58:57 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.internet-zahav.net [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id AAA07918 for ; Wed, 23 Jun 1999 00:58:54 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id LAA20793; Wed, 23 Jun 1999 11:01:43 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA04142; Wed, 23 Jun 99 11:01:33 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma004140; Wed, 23 Jun 99 11:01:09 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id LAA12735; Wed, 23 Jun 1999 11:01:56 +0200 Message-Id: <37709522.52BB79C0@radguard.com> Date: Wed, 23 Jun 1999 11:04:50 +0300 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: Srinivasa Rao Addepalli Cc: ietf-ipsra@vpnc.org Subject: Re: Authentication for remote access clients References: <37704DF3.311FAC5A@intotoinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: I believe you are assuming Phase I with identity protection. Without identity protection you can use the identity as the basis for your policy decisions. Srinivasa Rao Addepalli wrote: > Hi, > Whenever IKE receives phase1 first message, it selects IKE > policy from the database of IKE policies, based on the remote > IP address ( Which can be read from the UDP layer ) and > selects the transform and sends second message. > In case of Remote Clients ( whose IP address keeps changing ), > the NAS ( Network Access Server) should be configured with > the default policy so that any phase1 exchange initiated by > the remote client will use this default policy. > > If my above assumption is right, then we can have only one > policy on NAS ie default policy. That means I can have only > one preshared key which will be known to all remote access users. > In this case, for further authentication, extended auth schme > can be used. Now my question is, is this OK to share preshared > key with all remote access users? > > I may be wrong in my assumptions. Can somebody clarify this? > > Thanks in advance > Srini From owner-ietf-ipsra Wed Jun 23 10:43:18 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA10286 for ietf-ipsra-bks; Wed, 23 Jun 1999 10:43:18 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from trinc.com (steffi.trinc.com [206.40.37.34] (may be forged)) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA10282 for ; Wed, 23 Jun 1999 10:43:15 -0700 (PDT) Received: from intotoinc.com by trinc.com (8.8.7/SMI-SVR4) id KAA23142; Wed, 23 Jun 1999 10:41:44 -0700 (PDT) Message-ID: <37711E42.AC0A3EDF@intotoinc.com> Date: Wed, 23 Jun 1999 10:49:55 -0700 From: Srinivasa Rao Addepalli Organization: TRI X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Yael Dayan , sankar@vpnet.com CC: Srinivasa Rao Addepalli , ietf-ipsra@vpnc.org Subject: Re: Authentication for remote access clients References: <37704DF3.311FAC5A@intotoinc.com> <37709522.52BB79C0@radguard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Does it mean that, in these scenarios, we should use aggressive mode only? Regards Srini Yael Dayan wrote: > I believe you are assuming Phase I with identity protection. > Without identity protection you can use the identity as the basis for > your policy decisions. > > Srinivasa Rao Addepalli wrote: > > > Hi, > > Whenever IKE receives phase1 first message, it selects IKE > > policy from the database of IKE policies, based on the remote > > IP address ( Which can be read from the UDP layer ) and > > selects the transform and sends second message. > > In case of Remote Clients ( whose IP address keeps changing ), > > the NAS ( Network Access Server) should be configured with > > the default policy so that any phase1 exchange initiated by > > the remote client will use this default policy. > > > > If my above assumption is right, then we can have only one > > policy on NAS ie default policy. That means I can have only > > one preshared key which will be known to all remote access users. > > In this case, for further authentication, extended auth schme > > can be used. Now my question is, is this OK to share preshared > > key with all remote access users? > > > > I may be wrong in my assumptions. Can somebody clarify this? > > > > Thanks in advance > > Srini From owner-ietf-ipsra Wed Jun 23 11:21:04 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA10365 for ietf-ipsra-bks; Wed, 23 Jun 1999 11:21:04 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA10361 for ; Wed, 23 Jun 1999 11:21:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01524; Wed, 23 Jun 1999 11:25:33 -0700 (PDT) Received: from nobel.eng.sun.com (nobel.Eng.Sun.COM [129.146.122.141]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id LAA23071; Wed, 23 Jun 1999 11:25:31 -0700 (PDT) Received: from nobel by nobel.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08836; Wed, 23 Jun 1999 11:16:05 -0700 Date: Wed, 23 Jun 1999 11:16:05 -0700 (PDT) From: Vipul Gupta X-Sender: vgupta@nobel To: Srinivasa Rao Addepalli cc: ietf-ipsra@vpnc.org Subject: Re: Authentication for remote access clients In-Reply-To: <37704DF3.311FAC5A@intotoinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Note that this is not a problem if you use digital signatures with Main mode or use aggressive mode with pre-shared keys. In those cases, you can assign each remote user a different key. Main mode + pre-shared keys doesn't work for the remote access situation if the remote user could be using a dynamically allocated IP address. This is described in more detail in Section 3 of http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt vipul On Tue, 22 Jun 1999, Srinivasa Rao Addepalli wrote: > Hi, > Whenever IKE receives phase1 first message, it selects IKE > policy from the database of IKE policies, based on the remote > IP address ( Which can be read from the UDP layer ) and > selects the transform and sends second message. > In case of Remote Clients ( whose IP address keeps changing ), > the NAS ( Network Access Server) should be configured with > the default policy so that any phase1 exchange initiated by > the remote client will use this default policy. > > If my above assumption is right, then we can have only one > policy on NAS ie default policy. That means I can have only > one preshared key which will be known to all remote access users. > In this case, for further authentication, extended auth schme > can be used. Now my question is, is this OK to share preshared > key with all remote access users? > > > I may be wrong in my assumptions. Can somebody clarify this? > > Thanks in advance > Srini > > > From owner-ietf-ipsra Wed Jun 23 12:54:59 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id MAA10520 for ietf-ipsra-bks; Wed, 23 Jun 1999 12:54:59 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from trinc.com (steffi.trinc.com [206.40.37.34] (may be forged)) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA10516 for ; Wed, 23 Jun 1999 12:54:56 -0700 (PDT) Received: from intotoinc.com by trinc.com (8.8.7/SMI-SVR4) id MAA24545; Wed, 23 Jun 1999 12:53:34 -0700 (PDT) Message-ID: <37713D29.34AF8F25@intotoinc.com> Date: Wed, 23 Jun 1999 13:01:45 -0700 From: Srinivasa Rao Addepalli Organization: TRI X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Vipul Gupta CC: Srinivasa Rao Addepalli , ietf-ipsra@vpnc.org Subject: Re: Authentication for remote access clients References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, I have gone through the document and it is good one. Some of the points made us clear on our thoughts of implementing remote access solution. I still have some questions though. I agree that aggressive mode with preshared keys will solve my problem. Only problem with this is, it is not MUST exchange. How does main mode with digital signature solve the problem of having multiple IKE policies for remote users. Since, in the main mode, the identities have to be protected, the certificate can be sent only in the fifth message ( Certificate has ID in subjectAltName ). That means, the identity of the peer is known only in the fifth message. From this, it seems that only aggressive mode can be used for remote access purpose, if the NAS need to support multiple IKE policies for remote access. In your draft document, you had given two scenarios to map remote host to an 'internal presence'. I feel, second way ie dynamically assigning an internal adress to the remote host may be better. Even here, I prefer, first alternative ie ISAKMP configuration method for assigning IP address, mask, DNS Server etc.. for the following reason. By using configuration methiod, NAS has control to do things like creating proxy ARP entry for the address assigned to the remote host. Thereby all packets including IP broadcasts can be sent to the remote hosts giving sense of physical presence in the protected network. Regards Srini Vipul Gupta wrote: > Note that this is not a problem if you use digital signatures > with Main mode or use aggressive mode with pre-shared keys. > In those cases, you can assign each remote user a different > key. > > Main mode + pre-shared keys doesn't work for the > remote access situation if the remote user could be using > a dynamically allocated IP address. This is described in more > detail in Section 3 of > > http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt > > vipul > > On Tue, 22 Jun 1999, Srinivasa Rao Addepalli wrote: > > > Hi, > > Whenever IKE receives phase1 first message, it selects IKE > > policy from the database of IKE policies, based on the remote > > IP address ( Which can be read from the UDP layer ) and > > selects the transform and sends second message. > > In case of Remote Clients ( whose IP address keeps changing ), > > the NAS ( Network Access Server) should be configured with > > the default policy so that any phase1 exchange initiated by > > the remote client will use this default policy. > > > > If my above assumption is right, then we can have only one > > policy on NAS ie default policy. That means I can have only > > one preshared key which will be known to all remote access users. > > In this case, for further authentication, extended auth schme > > can be used. Now my question is, is this OK to share preshared > > key with all remote access users? > > > > > > I may be wrong in my assumptions. Can somebody clarify this? > > > > Thanks in advance > > Srini > > > > > > From owner-ietf-ipsra Fri Jun 25 11:39:52 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA15614 for ietf-ipsra-bks; Fri, 25 Jun 1999 11:39:52 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA15603; Fri, 25 Jun 1999 11:39:48 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id OAA19498; Fri, 25 Jun 1999 14:44:35 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa19477; Fri Jun 25 14:44:27 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Fri, 25 Jun 1999 14:44:24 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Fri, 25 Jun 1999 14:46:49 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB8EEDB@exchange> From: Stephane Beaulieu To: Glen Zorn , Stephane Beaulieu , Paul Hoffman / VPNC , vpnc-technical@vpnc.org Cc: ipsec , ipsra Subject: RE: Getting the features chart going Date: Fri, 25 Jun 1999 14:46:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > The alternatives to XAUTH/ISAKMP-config of which I'm aware > are documented in > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hy > brid-auth-02.t > xt and Again, Hybrid uses XAUTH (and implicitly ISAKMP-Config)to accomplish legacy authentication. It also modifies the behavior of IKE, thus making IKE more complex. > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-01.txt; This is a good alternative to ISAKMP-Config. I have a few reservations about creating specialty phase2 tunnels to configuration servers though. However, it does solve the same problem as ISAKMP-Config in a pretty simple, straightforward way and we can surely discuss the pro's and con's of both drafts in order to attempt to arrive at a standard. > there may be others. The major benefits of L2TP over hacking > IKE are pretty > obvious, I think, but include _real_ interoperability, the use of > well-understood protocols for both authentication and remote node > configuration. A more interesting question is why anyone > would favor the > invention of novel extensions to a protocol that is already > far too complex > over the use of widely-deployed, proven techniques. I understand that > firewall vendors have generally not implemented PPP, but > building a basic, > interoperable implementation of either PPP or L2TP is simple > enough to be a > college CS project. IMHO, the introduction of ISAKMP-Config into IKE is **FAR** more simple than implementing L2TP. From owner-ietf-ipsra Fri Jun 25 12:13:07 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id MAA15696 for ietf-ipsra-bks; Fri, 25 Jun 1999 12:13:07 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id MAA15692 for ; Fri, 25 Jun 1999 12:13:05 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Jun 1999 12:05:34 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Jun 1999 12:05:35 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF16F71920@RED-MSG-52> From: Glen Zorn To: Stephane Beaulieu , Stephane Beaulieu , Paul Hoffman / VPNC , vpnc-technical@vpnc.org Cc: ipsec , ipsra Subject: RE: Getting the features chart going Date: Fri, 25 Jun 1999 12:05:28 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Yes, I seem to have misread the hybrid auth draft. -----Original Message----- From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] Sent: Friday, June 25, 1999 11:47 AM To: Glen Zorn; Stephane Beaulieu; Paul Hoffman / VPNC; vpnc-technical@vpnc.org Cc: ipsec; ipsra Subject: RE: Getting the features chart going > The alternatives to XAUTH/ISAKMP-config of which I'm aware > are documented in > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hy > brid-auth-02.t > xt and Again, Hybrid uses XAUTH (and implicitly ISAKMP-Config)to accomplish legacy authentication. It also modifies the behavior of IKE, thus making IKE more complex. > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-01.txt; This is a good alternative to ISAKMP-Config. I have a few reservations about creating specialty phase2 tunnels to configuration servers though. However, it does solve the same problem as ISAKMP-Config in a pretty simple, straightforward way and we can surely discuss the pro's and con's of both drafts in order to attempt to arrive at a standard. > there may be others. The major benefits of L2TP over hacking > IKE are pretty > obvious, I think, but include _real_ interoperability, the use of > well-understood protocols for both authentication and remote node > configuration. A more interesting question is why anyone > would favor the > invention of novel extensions to a protocol that is already > far too complex > over the use of widely-deployed, proven techniques. I understand that > firewall vendors have generally not implemented PPP, but > building a basic, > interoperable implementation of either PPP or L2TP is simple > enough to be a > college CS project. IMHO, the introduction of ISAKMP-Config into IKE is **FAR** more simple than implementing L2TP. From owner-ietf-ipsra Fri Jun 25 12:26:36 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id MAA15717 for ietf-ipsra-bks; Fri, 25 Jun 1999 12:26:36 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA15713 for ; Fri, 25 Jun 1999 12:26:35 -0700 (PDT) Received: from cyphers.net (blowfish.cyphers.net [205.178.102.84]) by enigma.cyphers.net (8.9.3/8.8.7) with ESMTP id LAA02598; Fri, 25 Jun 1999 11:31:47 -0700 Message-ID: <3773D8E3.782624F3@cyphers.net> Date: Fri, 25 Jun 1999 12:31:12 -0700 From: Will Price X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu , Glen Zorn CC: ipsec , ipsra Subject: Re: Getting the features chart going References: <319A1C5F94C8D11192DE00805FBBADDFB8EEDB@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [[ Not sure who wrote the double quoted text here, maybe Glen??? The attribution was removed and some messages were left off the main list.]] > > there may be others. The major benefits of L2TP over hacking > > IKE are pretty > > obvious, I think Terms like "obvious" and "clearly" are an emotional response that seems unclear given that a large number of vendors have in fact chosen to use the route this poster thinks is "obvious"ly wrong. > > but include _real_ interoperability, As opposed to fake interoperability? There is a simple problem to solve here. Remote clients need an internal IP, DNS, and WINS address. ISAKMP-cfg gives it to them in a very simple addition to a protocol everyone here has already implemented, IKE. > > the use of > > well-understood protocols for both authentication and remote node > > configuration. IKE is a well understood protocol to everyone here. ISAKMP-cfg is so simple I can't imagine anyone saying it isn't well understood. Trying to bring L2TP, PPP, IKE, and IPSEC together all at once is far more likely to introduce these interoperability and not well understood issues that you raise. > > A more interesting question is why anyone > > would favor the > > invention of novel extensions to a protocol that is already > > far too complex > > over the use of widely-deployed, proven techniques. It must be a conspiracy. Seriously, while IKE may be complex, it has the significant advantage that everyone here already understands it quite well, has already implemented it, and IMHO didn't find it to be far too complex. I'm not sure what you mean by widely-deployed and proven techniques. The issue of whether an old implementation of PPTP happens to be deployed in NT is really orthogonal to the problems here. L2TP/PPP/IKE/IPSEC as a solution is not widely deployed by any stretch of the imagination. > > I understand that > > firewall vendors have generally not implemented PPP, but > > building a basic, > > interoperable implementation of either PPP or L2TP is simple > > enough to be a > > college CS project. Yes, firewall vendors would have implementation issues with L2TP/PPP/IKE/IPSEC. Throw the client vendors into that too. I'm not sure who that leaves wanting to surgically require four protocols L2TP/PPP/IKE/IPSEC for the simple issue of getting internal IP info. Stephane Beaulieu wrote: > IMHO, the introduction of ISAKMP-Config into IKE is **FAR** more > simple than implementing L2TP. Agreed. I posted to the main list about 2 months ago asking how many people had implemented isakmp-cfg and got a large number of replies. Most of the vendors I talked to at the bakeoff were also planning to support it or already do. I think the cat's already out of the bag on this. Personally, we don't support it yet, but we look forward to doing interop testing on it at the next bakeoff. - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 iQA/AwUBN3PX1ay7FkvPc+xMEQK8TgCgj2gBZFzTI4ccaz8K8JJOxSdhj4kAoMf0 z+WKlGg6bEvB/Yxce86saCXM =p6pV -----END PGP SIGNATURE----- From owner-ietf-ipsra Fri Jun 25 14:37:13 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id OAA15964 for ietf-ipsra-bks; Fri, 25 Jun 1999 14:37:13 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA15960 for ; Fri, 25 Jun 1999 14:37:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27341; Fri, 25 Jun 1999 14:41:50 -0700 (PDT) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.101.37]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id OAA18505; Fri, 25 Jun 1999 14:41:48 -0700 (PDT) Received: from nobel by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00787; Fri, 25 Jun 1999 14:41:47 -0700 Date: Fri, 25 Jun 1999 14:32:46 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Authentication for remote access clients To: srao@intotoinc.com, ietf-ipsra@vpnc.org Cc: vgupta@Eng.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Hmymy82zvezxpC0k1jb0CA== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: See my comments below. > Date: Wed, 23 Jun 1999 13:01:45 -0700 > From: Srinivasa Rao Addepalli > To: Vipul Gupta > > Hi, > I have gone through the document and it is good one. Some of > the points made us clear on our thoughts of implementing remote > access solution. > I still have some questions though. > > I agree that aggressive mode with preshared keys will > solve my problem. Only problem with this is, it is not > MUST exchange. > > How does main mode with digital signature solve the problem > of having multiple IKE policies for remote users. Since, in the > main mode, the identities have to be protected, the certificate can > be sent only in the fifth message ( Certificate has ID in > subjectAltName ). That means, the identity of the peer is > known only in the fifth message. I should have worded my response more carefully. You are right that when the first Main mode message arrives from a remote user, the responder can only look at the IP address in deciding whether to respond. Since the remote address may be dynamically assigned, there isn't much choice but to configure the responder's policy to always respond. Note, however, that the responder may still decide to abort the Phase I exchange after it finds the initiator's identity and checks that against local policy. When I said that Main mode w/ signatures will solve your problem, I was only addressing your following comment: "That means I can have only one preshared key which will be known to all remote access users." With Main Mode+signatures you can assign different public-private key pairs to different users and you don't need to know this key in order to decrypt the fifth message containing the identity. You can look up the appropriate key after you decrypt the initiator's identity. > From this, it seems that only aggressive mode can be used > for remote access purpose, if the NAS need to support multiple > IKE policies for remote access. > > In your draft document, you had given two scenarios to map > remote host to an 'internal presence'. I feel, second way ie > dynamically assigning an internal adress to the remote host may be better. Agreed. NAT should be avoided whenever possible. > Even here, I prefer, first alternative ie ISAKMP configuration > method for assigning IP address, mask, DNS Server etc.. for the > following reason. > > By using configuration methiod, NAS has control to do things > like creating proxy ARP entry for the address assigned to the remote > host. Thereby all packets including IP broadcasts can be sent to the > remote hosts giving sense of physical presence in the protected > network. I don't see how the DHCP-based approach precludes this. Please explain. Regards, vipul > Regards > Srini > > > > Vipul Gupta wrote: > > > Note that this is not a problem if you use digital signatures > > with Main mode or use aggressive mode with pre-shared keys. > > In those cases, you can assign each remote user a different > > key. > > > > Main mode + pre-shared keys doesn't work for the > > remote access situation if the remote user could be using > > a dynamically allocated IP address. This is described in more > > detail in Section 3 of > > > > http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt > > > > vipul > > > > On Tue, 22 Jun 1999, Srinivasa Rao Addepalli wrote: > > > > > Hi, > > > Whenever IKE receives phase1 first message, it selects IKE > > > policy from the database of IKE policies, based on the remote > > > IP address ( Which can be read from the UDP layer ) and > > > selects the transform and sends second message. > > > In case of Remote Clients ( whose IP address keeps changing ), > > > the NAS ( Network Access Server) should be configured with > > > the default policy so that any phase1 exchange initiated by > > > the remote client will use this default policy. > > > > > > If my above assumption is right, then we can have only one > > > policy on NAS ie default policy. That means I can have only > > > one preshared key which will be known to all remote access users. > > > In this case, for further authentication, extended auth schme > > > can be used. Now my question is, is this OK to share preshared > > > key with all remote access users? > > > > > > > > > I may be wrong in my assumptions. Can somebody clarify this? > > > > > > Thanks in advance > > > Srini > > > > > > > > > > > > From owner-ietf-ipsra Fri Jun 25 14:43:31 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id OAA15974 for ietf-ipsra-bks; Fri, 25 Jun 1999 14:43:31 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA15970 for ; Fri, 25 Jun 1999 14:43:29 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRQHKD; Fri, 25 Jun 1999 14:48:53 -0700 Message-ID: <3773F95E.51D9D213@redcreek.com> Date: Fri, 25 Jun 1999 14:49:18 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Will Price CC: Stephane Beaulieu , Glen Zorn , ipsec , ipsra Subject: Re: Getting the features chart going References: <319A1C5F94C8D11192DE00805FBBADDFB8EEDB@exchange> <3773D8E3.782624F3@cyphers.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Will Price wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [[ Not sure who wrote the double quoted text here, maybe Glen??? The > attribution was removed and some messages were left off the main > list.]] > > > there may be others. The major benefits of L2TP over hacking > > > IKE are pretty > > > obvious, I think > > Terms like "obvious" and "clearly" are an emotional response that > seems unclear given that a large number of vendors have in fact > chosen to use the route this poster thinks is "obvious"ly wrong. > >From the sounds of it, only a handful of vendors have actually implemented this so far. The fact is that it has not been fully debated in terms of security risks and other areas of concern as of yet, and that is one of the tasks that could lead to an ipsec remote access (ipsra) working group. Charging ahead full steam prior to this debate could be reckless... > > > the use of > > > well-understood protocols for both authentication and remote node > > > configuration. > > IKE is a well understood protocol to everyone here. I'm not so sure about this, especially given some of the cryptographic subtleties. That's not to say the there aren't people reading this who understand it very well, but... everyone here? Read http://www.ietf.org/internet-drafts/draft-simpson-danger-isakmp-01.txt, if you haven't already. > ISAKMP-cfg is so > simple I can't imagine anyone saying it isn't well understood. > Trying to bring L2TP, PPP, IKE, and IPSEC together all at once is far > more likely to introduce these interoperability and not well > understood issues that you raise. Perhaps this second statement (interop issues, etc) is true, but on the other hand, DHCP provides all the functionality required for configuration, and relies only on the security of the underlying ipsec framework, with no risk of compromising IKE by adding additional states and opportunities for attack. The only meaningful drawback I've heard of so far pertains to the additional overhead required for the extra SA, and this is really more of an optimization issue than anything else. It's not clear that isakmp-cfg is simple, and it's also not at all clear that the additional challenges it presents in terms of analyzability, reliability, etc. with respect to security are worth the overhead gains over the dhcp approach. > > > > A more interesting question is why anyone > > > would favor the > > > invention of novel extensions to a protocol that is already > > > far too complex > > > over the use of widely-deployed, proven techniques. > > It must be a conspiracy. > > Seriously, while IKE may be complex, it has the significant advantage > that everyone here already understands it quite well, has already > implemented it, and IMHO didn't find it to be far too complex. As I said above, I don't think everyone here understands it all that well. Protocols take time to analyze. I think we need to split this discussion. Isamkp-cfg vs. dhcp is one issue, and xauth vs (???) is another. Scott From owner-ietf-ipsra Fri Jun 25 15:22:09 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id PAA16041 for ietf-ipsra-bks; Fri, 25 Jun 1999 15:22:09 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from intotoinc.com ([206.40.37.1]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA16037 for ; Fri, 25 Jun 1999 15:22:07 -0700 (PDT) Received: from intotoinc.com ([206.40.37.56]) by intotoinc.com (8.9.1/8.9.1) with ESMTP id PAA00676; Fri, 25 Jun 1999 15:21:18 -0700 (PDT) Message-ID: <377402BD.BBCAE745@intotoinc.com> Date: Fri, 25 Jun 1999 15:29:17 -0700 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Vipul Gupta CC: ietf-ipsra@vpnc.org, vgupta@Eng.Sun.COM Subject: Re: Authentication for remote access clients References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, Vipul Gupta wrote: > See my comments below. > > > Date: Wed, 23 Jun 1999 13:01:45 -0700 > > From: Srinivasa Rao Addepalli > > To: Vipul Gupta > > > > Hi, > > I have gone through the document and it is good one. Some of > > the points made us clear on our thoughts of implementing remote > > access solution. > > I still have some questions though. > > > > I agree that aggressive mode with preshared keys will > > solve my problem. Only problem with this is, it is not > > MUST exchange. > > > > How does main mode with digital signature solve the problem > > of having multiple IKE policies for remote users. Since, in the > > main mode, the identities have to be protected, the certificate can > > be sent only in the fifth message ( Certificate has ID in > > subjectAltName ). That means, the identity of the peer is > > known only in the fifth message. > > I should have worded my response more carefully. You are right > that when the first Main mode message arrives from a remote user, > the responder can only look at the IP address in deciding whether > to respond. Since the remote address may be dynamically assigned, > there isn't much choice but to configure the responder's policy > to always respond. Note, however, that the responder may still > decide to abort the Phase I exchange after it finds the initiator's > identity and checks that against local policy. > > When I said that Main mode w/ signatures will solve > your problem, I was only addressing your following comment: > > "That means I can have only one preshared key which will > be known to all remote access users." > > With Main Mode+signatures you can assign different public-private > key pairs to different users and you don't need to know this key > in order to decrypt the fifth message containing the identity. You > can look up the appropriate key after you decrypt the initiator's > identity. > > > From this, it seems that only aggressive mode can be used > > for remote access purpose, if the NAS need to support multiple > > IKE policies for remote access. > > > > In your draft document, you had given two scenarios to map > > remote host to an 'internal presence'. I feel, second way ie > > dynamically assigning an internal adress to the remote host may be better. > > Agreed. NAT should be avoided whenever possible. > > > Even here, I prefer, first alternative ie ISAKMP configuration > > method for assigning IP address, mask, DNS Server etc.. for the > > following reason. > > > > By using configuration methiod, NAS has control to do things > > like creating proxy ARP entry for the address assigned to the remote > > host. Thereby all packets including IP broadcasts can be sent to the > > remote hosts giving sense of physical presence in the protected > > network. > > I don't see how the DHCP-based approach precludes this. Please > explain. YOu are right. Even DHCP-based approach is also good. > > > Regards, > > vipul > > > Regards > > Srini > > > > > > > > Vipul Gupta wrote: > > > > > Note that this is not a problem if you use digital signatures > > > with Main mode or use aggressive mode with pre-shared keys. > > > In those cases, you can assign each remote user a different > > > key. > > > > > > Main mode + pre-shared keys doesn't work for the > > > remote access situation if the remote user could be using > > > a dynamically allocated IP address. This is described in more > > > detail in Section 3 of > > > > > > http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt > > > > > > vipul > > > > > > On Tue, 22 Jun 1999, Srinivasa Rao Addepalli wrote: > > > > > > > Hi, > > > > Whenever IKE receives phase1 first message, it selects IKE > > > > policy from the database of IKE policies, based on the remote > > > > IP address ( Which can be read from the UDP layer ) and > > > > selects the transform and sends second message. > > > > In case of Remote Clients ( whose IP address keeps changing ), > > > > the NAS ( Network Access Server) should be configured with > > > > the default policy so that any phase1 exchange initiated by > > > > the remote client will use this default policy. > > > > > > > > If my above assumption is right, then we can have only one > > > > policy on NAS ie default policy. That means I can have only > > > > one preshared key which will be known to all remote access users. > > > > In this case, for further authentication, extended auth schme > > > > can be used. Now my question is, is this OK to share preshared > > > > key with all remote access users? > > > > > > > > > > > > I may be wrong in my assumptions. Can somebody clarify this? > > > > > > > > Thanks in advance > > > > Srini > > > > > > > > > > > > > > > > > > RegardsSrini From owner-ietf-ipsra Fri Jun 25 23:37:59 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id XAA16365 for ietf-ipsra-bks; Fri, 25 Jun 1999 23:37:59 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206191146-18.ricochet.net [206.191.146.18]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id XAA16361 for ; Fri, 25 Jun 1999 23:37:55 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.42]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id XAA06806; Fri, 25 Jun 1999 23:40:22 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Will Price'" , "'Stephane Beaulieu'" , "'Glen Zorn'" Cc: "'ipsec'" , "'ipsra'" Subject: RE: Getting the features chart going Date: Fri, 25 Jun 1999 23:59:21 -0700 Message-ID: <00ec01bebfa1$6bf34ee0$2a8939cc@vaio> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3773D8E3.782624F3@cyphers.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >There is a simple problem to >solve here. Remote clients need an internal IP, DNS, and WINS >address. ISAKMP-cfg gives it to them in a very simple addition to a >protocol everyone here has already implemented, IKE. Actually, the problem is far from simple. If it were, we wouldn't need all the other DHCP options. ISAKMP-cfg should not go down the road toward becoming a general configuration mechanism, but instead should focus on IP address assignment while leveraging DHCP INFORM for the rest. >ISAKMP-cfg is so simple I can't imagine anyone saying it >isn't well understood. Part of the reason that ISAKMP-cfg should stick to IP address assignment is that the mechanism currently cannot negotiate parameters in the way that say, PPP can. For example, there is no real equivalent of a NAK. I think that this could conceivably cause problems if it were to attempt to become a more general configuration mechanism. From owner-ietf-ipsra Fri Jun 25 23:56:36 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id XAA16386 for ietf-ipsra-bks; Fri, 25 Jun 1999 23:56:36 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206191146-18.ricochet.net [206.191.146.18]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id XAA16382 for ; Fri, 25 Jun 1999 23:56:31 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.42]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id XAA06817; Fri, 25 Jun 1999 23:53:23 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Scott G. Kelly'" , "'Will Price'" Cc: "'Stephane Beaulieu'" , "'Glen Zorn'" , "'ipsec'" , "'ipsra'" Subject: RE: Getting the features chart going Date: Sat, 26 Jun 1999 00:12:23 -0700 Message-ID: <00ed01bebfa3$3dbfb160$2a8939cc@vaio> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3773F95E.51D9D213@redcreek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >The only meaningful drawback I've heard of >so far pertains to the additional overhead required for the extra SA, >and this is really more of an optimization issue than anything else. The creation and deletion of SAs that will result from this could limit scalability, so I think that a decent case has been made for allowing ISAKMP-cfg to assign IP addresses. However, that's *all* that I think it should do. Everything else should be handled by DHCP INFORM. That's the conclusion we came to in the PPP working group back in the early 90s. >It's not clear that isakmp-cfg is simple, and it's also not at all clear >that the additional challenges it presents in terms of analyzability, >reliability, etc. with respect to security are worth the overhead gains >over the dhcp approach. There are security risks associated with assignment of IP addresses; these threats are detailed in the authenticated DHCP draft. However, those threats mostly have to do with unauthenticated clients making large numbers of resource requests, or unauthenticated servers handing out bogus parameters. In this particular case, ISAKMP-cfg is only invoked *after* mutual authentication so that both sides know who they are talking to. That doesn't mean that the initiator or responder can't act badly, but it does imply that you'll know who is doing it. This is about as much assurance as you get with authenticated DHCP. >Isamkp-cfg vs. dhcp is one issue, and xauth vs (???) is another. > I would agree. I think that there is a decent case for ISAKMP-CFG, provided that functionality is very strictly limited. XAUTH is a much weaker proposal, primarily because it does not leverage existing IETF authentication frameworks such as SASL, GSS_API (useful when the initiator has obtained initial credentials) and EAP (useful as an initial authentication mechanism). One good thing about XAUTH is that it occurs after IKE phase 1 so that you have a protected channel in place and are already mutually authenticated. This means that any extended authentication negotiation will be protected against downlevel attacks, which has been a concern about naked SASL or EAP negotiations (GSS_API with SPNEGO is protected as long as the finally agreed upon method supports integrity protection). Given that existing frameworks already support most of the methods described in XAUTH, going with standard frameworks would not remove functionality while considerably increasing the ease of implementation and compatibility with existing IETF architecture. From owner-ietf-ipsra Sat Jun 26 11:15:47 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA18580 for ietf-ipsra-bks; Sat, 26 Jun 1999 11:15:47 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206191146-18.ricochet.net [206.191.146.18]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA18576 for ; Sat, 26 Jun 1999 11:15:42 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.42]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id LAA12804; Sat, 26 Jun 1999 11:18:22 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Scott G. Kelly'" , "'Will Price'" Cc: "'Stephane Beaulieu'" , "'Glen Zorn'" , "'ipsec'" , "'ipsra'" Subject: RE: Getting the features chart going Date: Sat, 26 Jun 1999 11:37:05 -0700 Message-ID: <014601bec002$e573ed40$2a8939cc@vaio> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <00ed01bebfa3$3dbfb160$2a8939cc@vaio> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Some questions about IKE-CFG: 1. Are all attributes mandatory? 2. What if a vendor adds support for a new non-standard attribute? How will this affect interoperability? Remember, the extension could be at the initiator or responder. What should happen when an initiator requests an attribute that the responder can't handle, or vice versa? Does this behavior enable vendor "bullying"? 3. Should only IANA-approved attributes be allowed? What is the procedure for IANA approval? From owner-ietf-ipsra Sun Jun 27 10:57:27 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA19872 for ietf-ipsra-bks; Sun, 27 Jun 1999 10:57:27 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.rdc1.sfba.home.com (imail@ha1.rdc1.sfba.home.com [24.0.0.66]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA19868 for ; Sun, 27 Jun 1999 10:57:24 -0700 (PDT) Received: from ix.netcom.com ([24.1.105.178]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990627180221.UUXV8807.mail.rdc1.sfba.home.com@ix.netcom.com>; Sun, 27 Jun 1999 11:02:21 -0700 Message-ID: <377666E6.8EDDA2F7@ix.netcom.com> Date: Sun, 27 Jun 1999 11:01:10 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com CC: "'Scott G. Kelly'" , "'Will Price'" , "'Stephane Beaulieu'" , "'Glen Zorn'" , "'ipsec'" , "'ipsra'" Subject: Re: Getting the features chart going References: <00ed01bebfa3$3dbfb160$2a8939cc@vaio> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Bernard, Bernard Aboba wrote: > > >The only meaningful drawback I've heard of > >so far pertains to the additional overhead required for the extra SA, > >and this is really more of an optimization issue than anything else. > > The creation and deletion of SAs that will result from this could limit > scalability, so I think that a decent case has been made for allowing > ISAKMP-cfg to assign IP addresses. However, that's *all* that I think > it should do. Everything else should be handled by DHCP INFORM. That's > the conclusion we came to in the PPP working group back in the early > 90s. I sort of see your point, but think it becomes a bit more muddled when you look at what is meant by "allowing ISAKMP-cfg to assign IP addresses". Does this mean the sgw also runs a dhcp server? Does it mean that we embed a dhcp (bootp) relay spoofer within the isakmp code? If scalability is an issue here, what do we consider to be the *practical* limits by which we judge this? > >It's not clear that isakmp-cfg is simple, and it's also not at all clear > >that the additional challenges it presents in terms of analyzability, > >reliability, etc. with respect to security are worth the overhead gains > >over the dhcp approach. > > There are security risks associated with assignment of IP addresses; > these threats are detailed in the authenticated DHCP draft. However, > those threats mostly have to do with unauthenticated clients making > large numbers of resource requests, or unauthenticated servers handing > out bogus parameters. In this particular case, ISAKMP-cfg is only > invoked *after* mutual authentication so that both sides know who > they are talking to. That doesn't mean that the initiator or > responder can't act badly, but it does imply that you'll know who > is doing it. This is about as much assurance as you get with > authenticated DHCP. I wasn't referring to the assignment of IP addresses. I was referring to the complexity of the sgw, the ike code, etc., and to the fact that as the complexity increases, the analyzability decreases rapidly. At the same time, the probability of the presence of an exploitable hole increases. I think that the most secure sgw is (probably) the simplest possible implementation, and that's what I was driving at. Scott From owner-ietf-ipsra Mon Jun 28 05:41:29 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id FAA21042 for ietf-ipsra-bks; Mon, 28 Jun 1999 05:41:29 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id FAA21038 for ; Mon, 28 Jun 1999 05:41:27 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id IAA00287 for ietf-ipsra@vpnc.org; Mon, 28 Jun 1999 08:46:27 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa00275; Mon Jun 28 08:46:19 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Mon, 28 Jun 1999 08:46:17 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Mon, 28 Jun 1999 08:48:35 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFB8F051@exchange> From: Stephane Beaulieu To: aboba@internaut.com Cc: "'Stephane Beaulieu'" , "'ipsec'" , "'ipsra'" Subject: RE: Getting the features chart going Date: Mon, 28 Jun 1999 08:48:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > Some questions about IKE-CFG: > > 1. Are all attributes mandatory? >From Section 2 of the draft: "If a badly formatted exchange is received, the message SHOULD be silently discarded and MAY be logged locally, as per local policy. Badly formatted exchanges MIGHT include those with unknown codes or unknown attributes." I think it's up to the implementation. You may wish to abort the transaction if you receive an attribute that you don't support, or you may wish to attempt to continue. > > 2. What if a vendor adds support for a new > non-standard attribute? > > How will this affect interoperability? > > Remember, the extension could be at the > initiator or responder. What should happen > when an initiator requests an attribute that > the responder can't handle, or vice versa? > Does this behavior enable vendor "bullying"? A non-standard attribute would be in the private range. I think that most implementations would simply ignore attributes from the private range that they don't understand. > > 3. Should only IANA-approved attributes be > allowed? What is the procedure for IANA > approval? > The draft is still evolving, any suggestions should be brought up to the editor. From owner-ietf-ipsra Mon Jun 28 06:21:43 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id GAA21083 for ietf-ipsra-bks; Mon, 28 Jun 1999 06:21:43 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206191146-18.ricochet.net [206.191.146.18]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA21079 for ; Mon, 28 Jun 1999 06:21:36 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.42]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id GAA01089; Mon, 28 Jun 1999 06:24:35 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Scott G. Kelly'" Cc: "'Scott G. Kelly'" , "'Will Price'" , "'Stephane Beaulieu'" , "'Glen Zorn'" , "'ipsec'" , "'ipsra'" , , , Subject: IKECFG and DHCP (was Getting the Feature Chart going) Date: Mon, 28 Jun 1999 06:40:29 -0700 Message-ID: <000101bec16b$ca2c12a0$2a8939cc@vaio> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <377666E6.8EDDA2F7@ix.netcom.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: You are asking many good questions about how it is proposed that IKECFG will interact with DHCP. There are a number of reasons that it is vital that IKECFG integrate well with DHCP. The IKECFG draft does not say much about this but as I will describe I think that there are a number of issues here to be explored. As a result, I am cc:'ing Ralph Droms (chair of DHCP WG) and Bill Arbaugh, co-author of the DHCP authentication draft. >Does this mean the IPSEC security gateway (sgw) also runs a dhcp server? No, I hope it dos not mean that. You probably want a sgw machine to only perform that function. >Does it mean that we embed a dhcp (bootp) relay spoofer within the isakmp code? I do think that the sgw will end up running as a DHCP relay. If the address is assigned by the pure DHCP method, then this will be the only involvement that the sgw will have in the DHCP process. If the address is assigned within IKECFG, the interaction becomes somewhat more complex as described below. If IKECFG *only* handles addressing, then I think that the sgw will serve as a relay for DHCP INFORM packets, used for configuration. Since the IKE negotiation will have completed by the time the INFORM is sent, I don't think that the IKE code will need to be involved in the INFORM per se. However, as noted below, the sgw role with respect to address assignment is somewhat more complicated, as described below. The way address assignment would work is presumably similar to the way NAS devices handle address allocation within PPP today. This is typically by one of two methods: allocating out of an assigned pool, or making a DHCP request on behalf of the user. In allocating out of an assigned pool, there is typically an assumption that the sgw "owns" the address space with an infinite lease and that users connected to it get to use the address for as long as the session/tunnel remains up. So you do not get into the issue of leases and renewal. However, this model can be complicated by the fact that often there is more than one address pool, so that there needs to be a selection of what pool the address is assigned from. Since some networks use the pool in order to differentiate beween users for things like QoS, it can be important to be able to get this right. The pool can be negotiated between the user and sgw or the sgw can select it based on information it gleans from the IKE phase 1 negotiation, such as the identity. One question is whether most current implementations offer enough information to make this decision or whether additional IKECFG attributes are needed. In DHCP this kind of issue is handled via the User-Class option. I think that such an option will be needed in IKECFG for reasons that follow. When making a DHCP request on behalf of the user, it is necessary for IKE to be able to receive the same kind of address that the user would have gotten for himself. This implies that the sgw must be able to impersonate the user if DHCP authentication is in force, or must be able to request a DHCP address with the proper User-Class option so that the user is assigned out of the right pool. Since User-Class cannot necessarily be ascertained from the user identity, I think that this will be needed in IKECFG. Impersonation of the user in DHCP authentication is an interesting issue. Right now the IKECFG proposal does not address this, which is a shortcoming. Networks concerned enough about security to deploy IPSEC are probably among those who will care about DHCP authentication. In order to be able to impersonate the user context for DHCP authentication, the sgw must be able to verify integrity/auth options returned by the server, as well as to sign these options on behalf of the user. This implies that the sgw must either proxy between the user and DHCP server in a full fledged DHCP conversation, *or* must have access to the appropriate secrets to act on the user's behalf. I'm copying Bill Arbaugh on this thread, since he is the author of DHCP authentication. Bill -- any idea how this would work? I wasn't referring to the assignment of IP addresses. I was referring to the complexity of the sgw, the ike code, etc., and to the fact that as the complexity increases, the analyzability decreases rapidly. At the same time, the probability of the presence of an exploitable hole increases. I think that the most secure sgw is (probably) the simplest possible implementation, and that's what I was driving at. Scott From owner-ietf-ipsra Mon Jun 28 22:56:40 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id WAA21846 for ietf-ipsra-bks; Mon, 28 Jun 1999 22:56:40 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206253200-47.ricochet.net [206.253.200.47]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id WAA21842 for ; Mon, 28 Jun 1999 22:56:33 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.42]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id WAA01836; Mon, 28 Jun 1999 22:59:42 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Stephane Beaulieu'" Cc: "'ipsec'" , "'ipsra'" Subject: RE: Getting the features chart going Date: Mon, 28 Jun 1999 23:15:11 -0700 Message-ID: <008201bec1f6$c0759700$2a8939cc@vaio> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFB8F051@exchange> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >I think it's up to the implementation. You may wish to abort the >transaction if you receive an attribute that you don't support, or you may >wish to attempt to continue. >A non-standard attribute would be in the private range. I think that most >implementations would simply ignore attributes from the private range that >they don't understand. Leaving the response to unknown attributes up to the implementation could cause interoperability problems. For example, how am I to know whether the attribute relates to security, in which case it will be mandatory, or whether it relates to configuration of a parameter, in which case it can be ignored if it is not understood? If it can be assumed that an implementation will ignore unknown attributes, then it makes sense to offer all the non-mandatory attributes that can be understood without having to know whether the other implementation can accept them. However, if some implementations abort the transaction then the two approaches will not interoperate when they support a common subset of options, even though they both conform to the spec. There are several possible solutions to this. One is to allow the initiator and responder to send capabilities attributes defining what they can do and whether they require that certain attributes be understood. The capabilities attribute would be a list of supported attributes with an indication of mandatory/optional. Another solution is to define all attributes in the spec as mandatory, and all private attributes as optional and define the ranges of values corresponding to mandatory and optional for new attributes. This should eliminate ambiguities. >The draft is still evolving, any suggestions should be brought up to the >editor. I'd suggest that the IANA considerations section deal with the mandatory/ optional issue. At the least, the spec for a new attribute should state whether the attribute is required or not. However, I'd prefer to see a clear prescription as to which attributes are optional (private?) and which will be mandatory (spec-defined?). From owner-ietf-ipsra Tue Jun 29 05:56:57 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id FAA23819 for ietf-ipsra-bks; Tue, 29 Jun 1999 05:56:57 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id FAA23815 for ; Tue, 29 Jun 1999 05:56:55 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id JAA03444 for ietf-ipsra@vpnc.org; Tue, 29 Jun 1999 09:01:57 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa03409; Tue Jun 29 09:01:53 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Tue, 29 Jun 1999 09:01:03 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 29 Jun 1999 09:03:54 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFBB82B0@exchange> From: Stephane Beaulieu To: aboba@internaut.com Cc: "'ipsec'" , "'ipsra'" Subject: RE: Getting the features chart going Date: Tue, 29 Jun 1999 09:03:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Bernard, > > Another solution is to define all attributes in the spec as mandatory, > and all private attributes as optional and define the ranges of values > corresponding to mandatory and optional for new attributes. > This should > eliminate ambiguities. This sounds good to me. Thanks for the input. Stephane. From owner-ietf-ipsra Tue Jun 29 11:30:03 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id LAA24372 for ietf-ipsra-bks; Tue, 29 Jun 1999 11:30:03 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA24368 for ; Tue, 29 Jun 1999 11:30:01 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRQJXH; Tue, 29 Jun 1999 11:35:49 -0700 Message-ID: <3779122F.9AB61E04@redcreek.com> Date: Tue, 29 Jun 1999 11:36:31 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com CC: "'Scott G. Kelly'" , "'Will Price'" , "'Stephane Beaulieu'" , "'Glen Zorn'" , "'ipsec'" , "'ipsra'" , wdixon@microsoft.com, waa@dsl.cis.upenn.edu, droms@bucknell.edu Subject: Re: IKECFG and DHCP (was Getting the Feature Chart going) References: <000101bec16b$ca2c12a0$2a8939cc@vaio> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Bernard, Bernard Aboba wrote: > > >Does this mean the IPSEC security gateway (sgw) also runs a dhcp server? > > No, I hope it dos not mean that. You probably want > a sgw machine to only perform that function. (preserving above for later reference below) > > >Does it mean that we embed a dhcp (bootp) relay spoofer within the isakmp > code? > > I do think that the sgw will end up running as a DHCP relay. If the address > is assigned by the pure DHCP method, then this will be the only involvement > that the sgw will have in the DHCP process. If the address is assigned > within > IKECFG, the interaction becomes somewhat more complex as described below. If > IKECFG *only* handles addressing, then I think that the sgw will serve as a > relay for DHCP INFORM packets, used for configuration. > Since the IKE negotiation will have completed by the > time the INFORM is sent, I don't think that the IKE code will need to be > involved in the INFORM per se. However, as noted below, the sgw role > with respect to address assignment is somewhat more complicated, as > described below. > > The way address assignment would work is presumably similar to the > way NAS devices handle address allocation within PPP today. This is > typically by one of two methods: allocating out of an assigned pool, > or making a DHCP request on behalf of the user. > > In allocating out of an assigned pool, there is typically an assumption that > the sgw "owns" the address space with an infinite lease and that users > connected > to it get to use the address for as long as the session/tunnel remains up. > So you do not get into the issue of leases and renewal. > > However, this model can be complicated by the fact that often there is more > than one address pool, so that there needs to be a selection of what pool > the address is assigned from. Since some networks use the pool in order > to differentiate beween users for things like QoS, it can be important > to be able to get this right. The pool can be negotiated between the user > and > sgw or the sgw can select it based on information it gleans from the IKE > phase 1 negotiation, such as the identity. One question is whether most > current implementations offer enough information to make this decision > or whether additional IKECFG attributes are needed. In DHCP this kind of > issue is handled via the User-Class option. I think that such an option > will be needed in IKECFG for reasons that follow. > > When making a DHCP request on behalf of the user, it is necessary for IKE > to be able to receive the same kind of address that the user would have > gotten for himself. This implies that the sgw must be able to impersonate > the user if DHCP authentication is in force, or must be able to request > a DHCP address with the proper User-Class option so that the user is > assigned > out of the right pool. Since User-Class cannot necessarily be ascertained > from the user identity, I think that this will be needed in IKECFG. > > Impersonation of the user in DHCP authentication is an interesting issue. > Right now the IKECFG proposal does not address this, which is a > shortcoming. Networks concerned enough about security to deploy IPSEC are > probably among those who will care about DHCP authentication. In order > to be able to impersonate the user context for DHCP authentication, the > sgw must be able to verify integrity/auth options returned by the server, > as well as to sign these options on behalf of the user. This implies that > the sgw must either proxy between the user and DHCP server in a full fledged > DHCP conversation, *or* must have access to the appropriate secrets to > act on the user's behalf. > What you describe above becomes increasingly complex as you proceed. This concerns me, and I think it contradicts the sentiment expressed above when you said > No, I hope it dos not mean that. You probably want > a sgw machine to only perform that function. In fact, this is what has concerned me most about isakmp-cfg and xauth all along: they add significant complexity to IKE. I think that added complexity most likely degrades security, and that we should strive for the simplest, most secure mechanism. I don't think this necessarily rules out isakmp-cfg in a definitive way, but I think it should make us very suspicious of its suitability for the specific task at hand. I think one of the things we need to nail down at this point regards scalability limitations. In an earlier email, you expressed concern that using individual dhcp SAs for remote clients would not scale well. I'm curious as to how many individual remote clients we're talking about, and how the work related to dhcp proxying as discussed above compares to the work related to setting up and tearing down the individual SAs. This would give us a good relative indicator regarding the scalability differences of the 2 approaches. I'm continuing to think about this, but if you (or anyone else) has already worked through some of this, I'd be interested in seeing the results. Scott From owner-ietf-ipsra Tue Jun 29 23:28:38 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id XAA24870 for ietf-ipsra-bks; Tue, 29 Jun 1999 23:28:38 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from monitor.internaut.com (mg-206253200-47.ricochet.net [206.253.200.47]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id XAA24866 for ; Tue, 29 Jun 1999 23:28:24 -0700 (PDT) Received: from vaio (vaiobean [204.57.137.42]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id XAA03043; Tue, 29 Jun 1999 23:31:41 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Scott G. Kelly'" Cc: "'Scott G. Kelly'" , "'Will Price'" , "'Stephane Beaulieu'" , "'Glen Zorn'" , "'ipsec'" , "'ipsra'" , , , Subject: RE: IKECFG and DHCP (was Getting the Feature Chart going) Date: Tue, 29 Jun 1999 23:46:38 -0700 Message-ID: <012b01bec2c4$4e793f20$2a8939cc@vaio> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3779122F.9AB61E04@redcreek.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >What you describe above becomes increasingly complex as you proceed. >This concerns me... Handling address pool assignment and providing authenticated DHCP definitely does add some new wrinkles. After I sent the message I realized that there were probably a few other things that would be needed that hadn't been listed. For example, if you are managing address pools on the sgw, then you probably need a MIB or other address allocation management mechanism so that you can keep track of how many addresses have been allocated out of the pool and be notified when the address pool is running out. It is also worth noting that the DHCP WG is working on a failover protocol so that if you wanted to achieve equivalent resilience in this case you'd also need to think about how to provide failover functionality for address allocation on the sgw. There are also may be some new wrinkles that arise in dealing with mobile IP. A mobile node connecting via tunnel mode has already presumably obtained a care-of-address and wants to use its home address inside the tunnel. Therefore it does *not* want the sgw to assign an IP address. It also needs IKE to be able to handle packets on that SPI coming from another care-of-address if it moves, all without having to renegotiate the SA. So the client would need either not to request an IP address at all and just use the Home Address, or be able to decline an offer of an address in a way that clearly indicates mobility preference. >I'm curious as to how many individual remote clients we're talking about, >and how the work related to dhcp proxying as discussed above compares to >the work related to setting up and tearing down the individual SAs. This is definitely worth exploring. It's worth noting that the DHCP SA setup and teardown would presumably occur in phase 2 and be able to leverage the phase 1 negotiation. So it's not entirely clear to me that these operations are very heavy weight since there should be no D-H exchange involved. I'm curious as to what others think about this. It's also worth noting that the DHCP operations described above, while potentially complex, probably don't consume many cycles since other than the authenticated DHCP option signing (based on HMAC-MD5) there really are no cryptographic operations involved. From owner-ietf-ipsra Wed Jun 30 07:05:01 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id HAA26937 for ietf-ipsra-bks; Wed, 30 Jun 1999 07:05:01 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id HAA26933 for ; Wed, 30 Jun 1999 07:04:57 -0700 (PDT) Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.3) with ESMTP id QAA17139 for ; Wed, 30 Jun 1999 16:10:01 +0200 (MET DST) Received: from lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA06185; Wed, 30 Jun 1999 17:09:28 +0300 (EET DST) Message-ID: <377A2519.D3A728A6@lmf.ericsson.se> Date: Wed, 30 Jun 1999 17:09:29 +0300 From: Ari Huttunen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-ipsra@vpnc.org Subject: Re: Authentication for remote access clients References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: vgupta@Eng.Sun.COM wrote: > > Main mode + pre-shared keys doesn't work for the > remote access situation if the remote user could be using > a dynamically allocated IP address. This is described in more > detail in Section 3 of > > http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt > > vipul I don't see why NAS couldn't use the dynamically allocated IP address to determine the policy for the user. I think that in most cases it is the NAS that gives the user the IP address in the first place! You'll just have to set up a one-to-one relation between "one pool of IP addresses" and "one ISAKMP policy". Of course this fails if someone else assigns it. Perhaps we would need a "user class id" that would be transfered in the first ISAKMP message? It would say something like "the initiator belongs to the class of Company employees". This gives no more information to No Such Agency than is otherwise available. (If the connection succeeds to the company with a particular type of security, it provides the same information.) This probably can't be done without changing the RFC's, though?? Anyway, aggressive mode is not the answer. I'd rate it more as a problem. It provides no identity protection, and according to Simpson's draft, it is also much worse with the denial-of-service attack type. (This is probably not the right place, but can someone point out a good situation where one would definitely want to use aggressive mode?) Ari From owner-ietf-ipsra Wed Jun 30 13:33:48 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id NAA27425 for ietf-ipsra-bks; Wed, 30 Jun 1999 13:33:48 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA27421 for ; Wed, 30 Jun 1999 13:33:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16218; Wed, 30 Jun 1999 13:38:49 -0700 (PDT) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.95.37]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id NAA24934; Wed, 30 Jun 1999 13:38:48 -0700 (PDT) Received: from nobel by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA25368; Wed, 30 Jun 1999 13:38:46 -0700 Date: Wed, 30 Jun 1999 13:29:42 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Authentication for remote access clients To: Ari.Huttunen@lmf.ericsson.se Cc: ietf-ipsra@vpnc.org, Vipul.Gupta@Eng.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pjPnlhyYEGMoPexWdlWfrg== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > Date: Wed, 30 Jun 1999 17:09:29 +0300 > From: Ari Huttunen > > vgupta@Eng.Sun.COM wrote: > > > > > Main mode + pre-shared keys doesn't work for the > > remote access situation if the remote user could be using > > a dynamically allocated IP address. This is described in more > > detail in Section 3 of > > > > http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt > > > > vipul > > I don't see why NAS couldn't use the dynamically allocated IP address > to determine the policy for the user. I think that in most cases it is > the NAS that gives the user the IP address in the first place! You'll > just have to set up a one-to-one relation between "one pool of IP > addresses" > and "one ISAKMP policy". Of course this fails if someone else assigns > it. We seem to be talking about different scenarios. I was addressing the following scenario. User ---- ISP ---- Internet ---- IPSec ---- Corporate gateway Intranet <---------------------------> IPSec tunnel In this scenario, the user connects to the Internet via an IP address allocated dynamically by the ISP. The IPSec gateway protecting the corporate Intranet has no prior knowledge of what this address might be. The address allocation entity in this case is different from the Phase I responder. [More below on aggressive mode] > Perhaps we would need a "user class id" that would be transfered > in the first ISAKMP message? It would say something like "the initiator > belongs to the class of Company employees". This gives no more > information > to No Such Agency than is otherwise available. (If the connection > succeeds > to the company with a particular type of security, it provides the same > information.) This probably can't be done without changing the RFC's, > though?? > > Anyway, aggressive mode is not the answer. I'd rate it more as a > problem. > It provides no identity protection, and according to Simpson's draft, > it is also much worse with the denial-of-service attack type. > (This is probably not the right place, but can someone point out a good > situation > where one would definitely want to use aggressive mode?) > Ari It is true that aggressive mode does not offer identity protection when used with pre-shared keys (it does when using RSA encryption but the original poster was asking about pre-shared key authentictaion). Unfortunately, there's no way to use Main mode with pre-shared keys when the peer is using a dynamically assigned IP address. This restriction is mentioned in RFC 2409 (Section 5.4, last paragraph) and explained further in (Section 3). If you do not wish to use Aggressive mode in this situation, you can use signature based authentication with Main mode. I hope this answers your question. regards, vipul From owner-ietf-ipsra Wed Jun 30 14:16:44 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id OAA27529 for ietf-ipsra-bks; Wed, 30 Jun 1999 14:16:44 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA27525 for ; Wed, 30 Jun 1999 14:16:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01326; Wed, 30 Jun 1999 14:21:52 -0700 (PDT) Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.53.47]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id OAA16846; Wed, 30 Jun 1999 14:21:52 -0700 (PDT) Received: from nobel by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09185; Wed, 30 Jun 1999 14:21:49 -0700 Date: Wed, 30 Jun 1999 14:12:47 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: (Repost) Re: Authentication for remote access clients To: Ari.Huttunen@lmf.ericsson.se, ietf-ipsra@vpnc.org Cc: Vipul.Gupta@Eng.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gyPUrd1770KtK+bN2BYh0g== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: ------------- Begin Forwarded Message ------------- Date: Wed, 30 Jun 1999 13:29:42 -0700 (PDT) From: Vipul Gupta Subject: Re: Authentication for remote access clients To: Ari.Huttunen@lmf.ericsson.se Cc: ietf-ipsra@vpnc.org, vgupta@hsmpka MIME-Version: 1.0 Content-MD5: pjPnlhyYEGMoPexWdlWfrg== > Date: Wed, 30 Jun 1999 17:09:29 +0300 > From: Ari Huttunen > > vgupta@Eng.Sun.COM wrote: > > > > > Main mode + pre-shared keys doesn't work for the > > remote access situation if the remote user could be using > > a dynamically allocated IP address. This is described in more > > detail in Section 3 of > > > > http://www.ietf.org/internet-drafts/draft-gupta-ipsec-remote-access-02.txt > > > > vipul > > I don't see why NAS couldn't use the dynamically allocated IP address > to determine the policy for the user. I think that in most cases it is > the NAS that gives the user the IP address in the first place! You'll > just have to set up a one-to-one relation between "one pool of IP > addresses" > and "one ISAKMP policy". Of course this fails if someone else assigns > it. We seem to be talking about different scenarios. I was addressing the following scenario. User ---- ISP ---- Internet ---- IPSec ---- Corporate gateway Intranet <---------------------------> IPSec tunnel In this scenario, the user connects to the Internet via an IP address allocated dynamically by the ISP. The IPSec gateway protecting the corporate Intranet has no prior knowledge of what this address might be. The address allocation entity in this case is different from the Phase I responder. [More below on aggressive mode] > Perhaps we would need a "user class id" that would be transfered > in the first ISAKMP message? It would say something like "the initiator > belongs to the class of Company employees". This gives no more > information > to No Such Agency than is otherwise available. (If the connection > succeeds > to the company with a particular type of security, it provides the same > information.) This probably can't be done without changing the RFC's, > though?? > > Anyway, aggressive mode is not the answer. I'd rate it more as a > problem. > It provides no identity protection, and according to Simpson's draft, > it is also much worse with the denial-of-service attack type. > (This is probably not the right place, but can someone point out a good > situation > where one would definitely want to use aggressive mode?) > Ari It is true that aggressive mode does not offer identity protection when used with pre-shared keys (it does when using RSA encryption but the original poster was asking about pre-shared key authentictaion). Unfortunately, there's no way to use Main mode with pre-shared keys when the peer is using a dynamically assigned IP address. This restriction is mentioned in RFC 2409 (Section 5.4, last paragraph) and explained further in (Section 3). If you do not wish to use Aggressive mode in this situation, you can use signature based authentication with Main mode. I hope this answers your question. regards, vipul ------------- End Forwarded Message ------------- From owner-ietf-ipsra Tue Jul 6 04:12:39 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id EAA06115 for ietf-ipsra-bks; Tue, 6 Jul 1999 04:12:39 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.inter.net.il [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id EAA06111 for ; Tue, 6 Jul 1999 04:12:36 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id OAA12650; Tue, 6 Jul 1999 14:12:53 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA05999; Tue, 6 Jul 99 14:13:04 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma005996; Tue, 6 Jul 99 14:13:00 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id OAA07794; Tue, 6 Jul 1999 14:13:52 +0200 Message-Id: <3781E59B.406D682E@radguard.com> Date: Tue, 06 Jul 1999 14:16:43 +0300 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: ipsec@lists.tislabs.com, ipsra Subject: New draft submitted- IKE Base Mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings, A new draft on IKE Base Mode is available at http://www.radguard.com/drafts/draft-ietf-ipsec-ike-base-mode-00.txt , and has been submitted to the internet-drafts registry. The draft follows a presentation made in the last meeting, and has taken into account comments that followed. This might help in solving some of the problems raised on the ipsra list lately. Comments requested. Yael and Sara From owner-ietf-ipsra Tue Jul 13 19:06:50 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id TAA19555 for ietf-ipsra-bks; Tue, 13 Jul 1999 19:06:50 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id TAA19551 for ; Tue, 13 Jul 1999 19:06:48 -0700 (PDT) Received: from tenpoint ([24.112.230.124]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with SMTP id <19990714020757.EXNW7973.mail.rdc2.on.home.com@tenpoint> for ; Tue, 13 Jul 1999 19:07:57 -0700 Message-Id: <4.1.19990713220622.009fe3e0@pop6.ibm.net> X-Sender: cainet.moussea@pop6.ibm.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 13 Jul 1999 22:07:15 -0400 To: ietf-ipsra@vpnc.org From: Jeff Mousseau Subject: Subscription Information Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry to nail everyone with this but can someone pls tell me the address to subscribe to this list? From owner-ietf-ipsra Tue Jul 20 11:54:07 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA10359 for ietf-ipsra-bks; Tue, 20 Jul 1999 11:54:07 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA10355 for ; Tue, 20 Jul 1999 11:54:06 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRQ56S; Tue, 20 Jul 1999 11:56:26 -0700 Message-ID: <3794C636.82B100C8@redcreek.com> Date: Tue, 20 Jul 1999 11:55:50 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tamir Zegman CC: Dennis Glatting , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <378D9F5B.C3FA1495@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Tamir Zegman wrote: > > Dennis Glatting wrote: > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > be the IPsec authentication mechanism of choice until products mature > > and prices decline. The difference between simple shared secrets and > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > manage, managed shared secret technologies yielding, in my opinion, no > > motivation to improve the security of infrastructures (i.e., > > transition to PKI). Is this where we want to be after several years of > > work and some cantankerous meetings? > > > > There is another side for this coin. > We have many customers that are deferring their migration to IPSec because > they feel they are not ready to deploy a full scale PKI. > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > of PKI. > Sometimes it's easier to jump over two small hurdles rather than over a > big one. I agree with Tamir on this point, but think that if we are indeed viewing this (xauth, hybrid) as an intermediate step, then we should make this exceedingly clear, and the transition path should be clearly stated ("clearly" being a relative term at this point in the game). > > > > I offer the following suggestions. First, finish a combined > > xauth/hybrid draft and classify it as experimental. Second, the > > Security Considerations section of the draft be written not by the > > draft's proponents but by at least two of its detractors. Finally, set > > a deadline (perhaps three years) where the PS is committed to > > historic. > > I'll accept your offer with regard to the Security Consideration section. > Any volunteers? > I do not believe that the experimental is the right track for this. I'd be willing to contribute to the security considerations text. I'm not sure if the experimental track is right or not, though I do think that somehow limiting the lifetime of password-based approaches has a certain appeal. We must grease the skids for PKI deployment, and not simply provide an excuse for maintaining the status quo, but this is a complex issue. That is why I think we need a working group to iron it out. Scott From owner-ietf-ipsra Wed Jul 21 10:07:57 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA21099 for ietf-ipsra-bks; Wed, 21 Jul 1999 10:07:57 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA21095 for ; Wed, 21 Jul 1999 10:07:53 -0700 (PDT) Received: from checkpoint.com (kaveret.checkpoint.com [199.203.71.97]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id UAA11729; Wed, 21 Jul 1999 20:14:18 +0300 (IDT) Message-ID: <3795FF73.9FC060FF@checkpoint.com> Date: Wed, 21 Jul 1999 20:12:19 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <378D9F5B.C3FA1495@checkpoint.com> <3794C636.82B100C8@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: "Scott G. Kelly" wrote: > Tamir Zegman wrote: > > > > Dennis Glatting wrote: > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > be the IPsec authentication mechanism of choice until products mature > > > and prices decline. The difference between simple shared secrets and > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > manage, managed shared secret technologies yielding, in my opinion, no > > > motivation to improve the security of infrastructures (i.e., > > > transition to PKI). Is this where we want to be after several years of > > > work and some cantankerous meetings? > > > > > > > There is another side for this coin. > > We have many customers that are deferring their migration to IPSec because > > they feel they are not ready to deploy a full scale PKI. > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > of PKI. > > Sometimes it's easier to jump over two small hurdles rather than over a > > big one. > > I agree with Tamir on this point, but think that if we are indeed > viewing this (xauth, hybrid) as an intermediate step, then we should > make this exceedingly clear, and the transition path should be clearly > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > I offer the following suggestions. First, finish a combined > > > xauth/hybrid draft and classify it as experimental. Second, the > > > Security Considerations section of the draft be written not by the > > > draft's proponents but by at least two of its detractors. Finally, set > > > a deadline (perhaps three years) where the PS is committed to > > > historic. > > > > I'll accept your offer with regard to the Security Consideration section. > > Any volunteers? > > I do not believe that the experimental is the right track for this. > > I'd be willing to contribute to the security considerations text. > > I'm not sure if the experimental track is right or not, though I do > think that somehow limiting the lifetime of password-based approaches > has a certain appeal. We must grease the skids for PKI deployment, and > not simply provide an excuse for maintaining the status quo, but this is > a complex issue. That is why I think we need a working group to iron it > out. > > Scott Hi Scott, I think that there is a consensus that static passwords are BAD. XAUTH/Hybrid are not there to support static passwords but to support stronger authentication schemes. In some cases PKI with "soft" tokens are even less secure than legacy authentication schemes such as SecurID tokens. In the absence of PKI, IKE users will fall back to use pre-shared keys. Do we want that? In some aspects IKE pre-shared secrets are even less secure than XAUTH/Hybrid with fixed passwords since they are susceptible to off-line dictionary attacks. Why not ban pre-shared secrets? Tamir. From owner-ietf-ipsra Wed Jul 21 11:29:52 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id LAA21224 for ietf-ipsra-bks; Wed, 21 Jul 1999 11:29:52 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from btw.plaintalk.bellevue.wa.us (btw.aa.net [206.125.75.16]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA21220 for ; Wed, 21 Jul 1999 11:29:49 -0700 (PDT) Received: from localhost (dennisg@localhost) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id LAA87633; Wed, 21 Jul 1999 11:30:13 -0700 (PDT) Date: Wed, 21 Jul 1999 11:30:13 -0700 (PDT) From: Dennis Glatting To: Tamir Zegman cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid In-Reply-To: <3795FF73.9FC060FF@checkpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 21 Jul 1999, Tamir Zegman wrote: > > > > "Scott G. Kelly" wrote: > > > Tamir Zegman wrote: > > > > > > Dennis Glatting wrote: > > > > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > > be the IPsec authentication mechanism of choice until products mature > > > > and prices decline. The difference between simple shared secrets and > > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > > manage, managed shared secret technologies yielding, in my opinion, no > > > > motivation to improve the security of infrastructures (i.e., > > > > transition to PKI). Is this where we want to be after several years of > > > > work and some cantankerous meetings? > > > > > > > > > > There is another side for this coin. > > > We have many customers that are deferring their migration to IPSec because > > > they feel they are not ready to deploy a full scale PKI. > > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > > of PKI. > > > Sometimes it's easier to jump over two small hurdles rather than over a > > > big one. > > > > I agree with Tamir on this point, but think that if we are indeed > > viewing this (xauth, hybrid) as an intermediate step, then we should > > make this exceedingly clear, and the transition path should be clearly > > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > > > > > > I offer the following suggestions. First, finish a combined > > > > xauth/hybrid draft and classify it as experimental. Second, the > > > > Security Considerations section of the draft be written not by the > > > > draft's proponents but by at least two of its detractors. Finally, set > > > > a deadline (perhaps three years) where the PS is committed to > > > > historic. > > > > > > I'll accept your offer with regard to the Security Consideration section. > > > Any volunteers? > > > I do not believe that the experimental is the right track for this. > > > > I'd be willing to contribute to the security considerations text. > > > > I'm not sure if the experimental track is right or not, though I do > > think that somehow limiting the lifetime of password-based approaches > > has a certain appeal. We must grease the skids for PKI deployment, and > > not simply provide an excuse for maintaining the status quo, but this is > > a complex issue. That is why I think we need a working group to iron it > > out. > > > > Scott > > Hi Scott, > > I think that there is a consensus that static passwords are BAD. > XAUTH/Hybrid are not there to support static passwords but to > support stronger authentication schemes. In some cases PKI with > "soft" tokens are even less secure than legacy authentication > schemes such as SecurID tokens. In the absence of PKI, IKE users > will fall back to use pre-shared keys. Do we want that? In some > aspects IKE pre-shared secrets are even less secure than > XAUTH/Hybrid with fixed passwords since they are susceptible to > off-line dictionary attacks. Why not ban pre-shared secrets? > One of the key differences is XAUTH/hybrid provides no incentive to move to PKI whereas pre-shared secrets by virtue of being unmanageable does. However, just to throw a little personal experience for perspective in favor of shared secrets, whether XAUTH/hybrid provided or pre-shared secrets, I offer the following story. One of my clients has an IKE capable firewall. I decided to purchase the vendor's certificate based solution because I believe a certificate based solution offers better security, it inexpensively introduces my client to certificate based thinking, and it was a slam-dunk -- I didn't have to think about it. :) I purchased the recently released software in May of 1999 and discovered, after five weeks, I had to downgrade my NT server to a non-y2k patch level and the software itself wasn't y2k. I returned the software and went the pre-shared secret route. Even with PKI there is still a password problem: the user's password used to encrypt their private key. People do stupid things including choosing stupid passwords. Many users still write their passwords on pieces of paper and attach them to their terminals, or write them down on mouse pads, or write them down on a sheet just inside their top desk drawer, sometimes labeled "password." In one case a women could not remember her ID and password to save her life. Eventually I changed her password to her husband's name without any character substitutions. She could not remember that one, too. So, whether you are using certificates, smart cards, or anything else that is password related, the question is: what's the difference between having xauth/hybrid and not having it? Strictly looking at passwords, a central service can impose good password selection mechanisms as can client software; However, a central service is in a better position to perform an off-line dictionary attack to assure good choice. When I think about the problems xauth/hybrid address I think of Bart Simpson's immortal words (stolen from somewhere else, I bet) "you're damned if you do and you're damned if you don't." I believe XAUTH/hybrid offers something valuable but should not be encouraged. -dpg From owner-ietf-ipsra Wed Jul 21 11:55:04 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA21295 for ietf-ipsra-bks; Wed, 21 Jul 1999 11:55:04 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id LAA21291 for ; Wed, 21 Jul 1999 11:55:02 -0700 (PDT) Received: id OAA26227; Wed, 21 Jul 1999 14:52:39 -0400 Received: by gateway id ; Wed, 21 Jul 1999 14:55:17 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8DB@sothmxs06.entrust.com> From: Greg Carter To: "'Tamir Zegman'" , "Scott G. Kelly" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Wed, 21 Jul 1999 14:55:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, How are PKI 'soft' tokens (by that I guess you mean private keys stored on disk, password protected) less secure? How is a one way proprietary authentication scheme more secure than mutual authentication? with shared secrets or PKI? Its been awhile since I looked at the internals of the ACE server but I believe it too uses DES shared secrets between the server and the NAS, Most of the other DES based token cards rely on RADIUS to act as their authentication server, so now we are down to MD5 hiding. One way authentication is pointless, IMHO. Oh, what about soft tokens, most of the DES based challenge/response token vendors offer software based tokens, I believe SecurID does as well. So how does your SGW know if the user is using a true hardware token or a soft token, it doesn't. A soft token will be susceptible to the same attacks as your shared key file, yet offers only one way authentication. Bye. -----Original Message----- From: Tamir Zegman [mailto:zegman@checkpoint.com] Sent: Wednesday, July 21, 1999 1:12 PM To: Scott G. Kelly Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid I think that there is a consensus that static passwords are BAD. XAUTH/Hybrid are not there to support static passwords but to support stronger authentication schemes. In some cases PKI with "soft" tokens are even less secure than legacy authentication schemes such as SecurID tokens. In the absence of PKI, IKE users will fall back to use pre-shared keys. Do we want that? In some aspects IKE pre-shared secrets are even less secure than XAUTH/Hybrid with fixed passwords since they are susceptible to off-line dictionary attacks. Why not ban pre-shared secrets? Tamir. From owner-ietf-ipsra Wed Jul 21 13:10:29 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id NAA21489 for ietf-ipsra-bks; Wed, 21 Jul 1999 13:10:29 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from fulcrum (fulcrum.ie.cw.net [204.70.128.22]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA21485 for ; Wed, 21 Jul 1999 13:10:27 -0700 (PDT) Received: from cletus.ie.cw.net ([204.71.41.1]) by cw.net (PMDF V5.2-31 #35957) with ESMTP id <0FF800E6ELFIGM@cw.net> for ietf-ipsra@vpnc.org; Wed, 21 Jul 1999 16:11:42 -0400 (EDT) Received: (from yjj@localhost) by cletus.ie.cw.net (8.8.8+Sun/8.8.8) id QAA02461; Wed, 21 Jul 1999 16:11:35 -0400 (EDT) Date: Wed, 21 Jul 1999 16:11:35 -0400 (EDT) From: "Y. John Jiang" Subject: Re: Comment on xauth and hybrid In-reply-to: To: Dennis Glatting Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Certificate authentication is prone to key board monitoring attack. If one leaves the hard token in the PCMCIA slot, it is as weak as a soft token. Y. John Jiang, Internet Engineer, Internet Security, Cable and Wireless 703-715-7480, 2100 Reston Parkway, Reston, VA 20191 On Wed, 21 Jul 1999, Dennis Glatting wrote: > > > On Wed, 21 Jul 1999, Tamir Zegman wrote: > > > > > > > > > "Scott G. Kelly" wrote: > > > > > Tamir Zegman wrote: > > > > > > > > Dennis Glatting wrote: > > > > > > > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > > > be the IPsec authentication mechanism of choice until products mature > > > > > and prices decline. The difference between simple shared secrets and > > > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > > > manage, managed shared secret technologies yielding, in my opinion, no > > > > > motivation to improve the security of infrastructures (i.e., > > > > > transition to PKI). Is this where we want to be after several years of > > > > > work and some cantankerous meetings? > > > > > > > > > > > > > There is another side for this coin. > > > > We have many customers that are deferring their migration to IPSec because > > > > they feel they are not ready to deploy a full scale PKI. > > > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > > > of PKI. > > > > Sometimes it's easier to jump over two small hurdles rather than over a > > > > big one. > > > > > > I agree with Tamir on this point, but think that if we are indeed > > > viewing this (xauth, hybrid) as an intermediate step, then we should > > > make this exceedingly clear, and the transition path should be clearly > > > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > > > > > > > > > > > I offer the following suggestions. First, finish a combined > > > > > xauth/hybrid draft and classify it as experimental. Second, the > > > > > Security Considerations section of the draft be written not by the > > > > > draft's proponents but by at least two of its detractors. Finally, set > > > > > a deadline (perhaps three years) where the PS is committed to > > > > > historic. > > > > > > > > I'll accept your offer with regard to the Security Consideration section. > > > > Any volunteers? > > > > I do not believe that the experimental is the right track for this. > > > > > > I'd be willing to contribute to the security considerations text. > > > > > > I'm not sure if the experimental track is right or not, though I do > > > think that somehow limiting the lifetime of password-based approaches > > > has a certain appeal. We must grease the skids for PKI deployment, and > > > not simply provide an excuse for maintaining the status quo, but this is > > > a complex issue. That is why I think we need a working group to iron it > > > out. > > > > > > Scott > > > > Hi Scott, > > > > I think that there is a consensus that static passwords are BAD. > > XAUTH/Hybrid are not there to support static passwords but to > > support stronger authentication schemes. In some cases PKI with > > "soft" tokens are even less secure than legacy authentication > > schemes such as SecurID tokens. In the absence of PKI, IKE users > > will fall back to use pre-shared keys. Do we want that? In some > > aspects IKE pre-shared secrets are even less secure than > > XAUTH/Hybrid with fixed passwords since they are susceptible to > > off-line dictionary attacks. Why not ban pre-shared secrets? > > > > One of the key differences is XAUTH/hybrid provides no incentive to > move to PKI whereas pre-shared secrets by virtue of being unmanageable > does. However, just to throw a little personal experience for > perspective in favor of shared secrets, whether XAUTH/hybrid provided > or pre-shared secrets, I offer the following story. > > One of my clients has an IKE capable firewall. I decided to purchase > the vendor's certificate based solution because I believe a > certificate based solution offers better security, it inexpensively > introduces my client to certificate based thinking, and it was a > slam-dunk -- I didn't have to think about it. :) I purchased the > recently released software in May of 1999 and discovered, after five > weeks, I had to downgrade my NT server to a non-y2k patch level and > the software itself wasn't y2k. I returned the software and went the > pre-shared secret route. > > Even with PKI there is still a password problem: the user's password > used to encrypt their private key. People do stupid things including > choosing stupid passwords. Many users still write their passwords on > pieces of paper and attach them to their terminals, or write them down > on mouse pads, or write them down on a sheet just inside their top > desk drawer, sometimes labeled "password." In one case a women could > not remember her ID and password to save her life. Eventually I > changed her password to her husband's name without any character > substitutions. She could not remember that one, too. So, whether you > are using certificates, smart cards, or anything else that is password > related, the question is: what's the difference between having > xauth/hybrid and not having it? Strictly looking at passwords, a > central service can impose good password selection mechanisms as can > client software; However, a central service is in a better position to > perform an off-line dictionary attack to assure good choice. > > > When I think about the problems xauth/hybrid address I think of Bart > Simpson's immortal words (stolen from somewhere else, I bet) "you're > damned if you do and you're damned if you don't." I believe > XAUTH/hybrid offers something valuable but should not be encouraged. > > > -dpg > > > > From owner-ietf-ipsra Wed Jul 21 13:24:34 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id NAA21552 for ietf-ipsra-bks; Wed, 21 Jul 1999 13:24:34 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA21548 for ; Wed, 21 Jul 1999 13:24:32 -0700 (PDT) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA21570; Wed, 21 Jul 1999 16:26:11 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 21 Jul 1999 16:22:47 -0400 To: "Y. John Jiang" From: Stephen Kent Subject: Re: Comment on xauth and hybrid Cc: Dennis Glatting , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: At 4:11 PM -0400 7/21/99, Y. John Jiang wrote: >Certificate authentication is prone to key board monitoring attack. >If one leaves the hard token in the PCMCIA slot, it is as weak as >a soft token. No well-engineered hardware device should be capable of having it's private key(s) extracted via a software attack effected through a PC to which it is connected. Depending on the engineering of the device one might carry out various forms of close-in attacks, if the device is enabled and physically available to an attacker. Certainly one could initiate new SAs that the user might not really want to authorize (but that's a problem in any case). What eacctly did you have in mind when you made the above statement/ Steve From owner-ietf-ipsra Wed Jul 21 16:09:57 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id QAA22036 for ietf-ipsra-bks; Wed, 21 Jul 1999 16:09:57 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from fulcrum (fulcrum.ie.cw.net [204.70.128.22]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id QAA22032 for ; Wed, 21 Jul 1999 16:09:55 -0700 (PDT) Received: from cletus.ie.cw.net ([204.71.41.1]) by cw.net (PMDF V5.2-31 #35957) with ESMTP id <0FF800FGSTQW3Q@cw.net> for ietf-ipsra@vpnc.org; Wed, 21 Jul 1999 19:11:20 -0400 (EDT) Received: (from yjj@localhost) by cletus.ie.cw.net (8.8.8+Sun/8.8.8) id TAA02712; Wed, 21 Jul 1999 19:11:19 -0400 (EDT) Date: Wed, 21 Jul 1999 19:11:19 -0400 (EDT) From: "Y. John Jiang" Subject: Re: Comment on xauth and hybrid In-reply-to: To: Stephen Kent Cc: Dennis Glatting , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Steve, I did not mean the hacker needed to extract the key. The scenario is like this: 1. A trojan is installed on a user's PC (btw, this has become very popular). 2. The pass phrase is captured by monitoring the user's keystrokes. 3. The hacker logs into the PC and then logs into the user's bank account which requires certificate authentication. True, a well-engineered hardware device does not allow the capture of the pass phrase. Adding a small keyboard on the hard token would help. However, the popular hard tokens on the market all rely on the PC keyboard for pass phrase input. John On Wed, 21 Jul 1999, Stephen Kent wrote: > At 4:11 PM -0400 7/21/99, Y. John Jiang wrote: > > >Certificate authentication is prone to key board monitoring attack. > >If one leaves the hard token in the PCMCIA slot, it is as weak as > >a soft token. > > No well-engineered hardware device should be capable of having it's private > key(s) extracted via a software attack effected through a PC to which it is > connected. Depending on the engineering of the device one might carry out > various forms of close-in attacks, if the device is enabled and physically > available to an attacker. Certainly one could initiate new SAs that the > user might not really want to authorize (but that's a problem in any case). > What eacctly did you have in mind when you made the above statement/ > > Steve > From owner-ietf-ipsra Thu Jul 22 04:07:25 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id EAA23637 for ietf-ipsra-bks; Thu, 22 Jul 1999 04:07:25 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id EAA23633 for ; Thu, 22 Jul 1999 04:07:23 -0700 (PDT) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id HAA13686; Thu, 22 Jul 1999 07:10:58 -0400 (EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma013678; Thu, 22 Jul 99 07:10:13 -0400 Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id HAA00379; Thu, 22 Jul 1999 07:13:56 -0400 (EDT) Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L8AF65>; Thu, 22 Jul 1999 12:07:57 +0100 Message-ID: <29752A74B6C5D211A4920090273CA3DCA86824@new-exc1.ctron.com> From: "Waters, Stephen" To: Dennis Glatting Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 12:07:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Fair comment Dennis - passwords are a mess, wherever they are used. A shame really - a well chosen, well kept password does provide a hard nut to crack off-line, but the users can't be trusted to keep them safe. So what are we left with? If the end-user can't remember a simple pin number for a Token card/Smartcard without writing it down, what is left? That sort of blows all legacy mechanisms. Maybe if we write down the ideal requirements, something will pop-up (humm): 1) no passwords needed, since passwords get written down! 2) client authentication that can not be cracked off-line 3) a single, strong authentication mechanism that can be used without the need of XAUTH Without passwords/pin-numbers, we need some other way of validating that the user of the authentication information is the owner - like have a photo on a driving license. For VPNs, the best hope at the moment seems to be biometric cards. There have been some doubts expressed about the physical security of these cards on this list, so they need to be fixed somehow. The boimetric reader needs to be tightly coupled with the private-key access logic such that if any tampering occurs, the private key is history. In the meantime, it looks like we can't get away from some form of password/pin number. And if that is the case, I intend to use XAUTH to prevent off-line cracking. If the password is given-up easily (written down, or spoken loudly), then all bets are off. If it is treated with reverence, then XAUTH helps. Steve. -----Original Message----- From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] Sent: Wednesday, July 21, 1999 7:30 PM To: Tamir Zegman Cc: Scott G. Kelly; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid On Wed, 21 Jul 1999, Tamir Zegman wrote: > > > > "Scott G. Kelly" wrote: > > > Tamir Zegman wrote: > > > > > > Dennis Glatting wrote: > > > > > > > > > The PKI reality is there isn't one, so shared secrets, I expect, will > > > > be the IPsec authentication mechanism of choice until products mature > > > > and prices decline. The difference between simple shared secrets and > > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to > > > > manage, managed shared secret technologies yielding, in my opinion, no > > > > motivation to improve the security of infrastructures (i.e., > > > > transition to PKI). Is this where we want to be after several years of > > > > work and some cantankerous meetings? > > > > > > > > > > There is another side for this coin. > > > We have many customers that are deferring their migration to IPSec because > > > they feel they are not ready to deploy a full scale PKI. > > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment > > > of PKI. > > > Sometimes it's easier to jump over two small hurdles rather than over a > > > big one. > > > > I agree with Tamir on this point, but think that if we are indeed > > viewing this (xauth, hybrid) as an intermediate step, then we should > > make this exceedingly clear, and the transition path should be clearly > > stated ("clearly" being a relative term at this point in the game). > > > > > > > > > > > > > > I offer the following suggestions. First, finish a combined > > > > xauth/hybrid draft and classify it as experimental. Second, the > > > > Security Considerations section of the draft be written not by the > > > > draft's proponents but by at least two of its detractors. Finally, set > > > > a deadline (perhaps three years) where the PS is committed to > > > > historic. > > > > > > I'll accept your offer with regard to the Security Consideration section. > > > Any volunteers? > > > I do not believe that the experimental is the right track for this. > > > > I'd be willing to contribute to the security considerations text. > > > > I'm not sure if the experimental track is right or not, though I do > > think that somehow limiting the lifetime of password-based approaches > > has a certain appeal. We must grease the skids for PKI deployment, and > > not simply provide an excuse for maintaining the status quo, but this is > > a complex issue. That is why I think we need a working group to iron it > > out. > > > > Scott > > Hi Scott, > > I think that there is a consensus that static passwords are BAD. > XAUTH/Hybrid are not there to support static passwords but to > support stronger authentication schemes. In some cases PKI with > "soft" tokens are even less secure than legacy authentication > schemes such as SecurID tokens. In the absence of PKI, IKE users > will fall back to use pre-shared keys. Do we want that? In some > aspects IKE pre-shared secrets are even less secure than > XAUTH/Hybrid with fixed passwords since they are susceptible to > off-line dictionary attacks. Why not ban pre-shared secrets? > One of the key differences is XAUTH/hybrid provides no incentive to move to PKI whereas pre-shared secrets by virtue of being unmanageable does. However, just to throw a little personal experience for perspective in favor of shared secrets, whether XAUTH/hybrid provided or pre-shared secrets, I offer the following story. One of my clients has an IKE capable firewall. I decided to purchase the vendor's certificate based solution because I believe a certificate based solution offers better security, it inexpensively introduces my client to certificate based thinking, and it was a slam-dunk -- I didn't have to think about it. :) I purchased the recently released software in May of 1999 and discovered, after five weeks, I had to downgrade my NT server to a non-y2k patch level and the software itself wasn't y2k. I returned the software and went the pre-shared secret route. Even with PKI there is still a password problem: the user's password used to encrypt their private key. People do stupid things including choosing stupid passwords. Many users still write their passwords on pieces of paper and attach them to their terminals, or write them down on mouse pads, or write them down on a sheet just inside their top desk drawer, sometimes labeled "password." In one case a women could not remember her ID and password to save her life. Eventually I changed her password to her husband's name without any character substitutions. She could not remember that one, too. So, whether you are using certificates, smart cards, or anything else that is password related, the question is: what's the difference between having xauth/hybrid and not having it? Strictly looking at passwords, a central service can impose good password selection mechanisms as can client software; However, a central service is in a better position to perform an off-line dictionary attack to assure good choice. When I think about the problems xauth/hybrid address I think of Bart Simpson's immortal words (stolen from somewhere else, I bet) "you're damned if you do and you're damned if you don't." I believe XAUTH/hybrid offers something valuable but should not be encouraged. -dpg From owner-ietf-ipsra Thu Jul 22 04:55:17 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id EAA23687 for ietf-ipsra-bks; Thu, 22 Jul 1999 04:55:17 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id EAA23683 for ; Thu, 22 Jul 1999 04:55:12 -0700 (PDT) Received: from checkpoint.com (kaveret.checkpoint.com [199.203.71.97]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id PAA17180; Thu, 22 Jul 1999 15:01:41 +0300 (IDT) Message-ID: <379707AC.B93B29E1@checkpoint.com> Date: Thu, 22 Jul 1999 14:59:40 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg Carter CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <01E1D01C12D7D211AFC70090273D20B1B8F8DB@sothmxs06.entrust.com> Content-Type: multipart/alternative; boundary="------------D6755A718FA47231388316A3" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: --------------D6755A718FA47231388316A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Greg, Let me try to answer the questions you have posed: Greg Carter wrote: > Hi, > How are PKI 'soft' tokens (by that I guess you mean private keys stored on > disk, password protected) less secure? > > How is a one way proprietary authentication scheme more secure than mutual > authentication? with shared secrets or PKI? Its been awhile since I looked > at the internals of the ACE server but I believe it too uses DES shared > secrets between the server and the NAS, Most of the other DES based token > cards rely on RADIUS to act as their authentication server, so now we are > down to MD5 hiding. > > One way authentication is pointless, IMHO. > I agree - One way authentication is indeed pointless. But that's not what Hybrid is all about. In Hybrid you first authenticate the Gateway using signatures. Only then you authenticate the client using "legacy" authentication schemes. Authentication is mutual but different methods are employed to authenticate the client and the Gateway, hence the term Hybrid. > > Oh, what about soft tokens, most of the DES based challenge/response token > vendors offer software based tokens, I believe SecurID does as well. So how > does your SGW know if the user is using a true hardware token or a soft > token, it doesn't. A soft token will be susceptible to the same attacks as > your shared key file, yet offers only one way authentication. > Again I agree. It might be that I was misunderstood. I argue that in some cases hardware based legacy authentication schemes (e.g. SecurID cards) have advantages over PKI software tokens. One can copy your software token without you even noticing it and then mount on it an offline dictionary attack. I agree that XAUTH/Hybrid can be abused by employing weak authentication methods. I don't endorse static passwords or other weak authentication methods and I believe they should not be used. I do believe that there are strong legacy authentication methods. They are widely used today and should be supported. Regards, Tamir. --------------D6755A718FA47231388316A3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Greg,
Let me try to answer the questions you have posed:

Greg Carter wrote:

Hi,
How are PKI 'soft' tokens (by that I guess you mean private keys stored on
disk, password protected) less secure?

How is a one way proprietary authentication scheme more secure than mutual
authentication? with shared secrets or PKI?  Its been awhile since I looked
at the internals of the ACE server but I believe it too uses DES shared
secrets between the server and the NAS, Most of the other DES based token
cards rely on RADIUS to act as their authentication server, so now we are
down to MD5 hiding.

One way authentication is pointless, IMHO.
 

I agree - One way authentication is indeed pointless. But that's not what Hybrid is all about.
In Hybrid you first authenticate the Gateway using signatures. Only then you authenticate the client using "legacy" authentication schemes.
Authentication is mutual but different methods are employed to authenticate the client and the Gateway, hence the term Hybrid.
 
Oh, what about soft tokens, most of the DES based challenge/response token
vendors offer software based tokens, I believe SecurID does as well.  So how
does your SGW know if the user is using a true hardware token or a soft
token, it doesn't.  A soft token will be susceptible to the same attacks as
your shared key file, yet offers only one way authentication.
 
Again I agree.
It might be that I was misunderstood.
I argue that in some cases hardware based legacy authentication schemes (e.g. SecurID cards) have advantages over PKI software tokens.
One can copy your software token without you even noticing it and then mount on it an offline dictionary attack.

I agree that XAUTH/Hybrid can be abused by employing weak authentication methods.
I don't endorse static passwords or other weak authentication methods and I believe they should not be used.
I do believe that there are strong legacy authentication methods. They are widely used today and should be supported.

Regards,
Tamir.
  --------------D6755A718FA47231388316A3-- From owner-ietf-ipsra Thu Jul 22 05:48:10 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id FAA23756 for ietf-ipsra-bks; Thu, 22 Jul 1999 05:48:10 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id FAA23752 for ; Thu, 22 Jul 1999 05:48:06 -0700 (PDT) Received: from checkpoint.com (kaveret.checkpoint.com [199.203.71.97]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id PAA22084; Thu, 22 Jul 1999 15:54:38 +0300 (IDT) Message-ID: <37971415.4727305D@checkpoint.com> Date: Thu, 22 Jul 1999 15:52:37 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dennis Glatting CC: ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Dennis, I'm not sure I completely understood the reasoning you have presented with regard to favouring pre-shared keys on Xauth/Hybrid with static passwords. Hybrid, when employed, authenticates the server by means of public key signatures therefore providing stronger server authentication than pre-shared keys. Furthermore, if you use pre-shared keys with aggressive you are susceptible to the following attack: 1. Initiate aggressive mode with the server and abort after you receive a reply (in order to do that you only need to know the user identity). 2. Mount an offline dictionary attack on HASH_R to find out the pre-shared key. This attack cannot be employed in Hybrid. And again, don't get me wrong - I don't support use of static passwords. XAUTH/Hybrid is there to support stronger authentication schemes. Regards, Tamir. Dennis Glatting wrote: > > > One of the key differences is XAUTH/hybrid provides no incentive to > move to PKI whereas pre-shared secrets by virtue of being unmanageable > does. However, just to throw a little personal experience for > perspective in favor of shared secrets, whether XAUTH/hybrid provided > or pre-shared secrets, I offer the following story. > > One of my clients has an IKE capable firewall. I decided to purchase > the vendor's certificate based solution because I believe a > certificate based solution offers better security, it inexpensively > introduces my client to certificate based thinking, and it was a > slam-dunk -- I didn't have to think about it. :) I purchased the > recently released software in May of 1999 and discovered, after five > weeks, I had to downgrade my NT server to a non-y2k patch level and > the software itself wasn't y2k. I returned the software and went the > pre-shared secret route. > > Even with PKI there is still a password problem: the user's password > used to encrypt their private key. People do stupid things including > choosing stupid passwords. Many users still write their passwords on > pieces of paper and attach them to their terminals, or write them down > on mouse pads, or write them down on a sheet just inside their top > desk drawer, sometimes labeled "password." In one case a women could > not remember her ID and password to save her life. Eventually I > changed her password to her husband's name without any character > substitutions. She could not remember that one, too. So, whether you > are using certificates, smart cards, or anything else that is password > related, the question is: what's the difference between having > xauth/hybrid and not having it? Strictly looking at passwords, a > central service can impose good password selection mechanisms as can > client software; However, a central service is in a better position to > perform an off-line dictionary attack to assure good choice. > > When I think about the problems xauth/hybrid address I think of Bart > Simpson's immortal words (stolen from somewhere else, I bet) "you're > damned if you do and you're damned if you don't." I believe > XAUTH/hybrid offers something valuable but should not be encouraged. > > -dpg From owner-ietf-ipsra Thu Jul 22 06:38:36 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id GAA23800 for ietf-ipsra-bks; Thu, 22 Jul 1999 06:38:36 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA23796 for ; Thu, 22 Jul 1999 06:38:34 -0700 (PDT) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA01030; Thu, 22 Jul 1999 09:40:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 22 Jul 1999 09:34:49 -0400 To: "Y. John Jiang" From: Stephen Kent Subject: Re: Comment on xauth and hybrid Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: At 7:11 PM -0400 7/21/99, Y. John Jiang wrote: >I did not mean the hacker needed to extract the key. The scenario >is like this: >1. A trojan is installed on a user's PC (btw, this has become very >popular). >2. The pass phrase is captured by monitoring the user's keystrokes. >3. The hacker logs into the PC and then logs into the user's bank account >which requires certificate authentication. > >True, a well-engineered hardware device does not allow the capture of >the pass phrase. Adding a small keyboard on the hard token would help. >However, the popular hard tokens on the market all rely on the PC >keyboard for pass phrase input. I agree that this sort of TH attack would be successful, but this is only slightly different from having a TH take advantage of an already-enabled token of any sort, irrespectove of keystroke capture. Users are not likely to be willing to have to re-enter a PIN/passphrase every time they wat to enable a token. Once per "session" is about it. So, having a key[ad on a token help a bit, but also is not a complete solution. Steve From owner-ietf-ipsra Thu Jul 22 07:09:44 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id HAA23881 for ietf-ipsra-bks; Thu, 22 Jul 1999 07:09:44 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA23877 for ; Thu, 22 Jul 1999 07:09:42 -0700 (PDT) Received: id KAA14835; Thu, 22 Jul 1999 10:07:54 -0400 Received: by gateway id ; Thu, 22 Jul 1999 10:10:32 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8E6@sothmxs06.entrust.com> From: Greg Carter To: "'Waters, Stephen'" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 10:10:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Stephen, Not to be flippant but fortunately the first two are outside the scope of IPSec, the last already exists in IKE. We can not engineer IKE to the point of requiring Tempest shielded workstations... If an attacker can install a keyboard monitoring app, then why can't they install a shim to monitor IP traffic, which would make all the authentication in the world useless since they can just grab the plain text. If your software allows trivial passwords, or stores private keys/shared keys in the clear, or any of the other arguments I have heard for one-way auth... then its less than adequate to say the least. I actually have no problems in allowing vendors to do XAUTH, I have no doubts that any implementation that requires the user to enter two passwords, a challenge and a response and only provide one way authentication will never win in the market. I have problems with such a protocol being developed (and market) under the notion that it is some how more secure than the current IKE authentication mechanisms. Bye. -----Original Message----- From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] Sent: Thursday, July 22, 1999 7:08 AM To: Dennis Glatting Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Maybe if we write down the ideal requirements, something will pop-up (humm): 1) no passwords needed, since passwords get written down! 2) client authentication that can not be cracked off-line 3) a single, strong authentication mechanism that can be used without the need of XAUTH From owner-ietf-ipsra Thu Jul 22 08:19:06 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id IAA24054 for ietf-ipsra-bks; Thu, 22 Jul 1999 08:19:06 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id IAA24050 for ; Thu, 22 Jul 1999 08:19:04 -0700 (PDT) Received: id LAA12258; Thu, 22 Jul 1999 11:15:16 -0400 Received: by gateway id ; Thu, 22 Jul 1999 11:17:53 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8E8@sothmxs06.entrust.com> From: Greg Carter To: "'Tamir Zegman'" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 11:17:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: -----Original Message----- From: Tamir Zegman [mailto:zegman@checkpoint.com] Sent: Thursday, July 22, 1999 8:00 AM To: Greg Carter Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid Hi Greg, In Hybrid you first authenticate the Gateway using signatures. Only then you authenticate the client using "legacy" authentication schemes. Authentication is mutual but different methods are employed to authenticate the client and the Gateway, hence the term Hybrid. [Greg Carter] Dan has already stated that these methods do not allow for proper authentication of the IKE SA keying material. Also it introduces another DOS attack, where the gateway is forced to do many phase 1 negotiations without ever authenticating the client. [Greg Carter] Given that the client has the code to read and verify certificates why can't it manage its own (or its own shared keys)? If an organization can run an ACE server and manage 10's thousands of hardware cards, why can they run a directory and issue certificates? I argue that in some cases hardware based legacy authentication schemes (e.g. SecurID cards) have advantages over PKI software tokens. One can copy your software token without you even noticing it and then mount on it an offline dictionary attack. [Greg Carter] I meant 'soft' challenge/response tokens: http://www.securitydynamics.com/products/datasheets/securidst-ds.html http://www.axent.com/product/dsbu/def2.htm#secure , which you as a SGW have no way of knowing the user is using. So you can not guarantee that the user is using a 'hard' token, so the arguments that challenge/response tokens are more "secure" than public key are not valid. Bye. From owner-ietf-ipsra Thu Jul 22 09:15:08 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id JAA24229 for ietf-ipsra-bks; Thu, 22 Jul 1999 09:15:08 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA24225 for ; Thu, 22 Jul 1999 09:15:05 -0700 (PDT) Received: from checkpoint.com (kaveret.checkpoint.com [199.203.71.97]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id TAA10416; Thu, 22 Jul 1999 19:21:35 +0300 (IDT) Message-ID: <37974497.C682DC06@checkpoint.com> Date: Thu, 22 Jul 1999 19:19:35 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg Carter CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <01E1D01C12D7D211AFC70090273D20B1B8F8E8@sothmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Greg Carter wrote: > -----Original Message----- > From: Tamir Zegman [mailto:zegman@checkpoint.com] > Sent: Thursday, July 22, 1999 8:00 AM > To: Greg Carter > Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org > Subject: Re: Comment on xauth and hybrid > > Hi Greg, > In Hybrid you first authenticate the Gateway using signatures. Only then you > authenticate the client using "legacy" authentication schemes. > Authentication is mutual but different methods are employed to authenticate > the client and the Gateway, hence the term Hybrid. > > [Greg Carter] Dan has already stated that these methods do not allow for > proper authentication of the IKE SA keying material. Also it introduces > another DOS attack, where the gateway is forced to do many phase 1 > negotiations without ever authenticating the client. > I think that Dan was talking about the use of a global pre-shared key in Phase1. This is not Hybrid. Could you refer me to that above mentioned thread? With regard to DoS attacks this weakness is inherent to IKE as it is today: I assume you are not talking about Aggressive mode which opens you to very vicious DoS attacks no matter what authentication you are using but on MainMode. There are three cases we need to consider: 1. The client is spoofing its address - in which case the cookie mechanism protects the server and no DoS is possible (unless the client is in between the server and the spoofed address, see 2.). 2. The client is using his own address but does not do any DH exponentiations - In which case the server will be forced to do 2 DH exponentiations no matter what authentication method is used. 3. The client is using his own address and is doing the DH computations (well actually it can use 2^1 as a public key and thus save on the DH computations): In Hybrid authentication the server will need to do 2 DH computations + 1 DSA/RSA signature operation while the client will need to do 2 DH computations. In Signature authentication the server will need to do 2 DH computations + 1 DSA/RSA verification operation while the client will need to do 2 DH computations. I don't see much difference since DH has a bigger computational overhead. Oh, one more thing, if you use DSA, then verification is actually more expensive than signature. So Hybrid is even better in that respect. > > [Greg Carter] Given that the client has the code to read and verify > certificates why can't it manage its own (or its own shared keys)? If an > organization can run an ACE server and manage 10's thousands of hardware > cards, why can they run a directory and issue certificates? > > Well they can but they already have the ACE server infrastructure and are hesitant on having a fast transition to PKI. > I argue that in some cases hardware based legacy authentication schemes > (e.g. SecurID cards) have advantages over PKI software tokens. > One can copy your software token without you even noticing it and then mount > on it an offline dictionary attack. > > [Greg Carter] I meant 'soft' challenge/response tokens: > > http://www.securitydynamics.com/products/datasheets/securidst-ds.html > > > http://www.axent.com/product/dsbu/def2.htm#secure > > > , which you as a SGW have no way of knowing the user is using. So you can > not guarantee that the user is using a 'hard' token, so the arguments that > challenge/response tokens are more "secure" than public key are not valid. > I think we agree. I was talking about hardware legacy tokens while you are discussing software. I was not trying to say that Hybrid is better than signatures but that in some situations it is not much worse. Tamir & Moshe. From owner-ietf-ipsra Thu Jul 22 10:57:37 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA24512 for ietf-ipsra-bks; Thu, 22 Jul 1999 10:57:37 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id KAA24508 for ; Thu, 22 Jul 1999 10:57:35 -0700 (PDT) Received: id NAA09006; Thu, 22 Jul 1999 13:51:10 -0400 Received: by gateway id ; Thu, 22 Jul 1999 13:53:48 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F8EA@sothmxs06.entrust.com> From: Greg Carter To: "'Tamir Zegman'" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Comment on xauth and hybrid Date: Thu, 22 Jul 1999 13:53:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Tamir, I think that Dan was talking about the use of a global pre-shared key in Phase1. This is not Hybrid. Could you refer me to that above mentioned thread? Hybrid expects the Secure GW to use keying material it hasn't authenticated yet, to me this is similar to the global shared key case. With regard to DoS attacks this weakness is inherent to IKE as it is today: I assume you are not talking about Aggressive mode which opens you to very vicious DoS attacks no matter what authentication you are using but on MainMode. Except with regular IKE at the end of phase 1 you have authenticated the client, so if it fails you can through away state. Hybrid you must keep the phase 1 state around and do an XAUTH to authenticate the client. Given that most of the XAUTH methods (token cards) are rather lengthy operations I think this is worse, especially given that you'll have to allow for mistyped responses and have to 'retry' the AXUTH a number of times before failing. Or do you force a new phase 1 for each XAUTH attempt? > [Greg Carter] I meant 'soft' challenge/response tokens: > > http://www.securitydynamics.com/products/datasheets/securidst-ds.html > > > http://www.axent.com/product/dsbu/def2.htm#secure > > > , which you as a SGW have no way of knowing the user is using. So you can > not guarantee that the user is using a 'hard' token, so the arguments that > challenge/response tokens are more "secure" than public key are not valid. > I think we agree. I was talking about hardware legacy tokens while you are discussing software. I was not trying to say that Hybrid is better than signatures but that in some situations it is not much worse. I know your were talking about hardware tokens, I was pointing out that it is impossible for your gateway to distinguish a SecurID hardware token user from a SecurID software token user. So how can you make claims that using hardware tokens is better if there is no cryptographic way to prove the client is using them? Again I don't care if others want to do this, just don't claim it is better, or equivalent to existing IKE. Bye. From owner-ietf-ipsra Thu Jul 22 11:26:43 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id LAA24668 for ietf-ipsra-bks; Thu, 22 Jul 1999 11:26:43 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA24664 for ; Thu, 22 Jul 1999 11:26:40 -0700 (PDT) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id OAA15065; Thu, 22 Jul 1999 14:29:54 -0400 (EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma015043; Thu, 22 Jul 99 14:29:11 -0400 Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id OAA12669; Thu, 22 Jul 1999 14:32:54 -0400 (EDT) Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L8AHSC>; Thu, 22 Jul 1999 19:26:53 +0100 Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> From: "Waters, Stephen" To: "David P. Kemp" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Secret public keys Date: Thu, 22 Jul 1999 19:26:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Yes, I believe your suggestion (copied below) would fix the off-line cracking problem, and is supported in IKE today. BUT, it has problems in that, to a large extent, it will through VPN role into confusion! The model would be:- Client is loaded with: a) private key (password protected still, just for laughs) b) certificate of VPN server c) certificate of VPN server signer (CA certificate) I can deliver all this information to the client in a PKCS#12 file. As you say, the private key can now be impossible (very hard) to crack, because the client's public key is not accessible (hopefully). The client now 'connects' to the VPN server to engage in a signature authentication passing some id. The problem I have now is mapping that id to the client's public key or certificate in a manageable way. I hope we can agree that managing public-key to id mapping can only be handled by using the CA/certificate approach. For me to be able to find the appropriate certificate, I would need most of the information typically passed (by the client) in a certificate. To back-track a bit. My previous model was to have the VPN client send their certificate as part of the IKE exchange. This allows me greater flexibility. If the client did not send their certificate, a simple id (DN, IP, DNS..) may not be sufficient to resolve the correct certificate. I think (just made it up, so this is probably tosh but..) what is needed to fix this is a new type of certificate, a certificate with no public key in it! When I enrol, the CA would now generate two sister certificates: one 'public' one, and one 'private' one. The 'public' one would contain now public key, but would allow the 'private' certificate to be found using the contain DN/Signer/Serial number. The VPN client is then loaded with the 'public' certificate, and presents this to the VPN server. The VPN server uses this certificate (once tested for trustworthiness) to retrieve the 'private' certificate that does have the public key. Even if this makes sense, is it too late? Steve. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Thursday, July 22, 1999 2:39 PM To: Stephen.Waters@cabletron.com Cc: dpkemp@missi.ncsc.mil; kent@bbn.com Subject: Secret public keys It's not relevant to PKIX anymore, and since I'm not currently subscribed to IPSEC, I won't start a thread there. I was suggesting that the client be loaded with the entire private key, transformed (encrypted) using the password as the encryption key. Assuming private keys are uniformly distributed, there is no way to tell offline when the right password is guessed. And I was suggesting that the "public key" corresponding to the client's private key not be placed in a certificate or be made public - it is kept secret as part of the VPN server's user database. This is precisely Lynn Wheeler's "certificateless account" idea. The server can authenticate the client using the stored public key without ever sending it in a cert over the wire. The user may actually have a certificate and private key which he could use once to sign up for VPN service, but after that initial enrollment, the enrollment-generated keypair would be used in the IKE handshake. The user's certified keypair wouldn't need to be retained on the laptop at all for VPN purposes, and keeping it there for other purposes would not compromise the VPN authentication. Jeff Schiller's procedure mentioned by Steve Kent may increase the cracking effort by 1000x or 10,000x, but it is only a constant (O(1)) increase. I tend to view subexponential processes with caution, and an O(1) process as a band-aid. Increasing the length of the password gives an exponential (O(2^n)) increase in effort, so forcing the user to remember a longer password has big payoffs, but has even bigger pushback from users and marketers. Keeping the VPN public key secret completely precludes offline cracking even with user-friendly short passwords and without any artificial performance degraders. Regards, Dave > From: "Waters, Stephen" > > This started, I think, as a debate about certificates v passwords, but does > seem to be going in the IKE direction :) > > In your mail, are you suggesting that the client device is only loaded with > part of the private key, and that the remainder is entered when the client > device connects? > > If so, I think this can still be cracked off-line. If we are using > certificates, the client's public certificate (with public key) is very much > available. It may take some time (I've no idea how long!), but couldn't I > still work on the portion of the private key (the majority of which is > stored on the client device somehow) until I had reconstructed the private > key to match the public key? > > Cheers, Steve. From owner-ietf-ipsra Thu Jul 22 12:05:47 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id MAA24803 for ietf-ipsra-bks; Thu, 22 Jul 1999 12:05:47 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA24799 for ; Thu, 22 Jul 1999 12:05:40 -0700 (PDT) Received: from checkpoint.com (ts035p8.tlv.netvision.net.il [199.203.202.136]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id WAA19711; Thu, 22 Jul 1999 22:12:09 +0300 (IDT) Message-ID: <37977A43.E7844AC1@checkpoint.com> Date: Thu, 22 Jul 1999 22:08:35 +0200 From: Tamir Zegman X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Greg Carter CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Comment on xauth and hybrid References: <01E1D01C12D7D211AFC70090273D20B1B8F8EA@sothmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Greg Carter wrote: > Hi Tamir, > > > Hybrid expects the Secure GW to use keying material it hasn't authenticated > yet, to me this is similar to the global shared key case. I believe there is a difference. When you use a global shared key the client does not really authenticate the server whereas if you use Hybrid the server is authenticated using signatures. The Secure GW does use as you say the keying material before authenticating the client. However this keying material is used only for the following XAUTH exchange. It MUST NOT be used for anything else, specifically it MUST NOT be used for quick mode until XAUTH is successfully completed. < trimmed> > > > With regard to DoS attacks this weakness is inherent to IKE as it is > today: > I assume you are not talking about Aggressive mode which opens you > to very > vicious DoS attacks no matter what authentication you are using but > on MainMode. > > Except with regular IKE at the end of phase 1 you have authenticated the > client, so if it fails you can through away state. Hybrid you must keep the > phase 1 state around and do an XAUTH to authenticate the client. Given that > most of the XAUTH methods (token cards) are rather lengthy operations I > think this is worse, especially given that you'll have to allow for mistyped > responses and have to 'retry' the AXUTH a number of times before failing. > Or do you force a new phase 1 for each XAUTH attempt? > > Yes, I agree. This means that you need to keep state around for a while until the XAUTH is finished. I think that the best practice is to through away the Phase1 SA if XAUTH fails: "If the User fails to authenticate the IKE SA MUST be discarded." < trimmed> > > [Greg Carter] I meant 'soft' challenge/response tokens: > > > > http://www.securitydynamics.com/products/datasheets/securidst-ds.html > > > > > > http://www.axent.com/product/dsbu/def2.htm#secure > > > > > > , which you as a SGW have no way of knowing the user is using. So you can > > not guarantee that the user is using a 'hard' token, so the arguments that > > challenge/response tokens are more "secure" than public key are not valid. > > > > I think we agree. I was talking about hardware legacy tokens while > you are > discussing software. > I was not trying to say that Hybrid is better than signatures but > that in some > situations it is not much worse. > > I know your were talking about hardware tokens, I was pointing out that it > is impossible for your gateway to distinguish a SecurID hardware token user > from a SecurID software token user. So how can you make claims that using > hardware tokens is better if there is no cryptographic way to prove the > client is using them? > > Again I don't care if others want to do this, just don't claim it is better, > or equivalent to existing IKE. > Bye. Yes I agree. But if you issue your workers only hardware tokens then you have no problem with that. Regards, Tamir. From owner-ietf-ipsra Thu Jul 22 12:38:58 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id MAA24933 for ietf-ipsra-bks; Thu, 22 Jul 1999 12:38:58 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA24929 for ; Thu, 22 Jul 1999 12:38:55 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA10670; Thu, 22 Jul 1999 15:40:55 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA10666; Thu, 22 Jul 1999 15:40:54 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA06146; Thu, 22 Jul 1999 15:40:52 -0400 (EDT) Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id PAA12864; Thu, 22 Jul 1999 15:40:31 -0400 (EDT) Message-Id: <199907221940.PAA12864@ara.missi.ncsc.mil> Date: Thu, 22 Jul 1999 15:40:31 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Secret public keys To: dpkemp@missi.ncsc.mil, Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: b/06FOgafknU3EAhW9jNQQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > From: "Waters, Stephen" > > The problem I have now is mapping that id to the client's public key or > certificate in a manageable way. I hope we can agree that managing > public-key to id mapping can only be handled by using the CA/certificate > approach. It seems to me that the client must pass some sort of ID to the server, and that the server must have some sort of client-specific data that is *not* contained in a public certificate to enable XAUTH to work. You mentioned a large shared-secret value which could be unlocked on the client by use of a short password; how is that shared-secret made known to the server, in a manageable way? If shared-secrets are manageable, then a certificateless secret public key is just as manageable, using the identical procedures. Please describe exactly the steps you proposed for enabling a secondary authentication exchange (XAUTH). What data is stored on the client, what is stored on the server, and what flows between them during the IKE and XAUTH exchanges? The question that began this thread was "does IKE+XAUTH have any value-added over IKE alone?" It's obvious that managing secrets is more difficult than managing public data. But I believe that regardless of whether you choose to use secret information on the server to eliminate the possibility of offline password guessing attacks on the client, a secondary authentication exchange is superfluous. Whatever the requirements are, they can be satisfied within IKE. From owner-ietf-ipsra Thu Jul 22 14:16:21 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id OAA25307 for ietf-ipsra-bks; Thu, 22 Jul 1999 14:16:21 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA25303 for ; Thu, 22 Jul 1999 14:16:18 -0700 (PDT) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA25440; Thu, 22 Jul 1999 17:20:03 -0400 (EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma025417; Thu, 22 Jul 99 17:19:57 -0400 Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id RAA20622; Thu, 22 Jul 1999 17:23:41 -0400 (EDT) Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L8AHY4>; Thu, 22 Jul 1999 22:17:41 +0100 Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE64@new-exc1.ctron.com> From: "Waters, Stephen" To: "David P. Kemp" Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, "Bussiere, Dick" , "Bassett, John Robert" , "Holland, Gary" Subject: RE: Secret public keys Date: Thu, 22 Jul 1999 22:17:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: David, (your note copied below) I am trying to avoid using XAUTH, if possible. If I can get offline cracking protection using an IKE Phase mechanism, that's what I want. We have plans to allow RADIUS servers to provide per-user pre-shared secrets for IKE Phase-1 authentication, if that is what the customer wants. If the customer wants legacy, they are probably not going to like PKI in the picture, so our recommendation will be to use per-user pre-shared phase-1 and XAUTH for the legacy. If the customer will tolerate PKI, I would like to be able to offer it in a way that was comparable to the strongest legacy authentication they may be using today. The proposal to not load the VPN client with the public key (just private) COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to collect the appropriate public key, but the security manager would need some handy way to 'copy' the users' public key from the certificate (or key generation point) to the RADIUS management tool. Not impossible I guess. O.K., so here's a 'from ground up' Private Key Infrastructure: 1) Go to RADIUS tool. Add client stephen.waters@ctron.com 2) Push 'generate key pair' and public key is stored in association with new client 3) Push 'build client file' and a file is generated with the private-key (password protected), appropriate VPN server public key and ID (also password protected), and client id to present when connecting (stephen.waters@ctron.com), VPN server address, other stuff on policy/proposals maybe. Client device is now loaded with the file. Connects to VPN server, presents id and engages in a signature exchange. VPN server calls to RADIUS using provided id to collect public key to complete Phase1. Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. I think I like it :) No off-line cracking, no CRL problems, no new protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password problem, no CA. Something must be wrong! At the very least, a lot of people are going to be miffed it this works :) Sorry, I'm not being flippant, it's just late here and I've started to giggle at the apparent relief this offers. I know it won't last long. Steve. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Thursday, July 22, 1999 8:41 PM To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org Subject: RE: Secret public keys > From: "Waters, Stephen" > > The problem I have now is mapping that id to the client's public key or > certificate in a manageable way. I hope we can agree that managing > public-key to id mapping can only be handled by using the CA/certificate > approach. It seems to me that the client must pass some sort of ID to the server, and that the server must have some sort of client-specific data that is *not* contained in a public certificate to enable XAUTH to work. You mentioned a large shared-secret value which could be unlocked on the client by use of a short password; how is that shared-secret made known to the server, in a manageable way? If shared-secrets are manageable, then a certificateless secret public key is just as manageable, using the identical procedures. Please describe exactly the steps you proposed for enabling a secondary authentication exchange (XAUTH). What data is stored on the client, what is stored on the server, and what flows between them during the IKE and XAUTH exchanges? The question that began this thread was "does IKE+XAUTH have any value-added over IKE alone?" It's obvious that managing secrets is more difficult than managing public data. But I believe that regardless of whether you choose to use secret information on the server to eliminate the possibility of offline password guessing attacks on the client, a secondary authentication exchange is superfluous. Whatever the requirements are, they can be satisfied within IKE. From owner-ietf-ipsra Thu Jul 22 15:10:01 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id PAA25480 for ietf-ipsra-bks; Thu, 22 Jul 1999 15:10:01 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA25476 for ; Thu, 22 Jul 1999 15:09:59 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRQ8B1; Thu, 22 Jul 1999 15:12:23 -0700 Message-ID: <37979748.A21D606D@redcreek.com> Date: Thu, 22 Jul 1999 15:12:24 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Requirements driving xauth [was Re: Secret public keys, Re: comment on xauth and hybrid] References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: The various xauth threads have been most interesting, but I think Vipul and Dan asked a question which has never been explicitly answered: why do we need this? Stephen assessed the various threats pretty well: "Waters, Stephen" wrote: > Cases: > 1) Thief does a runner with a device with no intention of returning it. > > > 2) Thief borrows the device in order to steal the primary authentication > secret, then returns the device. > That is, there seems to be an argument for use of xauth as the second factor in a two-factor authentication scheme, where the threat motivating the use of this mechanism pertains to an attacker's ability to impersonate the user by simply swiping their laptop (or hardware token, or both), either temporarily or permanently, or otherwise gain access to their private key, preshared key, or whatever they are using. Note that the term "two-factor authentication", as used here, assumes that the endpoints of the IKE SA have been mutually authenticated in a reliable way prior to the xauth exchange. The xauth/hybrid scheme seems to indicate that there is a need for xauth as a primary single factor authentication mechanism (with respect to the user). This approach would seem to obviate the need for a second factor, since the first factor ostensibly may not be spoofed or otherwise compromised. Now, the point has been raised that xauth would not be necessary at all if we had a PKI in place, but that customers are not willing to make this leap at this time. However, it appears that even if the PKI were in place, we would still be faced with the threats Stephen mentioned. This leads me to think that the questions are these: 1) If we rely only upon the current built-in authentication methods for IKE, do we perceive a need for a two-factor mechanism like xauth, or for a single-factor hybrid mechanism using passphrases? If the answer to (1) is no, we are finished. On the other hand, if the answer to (1) is yes (or maybe), we must ask the following: 2) Why do we perceive this need? That is, could we remove the threat by somehow modifying the authentication mechanisms in IKE, or by better protecting the material IKE uses for authentication? 3) In the end, if we cannot insure the integrity of our stored authentication material, can we be sure of the integrity of the system into which we are typing our passphrase? That is, can we be sure we're running a "secure" ipsec implementation that's not diverting or otherwise storing our passphrase for later use, if we cannot be sure someone hasn't tampered with our system? What a can of worms... but what I think I may have convinced myself of is this: the need for xauth is dubious if you have PKI plus some measure of physical security for the private keys in the client. These may be locally protected on the client's system in a number of ways, ranging from hardware tokens to software obfuscation a la arcotsign. The point is, if you want to use a passphrase, biometric, or other such authentication mechanism, then it seems to make more sense from a security perspective to use it to unlock the private key on the client's system, and then use *that* to authenticate within IKE using the existing public key mechanisms. Scott From owner-ietf-ipsra Fri Jul 23 05:13:07 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id FAA04270 for ietf-ipsra-bks; Fri, 23 Jul 1999 05:13:07 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id FAA04266 for ; Fri, 23 Jul 1999 05:13:05 -0700 (PDT) Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id IAA08714; Fri, 23 Jul 1999 08:15:09 -0400 (EDT) Received: from dpj (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA04473; Fri, 23 Jul 1999 08:15:05 -0400 Message-Id: <3.0.5.32.19990723081649.00799300@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 23 Jul 1999 08:16:49 -0400 To: "Scott G. Kelly" From: David Jablon Subject: Re: Requirements driving xauth [was Re: Secret public keys, Re: comment on xauth and hybrid] Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org In-Reply-To: <37979748.A21D606D@redcreek.com> References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: The XAUTH threads have raised some good questions, but so far, not quite as many good answers, about the role of "legacy" authentication systems based on passwords, tokens, etc. I present some reasons to refocus the discussion on the issue of local vs. remote storage of credentials below. At 03:12 PM 7/22/99 -0700, Scott G. Kelly wrote: >The various xauth threads have been most interesting, but I think Vipul >and Dan asked a question which has never been explicitly answered: why >do we need this? Stephen assessed the various threats pretty well: > >"Waters, Stephen" wrote: >> Cases: >> 1) Thief does a runner with a device with no intention of returning it. > >> >> 2) Thief borrows the device in order to steal the primary authentication >> secret, then returns the device. We can also add: 3) Thief steals a backup media, which is never noticed as missing. >That is, there seems to be an argument for use of xauth as the second >factor in a two-factor authentication scheme, where the threat >motivating the use of this mechanism pertains to an attacker's ability >to impersonate the user by simply swiping their laptop (or hardware >token, or both), either temporarily or permanently, or otherwise gain >access to their private key, preshared key, or whatever they are using. > [...] >2) Why do we perceive this need? That is, could we remove the threat by >somehow modifying the authentication mechanisms in IKE, or by better >protecting the material IKE uses for authentication? Good questions. There is a need to better deal with credentials that can be kept in the user's head, and not on the local disk, without requiring cards and tokens. To fully deal with the low-entropy problem requires both extensions to IKE auth mechanisms *and* providing as much protection as possible for the use of the credentials in the local and remote systems. My main point is that there is no one perfect approach to this for all situations, and secure remote password verifiers are at least as important as local ones. >3) In the end, if we cannot insure the integrity of our stored >authentication material, can we be sure of the integrity of the system >into which we are typing our passphrase? That is, can we be sure we're >running a "secure" ipsec implementation that's not diverting or >otherwise storing our passphrase for later use, if we cannot be sure >someone hasn't tampered with our system? Your analysis is too simple. Local integrity and local privacy are distinct issues. The vulnerability of password-derived or password-encrypted local credentials is a separate serious issue. For example, one might be reasonably sure that a system doesn't have a keyboard sniffer installed right now, while at the same time be suspicious that a backup copy of the local disk has fallen into the wrong hands. >What a can of worms... but what I think I may have convinced myself of >is this: the need for xauth is dubious if you have PKI plus some measure >of physical security for the private keys in the client. These may be >locally protected on the client's system in a number of ways, ranging >from hardware tokens to software obfuscation a la arcotsign. The point >is, if you want to use a passphrase, biometric, or other such >authentication mechanism, then it seems to make more sense from a >security perspective to use it to unlock the private key on the client's >system, and then use *that* to authenticate within IKE using the >existing public key mechanisms. I'm not convinced. Perhaps the need for XAUTH is dubious, but to leap to the conclusion that local physical security is the sole answer is wrong. In many cases it makes more sense to keep sensitive user credentials in a secure remote location, and use strong remote password-based authentication (in-part) to securely retrieve this data. Entrust's SPEKE-enabled roaming feature is yet another approach to a so-called "virtual smart card" system, providing optimal use and protection for the low-entropy key, without limiting the scope of use of the user's private key. While XAUTH doesn't meet these goals, the need for strong mutual authentication that can safely use low-entropy secrets is real, and having a variety of solutions is valuable. I strongly disagree with some opinions expressed in earlier posts that supporting password methods will somehow slow deployment of PKI. Strong password methods do not pose a threat to those seriously committed to the evolution of robust PKI-based systems. -- dpj --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ietf-ipsra Fri Jul 23 05:11:03 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id FAA04257 for ietf-ipsra-bks; Fri, 23 Jul 1999 05:11:03 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id FAA04253 for ; Fri, 23 Jul 1999 05:11:01 -0700 (PDT) Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id IAA08551; Fri, 23 Jul 1999 08:12:59 -0400 (EDT) Received: from dpj (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA03494; Fri, 23 Jul 1999 08:12:54 -0400 Message-Id: <3.0.5.32.19990723081453.007c1530@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 23 Jul 1999 08:14:53 -0400 To: "Waters, Stephen" From: David Jablon Subject: RE: Secret public keys Cc: "David P. Kemp" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, "Bussiere, Dick" , "Bassett, John Robert" , "Holland, Gary" In-Reply-To: <29752A74B6C5D211A4920090273CA3DC4BBE64@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: XAUTH notwithstanding, the value of shared secret passwords and "secret public keys" is that they allow strong one-to-one agreements between a user and a service provider that is easy to set up with existing tools, with a large base of pre-existing relationships. Of course, shared-secrets alone, without a complementary PKI, don't scale to solve the world's e-commerce problems with establishing mutual trust between strangers. But this just isn't everyone's goal. Passwords and secret-public-keys are immensely practical and useful for securing user-to-provider relationships, especially when the number of highly-secure provider relationships needed by the typical user is small. Think about protecting the one most important site in your "single-sign-on" solutiuon. I believe IKE should be extended to permit strong mutual authentication based on low-entropy shared secrets. Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem to do it either. At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote: >David [Kemp], (your note copied below) > >I am trying to avoid using XAUTH, if possible. If I can get offline >cracking protection using an IKE Phase mechanism, that's what I want. > >We have plans to allow RADIUS servers to provide per-user pre-shared secrets >for IKE Phase-1 authentication, if that is what the customer wants. If the >customer wants legacy, they are probably not going to like PKI in the >picture, so our recommendation will be to use per-user pre-shared phase-1 >and XAUTH for the legacy. > >If the customer will tolerate PKI, I would like to be able to offer it in a >way that was comparable to the strongest legacy authentication they may be >using today. > >The proposal to not load the VPN client with the public key (just private) >COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to >collect the appropriate public key, but the security manager would need some >handy way to 'copy' the users' public key from the certificate (or key >generation point) to the RADIUS management tool. Not impossible I guess. > >O.K., so here's a 'from ground up' Private Key Infrastructure: > >1) Go to RADIUS tool. Add client stephen.waters@ctron.com >2) Push 'generate key pair' and public key is stored in association with new >client >3) Push 'build client file' and a file is generated with the private-key >(password protected), appropriate VPN server public key and ID (also >password protected), and client id to present when connecting >(stephen.waters@ctron.com), VPN server address, other stuff on >policy/proposals maybe. > >Client device is now loaded with the file. Connects to VPN server, presents >id and engages in a signature exchange. VPN server calls to RADIUS using >provided id to collect public key to complete Phase1. > >Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. > >I think I like it :) No off-line cracking, no CRL problems, no new >protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password >problem, no CA. Here's one problem: Password-encrypted local data may be inadequate protection for the safety of locally stored credentials. David Kemp wrote: >From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] >Sent: Thursday, July 22, 1999 8:41 PM >To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com >Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org >Subject: RE: Secret public keys > [...] >The question that began this thread was "does IKE+XAUTH have any >value-added over IKE alone?" It's obvious that managing secrets >is more difficult than managing public data. But I believe that >regardless of whether you choose to use secret information on the >server to eliminate the possibility of offline password guessing >attacks on the client, a secondary authentication exchange is >superfluous. Whatever the requirements are, they can be satisfied >within IKE. Even if we ignore obvious out-of-scope issues that IKE was never designed to solve, I think the last statement goes too far. IKE can certainly be further extended or improved to better use and protect low-entropy shared secrets. I have no opinion on whether IKE+XAUTH has value over IKE as-is. I do know that XAUTH doesn't address the mutual authentication issue in using low-entropy shared-secrets to strengthen the key exchange. IKE could be extended to use "legacy" credentials in a stronger way, with a password-authenticated key exchange. This would provide another factor for mutual authentication, and at the same time prevent yet another potential path for disclosure of these secrets. I think these are worthy goals. -- dpj --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ietf-ipsra Fri Jul 23 06:08:27 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id GAA05693 for ietf-ipsra-bks; Fri, 23 Jul 1999 06:08:27 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA05689 for ; Fri, 23 Jul 1999 06:08:24 -0700 (PDT) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA12520; Fri, 23 Jul 1999 09:10:35 -0400 (EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma012460; Fri, 23 Jul 99 09:10:28 -0400 Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id JAA20290; Fri, 23 Jul 1999 09:14:11 -0400 (EDT) Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id <38L8AJMS>; Fri, 23 Jul 1999 14:08:10 +0100 Message-ID: <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> From: "Waters, Stephen" To: David Jablon Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Secret public keys Date: Fri, 23 Jul 1999 14:08:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Can you explain this bit "Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem to do it either." IKE supports (today) the concept of "secret public keys". It's just a signature exchange. You are right that password protecting the private information is still the weak point, but if the private information is stored in such a way that it is not obvious when you have cracked it, the attacker won't know when he has the right password. This is an improvement on what we had before with all the tools (public key /cracked-private key) available, but it still relies on the sensible use of passwords. Whatever can be used to improve this weakness would be welcome. Any comments from Smartcard folk on the prospect of bomb-proof biometric cards? Cheers, Steve. -----Original Message----- From: David Jablon [mailto:dpj@world.std.com] Sent: Friday, July 23, 1999 1:15 PM To: Waters, Stephen Cc: David P. Kemp; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Bussiere, Dick; Bassett, John Robert; Holland, Gary Subject: RE: Secret public keys XAUTH notwithstanding, the value of shared secret passwords and "secret public keys" is that they allow strong one-to-one agreements between a user and a service provider that is easy to set up with existing tools, with a large base of pre-existing relationships. Of course, shared-secrets alone, without a complementary PKI, don't scale to solve the world's e-commerce problems with establishing mutual trust between strangers. But this just isn't everyone's goal. Passwords and secret-public-keys are immensely practical and useful for securing user-to-provider relationships, especially when the number of highly-secure provider relationships needed by the typical user is small. Think about protecting the one most important site in your "single-sign-on" solutiuon. I believe IKE should be extended to permit strong mutual authentication based on low-entropy shared secrets. Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem to do it either. At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote: >David [Kemp], (your note copied below) > >I am trying to avoid using XAUTH, if possible. If I can get offline >cracking protection using an IKE Phase mechanism, that's what I want. > >We have plans to allow RADIUS servers to provide per-user pre-shared secrets >for IKE Phase-1 authentication, if that is what the customer wants. If the >customer wants legacy, they are probably not going to like PKI in the >picture, so our recommendation will be to use per-user pre-shared phase-1 >and XAUTH for the legacy. > >If the customer will tolerate PKI, I would like to be able to offer it in a >way that was comparable to the strongest legacy authentication they may be >using today. > >The proposal to not load the VPN client with the public key (just private) >COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to >collect the appropriate public key, but the security manager would need some >handy way to 'copy' the users' public key from the certificate (or key >generation point) to the RADIUS management tool. Not impossible I guess. > >O.K., so here's a 'from ground up' Private Key Infrastructure: > >1) Go to RADIUS tool. Add client stephen.waters@ctron.com >2) Push 'generate key pair' and public key is stored in association with new >client >3) Push 'build client file' and a file is generated with the private-key >(password protected), appropriate VPN server public key and ID (also >password protected), and client id to present when connecting >(stephen.waters@ctron.com), VPN server address, other stuff on >policy/proposals maybe. > >Client device is now loaded with the file. Connects to VPN server, presents >id and engages in a signature exchange. VPN server calls to RADIUS using >provided id to collect public key to complete Phase1. > >Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. > >I think I like it :) No off-line cracking, no CRL problems, no new >protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password >problem, no CA. Here's one problem: Password-encrypted local data may be inadequate protection for the safety of locally stored credentials. David Kemp wrote: >From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] >Sent: Thursday, July 22, 1999 8:41 PM >To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com >Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org >Subject: RE: Secret public keys > [...] >The question that began this thread was "does IKE+XAUTH have any >value-added over IKE alone?" It's obvious that managing secrets >is more difficult than managing public data. But I believe that >regardless of whether you choose to use secret information on the >server to eliminate the possibility of offline password guessing >attacks on the client, a secondary authentication exchange is >superfluous. Whatever the requirements are, they can be satisfied >within IKE. Even if we ignore obvious out-of-scope issues that IKE was never designed to solve, I think the last statement goes too far. IKE can certainly be further extended or improved to better use and protect low-entropy shared secrets. I have no opinion on whether IKE+XAUTH has value over IKE as-is. I do know that XAUTH doesn't address the mutual authentication issue in using low-entropy shared-secrets to strengthen the key exchange. IKE could be extended to use "legacy" credentials in a stronger way, with a password-authenticated key exchange. This would provide another factor for mutual authentication, and at the same time prevent yet another potential path for disclosure of these secrets. I think these are worthy goals. -- dpj --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ietf-ipsra Fri Jul 23 10:24:37 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id KAA06598 for ietf-ipsra-bks; Fri, 23 Jul 1999 10:24:37 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA06593 for ; Fri, 23 Jul 1999 10:24:36 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRQ8RK; Fri, 23 Jul 1999 10:26:51 -0700 Message-ID: <3798A5E7.67156CFC@redcreek.com> Date: Fri, 23 Jul 1999 10:27:03 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Jablon CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Requirements driving xauth [was Re: Secret public keys,Re: comment on xauth and hybrid] References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi David, David Jablon wrote: > > > >"Waters, Stephen" wrote: > >> Cases: > >> 1) Thief does a runner with a device with no intention of returning it. > > > >> > >> 2) Thief borrows the device in order to steal the primary authentication > >> secret, then returns the device. > > We can also add: > 3) Thief steals a backup media, which is never noticed as missing. I think that the implications of (3) are covered by (2). > >2) Why do we perceive this need? That is, could we remove the threat by > >somehow modifying the authentication mechanisms in IKE, or by better > >protecting the material IKE uses for authentication? > > Good questions. There is a need to better deal with > credentials that can be kept in the user's head, and not on > the local disk, without requiring cards and tokens. > To fully deal with the low-entropy problem requires both > extensions to IKE auth mechanisms *and* providing as much > protection as possible for the use of the credentials > in the local and remote systems. I don't understand what you mean by "the low-entropy problem", and don't understand why you think IKE auth mechanisms need extending for this. >From your previous posts, I assume you mean that IKE should support passphrases, but it already does support preshared keys, which are passphrases, so I'm confused. > My main point is that there is no one perfect approach to > this for all situations, and secure remote password verifiers are > at least as important as local ones. I agree with the first part of this point, but would qualify that by saying that we are not trying to cover all situations. The focus here is on remote access to a company network. > >3) In the end, if we cannot insure the integrity of our stored > >authentication material, can we be sure of the integrity of the system > >into which we are typing our passphrase? That is, can we be sure we're > >running a "secure" ipsec implementation that's not diverting or > >otherwise storing our passphrase for later use, if we cannot be sure > >someone hasn't tampered with our system? > > Your analysis is too simple. Local integrity and local privacy > are distinct issues. The vulnerability of password-derived or > password-encrypted local credentials is a separate serious issue. It was not meant to be an analysis; rather, it is a rhetorical question, meant to illustrate some of the intracacies of this debate. Sorry I didn't make that more clear. I had hoped that my subsequent comment ("What a can of worms...") would have made it clear that I recognize the complexity here. > >What a can of worms... but what I think I may have convinced myself of > >is this: the need for xauth is dubious if you have PKI plus some measure > >of physical security for the private keys in the client. These may be > >locally protected on the client's system in a number of ways, ranging > >from hardware tokens to software obfuscation a la arcotsign. The point > >is, if you want to use a passphrase, biometric, or other such > >authentication mechanism, then it seems to make more sense from a > >security perspective to use it to unlock the private key on the client's > >system, and then use *that* to authenticate within IKE using the > >existing public key mechanisms. > > I'm not convinced. Perhaps the need for XAUTH is dubious, but to > leap to the conclusion that local physical security is the sole > answer is wrong. In many cases it makes more sense to keep > sensitive user credentials in a secure remote location, and use > strong remote password-based authentication (in-part) to securely > retrieve this data. Entrust's SPEKE-enabled roaming feature is > yet another approach to a so-called "virtual smart card" system, > providing optimal use and protection for the low-entropy key, > without limiting the scope of use of the user's private key. I think I understand your point, but maybe not. The term "physical security" does not quite do justice to what I was trying to communicate, and I could have added some more text, but then that probably wouldn't have done it either. This is very complex stuff, and there are no simple answers. This is why I think we need to focus on the requirements before we run off and try to design one-size-fits-all solutions. > I strongly disagree with some opinions expressed in earlier > posts that supporting password methods will somehow slow > deployment of PKI. Strong password methods do not pose > a threat to those seriously committed to the evolution of > robust PKI-based systems. > I'm one who has expressed such opinions, so let me try to clarify my reasoning. I think the concern has to do largely with complacency. It's not so much the thought that supporting *password* methods will slow PKI deployment, it's more that supporting arbitrary *legacy* mechanisms will slow deployment. Security is hard to understand, and also hard to deploy. Administrators will tend to take the path of least resistance, which in many cases may be attempting to continue using deployed technology. For remote access, this technology usually consists of radius, but there are others. The people who worked on radius will tell you unequivocally that is has major flaws with respect to security. As a security working group, the best thing we could possibly do is steer people clear of this. Granted, it may have been the only game in town 18 months ago, and this would give some justification for an interim hack. Even my company's products support radius at present, albeit not with xauth. However, doing it in practice as an interim hack is *way* different from standardizing it, and that is what we are discussing here. Scott From owner-ietf-ipsra Fri Jul 23 10:42:53 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id KAA06650 for ietf-ipsra-bks; Fri, 23 Jul 1999 10:42:53 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA06646 for ; Fri, 23 Jul 1999 10:42:51 -0700 (PDT) Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id NAA00077; Fri, 23 Jul 1999 13:44:56 -0400 (EDT) Received: from dpj (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA14888; Fri, 23 Jul 1999 13:44:51 -0400 Message-Id: <3.0.5.32.19990723134652.00812070@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 23 Jul 1999 13:46:52 -0400 To: "Waters, Stephen" From: David Jablon Subject: RE: Secret public keys Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org In-Reply-To: <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: At 02:08 PM 7/23/99 +0100, Stephen Waters wrote: >Can you explain this bit "Maybe XAUTH doesn't get us there. But IKE as-is >doesn't seem >to do it either." > >IKE supports (today) the concept of "secret public keys". It's just a >signature exchange. Simple. IKE doesn't yet use secret public keys in a way that protects low-entropy private keys. More specifically, IKE does not support a zero-knowledge password proof, which prevents network disclosure of a small password and at the same time authenticate the key exchange with the password. It can be done in several ways, and I thought that the philosophy motivating XAUTH and the technology of IKE fit particularly well with EKE-style techniques. >You are right that password protecting the private information is still the >weak point, but if the private information is stored in such a way that it >is not obvious when you have cracked it, the attacker won't know when he has >the right password. That's a big IF. Storing the information in a "non obvious" way still sounds weak to me. Better to not store it locally at all. I can do this today with well-built password systems, and I'd rather not be encouraged to take a step backwards to use IPSEC. To be conservative, one should presume that if software can find even an obscured locally stored private key, then then an attacker can too. One should also presume that if it's a user-chosen key, then it's crackable. >This is an improvement on what we had before with all the tools (public key >/cracked-private key) available, but it still relies on the sensible use of >passwords. Whatever can be used to improve this weakness would be welcome. What you suggest is not an improvement over all systems. And your implied meaning of "sensible use" misses the point. The entire concept of "sensible use of passwords" is relative to the system in which they're used. Take an ATM machine. A four-digit password seems to work fine there with appropriate revocation rules. With better password systems, it becomes much easier to enforce sensible use rules, which makes it possible for more users to operate securely. Deploying a new crypto system that relies on cryptographically-long passwords for security is a step in the wrong direction, and introduces unnecessary risk for users in many situations. >-----Original Message----- >From: David Jablon [mailto:dpj@world.std.com] >Sent: Friday, July 23, 1999 1:15 PM >To: Waters, Stephen >Cc: David P. Kemp; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; >Bussiere, Dick; Bassett, John Robert; Holland, Gary >Subject: RE: Secret public keys > > >XAUTH notwithstanding, the value of shared secret passwords >and "secret public keys" is that they allow strong one-to-one >agreements between a user and a service provider that is >easy to set up with existing tools, with a large base >of pre-existing relationships. > >Of course, shared-secrets alone, without a complementary PKI, >don't scale to solve the world's e-commerce problems with >establishing mutual trust between strangers. But this just >isn't everyone's goal. Passwords and secret-public-keys are >immensely practical and useful for securing user-to-provider >relationships, especially when the number of highly-secure >provider relationships needed by the typical user is small. >Think about protecting the one most important site in your >"single-sign-on" solutiuon. > >I believe IKE should be extended to permit strong mutual >authentication based on low-entropy shared secrets. > >Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem >to do it either. > >At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote: >>David [Kemp], (your note copied below) >> >>I am trying to avoid using XAUTH, if possible. If I can get offline >>cracking protection using an IKE Phase mechanism, that's what I want. >> >>We have plans to allow RADIUS servers to provide per-user pre-shared >secrets >>for IKE Phase-1 authentication, if that is what the customer wants. If the >>customer wants legacy, they are probably not going to like PKI in the >>picture, so our recommendation will be to use per-user pre-shared phase-1 >>and XAUTH for the legacy. >> >>If the customer will tolerate PKI, I would like to be able to offer it in a >>way that was comparable to the strongest legacy authentication they may be >>using today. >> >>The proposal to not load the VPN client with the public key (just private) >>COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to >>collect the appropriate public key, but the security manager would need >some >>handy way to 'copy' the users' public key from the certificate (or key >>generation point) to the RADIUS management tool. Not impossible I guess. >> >>O.K., so here's a 'from ground up' Private Key Infrastructure: >> >>1) Go to RADIUS tool. Add client stephen.waters@ctron.com >>2) Push 'generate key pair' and public key is stored in association with >new >>client >>3) Push 'build client file' and a file is generated with the private-key >>(password protected), appropriate VPN server public key and ID (also >>password protected), and client id to present when connecting >>(stephen.waters@ctron.com), VPN server address, other stuff on >>policy/proposals maybe. >> >>Client device is now loaded with the file. Connects to VPN server, >presents >>id and engages in a signature exchange. VPN server calls to RADIUS using >>provided id to collect public key to complete Phase1. >> >>Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. >> >>I think I like it :) No off-line cracking, no CRL problems, no new >>protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password >>problem, no CA. > >Here's one problem: Password-encrypted local data may be inadequate >protection for the safety of locally stored credentials. > >David Kemp wrote: >>From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] >>Sent: Thursday, July 22, 1999 8:41 PM >>To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com >>Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org >>Subject: RE: Secret public keys >> [...] >>The question that began this thread was "does IKE+XAUTH have any >>value-added over IKE alone?" It's obvious that managing secrets >>is more difficult than managing public data. But I believe that >>regardless of whether you choose to use secret information on the >>server to eliminate the possibility of offline password guessing >>attacks on the client, a secondary authentication exchange is >>superfluous. Whatever the requirements are, they can be satisfied >>within IKE. > >Even if we ignore obvious out-of-scope issues that IKE was >never designed to solve, I think the last statement goes too far. >IKE can certainly be further extended or improved to better use >and protect low-entropy shared secrets. > >I have no opinion on whether IKE+XAUTH has value over IKE as-is. >I do know that XAUTH doesn't address the mutual authentication >issue in using low-entropy shared-secrets to strengthen the >key exchange. IKE could be extended to use "legacy" credentials >in a stronger way, with a password-authenticated key exchange. >This would provide another factor for mutual authentication, >and at the same time prevent yet another potential path >for disclosure of these secrets. > >I think these are worthy goals. > >-- dpj > >--------------------------------------------------- >David P. Jablon dpj@IntegritySciences.com >President +1 508 898 9024 >Integrity Sciences, Inc. www.IntegritySciences.com From owner-ietf-ipsra Fri Jul 23 11:26:53 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA06791 for ietf-ipsra-bks; Fri, 23 Jul 1999 11:26:53 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mcfeeley.indusriver.com ([146.115.206.207]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA06787 for ; Fri, 23 Jul 1999 11:26:51 -0700 (PDT) Received: from comet (209.6.112.186) by mcfeeley.indusriver.com (Worldmail 1.3.167); 23 Jul 1999 14:28:05 -0400 Message-ID: <3770797500008EFC@mcfeeley.indusriver.com> (added by mcfeeley.indusriver.com) X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 23 Jul 1999 14:34:12 -0400 To: Stephen.Waters@cabletron.com, dpj@IntegritySciences.com From: David Chen Subject: RE: Secret public keys Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org In-Reply-To: <3.0.5.32.19990723134652.00812070@world.std.com> References: <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: I thought we like the public key as "public" as possible. (so that to prevent attack) How can someone want a "secret" for "public" key ? If it is secret, then it is private. Don't you agree? --- David From owner-ietf-ipsra Fri Jul 23 15:39:05 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id PAA07635 for ietf-ipsra-bks; Fri, 23 Jul 1999 15:39:05 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA07631 for ; Fri, 23 Jul 1999 15:39:03 -0700 (PDT) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA06184; Fri, 23 Jul 1999 18:41:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3770797500008EFC@mcfeeley.indusriver.com> (added by mcfeeley.indusriver.com) References: <3.0.5.32.19990723134652.00812070@world.std.com> <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Date: Fri, 23 Jul 1999 18:36:18 -0400 To: David Chen From: Stephen Kent Subject: RE: Secret public keys Cc: Stephen.Waters@cabletron.com, dpj@IntegritySciences.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: , Chen wrote: >I thought we like the public key as "public" as possible. (so that to >prevent attack) >How can someone want a "secret" for "public" key ? >If it is secret, then it is private. >Don't you agree? No. Making a public key public does nothing to improve its security. We're not talking about algorithms here. Public keys are public to facilitate verification of signatures, encryption, etc. However, one can choose to not disclose a public key to everyone, but rather to disclose it only to a selected set of peers if the application context supports that. Authentication in a closed system is an example of such a context. Steve From owner-ietf-ipsra Sun Jul 25 06:49:36 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id GAA26469 for ietf-ipsra-bks; Sun, 25 Jul 1999 06:49:36 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA26465 for ; Sun, 25 Jul 1999 06:49:34 -0700 (PDT) Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id JAA11908; Sun, 25 Jul 1999 09:51:48 -0400 (EDT) Received: from dpj (ppp0c145.std.com) by world.std.com (TheWorld/Spike-2.0) id AA07275; Sun, 25 Jul 1999 09:51:46 -0400 Message-Id: <3.0.5.32.19990725095333.0084c5e0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 25 Jul 1999 09:53:33 -0400 To: "David P. Kemp" From: David Jablon Subject: RE: Secret public keys Cc: Stephen.Waters@cabletron.com, ietf-ipsra@vpnc.org, kent@bbn.com In-Reply-To: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: David, Stephen forward your comments to the IPSEC list, and it has generated discussion there. Rather than focus on *persistent* secret public keys, you may find more benefit in using *ephemeral* secret public keys. These provide a more complete solution to the problem of locally stored password-encrypted private keys. At 07:26 PM 7/22/99 +0100, Waters, Stephen forwarded: >-----Original Message----- >From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] >Sent: Thursday, July 22, 1999 2:39 PM >To: Stephen.Waters@cabletron.com >Cc: dpkemp@missi.ncsc.mil; kent@bbn.com >Subject: Secret public keys > > >It's not relevant to PKIX anymore, and since I'm not currently subscribed >to IPSEC, I won't start a thread there. > >I was suggesting that the client be loaded with the entire private key, >transformed (encrypted) using the password as the encryption key. Assuming >private keys are uniformly distributed, there is no way to tell offline >when the right password is guessed. The ofline brute-force attack is still possible when additional information is available, such as the public key, or any message signed with the private key. >And I was suggesting that the "public key" corresponding to the >client's private key not be placed in a certificate or be made public - >it is kept secret as part of the VPN server's user database. This is >precisely Lynn Wheeler's "certificateless account" idea. The server >can authenticate the client using the stored public key without ever >sending it in a cert over the wire. The user may actually have a >certificate and private key which he could use once to sign up for VPN >service, but after that initial enrollment, the enrollment-generated >keypair would be used in the IKE handshake. The user's certified >keypair wouldn't need to be retained on the laptop at all for VPN >purposes, and keeping it there for other purposes would not compromise >the VPN authentication. Keeping it there still poses a risk, which can be eliminated more completely by moving it to a secure remote location. >Jeff Schiller's procedure mentioned by Steve Kent may increase the >cracking effort by 1000x or 10,000x, but it is only a constant (O(1)) >increase. I tend to view subexponential processes with caution, and >an O(1) process as a band-aid. I agree. The added safety margin of an iterated hash is better than nothing, but it's nothing like the tunable exponential benefit that you get from public-key encryption. >Increasing the length of the password >gives an exponential (O(2^n)) increase in effort, so forcing the user >to remember a longer password has big payoffs, but has even bigger >pushback from users and marketers. Absolutely. This is a serious issue for users, and one which "marketers" are beginning to understand. >Keeping the VPN public key secret >completely precludes offline cracking even with user-friendly short >passwords and without any artificial performance degraders. I disagree with the "completely precludes" part, which overstates the benefit. No matter how random the password and private key appear to be, they still belong to a small searchable space. The presence of additional data, either in the form of the public-key, or a signed message, gives the opportunity for brute-force attack. A further problem is that by limiting the distribution of the persistent public key, you lose the ability to securely communicate to the "public" at large. A better way to handle the problem is to use a secure remotely stored private key, and completely remove the need for persistent local client storage. This approach has the added benefit that the public-key can remain public, and the private key can then be used for broader purposes. I typically recommend using secret public keys, but of the ephemeral kind. Methods like EKE & SPEKE can safely retrieve the private key using a password-authenticated key exchange. This provides a more thorough approach to eliminating client storage of credentials. --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ietf-ipsra Sun Jul 25 06:47:38 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id GAA26459 for ietf-ipsra-bks; Sun, 25 Jul 1999 06:47:38 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA26455 for ; Sun, 25 Jul 1999 06:47:36 -0700 (PDT) Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id JAA11699; Sun, 25 Jul 1999 09:49:49 -0400 (EDT) Received: from dpj (ppp0c145.std.com) by world.std.com (TheWorld/Spike-2.0) id AA06003; Sun, 25 Jul 1999 09:49:46 -0400 Message-Id: <3.0.5.32.19990725094831.007e2c70@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 25 Jul 1999 09:48:31 -0400 To: David Chen From: David Jablon Subject: RE: Secret public keys Cc: Stephen.Waters@cabletron.com, dpj@IntegritySciences.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, dpkemp@missi.ncsc.mil In-Reply-To: <3770797500008EFC@mcfeeley.indusriver.com> (added by mcfeeley.indusriver.com) References: <3.0.5.32.19990723134652.00812070@world.std.com> <29752A74B6C5D211A4920090273CA3DCA868AF@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: At 02:34 PM 7/23/99 -0400, David Chen wrote: >I thought we like the public key as "public" as possible. (so that to >prevent attack) >How can someone want a "secret" for "public" key ? >If it is secret, then it is private. >Don't you agree? To see the definition of "secret public keys" in this thread, read David Kemp's original message as forwarded by Stephen Waters. "Secret public keys" can be used in several ways, typically to protect a private key that may be otherwise vulnerable to a brute-force attack. For example, a private key may be encrypted under a weak encryption key derived from a password. When the encryption key can be brute-forced, there's a risk that someone who obtains the encrypted private key and the public key can crack the private key. The principle of a *persistent* secret public key is to distribute the public key on a "need-to-know" basis. This greatly reduces the exposure to such attack. A related concept is *ephemeral* secret public keys. These form the basis for many strong password protocols. The general idea is to choose a one-time public/private key pair, integrate them with a password in a special way, and perform a key exchange with another party. The public/private keys are then discarded. The result is that only parties with the same password will be able to negotiate a large session key, without exposing the small password to brute-force attack. For examples, you can see slides from a presentation on protocols that use both of these concepts: --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ietf-ipsra Sun Jul 25 10:19:10 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA26707 for ietf-ipsra-bks; Sun, 25 Jul 1999 10:19:10 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.rdc1.sfba.home.com (imail@ha1.rdc1.sfba.home.com [24.0.0.66]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA26703 for ; Sun, 25 Jul 1999 10:19:09 -0700 (PDT) Received: from ix.netcom.com ([24.1.105.178]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990725172046.RBKX8807.mail.rdc1.sfba.home.com@ix.netcom.com>; Sun, 25 Jul 1999 10:20:46 -0700 Message-ID: <379B46FC.EBF18577@ix.netcom.com> Date: Sun, 25 Jul 1999 10:18:52 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Jablon CC: "David P. Kemp" , Stephen.Waters@cabletron.com, ietf-ipsra@vpnc.org, kent@bbn.com Subject: Re: Secret public keys References: <3.0.5.32.19990725095333.0084c5e0@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: David Jablon wrote: > > I typically recommend using secret public keys, but of the > ephemeral kind. Methods like EKE & SPEKE can safely > retrieve the private key using a password-authenticated key exchange. > This provides a more thorough approach to eliminating > client storage of credentials. > Are these mechanisms encumbered in any way (e.g. patented)? Scott From owner-ietf-ipsra Sun Jul 25 20:59:52 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id UAA27500 for ietf-ipsra-bks; Sun, 25 Jul 1999 20:59:52 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from fulcrum (fulcrum.ie.cw.net [204.70.128.22]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id UAA27496 for ; Sun, 25 Jul 1999 20:59:50 -0700 (PDT) Received: from cletus.ie.cw.net ([204.71.41.1]) by cw.net (PMDF V5.2-31 #35957) with ESMTP id <0FFG00CI3LUFGQ@cw.net> for ietf-ipsra@vpnc.org; Mon, 26 Jul 1999 00:01:27 -0400 (EDT) Received: (from yjj@localhost) by cletus.ie.cw.net (8.8.8+Sun/8.8.8) id AAA08278; Mon, 26 Jul 1999 00:01:25 -0400 (EDT) Date: Mon, 26 Jul 1999 00:01:25 -0400 (EDT) From: "Y. John Jiang" Subject: RE: Secret public keys In-reply-to: <3.0.5.32.19990723081453.007c1530@world.std.com> To: David Jablon Cc: ietf-ipsra@vpnc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Jul 1999, David Jablon wrote: > XAUTH notwithstanding, the value of shared secret passwords > and "secret public keys" is that they allow strong one-to-one > agreements between a user and a service provider that is > easy to set up with existing tools, with a large base > of pre-existing relationships. > > Of course, shared-secrets alone, without a complementary PKI, > don't scale to solve the world's e-commerce problems with > establishing mutual trust between strangers. But this just > isn't everyone's goal. Passwords and secret-public-keys are > immensely practical and useful for securing user-to-provider > relationships, especially when the number of highly-secure > provider relationships needed by the typical user is small. > Think about protecting the one most important site in your > "single-sign-on" solutiuon. Strong authentication may often be necessary in one way in e-Commerce. When a consumer buys soemthing, it's important to authenticate the seller online. However, only the buyer's payment (credit card num) is important to the seller. John > I believe IKE should be extended to permit strong mutual > authentication based on low-entropy shared secrets. > > Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem > to do it either. > > At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote: > >David [Kemp], (your note copied below) > > > >I am trying to avoid using XAUTH, if possible. If I can get offline > >cracking protection using an IKE Phase mechanism, that's what I want. > > > >We have plans to allow RADIUS servers to provide per-user pre-shared secrets > >for IKE Phase-1 authentication, if that is what the customer wants. If the > >customer wants legacy, they are probably not going to like PKI in the > >picture, so our recommendation will be to use per-user pre-shared phase-1 > >and XAUTH for the legacy. > > > >If the customer will tolerate PKI, I would like to be able to offer it in a > >way that was comparable to the strongest legacy authentication they may be > >using today. > > > >The proposal to not load the VPN client with the public key (just private) > >COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to > >collect the appropriate public key, but the security manager would need some > >handy way to 'copy' the users' public key from the certificate (or key > >generation point) to the RADIUS management tool. Not impossible I guess. > > > >O.K., so here's a 'from ground up' Private Key Infrastructure: > > > >1) Go to RADIUS tool. Add client stephen.waters@ctron.com > >2) Push 'generate key pair' and public key is stored in association with new > >client > >3) Push 'build client file' and a file is generated with the private-key > >(password protected), appropriate VPN server public key and ID (also > >password protected), and client id to present when connecting > >(stephen.waters@ctron.com), VPN server address, other stuff on > >policy/proposals maybe. > > > >Client device is now loaded with the file. Connects to VPN server, presents > >id and engages in a signature exchange. VPN server calls to RADIUS using > >provided id to collect public key to complete Phase1. > > > >Revoking involves deleting the RADIUS entry. The VPN server keeps no cache. > > > >I think I like it :) No off-line cracking, no CRL problems, no new > >protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password > >problem, no CA. > > Here's one problem: Password-encrypted local data may be inadequate > protection for the safety of locally stored credentials. > > David Kemp wrote: > >From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > >Sent: Thursday, July 22, 1999 8:41 PM > >To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com > >Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org > >Subject: RE: Secret public keys > > [...] > >The question that began this thread was "does IKE+XAUTH have any > >value-added over IKE alone?" It's obvious that managing secrets > >is more difficult than managing public data. But I believe that > >regardless of whether you choose to use secret information on the > >server to eliminate the possibility of offline password guessing > >attacks on the client, a secondary authentication exchange is > >superfluous. Whatever the requirements are, they can be satisfied > >within IKE. > > Even if we ignore obvious out-of-scope issues that IKE was > never designed to solve, I think the last statement goes too far. > IKE can certainly be further extended or improved to better use > and protect low-entropy shared secrets. > > I have no opinion on whether IKE+XAUTH has value over IKE as-is. > I do know that XAUTH doesn't address the mutual authentication > issue in using low-entropy shared-secrets to strengthen the > key exchange. IKE could be extended to use "legacy" credentials > in a stronger way, with a password-authenticated key exchange. > This would provide another factor for mutual authentication, > and at the same time prevent yet another potential path > for disclosure of these secrets. > > I think these are worthy goals. > > -- dpj > > --------------------------------------------------- > David P. Jablon dpj@IntegritySciences.com > President +1 508 898 9024 > Integrity Sciences, Inc. www.IntegritySciences.com > > From owner-ietf-ipsra Mon Jul 26 08:17:57 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id IAA28727 for ietf-ipsra-bks; Mon, 26 Jul 1999 08:17:57 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA28723 for ; Mon, 26 Jul 1999 08:17:54 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id LAA06075 for ietf-ipsra@vpnc.org; Mon, 26 Jul 1999 11:20:12 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa06033; Mon Jul 26 11:20:02 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Mon, 26 Jul 1999 11:19:55 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Mon, 26 Jul 1999 11:22:42 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC41344@exchange> From: Stephane Beaulieu To: Valery Smyslov , ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken Date: Mon, 26 Jul 1999 11:22:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="koi8-r" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Valery, You raise a good point regarding multiple attribute payloads in the same Isakmp-Cfg message. I agree that this should be disallowed for XAUTH. This type of extensibility would probably hurt interoperability and provide no significant gain. Even though the Message ID / XAUTH id pair would be the same for transaction, I would recommend that you still keep state on the XAUTH id and not solely rely on Message ID. These two identifiers serve different purposes. As for your question about concurrent XAUTHs. The answer is no. There's only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) message. If you were to have multiple XAUTH transactions, how could you tell when it's "really" done. There are mechanisms that allow you to send 2 REQUESTs within 1 XAUTH transaction. Thanks for your input, Stephane. Valery Smyslov wrote: > So, you don't pay any attention to attribute payload Identifier field > in your processing with the same M-ID, do you? If so, then > next problem arises: > currently XAUTH draft doesn't prohibit multiple attribute > payloads in one > message (and ISAKMP-CFG explicitly allows it). If you ignore > Identifier, you > cannot link REQUEST with REPLY and SET with ACK unless the > only attribute > payload is present in every message. This restriction (only > one attribute payload > in every message) seems to make sense for XAUTH, so I'd > prefer it to be mentioned > explicitly in the draft. Even in this case we have a problem: > what to do if Identifiers in > consequent messages don't match - ignore, abort, consider as > another XAUTH > exchange? Is it ever possible to have multiple concurrent > XAUTH exchanges? > > Regards, > Valery. > > > ----- Original Message ----- > From: Tim Jenkins > To: Valery Smyslov ; > ; Joern Sierwald > > Sent: Friday, July 23, 1999 5:04 PM > Subject: RE: XAUTH is broken > > > (Damn mailer dropped my response...) > > This is in response to questions about my objection to using multiple > different configuration exchange exchanges for extended > authentications that > require more than two packets. > > When extended authentication is required, an overall state > machine that > controls the phase 1 SA has to know what the result of the extended > authentication session is. It would be advantageous to > minimize how much > that state machine needs to know about the exchange. > > If it is done over a configuration exchange using the > attribute payload > identifier (or some other value common to the whole > exchange), the state > machine has to do the following: > > 1) know that extended authentication is required > 2) check that the first packet sent is the correct exchange type > (configuration exchange) > 3) check that the attributes in the exchange are valid (right > now there are > 9 defined; it needs to know about all of them in order to > know that this an > XAUTH exchange) > 4) save the message ID from the exchange > 5) save the identifier out of the attribute payload > > Then, for the next packet that goes through: > > 1) check the packet is the correct exchange type > (configuration exchange) > 2) check that the message ID matches the previous exchange > 3) look for the XAUTH_STATUS attribute > > If the XAUTH_STATUS attribute is found, the state machine can > take action > accordingly. > > If it's not found, the state machine has to do the next set > of actions until > it is found: > > 1) check that the next packet sent is the correct exchange type > (configuration exchange) > 2) check that the identifier out of the attribute payload > matches the saved > one > 3) check that the attributes in the exchange are valid (right > now there are > 9 defined; it needs to know about all of them) > 4) save the message ID from the exchange > 5) check that the next packet is the correct exchange type > (configuration > exchange) > 6) check that the message ID matches the previous exchange > 7) look for the XAUTH_STATUS attribute > > > Compare that work to the case where the extended > authentication is done in > its own open-ended exchange type: > > 1) know that extended authentication is required > 2) check that the first packet sent is the correct exchange > type (XAUTH > exchange) > 3) save the message ID from the exchange > > Then, for the remainder of the packets that go through: > > 1) check the packet is the correct exchange type (XAUTH exchange) > 2) check that the message ID matches the previous exchange > 3) look for the XAUTH_STATUS attribute (if an even numbered > message of the > exchange) > > If the XAUTH_STATUS attribute is found, the state machine take action > accordingly. > > If it's not found, the state machine has to the next pair of > actions until > it is found: > > It's simpler, requires less knowledge of the exchange and > attribute by the > state machine. > > Both can be done; it seems that the separate exchange type is > architecturally purer. > > Tim > > > > -----Original Message----- > > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > > Sent: July 23, 1999 8:36 AM > > To: Valery Smyslov; ipsec@lists.tislabs.com; Joern Sierwald > > Subject: RE: XAUTH is broken > > > > > > > > > > -----Original Message----- > > From: Valery Smyslov [mailto:svan@trustworks.com] > > Sent: July 23, 1999 9:57 AM > > To: ipsec@lists.tislabs.com; Joern Sierwald > > Subject: RE: XAUTH is broken > > > > > > > > On 23 Jul 99 at 10:40, Joern Sierwald wrote: > > > > > At 15:53 22.7.1999 -0400, you wrote: > > > > > > >This is a rather unfair and unreasonable accusation. > > > Yes it is. It was meant to be a bit teasing, but it looks > just mean > > > if it read it today. Sorry. > > > > > > >If it turns > > > >out that the best solution is to use a new exchange > type, we would > > > >still have to change our code, and it also one of the suggestions > > > >that I already said I prefer. > > > > > > > OK, let's go this way. I would like to suggest that we > define _two_ > > > new exchanges, one for 4 packets and one for 6 packets. > > > > Number of packets depends on type of authentication. Who can > > guarantee that tomorrow another type of authentication will require, > > say, 8 packets? Shall we define new exchange again then? And so on? > > Would'n be better to define XAUTH exchange as open ended? > > > > BTW, question to Tim Jenkins. Attribute payload contains > "Identifier" > > field. Why not use it (by requiring it to be the same in all > > attribute payloads during one XAUTH exchange) for state tracking and > > let M-ID be different (e.g. perform XAUTH as series of ordinary > > ISAKMP-CFG)? > > > > > Jörn > > > > Regards, > > Valery. > > > > From owner-ietf-ipsra Mon Jul 26 08:15:13 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id IAA28717 for ietf-ipsra-bks; Mon, 26 Jul 1999 08:15:13 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA28713 for ; Mon, 26 Jul 1999 08:15:12 -0700 (PDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 3A9FC4CE41; Mon, 26 Jul 1999 11:17:28 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id LAA02828; Mon, 26 Jul 1999 11:17:26 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 9AC5441F16; Mon, 26 Jul 1999 11:17:26 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 8BC86400B4; Mon, 26 Jul 1999 11:17:21 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: "Scott G. Kelly" Cc: David Jablon , "David P. Kemp" , Stephen.Waters@cabletron.com, ietf-ipsra@vpnc.org, kent@bbn.com Subject: Re: Secret public keys Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jul 1999 11:17:21 -0400 From: "Steven M. Bellovin" Message-Id: <19990726151726.9AC5441F16@SIGABA.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: In message <379B46FC.EBF18577@ix.netcom.com>, "Scott G. Kelly" writes: > > > David Jablon wrote: > > > > I typically recommend using secret public keys, but of the > > ephemeral kind. Methods like EKE & SPEKE can safely > > retrieve the private key using a password-authenticated key exchange. > > This provides a more thorough approach to eliminating > > client storage of credentials. > > > > Are these mechanisms encumbered in any way (e.g. patented)? EKE and its variant, AEKE, are definitely patented. The technical papers on them are at http://www.research.att.com/~smb/papers/neke.ps and http://www.research.att.com/~smb/papers/aeke.ps -- for both, there's also a corresponding .pdf file. I believe that SPEKE is patented as well. From owner-ietf-ipsra Mon Jul 26 16:17:39 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id QAA02313 for ietf-ipsra-bks; Mon, 26 Jul 1999 16:17:39 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id QAA02309 for ; Mon, 26 Jul 1999 16:17:36 -0700 (PDT) Received: from world.std.com by europe.std.com (STD1.2/BZS-8-1.0) id TAA11282; Mon, 26 Jul 1999 19:19:56 -0400 (EDT) Received: from dpj (world.std.com) by world.std.com (TheWorld/Spike-2.0) id AA22390; Mon, 26 Jul 1999 19:19:52 -0400 Message-Id: <3.0.5.32.19990726192125.0085f730@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 26 Jul 1999 19:21:25 -0400 To: "Scott G. Kelly" From: David Jablon Subject: Re: Secret public keys Cc: "David P. Kemp" , Stephen.Waters@cabletron.com, ietf-ipsra@vpnc.org, kent@bbn.com In-Reply-To: <379B46FC.EBF18577@ix.netcom.com> References: <3.0.5.32.19990725095333.0084c5e0@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:18 AM 7/25/99 -0700, Scott G. Kelly wrote: > > >David Jablon wrote: >> >> I typically recommend using secret public keys, but of the >> ephemeral kind. Methods like EKE & SPEKE can safely >> retrieve the private key using a password-authenticated key exchange. >> This provides a more thorough approach to eliminating >> client storage of credentials. > >Are these mechanisms encumbered in any way (e.g. patented)? Yes, there are patents. And no, there is no single blocking patent. It's similar to the situation with all other symmetric or public-key methods. Two basic issued patents in the field, for EKE and A-EKE, were mentioned by Steve Bellovin, a co-author of both. I also know of pending patents by Stanford University and Integrity Sciences, which should cover SRP-3 and SPEKE respectively. You should contact the authors and organizations in question for recent and complete information. Generally speaking, there are *lots* of patents one should be aware of, cryptographic and otherwise, some of which apply to specific uses of methods that many assume to be unencumbered. Vendors of cryptographic products and toolkits can provide assurance that the methods they support are fully licensed. When you develop it yourself, from spec or standard, or use a freeware solution, you may have to carry more of the burden of research and licensing. Patents are just one of the facts of life in hi-tech, and an area where one must always balance the costs with the opportunities. --------------------------------------------------- David P. Jablon dpj@IntegritySciences.com President +1 508 898 9024 Integrity Sciences, Inc. www.IntegritySciences.com From owner-ietf-ipsra Mon Jul 26 23:33:26 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id XAA05604 for ietf-ipsra-bks; Mon, 26 Jul 1999 23:33:26 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from relay1.trustworks.com (zuka.trustworks.com [194.190.192.147]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id XAA05599 for ; Mon, 26 Jul 1999 23:33:22 -0700 (PDT) Received: by relay1.trustworks.com (8.8.5/1.4) id KAA07497; Tue, 27 Jul 1999 10:35:30 +0400 (MSD) Message-Id: <199907270635.KAA07497@relay1.trustworks.com> Received: from svan-pc(194.190.192.51) by zuka via smap (V2.0) id xma007469; Tue, 27 Jul 99 10:34:38 +0400 Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: Stephane Beaulieu Date: Tue, 27 Jul 1999 10:34:47 +4 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: XAUTH is broken CC: ipsec@lists.tislabs.com, ipsra In-reply-to: <319A1C5F94C8D11192DE00805FBBADDFC41344@exchange> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: On 26 Jul 99 at 11:22, Stephane Beaulieu wrote: Hi, Stephane > Valery, > > You raise a good point regarding multiple attribute payloads in the same > Isakmp-Cfg message. I agree that this should be disallowed for XAUTH. This > type of extensibility would probably hurt interoperability and provide no > significant gain. > > Even though the Message ID / XAUTH id pair would be the same for > transaction, I would recommend that you still keep state on the XAUTH id and > not solely rely on Message ID. These two identifiers serve different > purposes. I agree. I asked this question because Tim's algorithm seems to ignore Attribute payload id. But the usage of Attribute payload id in XAUTH is still unclear. Should it be the same for all attribute payloads within one XAUTH exchange or should it be changed with every REQUEST/REPLY SET/ACK pair (as ISAKMP-CFG requires)? The former seems to simplify processing a bit while the latter more strictly follows ISAKMP-CFG draft (is it really needed if we define XAUTH as new exchange?). > As for your question about concurrent XAUTHs. The answer is no. There's > only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) > message. If you were to have multiple XAUTH transactions, how could you > tell when it's "really" done. There are mechanisms that allow you to send 2 > REQUESTs within 1 XAUTH transaction. You may initiate several XAUTH exchanges (with different M-ID, of course) simultaneously. In this case each transaction will be identified by M-ID and will be ended when SET(STATUS) will appear in corresponding XAUTH exchange. So, it seems that the reason you mentioned is not a real problem here. Have I missed something? > Thanks for your input, > Stephane. Regards, Valery. From owner-ietf-ipsra Tue Jul 27 06:17:56 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id GAA15667 for ietf-ipsra-bks; Tue, 27 Jul 1999 06:17:56 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA15663 for ; Tue, 27 Jul 1999 06:17:54 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id JAA06496 for ietf-ipsra@vpnc.org; Tue, 27 Jul 1999 09:20:17 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa06484; Tue Jul 27 09:20:13 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Tue, 27 Jul 1999 09:19:27 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 27 Jul 1999 09:22:11 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6E7D0@exchange> From: Tim Jenkins To: Valery Smyslov , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken Date: Tue, 27 Jul 1999 09:22:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > > -----Original Message----- > From: Valery Smyslov [mailto:svan@trustworks.com] > Sent: July 27, 1999 6:35 AM > To: Stephane Beaulieu > Cc: ipsec@lists.tislabs.com; ipsra > Subject: RE: XAUTH is broken > > > On 26 Jul 99 at 11:22, Stephane Beaulieu wrote: > Hi, Stephane > > Valery, > > > > You raise a good point regarding multiple attribute payloads in the same > > Isakmp-Cfg message. I agree that this should be disallowed for XAUTH. This > > type of extensibility would probably hurt interoperability and provide no > > significant gain. > > > > Even though the Message ID / XAUTH id pair would be the same for > > transaction, I would recommend that you still keep state on the XAUTH id and > > not solely rely on Message ID. These two identifiers serve different > > purposes. > I agree. I asked this question because Tim's algorithm seems to > ignore Attribute payload id. My "algorithm" was a quick-and-dirty illustration of the differences required between the two. It is not and should not be treated as gospel. What I illustrated was potentially the minimum you might need to do in order to show why I personally preferred the new exchange number route. > But the usage of Attribute payload id in XAUTH is still unclear. > Should it be the same for all attribute payloads within one XAUTH > exchange or should it be changed with every REQUEST/REPLY SET/ACK > pair (as ISAKMP-CFG requires)? The former seems to simplify > processing a bit while the latter more strictly follows ISAKMP-CFG > draft (is it really needed if we define XAUTH as new exchange?). If we use a new exchange type, then that can be defined independently of configuration exchange, while keeping the format of the attribute payload. I think your first suggestion (keep it across the entire exchange) is the correct one. > > As for your question about concurrent XAUTHs. The answer is no. There's > > only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) > > message. If you were to have multiple XAUTH transactions, how could you > > tell when it's "really" done. There are mechanisms that allow you to send 2 > > REQUESTs within 1 XAUTH transaction. > You may initiate several XAUTH exchanges (with different M-ID, of > course) simultaneously. In this case each transaction will be > identified by M-ID and will be ended when SET(STATUS) will appear > in corresponding XAUTH exchange. > So, it seems that the reason you mentioned is not a real problem > here. Have I missed something? Stephane's point was that you need a way to indicate to a higher level state machine that the phase 1 SA is fully authenticated and that it can be used for other things, such as quick modes. If you have multiple independent XAUTH exchanges, what does it mean with respect to fully authenticating the phase 1? Unless there's a really good reason to allow this, for the sake of interoperability, I would suggest we don't allow concurrent XAUTHS. (I suppose one could conceive of using dual bi-directional XAUTH, but I really don't think we want to go there right now.) Tim From owner-ietf-ipsra Tue Jul 27 06:20:53 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id GAA15678 for ietf-ipsra-bks; Tue, 27 Jul 1999 06:20:53 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA15674 for ; Tue, 27 Jul 1999 06:20:51 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id JAA07312 for ietf-ipsra@vpnc.org; Tue, 27 Jul 1999 09:23:14 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa07280; Tue Jul 27 09:23:03 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Tue, 27 Jul 1999 09:22:17 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 27 Jul 1999 09:25:01 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6E7D7@exchange> From: Stephane Beaulieu To: Valery Smyslov , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken Date: Tue, 27 Jul 1999 09:25:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Valery Smyslov wrote: > But the usage of Attribute payload id in XAUTH is still unclear. > Should it be the same for all attribute payloads within one XAUTH > exchange or should it be changed with every REQUEST/REPLY SET/ACK > pair (as ISAKMP-CFG requires)? The former seems to simplify > processing a bit while the latter more strictly follows ISAKMP-CFG > draft (is it really needed if we define XAUTH as new exchange?). The Attribute payload id should be identical for all messages in the XAUTH exchange. > > > As for your question about concurrent XAUTHs. The answer > is no. There's > > only one way end an XAUTH for a user and that's to send an > SET(STATUS(OK)) > > message. If you were to have multiple XAUTH transactions, > how could you > > tell when it's "really" done. There are mechanisms that > allow you to send 2 > > REQUESTs within 1 XAUTH transaction. > > You may initiate several XAUTH exchanges (with different M-ID, of > course) simultaneously. In this case each transaction will be > identified by M-ID and will be ended when SET(STATUS) will appear > in corresponding XAUTH exchange. > > So, it seems that the reason you mentioned is not a real problem > here. Have I missed something? I don't understand why you would need multiple XAUTH exchanges for 1 User. Is this a requirement for anyone? If so, why? If this is a requirement, then when would the Remote Client be allowed to initiate Quick Modes? after the first successful XAUTH, or only once they're all complete? I would really like to limit the number of XAUTH transactions to 1. You can still do two different authentication schemes in 1 transaction. Remote Edge ------- ----- <-- REQUEST(RADIUS) REPLY (RADIUS) --> <-- REQUEST(OTP) REPLY(OTP) --> <-- SET(OK) ACK --> QUICK MODE --> It make the state machine simpler. As soon as you receive STATUS=OK, start doing your QMs. From owner-ietf-ipsra Wed Jul 28 09:24:42 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id JAA19806 for ietf-ipsra-bks; Wed, 28 Jul 1999 09:24:42 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA19802 for ; Wed, 28 Jul 1999 09:24:37 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRRB24; Wed, 28 Jul 1999 09:27:26 -0700 Message-ID: <379F2F41.9CE2E65C@redcreek.com> Date: Wed, 28 Jul 1999 09:26:41 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, "Beaulieu, Stephane" , "Pereira, Roy" , Tamir Zegman Subject: xauth requirements: vulnerabilities References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry to keep hammering on this, but we need to make sure we've fully specified the requirements before we can reasonably discuss the efficacy of the proposed solution. I invite the various xauth and xauth/hybrid authors to contribute to this discussion, since you are the ones proposing solutions. So far, the following vulnerabilities have been identified in scenarios entailing using ipsec for remote access: (1) A system containing either a password (preshared key) or private key may be stolen, and the thief may now use the system to impersonate the owner, and access protected resources. (2) A system containing either a password (preshared key) or private key may be otherwise compromised in such a way as to give the attacker access to the password or private key, without the owners knowledge. This means that either a backup containing the information is stolen/copied, a copy of the system is somehow made without the owners knowledge, or the keys are somehow directly extracted. This information could be used to access protected resources directly, or to mount a man-in-the-middle attack on subsquent remote access sessions. (3) Rogue software may be installed on the system without the owners knowledge which monitors the user's typing and/or other aspects of any online session. Are there other vulnerabilities? Scott From owner-ietf-ipsra Wed Jul 28 10:25:18 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id KAA19912 for ietf-ipsra-bks; Wed, 28 Jul 1999 10:25:18 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA19908 for ; Wed, 28 Jul 1999 10:25:16 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id NAA15175 for ietf-ipsra@vpnc.org; Wed, 28 Jul 1999 13:27:44 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa15154; Wed Jul 28 13:27:40 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Wed, 28 Jul 1999 13:27:39 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Wed, 28 Jul 1999 13:30:21 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6ED60@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Stephane Beaulieu , Roy Pereira , Tamir Zegman Subject: RE: xauth requirements: vulnerabilities Date: Wed, 28 Jul 1999 13:30:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Scott, XAUTH was never intended to solve the vulnerabilities which you have enumerated. I will attempt to clarify it's intent. The purpose of XAUTH is to give a migration path to those people who have huge infrastructures that rely on RADIUS and other authentication mechanisms to do their day-to-day business. These people would like to start using IPSec, but can't (and won't) substitute their entire RADIUS infrastructure overnight. Some will deploy a PKI and still use some of the RADIUS tools to do their accounting, logging, and even authentication. Some will simply use a shared secret along with XAUTH for authentication only. To these people we must say "Be extremely careful not to bypass IKE's security by choosing a weak shared secret". And I can assure you, this will be in our documentation probably in bold and underlined three times. So I would say that the requirements are not what you have listed below but rather: "Provide the customer with a mechanism which will allow the use of legacy authentication schemes in conjunction with IPSec, while not diminishing the security of IPSec itself." Some have argued that XAUTH does diminish the security of IPSec by giving security administrators a false sense of security, and allowing them to choose a weak shared secret (which they could do with or without XAUTH). To prevent this, an implementation could easily restrict the network admin from using a "global" shared secret. You could also force them to use "good" shared secrets with FIPS 112. You could even go as far as forcing them to change their shared secret every day... although I'm sure you'd hear about it. I don't want people to think that what we're trying to solve is what you've listed below, although they are problems which I'm sure is of interest to everyone on this list. Regards, Stephane. > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Wednesday, July 28, 1999 12:27 PM > To: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Beaulieu, Stephane; > Pereira, Roy; Tamir Zegman > Subject: xauth requirements: vulnerabilities > > > Sorry to keep hammering on this, but we need to make sure we've fully > specified the requirements before we can reasonably discuss > the efficacy > of the proposed solution. I invite the various xauth and xauth/hybrid > authors to contribute to this discussion, since you are the ones > proposing solutions. > > So far, the following vulnerabilities have been identified in > scenarios > entailing using ipsec for remote access: > > (1) A system containing either a password (preshared key) or > private key > may be stolen, and the thief may now use the system to impersonate the > owner, and access protected resources. > > (2) A system containing either a password (preshared key) or > private key > may be otherwise compromised in such a way as to give the attacker > access to the password or private key, without the owners knowledge. > This means that either a backup containing the information is > stolen/copied, a copy of the system is somehow made without the owners > knowledge, or the keys are somehow directly extracted. This > information > could be used to access protected resources directly, or to mount a > man-in-the-middle attack on subsquent remote access sessions. > > (3) Rogue software may be installed on the system without the owners > knowledge which monitors the user's typing and/or other aspects of any > online session. > > Are there other vulnerabilities? > > Scott > From owner-ietf-ipsra Wed Jul 28 11:59:56 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id LAA20135 for ietf-ipsra-bks; Wed, 28 Jul 1999 11:59:56 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from potassium.network-alchemy.com (Potassium.Network-Alchemy.COM [199.46.17.146]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA20131 for ; Wed, 28 Jul 1999 11:59:54 -0700 (PDT) Received: from sodium.network-alchemy.com (localhost.Network-Alchemy.COM [127.0.0.1]) by potassium.network-alchemy.com (8.8.7/8.8.8) with ESMTP id MAA10726; Wed, 28 Jul 1999 12:02:07 -0700 (PDT) (envelope-from dharkins@network-alchemy.com) Message-Id: <199907281902.MAA10726@potassium.network-alchemy.com> To: Stephane Beaulieu cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities In-reply-to: Your message of "Wed, 28 Jul 1999 13:30:18 EDT." <319A1C5F94C8D11192DE00805FBBADDFC6ED60@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10723.933188526.1@network-alchemy.com> Date: Wed, 28 Jul 1999 12:02:07 -0700 From: Dan Harkins Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Stephane, Your description of XAUTH is very disingenous. Since the whole point of someone using XAUTH is because they do not want to deploy a PKI let's dismiss forever the notion that the IKE SA can be authenticated with a certificate and the two parties can proceed to XAUTH. You even admit this. It's for people who "can't (and won't) deploy a PKI". So that means you're stuck with pre-shared keys to authenticate the IKE SA. You can say in the largest font possible and underlined as much as you want, "Be extremely careful not to bypass IKE's security by choosing a weak shared secret" but the very use of this pre-shared key will make it weak! There is a fundamental limit in IKE that to use pre-shared keys (with Main Mode) means that the pre-shared key is bound to an IP address. Since you cannot know the IP address of these remote clients a priori you MUST use a shared group secret. That is by definition weak. FIPS 112 deals with passwords that are personal. You cannot use a FIPS 112 password in this environment. You also cannot go around changing the password every day because you'd orphan all the people out on the road (unless you somehow announced to all what the new "secret" was so they could update their laptops but the problem with that is, I hope, obvious). I don't know how you can say such things as "an implementation could easily restrict the network admin from using a 'global' shared secret" when you know that that is impossible. If a requirement of XAUTH is to provide legacy authentication without "diminishing the security of IPSec itself" please tell me how you intend to do this? The real problem I see with XAUTH is that it promotes and encourages and legitimizes an insecure use of IKE and IPSec. Dan. On Wed, 28 Jul 1999 13:30:18 EDT you wrote > Hi Scott, > > XAUTH was never intended to solve the vulnerabilities which you have > enumerated. I will attempt to clarify it's intent. > > The purpose of XAUTH is to give a migration path to those people who have > huge infrastructures that rely on RADIUS and other authentication mechanisms > to do their day-to-day business. These people would like to start using > IPSec, but can't (and won't) substitute their entire RADIUS infrastructure > overnight. Some will deploy a PKI and still use some of the RADIUS tools to > do their accounting, logging, and even authentication. Some will simply use > a shared secret along with XAUTH for authentication only. To these people > we must say "Be extremely careful not to bypass IKE's security by choosing a > weak shared secret". And I can assure you, this will be in our > documentation probably in bold and underlined three times. > > So I would say that the requirements are not what you have listed below but > rather: > "Provide the customer with a mechanism which will allow the use of legacy > authentication schemes in conjunction with IPSec, while not diminishing the > security of IPSec itself." > > Some have argued that XAUTH does diminish the security of IPSec by giving > security administrators a false sense of security, and allowing them to > choose a weak shared secret (which they could do with or without XAUTH). To > prevent this, an implementation could easily restrict the network admin from > using a "global" shared secret. You could also force them to use "good" > shared secrets with FIPS 112. You could even go as far as forcing them to > change their shared secret every day... although I'm sure you'd hear about > it. > > I don't want people to think that what we're trying to solve is what you've > listed below, although they are problems which I'm sure is of interest to > everyone on this list. From owner-ietf-ipsra Wed Jul 28 13:42:22 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id NAA20358 for ietf-ipsra-bks; Wed, 28 Jul 1999 13:42:22 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ennovatenetworks.com (ennovatenetworks.com [208.227.99.254]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA20354 for ; Wed, 28 Jul 1999 13:42:21 -0700 (PDT) Received: from ennovatenetworks.com (blues.ennovatenetworks.com [208.227.99.137]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id QAA26785; Wed, 28 Jul 1999 16:43:39 -0400 (EDT) (envelope-from dfox@ennovatenetworks.com) Message-ID: <379F6B7B.8B015EDB@ennovatenetworks.com> Date: Wed, 28 Jul 1999 16:43:39 -0400 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu , "Scott G. Kelly" , ipsec@lists.tislabs.com CC: ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities References: <319A1C5F94C8D11192DE00805FBBADDFC6ED60@exchange> Content-Type: multipart/mixed; boundary="------------F0AD7ACCE4F8FF453B4D2EFE" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. --------------F0AD7ACCE4F8FF453B4D2EFE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephane and the rest, Hello. I am an implementor trying to decide whether or not I need to support RADIUS Authentication in IKE via XAUTH. I have been reading this entire thread (and sub-threads, and ancillary threads) with great interest. Marketing tells me that I need to support XAUTH, particularly with SecureID, and so I might have to implement it anyway, but standardization should have higher bar. I personally don't see how supporting XAUTH/RADIUS provides an easy migration path when I still have to specify an entropy-filled shared secret for each user. How is this less work than just specifying that entropy-filled shared secret once? If, however, the argument is made that supporting XAUTH/RADIUS *and* the entropy-filled shared secret is more secure, then I can understand. And I think that's what Scott is trying to do. But as much as I'd like to, I just can't see the "migration path" argument, unless you use a global shared secret for phase 1. If we're migrating to PKI, and XAUTH is not more secure than pre-shared secrets, then the proper migration path is to use pre-shared secrets and gradually phase in PKI. Why add the extra infrastructure of XAUTH if it doesn't buy you anything? I think we need to really start a discussion on our requirements, and I think Scott has started us down that path. Stephane Beaulieu wrote: > Hi Scott, > > XAUTH was never intended to solve the vulnerabilities which you have > enumerated. I will attempt to clarify it's intent. > > The purpose of XAUTH is to give a migration path to those people who have > huge infrastructures that rely on RADIUS and other authentication mechanisms > to do their day-to-day business. These people would like to start using > IPSec, but can't (and won't) substitute their entire RADIUS infrastructure > overnight. Some will deploy a PKI and still use some of the RADIUS tools to > do their accounting, logging, and even authentication. Some will simply use > a shared secret along with XAUTH for authentication only. To these people > we must say "Be extremely careful not to bypass IKE's security by choosing a > weak shared secret". And I can assure you, this will be in our > documentation probably in bold and underlined three times. > > So I would say that the requirements are not what you have listed below but > rather: > "Provide the customer with a mechanism which will allow the use of legacy > authentication schemes in conjunction with IPSec, while not diminishing the > security of IPSec itself." > > Some have argued that XAUTH does diminish the security of IPSec by giving > security administrators a false sense of security, and allowing them to > choose a weak shared secret (which they could do with or without XAUTH). To > prevent this, an implementation could easily restrict the network admin from > using a "global" shared secret. You could also force them to use "good" > shared secrets with FIPS 112. You could even go as far as forcing them to > change their shared secret every day... although I'm sure you'd hear about > it. > > I don't want people to think that what we're trying to solve is what you've > listed below, although they are problems which I'm sure is of interest to > everyone on this list. > > Regards, > Stephane. > > > -----Original Message----- > > From: Scott G. Kelly [mailto:skelly@redcreek.com] > > Sent: Wednesday, July 28, 1999 12:27 PM > > To: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org; Beaulieu, Stephane; > > Pereira, Roy; Tamir Zegman > > Subject: xauth requirements: vulnerabilities > > > > > > Sorry to keep hammering on this, but we need to make sure we've fully > > specified the requirements before we can reasonably discuss > > the efficacy > > of the proposed solution. I invite the various xauth and xauth/hybrid > > authors to contribute to this discussion, since you are the ones > > proposing solutions. > > > > So far, the following vulnerabilities have been identified in > > scenarios > > entailing using ipsec for remote access: > > > > (1) A system containing either a password (preshared key) or > > private key > > may be stolen, and the thief may now use the system to impersonate the > > owner, and access protected resources. > > > > (2) A system containing either a password (preshared key) or > > private key > > may be otherwise compromised in such a way as to give the attacker > > access to the password or private key, without the owners knowledge. > > This means that either a backup containing the information is > > stolen/copied, a copy of the system is somehow made without the owners > > knowledge, or the keys are somehow directly extracted. This > > information > > could be used to access protected resources directly, or to mount a > > man-in-the-middle attack on subsquent remote access sessions. > > > > (3) Rogue software may be installed on the system without the owners > > knowledge which monitors the user's typing and/or other aspects of any > > online session. > > > > Are there other vulnerabilities? > > > > Scott > > --------------F0AD7ACCE4F8FF453B4D2EFE Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;fax:978-263-1099 tel;work:978-263-2002 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;330 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Senior Software Engineer fn:Daniel Fox end:vcard --------------F0AD7ACCE4F8FF453B4D2EFE-- From owner-ietf-ipsra Wed Jul 28 13:46:28 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id NAA20377 for ietf-ipsra-bks; Wed, 28 Jul 1999 13:46:28 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA20373 for ; Wed, 28 Jul 1999 13:46:26 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id QAA00207 for ietf-ipsra@vpnc.org; Wed, 28 Jul 1999 16:48:56 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdBAAa00166; Wed Jul 28 16:48:53 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Wed, 28 Jul 1999 16:48:49 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Wed, 28 Jul 1999 16:51:31 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC6EE7A@exchange> From: Stephane Beaulieu To: Dan Harkins , Stephane Beaulieu Cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: RE: xauth requirements: vulnerabilities Date: Wed, 28 Jul 1999 16:51:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Dan, > You can say in the largest font possible and underlined as > much as you > want, "Be extremely careful not to bypass IKE's security by choosing a > weak shared secret" but the very use of this pre-shared key will make > it weak! There is a fundamental limit in IKE that to use pre-shared > keys (with Main Mode) means that the pre-shared key is bound to an IP > address. Since you cannot know the IP address of these remote clients > a priori you MUST use a shared group secret. That is by > definition weak. The ID doesn't need to be bound to an IP Address in Aggressive Mode or Base Mode. It could be a known unique value for each remote user. > > FIPS 112 deals with passwords that are personal. You cannot > use a FIPS 112 > password in this environment. I believe that FIPS 112 has a set of rules that one may follow to choose a "good" password. Regardless, one could restrict the the admin from using a password that is less than 10 characters in length, at least one uppercase, one lower case, one numeric, etc... You also cannot go around > changing the password > every day because you'd orphan all the people out on the road > (unless you > somehow announced to all what the new "secret" was so they > could update > their laptops but the problem with that is, I hope, obvious). Yes, I wasn't really being serious by suggesting this. > I don't know > how you can say such things as "an implementation could > easily restrict the > network admin from using a 'global' shared secret" when you > know that that > is impossible. See above comments on using an ID with Base Mode or Aggressive Mode. > > If a requirement of XAUTH is to provide legacy > authentication without > "diminishing the security of IPSec itself" please tell me how > you intend > to do this? > > The real problem I see with XAUTH is that it promotes and encourages > and legitimizes an insecure use of IKE and IPSec. > One of the problems lies in the fact that IPSec doesn't prohibit the use of "weak" shared secrets. Certainly a less security-concious person may be more inclined to use a "weak" shared secret when using XAUTH (despite my bold and triple underlined warning), but nothing prevents a less security-concious person from doing the exact same thing when XAUTH isn't there. There are methods that one could use to ensure that the shared secret be unique and strong, but IPSec doesn't mandate them. Regards, Stephane. From owner-ietf-ipsra Wed Jul 28 13:55:53 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id NAA20412 for ietf-ipsra-bks; Wed, 28 Jul 1999 13:55:53 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA20408 for ; Wed, 28 Jul 1999 13:55:51 -0700 (PDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 800CD4CE24; Wed, 28 Jul 1999 16:58:21 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id QAA12915; Wed, 28 Jul 1999 16:58:20 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 08AF341F16; Wed, 28 Jul 1999 16:58:20 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id EDCED400B4; Wed, 28 Jul 1999 16:58:14 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Stephane Beaulieu Cc: Dan Harkins , "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jul 1999 16:58:14 -0400 From: "Steven M. Bellovin" Message-Id: <19990728205820.08AF341F16@SIGABA.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: In message <319A1C5F94C8D11192DE00805FBBADDFC6EE7A@exchange>, Stephane Beaulieu writes: > > One of the problems lies in the fact that IPSec doesn't prohibit the use of > "weak" shared secrets. Certainly a less security-concious person may be > more inclined to use a "weak" shared secret when using XAUTH (despite my > bold and triple underlined warning), but nothing prevents a less > security-concious person from doing the exact same thing when XAUTH isn't > there. There are methods that one could use to ensure that the shared > secret be unique and strong, but IPSec doesn't mandate them. Or, as David Jablon has pointed out, there are strong protocols that permit downloading of strong shared secrets or private keys without exposure to offline attacks based on weak shared secrets. Yes, there are patent issues with some of them. There are also at least three different schemes proposed, which gives the IETF a fair amount of leverage. (Disclaimer: I'm the inventor of one of the encumbered schemes. But in the aftermath of the break-up of AT&T, the EKE patents went to Lucent, so I no longer have any connection with those patents. In particular, I don't benefit if they're used; on the other hand, I no longer have any influence on the licensing policies.) The Perlman and Kaufman paper in NDSS '99 shows several different ways to do what's needed here -- bootstrap from a password to a strong private key. And they use show how both EKE and SPEKE can be used. From owner-ietf-ipsra Wed Jul 28 14:27:03 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id OAA20478 for ietf-ipsra-bks; Wed, 28 Jul 1999 14:27:03 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from potassium.network-alchemy.com (Potassium.Network-Alchemy.COM [199.46.17.146]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA20474 for ; Wed, 28 Jul 1999 14:27:02 -0700 (PDT) Received: from sodium.network-alchemy.com (localhost.Network-Alchemy.COM [127.0.0.1]) by potassium.network-alchemy.com (8.8.7/8.8.8) with ESMTP id OAA11040; Wed, 28 Jul 1999 14:29:28 -0700 (PDT) (envelope-from dharkins@network-alchemy.com) Message-Id: <199907282129.OAA11040@potassium.network-alchemy.com> To: Stephane Beaulieu cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org, Roy Pereira , Tamir Zegman Subject: Re: xauth requirements: vulnerabilities In-reply-to: Your message of "Wed, 28 Jul 1999 16:51:22 EDT." <319A1C5F94C8D11192DE00805FBBADDFC6EE7A@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11037.933197367.1@network-alchemy.com> Date: Wed, 28 Jul 1999 14:29:27 -0700 From: Dan Harkins Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Stephane, On Wed, 28 Jul 1999 16:51:22 EDT you wrote > Hi Dan, > > > You can say in the largest font possible and underlined as > > much as you > > want, "Be extremely careful not to bypass IKE's security by choosing a > > weak shared secret" but the very use of this pre-shared key will make > > it weak! There is a fundamental limit in IKE that to use pre-shared > > keys (with Main Mode) means that the pre-shared key is bound to an IP > > address. Since you cannot know the IP address of these remote clients > > a priori you MUST use a shared group secret. That is by > > definition weak. > > The ID doesn't need to be bound to an IP Address in Aggressive Mode or Base > Mode. It could be a known unique value for each remote user. Pre-shared keys don't scale. But I'll concede this point. You could somehow manage a large radius database _and_ some monster database of unique, per-user pre-shared keys. Fine, but then this gets back to my original point some months back. It's either insecure or superfluous. If the pre-shared key is unique for each remote user then what's the point of doing XAUTH? It doesn't buy you anything except to give you a warm fuzzy by "using" a card to "authenticate." Proof of knowledge of the unique, per-person, pre-shared key would unambiguously authenticate the user. You can spit accounting records out the back end when the user authenticates if this is the real goal. Two factors? Possession of the laptop and knowledge of the passphrase to unlock the pre-shared key. Authenticating with a unique pre-shared key also requires another dialog box (for the passphrase to unlock the pre-shared key) and runs counter to the other customer demand of single sign-on. Since "using" the card is paramount, that's the dialog box that's given. The pre-shared key is left unlocked and since pre-shared keys scale poorly that pre-shared key is just a shared group key. Yes, it's possible to use XAUTH securely but to do so is ridiculous. Why would someone go to double the trouble to authenticate? You're not going to sell alot of boxes by saying that customers have to manage two secret databases and have to go through two dialog boxes just to log in. Since the push behind XAUTH is supposed to be customer requirements which customer has this as a requirement? "I demand twice the trouble! I won't buy anything that let's me off with just a single sign-on!" > > The real problem I see with XAUTH is that it promotes and encourages > > and legitimizes an insecure use of IKE and IPSec. > > One of the problems lies in the fact that IPSec doesn't prohibit the use of > "weak" shared secrets. Certainly a less security-concious person may be > more inclined to use a "weak" shared secret when using XAUTH (despite my > bold and triple underlined warning), but nothing prevents a less > security-concious person from doing the exact same thing when XAUTH isn't > there. There are methods that one could use to ensure that the shared > secret be unique and strong, but IPSec doesn't mandate them. This is a red herring. The issue isn't whether the pre-shared key is "weak" or "strong". It's that XAUTH is either insecure or superfluous. Since it's doubtful that people will want to go through the trouble of superfluous "authentication" (with double the work) I believe that it's the former. Dan. From owner-ietf-ipsra Thu Jul 29 05:38:59 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id FAA29760 for ietf-ipsra-bks; Thu, 29 Jul 1999 05:38:59 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id FAA29756 for ; Thu, 29 Jul 1999 05:38:55 -0700 (PDT) Received: from checkpoint.com (kaveret.checkpoint.com [199.203.71.97]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id PAA29365; Thu, 29 Jul 1999 15:46:02 +0300 (IDT) Message-ID: <37A04C92.9197AA36@checkpoint.com> Date: Thu, 29 Jul 1999 15:44:02 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: xauth requirements: vulnerabilities References: <199907281902.MAA10726@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Dan, Dan Harkins wrote: > Stephane, > > Your description of XAUTH is very disingenous. > > Since the whole point of someone using XAUTH is because they do not > want to deploy a PKI let's dismiss forever the notion that the IKE SA can > be authenticated with a certificate and the two parties can proceed to > XAUTH. You even admit this. It's for people who "can't (and won't) deploy > a PKI". So that means you're stuck with pre-shared keys to authenticate > the IKE SA. > Then why don't you use Hybrid? Yes, you need a PKI, but only a small scale PKI. From owner-ietf-ipsra Thu Jul 29 10:30:08 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id KAA00436 for ietf-ipsra-bks; Thu, 29 Jul 1999 10:30:08 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.inter.net.il [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA00432 for ; Thu, 29 Jul 1999 10:30:06 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id UAA04021; Thu, 29 Jul 1999 20:32:24 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA15811; Thu, 29 Jul 99 20:32:42 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma015807; Thu, 29 Jul 99 20:32:22 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id UAA02611; Thu, 29 Jul 1999 20:33:21 +0200 Message-Id: <37A08FCB.AFD6FF32@radguard.com> Date: Thu, 29 Jul 1999 20:30:51 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" , ipsra Subject: Re: xauth requirements: vulnerabilities References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> <379F2F41.9CE2E65C@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hello Scott! I would like to refer to the vulnerabilities you've stated here. I think that the problems you raise here are out of the scope of specific protocols that you are referring to, namely IKE, XAUTH, hybrid and I am sure I could specify many others. Even the stongest PKI and Public key cryptography used will not save you from an unprotected private key. I think we should separate the authentication mechanism (e.g. certificates, SecureID, RADIUS) from the suggested IKE extends authentication protocols. The vulnerabilities you've stated refer to the strength of authentication mechanism that is used , and to the correctness and the security of its implementation. I think that we all agree that the preferred authentication mechanism is user certificates, but we also realize that reality and the market requirements require the work of other authentication mechanism. The purpose of the suggested extend authentication protocols is to convey these authentication mechanisms into the existing IKE protocol. Let's separate the requirement from the actual authentication mechanism, and the requirement's from IKE authentication protocols. I suggest that we will enable this integration into IKE, and that we will have a set of minimal requirements from an authentication mechanism that fits into the (future) IP Secure Remote Access framework. An example requirement might be if you use two factor authentication, then store the two factors (password, smart card) in different places... I think is that we are trying to understand what XAUTH and the other protocol are solving and not solving, instead of stating what are the problems and the requirements. I think this is the wrong way to go. Thanks, Sara. "Scott G. Kelly" wrote: > Sorry to keep hammering on this, but we need to make sure we've fully > specified the requirements before we can reasonably discuss the efficacy > of the proposed solution. I invite the various xauth and xauth/hybrid > authors to contribute to this discussion, since you are the ones > proposing solutions. > > So far, the following vulnerabilities have been identified in scenarios > entailing using ipsec for remote access: > > (1) A system containing either a password (preshared key) or private key > may be stolen, and the thief may now use the system to impersonate the > owner, and access protected resources. > > (2) A system containing either a password (preshared key) or private key > may be otherwise compromised in such a way as to give the attacker > access to the password or private key, without the owners knowledge. > This means that either a backup containing the information is > stolen/copied, a copy of the system is somehow made without the owners > knowledge, or the keys are somehow directly extracted. This information > could be used to access protected resources directly, or to mount a > man-in-the-middle attack on subsquent remote access sessions. > > (3) Rogue software may be installed on the system without the owners > knowledge which monitors the user's typing and/or other aspects of any > online session. > > Are there other vulnerabilities? > > Scott From owner-ietf-ipsra Thu Jul 29 11:52:03 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id LAA00570 for ietf-ipsra-bks; Thu, 29 Jul 1999 11:52:03 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA00566 for ; Thu, 29 Jul 1999 11:52:00 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRRCTR; Thu, 29 Jul 1999 11:54:53 -0700 Message-ID: <37A0A366.441A00E7@redcreek.com> Date: Thu, 29 Jul 1999 11:54:30 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sara Bitan CC: ipsra Subject: Re: xauth requirements: vulnerabilities References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> <379F2F41.9CE2E65C@redcreek.com> <37A08FCB.AFD6FF32@radguard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Sara, Sara Bitan wrote: > > Hello Scott! > > I would like to refer to the vulnerabilities you've stated here. > > I think that the problems you raise here are out of the scope of specific > protocols > that you are referring to, namely IKE, XAUTH, hybrid and I am sure I could > specify > many others. I've been thinking about this, and believe that perhaps the thread is improperly named. I began the discussion because I believe that we need to understand the remote access problem space before we can intelligently discuss solutions, and security vulnerabilities are a part of the problem space. At the same time, I've been trying to get someone to explicitly state the rationale for xauth in terms of requirements, and I think this may be confusing people. I should have separated the two discussions. > Even the stongest PKI and Public key cryptography used will not save you > from > an unprotected private key. Yes, I agree. > I think we should separate the authentication mechanism (e.g. certificates, > SecureID, RADIUS) > from the suggested IKE extends authentication protocols. > > The vulnerabilities you've stated refer to the strength of authentication > mechanism that is used > , and to the correctness and the security of its implementation. They also refer to the motivation one might have for seeking to somehow improve upon the authentication mechanisms built into IKE, which is what I had speculated that xauth/hybrid might be meant to do. We all agree that PK authentication may be very strong, but as you pointed out, an unprotected private key invalidates this supposition. Again, the vulnerabilities are but one aspect of the set of factors from which we derive requirements. > I think that we all agree that the preferred authentication mechanism is > user certificates, but > we also realize that reality and the market requirements require the work of > other authentication > mechanism. > > The purpose of the suggested extend authentication protocols is to convey > these authentication mechanisms into the existing IKE protocol. This gets to the heart of it, I think. There seems to be a market "requirement" which has driven xauth, that being that administrators think they want security, but they also have a conflicting desire, i.e. to continue using their currently installed weak authentication mechanisms. A remote access working group has been proposed, and I would hope that the purpose of this group would be to actually examine the remote access problem in depth and propose good, solid solutions, as opposed to simply rubber-stamping the existing proposed mechanisms without further thought. > Let's separate the requirement from the actual authentication mechanism, and > > the requirement's from IKE authentication protocols. Yes, I agree that we need to derive the remote access requirements independently of any existing proposed solutions. > I suggest that we will enable this integration into IKE, and that we will > have a set > of minimal requirements from an authentication mechanism that fits into the > (future) > IP Secure Remote Access framework. An example requirement might be > if you use two factor authentication, then store the > two factors (password, smart card) in different places... > > I think is that we are trying to understand what XAUTH and the other > protocol are solving > and not solving, instead of stating what are the problems and the > requirements. > I think this is the wrong way to go. I think I agree with you, and I'll feed back what I think so you can correct me if I'm missing the point. We need to discuss the requirements for secure remote access using ipsec. It is important that we not be confused by arguing about whether existing mechanisms meet the requirements when we have yet to explicitly state them. We should first determine the requirements, and then discuss how individual mechanisms meet (or don't meet) subsets of them. Scott From owner-ietf-ipsra Fri Jul 30 00:13:10 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id AAA01320 for ietf-ipsra-bks; Fri, 30 Jul 1999 00:13:10 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.inter.net.il [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id AAA01316 for ; Fri, 30 Jul 1999 00:13:06 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id KAA27503; Fri, 30 Jul 1999 10:15:35 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA20870; Fri, 30 Jul 99 10:15:12 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma020866; Fri, 30 Jul 99 10:14:53 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id KAA19094; Fri, 30 Jul 1999 10:15:50 +0200 Message-Id: <37A1508C.CAF40F55@radguard.com> Date: Fri, 30 Jul 1999 10:13:16 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" , ipsra Cc: IPSec mailing list Subject: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> <379F2F41.9CE2E65C@redcreek.com> <37A08FCB.AFD6FF32@radguard.com> <37A0A366.441A00E7@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hello Scott! "Scott G. Kelly" wrote: > I've been thinking about this, and believe that perhaps the thread is > improperly named. Hence I've allowed myself to change the name of the thread. I think that this is the problem that we should discuss. > I began the discussion because I believe that we need > to understand the remote access problem space before we can > intelligently discuss solutions, and security vulnerabilities are a part > of the problem space. At the same time, I've been trying to get someone > to explicitly state the rationale for xauth in terms of requirements, > and I think this may be confusing people. I should have separated the > two discussions. The problem as I see it : provide IPSec with an authentication of a user with a non fixed or fixed IP address (i.e. the IP address he uses is irrelevant to the authentication process). Ofcourse security vulnerabilities are an important part of this problem, after all these are the issues we discuss in this area, but they exist in several levels. I think that the a possible architecture for a solution could be a modular architecture that consists of an authentication mechanism that provides user authentication and a protocol that conveys this information to either IPSec or IKE. This solution is different from the current IKE approach to authentication in which the authentication is an integral part of the IKE protocol. > > Even the stongest PKI and Public key cryptography used will not save you > > from > > an unprotected private key. > > Yes, I agree. In this proposed architecture, the above problem is a security vulnerability of the authentication mechanism, or to be precise, of the implementation of the authentication mechanism. > > > > I think we should separate the authentication mechanism (e.g. certificates, > > SecureID, RADIUS) > > from the suggested IKE extends authentication protocols. > > > > The vulnerabilities you've stated refer to the strength of authentication > > mechanism that is used > > , and to the correctness and the security of its implementation. > > They also refer to the motivation one might have for seeking to somehow > improve upon the authentication mechanisms built into IKE, which is what > I had speculated that xauth/hybrid might be meant to do. We all agree > that PK authentication may be very strong, but as you pointed out, an > unprotected private key invalidates this supposition. Again, the > vulnerabilities are but one aspect of the set of factors from which we > derive requirements. We are seeking to improve the authentication mechanism built into IKE. One possibility is to improve security, which is what you refer to. Another way is to improve the ability to deploy IPSec, and to increase the number of scenarios in which IPSec can be used. These two goals might be contradicting, but we as engineers must make the trade-offs and come up with a reasonable set of solutions. > > > > I think that we all agree that the preferred authentication mechanism is > > user certificates, but > > we also realize that reality and the market requirements require the work of > > other authentication > > mechanism. > > > > The purpose of the suggested extend authentication protocols is to convey > > these authentication mechanisms into the existing IKE protocol. > > This gets to the heart of it, I think. There seems to be a market > "requirement" which has driven xauth, that being that administrators > think they want security, but they also have a conflicting desire, i.e. > to continue using their currently installed weak authentication > mechanisms. A remote access working group has been proposed, and I would > hope that the purpose of this group would be to actually examine the > remote access problem in depth and propose good, solid solutions, as > opposed to simply rubber-stamping the existing proposed mechanisms > without further thought. "rubber-stamping" is one way of looking at the integration of legacy authentication into IPSec. There are others. > > Let's separate the requirement from the actual authentication mechanism, and > > > > the requirement's from IKE authentication protocols. > > Yes, I agree that we need to derive the remote access requirements > independently of any existing proposed solutions. > > > I suggest that we will enable this integration into IKE, and that we will > > have a set > > of minimal requirements from an authentication mechanism that fits into the > > (future) > > IP Secure Remote Access framework. An example requirement might be > > if you use two factor authentication, then store the > > two factors (password, smart card) in different places... > > > > I think is that we are trying to understand what XAUTH and the other > > protocol are solving > > and not solving, instead of stating what are the problems and the > > requirements. > > I think this is the wrong way to go. > > I think I agree with you, and I'll feed back what I think so you can > correct me if I'm missing the point. We need to discuss the requirements > for secure remote access using ipsec. It is important that we not be > confused by arguing about whether existing mechanisms meet the > requirements when we have yet to explicitly state them. We should first > determine the requirements, and then discuss how individual mechanisms > meet (or don't meet) subsets of them. I think we should go to the modular approach, this way we'll separate the authentication mechanism from the protocol. This way the protocol can be used to add to the security of an underlying authentication mechanism. As for the requirements from the authentication mechanisms. Here I suggest we keep in mind what Jeff has reminded us during the IPSec session in Oslo. We are an ENGINEERING task force. We already have a good, scalable and secure authentication mechanism, namely user certificates. The problem is that it is hard to deploy. I think that in this case we should try to avoid (if possible) inventing a new authentication mechanism. There is an existing wide variety of authentication mechanism, some of them (with the right protocol protecting them and relaying the authentication information to IKE/IPSec) might be appropriate for us. I think we should specify the requirements, and suggest several (preferably existing) authentication mechanism. For each mechanism we should specify the trade-off, and declare the security risks he and his organization are exposed to if he uses this mechanism. We should remember that security and engineering is all about trade-offs. Let's look at IKE as an example. We have authentication methods that use user certificates, and pre-shared secret. We all know that pre-shared secrets authentication has it security risks (in addition to the scalability problems). But if pre-shared secret authentication hadn't exist in IKE, IPSec would not have been as deployed as it is today ( I even think IPSec wasn't here today if pre-shared secret authentication hadn't exist). We had suggested a good authentication method, and a worse one. We've pointed out the trade-offs, and let the users make their choice. I think we should approach the IPSRA problem in a similar way, > > > Scott Thanks, Sara. From owner-ietf-ipsra Fri Jul 30 08:05:24 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id IAA09744 for ietf-ipsra-bks; Fri, 30 Jul 1999 08:05:24 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.vpnc.org (8.9.3/8.9.0) with SMTP id IAA09740 for ; Fri, 30 Jul 1999 08:05:23 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.vpnc.org [165.227.249.9]) with SMTP; 30 Jul 1999 15:07:23 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA22291; Fri, 30 Jul 1999 11:04:13 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <3QWX97SS>; Fri, 30 Jul 1999 11:09:44 -0400 Message-ID: From: "Linn, John" To: "'Sara Bitan'" , "Scott G. Kelly" , ipsra Cc: IPSec mailing list Subject: RE: Using Legacy Authentication for IPSRA (was : xauth requiremen ts: vulnerabilities) Date: Fri, 30 Jul 1999 11:13:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Sara wrote, excerpting: > The problem as I see it : provide IPSec with an > authentication of a user > with a non fixed or fixed IP address (i.e. the IP address he > uses is irrelevant to > > the authentication process). Ofcourse security > vulnerabilities are an important > part of this problem, after all these are the issues we > discuss in this area, but > they exist > in several levels. > I think that the a possible architecture for a solution could > be a modular > architecture > that consists of an authentication mechanism that provides > user authentication and > a protocol > that conveys this information to either IPSec or IKE. This > solution is different > from the current IKE > approach to authentication in which the authentication is an > integral part of the > IKE protocol. It seems to me that two distinct problems arise for IPSRA: authentication of an IPsec client (familiar from base IPsec) and authentication of an associated human user (arising more specifically in the IPSRA context). Both are relevant to IPSRA, carry different assumptions and constraints, and may therefore suggest different mechanisms. People are poorly suited to remembering and entering long secrets or performing exponentiation, but can perform operations with hardware tokens that are disconnected from the IPsec client system. Computers are good at remembering long secrets, but quite variable in terms of how well those secrets are protected from unintended disclosure. Whether IPsec client and human user authentication are addressed within the same mechanism or separately from one another, it seems important that both sets of concerns be satisfiable. Several general choices could arise as to what's authenticated on behalf of the remote accessor: (1) the client IPsec entity only, independent of its user: here, no user-level secrets would be involved in the IPsec-visible distributed authentication protocol(s), though they might be used locally (perhaps involving side-channel protocol transactions outside IPsec) to unlock client-level secrets for use (2) the user only, independent of the client: here, user-level secrets would be involved in performing IPsec-visible distributed authentication protocol(s), and it would not be assumed that any client-retained secrets are sufficiently fine-grained to authenticate an individual client (3) a compound principal, representing the bound combination between user and client: here, separate secrets representing both user and client would be applied within the IPsec-visible protocol(s), in such a way as to demonstrate their conjunction (4) the user and client, independently authenticated: here, independent IPsec-visible authentication transactions would be performed for both user and client, though the performance of one authentication might rely on a secure channel provided by the other Does this taxonomy help to clarify the possibilities? --jl From owner-ietf-ipsra Fri Jul 30 08:45:37 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id IAA09859 for ietf-ipsra-bks; Fri, 30 Jul 1999 08:45:37 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA09855 for ; Fri, 30 Jul 1999 08:45:31 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRRF1V; Fri, 30 Jul 1999 08:48:37 -0700 Message-ID: <37A1C94A.B34218E7@redcreek.com> Date: Fri, 30 Jul 1999 08:48:26 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sara Bitan CC: ipsra , IPSec mailing list Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: <29752A74B6C5D211A4920090273CA3DC4BBE5F@new-exc1.ctron.com> <3.0.5.32.19990723081649.00799300@world.std.com> <3798A5E7.67156CFC@redcreek.com> <379F2F41.9CE2E65C@redcreek.com> <37A08FCB.AFD6FF32@radguard.com> <37A0A366.441A00E7@redcreek.com> <37A1508C.CAF40F55@radguard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Sara, One small clarification: Sara Bitan wrote: > > > The purpose of the suggested extend authentication protocols is to convey > > > these authentication mechanisms into the existing IKE protocol. > > > > This gets to the heart of it, I think. There seems to be a market > > "requirement" which has driven xauth, that being that administrators > > think they want security, but they also have a conflicting desire, i.e. > > to continue using their currently installed weak authentication > > mechanisms. A remote access working group has been proposed, and I would > > hope that the purpose of this group would be to actually examine the > > remote access problem in depth and propose good, solid solutions, as > > opposed to simply rubber-stamping the existing proposed mechanisms > > without further thought. > > "rubber-stamping" is one way of looking at the integration of legacy > authentication > into IPSec. There are others. The rubber-stamping I was referring to is with respect to xauth. I meant to say that I don't think we should go through the motions of forming a working group just so that we can standardize xauth with no real discussion. Scott From owner-ietf-ipsra Fri Jul 30 08:56:15 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id IAA09903 for ietf-ipsra-bks; Fri, 30 Jul 1999 08:56:15 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA09899 for ; Fri, 30 Jul 1999 08:56:14 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRRFFK; Fri, 30 Jul 1999 08:59:11 -0700 Message-ID: <37A1CBC0.3E6C4439@redcreek.com> Date: Fri, 30 Jul 1999 08:58:56 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn, John" CC: "'Sara Bitan'" , ipsra , IPSec mailing list Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi John, "Linn, John" wrote: > Several general choices could arise as to what's authenticated on behalf of > the remote accessor: > > (1) the client IPsec entity only, independent of its user: here, no > user-level secrets would be involved in the IPsec-visible distributed > authentication protocol(s), though they might be used locally (perhaps > involving side-channel protocol transactions outside IPsec) to unlock > client-level secrets for use > > (2) the user only, independent of the client: here, user-level secrets would > be involved in performing IPsec-visible distributed authentication > protocol(s), and it would not be assumed that any client-retained secrets > are sufficiently fine-grained to authenticate an individual client > > (3) a compound principal, representing the bound combination between user > and client: here, separate secrets representing both user and client would > be applied within the IPsec-visible protocol(s), in such a way as to > demonstrate their conjunction > > (4) the user and client, independently authenticated: here, independent > IPsec-visible authentication transactions would be performed for both user > and client, though the performance of one authentication might rely on a > secure channel provided by the other > > Does this taxonomy help to clarify the possibilities? Yes, I think so. I was headed in this direction with the vulnerabilities thread, but I had not reached this level of resolution yet. I think this very succinctly summarizes the available authentication subjects. The only thing missing seems to be the remote security gateway (the server?). In some cases the user may want to insist that the sgw be strongly authenticated, and in others, they may not care (or have the ability). Scott From owner-ietf-ipsra Sun Aug 1 14:53:51 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id OAA23981 for ietf-ipsra-bks; Sun, 1 Aug 1999 14:53:51 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ssh.fi (ssh.fi [194.100.44.97]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA23977 for ; Sun, 1 Aug 1999 14:53:48 -0700 (PDT) Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id AAA14904; Mon, 2 Aug 1999 00:56:33 +0300 (EEST) Received: (from kivinen@localhost) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) id AAA05231; Mon, 2 Aug 1999 00:56:32 +0300 (EET DST) Date: Mon, 2 Aug 1999 00:56:32 +0300 (EET DST) Message-Id: <199908012156.AAA05231@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: Stephane Beaulieu , ipsec@lists.tislabs.com, ipsra Subject: RE: XAUTH is broken In-Reply-To: <199907270635.KAA07497@relay1.trustworks.com> References: <319A1C5F94C8D11192DE00805FBBADDFC41344@exchange> <199907270635.KAA07497@relay1.trustworks.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 13 min Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Valery Smyslov writes: > But the usage of Attribute payload id in XAUTH is still unclear. > Should it be the same for all attribute payloads within one XAUTH > exchange or should it be changed with every REQUEST/REPLY SET/ACK > pair (as ISAKMP-CFG requires)? The former seems to simplify I think it should remain same all the time. I could not find any reference from the ISAKMP-CFG saying it must be changed every time. The draft-ietf-ipsec-isakmp-mode-cfg-04.txt just says it is "An identifier used to reference a configuration transaction within the individual messages." > processing a bit while the latter more strictly follows ISAKMP-CFG > draft (is it really needed if we define XAUTH as new exchange?). I don't think it is good idea to define new XAUTH exchange. There is no need for that. We can just use multiple configuration mode exchanges using the same attribute payload id, but different message id, until we see SET(STATUS=OK) message. The state machine is quite simple, and it does not interfare any way with the configuration modes used to implement the transport system (sending/receiving those attribute payloads). I think it makes things much easier if we just use cfg-mode as transport layer, without any modifications to it, and use "upper level state machine" to drive the xauth. This same "upper level state machine" is also used to decide things like do we need to get ip-address from the server, when can we start quick mode exchange etc. > > As for your question about concurrent XAUTHs. The answer is no. There's > > only one way end an XAUTH for a user and that's to send an SET(STATUS(OK)) > > message. If you were to have multiple XAUTH transactions, how could you > > tell when it's "really" done. There are mechanisms that allow you to send 2 > > REQUESTs within 1 XAUTH transaction. If there is multiple xauth transactions going, they all should have different attribute payload id. Only reason for that I can think of is if the server does not know what client is capable of doing. I.e server might start multiple xauths and see which of those the client selects, and when any one of those is successfully finished, then the server will allow quick mode exchange for that user. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ipsra Tue Aug 3 11:49:58 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id LAA06442 for ietf-ipsra-bks; Tue, 3 Aug 1999 11:49:58 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA06438 for ; Tue, 3 Aug 1999 11:49:57 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id OAA05959 for ietf-ipsra@vpnc.org; Tue, 3 Aug 1999 14:52:53 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa05940; Tue Aug 3 14:52:48 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Tue, 3 Aug 1999 14:52:43 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 3 Aug 1999 14:55:10 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC98D95@exchange> From: Stephane Beaulieu To: ipsec , ipsra Subject: the next rev of XAUTH Date: Tue, 3 Aug 1999 14:55:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi All, Sorry to keep bringing XAUTH up, but I just want to make sure everyone is in agreement before we proceed. A few weeks ago, there was a thread going on about modifying XAUTH to make it's state machine cleaner. I asked for comments and got quite a few, both private and public. I'd like to resolve this ASAP so that vendors who are interested in doing XAUTH can test interop at the next bakeoff. I've narrowed it down to 2 proposed changes which have both received a fair amount of support, and I'd like to get input as to which we should push forward. I would really like to hear from those who have already implemented, and who plan on implementing this in the near future on which proposal they prefer. Proposal 1: Use a new Exchange ID for XAUTH, with the same Isakmp Message ID, and XAUTH identifier throughout the transaction. Pros: - Easier to make the IKE state transitions because it is easier to tell whether we're really doing XAUTH or IKE-Config (we don't have to look inside the packet to figure it out) - State machine for Isakmp Processing is simple: if it is an IKE-Config exchange it is 2 messages, if it is an XAUTH exchange it is multiples of 2, until STATUS and ACK are done, then you can clean up your states. Cons: - Will have to use a new ISAKMP Exchange ID (240?), this will cause problems for those with an implementation already out there. - Exchange ID will change once/if XAUTH becomes an RFC, this means that we'll have to switch the Exchange ID once again and use Vendor ID payloads to maintain backwards compatibility. - Code re-use isn't as easy, because XAUTH and Ike-Config would have different behaviors. Proposal 2: Use IKE-Config as a transport (as it is today) but force the use of a new Isakmp Message ID for each REQUEST/REPLY, SET/ACK pair, and keep the identifier in the Ike-Config attribute payload consistent for all the XAUTH messages. Pros: - State machine for Isakmp Processing is simple: an IKE-Config transaction is always 2 messages. - Code re-use is much easier; little code needed to write new code if you already have Ike-Config - the Isakmp Exchange ID is more likely to remain as it is today (no backwards compatibility issues in the future) - Easier transition for those who already have XAUTH implemented. Cons: - Your IKE state machine doesn't know what it is processing (Ike-Config, or XAUTH) unless it looks inside the Ike-Config message or is notified by some other handler. Again, I'd like to get this resolved in the next 2 weeks, so if you've got an opinion on this matter, speak up now. Let me know what it is that you prefer. Thanks, Stephane. Stephane Beaulieu TimeStep Corporation sbeaulieu@timestep.com http://www.timestep.com (613) 599-3610 x4709 Fax: (613) 599-3617 From owner-ietf-ipsra Tue Aug 3 12:43:51 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id MAA06540 for ietf-ipsra-bks; Tue, 3 Aug 1999 12:43:51 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA06536 for ; Tue, 3 Aug 1999 12:43:49 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id PAA17689 for ietf-ipsra@vpnc.org; Tue, 3 Aug 1999 15:46:46 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdFAAa17628; Tue Aug 3 15:46:43 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Tue, 3 Aug 1999 15:46:42 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 3 Aug 1999 15:49:09 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> From: Roy Pereira To: ietf-ipsra@vpnc.org Subject: Proposed Charter Date: Tue, 3 Aug 1999 15:49:07 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: After many months, we have a proposed charter for the IP Security Remote Access working group. The charter was based on the one presented at the first IETF BOF, but it has been altered over the months because of various discussions with various individuals. The intent of this forum is not to merely 'rubber-stamp' existing proposals, but to solve some specific issues regarding remote access via IP VPNs. A lot of work has already been done researching this problem space by some individuals, and now it is time for everyone interested in this problem space to get involved and participate so that we may have common standard mechanisms for these problems. The problem space is intentionally being kept small at first so that the major remote access issues are dealt with first. After we succeed in bring forth documents for these issues, we may decide to re-charter ourselves with new IPSec remote access issues. This working group is the result of the IPSec working group being mandated to only work on the core IPSec documents. Thus all non-core IPSec documents were splintered out into their own respective (proposed) working groups. Regardless of how some people think that we shouldn't do anything about legacy systems, we must always integrate into the existing infrastructure or our products don't sell. The problem space is real, it exists today, and we need to come to consensus quick before we have no interoperability among 'IPSec' vendors, which would hurt us all. Before we even look at the problem space and how to address it, we must come to consensus with our charter so that a real working group be put together. Thus our number one priority should be to comment on the proposed charter below and come to a consensus before the next IETF meeting. If we can accomplish that task, then by the next IETF we can have a real working group meeting and start discussing how can IPSec best address these remote access issues. IP Security Remote Access Charter ================================= Chair(s): Roy Pereira Sara Bitan Security Area Director(s): Jeffrey Schiller Marcus Leech Security Area Advisor: Jeffrey Schiller Mailing Lists: To subscribe: ietf-ipsra-request@vpnc.org In body: subscribe Archive: http://www.vpnc.org/ietf-ipsra/mail-archive/ Proposed Charter: The rapid growth of remote access and the subsequent transition from older direct-dial remote access to Internet-based remote access is making an impact on secure communications. IP Security (IPSec), as it is defined today, is missing key functionality needed to effectively support Internet-based secure remote access as well as being difficult to deploy to remote users such as road-warriors and telecommuters wishing to connect back to their corporate networks. All these groups of users share the property that their IP address is temporary and doesn't give any information about the identity of the user. Although their temporary IP address is meaningless for IPSec, they still require to become a part of a virtual private network, and to have access to resources that are part of the private network. IPSec is quite functional and provides for a very robust base of security specifications, thus any new functionality would have to be added to the existing specifications as add-ons and not disrupt existing implementations. To address these individual problems the IPSRA Working Group will: 1) Specify an extensible mechanism for bootstrapping remote IPSec users for address management in the critical time before the intended phase 2 negotiation starts and requires these addresses. Address assignment from within the private network is needed to fulfill the requirement that remote users be able to access the resources of that private network. 2) Specify an extensible mechanism to extend IPSec to support legacy user authentication methods but still maintain its current security. While the current authentication mechanisms within IKE are very appropriate and very secure, PKI's are not yet widely deployed and there is a huge installation base of legacy remote access authentication servers, such as RADIUS and ACE/SecurID to name just a few, that aren't currently supported within IKE. 3) Research any enhancements to the IKE exchanges to better support remote users. Since this working group is focusing on IP Security, all of its goals have the underlying goal of being security conscious. The outputs of this working group should include: 1) An IPSec Remote Access framework document specifying the requirements from secure remote access. This document should identify all the entities participating in the secure remote access, and define the secure remote access architecture. 2) Standards that fulfill the requirements outlined in this charter. The proposed work items for this group would yield standards that are compatible with the existing IPSec architecture [RFC 2401] and IKE, complementing the standards work achieved by the IPSec Working Group. This work might be derived from, but not limited to, all or some of the following documents: draft-ietf-ipsec-ike-base-mode draft-ietf-ipsec-isakmp-hybrid-auth draft-ietf-ipsec-isakmp-mode-cfg draft-ietf-ipsec-iskamp-xauth draft-ietf-ipsec-dhcp draft-gupta-ipsec-remote-access-02.txt From owner-ietf-ipsra Wed Aug 4 08:08:26 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id IAA16170 for ietf-ipsra-bks; Wed, 4 Aug 1999 08:08:26 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.inter.net.il [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA16166 for ; Wed, 4 Aug 1999 08:08:22 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id SAA17424; Wed, 4 Aug 1999 18:10:26 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA05729; Wed, 4 Aug 99 18:10:36 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma005724; Wed, 4 Aug 99 18:10:33 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id SAA02316; Wed, 4 Aug 1999 18:11:37 +0200 Message-Id: <37A85787.C3BC7B88@radguard.com> Date: Wed, 04 Aug 1999 18:08:56 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: Stephen Kent Cc: IPSec mailing list , ipsra Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Steve, Stephen Kent wrote: > John, > > Your taxonomy is a nice one, but I think another way to view this issue is > to remember that the primary reason for authentication in IPsec is as input > to an iddentity-based access control decision that is enforced by the IPsec > receiver. RFC 2401 defines a set of ID forms for use in the SPD, and they > define the types of principles to which access is granted. This includes > both devices (based on IP address or DNS name or DN) and people (based on > RFC822 name or DN). [Often there is an assumption that if one > authenticates an end system, and it is a single user end system, then there > is a one-to-one mapping to a specific user, even if that mapping is not > expressed in the SPD by the choice of name form.] When an IPSec implementation is examining an IP packet against the SPD it has no clue which DNS name or DN name matches the IP addresses in the header. I think that the purpose of the authentication process is to bind a DN or DNS name to an IP address so that matching of a packet against the SPD is possible. > IPsec does not support > authentication of a compound principle, or of a user and a system > independently. It would not sense to do so unless there was a > corresponding SPD entry type for compound principles. I don't think IPSec needs to support compound principles. I do think that we need to define requirements from the authentication process that binds between the DN and the IP address. I think this should be an IPSec extension, and part of the IPSRA work. In this context I think this taxonomy is helpful. > > > Steve > > P.S. I avoid using the term "client" with IPsec as the protocols do not > have clients and servers. We have end systems and security gateways. Sara. From owner-ietf-ipsra Wed Aug 4 08:58:39 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id IAA16269 for ietf-ipsra-bks; Wed, 4 Aug 1999 08:58:39 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA16265 for ; Wed, 4 Aug 1999 08:58:38 -0700 (PDT) Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA10373; Wed, 4 Aug 1999 09:01:29 -0700 (PDT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 4 Aug 1999 09:01:28 -0700 Message-ID: <01C843625423D211AC3F00A0C969E89002CC82D1@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: "'Roy Pereira'" , ietf-ipsra@vpnc.org Subject: RE: Proposed Charter Date: Wed, 4 Aug 1999 09:01:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: There are other issues that probably need to be standardized sooner rather than later. For example: 1. Secondary VPN gateway FQDN / IP address One major issue for VPN gateway vendors is scalability as number of users grow, even more so as broadband connectivity gets deployed. It will be useful to indicate in-band the location of a backup gateway or gateways, if a primary gateway is unable to accept a new remote access VPN connection. 2. Reachable subnets (routes) These could be returned along with the tunnel (inner) IP address. It is desirable for VPN clients to manage simultaneous connectivity within and outside the tunnel. Remote access customers would like for example to access their personal ISP accounts or other web sites without being forced to go through the corporate tunnel and the corporate proxy where transactions may be logged. If reachable subnets/hosts are returned to remote access clients, the client software can manage routing data appropriately to support this requirement. 3. Link-state detection / keep alives Early detection of no link activity from a VPN client will enable a gateway to clean-up resources allocated to that client. 4. VPN gateway initiated VPN teardown It is desirable in some cases to initiate a VPN session teardown from the gateway. In this case, it will be nice if the process is handled gracefully, so that the user can be notified sufficiently in advance. Can these be included in the proposed charter as well. -Prakash Iyer Intel Architecture Labs -----Original Message----- From: Roy Pereira [mailto:rpereira@TimeStep.com] Sent: Tuesday, August 03, 1999 12:49 PM To: ietf-ipsra@vpnc.org Subject: Proposed Charter Importance: High After many months, we have a proposed charter for the IP Security Remote Access working group. The charter was based on the one presented at the first IETF BOF, but it has been altered over the months because of various discussions with various individuals. The intent of this forum is not to merely 'rubber-stamp' existing proposals, but to solve some specific issues regarding remote access via IP VPNs. A lot of work has already been done researching this problem space by some individuals, and now it is time for everyone interested in this problem space to get involved and participate so that we may have common standard mechanisms for these problems. The problem space is intentionally being kept small at first so that the major remote access issues are dealt with first. After we succeed in bring forth documents for these issues, we may decide to re-charter ourselves with new IPSec remote access issues. This working group is the result of the IPSec working group being mandated to only work on the core IPSec documents. Thus all non-core IPSec documents were splintered out into their own respective (proposed) working groups. Regardless of how some people think that we shouldn't do anything about legacy systems, we must always integrate into the existing infrastructure or our products don't sell. The problem space is real, it exists today, and we need to come to consensus quick before we have no interoperability among 'IPSec' vendors, which would hurt us all. Before we even look at the problem space and how to address it, we must come to consensus with our charter so that a real working group be put together. Thus our number one priority should be to comment on the proposed charter below and come to a consensus before the next IETF meeting. If we can accomplish that task, then by the next IETF we can have a real working group meeting and start discussing how can IPSec best address these remote access issues. IP Security Remote Access Charter ================================= Chair(s): Roy Pereira Sara Bitan Security Area Director(s): Jeffrey Schiller Marcus Leech Security Area Advisor: Jeffrey Schiller Mailing Lists: To subscribe: ietf-ipsra-request@vpnc.org In body: subscribe Archive: http://www.vpnc.org/ietf-ipsra/mail-archive/ Proposed Charter: The rapid growth of remote access and the subsequent transition from older direct-dial remote access to Internet-based remote access is making an impact on secure communications. IP Security (IPSec), as it is defined today, is missing key functionality needed to effectively support Internet-based secure remote access as well as being difficult to deploy to remote users such as road-warriors and telecommuters wishing to connect back to their corporate networks. All these groups of users share the property that their IP address is temporary and doesn't give any information about the identity of the user. Although their temporary IP address is meaningless for IPSec, they still require to become a part of a virtual private network, and to have access to resources that are part of the private network. IPSec is quite functional and provides for a very robust base of security specifications, thus any new functionality would have to be added to the existing specifications as add-ons and not disrupt existing implementations. To address these individual problems the IPSRA Working Group will: 1) Specify an extensible mechanism for bootstrapping remote IPSec users for address management in the critical time before the intended phase 2 negotiation starts and requires these addresses. Address assignment from within the private network is needed to fulfill the requirement that remote users be able to access the resources of that private network. 2) Specify an extensible mechanism to extend IPSec to support legacy user authentication methods but still maintain its current security. While the current authentication mechanisms within IKE are very appropriate and very secure, PKI's are not yet widely deployed and there is a huge installation base of legacy remote access authentication servers, such as RADIUS and ACE/SecurID to name just a few, that aren't currently supported within IKE. 3) Research any enhancements to the IKE exchanges to better support remote users. Since this working group is focusing on IP Security, all of its goals have the underlying goal of being security conscious. The outputs of this working group should include: 1) An IPSec Remote Access framework document specifying the requirements from secure remote access. This document should identify all the entities participating in the secure remote access, and define the secure remote access architecture. 2) Standards that fulfill the requirements outlined in this charter. The proposed work items for this group would yield standards that are compatible with the existing IPSec architecture [RFC 2401] and IKE, complementing the standards work achieved by the IPSec Working Group. This work might be derived from, but not limited to, all or some of the following documents: draft-ietf-ipsec-ike-base-mode draft-ietf-ipsec-isakmp-hybrid-auth draft-ietf-ipsec-isakmp-mode-cfg draft-ietf-ipsec-iskamp-xauth draft-ietf-ipsec-dhcp draft-gupta-ipsec-remote-access-02.txt From owner-ietf-ipsra Wed Aug 4 09:33:52 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id JAA16387 for ietf-ipsra-bks; Wed, 4 Aug 1999 09:33:52 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA16383 for ; Wed, 4 Aug 1999 09:33:51 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRRJDG; Wed, 4 Aug 1999 09:37:14 -0700 Message-ID: <37A86C23.5B3089A0@redcreek.com> Date: Wed, 04 Aug 1999 09:36:51 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Roy Pereira CC: ietf-ipsra@vpnc.org Subject: Re: Proposed Charter References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: I have some comments on the proposed charter. Near the bottom of the charter is the following language: > The outputs of this working group should include: > > 1) An IPSec Remote Access framework document specifying the > requirements from secure remote access. This document should identify all > the entities participating in the secure remote access, and define the > secure remote access architecture. > > 2) Standards that fulfill the requirements outlined in this charter. If item (2) is to be in the final charter, then I think some of the language preceding it needs substantial revision. Comments interspersed... Roy Pereira wrote: > > > Proposed Charter: > > The rapid growth of remote access and the subsequent transition from older > direct-dial remote access to Internet-based remote access is making an > impact on secure communications. > > IP Security (IPSec), as it is defined today, is missing key functionality > needed to effectively support Internet-based secure remote access as well as > being difficult to deploy to remote users such as road-warriors and > telecommuters wishing to connect back to their corporate networks. I believe the first part of this sentence is incorrect, and the second part is implementation dependent - I'll restrict my comments to the first part. I believe that all the "needed" mechanisms are present within IPsec as currently defined. PKI provides strong authentication, preshared keys provide weaker password-based authentication, and DHCP may be carried over the existing IPsec framework for other configuration. It seems that the real problem you wish to address is that some people are reluctant to deploy PKI and/or to abandon their previously installed "legacy" mechanism, and as a result, you are calling for us to integrate so-called legacy authentication mechanisms into IPsec. It should be the goal of this working group to determine how to provide secure remote access using IPsec. If, in the course of researching this problem, it is determined that the existing framework does not support some required functionality, then these would be valid work items for consideration. However, I believe that beginning with the premise that IPsec does not provide the necessary and sufficient mechanisms is incorrect. > All these groups of users share the property that their IP address is > temporary and doesn't give any information about the identity of the user. > Although their temporary IP address is meaningless for IPSec, they still > require to become a part of a virtual private network, and to have access to > resources that are part of the private network. The statement "All these groups of users share..." is also incorrect. Some telecommuters have ISP-assigned stationary IP addresses. And again, PKI and preshared secrets makes this point moot - IP addresses are not the only identifier types supported by IPsec. > IPSec is quite functional and provides for a very robust base of security > specifications, thus any new functionality would have to be added to the > existing specifications as add-ons and not disrupt existing implementations. > > To address these individual problems the IPSRA Working Group will: > > 1) Specify an extensible mechanism for bootstrapping remote IPSec users for > address management in the critical time before the intended phase 2 > negotiation starts and requires these addresses. Address assignment from > within the private network is needed to fulfill the requirement that remote > users be able to access the resources of that private network. > > 2) Specify an extensible mechanism to extend IPSec to support legacy user > authentication methods but still maintain its current security. While the > current authentication mechanisms within IKE are very appropriate and very > secure, PKI's are not yet widely deployed and there is a huge installation > base of legacy remote access authentication servers, such as RADIUS and > ACE/SecurID to name just a few, that aren't currently supported within IKE. > > 3) Research any enhancements to the IKE exchanges to better support remote > users. > > Since this working group is focusing on IP Security, all of its goals have > the underlying goal of being security conscious. > > The outputs of this working group should include: > > 1) An IPSec Remote Access framework document specifying the > requirements from secure remote access. This document should identify all > the entities participating in the secure remote access, and define the > secure remote access architecture. > > 2) Standards that fulfill the requirements outlined in this charter. I think it might be more realistic to say "Standards-track, Informational, Experimental, and Best Current Practices RFCs..." rather than just standards. > The proposed work items for this group would yield standards that are > compatible with the existing IPSec architecture [RFC 2401] and IKE, > complementing the standards work achieved by the IPSec Working Group. > > This work might be derived from, but not limited to, all or some of the > following documents: > > draft-ietf-ipsec-ike-base-mode > draft-ietf-ipsec-isakmp-hybrid-auth > draft-ietf-ipsec-isakmp-mode-cfg > draft-ietf-ipsec-iskamp-xauth > draft-ietf-ipsec-dhcp > draft-gupta-ipsec-remote-access-02.txt Scott From owner-ietf-ipsra Wed Aug 4 09:29:52 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id JAA16356 for ietf-ipsra-bks; Wed, 4 Aug 1999 09:29:52 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from aum (ip11.proper.com [165.227.249.11]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id JAA16352; Wed, 4 Aug 1999 09:29:46 -0700 (PDT) Message-Id: <4.2.0.58.19990804093131.00992360@mail.vpnc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 04 Aug 1999 09:32:48 -0700 To: "Iyer, Prakash" , "'Roy Pereira'" , ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: RE: Proposed Charter In-Reply-To: <01C843625423D211AC3F00A0C969E89002CC82D1@orsmsx35.jf.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:01 AM 8/4/1999 -0700, Iyer, Prakash wrote: >1. Secondary VPN gateway FQDN / IP address >2. Reachable subnets (routes) >3. Link-state detection / keep alives >4. VPN gateway initiated VPN teardown Are these all remote-access issues, or issues that should be dealt with in the main IPsec WG? I think 1 and 2 seem mostly relevant to remote-access folks, but 3 and 4 seem more generic to IPsec in general. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra Wed Aug 4 10:36:37 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA16505 for ietf-ipsra-bks; Wed, 4 Aug 1999 10:36:37 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.inter.net.il [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA16501 for ; Wed, 4 Aug 1999 10:36:34 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id UAA09103; Wed, 4 Aug 1999 20:34:20 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA07421; Wed, 4 Aug 99 20:34:37 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma007414; Wed, 4 Aug 99 20:34:13 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id UAA24800; Wed, 4 Aug 1999 20:35:17 +0200 Message-Id: <37A87933.49D936E0@radguard.com> Date: Wed, 04 Aug 1999 20:32:35 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" , ipsra Subject: Re: Proposed Charter References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> <37A86C23.5B3089A0@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: "Scott G. Kelly" wrote: > > Proposed Charter: > > > > The rapid growth of remote access and the subsequent transition from older > > direct-dial remote access to Internet-based remote access is making an > > impact on secure communications. > > > > IP Security (IPSec), as it is defined today, is missing key functionality > > needed to effectively support Internet-based secure remote access as well as > > being difficult to deploy to remote users such as road-warriors and > > telecommuters wishing to connect back to their corporate networks. > > I believe the first part of this sentence is incorrect, and the second > part is implementation dependent - I'll restrict my comments to the > first part. I believe that all the "needed" mechanisms are present > within IPsec as currently defined. PKI provides strong authentication, > preshared keys provide weaker password-based authentication, and DHCP > may be carried over the existing IPsec framework for other > configuration. It seems that the real problem you wish to address is > that some people are reluctant to deploy PKI and/or to abandon their > previously installed "legacy" mechanism, and as a result, you are > calling for us to integrate so-called legacy authentication mechanisms > into IPsec. One problem that does exist with the current IPSec RFCs is that IKE main mode with pre-shared keys authentication doesn't work with non static IP addresses. I think we must give an answer to this problem (and I don't think aggressive mode is a good answer....) Sara. From owner-ietf-ipsra Wed Aug 4 10:51:25 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA16548 for ietf-ipsra-bks; Wed, 4 Aug 1999 10:51:25 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from trinc.com (steffi.trinc.com [206.40.37.34] (may be forged)) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA16544 for ; Wed, 4 Aug 1999 10:51:23 -0700 (PDT) Received: from Garfield by trinc.com (8.8.7/SMI-SVR4) id KAA17075; Wed, 4 Aug 1999 10:47:40 -0700 (PDT) Message-ID: <008801bedf6b$755741a0$2b05010a@trinc.com> From: "Kalyan Chakravarthy Bade" To: "Sara Bitan" , "Scott G. Kelly" , "ipsra" References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> <37A86C23.5B3089A0@redcreek.com> <37A87933.49D936E0@radguard.com> Subject: Re: Proposed Charter Date: Thu, 5 Aug 1999 10:53:43 -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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > One problem that does exist with the current IPSec RFCs is that IKE > main mode with pre-shared keys authentication doesn't work with non static IP > addresses. I think we must give an answer to this problem (and I don't think > aggressive mode is a good answer....) It works when the identities in main mode are not IP addresses. When the pre-shared key authentication is used, the preshared key is common to all the remote access clients, so instead we can go for authentication with digital signatures. Kalyan. From owner-ietf-ipsra Wed Aug 4 12:18:53 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id MAA16788 for ietf-ipsra-bks; Wed, 4 Aug 1999 12:18:53 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from sales-finance.vpnet.com (vpnet.com [209.1.117.16]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA16784 for ; Wed, 4 Aug 1999 12:18:51 -0700 (PDT) Received: by vpnet.com with Internet Mail Service (5.0.1461.28) id ; Wed, 4 Aug 1999 12:20:29 -0700 Message-ID: From: Sankar Ramamoorthi To: "'Sara Bitan'" , "Scott G. Kelly" , ipsra Subject: RE: Proposed Charter Date: Wed, 4 Aug 1999 12:20:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: >From: Sara Bitan [sarab@radguard.com] >Sent: Wednesday, August 04, 1999 10:33 AM >To: Scott G. Kelly; ipsra >Subject: Re: Proposed Charter > >"Scott G. Kelly" wrote: > >> > Proposed Charter: >> > >> > The rapid growth of remote access and the subsequent transition from older >> > direct-dial remote access to Internet-based remote access is making an >> > impact on secure communications. >> > >> > IP Security (IPSec), as it is defined today, is missing key functionality >> > needed to effectively support Internet-based secure remote access as well as >> > being difficult to deploy to remote users such as road-warriors and >> > telecommuters wishing to connect back to their corporate networks. >> >> I believe the first part of this sentence is incorrect, and the second >> part is implementation dependent - I'll restrict my comments to the >> first part. I believe that all the "needed" mechanisms are present >> within IPsec as currently defined. PKI provides strong authentication, >> preshared keys provide weaker password-based authentication, and DHCP >> may be carried over the existing IPsec framework for other >> configuration. It seems that the real problem you wish to address is >> that some people are reluctant to deploy PKI and/or to abandon their >> previously installed "legacy" mechanism, and as a result, you are >> calling for us to integrate so-called legacy authentication mechanisms >> into IPsec. > >One problem that does exist with the current IPSec RFCs is that IKE >main mode with pre-shared keys authentication doesn't work with non static IP >addresses. I think we must give an answer to this problem (and I don't think >aggressive mode is a good answer....) > > Sara. I agree. Would it be within the charter to look for solutions to allow entities with non-ip identites to use main mode effectively? Currently one of the problems I run into with non-ip identities is 'The responder has no way of knowing which policy to use till the id payload is received'. Hence pre-shared secerts are out. Even with certificates it is not possible to find associated policy information when processing the first SA packet. The way I have implemented right now is to always accept the first proposal from a initiaor having non-ip idenitity and later match it against the local policy when the id payload is received. This solution is limiting since it does not allow me to select among the choice of proposals presented. Recommendation for a better solution is welcome. -- sankar -- From owner-ietf-ipsra Wed Aug 4 13:43:44 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id NAA16928 for ietf-ipsra-bks; Wed, 4 Aug 1999 13:43:44 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from exchange.redcreek.com ([209.125.38.15]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA16924 for ; Wed, 4 Aug 1999 13:43:41 -0700 (PDT) Received: from redcreek.com (host40.redcreek.com [209.218.26.40]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id NQYRRJW2; Wed, 4 Aug 1999 13:46:56 -0700 Message-ID: <37A8A6B1.52C66F9@redcreek.com> Date: Wed, 04 Aug 1999 13:46:41 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sara Bitan CC: ipsra Subject: Re: Proposed Charter References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> <37A86C23.5B3089A0@redcreek.com> <37A87933.49D936E0@radguard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi Sara, Sara Bitan wrote: > > One problem that does exist with the current IPSec RFCs is that IKE > main mode with pre-shared keys authentication doesn't work with non static IP > addresses. I think we must give an answer to this problem (and I don't think > aggressive mode is a good answer....) > I think you've actually already offered one solution with base mode. As you note in your draft, it's even possible that a cleverly chosen method for deriving ID_KEY_ID could provide identity protection, though I admit I haven't thought this all the way through. Scott From owner-ietf-ipsra Wed Aug 4 15:55:40 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id PAA17230 for ietf-ipsra-bks; Wed, 4 Aug 1999 15:55:40 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA17225; Wed, 4 Aug 1999 15:55:38 -0700 (PDT) Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id PAA21782; Wed, 4 Aug 1999 15:58:30 -0700 (PDT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 4 Aug 1999 15:58:25 -0700 Message-ID: <01C843625423D211AC3F00A0C969E89002CC82D9@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: "'Paul Hoffman / VPNC'" , "'Roy Pereira'" , ietf-ipsra@vpnc.org Subject: RE: Proposed Charter Date: Wed, 4 Aug 1999 15:54:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: My understanding was that the IPSEC WG was not interested in looking at these issues. They probably don't merit a new WG and don't seem to fit the agenda of another active WG, so I proposed that we address them in this WG. -Prakash -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Wednesday, August 04, 1999 9:33 AM To: Iyer, Prakash; 'Roy Pereira'; ietf-ipsra@vpnc.org Subject: RE: Proposed Charter At 09:01 AM 8/4/1999 -0700, Iyer, Prakash wrote: >1. Secondary VPN gateway FQDN / IP address >2. Reachable subnets (routes) >3. Link-state detection / keep alives >4. VPN gateway initiated VPN teardown Are these all remote-access issues, or issues that should be dealt with in the main IPsec WG? I think 1 and 2 seem mostly relevant to remote-access folks, but 3 and 4 seem more generic to IPsec in general. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra Thu Aug 5 01:52:34 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id BAA17794 for ietf-ipsra-bks; Thu, 5 Aug 1999 01:52:34 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.inter.net.il [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id BAA17790 for ; Thu, 5 Aug 1999 01:52:30 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id LAA12188; Thu, 5 Aug 1999 11:30:22 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA13833; Thu, 5 Aug 99 10:46:02 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma013825; Thu, 5 Aug 99 10:45:44 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id KAA15751; Thu, 5 Aug 1999 10:46:46 +0200 Message-Id: <37A94286.5908001C@radguard.com> Date: Thu, 05 Aug 1999 10:51:34 +0300 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: Kalyan Chakravarthy Bade , ipsra Subject: Re: Proposed Charter References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> <37A86C23.5B3089A0@redcreek.com> <37A87933.49D936E0@radguard.com> <008801bedf6b$755741a0$2b05010a@trinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Kalyan Chakravarthy Bade wrote: > It works when the identities in main mode are not IP addresses. When the > pre-shared key authentication is used, the preshared key is common to all > the remote access clients, Common to all the users ? Pre shared keys are weak enough when they are different for each user. > so instead we can go for authentication with digital > signatures. Do that whenever possible. But what if you don't have PKI ? > > > Kalyan. From owner-ietf-ipsra Thu Aug 5 10:42:41 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id KAA19360 for ietf-ipsra-bks; Thu, 5 Aug 1999 10:42:41 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from trinc.com (steffi.trinc.com [206.40.37.34] (may be forged)) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA19356 for ; Thu, 5 Aug 1999 10:42:39 -0700 (PDT) Received: from Garfield by trinc.com (8.8.7/SMI-SVR4) id KAA29264; Thu, 5 Aug 1999 10:39:10 -0700 (PDT) Message-ID: <005701bee033$7023c960$2b05010a@trinc.com> From: "Kalyan Chakravarthy Bade" To: "Yael Dayan" , "ipsra" References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> <37A86C23.5B3089A0@redcreek.com> <37A87933.49D936E0@radguard.com> <008801bedf6b$755741a0$2b05010a@trinc.com> <37A94286.5908001C@radguard.com> Subject: Re: Proposed Charter Date: Fri, 6 Aug 1999 10:45:13 -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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: > > It works when the identities in main mode are not IP addresses. When the > > pre-shared key authentication is used, the preshared key is common to all > > the remote access clients, > > Common to all the users ? Pre shared keys are weak enough when they are > different for each user. Thats true....Then why shouldn't anyone go for a PKI when they know that pre shared keys are weak enough in any scenerio.... From owner-ietf-ipsra Thu Aug 5 13:18:05 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id NAA19664 for ietf-ipsra-bks; Thu, 5 Aug 1999 13:18:05 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA19659; Thu, 5 Aug 1999 13:18:03 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id QAA28036; Thu, 5 Aug 1999 16:21:09 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdCAAa27966; Thu Aug 5 16:20:58 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 5 Aug 1999 16:20:56 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Thu, 5 Aug 1999 16:23:16 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC996C3@exchange> From: Roy Pereira To: Paul Hoffman / VPNC , "Iyer, Prakash" , ietf-ipsra@vpnc.org Subject: RE: Proposed Charter Date: Thu, 5 Aug 1999 16:23:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: I agree with Paul's comments. But I'm not sure what we can do about #1, since I think that really is an implementation issue for each vendor. #3 would be a really nice feature to have standardized, but it sounds like it really should be part of IPSec, although I'm not sure if they are in a position to push something like that. #4 should already be supported by the use of the ISAKMP DELete message. -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Wednesday, August 04, 1999 12:33 PM To: Iyer, Prakash; 'Roy Pereira'; ietf-ipsra@vpnc.org Subject: RE: Proposed Charter At 09:01 AM 8/4/1999 -0700, Iyer, Prakash wrote: >1. Secondary VPN gateway FQDN / IP address >2. Reachable subnets (routes) >3. Link-state detection / keep alives >4. VPN gateway initiated VPN teardown Are these all remote-access issues, or issues that should be dealt with in the main IPsec WG? I think 1 and 2 seem mostly relevant to remote-access folks, but 3 and 4 seem more generic to IPsec in general. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra Thu Aug 5 13:25:38 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id NAA19680 for ietf-ipsra-bks; Thu, 5 Aug 1999 13:25:38 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA19676 for ; Thu, 5 Aug 1999 13:25:36 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id QAA29306 for ietf-ipsra@vpnc.org; Thu, 5 Aug 1999 16:28:43 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa29281; Thu Aug 5 16:28:34 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP; Thu, 5 Aug 1999 16:27:15 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Thu, 5 Aug 1999 16:29:38 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFC996CB@exchange> From: Roy Pereira To: Sankar Ramamoorthi , "'Sara Bitan'" , "Scott G. Kelly" , ipsra Subject: RE: Proposed Charter Date: Thu, 5 Aug 1999 16:29:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: The third goal in the charter is for that purpose; 3) Research any enhancements to the IKE exchanges to better support remote users. -----Original Message----- From: Sankar Ramamoorthi [mailto:Sankar@vpnet.com] Sent: Wednesday, August 04, 1999 3:20 PM To: 'Sara Bitan'; Scott G. Kelly; ipsra Subject: RE: Proposed Charter Would it be within the charter to look for solutions to allow entities with non-ip identites to use main mode effectively? Currently one of the problems I run into with non-ip identities is 'The responder has no way of knowing which policy to use till the id payload is received'. Hence pre-shared secerts are out. Even with certificates it is not possible to find associated policy information when processing the first SA packet. The way I have implemented right now is to always accept the first proposal from a initiaor having non-ip idenitity and later match it against the local policy when the id payload is received. This solution is limiting since it does not allow me to select among the choice of proposals presented. Recommendation for a better solution is welcome. -- sankar -- From owner-ietf-ipsra Thu Aug 5 13:39:59 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id NAA19707 for ietf-ipsra-bks; Thu, 5 Aug 1999 13:39:59 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mail.inter.net.il (root@parker.inter.net.il [192.116.192.53]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA19703 for ; Thu, 5 Aug 1999 13:39:56 -0700 (PDT) Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.8.6/PA) with SMTP id XAA24612; Thu, 5 Aug 1999 23:42:05 +0300 (IDT) Received: by radguard.com (4.1/SMI-4.1) id AA22029; Thu, 5 Aug 99 23:41:35 IDT Received: from hellman.radguard.com(192.114.33.100) by gatekeeper.radguard.com via smap (V2.0beta) id xma022025; Thu, 5 Aug 99 23:41:08 +0300 Received: from radguard.com by hellman. (SMI-8.6/SMI-SVR4) id XAA08158; Thu, 5 Aug 1999 23:42:10 +0200 Message-Id: <37A9F67E.75B74161@radguard.com> Date: Thu, 05 Aug 1999 23:39:26 +0300 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" , ipsra , IPSec mailing list Subject: Re: Proposed Charter References: <319A1C5F94C8D11192DE00805FBBADDFC98E0B@exchange> <37A86C23.5B3089A0@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: Hello Scott! "Scott G. Kelly" wrote: > > Proposed Charter: > > > > The rapid growth of remote access and the subsequent transition from older > > direct-dial remote access to Internet-based remote access is making an > > impact on secure communications. > > > > IP Security (IPSec), as it is defined today, is missing key functionality > > needed to effectively support Internet-based secure remote access as well as > > being difficult to deploy to remote users such as road-warriors and > > telecommuters wishing to connect back to their corporate networks. > > I believe the first part of this sentence is incorrect, and the second > part is implementation dependent - I'll restrict my comments to the > first part. I believe that all the "needed" mechanisms are present > within IPsec as currently defined. PKI provides strong authentication, > preshared keys provide weaker password-based authentication, and DHCP > may be carried over the existing IPsec framework for other > configuration. It seems that the real problem you wish to address is > that some people are reluctant to deploy PKI and/or to abandon their > previously installed "legacy" mechanism, and as a result, you are > calling for us to integrate so-called legacy authentication mechanisms > into IPsec. I agree with you that we need to change the wording in the above sentence. IPSec does have the required functionality (i.e. certificates), but in the current status of PKI technology this functionality cannot yet be deployed in a scalable fashion. It doesn't matter if the reason is a financial one, an organizational one or just as you define it "people are reluctant to deploy PKI and/or to abandon their legacy mechanism". It is a legitimate requirement that we as IPSec vendors must provide an answer to. I don't think we have the power to force customers to abandon their legacy mechanism, and I prefer to see them use these mechanism within a framework that we sa working group will standardize, then to see allot of proprietary methods to use legacy authentication system with IPSec, some of them might turn out to be secure, but some probably will be insecure. > > > It should be the goal of this working group to determine how to provide > secure remote access using IPsec. If, in the course of researching this > problem, it is determined that the existing framework does not support > some required functionality, then these would be valid work items for > consideration. However, I believe that beginning with the premise that > IPsec does not provide the necessary and sufficient mechanisms is > incorrect. I agree that we should first define the problem, and then state the requirements, but I also argue that the current IPSec provide the required answers, not from the technology point of view but from other points of view. We are not going change the current framework, and I believe that providing support for legacy authentication systems will create a migration path that will lead us to deployment of IPSec with PKI. > > > > All these groups of users share the property that their IP address is > > temporary and doesn't give any information about the identity of the user. > > Although their temporary IP address is meaningless for IPSec, they still > > require to become a part of a virtual private network, and to have access to > > resources that are part of the private network. > > The statement "All these groups of users share..." is also incorrect. > Some telecommuters have ISP-assigned stationary IP addresses. Agreed, we'll change the wording. > And again, > PKI and preshared secrets makes this point moot - IP addresses are not > the only identifier types supported by IPsec. Preshared secrets with main mode with non IP address identifiers do not work. Certificate authentication with non IP address identifiers is exposed to denial of service attacks. From owner-ietf-ipsra Thu Aug 5 16:37:32 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id QAA19981 for ietf-ipsra-bks; Thu, 5 Aug 1999 16:37:32 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id QAA19977 for ; Thu, 5 Aug 1999 16:37:30 -0700 (PDT) Received: from [128.33.238.250] (tc238-250.bbn.com [128.33.238.250]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA17966; Thu, 5 Aug 1999 19:40:25 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <37A85787.C3BC7B88@radguard.com> References: Date: Thu, 5 Aug 1999 11:23:11 -0400 To: Sara Bitan From: Stephen Kent Subject: Re: Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities) Cc: IPSec mailing list , ipsra Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: sara, > >When an IPSec implementation is examining an IP packet against the SPD it has >no clue which >DNS name or DN name matches the IP addresses in the header. >I think that the purpose of the authentication process is to bind a DN or DNS >name to an >IP address so that matching of a packet against the SPD is possible. This is true for a security gateway, but not for a native end system implementation. >> IPsec does not support >> authentication of a compound principle, or of a user and a system >> independently. It would not sense to do so unless there was a >> corresponding SPD entry type for compound principles. > >I don't think IPSec needs to support compound principles. >I do think that we need to define requirements from the authentication >process that binds between the DN and the IP address. I think this should >be an IPSec extension, and part of the IPSRA work. >In this context I think this taxonomy is helpful. I think that the existing architecture provides for binding between any of the approved name forms and the IP addresses used in an SA. In order to support name (vs. address) entries in an SPD in a security gateway, a compliant implementation must already be able to do this, so it's not an extension. Steve From owner-ietf-ipsra Mon Aug 9 06:21:28 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id GAA20204 for ietf-ipsra-bks; Mon, 9 Aug 1999 06:21:28 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from mcfeeley.indusriver.com ([146.115.206.207]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA20200 for ; Mon, 9 Aug 1999 06:21:26 -0700 (PDT) Received: from indusriver.com (209.6.112.116) by mcfeeley.indusriver.com (Worldmail 1.3.167); 9 Aug 1999 09:20:35 -0400 Message-ID: <37AED602.13D662A2@indusriver.com> Date: Mon, 09 Aug 1999 09:22:10 -0400 From: Ben McCann X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Iyer, Prakash" CC: "'Roy Pereira'" , ietf-ipsra@vpnc.org Subject: Re: Proposed Charter References: <01C843625423D211AC3F00A0C969E89002CC82D1@orsmsx35.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: We have one more additional requirement beyond those suggested by Prakash. Windows based remote access clients need addresses for DNS and NBNS (netbios name servers) _within_ the private network. We think item 1 of the charter should be broadened to include a small number of configuration items such as these name server addresses. (Microsoft already has DNS and NBNS extensions in the Windows implementation of PPP IPCP so this addition provides comparable facilities for IPSEC Remote Access). I also had a few comments about Prakash's other issues: "Iyer, Prakash" wrote: > > There are other issues that probably need to be standardized sooner rather > than later. For example: > > 1. Secondary VPN gateway FQDN / IP address > One major issue for VPN gateway vendors is scalability as number of users > grow, even more so as broadband connectivity gets deployed. It will be > useful to indicate in-band the location of a backup gateway or gateways, if > a primary gateway is unable to accept a new remote access VPN connection. Can this be achieved with Dynamic DNS which provides load balancing among multiple servers? > > 2. Reachable subnets (routes) > These could be returned along with the tunnel (inner) IP address. It is > desirable for VPN clients to manage simultaneous connectivity within and > outside the tunnel. Remote access customers would like for example to access > their personal ISP accounts or other web sites without being forced to go > through the corporate tunnel and the corporate proxy where transactions may > be logged. If reachable subnets/hosts are returned to remote access clients, > the client software can manage routing data appropriately to support this > requirement. Is it necessary to invent a new protocol? Can we use an existing routing protocol (such as Triggered RIP) to provide the same functionality? -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ietf-ipsra Fri Aug 13 07:54:20 1999 Received: by mail.vpnc.org (8.9.3/8.9.0) id HAA02380 for ietf-ipsra-bks; Fri, 13 Aug 1999 07:54:20 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from altiga.com (altiga.altiga.com [63.67.72.130]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id HAA02376 for ; Fri, 13 Aug 1999 07:54:18 -0700 (PDT) Received: from perforce.altiga.com ([10.10.0.11]) by fw.altiga.com with ESMTP id <115203>; Fri, 13 Aug 1999 10:51:32 -0400 Received: from mail.altiga.com (mail [10.10.0.10]) by perforce.altiga.com (8.8.8+Sun/8.8.8) with ESMTP id KAA07315 for ; Fri, 13 Aug 1999 10:54:08 -0400 (EDT) Received: by mail.altiga.com with Internet Mail Service (5.5.2448.0) id ; Fri, 13 Aug 1999 10:50:23 -0400 Message-ID: <71B30BC67510D31184030090277A3DDE1385E9@mail.altiga.com> From: "Volpe, Victor" To: ietf-ipsra@vpnc.org Subject: Xauth and Mode Cfg capable clients Date: Fri, 13 Aug 1999 10:50:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: I am not sure if this has been talked about already, if it has, please just point me to the thread. One secondary benefit to using certs for authentication is that a lot of the "per user" configuration goes away. We have found that because of Xauth and mode cfg, some of this has been reintroduced if trying to support multiple flavors of clients. There are several ways to get around this. One way is to have the initiator kick off Xauth and mode cfg but this poses a whole slew of other problems. Another way is for the initiator to "inform", or negotiate the Xauth/mode cfg capabilities with, the responder. Does anyone see any value in this? A third way of solving this type of a problem is to tie a set of access privileges to the user's cert but this has migration issues. Basically, the administrator is forced to reissue certs when migrating to a different type of client. Victor /*********************************************************************/ Victor Volpe Altiga Networks, Inc. Software Development Manager 204 Grove Street, Suite 205 vvolpe@altiga.com Franklin, MA 02038-3156 phone: (508) 553-6105 www.altiga.com fax : (508) 541-7030 /*********************************************************************/ From owner-ietf-ipsra Tue Aug 17 12:43:15 1999 Received: (from majordomo@localhost) by mail.vpnc.org (8.9.3/8.9.0) id MAA05462 for ietf-ipsra-bks; Tue, 17 Aug 1999 12:43:15 -0700 (PDT) X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ietf-ipsra@mail.vpnc.org using -f Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA05458 for ; Tue, 17 Aug 1999 12:43:12 -0700 (PDT) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id PAA25812 for ietf-ipsra@vpnc.org; Tue, 17 Aug 1999 15:43:42 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdBAAa25587; Tue Aug 17 15:42:53 1999 Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Tue, 17 Aug 1999 15:40:08 -0400 Received: by exchange with Internet Mail Service (5.5.2232.9) id ; Tue, 17 Aug 1999 15:43:02 -0400 Message-Id: <319A1C5F94C8D11192DE00805FBBADDFCEC7E9@exchange> From: Roy Pereira To: ietf-ipsra@vpnc.org Subject: draft-ietf-ipsec-isakmp-mode-cfg-05.txt Date: Tue, 17 Aug 1999 15:43:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEE8E8.B7610650" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEE8E8.B7610650 Content-Type: text/plain; charset="iso-8859-1" Here is an updated version of the IKECFG draft; <> Roy Pereira TimeStep Corporation (613) 599-3610 x4808 http://www.timestep.com ------_=_NextPart_000_01BEE8E8.B7610650 Content-Type: text/plain; name="draft-ietf-ipsec-isakmp-mode-cfg-05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipsec-isakmp-mode-cfg-05.txt" Content-Location: ATT-0-A276588BBB54D311935200104B6AA8D8- Internet Engineering Task Force R. Pereira, TimeStep Corp. IP Security Working Group S. Anand, Microsoft Corp. Internet Draft B. Patel, Intel Corp. Expires in six months August 17, 1999 The ISAKMP Configuration Method Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is a submission to the IETF Internet Protocol Security Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor(s). This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes a new ISAKMP method that allows configuration items to be exchanged securely by using both push/acknowledge or request/reply paradigms. R. Pereira, S. Anand, B. Patel [Page 1] =0C Internet Draft The ISAKMP Configuration Method August, 99 Table of Contents 1. Introduction..............................................2 1.1 Reader Prerequisites......................................2 1.2 Specification of Requirements.............................3 2. Configuration Transaction.................................3 3. Configuration Method Exchange and Payload.................4 3.1 Transaction Exchanges.....................................4 3.2 Attribute Payload.........................................5 3.3 Configuration Message Types...............................6 3.4 Configuration Attributes..................................7 3.5 Retransmission............................................9 4. Exchange Positioning......................................9 5. Specific Uses.............................................9 5.1 Requesting an Internal Address...........................10 5.2 Requesting the Peer's Version............................11 6. Enterprise Management Considerations.....................11 7. Security Considerations..................................11 8. References...............................................12 9. Acknowledgments..........................................12 10. Editors' Addresses.......................................13 11. Expiration...............................................13 12. Full Copyright Statement.................................14 1. Introduction The ISAKMP protocol provides a framework to negotiate and generate Security Associations. While negotiating SAs, it is sometimes quite useful to retrieve certain information from the other peer before the non-ISAKMP SA can be established. Luckily, ISAKMP is also flexible enough to provide configuration information and do it securely. This document will present a mechanism to extend ISAKMP to provide such functionality. 1.1 Reader Prerequisites It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97] documents. Readers are advised to be familiar with both [IKE] and [ISAKMP] because of the terminology used within this document and the fact that this document is an extension of both of those documents. R. Pereira, S. Anand, B. Patel [Page 2] =0C Internet Draft The ISAKMP Configuration Method August, 99 1.2 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. 2. Configuration Transaction A "Configuration Transaction" is defined as two configuration exchanges, the first being either a Set or a Request and the second being either an Acknowledge or a Reply, respectively. A common identifier is used to identify the transaction between exchanges. There are two paradigms to follow for this method. o "Request/Reply" allows a host to request information from an informed hosts (a configuration manager). If the attributes in the Request message are not empty, then these attributes are taken as suggestions for that attribute. The Reply message MAY wish to choose those values, or return new values. It MAY also add new attributes and not include some requested attributes. A Reply MUST always be sent when a Request is received, even if it is an empty Reply or if there are missing attributes in the Request. This merely means that the requested attributes were not available or unknown. Initiator Responder --------------- -------------- REQUEST --> <-- REPLY o "Set/Acknowledge" works on the push principle that allows a configuration manager (a host that wishes to send information to another host) to start the configuration transaction. This code sends attributes that it wants the peer to alter. The Acknowledge code MUST return the zero length attributes that it accepted. Those attributes that it did not accept will NOT be sent back in the acknowledgement. Initiator Responder --------------- ------------------- SET --> <-- ACKNOWLEDGE R. Pereira, S. Anand, B. Patel [Page 3] =0C Internet Draft The ISAKMP Configuration Method August, 99 Transactions are completed once the Reply or Acknowledge code is received. If one is not received, the implementation MAY wish to retransmit the original exchange as detailed in a later section. The initiator and responder are not necessarily the same as the initiator and responder of the ISAKMP exchange. 3. Configuration Method Exchange and Payload 3.1 Transaction Exchanges A new exchange mode is required for the configuration method. This exchange is called the "Transaction Exchange" and has a value of 6. This exchange is quite similar to the Information exchange described in [ISAKMP] and [IKE], but allows for multi-exchange transactions instead of being a one-way transmittal of information. This specification protects ISAKMP Transaction Exchanges when possible. 3.1.1 Protected Exchanges Once an ISAKMP security association has been established (and SKEYID_e and SKEYID_a have been generated), the ISAKMP Transaction Exchange is as follows: Initiator Responder ----------- ----------- HDR*, HASH, ATTR --> <-- HDR*, HASH, ATTR Where the HASH payload contains the prf output, using SKEYID_a as the key, and the M-ID (ISAKMP header Message ID) unique to this exchange concatenated with all of the payloads after the HASH payload. In other words, the hash for the above exchange is: HASH =3D prf( SKEYID_a, M-ID | ATTR ) Multiple ATTR payloads MAY NOT be present in the Transaction Exchange. As noted, the message ID in the ISAKMP header-- as used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another exchange. The derivation of the initialization vector (IV) for the first message, used with SKEYID_e to encrypt the message, is described in Appendix B of [IKE]. Subsequent IVs are taken from the last ciphertext block of R. Pereira, S. Anand, B. Patel [Page 4] =0C Internet Draft The ISAKMP Configuration Method August, 99 the previous message as described in [IKE]. 3.1.2 Unprotected Exchanges If the ISAKMP security association has not yet been established at the time of the Transaction Exchange and the information being exchanged is not sensitive, the exchange MAY be done in the clear without an accompanying HASH payload. Initiator Responder ----------- ----------- HDR, ATTR --> <-- HDR, ATTR Multiple ATTR payloads MAY NOT be present in the Transaction Exchange. 3.2 Attribute Payload A new payload is defined to carry attributes as well as the type of transaction message. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! RESERVED ! Identifier ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Attributes ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attributes Payload fields are defined as follows: o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. o RESERVED (1 octet) - Unused, set to 0. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, the transaction- specific header and all attributes. If the length does not match the length of the payload headers plus the attributes, (i.e. an attribute is half contained within this payload) then entire payload MUST be discarded. R. Pereira, S. Anand, B. Patel [Page 5] =0C Internet Draft The ISAKMP Configuration Method August, 99 o Attribute Message Type (1 octet) - Specifies the type of message represented by the attributes. These are defined in the next section. o RESERVED (1 octet) - Unused, set to 0. o Identifier (2 octets) - An identifier used to reference a configuration transaction within the individual messages. o Attributes (variable length) - Zero or more ISAKMP Data Attributes as defined in [ISAKMP]. The attribute types are defined in a later section. The payload type for the Attributes Payload is 14. 3.3 Configuration Message Types These values are to be used within the Type field of an Attribute ISAKMP payload. Types Value = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RESERVED 0 ISAKMP_CFG_REQUEST 1 ISAKMP_CFG_REPLY 2 ISAKMP_CFG_SET 3 ISAKMP_CFG_ACK 4 Reserved for Future Use 5-127 Reserved for Private Use 128-255 Messages with unknown types SHOULD be silently discarded. R. Pereira, S. Anand, B. Patel [Page 6] =0C Internet Draft The ISAKMP Configuration Method August, 99 3.4 Configuration Attributes Zero or more ISAKMP attributes [ISAKMP] are contained within an Attributes Payload. Zero length attribute values are usually sent in a Request and MUST NOT be sent in a Response. All IPv6 specific attributes are mandatory only if the implementation supports IPv6 and vice versa for IPv4. Mandatory attributes are stated below. Unknown private attributes SHOULD be silently discarded. The following attributes are currently defined: Attribute Value Type Length = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RESERVED 0 INTERNAL_IP4_ADDRESS 1 Variable 0 or 4 octets INTERNAL_IP4_NETMASK 2 Variable 0 or 4 octets INTERNAL_IP4_DNS 3 Variable 0 or 4 octets INTERNAL_IP4_NBNS 4 Variable 0 or 4 octets INTERNAL_ADDRESS_EXPIRY 5 Variable 0 or 4 octets INTERNAL_IP4_DHCP 6 Variable 0 or 4 octets APPLICATION_VERSION 7 Variable 0 or more INTERNAL_IP6_ADDRESS 8 Variable 0 or 16 octets INTERNAL_IP6_NETMASK 9 Variable 0 or 16 octets INTERNAL_IP6_DNS 10 Variable 0 or 16 octets INTERNAL_IP6_NBNS 11 Variable 0 or 16 octets INTERNAL_IP6_DHCP 12 Variable 0 or 16 octets INTERNAL_IP4_SUBNET 13 Variable 0 or 4 octets SUPPORTED_ATTRIBUTES 14 Variable 0 or multiples of 2 Reserved for future use 15-16383 Reserved for private use 16384-32767 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - Specifies an address within the internal network. This address is sometimes called a red node address or a private address and MAY be a private address on the Internet. Multiple internal addresses MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. The requested address is valid until the expiry time defined with the INTERNAL_ADDRESS EXPIRY attribute or until the ISAKMP SA that was used to secure the request expires. The address MAY also expire when the IPSec (phase 2) SA expires, if the request is associated with a phase 2 negotiation. If no ISAKMP SA was used to secure the request, then the response MUST include an R. Pereira, S. Anand, B. Patel [Page 7] =0C Internet Draft The ISAKMP Configuration Method August, 99 expiry or the host MUST expire the SA after an implementation- defined time. An implementation MUST support this attribute. o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and reply messages. (e.g. 255.255.255.0) An implementation MUST support this attribute. o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS server within the network. Multiple DNS servers MAY be requested. The responder MAY respond with zero or more DNS server attributes. o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a NetBios Name Server (WINS) within the network. Multiple NBNS servers MAY be requested. The responder MAY respond with zero or more NBNS server attributes. o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one attribute MAY be present in the reply. An implementation MUST support this attribute. o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send any internal DHCP requests to the address contained within the attribute. Multiple DHCP servers MAY be requested. The responder MAY respond with zero or more DHCP server attributes. o APPLICATION_VERSION - The version or application information of the IPSec host. This is a string of printable ASCII characters that is NOT null terminated. This attribute does not need to be secured. An implementation MUST support this attribute. o INTERNAL_IP4_SUBNET =96 The protected sub-networks that this edge- device protects. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-networks attributes. An implementation MUST support this attribute. R. Pereira, S. Anand, B. Patel [Page 8] =0C Internet Draft The ISAKMP Configuration Method August, 99 o SUPPORTED_ATTRIBUTES =96 When used within a Request, this attribute must be zero length and specifies a query to the responder to reply back with all of the attributes that it supports. The response contains an attribute that contains a set of attribute identifiers each in 2 octets. The length divided by 2 (bytes) would state the number of supported attributes contained in the response. An implementation MUST support this attribute. Note that no recommendations are made in this document how an implementation actually figures out what information to send in a reply. i.e. we do not recommend any specific method of (an edge device) determining which DNS server should be returned to a requesting host. 3.5 Retransmission Retransmission SHOULD follow the same retransmission rules used with standard ISAKMP messages. 4. Exchange Positioning The exchange and messages defined within this document MAY appear at any time. Because of security considerations with most attributes, the exchange SHOULD be secured with an ISAKMP phase 1 SA. Depending on the type of transaction and the information being exchanged, the exchange MAY be dependant on an ISAKMP phase 1 SA negotiation, a phase 2 SA negotiation, or none of the above. The next section details specific functions and their position within an ISAKMP negotiation. 5. Specific Uses The following descriptions detail how to perform specific functions using this protocol. Other functions are possible and thus this list is not a complete list of all of the possibilities. While other functions are possible, the functions listed below MUST be performed as detailed in this document to preserve interoperability among different vendor's implementations. R. Pereira, S. Anand, B. Patel [Page 9] =0C Internet Draft The ISAKMP Configuration Method August, 99 5.1 Requesting an Internal Address This function provides address allocation to a remote host trying to tunnel into a network protected by an edge device. The remote host requests an address and optionally other information concerning the internal network from the edge device. The edge device procures an internal address for the remote host from any number of sources such as a DHCP/BOOTP server or an its own address pool. Initiator Responder ----------------------------- ------------------------------- HDR*, HASH, ATTR1(REQUEST) --> <-- HDR*, HASH, ATTR2(REPLY) ATTR1(REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY also contain any number of additional attributes that it wants returned in the response. For example: ATTR1(REQUEST) =3D INTERNAL_ADDRESS(0.0.0.0) INTERNAL_NETMASK(0.0.0.0) INTERNAL_DNS(0.0.0.0) ATTR2(REPLY) =3D INTERNAL_ADDRESS(192.168.219.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(291.168.219.0/255.255.255.0) All returned values will be implementation dependent. As can be seen in the above example, the edge device MAY also send other attributes that were not included in the REQUEST and MAY ignore the non-mandatory attributes that it does not support. This Transaction Exchange MUST occur after an ISAKMP phase 1 SA is already established and before an ISAKMP phase 2 negotiation has started, since that negotiation requires the internal address. Initial Negotiation: MainMode or AggressiveMode TransactionMode (IP Address request) QuickMode(s) Subsequent address requests would be done without the phase 1 negotiation when there already exists a phase 1 SA. R. Pereira, S. Anand, B. Patel [Page 10] =0C Internet Draft The ISAKMP Configuration Method August, 99 Subsequent Negotiations: TransactionMode (IP Address request) QuickMode(s) 5.2 Requesting the Peer's Version An IPSec host wishing to inquire about the other peer's version information (with or without security) MUST use this method. Initiator Responder ----------------------------- -------------------------- HDR, ATTR1(REQUEST) --> <-- HDR, ATTR2(REPLY) ATTR1(REQUEST) =3D APPLICATION_VERSION("") ATTR2(REPLY) =3D APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") The return text string will be im