RE: [HOKEY] key scope versus Context. consensus call: key distribution security requirement

[Madjid Nakhjiri <[e-mail]>]

Hi Russ,

Ok, yes, I stand corrected. There is no inconsistency. But there is an
overlap as you said. When we get into defining the syntax for scope versus
context for transport and protocol purposes (e.g. we want to possibly
transmit the key context along with the key itself with a AAA message) or
define "usage" for usage specific root key derivation from EMSK, it is
cleaner if there is no overlap in the definitions, so we can say:

Scope is just a bunch of identities, while context is the rest (loosely
speaking).

Thanks for the explanation on "manner". Ok, that is what I understood. So
manner is the cryptographic use of the key (derive keys, wrap keys, protect
stuff and so on).
So it seems "usage" could be another bullet for context (for the purpose of
EMSK draft, possibly not for Housley draft), where "usage" is hokey, Mobile
IP, etc.

R,

Madjid


-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Wednesday, April 11, 2007 1:53 PM
To: Madjid Nakhjiri; 'Charles Clancy'
Cc: [e-mail]; 'Bernard Aboba'
Subject: RE: [HOKEY] key scope versus Context. consensus call: key
distribution security requirement

Madjid:

See draft-housley-aaa-key-mgmt-09; I belive that key scope is defined 
as the parties to whom the key is available.  Also, a party has 
access to a particular key if it has access to all of the secret 
information needed to derive it.

There is overlap between the concepts of key scope and key 
context.  There is not an inconsistency in my view.

The manner in which a key will be used depends on the protocol 
environment that is being supported.  Will the key be used to derive 
other keys?  Will it be used to encrypt data?  Will it be used to 
encrypt other keys?  Will it be used to integrity protect data (e.g., 
compute a MAC)?  Every party that has access to the key needs to 
answer these questions the same way.

I continue to belive that the key context includes the other parties 
that are expected to perform operations with the key.  Consider an 
encryption key that is used with IPsec ESP.  These are simplex 
keys.  So, one party will perform encryption operations with the key, 
and the other party will perform decryption operation with the 
key.  Both parties need to know about the other, and which operation 
will be performed by each.

Russ


At 03:59 PM 4/11/2007, Madjid Nakhjiri wrote:
>Hi Charles,
>
>Apologize for procrastinating on my homework, I was planning on looking at
>the PS and see what text changes are needed. But it seems that we first
need
>a clear and more stringent definition of key scope and key context. Looking
>at these, the EAP keying doc and the Housley doc, and having USRK and hokey
>PS in mind, I think we should once and for all, nail the terminology down
>for the purpose of HOKEY and go forward based on that, so before suggesting
>text, I like to add a definition for "scope" and "context" to the main PS
>draft:
>
>1) scope: Housley draft does not define this, but EAP keying does:
>
>Key Scope
>      The parties to whom a key is available [EAP_keying].
>
>I suggest we adopt this for HOKEY and EMSK hierarchy drafts. However, I am
>not sure if the domain for the key would go into the scope definition or in
>the context definition.
>
>2) Context: EAP keying does not define this, but Housley does it in a way
>that causes confusion for hokey:
>
>"The context includes the following.
>
>             o  The manner in which the keying material is expected to
>                be used.
>
>             o  The other parties that are expected to have access to
>                the keying material.
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>It seems that there is a bit of inconsistency in scope versus context,
>especially the second bullet: Before this exercise, I was assuming that
>scope was simply the id of the two parties sharing the key, but it seems
>that it is ALL parties that can access it.  So I think we should remove the
>second bullet and Russ and Bernard should remove that bullet as well (and
>instead add the definition of scope explicitly in the Housley draft).
>
>"The manner" in first bullet is vague to me, especially now that we are
>defining "usage specific root keys". Is "manner" a usage, such as hokey or
>Mobile IP? Is it for a domain? Is it for a crypto purpose, such as signing
>or encryption? Is it to be a root for a hierarchy and not used for traffic?
>Or is it all the above. For Housley doc this might be ok, but I think for
>hokey, we need to be more specific in our requirements on context and the
>semantics that goes in it.
>So I am suggesting something like the following for "key context" (the main
>thing is I am replacing the second bullet)
>
>             o  The usage for which the keying material is generated.
><!-Madjid: we can say "usage and domain" if we want.--> The usage is
defined
>in [EMSK-hiearchy], e.g. Mobile IP, handover keying, etc.
>
>             o  The purpose for the keying material, e.g. traffic
protection
>(signing, encryption), signaling protection, key derivation, etc.
><!--Madjid: we can be more or less specific, but the purpose is
important-->
>
>             o  The expected lifetime of the keying material.  Lifetime
>                of a child key SHOULD NOT be greater than the lifetime of
>                its parent in the key hierarchy."
>
>
>
>I can send mods for requirements based on the above later.
>
>R,
>
>Madjid
>
>
>-----Original Message-----
>From: Charles Clancy [mailto:[e-mail]]
>Sent: Wednesday, April 04, 2007 5:39 PM
>To: Madjid Nakhjiri
>Cc: [e-mail]
>Subject: Re: [HOKEY] consensus call: key distribution security requirement
>
>Madjid,
>
>My opinion was that they were all already covered by the problem
>statement in one way or another.
>
>  > 1-Confidentiality --avoiding disclosure of the keying material to
>  > passive and active attackers.
>
>Covered by saying we must conform to I-D.housley-aaa-key-mgmt.  I have
>no problem adding that as an explicit thing in section 6 though.
>
>  > 3-Validation of credential source -- the recipient must prove where
>  > the credential came from and what context it was delivered for.
>
>Prove to whom?  Regardless, that information should be included in the
>key scope and context -- section 6.1.
>
>  > 4-Validation of authorization -- the scope (intended users) of the
>  >        network access credential MUST be distributed as part of the
>  >        credential and MUST be protected to the same degree as the
>  >        credential itself.
>
>See section 6.1 of the current PS.
>
>  > Some of these requirements are simply reflections of Housley document
>  > and to me are met through a channel binding procedure.
>
>Exactly, and CB is already in the PS.
>
>Feel free to send me text if you think section 6.1 should be modified.
>
>--
>t. charles clancy, ph.d.  |  [e-mail]  |  www.cs.umd.edu/~clancy
>
>
>_______________________________________________
>HOKEY mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/hokey




_______________________________________________
HOKEY mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hokey