[Emu] Re: [Hokeyp] USRK issue

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

Hi Madjid,

On Mon, Nov 27, 2006 at 03:12:28PM -0800, Madjid Nakhjiri wrote:
> Hi Yoshi,
> 
> I cced EMU since I thought we could use some of the expertise there.
> 
> Yes, this absolutely has to do the "key derivation" portion of application
> keying. We just thought the term "application" is confusing and used "usage
> specific" instead. Please note that the full scope of "application keying"
> is a lot wider than just deriving the USRKs. No child key derivation, key
> distribution or authorization issues are being discussed. We may however
> need to create a "handover USRK" if we go based on EMSK for hokey. So at
> least we got a small part of "application keying" idea approved in the
> charter and that is not a bad thing IMO.
> 
> 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.

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.

> 
> I don't agree with the fact that rekeying one USRK would require rekeying
> other USRK, there supposed to be a crypto-separation between the USRKs and
> from USRK up to EMSK. So as long as you can access the EMSK you can rekey an
> individual USRK if you want.

Selective re-keying in key hiearchy approach would be possible only up
to the EMSK lifetime and with the use of a usage-specific re-keying
protocol.  I think this should be cleary spelled out in the I-D.

> 
> Now as far as the need for rekeying USRK based on rekeying EMSK, the more
> philosophic question is this:
> say I have a usage (take Mobile IP) that needs a MIP-USRK, from which a
> bunch of other MIP related keys are derived (say Mobile node-home agent key,
> MN_HA_key). The AAA needs to authorize MIP before the MIP-USRK is generated,
> but EMSK is not exported to the AAA layer, which means, the AAA server/layer
> needs to request the EAP/ method layer/"EMSK-key holder" to generate the
> MIP-USRK for it. At this point and beyond,  it should be up to the AAA
> server to decide how long the user is authorized to do MIP and then decide
> the life time for MIP-USRK or the children keys (MN_HA_KEY). Why would the
> AAA have to tie the MIP-USRK or MN_HA_KEY to the EMSK anymore? Why should
> MIP authorization and security be tied to the initial EAP access
> authentication?

If you create those keys based on key derivation not key wrapping,
then the AAA would have to tie those keys because there is
cryptographic dependency between parent and child keys.  If you don't
want to tie those keys, then key derivation should not be used, IMO.

Yoshihiro Ohba


> If you agree with this, then EMSK rekeying would not automatically require
> USRK rekeying for every USRK? If not, then yes, there is a problem.
> 
> Madjid
> 
> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Yoshihiro Ohba
> Sent: Wednesday, November 22, 2006 5:46 PM
> To: hokeyp at opendiameter.org
> Subject: [Hokeyp] USRK issue
> 
> (I tried to reply the following thread but somehow my reply did not
> appear to the list:
> http://www.opendiameter.org/pipermail/hokeyp/2006-November/000356.html, 
> so let me post with a new thread.)
> 
> I have a fundamental issue with deriving multiple root keys
> used for different purposes as a form of key hierarchy.
> 
> There are two reasons.  When re-keying of EMSK happens, it would
> require all USRKs derived from EMSK to be re-keyed, regardless of the
> purposes the USRKs are used for.  Second, it is difficult to re-key
> only a specific USRK without re-keying other USRKs as well.  If we
> consider use of EAP for multiple different types of applications, this
> issue seems critical to me.
> 
> I would suggest further investigating this fundamental issue before WG
> adoption of draft-salowey-eap-emsk-deriv-01.  My sense is that a
> Kerberos-like approach (i.e., use of tickets that carries encrypted
> key and associated attributes including lifetime and key scope/usage)
> is much better than key derivation approach such as described in
> draft-salowey-eap-emsk-deriv-01, from key management perspective even
> if we consider the complexity aspect of a Kerberos-like approach.
> 
> I would like to also point out that USRK is related to so called
> "application keying" in HOAKEY BOF in March 2006, and "application
> keying" was ruled out from the BOF discussion.
> 
> Regards,
> Yoshihiro Ohba
> _______________________________________________
> Hokeyp mailing list
> Hokeyp at opendiameter.org
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> 
> 
> 

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