Transport Layer Security (TLS) Authorization Extensions
RFC 5878
Document | Type |
RFC - Experimental
(May 2010; Errata)
Updated by RFC 8447
Updates RFC 5246
Was draft-housley-tls-authz-extns (individual in sec area)
|
|
---|---|---|---|
Authors | Mark Brown , Russ Housley | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5878 (Experimental) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Tim Polk | ||
Send notices to | (None) |
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 documentShow full document text