eap Mailing List: RE: channel binding

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Charles Clancy [mailto:clancy [at] cs.umd.edu] 
> Sent: Wednesday, August 31, 2005 7:25 AM
> To: Salowey, Joe
> Cc: Yoshihiro Ohba; eap [at] frascone.com
> Subject: RE: [eap] channel binding
> 
> On Tue, 30 Aug 2005, Salowey, Joe wrote:
> 
> >> Regarding carrying a MAC of a blob instead of a blob 
> itself, I think 
> >> we need more analysis.  If a blob is mixture of confidential and 
> >> non-confidential parameters, can't the non-confidential parameters 
> >> and the MAC becomes a hint to find out the confidential ones?
> >
> > [Joe] Maybe, I don't think that a MAC necessarily has the 
> properties 
> > of a pseudo-random function so some information may leak 
> into the MAC 
> > value.  I'm not sure how close to a PRF something like HMAC is.
> 
> Originally, I meant that you would send both the channel 
> binding blob, and also a keyed MAC of the blob.  Would 
> sending *just* the MAC also work?  I guess both sides would 
> have to know the channel parameters in order to verify them...
> 

[Joe] Depends on how you want the channel bindings to be verified.  With
type 1 channel bindings the mechanism can make sure the channel bindings
match without having to know anything about the data or the lower layer.
In this case I think it would be simplest to say the both sides just
have to input the same blob on both sides.  In this case just sending
the MAC would be sufficient.  With type 2 bindings you must send the
actual data because it is verified outside the mechanism.  

We could come up with more complex semantics for type 1 bindings where
multiple blobs are processed by the mechanism according to some rules
that take care of differences in the order of parameters.  Here I think
you can get away with just sending multiple MACs with one for each blob.
I think we should avoid this complexity if possible. 

> The fact that the MAC is keyed prevents determination of 
> confidential parameters.  From a cryptographic standpoint, a 
> random oracle/PRF isn't needed here, so HMAC or CBC-MAC 
> should be sufficient.
> 

[Joe] Thanks. 


> [ t. charles clancy ]--[ tcc [at] umd.edu ]--[ 
> www.cs.umd.edu/~clancy ] [ computer science ]-----[ 
> university of maryland | college park ]
>