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

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

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
<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. 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 21 Apr 2005 10:38:01 -0700

> -----Original Message-----
> From: Nelson, David
> 
> 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.

David made a good point.  RADIUS (and TACACS+) servers and clients
establish multual trust via shared secrets.  I am not sure about
Radius, but in tacacs+ config, a pre-shared key needs to be 
configured for each pair of AAA server-client.

So in a sense, using RADIUS for SNMP authentication is not quite 
a solution because you just move the trust/auth problem from one 
place to another: instead of auth between SNMP entities, you do 
auth between SNMP entity and RADIUS server.  

BTW if we can use the pre-shared key(PSK) method to establish trust 
b/w RADIUS and SNMP entity, why don't we do the samething to auth 
among SNMP entities directly w/out the need for a third party?
SNMP entities *already* have some shared secrets: user passwords or 
community strings (so you don't need to configure additional keys 
as in RADIUS).  So why don't we leverage these shared secrets to 
auth not only users but also SNMP devices? And that's the motivation
behind the Localized PSK proposal.

Back to the original topic, using RADIUS as an optional AAA tool to 
facilitate SNMP user management is fine, but it should not be a MUST 
for SNMP auth, IMHO.

Khanh

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 21 Apr 2005 18:53:46 -0700

I agree that RADIUS can be very helpful for user configuration.
I just think that it should be an optional, not a required component 
of SNMP security.  

RADIUS is helpful for VACM, but if another access control model is used
(e.g. community based), then RADIUS may no longer applicable.  RFC3411 
allows multiple access control models, so from the architecture point 
of view, it's prefered that the security model is not dependent on a  
particular access control model. 

BTW the LPSK proposal also support RADIUS and other AAA options.
The LPSK values (or the passwords to generate them) can be stored
locally in the devices or remotely in AAA servers such as radius.
Which way to use (local or remote users) is up to the operators, and 
that's completely transparent to the rest of the model.

Regards.

Khanh

> From: Blumenthal, Uri [mailto:[email-masked]] 
> 
> But that was the whole problem! Admins did NOT want to enter 
> a new set of user-names and passwords in each agent, and then 
> manage the lists.
> The purpose of the linkage with RADIUS or such is to re-use 
> the name lists that are already there (no need to re-type) 
> and the keys that are already there (no need to re-key).
> 
> It's how EXACTLY to accomplish this, and WHAT existing 
> infrastructures to connect to, that people are arguing about 
> bitterly here and now. 
> 
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Tom Petch
> Sent: Thursday, April 21, 2005 4:35 PM
> To: Nelson, David; Khanh Nguyen (khanhvn); [email-masked]
> Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> I'm with Khanh on this one.  We could have a system whereby 
> the setup of 'USM'
> was much simpler, users with fixed names, passwords being 
> input at agent setup, no need for any contact between agent 
> and third party; and changing the behaviour of the manager to 
> fit in with this.  The manager is the easy part because it is 
> on a server already replete with security systems - (almost) 
> anything is possible there, like requiring authorisation to 
> send packets to port
> 161/162 if
> that is what the security demands.
> .
> Tom Petch
> 
> ----- Original Message -----
> From: "Nelson, David" <[email-masked]>
> To: "Khanh Nguyen (khanhvn)" <[email-masked]>; <[email-masked]>
> Sent: Thursday, April 21, 2005 7:55 PM
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
> 
> 
> Khanh Nguyen writes...
> 
> > ...why don't we do the samething to auth among SNMP 
> entities directly 
> > w/out the need for a third party?
> 
> I think that's what we have today -- USM -- that operator's 
> find to be onerous to deploy and manage.
> 
> 
>

---

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: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Tue, 26 Apr 2005 15:50:01 -0700

> From: Bernard Aboba
> Sent: Tuesday, April 26, 2005 3:33 PM
> To: David B Harrington
> Cc: [email-masked]; [email-masked]; [email-masked]

> Perhaps because the ISMS WG charter talks about RADIUS support?

Perhaps we'll revisit RADIUS later down the road, but for now let's
focus on the architecture, deciding on abstract issues like should 
we handle AAA at SNMP instrumentation (device) level or at manager 
application level, etc.

Khanh

---

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: "Martin Soukup" <[email-masked]>
Date: Wed, 27 Apr 2005 21:38:16 -0400

I believe the AD's direction on EAP was based on certain uses of EAP as
might have been understood earlier in the current discussions. Perhaps Sam
can comment, but I believe that the use of EAP for the exchange of keying
information for authentication and privacy is fully within the applicability
of EAP as stated (e.g. as it is used over RADIUS for 802.1x and WPA key
distribution).

Martin. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: April 26, 2005 6:33 PM
> To: David B Harrington