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

[Glen Zorn (gwz) (gwz]

Blumenthal, Uri <mailto:uri.blumenthal [at] intel.com> supposedly
scribbled:

>>> It was my understanding that while EAP is between the client
>>> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP
>>> method* that runs on top of EAP is between the client and RADIUS
>>> server.
>> 
>> No. Can we just _get it_ once and for all?  AAA & EAP are
_different_
>> and _separate_ things: there is no part of EAP that is "between"
the
>> EAP peer and any AAA entity.
> 
> What about EAP methods that run between the EAP client and EAP
server?
> Are you saying that EAP _method_ does not terminate in an EAP
server,
> or that EAP server is not usually [within and part of] a AAA
server?

No, but this is an implementation detail: it is by no means
necessary to have _any_ AAA infrastructure to deploy EAP.  AAA makes
it more convenient, scale better, etc., but it's not necessary, nor
is EAP "part of" AAA.

> "EAP server" is what "eap peer" and "aaa" share.  
> Oh and we _are_ talking EAPv2, right?

I don't know what that is.

> 
> 
>>> This tunnel created by EAP method can be considered as "trust
>>> between the client and AAA",
>> 
>> See above.
> 
> See above. 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.  
> 
> 
>>> and RADIUS between NAS and AAA (however it is
>>> accomplished) is "trust between NAS and AAA".
>>> 
>>> And yes, many find convenient to connect authorization decision
to
>>> some extra information about the supplicant - such as its
posture
>>> evaluation (Cisco NAC, Microsoft NAP, etc). Such information
would
>>> naturally be carried in TLVs as part of EAP inner method
exchange.
>> 
>> Or more rationally (gasp!) in a subsequent _authorization_
protocol
>> exchange.
> 
> Kindly explain how "authorization" doesn't include trust of the
> authorizing entity. 

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.  

> Also, it may be news for you - but [at least
> some] people want authentication combined with authorization: i.e.
if
> I get a set of keys, it means that (a) the AAA authenticated me
OK,
> _and_ (b) that the server implicitly authorized me to communicate
> with the given NAS.  

It's not news to me at all -- it's the same old RADIUS story.  
   
> 
> That authorization is dependent on host posture evaluation. I
thought
> it was Cisco that proposed it in their NAC architecture? Perhaps
you
> can/should shed some light on this?  

I thought this was a standards discussion; if you want to talk about
NAC (or any other proprietary Cisco stuff), I suggest that you talk
to your account manager -- I'm sure that he or she would love to
extol its wonders.  

> 
> 
>>> Yes it seems to go way beyond the original purpose of EAP, but
then
>>> it does seem to address the today's need.
>> 
>> If one has a sore toe, shooting oneself in the foot may seem to
>> satisfy "today's need"; in the long run, however, it will
probably
>> turn out to be counterproductive.
> 
> I'm simply describing what I perceive as today's reality. You may
> intensely dislike it - it's your free choice. Looks like the
market
> is moving the above-described way.  

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