One document matched: draft-josefsson-sasl-external-channel-05.xml

<?xml version="1.0"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3629 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC4422 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY RFC5234 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5246 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5746 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml">

<!ENTITY RFC2244 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2244.xml">
<!ENTITY RFC4301 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC5054 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5054.xml">
<!ENTITY RFC6091 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6091.xml">
<!ENTITY RFC5226 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="std" ipr="pre5378Trust200902"
     docName="draft-josefsson-sasl-external-channel-05">

<front>

<title abbrev="EXTERNAL-*">
SASL Mechanism Family for External Authentication: EXTERNAL-*
</title>

<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
	<organization>SJD AB</organization>
	<address>
		<email>simon@josefsson.org</email>
	</address>
</author>
<author initials="C." surname="Latze" fullname="Carolin Latze">
	<organization>Swisscom</organization>
	<address>
		<email>carolin.latze@swisscom.com</email>
	</address>
</author>

	
<date month="July" year="2012"/>

<abstract>

  <t>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.</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="RFC5246">TLS</xref> or <xref target="RFC4301">IP
      Security</xref> services.</t>

  <t>The EXTERNAL mechanism requires some a priori 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.</t>

  <t>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.</t>

  <t>In the EXTERNAL-* mechanism family, the external channel is
    identified through the SASL mechanism name.</t>

  <t>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
    <xref target="RFC2119" />.</t>

</section>

<section title="Use Cases">

<t>Depending on the application, in addition to authenticating a user
it is also important to authenticate the device the user is logged in
to. Assuming that the user and the device ID consist of an X.509
certificate, on way to authenticate a user and a device is to
establish a secure tunnel based on the device's certificate. The user
certificate will then be used to authenticate the user within that
tunnel. Although this solution works nicely with today's
authentication protocols it comes with a certain complexity since it
requires a tunnel-in-tunnel setup. It would be better to end up with
only one secure tunnel while still being able to use both
certificates. Another point is that the authorization decision might
be based on both authentications. The user is only allowed to access
certain resources if it uses a certain machine.</t>

<t>One real world scenario of this use case the so called
bring-your-own-device (BYOD) initiatives. In BYOD, a company allows
employees to bring their own hardware to access the company's
infrastructure. This is risky since they still want to make sure that
only this employee can access the infrastructure. Therefore the
company could issue a device certificate for this device as well as a
user certificate for the employee in order to make sure that only this
employee can access the network with his device.</t>

<t>This scheme might be extended on even more than two identities.</t>

<t>The EXTERNAL-TLS mechanism provides means to implement this
scheme.</t>

</section>


<section title="Specification of EXTERNAL-* Mechanism Family">

  <t>The name of the mechanism family is "EXTERNAL-".</t>

  <t>The mechanism family does not provide a security layer.  It
    provides similar functionality by relying on an external
    channel.</t>

  <t>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.</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
    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="RFC5234">Augmented Backus-Naur Form (ABNF)</xref>
    notation.</t>

  <figure>
    <artwork type="abnf">
   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
    </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 external security channel to use is implied by the SASL
    mechanism name.  The channel has to be uniquely identifiable at
    both cliend and server side.  This means that mechanisms
    registered in this family MUST detail which channel should be
    chosen if there are layered channels of the same type.</t>

  <t>The exchange fails if</t>

  <t>- the client has not established its credentials via the
    indicated external channel,</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="Specification of EXTERNAL-TLS Mechanism">

    <t>The purpose of the EXTERNAL-TLS mechanism is to refer to the
    authentication completed by an already negotiated <xref
    target="RFC5246">TLS</xref> protocol.  This covers potentially
    both client and server authentication.  The typical scenario is
    that applications enable TLS protection of the application
    protocol using a STARTTLS-like functionality, performs whatever
    client and server authentication necessary within the TLS session,
    and then proceeds to the EXTERNAL-TLS mechanism negotiation.</t>

    <t>Usually the TLS channel will have only one TLS handshake, but
    multiple TLS handshakes (i.e., one initial TLS handshake followed
    by re-negotiations) MAY be used to establish multiple
    authentications.  Implementations MUST only use credentials
    established securely with the <xref target="RFC5746">TLS
    Renegotiation Extension</xref>.  The set of credentials relevant
    to EXTERNAL-TLS authentication starts with the inner-most TLS
    channel and includes each additional credential negotiated outside
    of the current TLS channel when that channel was negotiated using
    TLS Renegotiation Extension.</t>

    <t>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.  Only the credentials established by the
    application TLS handshake is relevant.</t>

    <t>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,
    <xref target="RFC6091">OpenPGP client key</xref>, or <xref
    target="RFC5054">SRP</xref>.  The client MUST only request the
    EXTERNAL-TLS if it wishes to re-use the TLS client credentials for
    the SASL application.</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 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.</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 multiple re-negotiated TLS handshakes, the server
