Subject: Re: [HOKEY] consensus call: key distribution security requirement

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 02 Apr 2007 12:26:25 -0700

Sam sent an email to the IETF discussion list on identities and identity 
assertion in a similar (same?) context as we are discussing.  I am not 
sure whether I fully understand what he is saying and so I cannot say 
that I agree with him fully, but in a conversation with him in Prague, I 
agreed with him at a conceptual level (I may yet ask him for 
clarification on his email to the IETF Discussion list).

Anyway, the point of this email is that there is a notion of identities 
at different layers and furthermore there is also a notion of whether 
identity assertion is required or possible in all deployments.  So, I 
suggest that we should use the word "recommended" instead of "required" 
in this latest addition to the PS.

thanks,
Lakshminath

Charles Clancy wrote:
> HOKEY WG,
> 
> The 3-party protocol proposal at IETF 68 listed a variety of protocol 
> requirements, some of which went beyond those currently specified in the 
> problem statements draft.  The main extension was a requirement for 
> stronger key distribution security.
> 
> Discussion: The problem statements document currently requires channel 
> bindings to allow clients to authenticate the network to which they are 
> connecting, and prevent the lying NAS problem.  However one possible 
> implementation of channel bindings would allow keys to be distributed 
> prior to the network being authenticated by the peer.  While the peer 
> may decide to not use a network after it's validated its identity, 
> network entities could retain the keying material.  There has been much 
> debate on the list as to whether or not network entities could 
> maliciously use this keying material, and the intent here is to not 
> rehash all that discussion.
> 
> Question: Should additional text be added to the problem statement draft 
>  to require peer authorization for distributing keying material?
> 
> Protocol Implications: If "yes" then a 3-party protocol would be need, 
> and would require L2 advertisement of the NAS-ID and local AAA domain 
> name.  If "no" then channel bindings where identities are hashed into 
> the key derivation would be sufficient.
> 

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 3 Apr 2007 18:25:52 -0700

I'm barely caught up on all the email after having been on vacation
until now, so, pardon me if I'm bringing up stuff that's already been
discussed here. 

I share some of Glen's concerns about "requiring" peer consent and a
3-party protocol and about how practically deployable that is. In my
conversations with Dan in Prague, it seemed like we were on the same
page about including channel binding information in the HOKEY protocol
between the peer and server. I think such channel binding information
must be optional and not required. In some systems, there are no adverse
effects of distribution of key material without explicit peer consent
and there is no reason to place upper layer identity advertisement
requirements on the lower layers for such systems. In some other
systems, it may be a good idea to do so and having the capability to do
that in the protocol would be useful there. 

To specifically answer your question, I don't believe we need to update
the problem statement. It already captures the channel binding stuff and
the explicit data that the peer and authenticator may include is one way
of providing channel binding. 

Vidya

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Saturday, March 31, 2007 12:16 PM
> To: [email-masked]
> Subject: [HOKEY] consensus call: key distribution security requirement
> 
> HOKEY WG,
> 
> The 3-party protocol proposal at IETF 68 listed a variety of 
> protocol requirements, some of which went beyond those 
> currently specified in the problem statements draft.  The 
> main extension was a requirement for stronger key 
> distribution security.
> 
> Discussion: The problem statements document currently 
> requires channel bindings to allow clients to authenticate 
> the network to which they are connecting, and prevent the 
> lying NAS problem.  However one possible implementation of 
> channel bindings would allow keys to be distributed prior to 
> the network being authenticated by the peer.  While the peer 
> may decide to not use a network after it's validated its 
> identity, network entities could retain the keying material.  
> There has been much debate on the list as to whether or not 
> network entities could maliciously use this keying material, 
> and the intent here is to not rehash all that discussion.
> 
> Protocol Implications: If "yes" then a 3-party protocol would 
> be need, and would require L2 advertisement of the NAS-ID and 
> local AAA domain name.  If "no" then channel bindings where 
> identities are hashed into the key derivation would be sufficient.
> 
> --
> t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy
> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 3 Apr 2007 22:44:53 -0400

Hi Vidya,

Can you please explain why channel binding information must be
optional?

Can you also explain in which system there are no adverse effects in
key distribution without explicit peer consent?

Regards,
Yoshihiro Ohba

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 3 Apr 2007 21:55:33 -0700

Hi Charles, 

I see no reason to require the peer to explicitly authorize distribution
of key material.   

