eap Mailing List: RE: channel binding

[Salowey, Joe (jsalowey]

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

[Joe] I'm not sure what you mean, with type 1 bindings the same data is
input on both sides and the mechanism verifies this on both sides.  The
two communicating parties are the EAP-Server and EAP-Peer.  A trust
relationship between the EAP-Authenticator and EAP-Server is a separate
issue, independent of whether you use a blob or actual data. 

> This blob 
> validation issue is discussed in section 5 of 
> draft-ohba-eap-aaakey-binding-01.
> 
[Joe] OK, I'll take a look.

> 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.
> 
[Joe] If you were going to carry just a blob then you would probably
carry a hash instead of a MAC, the MAC above is keyed with key material
within the EAP method.  I'm not sure that carry a hash of parameters in
RADIUS  is sufficient or necessary.  It is probably not sufficient
because you may need to validate the contents of the bindings asserted
by the authenticator in the AAA hosting the EAP server to avoid the
problem you discuss above. It may not be necessary since you need to
have information associated with the authenticator on the AAA that is
hosting the EAP server to validate the asserted binding by the
authenticator.   If the information is not variable then you don't have
to transmit it.  If it is then you probably have to transmit it so it
can be verified.