[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

To: "Blumenthal, Uri" <uri.blumenthal@intel.com>
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
From: Bernard Aboba <aboba@internaut.com>
Date: Thu, 21 Apr 2005 21:51:29 -0700 (PDT)
Cc: "Nelson, David" <dnelson@enterasys.com>, isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org
In-reply-to: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>
References: <3DEC199BD7489643817ECA151F7C59290103F301@pysmsx401.amr.corp.intel.com>

> Yet NAS takes "go/no-go" decision from RADIUS, and takes the keys to
> talk to the client... If this is not trust - what is it?

There is no IETF standard defining how keys are provided within
RADIUS for exactly that reason -- there is no trust relationship defined
when a proxy is present.  The "Housley Criteria" described in RFC 4017 do
not allow disclosure of keys to additional parties.

The problem does not exist in Diameter EAP, which enables keys to
be provided directly without access by proxies.

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

Prev by Date: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Next by Date: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
Previous by thread: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
Next by thread: Re: [eap] RE: [Isms] RADIUS is not a trusted third party
Index(es):
- Date
- Thread