I'm not sure I understand how the protocol implications stated below
immediately follow.  It's not clear what "identities" you are going to
hash with the key, but whatever they are they must be known to the peer.
In addition I don't believe that explicit authorization requires a three
party protocol (but in any case I don't think it is necessary).   

Joe

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 4 Apr 2007 11:16:09 -0700

Hi Yoshi, 

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 7:45 PM
> To: Narayanan, Vidya
> Cc: Charles Clancy; [email-masked]
> Subject: Re: [HOKEY] consensus call: key distribution 
> security requirement
> 
> Hi Vidya,
> 
> Can you please explain why channel binding information must 
> be optional?
> 

Briefly, in many cases, as long as the peer receives a certain level of
service and is charged for the same, the identity of the network entity
providing the service is irrelevant. In some cases, it may be relevant
and hence, it would be good to have the capability to do channel
binding. But, for the other cases, there is no need to mandate the lower
layer to advertise identities. 

> Can you also explain in which system there are no adverse 
> effects in key distribution without explicit peer consent?
> 

I have not seen any real loss of security properties in distribution of
keys without peer consent, as long as the keys are scoped correctly, not
shared and freshness is always ensured. 

Please see
http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf if
you are interested in more details. I had put some slides together a
while ago on this identities issue. 

Vidya

> > must be optional and not required. In some systems, there are no 
> > adverse effects of distribution of key material without 
> explicit peer 
> > consent and there is no reason to place upper layer identity 
> > advertisement requirements on the lower layers for such systems. In 
> > some other systems, it may be a good idea to do so and having the 
> > capability to do that in the protocol would be useful there.
> > 
> > To specifically answer your question, I don't believe we need to 
> > update the problem statement. It already captures the 
> channel binding 
> > stuff and the explicit data that the peer and authenticator may 
> > include is one way of providing channel binding.
> > 
> > Vidya
> > 
> > > protocol requirements, some of which went beyond those currently 
> > > specified in the problem statements draft.  The main 
> extension was a 
> > > requirement for stronger key distribution security.
> > > 
> > > Discussion: The problem statements document currently requires 
> > > channel bindings to allow clients to authenticate the network to 
> > > which they are connecting, and prevent the lying NAS problem.  
> > > However one possible implementation of channel bindings 
> would allow 
> > > keys to be distributed prior to the network being 
> authenticated by 
> > > the peer.  While the peer may decide to not use a network 
> after it's 
> > > validated its identity, network entities could retain the keying 
> > > material.
> > > There has been much debate on the list as to whether or 
> not network 
> > > entities could maliciously use this keying material, and 
> the intent 
> > > here is to not rehash all that discussion.
> > > 
> > > Question: Should additional text be added to the problem 
> statement 
> > > draft
> > > Protocol Implications: If "yes" then a 3-party protocol would be 
> > > need, and would require L2 advertisement of the NAS-ID 
> and local AAA 
> > > domain name.  If "no" then channel bindings where identities are 
> > > hashed into the key derivation would be sufficient.
> > > 
> > > --

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 4 Apr 2007 16:24:11 -0700 (PDT)

Hi Vidya,

  As I explained to you previously the issue of "peer detects mismatch
during secure association protocol" (slide 5 of your deck) doesn't work
because these are symmetric keys and the "middle entity" can impersonate
the client now. Every single property that you want to give to the key
being distributed is lost.

  Of course you may not view that as a problem but I think that has more
to do with what you want to do then with whether it's secure or not.

  Can you please explain how to ensure that keys are properly scoped
if you do not bind the scoping information to the exchange that distributes
the key? How can the peer have any assurance that the key is "not shared"
(one of the qualifiers you mention) if it did not take part in the
distribution of its key?

  Why not just send the EMSK to every entity that the AS thinks it has a
security association with? I mean, in many cases as long as the peer
receives a certain level of service and is charged for same then the
identity of the entity receiving the EMSK is irrelevant and channel
binding isn't important and as long as we scope the key properly
(everyone with whom the AS shares a security association-- aka "the
network") then it's OK. After all, nothing matters as long as the peer
is satisfied and "if the peer is not satisfied or there is a billing
issue, it contacts its home network and tries to get service from some
other node instead" (to quote from slide #6).

  Dan.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 04 Apr 2007 16:26:18 -0700

Hi Charles,

The 3party key distribution protocol provide somewhere around 8-9
requirements, the peer consent being only one of them, there are other
requirements that are IMO undoubtedly important for the mechanisms HOKEY is
dealing with. For example (using the numbers in the draft):

1-Confidentiality --avoiding disclosure of the keying material to passive
       and active attackers.
3-Validation of credential source -- the recipient must prove where the
credential came from and what context it was delivered for.
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.

Some of these requirements are simply reflections of Housley document and to
me are met through a channel binding procedure.

Treating all the requirements based on the most controversial one seems to
be equivalent of pointing to one bunny (no offense to peer consent
opponents) tied next to other 7 huskies tied to a sled and then dismissing
all the huskies.

In my opinion we should treat each of these requirements individually and
not just the peer consent one and I think we will then can judge whether the
3 party distribution adds any value.

And finally to give you my personal opinion the above 3 requirements are at
least should be added to the PS document, or we should discuss to see
whether the existing PS requirements do cover these somehow.

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Saturday, March 31, 2007 12:16 PM
To: [email-masked]
Subject: [HOKEY] consensus call: key distribution security requirement

HOKEY WG,

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 04 Apr 2007 16:32:40 -0700

I agree with Joe here. I personally am not quite convinced that peer
explicit authorization is needed, as long as the peer and the server both
agree that they are talking to the same authenticator, we should be fine.
And some additional assurance is provided while deriving TSKs later on.

I also think that you need the identities to arrive at keys for various
domains or various authenticators (if we are still talking about key
hierarchy based on HRK, of course). In that case I don't see how the
identities can be used in key derivation, if the peer and server don't
notify each other of their own ids and don't agree on the identities that
are used in the derivations.

The 3 party process seems to be addressing a number of other requirements,
not just peer consent (which seems to be the most implicit requirement the 3
party is addressing).

R,

Madjid

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 9:56 PM
To: Charles Clancy; [email-masked]
Subject: RE: [HOKEY] consensus call: key distribution security requirement

Hi Charles, 

Joe

> statement draft

---

From: Charles Clancy <[email-masked]>
Date: Wed, 04 Apr 2007 19:39:25 -0500

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.

 >        credential and MUST be protected to the same degree as the

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.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: Charles Clancy <[email-masked]>
Date: Wed, 04 Apr 2007 20:27:19 -0500

All,

I think we need to look at the protocols.  To compare...

3-party protocol (Dan's proposal, slightly simplified assuming AAA 
provides the necessary transport security):

    1) A->B: A, {A, B, Na}Kas
    2) B->S: A, B, {A, B, Na}Kas
    3) S->B: {B, Na}Kas, {A, Kab}Kbs
    4) B->A: {B, Na}Kas

