RE: Issue 287

["Adrangi, Farid" <farid.adrangi@intel.com>]

Hi Geln, all
Thanks for your time.  Please see my comments inline.
-Farid

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
> Sent: Thursday, March 03, 2005 7:50 PM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org; gwz@cisco.com
> Subject: Issue 287
> 
> 
> There still seems to me to be a problem here.  The thinking
> portrayed in the revised document seems awfully fuzzy to me.  This
> is exemplified by the following: "If the identity hint is not sent
> initially (such as when the authenticator does not support this
> specification), then if the local AAA proxy/server implementing this
> specification receives an EAP-Response/Identity with an unknown
> realm, it SHOULD reply with an EAP-Request/Identity containing an
> identity hint."  Of course, the AAA proxy _cannot_ receive an
> EAP-Response, nor send an EAP-Request, since it is a _AAA_ proxy,
> not an EAP entity of any variety.

Well, it is my understanding that the EAP-aware AAA proxy/server
[RFC3579] in the access network can send EAP-Request/Identity within an
Access-Challenge.  Here is a quote from RFC3579:
"
   Rather than sending an initial EAP-Request packet to the
   authenticating peer, on detecting the presence of the peer, the NAS
   MAY send an Access-Request packet to the RADIUS server containing an
   EAP-Message attribute signifying EAP-Start.  The RADIUS server will
   typically respond with an Access-Challenge containing EAP-Message
   attribute(s) encapsulating an EAP-Request/Identity (Type 1).
"

Maybe we can make the paragraph more clear by revising to something like
this:

"
The EAP authenticator MAY send an identity hint to the peer in the
initial EAP-Request/Identity.  If the identity hint is not sent
initially (such as when the authenticator does not support this
specification), then if the local EAP-aware AAA proxy/server
implementing this specification receives an AAA Request packet with an
unknown realm, it SHOULD reply with an EAP-Request/Identity containing
an identity hint.  For example, in case of RADIUS, if the EAP-aware
RADIUS proxy/server [RFC 3579] receives an Access-Request packet with an
unknown realm in the UserName(1) attribute, then it can reply with an
EAP-Request/Identity containing an identity hint within an
Access-Challenge packet. Please see "option 3" in the appendix for the
message flow diagram.
"

What do you think? 

>  This is the same thing that I
> wrote about earlier, when I said that this draft is interfering with
> the EAP protocol: it seems clear that whatever is sending these
> "hints" is an EAP entity of some sort (because it is engaged in at
> least a subset of the EAP protocol), but it's not a peer (since it's
> not being authenticated), it's not an authenticator (since it's not
> doing the authenticating) and it's not a server (since it doesn't
> terminate the authentication method. So what is it?  
> 





> ~gwz
> 

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