idnits 2.17.1 draft-housley-tls-authz-extns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 512. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 490), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 430, but not defined -- Looks like a reference, but probably isn't: '20' on line 273 -- Looks like a reference, but probably isn't: '32' on line 275 ** Obsolete normative reference: RFC 3281 (ref. 'ATTRCERT') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT') (Obsoleted by RFC 4366) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAML' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Brown 3 March 2006 RedPhone Security 4 Expires: September 2006 R. Housley 5 Vigil Security 7 Transport Layer Security (TLS) Authorization Extensions 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). All Rights Reserved. 37 Abstract 39 This document specifies authorization extensions to the Transport 40 Layer Security (TLS) Handshake Protocol. Authorization information 41 is carried in the client and server hello messages. The syntax and 42 semantics of the authorization messages are described in detail. 44 1. Introduction 46 Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being 47 used in an increasing variety of operational environments, including 48 ones that were not envisioned when the original design criteria for 49 TLS were determined. The authorization extensions introduced in this 50 document are designed to enable TLS to operate in environments where 51 authorization information needs to be exchanged between the client 52 and the server before any protected data is exchanged. 54 This document describes authorization extensions for the TLS 55 Handshake Protocol in both TLS 1.0 and TLS 1.1. These extensions 56 observe the conventions defined for TLS Extensions [TLSEXT] that make 57 use of the general extension mechanisms for the client hello message 58 and the server hello message. The extensions described in this 59 document allow TLS clients to provide to the TLS server authorization 60 information, and allow TLS server to provide to the TLS client 61 authorization information about the TLS server. 63 The authorization extensions are intended for use with both TLS 1.0 64 and TLS 1.1. The extensions are designed to be backwards compatible, 65 meaning that the authorization information carried in the client 66 hello message and the server hello message can be ignored by any 67 implementation that does not support the included authorization 68 information format. 70 Clients typically know the context of the TLS session that is being 71 setup, thus the client can use of the authorization extensions when 72 needed. Servers must accept extended client hello messages, even if 73 the server does not "understand" the all of the listed extensions. 74 However, the server will not make use of the authorization 75 information if the authorization extension is not supported or the 76 authorization information is provided in an unsupported format. 78 1.1. Conventions 80 The syntax for the authorization messages is defined using the TLS 81 Presentation Language, which is specified in Section 4 of [TLS1.0]. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [STDWORDS]. 87 1.2. Overview 89 Figure 1 illustrates the placement of the authorization messages in 90 the full TLS handshake. 92 Client Server 94 ClientHello 95 (with AuthorizationData) --------> 96 ServerHello 97 (with AuthorizationData) 98 Certificate* 99 ServerKeyExchange* 100 CertificateRequest* 101 <-------- ServerHelloDone 102 Certificate* 103 ClientKeyExchange 104 CertificateVerify* 105 [ChangeCipherSpec] 106 Finished --------> 107 [ChangeCipherSpec] 108 <-------- Finished 109 Application Data <-------> Application Data 111 * Indicates optional or situation-dependent messages that 112 are not always sent. 114 [] Indicates that ChangeCipherSpec is an independent TLS 115 Protocol content type; it is not actually a TLS 116 Handshake Protocol message. 118 Figure 1. AuthorizationData carried in ClientHello and ServerHello 120 The ClientHello message includes the AuthorizationData extension, 121 which contains the authorization data for the client, and then the 122 ServerHello message includes the AuthorizationData extension, which 123 contains the authorization data for the server. If the server does 124 not support the AuthorizationData extension, or the server does not 125 support the authorization information format used by the client, then 126 the server MUST NOT include the AuthorizationData extension in the 127 ServerHello message. The Handshake Protocol continues, but without 128 the benefit of authorization information. 130 2. AuthorizationData Extension 132 The general extension mechanisms enable clients and servers to 133 negotiate the use of specific extensions. As specified in [TLSEXT], 134 the extension format used in the extended client hello message and 135 extended server hello message is: 137 struct { 138 ExtensionType extension_type; 139 opaque extension_data<0..2^16-1>; 140 } Extension; 142 The extension_type identifies a particular extension type, and the 143 extension_data contains information specific to the particular 144 extension type. 146 As specified in [TLSEXT], for all extension types, the extension type 147 MUST NOT appear in the extended server hello message unless the same 148 extension type appeared in the corresponding client hello message. 149 Clients MUST abort the handshake if they receive an extension type in 150 the extended server hello message that they did not request in the 151 associated extended client hello message. 153 When multiple extensions of different types are present in the 154 extended client hello message or the extended server hello message, 155 the extensions can appear in any order, but there MUST NOT be more 156 than one extension of the same type. 158 This document specifies the use of one new extension type: 159 authz_data. 161 This specification adds one new type to ExtensionType: 163 enum { 164 authz_data(TBD), (65535) 165 } ExtensionType; 167 The authorization extension is relevant when a session is initiated, 168 regardless of the use of a full handshake or use of session 169 resumption. Clients MUST explicitly present AuthorizationData in 170 every client hello message for which authorization information is 171 desired. Upon receipt of a client hello message that requests 172 session resumption but which contains no acceptable 173 AuthorizationData, the TLS server MAY resume the session but it MUST 174 NOT grant authorization to the session being resumed based on any 175 prior session authorization. 177 These requirements allow a series of resumed sessions to have 178 different authorizations from one another. More importantly, the 179 authorization information is always provided by the client in case 180 the server no longer honors the session resumption at the requested 181 authorization level. Repeated inclusion of the authorization 182 information allows the Handshake Protocol to proceed the same way for 183 both resume and session origination. 185 2.1. The authz_data Extension Type 187 Clients MUST include the authz_data extension type in the extended 188 client hello message to send authorization data to the server. The 189 extension_data field contains the authorization data. Section 2.2 190 specifies the authorization data formats that are supported. 192 Servers that receive an extended client hello message containing the 193 authz_data extension MUST respond with the authz_data extension in 194 the extended server hello message if the server is willing to make 195 use of the received authorization data in the provided format. If 196 the server has any authorization information to send to the client, 197 then the server MUST include the information in the authz_data 198 extension type in the extended server hello message. 200 The AuthorizationData structure is described in Section 2.3. 202 2.2. AuthzDataFormat Type 204 The AuthzDataFormat type is used in the authz_data extension. It 205 indicates the format of the authorization information that will be 206 transferred. The AuthzDataFormat type definition is: 208 enum { 209 x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), 210 saml_assertion_url(3), (255) 211 } AuthzDataFormat; 213 When the x509_attr_cert value is present, the authorization data is 214 an X.509 Attribute Certificate (AC) that conforms to the profile in 215 RFC 3281 [ATTRCERT]. 217 When the saml_assertion value is present, the authorization data is 218 an assertion composed using the Security Assertion Markup Language 219 (SAML) [SAML]. 221 When the x509_attr_cert_url value is present, the authorization data 222 is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT]; 223 however, the AC is fetched with the supplied URL. A one-way hash 224 value is provided to ensure that the intended AC is obtained. 226 When the saml_assertion_url value is present, the authorization data 227 is a SAML Assertion; however, the SAML Assertion is fetched with the 228 supplied URL. A one-way hash value is provided to ensure that the 229 intended SAML Assertion is obtained. 231 Additional formats can be registered in the future using the 232 procedures in section 3. 234 2.3. AuthorizationData Type 236 The AuthorizationData type is carried in the extension_data field for 237 the authz_data extension. When it appears in the extended client 238 hello message, it carries authorization information for the TLS 239 client. When it appears in the extended server hello message, it 240 carries authorization information for the TLS server. 242 struct { 243 AuthorizationDataEntry authz_data_list<1..2^16-1>; 244 } AuthorizationData; 246 struct { 247 AuthzDataFormat authz_format; 248 select (authz_format) { 249 case x509_attr_cert: X509AttrCert; 250 case saml_assertion: SAMLAssertion; 251 case x509_attr_cert_url: URLandHash; 252 case saml_assertion_url: URLandHash; 253 } authz_data_entry; 254 } AuthorizationDataEntry; 256 opaque X509AttrCert<1..2^16-1>; 258 opaque SAMLAssertion<1..2^16-1>; 260 struct { 261 opaque url<1..2^16-1>; 262 HashType hash_type; 263 select (hash_type) { 264 case sha1: SHA1Hash; 265 case sha256: SHA256Hash; 266 } hash; 267 } URLandHash; 269 enum { 270 sha1(0), sha256(1), (255) 271 } HashType; 273 opaque SHA1Hash[20]; 275 opaque SHA1Hash[32]; 277 When X509AttrCert is used, the field contains an ASN.1 DER-encoded 278 X.509 Attribute Certificate (AC) that follows the profile in RFC 3281 280 [ATTRCERT]. An AC is a structure similar to a public key certificate 281 (PKC); the main difference being that the AC contains no public key. 282 An AC may contain attributes that specify group membership, role, 283 security clearance, or other authorization information associated 284 with the AC holder. 286 When SAMLAssertion is used, the field contains XML constructs with a 287 nested structure defined in [SAML]. SAML is an XML-based framework 288 for exchanging security information. This security information is 289 expressed in the form of assertions about subjects, where a subject 290 is either human or computer with an identity. In this context, the 291 assertions are most likely to convey authorization decisions about 292 whether subjects are allowed to access certain resources. Assertions 293 are issued by SAML authorities, namely, authentication authorities, 294 attribute authorities, and policy decision points. 296 Since X509AttrCert and SAMLAssertion can lead to a significant 297 increase in the size of the hello messages, alternatives provide a 298 URL to obtain the ASN.1 DER-encoded X.509 AC or SAML Assertion. To 299 ensure that the intended object is obtained, a one-way hash value of 300 the object is also included. Integrity of this one-way hash value is 301 provided by the TLS Finished message. 303 Implementations that support either x509_attr_cert_url or 304 saml_assertion_url MUST support URLs that employ the http scheme. 305 Other schemes may also be supported; however, to avoid circular 306 dependencies, supported schemes SHOULD NOT themselves make use of 307 TLS, such as the https scheme. 309 Implementations that support either x509_attr_cert_url or 310 saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2] 311 as one-way hash functions. Other one-way hash functions may also be 312 supported. Additional one-way hash functions can be registered in 313 the future using the procedures in section 3. 315 3. IANA Considerations 317 IANA has assigned one TLS Extension Types: authz_data(TBD). 319 IANA has established a registry for TLS Authorization Data Formats. 320 The first two entries in the registry are x509_attr_cert(0) and 321 saml_assertion(1). TLS Authorization Data Format identifiers with 322 values in the inclusive range 0-63 (decimal) are assigned via RFC 323 2434 [IANA] Standards Action. Values from the inclusive range 64-223 324 (decimal) are assigned via RFC 2434 Specification Required. Values 325 from the inclusive range 224-255 (decimal) are reserved for RFC 2434 326 Private Use. 328 IANA has established a registry for TLS Hash Types. The first two 329 entries in the registry are sha1(0) and sha256(1). TLS Hash Type 330 identifiers with values in the inclusive range 0-158 (decimal) are 331 assigned via RFC 2434 [IANA] Standards Action. Values from the 332 inclusive range 159-223 (decimal) are assigned via RFC 2434 333 Specification Required. Values from the inclusive range 224-255 334 (decimal) are reserved for RFC 2434 Private Use. 336 4. Security Considerations 338 A TLS server can support more than one application, and each 339 application may include several features, each of which requires 340 separate authorization checks. This is the reason that more than one 341 piece of authorization information can be provided. 343 A TLS server that requires different authorization information for 344 different applications or different application features may find 345 that a client has provided sufficient authorization information to 346 grant access to a subset of these offerings. In this situation the 347 TLS Handshake Protocol will complete successfully; however, the 348 server must ensure that the client will only be able to use the 349 appropriate applications and application features. That is, the TLS 350 server must deny access to the applications and application features 351 for which authorization has not been confirmed. 353 In many cases, the authorization information is itself sensitive. 354 The double handshake technique can be used to provide protection for 355 the authorization information. Figure 2 illustrates the double 356 handshake, where the initial handshake does not include any 357 authorization information, but it does result in protected 358 communications. Then, a second handshake that includes the 359 authorization information is performed using the protected 360 communications. In Figure 2, the number on the right side indicates 361 the amount of protection for the TLS message on that line. A zero 362 (0) indicates that there is no communication protection; a one (1) 363 indicates that protection is provided by the first TLS session; and a 364 two (2) indicates that protection is provided by both TLS sessions. 366 Client Server 368 ClientHello |0 369 (no AuthorizationData) --------> |0 370 ServerHello |0 371 (no AuthorizationData) |0 372 Certificate* |0 373 ServerKeyExchange* |0 374 CertificateRequest* |0 375 <-------- ServerHelloDone |0 376 Certificate* |0 377 ClientKeyExchange |0 378 CertificateVerify* |0 379 [ChangeCipherSpec] |0 380 Finished --------> |1 381 [ChangeCipherSpec] |0 382 <-------- Finished |1 383 ClientHello |1 384 (with AuthorizationData) --------> |1 385 ServerHello |1 386 (with AuthorizationData) |1 387 Certificate* |1 388 ServerKeyExchange* |1 389 CertificateRequest* |1 390 <-------- ServerHelloDone |1 391 Certificate* |1 392 ClientKeyExchange |1 393 CertificateVerify* |1 394 [ChangeCipherSpec] |1 395 Finished --------> |2 396 [ChangeCipherSpec] |1 397 <-------- Finished |2 398 Application Data <-------> Application Data |2 400 Figure 2. Protection of Authorization Data (Two Full Handshakes) 402 Public key operations can be minimized by making the second handshake 403 a resumption. This is much more efficient in term of computation and 404 message exchanges. Figure 3 illustrates this more efficient double 405 handshake. 407 Client Server 409 ClientHello |0 410 (no AuthorizationData) --------> |0 411 ServerHello |0 412 (no AuthorizationData) |0 413 Certificate* |0 414 ServerKeyExchange* |0 415 CertificateRequest* |0 416 <-------- ServerHelloDone |0 417 Certificate* |0 418 ClientKeyExchange |0 419 CertificateVerify* |0 420 [ChangeCipherSpec] |0 421 Finished --------> |1 422 [ChangeCipherSpec] |0 423 <-------- Finished |1 424 ClientHello |1 425 (with AuthorizationData) --------> |1 426 ServerHello |1 427 (with AuthorizationData) |1 428 [ChangeCipherSpec] |1 429 <-------- Finished |2 430 [ChangeCipherSpec] |1 431 Finished --------> |2 432 Application Data <-------> Application Data |2 434 Figure 3. Protection of Authorization Data (Resumption) 436 5. Normative References 438 [ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute 439 Certificate Profile for Authorization", RFC 3281, 440 April 2002. 442 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing 443 an IANA Considerations Section in RFCs", RFC 3434, 444 October 1998. 446 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", 447 RFC 2246, January 1999. 449 [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security 450 (TLS) Protocol, Version 1.1", RFC 4346, February 2006. 452 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 453 and T. Wright, "Transport Layer Security (TLS) Extensions", 454 RFC 3546, June 2003. 456 [SAML] Organization for the Advancement of Structured Information 457 Standards, "Security Assertion Markup Language (SAML), 458 version 1.1", September 2003. [Version 2.0 is out for 459 public comment; it will replace this reference if approved.] 461 [SHA1] National Institute of Standards and Technology (NIST), 462 FIPS PUB 180-1, Secure Hash Standard, 17 April 1995. 464 [SHA2] National Institute of Standards and Technology (NIST), 465 FIPS PUB 180-2: Secure Hash Standard, 1 August 2002. 467 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 Author's Address 472 Mark Brown 473 RedPhone Security 474 2019 Palace Avenue 475 Saint Paul, MN 55105 476 USA 477 mark redphonesecurity com 479 Russell Housley 480 Vigil Security, LLC 481 918 Spring Knoll Drive 482 Herndon, VA 20170 483 USA 484 housley vigilsec com 486 Full Copyright Statement 488 Copyright (C) The Internet Society (2006). This document is subject 489 to the rights, licenses and restrictions contained in BCP 78, and 490 except as set forth therein, the authors retain all their rights. 492 This document and translations of it may be copied and furnished to 493 others, and derivative works that comment on or otherwise explain it 494 or assist in its implementation may be prepared, copied, published 495 and distributed, in whole or in part, without restriction of any 496 kind, provided that the above copyright notice and this paragraph are 497 included on all such copies and derivative works. However, this 498 document itself may not be modified in any way, such as by removing 499 the copyright notice or references to the Internet Society or other 500 Internet organizations, except as needed for the purpose of 501 developing Internet standards in which case the procedures for 502 copyrights defined in the Internet Standards process must be 503 followed, or as required to translate it into languages other than 504 English. 506 This document and the information contained herein are provided on an 507 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 508 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 509 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 510 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 511 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 512 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.