EAP-ER (translated to above notation and assuming AAA transport):

    1) A->B: A, {A, Na}Kas
    2) B->S: A, B, {A, Na}Kas
    3) S->B: {Na}Kas, {Kab}Kbs
    4) B->A: {Na}Kas

EAP-ER+CB (my proposal for adding channel binding to EAP-ER):

    1) A->B: A, {A, Na}Kas
    2) B->S: A, B, {A, Na}Kas
    3) S->B: {B, Na}Kas, {A, Kab}Kbs
    4) B->A: {B, Na}Kas

So, we've added "A" and "B" in messages 3 and 4, but not added "B" in 
message 1.  I feel this satisfies everything *but* peer consent, and 
doesn't require A to know "B" at the beginning.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 4 Apr 2007 18:20:21 -0700

Hi Dan,
As we talked about this before, there is no attack, when every key
handed out is fresh and unique across any two key fetches from the
server. So, the scoping of keys necessary is about ensuring that the
same key is never ever given out again, even to the (seemingly) same
entity. 

Vidya

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Wednesday, April 04, 2007 4:24 PM
> To: Narayanan, Vidya
> Cc: Yoshihiro Ohba; [email-masked]
>   As I explained to you previously the issue of "peer detects 
> mismatch during secure association protocol" (slide 5 of your 
> deck) doesn't work because these are symmetric keys and the 
> "middle entity" can impersonate the client now. Every single 
> property that you want to give to the key being distributed is lost.
> 
>   Of course you may not view that as a problem but I think 
> that has more to do with what you want to do then with 
> whether it's secure or not.
> 
>   Can you please explain how to ensure that keys are properly 
> scoped if you do not bind the scoping information to the 
> exchange that distributes the key? How can the peer have any 
> assurance that the key is "not shared"
> (one of the qualifiers you mention) if it did not take part 
> in the distribution of its key?
> 
>   Why not just send the EMSK to every entity that the AS 
> thinks it has a security association with? I mean, in many 
> cases as long as the peer receives a certain level of service 
> and is charged for same then the identity of the entity 
> receiving the EMSK is irrelevant and channel binding isn't 
> important and as long as we scope the key properly (everyone 
> with whom the AS shares a security association-- aka "the
> network") then it's OK. After all, nothing matters as long as 
> the peer is satisfied and "if the peer is not satisfied or 
> there is a billing issue, it contacts its home network and 
> tries to get service from some other node instead" (to quote 
> from slide #6).
> 
>   Dan.
> 
> >> Subject: Re: [HOKEY] consensus call: key distribution security 
> >> requirement
> >>
> >> Hi Vidya,
> >>
> > Briefly, in many cases, as long as the peer receives a 
> certain level 
> > of service and is charged for the same, the identity of the network 
> > entity providing the service is irrelevant. In some cases, 
> it may be 
> > relevant and hence, it would be good to have the capability to do 
> > channel binding. But, for the other cases, there is no need 
> to mandate 
> > the lower layer to advertise identities.
> >
> effects in 
> > I have not seen any real loss of security properties in 
> distribution 
> > of keys without peer consent, as long as the keys are scoped 
> > correctly, not shared and freshness is always ensured.
> >
> > Please see
> > 
> http://www.geocities.com/hellovidya/Authenticators_and_Identities.pdf 
> > if you are interested in more details. I had put some 
> slides together 
> > a while ago on this identities issue.
> >
> > Vidya
> >
> >> Regards,
> >> Yoshihiro Ohba
> >>
> >>
> currently

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 05 Apr 2007 09:32:43 -0400

Hi Vidya,

> layer to advertise identities. 

I don't understand what "many cases" are.  What is "a certain level of
service"?  What do you mean by "is charged for the same"?  I've read
your slides you indicated below (thanks for the pointer!), but
unfortunately, the slides do not contain detaied explanation on those
points.

> shared and freshness is always ensured. 

At least I can see a DoS attack without peer consent.  An attacker can
generate a non-secured trigger that invokes key distribution procedure
that causes installation of a lot of keys to authenticators.

> while ago on this identities issue. 

I have specific comments on your slides:

Slide 6:

"- As long as the peer is satisfied, the identity of the network entity
providing the service is irrelevant"

How do you define peer's "satisfaction" from security point of view?

"- If peer is not satisfied or there is a billing issue, it contacts its home
network and tries to get service from some other node instead"

This does not seem to help, since some other node may also be
impersonating.

Slide 7:

"This cannot be detected using any type of channel binding"

This is not true.  If an appropriate 3-party key distribution protocol
is used, this can be detected.

"No security properties are lost"

Isn't channel binding a security property?

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 05 Apr 2007 10:16:17 -0400

My answer is "yes".  I believe that peer consent is an important
requirement to prevent DoS attack on proactive key distribution.
Otherwise, an attacker can generate non-secured triggers by simply
spoofing the identities of authenticated peers, which can cause the
server to flood a number of keys to a number of authenticators.

BTW, I don't understand why channel bindings where identities are
hashed into the key derivation would be sufficient if the answer is
"no".

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 05 Apr 2007 10:29:53 -0400

Hi Charles,

> doesn't require A to know "B" at the beginning.

If step 3) and step 4) need to happen immediately after step 2), I
think peer consent requirement is satisfied in your proposal.  On the
other hand, this does not exempt NAS-ID from being advertised by lower
layer.