could extract all successfully authenticated X.509 client certificates
from the TLS stack, hash them, concatenate them and look the
concatenation string up in the mapping table. The following shows an
example where a first TLS handshake has been negotiated to
authenticate the client's machine and the second re-negotiated TLS
handshake was used to authenticate the user.</t>

<figure>
  <artwork>
    da831005c2ae3b919d2fc512490a15036460b548\
    d2fc512490a15036460b5489401439d6da5407fa carolin@tux
  </artwork>
</figure>

  <t>When mapping from <xref target="RFC6091">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="Examples">

  <t>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
    <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-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.</t>

  <figure>
    <artwork>
      S: * ACAP (SASL "GSSAPI")
      C: a001 STARTTLS
      S: a001 OK "Begin TLS negotiation now"
      <TLS negotiation, further commands are under TLS layer>
      S: * ACAP (SASL "GSSAPI" "PLAIN" "EXTERNAL-TLS")
      C: a002 AUTHENTICATE "EXTERNAL-TLS"
      S: + ""
      C: + ""
      S: a002 OK "Authenticated"
      </artwork>
    </figure>

  <t>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.</t>

  <figure>
    <artwork>
      S: * ACAP (SASL "GSSAPI")
      C: a001 STARTTLS
      S: a001 OK "Begin TLS negotiation now"
      <TLS negotiation, further commands are under TLS layer>
      S: * ACAP (SASL "GSSAPI" "PLAIN" "EXTERNAL-TLS")
      C: a002 AUTHENTICATE "EXTERNAL-TLS" {5+}
      C: 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>

    <t>The third example shows use of EXTERNAL-TLS with multiple
    re-negotiated TLS handshakes.  The first TLS negotiation could
    have been authenticated with a device certificate, and the TLS
    re-negotiation could have been authenticated with a user
    certificate.  Furthermore, an authorization identity of
    "carolin@tux" is used.</t>


  <figure>
    <artwork>
      S: * ACAP (SASL "GSSAPI")
      C: a001 STARTTLS
      S: a001 OK "Begin TLS negotiation now"
      <TLS negotiation, further commands are under TLS layer>
      <TLS re-negotiation, further commands are under TLS layer>
      S: * ACAP (SASL "GSSAPI" "PLAIN" "EXTERNAL-TLS")
      C: a002 AUTHENTICATE "EXTERNAL-TLS"
      S: + ""
      C: + carolin@tux
      S: a002 OK "Authenticated"
      </artwork>
    </figure>



</section>

<section title="IANA Considerations">

  <t>The IANA is requested to add to the SASL mechanisms registry the
    following entry.</t>

    <figure>
      <artwork>
      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 <simon@josefsson.org>
      Intended usage: COMMON
      Owner/Change controller: Simon Josefsson <simon@josefsson.org>
      </artwork>
    </figure>

    <t>IANA will register new SASL mechanism names under the
      "EXTERNAL-" namespace on a First Come First Served basis, as
      defined in <xref target="RFC5226" />.  IANA has the right to
      reject obviously bogus registration requests, but will perform
      no review of claims made in the registration form.</t>

    <t>Registration of a SASL mechanism under the "EXTERNAL-"
      namespace is requested by filling in the same template used in
      <xref target="RFC4422" /> using a name prefixed with
      "EXTERNAL-".</t>

    <t>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.</t>

</section>

<section title="Security Considerations">

  <t>The security of external channel is critical to the security of
    this mechanism.  It is important that the client authentication
    provided by the security channel is securely bound to any
    confidentiality or integrity services that protects the security
    channel.</t>

  <t>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.</t>

</section>

<section title="Acknowledgements">

  <t>Significant amount of text in this document is copied
    from <xref target="RFC4422">SASL</xref>.</t>

  <t>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.</t>

    <t>Further fruitful discussions took place with Paul Sangster and
    Gloria Serrao.</t>

</section>

</middle>

<back>

<references title="Normative References">

  &RFC2119;
  &RFC3629;
  &RFC4422;
  &RFC5234;
  &RFC5246;
  &RFC5746;

</references>

<references title="Informative References">

  &RFC2244;
  &RFC4301;
  &RFC5054;
  &RFC6091;
  &RFC5226;

</references>

</back>

</rfc>