idnits 2.17.1 draft-housley-tls-authz-extns-05.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 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 703. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 659), 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. 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 4 instances of too long lines in the document, the longest one being 3 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 583, but not defined -- Looks like a reference, but probably isn't: '20' on line 368 -- Looks like a reference, but probably isn't: '32' on line 370 ** Obsolete normative reference: RFC 3281 (ref. 'ATTRCERT') (Obsoleted by RFC 5755) ** Downref: Normative reference to an Informational RFC: RFC 2704 (ref. 'KEYNOTE') ** Obsolete normative reference: RFC 3280 (ref. 'PKIX1') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT') (Obsoleted by RFC 4366) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft M. Brown 3 May 2006 RedPhone Security 4 Expires: November 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 The use of these TLS authorization extensions is especially 57 attractive when more than one application protocol can make use of 58 the same authorization information. Straightforward binding of 59 identification, authentication, and authorization information is 60 possible when all of these are handled within TLS. If each 61 application requires unique authorization information, then it might 62 best be carried within the TLS-protected application protocol. 63 However, care must be taken to ensure appropriate bindings when 64 identification, authentication, and authorization information are 65 handled at different protocol layers. 67 This document describes authorization extensions for the TLS 68 Handshake Protocol in both TLS 1.0 and TLS 1.1. These extensions 69 observe the conventions defined for TLS Extensions [TLSEXT] that make 70 use of the general extension mechanisms for the client hello message 71 and the server hello message. The extensions described in this 72 document confirm that both the client and the server support the 73 desired authorization data types. Then, if supported, authorization 74 information is exchanged in the supplemental data handshake message 75 [TLSSUPP]. 77 The authorization extensions may be used in conjunction with TLS 1.0 78 and TLS 1.1. The extensions are designed to be backwards compatible, 79 meaning that the Handshake Protocol Supplemental Data messages will 80 only contain authorization information of a particular type if the 81 client indicates support for them in the client hello message and the 82 server indicates support for them in the server hello message. 84 Clients typically know the context of the TLS session that is being 85 setup, thus the client can use the authorization extensions when they 86 are needed. Servers must accept extended client hello messages, even 87 if the server does not "understand" the all of the listed extensions. 88 However, the server will not indicate support for these "not 89 understood" extensions. Then, clients may reject communications with 90 servers that do not support the authorization extensions. 92 1.1. Conventions 94 The syntax for the authorization messages is defined using the TLS 95 Presentation Language, which is specified in Section 4 of [TLS1.0]. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [STDWORDS]. 101 1.2. Overview 103 Figure 1 illustrates the placement of the authorization extensions 104 and supplemental data messages in the full TLS handshake. 106 Client Server 108 ClientHello (w/ extensions) --------> 110 ServerHello (w/ extensions) 111 SupplementalData* 112 Certificate* 113 ServerKeyExchange* 114 CertificateRequest* 115 <-------- ServerHelloDone 116 SupplementalData* 117 Certificate* 118 ClientKeyExchange 119 CertificateVerify* 120 [ChangeCipherSpec] 121 Finished --------> 122 [ChangeCipherSpec] 123 <-------- Finished 124 Application Data <-------> Application Data 126 * Indicates optional or situation-dependent messages that 127 are not always sent. 129 [] Indicates that ChangeCipherSpec is an independent TLS 130 Protocol content type; it is not actually a TLS 131 handshake message. 133 Figure 1. Authorization data exchange in full TLS handshake 135 The ClientHello message includes an indication of the client 136 authorization data formats that are supported and an indication of 137 the server authorization data formats that are supported. The 138 ServerHello message contains similar indications, but any 139 authorization data formats that are not supported by the server are 140 not included. Both the client and the server MUST indicate support 141 for the authorization data types. If the list of mutually supported 142 authorization data formats is empty, then the ServerHello message 143 MUST NOT carry the affected extension at all. 145 2. Authorization Extension Types 147 The general extension mechanisms enable clients and servers to 148 negotiate whether to use specific extensions, and how to use specific 149 extensions. As specified in [TLSEXT], the extension format used in 150 the extended client hello message and extended server hello message 151 is repeated here for convenience: 153 struct { 154 ExtensionType extension_type; 155 opaque extension_data<0..2^16-1>; 156 } Extension; 158 The extension_type identifies a particular extension type, and the 159 extension_data contains information specific to the particular 160 extension type. 162 As specified in [TLSEXT], for all extension types, the extension type 163 MUST NOT appear in the extended server hello message unless the same 164 extension type appeared in the corresponding client hello message. 165 Clients MUST abort the handshake if they receive an extension type in 166 the extended server hello message that they did not request in the 167 associated extended client hello message. 169 When multiple extensions of different types are present in the 170 extended client hello message or the extended server hello message, 171 the extensions can appear in any order, but there MUST NOT be more 172 than one extension of the same type. 174 This document specifies the use of two new extension types: 175 client_authz and server_authz. These extension types are described 176 in Section 2.1 and Section 2.2, respectively. This specification 177 adds two new types to ExtensionType: 179 enum { 180 client_authz(TBD), server_authz(TBD), (65535) 181 } ExtensionType; 183 The authorization extensions are relevant when a session is initiated 184 and any subsequent session resumption. However, a client that 185 requests resumption of a session does not know whether the server 186 will have all of the context necessary to accept this request, and 187 therefore the client SHOULD send an extended client hello message 188 that includes the extension types associated with the authorization 189 extensions. This way, if the resumption request is denied, then the 190 authorization extensions will be negotiated as normal. 192 2.1. The client_authz Extension Type 194 Clients MUST include the client_authz extension type in the extended 195 client hello message to indicate their desire to send authorization 196 data to the server. The extension_data field indicates the format of 197 the authorization data that will be sent in the supplemental data 198 handshake message. The syntax of the client_authz extension_data 199 field is described in Section 2.3. 201 Servers that receive an extended client hello message containing the 202 client_authz extension MUST respond with the same client_authz 203 extension in the extended server hello message if the server is 204 willing to receive authorization data in the indicated format. Any 205 unacceptable formats must be removed from the list provided by the 206 client. The client_authz extension MUST be omitted from the extended 207 server hello message if the server is not willing to receive 208 authorization data in any of the indicated formats. 210 2.2. The server_authz Extension Type 212 Clients MUST include the server_authz extension type in the extended 213 client hello message to indicate their desire to receive 214 authorization data from the server. The extension_data field 215 indicates the format of the authorization data that will be sent in 216 the supplemental data handshake message. The syntax of the 217 server_authz extension_data field as described in Section 2.3. 219 Servers that receive an extended client hello message containing the 220 server_authz extension MUST respond with the same server_authz 221 extension in the extended server hello message if the server is 222 willing to provide authorization data in the requested format. Any 223 unacceptable formats must be removed from the list provided by the 224 client. The server_authz extension MUST be omitted from the extended 225 server hello message if the server is not able to provide 226 authorization data in any of the indicated formats. 228 2.3. AuthzDataFormat Type 230 The AuthzDataFormat type is used in both the client_authz and the 231 server_authz extensions. It indicates the format of the 232 authorization data that will be transferred. The 233 AuthorizationDataFormats type definition is: 235 enum { 236 x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), 237 saml_assertion_url(3), keynote_assertion_list(4), (255) 238 } AuthzDataFormat; 240 AuthorizationDataFormats authz_format_list<1..2^8-1>; 242 When the x509_attr_cert value is present, the authorization data is 243 an X.509 Attribute Certificate (AC) that conforms to the profile in 244 RFC 3281 [ATTRCERT]. 246 When the saml_assertion value is present, the authorization data is 247 an assertion composed using the Security Assertion Markup Language 248 (SAML) [SAML1.1][SAML2.0]. 250 When the x509_attr_cert_url value is present, the authorization data 251 is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT]; 252 however, the AC is fetched with the supplied URL. A one-way hash 253 value is provided to ensure that the intended AC is obtained. 255 When the saml_assertion_url value is present, the authorization data 256 is a SAML Assertion; however, the SAML Assertion is fetched with the 257 supplied URL. A one-way hash value is provided to ensure that the 258 intended SAML Assertion is obtained. 260 When the keynote_assertion_list value is present, the authorization 261 data is a list of KeyNote assertions that conforms to the profile in 262 RFC 2704 [KEYNOTE]. 264 3. Supplemental Data Handshake Message Usage 266 As shown in Figure 1, supplemental data can be exchanges in two 267 places in the handshake protocol. The client_authz extension 268 determines what authorization data formats are acceptable for 269 transfer from the client to the server, and the server_authz 270 extension determines what authorization data formats are acceptable 271 for transfer from the server to the client. In both cases, the 272 syntax specified in [TLSSUPP] is used along with the authz_data type 273 defined in this document. 275 enum { 276 authz_data(TBD), (65535) 277 } SupplementalDataType; 279 struct { 280 SupplementalDataType supplemental_data_type; 281 select(SupplementalDataType) { 282 case authz_data: AuthorizationData; 283 } 284 } SupplementalData; 286 3.1. Client Authorization Data 288 The SupplementalData message sent from the client to the server 289 contains authorization data associated with the TLS client. 290 Following the principle of least privilege, the client ought to send 291 the minimal set of authorization information necessary to accomplish 292 the task at hand. That is, only those authorizations that are 293 expected to be required by the server in order to gain access to the 294 needed server resources ought to be included. The format of the 295 authorization data depends on the format negotiated in the 296 client_authz hello message extension. The AuthorizationData 297 structure is described in Section 3.3. 299 In some systems, clients present authorization information to the 300 server, and then the server provides new authorization information. 301 This type of transaction is not supported by SupplementalData 302 messages. In cases where the client intends to request the TLS 303 server to perform authorization translation or expansion services, 304 such translation services ought to occur within the ApplicationData 305 messages, not within the TLS Handshake protocol. 307 3.2. Server Authorization Data 309 The SupplementalData message sent from the server to the client 310 contains authorization data associated with the TLS server. This 311 authorization information is expected to include statements about the 312 server's qualifications, reputation, accreditation, and so on. 313 Wherever possible, authorizations that can be misappropriated for 314 fraudulent use ought to be avoided. The format of the authorization 315 data depends on the format negotiated in the server_authz hello 316 message extensions. The AuthorizationData structure is described in 317 Section 3.3. 319 3.3. AuthorizationData Type 321 The AuthorizationData structure carried authorization information for 322 either the client or the server. The AuthzDataFormat specified in 323 Section 2.3 for use in the hello extensions is also used in this 324 structure. 326 All of the entries in the authz_data_list MUST employ authorization 327 data formats that were negotiated in the relevant hello message 328 extension. 330 struct{ 331 AuthorizationDataEntry authz_data_list<1..2^16-1>; 332 } AuthorizationData; 334 struct { 335 AuthzDataFormat authz_format; 336 select (AuthzDataFormat) { 337 case x509_attr_cert: X509AttrCert; 338 case saml_assertion: SAMLAssertion; 339 case x509_attr_cert_url: URLandHash; 340 case saml_assertion_url: URLandHash; 341 case keynote_assertion_list: KeyNoteAssertionList; 342 } 343 } AuthorizationDataEntry; 345 enum { 346 x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2), 347 saml_assertion_url(3), keynote_assertion_list(4), (255) 348 } AuthzDataFormat; 350 opaque X509AttrCert<1..2^16-1>; 352 opaque SAMLAssertion<1..2^16-1>; 354 opaque KeyNoteAssertionList<1..2^16-1>; 356 struct { 357 opaque url<1..2^16-1>; 358 HashType hash_type; 359 select (hash_type) { 360 case sha1: SHA1Hash; 361 case sha256: SHA256Hash; 362 } hash; 363 } URLandHash; 364 enum { 365 sha1(0), sha256(1), (255) 366 } HashType; 368 opaque SHA1Hash[20]; 370 opaque SHA256Hash[32]; 372 3.3.1. X.509 Attribute Certificate 374 When X509AttrCert is used, the field contains an ASN.1 DER-encoded 375 X.509 Attribute Certificate (AC) that follows the profile in RFC 3281 376 [ATTRCERT]. An AC is a structure similar to a public key certificate 377 (PKC) [PKIX1]; the main difference being that the AC contains no 378 public key. An AC may contain attributes that specify group 379 membership, role, security clearance, or other authorization 380 information associated with the AC holder. 382 When making an authorization decision based on an AC, proper linkage 383 between the AC holder and the public key certificate that is 384 transferred in the TLS Certificate message is needed. The AC holder 385 field provides this linkage. The holder field is a SEQUENCE allowing 386 three different (optional) syntaxes: baseCertificateID, entityName 387 and objectDigestInfo. In the TLS authorization context, the holder 388 field MUST use the either baseCertificateID or entityName. In the 389 baseCertificateID case, the baseCertificateID field MUST match the 390 issuer and serialNumber fields in the certificate. In the entityName 391 case, the entityName MUST be the same as the subject field in the 392 certificate or one of the subjectAltName extension values in the 393 certificate. Note that [PKIX1] mandates that the subjectAltName 394 extension be present if the subject field contains an empty 395 distinguished name. 397 3.3.2. SAML Assertion 399 When SAMLAssertion is used, the field contains XML constructs with a 400 nested structure defined in [SAML1.1][SAML2.0]. SAML is an XML-based 401 framework for exchanging security information. This security 402 information is expressed in the form of assertions about subjects, 403 where a subject is either human or computer with an identity. In 404 this context, the SAML assertions are most likely to convey 405 authentication or attribute statements to be used as input to 406 authorization policy governing whether subjects are allowed to access 407 certain resources. Assertions are issued by SAML authorities. 409 When making an authorization decision based on a SAML assertion, 410 proper linkage between the SAML assertion and the public key 411 certificate that is transferred in the TLS Certificate message may be 412 needed. A "Holder of Key" subject confirmation method in the SAML 413 assertion can provide this linkage. In other scenarios, it may be 414 acceptable to use alternate confirmation methods that do not provide 415 a strong binding, such as a bearer mechanism. SAML assertion 416 recipients MUST decide which subject confirmation methods are 417 acceptable; such decisions MAY be specific to the SAML assertion 418 contents and the TLS session context. 420 There is no general requirement that the subject of the SAML 421 assertion correspond directly to the subject of the certificate. 422 They may represent the same or different entities. When they are 423 different, SAML also provides a mechanism by which the certificate 424 subject can be identified separately from the subject in the SAML 425 assertion subject confirmation method. 427 Since the SAML assertion is being provided at a part of the TLS 428 Handshake that is unencrypted, an eavesdropper could replay the same 429 SAML assertion when they establish their own TLS session. This is 430 especially important when a bearer mechanism is employed, the 431 recipient of the SAML assertion assumes that the sender is an 432 acceptable attesting entity for the SAML assertion. Some constraints 433 may be included to limit the context where the bearer mechanism will 434 be accepted. For example, the period of time that the SAML assertion 435 can be short-lived (often minutes), the source address can be 436 constrained, or the destination endpoint can be identified. Also, 437 bearer assertions are often checked against a cache of SAML assertion 438 unique identifiers that were recently received in order to detect 439 replay. This is an appropriate countermeasure if the bearer 440 assertion is intended to be used just once. Section 5 provides a way 441 to protect authorization information when necessary. 443 3.3.3. URL and Hash 445 Since the X.509 AC and SAML assertion can be large, alternatives 446 provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML 447 Assertion. To ensure that the intended object is obtained, a one-way 448 hash value of the object is also included. Integrity of this one-way 449 hash value is provided by the TLS Finished message. 451 Implementations that support either x509_attr_cert_url or 452 saml_assertion_url MUST support URLs that employ the http scheme. 453 Other schemes may also be supported; however, to avoid circular 454 dependencies, supported schemes SHOULD NOT themselves make use of 455 TLS, such as the https scheme. 457 Implementations that support either x509_attr_cert_url or 458 saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2] 459 as one-way hash functions. Other one-way hash functions may also be 460 supported. Additional one-way hash functions can be registered in 461 the future using the procedures in section 3. 463 3.3.4. KeyNote Assertion List 465 When KeyNoteAssertion List is used, the field contains an ASCII- 466 encoded list of signed KeyNote assertions, as described in RFC 2704 467 [KEYNOTE]. The assertions are separated by two '\n' (newline) 468 characters. A KeyNote assertion is a structure similar to a public 469 key certificate; the main difference is that instead of a binding 470 between a name and a public key, KeyNote assertions bind public keys 471 to authorization rules that are evaluated by the peer when the sender 472 later issues specific requests. 474 When making an authorization decision based on a list of KeyNote 475 assertions, proper linkage between the KeyNote assertions and the 476 public key certificate that is transferred in the TLS Certificate 477 message is needed. Receivers of a KeyNote assertion list should 478 initialize the ACTION_AUTHORIZER variable to be the sender's public 479 key, which was used to authenticate the TLS exchange. 481 4. IANA Considerations 483 This document defines a two TLS extensions: client_authz(TBD) and 484 server_authz(TBD). These extension type values are assigned from the 485 TLS Extension Type registry defined in [TLSEXT]. 487 This document defines one TLS supplemental data type: 488 authz_data(TBD). This supplemental data type is assigned from the 489 TLS Supplemental Data Type registry defined in [TLSSUPP]. 491 This document establishes a new registry, to be maintained by IANA, 492 for TLS Authorization Data Formats. The first five entries in the 493 registry are x509_attr_cert(0), saml_assertion(1), 494 x509_attr_cert_url(2), saml_assertion_url(3), and 495 keynote_assertion_list(4). TLS Authorization Data Format identifiers 496 with values in the inclusive range 0-63 (decimal) are assigned via 497 RFC 2434 [IANA] Standards Action. Values from the inclusive range 498 64-223 (decimal) are assigned via RFC 2434 Specification Required. 499 Values from the inclusive range 224-255 (decimal) are reserved for 500 RFC 2434 Private Use. 502 This document establishes a new registry, to be maintained by IANA, 503 for TLS Hash Types. The first two entries in the registry are 504 sha1(0) and sha256(1). TLS Hash Type identifiers with values in the 505 inclusive range 0-158 (decimal) are assigned via RFC 2434 [IANA] 506 Standards Action. Values from the inclusive range 159-223 (decimal) 507 are assigned via RFC 2434 Specification Required. Values from the 508 inclusive range 224-255 (decimal) are reserved for RFC 2434 Private 509 Use. 511 5. Security Considerations 513 A TLS server can support more than one application, and each 514 application may include several features, each of which requires 515 separate authorization checks. This is the reason that more than one 516 piece of authorization information can be provided. 518 A TLS server that requires different authorization information for 519 different applications or different application features may find 520 that a client has provided sufficient authorization information to 521 grant access to a subset of these offerings. In this situation the 522 TLS Handshake protocol will complete successfully; however, the 523 server must ensure that the client will only be able to use the 524 appropriate applications and application features. That is, the TLS 525 server must deny access to the applications and application features 526 for which authorization has not been confirmed. 528 In many cases, the authorization information is itself sensitive. 529 The double handshake technique can be used to provide protection for 530 the authorization information. Figure 2 illustrates the double 531 handshake, where the initial handshake does not include any 532 authorization extensions, but it does result in protected 533 communications. Then, a second handshake that includes the 534 authorization information is performed using the protected 535 communications. In Figure 2, the number on the right side indicates 536 the amount of protection for the TLS message on that line. A zero 537 (0) indicates that there is no communication protection; a one (1) 538 indicates that protection is provided by the first TLS session; and a 539 two (2) indicates that protection is provided by both TLS sessions. 541 The placement of the SupplementalData message in the TLS Handshake 542 results in the server providing its authorization information before 543 the client is authenticated. In many situations, servers will not 544 want to provide authorization information until the client is 545 authenticated. The double handshake illustrated in Figure 2 provides 546 a technique to ensure that the parties are mutually authenticated 547 before either party provides authorization information. 549 6. Acknowledgement 551 The authors thank Scott Cantor for his assistance with the SAML 552 Assertion portion of the document and Angelos Keromytis for his 553 assistance with the KeyNote portion of the document. 555 Client Server 557 ClientHello (no extensions) --------> |0 558 ServerHello (no extensions) |0 559 Certificate* |0 560 ServerKeyExchange* |0 561 CertificateRequest* |0 562 <-------- ServerHelloDone |0 563 Certificate* |0 564 ClientKeyExchange |0 565 CertificateVerify* |0 566 [ChangeCipherSpec] |0 567 Finished --------> |1 568 [ChangeCipherSpec] |0 569 <-------- Finished |1 570 ClientHello (w/ extensions) --------> |1 571 ServerHello (w/ extensions) |1 572 SupplementalData (w/ authz data)* |1 573 Certificate* |1 574 ServerKeyExchange* |1 575 CertificateRequest* |1 576 <-------- ServerHelloDone |1 577 SupplementalData (w/ authz data)* |1 578 Certificate* |1 579 ClientKeyExchange |1 580 CertificateVerify* |1 581 [ChangeCipherSpec] |1 582 Finished --------> |2 583 [ChangeCipherSpec] |1 584 <-------- Finished |2 585 Application Data <-------> Application Data |2 587 Figure 2. Double Handshake to Protect Authorization Data 589 7. Normative References 591 [ATTRCERT] Farrell, S., and R. Housley, "An Internet Attribute 592 Certificate Profile for Authorization", RFC 3281, 593 April 2002. 595 [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing 596 an IANA Considerations Section in RFCs", RFC 3434, 597 October 1998. 599 [KEYNOTE] Blaze, M., Feigenbaum, J., Ioannidis, J., and 600 A. Keromytis, "The KeyNote Trust-Management System, 601 Version 2", RFC 2704, September 1999. 603 [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 604 X.509 Public Key Infrastructure Certificate and 605 Certificate Revocation List (CRL) Profile", RFC 3280, 606 April 2002. 608 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", 609 RFC 2246, January 1999. 611 [TLS1.1] Dierks, T., and E. Rescorla, "The Transport Layer Security 612 (TLS) Protocol, Version 1.1", RFC 4346, February 2006. 614 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 615 and T. Wright, "Transport Layer Security (TLS) Extensions", 616 RFC 3546, June 2003. 618 [TLSSUPP] Santesson, S., " TLS Handshake Message for Supplemental 619 Data", work in progress: draft-santesson-tls-supp, 620 March 2006. 622 [SAML1.1] OASIS Security Services Technical Committee, "Security 623 Assertion Markup Language (SAML) Version 1.1 624 Specification Set", September 2003. 626 [SAML2.0] OASIS Security Services Technical Committee, "Security 627 Assertion Markup Language (SAML) Version 2.0 628 Specification Set", March2005. 630 [SHA1] National Institute of Standards and Technology (NIST), 631 FIPS PUB 180-1, Secure Hash Standard, 17 April 1995. 633 [SHA2] National Institute of Standards and Technology (NIST), 634 FIPS PUB 180-2: Secure Hash Standard, 1 August 2002. 636 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 Author's Address 641 Mark Brown 642 RedPhone Security 643 2019 Palace Avenue 644 Saint Paul, MN 55105 645 USA 646 mark redphonesecurity com 648 Russell Housley 649 Vigil Security, LLC 650 918 Spring Knoll Drive 651 Herndon, VA 20170 652 USA 653 housley vigilsec com 655 Full Copyright Statement 657 Copyright (C) The Internet Society (2006). This document is subject 658 to the rights, licenses and restrictions contained in BCP 78, and 659 except as set forth therein, the authors retain all their rights. 661 This document and translations of it may be copied and furnished to 662 others, and derivative works that comment on or otherwise explain it 663 or assist in its implementation may be prepared, copied, published 664 and distributed, in whole or in part, without restriction of any 665 kind, provided that the above copyright notice and this paragraph are 666 included on all such copies and derivative works. However, this 667 document itself may not be modified in any way, such as by removing 668 the copyright notice or references to the Internet Society or other 669 Internet organizations, except as needed for the purpose of 670 developing Internet standards in which case the procedures for 671 copyrights defined in the Internet Standards process must be 672 followed, or as required to translate it into languages other than 673 English. 675 This document and the information contained herein are provided on an 676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 678 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 679 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 680 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 683 The IETF takes no position regarding the validity or scope of any 684 Intellectual Property Rights or other rights that might be claimed to 685 pertain to the implementation or use of the technology described in 686 this document or the extent to which any license under such rights 687 might or might not be available; nor does it represent that it has 688 made any independent effort to identify any such rights. Information 689 on the procedures with respect to rights in RFC documents can be 690 found in BCP 78 and BCP 79. 692 Copies of IPR disclosures made to the IETF Secretariat and any 693 assurances of licenses to be made available, or the result of an 694 attempt made to obtain a general license or permission for the use of 695 such proprietary rights by implementers or users of this 696 specification can be obtained from the IETF on-line IPR repository at 697 http://www.ietf.org/ipr. 699 The IETF invites any interested party to bring to its attention any 700 copyrights, patents or patent applications, or other proprietary 701 rights that may cover technology that may be required to implement 702 this standard. Please address the information to the IETF at 703 ietf-ipr@ietf.org.