[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
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.
Thanks,
Vidya
> -----Original Message-----
> From: Alan DeKok [mailto:aland@deployingradius.com]
> Sent: Thursday, January 03, 2008 2:01 PM
> To: Narayanan, Vidya
> Cc: hokey@ietf.org; '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
> >
> 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/>