From owner-ipsec@lists.tislabs.com Wed Sep 1 03:53:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA17124; Wed, 1 Sep 1999 03:53:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA11329 Wed, 1 Sep 1999 05:19:52 -0400 (EDT) From: Sudeep_Khuraijam@3com.com X-Lotus-FromDomain: 3COM To: "Waters, Stephen" cc: Paul Koning , ipsec@lists.tislabs.com, ebomarsi@xedia.com Message-ID: <882567DF.00335560.00@hqoutbound.ops.3com.com> Date: Wed, 1 Sep 1999 02:20:25 -0700 Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I read some of the mail on this thread and I can summarize a few points. We support OSPF, RIPv1&2, & Integrated ISIS on a virtual port with IPIP IPSec tunnel mode (with policy tied to the virtual port). The implementation allows different policies(& SAs) for different traffic type to the same peer. However commonly lumping all the traffic including routing traffic under one generic policy and one SA is also possible for simplicity and most widely used. Of course QOS with TOS mapping and class based queueing etc. is supported on the VPN box which addresses the QOS along the path. An IPIP Virtual Port is treated as a Point to Point link in the context of OSPF unless you define it as a Point to Multi Point in which case it will be treated as a NBMA link. The latter is useful if one desires to define one Virtual Port that connects to say thousands of remote SGWs (With all the inner SGW VP IP addresses belonging to one SUBnet emulating an NBMA network). Thus one can get away by defining one virtual port and one policy for all the remote sites if so desired at the minimum or individual definitions if granularity is the choice. Also the IPIP virtual port can be used without any SPDs such that one can tunnel across a shared IP infrastrucure. You will find that is also useful in repairing partitioned areas, extending areas, in OSPF etc. We also support the above IP routing protocols plus most all multiprotocol and their routing protocols using L2TP or PPTP Virtual port IPSec Transport mode on the underlying physical port. /sudeep From owner-ipsec@lists.tislabs.com Wed Sep 1 03:58:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA17551; Wed, 1 Sep 1999 03:58:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA11425 Wed, 1 Sep 1999 05:42:54 -0400 (EDT) From: Sudeep_Khuraijam@3com.com X-Lotus-FromDomain: 3COM To: Dan Harkins cc: Stephen Kent , "Waters, Stephen" , ipsec@lists.tislabs.com Message-ID: <882567DF.00357089.00@hqoutbound.ops.3com.com> Date: Wed, 1 Sep 1999 02:43:31 -0700 Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Dan> So let me ask again, what is the problem with BGP? Granted BGP is one way to get reachability information in this context, I do not aggree that it is the right tool. IBGP is meant for other purposes than being an IGP. Besides having to maintain TCP connections with the peers (which could be a problem if you want to fully mesh thousands of sites - and you'd want a route reflector), you might actually want to redistribute BGP routes to the true IGP in most environments where the IGP is incumbent. Also you have increased the layers of route convergence. Administratively BGP adds another task. Now you have to administer the BGP policies on the peers such that the prefixes are announced and so far we are dealing with just one remote SGW. Imagine thousands of such remote sites. I believe what routing protocols are used should strictly be an administrative decision which was implied in this thread. Dan> BGP is a _much_ simpler protocol Perhaps in implementation. Not in deployment when the network is large. I absolutely like BGP but in this context using BGP just to get intranet reachability information would be like watering plants with a BobCat:-). /sudeep From owner-ipsec@lists.tislabs.com Wed Sep 1 10:40:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA25448; Wed, 1 Sep 1999 10:40:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13106 Wed, 1 Sep 1999 11:45:53 -0400 (EDT) Content-return: allowed Date: Wed, 01 Sep 1999 17:46:57 +0100 From: "Rakoczi, B." Subject: IPsec-based user authentication and security policy in Mobile IP? To: "'ipsec@lists.tislabs.com'" Message-id: <3A8F273F00E8D111BE4A00805FA7AC5401B652FB@ntl10.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I am new in the list. I have a few questions about use of IPsec in Mobile IP. You likely know that Mobile IP is designed to facilitate roaming of Internet users between different access networks based on different technologies. As the access networks are connected to each other across the untrusted Internet they must be protected against malicious intruders. In the description of Mobile IP itself solutions has been developed to secure Mobile IP signaling messages (registration, binding update). My guess is that it is also possible to use IPsec for these cases and even for protecting user data traffic. And what`s more, beside signaling&data protection (encryption, integrity checking, data origin authentication) IPsec provides user authentication as well. Focusing on the requirements of a secure Mobile IP connection consider the following questions: User authentication User identification in Mobile IP and in the access network will be independent. For example the secret key stored on the SIM card and used for GSM/UMTS level of authentication can not be reused for IP level authentication. For IP level authentication a private/public key mechanism can take place at every registration procedure to the home agent identifying the user by the so-called Network Access Identifier (NAI). The public keys are managed by a trusted third party (Certificate Authority (CA)). Concerning question: -> I know that IPsec provides mutual authentication (public key exchange) even for those who do not know anything about each other prior to the communication. I also heard about DIAMETER as an enhancement of RADIUS which also can be used for access control and user authentication in IP networks. Is there any relation between IPsec and DIAMETER? Which do you think is better for Mobile IP? Security Policy In IPsec the communicating parties agree on the level (encryption or/and data origin authentication) and mode(tunneling or transport) of the protection at SA negotiation. This agreement must satisfy the security policy of both parties. In Mobile IP every access network has its own security policy. It is very important for the different access networks (IP subnets) to learn each other`s security policy quickly and easily since seamless SA negotiation (unnoticeable by the user!) is required when the user moves from an access network to another. Concerning questions: -> Is there any standard or policy which defines how an IPsec-based security policy should be tailored to access networks that implement Mobile IP? I`m looking forward to having your answers. regards Balint From owner-ipsec@lists.tislabs.com Wed Sep 1 11:31:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA26444; Wed, 1 Sep 1999 11:31:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13354 Wed, 1 Sep 1999 12:57:03 -0400 (EDT) Message-ID: <37CD4E79.C3C75662@redcreek.com> Date: Wed, 01 Sep 1999 16:04:09 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: Dan Harkins Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <199909010047.RAA01815@Potassium.Network-Alchemy.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > On Tue, 31 Aug 1999 23:31:17 -0000 you wrote > > > > If BGP routes to a next hop which is more than one hop away, then BGP > > requires that the IGP be able to resolve the intermetiate next hops and > > you are back where you started. > > You have this problem anyway because you need your GRE tunnel needs to > be established. You have to have some route from SGW1 to SGW2 regardless. > Given that requirement, is the simplest way to "discover what is out there" > (which is the desire that started this thread-- quote from Steve Waters) > to tunnel RIP and/or OSPF-- and all the cruft that goes along with that-- > between them or to just use BGP? BGP is a _much_ simpler protocol that OSPF > and either is _much_ better than RIP. > > Dan. I still see the next hop as a problem for BGP. Let me be more specific with a problem description and then see if Dan or some BGP folk can show how this is workable. I do hope that BGP can be shown to work because it would very cleanly solve the 'interface' problem by not requiring an interface construct. AS1 AS2 1 ---- 2 3 ----- 4 --| |-----(internet)-----| |---- ---- ----- 5========tunnel=========6 Here are two SGWs on the internet protecting endpoints at the subnets connnected to and behind interfaces 1 and 4. An IPSec tunnel connection exists between interfaces 2 and 3. Routers in the internet are unaware of how to reach the protected endpoints behind interfaces 1 and 4. Let us suppose that each SGW protects many subnets behind interfaces 1 and 4 respectively. And we desire to use a routing protocol to "discover what is out there". (BTW: I'll attach a little rant about this goal at the bottom). So the SGWs become BGP peers and advertize iBGP routes to other routers in their protected spaces / Autonomyous Systems. Now here comes the rub (finally). The SGW on the left advertizes in BGP that to reach subnets behind the SGW on the right the next hop is at interface 4. It should not use interface 3 in its next hop advertizements because that is a publically routed internet address which the other routers in AS1 need to default route to. So we have just required that interface 4 be reachable in the IGP of all the routers in AS1. But it ain't. If a GRE (or other) tunnel had been used to create interfaces 5 and 6 and carry IGP routing messages this next hop issue would not be a problem because the IGP itself would discover all the routes on both sides and we would have only one AS. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; PS: Rant about "discover what is out there" OK, "discover what is out there" is an insufficient goal. "And do what with that info", is what I want us to get clear about. From this thread I believe that I have sensed to possible uses for discovered routing topology: 1) auto create SPD entries out of discovered routes. 2) provide VPN redundancy for sights with multiple paths between them. Personally, I strongly dislike option 1 and strongly like option 2. But I am also interested in what others think. From owner-ipsec@lists.tislabs.com Wed Sep 1 13:10:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA27770; Wed, 1 Sep 1999 13:10:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13880 Wed, 1 Sep 1999 14:36:38 -0400 (EDT) Message-Id: <199909011834.LAA03478@Potassium.Network-Alchemy.COM> To: Sudeep_Khuraijam@3com.com cc: Stephen Kent , "Waters, Stephen" , ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Wed, 01 Sep 1999 02:43:31 PDT." <882567DF.00357089.00@hqoutbound.ops.3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3475.936210894.1@network-alchemy.com> Date: Wed, 01 Sep 1999 11:34:54 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Fully mesh thousands of sites? That's going to be a problem with IPSec by itself unless you also have some automagic tunnel endpoint discovery mechanism. So I don't think that, in and of itself, is a valid reason to not use BGP. You'd hit a scaling wall either way (and administration of 1000 fully meshed GRE tunnels is not trivial). Redistribution of BGP routes into a "true IGP" is something that is done everyday throughout the world so that too I don't see as a problem. I guess it comes down to administration. Eliminating the need to administer a tunnel interface whose sole purpose is to tunnel routing protocols seems like a win. One less thing to worry about. And it eliminates the security issues that Steve K was talking about too. Win-win. Dan. On Wed, 01 Sep 1999 02:43:31 PDT you wrote > > > Dan, > > Dan> So let me ask again, what is the problem with BGP? > > Granted BGP is one way to get reachability information in this context, I do >not > aggree that it is the right tool. > IBGP is meant for other purposes than being an IGP. Besides having to mainta >in > TCP connections with the peers > (which could be a problem if you want to fully mesh thousands of sites - and > you'd want a route reflector), > you might actually want to redistribute BGP routes to the true IGP in most > environments where the IGP is incumbent. > Also you have increased the layers of route convergence. Administratively BG >P > adds another task. > Now you have to administer the BGP policies on the peers such that the prefix >es > are announced and so far we are > dealing with just one remote SGW. Imagine thousands of such remote sites. I > believe what routing protocols are used should > strictly be an administrative decision which was implied in this thread. > > Dan> BGP is a _much_ simpler protocol > > Perhaps in implementation. Not in deployment when the network is large. > I absolutely like BGP but in this context using BGP just to get intranet > reachability information > would be like watering plants with a BobCat:-). > > /sudeep > > > > From owner-ipsec@lists.tislabs.com Thu Sep 2 09:19:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA00339; Thu, 2 Sep 1999 09:19:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18550 Thu, 2 Sep 1999 10:38:52 -0400 (EDT) Message-Id: <199909021443.QAA04992@iabgdns.iabg.de> Comments: Authenticated sender is From: "Florian Heissenhuber" Organization: IABG mbH To: ipsec@lists.tislabs.com Date: Thu, 2 Sep 1999 16:38:33 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Tools for testing IPsec Reply-to: heissenhuber@iabg.de X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, does anybody know about (free and/or commercial) tools for testing IPsec implementations? Regards, Florian __________________________________________________________________ Florian Heissenhuber Phone+49 89 60883539 IABG mbH Fax +49 89 60882845 Einsteinstr. 20 heissenhuber@iabg.de 85521 Ottobrunn http://www.iabg.de Germany From owner-ipsec@lists.tislabs.com Thu Sep 2 13:16:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA04129; Thu, 2 Sep 1999 13:16:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19542 Thu, 2 Sep 1999 13:59:50 -0400 (EDT) Message-ID: <37CEAEAF.7E865D31@redcreek.com> Date: Thu, 02 Sep 1999 17:06:55 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ".MailList, ipsec" Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy () Just an idea from crazy land; lets see how far this goes... The Non-Encapsulating Tunnel Interface for use with IPSec and IGPs. Intro: IPSec introduces some problems for routing protocols. IGPs anticipate that routing peers are reachable via a logical interface within 1 hop. These IGPs then learn/construct routes to subnets. IPSec tunnels are unsuitable for IGPs to run over as interfaces because they may reach destinations which are more specific than a subnet and there may also be _very_ many IPSec tunnels between peers. Creating a seperate generic tunnel interface is also unsuitable because although it allows the IGP to function, IPSec must either shunt all traffic into a transport mode SA to cross the tunnel (which is insecure), or IPSec must encapsulate its own tunnels and deliver the packet to the logical generic tunnel interface which will encapsulate the packet in a point to point link protocol and then also encapsulate the packet in IP again (which is inefficient). BGP has been suggested as a routing protocol to use to avoid the problem since it does not require the asumption that a peer router be reachable on a particular interface within one hop. But even if BGP is shown to be workable (still under debate at this time), it introduces the administrative burden of managing a set of Autonomous Systems. This memo (could become a draft if it doesn't get shot down to badly) proposes to use an interface contstruct which does not encapsulate packets. Since IPSec tunnels have alread acomplished that work, doing so again is redundant. The only reason an 'interface' is needed at all is to facilitate IGPs. A non-encapsulating tunnel interface carries all of the IPSec tunnels which are desinted to the same peer. Properties: 1) is in ifTable above a physical/ip layer interface 2) runs a keep-alive protocol 3) is usable by SPD 4) MUST have an IPSec policy matching at least endpoint to endpoint routing and keepalive messages which provides identity authentication. 5) any traffic being sent via the interface which is not destined for the interface's peer is dropped and audited. Processing: INBOUND: o Link driver receives a packet on a physical interface o this interfaces updates ifTable stats o recognize packet as IP o run verification tests o recognize as special case of addressed to me = addressed to my tunnel intf o (reassemble if necessary) o update ifTable stats for tunnel intf o IPSec process w/ ingress interface = tunnel intf o Fwd or locally receive OUTBOUND: o After IPSec processing: o Route to far-end tunnel IP has true physical next hop(s) but also has exit interface = tunnel Intf o update stats in ifTable for tunnel intf o ARP for true physical next hop o append link headers for physical link o update stats in ifTable for physical intf send packet Originating an IGP Routing Message: Both ends of the tunnel interface are configured to be in the same subnet. IGP messages sent to unicast neighbors are sent to the far-end tunnel IP. IGP messages sent to multicast addresses are sent via the local tunnel interface. An IPSec policy matches and MUST tunnel this packet (not transport, that would blow-up with multicast) to the far end tunnel IP. Then the packet is forwarded as per outbound processing. Receiving an IGP Routing Message: Packet is received via inbound processing as above. The packet is delivered locally. Keep-alive: Whatever keep-alive protocol is utilized, they are originated and received just like unicast routing messages. The keep-alive state machine may mark this tunnel as operStatus up or down in the ifTable. When a tunnel is marked as operStatus=down, the routes through this interface should be removed from or invalidated in the routing table. Also, any IGP on this device should be notified of the link-down (or link-up) event in the normal way. When is a non-encapsulating tunnel interface invoked: This is under administrative control. An implementation MUST be able to create a tunnel interface, set it to non-encapsulating mode and name its peer. Any packet entering the tunnel which is not destined to the peer is to be dropped and audited. One could imagine a Tunnel discovery protocol based on the configured list of peers in IKE. Maybe later. Security Considerations: (need help with this section) 1) Masquerade Since tunnel endpoints must be Internet reachable, they are also masquaradeable. As long as IPSec is authenticating packets received on the tunnel interface, however, there would be now way for the malicious user to inject bogus information into your IGP or to inject bogus keepalives into your state machine. 2) DOS A masquerader would be able to successfully divert the keepalives and would therefor be able to make your link appear to be down at any time. However, this is an improved situation from today where Internet traffic could be diverted from an IPSec tunnel and you would have no notification of the event. Comparison to other options: 1) IPSec Tunnel is an interface: There may be multiple IPSec tunnels to the same peer and these IPSec tunnels may be for endpoints which are applications on hosts. Both of these facts may confuse a routing protocol. 2) IKE Tunnel is an interface: This is not an encapsulation technology... it just won't work. 3) GRE tunnel is an interface, All relevant IPSec tunnels run over it: This works but takes a _lot_ of headers. 4) GRE tunnel is an interface, one IPSec transport SA carries all traffic: Insecure. 5) IPSec tunnel is an interface, rely on administrators to not come up with configurations which would confuse routing protocols: Yeah right. 6) IPSec tunnel may be marked as an interface, then the implementation disallows other configuration which would confuse routing protocols: Difficult to implement, reduces security flexibility. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Thu Sep 2 14:15:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA05194; Thu, 2 Sep 1999 14:15:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19764 Thu, 2 Sep 1999 15:41:57 -0400 (EDT) Message-ID: <37CED217.CF3D2B0E@indusriver.com> Date: Thu, 02 Sep 1999 15:37:59 -0400 From: Ben McCann X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Ricky Charlet CC: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <37CEAEAF.7E865D31@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Very interesting idea. I've scattered a couple questions through your text... [Big Snip] > > Processing: > INBOUND: > o Link driver receives a packet on a physical interface > o this interfaces updates ifTable stats > o recognize packet as IP > o run verification tests > o recognize as special case of addressed to me = addressed to my tunnel > intf Since this is a 'non-encapsulating tunnel', the destination address on the physical interface will be the TUNNEL interface's address, right? That requires the box to proxy ARP that address on the physical interface network, right? > o (reassemble if necessary) > o update ifTable stats for tunnel intf > o IPSec process w/ ingress interface = tunnel intf > o Fwd or locally receive > > OUTBOUND: > o After IPSec processing: Which interface's SPD is consulted to perform IPSEC processing? I assume it is the tunnel interface's SPD, right? > o Route to far-end tunnel IP has true physical next hop(s) but also has > exit interface = tunnel Intf Why is it necessary for the route to the far-end tunnel endpoint have a true physical next hop but an exit interface of the tunnel Interface? At this point in outbound processing you've already passed through IPSEC. > o update stats in ifTable for tunnel intf > o ARP for true physical next hop > o append link headers for physical link > o update stats in ifTable for physical intf send packet > [Big Snip] > > Comparison to other options: > > 1) IPSec Tunnel is an interface: > There may be multiple IPSec tunnels to the same peer and these > IPSec tunnels may be for endpoints which are applications on hosts. Both > of these facts may confuse a routing protocol. > > 2) IKE Tunnel is an interface: > This is not an encapsulation technology... it just won't work. > > 3) GRE tunnel is an interface, All relevant IPSec tunnels run over it: > This works but takes a _lot_ of headers. > > 4) GRE tunnel is an interface, one IPSec transport SA carries all > traffic: > Insecure. > > 5) IPSec tunnel is an interface, rely on administrators to not come up > with configurations which would confuse routing protocols: > Yeah right. > > 6) IPSec tunnel may be marked as an interface, then the implementation > disallows other configuration which would confuse routing protocols: > Difficult to implement, reduces security flexibility. And.... 7) PPP interface over L2TP with is then secured between LNS and LAC using IPSEC transport mode. I think this is the 'accepted' method assumed by the L2TP working group. It looses inbound SPD validation, lumps multiple flows into one SA, and it requires many layers of encapsulation. Bleh. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu Sep 2 17:02:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA07088; Thu, 2 Sep 1999 17:02:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20442 Thu, 2 Sep 1999 18:41:52 -0400 (EDT) Message-ID: <37CEF0C8.68A83451@redcreek.com> Date: Thu, 02 Sep 1999 21:48:56 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben McCann , ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <37CEAEAF.7E865D31@redcreek.com> <37CED217.CF3D2B0E@indusriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy () My replies are interspersed: Ben McCann wrote: > > Very interesting idea. I've scattered a couple questions through your text... > > [Big Snip] > > > > > Processing: > > INBOUND: > > o Link driver receives a packet on a physical interface > > o this interfaces updates ifTable stats > > o recognize packet as IP > > o run verification tests > > o recognize as special case of addressed to me = addressed to my tunnel > > intf > > Since this is a 'non-encapsulating tunnel', the destination address > on the physical interface will be the TUNNEL interface's address, > right? That requires the box to proxy ARP that address on the > physical interface network, right? I have no implementation experience with a tunneling protocol. But I suppose this problem is no diffent than how to ARP reply from a GRE interface. Would anyone else care to chime in here...? > > > o (reassemble if necessary) > > o update ifTable stats for tunnel intf > > o IPSec process w/ ingress interface = tunnel intf > > o Fwd or locally receive > > > > OUTBOUND: > > o After IPSec processing: > > Which interface's SPD is consulted to perform IPSEC processing? I assume > it is the tunnel interface's SPD, right? That makes the most sense. But if someone can figure out how to apply the SPD to the true physical outbound interface and still use this scheme effectivly, I would not be pre-disposed to precluding that. > > > o Route to far-end tunnel IP has true physical next hop(s) but also has > > exit interface = tunnel Intf > > Why is it necessary for the route to the far-end tunnel endpoint have > a true physical next hop but an exit interface of the tunnel Interface? > At this point in outbound processing you've already passed through IPSEC. IPSec has just encapsulated the packet and the new destination IP address (outer header) is to the far end tunnel end point. We will need the exit interface to be the tunnel so that we may update mib-2 stats. We will need the true next hop so that we can avoid further encapsulations. > > > o update stats in ifTable for tunnel intf > > o ARP for true physical next hop > > o append link headers for physical link > > o update stats in ifTable for physical intf send packet > > > > [Big Snip] > > > > > Comparison to other options: > > > > 1) IPSec Tunnel is an interface: > > There may be multiple IPSec tunnels to the same peer and these > > IPSec tunnels may be for endpoints which are applications on hosts. Both > > of these facts may confuse a routing protocol. > > > > 2) IKE Tunnel is an interface: > > This is not an encapsulation technology... it just won't work. > > > > 3) GRE tunnel is an interface, All relevant IPSec tunnels run over it: > > This works but takes a _lot_ of headers. > > > > 4) GRE tunnel is an interface, one IPSec transport SA carries all > > traffic: > > Insecure. > > > > 5) IPSec tunnel is an interface, rely on administrators to not come up > > with configurations which would confuse routing protocols: > > Yeah right. > > > > 6) IPSec tunnel may be marked as an interface, then the implementation > > disallows other configuration which would confuse routing protocols: > > Difficult to implement, reduces security flexibility. > > And.... > > 7) PPP interface over L2TP with is then secured between LNS and LAC > using IPSEC transport mode. I think this is the 'accepted' method assumed > by the L2TP working group. It looses inbound SPD validation, lumps multiple > flows into one SA, and it requires many layers of encapsulation. Bleh. > > -Ben McCann > Thanks for pointing this option out. > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Fri Sep 3 07:18:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA25172; Fri, 3 Sep 1999 07:18:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22450 Fri, 3 Sep 1999 08:42:27 -0400 (EDT) Message-Id: <199909022055.QAA03703@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue In-reply-to: Your message of "Thu, 02 Sep 1999 17:06:55 -0000." <37CEAEAF.7E865D31@redcreek.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 02 Sep 1999 16:55:47 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I will admit to not having followed the entire thread, but: >>>>> "Ricky" == Ricky Charlet writes: Ricky> Intro: IPSec introduces some problems for routing protocols. IGPs Ricky> anticipate that routing peers are reachable via a logical Ricky> interface within 1 hop. These IGPs then learn/construct routes to Ricky> subnets. IPSec tunnels are unsuitable for IGPs to run over as Ricky> interfaces because they may reach destinations which are more Ricky> specific than a subnet and there may also be _very_ many IPSec Ricky> tunnels between peers. Creating a seperate generic tunnel I'm not sure I see the issue here. If you mean that you are unable to get the IGP packet into the tunnel because it is a per-host tunnel, then I agree. But, in many ways this is a variation of the ICMP problem. ICMP errors don't fit in those tunnels either. Ricky> interface is also unsuitable because although it allows the IGP to Ricky> function, IPSec must either shunt all traffic into a transport Ricky> mode SA to cross the tunnel (which is insecure), or IPSec must I don't understand this statement. Ricky> encapsulate its own tunnels and deliver the packet to the logical Ricky> generic tunnel interface which will encapsulate the packet in a Ricky> point to point link protocol and then also encapsulate the packet Ricky> in IP again (which is inefficient). BGP has been suggested as a Again, less understanding on my part here. Ricky> routing protocol to use to avoid the problem since it does not Ricky> require the asumption that a peer router be reachable on a Ricky> particular interface within one hop. But even if BGP is shown to Ricky> be workable (still under debate at this time), it introduces the Ricky> administrative burden of managing a set of Autonomous Systems. I thought that IBGP could deal with this problem. Ricky> This memo (could become a draft if it doesn't get shot down to Ricky> badly) proposes to use an interface contstruct which does not Ricky> encapsulate packets. Since IPSec tunnels have alread acomplished Ricky> that work, doing so again is redundant. The only reason an Ricky> 'interface' is needed at all is to facilitate IGPs. A Ricky> non-encapsulating tunnel interface carries all of the IPSec Ricky> tunnels which are desinted to the same peer. I see where you are getting at here. It is a useful idea. It may be a useful abstraction. Let me think more. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Sep 3 10:34:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA29004; Fri, 3 Sep 1999 10:34:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23378 Fri, 3 Sep 1999 12:02:49 -0400 (EDT) Message-ID: <37CFE4C2.7C143B04@redcreek.com> Date: Fri, 03 Sep 1999 15:09:54 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue References: <199909022055.QAA03703@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > > I thought that IBGP could deal with this problem. > Actually, I hope it can. iBGP as a solution would render this encapsulating-tunnel idea nearly moot and we would all have less implementation work to do. I have not yet been convenced that BGP can resolve the remote next hops without first relying on an IGP already knowing paths to these. As for any other areas of my post, feel free to ask questions or suggest alternate text. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Fri Sep 3 16:45:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA04210; Fri, 3 Sep 1999 16:45:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24502 Fri, 3 Sep 1999 18:25:17 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A8F273F00E8D111BE4A00805FA7AC5401B652FB@ntl10.research.kpn.com> Date: Fri, 3 Sep 1999 18:25:24 -0400 To: "Rakoczi, B." From: Stephen Kent Subject: Re: IPsec-based user authentication and security policy in Mobile IP? Cc: "'ipsec@lists.tislabs.com'" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Balint, >Focusing on the requirements of a secure Mobile IP connection consider the >following questions: > >User authentication >User identification in Mobile IP and in the access network will be >independent. For example the secret key stored on the SIM card and used for >GSM/UMTS level of authentication can not be reused for IP level >authentication. For IP level authentication a private/public key mechanism >can take place at every registration procedure to the home agent identifying >the user by the so-called Network Access Identifier (NAI). The public keys >are managed by a trusted third party (Certificate Authority (CA)). IPsec does not embody an NAI as a form of ID, so I'm not quite sure that we're on the same track here. Also, in IPsec, (if one uses carts with IKE) CA need not be a TTP; it often is operated by the organization with which the user is affiliated, e.g., the same folks who operate the home agent. >Concerning question: > >-> I know that IPsec provides mutual authentication (public key exchange) >even for those who do not know anything about each other prior to the >communication. I also heard about DIAMETER as an enhancement of RADIUS which >also can be used for access control and user authentication in IP networks. >Is there any relation between IPsec and DIAMETER? >Which do you think is better for Mobile IP? So far there is no relationship. IPsec provides access control as an intrinsic feature, not just authentication, integrity, and confidentiality. >Security Policy >In IPsec the communicating parties agree on the level (encryption or/and >data origin authentication) and mode(tunneling or transport) of the >protection at SA negotiation. This agreement must satisfy the security >policy of both parties. In Mobile IP every access network has its own >security policy. It is very important for the different access networks (IP >subnets) to learn each other`s security policy quickly and easily since >seamless SA negotiation (unnoticeable by the user!) is required when the >user moves from an access network to another. If IPsec is provided from the user's terminal to the home agent, the access network is not a player in the IPsec negotiation and has no role in the policy. It sounds as though you envision using IPsec from some access network to a home agent, rather than on an end-to-end basis. That is possible, but it certainly is not the preferred model for IPsec use, and it raises serious security questions. For example, muxing at some access network device after exiting the wireless net and before having IPsec applied is a security concern. In the dialup environment we use IPsec from the terminal to the home site, not from the PPP server to the hoem site, and as a user I would want the same level of security if I were to employ a wireless access network. >Concerning questions: > >-> Is there any standard or policy which defines how an IPsec-based security >policy should be tailored to access networks that implement Mobile IP? As noted above, end-to-end IPsec is independent of the access network, and the alternative you seem to allude to would generally not be recommended. Steve From owner-ipsec@lists.tislabs.com Mon Sep 6 05:56:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA05216; Mon, 6 Sep 1999 05:56:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA00600 Mon, 6 Sep 1999 06:55:36 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE26F@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Mon, 6 Sep 1999 11:55:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure BGP fixes the problem, for me. I want to be able to learn Intranet routes from a remote peer, and populate a routing table with next-hop information, where each next hop is associated with a particular 'interface'; I want to detect when that 'interface' has failed so I can re-route. The tunnel, I hope, will be seen as a single hop to routing. You are right that there is probably room for some re-think about routing protocols used of VPN tunnels, and some of the 'preferred route' aspects of BGP may be the place to go for guidance. If I have OSPF running to the same remote VPN-LAN via two different ISPs, I may well use BGP to guide the tunneled packets to my preferred ISP for a given peer, with OSPF running within the tunnels. Or, I may let OSPF aggregate the two tunnels. I think there is certainly room for some new text somewhere to discuss these options. Cheers, Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] Sent: Tuesday, August 31, 1999 11:12 PM To: Stephen Kent Cc: Waters, Stephen; ipsec@lists.tislabs.com Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue It seems to me that the whole problem described in this thread exists because routing protocols that assume their peers are 1 hop away are being used-- e.g. the multicast addresses used for OSPF and RIP are from the "local segment usage only" range. So the problem becomes how to tunnel these packets to hide this from the protocol, which would go away if the protocol did not have this requirement. So let me ask again, what is the problem with BGP? There would be no need for any bizarre tunneling scheme and the BGP session can be protected with transport mode IPSec if you're concerned about that (no need for the ambiguity of "is transport-mode protected IPIP actually tunnel mode?"). BGP sounds like the right tool for the right job here. No need to short circuit the IPSec access control mechanisms nor add unnecessary headers (as Steve K noted) to the packets. And, most importantly, it achieves the goal. Dan. On Tue, 31 Aug 1999 11:22:29 EDT you wrote > Stephen, > > >I think I disagree with the statement that "Anything else will violate RFC > >2401". A security gateway is perfectly entitled to protected 'originating > >traffic' with transport-mode, and if the traffic source is a tunnel device > >(IPIP, L2TP, GRE...), then IPSEC can quite fairly protect this with > >transport mode to a remote peer/security gateway: > > > >" Note that for the case where traffic is destined for a > > security gateway, e.g., SNMP commands, the security gateway is acting > > as a host and transport mode is allowed." > > > >It is convenient, I think, to model generic traffic between two security > >gateways as transport-mode, regardless of the protocol. > > One can do this if the goal is to eviscerate the access controls provided > by IPsec, and there is a desire to add unnecessary protocol layers (e.g., > L2TP and GRE) when carrying IP traffic :-). > > Steve From owner-ipsec@lists.tislabs.com Mon Sep 6 06:00:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA05269; Mon, 6 Sep 1999 06:00:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA00599 Mon, 6 Sep 1999 06:55:36 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE271@new-exc1.ctron.com> From: "Waters, Stephen" To: Sudeep_Khuraijam@3com.com Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Date: Mon, 6 Sep 1999 11:55:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sudeep, Thanks - very interesting stuff. The NBMA scheme looks useful. Cheers, Steve. -----Original Message----- From: Sudeep_Khuraijam@3com.com [mailto:Sudeep_Khuraijam@3com.com] Sent: Wednesday, September 01, 1999 10:20 AM To: Waters, Stephen Cc: Paul Koning; ipsec@lists.tislabs.com; ebomarsi@xedia.com Subject: RE: IPSEC tunnels for LAN-to-LAN interop issue Steve, I read some of the mail on this thread and I can summarize a few points. We support OSPF, RIPv1&2, & Integrated ISIS on a virtual port with IPIP IPSec tunnel mode (with policy tied to the virtual port). The implementation allows different policies(& SAs) for different traffic type to the same peer. However commonly lumping all the traffic including routing traffic under one generic policy and one SA is also possible for simplicity and most widely used. Of course QOS with TOS mapping and class based queueing etc. is supported on the VPN box which addresses the QOS along the path. An IPIP Virtual Port is treated as a Point to Point link in the context of OSPF unless you define it as a Point to Multi Point in which case it will be treated as a NBMA link. The latter is useful if one desires to define one Virtual Port that connects to say thousands of remote SGWs (With all the inner SGW VP IP addresses belonging to one SUBnet emulating an NBMA network). Thus one can get away by defining one virtual port and one policy for all the remote sites if so desired at the minimum or individual definitions if granularity is the choice. Also the IPIP virtual port can be used without any SPDs such that one can tunnel across a shared IP infrastrucure. You will find that is also useful in repairing partitioned areas, extending areas, in OSPF etc. We also support the above IP routing protocols plus most all multiprotocol and their routing protocols using L2TP or PPTP Virtual port IPSec Transport mode on the underlying physical port. /sudeep From owner-ipsec@lists.tislabs.com Tue Sep 7 08:21:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA01028; Tue, 7 Sep 1999 08:21:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04632 Tue, 7 Sep 1999 09:30:23 -0400 (EDT) From: Mohan Parthasarathy Message-Id: <199909061735.KAA28101@locked.eng.sun.com> Subject: Re: IPSEC tunnels for LAN-to-LAN interop issue To: owner-ipsec@lists.tislabs.com (Waters, Stephen) Date: Mon, 6 Sep 1999 10:35:38 -0800 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE26F@new-exc1.ctron.com> from "Waters, Stephen" at Sep 6, 99 11:55:56 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm not sure BGP fixes the problem, for me. I want to be able to learn > Intranet routes from a remote peer, and populate a routing table with > next-hop information, where each next hop is associated with a particular > 'interface'; I want to detect when that 'interface' has failed so I can > re-route. > I read both your old model and the new model. How about the mix of two ? Virtual IP interface | IPIP tunnel 'device' - with default policy. | Real interface - associated SPD. Packets leaving the tunnel device will be subjected to the default policy only if there is no match in the SPD associated with the Real interface. What most people may want is some defualt policy e.g 3DES/SHA1 for the packets leaving the tunnel. But if you want per-port selectors etc., why can't there be policy entries in the SPD associated with the Real interface handle this. If transport, transport mode negotiated and applied and pakcet sent. If tunnel mode, tunnel mode negotiated, 'transport' mode applied pakcet sent. There is only one tunnel device with which the routing entries are associated with in this case. Detecting whether the path to the peer has failed can be done by running a failure detection algorithm over the tunnels. -mohan an From owner-ipsec@lists.tislabs.com Wed Sep 8 06:02:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA23030; Wed, 8 Sep 1999 06:02:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10749 Wed, 8 Sep 1999 06:58:18 -0400 (EDT) Message-Id: <199909081059.GAA05719@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt Date: Wed, 08 Sep 1999 06:59:08 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-RIPEMD-160-96 within ESP and AH Author(s) : A. Keromytis, N. Provos Filename : draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt Pages : 6 Date : 07-Sep-99 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.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-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.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: <19990907081904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990907081904.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Sep 9 04:30:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA25684; Thu, 9 Sep 1999 04:30:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15616 Thu, 9 Sep 1999 05:49:46 -0400 (EDT) Message-ID: <37D7833E.5E784D30@DataFellows.com> Date: Thu, 09 Sep 1999 12:51:58 +0300 From: Ari Huttunen Organization: Data Fellows Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: Best packet sniffer? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could you recommend a packet sniffer that can decode as much of the VPN-related protocol packets as possible? (IKE, ESP, AH, L2TP, PPTP, RADIUS, PPP, etc.) By decode I don't mean a hex dump ;-). -- Ari Huttunen GSM: +358 40 5524634 Senior Software Engineer fax : +358 9 859 90200 Data Fellows Corporation http://www.DataFellows.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Sep 9 05:25:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA26386; Thu, 9 Sep 1999 05:25:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15787 Thu, 9 Sep 1999 06:54:47 -0400 (EDT) Message-Id: <199909091055.GAA21477@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-xauth-05.txt Date: Thu, 09 Sep 1999 06:55:43 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Authentication Within ISAKMP/Oakley Author(s) : R. Pereira, S. Beaulieu Filename : draft-ietf-ipsec-isakmp-xauth-05.txt Pages : 17 Date : 08-Sep-99 This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol. The purpose of this draft is not to replace or enhance the existing authentication mechanisms described in [IKE], but rather to allow them to be extended using legacy authentication mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-xauth-05.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-ietf-ipsec-isakmp-xauth-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-05.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: <19990908122520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-xauth-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990908122520.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Sep 9 08:32:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA29093; Thu, 9 Sep 1999 08:32:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16299 Thu, 9 Sep 1999 09:45:44 -0400 (EDT) Message-ID: <37D7BB17.58B31F0D@ibm.net> Date: Thu, 09 Sep 1999 09:50:15 -0400 From: Mike Williams X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec CC: geblerp@us.ibm.com Subject: IPCOMP using DEFLATE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have been looking at using zlib as a source for the DEFLATE compression algorithm for IPCOMP. One of the things that we have noticed is that a "dictionary" can be used. Since there is no way to negotiate a compression dictionary with IKE, I am assuming that a dictionary is not used with DEFLATE within the scope of IPCOMP. Is this true? Are there any implementations that do use a dictionary with DEFLATE? I have also noticed that RFC2407 does define a "Compress Dictionary Size" attribute. How is this used? It seems like IKE would have to not only negotiate the dictionary size, but also the dictionary value for this to be useful. Mike Williams From owner-ipsec@lists.tislabs.com Thu Sep 9 22:34:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA15471; Thu, 9 Sep 1999 22:34:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18654 Fri, 10 Sep 1999 00:09:06 -0400 (EDT) To: Ari.Huttunen@datafellows.com Cc: ipsec@lists.tislabs.com, mshindo@ascend.co.jp Subject: Re: Best packet sniffer? In-Reply-To: <37D7833E.5E784D30@DataFellows.com> References: <37D7833E.5E784D30@DataFellows.com> X-Mailer: Mew version 1.94b47 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990910131024M.not@iri.co.jp> Date: Fri, 10 Sep 1999 13:10:24 +0900 (JST) From: Naoto MATSUMOTO X-Dispatcher: imput version 990731(IM118) Lines: 20 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mr. Huttunen > Could you recommend a packet sniffer that can decode > as much of the VPN-related protocol packets as possible? > (IKE, ESP, AH, L2TP, PPTP, RADIUS, PPP, etc.) ISAKMP and IPSec Real-time Protocol Analyzer http://www.mew.co.jp/e-netcocoon/analyzer.html Tcpdump L2TP patch http://www.note.iri.co.jp/vpn/data/tcpdump-l2tp.gz > By decode I don't mean a hex dump ;-). me too :p ----- IRI [Internet Research Institute,Inc.] Naoto MATSUMOTO From owner-ipsec@lists.tislabs.com Tue Sep 14 06:33:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA01900; Tue, 14 Sep 1999 06:33:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03360 Tue, 14 Sep 1999 07:30:05 -0400 (EDT) Message-Id: <199909141130.HAA28449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ecc-groups-01.txt Date: Tue, 14 Sep 1999 07:30:59 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Additional ECC Groups For IKE Author(s) : P. Panjwani, Y. Poeluev Filename : draft-ietf-ipsec-ike-ecc-groups-01.txt Pages : 8 Date : 13-Sep-99 This document describes new ECC groups for use in IKE [RFC2409] in addition to the Oakley groups included in RFC 2409. These groups are defined to align with other ECC implementations and standards, and in addition, some of them provide higher strength than the Oakley groups. It should be noted that this document is not self-contained. It uses the notations and definitions of [RFC2409]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-01.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-ietf-ipsec-ike-ecc-groups-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990913141118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ecc-groups-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990913141118.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Sep 14 09:54:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA05480; Tue, 14 Sep 1999 09:53:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04315 Tue, 14 Sep 1999 11:12:28 -0400 (EDT) Message-Id: <199909141513.KAA28018@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: ipsec@lists.tislabs.com Subject: Next Bakeoff Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Sep 1999 10:13:30 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings all, Last I heard, the group was looking to have the next bakeoff in the October timeframe. As that timeframe is fast approaching and I haven't seen any traffic regarding a bakeoff, is there one planned? Regards, Michael Carney From owner-ipsec@lists.tislabs.com Wed Sep 15 02:37:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA14933; Wed, 15 Sep 1999 02:37:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06888 Wed, 15 Sep 1999 04:02:21 -0400 (EDT) Message-Id: <37DF5308.D7CA2D68@radguard.com> Date: Wed, 15 Sep 1999 10:04:25 +0200 From: Rakefet Zadik Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: sbeaulieu@TimeStep.com Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Comments on the new Xauth draft Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello,   After reading the new draft, we have a few unclear points:   "All ISAKMP-Config messages in an extended authentication    transaction MUST contain the same ISAKMP-Config transaction    identifier.  The Message ID in the ISAKMP header follows the    rules defined by the ISAKMP-Config protocol."      As we understood from the thread held in ipsra, there was a    trend for making xauth its own exchange (separating it from    cfg). This draft does not reflect that understanding, furthermore    this draft seams to force xauth on cfg.    The message ID is used as a session identifier through out the    isakmp protocols.    Using the identifier as such causes inconsistency and seems    artificial.    Bonding two cfg transactions for an xauth session requires a    state machine for the receiver, which is a contradiction to the    cfg protocol. Now the receiver will first have to verify according    to the message-id, that the message received is    not a reply to a cfg it sent. After the decryption, another    verification according to the identifier will be needed.                 "If the IPSec host does not have support for the authentication     method requested by the edge device, then it would send back     a reply with empty attributes, thus failing the authentication     but completing the transaction. " -                                                       "Zero length attribute values are usually sent     in a Request and MUST NOT be sent in a Response."                              -                 There seems to be a contradiction.             "Extended Authentication MAY be initiated by the edge device     at any time after the initial authentication exchange." - This is     de facto changing the life duration of the main mode after the     main mode is finished, why not initiate a new main mode     instead?        Regards       Keren & Rakefet     From owner-ipsec@lists.tislabs.com Wed Sep 15 13:44:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA02712; Wed, 15 Sep 1999 13:44:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08572 Wed, 15 Sep 1999 14:42:40 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFDB66A5@exchange> From: Stephane Beaulieu To: ipsec Subject: FW: Comments on the new Xauth draft Date: Wed, 15 Sep 1999 14:46:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA08569 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, forgot to cc ipsec list on the reply. -----Original Message----- From: Stephane Beaulieu Sent: Wednesday, September 15, 1999 12:08 PM To: 'Rakefet Zadik' Subject: RE: Comments on the new Xauth draft > Hello, > >   After reading the new draft, we have a few unclear points: > >   "All ISAKMP-Config messages in an extended authentication >    transaction MUST contain the same ISAKMP-Config transaction >    identifier.  The Message ID in the ISAKMP header follows the >    rules defined by the ISAKMP-Config protocol." >   > >    As we understood from the thread held in ipsra, there was a >    trend for making xauth its own exchange (separating it from >    cfg). This draft does not reflect that understanding, furthermore >    this draft seams to force xauth on cfg. Yes, this was one of the proposals (proposal#2) that Joern had suggested in his post with subject named "XAUTH is broken", posted on Jul 22 1999. In the same thread, I had mentioned that I was in favor of this. However, I received many private emails from implementors who felt that Joern's proposal#1 from that same email was a better solution (including one email posted to the list by Tero). To that effect, I sent out another post named "the next rev of XAUTH" on August 3, 1999, in which I solicited input from the list on which of the two proposals we should proceed with. Sadly, I received no emails on the list itself. However, I did receive 3 private emails supporting Joern's first proposal (as well as Tero's earlier posting to the list). > >    The message ID is used as a session identifier through out the >    isakmp protocols. >    Using the identifier as such causes inconsistency and seems >    artificial. > >    Bonding two cfg transactions for an xauth session requires a >    state machine for the receiver, which is a contradiction to the >    cfg protocol. Now the receiver will first have to verify according >    to the message-id, that the message received is >    not a reply to a cfg it sent. After the decryption, another >    verification according to the identifier will be needed. >              Your ISAKMP state machine should handle the decryption process based on the Message ID. After that the isakmp-cfg state machine extracts the transaction identifier and the message type to determine whether this is a response or a new exchange. > >    "If the IPSec host does not have support for the authentication >     method requested by the edge device, then it would send back >     a reply with empty attributes, thus failing the authentication >     but completing the transaction. " - >                                           > >   > >        > >    "Zero length attribute values are usually sent >     in a Request and MUST NOT be sent in a Response." >                              -      > >            There seems to be a contradiction. >   Good point. Thanks. > >        >    "Extended Authentication MAY be initiated by the edge device >     at any time after the initial authentication exchange." - This is >     de facto changing the life duration of the main mode after the >     main mode is finished, why not initiate a new main mode >     instead? >        Why go through the process of re-doing MM if all you want to do is refresh user authentication? The reason for adding this is that many authentication servers allow you to give access to a user for a set period of time. If the user wishes to extend that time, then he needs to re-authenticate himself. Thanks for your input, Stephane. > > Regards >   >     Keren & Rakefet >   >   > From owner-ipsec@lists.tislabs.com Wed Sep 15 14:57:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA04386; Wed, 15 Sep 1999 14:57:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09014 Wed, 15 Sep 1999 16:22:03 -0400 (EDT) Message-ID: <37E0009F.96E330C5@redcreek.com> Date: Wed, 15 Sep 1999 13:25:03 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: ipsec Subject: Re: FW: Comments on the new Xauth draft References: <319A1C5F94C8D11192DE00805FBBADDFDB66A5@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane Beaulieu wrote: > > As we understood from the thread held in ipsra, there was a > > trend for making xauth its own exchange (separating it from > > cfg). This draft does not reflect that understanding, furthermore > > this draft seams to force xauth on cfg. > > Yes, this was one of the proposals (proposal#2) that Joern had suggested in > his post with subject named "XAUTH is broken", posted on Jul 22 1999. In > the same thread, I had mentioned that I was in favor of this. However, I > received many private emails from implementors who felt that Joern's > proposal#1 from that same email was a better solution (including one email > posted to the list by Tero). To that effect, I sent out another post named > "the next rev of XAUTH" on August 3, 1999, in which I solicited input from > the list on which of the two proposals we should proceed with. Sadly, I > received no emails on the list itself. However, I did receive 3 private > emails supporting Joern's first proposal (as well as Tero's earlier posting > to the list). This has been discussed in multiple threads, and I also thought there was general consensus for splitting xauth and isakmp-cfg. The only relationship between the two is that they may be applied to remote access clients, and I don't think this justifies the take-all leave-all option that binding the two presents. Scott From owner-ipsec@lists.tislabs.com Thu Sep 16 07:46:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA18237; Thu, 16 Sep 1999 07:46:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11440 Thu, 16 Sep 1999 08:38:03 -0400 (EDT) Message-Id: <4.1.19990915083205.00ae4f00@sj-email> Message-Id: <4.1.19990915083205.00ae4f00@sj-email> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 15 Sep 1999 09:02:55 -0700 To: ipsec@lists.tislabs.com From: Anita Freeman Subject: Next Bakeoff Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike and all, James Matheke, MCI Worldcom, and I are in the process of getting the date and location for the next workshop. We hope to have an email to this list within the next two weeks with the details. That being said, the workshop will not take place in October. We are looking at the January/February timeframe. Thanks, Anita Freeman > -----Original Message----- > From: Mike Carney [SMTP:carney@securecomputing.com] > Sent: Tuesday, September 14, 1999 11:14 AM > To: ipsec@lists.tislabs.com > Subject: Next Bakeoff > > Greetings all, > Last I heard, the group was looking to have the next bakeoff in the > October > timeframe. As that timeframe is fast approaching and I haven't seen any > traffic regarding a bakeoff, is there one planned? > > Regards, > Michael Carney > From owner-ipsec@lists.tislabs.com Fri Sep 17 07:36:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA07098; Fri, 17 Sep 1999 07:36:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15171 Fri, 17 Sep 1999 08:12:04 -0400 (EDT) Message-Id: <199909171203.IAA04152@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippcp@external.cisco.com, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-00.txt Date: Fri, 17 Sep 1999 08:02:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-00.txt Pages : 9 Date : 16-Sep-99 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-00.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-shacham-ippcp-rfc2393bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990916072154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990916072154.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Sep 17 10:14:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA09315; Fri, 17 Sep 1999 10:14:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15577 Fri, 17 Sep 1999 10:12:04 -0400 (EDT) Date: Fri, 17 Sep 1999 07:12:43 -0700 (PDT) From: Abraham Shacham To: ippcp@external.cisco.com, ipsec@lists.tislabs.com Subject: rfc2393bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Following the threads on ipsec and ippcp mailing lists since the publication of RFC2393 in December 1998, and the hallway discussion in Oslo with some of the ippcp mailing-list members, draft-shacham-ippcp-rfc2393bis-00.txt -- (ippcp wg exists no more, therefore no draft-ietf naming) -- intends to update RFC2393 with the following clarifications: 1. Payload definition in IPv4 A more detailed definition of the payload to be compressed in IPv4, including in IP encapsulation such as tunnel mode, while walking away from the term 'upper layer protocol' or 'ULP'. 2. IPv6 header order Clarifications of IPv6 header order. 3. Negotiations in the context of IPSec 3.1 Stating that IPCOMP can be negotiated stand-alone or bundled with other protocols. 3.2 CPI in SPI field of a proposal; two-octet field as SHOULD, and a MAY for 4-octet field; the location of the 16-bit CPI in a 4-octet field; plus, a MUST for the receiver to process both field sizes. 3.3 Definition of encapsulation mode in the context of DOI, including answering RFC2407 'host-dependent' default assumption when the encapsulation attribute isn't defined: Encapsulation Mode [...] If unspecified, the default value shall be assumed to be unspecified (host-dependent). 3.4 Pointing to the 'guidelines' of ISAKMP negotiations, without specifying details that aren't IPComp-specific, and without duplicating the content of other RFCs. 4. Language Some (minor) language-related changes. For the convenience of the reader, attached is the diff between RFC2393 and the draft. After the trimming of all style (draft vs. rfc) and paging related modifications, that diff is pretty short. Each section of the diff is marked with the related change(s) from the above list. For example, 126,128c129,136 === #1 === states that the diff section is related to change #1, i.e. payload definition in IPv4. As in the past, I do encourage RFC2393 related discussions to take place on the ippcp mailing-list, reachable at ippcp@external.cisco.com. Acknowledgment: Tim Jenkins contributed suggestions for this draft, thanks! Regards, avram 126,128c129,136 === #1 === < In IP version 4 [RFC-0791], the compression is applied to the upper < layer protocol (ULP) payload of the IP datagram. No portion of the < IP header or the IP header options is compressed. --- > In IP version 4 [RFC-0791], the compression is applied to the payload > of the IP datagram, starting at the first octet following the IP > header, and continuing through the last octet of the datagram. No > portion of the IP header or the IP header options is compressed. > Note: in the case of an encapsulated IP header (e.g., tunnel mode > encapsulation in IPSec), the datagram payload is defined to start > immediately after the outer IP header; accordingly, the inner IP > header is considered part of the payload and is compressed. 134c142 === #4 === < and processed by nodes along a packet's delivery path, if such IP --- > and processed by nodes along a packet's delivery path, if such an IP 158,160c166,168 === #1 === < If the total size of a compressed ULP payload and the IPComp header, < as defined in section 3, is not smaller than the size of the original < ULP payload, the IP datagram MUST be sent in the original non- --- > If the total size of a compressed payload and the IPComp header, as > defined in section 3, is not smaller than the size of the original > payload, the IP datagram MUST be sent in the original non- 258c260,262 === #2 === < MUST precede the IPComp header in the packet. --- > MUST precede the IPComp header in the packet. Note: other IPv6 > headers may be present between the IPv6 Fragment Header and the > IPComp header. 302c306 === #4 === < independently of each other and there is no relationships --- > independently of each other and there is no relationship 333,334c337,345 === #3, #4 === < necessary mechanisms to establish IPCA. IPComp Association is < negotiated by the initiator using a Proposal Payload, which would < include one or more Transform Payloads. The Proposal Payload would < specify a compression protocol in the protocol id field and each < Transform Payload would contain the specific compression method(s) < being offered to the responder. --- > necessary mechanisms and guidelines for establishing IPCA. Using > ISAKMP, IPComp can be negotiated as stand-alone or in conjunction > with other IPSec protocols. > > An IPComp Association is negotiated by the initiator using a Proposal > Payload, which includes one or more Transform Payloads. The Proposal > Payload specifies the IP Payload Compression Protocol in the protocol > ID field and each Transform Payload contains the specific compression > algorithm(s) being offered to the responder. > > The CPI is sent in the SPI field of the proposal, with the SPI size > field set to match. The CPI SHOULD be sent as a 16-bit number, with > the SPI size field set to 2. Alternatively, the CPI MAY be sent as a > 32-bit value, with the SPI size field set to 4. In this case, the > 16-bit CPI number MUST be placed in the two least significant octets > of the SPI field, while the two most significant octets MUST be set > to zero, and MUST be ignored by the receiving node. The receiving > node MUST be able to process both forms of the CPI proposal. 351c369,372 === #3 === < Identifiers. --- > Identifiers. To suggest a non-default Encapsulation Mode (such as > Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode > attribute. If the Encapsulation Mode is unspecified, the default > value of Transport Mode is assumed. 356c377 === #4 === < than ISAKMP. Such protocol is beyond the scope of this document. --- > than ISAKMP. Such a protocol is beyond the scope of this document. === eom === From owner-ipsec@lists.tislabs.com Thu Sep 23 13:53:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA17896; Thu, 23 Sep 1999 13:53:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06164 Thu, 23 Sep 1999 14:44:30 -0400 (EDT) Message-ID: <37EA7479.B45C1F34@raptor.com> Date: Thu, 23 Sep 1999 14:42:01 -0400 From: Rafal Boni Organization: Raptor Systems Engineering X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Abraham Shacham CC: ippcp@external.cisco.com, ipsec@lists.tislabs.com Subject: Re: rfc2393bis References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Abraham Shacham wrote: > 3.2 CPI in SPI field of a proposal; two-octet field as SHOULD, > and a MAY for 4-octet field; the location of the 16-bit CPI in > a 4-octet field; plus, a MUST for the receiver to process both > field sizes. If as the initiator, I'm proposing (for example), Proposal #1 PROTO=PROTO_IPCOMP, SPI size=2 (octets), SPI=?? transform #1, transform_id IPCOMP_DEFLATE transform #2, transform_id IPCOMP_LZS, what do I send in the SPI field? I thought the point here was to send the "well known" CPI for one of the transforms I propose (which would work if there were only one transform), but since I'm proposing one or the other, am I basically restricted to using the 256-61439 range of CPIs in this case? Thanks! --rafal -- Rafal Boni rafal@raptor.com Raptor Systems, Waltham, MA http://www.raptor.com/ 781.530.2200 From owner-ipsec@lists.tislabs.com Fri Sep 24 01:17:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA08868; Fri, 24 Sep 1999 01:17:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08054 Fri, 24 Sep 1999 02:36:34 -0400 (EDT) Message-ID: <729D927EF825D311961000E029101CCC258CB1@mxclsa> From: Black_David@emc.com To: ipsec@lists.tislabs.com Subject: Unsupported DOI attributes and values Date: Fri, 24 Sep 1999 02:39:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the discussion of IPsec-ECN interactions in Oslo, a concern was raised about how to deal with implementations that don't support negotiating the new SA attribute. The suggestion was made that any proposal that includes the new attribute be accompanied by one that does not, so that an implementation that does not support the new attribute can select a proposal that does not contain it. OTOH, the DOI (RFC 2407) says: 4.5.3 Attribute Negotiation If an implementation receives a defined IPSEC DOI attribute (or attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted, unless the attribute value is in the reserved range. This appears to require that detection of an unsupported attribute or value causes the entire SA negotiation to fail. This seems less than ideal, as it means that any use of an attribute or value unsupported by the recipient fails to create an SA, at which point one has to figure out why and formulate new proposals that don't contain the offending attribute or value. At best this is inefficient, and could lead to lack of interoperability as I haven't found any guidance in the RFCs as to how to formulate such new proposals. Surely, receipt of proposals containing unsupported attributes and values happens in practice -- what are IPsec implementations actually doing when this happens? If there's a concern about answering this question on the list, feel free to email me directly, and I'll summarize the results without identifying who's doing what. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com --------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Sep 24 11:43:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA21132; Fri, 24 Sep 1999 11:43:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13011 Fri, 24 Sep 1999 13:01:15 -0400 (EDT) Message-Id: <199909241658.JAA17016@gallium.network-alchemy.com> To: Black_David@emc.com cc: ipsec@lists.tislabs.com Subject: Re: Unsupported DOI attributes and values In-reply-to: Your message of "Fri, 24 Sep 1999 02:39:34 EDT." <729D927EF825D311961000E029101CCC258CB1@mxclsa> Date: Fri, 24 Sep 1999 09:58:49 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >The suggestion was made that any proposal that includes the new attribute be >accompanied by one that does not, so that an implementation that does not >support the new attribute can select a proposal that does not contain it. A reasonable suggestion. If there are no objections, I'll ammend Section 4.5.3 to say that instead of aborting the entire negotiation, the requirement is that proposals containing unknown attributes MUST not be accepted. In practice, unknown attributes haven't been a problem at the bake-offs. Derrell From owner-ipsec@lists.tislabs.com Sun Sep 26 15:16:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12769; Sun, 26 Sep 1999 15:16:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17881 Sun, 26 Sep 1999 16:33:33 -0400 (EDT) Message-Id: <199909262031.NAA17908@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 26 Sep 1999 13:33:46 -0700 To: Rafal Boni From: Avram Shacham Subject: Re: rfc2393bis Cc: ippcp@external.cisco.com, ipsec@lists.tislabs.com In-Reply-To: <37EA7479.B45C1F34@raptor.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rafal, You may set your SPI to be one of the well-known CPI values, if it is legitimate to express your example as two proposals -- Proposal #1 PROTO=PROTO_IPCOMP, SPI size=2 (octets), SPI=IPCOMP_DEFLATE transform #1, transform_id IPCOMP_DEFLATE Proposal #2 PROTO=PROTO_IPCOMP, SPI size=2 (octets), SPI=IPCOMP_LZS transform #1, transform_id IPCOMP_LZS, I couldn't locate where rfc2408 prohibits the above, but I might have simply missed something. In any case, when the original proposal contains more than one compression transform, the SPI (CPI) has to be in the negotiated range, and, in that scenario, the extra step of converting the CPI to the actual algorithm-id is required. The responder may still use the well-known value as its CPI. avram At 02:42 PM 9/23/99 -0400, Rafal Boni wrote: >Abraham Shacham wrote: >> 3.2 CPI in SPI field of a proposal; two-octet field as SHOULD, >> and a MAY for 4-octet field; the location of the 16-bit CPI in >> a 4-octet field; plus, a MUST for the receiver to process both >> field sizes. > >If as the initiator, I'm proposing (for example), > Proposal #1 PROTO=PROTO_IPCOMP, SPI size=2 (octets), SPI=?? > transform #1, transform_id IPCOMP_DEFLATE > transform #2, transform_id IPCOMP_LZS, > >what do I send in the SPI field? I thought the point here was to >send the "well known" CPI for one of the transforms I propose (which >would work if there were only one transform), but since I'm proposing >one or the other, am I basically restricted to using the 256-61439 >range of CPIs in this case? > >Thanks! >--rafal From owner-ipsec@lists.tislabs.com Mon Sep 27 16:02:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA09695; Mon, 27 Sep 1999 16:02:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21977 Mon, 27 Sep 1999 17:16:36 -0400 (EDT) Date: Tue, 28 Sep 1999 00:18:28 +0300 (EET DST) Message-Id: <199909272118.AAA24594@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Black_David@emc.com Cc: ipsec@lists.tislabs.com Subject: Unsupported DOI attributes and values In-Reply-To: <729D927EF825D311961000E029101CCC258CB1@mxclsa> References: <729D927EF825D311961000E029101CCC258CB1@mxclsa> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 0 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com writes: > This appears to require that detection of an unsupported attribute or value > causes the entire SA negotiation to fail. This seems less than ideal, > as it means that any use of an attribute or value unsupported by the > recipient fails to create an SA, at which point one has to figure > out why and formulate new proposals that don't contain the offending > attribute or value. At best this is inefficient, and could lead to > lack of interoperability as I haven't found any guidance in the RFCs > as to how to formulate such new proposals. There is some text about that in my draft-ietf-ipsec-ike-ext-meth-02.txt saying (see the 12.1 first paragraph): ---------------------------------------------------------------------- 12. Data Attribute Types and Values SA payloads and some other payloads in the ISAKMP contain data attributes. Data attribute consists of an attribute type and a value. The data attribute type and value number spaces are divided into two parts: The IANA range and the private-use range. The phase 1 data attribute types and values are defined in the IKE document and ISAKMP documents. This part should probably be separated from those documents to separate IKE DOI. The Phase 2 data attributes are defined in the DOI [RFC-2407] document. The private-use data attribute TYPES can be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values the sender is using. When adding new IANA registered data attribute TYPES the minor version number of the protocol SHOULD NOT be updated. When adding new IANA registered data attribute TYPES the phase 1 transform identifier MAY be updated. The private-use data attribute VALUES can also be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values sender is using. When adding new IANA registered data attribute VALUES the minor version number of the protocol SHOULD NOT be updated. When adding new IANA registered data attribute VALUE the phase 1 transform identifier MAY be updated. 12.1. Data Attributes, Protocol and Transform IDs The proposal or transform payload MUST NOT be selected by the responder if it contains unknown protocol IDs, transform IDs, data attribute types, or data attribute values. This means that an initiator SHOULD always include a proposal without any private-use types or values so that if the other end does not understand them then it may select the transform or proposal without private-use types or values. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 28 14:32:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA01720; Tue, 28 Sep 1999 14:32:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26158 Tue, 28 Sep 1999 15:59:12 -0400 (EDT) Message-Id: <199909281959.MAA23397@Potassium.Network-Alchemy.COM> To: ipsec@lists.tislabs.com cc: sbeaulieu@TimeStep.com, rpereira@TimeStep.com Subject: New XAUTH draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23394.938548791.1@network-alchemy.com> Date: Tue, 28 Sep 1999 12:59:51 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane, Roy, I have some suggested text for the new XAUTH draft (-05.txt). Section 2 (Extended Authentication Model) includes this: The Extended Authentication mechanism does not replace the IKE Phase 1 authentication mechanisms. It simply extends them by allowing devices to do two different authentication schemes. Both peers SHOULD still authenticate each other via the authentication methods described in [IKE]. This really has to be a MUST. There is absolutely no reason why the IPSec WG (which is, after all, in the Security Area of the IETF) should allow an unauthenticated key exchange. Also, the mechanism described in this draft does not effect the authenticated status of the IKE SA in any way. It is not an extension of it as it does not add anything to the security of the IKE exchange. I suggest changing this to: The Extended Authenticated mechanism does not effect the authenticated nature of a phase 1 security association in any way. Both peers MUST authenticate each other via the authentication methods described in [IKE]. There are Security Considerations involved in one of the authentication methods in [IKE] and this is described in section 6. Secction 6 (Security Considerations) includes this paragraph: The use of Extended Authentication does not imply that phase 1 authentication is no longer needed. Phase 1 authentication provides a higher level of user authentication by signing ISAKMP packets. Extended Authentication does not provide this service. The removal or weakening of phase 1 authentication would leave the IPSec session vulnerable to a man-in-the-middle attack and other spoofing attacks. Therefore, when using Extended Authentication with Pre- Shared keys, it is vital that the Pre-Shared key be well chosen and secure. which severely understates the purpose of IKE authentication and goes on to assume a "well chosen" pre-shared key is appropriate for phase 1 authentication. Authentication of the IKE SA is not just for "signing ISAKMP packets." It is what binds the peers to their keying material and therefore what makes the resulting IPSec SAs authenticated. Without true authentication of the phase 1 SA the IPSec SAs are esentially unauthenticated. This can happen when one uses pre-shared key authentication with remote-access clients whose IP addresses cannot be know a priori. I would like to see that complete paragraph replaced with this: As mentioned in section 2, the protocol described in this memo does not effect the authenticated nature of the phase 1 security association in any way. An unauthenticated phase 1 security association could only create unauthenticated phase 2 security associations (e.g. IPSec security associations) regardless of the presence or absence of this protocol between a phase 1 and phase 2 exchange. Due to restrictions in [IKE] regarding the use of Main Mode and pre-shared keys this protocol MUST NOT be used with [IKE] when doing Main Mode and pre-shared key authentication. Further, it MUST NOT be used with any key exchange protocol in which the parties to the exchange authenticate each other using a "group" pre-shared key (i.e. one that is shared by more than the two parties to the exchange). thanks, Dan. From owner-ipsec@lists.tislabs.com Tue Sep 28 18:17:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA05262; Tue, 28 Sep 1999 18:17:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26637 Tue, 28 Sep 1999 19:50:22 -0400 (EDT) Message-ID: <37F1555D.273BFA71@intotoinc.com> Date: Tue, 28 Sep 1999 16:55:10 -0700 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Compression algorithms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, IPDOI is defining LZS and DEFLATE compression algorithms, apart from proprietary algorithms. Is DEFLATE algorithm supported by the majority of IPSEC vendors? Thanks Srini From owner-ipsec@lists.tislabs.com Tue Sep 28 18:33:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA06282; Tue, 28 Sep 1999 18:33:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26752 Tue, 28 Sep 1999 20:25:28 -0400 (EDT) Message-ID: <002201bf0a11$cfbaa260$7701a8c0@root94.oullim.co.kr> From: "Root Shin" To: Subject: Hello Date: Wed, 29 Sep 1999 09:30:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id UAA26749 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I subscribed mailing-list yesterday. I am programmer and, I am novice about IPSec. Now I am going to try to programming VPN. Can anybody advice to me ... From owner-ipsec@lists.tislabs.com Wed Sep 29 04:03:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA24658; Wed, 29 Sep 1999 04:03:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA28163 Wed, 29 Sep 1999 05:27:18 -0400 (EDT) Message-ID: <37F1DC0F.3660339E@checkpoint.com> Date: Wed, 29 Sep 1999 11:29:51 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: New XAUTH draft References: <199909281959.MAA23397@Potassium.Network-Alchemy.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > Stephane, Roy, > > I have some suggested text for the new XAUTH draft (-05.txt). > > Section 2 (Extended Authentication Model) includes this: > > The Extended Authentication mechanism does not replace the IKE > Phase 1 authentication mechanisms. It simply extends them by > allowing devices to do two different authentication schemes. Both > peers SHOULD still authenticate each other via the authentication > methods described in [IKE]. > > This really has to be a MUST. There is absolutely no reason why the IPSec > WG (which is, after all, in the Security Area of the IETF) should allow > an unauthenticated key exchange. Also, the mechanism described in this > draft does not effect the authenticated status of the IKE SA in any way. > It is not an extension of it as it does not add anything to the security > of the IKE exchange. I suggest changing this to: > > The Extended Authenticated mechanism does not effect the authenticated > nature of a phase 1 security association in any way. Both peers MUST > authenticate each other via the authentication methods described > in [IKE]. There are Security Considerations involved in one of the > authentication methods in [IKE] and this is described in section 6. > > Secction 6 (Security Considerations) includes this paragraph: > > The use of Extended Authentication does not imply that phase 1 > authentication is no longer needed. Phase 1 authentication provides > a higher level of user authentication by signing ISAKMP packets. > Extended Authentication does not provide this service. The removal > or weakening of phase 1 authentication would leave the IPSec > session vulnerable to a man-in-the-middle attack and other spoofing > attacks. Therefore, when using Extended Authentication with Pre- > Shared keys, it is vital that the Pre-Shared key be well chosen and > secure. > > which severely understates the purpose of IKE authentication and goes > on to assume a "well chosen" pre-shared key is appropriate for phase 1 > authentication. > > Authentication of the IKE SA is not just for "signing ISAKMP packets." > It is what binds the peers to their keying material and therefore what > makes the resulting IPSec SAs authenticated. Without true authentication > of the phase 1 SA the IPSec SAs are esentially unauthenticated. This can > happen when one uses pre-shared key authentication with remote-access > clients whose IP addresses cannot be know a priori. > > I would like to see that complete paragraph replaced with this: > > As mentioned in section 2, the protocol described in this memo does > not effect the authenticated nature of the phase 1 security association > in any way. An unauthenticated phase 1 security association could only > create unauthenticated phase 2 security associations (e.g. IPSec security > associations) regardless of the presence or absence of this protocol > between a phase 1 and phase 2 exchange. > > Due to restrictions in [IKE] regarding the use of Main Mode and > pre-shared keys this protocol MUST NOT be used with [IKE] when > doing Main Mode and pre-shared key authentication. Further, it MUST > NOT be used with any key exchange protocol in which the parties > to the exchange authenticate each other using a "group" pre-shared key > (i.e. one that is shared by more than the two parties to the exchange). > > thanks, > > Dan. I agree with your disapproval of the use of a key shared by more than two parties during Phase 1. This kind of modus operandi is even worse than standard pre-shared key authentication which is already weak. However, I do not think we need to mandate that Phase 1 authenticates both parties: For protection against man in the middle attacks it is sufficient for only one peer to be authenticated. For the remote user to trust the security gateway before divulging his credentials in XAUTH it is sufficient that the edge device is authenticated. Therefore, it seems that the demand for mutual Phase 1 authentication prior to XAUTH can be relaxed and replaced with the demand that only the edge device be authenticated. While asymmetric Phase 1 authentication with pre-shared keys seems unreasonable, the draft must not rule out asymmetric Phase 1 authentication using signatures. Regards, Tamir. From owner-ipsec@lists.tislabs.com Wed Sep 29 07:19:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA26365; Wed, 29 Sep 1999 07:19:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28689 Wed, 29 Sep 1999 08:38:16 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE399@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Wed, 29 Sep 1999 13:36:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Due to restrictions in [IKE] regarding the use of Main Mode and pre-shared keys this protocol MUST NOT be used with [IKE] when doing Main Mode and pre-shared key authentication. Further, it MUST NOT be used with any key exchange protocol in which the parties to the exchange authenticate each other using a "group" pre-shared key (i.e. one that is shared by more than the two parties to the exchange)." Dan, I think this is too restrictive. What if I decide to use main-mode/pre-shared for device level authentication, and XAUTH for user-level authentication? Also, the part about using a "group" pre-shared key is a policy decision, in my view. If the user/manager is happy with the security policy protecting a "group" pre-shared key, that should be his policy decision, not ours. It may be worth some text in the 'Security Considerations', but I don't think this should even be a "SHOULD" in the protocol itself. Cheers, Steve. From owner-ipsec@lists.tislabs.com Wed Sep 29 15:50:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA03832; Wed, 29 Sep 1999 15:50:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00629 Wed, 29 Sep 1999 16:59:36 -0400 (EDT) Message-Id: <199909292055.NAA25433@Potassium.Network-Alchemy.COM> To: "Waters, Stephen" cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Wed, 29 Sep 1999 13:36:53 BST." <29752A74B6C5D211A4920090273CA3DCCDE399@new-exc1.ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25430.938638512.1@network-alchemy.com> Date: Wed, 29 Sep 1999 13:55:12 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A policy decision? I guess everything could be called a policy decision but we're trying to build _secure_ protocols here. No one is being stopped from doing something insecure. If they're happy with insecurity (e.g. if they have a stated policy that an unauthenticated Diffie-Hellman is fine) they can do it without IKE. And there are other examples of mandating secure behavior (which could easily be called "a policy decision") in our various documents so I don't see this restrictive. What do you gain by allowing patently insecure use of a security protocol? Dan. On Wed, 29 Sep 1999 13:36:53 BST you wrote > > "Due to restrictions in [IKE] regarding the use of Main Mode and > pre-shared keys this protocol MUST NOT be used with [IKE] when > doing Main Mode and pre-shared key authentication. Further, it MUST > NOT be used with any key exchange protocol in which the parties > to the exchange authenticate each other using a "group" pre-shared key > (i.e. one that is shared by more than the two parties to the exchange)." > > > Dan, I think this is too restrictive. What if I decide to use > main-mode/pre-shared for device level authentication, and XAUTH for > user-level authentication? > > Also, the part about using a "group" pre-shared key is a policy decision, in > my view. If the user/manager is happy with the security policy protecting a > "group" pre-shared key, that should be his policy decision, not ours. It > may be worth some text in the 'Security Considerations', but I don't think > this should even be a "SHOULD" in the protocol itself. > > Cheers, Steve. From owner-ipsec@lists.tislabs.com Wed Sep 29 16:44:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA04647; Wed, 29 Sep 1999 16:44:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00802 Wed, 29 Sep 1999 18:22:11 -0400 (EDT) Message-ID: <729D927EF825D311961000E029101CCC258CD5@mxclsa> From: Black_David@emc.com To: kivinen@ssh.fi, Black_David@emc.com Cc: ipsec@lists.tislabs.com Subject: RE: Unsupported DOI attributes and values Date: Wed, 29 Sep 1999 18:24:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There is some text about that in my > draft-ietf-ipsec-ike-ext-meth-02.txt saying (see the 12.1 first > paragraph): > [snip] > 12.1. Data Attributes, Protocol and Transform IDs > > The proposal or transform payload MUST NOT be selected by the responder > if it contains unknown protocol IDs, transform IDs, data attribute > types, or data attribute values. > > This means that an initiator SHOULD always include a proposal without > any private-use types or values so that if the other end does not > understand them then it may select the transform or proposal without > private-use types or values. I like that text - I'll put something approximating it into the ipsec-ecn document (we're dealing with a new IANA allocated attribute and its values) and trust that Derrell will get RFC 2407 updated accordingly. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com --------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Sep 29 23:39:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id XAA24113; Wed, 29 Sep 1999 23:39:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA01628 Thu, 30 Sep 1999 00:59:45 -0400 (EDT) Message-Id: <199909300500.WAA11469@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 29 Sep 1999 22:02:53 -0700 To: Sankar Ramamoorthi From: Avram Shacham Subject: RE: rfc2393bis - request for developers' insight Cc: ippcp@external.cisco.com, ipsec@lists.tislabs.com, Will Price , Tim Jenkins , Paul Koning , Shawn Mamros , Rafal Boni , PJ Kirner , Sashidhar Annaluru , kasper.langkilde@i-data.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar, [The thread-in-progress is now CC-ed to the ippcp and ipsec lists.] See my comments inline. Regards, avram >>At 03:48 PM 9/28/99 -0700, Sankar Ramamoorthi wrote: >>> >>>My 2 cents. >>> >>>During the Santa Barbara bakeoff one of the interoperability issues was >>>with with the attributes that must be sent with the IPCOMP protocol when >>>negotiating a SA bundle. >>> >>>Section 4.1 of your draft seems to imply that only attribute that needs to >>>be set with IPCOMP protocol is 'Encapsulation mode'. >> >>Yes, that attribute seems the only one required to define IPCOMP. > >Agreed. > >> >>However, the same section starts with the overall statement: >> For IPComp in the context of IP security, ISAKMP provides the >> necessary mechanisms and guidelines for establishing IPCA. >> >>The generic phrase 'and guidelines' was added to let implementations >>comply with requirements, set by the negotiation-protocol, such as >>those that you quoted, but without duplicating the content of other RFCs. >> >>>What about other attributes >>>like lifetime, PFS? Should they be specified as well? >> >>imo, these attributes have no relation to IPCOMP. >>To rephrase the issue, if a compression algorithm requires >>an attribute, say DICTIONARY_SIZE, are AH and ESP expected >>to include that attribute in their proposals? >> >>That said, if -- in reality -- without those attributes it is going to be >>impossible to negotiate IPCOMP in IPSec, then see my remark above >>regarding 'guidelines'. >> >>>This confusion arises because IKE RFC states in section 5.5 >>>'All offers made during a Quick mode are logically related and must be >>>consistent. For example, if a KE payload is sent, the attribute describing >>>the >>>Diffe-Hellman group MUST be included in every transform of every SA being >>>negotiated'. >> >>Indeed, RFC2409 states the above in section 5.5, and almost the very same >>statement is included in the latest version >> >> >> All offers made during a Quick Mode are logically related and MUST be >> consistent. For example, if a KE payload is send the attribute >> describing the Diffie-Hellman group (see section 5 and [Pip98]) MUST >> be included in every transform of every proposal of every SA being >> negotiated. >> >>The only difference is that 'must' became 'MUST' . >> >>>Later Dan Harkins clarfied the above statement applies only to AH and ESP, >>>and it is upto IPCOMP document to specify the attributes that need be sent >>>with the transform payload. >> >>Could you point me to Dan's clarifications in that matter? > >I think it was disucssed in the meeting held during the bakeoff. >I have pulled out the mail that Dan posted after the bakeoff. > > >---------------------------------------------------------------------------- >---- > >To: ipsec@lists.tislabs.com >Subject: issues from the bakeoff >From: Dan Harkins >Date: Tue, 15 Jun 1999 12:54:40 -0700 >Sender: owner-ipsec@lists.tislabs.com > >---------------------------------------------------------------------------- >---- > > There was an IPSec + L2TP (and PPoE too) bakeoff the week of May 24th. >As usual there were issues in interoperability that came up and I'm >presenting them to the list. Not too surprisingly there were no issues >with interoperability of the IPSec protocols, it's all IKE. Also there >were several IPPCP issues that I'll summarize although they're being >taken care of in a different working group in a different area. > > I'll mention the general consensus of people at the bakeoff but that's >just as a starting point for discussion. The resolution (if any) of these >issues is work for this group. Please comment to the list. > > thanks, > > Dan. > >-------------------------------------------------------------------------- > >... >... Lots of lines deleted >... > >IP Payload Compresion Protocol (PCP) Issues: > > As I said, these aren't IPSec WG issues but people are using IKE to >negotiate PCP and these things came up. The appropriate WG needs >to deal with these. > > - IKE requires consistent attributes accross Quick Mode negotiation. >For instance, when doing PFS the group must be in all offers and it has to be >the same group. > What about PCP? Since it has no keys does it need a group >definition if the accompanying IPSec SAs will have PFS? > > - Do lifetimes in PCP SAs make sense to negotiate? If so, does a KB >lifetime expire on pre- or post-compressed data? > > - Is it valid to pass a SPI (actually a CPI in PCP) of zero? Is this >the "well known CPI"? > > - A CPI is two bytes. Is it OK to send a 4 byte one and have the >upper two bytes be zero? > > - A PCP RFC seems to say that tunnel mode processing is not >possible. Is this true? The clarifications in rfc23943bis are addressing the above issues, among other questions that were discussed on the lists. (btw, I did answer most of these points in a reply to the list.) However, the 'waiver' for non AH/ESP protocols, i.e. IPCOMP, isn't included there. >---------------------------------------------------------------------------- >---- > > >> >>>It would be nice if the document can clarify how IPCOMP is supposed to >>>be set up along with ESP and AH when negotiating an IPSEC SA bundle. >> >>If the above clarifications aren't enough, what else is needed? > >IMO, > >Explicit statement in IKE document to say that attributes specific >to protocols other than AH and ESP should be refered to the appropritate >protocol specific document. Agreed. But, will that change to IKE occur? >In IPPCP document state explicitly the attributes that are relevant >to IPPCP while using ISAKMP. The new Encapsulation Mode clause in rfc2393bis is addressing that exact concern. >A few lines about the transform attributes >to be set while using SA bundles along with reference to IKE >document would be nice. OK. >As it stands IPCOMP with IKE is confusing w.r.to SA bundles. >I believe that IKE document is the right place for some of the >explanation about attributes in a SA bundle. >Otherwise it leads to differing implementations. Agreed, with the same question mark as before. >Some flavors of SA bundle negotiation seen during the bakeoff were > >On sending side > >. Some implementations duplicate all attributes for AH, ESP and IPCOMP >. Some set only Encapsulation mode for IPCOMP transform >. Some implementations duplicate all attributes for AH and ESP and > do not set any for IPCOMP. The reason for that was no attribute > for IPCOMP was defined. > >On receiving side. > >. Some implementations were ignoring attributes for IPCOMP, instead > relying on the attributes from the AH/ESP transform in the SA bundle > >. Some implementations were rejecting the negotiation if encapsualtion > mode was not set and if not the same as the attributes in other > transforms. If the IKE doc is changed to reflect the suggested IPCOMP waiver, most of the above issues are going to be resolved without modifying rfc2393bis. If IKE's language stays, I'd suggest adding the following content to the existing section 4.1 - (a) When IPCOMP is part of SA bundle, the sending side MUST duplicate all attributes for AH, ESP, and IPCOMP, in order to comply with IKE. (b) The receiver MUST ignore all attributes that are not required for IPCOMP, i.e. all but Encapsulation Mode. Alternatives? Comments? ==== From owner-ipsec@lists.tislabs.com Thu Sep 30 00:45:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA29414; Thu, 30 Sep 1999 00:45:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01794 Thu, 30 Sep 1999 02:18:40 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: WWW based IPSec/IKE interoperability test sites X-Mailer: Mew version 1.94b42 on XEmacs 20.4 (Emerald) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990930152022A.korekawa@rinfo.sei.co.jp> Date: Thu, 30 Sep 1999 15:20:22 +0900 From: Norio Korekawa X-Dispatcher: imput version 990623(IM117) Lines: 14 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could anyone let me know some good WWW based IPSec/IKE interoperability test sites? I only know the following two sites, SSH and NIST at the moment. http://isakmp-test.ssh.fi http://ipsec-wit.antd.nist.gov Is there any other site? --- Norio Korekawa SUMITOMO ELECTRIC INDUSTRIES URL: http://www.sei.co.jp TEL +81 6 6466 5643 E-Mail: korekawa@rinfo.se.co.jp FAX +81 6 6466 5732 From owner-ipsec@lists.tislabs.com Thu Sep 30 05:24:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA14038; Thu, 30 Sep 1999 05:24:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA02428 Thu, 30 Sep 1999 06:50:12 -0400 (EDT) Message-ID: <37F3405B.FE620425@indusriver.com> Date: Thu, 30 Sep 1999 06:50:04 -0400 From: Ben McCann X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <199909281959.MAA23397@Potassium.Network-Alchemy.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Would you comment on Tamir's reply about asymmetric authentication in IKE: > I agree with your disapproval of the use of a key shared by more than > two parties during Phase 1. This kind of modus operandi is even worse > than standard pre-shared key authentication which is already weak. > > However, I do not think we need to mandate that Phase 1 authenticates > both parties: For protection against man in the middle attacks it is > sufficient for only one peer to be authenticated. For the remote user > to trust the security gateway before divulging his credentials in > XAUTH it is sufficient that the edge device is authenticated. > Therefore, it seems that the demand for mutual Phase 1 authentication > prior to XAUTH can be relaxed and replaced with the demand that only > the edge device be authenticated. While asymmetric Phase 1 > authentication with pre-shared keys seems unreasonable, the draft must > not rule out asymmetric Phase 1 authentication using signatures. Doesn't XAUTH combined with Tamir's assymetric Hybrid-Auth proposal provide a defense against man in the middle attacks? If it doesn't, please describe the attack. Otherwise, shouldn't we be discussing XAUTH _and_ hybrid-auth as the solution to this problem? My customer's are insisting that they want compatibility with legacy authentication mechanisms as they incrementally roll out PKI. (Some may never use PKI due to substantial investments in token cards). While I agree PKI is best, it is not my position to force my customers to adopt a technology they don't think they need. And they may be right. The customer should have a range of options for user authentication that match the value of their information and network access versus the cost of the authentication infrastructure. As an analogy, a bank doesn't need a vault with 4 foot thick steel walls and biometric authentication if their total deposits on hand are only $1000. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu Sep 30 07:57:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA17028; Thu, 30 Sep 1999 07:57:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03125 Thu, 30 Sep 1999 09:28:59 -0400 (EDT) Date: Thu, 30 Sep 1999 16:30:54 +0300 (EET DST) From: Markku Savela Message-Id: <199909301330.QAA23101@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com Subject: ICMP errors to IPSECed data? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In my implementation I have done the receive IPSEC processing "in place" (replacing crypted data with clear data) before passing it to the upper layer (TCP/UDP). Now it just occurs to me, that this is a potential security leak if the upper layer generates ICMP (such as port unreachable) and copies the received packet to the ICMP (especially in IPv6, where much more of the packet is copied). It is possible to have a policy that requires protection for specific UDP/port combo, and a different policy for ICMPs (like no encryption). Just wandering how this is actually solved by others? - keep the original packet untouched (and have require upper layers to be aware of this and have them use the original packet in their ICMP replies) [Not very tempting, as I don't like duplicating the buffer space requirement just for possible error situation] - have some "marker" on the packet, which stops the copying for such ICMP messages, - require that the policy writer is aware of such potential "leak" and specifies proper IPSEC for ICMP too [but, you could have high security on UDP(port=x) and some lower security for UDP(port=y), which one you specify for a possible ICMP] - should ICMP error messages actually get the security from a policy that matches the returned packet they are trying to report? [e.g. instead of matching ICMP to the selectors, match the contained packet instead (feels a bit complex and kludgy)] Has this issue been discussed? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Sep 30 08:02:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17088; Thu, 30 Sep 1999 08:02:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03159 Thu, 30 Sep 1999 09:34:33 -0400 (EDT) Date: Thu, 30 Sep 1999 16:36:27 +0300 (EET DST) From: Markku Savela Message-Id: <199909301336.QAA24655@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com Subject: ICMP errors to IPSECed data? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just noticed, is the chapter 6 in RFC-2401 actually indicating that following should happen? > - should ICMP error messages actually get the security from a policy > that matches the returned packet they are trying to report? > [e.g. instead of matching ICMP to the selectors, match the > contained packet instead (feels a bit complex and kludgy)] -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Sep 30 08:11:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA17235; Thu, 30 Sep 1999 08:11:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03173 Thu, 30 Sep 1999 09:36:34 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 14:33:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not suggesting that anyone should be happy with insecurity. My point was that there are ways to make the distribution of group pre-shared secrets secure, and if that is the policy adopted by a customer, the protocol should not prevent that. I am not saying pre-shared is 'great', and group-pre-shared is obviously n times more risky, but if the customer manages these risks effectively, the choice is his. There is no difference to the IKE protocol which is used, so it has no business (IMHO) mandating one over the other, and has no way of restricting it anyway. I think this is a small issue of wording. I'm agreeing that recommendations could be made and discussed in the draft. Cheers, Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] Sent: Wednesday, September 29, 1999 9:55 PM To: Waters, Stephen Cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft A policy decision? I guess everything could be called a policy decision but we're trying to build _secure_ protocols here. No one is being stopped from doing something insecure. If they're happy with insecurity (e.g. if they have a stated policy that an unauthenticated Diffie-Hellman is fine) they can do it without IKE. And there are other examples of mandating secure behavior (which could easily be called "a policy decision") in our various documents so I don't see this restrictive. What do you gain by allowing patently insecure use of a security protocol? Dan. On Wed, 29 Sep 1999 13:36:53 BST you wrote > > "Due to restrictions in [IKE] regarding the use of Main Mode and > pre-shared keys this protocol MUST NOT be used with [IKE] when > doing Main Mode and pre-shared key authentication. Further, it MUST > NOT be used with any key exchange protocol in which the parties > to the exchange authenticate each other using a "group" pre-shared key > (i.e. one that is shared by more than the two parties to the exchange)." > > > Dan, I think this is too restrictive. What if I decide to use > main-mode/pre-shared for device level authentication, and XAUTH for > user-level authentication? > > Also, the part about using a "group" pre-shared key is a policy decision, in > my view. If the user/manager is happy with the security policy protecting a > "group" pre-shared key, that should be his policy decision, not ours. It > may be worth some text in the 'Security Considerations', but I don't think > this should even be a "SHOULD" in the protocol itself. > > Cheers, Steve. From owner-ipsec@lists.tislabs.com Thu Sep 30 09:07:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA18166; Thu, 30 Sep 1999 09:07:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03520 Thu, 30 Sep 1999 10:35:51 -0400 (EDT) From: kompella@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com Message-ID: <852567FC.00505507.00@d54mta04.raleigh.ibm.com> Date: Thu, 30 Sep 1999 10:37:24 -0400 Subject: Re: ICMP errors to IPSECed data? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What we have done for manual IPSEC (as opposed to what we might do with IKE, because we are not yet sure what to do), is to generate a set of extra rules for ICMP. In particular, to deal with ICMP type 3 code * messages. Consider the scenario: HostA --- R1 --- SG1 --- R2 --- SG2 --- R3 --- HostB | | ============== SA between these For traffic from HostA to HostB, any errors between HostA and SG1 (tunnel start point) are handled normally. Since the packet is in the clear, we basically assume that the network is trusted. ICMP errors from R2 are a problem, as discussed extensively in this mailing list. I would be very cautious about relaying port unreachables from some random DOS box purporting to be from router R2, the untrusted part of the network. Furthermore, for IPv4, the offending IP packet does not contain enough information for SG1 to necessarily relay the error back to HostA. ICMPs from R3 can see the cleartext IP packet, so can be useful, if they can get back to HostA securely. So by adding a rule at SG2 that says that ICMP type3 from anybody in the remote subnet going back to HostA go through the tunnel, you can take care of some of the ICMP error cases. One problem would be to ensure that random hosts in the untrusted network do not route bogus ICMPs to HostA through SG2. We basically color our interfaces red and green to differentiate the "trusted" and "untrusted" interfaces, so a further screen on the ICMPs would say that ICMP type 3 from anybody on the *green* side of SG2 to HostA go through the same tunnel that carries HostB to HostA traffic. Other opinions? What do we do with nested SAs, e.g., if an SA also exists between HostA and HostB? Vach Kompella IBM Corp. Network Security Product Development kompella@us.ibm.com Ph.: (919) 254-7281 Fax: (919) 254-4239 Markku Savela on 09/30/99 09:30:54 AM Please respond to msa@hemuli.tte.vtt.fi (Markku Savela) To: ipsec@lists.tislabs.com cc: Subject: ICMP errors to IPSECed data? In my implementation I have done the receive IPSEC processing "in place" (replacing crypted data with clear data) before passing it to the upper layer (TCP/UDP). Now it just occurs to me, that this is a potential security leak if the upper layer generates ICMP (such as port unreachable) and copies the received packet to the ICMP (especially in IPv6, where much more of the packet is copied). It is possible to have a policy that requires protection for specific UDP/port combo, and a different policy for ICMPs (like no encryption). Just wandering how this is actually solved by others? - keep the original packet untouched (and have require upper layers to be aware of this and have them use the original packet in their ICMP replies) [Not very tempting, as I don't like duplicating the buffer space requirement just for possible error situation] - have some "marker" on the packet, which stops the copying for such ICMP messages, - require that the policy writer is aware of such potential "leak" and specifies proper IPSEC for ICMP too [but, you could have high security on UDP(port=x) and some lower security for UDP(port=y), which one you specify for a possible ICMP] - should ICMP error messages actually get the security from a policy that matches the returned packet they are trying to report? [e.g. instead of matching ICMP to the selectors, match the contained packet instead (feels a bit complex and kludgy)] Has this issue been discussed? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Sep 30 10:59:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA20803; Thu, 30 Sep 1999 10:59:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04184 Thu, 30 Sep 1999 12:12:34 -0400 (EDT) Message-Id: <199909301612.JAA27379@Potassium.Network-Alchemy.COM> To: "Waters, Stephen" cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 30 Sep 1999 14:33:26 BST." <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27376.938707964.1@network-alchemy.com> Date: Thu, 30 Sep 1999 09:12:45 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's not the distribution of the group pre-shared secrets that's the problem (remember MKMP? That was a marvelously secure, simple (3 messages), and mutually authenticated way to distribute a group secret. I also remember people screaming "but if more than two people know the secret then it isn't a secret anymore."). It's that you lose authentication that way. draft-ietf-ipsec-internet-key-01.txt was an April Fools draft but the security considerations of that were very real. Unfortunately that draft expired so let me quote it: The use of pre-shared keys has known security implications. When used for authentication, the presentation of a shared secret is proof of identity. When used for datagram authentication, the pre-shared key authenticates the content and source of the datagram. Using the Pre-Shared Key for the Internet will, in effect, allow you to authenticate everyone. One drawback is that this will negate the effects of all related security protocols. It might "make no difference to IKE" if you use the pre-shared key for the internet in doing IKE but that is just plain stupid. And, yes, it can restrict it by simple MUST NOT verbage. That's the whole point. Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the IKE secret state what you're ending up with is unauthenticated IPSec SAs! There's no way that the customer can manage this. It just plain doesn't work. If you want to do things insecurely then make up a simple insecure unauthenticated key exchange and do XAUTH on top of that. Dan. On Thu, 30 Sep 1999 14:33:26 BST you wrote > I'm not suggesting that anyone should be happy with insecurity. My point was > that there are ways to make the distribution of group pre-shared secrets > secure, and if that is the policy adopted by a customer, the protocol should > not prevent that. > > I am not saying pre-shared is 'great', and group-pre-shared is obviously n > times more risky, but if the customer manages these risks effectively, the > choice is his. > There is no difference to the IKE protocol which is used, so it has no > business (IMHO) mandating one over the other, and has no way of restricting > it anyway. > > I think this is a small issue of wording. I'm agreeing that recommendations > could be made and discussed in the draft. > > Cheers, Steve. > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Wednesday, September 29, 1999 9:55 PM > To: Waters, Stephen > Cc: ipsec@lists.tislabs.com > Subject: Re: New XAUTH draft > > > A policy decision? I guess everything could be called a policy decision > but we're trying to build _secure_ protocols here. No one is being stopped > from doing something insecure. If they're happy with insecurity (e.g. if > they have a stated policy that an unauthenticated Diffie-Hellman is fine) > they can do it without IKE. And there are other examples of mandating secure > > behavior (which could easily be called "a policy decision") in our various > documents so I don't see this restrictive. > > What do you gain by allowing patently insecure use of a security protocol? > > Dan. > > On Wed, 29 Sep 1999 13:36:53 BST you wrote > > > > "Due to restrictions in [IKE] regarding the use of Main Mode and > > pre-shared keys this protocol MUST NOT be used with [IKE] when > > doing Main Mode and pre-shared key authentication. Further, it MUST > > NOT be used with any key exchange protocol in which the parties > > to the exchange authenticate each other using a "group" pre-shared key > > > (i.e. one that is shared by more than the two parties to the > exchange)." > > > > > > Dan, I think this is too restrictive. What if I decide to use > > main-mode/pre-shared for device level authentication, and XAUTH for > > user-level authentication? > > > > Also, the part about using a "group" pre-shared key is a policy decision, > in > > my view. If the user/manager is happy with the security policy protecting > a > > "group" pre-shared key, that should be his policy decision, not ours. It > > may be worth some text in the 'Security Considerations', but I don't think > > this should even be a "SHOULD" in the protocol itself. > > > > Cheers, Steve. From owner-ipsec@lists.tislabs.com Thu Sep 30 12:08:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA22274; Thu, 30 Sep 1999 12:08:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04260 Thu, 30 Sep 1999 12:40:18 -0400 (EDT) Message-Id: <199909301641.JAA27482@Potassium.Network-Alchemy.COM> To: Ben McCann cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 30 Sep 1999 06:50:04 EDT." <37F3405B.FE620425@indusriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27479.938709661.1@network-alchemy.com> Date: Thu, 30 Sep 1999 09:41:01 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 30 Sep 1999 06:50:04 EDT you wrote > Dan, > > Would you comment on Tamir's reply about asymmetric authentication in IKE: Oh darn I was trying to duck that one... > > I agree with your disapproval of the use of a key shared by more than > > two parties during Phase 1. This kind of modus operandi is even worse > > than standard pre-shared key authentication which is already weak. > > > > However, I do not think we need to mandate that Phase 1 authenticates > > both parties: For protection against man in the middle attacks it is > > sufficient for only one peer to be authenticated. For the remote user > > to trust the security gateway before divulging his credentials in > > XAUTH it is sufficient that the edge device is authenticated. > > Therefore, it seems that the demand for mutual Phase 1 authentication > > prior to XAUTH can be relaxed and replaced with the demand that only > > the edge device be authenticated. While asymmetric Phase 1 > > authentication with pre-shared keys seems unreasonable, the draft must > > not rule out asymmetric Phase 1 authentication using signatures. > > Doesn't XAUTH combined with Tamir's assymetric Hybrid-Auth proposal > provide a defense against man in the middle attacks? If it doesn't, please > describe the attack. Otherwise, shouldn't we be discussing XAUTH _and_ > hybrid-auth as the solution to this problem? My comments on XAUTH were not explicitly about man-in-the-middle-attacks. Yes, Hybrid does foil those attacks where using a pre-shared key would not. My comments were more about the fact that XAUTH does not effect the authenticated nature of the phase 1 security association in any way (in fact I think I used that sentence or something like it three times). What I think people are missing here (and the comment in XAUTH about "signing ISAKMP packets" really underscores that) is that the SKEYID state is authenticated. The keying material gets authenticated in IKE and it is that state of "authenticatedness" that is conveyed to the IPSec SAs. If you do not authenticate, or weakly authenticate, the phase 1 SAs then it doesn't matter if you do XAUTH or not because the IPSec SAs with be correspondingly unauthenticated. > My customer's are insisting that they want compatibility with legacy > authentication mechanisms as they incrementally roll out PKI. (Some may > never use PKI due to substantial investments in token cards). While I > agree PKI is best, it is not my position to force my customers to adopt > a technology they don't think they need. This is the Internet _Engineering_ Task Force not the Internet Make a Quick Cludge for Customers that Don't Care Task Force. > And they may be right. The customer should have a range of options for > user authentication that match the value of their information and network > access versus the cost of the authentication infrastructure. As an analogy, > a bank doesn't need a vault with 4 foot thick steel walls and biometric > authentication if their total deposits on hand are only $1000. Oh what a great analogy. So what they would need then is the emasculated vault with 4' thick steel walls and biometric authentication, right? They'd remove the biometric authentication and change to something like a group PIN and if the $1000 is stolen then oh well, it was just $1000. But why even go that route. If that's their security concerns then don't sell them the 4' thick steel walled vault (IKE) sell them a wire birdcage. Like I said to Stephen, design your own unauthenticated key exchange (with the security of the birdcage-- I like this analogy!) and run XAUTH on top of that. Or wait a few days. There's a draft in the works that will hopefully address all concerns. Dan. From owner-ipsec@lists.tislabs.com Thu Sep 30 12:32:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA22657; Thu, 30 Sep 1999 12:32:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04595 Thu, 30 Sep 1999 14:01:34 -0400 (EDT) Date: Thu, 30 Sep 1999 14:03:27 -0400 Message-Id: <199909301803.OAA10419@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> <199909301612.JAA27379@Potassium.Network-Alchemy.COM> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I know you don't like XAUTH and are doing everything you can to torpedo it. That's well and good, but it seems to me that the points you're raising don't hold together. If you authenticate with a shared secret, what you know is that the other party knows the shared secret. What does that tell you? In the general case, nothing. In the specific case where each of the holders of the shared secret takes effective action to ensure it is not disclosed to third parties, shared secret authentication tells you that the other party is a member of the set who's supposed to know the shared secret. Whether that set has two members or more makes no difference. The mechanism tells you that the other party is a member of the set. Yes, from the point of view of risk management it is better for the size of that set to be small. But it is incorrect to claim that the only valid set size is 2. For some applications 2 is too large, for others it is too small. Also, you say that XAUTH gives you unauthenticated IPSec SAs. That doesn't make any sense. First of all, clearly those SAs are authenticated to whatever granularity the initial main mode exchange gives you. For preshared key, that means it's authenticated to within the set that knows that shared secret. How can you refer to this as "unauthenticated"? (Reference to April 1 RFCs isn't a useful way of arguing these points.) Second, I don't understand why you claim XAUTH offers no additional security. Or is that not what you claim? You did use the qualification "to the IKE secret state". I guess in the sense that the IKE SA related secret state is established by the main mode exchange, that may be true in some abstract sense; the other endpoint that holds the main mode state is authenticated by the main mode mechanism only. But in what way is that relevant? That system is acting on behalf of one or more parties, and those parties (for whom the IPSec SAs are being set up) are authenticated by XAUTH. You do not get the IPSec SA unless you pass that second step. To put it differently, can you describe an attack that demonstrates your assertion? Say that you and I are both using XAUTH to authenticate with a central site, using a preshared key common to the three of us. Can you demonstrate an attack that allows you to impersonate me, resulting in IPSec SAs to your box that appear to be bound to my identity? If so, then I would agree to your assertion. But if not, it seems to me your assertion is either invalid or not useful, and XAUTH is then shown to provide an additional service. paul From owner-ipsec@lists.tislabs.com Thu Sep 30 12:51:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA23052; Thu, 30 Sep 1999 12:51:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04461 Thu, 30 Sep 1999 13:25:03 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE3BF@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 18:25:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It might "make no difference to IKE" if you use the pre-shared key for >the internet in doing IKE but that is just plain stupid. And, yes, it can >restrict it by simple MUST NOT verbage. That's the whole point. My point was that the IKE protocol can not restrict this. Only a users policy can do that. > Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the >IKE secret state what you're ending up with is unauthenticated IPSec SAs! >There's no way that the customer can manage this. It just plain doesn't >work. You have made a leap from using shared pre-shared to using 'public knowledge' secrets. Xauth does not add to the IKE secret state, agreed. IKE auth tells you you can trust a device at the other end of the tunnel, and xauth allows you to control which users of that device are allowed access. Xauth using certain legacy systems (e.g. SecureID) does offer some of the features of certificate Smartcard without the need to require PKI. Migration is an important customer requirement. It may not add to the IKE secure state, but it does add security confidence that the client actually has the required token card and knows the pin number, but let's not go down that one again. > If you want to do things insecurely then make up a simple insecure >unauthenticated key exchange and do XAUTH on top of that. I don't want to do anything (usually). To try and focus on the common ground, I agree that pre-shared should be used only when PKI is not acceptable to some customers, and that per-user pre-shared with all the precautions we can list should be recommended. I don't agree that sharing pre-shared by more than one device should be out-lawed. Steve. > Dan. On Thu, 30 Sep 1999 14:33:26 BST you wrote > I'm not suggesting that anyone should be happy with insecurity. My point was > that there are ways to make the distribution of group pre-shared secrets > secure, and if that is the policy adopted by a customer, the protocol should > not prevent that. > > I am not saying pre-shared is 'great', and group-pre-shared is obviously n > times more risky, but if the customer manages these risks effectively, the > choice is his. > There is no difference to the IKE protocol which is used, so it has no > business (IMHO) mandating one over the other, and has no way of restricting > it anyway. > > I think this is a small issue of wording. I'm agreeing that recommendations > could be made and discussed in the draft. > > Cheers, Steve. > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Wednesday, September 29, 1999 9:55 PM > To: Waters, Stephen > Cc: > Subject: Re: New XAUTH draft > > > A policy decision? I guess everything could be called a policy decision > but we're trying to build _secure_ protocols here. No one is being stopped > from doing something insecure. If they're happy with insecurity (e.g. if > they have a stated policy that an unauthenticated Diffie-Hellman is fine) > they can do it without IKE. And there are other examples of mandating secure > > behavior (which could easily be called "a policy decision") in our various > documents so I don't see this restrictive. > > What do you gain by allowing patently insecure use of a security protocol? > > Dan. > > On Wed, 29 Sep 1999 13:36:53 BST you wrote > > > > "Due to restrictions in [IKE] regarding the use of Main Mode and > > pre-shared keys this protocol MUST NOT be used with [IKE] when > > doing Main Mode and pre-shared key authentication. Further, it MUST > > NOT be used with any key exchange protocol in which the parties > > to the exchange authenticate each other using a "group" pre-shared key > > > (i.e. one that is shared by more than the two parties to the > exchange)." > > > > > > Dan, I think this is too restrictive. What if I decide to use > > main-mode/pre-shared for device level authentication, and XAUTH for > > user-level authentication? > > > > Also, the part about using a "group" pre-shared key is a policy decision, > in > > my view. If the user/manager is happy with the security policy protecting > a > > "group" pre-shared key, that should be his policy decision, not ours. It > > may be worth some text in the 'Security Considerations', but I don't think > > this should even be a "SHOULD" in the protocol itself. > > > > Cheers, Steve. From owner-ipsec@lists.tislabs.com Thu Sep 30 13:39:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA24006; Thu, 30 Sep 1999 13:39:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04868 Thu, 30 Sep 1999 15:01:58 -0400 (EDT) Message-Id: <199909301902.MAA27764@Potassium.Network-Alchemy.COM> To: Paul Koning cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 30 Sep 1999 14:03:27 EDT." <199909301803.OAA10419@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27761.938718124.1@network-alchemy.com> Date: Thu, 30 Sep 1999 12:02:04 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 30 Sep 1999 14:03:27 EDT you wrote > I know you don't like XAUTH and are doing everything you can to > torpedo it. That's well and good, but it seems to me that the points > you're raising don't hold together. > > If you authenticate with a shared secret, what you know is that the > other party knows the shared secret. > > What does that tell you? In the general case, nothing. > > In the specific case where each of the holders of the shared secret > takes effective action to ensure it is not disclosed to third parties, > shared secret authentication tells you that the other party is a > member of the set who's supposed to know the shared secret. Right, that's all you know. This person is "in the set". And that's all you know about the IPSec SAs. The user is "in the set". But XAUTH is supposed to provide user-level authentication. But it can't. All you can possibly know about the IPSec SAs are that the user is "in the set" not which specific member of the set this person is. And practically how big are these sets? 5? 10? 1000? More? I'd say it's in the 1000 or more range. And in that case you are effectively unauthenticated. > Whether that set has two members or more makes no difference. The > mechanism tells you that the other party is a member of the set. > > Yes, from the point of view of risk management it is better for the > size of that set to be small. But it is incorrect to claim that the > only valid set size is 2. For some applications 2 is too large, for > others it is too small. > > Also, you say that XAUTH gives you unauthenticated IPSec SAs. That > doesn't make any sense. First of all, clearly those SAs are > authenticated to whatever granularity the initial main mode exchange > gives you. For preshared key, that means it's authenticated to within > the set that knows that shared secret. How can you refer to this as > "unauthenticated"? (Reference to April 1 RFCs isn't a useful way of > arguing these points.) IKE is supposed to provide SAs for IPSec that only the two peers are able to use. With a group key doing the "authentication" you lose that. Any member of the set can snoop traffic for any other member of the set by doing a man-in-the-middle with the unauthenticated IKE exchange and then just forwarding the XAUTH stuff on to the gateway and back to the client. Nothing in the XAUTH exchange binds the specific user to the resulting IPSec SAs. > Second, I don't understand why you claim XAUTH offers no additional > security. Or is that not what you claim? You did use the > qualification "to the IKE secret state". I guess in the sense that > the IKE SA related secret state is established by the main mode > exchange, that may be true in some abstract sense; the other endpoint > that holds the main mode state is authenticated by the main mode > mechanism only. But in what way is that relevant? That system is > acting on behalf of one or more parties, and those parties (for whom > the IPSec SAs are being set up) are authenticated by XAUTH. You do > not get the IPSec SA unless you pass that second step. > > To put it differently, can you describe an attack that demonstrates > your assertion? Say that you and I are both using XAUTH to > authenticate with a central site, using a preshared key common to the > three of us. Can you demonstrate an attack that allows you to > impersonate me, resulting in IPSec SAs to your box that appear to be > bound to my identity? If so, then I would agree to your assertion. > But if not, it seems to me your assertion is either invalid or not > useful, and XAUTH is then shown to provide an additional service. I do a man-in-the-middle against your phase 1 exchange. Then I forward your XAUTH messages onto the gateway. I accept the final "SET(status=OK)" message from the gateway but send you a "SET(status=not ok)". Now I get IPSec SAs and the gateway thinks it's you. I can even send you an IKE delete message so you'll blow your IKE SA away. You'll think, "oh crap. I must've entered this stuff wrong. I'll try again." Then you try again and presumably succeed. In the mean time I have SAs that the gateway erroneously thinks are yours. Granted it's about as practical as other man-in-the-middle attacks but it is possible. All it seems XAUTH provides is something to give to those customers that just want to continue to use their token cards (at least that's seems to be the motivation and defense of XAUTH). But just because you want to use a token card shouldn't mean that you have to do it insecurely. There is a way to do it right and a draft describing it will be released shortly. In a nutshell, the client generates a public/private key pair and uses the token card to cause the gateway to trust the public key (in effect he goes through a scaled down on-line certificate enrollement scheme but does not get a certificate, it just causes the gateway to trust the key). The IKE exchange is then authenticated with digital signatures binding each side to the SKEYID state as well as proving identity to the other party. As I said, it'll be out RSN. Dan. From owner-ipsec@lists.tislabs.com Thu Sep 30 13:39:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA24018; Thu, 30 Sep 1999 13:39:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04884 Thu, 30 Sep 1999 15:04:11 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Dan Harkins'" , "Waters, Stephen" Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 12:05:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It's not the distribution of the group pre-shared secrets that's the >problem (remember MKMP? That was a marvelously secure, simple (3 messages), >and mutually authenticated way to distribute a group secret. I also >remember people screaming "but if more than two people know the secret >then it isn't a secret anymore."). It's that you lose authentication that >way. draft-ietf-ipsec-internet-key-01.txt was an April Fools draft but >the security considerations of that were very real. Unfortunately that >draft expired so let me quote it: > > The use of pre-shared keys has known security implications. When used > for authentication, the presentation of a shared secret is proof of > identity. When used for datagram authentication, the pre-shared key > authenticates the content and source of the datagram. Using the > Pre-Shared Key for the Internet will, in effect, allow you to > authenticate everyone. One drawback is that this will negate the > effects of all related security protocols. > > It might "make no difference to IKE" if you use the pre-shared key for >the internet in doing IKE but that is just plain stupid. And, yes, it can >restrict it by simple MUST NOT verbage. That's the whole point. > > Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the >IKE secret state what you're ending up with is unauthenticated IPSec SAs! >There's no way that the customer can manage this. It just plain doesn't >work. > > If you want to do things insecurely then make up a simple insecure >unauthenticated key exchange and do XAUTH on top of that. > I agree. If we do something like 1) Use SSL/IKE exchange (with group(weak) key) to authenticate the end-user device 2) Do legacy authentication(securid, token card) to authenticate the client 3) Create a unique shared secret for the authenticated user 4) Use it do regular IKE exchanges between the client and the server What is the need to extend IKE? Isn't all that is needed is a simple protocol on top of IKE (and separate from IKE)? Thanks, -- sankar ramamoorthi (sankar@vpnet.com) -- From owner-ipsec@lists.tislabs.com Thu Sep 30 14:08:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA24315; Thu, 30 Sep 1999 14:08:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05114 Thu, 30 Sep 1999 15:46:11 -0400 (EDT) Message-Id: <199909301946.MAA27884@Potassium.Network-Alchemy.COM> To: Paul Koning cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 30 Sep 1999 15:26:51 EDT." <199909301926.PAA10520@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27881.938720766.1@network-alchemy.com> Date: Thu, 30 Sep 1999 12:46:06 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 30 Sep 1999 15:26:51 EDT you wrote > Man in the middle attack? > > The man in the middle has to be a member of the set authenticated by > the preshared key, right? Otherwise you can't mount that attack > because main mode doesn't let joe random user do a man in the middle > attack against it. Well your question to me was: "Say that you and I are both using XAUTH to authenticate with a central site, using a preshared key common to the three of us. Can you demonstrate an attack that allows you to impersonate me, resulting in IPSec SAs to your box that appear to be bound to my identity? If so, then I would agree to your assertion." So yea, the man-in-the-middle has to be a member of the set because that was what your question was. Do you agree with my assertion or not? > So now the question becomes: for applications where XAUTH would be > considered, can you partition the set of clients into subsets such > that the members of a particular subset are trusted not to be > interested in mounting man in the middle attacks for impersonating > other members of that same subset? > > If yes, then each subset can share a preshared key. (If no, then and > only then is your argument against group shared keys valid for that > particular application.) Stop moving that bar! The client is presumed to be coming from an unknown IP address so it's difficult to have multiple pre-shared keys on the gateway because he won't know which one to use. But even if you do find some way (aggressive mode using ID_KEYID with some blob there which says "use pre-shared key foo" for instance) you still have the burden of maintainance of the multiple pre-shared key sets and managing who goes into what set. That becomes very Rube Goldbergian and still does not overcome the fact that any member in a set can snoop traffic or inpersonate any other member of the set. Dan. From owner-ipsec@lists.tislabs.com Thu Sep 30 14:24:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA24536; Thu, 30 Sep 1999 14:24:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05085 Thu, 30 Sep 1999 15:41:42 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE3C6@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 20:37:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Right, that's all you know. This person is "in the set". And that's all >you know about the IPSec SAs. The user is "in the set". But XAUTH is >supposed to provide user-level authentication. But it can't. All you >can possibly know about the IPSec SAs are that the user is "in the set" >not which specific member of the set this person is. And practically >how big are these sets? 5? 10? 1000? More? I'd say it's in the 1000 or >more range. And in that case you are effectively unauthenticated. But it can. Phase1 auth tells you the client know an IKE pre-shared secret, Phase1.5 (xauth) tells you that client's ID based on legacy, per user authentication. Success at Phase 1.5 is a pre-requisite of phase2, and it is an implementation issue on how the IPSEC-SA is associated with the Xauth client id, QOS parameters, and any additional client-specific policy and filtering. >IKE is supposed to provide SAs for IPSec that only the two peers are >able to use. With a group key doing the "authentication" you lose that. >Any member of the set can snoop traffic for any other member of the set >by doing a man-in-the-middle with the unauthenticated IKE exchange >and then just forwarding the XAUTH stuff on to the gateway and back to >the client. Nothing in the XAUTH exchange binds the specific user to the >resulting IPSec SAs. It does and can. You either have fixed Intranet address in the clients, or you assign them via IKE-CFG. The phase2 then quotes the Intranet address back to the server in the Phase2 payload negotiation and the generated IPSEC-SA are specific to the allocated address. >All it seems XAUTH provides is something to give to those customers >that just want to continue to use their token cards (at least that's seems >to be the motivation and defense of XAUTH). But just because you want to >use a token card shouldn't mean that you have to do it insecurely. There >is a way to do it right and a draft describing it will be released shortly. >In a nutshell, the client generates a public/private key pair and uses >the token card to cause the gateway to trust the public key (in effect >he goes through a scaled down on-line certificate enrollement scheme but >does not get a certificate, it just causes the gateway to trust the key). >The IKE exchange is then authenticated with digital signatures binding >each side to the SKEYID state as well as proving identity to the other >party. As I said, it'll be out RSN. I look forward to reading it. Steve. From owner-ipsec@lists.tislabs.com Thu Sep 30 14:33:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA24703; Thu, 30 Sep 1999 14:33:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05184 Thu, 30 Sep 1999 16:05:47 -0400 (EDT) Message-ID: <37F3C34A.A6CBD204@checkpoint.com> Date: Thu, 30 Sep 1999 22:08:42 +0200 From: Tamir Zegman X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: dharkins@network-alchemy.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: New XAUTH draft References: <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> <199909301612.JAA27379@Potassium.Network-Alchemy.COM> <199909301803.OAA10419@tonga.xedia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk   Paul Koning wrote: >   > To put it differently, can you describe an attack that demonstrates > your assertion?  Say that you and I are both using XAUTH to > authenticate with a central site, using a preshared key common to the > three of us.  Can you demonstrate an attack that allows you to > impersonate me, resulting in IPSec SAs to your box that appear to be > bound to my identity?  If so, then I would agree to your assertion. > But if not, it seems to me your assertion is either invalid or not > useful, and XAUTH is then shown to provide an additional service. Actually I think I can give you such an attack. Assume that paul and Daniel have the same shared key to connect to Security Gateway (SG). Daniel can mount a simple man in the middle attack - When Paul tries to connect to SG, Daniel spoofs the SG and simultaneously have his own Phase 1 with SG. Paul finishes the Phase 1 and proceeds to XAUTH talking with Daniel but thinking he is talking to SG. By serving as proxy during the XAUTH exchange Daniel makes the SG believe it is speaking with Paul. At the end of XAUTH, not only did Daniel made the SG believe it is talking with Paul, but Dan has also acquired Paul's credentials. Assuming these credentials are static it can now impersonate Paul whenever he wants. Even If the credentials are static, Dan can use the IKE SA to to negotiate Quick Mode. Hybrid was designed to resist exactly this kind of attacks. Tamir.     From owner-ipsec@lists.tislabs.com Thu Sep 30 14:37:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA24791; Thu, 30 Sep 1999 14:37:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05213 Thu, 30 Sep 1999 16:10:46 -0400 (EDT) Message-ID: <37F3C4BB.CBC543CB@redcreek.com> Date: Thu, 30 Sep 1999 13:14:51 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: dharkins@network-alchemy.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> <199909301612.JAA27379@Potassium.Network-Alchemy.COM> <199909301803.OAA10419@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > To put it differently, can you describe an attack that demonstrates > your assertion? Say that you and I are both using XAUTH to > authenticate with a central site, using a preshared key common to the > three of us. Can you demonstrate an attack that allows you to > impersonate me, resulting in IPSec SAs to your box that appear to be > bound to my identity? If so, then I would agree to your assertion. > But if not, it seems to me your assertion is either invalid or not > useful, and XAUTH is then shown to provide an additional service. > Hmmm... how about if I capture your session and mount an offline known-plaintext analysis using the following from the exchange: IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> Now, I know your password, and I know the preshared key. I can impersonate you. From owner-ipsec@lists.tislabs.com Thu Sep 30 14:45:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA24977; Thu, 30 Sep 1999 14:45:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05233 Thu, 30 Sep 1999 16:15:14 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Bellovin To: ipsec@lists.tislabs.com Subject: anti-replay protection without IKE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Sep 1999 14:51:39 -0400 Message-Id: <19990930185249.5B048ACAE4@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If IKE isn't being used, should IPSEC hosts allow replay protection? RFC 2401 hints that replay checking shouldn't be done for manual SAs, presumably on the theory that manual keys are likely to be long-lived. However, there are applications that use a different key management protocol because (for various reasons) IKE is inappropriate. Simply as a matter of convenience, such applications may use the manual keying interface, especially if only one key management daemon can exist on a system. Should (or SHOULD) implementations permit such applications to request replay checking? --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Sep 30 15:17:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA25396; Thu, 30 Sep 1999 15:17:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05281 Thu, 30 Sep 1999 16:21:54 -0400 (EDT) Message-ID: <37F3C756.822D9F7F@redcreek.com> Date: Thu, 30 Sep 1999 13:25:58 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tamir Zegman CC: Paul Koning , dharkins@network-alchemy.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: New XAUTH draft References: <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> <199909301612.JAA27379@Potassium.Network-Alchemy.COM> <199909301803.OAA10419@tonga.xedia.com> <37F3C34A.A6CBD204@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tamir Zegman wrote: > > Paul Koning wrote: > > Actually I think I can give you such an attack. Excellent point, and probably easier to mount than my example... From owner-ipsec@lists.tislabs.com Thu Sep 30 15:17:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA25406; Thu, 30 Sep 1999 15:17:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05432 Thu, 30 Sep 1999 16:43:31 -0400 (EDT) From: John Ioannidis Date: Thu, 30 Sep 1999 16:45:25 -0400 (EDT) Message-Id: <199909302045.QAA01423@bual.research.att.com> To: ipsec@lists.tislabs.com, smb@research.att.com Subject: Re: anti-replay protection without IKE Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > RFC 2401 > hints that replay checking shouldn't be done for manual SAs, presumably on the > theory that manual keys are likely to be long-lived. However, there are I had missed that detail, but the explanation makes no sense. It's *especially* when we have long-lived keys that we want replay protection! On applications with manual keying, or non-IKE keying, maybe we want to allow turning off the replay protection, but I feel that it MUST be turned on by default. > Should (or SHOULD) implementations > permit such applications to request replay checking? I think that the phrasing should be "implementations MAY permit applications to turn OFF replay protection, but replay protection MUST be turned on by default." /ji -- John Ioannidis Secure Systems Research Department AT&T Labs - Research From owner-ipsec@lists.tislabs.com Thu Sep 30 15:21:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA25460; Thu, 30 Sep 1999 15:21:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05341 Thu, 30 Sep 1999 16:33:39 -0400 (EDT) From: Dan McDonald Message-Id: <199909302035.NAA00951@kebe.Eng.Sun.COM> Subject: Re: anti-replay protection without IKE To: smb@research.att.com (Steve Bellovin) Date: Thu, 30 Sep 1999 13:35:29 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <19990930185249.5B048ACAE4@smb.research.att.com> from "Steve Bellovin" at Sep 30, 99 02:51:39 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If IKE isn't being used, should IPSEC hosts allow replay protection? RFC > 2401 hints that replay checking shouldn't be done for manual SAs, > presumably on the theory that manual keys are likely to be long-lived. > However, there are applications that use a different key management > protocol because (for various reasons) IKE is inappropriate. Simply as a > matter of convenience, such applications may use the manual keying > interface, especially if only one key management daemon can exist on a > system. Should (or SHOULD) implementations permit such applications to > request replay checking? Absolutely! For most unicast traffic, there's no reason NOT to use replay, except for maybe manual keying. The cases where replay protection is destructive all involve the potential for multiple independent senders of traffic. The most common case of this is multicast traffic. Less common is a case where a unicast SA has no source address selector associated with it, and multiple senders use the same unicast SA to send traffic to a single unicast destination. Dan From owner-ipsec@lists.tislabs.com Thu Sep 30 15:25:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA25520; Thu, 30 Sep 1999 15:25:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05474 Thu, 30 Sep 1999 16:51:58 -0400 (EDT) Date: Thu, 30 Sep 1999 16:53:52 -0400 Message-Id: <199909302053.QAA13120@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: skelly@redcreek.com Cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> <199909301612.JAA27379@Potassium.Network-Alchemy.COM> <199909301803.OAA10419@tonga.xedia.com> <37F3C4BB.CBC543CB@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: > Hmmm... how about if I capture your session and mount an offline > known-plaintext analysis using the following from the exchange: > > IPSec Host Edge Device > -------------- ----------------- > <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") > REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> > > Now, I know your password, and I know the preshared key. I can > impersonate you. The XAUTH exchange is encrypted under the IKE SA key, right? So no, you can't do this because you don't know that key, unless you're in the middle as Dan and Tamir suggested. Listening isn't sufficient. paul From owner-ipsec@lists.tislabs.com Thu Sep 30 15:28:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA25561; Thu, 30 Sep 1999 15:28:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05373 Thu, 30 Sep 1999 16:38:25 -0400 (EDT) Date: Thu, 30 Sep 1999 16:40:14 -0400 Message-Id: <199909302040.QAA13110@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <199909301926.PAA10520@tonga.xedia.com> <199909301946.MAA27884@Potassium.Network-Alchemy.COM> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> On Thu, 30 Sep 1999 15:26:51 EDT you wrote >> Man in the middle attack? >> >> The man in the middle has to be a member of the set authenticated >> by the preshared key, right? Otherwise you can't mount that >> attack because main mode doesn't let joe random user do a man in >> the middle attack against it. Dan> Well your question to me was: Dan> "Say that you and I are both using XAUTH to authenticate with a Dan> central site, using a preshared key common to the three of us. Dan> Can you demonstrate an attack that allows you to impersonate me, Dan> resulting in IPSec SAs to your box that appear to be bound to my Dan> identity? If so, then I would agree to your assertion." Dan> So yea, the man-in-the-middle has to be a member of the set Dan> because that was what your question was. Do you agree with my Dan> assertion or not? Ok, I guess I do, to a limited extent. See below. >> So now the question becomes: for applications where XAUTH would be >> considered, can you partition the set of clients into subsets such >> that the members of a particular subset are trusted not to be >> interested in mounting man in the middle attacks for impersonating >> other members of that same subset? >> >> If yes, then each subset can share a preshared key. (If no, then >> and only then is your argument against group shared keys valid for >> that particular application.) Dan> Stop moving that bar! Am I moving the bar? I don't think so. I'm trying to clarify where the bar is. You use terms like "unauthenticated", and "man in the middle" without any qualification -- which suggests that the protocol under discussion is wide open to the entire world. Of course it isn't, and just how far from wide open is what I'm trying to figure out. You could have spelled it out up front, but you didn't do that. So let me see now if I have correctly identified the location of the bar. XAUTH is subject to attack: 1. only by parties that know the preshared key being used, 2. only via active man in the middle attack, not by passive attack or by active attack not in the middle. Is that right? If so, then yes I would agree that this constitutes an attack on the system. But I don't agree that it is a sufficiently serious threat to condemn the entire concept, as you have been doing. I believe (and I think a number of others do) that there are valid applications where XAUTH has value and this particular threat is not a significant concern. So perhaps the next question is: is there consensus that this threat is so serious that XAUTH has no meaningful applicability in the real world? If so, then of course the draft can't proceed. But if the consensus is that there are enough real world applications that can live with this threat, then the draft can and should proceed as it stands. paul From owner-ipsec@lists.tislabs.com Thu Sep 30 15:30:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA25629; Thu, 30 Sep 1999 15:30:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05573 Thu, 30 Sep 1999 17:02:28 -0400 (EDT) Message-ID: <37F3D0A7.9462CC3C@checkpoint.com> Date: Thu, 30 Sep 1999 23:05:43 +0200 From: Tamir Zegman X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Fwd: New XAUTH draft] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk   Dan Harkins wrote: < trimmed > >   > The client is presumed to be coming from an unknown IP address so it's > difficult to have multiple pre-shared keys on the gateway because he > won't know which one to use. But even if you do find some way (aggressive > mode using ID_KEYID with some blob there which says "use pre-shared key > foo" for instance) you still have the burden of maintainance of the > multiple pre-shared key sets and managing who goes into what set. That > becomes very Rube Goldbergian and still does not overcome the fact that > any member in a set can snoop traffic or inpersonate any other member of > the set. > >   Dan. On top of what Dan said, consider an employee who was just sacked. You now need to modify the pre-shared key used by the set of users he used to belong to. You'll need to notify (in a secure manner) all members of the group and give them the new group secret!   From owner-ipsec@lists.tislabs.com Thu Sep 30 15:31:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA25666; Thu, 30 Sep 1999 15:31:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05549 Thu, 30 Sep 1999 17:01:07 -0400 (EDT) Message-ID: <37F3D087.803E07FA@redcreek.com> Date: Thu, 30 Sep 1999 14:05:11 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com> <199909301612.JAA27379@Potassium.Network-Alchemy.COM> <199909301803.OAA10419@tonga.xedia.com> <37F3C4BB.CBC543CB@redcreek.com> <199909302053.QAA13120@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > >>>>> "Scott" == Scott G Kelly writes: > > > Hmmm... how about if I capture your session and mount an offline > > known-plaintext analysis using the following from the exchange: > > > > IPSec Host Edge Device > > -------------- ----------------- > > <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") > > REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> > > > > Now, I know your password, and I know the preshared key. I can > > impersonate you. > > The XAUTH exchange is encrypted under the IKE SA key, right? So no, > you can't do this because you don't know that key, unless you're in > the middle as Dan and Tamir suggested. Listening isn't sufficient. > First, let me emphasize that this is not a simple attack. Second, I'll add that you don't need the key in advance for a known-plaintext analysis, as the key is what you are trying to derive. The point is that you know exactly what some of the text is, and you have the corresponding ciphertext. Granted, a strong crypto algorithm makes this a *lot* harder to pull off, but it is still a possible attack, which is what you asked for. I also grant that this has substantially lighter implications for a one time password based system. Scott From owner-ipsec@lists.tislabs.com Thu Sep 30 16:24:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA26373; Thu, 30 Sep 1999 16:24:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05658 Thu, 30 Sep 1999 17:15:24 -0400 (EDT) Date: Thu, 30 Sep 1999 15:26:51 -0400 Message-Id: <199909301926.PAA10520@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <199909301803.OAA10419@tonga.xedia.com> <199909301902.MAA27764@Potassium.Network-Alchemy.COM> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Man in the middle attack? The man in the middle has to be a member of the set authenticated by the preshared key, right? Otherwise you can't mount that attack because main mode doesn't let joe random user do a man in the middle attack against it. So now the question becomes: for applications where XAUTH would be considered, can you partition the set of clients into subsets such that the members of a particular subset are trusted not to be interested in mounting man in the middle attacks for impersonating other members of that same subset? If yes, then each subset can share a preshared key. (If no, then and only then is your argument against group shared keys valid for that particular application.) paul From owner-ipsec@lists.tislabs.com Thu Sep 30 16:24:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA26383; Thu, 30 Sep 1999 16:24:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05529 Thu, 30 Sep 1999 16:59:23 -0400 (EDT) Message-Id: <199909302059.NAA28326@Potassium.Network-Alchemy.COM> To: Paul Koning cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 30 Sep 1999 16:40:14 EDT." <199909302040.QAA13110@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28323.938725143.1@network-alchemy.com> Date: Thu, 30 Sep 1999 13:59:04 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 30 Sep 1999 16:40:14 EDT you wrote > > So perhaps the next question is: is there consensus that this threat > is so serious that XAUTH has no meaningful applicability in the real > world? If so, then of course the draft can't proceed. But if the > consensus is that there are enough real world applications that can > live with this threat, then the draft can and should proceed as it > stands. I'd like to respectfully call for a postponement of that call for consensus. At least until a viable alternative to XAUTH has been presented to the WG and, as I said, it'll be out RSN (the less time I spend on this thread the more I spend on the draft). You've drawn boxes around the problems I described and want to say, in effect, well they might not be serious for all people and so XAUTH is fine for people not worried about that problem. But if there was a protocol which did not have these problems (and I'm frankly amused at how these problems are pooh-poohed in XAUTH whereas most any other _security_ protocol would get shot down in a barrage of bullets) but satisfied the main goal in XAUTH-- that is, selling customers something that uses token cards-- would it not be preferable? This draft will be released well in advance of the DC IETF so people will have ample opportunity to read it and compare it to XAUTH, throw darts, etc. Then we can call for consensus. Dan. From owner-ipsec@lists.tislabs.com Thu Sep 30 16:35:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA26473; Thu, 30 Sep 1999 16:35:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05790 Thu, 30 Sep 1999 17:33:20 -0400 (EDT) Date: Thu, 30 Sep 1999 17:35:18 -0400 Message-Id: <199909302135.RAA18465@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ji@research.att.com Cc: ipsec@lists.tislabs.com Subject: Re: anti-replay protection without IKE References: <199909302045.QAA01423@bual.research.att.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "John" == John Ioannidis writes: >> RFC 2401 hints that replay checking shouldn't be done for manual >> SAs, presumably on the theory that manual keys are likely to be >> long-lived. However, there are John> I had missed that detail, but the explanation makes no sense. John> It's *especially* when we have long-lived keys that we want John> replay protection! John> On applications with manual keying, or non-IKE keying, maybe we John> want to allow turning off the replay protection, but I feel John> that it MUST be turned on by default. Let's distinguish the two cases. I think the existing text is for manual keying, not "non-IKE" keying. Non-IKE dynamic keying is (presumably) already covered by the same rules that cover SAs created by IKE. >> Should (or SHOULD) implementations permit such applications to >> request replay checking? John> I think that the phrasing should be "implementations MAY permit John> applications to turn OFF replay protection, but replay John> protection MUST be turned on by default." Well, that would of course invalidate existing implementations... Anyway, for truly manual keyed SAs, this is a bit problematic. If your keying state is non-volatile but the sequence state isn't (which is a likely case) then after a reboot on one end the sequence checker would throw out all traffic until you send as many packets as were sent before the crash. This may be a non-issue in some applications, so allowing sequence checking to be turned on for manual keyed SAs makes sense to me. It's not clear that it's the right default, though. Also, if it's turned on then the SA should either go away or become non-operational when the sequence number hits 2^32-1. paul From owner-ipsec@lists.tislabs.com Thu Sep 30 16:42:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA26547; Thu, 30 Sep 1999 16:42:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05907 Thu, 30 Sep 1999 17:53:40 -0400 (EDT) Message-Id: <199909302154.OAA28502@Potassium.Network-Alchemy.COM> To: Steve Bellovin cc: ipsec@lists.tislabs.com Subject: Re: anti-replay protection without IKE In-reply-to: Your message of "Thu, 30 Sep 1999 14:51:39 EDT." <19990930185249.5B048ACAE4@smb.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28499.938728457.1@network-alchemy.com> Date: Thu, 30 Sep 1999 14:54:17 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, absolutely. I think IPSec should be key management neutral. Any key management scheme should be able to take full advantage of every aspect of IPSec. Regardless of the key management/SA establishment protocol I think the sender is still required to send packets with the anti-replay counter even if this request was not explicitly made. Dan. On Thu, 30 Sep 1999 14:51:39 EDT you wrote > If IKE isn't being used, should IPSEC hosts allow replay protection? RFC 240 >1 > hints that replay checking shouldn't be done for manual SAs, presumably on th >e > theory that manual keys are likely to be long-lived. However, there are > applications that use a different key management protocol because (for variou >s > reasons) IKE is inappropriate. Simply as a matter of convenience, such > applications may use the manual keying interface, especially if only one key > management daemon can exist on a system. Should (or SHOULD) implementations > permit such applications to request replay checking? > > --Steve Bellovin > > From owner-ipsec@lists.tislabs.com Thu Sep 30 17:33:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA27208; Thu, 30 Sep 1999 17:33:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06229 Thu, 30 Sep 1999 18:52:52 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE3C7@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 23:19:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Stop moving that bar! >The client is presumed to be coming from an unknown IP address so it's >difficult to have multiple pre-shared keys on the gateway because he >won't know which one to use. But even if you do find some way (aggressive >mode using ID_KEYID with some blob there which says "use pre-shared key >foo" for instance) you still have the burden of maintainance of the >multiple pre-shared key sets and managing who goes into what set. That >becomes very Rube Goldbergian and still does not overcome the fact that >any member in a set can snoop traffic or inpersonate any other member of >the set. This can be done in a straight forward way using the tunnel additions to RADIUS. Also, the clients can only snoop or impersonate if they have the authentication material needed to get past xauth as well. Steve. From owner-ipsec@lists.tislabs.com Thu Sep 30 18:04:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA27995; Thu, 30 Sep 1999 18:04:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06224 Thu, 30 Sep 1999 18:52:35 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE3C8@new-exc1.ctron.com> From: "Waters, Stephen" To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 23:19:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yep, that'll do it. If you don't use per-user pre-shared, and you care that your group members could snoop on you (I don't think I do, they can do that much more easily by sniffing my LAN data), then use a stronger xauth - CHAP/SecurID/other token cards/OTP. Cheers, Steve. -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Thursday, September 30, 1999 9:15 PM To: Paul Koning Cc: dharkins@network-alchemy.com; Stephen.Waters@cabletron.com; Subject: Re: New XAUTH draft Paul Koning wrote: > > To put it differently, can you describe an attack that demonstrates > your assertion? Say that you and I are both using XAUTH to > authenticate with a central site, using a preshared key common to the > three of us. Can you demonstrate an attack that allows you to > impersonate me, resulting in IPSec SAs to your box that appear to be > bound to my identity? If so, then I would agree to your assertion. > But if not, it seems to me your assertion is either invalid or not > useful, and XAUTH is then shown to provide an additional service. > Hmmm... how about if I capture your session and mount an offline known-plaintext analysis using the following from the exchange: IPSec Host Edge Device -------------- ----------------- <-- REQUEST(TYPE=RADIUS NAME="" PASSWORD="") REPLY(TYPE=RADIUS NAME="joe" PASSWORD="foobar") --> Now, I know your password, and I know the preshared key. I can impersonate you. From owner-ipsec@lists.tislabs.com Thu Sep 30 19:25:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA06472; Thu, 30 Sep 1999 19:25:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06684 Thu, 30 Sep 1999 21:09:18 -0400 (EDT) Message-Id: <199910010104.VAA04142@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 30 Sep 1999 22:08:42 +0200." <37F3C34A.A6CBD204@checkpoint.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Sep 1999 21:04:18 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tamir" == Tamir Zegman writes: Tamir> Actually I think I can give you such an attack. Assume that paul Tamir> and Daniel have the same shared key to connect to Security Gateway Tamir> (SG). Daniel can mount a simple man in the middle attack - When Tamir> Paul tries to connect to SG, Daniel spoofs the SG and No need for IPsec to do this attack. This attack was demonstrated years ago on multiple token authentication systems used to "secure" telnet connections. This attack is inherent in token authentication systems that only authenticates only the client to the server, and not the server to the client. There are challenge/response systems (some can involve tokens) that do not have this property that XAUTH could mediate. Dan, I have a question (even though I've been trying hard to delete every message that says "XAUTH" or "Hybrid" in it), do *you* prefer hybrid to XAUTH? ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Sep 30 19:30:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA06893; Thu, 30 Sep 1999 19:30:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06704 Thu, 30 Sep 1999 21:13:49 -0400 (EDT) Message-Id: <199910010109.VAA04160@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: anti-replay protection without IKE In-reply-to: Your message of "Thu, 30 Sep 1999 14:51:39 EDT." <19990930185249.5B048ACAE4@smb.research.att.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Sep 1999 21:09:01 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Steve" == Steve Bellovin writes: Steve> If IKE isn't being used, should IPSEC hosts allow replay Steve> protection? RFC 2401 hints that replay checking shouldn't be done Steve> for manual SAs, presumably on the theory that manual keys are Steve> likely to be long-lived. However, there are applications that use Steve> a different key management protocol because (for various reasons) We had this conversation a long time ago. It says "Manual keying" to acknowledge that IKE is not the only keying mechanism. If you have another way to change keys, then do reply checking. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Sep 30 19:48:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA08737; Thu, 30 Sep 1999 19:48:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06806 Thu, 30 Sep 1999 21:35:52 -0400 (EDT) Message-ID: <19991001013721.97433.qmail@hotmail.com> X-Originating-IP: [207.181.90.145] From: "Roy Pereira" To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft Date: Thu, 30 Sep 1999 21:37:20 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I understand what you are getting at, but I don't think it's XAUTH responsibility to mandate that a shared secret be truelly secret. I would like to see XAUTH be secure, but not be limiting. Not everyone has the same paranoia level, and thus the customer needs to make up their own mind about just how secure they need something to be. If they are foolish enough to spread a single "shared secret" around them, it is their own fault. Yes, we can place a lot of wording in our documents about the dangers about this scenario, but we can't prevent it from happening accidentally, or on purpose. >From: Dan Harkins >To: "Waters, Stephen" >CC: ipsec@lists.tislabs.com >Subject: Re: New XAUTH draft >Date: Thu, 30 Sep 1999 09:12:45 -0700 > > It's not the distribution of the group pre-shared secrets that's the >problem (remember MKMP? That was a marvelously secure, simple (3 messages), >and mutually authenticated way to distribute a group secret. I also >remember people screaming "but if more than two people know the secret >then it isn't a secret anymore."). It's that you lose authentication that >way. draft-ietf-ipsec-internet-key-01.txt was an April Fools draft but >the security considerations of that were very real. Unfortunately that >draft expired so let me quote it: > > The use of pre-shared keys has known security implications. When used > for authentication, the presentation of a shared secret is proof of > identity. When used for datagram authentication, the pre-shared key > authenticates the content and source of the datagram. Using the > Pre-Shared Key for the Internet will, in effect, allow you to > authenticate everyone. One drawback is that this will negate the > effects of all related security protocols. > > It might "make no difference to IKE" if you use the pre-shared key for >the internet in doing IKE but that is just plain stupid. And, yes, it can >restrict it by simple MUST NOT verbage. That's the whole point. > > Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the >IKE secret state what you're ending up with is unauthenticated IPSec SAs! >There's no way that the customer can manage this. It just plain doesn't >work. > > If you want to do things insecurely then make up a simple insecure >unauthenticated key exchange and do XAUTH on top of that. > > Dan. > >On Thu, 30 Sep 1999 14:33:26 BST you wrote > > I'm not suggesting that anyone should be happy with insecurity. My point >was > > that there are ways to make the distribution of group pre-shared secrets > > secure, and if that is the policy adopted by a customer, the protocol >should > > not prevent that. > > > > I am not saying pre-shared is 'great', and group-pre-shared is obviously >n > > times more risky, but if the customer manages these risks effectively, >the > > choice is his. > > There is no difference to the IKE protocol which is used, so it has no > > business (IMHO) mandating one over the other, and has no way of >restricting > > it anyway. > > > > I think this is a small issue of wording. I'm agreeing that >recommendations > > could be made and discussed in the draft. > > > > Cheers, Steve. > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > > Sent: Wednesday, September 29, 1999 9:55 PM > > To: Waters, Stephen > > Cc: ipsec@lists.tislabs.com > > Subject: Re: New XAUTH draft > > > > > > A policy decision? I guess everything could be called a policy >decision > > but we're trying to build _secure_ protocols here. No one is being >stopped > > from doing something insecure. If they're happy with insecurity (e.g. if > > they have a stated policy that an unauthenticated Diffie-Hellman is >fine) > > they can do it without IKE. And there are other examples of mandating >secure > > > > behavior (which could easily be called "a policy decision") in our >various > > documents so I don't see this restrictive. > > > > What do you gain by allowing patently insecure use of a security >protocol? > > > > Dan. > > > > On Wed, 29 Sep 1999 13:36:53 BST you wrote > > > > > > "Due to restrictions in [IKE] regarding the use of Main Mode and > > > pre-shared keys this protocol MUST NOT be used with [IKE] when > > > doing Main Mode and pre-shared key authentication. Further, it >MUST > > > NOT be used with any key exchange protocol in which the parties > > > to the exchange authenticate each other using a "group" pre-shared >key > > > > > (i.e. one that is shared by more than the two parties to the > > exchange)." > > > > > > > > > Dan, I think this is too restrictive. What if I decide to use > > > main-mode/pre-shared for device level authentication, and XAUTH for > > > user-level authentication? > > > > > > Also, the part about using a "group" pre-shared key is a policy >decision, > > in > > > my view. If the user/manager is happy with the security policy >protecting > > a > > > "group" pre-shared key, that should be his policy decision, not ours. >It > > > may be worth some text in the 'Security Considerations', but I don't >think > > > this should even be a "SHOULD" in the protocol itself. > > > > > > Cheers, Steve. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Thu Sep 30 20:05:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA10613; Thu, 30 Sep 1999 20:05:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06874 Thu, 30 Sep 1999 21:49:29 -0400 (EDT) Message-ID: <19991001015053.26057.qmail@hotmail.com> X-Originating-IP: [207.181.90.145] From: "Roy Pereira" To: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: New XAUTH draft Date: Thu, 30 Sep 1999 21:50:53 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've heard this "hybrid vs. XAUTH" thing a couple of times now and I would like to dispel it. As Tamir would probably agree, Hybrid isn't a competitor to XAUTH and it isn't one or the other, they are complementary. XAUTH is actually used within Hybrid. XAUTH uses the already established authentication mechanisms of IKE while Hybrid establishes its own "hybrid" authentication schemes. Hybrid is invaluable when only the server has a certificate and the client does not. For the actual legacy authentication process, Hybrid uses XAUTH. I guess the question for this thread is should XAUTH be allowed with shared secret authentication or should it mandate that it only be used with certificate-based authentication (RSA/enc, RSA/sig & DSA/enc) ? >From: Michael Richardson >To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org >Subject: Re: New XAUTH draft >Date: Thu, 30 Sep 1999 21:04:18 -0400 > > > >>>>> "Tamir" == Tamir Zegman writes: > Tamir> Actually I think I can give you such an attack. Assume that >paul > Tamir> and Daniel have the same shared key to connect to Security >Gateway > Tamir> (SG). Daniel can mount a simple man in the middle attack - >When > Tamir> Paul tries to connect to SG, Daniel spoofs the SG and > > No need for IPsec to do this attack. > > This attack was demonstrated years ago on multiple token authentication >systems used to "secure" telnet connections. This attack is inherent in >token authentication systems that only authenticates only the client to the >server, and not the server to the client. > There are challenge/response systems (some can involve tokens) that do >not have this property that XAUTH could mediate. > > Dan, I have a question (even though I've been trying hard to delete >every >message that says "XAUTH" or "Hybrid" in it), do *you* prefer hybrid to >XAUTH? > >] Train travel features AC outlets with no take-off restrictions| >firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device >driver[ >] panic("Just another NetBSD/notebook using, kernel hacking, security >guy"); [ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Thu Sep 30 20:09:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA11041; Thu, 30 Sep 1999 20:09:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06895 Thu, 30 Sep 1999 21:57:10 -0400 (EDT) Message-ID: <19991001015833.46352.qmail@hotmail.com> X-Originating-IP: [207.181.90.145] From: "Roy Pereira" To: Sankar@vpnet.com, dharkins@network-alchemy.com, Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 21:58:32 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why add the burden of supporting SSL to an IPSec device? That's one of the things XAUTH was trying to accomplish; don't add anything more than you have to. IKE exists and it works well. Just extend it to support other forms of authentication. Of course, we can get into a entire thread of the truelly secure nature of SSL as compared to IKE.... 8-( >From: Sankar Ramamoorthi >To: "'Dan Harkins'" , "Waters, >Stephen" >CC: ipsec@lists.tislabs.com >Subject: RE: New XAUTH draft >Date: Thu, 30 Sep 1999 12:05:39 -0700 > > > It's not the distribution of the group pre-shared secrets that's the > >problem (remember MKMP? That was a marvelously secure, simple (3 >messages), > > >and mutually authenticated way to distribute a group secret. I also > >remember people screaming "but if more than two people know the secret > >then it isn't a secret anymore."). It's that you lose authentication that > >way. draft-ietf-ipsec-internet-key-01.txt was an April Fools draft but > >the security considerations of that were very real. Unfortunately that > >draft expired so let me quote it: > > > > The use of pre-shared keys has known security implications. When used > > for authentication, the presentation of a shared secret is proof of > > identity. When used for datagram authentication, the pre-shared key > > authenticates the content and source of the datagram. Using the > > Pre-Shared Key for the Internet will, in effect, allow you to > > authenticate everyone. One drawback is that this will negate the > > effects of all related security protocols. > > > > It might "make no difference to IKE" if you use the pre-shared key for > >the internet in doing IKE but that is just plain stupid. And, yes, it can > >restrict it by simple MUST NOT verbage. That's the whole point. > > > > Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the > >IKE secret state what you're ending up with is unauthenticated IPSec SAs! > >There's no way that the customer can manage this. It just plain doesn't > >work. > > > > If you want to do things insecurely then make up a simple insecure > >unauthenticated key exchange and do XAUTH on top of that. > > > >I agree. > >If we do something like > >1) Use SSL/IKE exchange (with group(weak) key) to authenticate >the end-user device > >2) Do legacy authentication(securid, token card) to authenticate the client > > >3) Create a unique shared secret for the authenticated user > >4) Use it do regular IKE exchanges between the client and the server > > >What is the need to extend IKE? >Isn't all that is needed is a simple protocol on top of IKE (and separate >from IKE)? > > >Thanks, > >-- sankar ramamoorthi (sankar@vpnet.com) -- > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Thu Sep 30 20:19:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA11779; Thu, 30 Sep 1999 20:19:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06922 Thu, 30 Sep 1999 22:03:07 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Roy Pereira'" , Sankar Ramamoorthi , dharkins@network-alchemy.com, Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 30 Sep 1999 19:04:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I mentioned SSL as a choice. It could very well be another IKE exchange. My question was more related to 'why not use IKE as it exists today to do legacy authentication instead of extending it'. Thanks, -- sankar -- -----Original Message----- From: Roy Pereira [mailto:rp96@hotmail.com] Sent: Thursday, September 30, 1999 6:59 PM To: Sankar@vpnet.com; dharkins@network-alchemy.com; Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Why add the burden of supporting SSL to an IPSec device? That's one of the things XAUTH was trying to accomplish; don't add anything more than you have to. IKE exists and it works well. Just extend it to support other forms of authentication. Of course, we can get into a entire thread of the truelly secure nature of SSL as compared to IKE.... 8-( >From: Sankar Ramamoorthi >To: "'Dan Harkins'" , "Waters, >Stephen" >CC: ipsec@lists.tislabs.com >Subject: RE: New XAUTH draft >Date: Thu, 30 Sep 1999 12:05:39 -0700 > > > It's not the distribution of the group pre-shared secrets that's the > >problem (remember MKMP? That was a marvelously secure, simple (3 >messages), > > >and mutually authenticated way to distribute a group secret. I also > >remember people screaming "but if more than two people know the secret > >then it isn't a secret anymore."). It's that you lose authentication that > >way. draft-ietf-ipsec-internet-key-01.txt was an April Fools draft but > >the security considerations of that were very real. Unfortunately that > >draft expired so let me quote it: > > > > The use of pre-shared keys has known security implications. When used > > for authentication, the presentation of a shared secret is proof of > > identity. When used for datagram authentication, the pre-shared key > > authenticates the content and source of the datagram. Using the > > Pre-Shared Key for the Internet will, in effect, allow you to > > authenticate everyone. One drawback is that this will negate the > > effects of all related security protocols. > > > > It might "make no difference to IKE" if you use the pre-shared key for > >the internet in doing IKE but that is just plain stupid. And, yes, it can > >restrict it by simple MUST NOT verbage. That's the whole point. > > > > Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the > >IKE secret state what you're ending up with is unauthenticated IPSec SAs! > >There's no way that the customer can manage this. It just plain doesn't > >work. > > > > If you want to do things insecurely then make up a simple insecure > >unauthenticated key exchange and do XAUTH on top of that. > > > >I agree. > >If we do something like > >1) Use SSL/IKE exchange (with group(weak) key) to authenticate >the end-user device > >2) Do legacy authentication(securid, token card) to authenticate the client > > >3) Create a unique shared secret for the authenticated user > >4) Use it do regular IKE exchanges between the client and the server > > >What is the need to extend IKE? >Isn't all that is needed is a simple protocol on top of IKE (and separate >from IKE)? > > >Thanks, > >-- sankar ramamoorthi (sankar@vpnet.com) -- > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Thu Sep 30 23:16:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id XAA22961; Thu, 30 Sep 1999 23:16:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07167 Thu, 30 Sep 1999 23:08:42 -0400 (EDT) Message-ID: <19991001031010.5157.qmail@hotmail.com> X-Originating-IP: [207.181.90.145] From: "Roy Pereira" To: dharkins@network-alchemy.com, pkoning@xedia.com Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: New XAUTH draft Date: Thu, 30 Sep 1999 23:10:09 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm still unsure why you equate XAUTH with a "common group shared secret". XAUTH is just a mechanism to extend IKE to provide other authentication methods. How you secure it is up to you. You can choose to use the standard IKE mechanisms (cert. or shared secret) or Tamir's Hybrid proposal. >From: Dan Harkins >To: Paul Koning >CC: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com >Subject: Re: New XAUTH draft >Date: Thu, 30 Sep 1999 12:02:04 -0700 > >On Thu, 30 Sep 1999 14:03:27 EDT you wrote > > I know you don't like XAUTH and are doing everything you can to > > torpedo it. That's well and good, but it seems to me that the points > > you're raising don't hold together. > > > > If you authenticate with a shared secret, what you know is that the > > other party knows the shared secret. > > > > What does that tell you? In the general case, nothing. > > > > In the specific case where each of the holders of the shared secret > > takes effective action to ensure it is not disclosed to third parties, > > shared secret authentication tells you that the other party is a > > member of the set who's supposed to know the shared secret. > >Right, that's all you know. This person is "in the set". And that's all >you know about the IPSec SAs. The user is "in the set". But XAUTH is >supposed to provide user-level authentication. But it can't. All you >can possibly know about the IPSec SAs are that the user is "in the set" >not which specific member of the set this person is. And practically >how big are these sets? 5? 10? 1000? More? I'd say it's in the 1000 or >more range. And in that case you are effectively unauthenticated. > > > Whether that set has two members or more makes no difference. The > > mechanism tells you that the other party is a member of the set. > > > > Yes, from the point of view of risk management it is better for the > > size of that set to be small. But it is incorrect to claim that the > > only valid set size is 2. For some applications 2 is too large, for > > others it is too small. > > > > Also, you say that XAUTH gives you unauthenticated IPSec SAs. That > > doesn't make any sense. First of all, clearly those SAs are > > authenticated to whatever granularity the initial main mode exchange > > gives you. For preshared key, that means it's authenticated to within > > the set that knows that shared secret. How can you refer to this as > > "unauthenticated"? (Reference to April 1 RFCs isn't a useful way of > > arguing these points.) > >IKE is supposed to provide SAs for IPSec that only the two peers are >able to use. With a group key doing the "authentication" you lose that. >Any member of the set can snoop traffic for any other member of the set >by doing a man-in-the-middle with the unauthenticated IKE exchange >and then just forwarding the XAUTH stuff on to the gateway and back to >the client. Nothing in the XAUTH exchange binds the specific user to the >resulting IPSec SAs. > > > Second, I don't understand why you claim XAUTH offers no additional > > security. Or is that not what you claim? You did use the > > qualification "to the IKE secret state". I guess in the sense that > > the IKE SA related secret state is established by the main mode > > exchange, that may be true in some abstract sense; the other endpoint > > that holds the main mode state is authenticated by the main mode > > mechanism only. But in what way is that relevant? That system is > > acting on behalf of one or more parties, and those parties (for whom > > the IPSec SAs are being set up) are authenticated by XAUTH. You do > > not get the IPSec SA unless you pass that second step. > > > > To put it differently, can you describe an attack that demonstrates > > your assertion? Say that you and I are both using XAUTH to > > authenticate with a central site, using a preshared key common to the > > three of us. Can you demonstrate an attack that allows you to > > impersonate me, resulting in IPSec SAs to your box that appear to be > > bound to my identity? If so, then I would agree to your assertion. > > But if not, it seems to me your assertion is either invalid or not > > useful, and XAUTH is then shown to provide an additional service. > >I do a man-in-the-middle against your phase 1 exchange. Then I forward >your XAUTH messages onto the gateway. I accept the final "SET(status=OK)" >message from the gateway but send you a "SET(status=not ok)". Now I get >IPSec SAs and the gateway thinks it's you. I can even send you an IKE >delete message so you'll blow your IKE SA away. You'll think, "oh crap. >I must've entered this stuff wrong. I'll try again." Then you try again >and presumably succeed. In the mean time I have SAs that the gateway >erroneously thinks are yours. > >Granted it's about as practical as other man-in-the-middle attacks but >it is possible. > >All it seems XAUTH provides is something to give to those customers >that just want to continue to use their token cards (at least that's seems >to be the motivation and defense of XAUTH). But just because you want to >use a token card shouldn't mean that you have to do it insecurely. There >is a way to do it right and a draft describing it will be released shortly. >In a nutshell, the client generates a public/private key pair and uses >the token card to cause the gateway to trust the public key (in effect >he goes through a scaled down on-line certificate enrollement scheme but >does not get a certificate, it just causes the gateway to trust the key). >The IKE exchange is then authenticated with digital signatures binding >each side to the SKEYID state as well as proving identity to the other >party. As I said, it'll be out RSN. > > Dan. > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Thu Sep 30 23:16:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id XAA22960; Thu, 30 Sep 1999 23:16:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07277 Thu, 30 Sep 1999 23:26:09 -0400 (EDT) Message-ID: <19991001032738.50893.qmail@hotmail.com> X-Originating-IP: [207.181.90.145] From: "Roy Pereira" To: zegman@checkpoint.com, ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: [Fwd: New XAUTH draft] Date: Thu, 30 Sep 1999 23:27:37 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Again, I fail to understand what this has to do with XAUTH. You would have the same problem if you were stupid enough to use the same shared secret for a large group of people in a real working environment, with or without XAUTH. XAUTH can be used with shared secrets or with the more secure certificate mechanisms. Just because you want to use your existing RADIUS authentication server, doesn't mean that you forgo your phase security. btw: 'Hybrid' addresses those scenarios where you do not wish to establish the normal IKE phase 1 security contexts. >From: Tamir Zegman >To: ipsec@lists.tislabs.com >Subject: [Fwd: New XAUTH draft] >Date: Thu, 30 Sep 1999 23:05:43 +0200 > >  > >Dan Harkins wrote: >< trimmed > > > >   > > The client is presumed to be coming from an unknown IP address so it's > > difficult to have multiple pre-shared keys on the gateway because he > > won't know which one to use. But even if you do find some way >(aggressive > > mode using ID_KEYID with some blob there which says "use pre-shared key > > foo" for instance) you still have the burden of maintainance of the > > multiple pre-shared key sets and managing who goes into what set. That > > becomes very Rube Goldbergian and still does not overcome the fact that > > any member in a set can snoop traffic or inpersonate any other member of > > the set. > > > >   Dan. > >On top of what Dan said, consider an employee who was just sacked. >You now need to modify the pre-shared key used by the set of users he used >to >belong to. >You'll need to notify (in a secure manner) all members of the group and >give >them the new group secret! >  > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Thu Sep 30 23:42:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id XAA25418; Thu, 30 Sep 1999 23:42:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07325 Thu, 30 Sep 1999 23:44:21 -0400 (EDT) Message-Id: <199910010344.UAA29465@Potassium.Network-Alchemy.COM> To: Michael Richardson cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 30 Sep 1999 21:04:18 EDT." <199910010104.VAA04142@pzero.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29462.938749480.1@network-alchemy.com> Date: Thu, 30 Sep 1999 20:44:40 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 30 Sep 1999 21:04:18 EDT you wrote > > Dan, I have a question (even though I've been trying hard to delete every > message that says "XAUTH" or "Hybrid" in it), do *you* prefer hybrid to XAUTH >? Yes. Hybrid+XAUTH is much better than XAUTH. It prevents the m-in-m issue by authenticating the IKE SA (unidirectionally, but authenticating it nonetheless) prior to doing the XAUTH stuff. But the client does not bind himself in any way to the SKEYID state even with Hybrid+XAUTH. It might not matter and I'm not a cryptographer but it just rubs the wrong way. A much better solution would be for Hybrid to not proceed to XAUTH but to use its secure channel to authenticate a (raw) public key for the client and then use that key to do a standard digital signature authentication. That whole phase 1.5 stuff is an unnecessary complication on an already extremely complicated protocol. Sometimes you proceed from 1 to 2 other times it's 1 to 1.5 to 2. Error prone. Yeech. Dan.