eap Mailing List: Re: channel binding

[Yoshihiro Ohba (yohba]

On Wed, Aug 31, 2005 at 10:06:34AM -0700, Salowey, Joe wrote:
>  
> 
> > -----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.  

I don't think we can rely on simple MAC comparison on both sides in
type 1 if the authenticator is not fully trusted by the server.  In
this case, the server would need to validate the MAC sent by the
authenticator by comparing with the MAC computed from the *expetected*
blob value.  This blob validation issue is discussed in section 5 of
draft-ohba-eap-aaakey-binding-01.

But I like the idea of carrying a MAC of blob instead of a blob
itself, as we can avoid RADIUS attribute fragmentation that needs to
be considered if a blob itself is carried.

Yoshihiro Ohba

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