[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [HOKEY] a transparent proposal
Hi Barney, all,
An approach with unmodified authenticators was already considered and
rejected by the working group soon after its first meeting as a WG.
That was one of the very first points that was debated and the choice of
a single roundtrip protocol was made consciously, given that several
methods can already offer method-specific reauthentication in 2.5
roundtrips, which is the best the protocol can do with unmodified
authenticators.
These discussions can be found by digging through the archives and also
in the meeting minutes of the interim meeting from last year. At this
stage, I'd like to see us make forward progress rather than revisit
topics that have been debated and put to rest a long time ago.
Regards,
Vidya
> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com]
> Sent: Monday, January 07, 2008 3:05 PM
> To: Hannes Tschofenig
> Cc: radiusext@ops.ietf.org; hokey@ietf.org
> Subject: Re: [HOKEY] a transparent proposal
>
> 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.
>
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
>
--
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/>