idnits 2.17.1 draft-housley-tls-authz-extns-00.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 447. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 425), 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 111, 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 (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Brown 3 February 2006 RedPhone Security 4 Expires: August 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. Extension types are carried 41 in the client and server hello messages to confirm that both parties 42 support the authorization messages. The syntax and semantics of the 43 authorization messages are described in detail. 45 1. Introduction 47 Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being 48 used in an increasing variety of operational environments, including 49 ones that were not envisioned when the original design criteria for 50 TLS were determined. The extensions introduced in this document are 51 designed to enable TLS to operate in environments where authorization 52 information needs to be exchanged between the client and the server 53 before any protected data is exchanged. 55 This document describes authorization extensions for the TLS 56 Handshake Protocol in both TLS 1.0 and TLS 1.1. These extensions 57 observe the conventions defined for TLS Extensions [TLSEXT] that make 58 use of the general extension mechanisms for the client hello message 59 and the server hello message. The extensions described in this 60 document allow TLS clients to provide to the TLS server authorization 61 information, and allow TLS server to provide to the TLS client 62 authorization information about the TLS server. 64 The authorization extensions may be used in conjunction with TLS 1.0 65 and TLS 1.1. The extensions are designed to be backwards compatible, 66 meaning that the Handshake Protocol messages associated with the 67 authorization extensions will only be exchanged if the client 68 indicates support for them in the client hello message and the server 69 indicates support for them in the server hello message. 71 Clients typically know the context of the TLS session that is being 72 setup, thus the client can request the use of the authorization 73 extensions when they are needed. Servers must accept extended client 74 hello messages, even if the server does not "understand" the all of 75 the listed extensions. However, the server will not indicate support 76 for these "not understood" extensions. Then, clients may reject 77 communications with servers that do not support the authorization 78 extensions. 80 1.1. Conventions 82 The syntax for the authorization messages is defined using the TLS 83 Presentation Language, which is specified in Section 4 of [TLS1.0]. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [STDWORDS]. 89 1.2. Overview 91 Figure 1 illustrates the placement of the authorization messages in 92 the full TLS handshake. In order to avoid unnecessary disclosure of 93 privilege information, the authorization messages appear after the 94 Finished message. This placement ensures that they are encrypted and 95 integrity protected. 97 Client Server 99 ClientHello --------> 100 ServerHello 101 Certificate* 102 ServerKeyExchange* 103 CertificateRequest* 104 <-------- ServerHelloDone 105 Certificate* 106 ClientKeyExchange 107 CertificateVerify* 108 [ChangeCipherSpec] 109 Finished --------> 110 ClientAuthorizationData --------> 111 [ChangeCipherSpec] 112 <-------- Finished 113 <-------- ServerAuthorizationData 114 Application Data <-------> Application Data 116 * Indicates optional or situation-dependent messages that 117 are not always sent. 119 [] Indicates that ChangeCipherSpec is an independent TLS 120 Protocol content type; it is not actually a TLS 121 handshake message. 123 Figure 1. Authorization data exchange in full TLS handshake 125 The ClientHello message includes an indication that the 126 ClientAuthorizationData message and ServerAuthorizationData message 127 are supported. The ServerHello message also includes an indication 128 that the ClientAuthorizationData message and ServerAuthorizationData 129 message are supported. Both the client and the server MUST indicate 130 support for the authorization messages, otherwise they MUST NOT be 131 included in the handshake. 133 2. Authorization Extension Types 135 The general extension mechanisms enable clients and servers to 136 negotiate whether to use specific extensions, and how to use specific 137 extensions. As specified in [TLSEXT], the extension format used in 138 the extended client hello message and extended server hello message 139 is: 141 struct { 142 ExtensionType extension_type; 143 opaque extension_data<0..2^16-1>; 144 } Extension; 146 The extension_type identifies a particular extension type, and the 147 extension_data contains information specific to the particular 148 extension type. 150 As specified in [TLSEXT], for all extension types, the extension type 151 MUST NOT appear in the extended server hello message unless the same 152 extension type appeared in the corresponding client hello message. 153 Clients MUST abort the handshake if they receive an extension type in 154 the extended server hello message that they did not request in the 155 associated extended client hello message. 157 When multiple extensions of different types are present in the 158 extended client hello message or the extended server hello message, 159 the extensions can appear in any order, but there MUST NOT be more 160 than one extension of the same type. 162 This document specifies the use of two new extension types: 163 client_authz_request and server_authz_request. These extension types 164 are described in Section 2.1 and Section 2.2, respectively. This 165 specification adds two new types to ExtensionType: 167 enum { 168 client_authz_request(TBD), server_authz_request(TBD), 169 (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_request Extension Type 183 Clients MUST include the client_authz_request extension type in the 184 extended client hello message to indicate their desire to send 185 authorization data to the server. The extension_data field indicates 186 the format of the authorization data that will be sent. The format 187 is indicated with the AuthzDataFormat type defined in Section 2.3. 189 Servers that receive an extended client hello message containing the 190 client_authz_request extension MUST respond with the same 191 client_authz_request extension in the extended server hello message 192 if the server is willing to receive authorization data in the 193 indicated format. The client_authz_request extension MUST be omitted 194 from the extended server hello message if the server is not willing 195 to receive authorization data in the indicated format. 197 2.2. The server_authz_request Extension Type 199 Clients MUST include the server_authz_request extension type in the 200 extended client hello message to indicate their desire to receive 201 authorization data from the server. The extension_data field 202 indicates the format of the authorization data that is desired. The 203 format is indicated with the AuthzDataFormat type defined in Section 204 2.3. 206 Servers that receive an extended client hello message containing the 207 server_authz_request extension MUST respond with the same 208 server_authz_request extension in the extended server hello message 209 if the server is willing to provide authorization data in the 210 requested format. The server_authz_request extension MUST be omitted 211 from the extended server hello message if the server is not able to 212 provide authorization data in the requested format. 214 2.3. AuthzDataFormat Type 216 The AuthzDataFormat type is used in both the client_authz_request and 217 the server_authz_request extensions. It indicates the format of the 218 authorization data that will be transferred. The AuthzDataFormat 219 type definition is: 221 enum{ 222 x509_attr_cert(0), saml_assertion(1), (255) 223 } AuthzDataFormat; 225 When the x509_attr_cert value is present, the authorization data is 226 an X.509 Attribute Certificate that conforms to the profile in RFC 227 3281 [ATTRCERT]. 229 When the saml_assertion value is present, the authorization data is 230 an assertion composed using the Security Assertion Markup Language 231 (SAML) [SAML]. 233 3. Handshake Messages 235 This document specifies the use of two new handshake messages: the 236 ClientAuthorizationData message and ServerAuthorizationData message. 237 These messages are described in Section 3.1 and Section 3.2, 238 respectively. The updated handshake message structure becomes: 240 enum { 241 hello_request(0), client_hello(1), server_hello(2), 242 certificate(11), server_key_exchange (12), 243 certificate_request(13), server_hello_done(14), 244 certificate_verify(15), client_key_exchange(16), 245 finished(20), certificate_url(21), certificate_status(22), 246 client_authz_data(TBD), server_authz_data(TBD), (255) 247 } HandshakeType; 249 struct { 250 HandshakeType msg_type; /* handshake type */ 251 uint24 length; /* octets in message */ 252 select (HandshakeType) { 253 case hello_request: HelloRequest; 254 case client_hello: ClientHello; 255 case server_hello: ServerHello; 256 case certificate: Certificate; 257 case server_key_exchange: ServerKeyExchange; 258 case certificate_request: CertificateRequest; 259 case server_hello_done: ServerHelloDone; 260 case certificate_verify: CertificateVerify; 261 case client_key_exchange: ClientKeyExchange; 262 case finished: Finished; 263 case certificate_url: CertificateURL; 264 case certificate_status: CertificateStatus; 265 case client_authz_data: ClientAuthorizationData; 266 case server_authz_data: ServerAuthorizationData; 267 } body; 268 } Handshake; 270 3.1. ClientAuthorizationData Message 272 The ClientAuthorizationData message contains authorization data 273 associated with the TLS client. The format of the authentication 274 data depends on the format negotiated in the client_authz_request 275 hello message extensions. 277 struct { 278 client_authz_data AuthorizationData; 279 } ClientAuthorizationData; 281 The AuthorizationData structure is described in Section 3.3. 283 3.2. ServerAuthorizationData Message 285 The ServerAuthorizationData message contains authorization data 286 associated with the TLS server. The format of the authorization data 287 depends on the format negotiated in the server_authz_request hello 288 message extensions. 290 struct { 291 server_authz_data AuthorizationData; 292 } ServerAuthorizationData; 294 The AuthorizationData structure is described in Section 3.3. 296 3.3. AuthorizationData Type 298 The AuthorizationData structure is defined as follows. For 299 readability, the definition of AuthzDataFormat is repeated from 300 section 2.3. 302 All of the entries in the authz_data_list MUST contain the same 303 authz_format value, and this value MUST match the one advertised by 304 the client in the extended hello message extension. 306 struct{ 307 AuthorizationDataEntry authz_data_list<1..2^16-1>; 308 } AuthorizationData; 310 struct { 311 AuthzDataFormat authz_format; 312 select (authz_format) { 313 case x509_attr_cert: X509AttrCert; 314 case saml_assertion: SAMLAssertion; 315 } authz_data_entry; 316 } AuthorizationDataEntry; 317 enum{ 318 x509_attr_cert(0), saml_assertion(1), (255) 319 } AuthzDataFormat; 321 opaque X509AttrCert<1..2^16-1>; 323 opaque SAMLAssertion<1..2^16-1>; 325 When X509AttrCert is used, the field contains an ASN.1 DER-encoded 326 X.509 Attribute Certificate (AC) that follows the profile in RFC 3281 327 [ATTRCERT]. An AC is a structure similar to a public key certificate 328 (PKC); the main difference being that the AC contains no public key. 329 An AC may contain attributes that specify group membership, role, 330 security clearance, or other authorization information associated 331 with the AC holder. 333 When SAMLAssertion is used, the field contains XML constructs with a 334 nested structure defined in [SAML]. SAML is an XML-based framework 335 for exchanging security information. This security information is 336 expressed in the form of assertions about subjects, where a subject 337 is either human or computer with an identity. In this context, the 338 assertions are most likely to convey authorization decisions about 339 whether subjects are allowed to access certain resources. Assertions 340 are issued by SAML authorities, namely, authentication authorities, 341 attribute authorities, and policy decision points. 343 4. IANA Considerations 345 IANA needs to assign two TLS Extension Types: client_authz_request, 346 and server_authz_request. 348 IANA needs to assign two TLS Handshake Message Types: 349 client_authz_data, and server_authz_data. 351 IANA needs to establish a registry for TLS Authorization Data 352 Formats. The first two entries in the registry are x509_attr_cert(0) 353 and saml_assertion(1). TLS Authorization Data Format identifiers 354 with values in the inclusive range 0-63 (decimal) are assigned via 355 RFC 2434 [IANA] Standards Action. Values from the inclusive range 356 64-223 (decimal) are assigned via RFC 2434 Specification Required. 357 Values from the inclusive range 224-255 (decimal) are reserved for 358 RFC 2434 Private Use. 360 5. Security Considerations 362 A TLS server can support more than one application, and each 363 application may include several features, each of which requires 364 separate authorization checks. This is the reason that more than one 365 piece of authorization information can be provided. 367 A TLS server that requires different authorization information for 368 different applications or different application features may find 369 that a client has provided sufficient authorization information to 370 grant access to a subset of these offerings. In this situation the 371 TLS Handshake protocol will complete successfully; however, the 372 server must ensure that the client will only be able to use the 373 appropriate applications and application features. That is, the TLS 374 server must deny access to the applications and application features 375 for which authorization has not been confirmed. 377 6. Normative References 379 [ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute 380 Certificate Profile for Authorization", RFC 3281, 381 April 2002. 383 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing 384 an IANA Considerations Section in RFCs", RFC 3434, 385 October 1998. 387 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", 388 RFC 2246, January 1999. 390 [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security 391 (TLS) Protocol, Version 1.1", RFC 4346, February 2006. 393 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 394 and T. Wright, "Transport Layer Security (TLS) Extensions", 395 RFC 3546, June 2003. 397 [SAML] Organization for the Advancement of Structured Information 398 Standards, "Security Assertion Markup Language (SAML), 399 version 1.1", September 2003. [Version 2.0 is out for 400 public comment; it will replace this reference if approved.] 402 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 Author's Address 407 Mark Brown 408 RedPhone Security 409 2019 Palace Avenue 410 Saint Paul, MN 55105 411 USA 412 mark redphonesecurity com 414 Russell Housley 415 Vigil Security, LLC 416 918 Spring Knoll Drive 417 Herndon, VA 20170 418 USA 419 housley vigilsec com 421 Full Copyright Statement 423 Copyright (C) The Internet Society (2006). This document is subject 424 to the rights, licenses and restrictions contained in BCP 78, and 425 except as set forth therein, the authors retain all their rights. 427 This document and translations of it may be copied and furnished to 428 others, and derivative works that comment on or otherwise explain it 429 or assist in its implementation may be prepared, copied, published 430 and distributed, in whole or in part, without restriction of any 431 kind, provided that the above copyright notice and this paragraph are 432 included on all such copies and derivative works. However, this 433 document itself may not be modified in any way, such as by removing 434 the copyright notice or references to the Internet Society or other 435 Internet organizations, except as needed for the purpose of 436 developing Internet standards in which case the procedures for 437 copyrights defined in the Internet Standards process must be 438 followed, or as required to translate it into languages other than 439 English. 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 444 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 445 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 446 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.