RE: [Emu] RE: [Hokeyp] USRK issue

["Ray Bell" <ray at grid-net.com>]

Some comments below

Ray

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri at huawei.com] 
Sent: Thursday, November 30, 2006 3:01 PM
To: 'Yoshihiro Ohba'
Cc: hokeyp at opendiameter.org; emu at ietf.org
Subject: [Emu] RE: [Hokeyp] USRK issue

Hi Yoshi,

-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com] 
Sent: Monday, November 27, 2006 5:48 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; hokeyp at opendiameter.org; emu at ietf.org
Subject: Re: [Hokeyp] USRK issue

<snip>

> 
> Now, any time you have a key hierarchy where the lifetimes are completely
> dependent on the top level key lifetimes, you need to re-key the whole
tree.
> I don't know how that is different for Kerberos, say you are doing a
> Kerberos-EAP combo method, where your key wrapping mechanism uses a key
that
> itself is based on an EMSK that is refreshed, then you are back to square
> one. You have to rekey your key wrapping key too.

Re-keying key wrapping key may not necessary mean immediate re-keying
the keys wrapped by the key wrapping key, because the wrapped key has
no cryptographic dependency with the key wrapping key.  In the case of
Kerberos, whether immediate re-keying is needed when key wrapping key
is invalidated seems to be rather an authorization policy issue.

Madjid>> I thought we were discussing rekeying of USRKs, so I assumed your
Kerberos example was a use case for USRK spec and that is why I said the key
wrapping key could be a USRK. And yes, this being an "authorization policy"
is exactly the point I am making

In the case of key-hierarchy based approach, there is a cryptographic
dependency between the root key and its child keys.  Hence, if the
root key is re-keyed, then the old root key is not valid, and it is
natural to think that the child keys derived from the old root key are
no longer valid and re-keying is needed.

Ray >> So this would pertain to the MSK, it being the root key - yes?  Not
to the EMSK.

Madjid>>I don't think cryptographic dependency necessarily translates into
life time dependency, especially if the authorization entity (AAA server) is
possibly different from the entity generating the key (EAP server). Yes, if
you need to rekey using a root key and the root key is now updated, you
should use the updated key, but I think that can be worked into the AAA
server-EAP server API. I am using this terminology, since we know EMSK is
not exported from EAP layer.

Ray >> SDO policy information models support this type of authorization
policy modeling, distribution and enforcement.

 



_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu


_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu