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]