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

From: "Nelson, David" <[email-masked]>
Date: Thu, 21 Apr 2005 11:37:31 -0400

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.

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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 21 Apr 2005 14:31:31 -0400

Nice explanation David.  I have clarifying question below -

> server "attached" to the Radius server, which may in turn rely on other
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?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 Apr 2005 19:59:46 -0700 (PDT)

> various parties.

Yes.  Where RADIUS proxies are present there is no trust relationship
between the NAS and RADIUS server.  This is in contrast to Diameter, where
such a relationship can be established via re-direct.

The distinction is important in a number of cases.  In Kerberos, the KDC
is able to provide a ticket to any principal because it has a shared
secret that it shares with that principle.

Within RADIUS this is not possible.  A RADIUS server cannot
provide the user with a ticket to a NAS because it may not have a trust
relationship with that NAS.

Note that at one point, there was a proposal for integration of RADIUS
with Kerberos.  That proposal did in fact enable RADIUS to become a true
trusted third party.  The proposal seemed practical. However, the AAA WG
went with another proposal (Diameter CMS) which it turned out that noone
wanted to implement. Among other things, the proposal enabled a RADIUS
server to send a key to a NAS that could not be viewed by intervening
proxies.  In retrospect, the IETF may have missed an important
opportunity.

For a trip down memory lane, look here:
http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 22 Apr 2005 16:45:49 +0200

Hi,

> such a relationship can be established via re-direct.

 I'm wondering if an operator will let its EAP authenticator directly
 contact EAP server from other operators using redirect functionality of
 Diameter. 
 
 regards,

-- 
julien.bournelle at int-evry.fr
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Apr 2005 08:25:05 -0700 (PDT)

>  contact EAP server from other operators using redirect functionality of

As I understand it, proxy bypass is being considered by TERENA primarily
to eliminate excessive latency in trans-continental roaming.  More info on
the "trust fabric" of EduRoam NG is available here:

http://www.terena.nl/tech/task-forces/tf-mobility/
http://www.eduroam.org/docs/eduroam-article.pdf
http://www.eduroam.org/wiki/NextGeneration?v=ina
http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf
http://www.es.net/raf/ESnet-RAF-WP.html
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap