Transport Layer Security (TLS) Authorization Extensions
RFC 5878

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

Internet Engineering Task Force (IETF)                          M. Brown
Request for Comments: 5878                             RedPhone Security
Updates: 5246                                                 R. Housley
Category: Experimental                                    Vigil Security
ISSN: 2070-1721                                                 May 2010

        Transport Layer Security (TLS) Authorization Extensions

Abstract

   This document specifies authorization extensions to the Transport
   Layer Security (TLS) Handshake Protocol.  Extensions are 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, such as
   attribute certificates (ACs) or Security Assertion Markup Language
   (SAML) assertions, is exchanged in the supplemental data handshake
   message.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a candidate for any level of
   Internet Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5878.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Brown & Housley               Experimental                      [Page 1]
RFC 5878              TLS Authorization Extensions              May 2010

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   The Transport Layer Security (TLS) protocol ([TLS1.0], [TLS1.1],
   [TLS1.2]) 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.

   The format and content of the authorization information carried in
   these extensions are extensible.  This document references Security
   Assertion Markup Language (SAML) assertion ([SAML1.1], [SAML2.0]) and
   X.509 attribute certificate (AC) [ATTRCERT] authorization formats,
   but other formats can be used.  Future authorization extensions may
   include any opaque assertion that is digitally signed by a trusted
   issuer.  Recognizing the similarity to certification path validation,
   this document recommends the use of TLS Alert messages related to
   certificate processing to report authorization information processing
   failures.

   Straightforward binding of identification, authentication, and
   authorization information to an encrypted session 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 TLS 1.0, TLS 1.1, and TLS 1.2.  These
   extensions observe the conventions defined for TLS extensions that
   were originally defined in [TLSEXT1] and revised in [TLSEXT2]; TLS
   extensions are now part of TLS 1.2 [TLS1.2].  TLS extensions use
   general extension mechanisms for the client hello message and the

Brown & Housley               Experimental                      [Page 2]
RFC 5878              TLS Authorization Extensions              May 2010

   server hello message.  The extensions described in this document