[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
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
> 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.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.