Subject: RE: [eap] channel binding

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 30 Aug 2005 14:54:27 -0700

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Monday, August 29, 2005 11:06 AM
> To: Charles Clancy
> Cc: [email-masked]
> Subject: Re: [eap] channel binding
> 
> On Mon, Aug 29, 2005 at 12:57:38PM -0400, Charles Clancy wrote:
> > Channel binding transmits channel parameters between the EAP client 
> > and EAP server in some protected way.  When done by 
> methods, it seems 
> > the general approach is to encrypt it (PSK, TTLS, etc), 
> guaranteeing 
> > authenticity.  Is there any reason why it a MAC over the 
> blob would be 
> > insufficient?  Is confidentiality required for some reason?
> 
> This is an interesting issue.  
> 
> I am not sure whether confidentiality is required for channel 
> parameters or not for existing lower layers.  But a solution 
> that does not necessarily require exposing channel parameters 
> when exchanged between peer and authenticator is certainly 
> preferable, as I don't think we can determine at this moment 
> whether all lower layers (including existing and future ones) 
> do not require confidentiality.
> 
> 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. 

> Yoshihiro Ohba
> 
> > 
> > I'm working on defining a protected channel in EAP-PAX for 
> > communicating channel binding info, and I'd like to avoid 
> defining a 
> > symmetric-key encryption ciphersuite, as PAX is based on MACs.
> > 
> > [ t. charles clancy ]--[ [email-masked] ]--[ 
> www.cs.umd.edu/~clancy ] [ 
> > computer science ]-----[ university of maryland | college park ]
> > 
> > _______________________________________________
> > eap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Charles Clancy <[email-masked]>
Date: Wed, 31 Aug 2005 10:25:17 -0400 (EDT)

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

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.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Aug 2005 17:45:51 +0300

Charles Clancy 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 
> 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...

Yes, I think this is the distinction between Joe's class 1 and 2.
Class 2 appears easier to deploy and debug, while class 1 may
have some security advantages (like avoiding disclosure of private
information) and is simpler.

> parameters.  From a cryptographic standpoint, a random oracle/PRF 
> isn't needed here, so HMAC or CBC-MAC should be sufficient.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Aug 2005 21:23:21 -0400

> 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