Network Working Group S. Josefsson
Internet-Draft SJD AB
Intended status: Standards Track April 18, 2009
Expires: October 20, 2009
SASL Mechanism Family for External Authentication: EXTERNAL-*
draft-josefsson-sasl-external-channel-03
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 20, 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
Josefsson Expires October 20, 2009 [Page 1]
Internet-Draft EXTERNAL-* April 2009
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 describes a way to perform client authentication in the
Simple Authentication and Security Layer (SASL) framework by
referring to the client authentication provided by an external
security layer. We specify a SASL mechanism family EXTERNAL-* and
one instance EXTERNAL-TLS that rely on the Transport Layer Security
(TLS) protocol. This mechanism differs to the existing EXTERNAL
mechanism by alleviating the a priori assumptions that servers and
clients needs somehow negotiate out of band which secure channel that
is intended. This document also discuss the implementation of
authorization decisions.
See for more information.
Josefsson Expires October 20, 2009 [Page 2]
Internet-Draft EXTERNAL-* April 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of EXTERNAL-* Mechanism Family . . . . . . . . . 4
3. Specification of EXTERNAL-TLS Mechanism . . . . . . . . . . . 6
4. Making Authorization Decisions . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Josefsson Expires October 20, 2009 [Page 3]
Internet-Draft EXTERNAL-* April 2009
1. Introduction
The EXTERNAL mechanism, described in Appendix A of [RFC4422] allows a
client to request the server to use credentials established by means
external to the mechanism to authenticate the client. The external
means may be, for instance, TLS [RFC5246] or IP Security [RFC4301]
services.
The EXTERNAL mechanism requires some a prior agreement between the
client and the server regarding which external channel, and
consequently which external credentials, should be used for
authentication. In practice this has often meant that the EXTERNAL
mechanism is only used when there is tight out of band interaction
between the server administration and client user. This has impacted
the interoperability of the EXTERNAL mechanism.
The EXTERNAL-* mechanism family, specified in this document, is
similar to the EXTERNAL mechanism in that it relies on an external
channel to perform the client authentication. However, EXTERNAL-*
provides a way for the client to provide an identifier of the
external channel that is intended to provide the client credentials.
The intention is that the server need not rely on a priori
arrangement to identify the secure channel that was used, but can
automatically find the intended channel and re-use its credentials
for the SASL authentication. Further, upon successful
authentication, the client knows that the server used credentials
from the indicated security channel.
In the EXTERNAL-* mechanism family, the external channel is
identified through the SASL mechanism name.
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. Specification of EXTERNAL-* Mechanism Family
The name of the mechanism family is "EXTERNAL-".
The mechanism family does not provide a security layer. It provides
similar functionality by relying on an external channel.
The mechanism is capable of transferring an authorization identity
string. If the authorization identity string is empty, the client is
requesting to act as the identity the server has associated with the
client's credentials. If the authorization identity string is non-
empty, the client is requesting to act as the identity represented by
Josefsson Expires October 20, 2009 [Page 4]
Internet-Draft EXTERNAL-* April 2009
the string.
The client is expected to send data first in the authentication
exchange. Where the client does not provide an initial response data
in its request to initiate the authentication exchange, the server is
to respond to the request with an empty initial challenge and then
the client is to provide its initial response.
The client sends the initial response containing a UTF-8 [RFC3629]
encoding of the requested authorization identity string.
The authorization identity is non-empty when the client is requesting
to act as the identity represented by the (non-empty) string. The
authorization identity is empty when the client is requesting to act
as the identity the server associates with the external
authentication credentials.
The syntax of the initial response is specified as a value of the
production detailed below using the Augmented
Backus-Naur Form (ABNF) [RFC5234] notation.
external-initial-resp = authz-id-string
authz-id-string = *( UTF8-char-no-nul )
UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
;; where the UTF8-2, UTF8-3, and UTF8-4 productions are
;; as defined in RFC 3629.
UTF8-1-no-nul = %x01-7F
There are no additional challenges and responses.
Hence, the server is to return the outcome of the authentication
exchange.
The external security channel to use is implied by the SASL mechanism
name.
The exchange fails if
- the client has not established its credentials via the indicated
external channel,
- the client's credentials are inadequate,
- the client provided an empty authorization identity string and the
server is unwilling or unable to associate an authorization identity
with the client's credentials,
Josefsson Expires October 20, 2009 [Page 5]
Internet-Draft EXTERNAL-* April 2009
- the client provided a non-empty authorization identity string that
is invalid per the syntax requirements of the applicable application
protocol specification,
- the client provided a non-empty authorization identity string
representing an identity that the client is not allowed to act as, or
- the server is unwilling or unable to provide service to the client
for any other reason.
Otherwise the exchange is successful. When indicating a successful
outcome, additional data is not provided.
3. Specification of EXTERNAL-TLS Mechanism
The EXTERNAL-TLS mechanism uses client credentials established by the
outer TLS [RFC5246] channel. Only the inner-most TLS channel is
intended. For example, if an application opens up a TLS channel and
starts SASL negotiation, and if that communication happens to be sent
over a TLS-based VPN, the intended channel is the TLS channel opened
by the application.
The server MUST NOT advertise the EXTERNAL-TLS mechanism if the
client did not provided any supported form of client-side
authentication in the TLS channel, e.g., X.509 client certificate,
OpenPGP client key [RFC5081], or SRP [RFC5054]. The client MUST only
request the EXTERNAL-TLS if it wishes to re-use the TLS client
credentials for the SASL application.
4. Making Authorization Decisions
The server may use any mechanism to make authorization decisions.
For illustration, we want to give some ideas on how this may work in
practice. This section is not normative.
Typically external channels will not use authentication identities
that can be used by the application protocol that uses an instance of
the SASL EXTERNAL-* mechanism. Thus, a mapping is normally required.
There may be mappings from the external credential to a set of
permitted identifiers, and a "default" identifier can be provided in
the mapping table if the client do not specify a particular
authorization identity.
For example, when mapping from X.509 credentials used in TLS
connections to simple usernames, a table stored on the server can
contain hex-encoded hashes of client X.509 certificates and a set of
Josefsson Expires October 20, 2009 [Page 6]
Internet-Draft EXTERNAL-* April 2009
usernames.
aef3a7835277a28da831005c2ae3b919e2076a62 simon jas admin
d2fc512490a15036460b5489401439d6da5407fa joe
The server could extract a successfully authenticated X.509 client
certificate from the TLS stack, hash it and look it up in the mapping
table. Each of the usernames given would be permitted authorization
identities. The first username given may be the default username if
the client does not provide an authorization identity.
When mapping from OpenPGP credentials used in TLS [RFC5081], the
mapping table could consist of verified OpenPGP fingerprints and a
set of permitted usernames, such as the following table.
0424D4EE81A0E3D119C6F835EDA21E94B565716F simon jas admin
A4D94E92B0986AB5EE9DCD755DE249965B0358A2 werner
90A79E2FC6F4AAB5B604974FE15DD857B15C37D1 nikos
When SRP authentication with TLS [RFC5054] is used, the username
provided may be the same as the application username, and no mapping
would be necessary.
5. Examples
This section provides examples of EXTERNAL-TLS authentication
exchanges. The examples are intended to help the readers understand
the above text. The examples are not definitive. The Application
Configuration Access Protocol (ACAP) [RFC2244] is used in the
examples because ACAP sends the SASL tokens without additional
encoding.
The first example shows use of EXTERNAL-TLS with an empty
authorization identity. In this example, the initial response is not
sent in the client's request to initiate the authentication exchange.
S: * ACAP (SASL "GSSAPI")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
S: * ACAP (SASL "GSSAPI" "PLAIN" "EXTERNAL-TLS")
C: a002 AUTHENTICATE "EXTERNAL-TLS"
S: + ""
C: + ""
S: a002 OK "Authenticated"
The second example shows use of EXTERNAL-TLS with an authorization
Josefsson Expires October 20, 2009 [Page 7]
Internet-Draft EXTERNAL-* April 2009
identity of "simon". In this example, the initial response is sent
with the client's request to initiate the authentication exchange.
This saves a round-trip.
S: * ACAP (SASL "GSSAPI")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
S: * ACAP (SASL "GSSAPI" "PLAIN" "EXTERNAL-TLS")
C: a002 AUTHENTICATE "EXTERNAL-TLS" {5+}
C: simon
S: a002 NO "Cannot assume requested authorization identity"
Note how the server rejects the authentication attempt with an
authorization-related error message. Presumably the client
credentials presented in the TLS session does not give the client
authority to assume the identity of "simon".
6. IANA Considerations
The IANA is requested to add to the SASL mechanisms registry the
following entry.
Subject: Registration of SASL mechanism family EXTERNAL-*
SASL family name (or prefix for the family): EXTERNAL-
Security considerations: [THIS-DOC]
Published specification (recommended): [THIS-DOC]
Person & email address to contact for further information:
Simon Josefsson
Intended usage: COMMON
Owner/Change controller: Simon Josefsson
IANA will register new SASL mechanism names under the "EXTERNAL-"
namespace on a First Come First Served basis, as defined in
[RFC5226]. IANA has the right to reject obviously bogus registration
requests, but will perform no review of claims made in the
registration form.
Registration of a SASL mechanism under the "EXTERNAL-" namespace is
requested by filling in the same template used in [RFC4422] using a
name prefixed with "EXTERNAL-".
While this registration procedure does not require expert review,
authors of SASL mechanisms are encouraged to seek community review
and comment whenever that is feasible. Authors may seek community
review by posting a specification of their proposed mechanism as an
Internet-Draft. SASL mechanisms intended for widespread use should
Josefsson Expires October 20, 2009 [Page 8]
Internet-Draft EXTERNAL-* April 2009
be standardized through the normal IETF process, when appropriate.
7. Security Considerations
The security of external channel is critical to the security of this
mechanism. It is important that the client authentication that
occurs in the outer security channel is cryptographically bound to
the confidentiality or integrity services that protects the security
channel.
The EXTERNAL-* mechanism family does not authenticate clients itself,
it relies on implementation to perform the authentication as part of
the external channel. Care must be taken to ensure that the client
credential has been authenticated, rather than just blindly accepted
as part of a leap-of-faith setup.
8. Acknowledgements
Significant amount of text in this document is copied from SASL
[RFC4422].
The document was improved by discussion in the SASL Working Group
between Chris Newman, Philip Guenther, Alexey Melnikov, Hallvard B
Furuseth, Nicolas Williams, Sam Hartman, Jeffrey Hutzelman, and Kurt
Zeilenga.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Josefsson Expires October 20, 2009 [Page 9]
Internet-Draft EXTERNAL-* April 2009
9.2. Informative References
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
"Using the Secure Remote Password (SRP) Protocol for TLS
Authentication", RFC 5054, November 2007.
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", RFC 5081,
November 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Author's Address
Simon Josefsson
SJD AB
Email: simon@josefsson.org
Josefsson Expires October 20, 2009 [Page 10]