Add.

1 files changed, 896 insertions, 0 deletions

diff --git a/doc/protocol/draft-housley-tls-authz-extns-05.txt b/doc/protocol/draft-housley-tls-authz-extns-05.txt
new file mode 100644
index 0000000000..458445261f
--- /dev/null
+++ b/doc/protocol/draft-housley-tls-authz-extns-05.txt
@@ -0,0 +1,896 @@
+
+
+
+
+Internet-Draft                                                  M. Brown
+May 2006                                               RedPhone Security
+Expires: November 2006                                        R. Housley
+                                                          Vigil Security
+
+        Transport Layer Security (TLS) Authorization Extensions
+                 <draft-housley-tls-authz-extns-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 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]
+
+Internet-Draft                                                  May 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.
+
+   The use of these TLS authorization extensions is especially
+   attractive when more than one application protocol can make use of
+   the same authorization information.  Straightforward binding of
+   identification, authentication, and authorization information is
+   possible when all of these are handled within TLS.  If each
+   application requires unique authorization information, then it might
+   best be carried within the TLS-protected application protocol.
+   However, care must be taken to ensure appropriate bindings when
+   identification, authentication, and authorization information are
+   handled at different protocol layers.
+
+   This document describes authorization extensions for the TLS
+   Handshake Protocol in 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.
+
+
+
+
+
+
+Brown & Housley                                                 [Page 2]
+
+Internet-Draft                                                  May 2006
+
+
+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.
+
+    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
+
+
+
+Brown & Housley                                                 [Page 3]
+
+Internet-Draft                                                  May 2006
+
+
+   authorization data formats that are not supported by the server are
+   not included.  Both the client and the server MUST indicate support
+   for the authorization data types.  If the list of mutually supported
+   authorization data formats is empty, then the ServerHello message
+   MUST NOT carry the affected extension at all.
+
+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
+
+
+
+Brown & Housley                                                 [Page 4]
+
+Internet-Draft                                                  May 2006
+
+
+   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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley                                                 [Page 5]
+
+Internet-Draft                                                  May 2006
+
+
+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
+   AuthorizationDataFormats type definition is:
+
+      enum {
+         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
+         saml_assertion_url(3), keynote_assertion_list(4), (255)
+      } AuthzDataFormat;
+
+      AuthorizationDataFormats authz_format_list<1..2^8-1>;
+
+   When the x509_attr_cert value is present, the authorization data is
+   an X.509 Attribute Certificate (AC) that conforms to the profile in
+   RFC 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.
+
+   When the keynote_assertion_list value is present, the authorization
+   data is a list of KeyNote assertions that conforms to the profile in
+   RFC 2704 [KEYNOTE].
+
+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.
+
+
+
+
+
+Brown & Housley                                                 [Page 6]
+
+Internet-Draft                                                  May 2006
+
+
+      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
+   needed server resources ought to be included.  The format of the
+   authorization data depends on the format negotiated in the
+   client_authz hello message extension.  The AuthorizationData
+   structure is described in Section 3.3.
+
+   In some systems, clients present authorization information to the
+   server, and then the server provides new authorization information.
+   This type of transaction is not supported by SupplementalData
+   messages.  In cases where the client intends to request the TLS
+   server to perform authorization translation or expansion services,
+   such translation services ought to occur within the ApplicationData
+   messages, 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.
+
+
+
+
+
+
+
+
+Brown & Housley                                                 [Page 7]
+
+Internet-Draft                                                  May 2006
+
+
+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;
+
+      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;
+            case keynote_assertion_list: KeyNoteAssertionList;
+         }
+      } AuthorizationDataEntry;
+
+      enum {
+         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
+         saml_assertion_url(3), keynote_assertion_list(4), (255)
+      } AuthzDataFormat;
+
+      opaque X509AttrCert<1..2^16-1>;
+
+      opaque SAMLAssertion<1..2^16-1>;
+
+      opaque KeyNoteAssertionList<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;
+
+
+
+
+
+
+Brown & Housley                                                 [Page 8]
+
+Internet-Draft                                                  May 2006
+
+
+      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
+   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
+
+
+
+Brown & Housley                                                 [Page 9]
+
+Internet-Draft                                                  May 2006
+
+
+   needed.  A "Holder of Key" subject confirmation method in the SAML
+   assertion can provide this linkage.  In other scenarios, it may be
+   acceptable to use alternate confirmation methods that do not provide
+   a strong binding, such as a bearer mechanism.  SAML assertion
+   recipients MUST decide which subject confirmation methods are
+   acceptable; such decisions MAY be specific to the SAML assertion
+   contents and the TLS session context.
+
+   There is no general requirement that the subject of the SAML
+   assertion correspond directly to the subject of the certificate.
+   They may represent the same or different entities.  When they are
+   different, SAML also provides a mechanism by which the certificate
+   subject can be identified separately from the subject in the SAML
+   assertion subject confirmation method.
+
+   Since the SAML assertion is being provided at a part of the TLS
+   Handshake that is unencrypted, an eavesdropper could replay the same
+   SAML assertion when they establish their own TLS session.  This is
+   especially important when a bearer mechanism is employed, the
+   recipient of the SAML assertion assumes that the sender is an
+   acceptable attesting entity for the SAML assertion.  Some constraints
+   may be included to limit the context where the bearer mechanism will
+   be accepted.  For example, the period of time that the SAML assertion
+   can be short-lived (often minutes), the source address can be
+   constrained, or the destination endpoint can be identified.  Also,
+   bearer assertions are often checked against a cache of SAML assertion
+   unique identifiers that were recently received in order to detect
+   replay.  This is an appropriate countermeasure if the bearer
+   assertion is intended to be used just once.  Section 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
+
+
+
+Brown & Housley                                                [Page 10]
+
+Internet-Draft                                                  May 2006
+
+
+   supported.  Additional one-way hash functions can be registered in
+   the future using the procedures in section 3.
+
+3.3.4. KeyNote Assertion List
+
+   When KeyNoteAssertion List is used, the field contains an ASCII-
+   encoded list of signed KeyNote assertions, as described in RFC 2704
+   [KEYNOTE].  The assertions are separated by two '\n' (newline)
+   characters.  A KeyNote assertion is a structure similar to a public
+   key certificate; the main difference is that instead of a binding
+   between a name and a public key, KeyNote assertions bind public keys
+   to authorization rules that are evaluated by the peer when the sender
+   later issues specific requests.
+
+   When making an authorization decision based on a list of KeyNote
+   assertions, proper linkage between the KeyNote assertions and the
+   public key certificate that is transferred in the TLS Certificate
+   message is needed.  Receivers of a KeyNote assertion list should
+   initialize the ACTION_AUTHORIZER variable to be the sender's public
+   key, which was used to authenticate the TLS exchange.
+
+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 five entries in the
+   registry are x509_attr_cert(0), saml_assertion(1),
+   x509_attr_cert_url(2), saml_assertion_url(3), and
+   keynote_assertion_list(4).  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.
+
+   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
+
+
+
+Brown & Housley                                                [Page 11]
+
+Internet-Draft                                                  May 2006
+
+
+   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
+   before either party provides authorization information.
+
+6. Acknowledgement
+
+   The authors thank Scott Cantor for his assistance with the SAML
+   Assertion portion of the document and Angelos Keromytis for his
+   assistance with the KeyNote portion of the document.
+
+
+
+
+
+Brown & Housley                                                [Page 12]
+
+Internet-Draft                                                  May 2006
+
+
+    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
+
+
+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.
+
+   [KEYNOTE]    Blaze, M., Feigenbaum, J., Ioannidis, J., and
+                A. Keromytis, "The KeyNote Trust-Management System,
+                Version 2", RFC 2704, September 1999.
+
+
+
+Brown & Housley                                                [Page 13]
+
+Internet-Draft                                                  May 2006
+
+
+   [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 14]
+
+Internet-Draft                                                  May 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 15]
+
+Internet-Draft                                                  May 2006
+
+
+   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
+   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 16]