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

[Russ Housley <[e-mail]>]

If the set of data element together provides the scope and context, 
then you will get no trouble from me.

Russ

At 05:08 PM 4/11/2007, Madjid Nakhjiri wrote:
>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





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