Yoshihiro Ohba

---

From: "Charles Clancy" <[email-masked]>
Date: Thu, 5 Apr 2007 11:12:57 -0400 (EDT)

> think peer consent requirement is satisfied in your proposal.

The peer has consented that a key should be derived, but did not securely
specify "B" as the recipient of that key.  In message #4, the peer is
informed the recipient was "B".

> On the

Correct.  However, if the peer doesn't care about the identity of the
network, then he can always accept the key without comparing "B" to
something advertised at L2.

I imagine that in many cases, the identity of "B" is important -- for
example in a WiFi network, where "B" could equal the SSID.  However in a
cellular network, you many not care whose network you're connecting to, so
long as they have the proper roaming relationship with your provider.  In
that case, perhaps checking "B" is less important.

I think this approach is the most flexible.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Apr 2007 10:02:59 -0700 (PDT)

Vidya,

  All you're addressing is "preventing the domino effect". That is not
scoping the key or binding context to a key.

  There is context for the key. For instance, "this is for a particular
authenticator." To quote from draft-housley-aaa-key-mgmt-09.txt:

         The context will include the peer and NAS identities in more
         than one form.  One (or more) name form is needed to identify
         these parties in the authentication exchange and the AAA
         protocol.

In addition if HOKEY is going to have some key hierarchy in which keys
are specific for a particular usage or a particular domain then that
is additional context that has to be bound to the key. You're just
throwing a counter or a nonce into the mix and thinking that solves
all problems. It doesn't.

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 5 Apr 2007 10:22:09 -0700

