SASL Mechanism for External Authentication using a Named Channel: EXTERNAL-CHANNEL
draft-josefsson-sasl-external-channel-01

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 16, 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 describes a way to perform end-user authentication in the Simple Authentication and Security Layer (SASL) framework by re-using an external security layer (such as the Transport Layer Security (TLS) protocol) that may have already completed end-user authentication. In comparison with the existing EXTERNAL mechanism, this mechanism alleviates the a priori assumptions made by the design of the EXTERNAL mechanism. This mechanism transfers an identifier of the external channel to be used explicitly.

See <http://josefsson.org/external-channel/> for more information.

Table of Contents

1.  Introduction
2.  Technical Specification
3.  Examples
4.  Making Authorization Decisions
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Author's Address

1.  Introduction

The EXTERNAL mechanism, described in Appendix A of [RFC4422] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) 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 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] or IP Security (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) [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-CHANNEL mechanism, specified in this document, is similar to the EXTERNAL mechanism in that it relies on an external channel to perform the user authentication. However, EXTERNAL-CHANNEL provides a way for the client to provide an identifier of the external channel that provides the user 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.

In the EXTERNAL-CHANNEL mechanism, the external channel is identified using the "Channel binding unique prefix" string as defined in [RFC5056] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.).

2.  Technical Specification

The name of this mechanism is "EXTERNAL-CHANNEL".

The mechanism does not provide a security layer. It provides similar functionality by relying on an external channel.

The mechanism is capable of transferring a channel name and 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 the string. The channel name cannot be empty.

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 the channel name, and a UTF-8 (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) [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 <extern-initial-resp> production detailed below using the Augmented Backus-Naur Form (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] notation.

   external-initial-resp = cb-name " " authz-id-string

   cb-name               = 1*( US-ASCII / "." / "-")
        ;; Based on RFC 5056: "There is no naming convention for channel
        ;; bindings: any string composed of US-ASCII alphanumeric
        ;; characters, period ('.'), and dash ('-') will suffice."

   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 exchange fails if

- the cb-name denote an (to the server implementation) unknown or end-point channel binding type,

- 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,

- 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.  Examples

This section provides examples of EXTERNAL-CHANNEL 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) (Newman, C. and J. Myers, “ACAP -- Application Configuration Access Protocol,” November 1997.) [RFC2244] is used in the examples because ACAP sends the SASL tokens without additional encoding.

The first example shows use of EXTERNAL-CHANNEL with an empty authorization identity and an external "tls-unique" channel. In this example, the initial response is not sent in the client's request to initiate the authentication exchange.

      S: * ACAP (SASL "DIGEST-MD5")
      C: a001 STARTTLS
      S: a001 OK "Begin TLS negotiation now"
      <TLS negotiation, further commands are under TLS layer>
      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")
      C: a002 AUTHENTICATE "EXTERNAL-CHANNEL"
      S: + "tls-unique "
      C: + ""
      S: a002 OK "Authenticated"

Note how the string ends with a " ", it needs to be present even if the authorization identity is empty.

The second example shows use of EXTERNAL-CHANNEL with an authorization identity of "simon" bound to an external "tls-unique" channel. 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 "DIGEST-MD5")
      C: a001 STARTTLS
      S: a001 OK "Begin TLS negotiation now"
      <TLS negotiation, further commands are under TLS layer>
      S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")
      C: a002 AUTHENTICATE "EXTERNAL-CHANNEL" {16+}
      C: tls-unique 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".

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 the external channel will not use authentication identities that can be used by the application protocol that uses the SASL EXTERNAL-CHANNEL 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 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 (Mavrogiannopoulos, N., “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication,” November 2007.) [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 (Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, “Using the Secure Remote Password (SRP) Protocol for TLS Authentication,” November 2007.) [RFC5054] is used, the username provided may be the same as the application username, and no mapping would be necessary.

5.  IANA Considerations

The IANA is request to add to the SASL mechanisms registry the following entry.

      Subject: Registration of SASL mechanism EXTERNAL-CHANNEL
      SASL mechanism name (or prefix for the family): EXTERNAL-CHANNEL
      Security considerations: See security considerations in RFC XXXX.
      Published specification (recommended): RFC XXXX.
      Person & email address to contact for further information:
          Simon Josefsson <simon@josefsson.org>
      Intended usage: COMMON
      Owner/Change controller: Simon Josefsson <simon@josefsson.org>

6.  Security Considerations

The EXTERNAL-CHANNEL mechanism does not authenticate users 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.

The security of external channel is critical to the security of this mechanism. The connection between the authentication and the external channel is made by sending the name of the channel, so the security considerations related to channel bindings are also relevant, see [RFC5056] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.).

7.  Acknowledgements

The EXTERNAL-CHANNEL mechanism, and significant amount of text in this document, is based on the EXTERNAL mechanism in Appendix A of SASL (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) [RFC4422].

8.  References

8.1. Normative References

8.2. Informative References

Author's Address