[HOKEY] a transparent proposal

[Barney Wolff <barney@databus.com>]

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.

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