Add.

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]