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.

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
    1.1.  Conventions used in this document
2.  Channel Binding Semantics and Negotiation for SASL
3.  IANA Considerations
4.  Security Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Author's Address

1.  Introduction

The introduction of the Salted Challenge Response (SCRAM) SASL mechanism [I‑D.newman‑auth‑scram] (Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, “Salted Challenge Response (SCRAM) SASL Mechanism,” May 2009.) and GS2 family of SASL mechanisms [I‑D.ietf‑sasl‑gs2] (Josefsson, S. and N. Williams, “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” January 2010.) requires that we define the semantics of channel binding [RFC5056] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.) in the context of SASL [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.).

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 (Channel Binding Semantics and Negotiation for SASL).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Channel Binding Semantics and Negotiation for SASL

In order to use SASL [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) with channel binding [RFC5056] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.) 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) 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.

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.

4.  Security Considerations

For general security considerations relating to channel bindings see [RFC5056] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.). For general security considerations relating to SASL see [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.).

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 (Channel Binding Semantics and Negotiation for SASL).

5.  References

5.1. Normative References

5.2. Informative References

Author's Address