eap Mailing List: RE: RE: [Isms] RADIUS is not a trusted third party

[Glen Zorn (gwz) (gwz]

In order for a "trusted third party" in the technical sense to exist, the other two parties need to a) know about its existence and b) trust it.  Does the "authenticating entity" know about the RADIUS server?

 

In an EAP scenario the peer does in fact know about the AAA Server (or rather it always assumes that the AAA might be there).   

 

Which EAP are _you_ talking about?  I'm talking about the one defined in RFC 3748.

 

Consequently the AAA-Server does resemble a TTP in the EAP case  - as Jesse Walker wrote at length in http://mail.frascone.com/pipermail/eap/2004-October/002895.html 

 

To quote from the referenced email (emphasis added): "People have pointed out before that EAP is a two-party protocol, and that we can't change the EAP model, and I am sure they will again. However, the reality is we don't have to change EAP authentication one whit to address this problem, because it has nothing to do with authentication; it is about what to do with the results of authentication and the resulting authorization decision. All we need is one three-party scheme to deliver keys (properly bound to the authenticated identities of the NAS and Peer) to the NAS and to the Peer; we don't want some indeterminate number or 15 or 5 or even 2; just 1 proper key delivery that will allow applications to meet the SP 800-56 requirements. Even if EAP is itself two-party, the key distribution scheme can very well be three-party. And there are ready-made algorithms we can pick up and use (e.g., Needham-Schroeder, Otway-Rees, Bellare-Rogaway) if only we want to. To reach a solution that will be acceptable to NIST and to the 802.11 community, I beleive we need to define a 3-party protocol that involves the Peer, the NAS, and the AAA server; we would need to define how this consumes the EAP keys, and we would have to define a migration strategy to get from the current practice to the new mechanism. The document has not done this. I am willing to create time in my schedule to work with people to remedy this if there is any will in the group to take on the problem. If we need a different document to accomplish these ends, then that is ok, too.

I don't see any claims in the above that RADIUS, Diameter or EAP are three-party protocols, nor that the AAA server is a trusted third-party; it appears that Jesse might like it to be so, but that is a different issue.
 

There are scenarios (eg. mobile wireless) where the peer is _not at all_ interested in the identity of the NAS - but only that the NAS is trusted by the larger entity (ie. operator) that uses the AAA-Server for access enforcement.   That would amount to an inversion of what seems to be the standard trust model for RADIUS etc.

 

No, that _is the standards trust model for RADIUS, etc. -- or more precisely, for the access control _system_ which may or may not include  AAA.  From the user's POV, the system is a black box that proves it trustworthiness by showing knowledge of a shared secret; it doesn't matter if the secret is stored in local NVRAM or on a AAA server 6000 miles away.