| EAP Method Update | S.Z. Zhou |
| Internet-Draft | ZTE Corporation |
| Intended status: Standards Track | July 6, 2012 |
| Expires: January 05, 2013 |
Combination of Channel Binding and Tunnel Method
draft-zhou-emu-ch-tunnel-00
This document proposes to incorporate channel binding as defined in [I-D.ietf-emu-chbind ] into EAP tunnel method as soon as possible.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 05, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Channel binding as define in [I-D.ietf-emu-chbind] is used to imitigate lying authenticator , and is implemented as part of the ongoing EAP method, because the assertion transported from the EAP server to EAP peer is authenticated by the resluting key (TEK, to be more specific) derived from the EAP method. Although it is a bit late to know the contacting authenticator is a liar after the peer has completed the EAP method, it is a rather reasonable compromise to the legacy EAP methods.
EAP Tunnel methods, e.g., defined in [RFC4851][RFC5281][I-D.ietf-emu-eap-tunnel-method], are used to protect weak EAP methods, especially some legacy EAP methods. When it comes to using channel binding in tunnel methods, it is more complex. To maximise the compatibility , channel binding may still be carried out with the inner EAP method, using the inner TEK, or some key derived from tunnel key (output from tunnel method) and inner EAP method key, which has not been specified. This way, a peer is assured of the honesty of the contacting authenticator only after both the tunnel establishement and the completement of the inner EAP method.
Since tunnel methods are used to protect the inner method, it might be desirebale to provide channel binding simultaneously with or right after the tunnel establishment.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When there is no inner EAP method after the tunnel establishement,which is not ruled out in the current tunnel method specification, or the inner method does not output key, channel binding is carried out immediately after the tunnel establishment according to the procedure defined in [I-D.ietf-emu-chbind], the key used to authenticate the CB_Success or CB-Failure is derived from the tunnel key TK and some shared secret (TEK) between EAP server and the peer. TEK could be NULL if no shared secret can be provided at this time.
In this case, when TEK is NULL, the certificate verification of the EAP server (i.e., the tunnel server) is crucial, as pointed out in [I-D.ietf-emu-crypto-bind].
When some inner methods are carried out after the tunnel establishment, and the first inner method outputs key, channel binding is executed along with the first inner method, as defined in [I-D.ietf-emu-chbind],the key used to authenticate the CB-Success or CB_Failure is derived from the tunnel key TK and one of the outputs of the first inner method , i.e., TEK.
This document includes no request to IANA.
This document proposes to carry out channel binding as soon as possible, in the case of EAP tunnel method is involved, to detect rogueauthenticator as early as possible.