idnits 2.17.1 draft-housley-tls-authz-extns-02.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 477. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 455), 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 397, but not defined ** 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' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 5 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. Extensions carried in the 41 client and server hello messages to confirm that both parties support 42 the desired authorization data types. Then, if supported by both the 43 client and the server, authorization information is exchanged in the 44 supplemental data handshake message. 46 1. Introduction 48 Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being 49 used in an increasing variety of operational environments, including 50 ones that were not envisioned at the time of the original design for 51 TLS. The extensions introduced in this document are designed to 52 enable TLS to operate in environments where authorization information 53 needs to be exchanged between the client and the server before any 54 protected data is exchanged. 56 This document describes authorization extensions for the TLS 57 Handshake Protocol in both TLS 1.0 and TLS 1.1. These extensions 58 observe the conventions defined for TLS Extensions [TLSEXT] that make 59 use of the general extension mechanisms for the client hello message 60 and the server hello message. The extensions described in this 61 document confirm that both the client and the server support the 62 desired authorization data types. Then, if supported, authorization 63 information is exchanged in the supplemental data handshake message 64 [TLSSUPP]. 66 The authorization extensions may be used in conjunction with TLS 1.0 67 and TLS 1.1. The extensions are designed to be backwards compatible, 68 meaning that the Handshake Protocol Supplemental Data messages will 69 only contain authorization information of a particular type if the 70 client indicates support for them in the client hello message and the 71 server indicates support for them in the server hello message. 73 Clients typically know the context of the TLS session that is being 74 setup, thus the client can use the authorization extensions when they 75 are needed. Servers must accept extended client hello messages, even 76 if the server does not "understand" the all of the listed extensions. 77 However, the server will not indicate support for these "not 78 understood" extensions. Then, clients may reject communications with 79 servers that do not support the authorization extensions. 81 1.1. Conventions 83 The syntax for the authorization messages is defined using the TLS 84 Presentation Language, which is specified in Section 4 of [TLS1.0]. 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [STDWORDS]. 90 1.2. Overview 92 Figure 1 illustrates the placement of the authorization extensions 93 and supplemental data messages in the full TLS handshake. 95 Client Server 97 ClientHello (w/ extensions) --------> 99 ServerHello(w/ extensions) 100 SupplementalData* 101 Certificate* 102 ServerKeyExchange* 103 CertificateRequest* 104 <-------- ServerHelloDone 105 SupplementalData* 106 Certificate* 107 ClientKeyExchange 108 CertificateVerify* 109 [ChangeCipherSpec] 110 Finished --------> 111 [ChangeCipherSpec] 112 <-------- Finished 113 Application Data <-------> Application Data 115 * Indicates optional or situation-dependent messages that 116 are not always sent. 118 [] Indicates that ChangeCipherSpec is an independent TLS 119 Protocol content type; it is not actually a TLS 120 handshake message. 122 Figure 1. Authorization data exchange in full TLS handshake 124 The ClientHello message includes an indication of the client 125 authorization data formats that are supported and an indication of 126 the server authorization data formats that are supported. The 127 ServerHello message contains similar indications, but any 128 authentication data formats that are not supported by the server are 129 not included. Both the client and the server MUST indicate support 130 for the authorization data types. If the list of mutually supported 131 authorization data formats is empty, then the ServerHello message 132 MUST NOT carry the affected extension at all. 134 2. Authorization Extension Types 136 The general extension mechanisms enable clients and servers to 137 negotiate whether to use specific extensions, and how to use specific 138 extensions. As specified in [TLSEXT], the extension format used in 139 the extended client hello message and extended server hello message 140 is repeated here for convenience: 142 struct { 143 ExtensionType extension_type; 144 opaque extension_data<0..2^16-1>; 145 } Extension; 147 The extension_type identifies a particular extension type, and the 148 extension_data contains information specific to the particular 149 extension type. 151 As specified in [TLSEXT], for all extension types, the extension type 152 MUST NOT appear in the extended server hello message unless the same 153 extension type appeared in the corresponding client hello message. 154 Clients MUST abort the handshake if they receive an extension type in 155 the extended server hello message that they did not request in the 156 associated extended client hello message. 158 When multiple extensions of different types are present in the 159 extended client hello message or the extended server hello message, 160 the extensions can appear in any order, but there MUST NOT be more 161 than one extension of the same type. 163 This document specifies the use of two new extension types: 164 client_authz and server_authz. These extension types are described 165 in Section 2.1 and Section 2.2, respectively. This specification 166 adds two new types to ExtensionType: 168 enum { 169 client_authz(TBD), server_authz(TBD), (65535) 170 } ExtensionType; 172 The authorization extensions are relevant when a session is initiated 173 and any subsequent session resumption. However, a client that 174 requests resumption of a session does not know whether the server 175 will have all of the context necessary to accept this request, and 176 therefore the client SHOULD send an extended client hello message 177 that includes the extension types associated with the authorization 178 extensions. This way, if the resumption request is denied, then the 179 authorization extensions will be negotiated as normal. 181 2.1. The client_authz Extension Type 183 Clients MUST include the client_authz extension type in the extended 184 client hello message to indicate their desire to send authorization 185 data to the server. The extension_data field indicates the format of 186 the authorization data that will be sent in the supplemental data 187 handshake message. The syntax of the client_authz extension_data 188 field as described in Section 2.3. 190 Servers that receive an extended client hello message containing the 191 client_authz extension MUST respond with the same client_authz 192 extension in the extended server hello message if the server is 193 willing to receive authorization data in the indicated format. Any 194 unacceptable formats must be removed from the list provided by the 195 client. The client_authz extension MUST be omitted from the extended 196 server hello message if the server is not willing to receive 197 authorization data in any of the indicated formats. 199 2.2. The server_authz Extension Type 201 Clients MUST include the server_authz extension type in the extended 202 client hello message to indicate their desire to receive 203 authorization data from the server. The extension_data field 204 indicates the format of the authorization data that will be sent in 205 the supplemental data handshake message. The syntax of the 206 server_authz extension_data field as described in Section 2.3. 208 Servers that receive an extended client hello message containing the 209 server_authz extension MUST respond with the same server_authz 210 extension in the extended server hello message if the server is 211 willing to provide authorization data in the requested format. Any 212 unacceptable formats must be removed from the list provided by the 213 client. The server_authz extension MUST be omitted from the extended 214 server hello message if the server is not able to provide 215 authorization data in any of the indicated formats. 217 2.3. AuthzDataFormat Type 219 The AuthzDataFormat type is used in both the client_authz and the 220 server_authz extensions. It indicates the format of the 221 authorization data that will be transferred. The AuthzDataFormat 222 type definition is: 224 enum{ 225 x509_attr_cert(0), saml_assertion(1), (255) 226 } AuthzDataFormat; 228 When the x509_attr_cert value is present, the authorization data is 229 an X.509 Attribute Certificate that conforms to the profile in RFC 230 3281 [ATTRCERT]. 232 When the saml_assertion value is present, the authorization data is 233 an assertion composed using the Security Assertion Markup Language 234 (SAML) [SAML]. 236 3. Supplemental Data Handshake Message Usage 238 As shown in Figure 1, supplemental data can be exchanges in two 239 places in the handshake protocol. The client_authz extension 240 determines what authorization data formats are acceptable for 241 transfer from the client to the server, and the server_authz 242 extension determines what authorization data formats are acceptable 243 for transfer from the server to the client. In both cases, the 244 syntax specified in [TLSSUPP] is used along with the authz_data type 245 defined in this document. 247 enum { 248 authz_data(TBD), (65535) 249 } SupplementalDataType; 251 struct { 252 SupplementalDataType supplemental_data_type; 253 select(SupplementalDataType) { 254 case authz_data: AuthorizationData; 255 } 256 } SupplementalData; 258 3.1. Client Authorization Data 260 The SupplementalData message sent from the client to the server 261 contains authorization data associated with the TLS client. The 262 format of the authentication data depends on the format negotiated in 263 the client_authz hello message extension. The AuthorizationData 264 structure is described in Section 3.3. 266 3.2. Server Authorization Data 268 The SupplementalData message sent from the server to the client 269 contains authorization data associated with the TLS server. The 270 format of the authorization data depends on the format negotiated in 271 the server_authz hello message extensions. The AuthorizationData 272 structure is described in Section 3.3. 274 3.3. AuthorizationData Type 276 The AuthorizationData structure carried authorization information for 277 either the client or the server. The AuthzDataFormat specified in 278 Section 2.3 for use in the hello extensions is also used in this 279 structure. 281 All of the entries in the authz_data_list MUST employ authorization 282 data formats that were negotiated in the relevant hello message 283 extension. 285 struct{ 286 AuthorizationDataEntry authz_data_list<1..2^16-1>; 287 } AuthorizationData; 289 struct { 290 AuthzDataFormat authz_format; 291 select (AuthzDataFormat) { 292 case x509_attr_cert: X509AttrCert; 293 case saml_assertion: SAMLAssertion; 294 } 295 } AuthorizationDataEntry; 297 enum{ 298 x509_attr_cert(0), saml_assertion(1), (255) 299 } AuthzDataFormat; 301 opaque X509AttrCert<1..2^16-1>; 303 opaque SAMLAssertion<1..2^16-1>; 305 When X509AttrCert is used, the field contains an ASN.1 DER-encoded 306 X.509 Attribute Certificate (AC) that follows the profile in RFC 3281 307 [ATTRCERT]. An AC is a structure similar to a public key certificate 308 (PKC); the main difference being that the AC contains no public key. 309 An AC may contain attributes that specify group membership, role, 310 security clearance, or other authorization information associated 311 with the AC holder. 313 When SAMLAssertion is used, the field contains XML constructs with a 314 nested structure defined in [SAML]. SAML is an XML-based framework 315 for exchanging security information. This security information is 316 expressed in the form of assertions about subjects, where a subject 317 is either human or computer with an identity. In this context, the 318 assertions are most likely to convey authorization decisions about 319 whether subjects are allowed to access certain resources. Assertions 320 are issued by SAML authorities, namely, authentication authorities, 321 attribute authorities, and policy decision points. 323 4. IANA Considerations 325 IANA assigned two TLS Extension Types: client_authz(TBD) and 326 server_authz(TBD). 328 IANA assigned one TLS Supplemental Data Formats: authz_data(TBD). 330 IANA needs to establish a registry for TLS Authorization Data 331 Formats. The first two entries in the registry are x509_attr_cert(0) 332 and saml_assertion(1). TLS Authorization Data Format identifiers 333 with values in the inclusive range 0-63 (decimal) are assigned via 334 RFC 2434 [IANA] Standards Action. Values from the inclusive range 335 64-223 (decimal) are assigned via RFC 2434 Specification Required. 336 Values from the inclusive range 224-255 (decimal) are reserved for 337 RFC 2434 Private Use. 339 5. Security Considerations 341 A TLS server can support more than one application, and each 342 application may include several features, each of which requires 343 separate authorization checks. This is the reason that more than one 344 piece of authorization information can be provided. 346 A TLS server that requires different authorization information for 347 different applications or different application features may find 348 that a client has provided sufficient authorization information to 349 grant access to a subset of these offerings. In this situation the 350 TLS Handshake protocol will complete successfully; however, the 351 server must ensure that the client will only be able to use the 352 appropriate applications and application features. That is, the TLS 353 server must deny access to the applications and application features 354 for which authorization has not been confirmed. 356 In many cases, the authorization information is itself sensitive. 357 The double handshake technique can be used to provide protection for 358 the authorization information. Figure 2 illustrates the double 359 handshake, where the initial handshake does not include any 360 authorization extensions, but it does result in protected 361 communications. Then, a second handshake that includes the 362 authorization information is performed using the protected 363 communications. In Figure 2, the number on the right side indicates 364 the amount of protection for the TLS message on that line. A zero 365 (0) indicates that there is no communication protection; a one (1) 366 indicates that protection is provided by the first TLS session; and a 367 two (2) indicates that protection is provided by both TLS sessions. 369 Client Server 371 ClientHello (no extensions) --------> |0 372 ServerHello (no extensions) |0 373 Certificate* |0 374 ServerKeyExchange* |0 375 CertificateRequest* |0 376 <-------- ServerHelloDone |0 377 Certificate* |0 378 ClientKeyExchange |0 379 CertificateVerify* |0 380 [ChangeCipherSpec] |0 381 Finished --------> |1 382 [ChangeCipherSpec] |0 383 <-------- Finished |1 384 ClientHello (w/ extensions) --------> |1 385 ServerHello (w/ extensions) |1 386 SupplementalData (w/ authz data)* |1 387 Certificate* |1 388 ServerKeyExchange* |1 389 CertificateRequest* |1 390 <-------- ServerHelloDone |1 391 SupplementalData (w/ authz data)* |1 392 Certificate* |1 393 ClientKeyExchange |1 394 CertificateVerify* |1 395 [ChangeCipherSpec] |1 396 Finished --------> |2 397 [ChangeCipherSpec] |1 398 <-------- Finished |2 399 Application Data <-------> Application Data |2 401 Figure 2. Double Handshake to Protect Authorization Data 403 6. Normative References 405 [ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute 406 Certificate Profile for Authorization", RFC 3281, 407 April 2002. 409 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing 410 an IANA Considerations Section in RFCs", RFC 3434, 411 October 1998. 413 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", 414 RFC 2246, January 1999. 416 [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security 417 (TLS) Protocol, Version 1.1", RFC 4346, February 2006. 419 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 420 and T. Wright, "Transport Layer Security (TLS) Extensions", 421 RFC 3546, June 2003. 423 [TLSSUPP] Santesson, S., " TLS Handshake Message for Supplemental 424 Data", work in progress: draft-santesson-tls-supp, 425 March 2006. 427 [SAML] Organization for the Advancement of Structured Information 428 Standards, "Security Assertion Markup Language (SAML), 429 version 1.1", September 2003. [Version 2.0 is out for 430 public comment; it will replace this reference if approved.] 432 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 Author's Address 437 Mark Brown 438 RedPhone Security 439 2019 Palace Avenue 440 Saint Paul, MN 55105 441 USA 442 mark redphonesecurity com 444 Russell Housley 445 Vigil Security, LLC 446 918 Spring Knoll Drive 447 Herndon, VA 20170 448 USA 449 housley vigilsec com 451 Full Copyright Statement 453 Copyright (C) The Internet Society (2006). This document is subject 454 to the rights, licenses and restrictions contained in BCP 78, and 455 except as set forth therein, the authors retain all their rights. 457 This document and translations of it may be copied and furnished to 458 others, and derivative works that comment on or otherwise explain it 459 or assist in its implementation may be prepared, copied, published 460 and distributed, in whole or in part, without restriction of any 461 kind, provided that the above copyright notice and this paragraph are 462 included on all such copies and derivative works. However, this 463 document itself may not be modified in any way, such as by removing 464 the copyright notice or references to the Internet Society or other 465 Internet organizations, except as needed for the purpose of 466 developing Internet standards in which case the procedures for 467 copyrights defined in the Internet Standards process must be 468 followed, or as required to translate it into languages other than 469 English. 471 This document and the information contained herein are provided on an 472 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 473 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 474 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 475 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 476 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.