--- /dev/null
+
+
+
+
+Internet-Draft M. Brown
+April 2006 RedPhone Security
+Expires: October 2006 R. Housley
+ Vigil Security
+
+ Transport Layer Security (TLS) Authorization Extensions
+ <draft-housley-tls-authz-extns-03.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. Extensions 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 is exchanged in the
+ supplemental data handshake message.
+
+
+
+
+
+
+
+Brown & Housley [Page 1]
+\f
+Internet-Draft April 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 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.
+
+ 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 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
+ and TLS 1.1. 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
+ setup, 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" the 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.
+
+
+
+Brown & Housley [Page 2]
+\f
+Internet-Draft April 2006
+
+
+ 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
+
+
+ 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
+ authentication 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley [Page 3]
+\f
+Internet-Draft April 2006
+
+
+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 [TLSEXT], 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.
+
+ 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 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:
+
+ enum {
+ client_authz(TBD), server_authz(TBD), (65535)
+ } ExtensionType;
+
+ The authorization extensions are relevant when a session is initiated
+ and 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.
+
+
+
+
+
+Brown & Housley [Page 4]
+\f
+Internet-Draft April 2006
+
+
+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 as described in Section 2.3.
+
+ 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 AuthzDataFormat
+ type definition is:
+
+ enum {
+ x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
+ saml_assertion_url(3), (255)
+ } AuthzDataFormat;
+
+
+
+
+Brown & Housley [Page 5]
+\f
+Internet-Draft April 2006
+
+
+ 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) [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 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.
+
+3. Supplemental Data Handshake Message Usage
+
+ As shown in Figure 1, supplemental data can be exchanges 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(TBD), (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
+
+
+
+Brown & Housley [Page 6]
+\f
+Internet-Draft April 2006
+
+
+ needed server resources ought to be included. The format of the
+ authentication 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, not within the TLS Handshake protocol.
+
+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.
+
+3.3. AuthorizationData Type
+
+ The AuthorizationData structure carried 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.
+
+ struct{
+ AuthorizationDataEntry authz_data_list<1..2^16-1>;
+ } AuthorizationData;
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley [Page 7]
+\f
+Internet-Draft April 2006
+
+
+ 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>;
+ 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 SHA256Hash[32];
+
+3.3.1. X.509 Attribute Certificate
+
+ When X509AttrCert is used, the field contains an ASN.1 DER-encoded
+ X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
+ [ATTRCERT]. An AC is a structure similar to a public key certificate
+ (PKC) [PKIX1]; 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 making an authorization decision based on an AC, proper linkage
+ between the AC holder and the public key certificate that is
+
+
+
+Brown & Housley [Page 8]
+\f
+Internet-Draft April 2006
+
+
+ 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 the either 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 contains XML constructs with a
+ nested structure defined in [SAML1.1][SAML2.0]. 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 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
+
+
+
+Brown & Housley [Page 9]
+\f
+Internet-Draft April 2006
+
+
+ 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 5 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.
+
+ 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.
+
+4. IANA Considerations
+
+ This document defines a two TLS extensions: client_authz(TBD) and
+ server_authz(TBD). These extension type values are assigned from the
+ TLS Extension Type registry defined in [TLSEXT].
+
+ This document defines one TLS supplemental data type:
+ authz_data(TBD). 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 2434 [IANA] Standards Action. Values
+ from the inclusive range 64-223 (decimal) are assigned via RFC 2434
+
+
+
+Brown & Housley [Page 10]
+\f
+Internet-Draft April 2006
+
+
+ Specification Required. Values from the inclusive range 224-255
+ (decimal) are reserved for RFC 2434 Private Use.
+
+ This document establishes a new registry, to be maintained by IANA,
+ 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.
+
+5. 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 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
+
+
+
+Brown & Housley [Page 11]
+\f
+Internet-Draft April 2006
+
+
+ before either party provides authorization information.
+
+6. Acknowledgement
+
+ The authors thank Scott Cantor for his assistance with the SAML
+ Assertion portion of the document.
+
+
+
+ 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
+
+
+
+
+
+
+
+
+
+Brown & Housley [Page 12]
+\f
+Internet-Draft April 2006
+
+
+7. 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.
+
+ [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [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.
+
+ [TLSSUPP] Santesson, S., " TLS Handshake Message for Supplemental
+ Data", work in progress: draft-santesson-tls-supp,
+ March 2006.
+
+ [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", March2005.
+
+ [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 13]
+\f
+Internet-Draft April 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.
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+
+
+
+Brown & Housley [Page 14]
+\f
+Internet-Draft April 2006
+
+
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley [Page 15]
--- /dev/null
+
+
+
+
+INTERNET-DRAFT S. Santesson (Microsoft)
+Updates: 2246, 4346 (once approved) A. Medvinsky (Microsoft)
+Intended Category: Standards track J. Ball (Microsoft)
+Expires October 2006 April 2006
+
+
+ TLS User Mapping Extension
+ <draft-santesson-tls-ume-05.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 a "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+Abstract
+
+ This document specifies a TLS extension that enables clients to send
+ generic user mapping data in a supplemental data handshake message
+ defined in RFC TBD. One such mapping is defined, the UpnDomainHint,
+ which may be used by a server to locate a user in a directory
+ database. Other mappings may be defined in other documents in the
+ future.
+
+ (NOTE TO RFC EDITOR: Replace "RFC TBD" with the RFC number assigned
+ to draft-santesson-tls-supp-00.txt)
+
+
+
+
+
+
+Santesson, et. all [Page 1]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+Table of Contents
+
+ 1 Introduction ................................................ 2
+ 2 User mapping extension ...................................... 3
+ 3 User mapping handshake exchange ............................. 4
+ 4 Message flow ................................................ 7
+ 5 Security Considerations ..................................... 8
+ 6 References .................................................. 9
+ 7 IANA Considerations ... ...................................... 9
+ Authors' Addresses ............................................. 10
+ Acknowledgements ............................................... 10
+ Disclaimer ..................................................... 11
+ Copyright Statement ............................................ 11
+
+1. Introduction
+
+ This specification defines a TLS extension and a payload for the
+ SupplementalData handshake message, defined in RFC TBD [N6], to
+ accommodate mapping of users to their user accounts when using TLS
+ client authentication as the authentication method.
+
+ The UPN (User Principal Name) is a name form defined by Microsoft
+ which specifies a user's entry in a directory in the form of
+ userName@domainName. Traditionally Microsoft has relied on such UPN
+ names to be present in the client certificate when logging on to a
+ domain account.
+
+ This has however several drawbacks since it prevents the use of
+ certificates with an absent UPN and also requires re-issuance of
+ certificates or issuance of multiple certificates to reflect account
+ changes or creation of new accounts.
+
+ The TLS extension defined in this document provide a significant
+ improvement to this situation as it allows a single certificate to be
+ mapped to one or more accounts of the user and does not require the
+ certificate to contain a UPN.
+
+ The new TLS extension (user_mapping) is sent in the client hello
+ message. Per convention defined in RFC 4366 [N4], the server places
+ the same extension (user_mapping) in the server hello message, to
+ inform the client that the server understands this extension. If the
+ server does not understand the extension, it will respond with a
+ server hello omitting this extension and the client will proceed as
+ normal, ignoring the extension, and not include the
+ UserMappingDataList data in the TLS handshake.
+
+ If the new extension is understood, the client will inject
+ UserMappingDataList data in the SupplementalData handshake message
+
+
+
+Santesson, et. all [Page 2]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+ prior to the Client's Certificate message. The server will then parse
+ this message, extracting the client's domain, and store it in the
+ context for use when mapping the certificate to the user's directory
+ account.
+
+ No other modifications to the protocol are required. The messages are
+ detailed in the following sections.
+
+
+1.1 Terminology
+
+ 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 [N1].
+
+ The syntax for the TLS User Mapping extension is defined using the
+ TLS Presentation Language, which is specified in Section 4 of [N2].
+
+1.2 Design considerations
+
+ The reason the mapping data itself is not placed in the extension
+ portion of the client hello is to prevent broadcasting this
+ information to servers that don't understand the extension.
+ Additionally, if mapping information were to be considered
+ confidential, the addition of a new user mapping message type could
+ allow the data to be encrypted using the server's public key.
+
+
+2 User mapping extension
+
+ A new extension type (user_mapping(TBD)) is added to the Extension
+ used in both the client hello and server hello messages. The
+ extension type is specified as follows.
+
+
+ enum {
+ user_mapping(TBD), (65535)
+ } ExtensionType;
+
+ The "extension_data" field of this extension SHALL contain
+ "UserMappingTypeList" with a list of supported hint types where:
+
+ struct {
+ UserMappingType user_mapping_types<1..2^8-1>
+ } UserMappingTypeList;
+
+ Enumeration of hint types (user_mapping_types) defined in this
+ document is provided in section 3.
+
+
+
+Santesson, et. all [Page 3]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+ The list of user_mapping_types included in a client hello SHALL
+ signal the hint types supported by the client. The list of
+ user_mapping_types included in the server hello SHALL signal the hint
+ types preferred by the server.
+
+ If none of the hint types listed by the client is supported by the
+ server, the server SHALL omit the user_mapping extension in the
+ server hello.
+
+ When the user_mapping extension is included in the server hello, the
+ list of hint types in "UserMappingTypeList" SHALL be either equal to,
+ or a subset of, the list provided by the client.
+
+3 User mapping handshake exchange
+
+ The underlying structure of the SupplementalData handshake message,
+ used to carry information defined in this section, is defined in RFC
+ TBD [N6].
+
+ A new SupplementalDataType [N6] is defined to accommodate
+ communication of generic user mapping data. See RFC 2246 (TLS 1.0)
+ [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
+
+ The information in this data type carries one or more unauthenticated
+ hints, UserMappingDataList, inserted by the client side. Upon receipt
+ and successful completion of the TLS handshake, the server MAY use
+ this hint to locate the user's account from which user information
+ and credentials MAY be retrieved to support authentication based on
+ the client certificate.
+
+ The hint defined in this specification (upn_domain_hint) specifies
+ two fields, user_principal_name and domain_name. The domain_name
+ field MAY be used when only domain information is needed, e.g. where
+ a user have accounts in multiple domains using the same username
+ name, where that user name is known from another source (e.g. from
+ the client certificate). When the user name is also needed, the
+ upn_domain_hint field MAY be used to indicate both username and
+ domain name. If both fields are present, then the server can make use
+ of whichever one it chooses.
+
+
+ struct {
+ SupplementalDataType supp_data_type;
+ select(SupplementalDataType) {
+ case user_mapping_data: UserMappingDataList;
+ }
+ } SupplementalDataEntry;
+
+
+
+
+Santesson, et. all [Page 4]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+ enum {
+ user_mapping_data(TBD), (65535)
+ } SupplementalDataType;
+
+
+ The user_mapping_data(TBD) enumeration results in a new supplemental
+ data type UserMappingDataList with the following structure:
+
+
+ enum {
+ upn_domain_hint(0), (255)
+ } UserMappingType;
+
+ struct {
+ opaque user_principal_name<0..2^16-1>;
+ opaque domain_name<0..2^16-1>;
+ } UpnDomainHint;
+
+ struct {
+ UserMappingType user_mapping_version
+ select(UserMappingType) {
+ case upn_domain_hint:
+ UpnDomainHint;
+ }
+ } UserMappingData;
+
+ struct{
+ UserMappingData user_mapping_data_list<1..2^16-1>;
+ }UserMappingDataList;
+
+
+ The user_principal_name parameter, when specified, SHALL contain a
+ Unicode UPN, encoded as a UTF-8 string in the following form:
+
+ user@domain
+
+ For example the UPN 'foo@example.com' represents user 'foo' at domain
+ 'example.com'.
+
+ The user_principal_name field, when specified, SHALL be of the form
+ "user@domain", where "user" is a UTF-8 encoded Unicode string that
+ does not contain the "@" character, and "domain" is a domain name
+ meeting the requirements in the following paragraph.
+
+ The domain_name field, when specified, SHALL contain a domain name in
+ the usual text form: in other words, a sequence of one or more domain
+ labels separated by ".", each domain label starting and ending with
+ an alphanumeric character and possibly also containing "-"
+
+
+
+Santesson, et. all [Page 5]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+ characters. This field is an "IDN-unaware domain name slot" as
+ defined in RFC 3490 [N7] and therefore, domain names containing non-
+ ASCII characters have to be processed as described in RFC 3490 before
+ being stored in this field.
+
+ The UpnDomainHint MUST at least contain a non empty
+ user_principal_name or a non empty domain_name. The UpnDomainHint MAY
+ contain both user_principal_name and domain_name.
+
+ The UserMappingData structure contains a single mapping of type
+ UserMappingType. This structure can be leveraged to define new types
+ of user mapping hints in the future. The UserMappingDataList MAY
+ carry multiple hints; it is defined as a vector of UserMappingData
+ structures.
+
+ No preference is given to the order in which hints are specified in
+ this vector. If the client sends more then one hint then the Server
+ SHOULD use the applicable mapping supported by the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all [Page 6]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+4 Message flow
+
+ In order to negotiate to send user mapping data to a server in
+ accordance with this specification, clients MUST include an extension
+ of type "user_mapping" in the (extended) client hello, which SHALL
+ contain a list of supported hint types.
+
+ Servers that receive an extended client hello containing a
+ "user_mapping" extension, MAY indicate that they are willing to
+ accept user mapping data by including an extension of type
+ "user_mapping" in the (extended) server hello, which SHALL contain a
+ list of preferred hint types.
+
+ After negotiation of the use of user mapping has been successfully
+ completed (by exchanging hello messages including "user_mapping"
+ extensions), clients MAY send a "SupplementalData" message containing
+ the "UserMappingDataList" before the "Certificate" message. The
+ message flow is illustrated in Fig. 1 below.
+
+ Client Server
+
+ ClientHello
+ /* with user_mapping ext */ -------->
+
+ ServerHello
+ /* with user-mapping ext */
+ Certificate*
+ ServerKeyExchange*
+ CertificateRequest*
+ <-------- ServerHelloDone
+
+ SupplementalData
+ /* with UserMappingDataList */
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ [ChangeCipherSpec]
+ Finished -------->
+ [ChangeCipherSpec]
+ <-------- Finished
+ Application Data <-------> Application Data
+
+ Fig. 1 - Message flow with user mapping data
+
+ * Indicates optional or situation-dependent messages that are not
+ always sent according to RFC 2246 [N2] and RFC 4346 [N3].
+
+
+
+
+
+Santesson, et. all [Page 7]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+5 Security Considerations
+
+ The UPN sent in the UserMappingDataList is unauthenticated data that
+ MUST NOT be treated as a trusted identifier. Authentication of the
+ user represented by that UPN MUST rely solely on validation of the
+ client certificate. One way to do this in the Microsoft environment
+ is to use the UPN to locate and extract a certificate of the claimed
+ user from the trusted directory and subsequently match this
+ certificate against the validated client certificate from the TLS
+ handshake.
+
+ As the client is the initiator of this TLS extension, it needs to
+ determine when it is appropriate to send the User Mapping
+ Information. It may not be prudent to broadcast this information to
+ just any server at any time, as it can reveal network infrastructure
+ the client and server are using.
+
+ To avoid superfluously sending this information, two techniques
+ SHOULD be used to control its dissemination.
+
+ - The client SHOULD only send the UserMappingDataList in the
+ supplemental data message if it is agreed upon in the hello
+ message exchange, preventing the information from being sent
+ to a server that doesn't understand the User Mapping Extension.
+
+ - The client SHOULD further only send this information if the
+ server belongs to a domain to which the client intends to
+ authenticate using the UPN as identifier.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all [Page 8]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+6 References
+
+ Normative references:
+
+ [N1] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+ [N3] T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
+ RFC 4346, January 2006.
+
+ [N4] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
+ T. Wright, "Transport Layer Security (TLS) Extensions",
+ RFC 4366, February 2006.
+
+ [N5] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [N6] S. Santesson, "TLS Handshake Message for Supplementary
+ Data", RFC TBD (currently: draft-santesson-tls-supp-00,
+ Date 2006.
+
+ [N7] P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
+ Domain Names in Applications (IDNA)", RFC 3490, March 2003
+
+ [N8] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", RFC 2434, October 1998
+
+
+7 IANA Considerations
+
+ IANA needs to take the following actions:
+
+ 1) Create an entry, user_mapping(TBD), in the existing registry for
+ ExtensionType (defined in RFC 4366 [N4]).
+
+ 2) Create an entry, user_mapping_data(TBD), in the new registry for
+ SupplementalDataType (defined in draft-santesson-tls-supp-00).
+
+ 3) Establish a registry for TLS UserMappingType values. The first
+ entry in the registry is upn_domain_hint(0). TLS UserMappingType
+ values in the inclusive range 0-63 (decimal) are assigned via RFC
+ 2434 [N8] 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.
+
+
+
+Santesson, et. all [Page 9]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+Authors' Addresses
+
+
+ Stefan Santesson
+ Microsoft
+ Finlandsgatan 30
+ 164 93 KISTA
+ Sweden
+
+ EMail: stefans(at)microsoft.com
+
+
+ Ari Medvinsky
+ Microsoft
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ USA
+
+ Email: arimed(at)microsoft.com
+
+
+ Joshua Ball
+ Microsoft
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ USA
+
+ Email: joshball(at)microsoft.com
+
+
+
+Acknowledgements
+
+ The authors extend a special thanks to Russ Housley, Eric Resocorla
+ and Paul Leach for their substantial contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all [Page 10]
+\f
+INTERNET DRAFT TLS User Mapping extension April 2006
+
+
+Disclaimer
+
+ 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.
+
+
+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.
+
+
+Expires October 2006
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Santesson, et. all [Page 11]
projects / thirdparty / gnutls.git / commitdiff
