From mcr at sandelman.ottawa.on.ca Fri Feb 10 16:17:22 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 10 Feb 2006 19:17:22 -0500 Subject: [anonsec] SAB without connection latching References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Stephen" == Stephen Kent writes: >> Keep in mind Joe's point that this is a problem for IPsec even without >> BTNS in the picture. A PAD entry that allows road warriors access to >> dynamically allocated addresses will allow road warriors to steal each >> other's traffic in the same way as we've discussed could happen with >> BTNS. Stephen> I don't think this discussion has provided a good example to Stephen> illustrate the problem in question. I'm guessing that the Stephen> concern begins with the notion that one needs to dynamically Stephen> update or create a PAD entry to accommodate road Stephen> warriors. However, there has been no discussion in IPsec to Stephen> suggest that dynamic PAD entries are needed to support road Stephen> warriors. Stephen> A PAD entry might identify the set of all road warriors for a Stephen> company by a wild card name, e.g., *@bbn.com. The authorization Stephen> data for the entry might say that these individuals have certs Stephen> that can be validated using the CA cert for BBN. The entry would Stephen> also specify that the IKE ID (not the road warrior's source Stephen> address) be used for SPD matching. The SPD entry for these folks Stephen> would be tagged with the name. Section 4.4.1.1 specifically Stephen> gives the road warrior case as a motivation for the use of names Stephen> to specify SPD entries, and says how to take the IP address of Stephen> the road warrior (as the initiator) and use it as the remote Stephen> address for the SPD entry (in a sort of PFP fashion). This Stephen> should avoid the hijacking concern alluded to above. RW A arrives, sets up a tunnel. Let's say it is: 205.150.200.225/32 -> 205.150.200.160/28 => 205.150.200.134/32 leftsubnet rightsubnet gateway (this is a tunnel that I have up right now. It protects traffic across my local wireless network destined to the subnet my mail server is on) I have a policy that says that @marajade.sandelman.ca may connect from any IP, building a tunnel from that IP to 205.150.200.160/28. (doesn't work when I'm behind a NAT, because I propose an IP which isn't my outer IP.) RW B now arrives. It's my colleague. He quickly pulls the battery out of my laptop while I'm in the washroom. Then he brings up: 205.150.200.225/32 -> 205.150.200.160/28 => 205.150.200.134/32 leftsubnet rightsubnet gateway he has the same policy as I do, only a different FQDN with a different key defined. He gets "my" traffic. Well, it's hard to argue who was in the right. Stephen> Mike Richardson discussed how 2401 implementations (the PAD Stephen> concept was not part of the old standard) supported road Stephen> warriors, in the BTNS meeting at IETF64. Mike, how do you Stephen> envision using a PAD-equipped IPsec to accommodate road Stephen> warriors? Do you see a need for dynamic PAD entries? I don't seem to remember my argument. Obviously I'm reading this thread some 8 weeks after it was written. Sorry, life. In a host-host BTNS system, with IPsec integrated into the stack and connection latching, the TCP/UDP layer asks "please send this packet with SA#xxx" and discovers either that the SA is gone, or if not gone, then it goes out encrypted to RW A, which RW B can't decrypt. Happens that I'm implementing connection latching for UDP in openswan this past month, so that we can deal with having two identically numbered l2tp clients behind two different NATs. (i.e. two windows laptops are both 192.168.1.101 behind their commodity NAPT box). This is one reason I'm not reading lists. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQ+0tFICLcPvd0N1lAQJZfwf/UqNt7isGYYEJK79zvckBgJfruAEuVVZp lRkSTWge30pTzkSSdVpKjF34NcrDdh/i/mC8VvQTx8JCRGoopHLkaN80wd+pkHhr i/cKcVVRFgHwPdNvgOGZ/JfTOBigmmLxfemlh6uwFghbFHwsnoi/RJEt2xmD8+kX aI2J0Xp4f0NJHdchUjXcoi4X/qHyz6uJ9ey8Hd3qD25abOeVY/CPNdSOuAoljKdJ ndV61htIzrE1B6NFPtdcgfcyCdTkUNakroD/irAqjfiDbDWkVGxMHIzSkwNCILrH hEH0RqAkHeEJKyqPG9ntOIXl+Z+G9J3NZZFUn/3KsMdUNO18a1HS1A== =KjCA -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Fri Feb 10 17:03:54 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 10 Feb 2006 20:03:54 -0500 Subject: [anonsec] 3401 and highjacking References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> You ask what happens if an SA (for a road warrior) expires and Stephen> different peer claims the same remote IP address. It is not Stephen> clear that there is any point in the re-key process that makes Stephen> this a problem, per se. I think the real question is whether we Stephen> check to ensure that we don't create two SAs with different It's not about rekeys. RW A (Stephen Kent) connects does it's thing. It leaves, probably abruptly when it goes into hibernate mode as you close the lid and begin to board aircraft. RW B (Karen Sao) (not being on the same flight as you because, well, BBN and the IETF IPsec community can't let you both die in the same plane crash :-) then opens her laptop, gets the same IP address that you had (from the point of view of your gateway) (Either because the airport departure lounge is very busy, and the DHCP leases are ver short, or because you are all NAT'ed to a single IP anyway) What does the gateway do? Does it drop the tunnel to RW A (you) when RW B shows up? Does it refuse? Which is correct? If the gateway drops the tunnel to RW A in favour of RW B, then any entity which the gateway trusts with a policy like this can DOS other clients, if it can do some kind of on-path-ish attack. (Remembering that this might not be hard on wireless networks, and a NAPT might make it happen without malicious intent). On the other hand, if the gateway doesn't drop the tunnel to RW A in favour of RW B, then RW B might not be able to get online until the SA expires. Some things mitigate this: most gateways now use DPD. If the DPD values are short enough, then the DPD will keep the tunnel to RW A up for awhile, hopefully long enough for a TCP above to give up. At which point, the tunnel gets killed (probably after a few minutes). Now, relevance to BTNS: BTNS means that *ALL* hosts on the Internet are possibly able to make connections, not just your set of trusted road warriors. Last time I asked what modes were going to be used, I was told transport mode, and that this was going to just "work" through NAT (or that NAT wasn't important). I think that exactly how the gateway deals with NAT (and therefore what shape it's SPD takes) is going to be relevant. We may have to specify one solution as being better than others, or at least explain how to write the right SPD entries for various NAT-T+transport combinations. (%) NAT-T caveats. Or why it isn't really a problem in general. If you use NAT-T, then you get UDP encapsulation, and the NAPT assigns RW A/RW B new port numbers. So, the gateway can see you each as unique hosts. If the NAT is ESP/IKE aware (i.e. "helpful" aka "IPsec passthrough"), then this might not happen. Secondly, odds are you are going to use tunnel mode, and are going to propose and/or be assigned (by modecfg), a unique inner address, so in fact the SPD entry for each of you are actually unique. So, to make this scenario work you'd have to use transport mode, and the NAPT would have to assign the same port. A proper NAPT won't reallocate the UDP port number within a reasonable timeout period to a different client. The summary is that unless all the gods are aligned against you, the NAPT won't cause a non-malicious incident. The malicious situation is still possible. From Nicolas.Williams at sun.com Sat Feb 11 00:57:41 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sat, 11 Feb 2006 02:57:41 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: <20060211085741.GV9977@binky.Central.Sun.COM> On Fri, Feb 10, 2006 at 07:17:22PM -0500, Michael Richardson wrote: > In a host-host BTNS system, with IPsec integrated into the stack and > connection latching, the TCP/UDP layer asks "please send this packet with > SA#xxx" and discovers either that the SA is gone, or if not gone, then it > goes out encrypted to RW A, which RW B can't decrypt. Better: - transport, on output, says "please send this packet protected by an SA that matches the characteristics of the SA originally used for latching (this includes crypto algs AND peer IDs). - on input, IPsec/IP tell the transport "this packet arrived on this SA" and then the transport checks that the SA matches the latched characteristics - the actual latch is constructed from the characteristics of the SA that protected the first packet sent or received on the given connection (e.g., the SYN packet, in the case of TCP). Nico -- From Nicolas.Williams at sun.com Sat Feb 11 01:31:25 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sat, 11 Feb 2006 03:31:25 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: <20060211093124.GY9977@binky.Central.Sun.COM> On Fri, Feb 10, 2006 at 08:03:54PM -0500, Michael Richardson wrote: > Now, relevance to BTNS: BTNS means that *ALL* hosts on the Internet are > possibly able to make connections, not just your set of trusted road > warriors. As the size of a trust domain approaches the size of the Internet the difference between BTNS and non-BTNS approaches zero. I'm assuming the use of wildcard PAD entries and the non-use o iPAddress subject alt names for "clients" -- a fair assumption for an organization that large! > Last time I asked what modes were going to be used, I was told transport > mode, and that this was going to just "work" through NAT (or that NAT wasn't > important). I think that exactly how the gateway deals with NAT (and > therefore what shape it's SPD takes) is going to be relevant. BTNS is intended (e.g., by yours truly) to be used in end-to-end communications, not for client<->SG. The point I'm trying to make (before David Black does :) is that tunnel vs. transport mode isn't as interesting as whether BTNS is used to protect tunnelled traffic or end-to-end comms. And this because iSCSI uses tunnel mode, though it doesn't actually tunnel anything (in the SG sense). > We may have to specify one solution as being better than others, or at > least explain how to write the right SPD entries for various NAT-T+transport > combinations. I think we want to leave tunnelling out of scope for BTNS. That doesn't simplify things so much though -- we still need connection latching and, ultimately APIs to inspect what is latched and channel bindings. But note that IPsec generally needs this, and not because of BTNS -- BTNS is merely bringing the issue to a head. Nico -- From kent at bbn.com Mon Feb 13 13:29:33 2006 From: kent at bbn.com (Stephen Kent) Date: Mon, 13 Feb 2006 16:29:33 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: Michael, I'm getting too old to remember message exchanges 2 months ago :-). Nonetheless, using your airport lounge example, if Karen gets my old address, and if she successfully creates a new IKE SA, then she can have that addresses in parallel with me, in some circumstances. the addresses we're discussing here are unprotected ones, not the protected ones inside tunnel headers that are used by RWs to access SGs back at enterprise HQ. Thus they never are used for access control purposes, relative to the SPD or SAD. So, in the tunnel mode case, I think we're OK, even from the DoS concerns you raised. But, in transport mode (not applicable to the RW scenario), I agree that there could be DoS problems. Also, if Karen asserts the same inner address as me, and it is within an address range that is approved for BTNS use, then we do have a problem. This seems to be a good reason to be very careful in claiming what modes and in what contexts BTNS will work, as you suggest. Steve From Nicolas.Williams at sun.com Mon Feb 13 21:56:47 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 13 Feb 2006 23:56:47 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: <20060214055647.GY9977@binky.Central.Sun.COM> On Mon, Feb 13, 2006 at 04:29:33PM -0500, Stephen Kent wrote: > Michael, > > I'm getting too old to remember message exchanges 2 months ago :-). > > Nonetheless, using your airport lounge example, if Karen gets my old > address, and if she successfully creates a new IKE SA, then she can > have that addresses in parallel with me, in some circumstances. the > addresses we're discussing here are unprotected ones, not the > protected ones inside tunnel headers that are used by RWs to access > SGs back at enterprise HQ. Thus they never are used for access > control purposes, relative to the SPD or SAD. So, in the tunnel mode > case, I think we're OK, even from the DoS concerns you raised. But, > in transport mode (not applicable to the RW scenario), I agree that > there could be DoS problems. Also, if Karen asserts the same inner > address as me, and it is within an address range that is approved for > BTNS use, then we do have a problem. Yes, the assumption is that Karen could get the same inner address as you had. Often it's easier to not do static address assignments to SG users. > This seems to be a good reason to be very careful in claiming what > modes and in what contexts BTNS will work, as you suggest. But you missed the point -- this is a problem with use of wildcards in PAD entries, not with BTNS; BTNS merely makes the scope wider (from, e.g., all principals in a given PKI to practically *anyone*; given a sufficiently large PKI the distinction isn't all that large). So, yes, document this we must, but more importantly, and particularly for transport mode, we have to provide one or more of leap-of-faith (ick), connection latching and/or channel bindings (which, of course, presume connection latching). Nico -- From kent at bbn.com Wed Feb 15 13:27:42 2006 From: kent at bbn.com (Stephen Kent) Date: Wed, 15 Feb 2006 16:27:42 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060214055647.GY9977@binky.Central.Sun.COM> References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> Message-ID: At 11:56 PM -0600 2/13/06, Nicolas Williams wrote: >On Mon, Feb 13, 2006 at 04:29:33PM -0500, Stephen Kent wrote: >> Michael, >> >> I'm getting too old to remember message exchanges 2 months ago :-). >> >> Nonetheless, using your airport lounge example, if Karen gets my old >> address, and if she successfully creates a new IKE SA, then she can >> have that addresses in parallel with me, in some circumstances. the >> addresses we're discussing here are unprotected ones, not the >> protected ones inside tunnel headers that are used by RWs to access >> SGs back at enterprise HQ. Thus they never are used for access >> control purposes, relative to the SPD or SAD. So, in the tunnel mode >> case, I think we're OK, even from the DoS concerns you raised. But, >> in transport mode (not applicable to the RW scenario), I agree that >> there could be DoS problems. Also, if Karen asserts the same inner >> address as me, and it is within an address range that is approved for >> BTNS use, then we do have a problem. > >Yes, the assumption is that Karen could get the same inner address as >you had. Often it's easier to not do static address assignments to >SG users. sorry, I forgot the context from last year, and it was not explicitly re-stated in Mike's message. > >> This seems to be a good reason to be very careful in claiming what >> modes and in what contexts BTNS will work, as you suggest. > >But you missed the point -- this is a problem with use of wildcards in >PAD entries, not with BTNS; BTNS merely makes the scope wider (from, >e.g., all principals in a given PKI to practically *anyone*; given a >sufficiently large PKI the distinction isn't all that large). If a sys admin creates a PAD entry with wildcard values for source addresses, and matches it with an SPD entry that is address (vs. name) based, then the sys admin is asserting that the entities who are associated with the PAD entry are all viewed as equivalent for security purposes. If the PAD and SPD entries are name-based, then access control should work as expected, but there might still be a conflict over the inner addresses. An obvious question is how such addresses are assigned. If they are static, and the RWs don't modify them, then all should be OK. If they are DHCP assigned, as is typical for an RW-SG context, again, there should be non collisions. All of this seems reasonable for non-BTNS PAD entries. BTNS makes life complex, because the PAD entries are not being used for IPsec-level authenticated communication, yet there can be IPsec-level address conflicts. To me this seems to be an indication of a problem we are creating for ourselves, by applying security measures at layer 3 (which use layer 3 IDs, i.e., IP addresses), while relying on layer 7 to manage authentication. Steve From Nicolas.Williams at sun.com Wed Feb 15 14:42:34 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 15 Feb 2006 16:42:34 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> Message-ID: <20060215224234.GD9977@binky.Central.Sun.COM> On Wed, Feb 15, 2006 at 04:27:42PM -0500, Stephen Kent wrote: > >But you missed the point -- this is a problem with use of wildcards in > >PAD entries, not with BTNS; BTNS merely makes the scope wider (from, > >e.g., all principals in a given PKI to practically *anyone*; given a > >sufficiently large PKI the distinction isn't all that large). > > If a sys admin creates a PAD entry with wildcard values for source > addresses, and matches it with an SPD entry that is address (vs. > name) based, then the sys admin is asserting that the entities who > are associated with the PAD entry are all viewed as equivalent for > security purposes. If the PAD and SPD entries are name-based, then > access control should work as expected, but there might still be a > conflict over the inner addresses. > > An obvious question is how such addresses are assigned. [...] Forget SG usage for a minute and think about end-to-end IPsec. Q: Why would anyone use wildcard matching? A: Because as the size and/or dynamism of the network increases it becomes too difficult to either maintain IPsec configurations or to maintain host certificates with iPAddress subject alt names. Alternatives for the security conscious: push network security up the stack (SSHv2, TLS, etc.) or don't grow your network so large. Now, for end-to-end network security we have seen network security pushed up the stack, indeed (if it didn't even just start there). We should be happy with this state of affairs... ...unless we should find the possibility of off-loading more work onto NICs attractive (e.g., crypto), which in turn requires pushing at least session crypto back down the stack. BTNS + connection latching + channel bindings does just that while leaving principal authentication where it already is (up the stack). > BTNS makes life complex, because the PAD entries are not being used > for IPsec-level authenticated communication, yet there can be > IPsec-level address conflicts. To me this seems to be an indication > of a problem we are creating for ourselves, by applying security > measures at layer 3 (which use layer 3 IDs, i.e., IP addresses), > while relying on layer 7 to manage authentication. I'll restate: large, dynamic networks and IPsec configuration w/o wildcards don't mix well. This is not BTNS' fault. Nico -- From kent at bbn.com Thu Feb 16 10:12:35 2006 From: kent at bbn.com (Stephen Kent) Date: Thu, 16 Feb 2006 13:12:35 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060215224234.GD9977@binky.Central.Sun.COM> References: <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> Message-ID: Nico, I appreciate your analysis of the issues associated with the problems we are discussing, but I disagree with several of your assertions and conclusions. Network dynamics are more a fact of life today than they were in the past, which makes use of IP addresses less attractive as identifiers. Yet, at layer 3, on a per-packet basis, we have only addresses as end-point IDs, especially for intermediate systems like routers and firewalls. So,if we choose to enforce access controls at layer three, we have to be very careful in how we deal with identifiers, to ensure that we don't make mistakes resulting from cross-layer ambiguities. What we have done in IPsec and in other protocols is to allow for higher layer IDs to be used in lieu of addresses (e.g., to accommodate the dynamics you cite), but then to bind these IDs to addresses to enable efficient, per-packet access control policy enforcement for some time interval. An inevitable side effect of this is the potential to have a mismatch between a higher level ID and the address, based on unsynchronized management practices between the layers, e.g., address reassignment. You suggested that network security is being pushed up the stack. In some regards that is true, and in others it is not. User authentication at the application layer is nothing new; it has been a staple of host security since the days of multi-programming, time sharing, etc. Is it a network security issue? We have examples of how to make it more of a network security issue and reduce security, e.g., the Unix rhost file model. If we use certs to authenticate users does that make this a network security mechanism? I think not. On the other hand use of SSL/TLS is certainly an example of moving security up the stack (from layer 3 to layer 5). For some set of contexts, an SSL solution may be more appropriate than an IPsec solution. But, this WG decided to focus on IPsec, and so such discussions are out of scope here. There are multiple motivations for imposing security controls at layer 3. Performance may be important in some instances, as you suggest, but more often the motivations have to do with assurance and management. Lower layer controls can be more secure that higher later controls, given the unfortunate state of OS and application security. Lower layer controls can be imposed (cleanly) at points other than end systems, which simplifies management and also may improve assurance. None of this says that application layer security is redundant. However, it also does not suggest that trying to split security services between layer 3 and layer 7, as some BTNS use cases require, will necessarily work well. When this WG was chartered I noted that there were multiple constituencies, each with different goals, all of which hoped to use the same or similar mechanisms to achieve these disparate goals. What we are seeing here may be an example of that. Steve From Nicolas.Williams at sun.com Thu Feb 16 12:27:10 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 16 Feb 2006 14:27:10 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> Message-ID: <20060216202710.GB20143@binky.Central.Sun.COM> On Thu, Feb 16, 2006 at 01:12:35PM -0500, Stephen Kent wrote: > Nico, > > I appreciate your analysis of the issues associated with the problems > we are discussing, but I disagree with several of your assertions and > conclusions. > > Network dynamics are more a fact of life today than they were in the > past, which makes use of IP addresses less attractive as identifiers. > Yet, at layer 3, on a per-packet basis, we have only addresses as > end-point IDs, especially for intermediate systems like routers and > firewalls. So,if we choose to enforce access controls at layer three, > we have to be very careful in how we deal with identifiers, to ensure > that we don't make mistakes resulting from cross-layer ambiguities. > What we have done in IPsec and in other protocols is to allow for > higher layer IDs to be used in lieu of addresses (e.g., to > accommodate the dynamics you cite), but then to bind these IDs to > addresses to enable efficient, per-packet access control policy > enforcement for some time interval. An inevitable side effect of this > is the potential to have a mismatch between a higher level ID and the > address, based on unsynchronized management practices between the > layers, e.g., address reassignment. In other words: we're in agreement on the significance of wildcard matching in PAD entries. Cool. > You suggested that network security is being pushed up the stack. In > some regards that is true, and in others it is not. User > authentication at the application layer is nothing new; it has been a > staple of host security since the days of multi-programming, time > sharing, etc. Is it a network security issue? We have examples of how > to make it more of a network security issue and reduce security, > e.g., the Unix rhost file model. If we use certs to authenticate > users does that make this a network security mechanism? I think not. > On the other hand use of SSL/TLS is certainly an example of moving > security up the stack (from layer 3 to layer 5). For some set of > contexts, an SSL solution may be more appropriate than an IPsec > solution. But, this WG decided to focus on IPsec, and so such > discussions are out of scope here. Hmm, no, pushing session protection down the stack is in scope, indirectly at least. > There are multiple motivations for imposing security controls at > layer 3. Performance may be important in some instances, as you > suggest, but more often the motivations have to do with assurance and > management. Lower layer controls can be more secure that higher later > controls, given the unfortunate state of OS and application security. > Lower layer controls can be imposed (cleanly) at points other than > end systems, which simplifies management and also may improve > assurance. None of this says that application layer security is > redundant. However, it also does not suggest that trying to split > security services between layer 3 and layer 7, as some BTNS use cases > require, will necessarily work well. If channel binding to IPsec channels were not feasible I'd not spend one more ounce of energy on BTNS. Are you saying that they are not? Please expand. > When this WG was chartered I noted that there were multiple > constituencies, each with different goals, all of which hoped to use > the same or similar mechanisms to achieve these disparate goals. What > we are seeing here may be an example of that. This past week on this thread we've been discussing a weakness in the RFC4301 model. This somehow led me to explain, for the nth time, my use case for BTNS. Now that you're on the record as acknowledging (above) that use of wildcards in PAD entries represents a significant trade-off maybe we can move on and discuss other things :) Nico -- From kent at bbn.com Thu Feb 16 16:16:44 2006 From: kent at bbn.com (Stephen Kent) Date: Thu, 16 Feb 2006 19:16:44 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060216202710.GB20143@binky.Central.Sun.COM> References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> Message-ID: Nico, I'm afraid your interpretation of my comments diverges from my intent in several places. I'll try to clarify, using some different words this time, and responding directly to your comments. #1: do we agree on the "significance" of wildcard matching in the PAD? Not exactly. What I said is that address-based packet filtering is a necessary side effect of being able to operate at layer 3, especially for intermediate systems like SGs. This says nothing about the use of wildcards in the SPD or in the PAD. If we use only names (vs. addresses) in the SPD and PAD for specifying entries that trigger SA creation, we still can encounter problems due to address reuse: - Alice (at address X) successfully creates an SA with Bob, authenticating herself and matching a name-based PAD and SPD entry - Carol comes along, is assigned address X, and tries to create an SA with Bob, authenticating herself and matching a different name-based PAD and SPD entry - if both Alice and Carol connect to the same well-known port on Bob's computer, and if both happen to choose the same local port, we would now have two SAs that appear to be identical in terms of all five traffic selector values. this poses a problem for Bob's IPsec implementation, when it comes to mapping outbound traffic to the right SA. (It's not a problem for inbound traffic, since such traffic is demuxed based on SPI values chosen by Bob's IPsec implementation). If Bob has a BITW IPsec implementation, and thus no way to interact with Bob's computer to help resolve this ambiguity, what should it do? The safe bet is probably to refuse Carol's SA creation attempt, based on the reuse of X as the source address, to be safe. This approach to resolving an address reuse problem of this sort can be used irrespective of the reason that the conflict arises. Michael's example was different in various details, but focused on the potential problems caused by address reuse. He argued that there was no good way to deal with this, since one approach allows for DoS attacks against existing SAs, and the other discriminates against a legitimate user who happens to get the same address assignment. I'm in favor of door #2 here, and if I were the second user, I'd try to renew my DHCP lease to get a different address. My point here is that the type of problems we're discussing are not really specific to the use of wildcards, and probably not specific to the PAD design. Because BTNS wants to create SAs for entities who possess no authentication credentials, we cannot use the same set of criteria to reject SAs that use addresses that collide with other SAs, as suggested above. This exacerbates what I think is a relatively minor issue. I'd call this a BTNS-generated problem. #2 Did I say that pushing session protection down the stack is out of scope? No. I explained why I disagreed with your comment that performance was the motivation for pushing some security measures lower in the stack, while other factors pushed security measures higher in the stack. I also said that one could use SSL to address some (though not all) of the use cases that were put forth as motivations for BTNS, but that is out of scope for this WG, based on its current charter. #3. Did I say that channel binding to IPsec SAs is infeasible. Whether use of IPsec for channel binding is "feasible" is what the output of this WG will determine. I suggested that when one tries to split security service offerings between layers, one may create new problems, problems that may not arise if one avoids crossing layer boundaries in this fashion. Demonstrating the feasibility of using IPsec for channel binding is the responsibility of those who propose such uses. What we have discussed in the thread that was restarted from last year, was that under some circumstances, certain choices of PAD and SPD entries might be problematic, in principle. Michael also noted that we tend to not see this happening, due to various details of SG implementations. So, what might be a minor weakness of the 4301 model, in principle, may be a more serious problem for BTNS. I consider this a challenge for BTNS; I do not think it is a rationale to make significant changes to IPsec, to accommodate BTNS. Steve From Nicolas.Williams at sun.com Thu Feb 16 18:10:03 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 16 Feb 2006 20:10:03 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> Message-ID: <20060217021003.GJ20143@binky.Central.Sun.COM> On Thu, Feb 16, 2006 at 07:16:44PM -0500, Stephen Kent wrote: > Nico, > > I'm afraid your interpretation of my comments diverges from my intent > in several places. I'll try to clarify, using some different words > this time, and responding directly to your comments. > > #1: do we agree on the "significance" of wildcard matching in the PAD? I read the following to mean more or less "yes." [text not quoted.] > My point here is that the type of problems we're discussing are not > really specific to the use of wildcards, and probably not specific to > the PAD design. They are specific to configurations that try to avoid tying specific IDs to specific IP addresses. Such configurations will typically use wildcard matching, I assume. > Because BTNS wants to create SAs for entities who possess no > authentication credentials, we cannot use the same set of criteria to > reject SAs that use addresses that collide with other SAs, as > suggested above. This exacerbates what I think is a relatively minor > issue. I'd call this a BTNS-generated problem. Whereas I focus on the "exacerbates" part above. If we disagree then it's a matter of degree. > #2 Did I say that pushing session protection down the stack is out of scope? > > No. I explained why I disagreed with your comment that performance > was the motivation for pushing some security measures lower in the > stack, while other factors pushed security measures higher in the > stack. Was I not clear that this was *my* (as opposed to *the*) motivation? > I also said that one could use SSL to address some (though not > all) of the use cases that were put forth as motivations for BTNS, > but that is out of scope for this WG, based on its current charter. You wrote "[b]ut, this WG decided to focus on IPsec, and so such discussions are out of scope here." I took this to mean that you meant that talking about splitting security between layers is out of scope. Perhaps I read too much into that. > #3. Did I say that channel binding to IPsec SAs is infeasible. > > Whether use of IPsec for channel binding is "feasible" is what the > output of this WG will determine. I suggested that when one tries to > split security service offerings between layers, one may create new > problems, problems that may not arise if one avoids crossing layer > boundaries in this fashion. Demonstrating the feasibility of using > IPsec for channel binding is the responsibility of those who propose > such uses. Agreed. I thought perhaps you might have some comments specifically about the feasibility of channel bindings that you might share with us. > What we have discussed in the thread that was restarted from last > year, was that under some circumstances, certain choices of PAD and > SPD entries might be problematic, in principle. Michael also noted > that we tend to not see this happening, due to various details of SG > implementations. So, what might be a minor weakness of the 4301 > model, in principle, may be a more serious problem for BTNS. I > consider this a challenge for BTNS; I do not think it is a rationale > to make significant changes to IPsec, to accommodate BTNS. I do agree that BTNS makes that "minor" weakness in the RFC4301 model worse (and have said so now several times). I don't agree that that weakness is so minor. Given a sufficiently large, sufficiently dynamic network using IPsec (but not BTNS) that weakness approaches the same severity as in the BTNS case. In so far as when not using BTNS one does have a choice (strongly tie IDs and IP addresses or don't), this weakness is minor, but only if said choice is realistic, which, I suspect, it is not for sufficiently large&dynamic networks. Again, I read this to mean that we're mostly in agreement. From touch at ISI.EDU Fri Feb 17 07:43:55 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 17 Feb 2006 07:43:55 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> Message-ID: <43F5EF3B.5050301@isi.edu> Stephen Kent wrote: .... > ...I also said that one could use SSL to address some (though not > all) of the use cases that were put forth as motivations for BTNS, > but that is out of scope for this WG, based on its current charter. Since this point has been raised on repeated occasions: BTNS was motivated by the need to protect the network and transport headers. Connection-disruption attacks (RST attacks in specific, which also include ACK and other transport header attacks) were the primary case, and SSL does not protect against those. The ability to reuse techniques across different transport and higher layers was also sought, and for SSL again does not apply. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20060217/e792b240/signature.bin From mohanp at sbcglobal.net Fri Feb 17 09:57:38 2006 From: mohanp at sbcglobal.net (Mohan Parthasarathy) Date: Fri, 17 Feb 2006 09:57:38 -0800 (PST) Subject: [anonsec] 3401 and highjacking In-Reply-To: Message-ID: <20060217175738.22556.qmail@web80604.mail.yahoo.com> > > >>>>> "Stephen" == Stephen Kent > writes: > Stephen> You ask what happens if an SA (for a > road warrior) expires and > Stephen> different peer claims the same remote > IP address. It is not > Stephen> clear that there is any point in the > re-key process that makes > Stephen> this a problem, per se. I think the > real question is whether we > Stephen> check to ensure that we don't create > two SAs with different > > It's not about rekeys. > RW A (Stephen Kent) connects does it's thing. It > leaves, probably abruptly > when it goes into hibernate mode as you close the > lid and begin to board > aircraft. > > RW B (Karen Sao) (not being on the same flight as > you because, well, BBN and > the IETF IPsec community can't let you > both die in the same > plane crash :-) > > then opens her laptop, gets the same IP address > that you had (from the > point of view of your gateway) > (Either because the airport departure lounge is > very busy, and the DHCP > leases are ver short, or because you are all NAT'ed > to a single IP anyway) > > What does the gateway do? > Does it drop the tunnel to RW A (you) when RW B > shows up? > Does it refuse? Which is correct? > This was extensively discussed in MOBIKE (check the archives and also the appendix of the protocol draft). As you mentioned above, you need to handle this because of NAT where the SG sees the same address for two hosts behind the NAT. Some implementations (e.g. linux) may not work well today. But if you support NAT traversal, you better support this i.e both hosts should be able to create the SAs. Note that the hosts get different "inner" addresses. -mohan > If the gateway drops the tunnel to RW A in favour > of RW B, then any entity > which the gateway trusts with a policy like this can > DOS other clients, if it > can do some kind of on-path-ish attack. (Remembering > that this might not be > hard on wireless networks, and a NAPT might make it > happen without malicious > intent). > On the other hand, if the gateway doesn't drop the > tunnel to RW A in favour > of RW B, then RW B might not be able to get online > until the SA expires. > > Some things mitigate this: most gateways now use > DPD. If the DPD values are > short enough, then the DPD will keep the tunnel to > RW A up for awhile, > hopefully long enough for a TCP above to give up. At > which point, the tunnel > gets killed (probably after a few minutes). > > Now, relevance to BTNS: BTNS means that *ALL* > hosts on the Internet are > possibly able to make connections, not just your set > of trusted road > warriors. > Last time I asked what modes were going to be > used, I was told transport > mode, and that this was going to just "work" through > NAT (or that NAT wasn't > important). I think that exactly how the gateway > deals with NAT (and > therefore what shape it's SPD takes) is going to be > relevant. > We may have to specify one solution as being > better than others, or at > least explain how to write the right SPD entries for > various NAT-T+transport > combinations. > > (%) NAT-T caveats. Or why it isn't really a problem > in general. > If you use NAT-T, then you get UDP > encapsulation, and the NAPT assigns RW > A/RW B new port numbers. So, the gateway can see > you each as unique > hosts. If the NAT is ESP/IKE aware (i.e. > "helpful" aka "IPsec > passthrough"), then this might not happen. > > Secondly, odds are you are going to use tunnel > mode, and are going to > propose and/or be assigned (by modecfg), a > unique inner address, so in > fact the SPD entry for each of you are actually > unique. > > So, to make this scenario work you'd have to use > transport mode, and > the NAPT would have to assign the same port. A > proper NAPT won't > reallocate the UDP port number within a > reasonable timeout period to > a different client. > The summary is that unless all the gods are > aligned against you, > the NAPT won't cause a non-malicious incident. > The malicious situation > is still possible. > > > > > > > > > _______________________________________________ > From lha at it.su.se Fri Feb 17 13:44:09 2006 From: lha at it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Fri, 17 Feb 2006 22:44:09 +0100 Subject: [anonsec] btns preliminary for ietf65 Message-ID: <877C678B-BADF-42FA-8A37-B118373437AD@it.su.se> Hello, We have requested a 2h slot at IETF65, and would like to propose an agenda that looks something like the one included below. Is there anything that we should add/modify ? Thanks, Love Preliminaries - Chairs (5 min) - Introduction - Blue Sheets - Scribe, Jabber - Agenda Bashing Document Status - Chairs (5 min) - Problem statement and applicablity statement (-02) - Unauthenticated mode of IPsec Technical Discussion (N min) Any issues of problem statement and applicablity statement draft-ietf-btns-prob-and-applic-02.txt Unauthenticated mode of IPsec Discuss other outstanding issues Update Milestones - Chairs and Participants (10 min) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/anonsec/attachments/20060217/a264f77f/PGP.bin From touch at ISI.EDU Fri Feb 17 21:59:07 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 17 Feb 2006 21:59:07 -0800 Subject: [anonsec] new draft-ietf-btns-prob-and-applic-02.txt available Message-ID: <43F6B7AB.2060105@isi.edu> Hi, all, An update to the problem statement has been submitted as an Internet draft; it is available on the website, along with an updated list of pending issues. http://www.postel.org/anonsec Joe, David, and Yu-Shun -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20060217/3ce4f118/signature.bin From Nicolas.Williams at sun.com Mon Feb 20 00:53:51 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Feb 2006 02:53:51 -0600 Subject: [anonsec] New BTNS I-Ds Message-ID: <20060220085350.GY20143@binky.Central.Sun.COM> I've just submitted: - draft-btns-btns-00.txt - draft-btns-connection-latching-00.txt The latter I wrote just now, over the past couple of hours, in a hurry, so don't be surprised if there's some typos or thinkos in it. Cheers, Nico -- From kent at bbn.com Tue Feb 21 08:50:09 2006 From: kent at bbn.com (Stephen Kent) Date: Tue, 21 Feb 2006 11:50:09 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43F5EF3B.5050301@isi.edu> References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> Message-ID: At 7:43 AM -0800 2/17/06, Joe Touch wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enig684BFD82142EDE85608F2E7E" > > > >Stephen Kent wrote: >.... >> ...I also said that one could use SSL to address some (though not >> all) of the use cases that were put forth as motivations for BTNS, >> but that is out of scope for this WG, based on its current charter. > >Since this point has been raised on repeated occasions: > >BTNS was motivated by the need to protect the network and transport >headers. Connection-disruption attacks (RST attacks in specific, which >also include ACK and other transport header attacks) were >the primary case, and SSL does not protect against those. The ability to >reuse techniques across different transport and higher layers was also >sought, and for SSL again does not apply. > >Joe Joe, As I noted elsewhere in that message from which you extracted the quote, there are multiple, distinct constituencies for BTNS. Not all of them have the requirement you cite above re protection against transport layer attacks. So, it is inappropriate to make a broad statement about BTNS motivations without acknowledging this diversity. Also, SSL/TLS now is defined to support UDP, so the traditional argument about needing to use IPsec to accommodate other than TCP is no longer valid. Steve From Nicolas.Williams at sun.com Tue Feb 21 11:17:55 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 21 Feb 2006 13:17:55 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> Message-ID: <20060221191755.GI23695@binky.Central.Sun.COM> On Tue, Feb 21, 2006 at 11:50:09AM -0500, Stephen Kent wrote: > Also, SSL/TLS now is defined to support UDP, so the traditional > argument about needing to use IPsec to accommodate other than TCP is > no longer valid. For the record, I've not made that argument. Nico -- From touch at ISI.EDU Tue Feb 21 11:26:41 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 11:26:41 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> Message-ID: <43FB6971.6070805@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > At 7:43 AM -0800 2/17/06, Joe Touch wrote: > >> Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; >> boundary="------------enig684BFD82142EDE85608F2E7E" >> >> >> >> Stephen Kent wrote: >> .... >> >>> ...I also said that one could use SSL to address some (though not >>> all) of the use cases that were put forth as motivations for BTNS, >>> but that is out of scope for this WG, based on its current charter. >> >> >> Since this point has been raised on repeated occasions: >> >> BTNS was motivated by the need to protect the network and transport >> headers. Connection-disruption attacks (RST attacks in specific, which >> also include ACK and other transport header attacks) were >> the primary case, and SSL does not protect against those. The ability to >> reuse techniques across different transport and higher layers was also >> sought, and for SSL again does not apply. >> >> Joe > > Joe, > > As I noted elsewhere in that message from which you extracted the quote, > there are multiple, distinct constituencies for BTNS. Not all of them > have the requirement you cite above re protection against transport > layer attacks. So, it is inappropriate to make a broad statement about > BTNS motivations without acknowledging this diversity. Whatever BTNS is _now_ motivated by, it WAS motivated by the need for transport protection in the absence of a-priori keys (infrastructure or predeployed). As to the reasons you cited in your original quote: 1- performance 2- security of the software system 3- lower layer can be done elsewhere in the system 3- using BTNS as a place to explore split-layer security For which of these would SSL address a BTNS use case? > Also, SSL/TLS now is defined to support UDP, so the traditional argument > about needing to use IPsec to accommodate other than TCP is no longer > valid. There are more transport protocols than just TCP and UDP. See http://www.iana.org/assignments/protocol-numbers for a complete list ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD+2lxE5f5cImnZrsRAsyIAJ4zGH4/l8wo3b0PJANqKs9BXL+IlACg8PfL mNbTiDFmMeS9XKceZCuETys= =2UHC -----END PGP SIGNATURE----- From kent at bbn.com Tue Feb 21 14:03:57 2006 From: kent at bbn.com (Stephen Kent) Date: Tue, 21 Feb 2006 17:03:57 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060217021003.GJ20143@binky.Central.Sun.COM> References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> Message-ID: At 8:10 PM -0600 2/16/06, Nicolas Williams wrote: >... >> My point here is that the type of problems we're discussing are not >> really specific to the use of wildcards, and probably not specific to >> the PAD design. > >They are specific to configurations that try to avoid tying specific IDs >to specific IP addresses. Such configurations will typically use >wildcard matching, I assume. I see your point. I was focusing on use of wild cards as indices into the PAD or SPD, but you are correctly noting that the issues we are discussing arise even when wild cards are NOT used as indices. Anyway, I think the messages from Michael and Mohan note that these sorts of issues are adequately addressed, in the current IPsec environment, through the use of various ancillary mechanisms, some of which are needed to deal with mobility, NAT traversal, etc. > > Because BTNS wants to create SAs for entities who possess no >> authentication credentials, we cannot use the same set of criteria to >> reject SAs that use addresses that collide with other SAs, as >> suggested above. This exacerbates what I think is a relatively minor >> issue. I'd call this a BTNS-generated problem. > >Whereas I focus on the "exacerbates" part above. If we disagree then >it's a matter of degree. yes, it may just be a matter of degree. > >> #2 Did I say that pushing session protection down the stack is out of scope? >> >> No. I explained why I disagreed with your comment that performance >> was the motivation for pushing some security measures lower in the >> stack, while other factors pushed security measures higher in the >> stack. > >Was I not clear that this was *my* (as opposed to *the*) motivation? no, you were not clear, but I understand now. > >> I also said that one could use SSL to address some (though not >> all) of the use cases that were put forth as motivations for BTNS, >> but that is out of scope for this WG, based on its current charter. > >You wrote "[b]ut, this WG decided to focus on IPsec, and so such >discussions are out of scope here." I took this to mean that you meant >that talking about splitting security between layers is out of scope. > >Perhaps I read too much into that. yes, I think so. however, it is fair to say that I worry that the attempt to use layer 7 authentication in conjunction with layer 3 confidentiality, integrity and access control may a continuing source of problems for us. > > #3. Did I say that channel binding to IPsec SAs is infeasible. >> >> Whether use of IPsec for channel binding is "feasible" is what the >> output of this WG will determine. I suggested that when one tries to >> split security service offerings between layers, one may create new >> problems, problems that may not arise if one avoids crossing layer >> boundaries in this fashion. Demonstrating the feasibility of using >> IPsec for channel binding is the responsibility of those who propose >> such uses. > >Agreed. I thought perhaps you might have some comments specifically >about the feasibility of channel bindings that you might share with us. nope, not for now. > > What we have discussed in the thread that was restarted from last >> year, was that under some circumstances, certain choices of PAD and >> SPD entries might be problematic, in principle. Michael also noted >> that we tend to not see this happening, due to various details of SG >> implementations. So, what might be a minor weakness of the 4301 >> model, in principle, may be a more serious problem for BTNS. I >> consider this a challenge for BTNS; I do not think it is a rationale >> to make significant changes to IPsec, to accommodate BTNS. > >I do agree that BTNS makes that "minor" weakness in the RFC4301 model >worse (and have said so now several times). I don't agree that that >weakness is so minor. Given a sufficiently large, sufficiently dynamic >network using IPsec (but not BTNS) that weakness approaches the same >severity as in the BTNS case. In so far as when not using BTNS one does >have a choice (strongly tie IDs and IP addresses or don't), this >weakness is minor, but only if said choice is realistic, which, I >suspect, it is not for sufficiently large&dynamic networks. > >Again, I read this to mean that we're mostly in agreement. We do agree on a number of points. What worries me is that the possibility that one might look at the issues we have discussed and use that to justify changing existing features of IPsec in order to accommodate BTNS functionality. The form of the argument would be "... the PAD and SPD model don't accommodate some scenarios where address reuse by peers is a near term possibility, so let's change them in a way that also addresses problems associated with BTNS ..." My perspective is that the current PAD/SPD model works for IPsec, when one looks at the rest of the mechanisms used in IPsec deployments. The challenge for the WG is to add BTNS functionality to the existing IPsec architecture, without undermining the existing IPsec access control model. It is not to change the architecture for authenticated IPsec as a side effect of accommodating BTNS functionality. Steve From Nicolas.Williams at sun.com Tue Feb 21 14:14:53 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 21 Feb 2006 16:14:53 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> Message-ID: <20060221221453.GL23695@binky.Central.Sun.COM> On Tue, Feb 21, 2006 at 05:03:57PM -0500, Stephen Kent wrote: > At 8:10 PM -0600 2/16/06, Nicolas Williams wrote: > >Whereas I focus on the "exacerbates" part above. If we disagree then > >it's a matter of degree. > > yes, it may just be a matter of degree. Yes, I think so. [...] > >Perhaps I read too much into that. > > yes, I think so. > > however, it is fair to say that I worry that the attempt to use layer > 7 authentication in conjunction with layer 3 confidentiality, > integrity and access control may a continuing source of problems for > us. Hmm, no, the problems we've been discussing in this thread do not arise from trying to mix authentication at higher layers with session protection at lower layers. In fact, channel binding is an answer to those problems :) > >Again, I read this to mean that we're mostly in agreement. > > We do agree on a number of points. What worries me is that the > possibility that one might look at the issues we have discussed and > use that to justify changing existing features of IPsec in order to > accommodate BTNS functionality. The form of the argument would be > "... the PAD and SPD model don't accommodate some scenarios where > address reuse by peers is a near term possibility, so let's change > them in a way that also addresses problems associated with BTNS ..." I don't recall any such proposals. The argument that I've made is "these problems existed in the IPsec architecture to begin with, but they are most significant when BTNS is in the picture..." followed by "channel binding helps a lot" :) > My perspective is that the current PAD/SPD model works for IPsec, > when one looks at the rest of the mechanisms used in IPsec > deployments. I'm not sure that it does for sufficiently large and dynamic networks; I have no experience deploying and managing IPsec in such environments, so it's hard for me to say this authoritatively, but it does seem like a logical conclusion. > The challenge for the WG is to add BTNS functionality to the existing > IPsec architecture, without undermining the existing IPsec access > control model. It is not to change the architecture for authenticated > IPsec as a side effect of accommodating BTNS functionality. Not only. We should want BTNS not to undermine the existing IPsec architecture (I believe it does not, conceptually, nor concretely in my latest I-D), but also ensure that BTNS has certain desirable properties. BTNS as described in draft-btns-btns-00 is not good enough for my purposes, nor does it meet the original requirement of protection against MITM attacks after an initial exchange. But add draft-btns- connection-latching-00, channel bindings and/or leap-of-faith (ugh) and then it is good enough for some/most[/all?] of the stated purposes. Nico -- From kent at bbn.com Tue Feb 21 15:24:05 2006 From: kent at bbn.com (Stephen Kent) Date: Tue, 21 Feb 2006 18:24:05 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060221221453.GL23695@binky.Central.Sun.COM> References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> Message-ID: Nico, > > however, it is fair to say that I worry that the attempt to use layer >> 7 authentication in conjunction with layer 3 confidentiality, >> integrity and access control may a continuing source of problems for >> us. > >Hmm, no, the problems we've been discussing in this thread do not arise >from trying to mix authentication at higher layers with session >protection at lower layers. In fact, channel binding is an answer to >those problems :) Maybe for end systems, but probably not for intermediate systems. IPsec tries to offer roughly the same set of services for native host, BITS, BITW, and SG implementations. That's why we need to not assume channel binding is a solution for the full range of IPsec contexts. The BTNS contexts that are the primary focus for you are ones that can take advantage of native host implementations, and that's fine. But since the scope of IPsec is much broader, we ought not assume that we can rely on channel binding in general for Ipsec. >... > >I don't recall any such proposals. The argument that I've made is >"these problems existed in the IPsec architecture to begin with, but >they are most significant when BTNS is in the picture..." followed by >"channel binding helps a lot" :) OK. > >> My perspective is that the current PAD/SPD model works for IPsec, >> when one looks at the rest of the mechanisms used in IPsec >> deployments. > >I'm not sure that it does for sufficiently large and dynamic networks; I >have no experience deploying and managing IPsec in such environments, so >it's hard for me to say this authoritatively, but it does seem like a >logical conclusion. well, the folks who have experience deploying IPsec today don't seem to regard the problems we've explored as significant, as evidenced by a lack of feedback in the IPsec WG as we developed 4301. (These folks DID provide feedback that caused other changes to the architecture and that motivated the features set of IKE v2, so they were not silent.) But, you may argue that the current environment for deployment is not as dynamic as what you envision, and thus this is not a good basis for evaluating the adequacy of the current model. However, the mobile IP folks have been developing solutions based on 4301, in their context, which is very dynamic, so I may disagree with your conclusion. > >> The challenge for the WG is to add BTNS functionality to the existing >> IPsec architecture, without undermining the existing IPsec access >> control model. It is not to change the architecture for authenticated >> IPsec as a side effect of accommodating BTNS functionality. > >Not only. We should want BTNS not to undermine the existing IPsec >architecture (I believe it does not, conceptually, nor concretely in my >latest I-D), but also ensure that BTNS has certain desirable properties. > >BTNS as described in draft-btns-btns-00 is not good enough for my >purposes, nor does it meet the original requirement of protection >against MITM attacks after an initial exchange. But add draft-btns- >connection-latching-00, channel bindings and/or leap-of-faith (ugh) and >then it is good enough for some/most[/all?] of the stated purposes. I was not suggesting that any specific draft on the table has the problems I allude to above. I was making a general statement about how the WG ought to proceed when viewing any proposals. Steve From Internet-Drafts at ietf.org Tue Feb 21 15:50:02 2006 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue, 21 Feb 2006 18:50:02 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-prob-and-applic-02.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-prob-and-applic-02.txt -------------- next part -------------- From Nicolas.Williams at sun.com Tue Feb 21 16:00:51 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 21 Feb 2006 18:00:51 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> Message-ID: <20060222000051.GM23695@binky.Central.Sun.COM> On Tue, Feb 21, 2006 at 06:24:05PM -0500, Stephen Kent wrote: > Nico, > > > > however, it is fair to say that I worry that the attempt to use layer > >> 7 authentication in conjunction with layer 3 confidentiality, > >> integrity and access control may a continuing source of problems for > >> us. > > > >Hmm, no, the problems we've been discussing in this thread do not arise > >from trying to mix authentication at higher layers with session > >protection at lower layers. In fact, channel binding is an answer to > >those problems :) > > Maybe for end systems, but probably not for intermediate systems. BTNS for SG use is out of scope, as I recall... ...but even if it is in scope, connection latching[*] (though there is no ULP connection to speak of) can still work, as can channel binding. [*] See draft-btns-connection-latching-00, when it appears in the I-D directory. Think of having a layer 7 protocol for authenticating to the SG and the SG enabling packet forwarding only once the client is authenticated; conversely the tunnel (and latch) are to be torn down only when the client agrees or a sufficiently long inactivity timer expires. The latch and inactivity timer prevent theft of a client's packet flows (the attack that Michael described a few days ago). Nico -- From Nicolas.Williams at sun.com Tue Feb 21 16:04:59 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 21 Feb 2006 18:04:59 -0600 Subject: [anonsec] New BTNS I-Ds In-Reply-To: <20060220085350.GY20143@binky.Central.Sun.COM> References: <20060220085350.GY20143@binky.Central.Sun.COM> Message-ID: <20060222000458.GN23695@binky.Central.Sun.COM> On Mon, Feb 20, 2006 at 02:53:51AM -0600, Nicolas Williams wrote: > I've just submitted: > > - draft-btns-btns-00.txt > - draft-btns-connection-latching-00.txt Oh darn -- I screwed up the I-D names: I left out the 'ietf' bit. Can this be fixed easily? Nico -- From touch at ISI.EDU Tue Feb 21 19:31:27 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 19:31:27 -0800 Subject: [anonsec] New BTNS I-Ds In-Reply-To: <20060222000458.GN23695@binky.Central.Sun.COM> References: <20060220085350.GY20143@binky.Central.Sun.COM> <20060222000458.GN23695@binky.Central.Sun.COM> Message-ID: <43FBDB0F.6020701@isi.edu> Nicolas Williams wrote: > On Mon, Feb 20, 2006 at 02:53:51AM -0600, Nicolas Williams wrote: >> I've just submitted: >> >> - draft-btns-btns-00.txt >> - draft-btns-connection-latching-00.txt > > Oh darn -- I screwed up the I-D names: I left out the 'ietf' bit. > > Can this be fixed easily? > > Nico I'm not the one to ask. The connection-latching doc makes sense, but I don't understand the btns-btns doc (what IS it?) Joe From touch at ISI.EDU Tue Feb 21 19:35:24 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 19:35:24 -0800 Subject: [anonsec] New BTNS I-Ds In-Reply-To: <43FBDB0F.6020701@isi.edu> References: <20060220085350.GY20143@binky.Central.Sun.COM> <20060222000458.GN23695@binky.Central.Sun.COM> <43FBDB0F.6020701@isi.edu> Message-ID: <43FBDBFC.2060101@isi.edu> Joe Touch wrote: > > Nicolas Williams wrote: >> On Mon, Feb 20, 2006 at 02:53:51AM -0600, Nicolas Williams wrote: >>> I've just submitted: >>> >>> - draft-btns-btns-00.txt >>> - draft-btns-connection-latching-00.txt >> Oh darn -- I screwed up the I-D names: I left out the 'ietf' bit. >> >> Can this be fixed easily? >> >> Nico > > I'm not the one to ask. The connection-latching doc makes sense, but I > don't understand the btns-btns doc (what IS it?) PS - I think I get it: You meant draft-ietf-btns-btns ? It seems like a more meaningful name would be useful, e.g., draft-ietf-btns-spec or draft-ietf-btns-core is more typical as a filename... Joe From Nicolas.Williams at sun.com Wed Feb 22 08:08:16 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 22 Feb 2006 10:08:16 -0600 Subject: [anonsec] New BTNS I-Ds In-Reply-To: <43FBDBFC.2060101@isi.edu> References: <20060220085350.GY20143@binky.Central.Sun.COM> <20060222000458.GN23695@binky.Central.Sun.COM> <43FBDB0F.6020701@isi.edu> <43FBDBFC.2060101@isi.edu> Message-ID: <20060222160816.GS23695@binky.Central.Sun.COM> On Tue, Feb 21, 2006 at 07:35:24PM -0800, Joe Touch wrote: > > > Joe Touch wrote: > > > > Nicolas Williams wrote: > >> On Mon, Feb 20, 2006 at 02:53:51AM -0600, Nicolas Williams wrote: > >>> I've just submitted: > >>> > >>> - draft-btns-btns-00.txt > >>> - draft-btns-connection-latching-00.txt > >> Oh darn -- I screwed up the I-D names: I left out the 'ietf' bit. > >> > >> Can this be fixed easily? > >> > >> Nico > > > > I'm not the one to ask. The connection-latching doc makes sense, but I > > don't understand the btns-btns doc (what IS it?) > > PS - I think I get it: > > You meant draft-ietf-btns-btns ? Yes, that was my intention... > It seems like a more meaningful name would be useful, e.g., > > draft-ietf-btns-spec or draft-ietf-btns-core is more typical as a > filename... But not as amusing! From kent at bbn.com Wed Feb 22 14:03:26 2006 From: kent at bbn.com (Stephen Kent) Date: Wed, 22 Feb 2006 17:03:26 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060222000051.GM23695@binky.Central.Sun.COM> References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> <20060222000051.GM23695@binky.Central.Sun.COM> Message-ID: At 6:00 PM -0600 2/21/06, Nicolas Williams wrote: >On Tue, Feb 21, 2006 at 06:24:05PM -0500, Stephen Kent wrote: >> Nico, >> >> > > however, it is fair to say that I worry that the attempt to use layer >> >> 7 authentication in conjunction with layer 3 confidentiality, >> >> integrity and access control may a continuing source of problems for >> >> us. >> > >> >Hmm, no, the problems we've been discussing in this thread do not arise >> >from trying to mix authentication at higher layers with session >> >protection at lower layers. In fact, channel binding is an answer to >> >those problems :) >> >> Maybe for end systems, but probably not for intermediate systems. > >BTNS for SG use is out of scope, as I recall... I really don't recall, and I'm too lazy to check the charter right now :-). But IF one were to suggest changes to IPsec that are designed to address problems other than those induced by BTNS functionality, THEN such changes must be considered in the context of all IPsec deployment options as defined in 4301, i.e., native host, BITW, BITS, and SG. > >...but even if it is in scope, connection latching[*] (though there is >no ULP connection to speak of) can still work, as can channel binding. > >[*] See draft-btns-connection-latching-00, when it appears in the I-D > directory. > >Think of having a layer 7 protocol for authenticating to the SG and the >SG enabling packet forwarding only once the client is authenticated; >conversely the tunnel (and latch) are to be torn down only when the >client agrees or a sufficiently long inactivity timer expires. The >latch and inactivity timer prevent theft of a client's packet flows (the >attack that Michael described a few days ago). This almost sounds like a MIDCOM-style solution. I think this would be a very big change to the current IPsec architecture, probably out of scope for this WG. Steve From kent at bbn.com Wed Feb 22 14:04:42 2006 From: kent at bbn.com (Stephen Kent) Date: Wed, 22 Feb 2006 17:04:42 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43FB6971.6070805@isi.edu> References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> Message-ID: Joe, >... > >Whatever BTNS is _now_ motivated by, it WAS motivated by the need for >transport protection in the absence of a-priori keys (infrastructure or >predeployed). I agree that was your motivation, and you explained that clearly. But we now have a WG with a broader set of goals, and thus the original motivation you cite is not the only one. >As to the reasons you cited in your original quote: >1- performance >2- security of the software system >3- lower layer can be done elsewhere in the system >3- using BTNS as a place to explore split-layer security > >For which of these would SSL address a BTNS use case? There are a number of outboard, SSL accelerator products that clearly support #1 above. The use of such outboard accelerators could improve crypto security relative to the application layer, although that depends on the crypto options available to the application. The fact that these accelerators are analogous to BITW IPsec implementations also allows them to avoid some of the OS security pitfalls that accrue to an application running on the most popular OS, which also supports #2 above. Although it is an awful protocol layering violation, outboard accelerators for SSL are regularly placed as intermediate systems, just like IPsec SG, consistent with (the first) #3 above. The second bullet #3 above is NOT something I cited as a motivation for layer 3 security, so it seems out of place on your list. > > Also, SSL/TLS now is defined to support UDP, so the traditional argument >> about needing to use IPsec to accommodate other than TCP is no longer >> valid. > >There are more transport protocols than just TCP and UDP. See >http://www.iana.org/assignments/protocol-numbers for a complete list ;-) The vast majority of the protocols on that list are rarely used or obsolete (a limiting case of rarely used). For example, when do you think the last packet radio measurement packet (#21) was sent :-)? This is not a very relevant list for purposes of our discussion, although I admit there are transport protocols other than TCP and UDP. The relevant question is which ones are of interest to the potential set of BTNS users. Steve From touch at ISI.EDU Wed Feb 22 14:47:04 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 14:47:04 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> <20060222000051.GM23695@binky.Central.Sun.COM> Message-ID: <43FCE9E8.7020305@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > At 6:00 PM -0600 2/21/06, Nicolas Williams wrote: > >>On Tue, Feb 21, 2006 at 06:24:05PM -0500, Stephen Kent wrote: >> >>> Nico, >>> >>> > > however, it is fair to say that I worry that the attempt to use layer >>> >> 7 authentication in conjunction with layer 3 confidentiality, >>> >> integrity and access control may a continuing source of problems for >>> >> us. >>> > >>> >Hmm, no, the problems we've been discussing in this thread do not arise >>> >from trying to mix authentication at higher layers with session >>> >protection at lower layers. In fact, channel binding is an answer to >>> >those problems :) >>> >>> Maybe for end systems, but probably not for intermediate systems. >> >>BTNS for SG use is out of scope, as I recall... > > > I really don't recall, and I'm too lazy to check the charter right > now :-). But IF one were to suggest changes to IPsec that are > designed to address problems other than those induced by BTNS > functionality, THEN such changes must be considered in the context of > all IPsec deployment options as defined in 4301, i.e., native host, > BITW, BITS, and SG. > > >>...but even if it is in scope, connection latching[*] (though there is >>no ULP connection to speak of) can still work, as can channel binding. >> >>[*] See draft-btns-connection-latching-00, when it appears in the I-D >> directory. >> >>Think of having a layer 7 protocol for authenticating to the SG and the >>SG enabling packet forwarding only once the client is authenticated; >>conversely the tunnel (and latch) are to be torn down only when the >>client agrees or a sufficiently long inactivity timer expires. The >>latch and inactivity timer prevent theft of a client's packet flows (the >>attack that Michael described a few days ago). > > > This almost sounds like a MIDCOM-style solution. I think this would > be a very big change to the current IPsec architecture, probably out > of scope for this WG. I agree, however I wonder if that sort of issue was already present in the BITW variants in 4301 anyway (to ensure, e.g., that packets arriving on different links with the same IP address didn't collide on SPI allocations). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/OnoE5f5cImnZrsRApjsAJwOlQuFZZX4ss6JcIU/jlD9AHbhEgCfVvpW BpC2QkuJiWp4U2xUpANHJzU= =ZWJA -----END PGP SIGNATURE----- From touch at ISI.EDU Wed Feb 22 14:52:40 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 14:52:40 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> Message-ID: <43FCEB38.6050404@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > >> ... >> >> Whatever BTNS is _now_ motivated by, it WAS motivated by the need for >> transport protection in the absence of a-priori keys (infrastructure or >> predeployed). > > I agree that was your motivation, and you explained that clearly. But we > now have a WG with a broader set of goals, and thus the original > motivation you cite is not the only one. Steve, AOK; it'd be useful clarify the broader set since it relates to the P&AS. >> As to the reasons you cited in your original quote: >> 1- performance >> 2- security of the software system >> 3- lower layer can be done elsewhere in the system >> 3- using BTNS as a place to explore split-layer security >> >> For which of these would SSL address a BTNS use case? > > There are a number of outboard, SSL accelerator products that clearly > support #1 above. The use of such outboard accelerators could improve > crypto security relative to the application layer, although that depends > on the crypto options available to the application. The fact that these > accelerators are analogous to BITW IPsec implementations also allows > them to avoid some of the OS security pitfalls that accrue to an > application running on the most popular OS, which also supports #2 > above. Although it is an awful protocol layering violation, outboard > accelerators for SSL are regularly placed as intermediate systems, just > like IPsec SG, consistent with (the first) #3 above. The second bullet > #3 above is NOT something I cited as a motivation for layer 3 security, > so it seems out of place on your list. It wasn't my list; it was a summary of yours (with my misnumbering): (note that the 4th one, the second #3 above, was listed in the negative in your list): - -- quoted from original mail, "*" inserted to highlight the items above: There are multiple motivations for imposing security controls at layer 3. *Performance* may be important in some instances, as you suggest, but more often the motivations have to do with assurance and management. Lower layer controls can be *more secure* that higher later controls, given the unfortunate state of OS and application security. Lower layer controls *can be imposed (cleanly) at points other than end systems*, which simplifies management and also may improve assurance. None of this says that application layer security is redundant. However, it also does not suggest that *trying to split security services* between layer 3 and layer 7, as some BTNS use cases require, will necessarily work well. - -- None of these are solved by SSL; SSL has corresponding solutions for the first three, but in no case does it protect the transport connection. I.e., what is the motivation for BTNS that does not include - if not focus - on transport protection? >> > Also, SSL/TLS now is defined to support UDP, so the traditional >> argument >>> about needing to use IPsec to accommodate other than TCP is no longer >>> valid. >> >> There are more transport protocols than just TCP and UDP. See >> http://www.iana.org/assignments/protocol-numbers for a complete list ;-) > > The vast majority of the protocols on that list are rarely used or > obsolete (a limiting case of rarely used). For example, when do you > think the last packet radio measurement packet (#21) was sent :-)? This > is not a very relevant list for purposes of our discussion, although I > admit there are transport protocols other than TCP and UDP. The relevant > question is which ones are of interest to the potential set of BTNS users. RTP is used for VoIP, which is becoming more common, as we hope will be DCCP and SCTP. Then there are infrastructure protocols, like ISIS-over-IP. i.e., not all of these are as likely to be used as others, but there are more than 2. However, SSL/TLS is a red-herring here anyway; it doesn't protect the transport layer. TCP/MD5 is the comparable protocol for potential BTNS users; there is no equivalent for UDP, and we'd need to reinvent it for every other transport protocol in use (at least the handful above) as well. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/Os4E5f5cImnZrsRAovAAJ99sYd/xB+OhZBq4tj5cyYGBh+BpQCgma0h JW6Vm0ouTCoinrZKZTb0l9s= =vFdq -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Wed Feb 22 14:56:06 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 22 Feb 2006 16:56:06 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> <20060222000051.GM23695@binky.Central.Sun.COM> Message-ID: <20060222225606.GF23695@binky.Central.Sun.COM> On Wed, Feb 22, 2006 at 05:03:26PM -0500, Stephen Kent wrote: > >...but even if it is in scope, connection latching[*] (though there is > >no ULP connection to speak of) can still work, as can channel binding. > > > >[*] See draft-btns-connection-latching-00, when it appears in the I-D > > directory. > > > >Think of having a layer 7 protocol for authenticating to the SG and the > >SG enabling packet forwarding only once the client is authenticated; > >conversely the tunnel (and latch) are to be torn down only when the > >client agrees or a sufficiently long inactivity timer expires. The > >latch and inactivity timer prevent theft of a client's packet flows (the > >attack that Michael described a few days ago). > > This almost sounds like a MIDCOM-style solution. I think this would > be a very big change to the current IPsec architecture, probably out > of scope for this WG. 'Change' is probably not the right word here; perhaps 'addition' would be more appropriate. But let's leave this out of scope, if it isn't already. From robholliday at isocore.com Thu Feb 23 10:13:18 2006 From: robholliday at isocore.com (Robert Holliday) Date: Thu, 23 Feb 2006 13:13:18 -0500 Subject: [anonsec] Registration for Network Security 2006 Now Open Message-ID: <200602231813.k1NIDJu01215@boreas.isi.edu> International Conference on Network Security 2006 Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday at isocore.com. www.networksecurity2006.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/anonsec/attachments/20060223/f31d3053/attachment-0001.html From kent at bbn.com Thu Feb 23 15:07:01 2006 From: kent at bbn.com (Stephen Kent) Date: Thu, 23 Feb 2006 18:07:01 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43FCE9E8.7020305@isi.edu> References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> <20060222000051.GM23695@binky.Central.Sun.COM> <43FCE9E8.7020305@isi.edu> Message-ID: Joe, >... > > >> >> This almost sounds like a MIDCOM-style solution. I think this would >> be a very big change to the current IPsec architecture, probably out >> of scope for this WG. > >I agree, however I wonder if that sort of issue was already present in >the BITW variants in 4301 anyway (to ensure, e.g., that packets arriving > on different links with the same IP address didn't collide on SPI >allocations). This might be a problem if each interface had a distinct IPsec implementation, not just a distinct SPD. However, I know of no such devices, and thus no instances of problems of this sort. With just one SAD for a BITW device, SPI assignment is centralized and thus the problem you cite is avoided. Steve From touch at ISI.EDU Thu Feb 23 15:10:41 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 23 Feb 2006 15:10:41 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> <20060222000051.GM23695@binky.Central.Sun.COM> <43FCE9E8.7020305@isi.edu> Message-ID: <43FE40F1.1070100@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > >> ... >> > >> >>> >>> This almost sounds like a MIDCOM-style solution. I think this would >>> be a very big change to the current IPsec architecture, probably out >>> of scope for this WG. >> >> >> I agree, however I wonder if that sort of issue was already present in >> the BITW variants in 4301 anyway (to ensure, e.g., that packets arriving >> on different links with the same IP address didn't collide on SPI >> allocations). > > > This might be a problem if each interface had a distinct IPsec > implementation, not just a distinct SPD. However, I know of no such > devices, and thus no instances of problems of this sort. With just one > SAD for a BITW device, SPI assignment is centralized and thus the > problem you cite is avoided. > > Steve Just curious - without diving into 4301 myself - is that spec'd in 4301? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/kDxE5f5cImnZrsRAp2IAJ94FxemzXECg6TScHjipriveRResACfZg6q xQSylEDrbavQ7DgDrsadPgE= =HQQb -----END PGP SIGNATURE----- From kent at bbn.com Thu Feb 23 15:18:23 2006 From: kent at bbn.com (Stephen Kent) Date: Thu, 23 Feb 2006 18:18:23 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43FCEB38.6050404@isi.edu> References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> Message-ID: Joe, >... > >It wasn't my list; it was a summary of yours (with my misnumbering): >(note that the 4th one, the second #3 above, was listed in the negative >in your list): OK, the reversed polarity of the last item was confusing to me. >... >None of these are solved by SSL; SSL has corresponding solutions for the >first three, but in no case does it protect the transport connection. You are right that SSL/TLS does not protect the transport layer, but that was not what you asked me to address via that list. >I.e., what is the motivation for BTNS that does not include - if not >focus - on transport protection? Channel binding functionality does not explicitly demand transport layer protection. >... >RTP is used for VoIP, which is becoming more common, as we hope will be >DCCP and SCTP. Then there are infrastructure protocols, like >ISIS-over-IP. i.e., not all of these are as likely to be used as others, >but there are more than 2. And RTP users developed SRTP as an alternative to using IPsec, so ... >However, SSL/TLS is a red-herring here anyway; it doesn't protect the >transport layer. TCP/MD5 is the comparable protocol for potential BTNS >users; there is no equivalent for UDP, and we'd need to reinvent it for >every other transport protocol in use (at least the handful above) as well. > I agree that the TCP/MD5 hack offers transport layer integrity, but that does not make it comparable to either IPsec or SSL/TLS. My recollection from the BOF was that only some of the cited motivations for BTNS explicitly cite transport layer protection. When applications want to use lower layer security mechanisms to enable higher performance via off-loading crypto to a different processor, that can be achieved via SSL/TLS, for example. I think the crux of our possible disagreement is that you see every BTNS motivation as demanding protection for the transport layer protocol, whole I see only one of cited motivations as emphasizing this requirement. Steve From kent at bbn.com Thu Feb 23 15:23:03 2006 From: kent at bbn.com (Stephen Kent) Date: Thu, 23 Feb 2006 18:23:03 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43FE40F1.1070100@isi.edu> References: <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <20060217021003.GJ20143@binky.Central.Sun.COM> <20060221221453.GL23695@binky.Central.Sun.COM> <20060222000051.GM23695@binky.Central.Sun.COM> <43FCE9E8.7020305@isi.edu> <43FE40F1.1070100@isi.edu> Message-ID: At 3:10 PM -0800 2/23/06, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Stephen Kent wrote: >> Joe, >> >>> ... >>> > >>> >>>> >>>> This almost sounds like a MIDCOM-style solution. I think this would >>>> be a very big change to the current IPsec architecture, probably out >>>> of scope for this WG. >>> >>> >>> I agree, however I wonder if that sort of issue was already present in >>> the BITW variants in 4301 anyway (to ensure, e.g., that packets arriving >>> on different links with the same IP address didn't collide on SPI >>> allocations). >> >> >> This might be a problem if each interface had a distinct IPsec >> implementation, not just a distinct SPD. However, I know of no such >> devices, and thus no instances of problems of this sort. With just one >> SAD for a BITW device, SPI assignment is centralized and thus the >> problem you cite is avoided. >> >> Steve > >Just curious - without diving into 4301 myself - is that spec'd in 4301? > >Joe 4301 allows wither implementation approach, but warns folks that if each interface has a distinct SAD, then it will not generally be possible to treat the different interfaces as multi-homed instances of the same entity. Steve From touch at ISI.EDU Thu Feb 23 15:28:04 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 23 Feb 2006 15:28:04 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060214055647.GY9977@binky.Central.Sun.COM> <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> Message-ID: <43FE4504.8080502@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: ... >> I.e., what is the motivation for BTNS that does not include - if not >> focus - on transport protection? > > Channel binding functionality does not explicitly demand transport layer > protection. Channel binding isn't a motivation for BTNS. BTNS is a place where we are exploring it. >> ... >> RTP is used for VoIP, which is becoming more common, as we hope will be >> DCCP and SCTP. Then there are infrastructure protocols, like >> ISIS-over-IP. i.e., not all of these are as likely to be used as others, >> but there are more than 2. > > And RTP users developed SRTP as an alternative to using IPsec, so ... That's what I'd like to avoid by encouraging using a cross-transport solution, e.g., at the network layer. >> However, SSL/TLS is a red-herring here anyway; it doesn't protect the >> transport layer. TCP/MD5 is the comparable protocol for potential BTNS >> users; there is no equivalent for UDP, and we'd need to reinvent it for >> every other transport protocol in use (at least the handful above) as >> well. > > I agree that the TCP/MD5 hack offers transport layer integrity, but that > does not make it comparable to either IPsec or SSL/TLS. We have been talking about BTNS use cases; as I noted before, one (the original one, and at least one of the current ones) is to protect the transport layer. I *fully* agree with the fact that TCP/MD5 doesn't offer the same protection as IPsec, but it does protect the transport layer. That differentiates it from TLS. > My recollection from the BOF was that only some of the cited motivations > for BTNS explicitly cite transport layer protection. When applications > want to use lower layer security mechanisms to enable higher performance > via off-loading crypto to a different processor, that can be achieved > via SSL/TLS, for example. Performance issues were taken off the table at the BOF altogether. I agree with the rest of the conclusion above, though, but it doesn't seem relevant to BTNS. > I think the crux of our possible disagreement is that you see every BTNS > motivation as demanding protection for the transport layer protocol, > whole I see only one of cited motivations as emphasizing this requirement. > > Steve I agree completely; I'm still trying to understand a motivation that doesn't include that requirement, though. The only ones above that seem to be put forth (correct if wrong, please) are: - performance offloading but performance was taken off the table for BTNS during the BOF - channel binding which could be useful with or without BTNS, i.e., it binds an application identity to a network identity (but the latter need not be ephemeral) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/kUEE5f5cImnZrsRAsazAJoDi54/LXulqGIwcqpqbMuLNpHbjQCdHQ95 NhPTx1Iuud4XFQsXOMhncK8= =dCVk -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Feb 23 15:35:36 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 23 Feb 2006 15:35:36 -0800 Subject: [anonsec] Registration for Network Security 2006 Now Open In-Reply-To: <200602231813.k1NIDJu01215@boreas.isi.edu> References: <200602231813.k1NIDJu01215@boreas.isi.edu> Message-ID: <43FE46C8.6050004@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (speaking as mail list admin) ANONSEC Mailing list This is the mailing list of the IETF Better Than Nothing Security (BTNS) working group. Only messages that relate to the work of this WG and the IETF should be posted here. - -In particular, announcements of an non-IETF meetings are inappropriate for this list, and should not be posted here; they fall under "Discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns" Please see: http://www.ietf.org/maillist.html for more information. Joe Robert Holliday wrote: > International Conference on Network Security 2006 > > Registration Open!!! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/kbIE5f5cImnZrsRAndHAKCg7TzYrnqd9fF4poUoDg1g5qTwQQCgnI9A hySi9nwb0OPvw049x+jJSY8= =x5gs -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Fri Feb 24 09:45:55 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 24 Feb 2006 11:45:55 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> Message-ID: <20060224174555.GQ23695@binky.Central.Sun.COM> On Thu, Feb 23, 2006 at 06:18:23PM -0500, Stephen Kent wrote: > >None of these are solved by SSL; SSL has corresponding solutions for the > >first three, but in no case does it protect the transport connection. > > You are right that SSL/TLS does not protect the transport layer, but > that was not what you asked me to address via that list. It's session protection, but it's meant to seem like transport protection. > >I.e., what is the motivation for BTNS that does not include - if not > >focus - on transport protection? > > Channel binding functionality does not explicitly demand transport > layer protection. Channel binding demans channels to bind to. Such channels must: a) provide adequate (for the cb app) protection for data sent over it, b) provide a way to cryptographically bind to it. > My recollection from the BOF was that only some of the cited > motivations for BTNS explicitly cite transport layer protection. When > applications want to use lower layer security mechanisms to enable > higher performance via off-loading crypto to a different processor, > that can be achieved via SSL/TLS, for example. Yes, that's my motivation. > I think the crux of our possible disagreement is that you see every > BTNS motivation as demanding protection for the transport layer > protocol, whole I see only one of cited motivations as emphasizing > this requirement. We must be converging -- your disagreements with either Joe or myself are more and more matters of degree :) Nico -- From touch at ISI.EDU Fri Feb 24 10:00:08 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 24 Feb 2006 10:00:08 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060224174555.GQ23695@binky.Central.Sun.COM> References: <20060215224234.GD9977@binky.Central.Sun.COM> <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> <20060224174555.GQ23695@binky.Central.Sun.COM> Message-ID: <43FF49A8.90506@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Thu, Feb 23, 2006 at 06:18:23PM -0500, Stephen Kent wrote: ... >>My recollection from the BOF was that only some of the cited >>motivations for BTNS explicitly cite transport layer protection. When >>applications want to use lower layer security mechanisms to enable >>higher performance via off-loading crypto to a different processor, >>that can be achieved via SSL/TLS, for example. > > Yes, that's my motivation. We probably agree on that, but it's not a motivation for BTNS. BTNS is a good place to develop a particular channel binding variant, but that doesn't seem like a motivation. >>I think the crux of our possible disagreement is that you see every >>BTNS motivation as demanding protection for the transport layer >>protocol, whole I see only one of cited motivations as emphasizing >>this requirement. > > We must be converging -- your disagreements with either Joe or myself > are more and more matters of degree :) > > Nico Agreed on the last point, but it would be useful to understand these just a bit further, again as they may need to be incorporated into the P&AS. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/0moE5f5cImnZrsRAsQxAJ4ntQvv69jGABgpdPa6L0bW1hdaBACggFYa AI9d71VC+FlK6l0WxD9hMhc= =hn4p -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Fri Feb 24 10:23:40 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 24 Feb 2006 12:23:40 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43FF49A8.90506@isi.edu> References: <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> <20060224174555.GQ23695@binky.Central.Sun.COM> <43FF49A8.90506@isi.edu> Message-ID: <20060224182340.GU23695@binky.Central.Sun.COM> On Fri, Feb 24, 2006 at 10:00:08AM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > On Thu, Feb 23, 2006 at 06:18:23PM -0500, Stephen Kent wrote: > ... > >>My recollection from the BOF was that only some of the cited > >>motivations for BTNS explicitly cite transport layer protection. When > >>applications want to use lower layer security mechanisms to enable > >>higher performance via off-loading crypto to a different processor, > >>that can be achieved via SSL/TLS, for example. > > > > Yes, that's my motivation. > > We probably agree on that, but it's not a motivation for BTNS. BTNS is a > good place to develop a particular channel binding variant, but that > doesn't seem like a motivation. Oh no, channel binding certainly is a motivation for BTNS, if round-about: because implied in channel binding is that you already have an authentication infrastructure deployed that you can use at layer 7, but you want secure channels at lower layers where you don't care what is used for authentication, and having to deploy a separate authentication infrastructure just to get such channels is lame. I first posted to the old IPsec WG list about something like BTNS long before the ANONSEC BoF. And the motivation for channel binding to IPsec and unauthenticated IPsec goes back to March 2003 when a bunch of people at Connectathon sat down to work out a proposal from Mike Eisler going back to December 2002. Nico -- From touch at ISI.EDU Fri Feb 24 11:30:32 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 24 Feb 2006 11:30:32 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060224182340.GU23695@binky.Central.Sun.COM> References: <20060216202710.GB20143@binky.Central.Sun.COM> <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> <20060224174555.GQ23695@binky.Central.Sun.COM> <43FF49A8.90506@isi.edu> <20060224182340.GU23695@binky.Central.Sun.COM> Message-ID: <43FF5ED8.8090404@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Fri, Feb 24, 2006 at 10:00:08AM -0800, Joe Touch wrote: > >>Nicolas Williams wrote: >> >>>On Thu, Feb 23, 2006 at 06:18:23PM -0500, Stephen Kent wrote: >> >>... >> >>>>My recollection from the BOF was that only some of the cited >>>>motivations for BTNS explicitly cite transport layer protection. When >>>>applications want to use lower layer security mechanisms to enable >>>>higher performance via off-loading crypto to a different processor, >>>>that can be achieved via SSL/TLS, for example. >>> >>>Yes, that's my motivation. >> >>We probably agree on that, but it's not a motivation for BTNS. BTNS is a >>good place to develop a particular channel binding variant, but that >>doesn't seem like a motivation. > > > Oh no, channel binding certainly is a motivation for BTNS, if > round-about: because implied in channel binding is that you already have > an authentication infrastructure deployed that you can use at layer 7, > but you want secure channels at lower layers where you don't care what > is used for authentication, and having to deploy a separate > authentication infrastructure just to get such channels is lame. Why wouldn't channel binding be useful in the context of conventional IPsec? The network identity (i.e., as used by IKE) need not have anything to do with the application identity. It seems like it'd still be useful to combine the two. I.e., I'm suggesting that channel binding is definitely useful for some variants of BTNS, but isn't really a motivation for the work itself (even if it predated it, which I appreciate). That's a bit of a split hair, though, so I'll keep that in mind for the (hopefully nearing final) next update of the P&AS. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/17YE5f5cImnZrsRArRNAKCJn4AVBrc+pC2Gs3YsfXa6nikInwCcCzez +sxXupZv+gFRbkbuu4z4LSE= =6ccz -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Fri Feb 24 12:32:38 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 24 Feb 2006 14:32:38 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43FF5ED8.8090404@isi.edu> References: <43F5EF3B.5050301@isi.edu> <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> <20060224174555.GQ23695@binky.Central.Sun.COM> <43FF49A8.90506@isi.edu> <20060224182340.GU23695@binky.Central.Sun.COM> <43FF5ED8.8090404@isi.edu> Message-ID: <20060224203238.GX23695@binky.Central.Sun.COM> On Fri, Feb 24, 2006 at 11:30:32AM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > Oh no, channel binding certainly is a motivation for BTNS, if > > round-about: because implied in channel binding is that you already have > > an authentication infrastructure deployed that you can use at layer 7, > > but you want secure channels at lower layers where you don't care what > > is used for authentication, and having to deploy a separate > > authentication infrastructure just to get such channels is lame. > > Why wouldn't channel binding be useful in the context of conventional > IPsec? The network identity (i.e., as used by IKE) need not have > anything to do with the application identity. It seems like it'd still > be useful to combine the two. Because you might have the authenticatoin infrastructure for IPsec deployed. BTNS requires zero authentication infrastructure deployment. > I.e., I'm suggesting that channel binding is definitely useful for some > variants of BTNS, but isn't really a motivation for the work itself > (even if it predated it, which I appreciate). That's a bit of a split > hair, though, so I'll keep that in mind for the (hopefully nearing > final) next update of the P&AS. So, it's been my motivation for pursuing BTNS since sometime soon after March 2003. I think at least one list member here was at the meeting where we conceived of using channel bindings to IPsec to resolve the issues that Mike Eisler was looking to resolve in NFSv4. The others who were there are also participants at the IETF, so if you want confirmation of this motivation, I assure you I can get it :) From Internet-Drafts at ietf.org Fri Feb 24 12:50:01 2006 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri, 24 Feb 2006 15:50:01 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-core-00.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-00.txt -------------- next part -------------- From Internet-Drafts at ietf.org Mon Feb 27 12:50:01 2006 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 27 Feb 2006 15:50:01 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-connection-latching-00.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-00.txt -------------- next part --------------