Re: channel binding
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Wed, 31 Aug 2005 22:46:57 -0400 (EDT)
On Wed, Aug 31, 2005 at 10:25:17AM -0400, Charles Clancy wrote:
> 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...
> 
> 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.

I have a doubt about applicability of keyed MAC for a blob in
three-party key management system.  If the keyed MAC is generated by
peer and authenticator, and the authenticator sends the MAC to the
server (via a AAA protocol), which key is used for MAC computation? 
Note that AAA-Key is not used in this case because AAA-Key is not yet
available at the authenticator before the authenticator sends the MAC
to the server, for all possible solutions we have discussed.

Yoshihiro Ohba


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

Results generated by Tiger Technologies using MHonArc.