SASL WG N. Williams Internet-Draft Sun Updates: rfc4422 April 15, 2009 (if approved) Intended status: Standards Track Expires: October 17, 2009 SASL And Channel Binding draft-ietf-sasl-channel-bindings-02.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 17, 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 17, 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 . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Williams Expires October 17, 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 that we define the semantics of channel binding [RFC5056] in the context of SASL [RFC4422]. In SASL channel bindings are all-or-nothing, and the use or non-use of channel binding is negotiated via mechanism negotiation, with downgrade protection built into mechanisms that support channel binding. See Section 2. 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 17, 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 [RFC5056] the client and server applications MUST provide the SASL mechanism with channel bindings data and channel binding type names for all available channel binding types for the channel to be bound. These channel bindings data MUST be provided to the mechanism before the first authentication message is produced or consumed by the mechanism. The mechanism MUST use at least one, and MAY use more than one of the provided channel binding types. Channel binding is OPTIONAL, but when used, channel binding failure MUST cause authentication failure. Use of channel binding must be negotiable. Either or both of the client and server might not support channel binding in any given exchange. But because channel binding is all or nothing we need a method for negotiating its use. 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 optional channel binding MUST specify two mechanism names: one that indicates server support for channel binding, and one that indicates the opposite. Otherwise these two names MUST be equivalent. Mechanisms that require the use of channel bindings SHOULD have a single mechanism name. We RECOMMEND the use of a mechanism name suffix, specifically "-PLUS" to indicate server support for channel binding. The 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. The 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. 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) Williams Expires October 17, 2009 [Page 4] Internet-Draft SASL Channel Binding April 2009 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 17, 2009 [Page 5] Internet-Draft SASL Channel Binding April 2009 3. IANA Considerations This document changes the procedures for registration of SASL mechanism names in the IANA SASL mechanism name registry. Henceforth any SASL mechanism registration MUST indicate a) whether the mechanism supports channel binding, b) whether it requires channel binding, and, if the mechanism supports optional channel binding then c) two mechanism names and an indication of which name indicates server support for channel binding. Williams Expires October 17, 2009 [Page 6] Internet-Draft SASL Channel Binding April 2009 4. Security Considerations For general security considerations relating to channel bindings see [RFC5056]. For general security considerations relating to SASL see [RFC4422]. This document specifies how channel binding fits into SASL and, specifically, the semantics of channel binding for SASL and how channel binding is negotiated. The negotiation of channel binding is subject to downgrade attacks by active attackers, therefore we include a requirement that SASL mechanisms provide protection against downgrade attacks. Protection against downgrade attacks requires that the application provide certain information to the SASL mechanism. See Section 2. Williams Expires October 17, 2009 [Page 7] 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 17, 2009 [Page 8] 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 17, 2009 [Page 9]