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

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 19 Apr 2005 18:05:08 -0700

I definitely look at RADIUS as a trusted third party: 

Parties involved: 

- authenticating entity (user/application) 
- authenticator/policy enforcement point (device) 
- authoritative authentication source/policy decision point (RADIUS)

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?  

Martin. 

> -----Original Message----- 
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: April 19, 2005 8:29 PM 
> To: [email-masked]; 'Tschofenig Hannes'; 'Sam Hartman'; 
> Soukup, Martin [CAR:5K50:EXCH] 
> Cc: [email-masked]; [email-masked]; [email-masked] 
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party 
> 
> 
> Glen, 
> 
> > > what is radius for you? (you write that it is not a trusted
third 
> > > party.) 
> > 
> > It's not.  From the point of view of authentication protocols
(PAP, 
> > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": 
> 
> What happens when we look at this picture from the 
> "authorization" perspective? "Host-to-NAS authorization for 
> the network access service" is dynamically generated from 
> "host-to-AAA server" authorization and "AAA server to client 
> (NAS)" authorization. Wouldn't this constitute a 3-party model? 
> 
> Alper 
> 
> 
> > the 
> > operation of the auth protocols should be exactly the same 
> as if they 
> > terminated in the AAA client, instead of elsewhere.  Basically,
the 
> > purpose of AAA (again, from the POV of an authentication 
> > protocol) is simply scaling.  BTW, a lot of misery has been 
> caused by 
> > the erroneous belief that EAP is (or can be) a three-party 
> > authentication protocol: it isn't, and can't be.  It could 
> _carry_ a 
> > three-party protocol (like Kerberos), but EAP in itself is 
> a two-party 
> > protocol. 
> > 
> > > why do you care that only one party knows that radius is used?
it 
> > > could also be diameter. 
> > > 
> > > i would like to better understand why some people dislike the
aaa 
> > > architecture (radius, diameter). 
> > 
> > I think that the misunderstanding mentioned above might 
> have something 
> > to do with it... 
> > 
> > > 
> > > ciao 
> > > hannes 
> > > 
> > > 
> > >> -----Ursprüngliche Nachricht----- 
> > >> Von: [email-masked] 
> > >> [mailto:[email-masked]] Im Auftrag von Sam
Hartman 
> > >> Gesendet: Freitag, 15. April 2005 19:34 
> > >> An: Martin Soukup 
> > >> Cc: [email-masked] 
> > >> Betreff: [Isms] RADIUS is not a trusted third party 
> > >> 
> > >> 
> > >>>>>>> "Martin" == Martin Soukup <[email-masked]> writes: 
> > >> 
> > >>     Martin> RADIUS "Access-Accept" indicates a successful 
> > >>     Martin> authenthentication response for a user. 
> > >> 
> > >>     Martin> The Access-Accept already returns a 
> > "Session-Timeout", 
> > >>     Martin> defined as "Sets the maximum number of seconds of

> > service 
> > >>     Martin> to be provided to the user before the session 
> > >>     Martin> terminates. This attribute value becomes the
per-user 
> > >>     Martin> "absolute timeout."". 
> > >> 
> > >> This only tells the SNMP engine talking to the RADIUS server
the 
> > >> timeout.  You need to tell the other side of the exchange the

> > >> timeout too. 
> > >> 
> > >> Remember that RADIUS is a callout service; it is not a
trusted 
> > third 
> > >> party.  In other words, in a particular SNMP authentication,
only 
> > one 
> > >> of the parties will know that RADIUS is being used. 
> > >> 
> > >> 
> > >> _______________________________________________ 
> > >> Isms mailing list 
> > >> [email-masked]
https://www1.ietf.org/mailman/listinfo/isms 
> > >> 
> > > 
> > > _______________________________________________ 
> > > Isms mailing list 
> > > [email-masked]
https://www1.ietf.org/mailman/listinfo/isms 
> > 
> > Hope this helps, 
> > 
> > ~gwz 
> > 
> > Why is it that most of the world's problems can't be solved 
> by simply 
> >   listening to John Coltrane? -- Henry Gabriel 
> > _______________________________________________ 
> > eap mailing list 
> > [email-masked] 
> > http://mail.frascone.com/mailman/listinfo/eap 
> 
> 
> 
>

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 22 Apr 2005 10:33:02 -0400

John Vollbrecht writes ... [mailto:[email-masked]]
> 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?

I suspect there are cases in which a single (non-proxy) RADIUS server
could act as a trusted third party, but that would depend on the extent
to which the RADIUS server and the EAP server were considered a single
entity.  I think the issue is whether all parties can [directly]
validate the bindings of authenticated identity to keys. When one set of
bindings is created via the EAP session between the EAP peer and EAP
server and another set of bindings is created via the RADIUS
authentication and authorization exchanges between the RADIUS server and
the NAS, there is certainly the opportunity for the parties to have
disjoint sets of key bindings.

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 26 Apr 2005 15:03:33 -0400

Uri Blumenthal writes...

> I consider EAP server running inside AAA server. If others
> (besides Glen and Bernard) on this list disagree with this perception
-
> I invite them to speak up please.

I agree that is most often the case, in practice.  The EAP server is
packaged as part of the RADIUS or Diameter server software distribution.

From a protocol definition perspective, however, the EAP server and AAA
server are distinct entities.  Any interaction (API) between these
entities is outside the scope of the EAP, RADIUS or Diameter RFCs. Any
security analysis of those protocols cannot take into account the AAA
server to EAP server API, as it is implementation specific.

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 26 Apr 2005 15:07:14 -0400

Dave Harrington writes...

> Why are we spending so much time discussing EAP, if the AD has told
> the WG that EAP should not be used, and that the IESG is unlikely to
> approve a solution using EAP?

I don't know.  But I'll offer the somewhat pedantic clarification that
the AD told ISMS that EAP was out of scope because of the EAP
applicability statement.  There exists the finite possibility that the
EAP WG will decide to modify its applicability statement.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 26 Apr 2005 15:33:23 -0700 (PDT)

> dbh

Perhaps because the ISMS WG charter talks about RADIUS support?

Just a thought :)

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 27 Apr 2005 10:23:16 -0400

