SASL Mechanism Family for External Authentication: EXTERNAL-*
SJD ABsimon@josefsson.orgThis 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 <http://josefsson.org/external-channel/> for more
information.The EXTERNAL mechanism, described in Appendix A of
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 or IP
Security 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
.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 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 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)
notation.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,- 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.The EXTERNAL-TLS mechanism uses client credentials established by
the outer TLS 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,
or SRP. The client MUST only
request the EXTERNAL-TLS if it wishes to re-use the TLS client
credentials for the SASL application.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 usernames.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, the mapping table could consist of verified OpenPGP
fingerprints and a set of permitted usernames, such as the
following table.When SRP authentication with TLS is
used, the username provided may be the same as the application
username, and no mapping would be necessary.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) 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.The second example shows use of EXTERNAL-TLS with an
authorization 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.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".The IANA is requested to add to the SASL mechanisms registry the
following entry.IANA will register new SASL mechanism names under the
"EXTERNAL-" namespace on a First Come First Served basis, as
defined in . 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
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.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.Significant amount of text in this document is copied
from SASL.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.