[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
There may be proxies in between AAA-Home and Local ER server A
and between AAA-Home and Local ER Server B. There is strong consensus
in the group that there is no problem with this that all the proxies
will behave themselves and not abuse the fact that they know DRSK1
and/or DRSK2. That being the case why cannot the same logic that justifies
these proxies having such keying material be used to just give the
same key to Local ER Server A and Local ER Server B? Why do we need
to have different DRSKs? What problem are you trying to solve and isn't
that problem still going to be there since proxies are now involved?
On Thu, January 3, 2008 3:02 pm, Narayanan, Vidya wrote:
> Hi Alan,
> Some of this is revisiting the HOKEY charter discussions and can be
> found in the archives, but let me try a bit further to clarify here.
> Consider the following figure:
> | AAA-Home |
> | |
> | Local ER server A | | Local ER
> server B |
> | (Domain A) | | (Domain
> B) |
> | |
> | | |
> -------- -------- --------
> | NAS A1 | | NAS A2 | | NAS B1 |
> | NAS B2 |
> -------- -------- --------
> | Peer | ---------->
> In the figure above, the peer is attached to a NAS (say, A1) in Domain
> A, while its home domain corresponds to AAA-Home" which is potentially
> much further away than Domain A is. The first time around, the peer
> authenticates with its home AAA server, which results in an MSK at NAS
> A1 and an EMSK at AAA-Home. This is in accordance with regular EAP
> operation. When the peer, the local domain and the AAA-Home also
> support ERP, a DSRK (DSRK1) may be requested by the local ER server A at
> the time of the EAP exchange. DSRK1 is derived from the EMSK and given
> to the Local ER Server A. Now, when the peer moves from NAS A1 to NAS
> A2, it only needs to perform an ERP exchange with the Local ER Server A.
> No exchange is required with AAA-Home. This finishes much quicker than
> an exchange that would have to go all the way to AAA-Home.
> It is when the peer moves from Domain A to Domain B that the peer has to
> talk to AAA-Home again. At this point, a DSRK2 may be given to Local ER
> Server B, which then gets used for re-authentication within that domain
> (say, when the peer moves from NAS B1 to NAS B2).
> As shown, all re-authentications within a local domain are restricted to
> that domain with no exchanges needed with the home domain (unless the
> DSRK expired). Exchanges involve the home domain when the peer crosses
> domain boundaries.
> Hope this helps.
>> -----Original Message-----
>> From: Alan DeKok [mailto:firstname.lastname@example.org]
>> Sent: Thursday, January 03, 2008 2:01 PM
>> To: Narayanan, Vidya
>> Cc: email@example.com; 'radext mailing list'
>> Subject: 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 -
>> > - 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.
> HOKEY mailing list
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.