draft-josefsson-sasl-external-channel-02.txt   draft-josefsson-sasl-external-channel-03.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD AB Internet-Draft SJD AB
Intended status: Standards Track April 14, 2009 Intended status: Standards Track April 18, 2009
Expires: October 16, 2009 Expires: October 20, 2009
SASL Mechanism Family for External Authentication: EXTERNAL-* SASL Mechanism Family for External Authentication: EXTERNAL-*
draft-josefsson-sasl-external-channel-02 draft-josefsson-sasl-external-channel-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 16, 2009. This Internet-Draft will expire on October 20, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes a way to perform client authentication in the This document describes a way to perform client authentication in the
Simple Authentication and Security Layer (SASL) framework by Simple Authentication and Security Layer (SASL) framework by
referring to the end-user authentication provided by an external referring to the client authentication provided by an external
security layer. We specify a SASL mechanism family EXTERNAL-* and security layer. We specify a SASL mechanism family EXTERNAL-* and
one instance EXTERNAL-TLS that rely on the Transport Layer Security one instance EXTERNAL-TLS that rely on the Transport Layer Security
(TLS) protocol. This mechanism differs to the existing EXTERNAL (TLS) protocol. This mechanism differs to the existing EXTERNAL
mechanism by alleviating the a priori assumptions that servers and mechanism by alleviating the a priori assumptions that servers and
clients needs somehow negotiate out of band which secure channel that clients needs somehow negotiate out of band which secure channel that
is intended. This document also discuss the implementation of is intended. This document also discuss the implementation of
authorization decisions. authorization decisions.
See <http://josefsson.org/external-channel/> for more information. See <http://josefsson.org/external-channel/> for more information.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification of EXTERNAL-* Mechanism Family . . . . . . . . . 4 2. Specification of EXTERNAL-* Mechanism Family . . . . . . . . . 4
3. Specification of EXTERNAL-TLS Mechanism . . . . . . . . . . . . 6 3. Specification of EXTERNAL-TLS Mechanism . . . . . . . . . . . 6
4. Making Authorization Decisions . . . . . . . . . . . . . . . . 6 4. Making Authorization Decisions . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The EXTERNAL mechanism, described in Appendix A of [RFC4422] allows a The EXTERNAL mechanism, described in Appendix A of [RFC4422] allows a
client to request the server to use credentials established by means client to request the server to use credentials established by means
external to the mechanism to authenticate the client. The external external to the mechanism to authenticate the client. The external
means may be, for instance, TLS [RFC5246] or IP Security [RFC4301] means may be, for instance, TLS [RFC5246] or IP Security [RFC4301]
services. services.
The EXTERNAL mechanism requires some a prior agreement between the The EXTERNAL mechanism requires some a prior agreement between the
client and the server regarding which external channel, and client and the server regarding which external channel, and
consequently which external credentials, should be used for consequently which external credentials, should be used for
authentication. In practice this has often meant that the EXTERNAL authentication. In practice this has often meant that the EXTERNAL
mechanism is only used when there is tight out of band interaction mechanism is only used when there is tight out of band interaction
between the server administration and client user. This has impacted between the server administration and client user. This has impacted
the interoperability of the EXTERNAL mechanism. the interoperability of the EXTERNAL mechanism.
The EXTERNAL-* mechanism family, specified in this document, is The EXTERNAL-* mechanism family, specified in this document, is
similar to the EXTERNAL mechanism in that it relies on an external similar to the EXTERNAL mechanism in that it relies on an external
channel to perform the user authentication. However, EXTERNAL-* channel to perform the client authentication. However, EXTERNAL-*
provides a way for the client to provide an identifier of the provides a way for the client to provide an identifier of the
external channel that is intended to provide the user credentials. external channel that is intended to provide the client credentials.
The intention is that the server need not rely on a priori The intention is that the server need not rely on a priori
arrangement to identify the secure channel that was used, but can arrangement to identify the secure channel that was used, but can
automatically find the intended channel and re-use its credentials automatically find the intended channel and re-use its credentials
for the SASL authentication. Further, upon successful for the SASL authentication. Further, upon successful
authentication, the client knows that the server used credentials authentication, the client knows that the server used credentials
from the indicated security channel. from the indicated security channel.
In the EXTERNAL-* mechanism family, the external channel is In the EXTERNAL-* mechanism family, the external channel is
identified through the SASL mechanism name. 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 2. Specification of EXTERNAL-* Mechanism Family
The name of the mechanism family is "EXTERNAL-". The name of the mechanism family is "EXTERNAL-".
The mechanism family does not provide a security layer. It provides The mechanism family does not provide a security layer. It provides
similar functionality by relying on an external channel. similar functionality by relying on an external channel.
The mechanism is capable of transferring an authorization identity The mechanism is capable of transferring an authorization identity
string. If the authorization identity string is empty, the client is string. If the authorization identity string is empty, the client is
requesting to act as the identity the server has associated with the requesting to act as the identity the server has associated with the
skipping to change at page 6, line 19 skipping to change at page 6, line 23
Otherwise the exchange is successful. When indicating a successful Otherwise the exchange is successful. When indicating a successful
outcome, additional data is not provided. outcome, additional data is not provided.
3. Specification of EXTERNAL-TLS Mechanism 3. Specification of EXTERNAL-TLS Mechanism
The EXTERNAL-TLS mechanism uses client credentials established by the The EXTERNAL-TLS mechanism uses client credentials established by the
outer TLS [RFC5246] channel. Only the inner-most TLS channel is outer TLS [RFC5246] channel. Only the inner-most TLS channel is
intended. For example, if an application opens up a TLS channel and intended. For example, if an application opens up a TLS channel and
starts SASL negotiation, and if that communication happens to be sent starts SASL negotiation, and if that communication happens to be sent
over a TLS-based VPN, the credentials for the TLS-based VPN is not over a TLS-based VPN, the intended channel is the TLS channel opened
considered. by the application.
The server MUST NOT advertise the EXTERNAL-TLS mechanism if the The server MUST NOT advertise the EXTERNAL-TLS mechanism if the
client did not provided any supported form of client-side client did not provided any supported form of client-side
authentication in the TLS channel, e.g., X.509 client certificate, authentication in the TLS channel, e.g., X.509 client certificate,
OpenPGP client key [RFC5081], or SRP [RFC5054]. The client MUST only OpenPGP client key [RFC5081], or SRP [RFC5054]. The client MUST only
request the EXTERNAL-TLS if it wishes to re-use the TLS client request the EXTERNAL-TLS if it wishes to re-use the TLS client
credentials for the SASL application. credentials for the SASL application.
4. Making Authorization Decisions 4. Making Authorization Decisions
skipping to change at page 8, line 21 skipping to change at page 8, line 24
C: simon C: simon
S: a002 NO "Cannot assume requested authorization identity" S: a002 NO "Cannot assume requested authorization identity"
Note how the server rejects the authentication attempt with an Note how the server rejects the authentication attempt with an
authorization-related error message. Presumably the client authorization-related error message. Presumably the client
credentials presented in the TLS session does not give the client credentials presented in the TLS session does not give the client
authority to assume the identity of "simon". authority to assume the identity of "simon".
6. IANA Considerations 6. IANA Considerations
The IANA is request to add to the SASL mechanisms registry the The IANA is requested to add to the SASL mechanisms registry the
following entry. following entry.
Subject: Registration of SASL mechanism family EXTERNAL-* Subject: Registration of SASL mechanism family EXTERNAL-*
SASL family name (or prefix for the family): EXTERNAL- SASL family name (or prefix for the family): EXTERNAL-
Security considerations: [THIS-DOC] Security considerations: [THIS-DOC]
Published specification (recommended): [THIS-DOC] Published specification (recommended): [THIS-DOC]
Person & email address to contact for further information: Person & email address to contact for further information:
Simon Josefsson <simon@josefsson.org> Simon Josefsson <simon@josefsson.org>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: Simon Josefsson <simon@josefsson.org> Owner/Change controller: Simon Josefsson <simon@josefsson.org>
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
be standardized through the normal IETF process, when appropriate.
7. Security Considerations 7. Security Considerations
The security of external channel is critical to the security of this The security of external channel is critical to the security of this
mechanism. It is important that the client authentication that mechanism. It is important that the client authentication that
occurs in the outer security channel is cryptographically bound to occurs in the outer security channel is cryptographically bound to
the confidentiality or integrity services that protects the security the confidentiality or integrity services that protects the security
channel. channel.
The EXTERNAL-* mechanism family does not authenticate users itself, The EXTERNAL-* mechanism family does not authenticate clients itself,
it relies on implementation to perform the authentication as part of it relies on implementation to perform the authentication as part of
the external channel. Care must be taken to ensure that the client the external channel. Care must be taken to ensure that the client
credential has been authenticated, rather than just blindly accepted credential has been authenticated, rather than just blindly accepted
as part of a leap-of-faith setup. as part of a leap-of-faith setup.
8. Acknowledgements 8. Acknowledgements
The EXTERNAL-* mechanism family, and significant amount of text in Significant amount of text in this document is copied from SASL
this document, is based on the EXTERNAL mechanism in Appendix A of [RFC4422].
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. References
9.1. Normative 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 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
9.2. Informative References 9.2. Informative References
skipping to change at page 9, line 39 skipping to change at page 10, line 24
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
"Using the Secure Remote Password (SRP) Protocol for TLS "Using the Secure Remote Password (SRP) Protocol for TLS
Authentication", RFC 5054, November 2007. Authentication", RFC 5054, November 2007.
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", RFC 5081, Layer Security (TLS) Authentication", RFC 5081,
November 2007. 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 Author's Address
Simon Josefsson Simon Josefsson
SJD AB SJD AB
Email: simon@josefsson.org Email: simon@josefsson.org
 End of changes. 17 change blocks. 
20 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/