From kent at bbn.com Mon Apr 3 14:52:41 2006 From: kent at bbn.com (Stephen Kent) Date: Mon, 3 Apr 2006 17:52:41 -0400 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <442892DB.5010601@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> <20060327223050.GM7525@binky.Central.Sun.COM> <442892DB.5010601@isi.edu> Message-ID: At 5:35 PM -0800 3/27/06, 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. I agree with Nico. The essence of LoF is that a user accepts a credential (a cert that will be viewed as a trust anchor for SSL, a public key for a server in SSH) under the assumption that there is no MITM attack taking place at the time of exchange with the server, and that the ID and key asserted in the exchange is accurate. After that initial exchange where the LoF takes place, subsequent communication is authenticated based on the credential that was accepted, and is resistant to MITM attacks. In the IPsec context, this translates into creating a PAD entry based on a unauthenticated IKE exchange. The difference here is that IPsec, unlike SSH and SSL, implements access control and thus the ID bound to the key directly affects the protocol operation in this regard. So we have to be very careful what form of IDs are installed in a PAD entry under an LoF model of operation. For example, addresses might be inappropriate (due to DHCP and mobility) but names might be OK. Steve From Nicolas.Williams at sun.com Tue Apr 4 07:53:29 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 4 Apr 2006 09:53:29 -0500 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: References: <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: <20060404145329.GA1434@binky.Central.Sun.COM> On Mon, Apr 03, 2006 at 05:52:41PM -0400, Stephen Kent wrote: > >> 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. > > I agree with Nico. The essence of LoF is that a user accepts a > credential (a cert that will be viewed as a trust anchor for SSL, a > public key for a server in SSH) under the assumption that there is no > MITM attack taking place at the time of exchange with the server, and > that the ID and key asserted in the exchange is accurate. After that > initial exchange where the LoF takes place, subsequent communication > is authenticated based on the credential that was accepted, and is > resistant to MITM attacks. Right, so the BTNS core I-D only provides for "not caring at all" about authentication and leaves LoF to some other document. > In the IPsec context, this translates into creating a PAD entry based > on a unauthenticated IKE exchange. This is the first one of two methods we've considered so far. The second method involves connection latching and pushes the responsibility for LoF to the application. I *much* prefer the second method. > The difference here is that IPsec, > unlike SSH and SSL, implements access control and thus the ID bound > to the key directly affects the protocol operation in this regard. So > we have to be very careful what form of IDs are installed in a PAD > entry under an LoF model of operation. For example, addresses might > be inappropriate (due to DHCP and mobility) but names might be OK. The problem is that w/o IPsec-specific APIs the only "IDs" seen by the application through traditional APIs are, in fact, IP addresses. You've just re-identified the problem: IPsec LoF requires IPsec-specific APIs to avoid dynamic address consumption (read: DoS attacks), and it requires application involvement. We just agreed that we don't want strong bindings between PUBLICKEY IDs and addresses; we also don't want to allow theft of packet flows at SA expiration/renewal time, and we don't want very long SA lifetimes to create stronger publickey/address bindings than we're willing to tolerate. Which, IMO, argues for connection latching. If you'll accept IPsec APIs at all then I think you'll find the second LoF method (see above) more appealing than the first. Nico -- From kent at bbn.com Tue Apr 4 10:14:00 2006 From: kent at bbn.com (Stephen Kent) Date: Tue, 4 Apr 2006 13:14:00 -0400 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: <20060404145329.GA1434@binky.Central.Sun.COM> References: <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> <20060404145329.GA1434@binky.Central.Sun.COM> Message-ID: Nico, >... > >> In the IPsec context, this translates into creating a PAD entry based >> on a unauthenticated IKE exchange. > >This is the first one of two methods we've considered so far. > >The second method involves connection latching and pushes the >responsibility for LoF to the application. in that case, IPsec is not providing LoF support per se, as the responsibility is assumed by the application. >I *much* prefer the second method. no argument from me. > > The difference here is that IPsec, >> unlike SSH and SSL, implements access control and thus the ID bound >> to the key directly affects the protocol operation in this regard. So >> we have to be very careful what form of IDs are installed in a PAD >> entry under an LoF model of operation. For example, addresses might >> be inappropriate (due to DHCP and mobility) but names might be OK. > >The problem is that w/o IPsec-specific APIs the only "IDs" seen by the >application through traditional APIs are, in fact, IP addresses. yes, and even those are indirect references, since the apps usually employ names, not addresses >You've just re-identified the problem: IPsec LoF requires IPsec-specific >APIs to avoid dynamic address consumption (read: DoS attacks), and it >requires application involvement. Most of the discussion here seems to entail application involvement, so that does not seem like an issue, whether we're discussing APIs, etc. What I tried to do was to note that because IPsec enforces access control decisions based on IDs, LoF has different implications here vs in security protocols that do not offer access control functionality at all. >We just agreed that we don't want strong bindings between PUBLICKEY IDs >and addresses; we also don't want to allow theft of packet flows at SA >expiration/renewal time, and we don't want very long SA lifetimes to >create stronger publickey/address bindings than we're willing to >tolerate. Which, IMO, argues for connection latching. there are contexts in which bindings between PK IDs and addresses are feasible and maybe even desirable, but those are not the most general cases. >If you'll accept IPsec APIs at all then I think you'll find the second >LoF method (see above) more appealing than the first. I understand your preference here. APIs may be fine in many contexts, but they also may undermine the extant access control model in some other contexts. We need to provide suitable explanations of when these concerns arise, so that folks are not surprised by the results. Streve From Nicolas.Williams at sun.com Tue Apr 4 11:05:36 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 4 Apr 2006 13:05:36 -0500 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: References: <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> <20060404145329.GA1434@binky.Central.Sun.COM> Message-ID: <20060404180536.GF2108@binky.Central.Sun.COM> On Tue, Apr 04, 2006 at 01:14:00PM -0400, Stephen Kent wrote: > Nico, > > >I *much* prefer the second method. > > no argument from me. Looks like we're in violent agreement. Implicit here is support for connection latching and some IPsec APIs (these are abstractly described in the connection latching I-D); if I'm reading you incorrectly let us know. > >You've just re-identified the problem: IPsec LoF requires IPsec-specific > >APIs to avoid dynamic address consumption (read: DoS attacks), and it > >requires application involvement. > > Most of the discussion here seems to entail application involvement, > so that does not seem like an issue, whether we're discussing APIs, > etc. What I tried to do was to note that because IPsec enforces > access control decisions based on IDs, LoF has different implications > here vs in security protocols that do not offer access control > functionality at all. More violent agreement. > >We just agreed that we don't want strong bindings between PUBLICKEY IDs > >and addresses; we also don't want to allow theft of packet flows at SA > >expiration/renewal time, and we don't want very long SA lifetimes to > >create stronger publickey/address bindings than we're willing to > >tolerate. Which, IMO, argues for connection latching. > > there are contexts in which bindings between PK IDs and addresses are > feasible and maybe even desirable, but those are not the most general > cases. I believe Joe's original BTNS use case is one such case, and I agree that it is not a general case. IMO in general LoF is best handled by applications. > >If you'll accept IPsec APIs at all then I think you'll find the second > >LoF method (see above) more appealing than the first. > > I understand your preference here. APIs may be fine in many contexts, > but they also may undermine the extant access control model in some > other contexts. We need to provide suitable explanations of when > these concerns arise, so that folks are not surprised by the results. Of course. I expect that the end result will tell implementors when BTNS is applicable and will specifically recommend use of BTNS with SPD entries that limits BTNS to protocols whose applications are expected to use channel bindings or LoF. Specific examples may involved NFSv4, SSHv2, TLS (provided all are modified to support channel binding/LoF). Also, BGP (Joe's use case :) Nico -- From mcr at sandelman.ottawa.on.ca Fri Apr 7 15:41:20 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 07 Apr 2006 15:41:20 -0700 Subject: [anonsec] BTNS and NAT-traversal 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> <20060321230332.GB1010@binky.Central.Sun.COM> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> So, I envisioned NFSv4 use of BTNS (w/ channel bindings) as a Nicolas> way to push session crypto down the stack for performance wins Nicolas> that I expect to be primarily useful in intranet environments. Critical there. Nicolas> HOWEVER, I can certainly see that running NFSv4 over Nicolas> TLS/SSHv2/whatever across NATs will be important, so I think Nicolas> this should stay in scope. The client has no problem doing the TLS/TCP talking to one server. The NAS has problems dealing with the multiple-thousands of sessions, and you get into TCP and SSL offload, and lots of pain because you try to do load balancing at the wrong point in the stack (where it stateful) rather than doing it where it is easy (where it is mostly stateless). Nicolas> I remember conversations about how HIP and BTNS were working on Nicolas> 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. Nicolas> Heh. I don't understand shim6 yet -- I haven't looked at it. Nicolas> It's entirely possible that for some uses of BTNS we are wasting Nicolas> our time. But for my original use case I think BTNS w/ Nicolas> connection latching and channel binding is the simplest solution Nicolas> to implement and deploy. I think that shim6-boot-strap-to-HIP still needs a bunch of things that we would want to do for BTNS. - -- ] 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) iQEVAwUBRDbqkoCLcPvd0N1lAQLvLwf/fp/C3MHmfAZeWHceRfMLgny4TAIU1Wcd 2mwDNk6Y3J0HmwGNcldKueznFWfL6/iWAFkn5fUlTPtE0CnlCxzXHupeILHbK0VW A8djSGXeEJojdkf643pIt/QDdW0v3GnZ5JY+y21+rYVRK5Hh9/LbsjJJPNJttIGf Q+LxFL0k3HPwzDD3FhRVPLSBq7/9CDvs2CxIgntOgumtMLp1zG8aD5u937zXFF5j mOFFh3GoZ/paZ0otJCJun4B1E8C0VuDb19MgK+nXtqHe3ERa5igpoOMFT1YxKy2h Vv6XbQmkPSPEqexKA3y6sWs9y03pnVpTFBhXpkbXSKwlZIlvSP2nDg== =T/A3 -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Sun Apr 9 09:45:06 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 09 Apr 2006 09:45:06 -0700 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: Message from =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= of "Wed, 22 Mar 2006 13:40:46 CST." <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> Message-ID: <12300.1144601106@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "strand" == strand writes: strand> There was a short discussion on how to proceed with the API strand> item from the charter. Sam Hartman with help from David strand> Black will present at next IETF. Michael Richardson promised strand> to look at the old API requirements document that he and strand> Bill Sommerfeld made for IPSP. The document has been formatted again, and it is at: http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq-00.txt If this is judged in scope for BTNS, then I'll ask the ID editor to publish with that name. If there is still doubt, I'll post under my name. strand> * Require support of bare keys, and add self-signed strand> certificates as a SHOULD. * The IKE extentions will be strand> folded into the core document and Michael Richardson help strand> Nicolas with document as a co editor. What I think that we need is usage scenarios. I'm trying to write this up now. strand> Updated milestones ================== Nov06 WG LC on IPsec interfaces draft Nov06 Submit IPsec interfaces draft to the IESG I think that this is achievable, but I guess we have to have a document to discuss well in advance of July. - -- ] 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 iQEVAwUBRDk6DoCLcPvd0N1lAQJO0ggAl3Jia52iLtdxwoGjsw6phj288nxJw+As vTpmWcWjN4ipLdMvYd3UiDh/KeLwD2sSg0O4K73SJ1J0d2gH4qydTOmQHS96Mh4a VviCZqxQRnOo/4v3yqCpmQnsAx7FMK4/wbFPhwP7u7u/c+inx+NmLllTdnFrIal6 xD47sx5RitqhI4KIW6d72tTPZBCjnpAiK2D1pav+c+wSI48pT0WiFSMAeuJOAkUd AjA+aINJN1mmT2kp6n4K+7M2jNiTU5Z5rU67Nc918/5IratkyE4nUEAWrbBW8rkH h5/qdvzdJ50DPvmakHIjW/s+xqEeQJ8t+r8D5bqjRJYi8Ygb0eJbTw== =cpKV -----END PGP SIGNATURE----- From pekka.nikander at nomadiclab.com Mon Apr 10 03:04:30 2006 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Mon, 10 Apr 2006 13:04:30 +0300 Subject: [anonsec] PAS issue 14 - leap of faith In-Reply-To: References: <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> <20060404145329.GA1434@binky.Central.Sun.COM> Message-ID: Steve and Nico, >>> In the IPsec context, this translates into creating a PAD entry >>> based >>> on a unauthenticated IKE exchange. >> >> This is the first one of two methods we've considered so far. >> >> The second method involves connection latching and pushes the >> responsibility for LoF to the application. > > in that case, IPsec is not providing LoF support per se, as the > responsibility is assumed by the application. > >> I *much* prefer the second method. > > no argument from me. That makes perfect sense to me. In any case, the context (i.e. the PUBLICKEY) should be bound to the app that is using it, lest you find yourself with very interesting phishy dragons where an attacker creates a LoF binding in one context (e.g. online game) and then lures the user to use it in another context (e.g. banking). That taking place, the second context (banking) appears secure to the user. I am to see the user interface that would make the dangers involved clear to the average user. Note that with SSH this has not really been a problem, since SSH port forwarding has mostly been used only by knowledgeable people and with their consent. > there are contexts in which bindings between PK IDs and addresses are > feasible and maybe even desirable, but those are not the most general > cases. I agree. We just need to understand that such context are characterised by someone being "responsible" for the IP address ranger under consideration, and that the same (or strongly related) party is responsible for creating the bindings between the PK IDs and the addresses. The problem we are facing here is that not even a single body is responsible for assigning the addresses here, making it impossible to manage the bindings in any sensible terms. >> If you'll accept IPsec APIs at all then I think you'll find the >> second >> LoF method (see above) more appealing than the first. > > I understand your preference here. APIs may be fine in many contexts, > but they also may undermine the extant access control model in some > other contexts. We need to provide suitable explanations of when > these concerns arise, so that folks are not surprised by the results. I agree. It is in interesting mental exercise to consider the HIP ACL model here; in HIP the inner IP addresses are replaced by references to the public keys, at the socket API, in apps, and in apps protocols, --Pekka From pekka.nikander at nomadiclab.com Mon Apr 10 03:24:22 2006 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Mon, 10 Apr 2006 13:24:22 +0300 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <12300.1144601106@sandelman.ottawa.on.ca> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> Message-ID: <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, Thanks for working on this! It is great to see this go forward. Personally, I would be happy to accept this as a WG document. It seems like a good starting point for fulfilling our goal e), Develop an informational document describing the interfaces that IPsec implementations should provide to allow IPsec SAs to be used to secure higher layer protocols. A few points: - - It would be nice if the lists were formatted with bullets; they are now a little bit hard to read. - - When considering motivations (Section 3), the following paper of ours may be worth reading: Jari Arkko, and Pekka Nikander, "Limitations of IPsec Policy Mechanisms," to appear in Security Protocols, Eleventh International Workshop, Cambridge, UK, April 2-4, 2003., http://www.tml.tkk.fi/~pnr/ publications/cam2003.pdf - - In Section 5, I would like to see some more discussion of what are the problems of determining "WHO", or identity of the peer... Yes, it will be discussed in Section 8, but once the document is fleshed out a little bit, there may be some distance between Sections 5 and 8. - - I think I agree with your mission in 8.4, but also that it is out- of-scope of our current WG work. Nothing the mission (perhaps even in Section 3) and providing hooks for it, is IMHO very good, though. - - In 11.1, if you are using public keys as identities, the app should have some access to them. IIRC, Miika Komu struggled a little bit with that problem when he considered HIP native API issues. - --Pekka On Apr 9, 2006, at 19:45, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "strand" == strand writes: > strand> There was a short discussion on how to proceed with the > API > strand> item from the charter. Sam Hartman with help from David > strand> Black will present at next IETF. Michael Richardson > promised > strand> to look at the old API requirements document that he and > strand> Bill Sommerfeld made for IPSP. > > The document has been formatted again, and it is at: > > http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec- > apireq-00.txt > > If this is judged in scope for BTNS, then I'll ask the ID editor to > publish with that name. If there is still doubt, I'll post under > my name. > > strand> * Require support of bare keys, and add self-signed > strand> certificates as a SHOULD. * The IKE extentions will be > strand> folded into the core document and Michael Richardson help > strand> Nicolas with document as a co editor. > > What I think that we need is usage scenarios. > I'm trying to write this up now. > > strand> Updated milestones ================== > > Nov06 WG LC on IPsec interfaces draft > Nov06 Submit IPsec interfaces draft to the IESG > > I think that this is achievable, but I guess we have to have a > document to discuss well in advance of July. > > - -- > ] 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 > > iQEVAwUBRDk6DoCLcPvd0N1lAQJO0ggAl3Jia52iLtdxwoGjsw6phj288nxJw+As > vTpmWcWjN4ipLdMvYd3UiDh/KeLwD2sSg0O4K73SJ1J0d2gH4qydTOmQHS96Mh4a > VviCZqxQRnOo/4v3yqCpmQnsAx7FMK4/wbFPhwP7u7u/c+inx+NmLllTdnFrIal6 > xD47sx5RitqhI4KIW6d72tTPZBCjnpAiK2D1pav+c+wSI48pT0WiFSMAeuJOAkUd > AjA+aINJN1mmT2kp6n4K+7M2jNiTU5Z5rU67Nc918/5IratkyE4nUEAWrbBW8rkH > h5/qdvzdJ50DPvmakHIjW/s+xqEeQJ8t+r8D5bqjRJYi8Ygb0eJbTw== > =cpKV > -----END PGP SIGNATURE----- > _______________________________________________ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEOjJXwjLbdpYTu2YRAmUHAJsGBdA071Ef9EVMqh/1cGV7U27XYACfSz3r 6CfW+PdGyXsb66UrJcj08mM= =nly2 -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Mon Apr 10 09:19:49 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 10 Apr 2006 09:19:49 -0700 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: Message from Pekka Nikander of "Mon, 10 Apr 2006 13:24:22 +0300." <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> Message-ID: <12885.1144685989@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Pekka" == Pekka Nikander writes: Pekka> A few points: Pekka> - - It would be nice if the lists were formatted with Pekka> bullets; they are now a little bit hard to read. Sure. I haven't edited the document in 3 years... I'm going to ask have this version published, and then reflect your views into the -01. Pekka> - - When considering motivations (Section 3), the following Pekka> paper of ours may be worth reading: Pekka> Jari Arkko, and Pekka Nikander, "Limitations of IPsec Pekka> Policy Mechanisms," to appear in Security Protocols, Eleventh Pekka> International Workshop, Cambridge, UK, April 2-4, 2003., Pekka> http://www.tml.tkk.fi/~pnr/ publications/cam2003.pdf added. Pekka> - - In Section 5, I would like to see some more discussion of Pekka> what are the problems of determining "WHO", or identity of Pekka> the peer... Yes, it will be discussed in Section 8, but once Pekka> the document is fleshed out a little bit, there may be some Pekka> distance between Sections 5 and 8. okay. Pekka> - - I think I agree with your mission in 8.4, but also that Pekka> it is out- of-scope of our current WG work. Nothing the Pekka> mission (perhaps even in Section 3) and providing hooks for Pekka> it, is IMHO very good, though. Pekka> - - In 11.1, if you are using public keys as identities, the Pekka> app should have some access to them. IIRC, Miika Komu Pekka> struggled a little bit with that problem when he considered Pekka> HIP native API issues. Yes, I agree. - -- ] 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 iQEVAwUBRDqFpICLcPvd0N1lAQJ09QgAhMhuz+9YubjN+ZZr2O6z1p/ARSGjrPhu BbL0wTgYbrAtaPiof7gT9cZqVpUe+JuKZUVY9YZ+3x6+086uG35dfWFNXv8iwxvf q1tMiTcbJL6vrbkQXQ9p+RivMGzYdXZY8Fjyx2M/pAmJ8XquA/ppSM9mBKMFAqdT jT2TZEOlx1E2GyvUMl+n5UDW9fft0zAAXpoUE+jc5DNm6Q+9bcH5uMkoUfMC5m4P vFtl+51nHFJvnNN8cVdFwy0F/Z5Se9BnzaabaLJnpSRPPZrBoa4gbVBVHlAxdBZ3 Q1hGTNt8mawY0Errm6SQkVRMpC2I8sHOVpqGBDzQAcReqLz1gTYIDg== =aK1J -----END PGP SIGNATURE----- From miika at iki.fi Tue Apr 11 09:05:35 2006 From: miika at iki.fi (Miika Komu) Date: Tue, 11 Apr 2006 19:05:35 +0300 (EEST) Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <12885.1144685989@sandelman.ottawa.on.ca> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> <12885.1144685989@sandelman.ottawa.on.ca> Message-ID: On Mon, 10 Apr 2006, Michael Richardson wrote: Hi folks, > Pekka> - - In 11.1, if you are using public keys as identities, the > Pekka> app should have some access to them. IIRC, Miika Komu > Pekka> struggled a little bit with that problem when he considered > Pekka> HIP native API issues. > > Yes, I agree. Some background documents: Shorter version: http://www.niksula.cs.hut.fi/~mkomu/docs/f17-komu.pdf Medium-length IETF draft formatted version: http://www.ietf.org/internet-drafts/draft-mkomu-hip-native-api-00.txt Longer version with requirements (and bunch of other things): http://gaijin.iki.fi/hipl/hip-native-api-final.pdf I'd like to align our HIP related work with the work of other WGs and vice versa. The native APIs for HIP were accepted as official WG item at the last IETF, so we are looking for feedback for the native APIs and I'd also like to give feedback for other drafts. If I understood correctly, it seems like shim6 guys are interested in the interactions between applications, locators, referrals, resolver and shim module. We have touched those topics in the native HIP API work, but there is still a bunch of things to be done. Based on the "IPsec API requirements" draft, seems like the BTNS folks are interested in allowing the applications to discover and influence the security properties of the applications. This topic has been also touched in the native HIP API, but there is still a lot to be done also here. If there is interest in joint effort regarding APIs, maybe we should set up a separate mailing list for discussing the core API issues? I think cross-posting to several mailing lists is not very nice. As an alternative, we could ask if the apps area mailing could be used also. -- Miika Komu miika at iki.fi http://www.iki.fi/miika/ From hartmans-ietf at mit.edu Tue Apr 11 09:32:06 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 11 Apr 2006 12:32:06 -0400 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: (Miika Komu's message of "Tue, 11 Apr 2006 19:05:35 +0300 (EEST)") References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> <12885.1144685989@sandelman.ottawa.on.ca> Message-ID: I think coordinating these efforts is good provided that the coordination does not block any effort. Also, note that the BTNS charter is much narrower than HIP. From mcr at sandelman.ottawa.on.ca Tue Apr 11 10:58:24 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 11 Apr 2006 10:58:24 -0700 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: Message from Miika Komu of "Tue, 11 Apr 2006 19:05:35 +0300." References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> <12885.1144685989@sandelman.ottawa.on.ca> Message-ID: <19837.1144778304@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Miika" == Miika Komu writes: Miika> If there is interest in joint effort regarding APIs, maybe we Miika> should set up a separate mailing list for discussing the core Miika> API issues? I think cross-posting to several mailing lists is Miika> not very nice. As an alternative, we could ask if the apps Miika> area mailing could be used also. Yes, I want a joint effort. I leave it to the chairs/ADs to decide what mailing list to use, and more particularly, what WG to live in. Please make sure that there is a gmane.org group for the mailing list. - -- ] 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 iQEVAwUBRDvuP4CLcPvd0N1lAQJltwf/UBx4DjZfCrFYb44jNzBbUHDUUzqLZYgT rF7nfMf0CU3YaXT++vG1FmMPC6WAZJnsf50N68bGJT/jTBaYh79l0B6tmRI1PQh9 pIkJ9DLUo3NOMYtLt2VqyrQtjitNtmHt+p9Ow8yRocELwQ0qjTeD0N4krqeF/Gi0 9MslbmB8dxZylnr79dij6/wYZJ4wHq6P9RotrZuX/V2KqylLS+f7VM+d3CQkrfPe CAPwNDNoW/lvSYcFyDHUfAMoV2yCS6s6zRRV76NXUjspug7ZpPqBNpt4CgKA7Bdl o4cubnz9Nxx6VgCveM4Y19iY6rOylvjU9OmgaGbFkX53sbZJZ9dSYQ== =9s7K -----END PGP SIGNATURE----- From touch at ISI.EDU Wed Apr 12 10:19:13 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Apr 2006 10:19:13 -0700 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <12300.1144601106@sandelman.ottawa.on.ca> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> Message-ID: <443D3691.7090903@isi.edu> IDs need to be published as individual submissions first in order to be accepted as WG docs. Then the *WG* decides whether it becomes a WG doc. Once it's submitted, let me know and I'll post it on the website too. Joe Michael Richardson wrote: > >>>>>>> "strand" == strand writes: > strand> There was a short discussion on how to proceed with the API > strand> item from the charter. Sam Hartman with help from David > strand> Black will present at next IETF. Michael Richardson promised > strand> to look at the old API requirements document that he and > strand> Bill Sommerfeld made for IPSP. > > The document has been formatted again, and it is at: > > http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq-00.txt > > If this is judged in scope for BTNS, then I'll ask the ID editor to > publish with that name. If there is still doubt, I'll post under my name. > > strand> * Require support of bare keys, and add self-signed > strand> certificates as a SHOULD. * The IKE extentions will be > strand> folded into the core document and Michael Richardson help > strand> Nicolas with document as a co editor. > > What I think that we need is usage scenarios. > I'm trying to write this up now. > > strand> Updated milestones ================== > > Nov06 WG LC on IPsec interfaces draft > Nov06 Submit IPsec interfaces draft to the IESG > > I think that this is achievable, but I guess we have to have a > document to discuss well in advance of July. > _______________________________________________ From Nicolas.Williams at sun.com Wed Apr 12 10:41:15 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 12 Apr 2006 12:41:15 -0500 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <443D3691.7090903@isi.edu> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <443D3691.7090903@isi.edu> Message-ID: <20060412174114.GF20059@binky.Central.Sun.COM> On Wed, Apr 12, 2006 at 10:19:13AM -0700, Joe Touch wrote: > IDs need to be published as individual submissions first in order to be > accepted as WG docs. Then the *WG* decides whether it becomes a WG doc. > > Once it's submitted, let me know and I'll post it on the website too. I don't think so. From hartmans-ietf at mit.edu Wed Apr 12 11:19:28 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 12 Apr 2006 14:19:28 -0400 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <443D3691.7090903@isi.edu> (Joe Touch's message of "Wed, 12 Apr 2006 10:19:13 -0700") References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <443D3691.7090903@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> IDs need to be published as individual submissions first in Joe> order to be accepted as WG docs. Then the *WG* decides Joe> whether it becomes a WG doc. Joe, it is not actually a requirement that drafts need to be individual submissions first. The WG can choose to adopt a work item based only on a description of that work item. It is not uncommon for WGs to decide they will only adopt work items after looking at an individual draft. That is a valid policy for a WG to adopt, but it is not a requirement of RFC 2418 or 2026. From touch at ISI.EDU Wed Apr 12 11:15:34 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Apr 2006 11:15:34 -0700 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <20060412174114.GF20059@binky.Central.Sun.COM> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <443D3691.7090903@isi.edu> <20060412174114.GF20059@binky.Central.Sun.COM> Message-ID: <443D43C6.3010906@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Wed, Apr 12, 2006 at 10:19:13AM -0700, Joe Touch wrote: >> IDs need to be published as individual submissions first in order to be >> accepted as WG docs. Then the *WG* decides whether it becomes a WG doc. >> >> Once it's submitted, let me know and I'll post it on the website too. > > I don't think so. To what part? That the WG decides what becomes a WG doc? Or that the WG can't possibly decide this unless it's publicly available; that's the point of publishing it as individual. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPUPGE5f5cImnZrsRAvTmAKDh7uTyfg1F3HF/RbQA51+/Y7no4wCeLRDa HeOPk0d0bSX5NogzqiE/D/M= =Qfzy -----END PGP SIGNATURE----- From touch at ISI.EDU Wed Apr 12 11:28:18 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Apr 2006 11:28:18 -0700 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <443D3691.7090903@isi.edu> Message-ID: <443D46C2.6020004@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: >>>>>> "Joe" == Joe Touch writes: > > Joe> IDs need to be published as individual submissions first in > Joe> order to be accepted as WG docs. Then the *WG* decides > Joe> whether it becomes a WG doc. > > Joe, it is not actually a requirement that drafts need to be > individual submissions first. The WG can choose to adopt a work item > based only on a description of that work item. The WG adopted this as a work item (it's in the charter). That item was not based on this version of the doc; it's fair to let the WG decide how to proceed. > It is not uncommon for WGs to decide they will only adopt work items > after looking at an individual draft. That is a valid policy for a WG > to adopt, but it is not a requirement of RFC 2418 or 2026. That's been the case with the WG thus far. Is there a reason to vary from that procedure here? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPUbCE5f5cImnZrsRAquBAJ9cCva82E4oMwPftjJSPCqDgACRpgCfV/Zs D2BF2I6AblJcctI5/yDlmZw= =p8E+ -----END PGP SIGNATURE----- From shinta at sfc.wide.ad.jp Thu Apr 13 04:52:26 2006 From: shinta at sfc.wide.ad.jp (Shinta Sugimoto) Date: Thu, 13 Apr 2006 14:52:26 +0300 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <12885.1144685989@sandelman.ottawa.on.ca> Message-ID: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> Hi Miika, On Tue, 11 Apr 2006 19:05:35 +0300 (EEST) Miika Komu wrote: > On Mon, 10 Apr 2006, Michael Richardson wrote: > [snip] > I'd like to align our HIP related work with the work of other WGs and vice > versa. The native APIs for HIP were accepted as official WG item at the > last IETF, so we are looking for feedback for the native APIs and I'd also > like to give feedback for other drafts. > > If I understood correctly, it seems like shim6 guys are interested in the > interactions between applications, locators, referrals, resolver and shim > module. We have touched those topics in the native HIP API work, but > there is still a bunch of things to be done. Yes, now I am sorting out what kind of API is needed for SHIM6. In SHIM6, the issues are mainly how app can easily/efficiently deal with locators, and interaction between SHIM6 module and ULP (especially TCP) should also be defined. But certainly there is a relation to other API works (including the work done in HIP). > Based on the "IPsec API requirements" draft, seems like the BTNS folks are > interested in allowing the applications to discover and influence the > security properties of the applications. This topic has been also touched > in the native HIP API, but there is still a lot to be done also here. > > If there is interest in joint effort regarding APIs, maybe we should set > up a separate mailing list for discussing the core API issues? I think > cross-posting to several mailing lists is not very nice. As an > alternative, we could ask if the apps area mailing could be used also. Sounds good. I am happy to join the collaboration. Regards, Shinta From Internet-Drafts at ietf.org Fri Apr 14 12:50:01 2006 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri, 14 Apr 2006 15:50:01 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-ipsec-apireq-00.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-ipsec-apireq-00.txt -------------- next part -------------- From yaronf at checkpoint.com Sun Apr 16 08:33:02 2006 From: yaronf at checkpoint.com (Yaron Sheffer) Date: Sun, 16 Apr 2006 18:33:02 +0300 Subject: [anonsec] btns-ipsec-apireq.txt Message-ID: <002801c6616b$0cf6e5a0$5d2e1dc2@ad.checkpoint.com> One nit and one question: 1. In the Terminology section, should be: it does *not* imply any specific API... 2. The "WHO" section is missing the most obvious identity information, which is the IKE ID payloads (or SubjectAltName attributes) when these are available, i.e. in the non-anonymous case. Is this omission intentional? Thanks, Yaron From lha at it.su.se Mon Apr 17 13:35:02 2006 From: lha at it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Mon, 17 Apr 2006 22:35:02 +0200 Subject: [anonsec] IETF65 meeting minutes Message-ID: <861481FD-1E49-412F-AA70-1D17E3A8A265@it.su.se> Hejsan, The afternoon I published the meeting minutes on the IETF web-page. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 If you have any comments, please mail me before Thursday. With this mail, I also want to confirm the decisions made during the meeting. * Decisions made * Require support of bare keys, and add self-signed certificates as a SHOULD. * The IKE extensions will be folded into the core document and Michael Richardson help Nicolas with document as a co-editor. * Michael Richardson will do work on the API document. Love -------------- 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/20060417/885966d6/PGP.bin From miika at iki.fi Mon Apr 17 12:41:27 2006 From: miika at iki.fi (Miika Komu) Date: Mon, 17 Apr 2006 22:41:27 +0300 (EEST) Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <4443E62F.5080109@sun.com> References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> <12885.1144685989@sandelman.ottawa.on.ca> <4443E62F.5080109@sun.com> Message-ID: On Mon, 17 Apr 2006, Erik Nordmark wrote: > Miika Komu wrote: > > > Some background documents: > > > > Shorter version: > > > > http://www.niksula.cs.hut.fi/~mkomu/docs/f17-komu.pdf > > > > Medium-length IETF draft formatted version: > > > > http://www.ietf.org/internet-drafts/draft-mkomu-hip-native-api-00.txt > > > > Longer version with requirements (and bunch of other things): > > > > http://gaijin.iki.fi/hipl/hip-native-api-final.pdf > > Interesting. > > I'm trying to understand why and where you have an ED (endpoint > designator) instead of a HIT. > Is this only needed to support opportunistic mode? This is one use case. Some other possible use cases are: * Future compatiblity with larger HITs in the future * Future compatibility with process/session layer migration schemes * Makes developer's life with application defined HIs slightly easier > (I'd personally do opportunistic mode as a HIT discovery exchange before > telling TCP/UDP to setup state based on a HIT.) If you do this in the resolver, you might be creating some unwanted connections. > What is the uniqueness requirements for the ED? Is it just a locally > allocated number that a host could start assinging at 1 for the remote > hosts it talks to? Currently yes. It could be unique only in the process context, depending on the implementation. It would be possible extend the ED context slightly if there were (HIP) extensions for negotiating this. This way, an ED could be shared with a peer and we would have SCTP likish stream identifiers. I have been actually thinking of adding this idea to the API draft (but this may be the wrong discussion forum that). > Is a TCP connection identifier by a pair of ports and a pair of EDs, or > a pair of ports + HITs? Currently, an ED is only a local alias for HIT, so TCP is identified using ports and HITs. However, this could be extended as a described above. > How does the application associate state for remote peers if the EDs are > all it has, and the EDs are locally allocated? For instance, the > application could communicate with ED=7 to host A and host B could also > have picked ED=7. Is it a requirement that the applications associate > all their state for remote hosts with the HI? > > (And if TCP operates on EDs, the previous question applies to TCP as well.) If we would have some extensions for negotiating for randomly picked EDs, I guess this would work. > Thus if EDs only need to be introduced for opportunistic mode, I think > it is a lot simpler to handle opportunistic mode in a different place in > the layering, instead of inventing an ED namespace with all associated > issues. See my resolver comment above. Alternatively, you could handle the opportunistic mode with the socket handler implementation, but even in that case the application gets (incorrectly?) an IP which may be problematic with (HIP) mobility and multihoming. -- Miika Komu miika at iki.fi http://www.iki.fi/miika/ From mcr at sandelman.ottawa.on.ca Fri Apr 21 12:43:00 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 21 Apr 2006 15:43:00 -0400 Subject: [anonsec] PAS issue 14 - leap of faith References: <4422D720.8010508@isi.edu> <442322F0.60601@isi.edu> <20060323225745.GG1010@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/20060421/6e6336de/attachment.bin From mcr at sandelman.ottawa.on.ca Fri Apr 21 12:48:12 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 21 Apr 2006 15:48:12 -0400 Subject: [anonsec] PAS issue 14 - leap of faith 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: 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/20060421/9648dd67/attachment.bin From mcr at sandelman.ottawa.on.ca Fri Apr 21 12:56:09 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Fri, 21 Apr 2006 15:56:09 -0400 Subject: [anonsec] btns-ipsec-apireq.txt References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> <12885.1144685989@sandelman.ottawa.on.ca> 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/20060421/65a8f2b6/attachment.bin From mcr at sandelman.ottawa.on.ca Sat Apr 22 07:06:17 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 22 Apr 2006 10:06:17 -0400 Subject: [anonsec] btns-ipsec-apireq.txt References: <002801c6616b$0cf6e5a0$5d2e1dc2@ad.checkpoint.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Yaron" == Yaron Sheffer writes: Yaron> One nit and one question: 1. In the Terminology section, should Yaron> be: it does *not* imply any specific API... Thanks. Yaron> 2. The "WHO" section is missing the most obvious identity Yaron> information, which is the IKE ID payloads (or SubjectAltName Yaron> attributes) when these are available, i.e. in the non-anonymous Yaron> case. Is this omission intentional? Yes. I specifically do not want to teach application how to parse DNs, FQDNs, Kerberos principles, etc. Also note that in the first revision of the requirements, we are focused on the responding system, not the initiating system. We wanted the identifiers to have an opaque format that could be trivially compared. (In the API that envision, these would actually be pointers, which would equal() whenever they are eq(), but one would still need to use the proper IsIdentifyEqual() function) For auditing purposes, there should be a way to get a string from the opaque identifier. By making it unidirectional, we do not require that the mapping be reversable. So, if you have a nice human readable, printable form of the DN, you can display that. It might be perfect for the input side. For the case of certificates, if one takes a page from the HIP API, then the application doesn't really care/know --- it just loads a file that the user provided. I notice that I'm now on multimobsec-api at ietf.org, and I want to know if I should be CC'ing that list as well. Does this indicate that Sam thinks that perhaps this work should be in a new WG? ( https://www1.ietf.org/mailman/listinfo/multimobsec-api for those that didn't get subscribed ) - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBREo4W4CLcPvd0N1lAQIuzQf+OA45ZJrocvNRUoy63hS4Ez0D47YYALgZ UizTlF86xUFVjXZdkxlGjCHQhrljWH4LKQXb7/ZjO5yvgBjJxLrurSZdHs0mJ5uv da+bxT6H/uA3ZG39xSc++FaLw8cb1gr0W1UtSLp0LvMdQ6Cf/uqdVr63MDVsyTmV 6FydwBn/DRs+c8l/zNu6EKMeLjfJsl9FsCEdJKvapOw5qBkAsh7P8nISiMrghqvS 6e/IwJtDs0kCiOvAeXDAUEv+imEDBO+iUrSbB0xIc+kZKRTop0ddtARE6y27vGP0 JiDDe07ebMsGM9mabXklZCosDEteZnID68XhCpFphdspHUHKprr5bw== =88K4 -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Sat Apr 22 14:44:49 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Sat, 22 Apr 2006 17:44:49 -0400 Subject: [anonsec] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity Message-ID: Hi, folks. I'd like to describe some work that is proposed in the softwires working group. First though I'd like to review what we're trying to accomplish with security for Internet protocols and review how IPsec is being used in protocols over in the Internet area. Then I hope you'll join me in understanding that this work in softwires is a critical part of what we need to do in order to meet our goal of creating a usable security solution for overlay network protocols being developed in the Internet area. I hope you'll help make sure this work is a success. When we try and design security for a protocol, we start with a threat model and attempt to come up with a protocol design that provides security services adequate to address threats identified in the threat model. One of the key aspects of the success of this work is the deployability and usability of the security solutions. If the security solution is harder to configure than the rest of the protocol, then we have room for improvement. If the security solution has fundamentally different configuration scaling characteristics, then we have failed. As an example, consider a protocol intended to provide automated discovery. We cannot claim success if we only provide manually configured security for that protocol. Similarly we cannot claim success if the discovery mechanisms do not provide discovery for appropriate security parameters. Similarly, if we are designing security for a protocol where two parties who have no previous association will interact, we generally cannot assume any shared infrastructure or configuration for the security. We probably need to provide a mode of security that protects against passive attacks without infrastructure and/or a mode of security that depends on a PKI for protection against passive and active attacks. We have significant work to do in order to meet these goals of usability for some Internet Area protocols. Let me describe where things stand. The L3VPN working group was established to describe protocols for carrying customer IP traffic over a provider provisioned virtual private network. One use case is a customer who has multiple locations. The customer wishes to connect these locations together. The customer could get leased lines to each location, but instead hires the provider to provision an IP network . The provider wants to carry the customer traffic over the provider's existing network. However because everyone is using net 10 and for other reasons of isolation, the provider needs to tag the customer's packets with information about what addressing domain (which customer network) they belong to. For the networks under discussion MPLS is used. The L2VPN working group is doing similar things except they care about use cases where the provider wants to carry customer L2 packets over the provider's network. Similarly, the softwires working group supports a topology where you have a mesh of IPV6 tunnels over an IPV4 network or a mesh of IPV4 tunnels over an IPV6 network. The goal is to support cases where the core of a network is running a different version of IP than other parts. So, how do we provide confidentiality and integrity in these cases? We've decided that IPsec is the appropriate tool. RFC 4023 describes one of the basic encapsulations that would be used in these situations if you want to provide confidentiality or integrity. (Native MPLS over L2 does not typically support confidentiality or integrity) RFC 3931 describes L2TP V3, which provides another encapsulation that is useful in this space. Again, we have chosen IPsec as the confidentiality/integrity strategy. I know there are those here who believe that IPsec is the wrong strategy for application security. For these protocols, that ship has sailed: we have approved proposed standards that use IPsec. This predates my involvement in the IESG. Now we must provide usable security based on these existing decisions. Both RFC 4023 and 3931 provide reasonable security for the rest of the spec. IN particular, these specs provide for statically configured tunnels and provide for statically configured security. If you are specifying all the tunnel configuration by hand, it seems reasonable to specify the security configuration. I suspect the implementations are not all that usable: I suspect that you have to go to different parts of the configuration to set up the IPsec from the rest of the tunnel; I suspect that in practice there is no way to specify the tunnel endpoint once and have it apply both to the security configuration and the tunnel configuration. That's a problem but not a protocol problem. However all of these groups propose to provide automatic discovery of tunnels. For example RFC 4364 specifies a mechanism where BGP is used to discover and configure all the tunnels in an MPLS L3VPN. We need a security solution that is as easy to use as RFC 4364 in order to set up confidentiality and integrity for RFC 4364. The security requirements we're trying to deal with are outlined in RFC 4031 and its references. Roughly we're trying to provide confidentiality and integrity protection of the customer traffic. One controversial assumption I'm making here is that we can rely on the integrity of the signaling/discovery mechanism to give us integrity and confidentiality for the data plane. If the discovery were between the same two parties as the data traffic this would not be very controversial. However the discovery is carried over BGP. That means that the parties in the discovery may be different than the parties in the data plane exchange. Note that we've decided in the case of SIP, SDP and RTP that this model where hop-by-hop proxies are used to set up end-to-end confidentiality/integrity is OK. Without relying on the integrity of BGP, we'd have to require a PKI or preshared keys. A PKI is a non-starter for the deployment community--this is one of those layer 9 concerns that do establish requirements for engineering. The real problem with relying on BGP integrity is that it's kind of weak. The best case today is TCPMD5 and the worst case today is none. So, let's consider what we can get if we rely on BGP integrity and it happens not to be there. Well we can still get protection against passive attacks. So long as the attacker does not actually modify the BGP session, then we can negotiate end-to-end SAs authenticated with the right parties. If our BGP does happen to be integrity protected we get full protection against active attacks. If we do happen to have a PKI, our implementation supports using that and we have it configured, we end up getting optimal protection even if BGP is not properly integrity protected. My personal feeling is that deploying easy-to-use security that provides protection only against passive attacks is better than no security. Since the solution we're proposing does better than that I think it is a reasonable approach. Another thing to note about depending on BGP integrity. BGP will end up having to be used to configure whether a particular association is expected to have IPsec. As such anyone who can modify the BGP routes can disable security. So, what is the proposed solution? First, note that we are targeting the IPsec architecture described in RFC 2401. After discussing draft-bellovin-use-ipsec and my experiences with the OSPF V3 authentication draft, Russ and I have decided that we cannot ask people to use RFC 4301 to secure higher-layer protocols at this time. There aren't enough implementations and we really need guidance similar to draft-bellovin-use-ipsec targeted at 4301 before we could do that. People who are interested in seeing us move to 4301 should work on implementations and should work on BCPs and informational documents designed to make it easier to use in these situations. Russ and I both think that RFC 4301 is a significant improvement over RFC 2401. The idea is to include information in BGP routes used to set up the tunnels sufficient to let peers know that they want to use IPsec, know which identity to authenticate to and what IPsec parameters to use. Peers should already know what SPD entries to create because they should be able to identify what ports/protocols their tunnel traffic will use in order to establish that tunnel traffic. In practice this means that BGP would probably distribute a fingerprint of a certificate along with some very short identifier indicating any additional configuration information that is needed. The work on what to carry in BGP will be accompanied by a profile of IPsec which requires (probably by reference to the IPsec algorithms documents) appropriate mandatory algorithms and which specifies how to configure the SPD for this application. The work will take place in the softwires working group. They could of course use any IPsec help we are able to provide. Now is your chance to scream about the general approach. If you disagree, please explain how we can meet the requirements outlined in RFC 4031 and provide usable security solutions while still fixing the parts you disagree with. Thanks, --Sam From mcr at sandelman.ottawa.on.ca Sat Apr 22 16:08:13 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 22 Apr 2006 19:08:13 -0400 Subject: [anonsec] btns-ipsec-apireq.txt References: <12885.1144685989@sandelman.ottawa.on.ca> <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> 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/20060422/632caaa0/attachment.bin From mcr at sandelman.ottawa.on.ca Sat Apr 22 16:28:37 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 22 Apr 2006 19:28:37 -0400 Subject: [anonsec] btns-ipsec-apireq.txt References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> <12885.1144685989@sandelman.ottawa.on.ca> <4443E62F.5080109@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/20060422/b20a69af/attachment.bin From mcr at sandelman.ottawa.on.ca Sat Apr 22 16:40:27 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 22 Apr 2006 19:40:27 -0400 Subject: [anonsec] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity References: 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/20060422/8bdc3acf/attachment.bin From hartmans-ietf at mit.edu Sat Apr 22 23:27:18 2006 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Sun, 23 Apr 2006 02:27:18 -0400 Subject: [anonsec] [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity In-Reply-To: (Michael Richardson's message of "Sat, 22 Apr 2006 19:40:27 -0400") References: Message-ID: >>>>> "Michael" == Michael Richardson writes: >>>>> "Sam" == Sam Hartman writes: Sam> First, note that we are targeting the IPsec architecture Sam> described in RFC 2401. After discussing Sam> draft-bellovin-use-ipsec and my experiences with the OSPF V3 Sam> authentication draft, Russ and I have decided that we cannot Sam> ask people to use RFC 4301 to secure higher-layer protocols Sam> at this time. There aren't enough Michael> To confirm: you telling people to say "RFC2401" rather Michael> than "RFC4301" (Alternative which you are not saying is Michael> "do not use IPsec") We're saying 2401 today; we'd love to get to 4301 as soon as we can. "no security," is a non-option. "Don't use IPsec" is an option in cases where we've already decided to use IPsec. Sam> The idea is to include information in BGP routes used to set Sam> up the tunnels sufficient to let peers know that they want to Sam> use IPsec, know which identity to authenticate to and what Sam> IPsec parameters to use. Peers should already know what SPD Sam> entries to create because Michael> I question the need for all of these parameters in BGP. Michael> I haven't read the documents yet, but all *I* need to Michael> know if the public key (not certificate) (RSA preferred Michael> as I don't support DSA), and the end-point. The Michael> cryptographic algorithms are negotiable in IKE. If we Michael> don't have a common set, saying so in BGP won't help. Michael> The ID: it's the IP of the end-point. Valid points. I think it is important to support certs; I don't much care whether we support public keys or not, or what we hash in BGP. You're right; we only need to negotiate parameters in BGP that will not be negotiated by IKE and for which negotiation is useful. Michael> PS: I'm curious Sam: are cleartext or MIME signatures Michael> easier for your text-to-speech to deal with? Both are fine, but mime work better with my mail reader. From yaronf at checkpoint.com Sun Apr 23 09:48:21 2006 From: yaronf at checkpoint.com (Yaron Sheffer) Date: Sun, 23 Apr 2006 19:48:21 +0300 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: Message-ID: <004d01c666f5$bb0670e0$132e1dc2@ad.checkpoint.com> Hi Michael, I understand your reasoning, and the complexity of adding identity into the API. OTOH, "identity binding" is an often required feature. Let me give an example, and please point out where I am getting it wrong: the "responding system" is a RADIUS server, and it wants to perform access control on its clients based on something stronger and easier to manage than the authenticator value. The server might want to compare the alleged NAS-IP-Address (or NAS-Identifier) to the authenticated identity. If we provide standard mapping for the common identity types (IP address and FQDN), this would be easy. Thanks, Yaron ------------------------------ Message: 4 Date: Sat, 22 Apr 2006 10:06:17 -0400 From: Michael Richardson Subject: Re: [anonsec] btns-ipsec-apireq.txt To: anonsec at postel.org Message-ID: Content-Type: text/plain; charset=us-ascii -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Yaron" == Yaron Sheffer writes: Yaron> One nit and one question: 1. In the Terminology section, should Yaron> be: it does *not* imply any specific API... Thanks. Yaron> 2. The "WHO" section is missing the most obvious identity Yaron> information, which is the IKE ID payloads (or SubjectAltName Yaron> attributes) when these are available, i.e. in the non-anonymous Yaron> case. Is this omission intentional? Yes. I specifically do not want to teach application how to parse DNs, FQDNs, Kerberos principles, etc. Also note that in the first revision of the requirements, we are focused on the responding system, not the initiating system. We wanted the identifiers to have an opaque format that could be trivially compared. (In the API that envision, these would actually be pointers, which would equal() whenever they are eq(), but one would still need to use the proper IsIdentifyEqual() function) For auditing purposes, there should be a way to get a string from the opaque identifier. By making it unidirectional, we do not require that the mapping be reversable. So, if you have a nice human readable, printable form of the DN, you can display that. It might be perfect for the input side. For the case of certificates, if one takes a page from the HIP API, then the application doesn't really care/know --- it just loads a file that the user provided. I notice that I'm now on multimobsec-api at ietf.org, and I want to know if I should be CC'ing that list as well. Does this indicate that Sam thinks that perhaps this work should be in a new WG? ( https://www1.ietf.org/mailman/listinfo/multimobsec-api for those that didn't get subscribed ) - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBREo4W4CLcPvd0N1lAQIuzQf+OA45ZJrocvNRUoy63hS4Ez0D47YYALgZ UizTlF86xUFVjXZdkxlGjCHQhrljWH4LKQXb7/ZjO5yvgBjJxLrurSZdHs0mJ5uv da+bxT6H/uA3ZG39xSc++FaLw8cb1gr0W1UtSLp0LvMdQ6Cf/uqdVr63MDVsyTmV 6FydwBn/DRs+c8l/zNu6EKMeLjfJsl9FsCEdJKvapOw5qBkAsh7P8nISiMrghqvS 6e/IwJtDs0kCiOvAeXDAUEv+imEDBO+iUrSbB0xIc+kZKRTop0ddtARE6y27vGP0 JiDDe07ebMsGM9mabXklZCosDEteZnID68XhCpFphdspHUHKprr5bw== =88K4 -----END PGP SIGNATURE----- ------------------------------ _______________________________________________ ANONSEC mailing list ANONSEC at postel.org http://www.postel.org/mailman/listinfo/anonsec End of ANONSEC Digest, Vol 19, Issue 10 *************************************** From miika at iki.fi Sun Apr 23 15:16:27 2006 From: miika at iki.fi (Miika Komu) Date: Mon, 24 Apr 2006 01:16:27 +0300 (EEST) Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> <12300.1144601106@sandelman.ottawa.on.ca> <9F406627-9248-4D0E-B163-A2D55F3C686B@nomadiclab.com> <12885.1144685989@sandelman.ottawa.on.ca> <4443E62F.5080109@sun.com> Message-ID: On Sat, 22 Apr 2006, Michael Richardson wrote: >>>>>> "Miika" == Miika Komu writes: > >> What is the uniqueness requirements for the ED? Is it just a locally > >> allocated number that a host could start assinging at 1 for the remote > >> hosts it talks to? > > Miika> Currently yes. It could be unique only in the process context, > Miika> depending on the implementation. > > > I am seriously considering making the EDs, which I think of as first class > objects, be file descriptors. Further, they may well be Unix domain sockets > (perhaps with a new family type) that are already connected to the > appropriate keying daemon. > Yes, this is true. > (I think the HIP people might need to explain how HIP opportunistic mode > differs from rfc4332. It isn't the same) It means that there is a leap of faith because the first packet of the HIP key exchange is sent to an unkown HIP layer identifier (=HIT). In practice, this might be a little bit problematic to implement because the application might be doing a connect call on an IP address. It is problematic in the sense of mobility; when hosts move, the address may become invalid. There are various ways to go around this problem which mostly involve in wrapping or modifying the application sockets somehow, either at the application layer or sockets layer in kernel. Compared to them, ED makes things simpler because the HIT can be later on filled when the HIT is actually learned later on during the key exchange. -- Miika Komu miika at iki.fi http://www.iki.fi/miika/ From mcr at sandelman.ottawa.on.ca Mon Apr 24 14:19:58 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 24 Apr 2006 17:19:58 -0400 Subject: [anonsec] first steps in APIs References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> 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/20060424/6abe9e6d/attachment.bin From mcr at sandelman.ottawa.on.ca Mon Apr 24 14:28:47 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 24 Apr 2006 17:28:47 -0400 Subject: [anonsec] btns-ipsec-apireq.txt References: <004d01c666f5$bb0670e0$132e1dc2@ad.checkpoint.com> Message-ID: >>>>> "Yaron" == Yaron Sheffer writes: Yaron> Hi Michael, I understand your reasoning, and the complexity of Yaron> adding identity into the API. OTOH, "identity binding" is an often Yaron> required feature. Yaron> Let me give an example, and please point out where I am getting it Yaron> wrong: the "responding system" is a RADIUS server, and it wants to Yaron> perform access control on its clients based on something stronger Yaron> and easier to manage than the authenticator value. The server Yaron> might want to compare the alleged NAS-IP-Address (or Yaron> NAS-Identifier) to the authenticated identity. If we provide Yaron> standard mapping for the common identity types (IP address and Yaron> FQDN), this would be easy. In the case of authenticating against the IP address, your work is already done. You don't need an API. The credentials that were used to establish the IKE session would have had to have something that permitted the peer to assert that it is IP address FOO. The kernel components will keep all other peers from impersonating IP address FOO, so at that point, getpeername() returns what you want. The API has to have a method of comparing identifiers. I'm trying to make it clear that you compose the identifiers in some fashion, you get an iToken handle to it, and then you compare against what you were given. It may well be that: "192.139.46.73" and "C=CA, ST=Ontario, O=Openswan, L=Toronto, CN=herring.sandelman.ca, ipAddress=192.139.46.73" are in fact equal(). Do you want your appliation to have that logic? I don't. (it might depend upon which CA signed that certificate...) ======= How can I make this intention clearer in the API requirements? From miika at iki.fi Mon Apr 24 23:48:56 2006 From: miika at iki.fi (Miika Komu) Date: Tue, 25 Apr 2006 09:48:56 +0300 (EEST) Subject: [anonsec] first steps in APIs In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> Message-ID: On Mon, 24 Apr 2006, Michael Richardson wrote: >>>>>> "marcelo" == marcelo bagnulo braun writes: > marcelo> So bottom line is, the commonality comes from these two > marcelo> characteristics that seems to be available in the differetn > marcelo> scenarios: > > marcelo> - there are multiple addresses that need to be managed - a > marcelo> mechanism for failure detection and path exploration is used by > marcelo> the different protocols and it needs to be tuned/managed > > marcelo> The functions related to such functions can be made common to > marcelo> all the protocols. > > marcelo> Makes any sense? > > So do you feel that there is any overlap between shim6 and IPsec? > I think we have two APIs here. > > And that's fine -- decoupling is good. > The HIP folks have to coordinate twice, but we don't have to come to a > consensus among three groups. So, it seeems like we would have two APIs: one for security (IPsec) and the other one for locators. We'd need consensus between BTNS-HIP and SHIM6-HIP. It might even make things easier. If we split things already at this point, it may not make sense to create "core" drafts. Otherwise, we may end up with too many documents (?): * locator core * SHIM6 locator extensions * HIP locator extensions * IPsec security core * BTNS security extensions * HIP security extensions On the other hand, this separation might be better for other lower layer protocols as well. Comments, opinions? -- Miika Komu miika at iki.fi http://www.iki.fi/miika/ From miika at iki.fi Tue Apr 25 00:00:51 2006 From: miika at iki.fi (Miika Komu) Date: Tue, 25 Apr 2006 10:00:51 +0300 (EEST) Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: On Tue, 25 Apr 2006, marcelo bagnulo braun wrote: > I don't know... I think there is some overlap even between shim6 and btns, but the overlap is somewhat marginal. Consider these examples: * You could request current IPsec security parameters from shim6 module and it would tell you that there is none * To set-up BTNS IPsec policies and associations, you also need locators However, there is no reason why these APIs couldn't be decoupled. > what about MOBIKE? wouldn't mobike need similar locator management and > failure detection functions? > > what about MIP? (with the HA) in this case we would need to manage > multiple locators and deal with failure detection over the IPSec tunnel > with the HA... > > but again, i don't really know just exploring There is some overlap, but I think it is possible to abstract it. HIP is the common denominator, so HIP people need to make sure that the "gray area" is covered in the drafts. In any case, it would be very useful for everyone to review all drafts with a close attention what their working group wants from the APIs. -- Miika Komu miika at iki.fi http://www.iki.fi/miika/ From shinta at sfc.wide.ad.jp Tue Apr 25 01:30:07 2006 From: shinta at sfc.wide.ad.jp (Shinta Sugimoto) Date: Tue, 25 Apr 2006 11:30:07 +0300 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> Message-ID: <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Hi Michael, please find my comments inline. On Sat, 22 Apr 2006 19:08:13 -0400 Michael Richardson wrote: > > >>>>> "Shinta" == Shinta Sugimoto writes: > > (when I first read your name, I was sure it must be "Shim6ta Sugimoto"...) > > >> If I understood correctly, it seems like shim6 guys are interested in > >> the interactions between applications, locators, referrals, resolver > >> and shim module. We have touched those topics in the native HIP API > >> work, but there is still a bunch of things to be done. > > Shinta> Yes, now I am sorting out what kind of API is needed for SHIM6. > Shinta> In SHIM6, the issues are mainly how app can easily/efficiently > Shinta> deal with locators, and interaction between SHIM6 module and ULP > Shinta> (especially TCP) should also be defined. But certainly there is > Shinta> a relation to other API works (including the work done in HIP). > > I am perhaps someone naive in my understanding of shim6. > I followed multi6, and was well briefed over dinner at the last IETF as to > how shim6 works. I must be admit that I'm at a loss to understand the shim6 > API question, when it is not being used to bootstrap to HIP. > > As I understand it, upon initial connect, the application is going > (via getpeername/getsockname), going to see the address that was used to > connect to it, and the local address to which the connection was made. > > Should the shim6 layer detect a loss of connectivity and switch to another > address, the transition will be not be seen to the application. Is it an > open question what getsockname/getpeername() will say after the transition? No. IMO, getsockname()/getpeername() should not be affected by the locator change. If SHIM6 context is applied to given flow, then locator changed to something else, that should be kept invisible to the ULP. > i.e. is the kernel supposed to maintain the original fiction, Yes. > or is it > better that it indicate what is reality at that moment, so that if the > purpose of the query was to start a second connection (i.e. FTP...) that > it can start with a better hint. Apart from the above (that the locator change should not affect getsockname()/getpeername()), telling the 'reality' of the locator selection to the ULP might be helpful. Not sure how much is it helpful though. Such extension would allow application to get information about the locator which is bound to given socket. Similary, we may extend sendmsg()/recvmsg() to deliver locator information to the application storing them in acillary data, for instance. But again, I don't see clear need (good usecase) for that. Do you see any ? > I can see how getsockname()/getpeername() are not good enough, and you'd > like a more sophisticated answer. This is similar, certainly to what IPsec > wants: we want to know far more than what that interface can provide. > (And in the case IPv4 transport mode through a NAPT, the answer from > getpeername() is perhaps completely ambiguous) I see. BTW, is there any other cases than NAT where IPsec requires more sophisticated Socket API calls if peer is multihomed ? > Is that the extent of the requirements? Yes, I think so. > Or are there more? Not sure at the moment. Regards, Shinta From pekka.nikander at nomadiclab.com Tue Apr 25 02:41:15 2006 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Tue, 25 Apr 2006 12:41:15 +0300 Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: To me, one of the more important parts of this exercise is to see whether, from an application's point of view, one could more or less implement HIP-functionality with BTNS+CGA+SHIM6. In other words, my gut feeling is that that it would be good if HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. --Pekka On Apr 25, 2006, at 10:00, Miika Komu wrote: > On Tue, 25 Apr 2006, marcelo bagnulo braun wrote: > >> I don't know... > > I think there is some overlap even between shim6 and btns, but the > overlap > is somewhat marginal. Consider these examples: > > * You could request current IPsec security parameters from shim6 > module > and it would tell you that there is none > * To set-up BTNS IPsec policies and associations, you also need > locators > > However, there is no reason why these APIs couldn't be decoupled. > >> what about MOBIKE? wouldn't mobike need similar locator management >> and >> failure detection functions? >> >> what about MIP? (with the HA) in this case we would need to manage >> multiple locators and deal with failure detection over the IPSec >> tunnel >> with the HA... >> >> but again, i don't really know just exploring > > There is some overlap, but I think it is possible to abstract it. > HIP is > the common denominator, so HIP people need to make sure that the "gray > area" is covered in the drafts. > > In any case, it would be very useful for everyone to review all drafts > with a close attention what their working group wants from the APIs. > > -- > Miika Komu miika at iki.fi http://www.iki.fi/miika/ > _______________________________________________ > From miika at iki.fi Tue Apr 25 05:53:27 2006 From: miika at iki.fi (Miika Komu) Date: Tue, 25 Apr 2006 15:53:27 +0300 (EEST) Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: On Tue, 25 Apr 2006, Pekka Nikander wrote: > To me, one of the more important parts of this exercise is to see whether, > from an application's point of view, one could more or less implement > HIP-functionality with BTNS+CGA+SHIM6. In other words, my gut feeling is > that that it would be good if > > HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. This would work for me. -- Miika Komu miika at iki.fi http://www.iki.fi/miika/ From mcr at sandelman.ottawa.on.ca Tue Apr 25 06:24:58 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 25 Apr 2006 09:24:58 -0400 Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: Message from marcelo bagnulo braun of "Tue, 25 Apr 2006 09:42:38 +0300." <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: <26520.1145971498@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "marcelo" == marcelo bagnulo braun writes: marcelo> what about MOBIKE? wouldn't mobike need similar locator marcelo> management and failure detection functions? MOBIKE is about moving the outer part of an IPsec tunnel around. The addresses inside (the identifiers if you prefer), remain the same, so applications do not see any change. A MOBIKE daemon *itself* might benefit from the mechanisms provided by shim6 (if it were available for IPv4), but the end-user application would never see the changes. That's the purpose of MOBIKE. As for MIP, again, the point of the effort is to maintain the same set of identifiers for the application. - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRE4jJoCLcPvd0N1lAQJiNgf+KwUNs2RdKnIat0zoc0cBQXLtwbHa27ds v78cuzEtG28uq9IQ0lGngSlcNqouGM4taIVOvThQ2jEs9GG/2pSYgXON1VNbj2nG N7A+wuDC0EI5i7Qim/d4TplwGcmbHcPL+zCslKBf+KtU/UsKQ3WuIFkiNgJnmGIZ W1paC9g00X0p1QFOLfwlvgFVctHPBE2THLv4pDFb5/r3j2z7iCL7wGvwqSw3rTKK lzQjKhsi7g72pPPXyAty6CzQ4iYcsBcCyaorgH7FJurxh6SBPxpE4yX8pMK6hn+N DstQvQJzXx5QAr9OKkQHeLNfa57cbZ0Nc0p53ZMwHBkKeBxMP+RuuQ== =mm+X -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Tue Apr 25 06:29:58 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 25 Apr 2006 09:29:58 -0400 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: Message from Shinta Sugimoto of "Tue, 25 Apr 2006 11:30:07 +0300." <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Message-ID: <26824.1145971798@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Shinta" == Shinta Sugimoto writes: >> I can see how getsockname()/getpeername() are not good enough, >> and you'd like a more sophisticated answer. This is similar, >> certainly to what IPsec wants: we want to know far more than what >> that interface can provide. (And in the case IPv4 transport mode >> through a NAPT, the answer from getpeername() is perhaps >> completely ambiguous) Shinta> I see. BTW, is there any other cases than NAT where IPsec Shinta> requires more sophisticated Socket API calls if peer is Shinta> multihomed ? Many people would like to be able to establish multiple IPsec SAs between two nodes that are multihomed. I.e. one for each interface address. Many would like to load balance between the tunnels. (The only situation that I'm aware that have been deployed is actually where one load balances between *machines*, with failover between the two machines, and it's all about tunnels, so the end-application never sees this) Given shim6, let ULP=ESP, and just use shim6. So, IPsec in the kernel may need to know about shim6, but application does not see shim6, only IPsec. - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRE4kVICLcPvd0N1lAQJ2cggApEL/9B28gJk9s/IiAvvCn8c9yi9qaaYW F0J7hd4Blx+bhB5z+DG2gS6O7soXo1ehtqf731Xu9Kcl+ihUAxBx9gUd9j9EsXy/ OlxXavKAtKEh8N18CqJh6XJFqWr9m7DCBcYiz+GzIzc/0tgRTFBCidYC4PE4cNrk oJq9obxmQJgLVm2vWJIaQEDmtjW1CLymO2o6uwxcCTwJLPDR1N2G7+dGbSUH+d2m +7xsPcmdRrQmGFJxutpo9/KF/s5lyOn7SDm3XAbhE0B6oUGsBZtAgWvonZ+b3KGF /xcy1EQB6sEMt2w8fgYb6YTts4DqVAP63Or7EgT+U1yg8CQIKnQpNA== =91Gm -----END PGP SIGNATURE----- From miika at iki.fi Tue Apr 25 06:31:14 2006 From: miika at iki.fi (Miika Komu) Date: Tue, 25 Apr 2006 16:31:14 +0300 (EEST) Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Message-ID: On Tue, 25 Apr 2006, Shinta Sugimoto wrote: >> Should the shim6 layer detect a loss of connectivity and switch to another >> address, the transition will be not be seen to the application. Is it an >> open question what getsockname/getpeername() will say after the transition? > > No. IMO, getsockname()/getpeername() should not be affected by the > locator change. If SHIM6 context is applied to given flow, then locator > changed to something else, that should be kept invisible to the ULP. Agree with Shinta. >> or is it better that it indicate what is reality at that moment, so >> that if the purpose of the query was to start a second connection (i.e. >> FTP...) that it can start with a better hint. > > Apart from the above (that the locator change should not affect > getsockname()/getpeername()), telling the 'reality' of the locator > selection to the ULP might be helpful. Not sure how much is it helpful > though. We have now three layers of identifiers now: * application layer: endpoint descriptor * transport layer: initial shim6 locator (ULP), or some kind of CGA (HIT) * network layer: current (shim6) locator This the "clean" view of the APIs. For legacy apps, application layer id could be CGA type of address or just a (shim6) locator. In the light of this viewpoint, I think getsockname()/getpeername should return the application information that is adjacent to the application layer, that is transport layer information. > Such extension would allow application to get information about the > locator which is bound to given socket. In HIP we have HITs that cannot be resolved from DNS because they are flat (they are hashes of public keys). If you call getpeername, receive a HIT and pass it to a third host (the term is "referral"), it might be of any use the third host. The reason is that the third host might not be able to find the corresponding locator. Despite of this shortcoming, this will be most probably solved using DHT based look up services in future. Alternatively, we could pass the IP address instead of HIT. This is actually makes things worse because in HIP hosts are mobile. So, I would say that we should return transport layer id in getsockname/getpeername, and use a separate API for the locators. > Similary, we may extend sendmsg()/recvmsg() to deliver locator > information to the application storing them in acillary data, for > instance. But again, I don't see clear need (good usecase) for that. > Do you see any ? I there are three cases: 1. get identifier related info 1. a) explicit request from the application 1. b) sockets returning even information to the application 2. set identifier related info Here, identifier could be an HIT, CGA, ULID or locator. I think 1a and 1b could be specified using getsockopt and setsockopt to avoid adding new system calls. Shinta is referring to case 1b with sendmsg and recmsg. However, Pekka said that it might be better to use some other function, perhaps something like NETLINK socket to receive this information. This way, data transfer would be decoupled better from locator/security related events. -- Miika Komu miika at iki.fi http://www.iki.fi/miika/ From Nicolas.Williams at sun.com Tue Apr 25 08:15:09 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 10:15:09 -0500 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <004d01c666f5$bb0670e0$132e1dc2@ad.checkpoint.com> Message-ID: <20060425151509.GM4000@binky.Central.Sun.COM> On Mon, Apr 24, 2006 at 05:28:47PM -0400, Michael Richardson wrote: > > In the case of authenticating against the IP address, your work is already > done. You don't need an API. The credentials that were used to establish the > IKE session would have had to have something that permitted the peer to > assert that it is IP address FOO. The kernel components will keep all > other peers from impersonating IP address FOO, so at that point, > getpeername() returns what you want. > Yes, that is a dodge, that's why we're here :) > The API has to have a method of comparing identifiers. > > I'm trying to make it clear that you compose the identifiers in some > fashion, you get an iToken handle to it, and then you compare against what > you were given. It may well be that: > "192.139.46.73" > > and > "C=CA, ST=Ontario, O=Openswan, L=Toronto, CN=herring.sandelman.ca, > ipAddress=192.139.46.73" > > are in fact equal(). Do you want your appliation to have that logic? I don't. > (it might depend upon which CA signed that certificate...) So, you want some sort of canonical tokenized form for names that can then be compared octet-wise for equality? Sort of like what the GSS-API provides? This would undoubtedly work where the IDs are IKEv2 IDs that can be asserted on the wire or BTNS publickey IDs, and HITs. Of course, if folks then want to do granular authorization then we'll get into the same space that KITTEN WG is in right now... But we can cross that bridge when we come to it; KITTEN is proof that we can leave that for later. Nico -- From Nicolas.Williams at sun.com Tue Apr 25 08:22:35 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 10:22:35 -0500 Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: <20060425152234.GN4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 10:00:51AM +0300, Miika Komu wrote: > I think there is some overlap even between shim6 and btns, but the overlap > is somewhat marginal. Consider these examples: > > * You could request current IPsec security parameters from shim6 module > and it would tell you that there is none > * To set-up BTNS IPsec policies and associations, you also need locators Er, let's be careful and avoid confusion on the BTNS list about this: - BTNS is, at its core, about NOT authenticating peers - BTNS allows for anonymity and pseudonymity - (BTNS pseudonymity && (application-driven enrolment || application-driven leap-of-faith)) == ad-hoc IPsec authentication - Some BTNS applications (channel bindings) don't care for pseudonymity, and, therefore, don't care for ad-hoc IPsec authentication. So, BTNS can be said to have locators, but it isn't strictly the case that it does have locators -- "BTNS locators" are an application construct, not a fundamental BTNS construct. > However, there is no reason why these APIs couldn't be decoupled. Yes, but I think there's a point where they may meet: at the API for obtaining the end-point IDs of a latched connection, and, therefore, the representation of these IDs (IKEv2-style representation, + BTNS publickey ID type, + HITs). Nico -- From Nicolas.Williams at sun.com Tue Apr 25 08:29:28 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 10:29:28 -0500 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Message-ID: <20060425152928.GO4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 11:30:07AM +0300, Shinta Sugimoto wrote: > On Sat, 22 Apr 2006 19:08:13 -0400 > Michael Richardson wrote: > > or is it > > better that it indicate what is reality at that moment, so that if the > > purpose of the query was to start a second connection (i.e. FTP...) that > > it can start with a better hint. > > Apart from the above (that the locator change should not affect > getsockname()/getpeername()), telling the 'reality' of the locator > selection to the ULP might be helpful. Not sure how much is it helpful > though. Such extension would allow application to get information > about the locator which is bound to given socket. Similary, we may > extend sendmsg()/recvmsg() to deliver locator information to the > application storing them in acillary data, for instance. But again, > I don't see clear need (good usecase) for that. Do you see any ? Ah, er, I see Michael's point. What if the app wants to initiate a connection to a peer for which it already has a connection. Are there such applications today? (Yes! NFSv4.) How can such applications continue to work then in this environment? Ah, but there's no guarantee that they'd work even if getsockname()/getpeername() returned the peer's current locator because the peer and the application might be racing around the next change. Nico -- From Nicolas.Williams at sun.com Tue Apr 25 08:37:30 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 10:37:30 -0500 Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: <20060425153730.GP4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 12:41:15PM +0300, Pekka Nikander wrote: > To me, one of the more important parts of this exercise is to see > whether, from an application's point of view, one could more or less > implement HIP-functionality with BTNS+CGA+SHIM6. In other words, my > gut feeling is that that it would be good if > > HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. What is CGA? Anyways, what you call "BNTS api" is really an IPsec API: - APIs for getting latched connection peer IDs (enough for channel bindings and application-driven LoF and enrolment) - APIs for requesting services beyond what the SPD requires (e.g., confidentiality where the SPD requires only integrity protection, or any protection at all where the SPD allows bypassing) - APIs for requesting bypass (requiring privilege, of course) - APIs for editing the IPsec policy databases (PAD, SPD) (which could be used for application-driven LoF and enrolment, but this is a much bigger hammer than the above) Given a canonical tokenization of IKE/IPsec/BTNS IDs and HITs I think this comes very close to a basic HIP API. Still needed: - additional APIs to deal with mobility/NAT (again, this would be fairly generic) - APIs to locate peers (this being rather specific to HIP). Nico -- From Nicolas.Williams at sun.com Tue Apr 25 08:47:28 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 10:47:28 -0500 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Message-ID: <20060425154728.GQ4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 04:31:14PM +0300, Miika Komu wrote: > On Tue, 25 Apr 2006, Shinta Sugimoto wrote: > > Apart from the above (that the locator change should not affect > > getsockname()/getpeername()), telling the 'reality' of the locator > > selection to the ULP might be helpful. Not sure how much is it helpful > > though. > > We have now three layers of identifiers now: > > * application layer: endpoint descriptor > * transport layer: initial shim6 locator (ULP), or some kind of CGA (HIT) > * network layer: current (shim6) locator > > This the "clean" view of the APIs. For legacy apps, application layer id > could be CGA type of address or just a (shim6) locator. > > In the light of this viewpoint, I think getsockname()/getpeername should > return the application information that is adjacent to the application > layer, that is transport layer information. Well, why not label getsockname()/getpeername() legacy interfaces? Then you need to worry about two things: - backwards compatibility for users of getsockname()/getpeername() in various circumstances; if it can't always be preserved, oh well, don't be mobile :) If the application connect()ed using any locator other than an IP address then you can return all available information about the two end-points to the application. Otherwise, if the application connect()ed to an IP address or used accept() and did not do anything else to indicate support for anything other than IP addresses, then getsockname()/getpeername() should only return IP addresses (and ULP port numbers). - new APIs for everything the application might care for (see below), perhaps as an extension of existing APIs (see above) > > Such extension would allow application to get information about the > > locator which is bound to given socket. > > In HIP we have HITs that cannot be resolved from DNS because they are flat > (they are hashes of public keys). If you call getpeername, receive a HIT > and pass it to a third host (the term is "referral"), it might be of any > use the third host. The reason is that the third host might not be able to > find the corresponding locator. Despite of this shortcoming, this will be > most probably solved using DHT based look up services in future. > > Alternatively, we could pass the IP address instead of HIT. This is > actually makes things worse because in HIP hosts are mobile. Alternatively you make both items available to the application, which then can pass them to the third party, which then does not need to do any resolution (provided that the peer hasn't moved). Nico -- From mcr at sandelman.ottawa.on.ca Tue Apr 25 12:22:27 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 25 Apr 2006 15:22:27 -0400 Subject: [anonsec] btns-ipsec-apireq.txt References: <004d01c666f5$bb0670e0$132e1dc2@ad.checkpoint.com> <20060425151509.GM4000@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/20060425/f43754ce/attachment.bin From mcr at sandelman.ottawa.on.ca Tue Apr 25 12:29:55 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 25 Apr 2006 15:29:55 -0400 Subject: [anonsec] btns-ipsec-apireq.txt References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Message-ID: >>>>> "Miika" == Miika Komu writes: Miika> We have now three layers of identifiers now: Miika> * application layer: endpoint descriptor Miika> * transport layer: initial shim6 locator (ULP), or some kind of CGA (HIT) Miika> * network layer: current (shim6) locator So, in the IPsec space we have: a) principal - DN,SPKI Id,PGP identity,public key b) IKE layer - certificate/public key and/or hash of same. c) transport layer - ULP (could be HIT) d) IPsec layer - SPI# (SA bundle and pair) e) network layer - current (shim6) locator It is an explicit non-goal to provide access to (d). We already think we have access to (c) via current API. It is (b) and (a) that we are trying to get access to. Does this mean that there is in fact more commonality? Miika> So, I would say that we should return transport layer id in Miika> getsockname/getpeername, and use a separate API for the locators. Good. Principle of least surprise. Miika> Shinta is referring to case 1b with sendmsg and recmsg. However, Pekka Miika> said that it might be better to use some other function, perhaps something Miika> like NETLINK socket to receive this information. This way, data transfer Miika> would be decoupled better from locator/security related events. you need to have cmsg attached to sendmsg/recvmsg if you expect to support connectionless protocols. Each message may well have a different answer. ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr From mcr at sandelman.ottawa.on.ca Tue Apr 25 12:32:03 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 25 Apr 2006 15:32:03 -0400 Subject: [anonsec] first steps in APIs References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> 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/20060425/398ddf9a/attachment.bin From Nicolas.Williams at sun.com Tue Apr 25 13:05:15 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 15:05:15 -0500 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <004d01c666f5$bb0670e0$132e1dc2@ad.checkpoint.com> <20060425151509.GM4000@binky.Central.Sun.COM> Message-ID: <20060425200514.GL4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 03:22:27PM -0400, Michael Richardson wrote: > Nicolas> Of course, if folks then want to do granular authorization then > Nicolas> we'll get into the same space that KITTEN WG is in right now... > > Please give us more pointers. - KITTEN WG charter page :) http://www.ietf.org/html.charters/kitten-charter.html - Desired Enhancements to GSSAPI Version 3 Naming http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04.txt - GSS-API Naming Extensions http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-01.txt From Nicolas.Williams at sun.com Tue Apr 25 13:13:07 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 15:13:07 -0500 Subject: [anonsec] btns-ipsec-apireq.txt In-Reply-To: References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Message-ID: <20060425201306.GM4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 03:29:55PM -0400, Michael Richardson wrote: > So, in the IPsec space we have: > > a) principal - DN,SPKI Id,PGP identity,public key > b) IKE layer - certificate/public key and/or hash of same. > c) transport layer - ULP (could be HIT) > d) IPsec layer - SPI# (SA bundle and pair) > e) network layer - current (shim6) locator > > It is an explicit non-goal to provide access to (d). Indeed. Connection latching should obviate the need for applications to care about SPIs. > We already think we have access to (c) via current API. > It is (b) and (a) that we are trying to get access to. Yes! The BTNS connection latching I-D discusses this somewhat. (a) could be any of the ID types discussed in RFC4301, which relate fairly closely to IKEv2 ID types, which relate somewhat to credentials. (b) would be, IMO, only public keys or fingerprints thereof. I see entire certs as useful for granular authorization, but not necessary for the kinds of applications discussed in the BTNS WG. Note that (a) and (b) pretty much imply connection latching (to see why see the post-Vancouver, pre-Dallas threads on the BTNS WG list). > Does this mean that there is in fact more commonality? I think so. Nico -- From Nicolas.Williams at sun.com Tue Apr 25 13:30:32 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 15:30:32 -0500 Subject: [anonsec] first steps in APIs In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: <20060425203031.GP4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 03:32:03PM -0400, Michael Richardson wrote: > Pekka> HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. > > So, you do not so much want us to find common pieces, but rather to > delinate clearly where one starts and one ends. Dunno about Pekka, but, I see what he termed "BTNS api" above as a generic IPsec API, which I describe, in broad terms, in the BTNS connection latching I-D[0]. Given this I think we're talking about a well-delineated generic IPsec API[1] that is commonly useful in the BTNS, HIP and SHIM6 spaces. [0] http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-00.txt [1] There's another proposed IPsec API for editing IPsec policy databases, but I think this API would not be common to the BTNS, HIP and SHIM6 spaces. Nico -- From mcr at sandelman.ottawa.on.ca Tue Apr 25 14:05:43 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 25 Apr 2006 17:05:43 -0400 Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> <20060425152234.GN4000@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/20060425/ba48dd74/attachment.bin From Nicolas.Williams at sun.com Tue Apr 25 14:15:52 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 25 Apr 2006 16:15:52 -0500 Subject: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> <20060425152234.GN4000@binky.Central.Sun.COM> Message-ID: <20060425211552.GS4000@binky.Central.Sun.COM> On Tue, Apr 25, 2006 at 05:05:43PM -0400, Michael Richardson wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> Yes, but I think there's a point where they may meet: at the API > Nicolas> for obtaining the end-point IDs of a latched connection, and, > Nicolas> therefore, the > Nicolas> representation of these IDs (IKEv2-style representation, + BTNS > Nicolas> publickey ID type, + HITs). > > When you receive a latched connection that was accepted due to BTNS, > and the ID that was asserted in IKE was ID_IPV6 (recalling that BTNS > made you not care that much about how valid it was for them to assert that), > would you expect to see the end-point ID be: > a) the IPV6 that was asserted via IKE. > b) the HIT that the transport/shim6 layer asserted > > Aren't these two different things? > Particularly when the IE in IKE was in fact FQDN or something. You would expect to get the coerced peer ID, the BTNS publickey ID whose value is the peer's public key. You want to see the IP addresses? Sure, you can do that today. You want to see your NATed address, Ok, that's something new. > I can see applications that take a connection the first time, set > up some kind of account, have the account validated by out-of-band method > (e.g. the user paid for the service), and recall the public key used to sign > on. Subsequent sign-ons are authenticated nicely by public alone. Yes, exactly, that's ad-hoc authentication based on enrolment of BTNS public keys.