[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Nice explanation David.  I have clarifying question below -

On Apr 21, 2005, at 11:37 AM, Nelson, David wrote:

Apler Yegin writes...

I guess the AAA protocol that runs between the NAS and AAA server is a
"wire" as you said, but the AAA server is the trusted third party.
Does
this make sense?

I think there is a subtle difference between a "trusted third party" and
a RADIUS server which may have bi-lateral trust relationships with
various parties. The RADIUS server will always have a trust
relationship with its enrolled Radius clients, via the shared secret.
Those clients may be NASes or they may be RADIUS proxy servers. RADIUS
trust is always hop-by-hop.


Strictly speaking, the RADIUS server has a trust relationship with the
human user only when the native RADIUS password database is used as the
source of authentication credentials.  Most often, the RADIUS server
relies on some other authentication service (e.g. Active Directory,
LDAP, NIS, etc.).  One tends to think of this as a single entity, and
for certain purposes this is fine.  For other purposes, we need to
retain the distinction.

The host (e.g. via a machine certificate) may also have a trust
relationship, but once again this relationship is typically with an EAP
server "attached" to the Radius server, which may in turn rely on other
authentication services.
The question I am wondering about is whether the RADIUS server could be a trusted third party if it is directly connected to the NAS. In that case it has credentials with all parties. However the credentials are of quite different form - I am wondering if the form of credentials or the relationship between the credentials makes a difference in whether it can act effectively as a trusted third party. My first guess is that it could (especially if RADIUS had stronger hashing) but I am not sure.
What is your thought?


A more typical example of a "trusted third party" is a Kerberos KDC
which does in fact directly share credentials with all enrolled
principals (human users, hosts or applications).

_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>