Re: Issue 352: Channel Binding Issue
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Mon, 1 May 2006 18:48:41 -0700 (PDT)
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: yohba [at] tari.toshiba.com
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."



Results generated by Tiger Technologies using MHonArc.