I found 3 references may be helpful:
1. http://tools.ietf.org/html/draft-ohba-eap-channel-binding-02
[EAP-CHANNEL] Ohba, Y., Parthasrathy, M., and M. Yanagiya, "Channel
Binding Mechanism Based on Parameter Binding in Key
Derivation",
In this approach the EAP method includes channel binding parameters in
the calculation of
exported EAP keying material, making it impossible for the peer and
authenticator to complete the Secure Association Protocol if there is
a mismatch in the channel binding parameters. However, this approach
can only be applied where methods generating EAP keying material are
used along with lower layers that utilize EAP keying material. For
example, this mechanism would not enable verification of channel
binding on wired IEEE 802 networks using [IEEE-802.1X].
It talked about technique mentioned in current channel binding.
2. in rfc 5247 section 5.3.4. Mutual Authentication
Using EMSK in crypto binding was mentioned, maybe helpful in current
crypto binding
"Since the compound key MUST NOT be known to an attacker posing as an
authenticator, and yet must be derived from EAP keying material, it
MAY be desirable to derive the compound key from a portion of the
EMSK. Where this is done, in order to provide proper key hygiene, it
is RECOMMENDED that the compound key used for man-in-the-middle
protection be cryptographically separate from other keys derived from
the EMSK."
3. also in rfc 5247
TEKs are output from EAP methods and were designed to secure the
channel,
couldn't they be used in channel binding or crypto binding?
"Transient EAP Keys (TEKs)
Session keys that are used to establish a protected channel
between the EAP peer and server during the EAP authentication
exchange. The TEKs are appropriate for use with the ciphersuite
negotiated between EAP peer and server for use in protecting the
EAP conversation. The TEKs are stored locally by the EAP method
and are not exported. Note that the ciphersuite used to set up
the protected channel between the EAP peer and server during EAP
authentication is unrelated to the ciphersuite used to
subsequently protect data sent between the EAP peer and
authenticator.
"
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | |
| | | | | | V
+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^
| | | | Exported |
| Peer-Id(s), | channel | MSK (64+B) | IV (64B) by |
| Server-Id(s), | bindings | EMSK (64+B) | (Optional) EAP |
| Session-Id | & Result | | Method |
V V V V V
Regards~~~
-Sujing Zhou
emu-boun...@ietf.org 写于 2012-05-26 04:39:19:
> The IESG has approved the following document:
> - 'Channel Binding Support for EAP Methods'
> (draft-ietf-emu-chbind-16.txt) as Proposed Standard
>
> This document is the product of the EAP Method Update Working Group.
>
> The IESG contact persons are Sean Turner and Stephen Farrell.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/
>
>
>
>
> Technical Summary
>
> This document defines how to implement channel bindings for
> Extensible Authentication Protocol (EAP) methods to address
> the lying NAS as well as the lying provider problem.
>
> Working Group Summary
>
> This document has had extensive review in the EMU working
> group. The document has clear applicability in ABFAB and
> Network Access use cases.
>
> Document Quality
>
> Project Moonshot, an ABFAB implementation, is working on an
> implementation of this document.
>
> Personnel
>
> Joe Salowey (jsalo...@cisco.com), EMU working group co-chair, is the
> Working Group Shepherd for this document.
> Sean Turner (turn...@ieca.com) is the responsible AD.
>
> RFC Editor Note
>
> Two things:
>
> 1) s9.1: r/subvirt/subvert
>
> 2) Title page (xml2rfc fun on the title page):
>
> OLD:
>
> T. Clancy
> Department of Electrical
> Engineering and Computer Science
>
> NEW:
>
> T. Clancy
> Virginia Tech
>
>
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
