Subject: [eap] Re: Issue 352: Channel Binding Issue

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 01 May 2006 18:48:34 -0700

The text of Issue 352 is shown below.

The suggested substitute text is ok as far as it goes.

As I read the referenced document, it requires changes to EAP methods, much 
the same as the transportation approach does.  The peer and server have to 
negotiate what channel bindings are mixed in with the keying material, 
effectively producing "mixed" MSKs/EMSKs.   Since the EAP method is really 
just outputing an MSK/EMSK as usual (albeit with channel bindings mixed in), 
no new AAA attributes or communication flow is required.

Did I read the document correctly?
-----------------------------------------------------------------------------------------------------------------
Issue 352: Channel Binding Issue
Submitter name: Yoshihiro Ohba
Submitter email address: [email-masked]
Date Submitted: April 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04216.html
Document: Keying-12
Comment type: T
Priority: 1
Section: 5.11
Rationale/Explanation of issue:

Reference [I-D.draft-ohba-eap-aaakey-binding] should be obsoleted by
its successor, i.e., [I-D.draft-ohba-eap-channel-binding] which
provides more generic, complete and extensible way of channel binding.
Note that pre-configuration of the parameter set on AS is an important
property to achieve Channel Binding in 3-party key management.

Change:

"  It is also possible to achieve Channel Bindings without transporting
   data over EAP.  For example, see [I-D.draft-ohba-eap-aaakey-binding].
   In this approach the authenticator informs the backend server about
   the Channel Binding parameters using AAA, and the backend server
   calculates transported keying material based on this parameter set,
   making it impossible for the peer and authenticator to complete the
   Secure Association Protocol if there was a mismatch in the
   parameters."

to:

"  It is also possible to achieve Channel Bindings without
   transporting data over EAP.  For example, see
   [I-D.draft-ohba-eap-channel-binding].  In this approach the backend
   server calculates transported keying material based on the
   parameter set pre-configured for the authenticator, making it
   impossible for the peer and authenticator to complete the Secure
   Association Protocol if there was a mismatch in the parameters."

_________________________________________________________________
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: Tue, 02 May 2006 12:56:49 -0400

On Mon, May 01, 2006 at 06:48:34PM -0700, Bernard Aboba wrote:
> just outputing an MSK/EMSK as usual (albeit with channel bindings mixed 
> in), no new AAA attributes or communication flow is required.
> 

Thank you for reading the document.  And the answer is, if the
generated "mixed" MSKs are carried in the existing AAA attributes
instead of carrying the MSKs, then no AAA attributes or communication
flow is required for EAP keying.

[Note, however, if the "mixed" MSKs/EMSKs are used outside the scope
of EAP keying (e.g., handover keying), then new AAA attributes or
communication flow may be needed.  This all depends on what
requirements on out-of-the-scope usages will be.]

Regards,
Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 02 May 2006 12:26:42 -0700

>flow is required for EAP keying.

It might be worth saying a few words about this in the paragraph.  Overall, 
I'm not sure whether the Channel Binding text in the document is all that 
consistent/comprehesive.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 May 2006 17:56:53 -0400

On Tue, May 02, 2006 at 12:26:42PM -0700, Bernard Aboba wrote:
> It might be worth saying a few words about this in the paragraph.  

I agree on adding a few words on this in the paragraph.

> Overall, 

I agree with your opinion here as well.  Let me quote some
questionable part in Section 5.11 of eap-keying-13 below:

"
As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].
"

I'd mention that Channel Binding description in RFC3748 is somewhat
obsolete according to the recent discussion on the AAA server's
requirement on pre-configurating Channel Binding parameters.  Do we
need this paragraph?  Or instead we may have some explicit text here
to obsolete Channel Binding description in RFC3748.

"
Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method.  For example, see the
discussion in Section 1.4 as well as [I-D.arkko-eap-service-identity-
auth].
"

According to the the AAA server's requirement on pre-configurating
Channel Binding parameters, I don't see the usefulness of
[I-D.arkko-eap-service-identity-auth].  Do we really need this
paragraph?

"
The main difference between these approaches is that Channel Binding
support within an EAP method may require upgrading or changing the
EAP method, impacting both the peer and the server.   Where Channel
Bindings are implemented in AAA,  the peer, authenticator and the
backend server need to be upgraded, but the EAP method need not be
modified.
"

If we have only one Channel Binding method, we don't need this
comparison.

Best regards,
Yoshihiro Ohba