RE: [HOKEY] a transparent proposal

["Glen Zorn" <glenzorn@comcast.net>]

I've been reading the HOKEY drafts, and am somewhat taken aback by
the extent of the required changes.  I know it's late in the process,
but I wonder if the HOKEY group has considered and rejected an idea
like the following.  If so, why?  If not, and there is some expression
of support, I could write it up as a draft.

[gwz] 
I think that this is a splendid idea, w/just one (major) problem: our
charter says that hokey must require 
"No changes to EAP methods.  Any extensions defined to EAP must not cause
changes to existing EAP methods."  In addition, hokey must not rely upon the
use of any particular (initial) EAP method, which is what it sounds like you
are suggesting.  If we could figure out how to pass back the reuth ID in
another way (maybe a Notification-Request injected into the initial EAP
conversation by the local hokey server?), I think this would be great.
[/gwz]

Make HOKEY transparent to the authenticator - peer and server have to know,
but the authenticator does not.

As part of the initial EAP conversation, peer & server agree that HOKEY may
be done.  The MSK that the server sends to the authenticator is not the
real MSK, but a domain-authenticator-specific key derived from it that
the peer can also derive.

When the peer connects to another authenticator, the identity it
supplies is a reauth-NAI given to it by the original server rather
than the id it supplied at initial auth.  Based on the id, the new
authenticator naturally routes its access-requests to a reauth
server, without needing any code updates.  The reauth server goes
through an abbreviated conversation with the peer, and upon success
sends the newly-derived domain-authenticator-specific key to the
authenticator.  Class can be used to tie together all the pieces.

Advantages:

Authenticator is completely unchanged.

AAA proxies are completely unchanged.

Peer behavior remains that of an EAP responder, rather than being both
requester (for reauth) and responder (for initial auth) in the current
HOKEY drafts.  The HOKEY drafts seem to do considerable philosophical
violence to EAP in this regard.

No new EAP codes.  HOKEY can be done as a new EAP method.

Disadvantages:

There is an extra round-trip, but it is to a (presumably local) reauth
server.  Even that could be avoided if the authenticator were to be
upgraded to recognize a reauth-identity and generate a reauth-eap
request itself.  But I suspect that's not really necessary.

-- 
Barney Wolff         I never met a computer I didn't like.


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


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