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