diff options
author | Simon Josefsson <simon@josefsson.org> | 2006-03-24 08:52:36 +0000 |
---|---|---|
committer | Simon Josefsson <simon@josefsson.org> | 2006-03-24 08:52:36 +0000 |
commit | 9581062985fca571c666d983865baf5a278d9622 (patch) | |
tree | bf81a87e26985800ecff0b5fb7e036c8355aac06 /doc/protocol/draft-housley-tls-authz-extns-01.txt | |
parent | 9f21024aebaf395b3f58a281991618e5c12487b5 (diff) | |
download | gnutls-9581062985fca571c666d983865baf5a278d9622.tar.gz |
Add.
Diffstat (limited to 'doc/protocol/draft-housley-tls-authz-extns-01.txt')
-rw-r--r-- | doc/protocol/draft-housley-tls-authz-extns-01.txt | 672 |
1 files changed, 672 insertions, 0 deletions
diff --git a/doc/protocol/draft-housley-tls-authz-extns-01.txt b/doc/protocol/draft-housley-tls-authz-extns-01.txt new file mode 100644 index 0000000000..449a44c880 --- /dev/null +++ b/doc/protocol/draft-housley-tls-authz-extns-01.txt @@ -0,0 +1,672 @@ + + + + +Internet-Draft M. Brown +March 2006 RedPhone Security +Expires: September 2006 R. Housley + Vigil Security + + Transport Layer Security (TLS) Authorization Extensions + <draft-housley-tls-authz-extns-01.txt> + + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The Internet Society (2006). All Rights Reserved. + +Abstract + + This document specifies authorization extensions to the Transport + Layer Security (TLS) Handshake Protocol. Authorization information + is carried in the client and server hello messages. The syntax and + semantics of the authorization messages are described in detail. + + + + + + + + + +Brown & Housley [Page 1] + +Internet-Draft March 2006 + + +1. Introduction + + Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being + used in an increasing variety of operational environments, including + ones that were not envisioned when the original design criteria for + TLS were determined. The authorization 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. + + This document describes authorization extensions for the TLS + Handshake Protocol in both TLS 1.0 and TLS 1.1. These extensions + observe the conventions defined for TLS Extensions [TLSEXT] that make + use of the general extension mechanisms for the client hello message + and the server hello message. The extensions described in this + document allow TLS clients to provide to the TLS server authorization + information, and allow TLS server to provide to the TLS client + authorization information about the TLS server. + + The authorization extensions are intended for use with both TLS 1.0 + and TLS 1.1. The extensions are designed to be backwards compatible, + meaning that the authorization information carried in the client + hello message and the server hello message can be ignored by any + implementation that does not support the included authorization + information format. + + Clients typically know the context of the TLS session that is being + setup, thus the client can use of the authorization extensions when + needed. Servers must accept extended client hello messages, even if + the server does not "understand" the all of the listed extensions. + However, the server will not make use of the authorization + information if the authorization extension is not supported or the + authorization information is provided in an unsupported format. + +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]. + + + + + + + + + +Brown & Housley [Page 2] + +Internet-Draft March 2006 + + +1.2. Overview + + Figure 1 illustrates the placement of the authorization messages in + the full TLS handshake. + + Client Server + + ClientHello + (with AuthorizationData) --------> + ServerHello + (with AuthorizationData) + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + 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 Protocol message. + + Figure 1. AuthorizationData carried in ClientHello and ServerHello + + The ClientHello message includes the AuthorizationData extension, + which contains the authorization data for the client, and then the + ServerHello message includes the AuthorizationData extension, which + contains the authorization data for the server. If the server does + not support the AuthorizationData extension, or the server does not + support the authorization information format used by the client, then + the server MUST NOT include the AuthorizationData extension in the + ServerHello message. The Handshake Protocol continues, but without + the benefit of authorization information. + +2. AuthorizationData Extension + + The general extension mechanisms enable clients and servers to + negotiate the use of specific extensions. As specified in [TLSEXT], + the extension format used in the extended client hello message and + + + +Brown & Housley [Page 3] + +Internet-Draft March 2006 + + + extended server hello message is: + + 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. + + As specified in [TLSEXT], for all extension types, the extension type + MUST NOT appear in the extended server hello message unless the same + extension type appeared in the corresponding client hello message. + Clients MUST abort the handshake if they receive an extension type in + the extended server hello message that they did not request in the + associated extended client hello message. + + When multiple extensions of different types are present in the + extended client hello message or the extended server hello message, + the extensions can appear in any order, but there MUST NOT be more + than one extension of the same type. + + This document specifies the use of one new extension type: + authz_data. + + This specification adds one new type to ExtensionType: + + enum { + authz_data(TBD), (65535) + } ExtensionType; + + The authorization extension is relevant when a session is initiated, + regardless of the use of a full handshake or use of session + resumption. Clients MUST explicitly present AuthorizationData in + every client hello message for which authorization information is + desired. Upon receipt of a client hello message that requests + session resumption but which contains no acceptable + AuthorizationData, the TLS server MAY resume the session but it MUST + NOT grant authorization to the session being resumed based on any + prior session authorization. + + These requirements allow a series of resumed sessions to have + different authorizations from one another. More importantly, the + authorization information is always provided by the client in case + the server no longer honors the session resumption at the requested + authorization level. Repeated inclusion of the authorization + information allows the Handshake Protocol to proceed the same way for + + + +Brown & Housley [Page 4] + +Internet-Draft March 2006 + + + both resume and session origination. + +2.1. The authz_data Extension Type + + Clients MUST include the authz_data extension type in the extended + client hello message to send authorization data to the server. The + extension_data field contains the authorization data. Section 2.2 + specifies the authorization data formats that are supported. + + Servers that receive an extended client hello message containing the + authz_data extension MUST respond with the authz_data extension in + the extended server hello message if the server is willing to make + use of the received authorization data in the provided format. If + the server has any authorization information to send to the client, + then the server MUST include the information in the authz_data + extension type in the extended server hello message. + + The AuthorizationData structure is described in Section 2.3. + +2.2. AuthzDataFormat Type + + The AuthzDataFormat type is used in the authz_data extension. It + indicates the format of the authorization information that will be + transferred. The AuthzDataFormat type definition is: + + enum { + x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), + saml_assertion_url(3), (255) + } AuthzDataFormat; + + 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 3281 [ATTRCERT]. + + When the saml_assertion value is present, the authorization data is + an assertion composed using the Security Assertion Markup Language + (SAML) [SAML]. + + When the x509_attr_cert_url value is present, the authorization data + is an X.509 AC that conforms to the profile in RFC 3281 [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. + + + + +Brown & Housley [Page 5] + +Internet-Draft March 2006 + + + Additional formats can be registered in the future using the + procedures in section 3. + +2.3. AuthorizationData Type + + The AuthorizationData type is carried in the extension_data field for + the authz_data extension. When it appears in the extended client + hello message, it carries authorization information for the TLS + client. When it appears in the extended server hello message, it + carries authorization information for the TLS server. + + struct { + AuthorizationDataEntry authz_data_list<1..2^16-1>; + } AuthorizationData; + + struct { + AuthzDataFormat authz_format; + select (authz_format) { + case x509_attr_cert: X509AttrCert; + case saml_assertion: SAMLAssertion; + case x509_attr_cert_url: URLandHash; + case saml_assertion_url: URLandHash; + } authz_data_entry; + } AuthorizationDataEntry; + + opaque X509AttrCert<1..2^16-1>; + + opaque SAMLAssertion<1..2^16-1>; + + struct { + opaque url<1..2^16-1>; + HashType hash_type; + select (hash_type) { + case sha1: SHA1Hash; + case sha256: SHA256Hash; + } hash; + } URLandHash; + + enum { + sha1(0), sha256(1), (255) + } HashType; + + opaque SHA1Hash[20]; + + opaque SHA1Hash[32]; + + When X509AttrCert is used, the field contains an ASN.1 DER-encoded + X.509 Attribute Certificate (AC) that follows the profile in RFC 3281 + + + +Brown & Housley [Page 6] + +Internet-Draft March 2006 + + + [ATTRCERT]. An AC is a structure similar to a public key certificate + (PKC); the main difference being 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 SAMLAssertion is used, the field contains XML constructs with a + nested structure defined in [SAML]. SAML is an XML-based framework + for exchanging security information. This security information is + expressed in the form of assertions about subjects, where a subject + is either human or computer with an identity. In this context, the + assertions are most likely to convey authorization decisions about + whether subjects are allowed to access certain resources. Assertions + are issued by SAML authorities, namely, authentication authorities, + attribute authorities, and policy decision points. + + Since X509AttrCert and SAMLAssertion can lead to a significant + increase in the size of the hello messages, 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. + + 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; however, to avoid circular + dependencies, supported schemes SHOULD NOT themselves make use of + TLS, such as the https scheme. + + Implementations that support either x509_attr_cert_url or + saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2] + as one-way hash functions. Other one-way hash functions may also be + supported. Additional one-way hash functions can be registered in + the future using the procedures in section 3. + +3. IANA Considerations + + IANA has assigned one TLS Extension Types: authz_data(TBD). + + IANA has established a registry for TLS Authorization Data Formats. + The first two entries in the registry are x509_attr_cert(0) and + saml_assertion(1). TLS Authorization Data Format identifiers with + values in the inclusive range 0-63 (decimal) are assigned via RFC + 2434 [IANA] Standards Action. Values from the inclusive range 64-223 + (decimal) are assigned via RFC 2434 Specification Required. Values + from the inclusive range 224-255 (decimal) are reserved for RFC 2434 + Private Use. + + + + +Brown & Housley [Page 7] + +Internet-Draft March 2006 + + + IANA has established a registry for TLS Hash Types. The first two + entries in the registry are sha1(0) and sha256(1). TLS Hash Type + identifiers with values in the inclusive range 0-158 (decimal) are + assigned via RFC 2434 [IANA] Standards Action. Values from the + inclusive range 159-223 (decimal) are assigned via RFC 2434 + Specification Required. Values from the inclusive range 224-255 + (decimal) are reserved for RFC 2434 Private Use. + +4. 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 many cases, the authorization information is itself 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 information, 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. + + + + + + + + + + + + + + +Brown & Housley [Page 8] + +Internet-Draft March 2006 + + + Client Server + + ClientHello |0 + (no AuthorizationData) --------> |0 + ServerHello |0 + (no AuthorizationData) |0 + Certificate* |0 + ServerKeyExchange* |0 + CertificateRequest* |0 + <-------- ServerHelloDone |0 + Certificate* |0 + ClientKeyExchange |0 + CertificateVerify* |0 + [ChangeCipherSpec] |0 + Finished --------> |1 + [ChangeCipherSpec] |0 + <-------- Finished |1 + ClientHello |1 + (with AuthorizationData) --------> |1 + ServerHello |1 + (with AuthorizationData) |1 + Certificate* |1 + ServerKeyExchange* |1 + CertificateRequest* |1 + <-------- ServerHelloDone |1 + Certificate* |1 + ClientKeyExchange |1 + CertificateVerify* |1 + [ChangeCipherSpec] |1 + Finished --------> |2 + [ChangeCipherSpec] |1 + <-------- Finished |2 + Application Data <-------> Application Data |2 + + Figure 2. Protection of Authorization Data (Two Full Handshakes) + + + + + + + + + + + + + + + + +Brown & Housley [Page 9] + +Internet-Draft March 2006 + + + Public key operations can be minimized by making the second handshake + a resumption. This is much more efficient in term of computation and + message exchanges. Figure 3 illustrates this more efficient double + handshake. + + + Client Server + + ClientHello |0 + (no AuthorizationData) --------> |0 + ServerHello |0 + (no AuthorizationData) |0 + Certificate* |0 + ServerKeyExchange* |0 + CertificateRequest* |0 + <-------- ServerHelloDone |0 + Certificate* |0 + ClientKeyExchange |0 + CertificateVerify* |0 + [ChangeCipherSpec] |0 + Finished --------> |1 + [ChangeCipherSpec] |0 + <-------- Finished |1 + ClientHello |1 + (with AuthorizationData) --------> |1 + ServerHello |1 + (with AuthorizationData) |1 + [ChangeCipherSpec] |1 + <-------- Finished |2 + [ChangeCipherSpec] |1 + Finished --------> |2 + Application Data <-------> Application Data |2 + + Figure 3. Protection of Authorization Data (Resumption) + + + + + + + + + + + + + + + + + +Brown & Housley [Page 10] + +Internet-Draft March 2006 + + +5. Normative References + + [ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute + Certificate Profile for Authorization", RFC 3281, + April 2002. + + [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", RFC 3434, + October 1998. + + [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, February 2006. + + [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) Extensions", + RFC 3546, June 2003. + + [SAML] Organization for the Advancement of Structured Information + Standards, "Security Assertion Markup Language (SAML), + version 1.1", September 2003. [Version 2.0 is out for + public comment; it will replace this reference if approved.] + + [SHA1] National Institute of Standards and Technology (NIST), + FIPS PUB 180-1, Secure Hash Standard, 17 April 1995. + + [SHA2] National Institute of Standards and Technology (NIST), + FIPS PUB 180-2: Secure Hash Standard, 1 August 2002. + + [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + + + +Brown & Housley [Page 11] + +Internet-Draft March 2006 + + +Author's Address + + Mark Brown + RedPhone Security + 2019 Palace Avenue + Saint Paul, MN 55105 + USA + mark <at> redphonesecurity <dot> com + + Russell Housley + Vigil Security, LLC + 918 Spring Knoll Drive + Herndon, VA 20170 + USA + housley <at> vigilsec <dot> com + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + +Brown & Housley [Page 12] |