Sam Hartman wrote: > 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.
The client could disclose more than the SSID. Location, cost, etc. are all possible items of interest. > 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. The charter requires us to focus on adding support for EAP channel bindings to the tunneled method, and if possible, other TLS-based EAP methods. > 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. I'm not sure why each EAP method would require a different set of channel binding attributes. If they are the same, they should all use a common mechanism. > 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. Changing the NAS is extremely difficult. > 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. OK. > 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. OK. > 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. The charter suggests this approach. > 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. I agree. > 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. I agree. > I'd appreciate comments from the WG and chairs on this proposed > approach. I think it's a good approach. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
