One document matched: draft-josefsson-sasl-external-channel-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="std" ipr="full3978"
docName="draft-josefsson-sasl-external-channel-00">
<front>
<title abbrev="EXTERNAL-CHANNEL">
SASL Mechanism for External Authentication using Channel Bindings:
EXTERNAL-CHANNEL
</title>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization>SJD</organization>
<address>
<email>simon@josefsson.org</email>
</address>
</author>
<date month="August" year="2008"/>
<abstract>
<t>This document describes a way to perform end-user authentication
in the Simple Authentication and Security Layer (SASL) framework
which re-use 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 offers a way to cryptographically bind
the authentication to the security layer via a channel binding.
The EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions
made by the design of the EXTERNAL mechanism.</t>
<t>See <http://josefsson.org/external-channel/> for more
information.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The EXTERNAL mechanism, described in Appendix A of
<xref target="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,
<xref target="RFC4346">TLS</xref> or <xref target="RFC4301">IP
Security</xref> services.</t>
<t>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 an impact of the interoperability of the EXTERNAL
mechanism.</t>
<t>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.</t>
<t>In the EXTERNAL-CHANNEL mechanism the external channel is
identified using the "Channel binding unique prefix" string as
defined in <xref target="RFC5056" />. A channel bindings is
transferred, so that the server can verify that the client is a
peer of the same secure channel as the server.</t>
<t>Binding authentication to a specific encrypted session can
protect from certain <xref target="MITM">attacks</xref>. It can
also help to improve performance by having peers agree to re-use a
secure channel rather than to set up a new.</t>
</section>
<section title="Technical Specification">
<t>The name of this mechanism is "EXTERNAL-CHANNEL".</t>
<t>The mechanism does not provide a security layer. It provides
similar functionality by relying on an external channel.</t>
<t>The mechanism is capable of transferring a channel binding 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 binding name cannot be empty.</t>
<t>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.</t>
<t>The client sends the initial response containing the channel
binding name, a <xref target="RFC4648">base64</xref> encoded
channel bindings, and a <xref target="RFC3629">UTF-8</xref>
encoding of the requested authorization identity string.</t>
<t>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.</t>
<t>The syntax of the initial response is specified as a value of the
<extern-initial-resp> production detailed below using the
<xref target="RFC4234">Augmented Backus-Naur Form (ABNF)</xref>
notation.</t>
<figure>
<artwork type="abnf">
external-initial-resp = cb-name " " b64-cb-data " " 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."
b64-cb-data = *( ALPHA / DIGIT / "+" / "/" / "=" )
;; Base64 encoding of the channel bindings, the format
;; of the decoded data depends on the cb-name.
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
</artwork>
</figure>
<t>There are no additional challenges and responses.</t>
<t>Hence, the server is to return the outcome of the authentication
exchange.</t>
<t>The exchange fails if</t>
<t>- the cb-name denote an (to the server implementation) unknown or
end-point channel binding type,</t>
<t>- the client has not established its credentials via the
indicated external channel,</t>
<t>- the channel bindings data does not match,</t>
<t>- the client's credentials are inadequate,</t>
<t>- 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,</t>
<t>- the client provided a non-empty authorization identity string
that is invalid per the syntax requirements of the applicable
application protocol specification,</t>
<t>- the client provided a non-empty authorization identity string
representing an identity that the client is not allowed to act as,
or</t>
<t>- the server is unwilling or unable to provide service to the
client for any other reason.</t>
<t>Otherwise the exchange is successful. When indicating a
successful outcome, additional data is not provided.</t>
</section>
<section title="Examples">
<t>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
<xref target="RFC2244">Application Configuration Access Protocol
(ACAP)</xref> is used in the examples because ACAP sends the SASL
tokens without additional encoding.</t>
<t>The first example shows use of EXTERNAL-CHANNEL with an empty
authorization identity bound to an external "tls-unique" channel.
In this example, the initial response is not sent in the client's
request to initiate the authentication exchange.</t>
<figure>
<artwork>
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 rvOng1J3oo2oMQBc "
C: + ""
S: a002 OK "Authenticated"
</artwork>
</figure>
<t>Note how the string ends with a " ", it needs to be present even
if the authorization identity is empty.</t>
<t>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.</t>
<figure>
<artwork>
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" {31+}
C: tls-unique CI4WoQGSd7FdWPrw simon
S: a002 NO "Cannot assume requested authorization identity"
</artwork>
</figure>
<t>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".</t>
</section>
<section title="Making Authorization Decisions">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure>
<artwork>
aef3a7835277a28da831005c2ae3b919e2076a62 simon jas admin
d2fc512490a15036460b5489401439d6da5407fa joe
</artwork>
</figure>
<t>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.</t>
<t>When mapping from <xref target="RFC5081">OpenPGP credentials used
in TLS</xref>, the mapping table could consist of verified OpenPGP
fingerprints and a set of permitted usernames, such as the
following table.</t>
<figure>
<artwork>
0424D4EE81A0E3D119C6F835EDA21E94B565716F simon jas admin
A4D94E92B0986AB5EE9DCD755DE249965B0358A2 werner
90A79E2FC6F4AAB5B604974FE15DD857B15C37D1 nikos
</artwork>
</figure>
<t>When <xref target="RFC5054">SRP authentication with TLS</xref> is
used, the username provided may be the same as the application
username, and no mapping would be necessary.</t>
</section>
<section title="IANA Considerations">
<t>The IANA is request to add to the SASL mechanisms registry the
following entry.</t>
<figure>
<artwork>
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>
</artwork>
</figure>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>The security of external channel is critical to the security of
this mechanism. The connection between the authentication and the
external channel is made via a channel binding, thus the security
considerations related to channel bindings are also critical, see
<xref target="RFC5056"/>.</t>
<t>We claim that by appropriately using a channel binding an
application can protect itself from the attacks in
<xref target="MITM" />. To guarantee this property, the derived
data is only to be used for the intended purpose.</t>
</section>
<section title="Acknowledgements">
<t>The EXTERNAL-CHANNEL mechanism, and significant amount of text in
this document, is based on the EXTERNAL mechanism in Appendix A
of <xref target="RFC4422">SASL</xref>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3629.xml"?>
<?rfc include="reference.RFC.4234.xml"?>
<?rfc include="reference.RFC.4422.xml"?>
<?rfc include="reference.RFC.4648.xml"?>
<?rfc include="reference.RFC.5056.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2244.xml"?>
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.4346.xml"?>
<?rfc include="reference.RFC.5054.xml"?>
<?rfc include="reference.RFC.5081.xml"?>
<reference anchor="MITM">
<front>
<title>Man-in-the-Middle in Tunneled Authentication</title>
<author initials="N." surname="Asokan" fullname="N. Asokan">
</author>
<author initials="V." surname="Niemi" fullname="V. Niemi">
</author>
<author initials="K." surname="Nyberg" fullname="K. Nyberg">
</author>
</front>
<seriesInfo name="WWW"
value="http://www.saunalahti.fi/~asokan/research/mitm.html" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:37:37 |