Dan,
Context (usage) is additional information that needs to be bound to the
key - we have no disagreement there. But, channel binding is of no help
for that either. As to scope, the keys must be scoped to a domain and
that has also been agreed upon. 

Vidya 

> Sent: Thursday, April 05, 2007 10:03 AM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Yoshihiro Ohba; [email-masked]
>   All you're addressing is "preventing the domino effect". 
> That is not scoping the key or binding context to a key.
> 
>   There is context for the key. For instance, "this is for a 
> particular authenticator." To quote from 
> draft-housley-aaa-key-mgmt-09.txt:
> 
> In addition if HOKEY is going to have some key hierarchy in 
> which keys are specific for a particular usage or a 
> particular domain then that is additional context that has to 
> be bound to the key. You're just throwing a counter or a 
> nonce into the mix and thinking that solves all problems. It doesn't.
> 
>   Dan.
> 
> >> deck) doesn't work because these are symmetric keys and 
> the "middle 
> >> entity" can impersonate the client now. Every single property that 
> >> you want to give to the key being distributed is lost.
> >>
> that has 
> >> more to do with what you want to do then with whether it's 
> secure or 
> >> not.
> >>
> >> if you do not bind the scoping information to the exchange that 
> >> distributes the key? How can the peer have any assurance 
> that the key 
> >> is "not shared"
> >>   Why not just send the EMSK to every entity that the AS thinks it 
> >> has a security association with? I mean, in many cases as 
> long as the 
> >> peer receives a certain level of service and is charged 
> for same then 
> >> the identity of the entity receiving the EMSK is irrelevant and 
> >> channel binding isn't important and as long as we scope the key 
> >> properly (everyone with whom the AS shares a security 
> association-- 
> >> aka "the
> >> network") then it's OK. After all, nothing matters as long as the 
> >> peer is satisfied and "if the peer is not satisfied or there is a 
> >> billing issue, it contacts its home network and tries to 
> get service 
> >> from some other node instead" (to quote from slide #6).
> >>
> >>   Dan.
> >>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Apr 2007 11:19:43 -0700 (PDT)

Vidya,

  No, it is far from being "no help". Channel binding is the way to bind
all necessary context to the key.

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 5 Apr 2007 16:23:29 -0700

Dan,
I think we simply have been using different definitions of channel
binding. I've been using the definitions present in RFC3748 and the EAP
keying document, which don't quite include binding of context and such.
I do, however, agree, that the definition of channel binding is rather
loose and we don't have one unified view on that. 

Having said that, let me try another way of making progress here: 

* Keys should be bound to the correct context/usage
* Keys should be scoped to the entities that need to use it
* Keys should be fresh 
* Domino effect must be prevented 

I'm on board with all of the above. Are we on the same page? 

Vidya

> Sent: Thursday, April 05, 2007 11:20 AM
> To: Narayanan, Vidya
>   No, it is far from being "no help". Channel binding is the 
> way to bind all necessary context to the key.
> 
>   Dan.
> 
> > Context (usage) is additional information that needs to be bound to 
> > the key - we have no disagreement there. But, channel 
> binding is of no 
> > help for that either. As to scope, the keys must be scoped 
> to a domain 
> > and that has also been agreed upon.
> >
> > Vidya
> >
> >> In addition if HOKEY is going to have some key hierarchy in which 
> >> keys are specific for a particular usage or a particular 
> domain then 
> >> that is additional context that has to be bound to the key. You're 
> >> just throwing a counter or a nonce into the mix and thinking that 
> >> solves all problems. It doesn't.
> >>
> >>   Dan.
> >>
> >> >> >> > > Subject: [HOKEY] consensus call: key 
> distribution security 
> >> >> >> > > requirement
> >> >> >> > >
> >> >> >> > > HOKEY WG,
> >> >> >> > >

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 6 Apr 2007 09:46:25 -0700 (PDT)

Hi Vidya,

  When EAP is used in "pass-thru" mode there is a problem. As you note
that problem, and a solution to it, is described in RFC3748 under the
heading of "Channel Binding". We have that same sort of problem in
spades here in HOKEY because we're distributing keys that must be for
a specific authenticator, for a specific usage, and I guess for a specific
domain. There is context that constrains who can use a key and how that
key can be used. So we need to solve that same sort of problem that EAP
has when used in "pass-thru" mode.

  Perhaps "Channel Binding" isn't a good term to use since it implies
something specific (RFC3748). How about "protected exchange"? That is
how RFC3748 describes "Channel Binding" anyway. So would something along
the lines of this be agreeable?

   HOKEY MUST include a protected exchange of context, usage, and
   identities that are bound to, and constrain, a key including but
   not limited to [enumerate the things needed]. This will make it
   possible to match the same properties provided by the authenticator
   via an out-of-band mechanism (like AAA) against those in the protected
   exchange in the HOKEY protocol.

To plagiarize^H^H^H^H^H^H paraphrase RFC3748.

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 9 Apr 2007 18:00:00 -0700

Hi Dan, 
Some notes inline. 

> Sent: Friday, April 06, 2007 9:46 AM
> To: Narayanan, Vidya
>   When EAP is used in "pass-thru" mode there is a problem. As 
> you note that problem, and a solution to it, is described in 
> RFC3748 under the heading of "Channel Binding". We have that 
> same sort of problem in spades here in HOKEY because we're 
> distributing keys that must be for a specific authenticator, 
> for a specific usage, and I guess for a specific domain. 
> There is context that constrains who can use a key and how 
> that key can be used. So we need to solve that same sort of 
> problem that EAP has when used in "pass-thru" mode.
> 
>   Perhaps "Channel Binding" isn't a good term to use since it 
> implies something specific (RFC3748). How about "protected 
> exchange"? That is how RFC3748 describes "Channel Binding" 
> anyway. So would something along the lines of this be agreeable?
> 

What is the difference between context and usage? 

>    identities 

On identities, I believe the exchange may be needed in some cases and
not in other cases. So, having an optional exchange of identities would
be sufficient in my view. 

Vidya

> that are bound to, and constrain, a key including but
> > binding. I've been using the definitions present in RFC3748 and the 
> > EAP keying document, which don't quite include binding of 
> context and such.
> >>   No, it is far from being "no help". Channel binding is 
> the way to 
> >> bind all necessary context to the key.
> >>
> >>   Dan.
> >>
> >> >> >> Subject: RE: [HOKEY] consensus call: key 
> distribution security 
> >> >> >> requirement
> >> >> >>
> >> >> >>
> >> >> >>   Hi Vidya,
> >> >> >>
> >> >> >> >> > 3-party protocol and about how practically 
> deployable that
> >> >> >> >> is. In my
> >> >> >> >> > conversations with Dan in Prague, it seemed 
> like we were 
> >> >> >> >> > on
> >> >> >> >> the same
> >> >> >> >> > between the peer and server. I think such 
> channel binding
> >> >> >> >> information

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 9 Apr 2007 18:15:32 -0700

Hi Yoshi,

<snip>

> 
> I don't understand what "many cases" are.  What is "a certain 
> level of service"?  What do you mean by "is charged for the 
> same"?  I've read your slides you indicated below (thanks for 
> the pointer!), but unfortunately, the slides do not contain 
> detaied explanation on those points.
> 

As an example, if I was guaranteed 1Mbps and that's what I get and
that's what I pay for, the identity of the entity that gave me 1Mbps may
be irrelevant to me. 

<snip>

> "- As long as the peer is satisfied, the identity of the 
> network entity providing the service is irrelevant"
> 

Again, this is what I've explained above. I may be looking for no
security guarantees from the network - i.e., I either don't care about
data security and exchange data in the clear through that network or do
care about it and use some end-to-end security for my data. 

> "- If peer is not satisfied or there is a billing issue, it 
> contacts its home network and tries to get service from some 
> other node instead"
> 

It doesn't matter if some entity is impersonating as long as I'm getting
what I want and I'm paying for what I get, in this case. All I'm saying
is that this is a very common case in wireles networks. I can see cases
of enterprise connectivity, where the identity of the node I'm attaching
to is of importance to me. 

> This is not true.  If an appropriate 3-party key distribution 
> protocol is used, this can be detected.
> 

I don't understand how 3-party key distribution is just channel binding.

> Isn't channel binding a security property?

For anything we call as a "security property", we should be able to
clearly state what is lost when that property is not met. In reality,
for some cases, nothing is lost without channel bindings is the point I
am trying to get at. I don't argue that CB might be important for some
cases - I'm just showing why it is sufficient for CB to be optional. 

Regards,
Vidya

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 09 Apr 2007 21:54:48 -0400

> that's what I pay for, the identity of the entity that gave me 1Mbps may

But this has nothing to do with security properties we are talking about.

> care about it and use some end-to-end security for my data. 

This sounds like sidetracking...

