SASL WG N. Williams Internet-Draft Sun Updates: rfc4422 April 9, 2009 (if approved) Intended status: Standards Track Expires: October 11, 2009 SASL And Channel Binding draft-ietf-sasl-channel-bindings-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 11, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Williams Expires October 11, 2009 [Page 1] Internet-Draft SASL Channel Binding April 2009 Abstract This document specifies the semantics of channel binding for the Simple Authentication and Security Layers (SASL) framework, mechanisms and applications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. Channel Binding Semantics and Negotiation for SASL . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Williams Expires October 11, 2009 [Page 2] Internet-Draft SASL Channel Binding April 2009 1. Introduction The introduction of the Salted Challenge Response (SCRAM) SASL mechanism [I-D.newman-auth-scram] and GS2 family of SASL mechanisms [I-D.ietf-sasl-gs2] requires the introduction into SASL of an abstract interface to channel binding [RFC5056]. 1.1. Conventions used in this document 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]. Williams Expires October 11, 2009 [Page 3] Internet-Draft SASL Channel Binding April 2009 2. Channel Binding Semantics and Negotiation for SASL In order to use SASL [RFC4422] with channel binding the client and server applications MUST provide a channel binding type and channel binding data to the selected SASL mechanism before the first mechanism's authentication message is produced (client side) or consumed (server side). Channel binding failure MUST cause authentication failure. Use of channel binding must be negotiable. The client need not use channel binding, and the server may not support the use of channel binding. But because channel binding is all or nothing we need a method for negotiating its used. We accomplish this by using a convention by which the server can indicate whether it supports channel binding in its mechanism list. That is, we overload the mechanism negotiation to obtain channel binding negotiation. The convention is that the specification for any SASL mechanism that supports channel binding MUST specify two mechanism names: one that indicates server support for channel binding, and one that indicates the opposite. We RECOMMEND the use of a mechanism name suffix, specifically "-PLUS" to indicate server support for channel binding.. A client MUST NOT use channel binding if it lists the server's mechanisms and does not find a suitable mechanism that supports channel binding in that list. A server MUST NOT advertise mechanism names indicating support for channel binding if the server application or the mechanism implementations do not support channel binding. Conversely, the server MUST advertise mechanism names indicating support for channel binding if the server application and the mechanism implementations do support channel binding. To prevent downgrade attacks each mechanism that supports channel binding MUST provide downgrade attack detection. To do this the client application MUST provide the name of the selected mechanism, or the server's entire mechanism list, as an input to the mechanism prior to producing the mechanism's first authentication message. The mechanism MUST securely indicate to the server whether the client a) chose to use channel binding, b) would have chosen to use channel binding if the server had supported it, c) cannot do channel binding. In the case of (c) the server MUST fail authentication if the server does actually support channel binding. Williams Expires October 11, 2009 [Page 4] Internet-Draft SASL Channel Binding April 2009 3. IANA Considerations This document changes the procedures for registration of SASL mechanism names. Henceforth any SASL mechanism registration MUST indicate a) whether the mechanism supports channel binding, and, if it does, b) two mechanism names and an indication of which name indicates server support for channel binding. Williams Expires October 11, 2009 [Page 5] Internet-Draft SASL Channel Binding April 2009 4. Security Considerations For general security considerations relating to channel bindings see [RFC5056]. Williams Expires October 11, 2009 [Page 6] Internet-Draft SASL Channel Binding April 2009 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. 5.2. Informative References [I-D.ietf-sasl-gs2] Josefsson, S. and N. Williams, "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-11 (work in progress), March 2009. [I-D.newman-auth-scram] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, "Salted Challenge Response (SCRAM) SASL Mechanism", draft-newman-auth-scram-12 (work in progress), March 2009. Williams Expires October 11, 2009 [Page 7] Internet-Draft SASL Channel Binding April 2009 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires October 11, 2009 [Page 8]