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

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

Hi Dan, 
Some notes inline. 

> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]] 
> Sent: Friday, April 06, 2007 9:46 AM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Yoshihiro Ohba; [e-mail]
> Subject: RE: [HOKEY] consensus call: key distribution 
> security requirement
> 
> 
>   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

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
>    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