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

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 27 Nov 2006 15:12:28 -0800

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Yoshihiro Ohba
Sent: Wednesday, November 22, 2006 5:46 PM
To: [email-masked]
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
[email-masked]
http://www.opendiameter.org/mailman/listinfo/hokeyp

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Nov 2006 20:48:17 -0500

Hi Madjid,

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

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

> MIP authorization and security be tied to the initial EAP access

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 30 Nov 2006 15:01:15 -0800

Hi Yoshi,

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Monday, November 27, 2006 5:48 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; [email-masked]; [email-masked]
Subject: Re: [Hokeyp] USRK issue

<snip>

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

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.

---

From: "Ray Bell" <[email-masked]>
Date: Thu, 30 Nov 2006 15:46:41 -0800

Some comments below

Ray

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 3:01 PM
To: 'Yoshihiro Ohba'
Cc: [email-masked]; [email-masked]
Subject: [Emu] RE: [Hokeyp] USRK issue

Hi Yoshi,

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Monday, November 27, 2006 5:48 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; [email-masked]; [email-masked]
Subject: Re: [Hokeyp] USRK issue

<snip>

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

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 30 Nov 2006 17:15:58 -0800

Yes, SDOs are increasingly using AAA for variety of network security and
authorization management tasks and for the AAA server to act as a center of
authority, such flexibility is needed.

Madjid
-----Original Message-----
From: Ray Bell [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 3:47 PM
To: 'Madjid Nakhjiri'; 'Yoshihiro Ohba'
Cc: [email-masked]; [email-masked]
Subject: RE: [Emu] RE: [Hokeyp] USRK issue
<snip>