[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Hi Dan,
There are two points here. End-to-end protection of key material is
certainly feasible and is not prohibited by the model - it is quite
feasible in the enterprise space, for instance. Even when hop-by-hop
protected, the proxies don't have authorization to use the DSRK. It is
only meant for use by the local ER server.
For key separation, it is important to have different DSRKs per domain.
For instance, there must be separation between the rMSKs given to the
different NASs - if the same DSRK was given to multiple local ER
servers, you would end up with the same rMSK for multiple NASs. We
could come up with other key separation techniques that keep the rMSK
unique, but that would mean introducing the domain or an equivalent
differentiation at that level instead of at the DSRK.
Also, another point is that Domain A and Domain B may actually be
different administrative domains, in which case, it is not necessarily
true that they have a business relationship with each other or that they
have the same level of relationship with the home domain. So, there is
no assumption that any one visited domain is a proxy in the path between
another visited domain and the home domain. Hence, ensuring proper key
separation at the DSRK level is important.
Regards,
Vidya
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Thursday, January 03, 2008 4:33 PM
> To: Narayanan, Vidya
> Cc: Alan DeKok; radext mailing list; hokey@ietf.org
> Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
>
>
> Hi Vidya,
>
> 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?
>
> Dan.
>
> 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.
> >
> > 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.
> >>
> >
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY@ietf.org
> > https://www1.ietf.org/mailman/listinfo/hokey
> >
>
>
>
--
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/>