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]
