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

From: Charles Clancy <[email-masked]>
Date: Tue, 01 May 2007 18:10:13 -0400

I propose the following text to address this:

     In [I-D.housley-aaa-key-mgmt], "key scope" is who is authorized to
     possess a key, and "key context" is how that key should be used.
     For HOKEY, we shall further define "key context" to specifically
     include a service authorized to use a key, and a domain in which
     that key is applicable.  Note that for USRKs, the domain would be
     unrestricted, and for DSRKs, the service would be unrestricted.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

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:[email-masked]] 
> Sent: Wednesday, April 04, 2007 5:39 PM
> To: Madjid Nakhjiri
> Cc: [email-masked]
> 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.
> 

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

---

From: Charles Clancy <[email-masked]>
Date: Tue, 01 May 2007 19:36:12 -0400

AAA administrative domain

Bernard Aboba wrote:
> What does "domain" mean here?
> 
> Charles Clancy said:
>

---

From: Charles Clancy <[email-masked]>
Date: Tue, 01 May 2007 20:04:44 -0400

The current EMSK keying hierarchy has a notion of a Domain-Specific Root 
Key (DSRK) as a child to the EMSK.  The idea is that this key can be 
generated by your home EAP server and delivered to a AAA server in 
another domain and used as the root key for service-specific keys when 
roaming outside your home AAA domain.  This essentially delegates 
authority for service-specific keys in that domain to that domain.  The 
DSRK would specifically be scoped for that AAA server, and its context 
would be restricted to within that AAA domain.

Bernard Aboba wrote:
> A key derived by a AAA server may only be available to that server, not 
> to other AAA servers within the administrative domain.  So I'm not sure 
> what it means for a key to be "applicable" to a AAA server that is not 
> within the key scope.
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 01 May 2007 16:35:02 -0700

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 01 May 2007 16:58:04 -0700

A key derived by a AAA server may only be available to that server, not to 
other AAA servers within the administrative domain.  So I'm not sure what it 
means for a key to be "applicable" to a AAA server that is not within the 
key scope.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 02 May 2007 11:46:50 -0700

This is bringing a practical issue for the protocol, since at some point we
have to come up with bit-fields to cover domain info:

We can have a domain label ([email-masked]), that covers the domain (I
guess I have seen this elsewhere), then domain can go in the _context_.

But if we need to specify every AAA server within that domain, then it seems
that the domain needs to consist of a list of AAA servers, which will go in
_scope_.

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, May 01, 2007 5:05 PM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: [HOKEY] key scope versus Context. consensus call: key
distributionsecurity requirement