Hi Steve, On Sun, August 16, 2009 9:43 am, Stephen Hanna wrote: > I do not agree that EAP channel bindings are about > authentication. They have two parts: checking whether > the NAS is advertising services that it's not > authorized to advertise and using information from > the NAS (like which SSID the peer is trying to > connect to) to supplement the AAA server's decision > about whether to grant the requested access. > Both of these are authorization decisions and they > are made not based on authenticating the NAS (which > we have had for many years in the form of the secret > shared between the NAS and the AAA server) but on > supplementary information about the SSIDs and other > things being advertised by the NAS and requested by > the EAP peer.
The problem with your definition of channel bindings is that it completely ignores the lying NAS problem. An identity is not a service that a NAS can be authorized to provide that is checked after authentication has completed. When there are 3 parties involved in this 2 party protocol it is justified by saying that the EAP server trusts the NAS so there is no security issue when MSK is disclosed to it. But what NAS identity does the EAP server trust? The peer and EAP server derive a shared key and for the key to be disclosed to another entity the peer and EAP server must have a consistent view of the identity of that entity. If they cannot arrive at a consistent view of all identities then the protocol deriving the key fails. That is not an authorization issue, it's an authentication issue. > I agree that NEA assessments are a different topic. > They're not the same as channel bindings. I'd say > that the data conveyed in EAP for channel bindings > and for NEA assessments are both authorization data > in that they are not authentication protocols but > supplementary data that the AAA server will use in > deciding whether access should be granted (and maybe > whether other action should be taken, like getting > the lying NAS repaired or sending remediation > instructions to an unhealthy endpoint). "Repair" the lying NAS after authentication? Whoa! If authentication does not fail because a lying NAS was detected then there is a huge security problem. You seem to be conflating authentication and authorization because a "AAA server" might use information from both steps in deciding whether access is granted or not. An EAP server asks "who are you?" and then proceeds to prove the identity it is told using a method of its choice. If the EAP method derives keys the keys have to be bound to a consistent view of the identities involved in the communication (including the NAS identity). If the EAP server is successful in proving that the peer really is the identity it claimed (and the key is successfully bound to a consistent view of all identities) there can still be other, supplementary, things to consider before deciding to grant access or not-- time-of-day, location, up-to-date anti-virus software, etc. But those other, supplementary, things are not EAP, which is why you're mentioning a "AAA server" and not an "EAP server". We might want to make them part of EAP since EAP is the only protocol allowed prior to the access decision being made and it's attractive to pass arbitrary data encapsulated in EAP. But I think it's wrong to say that NEA assessments can piggy back in because the door is being held open for channel bindings. Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
