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

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 26 Apr 2005 14:17:08 -0400

>> 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? "EAP
server" is what "eap peer" and "aaa" share.
Oh and we _are_ talking EAPv2, right?

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

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?

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

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 26 Apr 2005 14:27:24 -0400

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?

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blumenthal, Uri
> Sent: Tuesday, April 26, 2005 2:17 PM
> To: [email-masked]; Bernard Aboba
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party
>

---

From: Robert Story <[email-masked]>
Date: Tue, 26 Apr 2005 17:44:56 -0400

On Tue, 26 Apr 2005 14:27:24 -0400 David wrote:
DBH> Why are we spending so much time discussing EAP, if the AD has told
DBH> the WG that EAP should not be used, and that the IESG is unlikely to
DBH> approve a solution using EAP?

I've been wondering the same thing, but also include RADIUS, as that is just
one possible component of OOBK, which hasn't been selected as the
architecture..

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 26 Apr 2005 20:42:54 -0700

Blumenthal, Uri <mailto:[email-masked]> supposedly

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

I don't know what that is.

> (besides Glen and Bernard) on this list disagree with this
perception
> - I invite them to speak up please.  
> 
> 
> 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.
>> 
> 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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 26 Apr 2005 22:43:05 -0700 (PDT)

> "EAP server" is what "eap peer" and "aaa" share.

An EAP server can exist on the authenticator when there is  no AAA
server present.  It is a distinct entity from the EAP peer.  It is not
"shared" between the EAP peer and AAA server.

> Oh and we _are_ talking EAPv2, right?

The only version of EAP that I'm familiar with is defined in RFC 3748.

Maybe this entire discussion has been about some *other* version of EAP?

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 27 Apr 2005 14:25:53 -0700

Bernard Aboba <mailto:[email-masked]> supposedly scribbled:

> server present.  

I'd actually go a bit further and claim that the distinction between
the authenticator and the EAP "server" is one of convenience & that
they are logically the same entity.

> It is a distinct entity from the EAP peer.  It is
> not "shared" between the EAP peer and AAA server.  
> 
> Maybe this entire discussion has been about some *other* version
of
> EAP? 

Hope this helps,

~gwz

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Apr 2005 22:33:30 -0700 (PDT)

Over the last few weeks, a large number of messages relating to ISMS have
been cross-posted to the EAP WG mailing list.

At present, the EAP WG has a limited number of work items left on its
plate, and the group needs to focus on that.

In order to avoid continued disruption, I would like to request that the
cross posting cease.  If there is a need for the EAP WG to assist ISMS WG
by reviewing a specific document, let us know.

Bernard Aboba
EAP WG Co-Chair

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Apr 2005 07:01:18 -0700 (PDT)

To be clear, the issue is that the cross posted messages did not relate to
EAP, but to AAA.  Issues specifically relating to EAP are fair game on the
EAP WG mailing list, particularly if they relate to specific documents
that the WG has worked on or is working on (such as RFC 3748 or the EAP
Key Management Framework).