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

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

  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