From kent at bbn.com Wed Mar 1 17:22:58 2006 From: kent at bbn.com (Stephen Kent) Date: Wed, 1 Mar 2006 20:22:58 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43FE4504.8080502@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> <43FE4504.8080502@isi.edu> Message-ID: At 3:28 PM -0800 2/23/06, Joe Touch wrote: >... >Channel binding isn't a motivation for BTNS. BTNS is a place where we >are exploring it. Sorry. I though it was one of the cited motivations. I'll have to read the latest problem statement I-D. > >... >That's what I'd like to avoid by encouraging using a cross-transport >solution, e.g., at the network layer. The reasons that they chose to not use Ipsec are based on per-packet overhead, for the very small RTP packets. Nothing we do in BTNS is going to address that concern. >... >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. The original one you cited, yes, but that has not been the primary focus of most of the more recent discussion, I think. >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. it offers some protection, but to say that it "protects" the layer might surprise folks who think confidentiality is important :-). Steve From touch at ISI.EDU Wed Mar 1 21:50:16 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 01 Mar 2006 21:50:16 -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> <43FE4504.8080502@isi.edu> Message-ID: <44068798.6070300@isi.edu> Stephen Kent wrote: > At 3:28 PM -0800 2/23/06, Joe Touch wrote: >> ... >> Channel binding isn't a motivation for BTNS. BTNS is a place where we >> are exploring it. > > Sorry. I though it was one of the cited motivations. I'll have to read > the latest problem statement I-D. I saw Nico's post on this; I'll recheck the latest PS doc to see whether this needs to be updated on this. >> ... >> That's what I'd like to avoid by encouraging using a cross-transport >> solution, e.g., at the network layer. > > The reasons that they chose to not use Ipsec are based on per-packet > overhead, for the very small RTP packets. Nothing we do in BTNS is going > to address that concern. Their per-packet processing overhead can't be all that different; they use AES and HMAC-SHA1. The key difference is that SRTP allows "good enough" key lengths that are less than full-sized, which helps keep the bandwidth overhead down and packet expansion constrained, but which forces the session keys to have a shorter lifetime. That logic is equally valid for IPsec. >> ... >> 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. > > The original one you cited, yes, but that has not been the primary focus > of most of the more recent discussion, I think. Many of those discussions were raised in the context of connection binding; while BTNS is a place where that issue is being raised, it is not unique to BTNS. >> 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. > > it offers some protection, but to say that it "protects" the layer might > surprise folks who think confidentiality is important :-). The same is true for an IPsec SA based on MD5. The point wasn't privacy vs. authentication; it's transport vs. non-transport. Joe From kent at bbn.com Wed Mar 1 22:04:45 2006 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Mar 2006 01:04:45 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <44068798.6070300@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> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> Message-ID: At 9:50 PM -0800 3/1/06, Joe Touch wrote: >... > > The reasons that they chose to not use Ipsec are based on per-packet >> overhead, for the very small RTP packets. Nothing we do in BTNS is going >> to address that concern. > >Their per-packet processing overhead can't be all that different; they >use AES and HMAC-SHA1. The key difference is that SRTP allows "good >enough" key lengths that are less than full-sized, which helps keep the >bandwidth overhead down and packet expansion constrained, but which >forces the session keys to have a shorter lifetime. That logic is >equally valid for IPsec. It's communication overhead, not processing overhead, that motivates use of SRTP. the headers for SRTP are very small, even compared to transport mode ESP. > >... > >>> 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. >> >> it offers some protection, but to say that it "protects" the layer might >> surprise folks who think confidentiality is important :-). > >The same is true for an IPsec SA based on MD5. The point wasn't privacy >vs. authentication; it's transport vs. non-transport. First, there are no SAs that are protected via MD5, per se, although we can have SAs that make use of HMAC-MD5. But, ESP (which is a more efficient way to offer integrity and authentication that AH), also offers confidentiality, if desired. Thus it can "protect" a connection to whatever extent a user wishes, depending on selection of appropriate options, unlike the limited forms of protection offered by the TCP-MD5 checksum option. Steve From touch at ISI.EDU Wed Mar 1 22:15:03 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 01 Mar 2006 22:15:03 -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> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> Message-ID: <44068D67.2020004@isi.edu> Stephen Kent wrote: ... >>>> 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. >>> >>> it offers some protection, but to say that it "protects" the layer >>> might >>> surprise folks who think confidentiality is important :-). >> >> The same is true for an IPsec SA based on MD5. The point wasn't privacy >> vs. authentication; it's transport vs. non-transport. > > First, there are no SAs that are protected via MD5, per se, although we > can have SAs that make use of HMAC-MD5. I never knew that HMAC-MD5 was not based on MD5. ;-) > But, ESP (which is a more > efficient way to offer integrity and authentication that AH), also > offers confidentiality, if desired. Thus it can "protect" a connection > to whatever extent a user wishes, depending on selection of appropriate > options, unlike the limited forms of protection offered by the TCP-MD5 > checksum option. I never knew there was a way to use ESP with an algorithm based on MD5 (e.g., HMAC-MD5-96, as per RFC4305) that afforded confidentiality either. Joe > > Steve From kent at bbn.com Wed Mar 1 22:23:44 2006 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Mar 2006 01:23:44 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <44068D67.2020004@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> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> <44068D67.2020004@isi.edu> Message-ID: At 10:15 PM -0800 3/1/06, Joe Touch wrote: >Stephen Kent wrote: >... >>>>> 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. >>>> >>>> it offers some protection, but to say that it "protects" the layer >>>> might >>>> surprise folks who think confidentiality is important :-). >>> >>> The same is true for an IPsec SA based on MD5. The point wasn't privacy >>> vs. authentication; it's transport vs. non-transport. >> >> First, there are no SAs that are protected via MD5, per se, although we >> can have SAs that make use of HMAC-MD5. > >I never knew that HMAC-MD5 was not based on MD5. ;-) if there were not a significant difference between MD5 and HMAC-MD5, we would not bother using the latter, given the additional processing. thus it makes sense to be precise in discussing which integrity algorithm we're using. > > But, ESP (which is a more >> efficient way to offer integrity and authentication that AH), also >> offers confidentiality, if desired. Thus it can "protect" a connection >> to whatever extent a user wishes, depending on selection of appropriate >> options, unlike the limited forms of protection offered by the TCP-MD5 >> checksum option. > >I never knew there was a way to use ESP with an algorithm based on MD5 >(e.g., HMAC-MD5-96, as per RFC4305) that afforded confidentiality either. nor did I say so. again, precision and clarity in our communication is its own reward. > >Joe it's probably best if we stop arguing over who is and is not communicating clearly, given the outcome of previous arguments on this topic. Steve From hartmans-ietf at mit.edu Fri Mar 10 14:19:04 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Fri, 10 Mar 2006 17:19:04 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: (Stephen Kent's message of "Thu, 2 Mar 2006 01:04:45 -0500") 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> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> It's communication overhead, not processing overhead, Stephen> that motivates use of SRTP. the headers for SRTP are very Stephen> small, even compared to transport mode ESP. You should be aware that there is a proposal being discussed at AVT in Dallas to use DTLS as an alternative to secure RTP instead of SRTP. There are problems with keying SRTP that have caused some to question whether perhaps the key establishment should happen as part of the RTP stream establishment instead of part of the session setup layer. If this proposal is viewed favorably, it casts doubt on claims about SRTP being different from other protocols in terms of overhead requirements. From hartmans-ietf at mit.edu Fri Mar 10 14:21:40 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Fri, 10 Mar 2006 17:21:40 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060224203238.GX23695@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 24 Feb 2006 14:32:38 -0600") 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> <20060224203238.GX23695@binky.Central.Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> So, it's been my motivation for pursuing BTNS since Nicolas> sometime soon after March 2003. I think at least one Nicolas> list member here was at the meeting where we conceived of Nicolas> using channel bindings to IPsec to resolve the issues Nicolas> that Mike Eisler was looking to resolve in NFSv4. The Nicolas> others who were there are also participants at the IETF, Nicolas> so if you want confirmation of this motivation, I assure Nicolas> you I can get it :) CB has been one of two motivations that made me very interested in BTNS as an AD. From kent at bbn.com Fri Mar 10 15:12:13 2006 From: kent at bbn.com (Stephen Kent) Date: Fri, 10 Mar 2006 18:12:13 -0500 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> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> Message-ID: At 5:19 PM -0500 3/10/06, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > > Stephen> It's communication overhead, not processing overhead, > Stephen> that motivates use of SRTP. the headers for SRTP are very > Stephen> small, even compared to transport mode ESP. > > >You should be aware that there is a proposal being discussed at AVT in >Dallas to use DTLS as an alternative to secure RTP instead of SRTP. >There are problems with keying SRTP that have caused some to question >whether perhaps the key establishment should happen as part of the RTP >stream establishment instead of part of the session setup layer. > >If this proposal is viewed favorably, it casts doubt on claims about >SRTP being different from other protocols in terms of overhead >requirements. Yes, IF the proposal is accepted, then it signals a change of heart by the folks who created SRTP and cited per-packet bandwidth as the rationale. Steve From Nicolas.Williams at sun.com Fri Mar 10 15:28:37 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 10 Mar 2006 17:28:37 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> Message-ID: <20060310232837.GC21630@binky.Central.Sun.COM> On Fri, Mar 10, 2006 at 06:12:13PM -0500, Stephen Kent wrote: > >You should be aware that there is a proposal being discussed at AVT in > >Dallas to use DTLS as an alternative to secure RTP instead of SRTP. > >There are problems with keying SRTP that have caused some to question > >whether perhaps the key establishment should happen as part of the RTP > >stream establishment instead of part of the session setup layer. > > > >If this proposal is viewed favorably, it casts doubt on claims about > >SRTP being different from other protocols in terms of overhead > >requirements. > > Yes, IF the proposal is accepted, then it signals a change of heart > by the folks who created SRTP and cited per-packet bandwidth as the > rationale. If you want data authentication then you have to have some overhead and that will be comparable in home-grown solutions, AH and DTLS. So, if you want data authentication and the overhead thereof is too much then either give up on data authentication or throw better networks (more money) at the problem. Case closed :) Nico -- From kent at bbn.com Mon Mar 13 07:41:56 2006 From: kent at bbn.com (Stephen Kent) Date: Mon, 13 Mar 2006 10:41:56 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20060310232837.GC21630@binky.Central.Sun.COM> References: <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> <20060310232837.GC21630@binky.Central.Sun.COM> Message-ID: At 5:28 PM -0600 3/10/06, Nicolas Williams wrote: >On Fri, Mar 10, 2006 at 06:12:13PM -0500, Stephen Kent wrote: >> >You should be aware that there is a proposal being discussed at AVT in >> >Dallas to use DTLS as an alternative to secure RTP instead of SRTP. >> >There are problems with keying SRTP that have caused some to question >> >whether perhaps the key establishment should happen as part of the RTP >> >stream establishment instead of part of the session setup layer. >> > >> >If this proposal is viewed favorably, it casts doubt on claims about >> >SRTP being different from other protocols in terms of overhead >> >requirements. >> >> Yes, IF the proposal is accepted, then it signals a change of heart >> by the folks who created SRTP and cited per-packet bandwidth as the >> rationale. > >If you want data authentication then you have to have some overhead and >that will be comparable in home-grown solutions, AH and DTLS. > >So, if you want data authentication and the overhead thereof is too much >then either give up on data authentication or throw better networks >(more money) at the problem. > >Case closed :) > >Nico >-- Not quite that simple :-). What SRTP did was to add integrity and confidentially to RTP in a very careful, space-efficient fashion. In so doing, they reduced overhead well below what one could achieve via use of DTLS or ESP or AH. This is not a practice I encourage for application in general, because the costs of custom designs of this sort are very high, and for most apps the bandwidth savings will not justify these costs. Also, as Joe noted, the likelihood of introducing security problems in such designs (and in implementations) is also very high. Steve From hartmans-ietf at mit.edu Mon Mar 13 11:08:15 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 13 Mar 2006 14:08:15 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: (Stephen Kent's message of "Mon, 13 Mar 2006 10:41:56 -0500") References: <43FB6971.6070805@isi.edu> <43FCEB38.6050404@isi.edu> <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> <20060310232837.GC21630@binky.Central.Sun.COM> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> What SRTP did was to add integrity and confidentially to Stephen> RTP in a very careful, space-efficient fashion. In so Stephen> doing, they reduced overhead well below what one could Stephen> achieve via use of DTLS or ESP or AH. This is not a Stephen> practice I encourage for application in general, because Stephen> the costs of custom designs of this sort are very high, Stephen> and for most apps the bandwidth savings will not justify Stephen> these costs. Also, as Joe noted, the likelihood of Stephen> introducing security problems in such designs (and in Stephen> implementations) is also very high. The multimedia application also has a number of other special requirements. I think that multimedia streams over cellular networks are one of the few cases I've seen where confidentiality without integrity may be reasonable. Humans will know if an attacker significantly corrupts a voice or video stream. However the cost of lost packets do to corruption of a MAC may be unacceptable given radio error rates. --Sam From Nicolas.Williams at sun.com Mon Mar 13 11:14:16 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 13 Mar 2006 13:14:16 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <43FE4504.8080502@isi.edu> <44068798.6070300@isi.edu> <20060310232837.GC21630@binky.Central.Sun.COM> Message-ID: <20060313191415.GZ21630@binky.Central.Sun.COM> On Mon, Mar 13, 2006 at 02:08:15PM -0500, Sam Hartman wrote: > The multimedia application also has a number of other special > requirements. I think that multimedia streams over cellular networks > are one of the few cases I've seen where confidentiality without > integrity may be reasonable. > > Humans will know if an attacker significantly corrupts a voice or > video stream. However the cost of lost packets do to corruption of a > MAC may be unacceptable given radio error rates. Although authentication can still help at least provide feedback to the user as to the quality of reception (100% vs. not 100% :) From mcr at sandelman.ottawa.on.ca Sun Mar 19 09:11:45 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 19 Mar 2006 11:11:45 -0600 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> <20060211085741.GV9977@binky.Central.Sun.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20060319/1daca5df/attachment.bin From mcr at sandelman.ottawa.on.ca Sun Mar 19 09:49:46 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 19 Mar 2006 11:49:46 -0600 Subject: [anonsec] BTNS updates References: <20051206000303.GM17884@binky.Central.Sun.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20060319/fb488cd9/attachment.bin From Nicolas.Williams at sun.com Sun Mar 19 14:23:22 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 19 Mar 2006 16:23:22 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20060211085741.GV9977@binky.Central.Sun.COM> Message-ID: <20060319222321.GI27125@binky.Central.Sun.COM> On Sun, Mar 19, 2006 at 11:11:45AM -0600, Michael Richardson wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> On Fri, Feb 10, 2006 at 07:17:22PM -0500, Michael Richardson > Nicolas> 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. > > Nicolas> Better: > > Nicolas> - transport, on output, says "please send this packet protected > Nicolas> by an SA that matches the characteristics of the SA originally > Nicolas> used for latching (this includes crypto algs AND peer IDs). > > It's really a lot of thinking to distribute around the place (and for > connectionless procotols, it winds up in the application), and I'd rather let > the key manager deal with determining what is "equal" The ULP doesn't have to concern itself with the details of latching. One way to architect this in software: for inbound packets let IPsec pass packets up with a reference to the SA used to protect it, then let ULPs call generic IPsec functions to either obtain a latch corresponding to a given SA or determine whether a given SA matches a given latch; on output ULPs should pass down a reference to a latch and IPsec just has to find or establish an SA that matches the given latch. For connectionless ULPs the application doesn't have to do the latching as long as it can hold on to a "handle" for a particular 5-tuple and corresponding latch. In BSD socket terms, for sending a UDP datagram it suffices to connect() a UDP socket before sending; for receiving you'd have to do something where you accept() on UDP unconnected sockets to get a "connected" UDP socket whenever a datagram comes in that doesn't match the 5-tuple of an existing connected socket (or more). > Nicolas> - the actual latch is constructed from the characteristics of > Nicolas> the SA that protected the first packet sent or received on the > Nicolas> given connection (e.g., the SYN packet, in the case of TCP). > > I thought a lot about doing that, but I decided simplify the life of the > ULP. I'm very concerned about BTNS work through NATs. The ULP need not know the details of how to do this, see above. All you need are generic IPsec functions of this form: sa2latch(sa#) -> latch sa_matches_latch_p(sa#, latch) -> true/false plus let IPsec label incoming protected packets with the SA# used to protect them and let ULPs label outgoing packets with a latch. There may be other ways to design your implementation of connection latching, of course. My point here is that where ULPs are implemented separately from layer 3 the ULPs need not know the details of IPsec connection latching. Nico -- From Nicolas.Williams at sun.com Sun Mar 19 14:26:06 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 19 Mar 2006 16:26:06 -0600 Subject: [anonsec] BTNS updates In-Reply-To: References: <20051206000303.GM17884@binky.Central.Sun.COM> Message-ID: <20060319222606.GJ27125@binky.Central.Sun.COM> On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael Richardson wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> - Nodes that wish to be treated as BTNS nodes by their peers > Nicolas> should generate a self-signed cert with a randomized DN. > > Can you be more specific? Do I have to be? > Nicolas> We did discuss channel bindings, however. Channel bindings do > Nicolas> presume connection latching, which we did not work out in > Nicolas> detail, but nonetheless we think that for SAs authenticated with > Nicolas> public key signatures the channel bindings for latched > Nicolas> connections will be the public key values of the two peers. > > Directly? Or concatenation of hashes of public keys? > What order? No, not directly, a bit of structure may be necessary, and a canonical order is necessary (there can be only two, so let's pick one). > Will we write a single description of a channel binding "blob", or will > this be application defined? We will write a single description in a separate document (most likely). > If there are two connections between peers, such as, in some cases, two NFS > mounts, but certainly if I used channel binding for two SSH connections for > which I had a (probably-non-btns) /32<->/32 tunnel, would both instances see > the same binding data? Most often, yes, but not necessarily. Nico -- From Nicolas.Williams at sun.com Sun Mar 19 14:40:41 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 19 Mar 2006 16:40:41 -0600 Subject: [anonsec] BTNS updates In-Reply-To: <20060319222606.GJ27125@binky.Central.Sun.COM> References: <20051206000303.GM17884@binky.Central.Sun.COM> <20060319222606.GJ27125@binky.Central.Sun.COM> Message-ID: <20060319224041.GK27125@binky.Central.Sun.COM> On Sun, Mar 19, 2006 at 04:26:06PM -0600, Nicolas Williams wrote: > On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael Richardson wrote: > > If there are two connections between peers, such as, in some cases, two NFS > > mounts, but certainly if I used channel binding for two SSH connections for > > which I had a (probably-non-btns) /32<->/32 tunnel, would both instances see > > the same binding data? > > Most often, yes, but not necessarily. To be more specific, provided that the peer IDs do not change then the *latched* IDs should be the same for all end-to-end connections with the same ends, but because of key rollovers the channel bindings for any two such connections may be different. From mcr at sandelman.ottawa.on.ca Sun Mar 19 22:47:12 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 20 Mar 2006 00:47:12 -0600 Subject: [anonsec] BTNS updates In-Reply-To: Message from Nicolas Williams of "Sun, 19 Mar 2006 16:26:06 CST." <20060319222606.GJ27125@binky.Central.Sun.COM> References: <20051206000303.GM17884@binky.Central.Sun.COM> <20060319222606.GJ27125@binky.Central.Sun.COM> Message-ID: <17246.1142837232@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael Nicolas> Richardson wrote: >> >>>>> "Nicolas" == Nicolas Williams >> writes: Nicolas> - Nodes that wish to be treated as BTNS nodes by their Nicolas> peers should generate a self-signed cert with a randomized Nicolas> DN. >> Can you be more specific? Nicolas> Do I have to be? Give me an example of a randomized DN. Nicolas> No, not directly, a bit of structure may be necessary, and Nicolas> a canonical order is necessary (there can be only two, so Nicolas> let's pick one). I suggest sorting by IP address of initiator/responder in network order. That's a simple sorting method. >> Will we write a single description of a channel binding "blob", >> or will this be application defined? Nicolas> We will write a single description in a separate document Nicolas> (most likely). Good. I prefer it be similar across application uses. >> If there are two connections between peers, such as, in some >> cases, two NFS mounts, but certainly if I used channel binding >> for two SSH connections for which I had a (probably-non-btns) >> /32<->/32 tunnel, would both instances see the same binding data? Nicolas> Most often, yes, but not necessarily. Okay. I am concerned about this. I have a nagging feeling that the channel binding should be made unique between users, but I'm not sure how to do this without introducing new {IKE,IKEv2} notifies. - -- ] 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) Comment: Finger me for keys iQEVAwUBRB5P74CLcPvd0N1lAQJmrAf/RaVkj/8NHIcD5d6fY1cJGlYdL5hXO5WU K5rCSRc58nQcY0gaGWbgAjpSlAuITQTuMKEaAJl3fmcmEM/ZXsDhqEAxjXAD/bYl IXDc0d4sd96USN2ZEDAh7O1jNvH9AXLhjgTTUX8YDgnzJxOxhTjqxOGN0CxHQMLA sz3amoG/vYCYuJ91tj3YZ6vLzSWYFjqCDaVCoH7JdEbh1qEcnJm1Tdh6KSIW4A2x us1LfravwSurq1lpqMH07P9EUtW5inttw6IayvoNurk2nsy4gE2b0E24QYnkvVx1 4wXFa4R0jvBIwDlFb+g/+2pZ5ilxZQ/54xA4zSkcVNJQDjbbqEjZIQ== =xiom -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Sun Mar 19 22:55:09 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 20 Mar 2006 00:55:09 -0600 Subject: [anonsec] BTNS updates In-Reply-To: Message from Nicolas Williams of "Sun, 19 Mar 2006 16:40:41 CST." <20060319224041.GK27125@binky.Central.Sun.COM> References: <20051206000303.GM17884@binky.Central.Sun.COM> <20060319222606.GJ27125@binky.Central.Sun.COM> <20060319224041.GK27125@binky.Central.Sun.COM> Message-ID: <25246.1142837709@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: >> On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael Richardson >> wrote: > If there are two connections between peers, such as, in >> some cases, two NFS > mounts, but certainly if I used channel >> binding for two SSH connections for > which I had a >> (probably-non-btns) /32<->/32 tunnel, would both instances see > >> the same binding data? >> >> Most often, yes, but not necessarily. Nicolas> To be more specific, provided that the peer IDs do not Nicolas> change then the *latched* IDs should be the same for all Nicolas> end-to-end connections with the same ends, but because of Nicolas> key rollovers the channel bindings for any two such Nicolas> connections may be different. When you say key rollover, you mean at the PK level, not at the IPsec "rekey" level, right? To take what I consider is the canonical case of FTP with the data channel(s) (but also maps to HTTP with multiple sessions, SIP with control and RTP channels, and other protocols too), you are saying that the channel binding for data/control of FTP would be the same. I agree that this *SHOULD* be the case. But, you are also saying that *two* FTP sessions between the same hosts (under the same users, if user-based-keying were available) would have the same channel bindings as well. I'm trying to figure out if there is some threat there that we need defend against, given that the public key are the same. I think that I'd like the channel binding to be hash'es of the public key itself (not the certificate, if one was involved). that way, I don't have to worry how the end-points got the public keys. I suggest that the hash should be essentially identical to SSHFP format or # openssl x509 -hash -noout -in /etc/postfix/client.crt format. I am not sufficiently PKIX aware to know if this is the same HASH. - -- ] 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) Comment: Finger me for keys iQEVAwUBRB5Ry4CLcPvd0N1lAQLmDAf9H1XYEeU48OJIBhj22d58EW6s/Kh2/1IZ BOLQl9EhcJ7k0kKWk21ur+GRgWa38NkzSH2sZ8ITrqkHsLJ86u0p3QZSEFDvG4HN leu3v3/UTKRqldUDLP/wPMakjvaMihv1v45MHyIm4xzMapxDwN+hFT1/sKEKlN4R ioWMJDQpzocvKV7o+mYd6HS92YX7xodMiBkKs20Cg61YcsyCY6igiuqps3Tt6H8O m/xM+4oNJmwsLqGcDBuU9XgF5/4YzJZW71MXVH9D3mg7Bk/UxFSrX+ULA+GJRhZ2 S4rjInQ36v4zIWJhrrnsORWF8T3DgeLpdIk6oePvVyRM1o9V3mFYNw== =zTpZ -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Mar 20 07:10:38 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 20 Mar 2006 09:10:38 -0600 Subject: [anonsec] BTNS updates In-Reply-To: <25246.1142837709@sandelman.ottawa.on.ca> References: <20051206000303.GM17884@binky.Central.Sun.COM> <20060319222606.GJ27125@binky.Central.Sun.COM> <20060319224041.GK27125@binky.Central.Sun.COM> <25246.1142837709@sandelman.ottawa.on.ca> Message-ID: <20060320151038.GN27125@binky.Central.Sun.COM> On Mon, Mar 20, 2006 at 12:55:09AM -0600, Michael Richardson wrote: > Nicolas> To be more specific, provided that the peer IDs do not > Nicolas> change then the *latched* IDs should be the same for all > Nicolas> end-to-end connections with the same ends, but because of > Nicolas> key rollovers the channel bindings for any two such > Nicolas> connections may be different. > > When you say key rollover, you mean at the PK level, not at the IPsec > "rekey" level, right? Yes. > To take what I consider is the canonical case of FTP with the data > channel(s) (but also maps to HTTP with multiple sessions, SIP with > control and RTP channels, and other protocols too), you are saying that > the channel binding for data/control of FTP would be the same. > I agree that this *SHOULD* be the case. > > But, you are also saying that *two* FTP sessions between the same > hosts (under the same users, if user-based-keying were available) would > have the same channel bindings as well. > I'm trying to figure out if there is some threat there that we need > defend against, given that the public key are the same. > > I think that I'd like the channel binding to be hash'es of the public > key itself (not the certificate, if one was involved). that way, I don't > have to worry how the end-points got the public keys. The latch is to the IDs, the channel bindings are the public keys used to authenticate the peers in the KE for the SA that protected the packet that led to the latch being set up. If there's a key rollover but the IDs don't change between two connections between the same endpoints then the latches will be the same for both connections but the channel bindings will differ. From mcr at sandelman.ottawa.on.ca Mon Mar 20 11:18:25 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 20 Mar 2006 13:18:25 -0600 Subject: [anonsec] prob-02 Message-ID: <22318.1142882305@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > and Key IDs [10]. All require either CA-signed certificates or pre- > shared secrets to authenticate. These can be roughly categorized into > network layer identifiers and other identifiers. ... >2.1.2. Authentication Methods > > As described earlier, CA-signed certificates and pre-shared secrets > are the only methods of authentications accepted by current IPsec and > IKE specifications. Pre-shared secrets require manual configuration This is false. There is nothing in IKEv1 or IKEv2 that says that you have to use a CA-signed certificate to us RSASIG authentication. As implementation proof, there is the Openswan/Freeswan/Strongswan, and ncp.de (for windows) that provides raw rsa key usage with RSASIG. Self-signed certificates are widely used as well, both by *swan, and also by racoon, SSH/Safenet, and others. The fact that these things need to be pre-exchanged is irrelevant, as so do PSK. The fact of the matter is that a multitude of IPsec vendors have made it very hard to use RSASIG mode in any kind of small-scale deployment. These systems simply do not scale: scaling is about working with 2 machines as well as with 2million. Just working for 2 million nodes is not "scaling". By stating the above you are propogating the myth that "PK is hard" (Think of that in a "math-is-hard" Barbie voice). It isn't. It's the "I" part that is hard, particularly if you wish to work without pre-deployed infrastructure, which Joe does. I can not suggest text, because I think worrying about how hard certificates are to get is totally irrelevant. I would just say that pre-arranging appropriate, mutually trusted authentication systems is hard, particularly when the connection crosses organizationational boundaries. - -- ] 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) Comment: Finger me for keys iQEVAwUBRB8AAICLcPvd0N1lAQJchwf/Q/GAHa0qcE5N6G85QHJb+ue5CIJI6tyP +XRGM4Il453acOqnz+O4VBnIq9pGTqvoEGaqpGFZ67iYr5jGIsPcbYSCMJv4XpQI qiJZJzJi9OJ3ytlWTANdl9FsLyOKFdD13KsOpN3vgsQvTHf/Mr1zzpbG1Yb6FC3D SApu3Zy5NobzF5oLOzMNVlIKgoLArDZAMLy1QH8l1i+/8dfTt0t3D3NRGTFSFhPn hrS4G1AYhYIAfP016ESfzZsKym87AXObS7vL92IFjW58OO7ZloK+kJs47GAngC6Y u1wIn9ch4bxMTe8Dh/cVgsO3KJmKeVnAMSO15DUaBocLT7ueq+gXRw== =kwGy -----END PGP SIGNATURE----- From kent at bbn.com Mon Mar 20 13:26:31 2006 From: kent at bbn.com (Stephen Kent) Date: Mon, 20 Mar 2006 16:26:31 -0500 Subject: [anonsec] prob-02 In-Reply-To: <22318.1142882305@sandelman.ottawa.on.ca> References: <22318.1142882305@sandelman.ottawa.on.ca> Message-ID: At 1:18 PM -0600 3/20/06, Michael Richardson wrote: >... >Self-signed certificates are widely used as well, both by *swan, and >also by racoon, SSH/Safenet, and others. technically, a self-signed, PKIX-compliant cert is a CA cert. Steve From hartmans-ietf at mit.edu Mon Mar 20 13:49:06 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 20 Mar 2006 16:49:06 -0500 (EST) Subject: [anonsec] Propose dropping asymmetric CBB Message-ID: <20060320214906.96311E0053@carter-zimmerman.mit.edu> I propose that we drop the applicability statement for asymmetric CBB because I don't think it is useful. I think the other applicability statements are much better than in previous versions. --Sam From yushunwa at ISI.EDU Mon Mar 20 13:56:48 2006 From: yushunwa at ISI.EDU (Yu-Shun Wang) Date: Mon, 20 Mar 2006 15:56:48 -0600 Subject: [anonsec] prob-02 In-Reply-To: <22318.1142882305@sandelman.ottawa.on.ca> References: <22318.1142882305@sandelman.ottawa.on.ca> Message-ID: <441F2520.9070008@isi.edu> Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >> and Key IDs [10]. All require either CA-signed certificates or pre- >> shared secrets to authenticate. These can be roughly categorized into >> network layer identifiers and other identifiers. > ... > >> 2.1.2. Authentication Methods >> >> As described earlier, CA-signed certificates and pre-shared secrets >> are the only methods of authentications accepted by current IPsec and >> IKE specifications. Pre-shared secrets require manual configuration > > This is false. > > There is nothing in IKEv1 or IKEv2 that says that you have to use a > CA-signed certificate to us RSASIG authentication. I should clarify. It's actually more about 4301, PAD and SPD rather than IKE. This is from 4301: 4.4.3.2. IKE Peer Authentication Data Once an entry is located based on an ordered search of the PAD based on ID field matching, it is necessary to verify the asserted identity, i.e., to authenticate the asserted ID. For each PAD entry, there is an indication of the type of authentication to be performed. This document requires support for two required authentication data types: - X.509 certificate - pre-shared secret For authentication based on an X.509 certificate, the PAD entry contains a trust anchor via which the end entity (EE) certificate for the peer must be verifiable, either directly or via a certificate path. See RFC 3280 for the definition of a trust anchor. And also based on my impression of the BTNS charter. I am not familiar about IKE, but IMO it's more about the requirements IPsec impose on the authentications used by IKE. Maybe we should just remove IKE from the quote? I am certain there are implementations that could do this, but that's not the point. So I'll skip the comments below. yushun > As implementation proof, there is the Openswan/Freeswan/Strongswan, and > ncp.de (for windows) that provides raw rsa key usage with RSASIG. > > Self-signed certificates are widely used as well, both by *swan, and > also by racoon, SSH/Safenet, and others. > > The fact that these things need to be pre-exchanged is irrelevant, as so > do PSK. > > The fact of the matter is that a multitude of IPsec vendors have made it > very hard to use RSASIG mode in any kind of small-scale deployment. > These systems simply do not scale: scaling is about working with 2 > machines as well as with 2million. > Just working for 2 million nodes is not "scaling". > > By stating the above you are propogating the myth that "PK is hard" > (Think of that in a "math-is-hard" Barbie voice). It isn't. It's the "I" > part that is hard, particularly if you wish to work without pre-deployed > infrastructure, which Joe does. > > I can not suggest text, because I think worrying about how hard > certificates are to get is totally irrelevant. I would just say that > pre-arranging appropriate, mutually trusted authentication systems is > hard, particularly when the connection crosses organizationational > boundaries. From touch at ISI.EDU Mon Mar 20 14:19:22 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 20 Mar 2006 14:19:22 -0800 Subject: [anonsec] Propose dropping asymmetric CBB In-Reply-To: <20060320214906.96311E0053@carter-zimmerman.mit.edu> References: <20060320214906.96311E0053@carter-zimmerman.mit.edu> Message-ID: <441F2A6A.2090306@isi.edu> Should it be included as a variant for completeness, but the lack of currently known utility / motivation noted? Sam Hartman wrote: > > I propose that we drop the applicability statement for asymmetric CBB because I don't think it is useful. > > I think the other applicability statements are much better than in > previous versions. > > --Sam > > _______________________________________________ From hartmans-ietf at mit.edu Mon Mar 20 15:06:34 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 20 Mar 2006 18:06:34 -0500 Subject: [anonsec] Propose dropping asymmetric CBB In-Reply-To: <441F2A6A.2090306@isi.edu> (Joe Touch's message of "Mon, 20 Mar 2006 14:19:22 -0800") References: <20060320214906.96311E0053@carter-zimmerman.mit.edu> <441F2A6A.2090306@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> Should it be included as a variant for completeness, but the Joe> lack of currently known utility / motivation noted? No, because I think it has security problems and I don't want to spend the effort doing analysis unless we have a justification for that work. Let me make sure I understand what you mean though. You consider this the case where one side verifies the channel binding but the other side does not, not the case where you use channel bindings but one side has full IKE, right? From touch at ISI.EDU Mon Mar 20 15:10:28 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 20 Mar 2006 15:10:28 -0800 Subject: [anonsec] Propose dropping asymmetric CBB In-Reply-To: References: <20060320214906.96311E0053@carter-zimmerman.mit.edu> <441F2A6A.2090306@isi.edu> Message-ID: <441F3664.4020803@isi.edu> Is it worth mentioning "here it is, we're not discussing it due to concerns about security problems"? I'm concerned about not addressing it at all; I don't want to leave an open door for an update to miss ;-) Joe Sam Hartman wrote: >>>>>> "Joe" == Joe Touch writes: > > Joe> Should it be included as a variant for completeness, but the > Joe> lack of currently known utility / motivation noted? > > No, because I think it has security problems and I don't want to spend > the effort doing analysis unless we have a justification for that > work. > > > > Let me make sure I understand what you mean though. You consider this > the case where one side verifies the channel binding but the other > side does not, not the case where you use channel bindings but one > side has full IKE, right? From mcr at sandelman.ottawa.on.ca Tue Mar 21 11:29:48 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 21 Mar 2006 13:29:48 -0600 Subject: [anonsec] BTNS and NAT-traversal References: <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20060211093124.GY9977@binky.Central.Sun.COM> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20060321/e1b89679/attachment.bin From Nicolas.Williams at sun.com Tue Mar 21 12:07:47 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 21 Mar 2006 14:07:47 -0600 Subject: [anonsec] BTNS and NAT-traversal In-Reply-To: References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20060211093124.GY9977@binky.Central.Sun.COM> Message-ID: <20060321200747.GJ29724@binky.Central.Sun.COM> On Tue, Mar 21, 2006 at 01:29:48PM -0600, Michael Richardson wrote: > So, there is some significant difference between: > a) A:1234/32 <-> B:80/32 (transport mode) > and > b) A[A:1234/32] <-> B[B:80/32] (tunnel mode) > > when a NAT is involved. From the point of view of the gateway, these > become: > > a) N:4567/32 <-> B:80/32 (%) > a' A:1234/32 <-> B:80/32 > > b) N:4576[A:1234/32] <-> B[B:80/32] (host-to-host tunnel mode) > > Where N:4567 is outer IP of NAT, and 4567 is outer UDP port. > > (%) Yes, there are some systems that let transport mode change TCP (or SCTP) > connections into UDP connections... they are broken. Openswan KLIPS > was such a system until recently. Yes, I see now (actually, I saw yesterday :) Now, we could leave NAT out of scope :) or we could do what you suggested yesterday, namely, to use connection latching as part of the packet inbound dispatch/outbound SA/tunnel (or NAT address) selection process. I don't mind leaving NAT in scope because your solution seems obvious enough and seems not to do too much violence to IP/IPsec. That said, I would insist on this being optional, or even a separate document altogether. > Now, if you have a', guess what... *A* is not UNIQUE. You REQUIRE > connection latching, and BITS and BITW just can't work easily. > > If you have b), then guess what... *A* is not UNIQUE. > Note that (b) is morally equivalent to gateway mode, from a policy point of > view. BTW, is there a potential argument here that connection latching SHOULD or MUST be used with tunnel mode only because it makes (I assume, for this argument) implementation of this sort of NAT traversal easier? > Nicolas> I think we want to leave tunnelling out of scope for BTNS. That > Nicolas> doesn't simplify things so much though -- we still need > Nicolas> connection latching and, ultimately APIs to inspect what is > Nicolas> latched and channel bindings. But note that IPsec generally > Nicolas> needs this, and not because of BTNS -- BTNS is merely bringing > Nicolas> the issue to a head. > > I agree. > I don't think you can reasonably do BTNS through a NAT without connection > latching. > > I also don't think you can do it using the language of the RFC2401/4301 > SPD, because the indirection level introduced by that mechanism means that > you can't seperate two SAs or SPDs that leads to the same "identifier" > (rfc1918) address. But not because of BTNS. End-to-end IPsec NAT traversal has this same problem, no? > In this context I have been pondering what to do with Opportunistic > encryption through NATs. Originally, we thought that the problem was policy > and authorization. We figured out how to solve this. > > Since OE uses host /32<->/32 tunnels, we need something unique for the host > to use as it's "identifier" for the inside. We considered the subset of > people like the developers, who have unique identifiers we can allocate > already. (road.marajade.sandelman.ca, 205.150.200.163 is an IP for my laptop > that I use only on the inside of a tunnel). > > I then realized that we had a problem. Our outgoing TCP connection was > going to try to send a packet from: > 192.168.1.101 -> 205.150.200.178 (my web site) > > and I was hen going to want to try to match it to an SPD that said: > 205.150.200.163/32 -> 0.0.0.0/0 => try OE. > > Worse, if I managed to do this, I would then, after having established a > tunnel, want to *change* the IP from 192.168.1.101 to 205.150.200.163! > > Then I thought about people who don't have that unique IP, and wondered, as > long as I'm violating several layers of software stack, why not change the IP > >From a v4 to a v6 underneath the application. In the case of Linux<->Linux, I > can reasonably guarantee that there is v6 at the remote end, and I can use > IPv4-mapped IPv6 addresses at the remote... > > Ooops. Maybe transport (BTNS) and/or BEET mode would be better at the lower > levels, but it may be that I still want to do this. > HIP pushes the problem that I have described up to the application layer, > giving it these HIT's in the form of IPv6 (and now IPv4, I'm told) addresses. Which the application could use for channel binding and/or LoF? I remember conversations about how HIP and BTNS were working on the same problem from different directions. Nico -- From mcr at sandelman.ottawa.on.ca Tue Mar 21 12:40:44 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 21 Mar 2006 14:40:44 -0600 Subject: [anonsec] BTNS and NAT-traversal In-Reply-To: Message from Nicolas Williams of "Tue, 21 Mar 2006 14:07:47 CST." <20060321200747.GJ29724@binky.Central.Sun.COM> References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20060211093124.GY9977@binky.Central.Sun.COM> <20060321200747.GJ29724@binky.Central.Sun.COM> Message-ID: <3091.1142973644@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: >> (%) Yes, there are some systems that let transport mode change >> TCP (or SCTP) connections into UDP connections... they are >> broken. Openswan KLIPS was such a system until recently. Nicolas> Yes, I see now (actually, I saw yesterday :) Sorry... I wrote that on airplane, but it didn't go out until I noticed it pushed. I'm a newbie to using GNUS+agent to read gmane.org. Nicolas> Now, we could leave NAT out of scope :) or we could do what Nicolas> you suggested yesterday, namely, to use connection latching Nicolas> as part of the packet inbound dispatch/outbound SA/tunnel Nicolas> (or NAT address) selection process. Nicolas> I don't mind leaving NAT in scope because your solution Nicolas> seems obvious enough and seems not to do too much violence Nicolas> to IP/IPsec. That said, I would insist on this being Nicolas> optional, or even a separate document altogether. I don't see use cases for BTNS (particularly when it was an enabler for channel binding) that do not involve NAT-traversal. Except for securing BGP....... We are talking to customers who want to build various kinds of NFSv4 NAS things that live centrally and talk to widely distributed clients (naturally, NAT'ed out the wazoo). The load/power-considerations on the NAS device is such that they hardware acceleration is cost-effective, and this favours IPsec rather than GSSAPI for doing the encryption. >> Now, if you have a', guess what... *A* is not UNIQUE. You REQUIRE >> connection latching, and BITS and BITW just can't work easily. >> >> If you have b), then guess what... *A* is not UNIQUE. Note that >> (b) is morally equivalent to gateway mode, from a policy point of >> view. Nicolas> BTW, is there a potential argument here that connection Nicolas> latching SHOULD or MUST be used with tunnel mode only Nicolas> because it makes (I assume, for this argument) Nicolas> implementation of this sort of NAT traversal easier? I'm not sure I agree. Nicolas> But not because of BTNS. End-to-end IPsec NAT traversal Nicolas> has this same problem, no? Yes. But like everything else, BTNS makes IPsec use more ubiquitous... Nicolas> I remember conversations about how HIP and BTNS were Nicolas> working on the same problem from different directions. Now that I understand shim6, I wonder if we are wasting our time, and should just switch to shim6-upgrade-to-hip. - -- ] 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) Comment: Finger me for keys iQEVAwUBRCBkyoCLcPvd0N1lAQJ8BQf/dqA0dVznQCT3mGwKXFkZrI1A2F9W13n7 HnEokThEtaw9a60mlfDHwcgLk0Gi2zCzrFEIcDas4/Imii+xzO/k1APUp9aIqUk3 lgRHONeD3sTglidXR4PnuVSHptAlKAewVqjtdy7xq8PBRpi0jN0shEgqXklYQ80D JVxQW+aK3VPHKl9A1FPKJ3wnf8it+33YcEthBLP8kutjDJHAY1qycbu7Xjv7sA/b yIxGYFihsaQl831KVGG1ldcYMKgR7i5Kde7ahrKTgz2JmYEuOdGleTAb551ujhbG lKvf3no6n7ghYpJ+cn3SXxC7THZsaA/RWjzbqM/oOwSycJ5Yh3uENQ== =FYOZ -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Tue Mar 21 15:03:32 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 21 Mar 2006 17:03:32 -0600 Subject: [anonsec] BTNS and NAT-traversal In-Reply-To: <3091.1142973644@sandelman.ottawa.on.ca> References: <20051207145408.GE21090@binky.Central.Sun.COM> <20060211093124.GY9977@binky.Central.Sun.COM> <20060321200747.GJ29724@binky.Central.Sun.COM> <3091.1142973644@sandelman.ottawa.on.ca> Message-ID: <20060321230332.GB1010@binky.Central.Sun.COM> On Tue, Mar 21, 2006 at 02:40:44PM -0600, Michael Richardson wrote: > Nicolas> I don't mind leaving NAT in scope because your solution > Nicolas> seems obvious enough and seems not to do too much violence > Nicolas> to IP/IPsec. That said, I would insist on this being > Nicolas> optional, or even a separate document altogether. > > I don't see use cases for BTNS (particularly when it was an enabler > for channel binding) that do not involve NAT-traversal. Except for > securing BGP....... > We are talking to customers who want to build various kinds of NFSv4 > NAS things that live centrally and talk to widely distributed > clients (naturally, NAT'ed out the wazoo). The load/power-considerations > on the NAS device is such that they hardware acceleration is > cost-effective, and this favours IPsec rather than GSSAPI for doing the > encryption. So, I envisioned NFSv4 use of BTNS (w/ channel bindings) as a way to push session crypto down the stack for performance wins that I expect to be primarily useful in intranet environments. HOWEVER, I can certainly see that running NFSv4 over TLS/SSHv2/whatever across NATs will be important, so I think this should stay in scope. My only question is: what I-D should deal with the NAT issue? I'm happy with the connection latching I-D containing this, but I can also see it as a separate I-D. > >> Now, if you have a', guess what... *A* is not UNIQUE. You REQUIRE > >> connection latching, and BITS and BITW just can't work easily. > >> > >> If you have b), then guess what... *A* is not UNIQUE. Note that > >> (b) is morally equivalent to gateway mode, from a policy point of > >> view. > > Nicolas> BTW, is there a potential argument here that connection > Nicolas> latching SHOULD or MUST be used with tunnel mode only > Nicolas> because it makes (I assume, for this argument) > Nicolas> implementation of this sort of NAT traversal easier? > > I'm not sure I agree. OK, just checking :) > Nicolas> But not because of BTNS. End-to-end IPsec NAT traversal > Nicolas> has this same problem, no? > > Yes. But like everything else, BTNS makes IPsec use more ubiquitous... Indeed. > Nicolas> I remember conversations about how HIP and BTNS were > Nicolas> working on the same problem from different directions. > > Now that I understand shim6, I wonder if we are wasting our time, and > should just switch to shim6-upgrade-to-hip. Heh. I don't understand shim6 yet -- I haven't looked at it. It's entirely possible that for some uses of BTNS we are wasting our time. But for my original use case I think BTNS w/ connection latching and channel binding is the simplest solution to implement and deploy. Nico -- From robholliday at isocore.com Tue Mar 21 15:22:57 2006 From: robholliday at isocore.com (Robert Holliday) Date: Tue, 21 Mar 2006 18:22:57 -0500 Subject: [anonsec] Network Security 2006 Message-ID: <200603212323.k2LNN2G06276@boreas.isi.edu> International Conference on Network Security 2006, April 17-19 Only, one week remaining to take advantage of Early Bird Specials. All those registering before April 1 receive a $200 dollar discount on registration. Register at: http://www.isocore.com/networksecurity2006/onlineregis.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/anonsec/attachments/20060321/8992973f/attachment.html From lha at it.su.se Wed Mar 22 11:40:46 2006 From: lha at it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 22 Mar 2006 13:40:46 -0600 Subject: [anonsec] BTNS IETF65 session summary Message-ID: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> IETF-65 BTNS Session Summary March 20, 9.00-11.30 ============================ BTNS held its third meeting in Dallas. Three documents where discussed during the meeting, the "Problem and Applicability Statement", "An Unauthenticated Mode of IPsec", and "IPsec Channels: Connection Latching", the two later accepted as working group document since the last meeting. Joe Touch talked about the Problem and Applicability Statement document. There are four outstanding issues, and hopefully next revision of the document can go to working group last call. Nicolas Williams made a presentation of his drafts "An Unauthenticated Mode of IPsec" and "IPsec Channels: Connection Latching". The group thought that direction of document was the right one. There was consensus that the document was too tense, and that Nicolas needed fill in more details how it should work and how it would fit into IPsec processing. There was a short discussion on how to proceed with the API item from the charter. Sam Hartman with help from David Black will present at next IETF. Michael Richardson promised to look at the old API requirements document that he and Bill Sommerfeld made for IPSP. Decisions ========= * Require support of bare keys, and add self-signed certificates as a SHOULD. * The IKE extentions will be folded into the core document and Michael Richardson help Nicolas with document as a co editor. Action items ============ * Re-spin PS/AS document, submit document in May, and take to WG-LC * Address comments on Nicolas?s drafts * Start up work on IPsec interfaces draft Updated milestones ================== Done First version of SPD and/or PAD extensions draft May 06 WG LC on problem and applicability statement (a+b) Done First version of IKE extensions draft (if needed) May 06 First version of IPsec interfaces draft (e) May 06 Submit problem and applicability statement to IESG (a+b) Aug 06 WG LC on IKE extensions (c) Aug 06 WG LC on SPD and/or PAD extensions (d) Sep 06 Submit IKE extensions to the IESG Sep 06 Submit SPD and/or PAD extensions to the IESG Nov06 WG LC on IPsec interfaces draft Nov06 Submit IPsec interfaces draft to the IESG Mar 06 Recharter or close the WG -------------- 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/20060322/2a59b0dd/PGP.bin From mcr at sandelman.ottawa.on.ca Mon Mar 20 13:59:13 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 20 Mar 2006 15:59:13 -0600 Subject: [anonsec] what I call leap-of-faith Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20060320/8a7af661/attachment.bin From yushunwa at ISI.EDU Thu Mar 23 09:13:04 2006 From: yushunwa at ISI.EDU (Yu-Shun Wang) Date: Thu, 23 Mar 2006 11:13:04 -0600 Subject: [anonsec] what I call leap-of-faith In-Reply-To: References: Message-ID: <4422D720.8010508@isi.edu> Hi, Michael, Comments below. Michael Richardson wrote: > When you SSH to a host the server sends it's public key inline. > > The client checks against a local database it has (~/.ssh/known_hosts for ssh > 1 and openssh, ~/ssh2/hostkeys/key_PORT_NAME for ssh.com ssh2). You can > populate these yourself if you want. > > If the entry is not found, the user is presented with a finger print (hex and > bubble-babble are common), and asked if they want to check it. The user types > "y" or "n". Some users call up the admin and ask for the fingerprint, others > just make a leap-of-faith: that they are not being MITM attacked at that > moment. > > ssh.com ssh now stores things by the name that you type on the command > line + port number. openssh stores by IP and name. This causes problems if > you have ssh servers on different port numbers, such as having port 222 > portforwarded by you NAT to some host behind it --- I mention this because > the public is bound to a name in different ways by different vendors. > > The leap-of-faith is that the user is consulted as an oracle to make the hard > decision. Modern SSH implementations will now for instance, turn off password > authentication when the host is not yet known, to avoid disclosing the > password to a MITM. > > If I was doing leap-of-faith for IPsec, as a peer that doesn't have an active > user that can be contacted, then I'd accept to create the PARENT SA, and then > limit the CHILD SA to what would otherwise be permitted as plaintext. If channel binding is to be used, I thought CB doesn't or shouldn't send passwords in cleartext? > When we store the key, we have to be careful about storing it by IP > address. I would not do that, as I have no way of knowing if the IP address > is permanent or ephermeral. > > I see no major problem with storing the keys by other IDs, particularly > random DN. > > The leap-of-faith would be when the admin took the key, and "locked it down", > i.e. loaded it into the trusted-store and attached some kind of SPD entry to > it. I.e. the leap-of-faith takes this peer from being BTNS to being > "normal" IPsec, with the exchanging of authentication material having been > facilitated by BTNS in-band. > (How the admin checked the key is by definition out of scope) Disagree on the last point, though it's subtle and not sure how significant it'll be. When SSH stores the key from the LoF, it means two thing: - It's a leap of faith for _this_ connection. - By storing the key for future use, one is extending the leap of faith for future connections until noted otherwise. This is similar to answering "Accepting this CA cert permanently" when prompted by web browsers. For both cases, they are still leap of faith, and are still unauthenticated (if no channel binding). It should not be treated or converted to _normal_ (authenticated) IPsec just because the leap of faith is extended. Bottom line: the auth credential is still unauthenticated in PAD, so IMO presenting it otherwise would be dangerous. I admit that in doing so, the applications, SSH & browsers, are essentially treating such extended LoF as "normal" by bypassing the prompts. But it's different to do so in protocols. Actually, now that I think about it, adding SPD probably doesn't make it "normal" (non-BTNS) IPsec because it's PAD that matters. Steve will know for sure. Finally, I am not sure if adding SPD entries because of BTNS is a good idea or not. Although it seems like the actual policy regarding authentication is in PAD in 4301 now, SPD is still part of the policy database and I've always thought BTNS should be specified by policy but not creating policy? Maybe this is related to Sam's comments re: API or interfaces to SPD? But I thought that's from _outside_ of IPsec such as other protocols or apps. yushun From Nicolas.Williams at sun.com Thu Mar 23 11:57:25 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Mar 2006 13:57:25 -0600 Subject: [anonsec] Your message to ANONSEC awaits moderator approval In-Reply-To: References: Message-ID: <20060323195725.GZ1010@binky.Central.Sun.COM> On Thu, Mar 23, 2006 at 09:47:07AM -0800, anonsec-bounces at postel.org wrote: > Your mail to 'ANONSEC' with the subject > > Re: [anonsec] what I call leap-of-faith > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > The message headers matched a filter rule Please fix the filter :/ (And what could that filter rule be?!) Nico -- From yushunwa at ISI.EDU Thu Mar 23 12:34:38 2006 From: yushunwa at ISI.EDU (Yu-Shun Wang) Date: Thu, 23 Mar 2006 14:34:38 -0600 Subject: [anonsec] Your message to ANONSEC awaits moderator approval In-Reply-To: <20060323195725.GZ1010@binky.Central.Sun.COM> References: <20060323195725.GZ1010@binky.Central.Sun.COM> Message-ID: <4423065E.5090804@isi.edu> Nicolas Williams wrote: > On Thu, Mar 23, 2006 at 09:47:07AM -0800, anonsec-bounces at postel.org wrote: >> Your mail to 'ANONSEC' with the subject >> >> Re: [anonsec] what I call leap-of-faith >> >> Is being held until the list moderator can review it for approval. >> >> The reason it is being held: >> >> The message headers matched a filter rule > > Please fix the filter :/ > > (And what could that filter rule be?!) Got the same response and asked Joe. It's to intercept "call" for papers. :-) yushun From Nicolas.Williams at sun.com Thu Mar 23 12:43:46 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Mar 2006 14:43:46 -0600 Subject: [anonsec] Your message to ANONSEC awaits moderator approval In-Reply-To: <4423065E.5090804@isi.edu> References: <20060323195725.GZ1010@binky.Central.Sun.COM> <4423065E.5090804@isi.edu> Message-ID: <20060323204346.GE1010@binky.Central.Sun.COM> On Thu, Mar 23, 2006 at 02:34:38PM -0600, Yu-Shun Wang wrote: > >> Re: [anonsec] what I call leap-of-faith > > Got the same response and asked Joe. It's to intercept > "call" for papers. :-) Heh. Ok, keep the filter then, but except this particular subject line! From kivinen at iki.fi Thu Mar 23 12:57:54 2006 From: kivinen at iki.fi (Tero Kivinen) Date: Thu, 23 Mar 2006 22:57:54 +0200 Subject: [anonsec] Your message to ANONSEC awaits moderator approval In-Reply-To: <20060323204346.GE1010@binky.Central.Sun.COM> References: <20060323195725.GZ1010@binky.Central.Sun.COM> <4423065E.5090804@isi.edu> <20060323204346.GE1010@binky.Central.Sun.COM> Message-ID: <17443.3026.791588.750188@fireball.acr.fi> Nicolas Williams writes: > On Thu, Mar 23, 2006 at 02:34:38PM -0600, Yu-Shun Wang wrote: > > >> Re: [anonsec] what I call leap-of-faith > > > > Got the same response and asked Joe. It's to intercept > > "call" for papers. :-) > > Heh. Ok, keep the filter then, but except this particular subject line! And when is the moderator planning to approve our emails... -- kivinen at safenet-inc.com From touch at ISI.EDU Thu Mar 23 14:23:23 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 23 Mar 2006 14:23:23 -0800 Subject: [anonsec] Your message to ANONSEC awaits moderator approval In-Reply-To: <17443.3026.791588.750188@fireball.acr.fi> References: <20060323195725.GZ1010@binky.Central.Sun.COM> <4423065E.5090804@isi.edu> <20060323204346.GE1010@binky.Central.Sun.COM> <17443.3026.791588.750188@fireball.acr.fi> Message-ID: <44231FDB.2080409@isi.edu> FYI - typically at least once a day except when on travel (when it's less) or when I know there is a backup (when it's more). Like just now... Joe Tero Kivinen wrote: > Nicolas Williams writes: >> On Thu, Mar 23, 2006 at 02:34:38PM -0600, Yu-Shun Wang wrote: >>>>> Re: [anonsec] what I call leap-of-faith >>> Got the same response and asked Joe. It's to intercept >>> "call" for papers. :-) >> Heh. Ok, keep the filter then, but except this particular subject line! > > And when is the moderator planning to approve our emails... From touch at ISI.EDU Thu Mar 23 14:22:33 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 23 Mar 2006 14:22:33 -0800 Subject: [anonsec] Your message to ANONSEC awaits moderator approval In-Reply-To: <20060323195725.GZ1010@binky.Central.Sun.COM> References: <20060323195725.GZ1010@binky.Central.Sun.COM> Message-ID: <44231FA9.7070209@isi.edu> The filter rule deals with list policy. The better solution, IMO, would be to use a subject line that identifies the discussion topic better. I had requested that PAS issues be listed as: PAS issue #: Those should fly through fine ;-) Joe Nicolas Williams wrote: > On Thu, Mar 23, 2006 at 09:47:07AM -0800, anonsec-bounces at postel.org wrote: >> Your mail to 'ANONSEC' with the subject >> >> Re: [anonsec] what I call leap-of-faith >> >> Is being held until the list moderator can review it for approval. >> >> The reason it is being held: >> >> The message headers matched a filter rule > > Please fix the filter :/ > > (And what could that filter rule be?!) > > Nico From kivinen at iki.fi Thu Mar 23 09:25:44 2006 From: kivinen at iki.fi (Tero Kivinen) Date: Thu, 23 Mar 2006 19:25:44 +0200 Subject: [anonsec] what I call leap-of-faith In-Reply-To: References: Message-ID: <17442.55832.446877.341320@fireball.acr.fi> Michael Richardson writes: > ssh.com ssh now stores things by the name that you type on the command > line + port number. openssh stores by IP and name. This causes problems if > you have ssh servers on different port numbers, such as having port 222 > portforwarded by you NAT to some host behind it --- I mention this because > the public is bound to a name in different ways by different vendors. The important thing there is to store AND match the identity user indicated to the database, without doing any unsecure modifcations to it (dns lookups, adding search path etc). There are attacks which can be done if those are done. I.e. the database lookup should be based only on the thing user typed in. One of the features implementations do not yet have is to do reverse matching of the keys, i.e. if the key is not found from the database using the identity given by user, then search the database for the matching public key, and instead of print "unknown host dialog", print out "Unknown host, but the samepublic key was previous used by host foo". This solves the problem where you ssh into your laptop in the remote network, where it might have unknown name and ip, but you can still find the matching public key from your database matching our "mylaptop.mynetwork.com" entry. Also implementations should give out the option to use make temporary connection,i.e. not to stopre information to the database permanently. > When we store the key, we have to be careful about storing it by IP > address. I would not do that, as I have no way of knowing if the IP address > is permanent or ephermeral. The problem with btns use of leap-of-faith is that quite often the IP-address is the only thing we have. My application might have some other identity (like dns-name), but when the packets finally end up to the ipsec level there is nothing left than the IP-address. If we do not have any specific policy for that host, then we do not have any other ID than IP address. Again here comes those gui-options in to important role. The user quite often knows whether the IP address he is connecting is permanent or not, he also knows whether he wants to insert the data to database or not. Also doing reverse lookup based on the public key for unknown identities will help user again to ntoice that all ip-addresses of for example www.google.com do match to the same key, especially if when adding to the new identity is added to the database the user is also given option to add extra comments. > I see no major problem with storing the keys by other IDs, particularly > random DN. Where do you get that DN or other IDs? You should not really trust the other end sending you ID claiming to be www.example.com when you are connecting to the www.evil.org. > The leap-of-faith would be when the admin took the key, and "locked it down", > i.e. loaded it into the trusted-store and attached some kind of SPD entry to > it. I.e. the leap-of-faith takes this peer from being BTNS to being > "normal" IPsec, with the exchanging of authentication material having been > facilitated by BTNS in-band. > (How the admin checked the key is by definition out of scope) -- kivinen at safenet-inc.com From Nicolas.Williams at sun.com Thu Mar 23 09:46:21 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Mar 2006 11:46:21 -0600 Subject: [anonsec] what I call leap-of-faith In-Reply-To: References: Message-ID: <20060323174621.GY1010@binky.Central.Sun.COM> On Mon, Mar 20, 2006 at 03:59:13PM -0600, Michael Richardson wrote: > > When you SSH to a host the server sends it's public key inline. [...] Note that this is a very application-centric view of LoF. And maybe that's what we can do in this context through use of connection-latching and IPsec APIs. That is, let the app get peer IDs, channel bindings, out of latched connections and then perform LoF at the application layer. Doing LoF at the IPsec layer gets us into all those issues we talked about. Note too that, given APIs to manipulate the IPsec DBs (PAD, SPD, SADB) applications could apply LoF not only at the app layer, but also enforce it in the PAD by creating PAD entries that bind BTNS publickey IDs and node addresses, though I wouldn't recommend it. Nico -- From touch at ISI.EDU Thu Mar 23 14:36:32 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 23 Mar 2006 14:36:32 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <4422D720.8010508@isi.edu> References: <4422D720.8010508@isi.edu> Message-ID: <442322F0.60601@isi.edu> Maybe it'd be useful to pose the questions separately, i.e., what should each of the following steps be called> 1. accepting the first unauthenticated certificate (U-C) 2. deciding to cache accepted U-Cs for future use 3. referring to the blind acceptance of cached U-Cs when matching Where's the leap? Is it in: - accepting the first UC - assuming that matching UCs mean matching endpoints - somewhere else? Joe Yu-Shun Wang wrote: > Hi, Michael, > > Comments below. > > Michael Richardson wrote: >> When you SSH to a host the server sends it's public key inline. >> >> The client checks against a local database it has (~/.ssh/known_hosts for ssh >> 1 and openssh, ~/ssh2/hostkeys/key_PORT_NAME for ssh.com ssh2). You can >> populate these yourself if you want. >> >> If the entry is not found, the user is presented with a finger print (hex and >> bubble-babble are common), and asked if they want to check it. The user types >> "y" or "n". Some users call up the admin and ask for the fingerprint, others >> just make a leap-of-faith: that they are not being MITM attacked at that >> moment. >> >> ssh.com ssh now stores things by the name that you type on the command >> line + port number. openssh stores by IP and name. This causes problems if >> you have ssh servers on different port numbers, such as having port 222 >> portforwarded by you NAT to some host behind it --- I mention this because >> the public is bound to a name in different ways by different vendors. >> >> The leap-of-faith is that the user is consulted as an oracle to make the hard >> decision. Modern SSH implementations will now for instance, turn off password >> authentication when the host is not yet known, to avoid disclosing the >> password to a MITM. >> >> If I was doing leap-of-faith for IPsec, as a peer that doesn't have an active >> user that can be contacted, then I'd accept to create the PARENT SA, and then >> limit the CHILD SA to what would otherwise be permitted as plaintext. > > If channel binding is to be used, I thought CB doesn't > or shouldn't send passwords in cleartext? > >> When we store the key, we have to be careful about storing it by IP >> address. I would not do that, as I have no way of knowing if the IP address >> is permanent or ephermeral. >> >> I see no major problem with storing the keys by other IDs, particularly >> random DN. >> >> The leap-of-faith would be when the admin took the key, and "locked it down", >> i.e. loaded it into the trusted-store and attached some kind of SPD entry to >> it. I.e. the leap-of-faith takes this peer from being BTNS to being >> "normal" IPsec, with the exchanging of authentication material having been >> facilitated by BTNS in-band. >> (How the admin checked the key is by definition out of scope) > > Disagree on the last point, though it's subtle and not sure > how significant it'll be. When SSH stores the key from the > LoF, it means two thing: > > - It's a leap of faith for _this_ connection. > - By storing the key for future use, one is extending the > leap of faith for future connections until noted otherwise. > > This is similar to answering "Accepting this CA cert > permanently" when prompted by web browsers. > > For both cases, they are still leap of faith, and are still > unauthenticated (if no channel binding). It should not be > treated or converted to _normal_ (authenticated) IPsec just > because the leap of faith is extended. Bottom line: the > auth credential is still unauthenticated in PAD, so IMO > presenting it otherwise would be dangerous. I admit that > in doing so, the applications, SSH & browsers, are essentially > treating such extended LoF as "normal" by bypassing the > prompts. But it's different to do so in protocols. Actually, > now that I think about it, adding SPD probably doesn't make > it "normal" (non-BTNS) IPsec because it's PAD that matters. > Steve will know for sure. > > Finally, I am not sure if adding SPD entries because of BTNS is > a good idea or not. Although it seems like the actual policy > regarding authentication is in PAD in 4301 now, SPD is > still part of the policy database and I've always thought > BTNS should be specified by policy but not creating policy? > Maybe this is related to Sam's comments re: API or interfaces > to SPD? But I thought that's from _outside_ of IPsec such as > other protocols or apps. > > yushun > _______________________________________________ From Nicolas.Williams at sun.com Thu Mar 23 14:57:45 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Mar 2006 16:57:45 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <442322F0.60601@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> Message-ID: <20060323225745.GG1010@binky.Central.Sun.COM> On Thu, Mar 23, 2006 at 02:36:32PM -0800, Joe Touch wrote: > Maybe it'd be useful to pose the questions separately, i.e., what should > each of the following steps be called> > > 1. accepting the first unauthenticated certificate (U-C) > > 2. deciding to cache accepted U-Cs for future use > > 3. referring to the blind acceptance of cached U-Cs when matching > > Where's the leap? Is it in: > - accepting the first UC > - assuming that matching UCs mean matching endpoints > - somewhere else? The better question is: where is the leap taken? If it's taken by the app, then we avoid the problems we discussed at Vancouver, whereas if it's taken in the KE (by creating LoF PAD entries binding the peer address and public key) then we run into those problems. Also, looking at the SSH example, LoF is usefully done on a client, not a server -- the server doesn't care about the client's public key since the client will be authenticating at the app layer and connection latching and channel bindings will protect against MITMs, but the client cares because once it knows a server's public key it might be willing to send passwords/session ID cookies (for "fast re-authentication") and what not over the latched connection. Nico -- From Nicolas.Williams at sun.com Thu Mar 23 15:42:01 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Mar 2006 17:42:01 -0600 Subject: [anonsec] what I call leap-of-faith In-Reply-To: References: Message-ID: <20060323234200.GH1010@binky.Central.Sun.COM> On Mon, Mar 20, 2006 at 03:59:13PM -0600, Michael Richardson wrote: > The leap-of-faith is that the user is consulted as an oracle to make the hard > decision. The leap-of-faith is what the user effectively has to do: he has to trust that (have faith in) his client's server is the one the user wanted -- the user has no realistic way of verifying this, so he has to take a 'leap' and just blindly believe it. > Modern SSH implementations will now for instance, turn off password > authentication when the host is not yet known, to avoid disclosing the > password to a MITM. Yup. > If I was doing leap-of-faith for IPsec, as a peer that doesn't have an active > user that can be contacted, then I'd accept to create the PARENT SA, and then > limit the CHILD SA to what would otherwise be permitted as plaintext. Well, the BTNS core doc allows just that (the administrator has to provide policy, of course). But a BTNS client could do LoF much like SSH clients given connection latching and APIs to retrieve the peer's ID type/value (if it's PUBLICKEY/... then BTNS was used and the client can look for the key in a known_hosts database and/or LoF). > When we store the key, we have to be careful about storing it by IP > address. I would not do that, as I have no way of knowing if the IP address > is permanent or ephermeral. Yes, that gets you into the problems we discussed at Vancouver. > I see no major problem with storing the keys by other IDs, particularly > random DN. Or whatever name a user passed to the client UI. > The leap-of-faith would be when the admin took the key, and "locked it down", > i.e. loaded it into the trusted-store and attached some kind of SPD entry to > it. I.e. the leap-of-faith takes this peer from being BTNS to being > "normal" IPsec, with the exchanging of authentication material having been > facilitated by BTNS in-band. > (How the admin checked the key is by definition out of scope) This is what we discussed at Vancouver. (Or was it Paris? Anyways.) Sure, the admin could create PAD and SPD entries binding an address/key pair, subject to the pains created by dynamic addressing. APIs like Sam was asking for would help make this possible :) Nico -- From Nicolas.Williams at sun.com Thu Mar 23 15:47:13 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 23 Mar 2006 17:47:13 -0600 Subject: [anonsec] what I call leap-of-faith In-Reply-To: <4422D720.8010508@isi.edu> References: <4422D720.8010508@isi.edu> Message-ID: <20060323234713.GI1010@binky.Central.Sun.COM> On Thu, Mar 23, 2006 at 11:13:04AM -0600, Yu-Shun Wang wrote: > Finally, I am not sure if adding SPD entries because of BTNS is > a good idea or not. Automatically? No, that'd be mostly a bad idea unless one were very careful to limit the addresses that can be so bound to keys. The problem you get into is a DoS (unintentional even) where clients over time cause all available dynamically assigned addresses to be so bound to their keys in their peers' policy databases, which then denies new clients that obtain those same addresses at future times the ability to talk to those servers. > Although it seems like the actual policy > regarding authentication is in PAD in 4301 now, SPD is > still part of the policy database and I've always thought > BTNS should be specified by policy but not creating policy? Yes. > Maybe this is related to Sam's comments re: API or interfaces > to SPD? But I thought that's from _outside_ of IPsec such as > other protocols or apps. APIs are interfaces. And yes, it would applications using them. Anything from IPsec configuration apps (which shouldn't be necessary, presumably, since you'd expect the native implementor to provide such applications) to applications that wish to create policy given contextual information (LoF at clients could be done this way). Nico -- From nwnetworks at dial.pipex.com Fri Mar 24 10:24:49 2006 From: nwnetworks at dial.pipex.com (Tom Petch) Date: Fri, 24 Mar 2006 19:24:49 +0100 Subject: [anonsec] what I call leap-of-faith References: Message-ID: <000901c64f70$56ba01c0$0601a8c0@pc6> Not sure what gave rise to this thread but the security glossary draft now contains a definition which I would regard as a starting point $ leap of faith 1. (I) /general security/ Operating a system as though it began operation in a secure state, even though it cannot be proven that such a state was established (i.e., even though a security compromise might have occurred at or before the time when operation began). 2. (I) /COMSEC/ The initial part, i.e., the first communication step or steps, of a protocol that is vulnerable to attack (especially a man-in-the-middle attack) during that part but, if that part is completed without being attacked, is subsequently not vulnerable in later steps (i.e., results in a secure communication association for which no man-in-the-middle attack is possible). Usage: This term is listed in English dictionaries, but their definitions are broad and can be interpreted in many ways in Internet contexts. Similarly, the definition stated here can be interpreted in several ways. Therefore, ISDs that use this term (especially ISDs that are protocol specifications) SHOULD state a more specific definition for it. Tutorial: In a protocol, a leap of faith typically consists of accepting a claim of peer identity, data origin, or data integrity without authenticating that claim. When a protocol includes such a step, the protocol might also be designed so that if a man-in-the- middle attack succeeds during the vulnerable first part, then the attacker must remain in the middle for all subsequent exchanges or else one of the legitimate parties will be able to detect the attack. Tom Petch ----- Original Message ----- From: "Michael Richardson" To: Sent: Monday, March 20, 2006 10:59 PM Subject: [anonsec] what I call leap-of-faith > When you SSH to a host the server sends it's public key inline. > > The client checks against a local database it has (~/.ssh/known_hosts for ssh > 1 and openssh, ~/ssh2/hostkeys/key_PORT_NAME for ssh.com ssh2). You can > populate these yourself if you want. > > If the entry is not found, the user is presented with a finger print (hex and > bubble-babble are common), and asked if they want to check it. The user types > "y" or "n". Some users call up the admin and ask for the fingerprint, others > just make a leap-of-faith: that they are not being MITM attacked at that > moment. > > ssh.com ssh now stores things by the name that you type on the command > line + port number. openssh stores by IP and name. This causes problems if > you have ssh servers on different port numbers, such as having port 222 > portforwarded by you NAT to some host behind it --- I mention this because > the public is bound to a name in different ways by different vendors. > > The leap-of-faith is that the user is consulted as an oracle to make the hard > decision. Modern SSH implementations will now for instance, turn off password > authentication when the host is not yet known, to avoid disclosing the > password to a MITM. > > If I was doing leap-of-faith for IPsec, as a peer that doesn't have an active > user that can be contacted, then I'd accept to create the PARENT SA, and then > limit the CHILD SA to what would otherwise be permitted as plaintext. > > When we store the key, we have to be careful about storing it by IP > address. I would not do that, as I have no way of knowing if the IP address > is permanent or ephermeral. > > I see no major problem with storing the keys by other IDs, particularly > random DN. > > The leap-of-faith would be when the admin took the key, and "locked it down", > i.e. loaded it into the trusted-store and attached some kind of SPD entry to > it. I.e. the leap-of-faith takes this peer from being BTNS to being > "normal" IPsec, with the exchanging of authentication material having been > facilitated by BTNS in-band. > (How the admin checked the key is by definition out of scope) > > -- > ] 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"); [ > > --=-=-= > From touch at ISI.EDU Mon Mar 27 10:01:44 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 10:01:44 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060323225745.GG1010@binky.Central.Sun.COM> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> Message-ID: <44282888.7080204@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Thu, Mar 23, 2006 at 02:36:32PM -0800, Joe Touch wrote: >> Maybe it'd be useful to pose the questions separately, i.e., what should >> each of the following steps be called> >> >> 1. accepting the first unauthenticated certificate (U-C) >> >> 2. deciding to cache accepted U-Cs for future use >> >> 3. referring to the blind acceptance of cached U-Cs when matching >> >> Where's the leap? Is it in: >> - accepting the first UC >> - assuming that matching UCs mean matching endpoints >> - somewhere else? > > The better question is: where is the leap taken? By whatever enables BTNS, which would be a user or an app. > If it's taken by the > app, then we avoid the problems we discussed at Vancouver, whereas if > it's taken in the KE (by creating LoF PAD entries binding the peer > address and public key) then we run into those problems. Those PAD entries are instances of a broader "BTNS OK" entry, which means the 'leap' has already been taken. > Also, looking at the SSH example, LoF is usefully done on a client, not > a server -- the server doesn't care about the client's public key since > the client will be authenticating at the app layer and connection > latching and channel bindings will protect against MITMs, but the client > cares because once it knows a server's public key it might be willing to > send passwords/session ID cookies (for "fast re-authentication") and > what not over the latched connection. Some servers have keys which don't match their DNS names, or are signed by CAs which are not well-known (i.e., predistributed with the client apps). In those cases, the client is sometimes asked to accept the key for the session or permanently - which is the same leap that the server takes w.r.t. the client (except that the server defaults to 'accept'). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKCiIE5f5cImnZrsRAnYRAKDNYzvQJsQqjsLrQgrqc9tEqr9LhgCg3o/X X9FU8S2MqwuFLlkJB7By9rI= =qAP4 -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Mar 27 10:14:18 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 27 Mar 2006 12:14:18 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44282888.7080204@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> Message-ID: <20060327181418.GE7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 10:01:44AM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > On Thu, Mar 23, 2006 at 02:36:32PM -0800, Joe Touch wrote: > >> Maybe it'd be useful to pose the questions separately, i.e., what should > >> each of the following steps be called> > >> > >> 1. accepting the first unauthenticated certificate (U-C) > >> > >> 2. deciding to cache accepted U-Cs for future use > >> > >> 3. referring to the blind acceptance of cached U-Cs when matching > >> > >> Where's the leap? Is it in: > >> - accepting the first UC > >> - assuming that matching UCs mean matching endpoints > >> - somewhere else? > > > > The better question is: where is the leap taken? > > By whatever enables BTNS, which would be a user or an app. > > [...] > > Those PAD entries are instances of a broader "BTNS OK" entry, which > means the 'leap' has already been taken. LoF isn't merely about accepting unauthenticated peers -- in the context of SSH, for example, it's about interactively asking if a peer's public key is "valid" and then recording it so that subsequently no such interaction is necessary. Applying the SSH model to BTNS we want: - "servers" to accept unauthenticated [BTNS] clients blindly, leaving it to the application to do any client/user authentication that might be desired at the application layer, - "clients" to require either that servers be authenticated (not BTNS) or that interaction with a user to accept a server's public key (BTNS PUBLICKEY ID) and record it somewhere (potentially the PAD could be used as an ssh_known_hosts type record, though I would not recommend it, and I would recommend against it on multi-user [time sharing] systems). Clients may, instead of interacting with a user to "validate" a server's public key, bind authentication at the application layer to the server's public key, as is done in SSHv2 with the GSS-API key exchange extension to SSHv2. Nico -- From touch at ISI.EDU Mon Mar 27 10:35:44 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 10:35:44 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060327181418.GE7525@binky.Central.Sun.COM> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> Message-ID: <44283080.3010106@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 10:01:44AM -0800, Joe Touch wrote: >> Nicolas Williams wrote: >>> On Thu, Mar 23, 2006 at 02:36:32PM -0800, Joe Touch wrote: >>>> Maybe it'd be useful to pose the questions separately, i.e., what should >>>> each of the following steps be called> >>>> >>>> 1. accepting the first unauthenticated certificate (U-C) >>>> >>>> 2. deciding to cache accepted U-Cs for future use >>>> >>>> 3. referring to the blind acceptance of cached U-Cs when matching >>>> >>>> Where's the leap? Is it in: >>>> - accepting the first UC >>>> - assuming that matching UCs mean matching endpoints >>>> - somewhere else? >>> The better question is: where is the leap taken? >> By whatever enables BTNS, which would be a user or an app. >> >> [...] >> >> Those PAD entries are instances of a broader "BTNS OK" entry, which >> means the 'leap' has already been taken. > > LoF isn't merely about accepting unauthenticated peers -- in the context > of SSH, for example, it's about interactively asking if a peer's public > key is "valid" and then recording it so that subsequently no such > interaction is necessary. This is the part I don't quite understand. Where's the LOF? - accepting the key now - keeping it for later reuse There's no reason the application can't set "accept unauthenticated peers for the following addresses/protocols/ports", so that the protocol doesn't need to ask the app even for new peers. I.e., the 'leap' seems to be in 'blindly accepting a peer's cert'. That need not wait for an initial exchange, and is often exactly what users end up doing when asked anyway... > Applying the SSH model to BTNS we want: > > - "servers" to accept unauthenticated [BTNS] clients blindly, leaving > it to the application to do any client/user authentication that might > be desired at the application layer, > > - "clients" to require either that servers be authenticated (not BTNS) > or that interaction with a user to accept a server's public key (BTNS > PUBLICKEY ID) and record it somewhere (potentially the PAD could be > used as an ssh_known_hosts type record, though I would not recommend > it, and I would recommend against it on multi-user [time sharing] > systems). The key might be useful to record during the SA (to prevent hijacking), but need not be recorded beyond that; the latter seems more like an option than a necessity. > Clients may, instead of interacting with a user to "validate" a > server's public key, bind authentication at the application layer to > the server's public key, as is done in SSHv2 with the GSS-API key > exchange extension to SSHv2. The client must first auto-accept the server's public key (instead of interacting with the user first), otherwise there won't be a channel to bind later ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKDCAE5f5cImnZrsRAgy5AKDyL3rw1q3ohJZgtq9Tnaqau9u34gCg1aRV 5sjWBU8ZicAMGqO2Ej4KvLw= =yNZi -----END PGP SIGNATURE----- From touch at ISI.EDU Mon Mar 27 11:19:27 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 11:19:27 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44282888.7080204@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> Message-ID: <44283ABF.2020609@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's a summary of what I understand so far; please post corrections. 1. leap of faith = accepting an unauthenticated certificate this refers to the FIRST accept of that certificate SSH servers do this automatically for client certificates, e.g. SSH clients typically ask users to verify certificates that otherwise cannot be authenticated in-band; this *assumes* out-of-band authentication of the certificate. One can consider users who blindly 'accept' those certificates to be performing a similar 'leap of faith' at the user level, though. 2. caching previously 'trusted' (authenticated or LOF assumed) keys for future use is NOT LOF there is no new leap taken this establishes continuity to _avoid_ a second LOF for the same certificate I was reminded that such caching is irrelevant to IKE, i.e., that keys need not be cached to prevent hijacking, since SAs can be torn down only if the child of a parent SA (can anyone confirm?). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKDq/E5f5cImnZrsRAr6gAJ9pRiAMiVVansoF7hpHXjh7Ni5YtACfZhDH oh3GKqMshIitrDffxZcCCKs= =UytH -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Mar 27 11:51:28 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 27 Mar 2006 13:51:28 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44283080.3010106@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> Message-ID: <20060327195128.GG7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 10:35:44AM -0800, Joe Touch wrote: > > LoF isn't merely about accepting unauthenticated peers -- in the context > > of SSH, for example, it's about interactively asking if a peer's public > > key is "valid" and then recording it so that subsequently no such > > interaction is necessary. > > This is the part I don't quite understand. > > Where's the LOF? It's what we as human users to do: "validate" (as if they even usually could, via some oob way) a peer's public key so that the application can create a pseudonymous-ID-(public key)-to-peer-address/ID/name/... binding. If unprotected traffic is OK then accepting peer public keys for "better than nothing security" requires no "faith" at all. (The BTNS core I-D provides only for this, and so does not address LoF _at all_.) OTOH, if protection against MITMs is required then on first meeting either "faith" or channel binding will be required to get past a peer's non-certified public key. Once one has take this leep then one can create a public key -> name/address/ID binding to avoid having to take it again later. > - accepting the key now > - keeping it for later reuse > > There's no reason the application can't set "accept unauthenticated > peers for the following addresses/protocols/ports", so that the protocol > doesn't need to ask the app even for new peers. Yes, but that's not quite LoF. And the app, given connection latching and APIs to retrieve a latched connection's peer's public key, could still do LoF at the app layer, even though there's no LoF below. > I.e., the 'leap' seems to be in 'blindly accepting a peer's cert'. That > need not wait for an initial exchange, and is often exactly what users > end up doing when asked anyway... Not just 'blindly accepting a peer's cert', but doing so when and in spite of stronger authentication being desired, because one has "faith" that one is not currently being actively attacked... ...And thence creating a stronger binding between the 'peer's cert' and the name/address by which it was named (at the transport layer and below that would always be an IP address; at the applications layers it would be a name or address). > > Clients may, instead of interacting with a user to "validate" a > > server's public key, bind authentication at the application layer to > > the server's public key, as is done in SSHv2 with the GSS-API key > > exchange extension to SSHv2. > > The client must first auto-accept the server's public key (instead of > interacting with the user first), otherwise there won't be a channel to > bind later ;-) Yes, of course, and IPsec policy must allow it, but that's not LoF in the SSH sense (see above); LoF in the SSH sense would consist of recording a {server's public key, user-provided servername/address} tuple on faith [that there peer really is the one the user wanted] and subsequently using the recorded entry to avoid having to take the leap again. Nico -- From Nicolas.Williams at sun.com Mon Mar 27 12:47:36 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 27 Mar 2006 14:47:36 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44283ABF.2020609@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <44283ABF.2020609@isi.edu> Message-ID: <20060327204736.GI7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 11:19:27AM -0800, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's a summary of what I understand so far; please post corrections. > > 1. leap of faith = accepting an unauthenticated certificate > this refers to the FIRST accept of that certificate My version: 1. leap of faith = accepting an unauthenticated peer when authentication of it is otherwise desired Here "faith" refers to the belief, or rather, hope that the peer is not being impersonated by an active attacker. > SSH servers do this automatically for client certificates, e.g. ^^^^^^ ^^^^^^^^^^^^ server public keys > SSH clients typically ask users to verify certificates that > otherwise cannot be authenticated in-band; this *assumes* > out-of-band authentication of the certificate. One can consider > users who blindly 'accept' those certificates to be performing > a similar 'leap of faith' at the user level, though. Not "consider" -- that *is* what leap of faith means in an SSH context: that the user is asked to do something they often can't and so typically accept a peer without further ado, on "faith" as it were. > 2. caching previously 'trusted' (authenticated or LOF assumed) keys for > future use is NOT LOF > there is no new leap taken > > this establishes continuity to _avoid_ a second LOF for the > same certificate (2) is incidental to LoF, but fundamental to making LoF practical. > I was reminded that such caching is irrelevant to IKE, i.e., that keys > need not be cached to prevent hijacking, since SAs can be torn down only > if the child of a parent SA (can anyone confirm?). This question is not important because you need connection latching to protect you from the wildcard matching problems discussed and that, in turn, provides a binding between individual packet flows and their end-point IDs. Nico -- From touch at ISI.EDU Mon Mar 27 12:50:29 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 12:50:29 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060327195128.GG7525@binky.Central.Sun.COM> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> Message-ID: <44285015.1000907@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 10:35:44AM -0800, Joe Touch wrote: >>> LoF isn't merely about accepting unauthenticated peers -- in the context >>> of SSH, for example, it's about interactively asking if a peer's public >>> key is "valid" and then recording it so that subsequently no such >>> interaction is necessary. >> This is the part I don't quite understand. >> >> Where's the LOF? > > It's what we as human users to do: "validate" (as if they even usually > could, via some oob way) a peer's public key so that the application can > create a pseudonymous-ID-(public key)-to-peer-address/ID/name/... binding. That seems like a very specific thing - out-of-band validation. There's no leap there - the user can (and seems like they're expected to) validate the key out-of-band. I.e., I was distinguishing between out-of-band validation - which is what SSL clients tend to do when the server's key isn't signed by a known CA, vs what SSL servers to - which does not involve asking a user anything. > If unprotected traffic is OK then accepting peer public keys for "better > than nothing security" requires no "faith" at all. (The BTNS core I-D > provides only for this, and so does not address LoF _at all_.) > > OTOH, if protection against MITMs is required then on first meeting > either "faith" or channel binding will be required to get past a peer's > non-certified public key. There are different places in the communication that MITM can occur; BTNS SAB still protects against MITM after the IKE DH step; it just doesn't protect you from doing the DH with the middle-man. I.e., if the DH isn't to the middle-man, then the stream should be MITM-protected. > Once one has take this leep then one can create a > > public key -> name/address/ID > > binding to avoid having to take it again later. That step seems to have nothing to do with LOF or even CB. It seems like it's just a local CA, equivalent to signing the remote keys yourself (i.e., you trusted them before, so you trust them in the future). >> - accepting the key now >> - keeping it for later reuse >> >> There's no reason the application can't set "accept unauthenticated >> peers for the following addresses/protocols/ports", so that the protocol >> doesn't need to ask the app even for new peers. > > Yes, but that's not quite LoF. And the app, given connection latching > and APIs to retrieve a latched connection's peer's public key, could > still do LoF at the app layer, even though there's no LoF below. I didn't think LOF was limited to cases with connection latching; if it is, please let me know. >> I.e., the 'leap' seems to be in 'blindly accepting a peer's cert'. That >> need not wait for an initial exchange, and is often exactly what users >> end up doing when asked anyway... > > Not just 'blindly accepting a peer's cert', but doing so when and in > spite of stronger authentication being desired, because one has "faith" > that one is not currently being actively attacked... "blindly" meant 'in the absence of stronger authentication' if stronger authentication is desired, the the leap isn't taken ;-) the faith is that the attack isn't in the identity phase of the protocol; there can still be assumptions of attacks at other phases (e.g., data attacks) > ...And thence creating a stronger binding between the 'peer's cert' and > the name/address by which it was named (at the transport layer and below > that would always be an IP address; at the applications layers it would > be a name or address). > >>> Clients may, instead of interacting with a user to "validate" a >>> server's public key, bind authentication at the application layer to >>> the server's public key, as is done in SSHv2 with the GSS-API key >>> exchange extension to SSHv2. >> The client must first auto-accept the server's public key (instead of >> interacting with the user first), otherwise there won't be a channel to >> bind later ;-) > > Yes, of course, and IPsec policy must allow it, but that's not LoF in > the SSH sense (see above); LoF in the SSH sense would consist of > recording a {server's public key, user-provided servername/address} > tuple on faith [that there peer really is the one the user wanted] and > subsequently using the recorded entry to avoid having to take the leap > again. As per above, I don't see how using a cached leap is a new leap, and LOF can't be defined in terms of just that cache (it'd be a circular definition). There must be an initial leap; subsequent use of the cache really seems like it isn't taking a new leap at all. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKFAVE5f5cImnZrsRAuCLAJ47jaTqzzTTeJrQ10XbrAXY7nMCbgCfUZmo pdbRcqqzzhTdTpYW99SgRgE= =LD3N -----END PGP SIGNATURE----- From touch at ISI.EDU Mon Mar 27 12:57:57 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 12:57:57 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060327204736.GI7525@binky.Central.Sun.COM> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <44283ABF.2020609@isi.edu> <20060327204736.GI7525@binky.Central.Sun.COM> Message-ID: <442851D5.2060105@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 11:19:27AM -0800, Joe Touch wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Here's a summary of what I understand so far; please post corrections. >> >> 1. leap of faith = accepting an unauthenticated certificate >> this refers to the FIRST accept of that certificate > > My version: > > 1. leap of faith = accepting an unauthenticated peer when authentication > of it is otherwise desired > > Here "faith" refers to the belief, or rather, hope that the peer is > not being impersonated by an active attacker. > >> SSH servers do this automatically for client certificates, e.g. > ^^^^^^ ^^^^^^^^^^^^ > server public keys I meant client public keys. The auto-part is done at the server for the client info. The clients typically do NOT accept unauthenticated server public keys; they typically ask the user to authenticate them (as per below). >> SSH clients typically ask users to verify certificates that >> otherwise cannot be authenticated in-band; this *assumes* >> out-of-band authentication of the certificate. One can consider >> users who blindly 'accept' those certificates to be performing >> a similar 'leap of faith' at the user level, though. > > Not "consider" -- that *is* what leap of faith means in an SSH context: > that the user is asked to do something they often can't and so typically > accept a peer without further ado, on "faith" as it were. It's really useful to distinguish between what the user does (typically 'leaps') and what the protocol thinks it's doing (delegating authentication to a user process). SSH isn't taking the leap there. > >> 2. caching previously 'trusted' (authenticated or LOF assumed) keys for >> future use is NOT LOF >> there is no new leap taken >> >> this establishes continuity to _avoid_ a second LOF for the >> same certificate > > (2) is incidental to LoF, but fundamental to making LoF practical. The only practicality relates to interrupting the user to do out-of-band authentication. It's relevant only at the client side; the server side need not cache anything to be practical. >> I was reminded that such caching is irrelevant to IKE, i.e., that keys >> need not be cached to prevent hijacking, since SAs can be torn down only >> if the child of a parent SA (can anyone confirm?). > > This question is not important because you need connection latching to > protect you from the wildcard matching problems discussed and that, in > turn, provides a binding between individual packet flows and their > end-point IDs. Doesn't the need for (and utility of) connection latching presume channel binding? I.e., in the case where there is no channel binding, this doesn't seem relevant. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKFHVE5f5cImnZrsRAmY1AKDGKOwf1d6z7k+BxtJZw7ahot64KACfSyB4 DNXrcqi/Wdcmn1Q9ZPK4L3w= =7TV7 -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Mar 27 13:00:39 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 27 Mar 2006 15:00:39 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44285015.1000907@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> Message-ID: <20060327210039.GJ7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 12:50:29PM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > On Mon, Mar 27, 2006 at 10:35:44AM -0800, Joe Touch wrote: > >>> LoF isn't merely about accepting unauthenticated peers -- in the context > >>> of SSH, for example, it's about interactively asking if a peer's public > >>> key is "valid" and then recording it so that subsequently no such > >>> interaction is necessary. > >> This is the part I don't quite understand. > >> > >> Where's the LOF? > > > > It's what we as human users to do: "validate" (as if they even usually > > could, via some oob way) a peer's public key so that the application can > > create a pseudonymous-ID-(public key)-to-peer-address/ID/name/... binding. > > That seems like a very specific thing - out-of-band validation. There's > no leap there - the user can (and seems like they're expected to) > validate the key out-of-band. No, they usually can't, and even more commonly don't. They take a "leap": "I'm not being attacked"; and usually this leap works out fine (which teaches them to keep this up). From touch at ISI.EDU Mon Mar 27 13:13:08 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 13:13:08 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060327210039.GJ7525@binky.Central.Sun.COM> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> Message-ID: <44285564.6030707@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 12:50:29PM -0800, Joe Touch wrote: >> Nicolas Williams wrote: >>> On Mon, Mar 27, 2006 at 10:35:44AM -0800, Joe Touch wrote: >>>>> LoF isn't merely about accepting unauthenticated peers -- in the context >>>>> of SSH, for example, it's about interactively asking if a peer's public >>>>> key is "valid" and then recording it so that subsequently no such >>>>> interaction is necessary. >>>> This is the part I don't quite understand. >>>> >>>> Where's the LOF? >>> It's what we as human users to do: "validate" (as if they even usually >>> could, via some oob way) a peer's public key so that the application can >>> create a pseudonymous-ID-(public key)-to-peer-address/ID/name/... binding. >> That seems like a very specific thing - out-of-band validation. There's >> no leap there - the user can (and seems like they're expected to) >> validate the key out-of-band. > > No, they usually can't, and even more commonly don't. They take a > "leap": "I'm not being attacked"; and usually this leap works out fine > (which teaches them to keep this up). The leap's at the user level, NOT at SSL. SSL thinks the user is performing whatever validation - leap or not - the user wants. Besides, they can: - check to see if the cert has the IP address they expect - check to see if the cert has the DNS name they expect - check the contents of the cert (some websites of unsigned keys this info for this purpose, under the assumption that an attack would need to spoof both the web server and the SSH server to work) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKFVkE5f5cImnZrsRAmuQAJ9S1lxya/nWNP/lCSFG8Diav3VEjwCgwRbj BtMwmJXNU+C4ZKeUizp4Rvs= =loXZ -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Mar 27 13:29:40 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 27 Mar 2006 15:29:40 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <442851D5.2060105@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <44283ABF.2020609@isi.edu> <20060327204736.GI7525@binky.Central.Sun.COM> <442851D5.2060105@isi.edu> Message-ID: <20060327212940.GK7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 12:57:57PM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > On Mon, Mar 27, 2006 at 11:19:27AM -0800, Joe Touch wrote: > > > > My version: > > > > 1. leap of faith = accepting an unauthenticated peer when authentication > > of it is otherwise desired > > > > Here "faith" refers to the belief, or rather, hope that the peer is > > not being impersonated by an active attacker. > > > >> SSH servers do this automatically for client certificates, e.g. > > ^^^^^^ ^^^^^^^^^^^^ > > server public keys > > I meant client public keys. The auto-part is done at the server for the > client info. That was something we discussed some months ago. I think it's what you wanted for your BGP use case, and it may make sense in that context, ... ...but because of the dynamic address space consumption problem we discussed at Vancouver it's not generally useful. I think client-side LoF can be useful far more often than server-side LoF. At the very least we should distinguish between the two. > The clients typically do NOT accept unauthenticated server public keys; > they typically ask the user to authenticate them (as per below). But they (the users) don't [authenticate server public keys] -- they take a "leap of faith" that those are the correct keys. > >> SSH clients typically ask users to verify certificates that > >> otherwise cannot be authenticated in-band; this *assumes* > >> out-of-band authentication of the certificate. One can consider > >> users who blindly 'accept' those certificates to be performing > >> a similar 'leap of faith' at the user level, though. > > > > Not "consider" -- that *is* what leap of faith means in an SSH context: > > that the user is asked to do something they often can't and so typically > > accept a peer without further ado, on "faith" as it were. > > It's really useful to distinguish between what the user does (typically > 'leaps') and what the protocol thinks it's doing (delegating > authentication to a user process). SSH isn't taking the leap there. It is the user taking the leap, absolutely,which is why I insisted earlier on asking where in the stack (and which peer) LoF would function in BTNS LoF. But the protocol, by providing ad-hoc authentication schemes, does imply LoF in actuality since that's the best that users can do. > >> I was reminded that such caching is irrelevant to IKE, i.e., that keys > >> need not be cached to prevent hijacking, since SAs can be torn down only > >> if the child of a parent SA (can anyone confirm?). > > > > This question is not important because you need connection latching to > > protect you from the wildcard matching problems discussed and that, in > > turn, provides a binding between individual packet flows and their > > end-point IDs. > > Doesn't the need for (and utility of) connection latching presume > channel binding? I.e., in the case where there is no channel binding, > this doesn't seem relevant. No. With connection latching we can have the application (possibly through interaction with the user) perform SSH-like LoF _at the application layer_. Incidentally, this thread convinces me (ok, I've convinced myself :) that LoF really belongs at the application layer. At its core BTNS should simply require that policy identify traffic types (port numbers, etc) that should be allowed and protected even with unauthenticated peers on account of measures taken by the applications driving such traffic flows; such measures include channel binding and LoF. A contrived example of BTNS + LoF based on the SSH model would be SSH itself: given IPsec, BTNS, connection latching and an API for obtaining the latched IDs/keys then SSHv2 clients and servers could negotiate the use of the none cipher/MAC at the SSHv2 layer, relying instead on ESP/AH to provide the desired QoP. In this contrived example the client would still have to ask the user to "validate" any servers' BTNS public keys, so users would continue to take "leaps of faith." That example may not be so contrived, actually, in that given sufficiently advanced ESP/AH offload in NICs and bulk applications running over SSHv2 then this scheme I posit may be desirable, not merely fantasy. A non-contrived example of BTNS + LoF might be your original BGP use case (feel free to elaborate). A non-contrived example of channel binding is NFSv4. I won't repeat that right now, to avoid sounding like a broken record :) Cheers, Nico -- From Nicolas.Williams at sun.com Mon Mar 27 13:31:59 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 27 Mar 2006 15:31:59 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44285564.6030707@isi.edu> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> <44285564.6030707@isi.edu> Message-ID: <20060327213158.GL7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 01:13:08PM -0800, Joe Touch wrote: > >> That seems like a very specific thing - out-of-band validation. There's > >> no leap there - the user can (and seems like they're expected to) > >> validate the key out-of-band. > > > > No, they usually can't, and even more commonly don't. They take a > > "leap": "I'm not being attacked"; and usually this leap works out fine > > (which teaches them to keep this up). > > The leap's at the user level, NOT at SSL. SSL thinks the user is > performing whatever validation - leap or not - the user wants. Huh? Did you mean SSH? > Besides, they can: > - check to see if the cert has the IP address they expect > - check to see if the cert has the DNS name they expect > - check the contents of the cert (some websites of unsigned keys > this info for this purpose, under the assumption that an > attack would need to spoof both the web server and the SSH > server to work) In the SSL/TLS case the leap really derives from installing and using browsers with large sets of trust anchors :^/ In any case, if you have a cert that you can validate (up to an acceptable trust anchor) and tie to the peer's address/name/whatever then you're done, and there's no need to take leaps or bind channels. From touch at ISI.EDU Mon Mar 27 13:47:46 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 13:47:46 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060327213158.GL7525@binky.Central.Sun.COM> References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> <44285564.6030707@isi.edu> <20060327213158.GL7525@binky.Central.Sun.COM> Message-ID: <44285D82.4070504@isi.edu> Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 01:13:08PM -0800, Joe Touch wrote: >>>> That seems like a very specific thing - out-of-band validation. There's >>>> no leap there - the user can (and seems like they're expected to) >>>> validate the key out-of-band. >>> No, they usually can't, and even more commonly don't. They take a >>> "leap": "I'm not being attacked"; and usually this leap works out fine >>> (which teaches them to keep this up). >> The leap's at the user level, NOT at SSL. SSL thinks the user is >> performing whatever validation - leap or not - the user wants. > > Huh? Did you mean SSH? I was talking about SSL (TLS). Which is probably why we got crossed w.r.t. clients and servers. SSL/TLS is the one that has the server side that is more like BTNS SAB, and the client side that is more like BTNS w/channel binding. >> Besides, they can: >> - check to see if the cert has the IP address they expect >> - check to see if the cert has the DNS name they expect >> - check the contents of the cert (some websites of unsigned keys >> this info for this purpose, under the assumption that an >> attack would need to spoof both the web server and the SSH >> server to work) > > In the SSL/TLS case the leap really derives from installing and using > browsers with large sets of trust anchors :^/ As I noted, when those anchors are insufficient: - on the server side, LOF occurs (just accepts the user's cert) - on the client side, the app asks the user to authenticate the cert; most users tend to just click 'yes' (LOF), whereas some check the cert (more like out-of-band auth) > In any case, if you have a cert that you can validate (up to an > acceptable trust anchor) and tie to the peer's address/name/whatever > then you're done, and there's no need to take leaps or bind channels. From Nicolas.Williams at sun.com Mon Mar 27 14:30:50 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 27 Mar 2006 16:30:50 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44285D82.4070504@isi.edu> References: <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> <44285564.6030707@isi.edu> <20060327213158.GL7525@binky.Central.Sun.COM> <44285D82.4070504@isi.edu> Message-ID: <20060327223050.GM7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 01:47:46PM -0800, Joe Touch wrote: > As I noted, when those anchors are insufficient: > > - on the server side, LOF occurs (just accepts the user's cert) > - on the client side, the app asks the user to authenticate > the cert; most users tend to just click 'yes' (LOF), whereas > some check the cert (more like out-of-band auth) I think I'm ready to assert: a) LoF is meaningful only where actual authentication of the peer is desired; not caring at all requires no "leap"; b) Without interaction or creation of a persistent binding between a peer's public key and asserted identity LoF is no better than AUTH_SYS + unauthenticated DH key exchange; c) Without interaction but with creation of a persistent binding between peer's public key and asserted identity LoF creates a DoS whereby peers can bottle up all scarce identities (in the BTNS case we've discussed that would be dynamically assigned IP addresses as well as any other addresses that an attacker can commandeer). d) Creation of a persistent binding between a peer's public key and asserted identity is necessary for interactive LoF to be user- friendly and practical. I'll also assert that: - draft-ietf-btns-core-00.txt does not address LoF at all, instead it provides for how to configure a system to allow unauthenticated peers for selected applications (selected based traffice selectors). - Connection latching + APIs to obtain a latched connection's peer ID/public key allows applications to implement channel binding and/or LoF at the application layer if they so desire. - The above + IPsec APIs such as Sam proposed would allow applications to drive LoF at the IPsec policy layer by creating PAD entries binding peer IDs/public keys to their addresses and creating associated SPD entries searched for by peer ID and binding specific traffic types to such PAD entries. Comments? Nico -- From touch at ISI.EDU Mon Mar 27 17:35:23 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 27 Mar 2006 17:35:23 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060327223050.GM7525@binky.Central.Sun.COM> References: <20060323225745.GG1010@binky.Central.Sun.COM> <44282888.7080204@isi.edu> <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> <44285564.6030707@isi.edu> <20060327213158.GL7525@binky.Central.Sun.COM> <44285D82.4070504@isi.edu> <20060327223050.GM7525@binky.Central.Sun.COM> Message-ID: <442892DB.5010601@isi.edu> Nicolas Williams wrote: > On Mon, Mar 27, 2006 at 01:47:46PM -0800, Joe Touch wrote: >> As I noted, when those anchors are insufficient: >> >> - on the server side, LOF occurs (just accepts the user's cert) >> - on the client side, the app asks the user to authenticate >> the cert; most users tend to just click 'yes' (LOF), whereas >> some check the cert (more like out-of-band auth) > > I think I'm ready to assert: > > a) LoF is meaningful only where actual authentication of the peer is > desired; not caring at all requires no "leap"; That makes no sense to me, nor does it match anything I could find in the literature. LOF seems precisely about blind acceptance of the first certificate presented without authentication. > b) Without interaction or creation of a persistent binding between a > peer's public key and asserted identity LoF is no better than > AUTH_SYS + unauthenticated DH key exchange; I'm not sure I see your point here. > c) Without interaction but with creation of a persistent binding between > peer's public key and asserted identity LoF creates a DoS whereby > peers can bottle up all scarce identities (in the BTNS case we've > discussed that would be dynamically assigned IP addresses as well as > any other addresses that an attacker can commandeer). If the certificate is kept, then there's a DOS attack. If it's not, then there's no scarcity of identities to consume. That seems contrary to your point here. > d) Creation of a persistent binding between a peer's public key and > asserted identity is necessary for interactive LoF to be user- > friendly and practical. I presented a case to the contrary of that before, e.g., SSH server-side LOF. > I'll also assert that: > > - draft-ietf-btns-core-00.txt does not address LoF at all, This was a PAS issue... > - Connection latching + APIs to obtain a latched connection's peer > ID/public key allows applications to implement channel binding and/or > LoF at the application layer if they so desire. The issue w.r.t. the PAS doc is whether CL/CB are required for LOF or not, and whether certificate caching is required for LOF or not. The question I'm trying to resolve is more about whether LOF requires these components - in which case it seems like it ought to be discussed solely in the context of the CL/CB doc - or whether it's germane to the general case, as discussed in the PAS. Are there others who can help resolve this? Joe From Nicolas.Williams at sun.com Tue Mar 28 00:16:21 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 28 Mar 2006 02:16:21 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <442892DB.5010601@isi.edu> References: <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> <44285564.6030707@isi.edu> <20060327213158.GL7525@binky.Central.Sun.COM> <44285D82.4070504@isi.edu> <20060327223050.GM7525@binky.Central.Sun.COM> <442892DB.5010601@isi.edu> Message-ID: <20060328081620.GC7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 05:35:23PM -0800, Joe Touch wrote: > > > Nicolas Williams wrote: > > On Mon, Mar 27, 2006 at 01:47:46PM -0800, Joe Touch wrote: > >> As I noted, when those anchors are insufficient: > >> > >> - on the server side, LOF occurs (just accepts the user's cert) > >> - on the client side, the app asks the user to authenticate > >> the cert; most users tend to just click 'yes' (LOF), whereas > >> some check the cert (more like out-of-band auth) > > > > I think I'm ready to assert: > > > > a) LoF is meaningful only where actual authentication of the peer is > > desired; not caring at all requires no "leap"; > > That makes no sense to me, nor does it match anything I could find in > the literature. LOF seems precisely about blind acceptance of the first > certificate presented without authentication. We have to distinguish cases where we care not a bit about authenticating peers or protecting traffice, in which case blindly accepting peers and protecting traffic is "better than nothing," but not remotely like SSH LoF. We may argue about terminology, but when I think LoF I think SSH (thanks to Michael for re-focusing the discussion on that angle -- I was a bit lost before that). > > b) Without interaction or creation of a persistent binding between a > > peer's public key and asserted identity LoF is no better than > > AUTH_SYS + unauthenticated DH key exchange; > > I'm not sure I see your point here. AUTH_SYS is an ONC/RPC security flavour where clients assert their IDs and servers do nothing particularly strong to verify that the clients are who they say they are; and it provides no data protection. > > d) Creation of a persistent binding between a peer's public key and > > asserted identity is necessary for interactive LoF to be user- > > friendly and practical. > > I presented a case to the contrary of that before, e.g., SSH server-side > LOF. No such thing. > > I'll also assert that: > > > > - draft-ietf-btns-core-00.txt does not address LoF at all, > > This was a PAS issue... LoF can be addressed in a separate I-D. I saw no consensus for describing LoF in the core doc. > > - Connection latching + APIs to obtain a latched connection's peer > > ID/public key allows applications to implement channel binding and/or > > LoF at the application layer if they so desire. > > The issue w.r.t. the PAS doc is whether CL/CB are required for LOF or > not, and whether certificate caching is required for LOF or not. The > question I'm trying to resolve is more about whether LOF requires these > components - in which case it seems like it ought to be discussed solely > in the context of the CL/CB doc - or whether it's germane to the general > case, as discussed in the PAS. Either could be followed, but the problems with the latter are such that I will not pursue it. (Feel free to edit an I-D that described the LoF fotm you like :) > Are there others who can help resolve this? I hope so as for now we seem to be talking past each other (I attribute this to a terminology problem :) Nico -- From touch at ISI.EDU Tue Mar 28 07:21:21 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 28 Mar 2006 07:21:21 -0800 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060328081620.GC7525@binky.Central.Sun.COM> References: <20060327181418.GE7525@binky.Central.Sun.COM> <44283080.3010106@isi.edu> <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> <44285564.6030707@isi.edu> <20060327213158.GL7525@binky.Central.Sun.COM> <44285D82.4070504@isi.edu> <20060327223050.GM7525@binky.Central.Sun.COM> <442892DB.5010601@isi.edu> <20060328081620.GC7525@binky.Central.Sun.COM> Message-ID: <44295471.4020608@isi.edu> Nicolas Williams wrote: ... >> This was a PAS issue... > > LoF can be addressed in a separate I-D. I saw no consensus for > describing LoF in the core doc. Can someone else confirm this? If so, I'd be GLAD to remove it and call the issue closed for now ;-) Joe From Nicolas.Williams at sun.com Tue Mar 28 07:31:07 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 28 Mar 2006 09:31:07 -0600 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <44295471.4020608@isi.edu> References: <20060327195128.GG7525@binky.Central.Sun.COM> <44285015.1000907@isi.edu> <20060327210039.GJ7525@binky.Central.Sun.COM> <44285564.6030707@isi.edu> <20060327213158.GL7525@binky.Central.Sun.COM> <44285D82.4070504@isi.edu> <20060327223050.GM7525@binky.Central.Sun.COM> <442892DB.5010601@isi.edu> <20060328081620.GC7525@binky.Central.Sun.COM> <44295471.4020608@isi.edu> Message-ID: <20060328153107.GN7525@binky.Central.Sun.COM> On Tue, Mar 28, 2006 at 07:21:21AM -0800, Joe Touch wrote: > > > Nicolas Williams wrote: > ... > >> This was a PAS issue... > > > > LoF can be addressed in a separate I-D. I saw no consensus for > > describing LoF in the core doc. > > Can someone else confirm this? If so, I'd be GLAD to remove it and call > the issue closed for now ;-) :) I do think though that now I understand what _I_ would want in terms of LoF w/ BTNS, and how to specify it. Nico -- From kent at bbn.com Mon Mar 27 13:49:29 2006 From: kent at bbn.com (Stephen Kent) Date: Mon, 27 Mar 2006 16:49:29 -0500 Subject: [anonsec] what I call leap-of-faith In-Reply-To: <20060323174621.GY1010@binky.Central.Sun.COM> References: <20060323174621.GY1010@binky.Central.Sun.COM> Message-ID: At 11:46 AM -0600 3/23/06, Nicolas Williams wrote: >... >Note too that, given APIs to manipulate the IPsec DBs (PAD, SPD, SADB) >applications could apply LoF not only at the app layer, but also enforce >it in the PAD by creating PAD entries that bind BTNS publickey IDs and >node addresses, though I wouldn't recommend it. > >Nico I agree that there may be a number of problems associated with LoF implemented at the IP layer, as Nico noted. I also want to second Nico's aversion to using APIs for manipulating the PAD or SPD as a way to address all of our problems. IPsec focuses on access control that is effected via these databases. If every app can manipulate these databases, then we undermine these access controls. A Trojan Horse acting on these databases via an API could completely circumvent whatever policy a user might have established. To avoid this sort of problem we would have to impose access controls on what SPD/PAD entries different apps are allowed to manipulate, which sounds awfully complex. Steve From Nicolas.Williams at sun.com Tue Mar 28 00:09:24 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 28 Mar 2006 02:09:24 -0600 Subject: [anonsec] what I call leap-of-faith In-Reply-To: References: <20060323174621.GY1010@binky.Central.Sun.COM> Message-ID: <20060328080924.GB7525@binky.Central.Sun.COM> On Mon, Mar 27, 2006 at 04:49:29PM -0500, Stephen Kent wrote: > At 11:46 AM -0600 3/23/06, Nicolas Williams wrote: > >... > >Note too that, given APIs to manipulate the IPsec DBs (PAD, SPD, SADB) > >applications could apply LoF not only at the app layer, but also enforce > >it in the PAD by creating PAD entries that bind BTNS publickey IDs and > >node addresses, though I wouldn't recommend it. > > > >Nico > > I agree that there may be a number of problems associated with LoF > implemented at the IP layer, as Nico noted. I also want to second > Nico's aversion to using > APIs for manipulating the PAD or SPD as a way to address all of our > problems. Oh, I'm not entirely averse to them, I'm averse to automatically creating PAD/SPD entries corresponding to BTNS peers one has seen, because of those problems. LoF should be implemented, if at all, at the app layer using connection latching and APIs to retreive the latched IDs/keys. Nico --