Re: [HOKEY] a transparent proposal

[Barney Wolff <barney@databus.com>]

On Mon, Jan 07, 2008 at 10:54:02AM +0200, Hannes Tschofenig wrote:
> I don't think that this works since the Authenticator needs to route the 
> messages to a local proxy that later acts as the local ER server. Hence, 
> the Authenticator needs to perform special routing functionality. In my 
> recent mail to the list I was wondering whether in Diameter one would have 
> to define a new Diameter application for EAP-ER to accomplish this routing 
> since otherwise you might encounter other interesting effects.

It does work, if the NAI that the peer supplies routes "naturally" to a
local ER server.  There is no reason the peer cannot accomplish this, as
it certainly knows that it is attempting reauth.  Any NAI that ends in
.reauth or @reauth would be guaranteed to be workable, but we might
consider whether something like ReAuTh%<iKeyname>%<seq>%<hash>%<originalNAI>
might be better, as a reauth-supporting AAA proxy on the route could
recognize it, while if there is no support for reauth in the new domain
the request should end up at the original home AAA server.

I'm a little vague on how the current HOKEY drafts are supposed to work
in scenarios such as:
-	new authenticator does not support reauth
-	new authenticator supports reauth but the ER server failed to get the
	necessary info for this peer

Any HOKEY scheme clearly has to be workable during what's likely to be an
extended transition, in the sense that an upgraded peer should not cause
an appreciably worse user experience than an old peer, when dealing with
a non-upgraded domain, and vice-versa.  Or am I confused as to the intended
deployment plans?

Regards,
Barney

> Barney Wolff wrote:
>> 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/>