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

Abstract

This document proposes to incorporate channel binding as defined in [I-D.ietf-emu-chbind ] into EAP tunnel method as soon as possible.

Status of this Memo

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 Notice

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.


Table of Contents

1. Introduction

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.

1.1. Terminology

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

2. Channel Binding after Tunnel Establishment

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

3. Channel Binding after the First Inner Method

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.

4. IANA Considerations

This document includes no request to IANA.

5. Security Considerations

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.

6. References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J. and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[I-D.ietf-emu-crypto-bind] Hartman, S, Wasserman, M and D Zhang, "EAP Mutual Cryptographic Binding", Internet-Draft draft-ietf-emu-crypto-bind-00, June 2012.
[I-D.ietf-emu-chbind] Hartman, S, Clancy, T and K Hoeper, "Channel Binding Support for EAP Methods", Internet-Draft draft-ietf-emu-chbind-08, July 2011.
[I-D.ietf-emu-eap-tunnel-method] Zhou, H, Cam-Winget, N, Salowey, J and S Hanna, "Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) Version 2", Internet-Draft draft-ietf-emu-eap-tunnel-method-00, May 2011.
[I-D.josefsson-pppext-eap-tls-eap] Josefsson, S, Palekar, A, Simon, D and G Zorn, "Protected EAP Protocol (PEAP) Version 2", Internet-Draft draft-josefsson-pppext-eap-tls-eap-10, October 2004.

Author's Address

Sujing Zhou ZTE Corporation No.68 Zijinghua Rd. Yuhuatai District Nanjing, Jiang Su 210012 R.R.China EMail: zhou.sujing@zte.com.cn