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

[Yoshihiro Ohba <[e-mail]>]

On Mon, Apr 09, 2007 at 07:08:47PM -0700, Narayanan, Vidya wrote:
>  
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[e-mail]] 
> > Sent: Monday, April 09, 2007 6:55 PM
> > To: Narayanan, Vidya
> > Cc: Yoshihiro Ohba; Charles Clancy; [e-mail]
> > Subject: Re: [HOKEY] consensus call: key distribution 
> > security requirement
> > 
> > On Mon, Apr 09, 2007 at 06:15:32PM -0700, Narayanan, Vidya wrote:
> > > Hi Yoshi,
> > > 
> > > <snip>
> > > 
> > > > 
> > > > I don't understand what "many cases" are.  What is "a 
> > certain level 
> > > > of service"?  What do you mean by "is charged for the 
> > same"?  I've 
> > > > read your slides you indicated below (thanks for the 
> > pointer!), but 
> > > > unfortunately, the slides do not contain detaied explanation on 
> > > > those points.
> > > > 
> > > 
> > > As an example, if I was guaranteed 1Mbps and that's what I get and 
> > > that's what I pay for, the identity of the entity that gave 
> > me 1Mbps 
> > > may be irrelevant to me.
> > 
> > But this has nothing to do with security properties we are 
> > talking about.
> 
> Why not?  

Because any security property I know of does not depend on how much
bandwidth is guaranteed.

> 
> > > 
> > > <snip>
> > > 
> > > > 
> > > > I have specific comments on your slides:
> > > > 
> > > > Slide 6:
> > > > 
> > > > "- As long as the peer is satisfied, the identity of the network 
> > > > entity providing the service is irrelevant"
> > > > 
> > > > How do you define peer's "satisfaction" from security 
> > point of view?
> > > > 
> > > 
> > > Again, this is what I've explained above. I may be looking for no 
> > > security guarantees from the network - i.e., I either don't 
> > care about 
> > > data security and exchange data in the clear through that 
> > network or 
> > > do care about it and use some end-to-end security for my data.
> > 
> > This sounds like sidetracking...
> > 
> > If what you are saying can justify making channel binding 
> > optional feature for the above reason, why can't we just make 
> > link-layer ciphering optional and recommend use of end-to-end 
> > security instead?
> > 
> 
> We don't make link-layer ciphering mandatory here at the IETF. If a
> network wants to do access control, it does that. EAP may provide the
> keys necessary to do that. And, just integrity protection is sufficient
> for access control. 

If you are talking about the case in which EAP does not provide keys
(e.g., wired Ethernet access with 802.1X), that is fine.  But as long
as keys are provided for link layer ciphering, I believe channel
binding is an important security property (and also see my comment below).

> 
> <snip>
> 
> > 
> > Without channel binding, a peer may connect to a network 
> > which is different from the intended one, through an 
> > impersonating authenticator.  As a result, the peer may 
> > happen to disclose information that is supposed to be sent to 
> > the intended network only, to the impersonating 
> > authenticator, and the impersonating authenticator can obtain 
> > that information.  This is a threat if channel binding is not 
> > provided.
> > 
> 
> This seems to be the point of disconnect. This is true when I treat my
> data that way selectively - may be true when I want to exchange data in
> the clear over an enterprise intranet, because I know I'm attached to an
> enterprise intranet. Channel binding may be relevant there and can also
> be done more effectively. When I'm attaching to an access point in
> Starbucks, I don't care what its identity is; my data is either not
> sensitive and I send it or I use end-to-end security for it. And, in
> such cases, channel binding is of no use. 

Since Starbucks does not use EAP or link-layer ciphering, and I don't
see your point.

Finally, how your argument on making channel binding optional can fit
draft-housley-aaa-key-mgmt?

Yoshihiro Ohba



> 
> Vidya
> 
> > Regards,
> > Yoshihiro Ohba
> > 
> > 
> > > 
> > > Regards,
> > > Vidya
> > > 
> > > > Regards,
> > > > Yoshihiro Ohba
> > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 

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