RFC 5878
Transport Layer Security (TLS) Authorization Extensions
RFC 5878: Transport Layer Security (TLS) Authorization Extensions 🎀
Okay bestie, this is RFC 5878, and it's giving Experimental energy 🧪 Here's the title block tea ☕
- Number: RFC 5878 💖
- Authors: M. Brown of RedPhone Security and R. Housley of Vigil Security 👑
- Category: Experimental 🧪 (this is not a Standards Track spec, so it's for trying things out and reviewing them, not a final standard 🙈)
- Date: May 2010 📅
- ISSN: 2070-1721 ✨
- Updates: 5246 🔥
- Obsoletes: nothing listed in the header 🦋
Abstract 🌸
Okay so this doc is all about authorization extensions for the TLS Handshake Protocol 🔐 The extensions ride along in the client and server hello messages to confirm that both sides support the authorization data types they want. Then, if both the client and the server support it, the authorization info gets swapped in the supplemental data handshake message 💅 That info can be stuff like attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions. Iconic 😭
Status of This Memo ✨
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪
This document defines an Experimental Protocol for the Internet community 🌈 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🫶
Info about the current status of this document, any errata, and how to give feedback lives 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) as in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect 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 they're provided without warranty as described in the Simplified BSD License 📜
1. Introduction 🧚
So TLS ([TLS1.0], [TLS1.1], [TLS1.2]) is showing up in more and more environments, including ones nobody imagined when TLS was first designed 🌍 The extensions in this doc are built so TLS can work in places where authorization information has to be exchanged between the client and the server before any protected data gets sent 🔐 They're especially useful when more than one application protocol can use the same authorization info, which is very main character energy ✨
The format and content of the authorization info in these extensions is extensible 🦋 This doc references the SAML assertion formats ([SAML1.1], [SAML2.0]) and the X.509 attribute certificate (AC) format ([ATTRCERT]), but other formats can be used too. Future authorization extensions may include any opaque assertion that's digitally signed by a trusted issuer. Since this is kind of like certification path validation, the doc recommends using TLS Alert messages related to certificate processing to report authorization information processing failures 🚨
Binding identification, authentication, and authorization info to an encrypted session is pretty straightforward when all three are handled inside TLS 💅 If each application needs its own unique authorization info, it might be best to carry that inside the TLS-protected application protocol instead. Just be careful about bindings when identification, authentication, and authorization are handled at different protocol layers, because that's where things can get messy 😭
This document describes authorization extensions for the TLS Handshake Protocol in TLS 1.0, TLS 1.1, and TLS 1.2 🎀 These extensions follow the conventions for TLS extensions that were first defined in [TLSEXT1] and then 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 server hello message. The extensions in this doc confirm that both the client and the server support the authorization data types they want. Then, if supported, authorization info gets exchanged in the supplemental data handshake message [TLSSUPP] 🫶
The authorization extensions may be used with TLS 1.0, TLS 1.1, and TLS 1.2 🌈 They're designed to be backwards compatible, which means the supplemental data messages will only contain authorization info of a particular type if the client says it supports that type in the client hello message and the server says it supports that type in the server hello message 🙌
Clients usually know the context of the TLS session being set up, so they can use the authorization extensions when they're needed ✨ Servers must accept extended client hello messages, even if the server doesn't "understand" all of the listed extensions 🥺 However, the server won't indicate support for those "not understood" extensions. Then, clients may reject communications with servers that don't support the authorization extensions 🚫
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 shows where the authorization extensions and supplemental data messages sit in the 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 has similar indications, but any authorization data formats the server doesn't support are left out 🙈 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 🚫
Successful session resumption uses the same authorization information as the original session 🔁
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 Handshake2. Authorization Extension Types 🌟
The general extension mechanisms let clients and servers negotiate whether to use specific extensions, and how to use them 🤝 As specified in [TLS1.2], 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 info specific to that extension type 🎀 This document specifies two new extension types: client_authz and server_authz. They're described in Section 2.1 and Section 2.2, respectively. This specification adds two new types to ExtensionType:
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;The authorization extensions matter when a session is initiated and on any later session resumption 💫 But a client that asks to resume a session doesn't know whether the server has all the context it needs to accept that request. So the client SHOULD send an extended client hello message that includes the extension types for the authorization extensions 🙏 That way, if the resumption request gets denied, the authorization extensions still get negotiated as normal 🔄
When a session is resumed, ClientHello is followed right away by ChangeCipherSpec. That doesn't leave any chance for different authorization information to be exchanged 😤 Successful session resumption MUST use the same authorization information as the original session 🔒
2.1. The client_authz Extension Type 🎀
Clients MUST include the client_authz extension type in the extended client hello message to say they want to send authorization data to the server 📨 The extension_data field shows 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, but only if the server is willing to receive authorization data in the indicated format 🫶 Any unacceptable formats must be removed from the list the client provided. The client_authz extension MUST be omitted from the extended server hello message if the server isn't willing to receive authorization data in any of the indicated formats 🚫
(part 2 coming next, bestie 🫶💅)
2.2. The server_authz Extension Type ✨
Okay bestie, so clients MUST include the server_authz extension type in the extended client hello message 💌 to say "yes pls, I want authorization data from the server." The extension_data field tells the server what format the authz data should come in when it's sent in the supplemental data handshake message. The syntax for that field is in Section 2.3 💅
Servers that get an extended client hello with server_authz MUST respond with the same server_authz extension in the extended server hello, but only if they're willing to provide authz data in the requested format 🫶 Any formats they can't do must be removed from the list the client sent. And if the server can't provide authz data in ANY of the indicated formats, the server_authz extension MUST be omitted from the extended server hello 😭
2.3. AuthzDataFormat Type 🎀
The AuthzDataFormat type is used in both the client_authz and the server_authz extensions 🦋 It tells everyone what format the authorization data is going to be in. Here's the AuthzDataFormats type definition:
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), (255)
} AuthzDataFormat;
AuthzDataFormats authz_format_list<1..2^8-1>;So when x509_attr_cert is present, the authorization data is an X.509 attribute certificate (AC) that follows the profile in RFC 5755 [ATTRCERT] 🌸
When saml_assertion is present, the authorization data is an assertion built with the Security Assertion Markup Language (SAML) ([SAML1.1], [SAML2.0]) 🧚
When x509_attr_cert_url is present, the authorization data is still an X.509 AC that follows the profile in RFC 5755 [ATTRCERT]. The difference is that the AC gets fetched from the URL you supply 🔗 A one-way hash value comes along too, so you can make sure you got the right AC 👑
When saml_assertion_url is present, the authorization data is a SAML assertion, but it gets fetched from the supplied URL instead. Same deal: a one-way hash value is included so the intended SAML assertion is the one that actually shows up 💜
Now the important part 🚨 Implementations that support either x509_attr_cert_url or saml_assertion_url MUST support URLs that use the http scheme [HTTP]. These implementations MUST confirm that the hash value computed on the fetched authorization matches the one received in the handshake. Mismatched hash values SHOULD be treated as though the authorization was not provided, which results in a bad_certificate_hash_value alert (see Section 4) 💀 And if the authorization can't be obtained from the provided URL, implementations MUST deny access by sending a certificate_unobtainable alert (see Section 4) 🙅♀️
3. Supplemental Data Handshake Message Usage 🌈
As shown in Figure 1, supplemental data can be exchanged in two places in the handshake protocol 🍓 The client_authz extension decides which authorization data formats are acceptable for transfer from the client to the server, and the server_authz extension decides which 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 🎀
enum {
authz_data(16386), (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 get the job done ✨ That means only the authorizations the server is expected to need in order to get into the server resources it's after should 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.
Sometimes, in some systems, clients show the server their authorization info and then the server hands back new authorization info. That kind of back-and-forth is not supported by SupplementalData messages 🙃 If the client wants the TLS server to do authorization translation or expansion services, those translation services ought to happen within the ApplicationData messages, not inside 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 info is expected to include statements about the server's qualifications, reputation, accreditation, and so on. Wherever possible, authorizations that could 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, and here's a fictitious example of a single 5-octet SAML assertion to show how it works:
17 # Handshake.msg_type == supplemental_data(23)
00 00 11 # Handshake.length = 17
00 00 0e # length of SupplementalData.supp_data = 14
40 02 # SupplementalDataEntry.supp_data_type = 16386
00 0a # SupplementalDataEntry.supp_data_length = 10
00 08 # length of AuthorizationData.authz_data_list = 8
01 # authz_format = saml_assertion(1)
00 05 # length of SAMLAssertion
aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa")3.3. AuthorizationData Type 💅
The AuthorizationData structure carries authorization information for either the client or the server 🫶 The AuthzDataFormat from Section 2.3, which is used in the hello extensions, is also used in this structure.
All of the entries in the authz_data_list MUST use authorization data formats that were negotiated in the relevant hello message extension. No freelancing, bestie 🙅♀️
The HashAlgorithm type comes from [TLS1.2], which means additional one-way hash functions can be registered in the IANA TLS HashAlgorithm registry in the future 🔮
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;
}
} AuthorizationDataEntry;
enum {
x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
saml_assertion_url(3), (255)
} AuthzDataFormat;
opaque X509AttrCert<1..2^16-1>;
opaque SAMLAssertion<1..2^16-1>;
struct {
opaque url<1..2^16-1>;
HashAlgorithm hash_alg;
select (hash_alg) {
case md5: MD5Hash;
case sha1: SHA1Hash;
case sha224: SHA224Hash;
case sha256: SHA256Hash;
case sha384: SHA384Hash;
case sha512: SHA512Hash;
} hash;
} URLandHash;
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
opaque MD5Hash[16];
opaque SHA1Hash[20];
opaque SHA224Hash[28];
opaque SHA256Hash[32];
opaque SHA384Hash[48];
opaque SHA512Hash[64];3.3.1. X.509 Attribute Certificate 🦢
When X509AttrCert is used, the field contains an ASN.1 Distinguished Encoding Rules (DER)-encoded X.509 attribute certificate (AC) that follows the profile in RFC 5755 [ATTRCERT] ✨ An AC is basically a structure similar to a public key certificate (PKC) [PKIX1], but the main difference is that the AC has no public key 🙈 An AC may contain attributes for group membership, role, security clearance, or other authorization info tied to the AC holder.
When you're making an authorization decision based on an AC, you need proper linkage between the AC holder and the public key certificate that's transferred in the TLS Certificate message 🔗 That's what the AC holder field is for. The holder field is a SEQUENCE that allows three different (optional) syntaxes: baseCertificateID, entityName, and objectDigestInfo. In the TLS authorization context, the holder field MUST use either the 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. Also note that [PKIX1] mandates that the subjectAltName extension be present if the subject field contains an empty distinguished name 👀
3.3.2. SAML Assertion 💖
okay so when SAMLAssertion is used, the field MUST contain well-formed XML [XML1.0] and MUST use either UTF-8 [UTF-8] or UTF-16 [UTF-16] character encoding. UTF-8 is the preferred one, bestie 🫶 The XML text declaration MUST be followed by an <Assertion> element using the AssertionType complex type as defined in [SAML1.1] and [SAML2.0]. The XML text MUST also follow the rules of [XML1.0] for including the Byte Order Mark (BOM) in encoded entities. 🧚
ngl SAML is giving serious "security info in XML" energy ✨ It's an XML-based framework for swapping security information. That info is written as assertions about subjects, and a subject is either a human or a computer with an identity. In this context, SAML assertions most likely carry authentication or attribute statements, which then feed into authorization policy that decides whether a subject gets to access certain resources. Assertions are issued by SAML authorities 👑
When you're making an authorization decision based on a SAML assertion, you may need a proper link between that assertion and the public key certificate that shows up in the TLS Certificate message 🔗 A "Holder of Key" subject confirmation method in the SAML assertion can give you that link. In other scenarios it may be acceptable to use other confirmation methods that don't give a strong binding, like a bearer mechanism 🦋 Either way, SAML assertion recipients MUST decide which subject confirmation methods are acceptable 💅 and those decisions MAY be specific to the SAML assertion contents and the TLS session context.
There's no general rule that the subject of the SAML assertion has to match the subject of the certificate. They can be the same entity or different ones 🌈 When they're different, SAML also has a way to identify the certificate subject separately from the subject in the subject confirmation method.
Now the spicy part 🙈 The SAML assertion gets sent during a part of the TLS handshake that isn't encrypted, so an eavesdropper could replay the same assertion when they set up their own TLS session. This is extra important with a bearer mechanism, because the recipient assumes the sender is an acceptable attesting entity for that assertion. You can limit where a bearer mechanism gets accepted. For example, the assertion can be short-lived (often minutes), the source address can be constrained, or the destination endpoint can be identified. Bearer assertions are also often checked against a cache of SAML assertion unique identifiers that were recently received, which helps detect replay. That's a solid countermeasure if the bearer assertion is only meant to be used once 🔥 Section 6 explains a way to protect authorization information when you need it.
3.3.3. URL and Hash 🎀
the X.509 AC and SAML assertion can be pretty big, so there's an alternative: you provide a URL where the ASN.1 DER-encoded X.509 AC or SAML assertion can be fetched 🌸 To make sure you get the exact object you meant, a one-way hash value of that object is included too. The TLS Finished message provides integrity for this one-way hash value 🔐
Implementations that support either x509_attr_cert_url or saml_assertion_url MUST support URLs that use the HTTP scheme. Other schemes may also be supported 🌍 When you dereference these URLs, circular dependencies MUST be avoided. One way to dodge circular dependencies is to avoid TLS when dereferencing these URLs. So clients using the HTTP scheme MUST NOT use these TLS extensions if UPGRADE in HTTP [UPGRADE] is used 🙅♀️ For other schemes, you have to take similar care to avoid using these TLS extensions.
Implementations that support either x509_attr_cert_url or saml_assertion_url MUST support both SHA-1 [SHS] and SHA-256 [SHS] as one-way hash functions. Other one-way hash functions may also be supported. More can be added to the IANA TLS HashAlgorithm registry later on ✨
Implementations that support x509_attr_cert_url MUST support responses that use the "application/pkix-attr-cert" Multipurpose Internet Mail Extension (MIME) media type as defined in [ACTYPE] 🍓
Implementations that support saml_assertion_url MUST support responses that use the "application/samlassertion+xml" MIME type as defined in Appendix A of [SAMLBIND] 💜
TLS authorizations SHOULD follow the extra guidance in Section 3.3 of [TLSEXT2] about client certificate URLs 🫶
4. Alert Messages ✨
okay so this section is about reusing TLS Alert messages that are normally for public key certificate processing, but now for any errors that pop up during authorization processing 💅 The AlertLevels stay exactly as they're authoritatively defined in [TLS1.2] or [TLSEXT2]. All alerts used in authorization processing are fatal, no cap 💀
Here are the updated Alert message definitions used to describe errors during authorization processing. For easy comparison, the Alert message definition from Section 7.2 of [TLS1.2] is reproduced below, augmented with two values defined in [TLSEXT2]:
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
certificate_unobtainable(111),
bad_certificate_hash_value(114),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;TLS alert processing is a little fuzzy 🙈 the message doesn't say which certificate in a certification path caused the error. This gets a bit messier with this extended use of alerts, because the alert could come from a problem with either a certificate or an authorization. Implementations that support these extensions should be aware of this imprecision 🌈
Here's how the AlertDescription values are used to report errors in authorization processing:
bad_certificate: In certificate processing, bad_certificate means a certificate was corrupt, had signatures that didn't verify correctly, and so on. In authorization processing, it means an authorization was corrupt, had signatures that didn't verify correctly, and so on. In authorization processing, bad_certificate can also mean the handshake established that an AuthzDataFormat was to be provided, but no AuthorizationData of the expected format was provided in SupplementalData.unsupported_certificate: In certificate processing, this means a certificate was of an unsupported type. In authorization processing, it means AuthorizationData uses a version or format the implementation doesn't support.certificate_revoked: In certificate processing, this means a certificate was revoked by its issuer. In authorization processing, it means the authorization was revoked by its issuer, or a certificate needed to validate the signature on the authorization was revoked by its issuer.certificate_expired: In certificate processing, this means a certificate has expired or isn't currently valid. In authorization processing, it means an authorization has expired or isn't currently valid.certificate_unknown: In certificate processing, this means some other (unspecified) issue came up while processing the certificate, making it unacceptable. In authorization processing, it means processing of AuthorizationData failed because of other (unspecified) issues, including AuthzDataFormat parse errors.unknown_ca: In certificate processing, this means a valid certification path or partial certification path was received, but the certificate wasn't accepted because the certification authority (CA) certificate couldn't be located or couldn't be matched with a known, trusted CA. In authorization processing, it means the authorization issuer isn't known and trusted.access_denied: In certificate processing, this means a valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. In authorization processing, it means the authorization wasn't sufficient to grant access.certificate_unobtainable: The client_certificate_url extension defined in RFC 4366 [TLSEXT2] specifies that download errors lead to a certificate_unobtainable alert. In authorization processing, certificate_unobtainable means a URL doesn't result in an authorization. Certificate processing doesn't require this alert to be fatal, but in authorization processing it IS fatal 😭bad_certificate_hash_value: In certificate processing, this means a downloaded certificate doesn't match the expected hash. In authorization processing, it means a downloaded authorization doesn't match the expected hash.
5. IANA Considerations 🌷
This document defines two TLS extensions: client_authz(7) and server_authz(8). These extension type values are assigned from the TLS Extension Type registry defined in [TLSEXT2] 🎀
This document defines one TLS supplemental data type: authz_data(16386). This supplemental data type is assigned from the TLS Supplemental Data Type registry defined in [TLSSUPP] 🧚
This document sets up a new registry, maintained by IANA, for TLS Authorization Data Formats 👑 The first four entries are x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), and saml_assertion_url(3). TLS Authorization Data Format identifiers in the inclusive range 0-63 (decimal) are assigned via RFC 5226 [IANA] IETF Review. Values in the inclusive range 64-223 (decimal) are assigned via RFC 5226 Specification Required. Values in the inclusive range 224-255 (decimal) are reserved for RFC 5226 Private Use 🦋
6. Security Considerations 🔒💅
okay bestie, this is the part where we get serious 😤 A TLS server can support more than one application, and each application might have several features. Every one of those needs its own authorization check 🎀 That's why more than one piece of authorization information can be provided ✨
A TLS server that needs different authorization info for different applications or features might notice that a client has given enough info to unlock some of the offerings 👀 In that case the TLS Handshake Protocol still completes successfully 🎉 BUT the server must make sure the client can only use the apps and features it's actually been approved for. So the server must deny access to any application or feature where authorization hasn't been confirmed 🚫 no exceptions, no sneaking in 💀
Now, if the authorization info is itself sensitive, the double handshake technique can protect it 🫶 Figure 2 shows the idea. The first handshake has no authorization extensions at all, but it still gives you protected communications 🔐 Then a second handshake carries the authorization info, and it happens over that already-protected channel 💜 In the figure, the number on the right tells you how much protection each TLS message has. A 0 means no protection, a 1 means the first TLS session protects it, and a 2 means both TLS sessions protect it 🌈
Here's the tea ☕ The SupplementalData message sits in the handshake in a way that means the server gives its authorization info before the client has been authenticated 😳 A lot of servers won't want to do that. They'll want to wait until the client is authenticated first. The double handshake in Figure 2 is the trick for making sure both parties are mutually authenticated before either one hands over authorization info 🤝 iconic behavior ✨
Bearer SAML assertions are a bit of a risk, ngl 😬 They let an eavesdropper or a man-in-the-middle grab the SAML assertion and try to reuse it somewhere else 🙈 The constraints from Section 3.3.2 might help against an eavesdropper, but they're less likely to stop a man-in-the-middle 😭 What does help: authenticating both parties in the TLS session (which means using client authentication) stops an undetected man-in-the-middle 🛡️ And the double handshake from Figure 2 keeps the bearer SAML assertion from being disclosed to anyone except the TLS peer 🔥
Also, AuthzDataFormats that point to authorization data, like x509_attr_cert_url and saml_assertion_url, instead of just including the data in the handshake, can be exploited by an attacker 👾 So implementations that accept pointers to authorization data SHOULD adopt a least-privilege policy that limits which references they'll try to use 💅 For more on this, check Section 6.3 of [TLSEXT2] 📖
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 |2Figure 2. Double Handshake To Protect Authorization Data 🎀
7. Acknowledgement 🌸
The authors thank Scott Cantor for his help with the SAML assertion part of the document 🫶 you're a legend, Scott 👑
8. References 📚
8.1. Normative References
[ACTYPE] Housley, R., "The application/pkix-attr-cert Media Type
for Attribute Certificates", RFC 5877, May 2010.
[ATTRCERT] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization",
RFC 5755, January 2010.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[PKIX1] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[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", March 2005.
[SAMLBIND] OASIS Security Services Technical Committee, "Bindings
for the OASIS Security Assertion Markup Language (SAML)
V2.0", March 2005.
[SHS] National Institute of Standards and Technology (NIST),
FIPS PUB 180-3, Secure Hash Standard (SHS), October 2008.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, April 2006.
[TLS1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLSEXT2] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
Mikkelsen, J., and T. Wright, "Transport Layer Security
(TLS) Extensions", RFC 4366, April 2006.
[TLSSUPP] Santesson, S., "TLS Handshake Message for Supplemental
Data", RFC 4680, October 2006.
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of
ISO 10646", RFC 2781, February 2000.
[XML1.0] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", http://www.w3.org/TR/xml/, November 2008.8.2. Informative References
[TLSEXT1] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
Mikkelsen, J., and T. Wright, "Transport Layer Security
(TLS) Extensions", RFC 3546, June 2003.Authors' Addresses 💌
Mark Brown
RedPhone Security
1199 Falls View Court
Mendota Heights, MN 55118
USA
EMail: mark@redphonesecurity.com
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.comAnd that's the whole spec, bestie 🌈✨ we did it 💖🦋
📦 where this page comes from
- ietf: rfc5878 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms