RE: [HOKEY] consensus call: key distribution security requirement

["Dan Harkins" <[e-mail]>]

  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.

On Thu, April 5, 2007 4:23 pm, Narayanan, Vidya wrote:
> 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
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:[e-mail]]
>> Sent: Thursday, April 05, 2007 11:20 AM
>> To: Narayanan, Vidya
>> Cc: Dan Harkins; Yoshihiro Ohba; [e-mail]
>> Subject: RE: [HOKEY] consensus call: key distribution
>> security requirement
>>
>>
>>   Vidya,
>>
>>   No, it is far from being "no help". Channel binding is the
>> way to bind all necessary context to the key.
>>
>>   Dan.
>>
>> On Thu, April 5, 2007 10:22 am, Narayanan, Vidya wrote:
>> > 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
>> >
>> >> -----Original Message-----
>> >> From: Dan Harkins [mailto:[e-mail]]
>> >> Sent: Thursday, April 05, 2007 10:03 AM
>> >> To: Narayanan, Vidya
>> >> Cc: Dan Harkins; Yoshihiro Ohba; [e-mail]
>> >> Subject: RE: [HOKEY] consensus call: key distribution security
>> >> requirement
>> >>
>> >>
>> >>   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.
>> >>
>> >> On Wed, April 4, 2007 6:20 pm, Narayanan, Vidya wrote:
>> >> > 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
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Dan Harkins [mailto:[e-mail]]
>> >> >> Sent: Wednesday, April 04, 2007 4:24 PM
>> >> >> To: Narayanan, Vidya
>> >> >> Cc: Yoshihiro Ohba; [e-mail]
>> >> >> Subject: RE: [HOKEY] consensus call: key distribution security
>> >> >> requirement
>> >> >>
>> >> >>
>> >> >>   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.
>> >> >>
>> >> >> On Wed, April 4, 2007 11:16 am, Narayanan, Vidya wrote:
>> >> >> > Hi Yoshi,
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: Yoshihiro Ohba [mailto:[e-mail]]
>> >> >> >> Sent: Tuesday, April 03, 2007 7:45 PM
>> >> >> >> To: Narayanan, Vidya
>> >> >> >> Cc: Charles Clancy; [e-mail]
>> >> >> >> 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
>> >> >> >
>> >> >> >> Regards,
>> >> >> >> Yoshihiro Ohba
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tue, Apr 03, 2007 at 06:25:52PM -0700, Narayanan,
>> >> Vidya wrote:
>> >> >> >> > 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:[e-mail]]
>> >> >> >> > > Sent: Saturday, March 31, 2007 12:16 PM
>> >> >> >> > > To: [e-mail]
>> >> >> >> > > 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.
>> >> >> >> > >
>> >> >> >> > > 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.
>> >> >> >> > >
>> >> >> >> > > --
>> >> >> >> > > 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
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > HOKEY mailing list
>> >> >> > [e-mail]
>> >> >> > https://www1.ietf.org/mailman/listinfo/hokey
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>



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