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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
