Subject: [eap] Re: Issue 325: Channel Bindings

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 22 Jan 2006 21:25:51 -0800

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: [email-masked]
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

---

From: Yoshihiro Ohba <[email-masked]>
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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 23 Jan 2006 17:53:57 -0800

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

>From: Yoshihiro Ohba <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked]
>Subject: Re: [eap] Re: Issue 325: Channel Bindings
>Date: Mon, 23 Jan 2006 19:27:51 -0500
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 23 Jan 2006 21:26:49 -0500

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.
> 
> 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 <[email-masked]>
Date: Wed, 25 Jan 2006 17:48:48 -0500

The new channel binding draft I mentioned was submitted.

Until it appears in the IETF I-D repository, a copy is available at:
http://www.opendiameter.org/draft-ohba-eap-channel-binding-00.txt

Yoshihiro Ohba