eap Mailing List: Re: Re: Issue 325: Channel Bindings

[Yoshihiro Ohba (yohba]

I had a discussion with Mohan and we have a doubt about usefulness of
exportable channel binding.  It appears that relying solely on the
binary comparison does not prevent a rogue NAS from advertising the
same incorrect parameters for both peer and authentication server.
In fact it is stated in draft-arkko-eap-service-identity-auth-04.txt:

"
   It is important to make a distinction between channel bindings and
   authenticating information related to the the pass-through
   authenticator.  Channel bindings only ensure that the same
   information is available to the EAP peer and the AAA server.  This
   alone does not prevent an authenticator from impersonating another
   authenticator if the AAA server blindly accepts any information
   received from the authenticator.  To provide authentication, the AAA
   server has to verify that the information actually corresponds to the
   entity the AAA-Key is sent to.
"

On the other hand, the current Channel Binding definition in section
1.3 of eap-keying states:

"
   Channel Bindings include lower layer parameters that are verified for
   consistency between the EAP peer and server.
"

This definition also seems to imply that the aspects of authenticating
information related to the pass-through authenticator is not included
in the "verification" process.  

But I think that the definition of Channel Binding should be revised
to include the functionality of authenticating information related to
the pass-through authenticator so that it can even prevent a rogue NAS
from advertising the same incorrect parameters for both peer and
authentication server, otherwise, Channel Binding is just incomplete.
Along this line, it appears that the only way to prevent this is
pre-configuring lower-layer parameters on a server.  If so, exchanging
lower-layer parameters in EAP methods does not make sense.  On the
other hand, draft-ohba-eap-aaakey-binding is incomplete as well
because the solution still relies on the EAP authenticator to send a
blob to the server.

This seems to be a fundamental issue and we are currently working on a
new channel binding I-D to address the above point I made (to be
submitted in a few days.)

Regards,
Yoshihiro Ohba



On Sun, Jan 22, 2006 at 09:25:51PM -0800, Bernard Aboba wrote:
> It sounds like we have agreed to further develop the text on channel 
> bindings.  Can someone supply text?
> 
> --------------------------------------------------------------------------------------------
> Issue 325: Channel Bindings
> Submitter name: Joe Salowey
> Submitter email address: jsalowey [at] cisco.com
> Date Submitted: December 1, 2005
> Reference:
> Document: Keying-08
> Comment type: T
> Priority: 1
> Section: 1.3, 1.4
> Rationale/Explanation of issue:
> Section 1.3
> 
> There are two styles of channel bindings that may be supported by EAP
> methods. The text in this section describes exportable channel bindings.
> There is also the approach where the bindings are non exportable.  In
> this case the method does a binary comparison of the channel bindings or
> hash of the channel bindings and fails if the result does not match.  I
> can see the possibility of a method supporting both styles.  Should we
> include both?
> 
> Section 1.4
> 
> Exportable channel binding are references in this section,
> non-exportable ones are not.  If we make changes to this affect above
> then we should change it here as well.
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>