Subject: FW: [HOKEY] a transparent proposal

From: "gwz" <[email-masked]>
Date: Mon, 7 Jan 2008 11:10:34 -0800

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

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

---

From: "Tom Wan" <[email-masked]>
Date: Wed, 16 Jan 2008 11:39:56 +0800

Dear Glen Zorn:
I'd like to add more to your words:
IMO, we can only judge whether a mechanism is EAP method independent or
not based on the type field. If the mechanism modified the type field,
then it is a new EAP method. If we use the code field instead of the
type field, then it is EAP method independent. So we can not judge
whether an algorithm is method independent or not based on the algorithm
itself. We can only judge it based on the type field.
Am I right? Thanks.

BR
Tom

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 gwz
发送时间: 2008年1月8日 3:11
收件人: 'Barney Wolff'
抄送: [email-masked]; [email-masked]
主题: FW: [HOKEY] a transparent proposal

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

Advantages:

Disadvantages:

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 16 Jan 2008 18:23:59 -0800

Tom Wan <mailto:[email-masked]> scribbled on Tuesday, January
15, 2008 7:40 PM:

> IMO, we can only judge whether a mechanism is EAP method independent
> or not based on the type field. If the mechanism modified the type
> field, then it is a new EAP method. If we use the code field instead
> of the type field, then it is EAP method independent. So we can not
> judge whether an algorithm is method independent or not based on the
> algorithm itself. We can only judge it based on the type field.     

Sounds accurate to me.

...