idnits 2.17.1 draft-housley-tls-authz-extns-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 October 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SAML' is mentioned on line 67, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 770, but not defined -- Looks like a reference, but probably isn't: '16' on line 410 -- Looks like a reference, but probably isn't: '20' on line 412 -- Looks like a reference, but probably isn't: '28' on line 414 -- Looks like a reference, but probably isn't: '32' on line 416 -- Looks like a reference, but probably isn't: '48' on line 418 -- Looks like a reference, but probably isn't: '64' on line 420 ** Obsolete normative reference: RFC 3281 (ref. 'ATTRCERT') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4366 (ref. 'TLSEXT2') (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 3546 (ref. 'TLSEXT1') (Obsoleted by RFC 4366) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Brown 3 Intended Status: Experimental RedPhone Security 4 Updates: 5246 (once approved) R. Housley 5 Vigil Security 6 Expires: 14 April 2010 14 October 2009 8 Transport Layer Security (TLS) Authorization Extensions 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 Abstract 44 This document specifies authorization extensions to the Transport 45 Layer Security (TLS) Handshake Protocol. Extensions carried in the 46 client and server hello messages to confirm that both parties support 47 the desired authorization data types. Then, if supported by both the 48 client and the server, authorization information, such as Attribute 49 Certificates or SAML Assertions, is exchanged in the supplemental 50 data handshake message. 52 1. Introduction 54 Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1][TLS1.2] is 55 being used in an increasing variety of operational environments, 56 including ones that were not envisioned at the time of the original 57 design for TLS. The extensions introduced in this document are 58 designed to enable TLS to operate in environments where authorization 59 information needs to be exchanged between the client and the server 60 before any protected data is exchanged. The use of these TLS 61 authorization extensions is especially attractive when more than one 62 application protocol can make use of the same authorization 63 information. 65 The format and content of the authorization information carried in 66 these extensions is extensible. This document references SAML 67 assertion [SAML] and X509 Attribute Certificate [ATTRCERT] 68 authorization formats, but other formats can be used. Future 69 authorization extensions may include any opaque assertion that is 70 digitally signed by a trusted issuer. Recognizing the similarity to 71 certification path validation, this document recommends the use of 72 TLS Alert messages related to certificate processing to report 73 authorization information processing failures. 75 Straightforward binding of identification, authentication, and 76 authorization information to an encrypted session is possible when 77 all of these are handled within TLS. If each application requires 78 unique authorization information, then it might best be carried 79 within the TLS-protected application protocol. However, care must be 80 taken to ensure appropriate bindings when identification, 81 authentication, and authorization information are handled at 82 different protocol layers. 84 This document describes authorization extensions for the TLS 85 Handshake Protocol in both TLS 1.0, TLS 1.1, and TLS 1.2. These 86 extensions observe the conventions defined for TLS Extensions that 87 were originally defined in [TLSEXT1] and revised in [TLSEXT2]; TLS 88 Extensions are now part of TLS 1.2 [TLS1.2]. TLS Extensions use 89 general extension mechanisms for the client hello message and the 90 server hello message. The extensions described in this document 91 confirm that both the client and the server support the desired 92 authorization data types. Then, if supported, authorization 93 information is exchanged in the supplemental data handshake message 94 [TLSSUPP]. 96 The authorization extensions may be used in conjunction with TLS 1.0, 97 TLS 1.1, and TLS 1.2. The extensions are designed to be backwards 98 compatible, meaning that the Handshake Protocol Supplemental Data 99 messages will only contain authorization information of a particular 100 type if the client indicates support for them in the client hello 101 message and the server indicates support for them in the server hello 102 message. 104 Clients typically know the context of the TLS session that is being 105 setup, thus the client can use the authorization extensions when they 106 are needed. Servers must accept extended client hello messages, even 107 if the server does not "understand" the all of the listed extensions. 108 However, the server will not indicate support for these "not 109 understood" extensions. Then, clients may reject communications with 110 servers that do not support the authorization extensions. 112 1.1. Conventions 114 The syntax for the authorization messages is defined using the TLS 115 Presentation Language, which is specified in Section 4 of [TLS1.0]. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [STDWORDS]. 121 1.2. Overview 123 Figure 1 illustrates the placement of the authorization extensions 124 and supplemental data messages in the full TLS handshake. 126 The ClientHello message includes an indication of the client 127 authorization data formats that are supported and an indication of 128 the server authorization data formats that are supported. The 129 ServerHello message contains similar indications, but any 130 authorization data formats that are not supported by the server are 131 not included. Both the client and the server MUST indicate support 132 for the authorization data types. If the list of mutually supported 133 authorization data formats is empty, then the ServerHello message 134 MUST NOT carry the affected extension at all. 136 Successful session resumption uses the same authorization information 137 as the original session. 139 Client Server 141 ClientHello (w/ extensions) --------> 143 ServerHello (w/ extensions) 144 SupplementalData* 145 Certificate* 146 ServerKeyExchange* 147 CertificateRequest* 148 <-------- ServerHelloDone 149 SupplementalData* 150 Certificate* 151 ClientKeyExchange 152 CertificateVerify* 153 [ChangeCipherSpec] 154 Finished --------> 155 [ChangeCipherSpec] 156 <-------- Finished 157 Application Data <-------> Application Data 159 * Indicates optional or situation-dependent messages that 160 are not always sent. 162 [] Indicates that ChangeCipherSpec is an independent TLS 163 Protocol content type; it is not actually a TLS 164 handshake message. 166 Figure 1. Authorization data exchange in full TLS handshake 168 2. Authorization Extension Types 170 The general extension mechanisms enable clients and servers to 171 negotiate whether to use specific extensions, and how to use specific 172 extensions. As specified in [TLS1.2], the extension format used in 173 the extended client hello message and extended server hello message 174 is repeated here for convenience: 176 struct { 177 ExtensionType extension_type; 178 opaque extension_data<0..2^16-1>; 179 } Extension; 181 The extension_type identifies a particular extension type, and the 182 extension_data contains information specific to the particular 183 extension type. This document specifies the use of two new extension 184 types: client_authz and server_authz. These extension types are 185 described in Section 2.1 and Section 2.2, respectively. This 186 specification adds two new types to ExtensionType: 188 enum { 189 client_authz(TBD), server_authz(TBD), (65535) 190 } ExtensionType; 192 The authorization extensions are relevant when a session is initiated 193 and any subsequent session resumption. However, a client that 194 requests resumption of a session does not know whether the server 195 will have all of the context necessary to accept this request, and 196 therefore the client SHOULD send an extended client hello message 197 that includes the extension types associated with the authorization 198 extensions. This way, if the resumption request is denied, then the 199 authorization extensions will be negotiated as normal. 201 When a session is resumed, ClientHello is followed immediately by 202 ChangeCipherSpec, which does not provide an opportunity for different 203 authorization information can be exchanged. Successful session 204 resumption MUST use the same authorization information as the 205 original session. 207 2.1. The client_authz Extension Type 209 Clients MUST include the client_authz extension type in the extended 210 client hello message to indicate their desire to send authorization 211 data to the server. The extension_data field indicates the format of 212 the authorization data that will be sent in the supplemental data 213 handshake message. The syntax of the client_authz extension_data 214 field is described in Section 2.3. 216 Servers that receive an extended client hello message containing the 217 client_authz extension MUST respond with the same client_authz 218 extension in the extended server hello message if the server is 219 willing to receive authorization data in the indicated format. Any 220 unacceptable formats must be removed from the list provided by the 221 client. The client_authz extension MUST be omitted from the extended 222 server hello message if the server is not willing to receive 223 authorization data in any of the indicated formats. 225 2.2. The server_authz Extension Type 227 Clients MUST include the server_authz extension type in the extended 228 client hello message to indicate their desire to receive 229 authorization data from the server. The extension_data field 230 indicates the format of the authorization data that will be sent in 231 the supplemental data handshake message. The syntax of the 232 server_authz extension_data field as described in Section 2.3. 234 Servers that receive an extended client hello message containing the 235 server_authz extension MUST respond with the same server_authz 236 extension in the extended server hello message if the server is 237 willing to provide authorization data in the requested format. Any 238 unacceptable formats must be removed from the list provided by the 239 client. The server_authz extension MUST be omitted from the extended 240 server hello message if the server is not able to provide 241 authorization data in any of the indicated formats. 243 2.3. AuthzDataFormat Type 245 The AuthzDataFormat type is used in both the client_authz and the 246 server_authz extensions. It indicates the format of the 247 authorization data that will be transferred. The AuthzDataFormats 248 type definition is: 250 enum { 251 x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), 252 saml_assertion_url(3), (255) 253 } AuthzDataFormat; 255 AuthzDataFormats authz_format_list<1..2^8-1>; 257 When the x509_attr_cert value is present, the authorization data is 258 an X.509 Attribute Certificate (AC) that conforms to the profile in 259 RFC 3281 [ATTRCERT]. 261 When the saml_assertion value is present, the authorization data is 262 an assertion composed using the Security Assertion Markup Language 263 (SAML) [SAML1.1][SAML2.0]. 265 When the x509_attr_cert_url value is present, the authorization data 266 is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT]; 267 however, the AC is fetched with the supplied URL. A one-way hash 268 value is provided to ensure that the intended AC is obtained. 270 When the saml_assertion_url value is present, the authorization data 271 is a SAML Assertion; however, the SAML Assertion is fetched with the 272 supplied URL. A one-way hash value is provided to ensure that the 273 intended SAML Assertion is obtained. 275 Implementations that support either x509_attr_cert_url or 276 saml_assertion_url MUST support URLs that employ the http scheme 277 [HTTP]. These implementations MUST confirm that the hash value 278 computed on the fetched authorization matches the one received in the 279 handshake. Mismatch of the hash values SHOULD be treated as though 280 the authorization was not provided, which will result in a 281 bad_certificate_hash_value alert (see Section 4). Implementations 282 MUST deny access if the authorization cannot be obtained from the 283 provided URL, sending certificate_unobtainable alert (see Section 4). 285 3. Supplemental Data Handshake Message Usage 287 As shown in Figure 1, supplemental data can be exchanges in two 288 places in the handshake protocol. The client_authz extension 289 determines what authorization data formats are acceptable for 290 transfer from the client to the server, and the server_authz 291 extension determines what authorization data formats are acceptable 292 for transfer from the server to the client. In both cases, the 293 syntax specified in [TLSSUPP] is used along with the authz_data type 294 defined in this document. 296 enum { 297 authz_data(TBD), (65535) 298 } SupplementalDataType; 300 struct { 301 SupplementalDataType supplemental_data_type; 302 select(SupplementalDataType) { 303 case authz_data: AuthorizationData; 304 } 305 } SupplementalData; 307 3.1. Client Authorization Data 309 The SupplementalData message sent from the client to the server 310 contains authorization data associated with the TLS client. 311 Following the principle of least privilege, the client ought to send 312 the minimal set of authorization information necessary to accomplish 313 the task at hand. That is, only those authorizations that are 314 expected to be required by the server in order to gain access to the 315 needed server resources ought to be included. The format of the 316 authorization data depends on the format negotiated in the 317 client_authz hello message extension. The AuthorizationData 318 structure is described in Section 3.3. 320 In some systems, clients present authorization information to the 321 server, and then the server provides new authorization information. 322 This type of transaction is not supported by SupplementalData 323 messages. In cases where the client intends to request the TLS 324 server to perform authorization translation or expansion services, 325 such translation services ought to occur within the ApplicationData 326 messages, not within the TLS Handshake protocol. 328 3.2. Server Authorization Data 330 The SupplementalData message sent from the server to the client 331 contains authorization data associated with the TLS server. This 332 authorization information is expected to include statements about the 333 server's qualifications, reputation, accreditation, and so on. 334 Wherever possible, authorizations that can be misappropriated for 335 fraudulent use ought to be avoided. The format of the authorization 336 data depends on the format negotiated in the server_authz hello 337 message extensions. The AuthorizationData structure is described in 338 Section 3.3, and the following fictitious example of a single 5-octet 339 SAML Assertion illustrates the use: 341 17 # Handshake.msg_type == supplemental_data(23) 342 00 00 11 # Handshake.length = 17 343 00 00 0e # length of SupplementalData.supp_data = 14 344 ?? ?? # SupplementalDataEntry.supp_data_type = TBD 345 00 0a # SupplementalDataEntry.supp_data_length = 10 346 00 08 # length of AuthorizationData.authz_data_list = 8 347 01 # authz_format = saml_assertion(1) 348 00 05 # length of SAMLAssertion 349 aa aa aa aa aa # SAML assertion (fictitious: "aa aa aa aa aa") 351 {{ RFC Editor: Please replace "TBD" with the value assigned by 352 IANA, and replace "?? ??" with the hexadecimal value assigned 353 for TBD. }} 355 3.3. AuthorizationData Type 357 The AuthorizationData structure carried authorization information for 358 either the client or the server. The AuthzDataFormat specified in 359 Section 2.3 for use in the hello extensions is also used in this 360 structure. 362 All of the entries in the authz_data_list MUST employ authorization 363 data formats that were negotiated in the relevant hello message 364 extension. 366 The HashAlgorithm type is taken from [TLS1.2], which allows 367 additional one-way hash functions to be registered in the IANA TLS 368 HashAlgorithm registry in the future. 370 struct{ 371 AuthorizationDataEntry authz_data_list<1..2^16-1>; 372 } AuthorizationData; 373 struct { 374 AuthzDataFormat authz_format; 375 select (AuthzDataFormat) { 376 case x509_attr_cert: X509AttrCert; 377 case saml_assertion: SAMLAssertion; 378 case x509_attr_cert_url: URLandHash; 379 case saml_assertion_url: URLandHash; 380 } 381 } AuthorizationDataEntry; 383 enum { 384 x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), 385 saml_assertion_url(3), (255) 386 } AuthzDataFormat; 388 opaque X509AttrCert<1..2^16-1>; 390 opaque SAMLAssertion<1..2^16-1>; 392 struct { 393 opaque url<1..2^16-1>; 394 HashAlgorithm hash_alg; 395 select (hash_alg) { 396 case md5: MD5Hash; 397 case sha1: SHA1Hash; 398 case sha224: SHA224Hash; 399 case sha256: SHA256Hash; 400 case sha384: SHA384Hash; 401 case sha512: SHA512Hash; 402 } hash; 403 } URLandHash; 405 enum { 406 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), 407 sha512(6), (255) 408 } HashAlgorithm; 410 opaque MD5Hash[16]; 412 opaque SHA1Hash[20]; 414 opaque SHA224Hash[28]; 416 opaque SHA256Hash[32]; 418 opaque SHA384Hash[48]; 420 opaque SHA512Hash[64]; 422 3.3.1. X.509 Attribute Certificate 424 When X509AttrCert is used, the field contains an ASN.1 DER-encoded 425 X.509 Attribute Certificate (AC) that follows the profile in RFC 3281 426 [ATTRCERT]. An AC is a structure similar to a public key certificate 427 (PKC) [PKIX1]; the main difference being that the AC contains no 428 public key. An AC may contain attributes that specify group 429 membership, role, security clearance, or other authorization 430 information associated with the AC holder. 432 When making an authorization decision based on an AC, proper linkage 433 between the AC holder and the public key certificate that is 434 transferred in the TLS Certificate message is needed. The AC holder 435 field provides this linkage. The holder field is a SEQUENCE allowing 436 three different (optional) syntaxes: baseCertificateID, entityName 437 and objectDigestInfo. In the TLS authorization context, the holder 438 field MUST use the either baseCertificateID or entityName. In the 439 baseCertificateID case, the baseCertificateID field MUST match the 440 issuer and serialNumber fields in the certificate. In the entityName 441 case, the entityName MUST be the same as the subject field in the 442 certificate or one of the subjectAltName extension values in the 443 certificate. Note that [PKIX1] mandates that the subjectAltName 444 extension be present if the subject field contains an empty 445 distinguished name. 447 3.3.2. SAML Assertion 449 When SAMLAssertion is used, the field MUST contain well-formed XML 450 [XML1.0] and MUST use either UTF-8 [UTF-8] or UTF-16 [UTF-16] 451 character encoding. UTF-8 is the preferred character encoding. The 452 XML text declaration MUST be followed by an element using 453 the AssertionType complex type as defined in [SAML1.1][SAML2.0]. The 454 XML text MUST also follow the rules of [XML1.0] for including the 455 Byte Order Mark (BOM) in encoded entities. SAML is an XML-based 456 framework for exchanging security information. This security 457 information is expressed in the form of assertions about subjects, 458 where a subject is either human or computer with an identity. In 459 this context, the SAML assertions are most likely to convey 460 authentication or attribute statements to be used as input to 461 authorization policy governing whether subjects are allowed to access 462 certain resources. Assertions are issued by SAML authorities. 464 When making an authorization decision based on a SAML assertion, 465 proper linkage between the SAML assertion and the public key 466 certificate that is transferred in the TLS Certificate message may be 467 needed. A "Holder of Key" subject confirmation method in the SAML 468 assertion can provide this linkage. In other scenarios, it may be 469 acceptable to use alternate confirmation methods that do not provide 470 a strong binding, such as a bearer mechanism. SAML assertion 471 recipients MUST decide which subject confirmation methods are 472 acceptable; such decisions MAY be specific to the SAML assertion 473 contents and the TLS session context. 475 There is no general requirement that the subject of the SAML 476 assertion correspond directly to the subject of the certificate. 477 They may represent the same or different entities. When they are 478 different, SAML also provides a mechanism by which the certificate 479 subject can be identified separately from the subject in the SAML 480 assertion subject confirmation method. 482 Since the SAML assertion is being provided at a part of the TLS 483 Handshake that is unencrypted, an eavesdropper could replay the same 484 SAML assertion when they establish their own TLS session. This is 485 especially important when a bearer mechanism is employed, the 486 recipient of the SAML assertion assumes that the sender is an 487 acceptable attesting entity for the SAML assertion. Some constraints 488 may be included to limit the context where the bearer mechanism will 489 be accepted. For example, the period of time that the SAML assertion 490 can be short-lived (often minutes), the source address can be 491 constrained, or the destination endpoint can be identified. Also, 492 bearer assertions are often checked against a cache of SAML assertion 493 unique identifiers that were recently received in order to detect 494 replay. This is an appropriate countermeasure if the bearer 495 assertion is intended to be used just once. Section 5 provides a way 496 to protect authorization information when necessary. 498 3.3.3. URL and Hash 500 Since the X.509 AC and SAML assertion can be large, alternatives 501 provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML 502 Assertion. To ensure that the intended object is obtained, a one-way 503 hash value of the object is also included. Integrity of this one-way 504 hash value is provided by the TLS Finished message. 506 Implementations that support either x509_attr_cert_url or 507 saml_assertion_url MUST support URLs that employ the http scheme. 508 Other schemes may also be supported. When dereferencing these URLs, 509 circular dependencies MUST be avoided. Avoiding TLS when 510 dereferencing these URLs is one way to avoid circular dependencies. 511 Therefore, clients using the HTTP scheme MUST NOT use these TLS 512 extensions if UPGRADE in HTTP [UPGRADE] is used. For other schemes, 513 similar care must be used to avoid using these TLS extensions. 515 Implementations that support either x509_attr_cert_url or 516 saml_assertion_url MUST support both SHA-1 [SHS] and SHA-256 [SHS] as 517 one-way hash functions. Other one-way hash functions may also be 518 supported. Additional one-way hash functions can be added to the 519 IANA TLS HashAlgorithm registry in the future. 521 Implementations that support x509_attr_cert_url MUST support 522 responses that employ the "application/pkix-attr-cert" Multipart 523 Internet Mail Extension (MIME) type as defined in [ACTYPE]. 525 Implementations that support saml_assertion_url MUST support 526 responses that employ the "application/samlassertion+xml" MIME type 527 as defined in Appendix A of [SAMLBIND]. 529 TLS Authorizations SHOULD follow the additional guidance provided in 530 Section 3.3 of [TLSEXT2] regarding client certificate URLs. 532 4. Alert Messages 534 This document specifies the reuse TLS Alert messages related to 535 public-key certificate processing for any errors that arise during 536 authorization processing, while preserving the AlertLevels as 537 authoritatively defined in [TLS1.2] or [TLSEXT2]. All Alerts used in 538 authorization processing are fatal. 540 The following updated definitions for the Alert messages are used to 541 describe errors that arise while processing authorizations. For ease 542 of comparison, we reproduce the Alert message definition from Section 543 7.2 of [TLS1.2], augmented with two values defined [TLSEXT2]: 545 enum { warning(1), fatal(2), (255) } AlertLevel; 547 enum { 548 close_notify(0), 549 unexpected_message(10), 550 bad_record_mac(20), 551 decryption_failed_RESERVED(21), 552 record_overflow(22), 553 decompression_failure(30), 554 handshake_failure(40), 555 no_certificate_RESERVED(41), 556 bad_certificate(42), 557 unsupported_certificate(43), 558 certificate_revoked(44), 559 certificate_expired(45), 560 certificate_unknown(46), 561 illegal_parameter(47), 562 unknown_ca(48), 563 access_denied(49), 564 decode_error(50), 565 decrypt_error(51), 566 export_restriction_RESERVED(60), 567 protocol_version(70), 568 insufficient_security(71), 569 internal_error(80), 570 user_canceled(90), 571 no_renegotiation(100), 572 unsupported_extension(110), 573 certificate_unobtainable(111), 574 bad_certificate_hash_value(114), 575 (255) 576 } AlertDescription; 578 struct { 579 AlertLevel level; 580 AlertDescription description; 581 } Alert; 583 TLS processing of alerts includes some ambiguity because the message 584 does not indicate which certificate in a certification path gave rise 585 to the error. This problem is made slightly worse in this extended 586 use of alerts, as the alert could be the result an error in process 587 of either a certificate or an authorization. Implementations that 588 support these extensions should be aware of this imprecision. 590 The AlertDescription values are used as follows to report errors in 591 authorizations processing: 593 bad_certificate 594 In certificate processing, bad_certificate indicates that a 595 certificate was corrupt, contained signatures that did not 596 verify correctly, and so on. Similarly in authorization 597 processing, bad_certificate indicates that an authorization was 598 corrupt, contained signatures that did not verify correctly, 599 and so on. In authorization processing, bad_certificate can 600 also indicate that the handshake established that an 601 AuthzDataFormat was to be provided, but no AuthorizationData of 602 the expected format was provided in SupplementalData. 604 unsupported_certificate 605 In certificate processing, unsupported_certificate indicates 606 that a certificate was of an unsupported type. Similarly in 607 authorization processing, unsupported_certificate indicates 608 that AuthorizationData uses a version or format unsupported by 609 the implementation. 611 certificate_revoked 612 In certificate processing, certificate_revoked indicates that a 613 certificate was revoked by its issuer. Similarly in 614 authorization processing, certificate_revoked indicates that 615 authorization was revoked by its issuer, or a certificate 616 needed to validate the signature on the authorization was 617 revoked by its issuer. 619 certificate_expired 620 In certificate processing, certificate_expired indicates that a 621 certificate has expired or is not currently valid. Similarly 622 in authorization processing, certificate_expired indicates that 623 an authorization has expired or is not currently valid. 625 certificate_unknown 626 In certificate processing, certificate_unknown indicates that 627 some other (unspecified) issue arose while processing the 628 certificate, rendering it unacceptable. Similarly in 629 authorization processing, certificate_unknown indicates that 630 processing of AuthorizationData failed because other 631 (unspecified) issue, including AuthzDataFormat parse errors. 633 unknown_ca 634 In certificate processing, unknown_ca indicates that a valid 635 certification path or partial certification path was received, 636 but the certificate was not accepted because the CA certificate 637 could not be located or could not be matched with a known, 638 trusted CA. Similarly in authorization processing, unknown_ca 639 indicates that the authorization issuer is not known and 640 trusted. 642 access_denied 643 In certificate processing, access_denied indicates that a valid 644 certificate was received, but when access control was applied, 645 the sender decided not to proceed with negotiation. Similarly 646 in authorization processing, access_denied indicates that the 647 authorization was not sufficient to grant access. 649 certificate_unobtainable 650 The client_certificate_url extension defined in RFC 4366 651 [TLSEXT2] specifies that download errors lead to a 652 certificate_unobtainable alert. Similarly in authorization 653 processing, certificate_unobtainable indicates that a URL does 654 not result in an authorization. While certificate processing 655 does not require this alert to be fatal, this is a fatal alert 656 in authorization processing. 658 bad_certificate_hash_value 659 In certificate processing, bad_certificate_hash_value indicates 660 that a downloaded certificate does not match the expected hash. 661 Similarly in authorization processing, 662 bad_certificate_hash_value indicates that a downloaded 663 authorization does not match the expected hash. 665 5. IANA Considerations 667 This document defines a two TLS extensions: client_authz(TBD) and 668 server_authz(TBD). These extension type values are assigned from the 669 TLS Extension Type registry defined in [TLSEXT2]. 671 This document defines one TLS supplemental data type: 672 authz_data(TBD). This supplemental data type is assigned from the 673 TLS Supplemental Data Type registry defined in [TLSSUPP]. 675 This document establishes a new registry, to be maintained by IANA, 676 for TLS Authorization Data Formats. The first four entries in the 677 registry are x509_attr_cert(0), saml_assertion(1), 678 x509_attr_cert_url(2), and saml_assertion_url(3). TLS Authorization 679 Data Format identifiers with values in the inclusive range 0-63 680 (decimal) are assigned via RFC 5226 [IANA] IETF Review. Values from 681 the inclusive range 64-223 (decimal) are assigned via RFC 5226 682 Specification Required. Values from the inclusive range 224-255 683 (decimal) are reserved for RFC 5226 Private Use. 685 6. Security Considerations 687 A TLS server can support more than one application, and each 688 application may include several features, each of which requires 689 separate authorization checks. This is the reason that more than one 690 piece of authorization information can be provided. 692 A TLS server that requires different authorization information for 693 different applications or different application features may find 694 that a client has provided sufficient authorization information to 695 grant access to a subset of these offerings. In this situation the 696 TLS Handshake protocol will complete successfully; however, the 697 server must ensure that the client will only be able to use the 698 appropriate applications and application features. That is, the TLS 699 server must deny access to the applications and application features 700 for which authorization has not been confirmed. 702 In many cases, the authorization information is itself sensitive. 703 The double handshake technique can be used to provide protection for 704 the authorization information. Figure 2 illustrates the double 705 handshake, where the initial handshake does not include any 706 authorization extensions, but it does result in protected 707 communications. Then, a second handshake that includes the 708 authorization information is performed using the protected 709 communications. In Figure 2, the number on the right side indicates 710 the amount of protection for the TLS message on that line. A zero 711 (0) indicates that there is no communication protection; a one (1) 712 indicates that protection is provided by the first TLS session; and a 713 two (2) indicates that protection is provided by both TLS sessions. 715 The placement of the SupplementalData message in the TLS Handshake 716 results in the server providing its authorization information before 717 the client is authenticated. In many situations, servers will not 718 want to provide authorization information until the client is 719 authenticated. The double handshake illustrated in Figure 2 provides 720 a technique to ensure that the parties are mutually authenticated 721 before either party provides authorization information. 723 The use of bearer SAML assertions allows an eavesdropper or a man-in- 724 the-middle to capture the SAML assertion and try to reuse it in 725 another context. The constraints discussed in Section 3.3.2 might be 726 effective against an eavesdropper, but they are less likely to be 727 effective against a man-in-the-middle. Authentication of both 728 parties in the TLS session, which involves the use of client 729 authentication, will prevent an undetected man-in the-middle, and the 730 use of the double handshake illustrated in Figure 2 will prevent the 731 disclosure of the bearer SAML assertion to any party other than the 732 TLS peer. 734 AuthzDataFormats that point to authorization data, such as 735 x509_attr_cert_url and saml_assertion_url, rather than simply 736 including the authorization data in the handshake may be exploited by 737 an attacker. Implementations that accept pointers to authorization 738 SHOULD adopt a policy of least privilege that limits the acceptable 739 references that they will attempt to use. For more information, see 740 Section 6.3 of [TLSEXT2]. 742 Client Server 744 ClientHello (no extensions) --------> |0 745 ServerHello (no extensions) |0 746 Certificate* |0 747 ServerKeyExchange* |0 748 CertificateRequest* |0 749 <-------- ServerHelloDone |0 750 Certificate* |0 751 ClientKeyExchange |0 752 CertificateVerify* |0 753 [ChangeCipherSpec] |0 754 Finished --------> |1 755 [ChangeCipherSpec] |0 756 <-------- Finished |1 757 ClientHello (w/ extensions) --------> |1 758 ServerHello (w/ extensions) |1 759 SupplementalData (w/ authz data)* |1 760 Certificate* |1 761 ServerKeyExchange* |1 762 CertificateRequest* |1 763 <-------- ServerHelloDone |1 764 SupplementalData (w/ authz data)* |1 765 Certificate* |1 766 ClientKeyExchange |1 767 CertificateVerify* |1 768 [ChangeCipherSpec] |1 769 Finished --------> |2 770 [ChangeCipherSpec] |1 771 <-------- Finished |2 772 Application Data <-------> Application Data |2 774 Figure 2. Double Handshake to Protect Authorization Data 776 7. Acknowledgement 778 The authors thank Scott Cantor for his assistance with the SAML 779 Assertion portion of the document. 781 8. References 783 8.1. Normative References 785 [ACTYPE] Housley, R., "The application/pkix-attr-cert Content 786 Type for Attribute Certificates", work in progress. 788 [ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute 789 Certificate Profile for Authorization", RFC 3281, 790 April 2002. 792 [HTTP] Fielding, R, J. Gettys, J. Mogul, H. Frystyk, 793 L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext 794 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 796 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing 797 an IANA Considerations Section in RFCs", RFC 5226, 798 May 2008. 800 [PKIX1] Cooper, D., S. Santesson, S. Farrell, S. Boeyen, 801 R. Housley, and W. Polk, "Internet X.509 Public Key 802 Infrastructure Certificate and Certificate Revocation 803 List (CRL) Profile", RFC 5280, May 2008. 805 [SAML1.1] OASIS Security Services Technical Committee, "Security 806 Assertion Markup Language (SAML) Version 1.1 807 Specification Set", September 2003. 809 [SAML2.0] OASIS Security Services Technical Committee, "Security 810 Assertion Markup Language (SAML) Version 2.0 811 Specification Set", March 2005. 813 [SAMLBIND] OASIS Security Services Technical Committee, "Bindings 814 for the OASIS Security Assertion Markup Language (SAML) 815 V2.0", March 2005. 817 [SHS] National Institute of Standards and Technology (NIST), 818 FIPS PUB 180-3, Secure Hash Standard (SHS), 819 October 2008. 821 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 825 1.0", RFC 2246, January 1999. 827 [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer 828 Security (TLS) Protocol, Version 1.1", RFC 4346, 829 February 2006. 831 [TLS1.2] Dierks, T., and E. Rescorla, "The Transport Layer 832 Security (TLS) Protocol, Version 1.2", RFC 5246, 833 August 2008. 835 [TLSEXT2] Blake-Wilson, S., Nystrom, M., Hopwood, D., 836 Mikkelsen, J., and T. Wright, "Transport Layer 837 Security (TLS) Extensions", RFC 4366, April 2006. 839 [TLSSUPP] Santesson, S., " TLS Handshake Message for Supplemental 840 Data", RFC 4680, September 2006. 842 [UPGRADE] Khare, R., and S. Lawrence, "Upgrading to TLS Within 843 HTTP/1.1", RFC 2817, May 2000. 845 [UTF-8] Yergeau, F., "UTF-8, a transformation format of 846 ISO 10646", RFC 3629, November 2003. 848 [UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of 849 ISO 10646", RFC 2781, February 2000. 851 8.2. Informative References 853 [TLSEXT1] Blake-Wilson, S., Nystrom, M., Hopwood, D., 854 Mikkelsen, J., and T. Wright, "Transport Layer 855 Security (TLS) Extensions", RFC 3546, June 2003. 857 Authors' Addresses 859 Mark Brown 860 RedPhone Security 861 2019 Palace Avenue 862 Saint Paul, MN 55105 863 USA 864 mark redphonesecurity com 866 Russell Housley 867 Vigil Security, LLC 868 918 Spring Knoll Drive 869 Herndon, VA 20170 870 USA 871 housley vigilsec com