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

[Yoshihiro Ohba (yohba]

On Mon, Jan 23, 2006 at 05:53:57PM -0800, Bernard Aboba wrote:
> Good point.  Channel bindings is not just about verifying that the peer 
> and server are told the same information by the authenticator.  It is 
> also about enabling the validation of the information itself.
> 
> In practice, the validation will often require pre-configuration on the 
> first-hop AAA server.  For example, a first-hop proxy may need to:
> 
> a. Validate the NAS-IP-Address/NAS-IPv6-Address/NAS-Identifier against 
> the source IP address in the AAA packet
> 
> b. Check the Called-Station-ID and other attributes against a 
> pre-configured entry for the NAS
> 
> c. Compare the Calling-Station-ID attribute against pre-configured 
> entries for that User-Name, etc.
> 
> All of this pre-configuration is expensive, and something of a 
> management headache.  As a result, it is not entirely clear to me that 
> operators will be motivated to implement it, at least until the problem 
> becomes big enough (e.g. fraud losses become substantial).

Sure.  This would lead to a requirement that the Channel Binding is an 
optional feature anyways.  This means that some negotiation must
occur between EAP peer and authentication server about the use of this
functionality.  This negotiation can be naturally provided by EAP
methods since they run between EAP peer and EAP server where the EAP
server is typically implemented on the authentication server.

I think that this negotiation capability should be a requirement for
an EAP method to claim Channel Binding support, rather than the one
currently described in section 7.2.1 of RFC 3748, which is incomplete.

(My personal opinion is that it is a bit early to close the EAP WG
before completely solving the Channel Binding problem which seems to
be also important for future work such as handover keying and
preauth...)

Regards,
Yoshihiro Ohba


> 
> 
> 
> 
> >From: Yoshihiro Ohba <yohba [at] tari.toshiba.com>
> >To: Bernard Aboba <bernard_aboba [at] hotmail.com>
> >CC: eap [at] frascone.com
> >Subject: Re: [eap] Re: Issue 325: Channel Bindings
> >Date: Mon, 23 Jan 2006 19:27:51 -0500
> >
> >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
> >>
> 
> 
>