Subject: [HOKEY] a transparent proposal

From: Barney Wolff <[email-masked]>
Date: Sun, 6 Jan 2008 18:32:08 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 07 Jan 2008 10:54:02 +0200

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.

Ciao
Hannes

---

From: Alan DeKok <[email-masked]>
Date: Mon, 07 Jan 2008 13:27:56 +0100

Hannes Tschofenig wrote:
> messages to a local proxy that later acts as the local ER server.

  This scenario already includes roaming users, so the local AAA
server(s) already do realm routing.  Adding one more for a local ER
server shouldn't be major change.

> Hence,
> the Authenticator needs to perform special routing functionality. 

  I don't believe so.  The local *AAA* server needs to perform special
routing.  But as noted above, it already does this.

  Alan DeKok.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Jan 2008 10:53:06 -0800

Hi Bernard,
AAA routing in ERX is still done based on the realm.  It is up to the
local domain how the key state replication is handled.  If there are
multiple local ER servers in the same domain for redundancy sake, key
state may be replicated across those servers.  While ERX provides no
provisions for such AAA replication, this is not restricted by ERX. 

So, there are no changes to AAA routing between regular EAP and ERX.  In
fact, this was one of the debated points earlier on in the design when
the choice was made to keep the AAA routing the same to minimize impact
to AAA entities. 

Thanks,
Vidya

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, January 07, 2008 7:56 AM
> To: Hannes Tschofenig; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [HOKEY] a transparent proposal
> 
> To avoid changes to existing RADIUS routing procedures, the 
> messages would need to be routed to based on the realm in the NAI.  
> 
> However, the routing requirements for the ERX application are 
> different from those in normal AAA exchanges, because here 
> key state (unlike the AAA credentials database) is not 
> replicated.   That means that messages can't just be routed 
> based on a "Domain Identifier" -- they actually have to be 
> addressed to specific servers, since only those servers will 
> hold the required key state. 
> 
> For example, a "session resume NAI" could identify the 
> specific EAP Session-Id that is being resumed, as well as the 
> realm in which that key resides.  However, an NAI including 
> only the realm will not necessarily be routed to the server 
> or proxy that holds the key state, because AAA deployments 
> often point the authenticators at different AAA servers or 
> proxies for load balancing purposes.   To ensure that the 
> request goes to the right place, the specific server name 
> needs to be provided within the NAI.  
> 
> This may not be that easy to produce.  Not all EAP methods 
> produce the Server-Id, so the peer may not be able to include 
> the specific server name in a "session resume NAI" sent to 
> the home AAA server.  For the peer to compose a "session 
> resume NAI" for the local realm, it would have to learn the 
> local server name, not just a "Domain Identifier".  
> 
> 
> > Date: Mon, 7 Jan 2008 10:54:02 +0200
> > From: [email-masked]
> > To: [email-masked]
> > CC: [email-masked]; [email-masked]
> > Subject: Re: [HOKEY] a transparent proposal
> > 
> > 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.
> > 
> > Ciao
> > Hannes
> > 
> > 
> > 
> > 
> > 
> > Barney Wolff wrote:
> > > 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 
> > > 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.
> > >
> > > 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.
> > >
> > > 
> > 
> > 
> > --
> > 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/>
> 
>

---

From: Barney Wolff <[email-masked]>
Date: Mon, 7 Jan 2008 18:05:16 -0500

On Mon, Jan 07, 2008 at 10:54:02AM +0200, Hannes Tschofenig wrote:
> 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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Jan 2008 15:30:26 -0800

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 

> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Monday, January 07, 2008 3:05 PM
> To: Hannes Tschofenig
> Cc: [email-masked]; [email-masked]
> 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:
> 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:
> >> like the following.  If so, why?  If not, and there is some 
> >> expression of support, I could write it up as a draft.
> >> 
> server have to 
> >> know, but the authenticator does not.
> >> 
> >> domain-authenticator-specific key derived from it that the 
> peer can also derive.
> >>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 09 Jan 2008 08:26:52 +0100

Bernard Aboba wrote:
> However, the routing requirements for the ERX application are different
> from those in normal AAA exchanges, because here key state (unlike the
> AAA credentials database) is not replicated.   That means that messages
> can't just be routed based on a "Domain Identifier" -- they actually
> have to be addressed to specific servers, since only those servers will

  Yes and no.  The NAI could be decorated with a re-auth request, e.q.
"[email-masked]@REAUTH".  Existing servers not implementing re-auth
could be configured to strip/ignore "@REAUTH", and forward the request
as normal.

  Servers implementing re-auth could forward the request to a
re-authentication server.  The key data obtained on initial login could
also be forwarded to that same re-authentication server.  Nobody else
needs to know or care where those servers are located.

  Of course, this only works for re-authentication within one domain.
If the user tries to re-authenticate to a different domain, then the
request has to be forwarded back up the proxy chain to another server
which has cached those credentials, or which can authenticate the user
from scratch.

> For example, a "session resume NAI" could identify the specific EAP
> Session-Id that is being resumed, as well as the realm in which that key
> resides.  However, an NAI including only the realm will not necessarily
> be routed to the server or proxy that holds the key state, because AAA
> deployments often point the authenticators at different AAA servers or
> proxies for load balancing purposes.   To ensure that the request goes
> to the right place, the specific server name needs to be provided within
> the NAI. 

  It is up to that domain to ensure all of it's AAA servers have the
same policy.  This includes managing state for multiple login detection,
and potentially re-auth keys.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 09 Jan 2008 10:53:35 +0100

Bernard Aboba wrote:
> Doesn't this imply a significant degree of complexity?  For example,
> one argument for the RFC 4507 PAC is that avoiding server-side state
> enables better scaling and authentication performance, because RADIUS
> servers don't replicate TLS key state.

  The re-authentication credentials aren't TLS key state, though.  From
the current proposals, they're just opaque keys.  They may be
*generated* from TLS key state, but once generated, they can be cached
by intermediate servers.

>  It's hard to reconcile that
> argument with the idea of having the domain keeping track of server side
> state. 

  Some server somewhere has to keep track of the re-authentication
credentials.

  Alan DeKok.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 9 Jan 2008 12:13:20 -0800

> Sent: Wednesday, January 09, 2008 12:18 AM
> To: Alan DeKok
> Cc: Hannes Tschofenig; [email-masked]; [email-masked]; 
> [email-masked]
> > same policy.  This includes managing state for multiple login 
> > detection, and potentially re-auth keys.
> 
> Doesn't this imply a significant degree of complexity?  For 
> example, one argument for the RFC 4507 PAC is that avoiding 
> server-side state enables better scaling and authentication 
> performance, because RADIUS servers don't replicate TLS key 
> state.  It's hard to reconcile that argument with the idea of 
> having the domain keeping track of server side state. 
> 
> If there is a way to push that state on the peer, things 
> would be much simpler.  For example, if the ERX exchange were 
> to leave the peer with an NAI identifying the "local server" 
> and corresponding key state, then the peer could use that 
> "re-auth" NAI in subsequent requests. 
> 

That is what is done.  The peer performs the ERP exchange with
"rIKName@localdomain", where the "rIKName" is the name of the
reauthentication integrity key that is used to authenticate the ERP
exchange and "localdomain" identifies the domain name of the local ER
server.  For local domains that replicate key material, this domain name
may actually route to one of the multiple local ER servers; for local
domains that strictly have one server, they have the burden of providing
local domain names that are server-specific.   

The peer learns the local domain name at the time of ERX bootstrapping
and uses that, along with the corresponding rIKName as the username part
of its NAI at the time of reauthentication.  

Vidya