If what you are saying can justify making channel binding optional
feature for the above reason, why can't we just make link-layer
ciphering optional and recommend use of end-to-end security instead?

> to is of importance to me. 

Please see my comment above.

> I don't understand how 3-party key distribution is just channel binding.

3-party key distribution is more than just channel binding, and it
provides channel binding by satisfying certain requirements we listed
in 3party-keydist-ps draft.

> cases - I'm just showing why it is sufficient for CB to be optional. 

Without channel binding, a peer may connect to a network which is
different from the intended one, through an impersonating
authenticator.  As a result, the peer may happen to disclose
information that is supposed to be sent to the intended network only,
to the impersonating authenticator, and the impersonating
authenticator can obtain that information.  This is a threat if
channel binding is not provided.

Regards,
Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 9 Apr 2007 19:08:47 -0700

> Sent: Monday, April 09, 2007 6:55 PM
> To: Narayanan, Vidya
> Cc: Yoshihiro Ohba; Charles Clancy; [email-masked]
> > > I don't understand what "many cases" are.  What is "a 
> certain level 
> > > of service"?  What do you mean by "is charged for the 
> same"?  I've 
> > > read your slides you indicated below (thanks for the 
> pointer!), but 
> > > unfortunately, the slides do not contain detaied explanation on 
> > > those points.
> > > 
> > 
> > that's what I pay for, the identity of the entity that gave 
> me 1Mbps 
> > may be irrelevant to me.
> 

Why not?  

> > > "- As long as the peer is satisfied, the identity of the network 
> > > entity providing the service is irrelevant"
> > > 
> > data security and exchange data in the clear through that 
> network or 
> > do care about it and use some end-to-end security for my data.
> 
> If what you are saying can justify making channel binding 
> optional feature for the above reason, why can't we just make 
> link-layer ciphering optional and recommend use of end-to-end 
> security instead?
> 

We don't make link-layer ciphering mandatory here at the IETF. If a
network wants to do access control, it does that. EAP may provide the
keys necessary to do that. And, just integrity protection is sufficient
for access control. 

<snip>

> 
> Without channel binding, a peer may connect to a network 
> which is different from the intended one, through an 
> impersonating authenticator.  As a result, the peer may 
> happen to disclose information that is supposed to be sent to 
> the intended network only, to the impersonating 
> authenticator, and the impersonating authenticator can obtain 
> that information.  This is a threat if channel binding is not 
> provided.
> 

This seems to be the point of disconnect. This is true when I treat my
data that way selectively - may be true when I want to exchange data in
the clear over an enterprise intranet, because I know I'm attached to an
enterprise intranet. Channel binding may be relevant there and can also
be done more effectively. When I'm attaching to an access point in
Starbucks, I don't care what its identity is; my data is either not
sensitive and I send it or I use end-to-end security for it. And, in
such cases, channel binding is of no use. 

Vidya

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Apr 2007 00:31:46 -0400

> > But this has nothing to do with security properties we are 

Because any security property I know of does not depend on how much
bandwidth is guaranteed.

> keys necessary to do that. And, just integrity protection is sufficient

If you are talking about the case in which EAP does not provide keys
(e.g., wired Ethernet access with 802.1X), that is fine.  But as long
as keys are provided for link layer ciphering, I believe channel
binding is an important security property (and also see my comment below).

> such cases, channel binding is of no use. 

Since Starbucks does not use EAP or link-layer ciphering, and I don't
see your point.

Finally, how your argument on making channel binding optional can fit
draft-housley-aaa-key-mgmt?

Yoshihiro Ohba

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 10 Apr 2007 08:28:52 -0700 (PDT)

On Mon, April 9, 2007 6:00 pm, Narayanan, Vidya wrote:
[snip]
> What is the difference between context and usage?

  It's all the cruft you want to bind to the keys that aren't the usage.
Is there some specific VLAN this person is assigned to? Maybe there's a
lifetime associated with this key? I don't know.

  I honestly don't understand the "usage" thing (HOKEY doesn't need to be
a swiss army knife of access protocols) but it's in there so I included
it.

> be sufficient in my view.

  It sounds like you have a particular deployment in mind and it's hard
for that particular deployment to solve this problem so you are saying
that it shoudn't have to. That seems like a bassackwards way to come up
with a protocol.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 10 Apr 2007 08:30:14 -0700 (PDT)

Vidya,

> that's what I pay for, the identity of the entity that gave me 1Mbps may

  This sounds like the "evil twins R us" network.

  Dan.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 10 Apr 2007 15:47:24 -0700

Hi Charles, 

