From mcr at sandelman.ottawa.on.ca Sun Apr 1 14:41:48 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 01 Apr 2007 17:41:48 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Message from Francis Dupont of "Wed, 21 Mar 2007 18:05:37 BST." <200703211705.l2LH5bbI028522@tao.fdupont.fr> References: <200703211705.l2LH5bbI028522@tao.fdupont.fr> Message-ID: <14450.1175463708@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Francis" == Francis Dupont writes: Francis> => what about to use the INTEG (integrity algorithm) in Francis> place of the PRF (pseudo-random function) with the same Francis> arguments? (IMHO this is more appropriate to the intended Francis> usage.) If I understand you, that's a phase 2/CHILD-SA thing that is negotiated, and perhaps not every phase 2 has an integrity algorithm. It might also be that the negotiated phase 2 algorithm is only implemented/available in a line card the implements the phase 2, and has no software implementation in the "host". (Consider some kind of patented algorithm) - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhAnEICLcPvd0N1lAQJHMAf/QoLM7DbkWfOP3wE21mk4Ka9PuRqePVrc R+Cy090EkL7R56+Dy1KJEDE49croijckf1DkIBv/YqBqkn1ijIIfDcXOszC/Jh1Y wYczF4PtJioBqhwj9IH2aWftQoEvDirStQo5PwsZszxMrlDuZHkNZ9YOk/lUOcyn D839/TyI63A2lIVjxGZqa6TbwJ9FZky9B5J1+F+pvy4FGPKMHaReTodYGCSgyvQF Qm1KcJ8DLVIogv7D6NCuvxfFa3S1/AuYk78qHas4WZZwcyzv0bBAuAGOAS3n4zmp l0SESFi2B35x8E1iutEsM+MzmwNLknCrBt9+P67ShvRAPCOSbRxE5A== =4SBo -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Sun Apr 1 14:43:05 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 01 Apr 2007 17:43:05 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Message from Nicolas Williams of "Wed, 21 Mar 2007 12:13:30 CDT." <20070321171330.GE22445@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> Message-ID: <14575.1175463785@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> - Imagine I send a SYN packet protected with some SA, say, Nicolas> SPI 1001, but the SYN|ACK does not arrive in time so I Nicolas> retransmit, only this time I use a new SA (SPI 1002, say) Nicolas> because, say, the old one expired. Nicolas> We can get into a weird situation: the SA that _I_ see Nicolas> as the one used to protect the channel creation trigger is Nicolas> _different_ from the one seen by my peer, so we fail to Nicolas> agree on channel binding! Perhaps, in this case, it should fail. - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhAnZ4CLcPvd0N1lAQIYbAf+POrRcFF4iaOp21FguGLsIPHWNCWybIU3 EsFtRApUFZaLX9yOKi0m9bL+VIq6lKaEXsbPp4okB8tZjUTnFItsV09lFt82P7Nf FNuW5nhpVwmLlGuBJTaXZFI7iV50fSNAwLB2bFbIIl76u59R7Kek6X+lgHWdEVXl dN4l18OGQfVULrR1gi9YQO+liajvWnui/Uj9OTtGdHhKvyf1LhaAcIFFiDZaX5RP LJmhy7GUQoHPK2a7jkztU3gXHpOcze3UZ77K1iQabQzEDuWtQZx6qUQPJb4V74Yz DuEvWwRqXHyRqRvpx8kBP+qShWLdVCwyLeMK9eGeE3B6354d3epPzw== =cTGt -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Sun Apr 1 14:44:30 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 01 Apr 2007 17:44:30 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Message from Nicolas Williams of "Wed, 21 Mar 2007 14:33:34 CDT." <20070321193334.GH22445@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <17921.32473.971082.12197@fireball.kivinen.iki.fi> <20070321193334.GH22445@Sun.COM> Message-ID: <14716.1175463870@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> This needs to work for IKEv1. Assuming that the IKE_SA is Nicolas> still around is not a good assumption. I have no problem with requiring that the IKE_SA remain around. Seriously. - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhAnvYCLcPvd0N1lAQL2iwf+JFvMfMeIDeR2fcWlJ2q/BWT3KwSYV8GP 5z5dVReO6Rd2UWC+JAOqixQCk3wHD3/3d/4M+CMkwT9ns8ZLEz3um5/DPYKM1fYc BkI/73lVUx/njlez72LlGIUEFCfaWqw5orEYm43KaWlx1dmJvwCOMJkK8Ap4OV4W M415IJ2n7gt6VvvnNSK2uqrhJl2iVWh9uFsUKVZpzb9fmPbhDl9pDhyNNq96Torl auTWxBtoFE1qV0aroA9I/5d2LRiDG/Db2nrxVGCBMAljhnOlTTQVYCErIa97JYOb +my+++vFg0euDWfWEFlD5Kq8hxHimZgjLH4XH+1JFinIMLqM4+Wd8g== =B030 -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Sun Apr 1 15:31:59 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 1 Apr 2007 17:31:59 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <14575.1175463785@sandelman.ottawa.on.ca> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <14575.1175463785@sandelman.ottawa.on.ca> Message-ID: <20070401223158.GK8252@Sun.COM> On Sun, Apr 01, 2007 at 05:43:05PM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> - Imagine I send a SYN packet protected with some SA, say, > Nicolas> SPI 1001, but the SYN|ACK does not arrive in time so I > Nicolas> retransmit, only this time I use a new SA (SPI 1002, say) > Nicolas> because, say, the old one expired. > > Nicolas> We can get into a weird situation: the SA that _I_ see > Nicolas> as the one used to protect the channel creation trigger is > Nicolas> _different_ from the one seen by my peer, so we fail to > Nicolas> agree on channel binding! > > Perhaps, in this case, it should fail. Well, it will fail. But with the other channel binding scheme it will succeed, as it should. We seem to be willing to accept this pathological condition. The only question is: why not go with the way that doesn't have this corner case? Possible reasons to reject public-keys-of-peers-as-channel-bindings: - doesn't work for IKEv2 w/ EAP authentication But does anyone want to do channel binding to channels where the peers were authenticated with EAP? I had a hallway conversation with Sam and Jeff H. about this but I came away unconvinced: the peers would have to be the client and the SG (since IKEv2 w/ EAP is only applicable to network access through IPsec VPNs), so given strong authentication to/of the SG at the IPsec layer why should any application on the client want to use channel bindings? Perhaps the EAP method used wasn't very strong -- but then why use it at all? Still, I'm certainly open to arguments on this. - unique channel bindings are better They certainly are. In SASL WG we saw a presentation about a password-based challenge/response authentication mechanism (YAP) that uses unique channel bindings as the server challenge and client nonce, thus saving a full round-trip (and since it only runs inside a secure channel it also provides a measure of privacy protection). So count me as half-convinced. Nico -- From Nicolas.Williams at sun.com Sun Apr 1 15:35:34 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 1 Apr 2007 17:35:34 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <14716.1175463870@sandelman.ottawa.on.ca> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <17921.32473.971082.12197@fireball.kivinen.iki.fi> <20070321193334.GH22445@Sun.COM> <14716.1175463870@sandelman.ottawa.on.ca> Message-ID: <20070401223533.GL8252@Sun.COM> On Sun, Apr 01, 2007 at 05:44:30PM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> This needs to work for IKEv1. Assuming that the IKE_SA is > Nicolas> still around is not a good assumption. > > I have no problem with requiring that the IKE_SA remain around. > Seriously. The channel initiator (client) can certainly keep it around. The server need not have any idea that it will have to keep it around. What we could do is make the connect() fail if the client were to retransmit a TCP SYN (or whatever) protected by a child SA of a different IKE_SA even though for the same peer. But how do you make that work for connect()ed UDP sockets? Or perhaps we should say that connect()ed UDP sockets don't have channel bindings, use IPsec APIs instead of connected UDP socets. I'd be willing to live with that. Nico -- From Nicolas.Williams at sun.com Sun Apr 1 15:46:49 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 1 Apr 2007 17:46:49 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <20070401223533.GL8252@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321171330.GE22445@Sun.COM> <17921.32473.971082.12197@fireball.kivinen.iki.fi> <20070321193334.GH22445@Sun.COM> <14716.1175463870@sandelman.ottawa.on.ca> <20070401223533.GL8252@Sun.COM> Message-ID: <20070401224649.GO8252@Sun.COM> On Sun, Apr 01, 2007 at 05:35:34PM -0500, Nicolas Williams wrote: > On Sun, Apr 01, 2007 at 05:44:30PM -0400, Michael Richardson wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> This needs to work for IKEv1. Assuming that the IKE_SA is > > Nicolas> still around is not a good assumption. > > > > I have no problem with requiring that the IKE_SA remain around. > > Seriously. > > The channel initiator (client) can certainly keep it around. The > server need not have any idea that it will have to keep it around. Responding to myself: i.e., what if the server reboots or otherwise loses IKE state? Nico -- From julien.IETF at laposte.net Mon Apr 2 02:10:21 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 2 Apr 2007 10:10:21 +0100 Subject: [anonsec] Preliminary minutes of BTNS@IETF68 Message-ID: <200704021110.21999.julien.IETF@laposte.net> Folks, Attached are the preliminary minutes of the BTNS session at IETF68. Please send corrections/additions to the mailing list before 2007-04-09 (next Monday). -- Julien & Love BTNS Chairs -------------- next part -------------- --------------------------------------------------------------------------- BTNS working group meeting minutes --------------------------------------------------------------------------- These are the minutes for the Better than nothing security (BTNS) working group meeting, held at IETF-67 on Wednesday, Mar 21, 2007, in beautiful Prague, Czech Republik. Thanks to the people who have implemented MP3 recording of the session on which these minutes are based. Chair: Julien Laganier (Love Hornquist Astrand excused) Responsible AD: Sam Hartman * Agenda Preliminaries - Chairs Core and Connection Latching - Nico Williams API - Michael Richardson & Miika Komu IKE Extensions - Michael Richardson * Action items - Chair to submit AS/PS to IESG for publication as Informational RFC - Chair to issue WG Last call on BTNS Core document after meeting - WG participants to read and comment connexion latching, API and IKE extensions documents * Narrative minutes for the session --------------------------------------------------------------------------- Status update (Chair) --------------------------------------------------------------------------- Missing couple of milestones, but chair confident that we can meet them soon. AS/PS to IESG after the meeting. Soon WGLC for core & connextion latching. Soon adopt API documents as WG items. --------------------------------------------------------------------------- Core BTNS (Nico Williams) --------------------------------------------------------------------------- Slide 2: Change since -01 ------------------------- There's only two changes. One was the changes made to the PAD SPD entries in the examples to remove inconsistencies that Steven Kent pointed out. It's done, Steve can confirm. I also reworded the bit about address accumulation. If you remember, we need PAD entries to reject BTNS peers if their traffic selectors for their child SAs could be asserted by non-BTNS peers. Better wording is to make two ordered passes over PAD, one at authentication time, one at chid SA authorization time. That's it for the changes. Slide 3: Status: Ready for WGLC ------------------------------- Status is I think it's ready for working group last call. Questions? I thought it was ready for working group last call modulo Steve comments, so Julien I would ask for working group last call. Actions: Chairs will issue WGLC. -------- --------------------------------------------------------------------------- Connexion Latching (Nicolas Williams) --------------------------------------------------------------------------- Slide 2: What ------------- Connexion latching, it's sort of... It's to IPsec as TCP is to IP. It protects packet flows coherently, not just packets. Kind of like TCP builds byte streams out of packets. Alternatively it's a way to build IPsec channels. It's needed because channel bindings needs IPsec channels. In addition there's a desire to protect against change in policy. Helps to address the problem where the PAD and SPD policy allows multiple hosts to claim address from the same networks Finally this is a fundation to IPsec APIs Questions: Slide 3: Why ------------ We need it because you know for things like channel binding, we need IPsec channels. In addition there is a desire to protect against a policy changing in such a way that it will compromise packet flows. Also, it helps to address the problem we discussed both in Montreal and I think in Vancouver, or wherever it was, two meetings before, where you know, the PAD has an SPD policy basically allowing multiple nodes to claim addresses from the same network making it possible to steal each other's packets. Finally, it's a foundation for IPsec APIs, and it's also sort of described in terms of ... IPsec APIs. Slide 4: How ------------ The idea is that when a connexion creation trigger occurs... in UDP you may still have something like a packet flow, but it's not a connexion, think of connected UDP sockets in BSD socket API... So what you do is that you figure out what the peer ID is, and what kind of SA protection, ESP, whatever, what are the algorithms, etc., and make sure that all subsequent packets for that packet flow are protected by similar SA. If you find packet from same packet flow which isn't protected, you drop. If you want to send packet but don't have an SA, you drop. On connexion tear down, you tear down the latch. Slide 5: How ------------ The draft sketches two implementation designs, you don't have to do it in either of these ways. In approach #1, you record latch in upper layer protocol TCB, communicate incoming/outgoing packet SA parameters between IPsec layer and ULP, effectively tags packets as they move up/down in the stack In datagram-oriented applications the latch would have to... Well, in datagram-oriented applications, if the user connected socket, UDP socket, they have to enforce latch. Then in approach #2, you record the latch in the PAD and SPD and enforce the latch at the IPsec policy layer. Slide 6: Approach #1: Intimate Interfaces ----------------------------------------- So approach #1 is the intimate interfaces, it effectively involves having interfaces between the ULP and IPsec, and you know, we need a mean to say, hey tell me how you protected this outgoing packet, and this incoming packet was protected like so, and protect this packets like so. Slide 7: Approach #2: PAD-based latching ---------------------------------------- PAD-based latching is a little more complicated, it basically requires ULP to create create template PAD entry. For listeners we create 3-tuple template PAD entry. For initiators we create 5-tuple PAD entry Packets that match a template PAD entry cause an actual PAD entry to be created. The child SA constraints are populated from the packet. The peer ID populated from the SA that protected the incoming packet. And on connection tear-down you have to remove the cloned PAD entry. Slide 8: Properties ------------------- Approach #1 works for connection-oriented and non-connection-oriented ULPs. For UDP applications can connect UDP sockets, or they can record and enforce the latch through ptokens, which is something we'll see in Michael's presentation, or sendmsg/recvmsg. The approach #2 also allows for UDP, but only in connected state. Approach #2 also needs a TIME_WAIT like state. This is because the tear-down of the flow and latch have to be atomic with respect to new flow triggers. The wait time is given by local latencies only, how long it takes for packets to move up and down in the stack. Slide 9: Properties ------------------- But of course approach #2 is very close to RFC4301 model and if you have a NIC that say provides ESP/AH/SPD offload but which don't provide a way to tag packets, then you need to do something like approach #2. Slide 10: APIs -------------- At it's simplest this is just the traditional connect()/accept() BSD socket-type APIs and they can work connection latching without the application even knowing. Slide 11: APIs -------------- But IPsec APIs can give applications much more power. Who am I really talking to, what is their IPsec ID, not their IP address but what is their certificate, or what IP did they assert. Specify/verify that a connection's QoP meet/meet. We can check whether the latch is ESP, AH, algorithms... We can do leap-of-faith if we know the peer public key, and so on. So you see this in Michael's and Miika's presentations and their I-Ds. Slide 12: BYPASS OR PROTECT --------------------------- Finally there's something that I don't know if it belongs to this draft or not. It's BYPASS or PROTECT. Basically for some things it would be nice if you could have the notion of optional IPsec protection so the example that I give there is BYPASS If you want to be able to leverage IPsec, you want to say hey if you can, give me IPsec, and give me channel bindings, and we'll do channel bindings with the RPCSEC_GESS layer. Well if you can't do IPsec.... If we can negotiate this use of IPsec, great, so I call this BYPASS OR PROTECT. In Approach #1 this is handled by the ULP or the application, you still need some sort of SPD entry that says BYPASS OR PROTECT and the application knows what to do. In Approach #2 this requires the same sort of things and some more. Slide 13: BYPASS OR PROTECT --------------------------- So in approach #1, the ULP and application is responsible. In approach #2, we need to have some sort of template SPD entry, and that works kind of like the template PAD entry that I described earlier. When a matching packet arrives, unprotected, clone a BYPASS entry for just that 5-tuple. When a matching packet arrives protected clone a PROTECT entry for just that 5-tuple. The ULP has to tear these down when the flows end. On outgoing flow initiating packets the application must tell the system what it wants really, and it must be able to do with IKE timeouts. So okay I'm not getting an IPsec protection, so I just close that socket. Slide 14: BYPASS OR PROTECT --------------------------- So this is the example I gave before. That's it. Questions: I should point out that there are implementation of connexion latching today, and some minimal set of APIs. If you use Solaris you can look at the man pages for ipsecconf(1M) that describes connexion latching and tells you that if you change policy your changes won't affect existing latching. And then the ipsec(7P) man page tells you what socket option you can use to request or check what algorithms are used, but you don't get to see what peer identities are used so it's a small primitive API. I think KAME also has an implementation although I'm not sure. Questions: ---------- Chair: Who read the draft? -> Two persons. Chair: Please read the draft and comment on the mailing list. --------------------------------------------------------------------------- C-Bindings for BTNS APIs (Miika Komu) --------------------------------------------------------------------------- Slide 1: -------- Hi everybody, My name is Miika Komu and I'll present work i did with Sasu Tarkoma, Nicolas Williams and Michael Richardson. Slide 2: What Problem Are We Solving? ------------------------------------- So the problem that we are solving in practice is how do we make application IPsec awarer. How can an application know that a connection is secured by IPsec? How can the application tell to use the BTNS extensions. How to do this using the C language with the socket API. Slide 3: Diagram ---------------- We are interested in two kind of applications, the ones that use only the IPsec API, and then application that also use TLS, GSS or SASL APIs. Slide 4: Relationship to GSS/SASL --------------------------------- So what's the difference then with these higher layer APIs, GSS and SASL. The fundamental difference is that they are not using socket descriptors. The IPsec API is tightly bound to socket descriptors, and can be used simultaneously with GSS and SASL. Slide 5: Policies ----------------- Here are the functions for handling policies. There are some accessors to create and get policies... Slide 6: Channel Bindings ------------------------- ... and the same for channel bindings. Slide 7: Changelog from 00 to 01 -------------------------------- And this is the changelog from 00 to 01... These are the old slides, I submitted new ones, but never mind. 00 only contained ideas, but now there's some concrete interfaces in the draft. Nico, Michael, Love and Julien have given me lots of feebdack. Slide 8: Todo list 1/3 ---------------------- Todo list is quite long, so anyway it means some more code examples, and definition of error values. Slide 9: Todo list 2/3 ---------------------- I'll fix the terminology in next version, the constants will be strings... Slide 10: Todo list 3/3 ----------------------- Comparison functions for attributes to see if one protection is stronger than another, but I am not sure it is needed. Then more attributes definitions, and also conversion fucntions so that we can get human readable. Also lot of editorial corrections. These were actually the minimal version of the slides, I submitted longer slides. Questions: ---------- Sam Hartman: You should submit slides you actually presented during the session. Please make sure you don't overwrite these with newest version. Chair: I'll send a link to the updated slides to the list, but proceedings will contained presented version. Chair: How many people read the draft? -> Not too many Sam Hartman: One thing would be to encourage reviewer to make sure that anything in this API is consistent with RFC4301. Michael Richardson: Sam when you say everything should be consistent with 4301, there are three interpretations I can take with that. Which is that a 4301 implementation, all 4301 implementation implement everything in here? Or that everything in here can be done by some subset of 4301? Or in fact does not contradict with 4301 but may in fact extend it so that strictly 4301 implementation may need to be extended to implement this specification? Sam: I propose that any... so first one, must not contradict 4301, that's clearly important that you know for example you should not be able to... so for example 4301 doesn't permit an implementation to... 4301 does not really have a concept of optional encryption like... I mean things like connexion latching, today I cannot say that it's okay for some people on application 1234 to use ESP and for some people it's okay not to use it. I can't express that. Michael: Right, that would be an extension. Sam: That would be an extension. Nico: But extensions are okay? Sam: No... Okay, Steve is actually going to argue that this is not an extension, Steve is going to argue that this is a fundamental change. So certainly no fundamental changes, and we can have debates about what they are, but I think Steve is going to be pretty firm on that one, that particular one. Another thing is that, it would be nice if there were no... I would say that extensions that are not covered by 4301 would be bad... for example 4301 ... like SPD selection functions, and so if you wanted ... that would be fine, if you wanted things that are beyond 4301 I don't think they should be specified here, they should be specified as part of another document. Things in 4301 should be sufficient to implement API. Nico: I don't know, why? Sam: I don't think... Michael Richardson: But the whole point of this whole effort is that people want to do things that they can't do with just 4301. The whole point is that we're trying to make applications that want to do things beyond that able to do things. So limited to what 4301 says you can do, which does not say anything about API, so we can't have an API with that argument. So clearly that's not what you mean. The biggest issue is how do you interface there, and actually Nico has addressed that in details in his draft on connexion latching, how do you implement things, and actually there's one version of how do you implement things that makes it much more difficult to do the things but it's possible to do that with BITW or BITS implementation using relatively stricts 4301 concepts, although they may need the PROTECT OR BYPASS concept to be able to cope with that. So with the additional, with the internet connexions to the upper layer protocols we actually don't need or want to really go through all of the 4301 mechanisms, we don't have to because we did a classification by virtue of the fact that, particurlarly in the downward direction, by virtue of the fact that we created the packet with knowledge of the SA we want to go in, and that's pretty much it , and we also know in the TCP sockets which SA specifically was supposed to be received on. So we actually don't need to go and look at what the actual values were and Steve Bellovin has argued that actually it's completely irrelevant what they are, what matters is the crypto check determining whether the packet should be accepted by TCP. To not check is an extension, but we don't need to say whether or not you go with that effort so some of the rules in the processing instructions can be implicitely skipped and there's some interesting advantages in doing that but functionally, the functions are still there because TCP rejects packets from non originating destinations anyway. So that's the question when you say, is it consistent with 4301, well we're saying that we get the same result if you implement it that way, but we're not saying we work forward identical. Sam: Steve, I am correct that you object as much as I think to the PROTECT OR BYPASS concept? Steve Kent: When we set up the working group initially we did had a long discussion on important features of providing BTNS functionality. An essential feature was to not undermine the access control functionality of an end system doing simultaneously BTNS and conventional IPsec protection, so I think the burden is on people writing these documents to explain how that is still satisfied, rather than you know picking an individual issue here, it's to show that when the thing is set-up, the criteria is still met. Nico: Ok. And I think nothing in connexion latching undermines access control. So connexion latching can be done without any API, sure. BYPASS OR PROTECT is not needed if you do connexion latching without any API. However there is a class of applications which today do one thing and which might do something different if they could use IPsec. They might be able to say "hey, can we get IPsec?" and if not let's do not IPsec. That's the only place where BYPASS OR PROTECT comes in. And that would be done using port selectors that narrow packet flows significantly only to these applications that know how to handle this. Therefore I think no access control feature of 4301 model would be violated. Sam: Ok what Steve said today is much broader that what he said last time. I think Steve... there is ... so ... I don't think that the API document should be defining extensions to IPsec, I think that those should be somewhere else and that the API document should be defining an API to use extensions that are defined elsewhere. I am asking for architectural cleanliness Nico: This particular extension is something that connexion latching... Sam: I am not talking about connexion latching. Nico: No, BYPASS OR PROTECT I guess? Sam: No, I'm talking about the API document. Nico: Ok, the API document does not specify extensions. Michael: Well if we continue, my talk will try to show another direction, and it will probably get more clear where we're going. We should actually have done the talks in the reverse order. Nico: Right because Michael's API is the abstract API, not the C API. Chair: So maybe Michael you present the abstract API now... Michael: Yes. --------------------------------------------------------------------------- BTNS API proposal overview (Michael Richardson) --------------------------------------------------------------------------- Actually I should but Bill Sommerfeld's name on these slides too. But I'm not so sure if he's still alive, I've heard he is but couldn't talk to him. Slide 1: Three objects ---------------------- Oh yeah, these are also not the last version. So, on Monday Nico convinced me to add this third bullet, on Tuesday he convinced me to remove it. So essentially we have two objects and we concluded that the third object was not a first class object but was rather an attribute of the second object. We have protection Token, that deals with the details of one session, so if you like you can link it to an IPsec SA. We don't really want to tell that the application knows too many details of that, but that's the kind of thing, they are specific to an SA, protection tokens have no scope outside of the process you're running in, don't expect to put them in a Jabber channel and have someone else knows what they mean or anything like that. So they're very very specific, they have some attributes, some of these attributes could be things like strength and key size and things like that. Absolutelly never the actual keys, they would never be revealled. And anyone who did that I think deserved to be slapped. Then we have identity tokens, identity tokens are... I take a protection token, you can get from that an identity token. An identity token somehow maps to something like a certificate or other type of things, and may have what we created what this crededntials token, and this is the notion that may tell you where to get your private key, specifically in the case where they might be offline, or in a kind of smartcard or something like that. Slide 2: Connected sockets -------------------------- So let's just talk about you how get things, and this maps a little bit to the details like the C-bindings that Miika has worked on. So let's talk first of a connected sockets, so TCP, SCTP, or UDP sockets that call connect(), so basically we're not going to change I/O operations basis. Initiator for these things is the end that calls connect(), and we suggest for simplicity and describing the whole situation that you also think of it as such because it called connect(), it also created the first packet, and therefore caused IKE to do something and create the IPsec SA. Clearly that connexion doesn't have to be here but it will make things much simpler for everyone to understand. The acceptor is the end that calls accept(), and therefore becomes the IKE responder, and it's the IKE responder before the accept() call terminates so this is important because the responder really doesn't know its policies until after it gots the connexion, and the initiator of course would like to express its policies before the connexion occurs, but it may actually not know the details until after it completes, ok? Slide 3: Use case #1 -------------------- So use case #1, call connect() as an initiator, and accept() as an acceptor, and you didn't say anything special, and you say okay get my protection token from the file descriptor that I got from this process, so in accept that's a brand new file descriptor connected. Then you say okay get my iToken from the pToken, and this tells me essentialy, from the cryptographic point of view, who I am connected to. And if I like I can take a channel binding out of that, feed it into my GSS API, connexion latching, do things like that, ah excuse me, into the channel binding and I'm pretty much set ok? This assumes that the reason why the system to setup an IPsec tunnel was determined by the system somehow, so there is PAD entry, an SPD entry that said, when you talk to this host or when you speak to this protocol or any number of various selectors that we have in the system, said I want to do IPsec for this connexion, so no contradiction no new things here, just IPsec occured for some reasons beyond the application's knowledge and the application now can find out that in fact it did happened. This case does not distinguish between the case where it might happened, like BYPASS OR PROTECT, we don't know the situation we don't know that there may ever be cases where it's not accepted. But if didn't go through, we didn't have IPsec, we'll find out at one of these two points that there was no IPsec there. Slide 4: Use case #2 -------------------- So use case 2 is initiator, so you said get me the identity of my remote guy bob with whom I wanted to talk to, and get a protection token, and this should be essentially use my default identity whatever that is, I'm not going to tell you, you figure out, you know, who I want to talk to, that's bob identity. At a high level that might be a DN, that might be a raw public key, that might be an IPsec address, or something else. At this level of the abstract API we're not really going to care about that. I have a file descriptor, I got it from my socket call, it's a newborn, I set my protection token on this. What does that mean at the bottom level? That means probably some kind of a template PAD entry goes into place, probably something that has everything relatively well specified except for the originating ports. Maybe it's a populate-from-packet... Sam: You mean SPD entry? Michael: Yeah I mean SPD entry, I'm sorry. And it calls connect(), and crypto happens. Acceptor is like use case 1, if you like... that call the connect call... Nico: It's actually a template PAD entry as I described in the connexion latching presentation, because we're saying we're trying to constrain the address in the selector for the child SA for this packet flow for what happened to a protected perr, and that happende in the back Sam: And in the SPD? Nico: And in the SPD, but specifically it happened in the PAD... Michael: That's why I wrote in my notes SPD/PAD, and I didn't really sort out what these things really are in my head, I just noted that I have a template that means the right thing. Emphasis that these are standard unpriviliged calls, there's some details as to what extent an unpriviliged application can override the system, that's to a system level setting to decide, that's well into the realm of local policy, and you should think about it, and take ... but I don't think this is a subject for standardization or really great discussion here, except to realize that's considerations that you will have to make. Sam: I disagree, I think that we actually do need needs to get in this space so that we can provide IPsec solutions for the protocols we standardize and people can understand how they interact with locally configured SPD entries, and that's something I talk a little bit about last week-end, and talked off-line to some people. Michael: So Sam, are you suggesting that we should have in our API a statement explaining under what circumstances an unpriviliged appplication may overrides a system policy? Sam: I am saying that use of IPsec 4301 should talk about how SPD entries from applications are combined with system SPD entries, and what ordering would be used. Not in your document, but in use IPsec 4301. Nico: But it is in IESG right now? Sam: No just use IPsec 4301. You said IPsec 4301... It's out of scope of your document Michael: I understand your concern and I agree there's a concern and if you feel there need to be a greater statement I would be doing that. Sam: I think it's out of scope of your document. Michael: Yes. Slide 5: Use case #3 -------------------- So this is initiator only, I say: I like to talk to Bob. And I say: By the way, on this multi-user system, my name is Alice (Francis or Julie). Furthermore, and this becomes different than in the other slide, somehow I have this magic PKCS11 session. Nico: It doesn't need to be PKCS11. Michael: Yeah, this is not the point, the point is that there's a real world example where you've logged into your desktop, your computer is remote but your crypto identity is actually local to you and the application can somehow access to it, and furthermore can tell the IKE how to talk to it. So that's the important part of it, that somehow this handle, it's like a file descriptor, that somehow you tell IKE use that identity, and the resaon why I say I'm Alice, that's because these are definitely the phase 1 ids that ared use in the parent SA. So now I can do the right thing. I get a protection token and I tell the system I want to use these things as part of it. I set the token on the file descriptor and call connect(). So then the identity and the credentials are determined by the application not the system. Slide 6: Use case #4 -------------------- This is on the other side, on the Bob side. Bob has said "I want to tell the guy I'm Bob", and on this socket when you respond you need to make sure that you set identity, so you set that on the file descriptor, we call accept, and afterwards you probably want to find out who connected to you, and do something. But of course you have to set your identity to respond with. Potentially there's an https problem here, where you can only have an identity per port 443 - IP address combination, because the crypto happens before the virtual host thing. There's no good solution to that, there were proposals some time ago to have the iniator say which responder they wanted to talk to. But in this case the issue is that they don't say I want to talk to Bob, I said I am Bob. I am unclear what happens. Maybe this is not a problem that we need to solve, just need to write the question. They connected to me they said they wanted to talk to Frank, but only Bob is listening. What does it connect to? are we allowed to have multiple listening on the same port number with different security associations? That's an interesting system question that you might ask. Sam: So, what is the purpose of Bob saying who he wants to be to accept? Michael: Well, listening to any application where there's a secondary data port like FTP, you may have a situation where control connection has Alice to Bob, and later on you open a data port for them to connect back again, so you're trying to express that on that port to listen on you don't want the system identity, but Bob's identity. Sam: Ok, but in the case where you are not the initiator... Nico: I have an answer, in practice this is odd because when somebody comes to you as a responder, they don't tell you right the way who they want, what selectors they're using. Michael: Right, but from an IKE point of view, you hope to discover the mismatch. Nico: Well but the only thing that really does is act as a fallback. And we could get rid of it because the application can always do the filtering itself. And we could also have a notification from IKE that said: Oh dude you really meant Bob. Sam: Actually I disagree, I think that's kind of the wrong way to deal with this. I think that what this is.. It serves two purposes, first of all, it says make this identity available, if people try to establish an IKE SA to Frances then let's do that. The second thing it does is it should if it turns out that you need to establish an SA in the reverse direction then it says who to use as your initiator identity. I don't think it makes sense to make this peer filter on one responder identity it already accepted. If you want that kind of filter, it should be on initiator side. And Initiator can do that and say : I want to talk to Bob. And if it can't get Bob, then that connect() fails. Slide 7: Unconnected sockets (datagrams) ---------------------------------------- The next discussion is for unconnected sockets. You should think of this a little bit as this is the interface between TCP connected systems and lower layers. Slide 8: Use case #5 -------------------- The protection, the people you're talking to can change on every packets. So you can't just get the data independently of the packet. You can't use read() or fread() calls to get this stuff out. You could get the identity out and protection token on every packet you receive, so somehow you have to get it out of the recvmsg() call, so I put it there but in reality it would come through ancillary data. So you get that each time, itoken, ptoken, and in this case the initiator identiy and credentail determined by the system. It's not clear for unconnected if you can really set who I am expecting to be before I connect to you. And you could do that again it would probably work. So you could set your Bob identity. Slide 9: Use case #6 -------------------- For the initiator you get protection token and you send the message with the protection token. Now that may be a template ptoken. We don't think that there's any guarantee that you could use the ancillary data cmsg as a value result parameter. So you put the ptoken in, we're not sure how to get the ptoken out again, the one that actually was used, the one that contains the parameter of the session that was actually created as that message was sent. Including non-templated PAD/SPD parts. So it's an open question how to do that for this. I think that a number of systems could just happily do it, but I don't think it's guaranteed by any spec we have. Again unprivileged calls. Slide 10: Similarities to GSSAPI -------------------------------- We intentionaly did this similar to GSSAPI. And in GSSAPI the ctoken has to be first class object because there's no other context to associate with, because GSSAPI just lives in whatever kind of bytestream. Use case 5 and 6 are not easily implemented for systems using connection-latching section 2.2 "Latching through PAD manipulations and extensions". If you are using "Intimate interfaces between ULPs and IPsec" this is really easy to do, I actually implemented it a year ago, for not actually for connected sockets, for unconnected sockets where you cannot use any kind of standard selectors because the host at the other end with the transport mode SA to .... The document that I wrote should become the abstract API, and Miika's document should become the C-bindings of the abstract API. This is fairly similar to the way GSSAPI did it. Nico told me to my surprise that the GSSAPI documents were actually standard track, not informational. We should ask the audience what do you think? Any objection to the approach? Sam: I think the abstract API presentation was very useful, we can solve issues with 4301, I think this is a very good model. I think it's not completely abstract... Michael: I wanted to say is that the only thing you get to is the socket, kernel is in charge of rest of the details. Sam: I think it's a very good thing. --------------------------------------------------------------------------- Wrap up (Chair) --------------------------------------------------------------------------- Last presentations on IKE extensions (2 slides) was skipped because we were overtime. Next step: - AS/PS to IESG after the meeting. - WGLC soon for Core. - Please read and commenst connexion latching then we WGLC it. - Please read API docs so that we can adopt them as WG items. - Please also read and comment short IKE extension draft. That's it. --------------------------------------------------------------------------- End of the meeting. --------------------------------------------------------------------------- From julien.IETF at laposte.net Mon Apr 2 04:49:20 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 2 Apr 2007 13:49:20 +0200 Subject: [anonsec] WGLC: "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec" In-Reply-To: <200703261403.45625.julien.IETF@laposte.net> References: <200703261403.45625.julien.IETF@laposte.net> Message-ID: <200704021349.20606.julien.IETF@laposte.net> Folks, We are already half-way thru this WGLC and no comments were posted to the mailing list yet. I'd like to encourage people to check the document and send a message to the list if they think it is ready to be submitted to IESG. Thanks. --julien, BTNS co-chair On Monday 26 March 2007 14:03, Julien Laganier wrote: > Folks, > > We would like to issue a WGLC on the following > document before submitting it to IESG for > publication as Proposed Standard: > > "Better-Than-Nothing-Security: An Unauthenticated > Mode of IPsec" > > -core-02.txt> > > If you have any comments, please send them to the > list and authors without changing the subject line > (OTOH if you want to discuss something not directly > related to this WGLC please do change the subject > line) > > The WGLC will end on 2007-04-09 (two weeks from > now). > > Best, > > -- Julien & Love, > BTNS chairs. > _______________________________________________ From kent at bbn.com Mon Apr 2 11:43:45 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 2 Apr 2007 14:43:45 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070328225901.GD1666@Sun.COM> References: <20070328225901.GD1666@Sun.COM> Message-ID: Nico, The existing 4301 model describes BYPASS and PROTECT as mutually exclusive descriptions. So, the new option, which might more properly be named "PROTECT IF POSSIBLE" is a third option that the user has to see as a distinct choice. So long as we represent this as a new option (which I think may be better reinforced by the name I suggested above), I don't think it undermines the 4301 model. Of course we still have to make sure that there is no overlap (in terms of address space or name space) between entries in the SPD that are described as PROTECT and ones that are labeled as "PROTECT IF POSSIBLE." The same is true for the PAD. These constrains are needed to satisfy the "don't undermine the existing 4301 access control model" criteria we discussed in Prague. Steve From paul at xelerance.com Mon Apr 2 20:13:43 2007 From: paul at xelerance.com (Paul Wouters) Date: Tue, 3 Apr 2007 05:13:43 +0200 (CEST) Subject: [anonsec] Preliminary minutes of BTNS@IETF68 In-Reply-To: <200704021110.21999.julien.IETF@laposte.net> References: <200704021110.21999.julien.IETF@laposte.net> Message-ID: On Mon, 2 Apr 2007, Julien Laganier wrote: > Attached are the preliminary minutes of the BTNS > session at IETF68. Please send corrections/additions > to the mailing list before 2007-04-09 (next Monday). Thanks for the excellent minutes. Is it possible to provide links to the presentations given? Paul From Nicolas.Williams at sun.com Mon Apr 2 21:56:28 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 2 Apr 2007 23:56:28 -0500 Subject: [anonsec] Preliminary minutes of BTNS@IETF68 In-Reply-To: References: <200704021110.21999.julien.IETF@laposte.net> Message-ID: <20070403045628.GP28748@Sun.COM> On Tue, Apr 03, 2007 at 05:13:43AM +0200, Paul Wouters wrote: > On Mon, 2 Apr 2007, Julien Laganier wrote: > > > Attached are the preliminary minutes of the BTNS > > session at IETF68. Please send corrections/additions > > to the mailing list before 2007-04-09 (next Monday). > > Thanks for the excellent minutes. > > Is it possible to provide links to the presentations given? They're on the proceedings page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68#wg-btns From Nicolas.Williams at sun.com Mon Apr 2 23:38:34 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 3 Apr 2007 01:38:34 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> Message-ID: <20070403063833.GU28748@Sun.COM> On Mon, Apr 02, 2007 at 02:43:45PM -0400, Stephen Kent wrote: > The existing 4301 model describes BYPASS and PROTECT as mutually > exclusive descriptions. So, the new option, which might more properly > be named "PROTECT IF POSSIBLE" is a third option that the user has to > see as a distinct choice. So long as we represent this as a new > option (which I think may be better reinforced by the name I > suggested above), I don't think it undermines the 4301 model. Thank you. I agree, PROTECT IF POSSIBLE is a better name. > Of course we still have to make sure that there is no overlap (in > terms of address space or name space) between entries in the SPD > that are described as PROTECT and ones that are labeled as "PROTECT > IF POSSIBLE." The same is true for the PAD. These constrains are > needed to satisfy the "don't undermine the existing 4301 access > control model" criteria we discussed in Prague. I agree, but this needs a bit of refinement. The point is that such overlap does not happen accidentally. First, administrators who want to write simple rules might appreciate a way to write few PROTECT or DISCARD rules that cover most traffic and PROTECT IF POSSIBLE that "punch holes" into the former for specific IPsec-aware applications. Second, IPsec-aware apps should not be able to create PROTECT IF POSSIBLE rules that punch holes in system policy that would PROTECT/ DISCARD the apps' traffic unless the apps are sufficiently privileged. OTOH, IPsec-aware apps should be able to PROTECT or PROTECT IF POSSIBLE traffic that would otherwise be BYPASSED. (This is the rule implemented in Solaris, BTW.) Nico -- From Nicolas.Williams at sun.com Mon Apr 2 23:41:14 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 3 Apr 2007 01:41:14 -0500 Subject: [anonsec] Preliminary minutes of BTNS@IETF68 In-Reply-To: <200704021110.21999.julien.IETF@laposte.net> References: <200704021110.21999.julien.IETF@laposte.net> Message-ID: <20070403064114.GV28748@Sun.COM> On Mon, Apr 02, 2007 at 10:10:21AM +0100, Julien Laganier wrote: > Folks, > > Attached are the preliminary minutes of the BTNS > session at IETF68. Please send corrections/additions > to the mailing list before 2007-04-09 (next Monday). Wow! Looks like you used the mp3 audio recording a lot to make these minutes. Thank you. Nico -- From miika at iki.fi Tue Apr 3 05:02:56 2007 From: miika at iki.fi (Miika Komu) Date: Tue, 3 Apr 2007 15:02:56 +0300 (EEST) Subject: [anonsec] BTNS C-bindings slides Message-ID: Hi all, below you can find an updated version of the BTNS C-bindings slides for IETF68. Unfortunately, we had an older version of the slides in the WG meeting. I had added a proper intro to the new slides, but otherwise they are the same: http://www.iki.fi/miika/docs/btns-api-ietf68.pdf -- Miika Komu http://www.iki.fi/miika/ From julien.IETF at laposte.net Tue Apr 3 06:26:42 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Tue, 3 Apr 2007 15:26:42 +0200 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <20070321170635.GD22445@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321170635.GD22445@Sun.COM> Message-ID: <200704031526.43271.julien.IETF@laposte.net> On Wednesday 21 March 2007 18:06, Nicolas Williams wrote: > On Wed, Mar 21, 2007 at 05:46:03PM +0100, Michael Richardson wrote: > > At lunch I was discussing the question of what the > > IKE/IPsec channel binding blog would be. > > I think you meant "blob" not "blog" :) > > We've discussed this before and the answer is: > > - the public key values of the two peers > concatenated in this order: channel initiator || > channel acceptor > > or some similar transformation of those two values. You might also want to do something similar to what HIP does: min(pk_i, pk_r) || max(pk_i, pk_r) so that the channel bindings between two peers is independent from who initiated the IKE exchange. --julien From julien.IETF at laposte.net Tue Apr 3 06:37:57 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Tue, 3 Apr 2007 15:37:57 +0200 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <20070401223158.GK8252@Sun.COM> References: <4601614B.3030207@sandelman.ca> <14575.1175463785@sandelman.ottawa.on.ca> <20070401223158.GK8252@Sun.COM> Message-ID: <200704031537.58414.julien.IETF@laposte.net> On Monday 02 April 2007 00:31, Nicolas Williams wrote: > On Sun, Apr 01, 2007 at 05:43:05PM -0400, Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > >>>>> "Nicolas" == Nicolas Williams > > >>>>> writes: > > > > Nicolas> - Imagine I send a SYN packet > > protected with some SA, say, Nicolas> SPI 1001, > > but the SYN|ACK does not arrive in time so I > > Nicolas> retransmit, only this time I use a new SA > > (SPI 1002, say) Nicolas> because, say, the old one > > expired. > > > > Nicolas> We can get into a weird situation: > > the SA that _I_ see Nicolas> as the one used to > > protect the channel creation trigger is Nicolas> > > _different_ from the one seen by my peer, so we > > fail to Nicolas> agree on channel binding! > > > > Perhaps, in this case, it should fail. > > Well, it will fail. But with the other channel > binding scheme it will succeed, as it should. > > We seem to be willing to accept this pathological > condition. The only question is: why not go with > the way that doesn't have this corner case? > > Possible reasons to reject > public-keys-of-peers-as-channel-bindings: > > - doesn't work for IKEv2 w/ EAP authentication When IKEv2 is used with EAP authentication, the channel binding blob could fallback from being peers' public keys to a PRF of the EAP MSK. Both peers know that EAP was used, so that doesn't even require additional signalling to let peers generate the appropriate blob. --julien From julien.IETF at laposte.net Tue Apr 3 07:12:18 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Tue, 3 Apr 2007 16:12:18 +0200 Subject: [anonsec] Preliminary minutes of BTNS@IETF68 In-Reply-To: <20070403064114.GV28748@Sun.COM> References: <200704021110.21999.julien.IETF@laposte.net> <20070403064114.GV28748@Sun.COM> Message-ID: <200704031612.18595.julien.IETF@laposte.net> On Tuesday 03 April 2007 08:41, Nicolas Williams wrote: > On Mon, Apr 02, 2007 at 10:10:21AM +0100, Julien Laganier wrote: > > Folks, > > > > Attached are the preliminary minutes of the BTNS > > session at IETF68. Please send > > corrections/additions to the mailing list before > > 2007-04-09 (next Monday). > > Wow! Looks like you used the mp3 audio recording a > lot to make these minutes. Thank you. Indeed. I'd like to thanks Joel Jaeggli and the team that implemented MP3 recording. --julien From mcr at sandelman.ottawa.on.ca Tue Apr 3 07:37:28 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 03 Apr 2007 10:37:28 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Message from Julien Laganier of "Tue, 03 Apr 2007 15:37:57 +0200." <200704031537.58414.julien.IETF@laposte.net> References: <4601614B.3030207@sandelman.ca> <14575.1175463785@sandelman.ottawa.on.ca> <20070401223158.GK8252@Sun.COM> <200704031537.58414.julien.IETF@laposte.net> Message-ID: <22734.1175611048@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Julien" == Julien Laganier writes: >> We seem to be willing to accept this pathological condition. The >> only question is: why not go with the way that doesn't have this >> corner case? >> >> Possible reasons to reject >> public-keys-of-peers-as-channel-bindings: >> >> - doesn't work for IKEv2 w/ EAP authentication Julien> When IKEv2 is used with EAP authentication, the channel Julien> binding blob could fallback from being peers' public keys to Julien> a PRF of the EAP MSK. Both peers know that EAP was used, so Julien> that doesn't even require additional signalling to let peers Julien> generate the appropriate blob. This suffers from all the problems that using something derived from the DH SKEYSEED has. I don't see a *BTNS* case for doing EAP and then using channel binding, but I might be wrong. (I can see BTNS for PARENT_SA "authentication", and then EAP for further authentication of the SA, but at which point, it might be unnecessary to actually do a channel binding. That's is in theory, but perhaps in practice, there isn't the total awareness necessary to avoid this.) I raised this question, because I felt that it needed to be resolved in some way, or resolved that we are comfortable with what we had already. The above proposal has the advantage that, like the concatenated public keys, it can be checked with memcmp(). This is the fundamental API issue. Is the API: #1 memcpy suffices: u_char *my_channel_binding_blob; int my_channel_binding_blob_len; u_char *his_channel_binding_blob; int his_channel_binding_blob_len; ipsec_get_iToken_attr(iToken, CHANNEL_BINDING, &my_channel_binding_blob, &my_channel_binding_blob_len); gssapi_somefoo_send_channel_binding(my_channel_binding_blob, my_channel_binding_blob_len); /* do I look like I know anything about gssapi? */ gssapi_somefoo_recv_channel_binding(&his_channel_binding_blob, &his_channel_binding_blob_len); if(my_channel_binding_blob_len == his_channel_binding_blob_len && memcmp(my_channel_binding_blob, his_channel_binding_blob, his_channel_binding_blob_len)==0)) { return TRUE; } else { printf("Mallor has been seen!\n"); return FALSE; } #2 channel binding needs to be checked: u_char *my_channel_binding_blob; int my_channel_binding_blob_len; u_char *his_channel_binding_blob; int his_channel_binding_blob_len; ipsec_get_iToken_attr(iToken, CHANNEL_BINDING, &my_channel_binding_blob, &my_channel_binding_blob_len); gssapi_somefoo_send_channel_binding(my_channel_binding_blob, my_channel_binding_blob_len); /* do I look like I know anything about gssapi? */ gssapi_somefoo_recv_channel_binding(&his_channel_binding_blob, &his_channel_binding_blob_len); if(ipsec_check_channel_binding(my_channel_binding_blob, my_channel_binding_blob_len, his_channel_binding_blob, his_channel_binding_blob_len) { { return TRUE; } else { printf("Mallor has been seen!\n"); return FALSE; } Obviously, case #1 can be implemented inside of case #2. Case #2 may, however, involve a round trip through the kernel to talk to the keying deamon if the channel binding blob can not be fully authenticated without key material that the keying daemon prefers not to disclose. - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhJmpoCLcPvd0N1lAQJjOQf7BODO76X1E5uQUacDJN/TtGoesesJ1MJh /BjBB3yCmj20C4GjAXkJh4biwvS8/0E+H90i+aHTdtVUckvictGwgDQL+CXGAQkm 77q6maFB13PSLPHLpsc2nctmk8l4AI6MMRUBmWuFrt/C9D0k6GGrhr/q5cOSbNtJ cygPsaKSoFa5RJ4Sb9yeF+l5yZu/QzRBrncbRZPIs2ELG0J9IInXB/uw3a1NH00x +uc5ax2n3YokXK2FdG3sePhcPxMBWUcYKIQwN9ochThrxIZ6tT51Ua0h2DIlyKEw AiDeL6kMS+Atx8FosWQLbAynJMzl+frtivOfRTjKRburqZPMcBembQ== =PS/1 -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Tue Apr 3 07:39:46 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 03 Apr 2007 10:39:46 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Message from Julien Laganier of "Tue, 03 Apr 2007 15:26:42 +0200." <200704031526.43271.julien.IETF@laposte.net> References: <4601614B.3030207@sandelman.ca> <20070321170635.GD22445@Sun.COM> <200704031526.43271.julien.IETF@laposte.net> Message-ID: <22964.1175611186@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Julien" == Julien Laganier writes: Julien> You might also want to do something similar to what HIP Julien> does: Julien> min(pk_i, pk_r) || max(pk_i, pk_r) so that the channel Julien> bindings between two peers is independent from who initiated Julien> the IKE exchange. I agree that perhaps this makes more sense. I was going to propose ordering by ordered IP addresses, but this is perhaps more cool. - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhJnJoCLcPvd0N1lAQKUwgf7BwOfcdlyh1SDroIKd9QWjylkqv99KwJ3 7VMEQeBosZKsJQjAK5S4tpiL1G2NGyxMUqSA0PjXGhKoyOhDRFBvE0ykNAJn/mZ6 c3hR3JAcz9ZAZlvCjfWJ19Wm/ZxLoR4J+aYg3/LSzE4LZLQ9/QvK70V4XDue9us/ oZqGnySygeYmZCFidPfiwLfVT+aryJsOXQfI9QmrchmfSSek1SUZat7xwQJFE9vZ 5eic0jL73zHuuvYf/eC532bVU1a9v+Hl05YJvH2gl3tqrfNfRkhya5OfonfY2qyB 6Sn8GdUuNKLgqAYzlC/2trG3mFZGiXc/KXarmLZLWXf6jNp2MjNdgw== =80ek -----END PGP SIGNATURE----- From mcr at sandelman.ca Tue Apr 3 09:29:34 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 03 Apr 2007 12:29:34 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070328225901.GD1666@Sun.COM> References: <20070328225901.GD1666@Sun.COM> Message-ID: Nicolas Williams wrote: > You may also recall that in the case of the core BTNS document the > access control issue had been about ensuring that BTNS peers not be > allowed to assert traffic selectors that non-BTNS peers are allowed to > assert. And recall that we addressed this by providing that the PAD be > searched twice, once at authentication time and once at CHILD SA > creation time, the latter to find that the asserted traffic selectors do > not overlap with ones reserved for non-BTNS peers. I want to say that Openswan does precisely this when it implements Opportunistic Encryption a la RFC4322. From mcr at sandelman.ca Tue Apr 3 09:31:27 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 03 Apr 2007 12:31:27 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> Message-ID: Stephen Kent wrote: > The existing 4301 model describes BYPASS and PROTECT as mutually > exclusive descriptions. So, the new option, which might more properly > be named "PROTECT IF POSSIBLE" is a third option that the user has to As this is used primarily on the responder, I suggest th wording be infact: "PROTECT IF REQUESTED" > Of course we still have to make sure that there is no overlap (in > terms of address space or name space) between entries in the SPD > that are described as PROTECT and ones that are labeled as "PROTECT > IF POSSIBLE." The same is true for the PAD. These constrains are This is a general problem in the PAD, and SPD with overlapping items. i.e. this problem already exists, and has been solved. From mcr at sandelman.ca Tue Apr 3 09:43:21 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 03 Apr 2007 12:43:21 -0400 Subject: [anonsec] Preliminary minutes of BTNS@IETF68 In-Reply-To: References: <200704021110.21999.julien.IETF@laposte.net> Message-ID: Paul Wouters wrote: > Is it possible to provide links to the presentations given? These are the foils that I had intended to present. http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf68/btnsAPIAbstract.html http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf68/ietf68api.pdf This has the cToken removed. http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf68/ietf68ikeextend.pdf two slides, not much to say. submitted to ID editor: http://www.sandelman.ca/SSW/ietf/ipsec/btns/richardson-btns-ikeextensions-00.txt I will revise this some more first. http://www.sandelman.ca/SSW/ietf/ipsec/btns/richardson-btns-abstract-api-00.txt From yaronf at checkpoint.com Tue Apr 3 23:53:35 2007 From: yaronf at checkpoint.com (Yaron Sheffer) Date: Wed, 04 Apr 2007 09:53:35 +0300 Subject: [anonsec] draft-richardson-btns-ikeextensions-00 Message-ID: <46134B6F.8090904@checkpoint.com> Mostly nits, some bigger comments. * If the use of Raw RSA is "clarified", shouldn't this draft "update" RFC 4306 (or worse, RFC 4718)? * Sec. 2: "It *SHOULD be sent in after *the phase 1 SA has become private," - I guess you mean "SHOULD be sent *only* after. * Typo: "Aggressive mode *is *SHOULD NOT". * Sec. 3: "This code point is hereby defined for IKEv1" - this should also go into the IANA Considerations. * KEY is capitalized a number of times. * Sec. 5: "It details the order in which to look for authentication data for a protocol which does not in itself require any authentication data." This sentence baffled me. What do you mean? Does this imply that no further security analysis is required? Thanks, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070404/2edd4baf/attachment.html From julien.IETF at laposte.net Wed Apr 4 01:51:47 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 4 Apr 2007 10:51:47 +0200 Subject: [anonsec] Fwd: I-D ACTION:draft-richardson-btns-ikeextensions-00.txt Message-ID: <200704041051.47589.julien.IETF@laposte.net> FYI --julien -------------- next part -------------- An embedded message was scrubbed... From: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-richardson-btns-ikeextensions-00.txt Date: Tue, 03 Apr 2007 15:50:02 -0400 Size: 5794 Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070404/db84d001/attachment.mht From kent at bbn.com Wed Apr 4 08:17:57 2007 From: kent at bbn.com (Stephen Kent) Date: Wed, 4 Apr 2007 11:17:57 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070403063833.GU28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> Message-ID: At 1:38 AM -0500 4/3/07, Nicolas Williams wrote: >On Mon, Apr 02, 2007 at 02:43:45PM -0400, Stephen Kent wrote: >> The existing 4301 model describes BYPASS and PROTECT as mutually >> exclusive descriptions. So, the new option, which might more properly >> be named "PROTECT IF POSSIBLE" is a third option that the user has to >> see as a distinct choice. So long as we represent this as a new >> option (which I think may be better reinforced by the name I >> suggested above), I don't think it undermines the 4301 model. > >Thank you. I agree, PROTECT IF POSSIBLE is a better name. > >> Of course we still have to make sure that there is no overlap (in >> terms of address space or name space) between entries in the SPD >> that are described as PROTECT and ones that are labeled as "PROTECT >> IF POSSIBLE." The same is true for the PAD. These constrains are >> needed to satisfy the "don't undermine the existing 4301 access >> control model" criteria we discussed in Prague. > >I agree, but this needs a bit of refinement. The point is that such >overlap does not happen accidentally. > >First, administrators who want to write simple rules might appreciate a >way to write few PROTECT or DISCARD rules that cover most traffic and >PROTECT IF POSSIBLE that "punch holes" into the former for specific >IPsec-aware applications. > >Second, IPsec-aware apps should not be able to create PROTECT IF >POSSIBLE rules that punch holes in system policy that would PROTECT/ >DISCARD the apps' traffic unless the apps are sufficiently privileged. >OTOH, IPsec-aware apps should be able to PROTECT or PROTECT IF POSSIBLE >traffic that would otherwise be BYPASSED. (This is the rule implemented >in Solaris, BTW.) Good points. I think this says we may need another SPD extension, one that marks rules as ones that are inviolable, vs. ones that may be overridden by a user/app as you described above. Steve From kent at bbn.com Wed Apr 4 08:22:04 2007 From: kent at bbn.com (Stephen Kent) Date: Wed, 4 Apr 2007 11:22:04 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> Message-ID: At 12:31 PM -0400 4/3/07, Michael Richardson wrote: >Stephen Kent wrote: >> The existing 4301 model describes BYPASS and PROTECT as mutually >> exclusive descriptions. So, the new option, which might more properly >> be named "PROTECT IF POSSIBLE" is a third option that the user has to > > As this is used primarily on the responder, I suggest th wording be infact: > "PROTECT IF REQUESTED" Does the spec say that it is used ONLY by a responder? If so, then your wording sounds better. If not, ... > >> Of course we still have to make sure that there is no overlap (in >> terms of address space or name space) between entries in the SPD >> that are described as PROTECT and ones that are labeled as "PROTECT >> IF POSSIBLE." The same is true for the PAD. These constrains are > > This is a general problem in the PAD, and >SPD with overlapping items. i.e. this problem already exists, and >has been solved. I'm not quite sure what you mean above. The ordering of the PAD and SPD allows one to have overlapping entries, but those were entries that all had the same precedence, and which offer a binary choice. The notion of PROTECT IF REQUESTED/POSSIBLE is a new concept with different semantics and that's why I believe we have to be more sophisticated in how we add this feature to the PAD and SPD. Steve From julien.IETF at laposte.net Wed Apr 4 08:36:08 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 4 Apr 2007 17:36:08 +0200 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <22734.1175611048@sandelman.ottawa.on.ca> References: <4601614B.3030207@sandelman.ca> <200704031537.58414.julien.IETF@laposte.net> <22734.1175611048@sandelman.ottawa.on.ca> Message-ID: <200704041736.08814.julien.IETF@laposte.net> On Tuesday 03 April 2007 16:37, Michael Richardson wrote: > Julien Laganier writes: > > >> Possible reasons to reject > >> public-keys-of-peers-as-channel-bindings: > >> > >> - doesn't work for IKEv2 w/ EAP > >> authentication > > > When IKEv2 is used with EAP > > authentication, the channel binding blob > > could fallback from being peers' public keys to > > a PRF of the EAP MSK. Both peers know that > > EAP was used, so Julien> that doesn't even require > > additional signalling to let peers generate > > the appropriate blob. > > This suffers from all the problems that using > something derived from the DH SKEYSEED has. I don't > see a *BTNS* case for doing EAP and then using > channel binding, but I might be wrong. I don't see a case either. If EAP is used it means that both peers were authenticated at the IPsec layer (the initiator via EAP, the responder via a certificate, and possibly also via EAP mutual authentication). Why would someone want to authenticate "again" at the IPsec layer via channel binding with an ULP... Still it might be compelling to provide a channel binding method anyway in case we're both wrong... > (I can see BTNS for PARENT_SA "authentication", > and then EAP for further authentication of the SA, > but at which point, it might be unnecessary to > actually do a channel binding. That's is in theory, > but perhaps in practice, there isn't the total > awareness necessary to avoid this.) > > I raised this question, because I felt that it > needed to be resolved in some way, or resolved that > we are comfortable with what we had already. The > above proposal has the advantage that, like the > concatenated public keys, it can be checked with > memcmp(). Yes. > This is the fundamental API issue. Is the API: > > #1 memcpy suffices: > > [...] if(my_channel_binding_blob_len == his_channel_binding_blob_len && memcmp(my_channel_binding_blob, his_channel_binding_blob, his_channel_binding_blob_len)==0)) > [...] > > #2 channel binding needs to be checked: > > [...] if(ipsec_check_channel_binding(my_channel_binding_blob, my_channel_binding_blob_len, his_channel_binding_blob, his_channel_binding_blob_len) > Obviously, case #1 can be implemented inside of case > #2. Case #2 may, however, involve a round trip > through the kernel to talk to the keying deamon if > the channel binding blob can not be fully > authenticated without key material that the keying > daemon prefers not to disclose. I think it's good if we spare the additional userland-kernel RTT. --julien From Nicolas.Williams at sun.com Wed Apr 4 08:47:59 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 10:47:59 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> Message-ID: <20070404154758.GH28748@Sun.COM> On Wed, Apr 04, 2007 at 11:17:57AM -0400, Stephen Kent wrote: > Good points. I think this says we may need another SPD extension, > one that marks rules as ones that are inviolable, vs. ones that may > be overridden by a user/app as you described above. Another way to look at it is to have system policy determine insertion points into the SPD for app-requested rules -- since the SPD is ordered then the insertion points determine what rules the apps can "punch holes" into. There could be multiple such insertion points, corresponding to multiple local privilege levels. So the SPD extension, then, would be a rule type that declares an insertion point for specific applications or local privileges. Since there's more than one way to represent this we need English- language text and a canonical representation that implementors can ignore, provided that they provide equivalent functionality. Personally I prefer the insertion point approach since it does not require modifying existing rules. Your notion of "inviolable" rules maps into placing such rules ahead of any insertion points. Nico -- From kent at bbn.com Wed Apr 4 09:06:22 2007 From: kent at bbn.com (Stephen Kent) Date: Wed, 4 Apr 2007 12:06:22 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070404155014.GJ3157@sun.com> References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404155014.GJ3157@sun.com> Message-ID: At 11:50 AM -0400 4/4/07, Dan McDonald wrote: >On Wed, Apr 04, 2007 at 11:17:57AM -0400, Stephen Kent wrote: >> >Second, IPsec-aware apps should not be able to create PROTECT IF >> >POSSIBLE rules that punch holes in system policy that would PROTECT/ >> >DISCARD the apps' traffic unless the apps are sufficiently privileged. >> >OTOH, IPsec-aware apps should be able to PROTECT or PROTECT IF POSSIBLE >> >traffic that would otherwise be BYPASSED. (This is the rule implemented >> >in Solaris, BTW.) >> >> Good points. I think this says we may need another SPD extension, >> one that marks rules as ones that are inviolable, vs. ones that may >> be overridden by a user/app as you described above. > >For example, OpenSolaris has "inviolable" as a global flag (which is disabled >by default) for the entire SPD. The only exception to sockets overriding the >SPD is for a socket that wishes to PASS - the process that wishes to PASS >MUST be privileged AND the "inviolable" flag MUST be disabled. > >Having per-rule inviolability is a good idea, but we need to consider apps >AND their privileges. For another example, I really want my IKE daemon to >speak in the clear REGARDLESS of the contents of the SPD. > >Dan Dan, I think the WG has to discuss just what semantics we need for the flag, but it's good to know that some implementations have analogous capabilities now. I'm pretty sure 4301 says that IKE messages cross the IPsec boundary and that there need to be SPD entries to enable this, so your last comment above is in conflict with that. Steve From mcr at sandelman.ottawa.on.ca Wed Apr 4 10:09:51 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Wed, 04 Apr 2007 13:09:51 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: Message from Stephen Kent of "Wed, 04 Apr 2007 11:22:04 EDT." References: <20070328225901.GD1666@Sun.COM> Message-ID: <8083.1175706591@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Stephen" == Stephen Kent writes: Stephen> At 12:31 PM -0400 4/3/07, Michael Richardson wrote: >> Stephen Kent wrote: >>> The existing 4301 model describes BYPASS and PROTECT as mutually >>> exclusive descriptions. So, the new option, which might more >>> properly be named "PROTECT IF POSSIBLE" is a third option that >>> the user has to >> As this is used primarily on the responder, I suggest th wording >> be infact: "PROTECT IF REQUESTED" Stephen> Does the spec say that it is used ONLY by a responder? If Stephen> so, then your wording sounds better. If not, ... 1) BTNS says nothing about how nodes know to do BTNS. We explicitely left out discovery. So, an initiator would have to some some PAD/SPD entry that told it to do something. If that thing was "PROTECT IF REQUESTED", and the application requested protection, then that wording would fit. 2) I think that it does make most sense to have such entries on the responder. I expect to see more clear "PROTECT" entries on the "clients" (I use that label vs initiator, on purpose) >>> Of course we still have to make sure that there is no overlap >>> (in terms of address space or name space) between entries in the >>> SPD that are described as PROTECT and ones that are labeled as >>> "PROTECT IF POSSIBLE." The same is true for the PAD. These >>> constrains are >> This is a general problem in the PAD, and SPD with overlapping >> items. i.e. this problem already exists, and has been solved. Stephen> I'm not quite sure what you mean above. The ordering of the Stephen> PAD and SPD allows one to have overlapping entries, but Stephen> those were entries that all had the same precedence, and Stephen> which offer a binary choice. The notion of PROTECT IF Stephen> REQUESTED/POSSIBLE is a new concept with different Stephen> semantics and that's why I believe we have to be more Stephen> sophisticated in how we add this feature to the PAD and Stephen> SPD. Can you give me an example of an ordered PAD that would still be ambiguous? Your word "precedence" is funny to me, since the entries don't have the same precedence if they are ordered. - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhPb3oCLcPvd0N1lAQLnIQgAoREwgSeUNiOmcig3PTCVbc36m0fjim0O 0mF2hEl3oGYxXdEIxfHu/mbhaP1dTW6M07l/I6zIslD2FKBRZWC/pooWhpZS/xdf jHFVj7KhmcZIDW3M4b+S7Gg5KSvg/P9NhpuT2Av8SyPIp6qzLzlPn+pzGnmsiSfG Ox36yWMtn9RuBL9PKT8SyD3hD2XZlWJTTJubeIvintMMeLuT3TyUbhOlP/V6tu2G dqLzoIr6T+724SBCSv5uYgWfeafO+KPAHCsS8riz/Kgv0TG+mSTN04L4DjmeaGUF ZlBtAMBuYDp1ekw221ZVD5vQZmafexde1JvANnF1Kmm+xILNfNloow== =gTKk -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Wed Apr 4 10:27:30 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 12:27:30 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <8083.1175706591@sandelman.ottawa.on.ca> References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> Message-ID: <20070404172729.GP28748@Sun.COM> On Wed, Apr 04, 2007 at 01:09:51PM -0400, Michael Richardson wrote: > >>>>> "Stephen" == Stephen Kent writes: > Stephen> I'm not quite sure what you mean above. The ordering of the > Stephen> PAD and SPD allows one to have overlapping entries, but > Stephen> those were entries that all had the same precedence, and > Stephen> which offer a binary choice. The notion of PROTECT IF > Stephen> REQUESTED/POSSIBLE is a new concept with different > Stephen> semantics and that's why I believe we have to be more > Stephen> sophisticated in how we add this feature to the PAD and > Stephen> SPD. > > Can you give me an example of an ordered PAD that would still be > ambiguous? > Your word "precedence" is funny to me, since the entries don't have > the same precedence if they are ordered. I too wondered about the "but those were entries that all had the same precedence" bit -- these are ordered lists, so no two rules can have the "sam precedence." From Nicolas.Williams at sun.com Wed Apr 4 12:08:18 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 14:08:18 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> Message-ID: <20070404190817.GR28748@Sun.COM> On Tue, Apr 03, 2007 at 12:31:27PM -0400, Michael Richardson wrote: > Stephen Kent wrote: > > The existing 4301 model describes BYPASS and PROTECT as mutually > > exclusive descriptions. So, the new option, which might more properly > > be named "PROTECT IF POSSIBLE" is a third option that the user has to > > As this is used primarily on the responder, I suggest th wording be infact: > "PROTECT IF REQUESTED" Actually, these rules might not be used at all by administrators, but be created dynamically by applications. In any case, they are used on both sides (client and server). We could just call them TEMPLATE BYPASS OR PROTECT (yes, I still like the name I picked originally) -- something that indicates: a) the fact these aren't rules as such but rules that give rise to flow-specific rules, and b) that the latter may be either BYPASS or PROTECT rules. Nico -- From Nicolas.Williams at sun.com Wed Apr 4 12:39:49 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 14:39:49 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <200704031537.58414.julien.IETF@laposte.net> References: <4601614B.3030207@sandelman.ca> <14575.1175463785@sandelman.ottawa.on.ca> <20070401223158.GK8252@Sun.COM> <200704031537.58414.julien.IETF@laposte.net> Message-ID: <20070404193948.GS28748@Sun.COM> On Tue, Apr 03, 2007 at 03:37:57PM +0200, Julien Laganier wrote: > > - doesn't work for IKEv2 w/ EAP authentication > > When IKEv2 is used with EAP authentication, the channel > binding blob could fallback from being peers' public > keys to a PRF of the EAP MSK. Both peers know that EAP > was used, so that doesn't even require additional > signalling to let peers generate the appropriate blob. That's true, we could do that. We could also specify both kinds of channel binding for IPsec and let ULPs and/or application protocols decide which to use. For example: TCP (and any protocol like it that has a handshake at the beginning) can recover from IKE_SA expiration by simply not retransmitting the SYN packet protected with an SA such that the SKEYSEED-based channel bindings would be different than for the first SYN -- instead TCP can fail the connect() with a suitable error code or even begin again with a new 5-tuple (diff client side ephemeral port #). Whereas for "connected" UDP we either have to accept that SKEYSEED-based channel bindings break across IKE_SA expiration/abandonment or we have to accept end-point public keys as the channel bindings. For unconnected UDP we can leave the matter to the application: if it has a TCP-like handshake then the app can deal with SKEYSEED-based channel bindings just like TCP could, else see above. This could be a suitable compromise because it means we can have unique channel bindings (SKEYSEED-based) in more places. "Unique channel bindings" are preferable over "end-point channel bindigs" because they can double as nonce/challenge in application layers to obtain authentication replay protection with fewer messages or w/o clock synchronization + replay caches. Nico -- From Nicolas.Williams at sun.com Wed Apr 4 12:41:39 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 14:41:39 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <200704031526.43271.julien.IETF@laposte.net> References: <4601614B.3030207@sandelman.ca> <20070321170635.GD22445@Sun.COM> <200704031526.43271.julien.IETF@laposte.net> Message-ID: <20070404194138.GT28748@Sun.COM> On Tue, Apr 03, 2007 at 03:26:42PM +0200, Julien Laganier wrote: > You might also want to do something similar to what HIP > does: > > min(pk_i, pk_r) || max(pk_i, pk_r) so that the channel > bindings between two peers is independent from who > initiated the IKE exchange. We've long known we'd have to do something like that because initiator/responder at the IKE layer can be the opposite of client/server roles at the ULP or higher layers. (TCP-like protocols can always figure out which is which and put the two public keys in client || server order. From Nicolas.Williams at sun.com Wed Apr 4 12:42:45 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 14:42:45 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <22964.1175611186@sandelman.ottawa.on.ca> References: <4601614B.3030207@sandelman.ca> <20070321170635.GD22445@Sun.COM> <200704031526.43271.julien.IETF@laposte.net> <22964.1175611186@sandelman.ottawa.on.ca> Message-ID: <20070404194245.GU28748@Sun.COM> On Tue, Apr 03, 2007 at 10:39:46AM -0400, Michael Richardson wrote: > I was going to propose ordering by ordered IP addresses, but this is > perhaps more cool. I don't believe that you'd think of ordering by IP addresses when you're also so concerned about support for NAT! ;) From Nicolas.Williams at sun.com Wed Apr 4 12:56:17 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 14:56:17 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <22734.1175611048@sandelman.ottawa.on.ca> References: <4601614B.3030207@sandelman.ca> <14575.1175463785@sandelman.ottawa.on.ca> <20070401223158.GK8252@Sun.COM> <200704031537.58414.julien.IETF@laposte.net> <22734.1175611048@sandelman.ottawa.on.ca> Message-ID: <20070404195616.GV28748@Sun.COM> On Tue, Apr 03, 2007 at 10:37:28AM -0400, Michael Richardson wrote: > I don't see a *BTNS* case for doing EAP and then > using channel binding, but I might be wrong. Well, I don't see a use for channel binding to EAP-authenticated IPsec channels (subtle difference). That's because EAP, by its applicability, would be used in IPsec VPN-type use cases, and so the end-points of the channel would be the client and the SG, which have already authenticated each other, so why authenticate again at the application layer? > (I can see BTNS for PARENT_SA "authentication", and then EAP for > further authentication of the SA, but at which point, it might be > unnecessary to actually do a channel binding. That's is in theory, but > perhaps in practice, there isn't the total awareness necessary to avoid > this.) Well, the channel binding could be done inside EAP, and this could be used to enroll client public keys (a useful use case if you want to do two-factor authentication where one factor is a BTNS key and it is enrolled by one-time one-factor authentication). > I raised this question, because I felt that it needed to be resolved > in some way, or resolved that we are comfortable with what we had > already. The above proposal has the advantage that, like the > concatenated public keys, it can be checked with memcmp(). Unique and end-point channel bindings can both be checked with memcmp() (or memcmp() of a hash/MAC of the channel bindings). > /* do I look like I know anything about gssapi? */ No :) Look at RFC2743 or RFC2744 and look at the function signatures for GSS_Init_sec_context()/GSS_Accept_sec_context(). In the GSS-API (and in SASL/GS2) channel bindings are as an input to a black box at each peer -- both have to provide the same channel binding octet strings, else -> failure[*]. The black box can (and does, e.g., in the case of the Kerberos V GSS mech) cause hashes/MACs of the channel bindings octet strings to be exchanged. [*] Total failure in the GSS-API case, partial failure for SASL/GS2. Nico -- From Nicolas.Williams at sun.com Wed Apr 4 15:11:44 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 4 Apr 2007 17:11:44 -0500 Subject: [anonsec] BTNS C-bindings slides In-Reply-To: References: Message-ID: <20070404221144.GA28748@Sun.COM> On Tue, Apr 03, 2007 at 03:02:56PM +0300, Miika Komu wrote: > http://www.iki.fi/miika/docs/btns-api-ietf68.pdf BTW, channel bindings are best thought of as a property of pTokens, not iTokens. Unique channel bindings (e.g., if we go the SKEYSEED route) can only be associated with specific channel instances, whereas end-point channel bindings can be associated with either the channel or the end-point identities. Also, we need to apply a small transformation to the end-point public keys in order to produce a channel binding octet string (see other posts from Julien, Michael). Therefore it's best to always think of channel bindings as an attribute of a channel. Also, a peer identity (iToken) might have multiple names (though only one asserted name); its asserted name will never be a public key unless the peer is a BTNS peer. We do, however, want the peer public keys, if there are any, to be available through the iToken. Recap: channel binding octet string -> attribute of pToken end-point public keys values -> attribute of iToken Nico -- From kent at bbn.com Thu Apr 5 04:18:07 2007 From: kent at bbn.com (Stephen Kent) Date: Thu, 5 Apr 2007 07:18:07 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070404154758.GH28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> Message-ID: At 10:47 AM -0500 4/4/07, Nicolas Williams wrote: >On Wed, Apr 04, 2007 at 11:17:57AM -0400, Stephen Kent wrote: >> Good points. I think this says we may need another SPD extension, >> one that marks rules as ones that are inviolable, vs. ones that may >> be overridden by a user/app as you described above. > >Another way to look at it is to have system policy determine insertion >points into the SPD for app-requested rules -- since the SPD is ordered >then the insertion points determine what rules the apps can "punch >holes" into. There could be multiple such insertion points, >corresponding to multiple local privilege levels. one could do that, although I worry that this sounds fairly complex, especially because it sounds like changes in SPD affect where different rules apply. >So the SPD extension, then, would be a rule type that declares an >insertion point for specific applications or local privileges. how would one define the insertion point in a way that doesn't get too complex? >Since there's more than one way to represent this we need English- >language text and a canonical representation that implementors can >ignore, provided that they provide equivalent functionality. agreed. >Personally I prefer the insertion point approach since it does not >require modifying existing rules. Your notion of "inviolable" rules >maps into placing such rules ahead of any insertion points. I see what you mean, and I appreciate the generality, but I do worry about creating a sophisticated access control capability that will induce management errors. Steve From kent at bbn.com Thu Apr 5 04:32:37 2007 From: kent at bbn.com (Stephen Kent) Date: Thu, 5 Apr 2007 07:32:37 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070404172729.GP28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> <20070404172729.GP28748@Sun.COM> Message-ID: At 12:27 PM -0500 4/4/07, Nicolas Williams wrote: >On Wed, Apr 04, 2007 at 01:09:51PM -0400, Michael Richardson wrote: >> >>>>> "Stephen" == Stephen Kent writes: >> Stephen> I'm not quite sure what you mean above. The ordering of the >> Stephen> PAD and SPD allows one to have overlapping entries, but >> Stephen> those were entries that all had the same precedence, and >> Stephen> which offer a binary choice. The notion of PROTECT IF >> Stephen> REQUESTED/POSSIBLE is a new concept with different >> Stephen> semantics and that's why I believe we have to be more >> Stephen> sophisticated in how we add this feature to the PAD and >> Stephen> SPD. >> >> Can you give me an example of an ordered PAD that would still be >> ambiguous? >> Your word "precedence" is funny to me, since the entries don't have >> the same precedence if they are ordered. > >I too wondered about the "but those were entries that all had the same >precedence" bit -- these are ordered lists, so no two rules can have the >"sam precedence." >_______________________________________________ The issue is not precedence once the list (PAD or SPD) is ordered. The issue is that given an extant, presumably OK list, if someone tries to add a new entry at a given location in the ordered database, are they allowed to do so. If PAD/SPD entries have a label that indicates the precedence/priority of the each entry, analogous to user/supervisor state, then maybe one can decide whether the new entry can be added (at the requested point) based o the comparison with the extant entries and their labels. Steve From kent at bbn.com Thu Apr 5 05:10:09 2007 From: kent at bbn.com (Stephen Kent) Date: Thu, 5 Apr 2007 08:10:09 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <8083.1175706591@sandelman.ottawa.on.ca> References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> Message-ID: At 1:09 PM -0400 4/4/07, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>>>> "Stephen" == Stephen Kent writes: > Stephen> At 12:31 PM -0400 4/3/07, Michael Richardson wrote: > >> Stephen Kent wrote: > >>> The existing 4301 model describes BYPASS and PROTECT as mutually > >>> exclusive descriptions. So, the new option, which might more > >>> properly be named "PROTECT IF POSSIBLE" is a third option that > >>> the user has to > >> As this is used primarily on the responder, I suggest th wording > >> be infact: "PROTECT IF REQUESTED" > > Stephen> Does the spec say that it is used ONLY by a responder? If > Stephen> so, then your wording sounds better. If not, ... > > 1) BTNS says nothing about how nodes know to do BTNS. We explicitely > left out discovery. > So, an initiator would have to some some PAD/SPD entry that told it > to do something. > > If that thing was "PROTECT IF REQUESTED", and the application > requested protection, then that wording would fit. I was focusing on the requester being the peer, not the application triggering SA creation. I am still a bit confused. Are you saying that if an app requests IPsec protection for a connection then this entry will try to create an SA, but it will not try to create an SA if the app does not request it? I guess I tend to think in PAD/SPD -centric terms, not app-centric terms, which would say create the SA IF possible, irrespective of whether an app requests it or not. I also see a possible disconnect here. Consider an SPD entry that supports our new "PROTECT IF X" feature and that entry is a tunnel for ALL TCP traffic between Host A and Host B. Let's say that one app does not request an SA between A and B, and so an unprotected TCP connection is established. Then a second app requests an SA, if possible. Do we create a tunnel and migrate the old, unprotected traffic to the tunnel? If not, we would seem to have a conflict between two SAD entries, one labelled BYPASS and one ESP, with the same scope (based on the SPD entry I described above). have we discussed this scenario before, and if so, what was the conclusion? Steve From kent at bbn.com Thu Apr 5 05:13:03 2007 From: kent at bbn.com (Stephen Kent) Date: Thu, 5 Apr 2007 08:13:03 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070404190817.GR28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070404190817.GR28748@Sun.COM> Message-ID: At 2:08 PM -0500 4/4/07, Nicolas Williams wrote: >On Tue, Apr 03, 2007 at 12:31:27PM -0400, Michael Richardson wrote: >> Stephen Kent wrote: >> > The existing 4301 model describes BYPASS and PROTECT as mutually >> > exclusive descriptions. So, the new option, which might more properly >> > be named "PROTECT IF POSSIBLE" is a third option that the user has to >> >> As this is used primarily on the responder, I suggest th >>wording be infact: >> "PROTECT IF REQUESTED" > >Actually, these rules might not be used at all by administrators, but be >created dynamically by applications. In any case, they are used on both >sides (client and server). > >We could just call them TEMPLATE BYPASS OR PROTECT (yes, I still like >the name I picked originally) -- something that indicates: a) the fact >these aren't rules as such but rules that give rise to flow-specific >rules, and b) that the latter may be either BYPASS or PROTECT rules. > >Nico >-- >_______________________________________________ I'n not saying this is a bad idea, but I don't think I've seen a clear description of how the templates fit into the extant 4301 model. maybe we need more details. Also, if apps create the rules, there is still a need to be able to determine if they conflict with other rules already created by an admin, in order to be sure that an admin-controlled access control policy is not subverted. Steve From mcr at sandelman.ottawa.on.ca Thu Apr 5 06:29:15 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 05 Apr 2007 09:29:15 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Message from Nicolas Williams of "Wed, 04 Apr 2007 14:42:45 CDT." <20070404194245.GU28748@Sun.COM> References: <4601614B.3030207@sandelman.ca> <20070321170635.GD22445@Sun.COM> <200704031526.43271.julien.IETF@laposte.net> <22964.1175611186@sandelman.ottawa.on.ca> <20070404194245.GU28748@Sun.COM> Message-ID: <29814.1175779755@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: >> I was going to propose ordering by ordered IP addresses, but this >> is perhaps more cool. Nicolas> I don't believe that you'd think of ordering by IP Nicolas> addresses when you're also so concerned about support for Nicolas> NAT! ;) Yes, that's why I prefer the min/max construct. - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhT5pYCLcPvd0N1lAQJHAQgAqqFj+vr1S3Zdw38K/AozrqucSELObrmt 3LXgTHuu+Hm/bJPISK1OISYN7hx25FarHsI6XC3HvUof9b7BhXkOr8G3mXLGhycR MbasZe6iseEdy7k/8CW9KaTycD/Fed4+22UJX2qdtf4E6e29KVw8FRCu1c5t+Cta rzs3oR7ydBe/kjmcsBv6gLB3BnCZOGa2Ss9ShsuTKSsyQsLdWsclWllg72wc9hD/ ZZF8EghNZr+nYHVCfLHa+OEBJONRoQDz/asZj6tPAGOkTdtfQUXiYrQZ7vVuLtVj K6iC6BfW9WSB82ucIPPzb+NgxkwRh3g7dKrzYnaiJRTLQZxCFBb1MQ== =EGSl -----END PGP SIGNATURE----- From mcr at sandelman.ottawa.on.ca Thu Apr 5 06:33:00 2007 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 05 Apr 2007 09:33:00 -0400 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: Message from Nicolas Williams of "Wed, 04 Apr 2007 14:56:17 CDT." <20070404195616.GV28748@Sun.COM> References: <4601614B.3030207@sandelman.ca> <14575.1175463785@sandelman.ottawa.on.ca> <20070401223158.GK8252@Sun.COM> <200704031537.58414.julien.IETF@laposte.net> <22734.1175611048@sandelman.ottawa.on.ca> <20070404195616.GV28748@Sun.COM> Message-ID: <30243.1175779980@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> That's because EAP, by its applicability, would be used in Nicolas> IPsec VPN-type use cases, and so the end-points of the Nicolas> channel would be the client and the SG, which have already Nicolas> authenticated each other, so why authenticate again at the Nicolas> application layer? Because the application layer isn't aware of whether or not the "VPN" is actually active or not. Take the case of a laptop doing an NFS mount of a server (assume NFS server and VPN gateway are co-located, such as happens with a small office server). When at "home", there is no tunnel, so the application needs to authenticate. When remote, it can exploit the IPsec tunnel that exists. (Ironically, if you have any hardware offload on the gateway, it would actually be better to use the IPsec all the time, since the hardware is likely faster, and you can, when local, probably get more use of it...) Nicolas> Well, the channel binding could be done inside EAP, and Nicolas> this could be used to enroll client public keys (a useful Nicolas> use case if you want to do two-factor authentication where Nicolas> one factor is a BTNS key and it is enrolled by one-time Nicolas> one-factor authentication). But, it still doesn't tell the application that it can avoid a second layer of encryption. Nicolas> Look at RFC2743 or RFC2744 and look at the function Nicolas> signatures for Nicolas> GSS_Init_sec_context()/GSS_Accept_sec_context(). Nicolas> In the GSS-API (and in SASL/GS2) channel bindings are as an Nicolas> input to a black box at each peer -- both have to provide Nicolas> the same channel binding octet strings, else -> failure[*]. Nicolas> The black box can (and does, e.g., in the case of the Nicolas> Kerberos V GSS mech) cause hashes/MACs of the channel Nicolas> bindings octet strings to be exchanged. But are they compared with memcmp(), or with a function? - -- ] Bear: "Me, I'm just the shape of a bear." | 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.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRhT6i4CLcPvd0N1lAQLadQf/aF7ijAQb1YX4dU76e64h6PUSfsdGiM2z WOPjFE5FPWH3/N4es/W3cVRZ/fD4+oEeZPG1xyFOOl8/6fF+RYUvypXx3FgQJvsk pUhKkTmH5AAZSoJLD7H6tQXCRwPCJwQWP6zrIG1nSDjXPzlKUsCDPBgn8ai15l/L 6u6fjY96SUJemeCi23rTkKDpPPBiXM1QcmMlsgyzCjYLddgBNCLzbRNf8nmpH9h4 dcaz6ZJDPVlXzs8K8r0PmW8eYmJ3/kVvvE06Nqe/zf7d2XT/+y6fK4hBoCjTV4Rd xiwdrnyOA1C46SkdtWVas7wO/KgLyFU58q15u53EA3Pae1QuFyqZWg== =op6d -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Thu Apr 5 08:41:43 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Apr 2007 10:41:43 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> Message-ID: <20070405154143.GE28748@Sun.COM> On Thu, Apr 05, 2007 at 07:18:07AM -0400, Stephen Kent wrote: > At 10:47 AM -0500 4/4/07, Nicolas Williams wrote: > >Another way to look at it is to have system policy determine insertion > >points into the SPD for app-requested rules -- since the SPD is ordered > >then the insertion points determine what rules the apps can "punch > >holes" into. There could be multiple such insertion points, > >corresponding to multiple local privilege levels. > > one could do that, although I worry that this sounds fairly complex, > especially because it sounds like changes in SPD affect where > different rules apply. That's the nature of policies consisting of ordered rulesets. From Nicolas.Williams at sun.com Thu Apr 5 08:46:49 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Apr 2007 10:46:49 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> Message-ID: <20070405154649.GF28748@Sun.COM> On Thu, Apr 05, 2007 at 07:18:07AM -0400, Stephen Kent wrote: > At 10:47 AM -0500 4/4/07, Nicolas Williams wrote: > >So the SPD extension, then, would be a rule type that declares an > >insertion point for specific applications or local privileges. > > how would one define the insertion point in a way that doesn't get too > complex? You put that "inviolable" rules that you posited ahead of the insertion point. All others go behind. For a simple system with two levels of privilege (w.r.t. IPsec policy), privileged and unprivileged, you need two insertion points: one at the head of the SPD-S for privileged apps to request BYPASS in contravention to system poilicy, and one at the end of the SPD-S for unprivileged apps to request PROTECT where system policy would BYPASS. (Yes, I ignored DISCARD rules there.). > >Since there's more than one way to represent this we need English- > >language text and a canonical representation that implementors can > >ignore, provided that they provide equivalent functionality. > > agreed. > > >Personally I prefer the insertion point approach since it does not > >require modifying existing rules. Your notion of "inviolable" rules > >maps into placing such rules ahead of any insertion points. > > I see what you mean, and I appreciate the generality, but I do worry > about creating a sophisticated access control capability that will > induce management errors. Me too. But how can we ignore the "where" in the SPD to insert API-driven rules? Do you believe that your "inviolable" flag would allow us to ignore SPD order for such rules? Nico -- From Nicolas.Williams at sun.com Thu Apr 5 08:49:47 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Apr 2007 10:49:47 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> <20070404172729.GP28748@Sun.COM> Message-ID: <20070405154946.GG28748@Sun.COM> On Thu, Apr 05, 2007 at 07:32:37AM -0400, Stephen Kent wrote: > At 12:27 PM -0500 4/4/07, Nicolas Williams wrote: > >On Wed, Apr 04, 2007 at 01:09:51PM -0400, Michael Richardson wrote: > >> Your word "precedence" is funny to me, since the entries don't have > >> the same precedence if they are ordered. > > > >I too wondered about the "but those were entries that all had the same > >precedence" bit -- these are ordered lists, so no two rules can have the > >"sam precedence." > >_______________________________________________ > > The issue is not precedence once the list (PAD or SPD) is ordered. > The issue is that given an extant, presumably OK list, if someone > tries to add a new entry at a given location in the ordered database, > are they allowed to do so. If PAD/SPD entries have a label that > indicates the precedence/priority of the each entry, analogous to > user/supervisor state, then maybe one can decide whether the new > entry can be added (at the requested point) based o the comparison > with the extant entries and their labels. This sounds very much like what I meant by insertion points -- you have to know, or else you have to have some way to figure out where in the SPD to insert API-driven rules. (Of course, native implementions might not implement API-driven rules as rules that are inserted into the SPD as there are other morally equivalent ways to describe this, but we're trying to stay close to the RFC4301 model.) Nico -- From Nicolas.Williams at sun.com Thu Apr 5 08:52:24 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Apr 2007 10:52:24 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <30243.1175779980@sandelman.ottawa.on.ca> References: <4601614B.3030207@sandelman.ca> <14575.1175463785@sandelman.ottawa.on.ca> <20070401223158.GK8252@Sun.COM> <200704031537.58414.julien.IETF@laposte.net> <22734.1175611048@sandelman.ottawa.on.ca> <20070404195616.GV28748@Sun.COM> <30243.1175779980@sandelman.ottawa.on.ca> Message-ID: <20070405155224.GH28748@Sun.COM> On Thu, Apr 05, 2007 at 09:33:00AM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> That's because EAP, by its applicability, would be used in > Nicolas> IPsec VPN-type use cases, and so the end-points of the > Nicolas> channel would be the client and the SG, which have already > Nicolas> authenticated each other, so why authenticate again at the > Nicolas> application layer? > > Because the application layer isn't aware of whether or not the "VPN" > is actually active or not. Take the case of a laptop doing an NFS mount > of a server (assume NFS server and VPN gateway are co-located, such as > happens with a small office server). > When at "home", there is no tunnel, so the application needs to > authenticate. When remote, it can exploit the IPsec tunnel that exists. OK, that's a probable use case. From Nicolas.Williams at sun.com Thu Apr 5 08:58:28 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Apr 2007 10:58:28 -0500 Subject: [anonsec] details of IKE/IPsec channel binding In-Reply-To: <30243.1175779980@sandelman.ottawa.on.ca> References: <4601614B.3030207@sandelman.ca> <14575.1175463785@sandelman.ottawa.on.ca> <20070401223158.GK8252@Sun.COM> <200704031537.58414.julien.IETF@laposte.net> <22734.1175611048@sandelman.ottawa.on.ca> <20070404195616.GV28748@Sun.COM> <30243.1175779980@sandelman.ottawa.on.ca> Message-ID: <20070405155827.GI28748@Sun.COM> On Thu, Apr 05, 2007 at 09:33:00AM -0400, Michael Richardson wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> In the GSS-API (and in SASL/GS2) channel bindings are as an > Nicolas> input to a black box at each peer -- both have to provide > Nicolas> the same channel binding octet strings, else -> failure[*]. > > Nicolas> The black box can (and does, e.g., in the case of the > Nicolas> Kerberos V GSS mech) cause hashes/MACs of the channel > Nicolas> bindings octet strings to be exchanged. > > But are they compared with memcmp(), or with a function? Something is compared, but the something isn't necessarily the raw channel binding octet string. It could be a hash of them, it could that the channel bindings are used in key derivation so that an "authenticator" message is what gets compared, etc... In the case of SASL/GS2 the raw channel binding octet string is memcmp()ed. In the case of the Kerberos V GSS-API mechanism (and, I think, the upcoming replacement for SPKM, 'PKU2U'), hash or a MAC of the channel binding octet string is memcmp()ed. Nico -- From kent at bbn.com Thu Apr 5 14:52:32 2007 From: kent at bbn.com (Stephen Kent) Date: Thu, 5 Apr 2007 17:52:32 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070405124929.GB4777@sun.com> References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> <20070405124929.GB4777@sun.com> Message-ID: At 8:49 AM -0400 4/5/07, Dan McDonald wrote: >On Thu, Apr 05, 2007 at 08:10:09AM -0400, Stephen Kent wrote: > > > >> I also see a possible disconnect here. Consider an SPD entry that >> supports our new "PROTECT IF X" feature and that entry is a tunnel >> for ALL TCP traffic between Host A and Host B. Let's say that one app >> does not request an SA between A and B, and so an unprotected TCP >> connection is established. Then a second app requests an SA, if >> possible. Do we create a tunnel and migrate the old, unprotected >> traffic to the tunnel? If not, we would seem to have a conflict >> between two SAD entries, one labelled BYPASS and one ESP, with the >> same scope (based on the SPD entry I described above). have we >> discussed this scenario before, and if so, what was the conclusion? > >Connection latching covers this. The first TCP connection between A and B >will latch into BYPASS, and the second one will latch into ESP. Once a >connection is latched, policy changes will not affect the connection. > >Dan I don't see how this is consistent with the 4301 model of caching SPD entries. Steve From Nicolas.Williams at sun.com Thu Apr 5 15:48:43 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Apr 2007 17:48:43 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> <20070405124929.GB4777@sun.com> Message-ID: <20070405224843.GZ28748@Sun.COM> On Thu, Apr 05, 2007 at 05:52:32PM -0400, Stephen Kent wrote: > At 8:49 AM -0400 4/5/07, Dan McDonald wrote: > >On Thu, Apr 05, 2007 at 08:10:09AM -0400, Stephen Kent wrote: > > > > > > > >> I also see a possible disconnect here. Consider an SPD entry that > >> supports our new "PROTECT IF X" feature and that entry is a tunnel > >> for ALL TCP traffic between Host A and Host B. Let's say that one app PROTECT OR BYPASS is intended to support application use of IPsec and very much relates to specific traffic flows -- all SPD entries resulting from template PROTECT OR BYPASS entries will be for specific 5-tuples (yes, SCTP's multi-homing angle should be addressed). > >> does not request an SA between A and B, and so an unprotected TCP > >> connection is established. Then a second app requests an SA, if > >> possible. Do we create a tunnel and migrate the old, unprotected > >> traffic to the tunnel? If not, we would seem to have a conflict > >> between two SAD entries, one labelled BYPASS and one ESP, with the > >> same scope (based on the SPD entry I described above). have we > >> discussed this scenario before, and if so, what was the conclusion? > > > >Connection latching covers this. The first TCP connection between A and B > >will latch into BYPASS, and the second one will latch into ESP. Once a > >connection is latched, policy changes will not affect the connection. > > I don't see how this is consistent with the 4301 model of caching SPD entries. Which part isn't consistent? Keep in mind that each latch is for a specific packet flow. Are you concerned about tunnels and connection latching? Let's imagine a scenario where client A and server S are trying to communicate using PROTECTed traffic but A has to tunnel through an SG, G, and has to PROTECT all traffic between A and the SG. This means we have to nest IPsec. In the following lame ASCII-art the thick line represents the tunnel between A and G, and the thin line represents end-to-end IPsec between A and B: A G /----------------------\ app <--+----------------------+-----------------> B \----------------------/ Here the connection latch is between the application on A and B and though PROTECTed it is further encapsulated into the tunnel between A and G. Nico -- From kent at bbn.com Fri Apr 6 09:50:39 2007 From: kent at bbn.com (Stephen Kent) Date: Fri, 6 Apr 2007 12:50:39 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070405224843.GZ28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <8083.1175706591@sandelman.ottawa.on.ca> <20070405124929.GB4777@sun.com> <20070405224843.GZ28748@Sun.COM> Message-ID: At 5:48 PM -0500 4/5/07, Nicolas Williams wrote: >On Thu, Apr 05, 2007 at 05:52:32PM -0400, Stephen Kent wrote: >> At 8:49 AM -0400 4/5/07, Dan McDonald wrote: >> >On Thu, Apr 05, 2007 at 08:10:09AM -0400, Stephen Kent wrote: >> > >> > >> > >> >> I also see a possible disconnect here. Consider an SPD entry that >> >> supports our new "PROTECT IF X" feature and that entry is a tunnel >> >> for ALL TCP traffic between Host A and Host B. Let's say that one app > >PROTECT OR BYPASS is intended to support application use of IPsec and >very much relates to specific traffic flows -- all SPD entries resulting >from template PROTECT OR BYPASS entries will be for specific 5-tuples >(yes, SCTP's multi-homing angle should be addressed). OK, then we need to make sure that this, and analogous restrictions, are stated explicitly. > >> >> does not request an SA between A and B, and so an unprotected TCP >> >> connection is established. Then a second app requests an SA, if >> >> possible. Do we create a tunnel and migrate the old, unprotected >> >> traffic to the tunnel? If not, we would seem to have a conflict >> >> between two SAD entries, one labelled BYPASS and one ESP, with the >> >> same scope (based on the SPD entry I described above). have we >> >> discussed this scenario before, and if so, what was the conclusion? >> > >> >Connection latching covers this. The first TCP connection between A and B >> >will latch into BYPASS, and the second one will latch into ESP. Once a >> >connection is latched, policy changes will not affect the connection. >> >> I don't see how this is consistent with the 4301 model of caching >>SPD entries. > >Which part isn't consistent? Keep in mind that each latch is for a >specific packet flow. If we restrict the sorts of SPD entries top which BTMS applies, then the problem I cited does not arise. Otherwise, we have a scenario in which there is an extant, BYPASS SA and a new, PROTECTED SA, and there is no way to decide which traffic belongs on which SA, based on the cached SPD entry model defined in 4301. >Are you concerned about tunnels and connection latching? > >Let's imagine a scenario where client A and server S are trying to >communicate using PROTECTed traffic but A has to tunnel through an SG, >G, and has to PROTECT all traffic between A and the SG. This means we >have to nest IPsec. In the following lame ASCII-art the thick line >represents the tunnel between A and G, and the thin line represents >end-to-end IPsec between A and B: > > A G > /----------------------\ > app <--+----------------------+-----------------> B > \----------------------/ > >Here the connection latch is between the application on A and B and >though PROTECTed it is further encapsulated into the tunnel between A >and G. > >Nico >-- How one uses entries in the SPD caches and in the forwarding tables to create nesting of SAs is already defined in the 4301 model. That was not my concern. I admit that I do not understand how connection latching is realized relative to the 4301 model. When I look at your connection latching I-D, I see some new terms, e.g., "template" PAD entry and "cloned" PAD and SPD entry, and an informal description of how to use them to effect connection latching. I didn't see a description of how the 4301 model is extended to accommodate these new features. I think that needs to be part of the document, i.e., a comparison of how 4301 describes packet processing vs. what will now be required, and an analysis of why the changes do not undermine the security provided by 4301. Additionally, if there are any changes that affect the performance features of 4301, e.g., the ability to cache de-correlated SPD entries, that too needs to be addressed. For example, an important feature of 4301 is the use of caches, to avoid the need to search the SPD for each outbound packet, or to search it to verify that a packet received on an SA was consistent with the access controls for that SA. The text in the connection latching I-D does not make clear if the same processing model applies, given the references to cloned and template PAD and SPD entries Also, whereas the BTNS I-D describes adding ONE new PAD entry, at the end, to allow communication with unauthenticated peers, we have been discussing much more elaborate capabilities, which require multiple new PAD entries, insertion at other than the end of the PAD table, restrictions on the types of SPD entries can can be safely used (as you explained above), etc. These are not in the BTNS I-D, and they do not appear to be in the connection latching I-D. Steve From kent at bbn.com Fri Apr 6 14:12:51 2007 From: kent at bbn.com (Stephen Kent) Date: Fri, 6 Apr 2007 17:12:51 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070405154649.GF28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154649.GF28748@Sun.COM> Message-ID: At 10:46 AM -0500 4/5/07, Nicolas Williams wrote: >... > > >> I see what you mean, and I appreciate the generality, but I do worry >> about creating a sophisticated access control capability that will >> induce management errors. > >Me too. But how can we ignore the "where" in the SPD to insert >API-driven rules? Do you believe that your "inviolable" flag would >allow us to ignore SPD order for such rules? > >Nico >-- I had a very simple model in mind, which might be too simplistic, but let me state it anyway. For what I believe is the common case of user vs. supervisor, we would need to mark rules as "U" or "S." When a newly proposed "U" rule is to be inserted, we invoke an algorithmic check to determine whether it would affect any "S" rule. If so, then the attempt to insert the "U" rule is rejected. In this model one does not need to define points where "U" rules could be inserted. Steve From kent at bbn.com Fri Apr 6 14:14:42 2007 From: kent at bbn.com (Stephen Kent) Date: Fri, 6 Apr 2007 17:14:42 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070405154143.GE28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154143.GE28748@Sun.COM> Message-ID: At 10:41 AM -0500 4/5/07, Nicolas Williams wrote: >On Thu, Apr 05, 2007 at 07:18:07AM -0400, Stephen Kent wrote: >> At 10:47 AM -0500 4/4/07, Nicolas Williams wrote: >> >Another way to look at it is to have system policy determine insertion >> >points into the SPD for app-requested rules -- since the SPD is ordered >> >then the insertion points determine what rules the apps can "punch >> >holes" into. There could be multiple such insertion points, >> >corresponding to multiple local privilege levels. >> >> one could do that, although I worry that this sounds fairly complex, >> especially because it sounds like changes in SPD affect where >> different rules apply. > >That's the nature of policies consisting of ordered rulesets. This is not true for many access control models. We adopted the ordered rule model because it was commonly employed in other contexts, e.g., firewall filter rule, and because, with caching, it works very well at layer 3. Also, recall that the 4301 processing model uses caches and that calls for the SPD to be de-correlated, which implies no ordering. So, although it still makes sense to offer an interface for an ordered SPD to a human user to administer, if we talk about making changes to an SPD dynamically, from an app, we are assuming that the correlated SPD is used as the reference, and then we have to de-correlate it, see what impact that has on extant SPD cache and SAD entries, etc. Steve From Nicolas.Williams at sun.com Fri Apr 6 14:19:52 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 6 Apr 2007 16:19:52 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154649.GF28748@Sun.COM> Message-ID: <20070406211951.GP28748@Sun.COM> On Fri, Apr 06, 2007 at 05:12:51PM -0400, Stephen Kent wrote: > I had a very simple model in mind, which might be too simplistic, but > let me state it anyway. > > For what I believe is the common case of user vs. supervisor, we > would need to mark rules as "U" or "S." When a newly proposed "U" > rule is to be inserted, we invoke an algorithmic check to determine > whether it would affect any "S" rule. If so, then the attempt to > insert the "U" rule is rejected. In this model one does not need to > define points where "U" rules could be inserted. Marking an insertion point into the SPD -- bissecting it -- is the equivalent of what you propose: all the rules ahead of the insertion point for unprivileged apps are 'S' and all the rules behind it are 'U'. We need a canonical model only to explain what the correct semantics are, not to dictate implementation. I fully expect that some implementations will do something really simple, like: unprivileged app-driven PROTECT rules go at the back of the SPD, while privileged app-drive BYPASS rules go at the head of the SPD. I expect such an implementation to match the semantics of that we'll describe for PROTECT OR BYPASS (and not because we should describe what implementations that have this feature do, but because this is fairly natural). Nico -- From Nicolas.Williams at sun.com Fri Apr 6 14:23:34 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 6 Apr 2007 16:23:34 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154143.GE28748@Sun.COM> Message-ID: <20070406212333.GQ28748@Sun.COM> On Fri, Apr 06, 2007 at 05:14:42PM -0400, Stephen Kent wrote: > >That's the nature of policies consisting of ordered rulesets. > > This is not true for many access control models. We adopted the > ordered rule model because it was commonly employed in other > contexts, e.g., firewall filter rule, and because, with caching, it > works very well at layer 3. > > Also, recall that the 4301 processing model uses caches and that > calls for the SPD to be de-correlated, which implies no ordering. So, However, the access control semantics of RFC4301 depend on the SPD being ordered, and SPD de-correlation is intended to preserve the access control semantics of a pre-de-correlation, ordered SPD. N'est ce pas? > although it still makes sense to offer an interface for an ordered > SPD to a human user to administer, if we talk about making changes to > an SPD dynamically, from an app, we are assuming that the correlated > SPD is used as the reference, and then we have to de-correlate it, > see what impact that has on extant SPD cache and SAD entries, etc. My view was that app-driven rules, in the model we'll describe, are inserted into a normal SPD and then de-correlation is done again in order to install the new SPD. Implementors may choose to do this differently, provided that they maintain the same semantics. From kent at bbn.com Mon Apr 9 05:28:35 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 9 Apr 2007 08:28:35 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070406212333.GQ28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154143.GE28748@Sun.COM> <20070406212333.GQ28748@Sun.COM> Message-ID: At 4:23 PM -0500 4/6/07, Nicolas Williams wrote: >On Fri, Apr 06, 2007 at 05:14:42PM -0400, Stephen Kent wrote: >> >That's the nature of policies consisting of ordered rulesets. >> >> This is not true for many access control models. We adopted the >> ordered rule model because it was commonly employed in other >> contexts, e.g., firewall filter rule, and because, with caching, it >> works very well at layer 3. >> >> Also, recall that the 4301 processing model uses caches and that >> calls for the SPD to be de-correlated, which implies no ordering. So, > >However, the access control semantics of RFC4301 depend on the SPD being >ordered, and SPD de-correlation is intended to preserve the access >control semantics of a pre-de-correlation, ordered SPD. N'est ce pas? right. > > although it still makes sense to offer an interface for an ordered >> SPD to a human user to administer, if we talk about making changes to >> an SPD dynamically, from an app, we are assuming that the correlated >> SPD is used as the reference, and then we have to de-correlate it, >> see what impact that has on extant SPD cache and SAD entries, etc. > >My view was that app-driven rules, in the model we'll describe, are >inserted into a normal SPD and then de-correlation is done again in >order to install the new SPD. OK, then let's say so explicitly in our description of the nominal model. >Implementors may choose to do this differently, provided that they >maintain the same semantics. right, but we need a precise nominal model, like 4301, to provide a testable reference. Steve From kent at bbn.com Mon Apr 9 05:27:01 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 9 Apr 2007 08:27:01 -0400 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070406211951.GP28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154649.GF28748@Sun.COM> <20070406211951.GP28748@Sun.COM> Message-ID: At 4:19 PM -0500 4/6/07, Nicolas Williams wrote: >On Fri, Apr 06, 2007 at 05:12:51PM -0400, Stephen Kent wrote: >> I had a very simple model in mind, which might be too simplistic, but >> let me state it anyway. >> >> For what I believe is the common case of user vs. supervisor, we >> would need to mark rules as "U" or "S." When a newly proposed "U" >> rule is to be inserted, we invoke an algorithmic check to determine >> whether it would affect any "S" rule. If so, then the attempt to >> insert the "U" rule is rejected. In this model one does not need to >> define points where "U" rules could be inserted. > >Marking an insertion point into the SPD -- bissecting it -- is the >equivalent of what you propose: all the rules ahead of the insertion >point for unprivileged apps are 'S' and all the rules behind it are 'U'. You seem to be assuming that we perform a sort on the (correlated) SPD to put all S rules above all U rules. If no U rules are allowed to overlap with any S rules, then that should allow the simple, two-tier SPD that you are suggesting. I don't recall you explicitly stating that assumption in prior messages, or maybe I just missed it. Yes, I thin this would work. >We need a canonical model only to explain what the correct semantics >are, not to dictate implementation. agreed. >I fully expect that some implementations will do something really >simple, like: unprivileged app-driven PROTECT rules go at the back of >the SPD, while privileged app-drive BYPASS rules go at the head of the >SPD. I expect such an implementation to match the semantics of that >we'll describe for PROTECT OR BYPASS (and not because we should describe >what implementations that have this feature do, but because this is >fairly natural). Do we agree that the spec needs to have one model that has enough detail to be unambiguous and testable, like 4301, but also need to tell implementers that they are free to implement the model in nay way that exactly matches the model's external behavior? Steve From Nicolas.Williams at sun.com Mon Apr 9 08:12:46 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 9 Apr 2007 10:12:46 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154143.GE28748@Sun.COM> <20070406212333.GQ28748@Sun.COM> Message-ID: <20070409151244.GT28748@Sun.COM> On Mon, Apr 09, 2007 at 08:28:35AM -0400, Stephen Kent wrote: > At 4:23 PM -0500 4/6/07, Nicolas Williams wrote: > >My view was that app-driven rules, in the model we'll describe, are > >inserted into a normal SPD and then de-correlation is done again in > >order to install the new SPD. > > OK, then let's say so explicitly in our description of the nominal model. > > >Implementors may choose to do this differently, provided that they > >maintain the same semantics. > > right, but we need a precise nominal model, like 4301, to provide a > testable reference. The next revision of the connection latching I-D will say so, or perhaps this should be a separate I-D (Sam seemed to think so). What's the status of the core I-D? Nico -- From Nicolas.Williams at sun.com Mon Apr 9 08:36:14 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 9 Apr 2007 10:36:14 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: References: <20070328225901.GD1666@Sun.COM> <20070403063833.GU28748@Sun.COM> <20070404154758.GH28748@Sun.COM> <20070405154649.GF28748@Sun.COM> <20070406211951.GP28748@Sun.COM> Message-ID: <20070409153613.GU28748@Sun.COM> On Mon, Apr 09, 2007 at 08:27:01AM -0400, Stephen Kent wrote: > At 4:19 PM -0500 4/6/07, Nicolas Williams wrote: > >On Fri, Apr 06, 2007 at 05:12:51PM -0400, Stephen Kent wrote: > >> I had a very simple model in mind, which might be too simplistic, but > >> let me state it anyway. > >> > >> For what I believe is the common case of user vs. supervisor, we > >> would need to mark rules as "U" or "S." When a newly proposed "U" > >> rule is to be inserted, we invoke an algorithmic check to determine > >> whether it would affect any "S" rule. If so, then the attempt to > >> insert the "U" rule is rejected. In this model one does not need to > >> define points where "U" rules could be inserted. > > > >Marking an insertion point into the SPD -- bissecting it -- is the > >equivalent of what you propose: all the rules ahead of the insertion > >point for unprivileged apps are 'S' and all the rules behind it are 'U'. > > You seem to be assuming that we perform a sort on the (correlated) > SPD to put all S rules above all U rules. If no U rules are allowed > to overlap with any S rules, then that should allow the simple, > two-tier SPD that you are suggesting. I don't recall you explicitly > stating that assumption in prior messages, or maybe I just missed it. Indeed, that's my assumption, and I state it explicitly in this thread, but not in the I-D. > Yes, I thin this would work. Me too :) > Do we agree that the spec needs to have one model that has enough > detail to be unambiguous and testable, like 4301, but also need to > tell implementers that they are free to implement the model in nay > way that exactly matches the model's external behavior? Yes, you and I do, and I suspect that the rest of the WG will agree as well. Now I have to go re-read what RFC4301 has to say about the SPD... In this thread we've not taken into account RFC4301's logical split of the SPD into three pieces (SPD-S, -I and -O). I'm sure that won't be a problem. Nico -- From julien.IETF at laposte.net Wed Apr 11 02:01:25 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 11 Apr 2007 11:01:25 +0200 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070409151244.GT28748@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <20070409151244.GT28748@Sun.COM> Message-ID: <200704111101.26422.julien.IETF@laposte.net> On Monday 09 April 2007 17:12, Nicolas Williams wrote: > On Mon, Apr 09, 2007 at 08:28:35AM -0400, Stephen Kent wrote: > > At 4:23 PM -0500 4/6/07, Nicolas Williams wrote: > > >My view was that app-driven rules, in the model > > > we'll describe, are inserted into a normal SPD > > > and then de-correlation is done again in order > > > to install the new SPD. > > > > OK, then let's say so explicitly in our > > description of the nominal model. > > > > >Implementors may choose to do this differently, > > > provided that they maintain the same semantics. > > > > right, but we need a precise nominal model, like > > 4301, to provide a testable reference. > > The next revision of the connection latching I-D > will say so, or perhaps this should be a separate > I-D (Sam seemed to think so). > > What's the status of the core I-D? Nico, the WGLC concluded on 2007-04-09, hence I thought the WG would request publication of the core I-D to IESG. Does the discussion you and Steve have had so far impact that? In other words, should we delay submission of the core I-D to IESG? -- julien / BTNS co-chair From Nicolas.Williams at sun.com Fri Apr 13 09:15:35 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 13 Apr 2007 11:15:35 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <200704111101.26422.julien.IETF@laposte.net> References: <20070328225901.GD1666@Sun.COM> <20070409151244.GT28748@Sun.COM> <200704111101.26422.julien.IETF@laposte.net> Message-ID: <20070413161534.GX4375@Sun.COM> On Wed, Apr 11, 2007 at 11:01:25AM +0200, Julien Laganier wrote: > > What's the status of the core I-D? > > Nico, the WGLC concluded on 2007-04-09, hence I thought > the WG would request publication of the core I-D to > IESG. OK. > Does the discussion you and Steve have had so far > impact that? No, it does not. > In other words, should we delay > submission of the core I-D to IESG? Nope. I think it's ready. Nico -- From julien.IETF at laposte.net Mon Apr 16 04:22:10 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 16 Apr 2007 13:22:10 +0200 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <20070413161534.GX4375@Sun.COM> References: <20070328225901.GD1666@Sun.COM> <200704111101.26422.julien.IETF@laposte.net> <20070413161534.GX4375@Sun.COM> Message-ID: <200704161322.10942.julien.IETF@laposte.net> On Friday 13 April 2007 18:15, Nicolas Williams wrote: > On Wed, Apr 11, 2007 at 11:01:25AM +0200, Julien Laganier wrote: > > > What's the status of the core I-D? > > > > Nico, the WGLC concluded on 2007-04-09, hence I > > thought the WG would request publication of the > > core I-D to IESG. > > OK. > > > Does the discussion you and Steve have had so far > > impact that? > > No, it does not. > > > In other words, should we delay > > submission of the core I-D to IESG? > > Nope. I think it's ready. Before I forward it to IESG, I need you to resubmit a new version of the draft that passes all IDnits checks: It currently has 4 errors: - No 'Intended status' indicated ==> Use "std" as category in the XML's mark (e.g. ) - Lack an IANA Considerations section ==> If the document hasn't IANA considerations, include an IANA cons section stating "This document has no IANA considerations" - Bad Normative/Informative ref split causing downrefs. ==> I think [I-D.ietf-btns-connection-latching], [I-D.ietf-btns-prob-and-applic], [I-D.ietf-kitten-gssapi-channel-bindings], and [I-D.ietf-nfsv4-channel-bindings] are Informative rather than Normative... - Normative reference to obsolete RFCs (RFC 2408 and RFC2409) ==> Suggest removing them, or move to Informative? Once those are taken care of, I'll forward the draft to IESG. --julien / BTNS co-chair. From Nicolas.Williams at sun.com Mon Apr 16 08:40:08 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 16 Apr 2007 10:40:08 -0500 Subject: [anonsec] BYPASS OR PROTECT In-Reply-To: <200704161322.10942.julien.IETF@laposte.net> References: <20070328225901.GD1666@Sun.COM> <200704111101.26422.julien.IETF@laposte.net> <20070413161534.GX4375@Sun.COM> <200704161322.10942.julien.IETF@laposte.net> Message-ID: <20070416154007.GT4375@Sun.COM> On Mon, Apr 16, 2007 at 01:22:10PM +0200, Julien Laganier wrote: > Before I forward it to IESG, I need you to resubmit a > new version of the draft that passes all IDnits > checks: > > > > It currently has 4 errors: > > - No 'Intended status' indicated > > ==> Use "std" as category in the XML's mark (e.g. > ) OK. > - Lack an IANA Considerations section > > ==> If the document hasn't IANA considerations, include > an IANA cons section stating "This document has no > IANA considerations" OK. > - Bad Normative/Informative ref split causing downrefs. > > ==> I think [I-D.ietf-btns-connection-latching], > [I-D.ietf-btns-prob-and-applic], > [I-D.ietf-kitten-gssapi-channel-bindings], and > [I-D.ietf-nfsv4-channel-bindings] are Informative > rather than Normative... And I-D.ietf-nfsv4-channel-bindings has been replaced with I-D.williams-on-channel-bindings. OK. > - Normative reference to obsolete RFCs (RFC 2408 and > RFC2409) > > ==> Suggest removing them, or move to Informative? Those should be informative, since they are only referenced in the Introduction. Similarly for RFC4306 (IKEv2). The only normative references left are to RFC2119 and RFC4301. > Once those are taken care of, I'll forward the draft to > IESG. I'll re-submit shortly. Nico -- From hartmans-ietf at mit.edu Tue Apr 24 17:34:57 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 24 Apr 2007 20:34:57 -0400 Subject: [anonsec] AD Review: Probably and Applicability Statement Message-ID: Hi, folks. I've finished reviewing the Problem and Applicability Statement draft. I'd like to thank the authors for a lot of good work. Several of the comments I made in my first review of the document still haven't been fixed. Terms like flash crowd, DDOS, zombies are not defined before they are used. Section 5.3 claims that passwords over anonymous channels are inappropriate. I don't think there is an ietf consensus behind this. Replace old: Therefore, CBB must not be used with higher layer protocols that may expose sensitive information during authentication exchange. with new: Therefore, CBB must not be used with higher layer protocols that may expose sensitive information during authentication exchange where the exposure of this information presents an unacceptable security risk. I wonder if the working group has adequately reviewed section 5.7. In particular do we actually have a strong consensus that caching of BTNS credentials is inappropriate? We certainly have a lot of issues to work through before we can recommend this caching. But if there is no caching how is that leap of faith at all? If there is such a consensus then Section 5.7 should be removed and a section added to the applicability statement saying that leap of faith/credential caching is out of scope. Section 6 rules mobility, nat and multihoming out of scope. Please provide an argument that btns does not make issues associated with nat and multihoming worse. IN particular think about address selection for inner addresses with anonymous open services and show that this problem is not worse in a BTNS universe. If you can do that then you can attempt to rule NAT and multihoming/mobility out of scope. I'll still call it out in the IETF last call message and confirm that the community is willing to let you rule this out of scope. Sam Hartman Security Area Director