Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt

[Alan DeKok <aland@deployingradius.com>]

Narayanan, Vidya wrote:
> Thanks for the review.  Let me attempt to clarify a few things that may
> answer majority of your questions below.  The DSRK is a domain specific
> root key that is derived from the EMSK for the purpose of having a local
> EAP Re-authentication server (ER server) in the visited domain.

  I'm not sure I understand why.  If there isn't an EAP
re-authentication server, then the EAP authentications will go through
the local AAA server.  So there is significant benefit in *always* going
through the local AAA server.  i.e. having the AAA servers cache the
keys required for re-authentication.

> "Visited domain" doesn't necessarily imply administrative in this case -
> a large domain can be broken up into multiple smaller domains for sake
> of efficient re-authentication.  

  I'm not sure I understand how this helps efficiency.  If there's one
large domain for the initial authentication, then only one domain is
needed.  If the home server can handle the re-authentication, then
there's doubly no need for multiple domains.

> This is done so that the latency involved in reauthentication at the
> time of a handoff for a peer is minimal (the peer doesn't have to go
> back to the home AAA server to get reauthenticated).  When the peer
> hands off across domains (i.e., leaves the boundary of an ER server), it
> needs to communicate with the home AAA server to obtain a new DSRK for
> the new ER server.  This may be done using a full EAP exchange or with
> an ER exchange with the home AAA server.  

  If the re-authentication has to go back to the home AAA server for a
to obtain a new DSRK, why are there multiple domains?  The home server
is manifestly capable of handling all re-authentication requests.

> The problem statement and use cases are described further in
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt.
> The ERX protocol draft itself describes the protocol in detail -
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt -
> figure 2, for instance, shows the recipient of the DSRK and how it is
> further used for reauthentication during authenticator changes within
> that domain.  

  I think I need to address many of my comments to that draft.

> Hope this clarifies many of the things you ask below.  A few further
> comments inline on the other questions. 

  It clarifies it a little.  I've gone over the problem statement draft,
and have some questions about it.

> Actually, this document has gone through a couple of contortions due to
> lack of clarity from the RADIUS side on how to proceed here.

  The radext WG is always available to answer questions.  I've been
lurking on hokey for a while, but until recently have been too busy to
pay much attention to the drafts.

> There will only be one key response, but the key name is still needed so
> that the peer, upon reauthentication later, can refer to the key.

  Ok... I have questions, but I'll address them to another draft, I think.

> As I mentioned before, there is no goal to change the RADIUS security
> measures.  This draft will also be updated to work with keywrap and DTLS

  I don't believe either method is strictly necessary for transporting
these keys.  There are alternatives that should be able to work.

  Alan DeKok.

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