I am still catching up on my emails. By eliminating B you are introducing
the vulnerability to the lying NAS problem. So I personally never saw adding
B as a peer consent thing, but rather as part of channel binding. This was
part of the channel binding solution I presented in SJ even.

 I don't really see a big problem with peer knowing the authenticator ID, it
can either go as part of the EAP request message or as part of L2 beacon
carrying higher layer network data. 802.21 MIH information server is
supposed to carry all kinds of network data to the mobiles...

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 6:27 PM
To: [email-masked]
Subject: Re: [HOKEY] consensus call: key distribution security requirement

All,

    1) A->B: A, {A, Na}Kas

    1) A->B: A, {A, Na}Kas

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 10 Apr 2007 15:53:31 -0700

When B is the identity of the authenticator used in derivation of
per-authenticator master keys (I called it MDMSK for mobility domain MSK)
from HRK, then both peer and HOKEY server need to use the same B in the
derivation, otherwise everything will fall apart. Now whether B is SSID or
something else, it must be recognizable by the HOKEY server.

Madjid

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 10 Apr 2007 16:01:41 -0700

Madjid>>because, I thought we are worried about the threat of domino effect
for wireless link security (which is between a peer and a specific point of
attachment).

Frankly, I am surprised by the poorness of the example that is given...

Why not?

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 11 Apr 2007 12:59:30 -0700

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,

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 11 Apr 2007 13:59:32 -0700

Here is my homework on PS relating to the 3 requirements I mentioned
earlier.

Section 6.1

Current text: 
"Any key MUST have a well-defined scope and MUST be used in a specific
   context and for the intended use.  This specifically means the
   lifetime and scope of each key MUST be defined clearly so that all
   entities that are authorized to have access to the key have the same
   context during the validity period. "

new text for scope:

"Any key MUST have a well-defined and properly authorized scope. The scope
of a key can be extended to include 3rd parties that receive the key through
distribution (rather than generation). Distribution of the key to such 3rd
parties MUST happen through secure transport, to avoid disclosure of the
keying material to passive and active attackers. When proving the possession
of the distributed keys, such 3rd parties MUST be able to provide proof on
the authorization to use the key and entity making such authorization.
Alternatively, the scope of the key MAY be communicated by the authorizing
party to all parties explicitly. Communication of scope MUST be in a secure
manner. Each party included in the scope definition MUST be known to all
other parties in an unequivocal manner."

Madjid>>The text above, means the scope does not have to be provided from
server to the peer directly, so we are not requiring direct signaling of the
scope, but through a peer-authenticator exchange later on.
Also it says, the party that distributes the key, also authorizes its use.
It is stronger than just transporting the key to authenticator from the
server, but it is weaker than requiring peer consent.
The last sentence covers the channel binding problem.

New text for context:

"Any key MUST have well defined context. The context information MUST be
communicated securely to parties receiving the key through distribution and
MUST be well understood and Must be agreed upon by all parties covered by
key scope definition. This for instance means, all entities that are
authorized to have access to the key have the notion of the key usage and
validity period."

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,

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Apr 2007 16:52:48 -0400

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:
>I suggest we adopt this for HOKEY and EMSK hierarchy dFrom [email-masked] Wed Apr 11 23:05:34 2007
Date: Wed, 11 Apr 2007 16:52:48 -0400
To: Madjid Nakhjiri <[email-masked]>,
	'Charles Clancy' <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: [HOKEY] key scope versus Context. consensus call: key
	distribution security requirement
Cc: 'Bernard Aboba' <[email-masked]>, [email-masked]

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

---

From: Charles Clancy <[email-masked]>
Date: Thu, 12 Apr 2007 22:14:46 -0400

MAdjid,

I'm only eliminating B in the initial messages 1/2.  The Lying NAS 
problem is prevented by B being included in messages 3/4.  When the peer 
receives message 4, if the value of "B" differs from the advertised 
value the peer can disconnect.  The side effect is we don't have peer 
authorization, so keying material ends up being sent to "B".  But, 
assuming we have all those freshness guarantees, that keying material is 
useless.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 16 Apr 2007 12:57:19 -0700

Ok, I understand, However, if you could load the peer's message (which I am
guessing is the reason, you eliminated it), then you could avoid the server
creating key material for a lying NAS before the peer detecting this. So as
you said the server ends up spending CPU and bandwidth doing all this for
nothing.

Plus, right now, it is really up the peer to detect the issue and the peer
may really not have a way to notify the server, since there is no message
after 4 (EAP Success).

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 7:15 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [HOKEY] consensus call: key distribution security requirement

MAdjid,