Issue 287

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

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