[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Hi Vidya,
Thank you very much for responding.
On Thu, January 3, 2008 10:20 pm, Narayanan, Vidya wrote:
> 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.
I understand that it is "not prohibited" but it is not mandatory and
therefore when looking at the security of the scheme we have to operate
under the assumption that the key is being exposed to parties that are
the intended recipient.
This non-authorization isn't enforced anyway is it? It is merely by
fiat in the document that the proxies are not authorized to use the key.
We're just assuming that they won't misbehave.
> 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.
You could only end up with the same rMSK being used for multiple NASs
if the sequence number the peer used during re-auth was the same. So if
that is deemed a problem then mandate that the sequence number be a
monotonically increasing counter which is initialized to 1 when the peer
finishes initial and full EAP authentication and not when a new rRK is
derived. No need for any domain differentiation at any level, just a
simple edit of half a sentence in the ERX document.
If this is the only problem that is solved by having this key hierarchy
then let's do the simple edit I propose and get rid of the key hierarchy!
Agreed?
> 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.
Yes, Domain A and Domain B may actually be different administrative
domains! And the proxies between them and the home server might be too!
And they all might have different business relationships with each other!
That's my point!
We're just placing blind trust in proxies to "do the right thing".
That being the case the level of blind trust placed in ER servers in
Domain A or Domain B CANNOT be any less than the level of blind trust
placed in proxies between them and the home AAA server.
Again, what _specific problem_ is being solved by having different keys
in Domain A and Domain B? Do you want to stop NASs in Domain A from
impersonating NASs in Domain B but for some reason you're not concerned
about proxies impersonating Domain A or Domain B in their entirety?
It seems to me that any problem that requires different keys for ER
Servers in Domain A and Domain B will also require different keys for all
proxies. But we can't do that so we can't really use key separation to
solve the problem, whatever it is.
Key separation would be important if there was a 3 party protocol between
the home AAA server the ER server and the peer that disclosed a unique
key to the ER server and only the ER server. But there isn't.
The argument against a 3 party protocol is that the peer doesn't care
to whom the key is disclosed as long as he continues to get service
provided (and there's no surprises in the bill at the end of the month
but that's what legal documents are for). If the network has to disclose
keys to unintended recipients in order to continue to be able to provide
service then have at it, disclose keys!
What we've ended up with is a network being trusted implicitly to not
misbehave with keys it obtains and a peer that doesn't care as long as
he gets a dial tone. So please tell me what problem is being solved by
having this key hierarchy.
Thank you again for responding to my post and I would be very grateful
if you could answer my questions above and/or point out the errors in
my logic.
regards,
Dan.
> 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/>