Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party

From: Jeff Mandin <[email-masked]>
Date: Wed, 20 Apr 2005 15:32:52 +0200

On 4/20/05, *Glen Zorn (gwz)* <[email-masked] <mailto:[email-masked]>> wrote:

    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).  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 
<http://mail.frascone.com/pipermail/eap/2004-October/002895.html>

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.

- Jeff Mandin

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 20 Apr 2005 11:23:02 -0700

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
<http://mail.frascone.com/pipermail/eap/2004-October/002895.html>
/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.