    Internet Engineering Task Force (IETF)                          M. Brown
    Request for Comments: 5878                             RedPhone Security
    Updates: 5246                                                 R. Housley
    Category: Experimental                                    Vigil Security
    ISSN: 2070-1721                                                 May 2010

            Transport Layer Security (TLS) Authorization Extensions

    Abstract

       This document specifies authorization extensions to the Transport
       Layer Security (TLS) Handshake Protocol.  Extensions are carried in
       the client and server hello messages to confirm that both parties
       support the desired authorization data types.  Then, if supported by
       both the client and the server, authorization information, such as
       attribute certificates (ACs) or Security Assertion Markup Language
       (SAML) assertions, is exchanged in the supplemental data handshake
       message.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for examination, experimental implementation, and
       evaluation.

       This document defines an Experimental Protocol for the Internet
       community.  This document is a product of the Internet Engineering
       Task Force (IETF).  It represents the consensus of the IETF
       community.  It has received public review and has been approved for
       publication by the Internet Engineering Steering Group (IESG).  Not
       all documents approved by the IESG are a candidate for any level of
       Internet Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc5878.

    Copyright Notice

       Copyright (c) 2010 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
       (http://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect

    Brown & Housley               Experimental                      [Page 1]

    RFC 5878              TLS Authorization Extensions              May 2010

       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

    1.  Introduction

       The Transport Layer Security (TLS) protocol ([TLS1.0], [TLS1.1],
       [TLS1.2]) is being used in an increasing variety of operational
       environments, including ones that were not envisioned at the time of
       the original design for TLS.  The extensions introduced in this
       document are designed to enable TLS to operate in environments where
       authorization information needs to be exchanged between the client
       and the server before any protected data is exchanged.  The use of
       these TLS authorization extensions is especially attractive when more
       than one application protocol can make use of the same authorization
       information.

       The format and content of the authorization information carried in
       these extensions are extensible.  This document references Security
       Assertion Markup Language (SAML) assertion ([SAML1.1], [SAML2.0]) and
       X.509 attribute certificate (AC) [ATTRCERT] authorization formats,
       but other formats can be used.  Future authorization extensions may
       include any opaque assertion that is digitally signed by a trusted
       issuer.  Recognizing the similarity to certification path validation,
       this document recommends the use of TLS Alert messages related to
       certificate processing to report authorization information processing
       failures.

       Straightforward binding of identification, authentication, and
       authorization information to an encrypted session is possible when
       all of these are handled within TLS.  If each application requires
       unique authorization information, then it might best be carried
       within the TLS-protected application protocol.  However, care must be
       taken to ensure appropriate bindings when identification,
       authentication, and authorization information are handled at
       different protocol layers.

       This document describes authorization extensions for the TLS
       Handshake Protocol in TLS 1.0, TLS 1.1, and TLS 1.2.  These
       extensions observe the conventions defined for TLS extensions that
       were originally defined in [TLSEXT1] and revised in [TLSEXT2]; TLS
       extensions are now part of TLS 1.2 [TLS1.2].  TLS extensions use
       general extension mechanisms for the client hello message and the

    Brown & Housley               Experimental                      [Page 2]

    RFC 5878              TLS Authorization Extensions              May 2010

       server hello message.  The extensions described in this document
       confirm that both the client and the server support the desired
       authorization data types.  Then, if supported, authorization
       information is exchanged in the supplemental data handshake message
       [TLSSUPP].

       The authorization extensions may be used in conjunction with TLS 1.0,
       TLS 1.1, and TLS 1.2.  The extensions are designed to be backwards
       compatible, meaning that the handshake protocol supplemental data
       messages will only contain authorization information of a particular
       type if the client indicates support for them in the client hello
       message and the server indicates support for them in the server hello
       message.

       Clients typically know the context of the TLS session that is being
       set up; thus, the client can use the authorization extensions when
       they are needed.  Servers must accept extended client hello messages,
       even if the server does not "understand" all of the listed
       extensions.  However, the server will not indicate support for these
       "not understood" extensions.  Then, clients may reject communications
       with servers that do not support the authorization extensions.

    1.1.  Conventions

       The syntax for the authorization messages is defined using the TLS
       Presentation Language, which is specified in Section 4 of [TLS1.0].

       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 RFC 2119 [STDWORDS].

    1.2.  Overview

       Figure 1 illustrates the placement of the authorization extensions
       and supplemental data messages in the full TLS handshake.

       The ClientHello message includes an indication of the client
       authorization data formats that are supported and an indication of
       the server authorization data formats that are supported.  The
       ServerHello message contains similar indications, but any
       authorization data formats that are not supported by the server are
       not included.  Both the client and the server MUST indicate support
       for the authorization data types.  If the list of mutually supported
       authorization data formats is empty, then the ServerHello message
       MUST NOT carry the affected extension at all.

       Successful session resumption uses the same authorization information
       as the original session.

    Brown & Housley               Experimental                      [Page 3]

    RFC 5878              TLS Authorization Extensions              May 2010

        Client                                                   Server

        ClientHello (w/ extensions) -------->

                                            ServerHello (w/ extensions)
                                                      SupplementalData*
                                                           Certificate*
                                                     ServerKeyExchange*
                                                    CertificateRequest*
                                    <--------           ServerHelloDone
        SupplementalData*
        Certificate*
        ClientKeyExchange
        CertificateVerify*
        [ChangeCipherSpec]
        Finished                    -------->
                                                     [ChangeCipherSpec]
                                    <--------                  Finished
        Application Data            <------->          Application Data

         *  Indicates optional or situation-dependent messages that
            are not always sent.

         [] Indicates that ChangeCipherSpec is an independent TLS
            protocol content type; it is not actually a TLS
            handshake message.

           Figure 1.  Authorization Data Exchange in Full TLS Handshake

    2.  Authorization Extension Types

       The general extension mechanisms enable clients and servers to
       negotiate whether to use specific extensions, and how to use specific
       extensions.  As specified in [TLS1.2], the extension format used in
       the extended client hello message and extended server hello message
       is repeated here for convenience:

          struct {
             ExtensionType extension_type;
             opaque extension_data<0..2^16-1>;
          } Extension;

       The extension_type identifies a particular extension type, and the
       extension_data contains information specific to the particular
       extension type.  This document specifies the use of two new extension
       types: client_authz and server_authz.  These extension types are
       described in Section 2.1 and Section 2.2, respectively.  This
       specification adds two new types to ExtensionType:

    Brown & Housley               Experimental                      [Page 4]

    RFC 5878              TLS Authorization Extensions              May 2010

          enum {
            client_authz(7), server_authz(8), (65535)
          } ExtensionType;

       The authorization extensions are relevant when a session is initiated
       and on any subsequent session resumption.  However, a client that
       requests resumption of a session does not know whether the server
       will have all of the context necessary to accept this request, and
       therefore the client SHOULD send an extended client hello message
       that includes the extension types associated with the authorization
       extensions.  This way, if the resumption request is denied, then the
       authorization extensions will be negotiated as normal.

       When a session is resumed, ClientHello is followed immediately by
       ChangeCipherSpec, which does not provide an opportunity for different
       authorization information can be exchanged.  Successful session
       resumption MUST use the same authorization information as the
       original session.

    2.1.  The client_authz Extension Type

       Clients MUST include the client_authz extension type in the extended
       client hello message to indicate their desire to send authorization
       data to the server.  The extension_data field indicates the format of
       the authorization data that will be sent in the supplemental data
       handshake message.  The syntax of the client_authz extension_data
       field is described in Section 2.3.

       Servers that receive an extended client hello message containing the
       client_authz extension MUST respond with the same client_authz
       extension in the extended server hello message if the server is
       willing to receive authorization data in the indicated format.  Any
       unacceptable formats must be removed from the list provided by the
       client.  The client_authz extension MUST be omitted from the extended
       server hello message if the server is not willing to receive
       authorization data in any of the indicated formats.

    2.2.  The server_authz Extension Type

       Clients MUST include the server_authz extension type in the extended
       client hello message to indicate their desire to receive
       authorization data from the server.  The extension_data field
       indicates the format of the authorization data that will be sent in
       the supplemental data handshake message.  The syntax of the
       server_authz extension_data field is described in Section 2.3.

    Brown & Housley               Experimental                      [Page 5]

    RFC 5878              TLS Authorization Extensions              May 2010

       Servers that receive an extended client hello message containing the
       server_authz extension MUST respond with the same server_authz
       extension in the extended server hello message if the server is
       willing to provide authorization data in the requested format.  Any
       unacceptable formats must be removed from the list provided by the
       client.  The server_authz extension MUST be omitted from the extended
       server hello message if the server is not able to provide
       authorization data in any of the indicated formats.

    2.3.  AuthzDataFormat Type

       The AuthzDataFormat type is used in both the client_authz and the
       server_authz extensions.  It indicates the format of the
       authorization data that will be transferred.  The AuthzDataFormats
       type definition is:

          enum {
             x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
             saml_assertion_url(3), (255)
          } AuthzDataFormat;

          AuthzDataFormats authz_format_list<1..2^8-1>;

       When the x509_attr_cert value is present, the authorization data is
       an X.509 attribute certificate (AC) that conforms to the profile in
       RFC 5755 [ATTRCERT].

       When the saml_assertion value is present, the authorization data is
       an assertion composed using the Security Assertion Markup Language
       (SAML) ([SAML1.1], [SAML2.0]).

       When the x509_attr_cert_url value is present, the authorization data
       is an X.509 AC that conforms to the profile in RFC 5755 [ATTRCERT];
       however, the AC is fetched with the supplied URL.  A one-way hash
       value is provided to ensure that the intended AC is obtained.

       When the saml_assertion_url value is present, the authorization data
       is a SAML assertion; however, the SAML assertion is fetched with the
       supplied URL.  A one-way hash value is provided to ensure that the
       intended SAML assertion is obtained.

       Implementations that support either x509_attr_cert_url or
       saml_assertion_url MUST support URLs that employ the http scheme
       [HTTP].  These implementations MUST confirm that the hash value
       computed on the fetched authorization matches the one received in the
       handshake.  Mismatch of the hash values SHOULD be treated as though
       the authorization was not provided, which will result in a
       bad_certificate_hash_value alert (see Section 4).  Implementations

    Brown & Housley               Experimental                      [Page 6]

    RFC 5878              TLS Authorization Extensions              May 2010

       MUST deny access if the authorization cannot be obtained from the
       provided URL, by sending a certificate_unobtainable alert (see
       Section 4).

    3.  Supplemental Data Handshake Message Usage

       As shown in Figure 1, supplemental data can be exchanged in two
       places in the handshake protocol.  The client_authz extension
       determines what authorization data formats are acceptable for
       transfer from the client to the server, and the server_authz
       extension determines what authorization data formats are acceptable
       for transfer from the server to the client.  In both cases, the
       syntax specified in [TLSSUPP] is used along with the authz_data type
       defined in this document.

          enum {
             authz_data(16386), (65535)
          } SupplementalDataType;

          struct {
             SupplementalDataType supplemental_data_type;
             select(SupplementalDataType) {
                case authz_data:  AuthorizationData;
             }
          } SupplementalData;

    3.1.  Client Authorization Data

       The SupplementalData message sent from the client to the server
       contains authorization data associated with the TLS client.
       Following the principle of least privilege, the client ought to send
       the minimal set of authorization information necessary to accomplish
       the task at hand.  That is, only those authorizations that are
       expected to be required by the server in order to gain access to the
       needed server resources ought to be included.  The format of the
       authorization data depends on the format negotiated in the
       client_authz hello message extension.  The AuthorizationData
       structure is described in Section 3.3.

       In some systems, clients present authorization information to the
       server, and then the server provides new authorization information.
       This type of transaction is not supported by SupplementalData
       messages.  In cases where the client intends to request the TLS
       server to perform authorization translation or expansion services,
       such translation services ought to occur within the ApplicationData
       messages, and not within the TLS Handshake Protocol.

    Brown & Housley               Experimental                      [Page 7]

    RFC 5878              TLS Authorization Extensions              May 2010

    3.2.  Server Authorization Data

       The SupplementalData message sent from the server to the client
       contains authorization data associated with the TLS server.  This
       authorization information is expected to include statements about the
       server's qualifications, reputation, accreditation, and so on.
       Wherever possible, authorizations that can be misappropriated for
       fraudulent use ought to be avoided.  The format of the authorization
       data depends on the format negotiated in the server_authz hello
       message extensions.  The AuthorizationData structure is described in
       Section 3.3, and the following fictitious example of a single 5-octet
       SAML assertion illustrates its use:

          17             # Handshake.msg_type == supplemental_data(23)
          00 00 11       # Handshake.length = 17
          00 00 0e       # length of SupplementalData.supp_data = 14
          40 02          # SupplementalDataEntry.supp_data_type = 16386
          00 0a          # SupplementalDataEntry.supp_data_length = 10
          00 08          # length of AuthorizationData.authz_data_list = 8
          01             # authz_format = saml_assertion(1)
          00 05          # length of SAMLAssertion
          aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")

    3.3.  AuthorizationData Type

       The AuthorizationData structure carries authorization information for
       either the client or the server.  The AuthzDataFormat specified in
       Section 2.3 for use in the hello extensions is also used in this
       structure.

       All of the entries in the authz_data_list MUST employ authorization
       data formats that were negotiated in the relevant hello message
       extension.

       The HashAlgorithm type is taken from [TLS1.2], which allows
       additional one-way hash functions to be registered in the IANA TLS
       HashAlgorithm registry in the future.

    Brown & Housley               Experimental                      [Page 8]

    RFC 5878              TLS Authorization Extensions              May 2010

          struct{
             AuthorizationDataEntry authz_data_list<1..2^16-1>;
          } AuthorizationData;

          struct {
             AuthzDataFormat authz_format;
             select (AuthzDataFormat) {
                case x509_attr_cert:         X509AttrCert;
                case saml_assertion:         SAMLAssertion;
                case x509_attr_cert_url:     URLandHash;
                case saml_assertion_url:     URLandHash;
             }
          } AuthorizationDataEntry;

          enum {
             x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
             saml_assertion_url(3), (255)
          } AuthzDataFormat;

          opaque X509AttrCert<1..2^16-1>;

          opaque SAMLAssertion<1..2^16-1>;

          struct {
             opaque url<1..2^16-1>;
             HashAlgorithm hash_alg;
             select (hash_alg) {
                case md5:    MD5Hash;
                case sha1:   SHA1Hash;
                case sha224: SHA224Hash;
                case sha256: SHA256Hash;
                case sha384: SHA384Hash;
                case sha512: SHA512Hash;
             } hash;
          } URLandHash;

          enum {
             none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
             sha512(6), (255)
          } HashAlgorithm;

    Brown & Housley               Experimental                      [Page 9]

    RFC 5878              TLS Authorization Extensions              May 2010

          opaque MD5Hash[16];

          opaque SHA1Hash[20];

          opaque SHA224Hash[28];

          opaque SHA256Hash[32];

          opaque SHA384Hash[48];

          opaque SHA512Hash[64];

    3.3.1.  X.509 Attribute Certificate

       When X509AttrCert is used, the field contains an ASN.1 Distinguished
       Encoding Rules (DER)-encoded X.509 attribute certificate (AC) that
       follows the profile in RFC 5755 [ATTRCERT].  An AC is a structure
       similar to a public key certificate (PKC) [PKIX1]; the main
       difference is that the AC contains no public key.  An AC may contain
       attributes that specify group membership, role, security clearance,
       or other authorization information associated with the AC holder.

       When making an authorization decision based on an AC, proper linkage
       between the AC holder and the public key certificate that is
       transferred in the TLS Certificate message is needed.  The AC holder
       field provides this linkage.  The holder field is a SEQUENCE allowing
       three different (optional) syntaxes: baseCertificateID, entityName,
       and objectDigestInfo.  In the TLS authorization context, the holder
       field MUST use either the baseCertificateID or entityName.  In the
       baseCertificateID case, the baseCertificateID field MUST match the
       issuer and serialNumber fields in the certificate.  In the entityName
       case, the entityName MUST be the same as the subject field in the
       certificate or one of the subjectAltName extension values in the
       certificate.  Note that [PKIX1] mandates that the subjectAltName
       extension be present if the subject field contains an empty
       distinguished name.

    3.3.2.  SAML Assertion

       When SAMLAssertion is used, the field MUST contain well-formed XML
       [XML1.0] and MUST use either UTF-8 [UTF-8] or UTF-16 [UTF-16]
       character encoding.  UTF-8 is the preferred character encoding.  The
       XML text declaration MUST be followed by an <Assertion> element using
       the AssertionType complex type as defined in [SAML1.1] and [SAML2.0].
       The XML text MUST also follow the rules of [XML1.0] for including the
       Byte Order Mark (BOM) in encoded entities.  SAML is an XML-based
       framework for exchanging security information.  This security
       information is expressed in the form of assertions about subjects,

    Brown & Housley               Experimental                     [Page 10]

    RFC 5878              TLS Authorization Extensions              May 2010

       where a subject is either human or computer with an identity.  In
       this context, the SAML assertions are most likely to convey
       authentication or attribute statements to be used as input to
       authorization policy governing whether subjects are allowed to access
       certain resources.  Assertions are issued by SAML authorities.

       When making an authorization decision based on a SAML assertion,
       proper linkage between the SAML assertion and the public key
       certificate that is transferred in the TLS Certificate message may be
       needed.  A "Holder of Key" subject confirmation method in the SAML
       assertion can provide this linkage.  In other scenarios, it may be
       acceptable to use alternate confirmation methods that do not provide
       a strong binding, such as a bearer mechanism.  SAML assertion
       recipients MUST decide which subject confirmation methods are
       acceptable; such decisions MAY be specific to the SAML assertion
       contents and the TLS session context.

       There is no general requirement that the subject of the SAML
       assertion correspond directly to the subject of the certificate.
       They may represent the same or different entities.  When they are
       different, SAML also provides a mechanism by which the certificate
       subject can be identified separately from the subject in the SAML
       assertion subject confirmation method.

       Since the SAML assertion is being provided at a part of the TLS
       handshake that is unencrypted, an eavesdropper could replay the same
       SAML assertion when they establish their own TLS session.  This is
       especially important when a bearer mechanism is employed; the
       recipient of the SAML assertion assumes that the sender is an
       acceptable attesting entity for the SAML assertion.  Some constraints
       may be included to limit the context where the bearer mechanism will
       be accepted.  For example, the period of time that the SAML assertion
       can be short-lived (often minutes), the source address can be
       constrained, or the destination endpoint can be identified.  Also,
       bearer assertions are often checked against a cache of SAML assertion
       unique identifiers that were recently received, in order to detect
       replay.  This is an appropriate countermeasure if the bearer
       assertion is intended to be used just once.  Section 6 provides a way
       to protect authorization information when necessary.

    3.3.3.  URL and Hash

       Since the X.509 AC and SAML assertion can be large, alternatives
       provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML
       assertion.  To ensure that the intended object is obtained, a one-way
       hash value of the object is also included.  Integrity of this one-way
       hash value is provided by the TLS Finished message.

    Brown & Housley               Experimental                     [Page 11]

    RFC 5878              TLS Authorization Extensions              May 2010

       Implementations that support either x509_attr_cert_url or
       saml_assertion_url MUST support URLs that employ the HTTP scheme.
       Other schemes may also be supported.  When dereferencing these URLs,
       circular dependencies MUST be avoided.  Avoiding TLS when
       dereferencing these URLs is one way to avoid circular dependencies.
       Therefore, clients using the HTTP scheme MUST NOT use these TLS
       extensions if UPGRADE in HTTP [UPGRADE] is used.  For other schemes,
       similar care must be taken to avoid using these TLS extensions.

       Implementations that support either x509_attr_cert_url or
       saml_assertion_url MUST support both SHA-1 [SHS] and SHA-256 [SHS] as
       one-way hash functions.  Other one-way hash functions may also be
       supported.  Additional one-way hash functions can be added to the
       IANA TLS HashAlgorithm registry in the future.

       Implementations that support x509_attr_cert_url MUST support
       responses that employ the "application/pkix-attr-cert" Multipurpose
       Internet Mail Extension (MIME) media type as defined in [ACTYPE].

       Implementations that support saml_assertion_url MUST support
       responses that employ the "application/samlassertion+xml" MIME type
       as defined in Appendix A of [SAMLBIND].

       TLS authorizations SHOULD follow the additional guidance provided in
       Section 3.3 of [TLSEXT2] regarding client certificate URLs.

    4.  Alert Messages

       This document specifies the reuse of TLS Alert messages related to
       public key certificate processing for any errors that arise during
       authorization processing, while preserving the AlertLevels as
       authoritatively defined in [TLS1.2] or [TLSEXT2].  All alerts used in
       authorization processing are fatal.

       The following updated definitions for the Alert messages are used to
       describe errors that arise while processing authorizations.  For ease
       of comparison, we reproduce the Alert message definition from
       Section 7.2 of [TLS1.2], augmented with two values defined in
       [TLSEXT2]:

    Brown & Housley               Experimental                     [Page 12]

    RFC 5878              TLS Authorization Extensions              May 2010

          enum { warning(1), fatal(2), (255) } AlertLevel;

          enum {
              close_notify(0),
              unexpected_message(10),
              bad_record_mac(20),
              decryption_failed_RESERVED(21),
              record_overflow(22),
              decompression_failure(30),
              handshake_failure(40),
              no_certificate_RESERVED(41),
              bad_certificate(42),
              unsupported_certificate(43),
              certificate_revoked(44),
              certificate_expired(45),
              certificate_unknown(46),
              illegal_parameter(47),
              unknown_ca(48),
              access_denied(49),
              decode_error(50),
              decrypt_error(51),
              export_restriction_RESERVED(60),
              protocol_version(70),
              insufficient_security(71),
              internal_error(80),
              user_canceled(90),
              no_renegotiation(100),
              unsupported_extension(110),
              certificate_unobtainable(111),
              bad_certificate_hash_value(114),
              (255)
          } AlertDescription;

          struct {
              AlertLevel level;
              AlertDescription description;
          } Alert;

       TLS processing of alerts includes some ambiguity because the message
       does not indicate which certificate in a certification path gave rise
       to the error.  This problem is made slightly worse in this extended
       use of alerts, as the alert could be the result of an error in
       processing of either a certificate or an authorization.
       Implementations that support these extensions should be aware of this
       imprecision.

    Brown & Housley               Experimental                     [Page 13]

    RFC 5878              TLS Authorization Extensions              May 2010

       The AlertDescription values are used as follows to report errors in
       authorizations processing:

          bad_certificate
             In certificate processing, bad_certificate indicates that a
             certificate was corrupt, contained signatures that did not
             verify correctly, and so on.  Similarly, in authorization
             processing, bad_certificate indicates that an authorization was
             corrupt, contained signatures that did not verify correctly,
             and so on.  In authorization processing, bad_certificate can
             also indicate that the handshake established that an
             AuthzDataFormat was to be provided, but no AuthorizationData of
             the expected format was provided in SupplementalData.

          unsupported_certificate
             In certificate processing, unsupported_certificate indicates
             that a certificate was of an unsupported type.  Similarly, in
             authorization processing, unsupported_certificate indicates
             that AuthorizationData uses a version or format unsupported by
             the implementation.

          certificate_revoked
             In certificate processing, certificate_revoked indicates that a
             certificate was revoked by its issuer.  Similarly, in
             authorization processing, certificate_revoked indicates that
             authorization was revoked by its issuer, or a certificate that
             was needed to validate the signature on the authorization was
             revoked by its issuer.

          certificate_expired
             In certificate processing, certificate_expired indicates that a
             certificate has expired or is not currently valid.  Similarly,
             in authorization processing, certificate_expired indicates that
             an authorization has expired or is not currently valid.

          certificate_unknown
             In certificate processing, certificate_unknown indicates that
             some other (unspecified) issue arose while processing the
             certificate, rendering it unacceptable.  Similarly, in
             authorization processing, certificate_unknown indicates that
             processing of AuthorizationData failed because of other
             (unspecified) issues, including AuthzDataFormat parse errors.

          unknown_ca
             In certificate processing, unknown_ca indicates that a valid
             certification path or partial certification path was received,
             but the certificate was not accepted because the certification
             authority (CA) certificate could not be located or could not be

    Brown & Housley               Experimental                     [Page 14]

    RFC 5878              TLS Authorization Extensions              May 2010

             matched with a known, trusted CA.  Similarly, in authorization
             processing, unknown_ca indicates that the authorization issuer
             is not known and trusted.

          access_denied
             In certificate processing, access_denied indicates that a valid
             certificate was received, but when access control was applied,
             the sender decided not to proceed with negotiation.  Similarly,
             in authorization processing, access_denied indicates that the
             authorization was not sufficient to grant access.

          certificate_unobtainable
             The client_certificate_url extension defined in RFC 4366
             [TLSEXT2] specifies that download errors lead to a
             certificate_unobtainable alert.  Similarly, in authorization
             processing, certificate_unobtainable indicates that a URL does
             not result in an authorization.  While certificate processing
             does not require this alert to be fatal, this is a fatal alert
             in authorization processing.

          bad_certificate_hash_value
             In certificate processing, bad_certificate_hash_value indicates
             that a downloaded certificate does not match the expected hash.
             Similarly, in authorization processing,
             bad_certificate_hash_value indicates that a downloaded
             authorization does not match the expected hash.

    5.  IANA Considerations

       This document defines two TLS extensions: client_authz(7) and
       server_authz(8).  These extension type values are assigned from the
       TLS Extension Type registry defined in [TLSEXT2].

       This document defines one TLS supplemental data type:
       authz_data(16386).  This supplemental data type is assigned from the
       TLS Supplemental Data Type registry defined in [TLSSUPP].

       This document establishes a new registry, to be maintained by IANA,
       for TLS Authorization Data Formats.  The first four entries in the
       registry are x509_attr_cert(0), saml_assertion(1),
       x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
       Data Format identifiers with values in the inclusive range 0-63
       (decimal) are assigned via RFC 5226 [IANA] IETF Review.  Values from
       the inclusive range 64-223 (decimal) are assigned via RFC 5226
       Specification Required.  Values from the inclusive range 224-255
       (decimal) are reserved for RFC 5226 Private Use.

    Brown & Housley               Experimental                     [Page 15]

    RFC 5878              TLS Authorization Extensions              May 2010

    6.  Security Considerations

       A TLS server can support more than one application, and each
       application may include several features, each of which requires
       separate authorization checks.  This is the reason that more than one
       piece of authorization information can be provided.

       A TLS server that requires different authorization information for
       different applications or different application features may find
       that a client has provided sufficient authorization information to
       grant access to a subset of these offerings.  In this situation, the
       TLS Handshake Protocol will complete successfully; however, the
       server must ensure that the client will only be able to use the
       appropriate applications and application features.  That is, the TLS
       server must deny access to the applications and application features
       for which authorization has not been confirmed.

       In cases where the authorization information itself is sensitive, the
       double handshake technique can be used to provide protection for the
       authorization information.  Figure 2 illustrates the double
       handshake, where the initial handshake does not include any
       authorization extensions, but it does result in protected
       communications.  Then, a second handshake that includes the
       authorization information is performed using the protected
       communications.  In Figure 2, the number on the right side indicates
       the amount of protection for the TLS message on that line.  A zero
       (0) indicates that there is no communication protection; a one (1)
       indicates that protection is provided by the first TLS session; and a
       two (2) indicates that protection is provided by both TLS sessions.

       The placement of the SupplementalData message in the TLS handshake
       results in the server providing its authorization information before
       the client is authenticated.  In many situations, servers will not
       want to provide authorization information until the client is
       authenticated.  The double handshake illustrated in Figure 2 provides
       a technique to ensure that the parties are mutually authenticated
       before either party provides authorization information.

       The use of bearer SAML assertions allows an eavesdropper or a man-in-
       the-middle to capture the SAML assertion and try to reuse it in
       another context.  The constraints discussed in Section 3.3.2 might be
       effective against an eavesdropper, but they are less likely to be
       effective against a man-in-the-middle.  Authentication of both
       parties in the TLS session, which involves the use of client
       authentication, will prevent an undetected man-in-the-middle, and the
       use of the double handshake illustrated in Figure 2 will prevent the
       disclosure of the bearer SAML assertion to any party other than the
       TLS peer.

    Brown & Housley               Experimental                     [Page 16]

    RFC 5878              TLS Authorization Extensions              May 2010

       AuthzDataFormats that point to authorization data, such as
       x509_attr_cert_url and saml_assertion_url, rather than simply
       including the authorization data in the handshake, may be exploited
       by an attacker.  Implementations that accept pointers to
       authorization data SHOULD adopt a policy of least privilege that
       limits the acceptable references that they will attempt to use.  For
       more information, see Section 6.3 of [TLSEXT2].

        Client                                                   Server

        ClientHello (no extensions) -------->                            |0
                                            ServerHello (no extensions)  |0
                                                           Certificate*  |0
                                                     ServerKeyExchange*  |0
                                                    CertificateRequest*  |0
                                    <--------           ServerHelloDone  |0
        Certificate*                                                     |0
        ClientKeyExchange                                                |0
        CertificateVerify*                                               |0
        [ChangeCipherSpec]                                               |0
        Finished                    -------->                            |1
                                                     [ChangeCipherSpec]  |0
                                    <--------                  Finished  |1
        ClientHello (w/ extensions) -------->                            |1
                                            ServerHello (w/ extensions)  |1
                                      SupplementalData (w/ authz data)*  |1
                                                           Certificate*  |1
                                                     ServerKeyExchange*  |1
                                                    CertificateRequest*  |1
                                    <--------           ServerHelloDone  |1
        SupplementalData (w/ authz data)*                                |1
        Certificate*                                                     |1
        ClientKeyExchange                                                |1
        CertificateVerify*                                               |1
        [ChangeCipherSpec]                                               |1
        Finished                    -------->                            |2
                                                     [ChangeCipherSpec]  |1
                                    <--------                  Finished  |2
        Application Data            <------->          Application Data  |2

             Figure 2.  Double Handshake To Protect Authorization Data

    7.  Acknowledgement

       The authors thank Scott Cantor for his assistance with the SAML
       assertion portion of the document.

    Brown & Housley               Experimental                     [Page 17]

    RFC 5878              TLS Authorization Extensions              May 2010

    8.  References

    8.1.  Normative References

       [ACTYPE]    Housley, R., "The application/pkix-attr-cert Media Type
                   for Attribute Certificates", RFC 5877, May 2010.

       [ATTRCERT]  Farrell, S., Housley, R., and S. Turner, "An Internet
                   Attribute Certificate Profile for Authorization",
                   RFC 5755, January 2010.

       [HTTP]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                   Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                   Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

       [IANA]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
                   IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                   May 2008.

       [PKIX1]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                   Housley, R., and W. Polk, "Internet X.509 Public Key
                   Infrastructure Certificate and Certificate Revocation
                   List (CRL) Profile", RFC 5280, May 2008.

       [SAML1.1]   OASIS Security Services Technical Committee, "Security
                   Assertion Markup Language (SAML) Version 1.1
                   Specification Set", September 2003.

       [SAML2.0]   OASIS Security Services Technical Committee, "Security
                   Assertion Markup Language (SAML) Version 2.0
                   Specification Set", March 2005.

       [SAMLBIND]  OASIS Security Services Technical Committee, "Bindings
                   for the OASIS Security Assertion Markup Language (SAML)
                   V2.0", March 2005.

       [SHS]       National Institute of Standards and Technology (NIST),
                   FIPS PUB 180-3, Secure Hash Standard (SHS), October 2008.

       [STDWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

       [TLS1.0]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
                   RFC 2246, January 1999.

       [TLS1.1]    Dierks, T. and E. Rescorla, "The Transport Layer Security
                   (TLS) Protocol Version 1.1", RFC 4346, April 2006.

    Brown & Housley               Experimental                     [Page 18]

    RFC 5878              TLS Authorization Extensions              May 2010

       [TLS1.2]    Dierks, T. and E. Rescorla, "The Transport Layer Security
                   (TLS) Protocol Version 1.2", RFC 5246, August 2008.

       [TLSEXT2]   Blake-Wilson, S., Nystrom, M., Hopwood, D.,
                   Mikkelsen, J., and T. Wright, "Transport Layer Security
                   (TLS) Extensions", RFC 4366, April 2006.

       [TLSSUPP]   Santesson, S., "TLS Handshake Message for Supplemental
                   Data", RFC 4680, October 2006.

       [UPGRADE]   Khare, R. and S. Lawrence, "Upgrading to TLS Within
                   HTTP/1.1", RFC 2817, May 2000.

       [UTF-8]     Yergeau, F., "UTF-8, a transformation format of
                   ISO 10646", STD 63, RFC 3629, November 2003.

       [UTF-16]    Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
                   ISO 10646", RFC 2781, February 2000.

       [XML1.0]    Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, and
                   F.  Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
                   Edition)", http://www.w3.org/TR/xml/, November 2008.

    8.2.  Informative References

       [TLSEXT1]   Blake-Wilson, S., Nystrom, M., Hopwood, D.,
                   Mikkelsen, J., and T. Wright, "Transport Layer Security
                   (TLS) Extensions", RFC 3546, June 2003.

    Authors' Addresses

       Mark Brown
       RedPhone Security
       1199 Falls View Court
       Mendota Heights, MN  55118
       USA
       EMail: mark@redphonesecurity.com

       Russell Housley
       Vigil Security, LLC
       918 Spring Knoll Drive
       Herndon, VA  20170
       USA
       EMail: housley@vigilsec.com

    Brown & Housley               Experimental                     [Page 19]