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

From: Tschofenig Hannes <[email-masked]>
Date: Sun, 17 Apr 2005 13:21:49 +0200

hi sam, 

you have intentionally chosen a provocative title for your mail. 

you write:

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

what is a "callout service"?
what is radius for you? (you write that it is not a trusted third party.)
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).

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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 17 Apr 2005 11:09:54 -0700

Tschofenig Hannes <> supposedly scribbled:

>> of the parties will know that RADIUS is being used. "
> 

It's not.  From the point of view of authentication protocols (PAP,
CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": 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 think that the misunderstanding mentioned above might have
something to do with it...

>> timeout.  You need to tell the other side of the exchange the
>> timeout too. 
>> 

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

---

From: Sam Hartman <[email-masked]>
Date: Sun, 17 Apr 2005 15:32:14 -0400

>>>>> "Tschofenig" == Tschofenig Hannes <[email-masked]> writes:

    Tschofenig> hi sam, you have intentionally chosen a provocative
    Tschofenig> title for your mail.

Or at least a title designed to catch people's attention and make sure
we resolve this issue.

    Tschofenig> you write:

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

    Tschofenig> what is a "callout service"?  what is radius for you?

It is a service used by one party (typically the command responder for
SNMP) in order to improve the scaling properties of the authentication
infrastructure and avoid storing credentials in each command
responder.  I.E.  it is a service that the command responder uses to
call out to instead of performing some functions locally.

    Tschofenig> (you write that it is not a trusted third party.)  

Note that I don't mean that RADIUS should not be trusted.  Trusted
third party is a term of art in security and RADIUS as it is intended
to be used does not meet the definition of that term.

    Tschofenig> why
    Tschofenig> do you care that only one party knows that radius is
    Tschofenig> used? it could also be diameter.

You bring up one of the obvious reasons yourself.  If both parties
know RADIUS is used that means that the use of RADIUS has entered into
the protocol between those two parties.  That makes it hard for me to
use something else instead like diameter or tacacs+.  Another concern
is that if both parties need to know RADIUS is being used it probably
means that RADIUS is being misused.

    Tschofenig> i would like to better understand why some people
    Tschofenig> dislike the aaa architecture (radius, diameter).

With properly design EAP methods I think AAA can be fine.  RADIUS
traditionally has weak protection of its messages but that is not an
inherent flaw with AAA.  So I don't think I can present a good
argument that AAA is architecturally flawed because I don't believe
such an argument.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 17 Apr 2005 12:48:55 -0700 (PDT)

> something to do with it...

As Glen said, EAP is a two-party protocol (run between EAP peer and
server).  RADIUS is also a two party protocol (between the authenticator
and server).  The system may also include a protocol run between the peer
and authenticator (the Secure Association Protocol).

An application has the flexibility to define new AAA attributes
(e.g. Diameter EAP); to define requirements with respect to EAP methods
(e.g. RFC 4017); and to define the Secure Association Protocol
(e.g. 802.11i 4-way handshake).

This flexibility is both a blessing and a curse.  It is a blessing in
that there is a lot of flexibility available to meet requirements if they
are well defined.  It is a curse because a key management application
needs to do considerable work in defining and analyzing the security
properties of the system in order to meet the security requirements
described in RFC 4017 (the Housley Criteria).

To enable analysis, the specification needs to detail the required AAA
protocol and EAP method properties as well as to define the security
properties of the Secure Association Protocol.  The best existing example
of this to date is probably IEEE 802.11i, but even that effort left out
some important pieces.

Note that the ISMS charter explicitly mentions RADIUS support:

"Version 3 of the Simple Network Management Protocol (SNMPv3) was
elevated to Internet Standard in late 2002 and added security to the
previous versions of the protocol. Although the enhanced protocol
is secure, operators and administrators find that deploying it can
be problematic in large distributions. This is due primarily to two
synchronization problems. The first is the addition of yet another
authentication system specific to SNMPv3 that needs to be maintained
across all networking devices. Most of these devices already
contain local accounts and/or the ability to negotiate with
authentication servers (e.g. RADIUS servers). However, SNMPv3 does
not make use of these authentication mechanisms, and this causes
additional synchronization burdens. The second issue found with
deploying SNMPv3 is that distributing and maintaining View-based
Access Control Model (VACM) rules is also difficult in large-scale
environments."

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 17 Apr 2005 13:39:31 -0700

>>>>> On Sun, 17 Apr 2005 15:32:14 -0400, Sam Hartman <[email-masked]> said:

Sam> Another concern is that if both parties need to know RADIUS is
Sam> being used it probably means that RADIUS is being misused.

Thank you for stating that so clearly, as I think it's a point that
most people miss when they're thinking about Radius and similar
architectures.  I've been trying to argue from the beginning that the
manager doesn't need to know *what* is being used to authenticate its
credentials as it really only complicates matters much of the time.
However, I've failed in expressing that as clearly as the above
statement does.

[MiM issues, of course, need to be dealt with when the agent passes
those credentials onward]

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 19 Apr 2005 17:57:42 -0700

Alper Yegin <> supposedly scribbled:

> Glen,
> 
>>> what is radius for you? (you write that it is not a trusted
third
>>> party.)
>> 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? 

I'm pretty sure that both Sam & I were just talking about
authentication.  In any case, could you expound a bit?  I don't
actually know what you're talking about.  What do "Host-to-NAS
authorization for the network access service", "host-to-AAA server
authorization" and "AAA server to client (NAS) authorization" mean?
Are you saying that somehow the host authorizes the NAS to provide
it network access?

> Alper
>> the
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
>>> why do you care that only one party knows that radius is used?
it
>>> could also be diameter. 
>>>>     Martin> defined as "Sets the maximum number of seconds of
>>>>     service Martin> to be provided to the user before the
session
>>>> third party.  In other words, in a particular SNMP
authentication,
>>>> only one of the parties will know that RADIUS is being used.
>>>> 
>>>> 
simply
>> eap mailing list
>> [email-masked]
>> http://mail.frascone.com/mailman/listinfo/eap
> 
> 
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

Hope this helps,

~gwz

---

From: Alper Yegin <[email-masked]>
Date: Tue, 19 Apr 2005 17:28:52 -0700

Glen,

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

> service

---

From: Alper Yegin <[email-masked]>
Date: Wed, 20 Apr 2005 11:20:21 -0700

> authentication.  

I understand that.

> In any case, could you expound a bit?  I don't

The host (or the user on the host) is authorized to access the Internet
by relying on its subscription with an operator that runs the AAA
server. SLAs, credentials are used to encode this relation. [1]

A bunch of NASes are also authorized by the same AAA server to provide
access service to subscribers of that operator. This comes in the form
of roaming agreements (list of NAS identifiers, credentials, etc.) [2]

Now, if host1 wants to access the Internet via NAS1, the required
dynamic authorization (that host1 is allowed to access the Internet, and
NAS1 is allowed to provide this service) can be generated by relying on
[1] and [2].

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?

Alper