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

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alper Yegin <> supposedly scribbled:

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

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
>> 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: isms-bounces@lists.ietf.org
>>>> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman
>>>> Gesendet: Freitag, 15. April 2005 19:34
>>>> An: Martin Soukup
>>>> Cc: isms@ietf.org
>>>> Betreff: [Isms] RADIUS is not a trusted third party
>>>> 
>>>> 
>>>>>>>>> "Martin" == Martin Soukup <msoukup@nortel.com> 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
>>>> Isms@lists.ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/isms
>>>> 
>>> 
>>> _______________________________________________
>>> Isms mailing list
>>> Isms@lists.ietf.org
>>> 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
>> eap@frascone.com
>> http://mail.frascone.com/mailman/listinfo/eap
> 
> 
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap

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

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