Glen Zorn writes...

> I may not trust the government of the United States, but it has
> authorized me (through the issuance of a passport) to leave the
> country and return.

I'm not sure this is an apt example of your point.  I rather suspect
that your distrust of the Federal government extends to areas other than
whether or not the agency that issued you a passport has the authority
to do so. :-)

In terms of the trust needed for enforcement of authorization, in your
example it is the trust relationship that various customs agents have
with the US government (among others) that allows them to validate your
passport and grant you passage.

In general, I think that concept of authorization without any form of
trust relationship is pretty useless.

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 27 Apr 2005 14:46:38 -0700

Blumenthal, Uri <mailto:[email-masked]> supposedly
scribbled:

>>> "EAP server" is what "eap peer" and "aaa" share.
>> 
>> An EAP server can exist on the authenticator when there is  no
AAA
>> server present.  It is a distinct entity from the EAP peer.  It
is
>> not "shared" between the EAP peer and AAA server.
> 
> In theory EAP server is a distinct entity and can be anywhere, in
> practice it's a part of AAA most of the time. Why are we arguing
> about this?  

I thought we were talking about architecture; and further,
discussing components which might or might not be utilized in that
architecture.  Maybe it's just me, but I think that it's a good idea
to understand how those components actually work (as opposed to how
we might wish or imagine they work, or the direction in which
marketeers might be pushing them).  If a building architect thought
that a brick was part of a girder, he would design a pretty strange
building and  misconceptions in networking can easily lead to
similar results.  For example, there was a recent thread on a
different list in which someone was worried about security problems
if a 4th party (!) was introduced into an EAP conversation.  There
are not 3 or 4 or 17 parties in an EAP exchange, there are exactly
2; there are also (logically) 2 parties in a RADIUS exchange, and
those sets are disjoint.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap