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

["Narayanan, Vidya" <[e-mail]>]

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