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

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

  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