[Emu] RE: [Hokeyp] USRK issue

[Madjid Nakhjiri <mnakhjiri at huawei.com>]

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.

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.

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 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