path: root/doc/protocol/draft-housley-tls-authz-extns-01.txt

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]