Hi Sam, Thanks again for taking this on. I think the approach below makes sense. I think one of the biggest sticking points has been around the motivation and use cases. I believe this has been holding up progress more than anything else. The next big issue has been around the requirements for the bindings themselves and how they should be designed. The draft mainly focuses on these aspects.
I think we've had pretty good agreement that we would like to have a common names space for bindings so we don't have different methods doing different things. I think a tunnel method approach could be useful here; we have had some discussion of this and I think we will have more as we move further along in tunnel method development. We had previously deferred a concrete definition of channel bindings to a follow-on document; I think some people would like to see the current document include this as well. I'll go back and check to see what other issues are open, but I think what you discuss below involves most of the large open issues. Do you think you can have a revision in time for discussion in Maastricht? Cheers, Joe > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Sam > Hartman > Sent: Tuesday, June 15, 2010 12:29 PM > To: [email protected] > Subject: [Emu] Channel Binding Discussion at IETF 77 > > > > Hi. At IETF 77, I agreed to edit draft-ietf-emu-chbind. Also, at that > meeting, I sat down with Glen to understand his concerns with the > document. I'd like to write up my notes on that meeting and to discuss > what I think the critical next steps are for the document. > > > I presented two motivating examples, one of which is I think directly > within the previous discussions of channel binding and one of which is > my motivation for caring about the problem. > > Consider a corporation that has an internal network and that also has > agreements with WIFI hotspots to provide its employees connectivity. > Policy requires that people use a different set of firewall rules and > VPN configuration when connecting at the WIFI hotspots than when > connecting to the home network. Typically clients determine which > network is in use by the SSID. They use the same EAP credentials in > both cases. > > You can imagine that the corporation would know the identities of its > own access points. In particular, a combination of configuration on the > AAA servers and at the boundary firewall could mean that the AAA servers > know whether a given request for access is coming from the corporate > network or a WIFI hotspot. Today, however, the corporate AAA > infrastructure does not know what the client thinks it is connecting > to. If the client disclosed the SSID it sees then the corporation would > be in a position to enforce the security policy. > > Glen agreed that channel binding could address this. We'll come back to > whether it's a good idea in a bit. > > My motivation is related to the technology being developed by the > Moonshot project (http://www.project-moonshot.org ). > We'd like to use EAP as part of application authentication. With network > access, there are a lot of situations where one network is much the same > as another. However with application authentication the party you're > talking to matters a lot, especially in federations with relatively > liberal membership policies. I might well be willing to send > information to my company's ERP system that I should not send to a rogue > machine at a competitor that is part of the same federation. I'd like to > know the difference in who I'm talking to. > > Glen described several significant concerns about the way channel > binding has been handled. > > First, there is the basic complexity concern. > EAP has grown and evolved over the years, in many cases with design > taking place after the fact. Adding a new facility has a high > cost. However, there are some things in the current draft that make that > cost even higher. > > I, and a few others have argued that all EAP methods should gain channel > binding support. Glen points out that is a lot of work and argues it is > unnecessary. > > Glen is also concerned that each EAP method will handle channel binding > differently.His assumption is that each method would have a different > set of channel binding attributes that it carried, a different mechanism > for carrying them, and different names/numbers for the attributes. So, > rather than just supporting channel binding in some deployment of EAP, > you would need to tie it to a particular method or small set of > methods. He acknowledged that we could have some standardized way of > dealing with new EAP methods but points out that we have a lot of > existing methods. > > Glen and I had a long discussion about channel binding in EAP vs channel > binding as part of the secure association protocol. > That was a very useful discussion. > > The interesting question is what favors one approach vs another. > > Channel binding always requires changing the client and the home AAA > server/EAP server. > > Using a SAP requires: > 1) changing all the NASes > 2) Specifying an extension to each lower layer that may be used > 3) Specifying AAA transport for this extension. > > [As an aside, Glen proposed a mechanism for doing this at the AAA layer > that should get written up somewhere. I thought it was quite clever and > easier than any attempt to do this I had seen before. Of course I'm a > relative novice when it comes to AAA.] > > Using channel binding inside EAP requires: > > 1) Changing/specifying channel binging for the EAP methods in use. > > For most of the applications I care about (with the exception of the EAP > for non-network-access use case), avoiding having to change the NAS is a > huge advantage. > Also, from where I sit, not having to update the link layers is a big > deal. > However, the conversation was really useful because I now understand > situations in which both of those assumptions about complexity of change > would be different. > > So, here are some ideas going forward for areas I'd like to improve the > draft: > > 1) The introduction does discuss use cases. However I don't think it > does a particularly good job of describing concrete use cases; I'd like > to provide some explicit examples. > > 2) The draft doesn't currently motivate the secure association protocol > version of channel binding. I will admit that my reaction when I read > that section of the draft was roughly "that's a stupid idea there to > placate people who don't think we can do this in EAP." At this point I > feel I understand the use case well enough to describe it and would like > to attempt doing so. > > 3) It's not actually true that you need to cover all EAP methods in > order to use channel binding inside EAP. In particular, if you have a > tunneled configuration, only one of the methods needs to support channel > binding. There are complexities here: you either need cryptographic > binding or you need the channel binding to be part of the method that > provides authentication of the client to the server. Still, it seems > like this is an area where we should explicitly consider what's going on > and see if we can use tunnel methods to reduce cases where we need to > implement channel bindings. > > 4) It seems clear to me that we want one namespace of channel binding > attributes that we carry in EAP methods and secure association > protocols. The current draft implies that but doesn't really give > concrete mappings for how that will be carried in existing EAP methods. > It's my understanding that there has been work done in this space. I > think that we need to go through that work and make sure it is sound to > address Glen's concern that we don't want the set of attributes to be > method-specific, nor do we want applications consuming channel binding > to need to pay attention to what their method supports. Some methods > will support channel binding; some will not. However for those that do, > we want a consistent interface provided to the lower layer. > > > There may be other open issues with the document. I have not inherited > any such list if there is one. > > I'd appreciate comments from the WG and chairs on this proposed > approach. > > --Sam > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
