1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft Microsoft Corporation 5Intended status: Standards Track J. Altman 6Expires: May 7, 2009 Secure Endpoints 7 N. Williams 8 Sun 9 November 3, 2008 10 11 12 Public Key Cryptography Based User-to-User Authentication - (PKU2U) 13 draft-zhu-pku2u-09 14 15Status of this Memo 16 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 26 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 31 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 34 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 37 38 This Internet-Draft will expire on May 7, 2009. 39 40Abstract 41 42 This document defines a Generic Security Services Application Program 43 Interface (GSS-API) mechanism based on Public Key Infrastructure 44 (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the 45 Kerberos V GSS-API mechanism, but without requiring a Kerberos Key 46 Distribution Center (KDC). 47 48 49 50 51 52 53 54Zhu, et al. Expires May 7, 2009 [Page 1] 55 56Internet-Draft PKU2U November 2008 57 58 59Table of Contents 60 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 63 3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3 64 4. The NULL Principal Name . . . . . . . . . . . . . . . . . . . 4 65 5. PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . . 4 66 5.1. GSS_C_NT_DN . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.2. GSS_C_NT_HOSTNAME . . . . . . . . . . . . . . . . . . . . 6 68 5.3. GSS_C_NT_EMAIL_ADDR . . . . . . . . . . . . . . . . . . . 7 69 5.4. GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . . 7 70 5.5. GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . . 9 71 5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based 72 Principal Names to Acceptor Certificates . . . . . . . . . 9 73 6. The Protocol Description and the Context Establishment 74 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Context Token Derived from KRB_AS_REQ . . . . . . . . . . 12 76 6.2. Context Token Derived from KRB_AS_REP . . . . . . . . . . 15 77 6.3. Context Tokens Imported from RFC4121 . . . . . . . . . . . 16 78 7. Guidelines for Credentials Selection . . . . . . . . . . . . . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 84 Intellectual Property and Copyright Statements . . . . . . . . . . 23 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110Zhu, et al. Expires May 7, 2009 [Page 2] 111 112Internet-Draft PKU2U November 2008 113 114 1151. Introduction 116 117 The Generic Security Services Application Programming Interface (GSS- 118 API) is a generic protocol and API for providing authentication and 119 session protection to applications. It is generic in that it 120 supports multiple authentication mechanisms. Today there exists only 121 one workable, widely deployed, standards-track GSS-API mechanism: the 122 Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on 123 Kerberos V [RFC4120]. There is a need to provide a GSS-API mechanism 124 which does not require Kerberos V Key Distribution Center (KDC) 125 infrastructure, and which supports the use of public key 126 cryptography, particularly Public Key Infrastructure (PKI) [RFC5280], 127 including the use of public key certificates without a PKI. 128 129 This document specifies such a mechanism: the Public Key User to User 130 mechanism (PKU2U). 131 132 PKU2U is based on building blocks taken from Kerberos V [RFC4120], 133 PKINIT, [RFC4556] (which in turn uses PKI [RFC5280]) building 134 blocks), and the Kerberos V GSS-API mechanism [RFC1964] [RFC4121]. 135 In spite of using Kerberos V building blocks, PKU2U does not require 136 any Kerberos V KDC infrastructure. And though PKU2U also uses PKI 137 building blocks, PKU2U can be used without a PKI by pre-sharing 138 certificates and/or pre-associating name/certificate bindings. 139 140 Therefore PKU2U can be used for true peer-to-peer authentication, as 141 well as for PKI-based authentication. 142 143 1442. Conventions Used in This Document 145 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 149 150 In this document, the GSS-API initiator or acceptor is referred to as 151 the peer when the description is applicable to both the initiator and 152 the acceptor. 153 154 1553. The PKU2U Realm Name 156 157 The PKU2U realm name is defined as a reserved Kerberos realm name per 158 [KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U". 159 160 The PKU2U realm name has no meaning, but is intended to be used in 161 the Kebreros V Protocol Data Units (PDUs) that are re-used by PKU2U 162 wherever realm names are needed. Unless otherwise specified, the 163 164 165 166Zhu, et al. Expires May 7, 2009 [Page 3] 167 168Internet-Draft PKU2U November 2008 169 170 171 realm name in any Kerberos message used by PKU2U is the PKU2U realm 172 name. 173 174 1754. The NULL Principal Name 176 177 The NULL Kerberos principal name is defined as a well-known Kerberos 178 principal name based on [KRB-NAMING]. The value of the name-type 179 field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name- 180 string field is a sequence of two KerberosString components: 181 "WELLKNOWN", "NULL". 182 183 The NULL Kerberos principal name is used in the Kerberos messages 184 where there is no Kerberos representation of the principal name, for 185 example, when the client name is a Distinguished Name. When the NULL 186 principal name is used in the Kerberos messages, the principal name 187 is either not used or provided separately (for example in the 188 PA_PKU2U_NAME padata defined in Section 6.1). 189 190 1915. PKU2U Principal Naming 192 193 The GSS-API targ_name supplied for the initiator MUST NOT be 194 GSS_C_NO_NAME in PKU2U. 195 196 PKU2U principal names can be Kerberos principal names, and they can 197 also be distiguished names, or subject alternative names [RFC5280] as 198 they appear in the certificate of any PKU2U peer, as well as any 199 names agreed to out of band that do not appear in the peer 200 certificates. 201 202 Certificates may be associated with multiple principal names. This 203 presents problems for the GSS-API bindings of a PKI-based mechanism 204 because, for example, for any given, established GSS-API security 205 mechanism there can be only one initiator name, and one acceptor 206 name, and credential handles may be associated with only one name. 207 We resolve these problems as follows: 208 209 o We define multiple GSS-API name types corresponding to several 210 GeneralName choices [RFC5280], along with syntaxes, display forms, 211 and exported name token formats for each. For most of the name- 212 types listed below the exported name token formats consists of a 213 GeneralName with the usual exported name token header as per- 214 RFC2743. Two name-types are shared with the Kerberos V mechanism 215 and use the Kerberos V mechanism's query and display syntaxes, 216 canonicalization rules, and exported name token format. 217 218 219 220 221 222Zhu, et al. Expires May 7, 2009 [Page 4] 223 224Internet-Draft PKU2U November 2008 225 226 227 o The cred_name of a credential handle acquired with 228 GSS_C_NT_NO_NAME as the desired_name SHOULD be the Distinguished 229 Name (DN) of the certificate underlying the credential. If there 230 are multiple certificates and private keys, then either one MUST 231 be selected by local, implementation-specific means, or credential 232 acquisition with GSS_C_NT_NO_NAME MUST fail (implementers may 233 choose which of these two behaviors to provide). 234 235 o When using desired_name values other than GSS_C_NT_NO_NAME for 236 credential handle acquisition then the implementation MUST use 237 exact matching of the given desired_name to a certificate's DN or 238 Subject Alternative Names (SANs) for all name-types given below, 239 except for GSS_C_NT_DN, where matching rules are fuzzier and given 240 below. The names of a X.509 certificate will be compared to the 241 given desired_name in this order: certificate DN first, then SANs 242 in the order in which they appear in the certificate. When 243 multiple certificates and private keys are available the order in 244 which the various certificates are searched is significant; no 245 canonical certificate collation order is defined herein. 246 247 o The cred_name of a credential object acquired with a desired_name 248 other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or 249 SAN matched by the given desired_name. 250 251 o We provide a method (see below) by which initiators can assert, in 252 their context tokens, one of these names of the initiator. We 253 also provide a method of asserting names that do not appear in a 254 X.509 certificate, in which case the binding of X.509 certificate 255 to the asserted name is done out-of band. The name to be 256 asserted, of course, is the cred_name of the cred_handle passed to 257 GSS_Init_sec_context(). 258 259 o The initiator's context tokens may also indicate what is the 260 expected name of the acceptor -- the targ_name passed in to 261 GSS_Init_sec_context(). 262 263 o No attempt is made to map Kerberos V realm names to trust anchor 264 certificate authority (CA) names. 265 266 o We provide a method of matching host-based service principal names 267 to acceptor certificates, so that: a) initiators need not know the 268 particulars of an acceptor's certificates' names a priori, b) 269 acceptors can select a credential to accept a security context 270 with that the initiator will accept, c) existing certificates for 271 web servers, may be used as host-based service principal names as 272 though the service name were "HTTP". 273 274 Thus GSS-API initiator applications that use the GSS_C_NO_NAME as the 275 276 277 278Zhu, et al. Expires May 7, 2009 [Page 5] 279 280Internet-Draft PKU2U November 2008 281 282 283 desired_name arguments of GSS_Acquire_cred() and GSS_Add_cred(), or 284 GSS_C_NO_CREDENTIAL as the cred argument of GSS_Init_sec_context() 285 will assert the selected X.509 certificate's subject DN, and that 286 X.509 certificate's subject DN will be the name returned by 287 GSS_Inquire_cred() and GSS_Inquire_cred_by_mech(). 288 289 And portable GSS-API initiator applications using 290 GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing 291 a name to use as the targ_name input argument of 292 GSS_Init_sec_context()) will have a reasonable chance of success in 293 authenticating peers with X.509 certificates predating this 294 specification. 295 2965.1. GSS_C_NT_DN 297 298 The name type GSS_C_NT_DN, with Object Identifier (OID) <TBD> (see 299 Section 10), is defined. This corresponds to the 'directoryName' 300 choice of the 'GeneralName' Abstract Syntax Notation One (ASN.1) 301 [CCITT.X680.2002] type defined in [RFC5280]. 302 303 The query syntax and display form for names of this type SHALL be as 304 described in [RFC4514]. 305 306 As RFC4514 says, "[c]omparison of DNs for equality is to be performed 307 in accordance with the distinguishedNameMatch matching rule 308 [RFC4517]". 309 310 There is no reasonable way to canonicalize names of this type without 311 providing certificates to match query forms of GSS_C_NT_DN against, 312 such as in the form of a directory. Therefore 313 GSS_Canonicalize_name() as applied to names imported with the 314 GSS_C_NT_DN name-type MUST search available certificate databases, or 315 directories, or MUST fail. No method of locating and searching 316 directories for matching certificate DNs is specified herein. Note 317 though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context() 318 can and, indeed, MUST return "mechanism names" (MN) (see [RFC2743]). 319 320 The exported name token format for names of this type SHALL be the 321 Distinguished Encoding Rules (DER) [CCITT.X680.2002] 322 [CCITT.X690.2002] encoding of a GeneralName with directoryName as the 323 choice. 324 325 Implementation support for this name type is REQUIRED. 326 3275.2. GSS_C_NT_HOSTNAME 328 329 The name type GSS_C_NT_HOSTNAME, with OID <TBD>, is defined. This 330 corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type 331 332 333 334Zhu, et al. Expires May 7, 2009 [Page 6] 335 336Internet-Draft PKU2U November 2008 337 338 339 defined in [RFC5280]. 340 341 The query syntax for names of this type SHALL be a DNS name [RFC1034] 342 in either ACE or Unicode form [RFC3490]. 343 344 The display and canonical form of names of this type SHALL be a DNS 345 domain name in ACE form, with character case folded down. 346 Canonicalization consists merely of applying the ToASCII() function 347 and case-folding the result. 348 349 The exported name token format for names of this type SHALL be the 350 DER encoding of a GeneralName with dNSName as the choice and the DNS 351 domain name in ACE form and case folded down. 352 353 Implementation support for this name type is OPTIONAL. 354 3555.3. GSS_C_NT_EMAIL_ADDR 356 357 The name type GSS_C_NT_EMAIL_ADDR, with OID <TBD>, is defined. This 358 corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1 359 type defined in [RFC5280]. 360 361 The query syntax and display form for names of this type SHALL be the 362 text representation of an 'addr-spec' as defined in [RFC0822]. 363 364 The canonical form of names of this type SHALL be the query form with 365 case folded down. Note that the domain name part of an addr-spec is 366 a "domain name slot" and so the canonicalization rules for 367 GSS_C_NT_HOSTNAME given above apply here as well. 368 369 The exported name token form for this name type SHALL be the DER- 370 encoding of a GeneralName with the rfc822Name choice. 371 372 Implementation support for this name type is OPTIONAL. 373 3745.4. GSS_KRB5_NT_PRINCIPAL_NAME 375 376 PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964]. 377 378 The query, display, canonical and exported name token forms of names 379 of this type SHALL be as specified in RFC4121. The realm name part 380 of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax; 381 when canonicalized, names of this type lacking a realm name will have 382 the well-known PKU2U realm name affixed. 383 384 When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted 385 or otherwise is the well-known PKU2U realm name, then the "cname"' or 386 sname fields of the Kerberos V PDUs used to construct PKU2U security 387 388 389 390Zhu, et al. Expires May 7, 2009 [Page 7] 391 392Internet-Draft PKU2U November 2008 393 394 395 context tokens MUST be set to the principal name part of the given 396 NAME. Otherwise the PA_PKU2U_NAME pre-authentication data MUST be 397 used to indicate a name of id-pkinit-san type [RFC4556] corresponding 398 to the given NAME. See Section 5.4. 399 400 No attempt is made to map Kerberos V realm names to trust anchor 401 certificate authority (CA) names. 402 403 Note that having more than one mechanism share name-types has 404 implications for multi-mechanism, pluggable GSS-API implementations 405 (commonly referred to as "mechglue"). Specifically: 406 407 o It must be the responsibility of the mechanism, not of the 408 mechglue, to ensure that the standard exported name token header 409 (which includes a mechanism OID), is included in exported name 410 tokens. The exported name token for a GSS_KRB5_NT_PRINCIPAL_NAME 411 MN produced by PKU2U would have PKU2U's mechanism OID in the 412 header. 413 414 o A pluggable mechglue must be able to find a mechanism that can 415 import an exported name token if an available mechanism can 416 produce that exported name token. For example, a pluggable 417 mechglue where PKU2U is available but where the Kerberos V 418 mechanism [RFC1964] is not should still be able to import exported 419 Kerberos V name tokens since PKU2U can create such tokens. One 420 way to do this would be for the mechglue to try the mechanism 421 named in the exported name token header, if it is available, else 422 try all other available mechanisms until one succeeds or all fail. 423 It would be reasonable for a mechglue implementer to require that 424 the Kerberos V mechanism be available if PKU2U is too. 425 426 o It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use 427 a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name 428 argument value to acquire a PKU2U credential. Similarly, it must 429 be possible to use a Kerberos V MN as the target_name in a call to 430 GSS_Init_sec_context with PKU2U as the mech OID. A multi- 431 mechanism mechglue implementer would likely have a mechglue-layer 432 NAME object that internally keeps a reference to a NAME object 433 produced by the underlying mechanism, but a pluggable mechglue 434 could not expect two different mechanisms to be able to share 435 their internal NAME objects. A clever implementer can work around 436 this by exporting the one mechanism's MN and then re-importing 437 using the target mechanism's GSS_Import_name() service function. 438 439 o It must be possible for the credential inquiry functions (e.g., 440 GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a 441 cred_name that is an MN of a different mechanism than the 442 credential element being inquired. 443 444 445 446Zhu, et al. Expires May 7, 2009 [Page 8] 447 448Internet-Draft PKU2U November 2008 449 450 451 Implementation support for this name type, with defaulted realm name 452 or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use 453 with any other realm names. 454 4555.5. GSS_C_NT_ANONYMOUS 456 457 This is a generic GSS-API name-type. Implementation support for this 458 name type is OPTIONAL. See Section 6.1 for more information. 459 460 See [RFC2743] and [RFC2744] for more information about this name 461 type. 462 463 The PKU2U mechanism only supports anonymous initiators, not 464 acceptors. 465 466 Implementation support for this name type is RECOMMENDED. 467 4685.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based Principal Names 469 to Acceptor Certificates 470 471 Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described 472 herein. 473 474 The query form of this name type is as per-RFC2743. The canonical 475 and exported name token forms are as per-RFC1964. The display form 476 of this name type is left unspecified, but should either be as per- 477 RFC2743 or the same as the display form for 478 GSS_KRB5_NT_PRINCIPAL_NAME [RFC1964]. 479 480 Initiators using names of type GSS_C_NT_HOSTBASED_SERVICE to identify 481 target acceptors represent these names as Kerberos V principal names 482 as per [RFC1964] but with a well-known realm name of "WELLKNOWN: 483 PKU2U" (see Section 5.4). 484 485 Acceptors match such names to acceptor certificates as follows. 486 Initiators then match the certificate chosen by the acceptor in the 487 same manner. 488 489 Initiators can also assert host-based service names as the initiator 490 name. In this case acceptors MUST also apply the matching rules 491 below, in order, to validate the initiator's assertion. 492 493 1. If there is an out-of-band binding of the peer's host-based 494 service name to its certificate, then the certificate matches. 495 496 2. If the peer has a certificate with an id-pkinit-san subject 497 alternative name matching the initiator-provided acceptor name, 498 then the X.509 certificate matches. 499 500 501 502Zhu, et al. Expires May 7, 2009 [Page 9] 503 504Internet-Draft PKU2U November 2008 505 506 507 3. If a X.509 certificate has a dNSName SAN that matches the 508 hostname part of the host-based service principal name, and 509 either the anyExtendedKeyUsage extended key usage (EKU), or no 510 EKU is present, or an EKU is present which corresponds to the 511 service part of the host-based service principal name, then the 512 X.509 certificate matches. The id-kp-serverAuth EKU SHALL be 513 considered to match the 'HTTP' service name. (See Section 10, 514 IANA considerations, where the GSS-API service name registry is 515 extended to include an EKU for each service name.) 516 517 4. Implementations SHOULD, subject to local configuration, allow 518 matches where the single-component cn of the DN of a X.509 519 certificate matches the hostname part of the host-based service 520 name, for some or all service names. This feature is needed to 521 allow the use of existing X.509 web certificates. 522 523 Implementation support for this name type as an acceptor name is 524 REQUIRED. Implementation support for this name type as an initiator 525 name is OPTIONAL. 526 527 5286. The Protocol Description and the Context Establishment Tokens 529 530 The PKU2U mechanism is a GSS-API mechanism based on [RFC4120], 531 [RFC4556] and [RFC4121]. 532 533 The per-message tokens of the PKU2U mechanism are the same as those 534 of the Kerberos V GSS-API mechanism [RFC4121]. 535 536 The GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same 537 as that of the Kerberos V GSS-API mechanism [RFC4402]. 538 539 The PKU2U security context token exchange consists of KRB_AS_REQ and 540 KRB_AS_REP (and KRB_ERROR) Kerberos KDC PDUs (with no changes to 541 their ASN.1 description, but with other minor changes/requirements 542 described below) as context tokens, with the acceptor as the KDC, 543 followed by context tokens from [RFC4121] using the Kerberos V Ticket 544 PDU issued by the acceptor-as-KDC. PKINIT [RFC4556] is the only 545 acceptable pre-authentication method in this document. Caching the 546 ticket issued by the acceptor allows subsequent security context 547 exchanges between the same to peers to use a single context token 548 round-trip -- a "fast reconnect" feature. 549 550 PKU2U differs from Kerberos V with PKINIT in several minor ways as 551 follows (this is not a complete list): 552 553 554 555 556 557 558Zhu, et al. Expires May 7, 2009 [Page 10] 559 560Internet-Draft PKU2U November 2008 561 562 563 o KDC PDUs are not exchanged as usual in Kerberos, but wrapped as 564 [the first two] GSS-API context tokens. 565 566 o PKU2U does not use KDC certificates. 567 568 o PKU2U adds pa-data types for carrying the initiator's assertion of 569 its name and the targ_name passed to GSS_Init_sec_context(). 570 571 PKU2U differs from the Kerberos V GSS-API mechanism in several ways: 572 573 o KDC PDUs are not exchanged as described in [RFC4120], but wrapped 574 as GSS-API context tokens. 575 576 o PKU2U allows the use of principal names matching PKI naming (see 577 Section 5). PKU2U does support the use of Kerberos V naming, but 578 requires only support of Kerberos V naming to a limited extent 579 (full support is optional). 580 581 o PKU2U adds an extension [GSS-EXTS] to the RFC4121 initial context 582 token for binding the AP-REQ to the AS exchange that precedes is 583 (that is, when the initiator has to request a ticket from the 584 acceptor). 585 586 o The number of round-trips can vary. If the initiator already has 587 a ticket for the acceptor then the context token exchange will be 588 half a round-trip or one round-trip, as per RFC4121. Otherwise 589 one or two round-trips are added for the AS exchanges needed to 590 acquire a ticket. Note that two AS exchanges may be required when 591 the initiator's initial choice of X.509 certificate does not match 592 the acceptor's trust anchors, in which case the acceptor SHOULD 593 reply with a KRB-ERROR with TD-TRUSTED-CERTIFIERS indicating what 594 the acceptor's trust anchors are, and then the initiator can 595 engage in a second AS exchange within the same GSS-API context. 596 597 To recapitulate, the acceptor and the initiator communicate by 598 tunneling the authentication service exchange messages through the 599 use of the GSS-API tokens and application traffic. In the event of 600 security context token loss, message duplication, or out of order 601 message delivery, the security context MUST fail to establish. 602 603 All security context establishment tokens MUST follow the 604 InitialContextToken syntax defined in Section 3.1 of [RFC2743]. 605 PKU2U is identified by the Objection Identifier (OID) id-kerberos- 606 pku2u. 607 608 609 610 611 612 613 614Zhu, et al. Expires May 7, 2009 [Page 11] 615 616Internet-Draft PKU2U November 2008 617 618 619 The PKU2U OID is: 620 621 id-kerberos-pku2u ::= 622 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 623 pku2u(7) } 624 625 All context establishment tokens consist of some Kerberos V PDU or 626 another, prefixed with a two-octet token type ID, and the 627 InitialContextToken header (see above). 628 629 The innerToken described in section 3.1 of [RFC2743] and subsequent 630 GSS-API mechanism tokens have the following formats: it starts with a 631 two-octet token-identifier (TOK_ID), followed by a Kerberos message. 632 The TOK_ID values for the AS-REQ message and the AS-REP message are 633 defined in the table blow: 634 635 Token TOK_ID Value in Hex 636 ----------------------------------------------- 637 KRB_AS_REQ 05 00 638 KRB_AS_REP 06 00 639 640 The TOK_ID values for all other Kerberos messages are the same as 641 defined in [RFC4121]. 642 643 It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U 644 can authenticate the acceptor without revealing the initiator's 645 identity 646 6476.1. Context Token Derived from KRB_AS_REQ 648 649 When the initiator does not have a service ticket to the acceptor, it 650 requests a ticket from the acceptor instead of from the KDC by 651 constructing a KRB_AS_REQ PDU [RFC4120] and using it as the context 652 token, with a token type ID prefixed. This will be the initiator's 653 initial context token, therefore it MUST also have the standard 654 header bearing the OID of the mechanism being used (in this case, 655 PKU2U's OID). 656 657 The initiator MUST NOT set any KDC options in the 'kdc-options' field 658 of the AS-REQ. 659 660 The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known 661 PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING]. 662 663 If the initiator wishes to assert a name of type 664 GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it 665 MUST set the 'cname' field of the AS-REQ accordingly if and only if 666 the realm name part of the given name object is defaulted or the 667 668 669 670Zhu, et al. Expires May 7, 2009 [Page 12] 671 672Internet-Draft PKU2U November 2008 673 674 675 well-known PKU2U realm name. Otherwise the initiator MUST add a pa- 676 data element (see below) stating the name that the initiator wishes 677 to assert, it MUST set the cname field to the NULL principal name as 678 defined in Section 4. 679 680 If the targ_name passed to GSS_Init_sec_context() is of type 681 GSS_C_NT_HOSTBASED_NAME then the initiator sets the 'sname' field of 682 the AS-REQ to match the parsed name as per [RFC4121]. If the target 683 name does not have a representation as a Kerberos principal name per 684 [RFC1964], then the initiator MUST add a pa-data element (see below) 685 stating the given targ_name and the initiator MUST set the 'sname' 686 field of the AS-REQ to the NULL principal name as defined in 687 Section 4. 688 689 The padata used to convey initiator and target names is of type 690 PA_PKU2U_NAME <136> and it's value consists of the DER 691 [CCITT.X680.2002] [CCITT.X690.2002] encoding of the ASN.1 type 692 InitiatorNameAssertion (with explicit tagging). 693 694 InitiatorName ::= CHOICE { 695 -- -1 -> certificate DN 696 -- 0..16384 -> subjectAltName named by 697 -- this index 698 sanIndex INTEGER (-1..16384), -- DN or SAN 699 nameNotInCert GeneralName, -- name not present in cert 700 -- (see RFC5280 for definition 701 of GeneralName) 702 ... 703 } 704 705 TargetName ::= CHOICE { 706 exportedTargName OTCET STRING, -- exported krb5 name 707 generalName [0] GeneralName, -- all other PKI names 708 -- (tagged to distinguish 709 -- from nameNotInCert 710 -- choice of InitiatorName) 711 ... 712 } 713 714 InitiatorNameAssertion ::= SEQUENCE { 715 initiatorName InitiatorName OPTIONAL, 716 targetName TargetName OPTIONAL, 717 ... 718 } 719 720 The initiatorName, if present, contains the initiator's name. The 721 initiator can fill out either the sanIndex field or the nameNotInCert 722 field to indicate the name of the initiator. 723 724 725 726Zhu, et al. Expires May 7, 2009 [Page 13] 727 728Internet-Draft PKU2U November 2008 729 730 731 The sanIndex field, if present, is used to refer to either the 732 Distinguished Name or the SubjectAltName in the initiator's X.509 733 certificate. A sanIndex value of -1 value refers to the initiator's 734 certificate's DN. All other legal values of sanIndex refer to the 735 corresponding element of the SubjectAltName sequence. A value of 0 736 means the first instance of GeneralName in the SubjectAltName 737 sequence, and 1 means the second, and so on. If the sanIndex value 738 is equal or biger than the number of GeneralName elements in the 739 SubjectAltName, the security context establishment attempt MUST fail. 740 741 The nameNotInCert field, if present, contains the initiator's 742 GeneralName. 743 744 If an initiator name assertion is included, the acceptor MUST verify 745 that this asserted name is either present in the initiator's 746 certificate or otherwise bound to the initiator's certificate by out- 747 of-band provisioning (e.g., by a table lookup). Failure to validate 748 the asserted initiator's name MUST cause GSS_Accept_sec_context() to 749 return an error and, optionally, to output a KRB_ERROR context token 750 as per-RFC4121. 751 752 The initiatorName field MUST NOT be present if the initiator is 753 anonymous or if the 'cname' field of the AS-REQ is not the NULL name 754 (see Section 4). 755 756 Target names passed to GSS_Init_sec_context() that can be represented 757 as Kerberos V principal names, namely, names of 758 GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be 759 represented as the 'sname' field of the AS-REQ or as the 760 exportedTargName choice of TargetName (if the realm part is not the 761 PKU2U realm name). The contents of the exportedTargName octet string 762 MUST be an exported name token for the Kerberos V mechanism 763 containing a Kerberos V principal name. 764 765 Other target names are represented as a generalName choice of 766 TargetName. These may be present in an acceptor certificate, or 767 agreed out of band. 768 769 The acceptor MUST select an appropriate acceptor credential that 770 matches the AS-REQ's 'sname' (if not NULL) or the targetName provided 771 in the InitiatorNameAssertion, when present. 772 773 The targetName field MUST NOT be present if the 'sname' field of the 774 AS-REQ is not the NULL name. The targetName field MUST be present if 775 the 'sname' field of the AS-REQ is the NULL name. 776 777 The PA_PKU2U_NAME padata SHOULD NOT be present when the initiatorName 778 and targetName both shouldn't be present. 779 780 781 782Zhu, et al. Expires May 7, 2009 [Page 14] 783 784Internet-Draft PKU2U November 2008 785 786 787 Implementation note: the encrypted part of a PKU2U Ticket can be 788 anything at all since the only entity that will consumer a given 789 PKU2U Ticket is the same entity that issued it. Implementers may 790 choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and 791 DER encoding. 792 7936.2. Context Token Derived from KRB_AS_REP 794 795 When the initiator's initial context token is a AS-REQ then the 796 acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or 797 a token derived from a KRB_AS_REP PDU [RFC4120] constructed to 798 respond to the initiator's KRB_AS_REQ. 799 800 The initiator MUST use PKINIT pre-authentication and the acceptor 801 MUST require it. If the initiator does not use PKINIT pre- 802 authentication then the acceptor MUST respond with a KRB-ERROR and 803 indicate that PKINIT is required. 804 805 If the initiator's KRB_AS_REQ token is valid, and the asserted 806 initiator's name, if present, is bound with the initiator's 807 certificate, and the acceptor can select a certificate based on the 808 initiator's asserted targ_name, the acceptor then constructs a 809 KRB_AS_REP using PKINIT as described in [RFC4556], except that the 810 acceptor's certificate is used in the place of the KDC certificate. 811 If and only if the initiator's X.509 certficate is validated using 812 PKI, the acceptor SHOULD include an authorization element 813 AD_INITIAL_VERIFIED_CAS [RFC4556] in the returned ticket. If an 814 InitiatorName is included in the PA_PKU2U_NAME padata in the request, 815 an authorization element of the type ad-pku2u-client-name <143> MUST 816 be included in the returned ticet and this authorization element 817 contains the DER encoded InitiatorName in the request. 818 819 The initiator then validates the KRB-AS-REP reply context token 820 according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of 821 [RFC4556]. The inclusion of the EKU KeyPurposeId [RFC5280] id- 822 pkinit-KPKdc in the X.509 certificate in the response is not 823 applicable when PKU2U is used because there is no KDC involved in 824 this protocol. The initiator MUST verify that the acceptor's 825 certificate is bound with the targ_name passed in to 826 GSS_Init_sec_context(), by verifying either the targ_name matches 827 with either the subject DN or one instance of the SubjectAltName name 828 in the acceptor's certificate, or otherwise the targ_name is bound 829 with the acceptor's certificate by out-of-band provisioning (e.g., by 830 a table lookup). Failure to validate this name binding MUST cause 831 the authentication to be rejected. 832 833 The 'flags' field of the AS-REP MUST have only the 'initial' and 834 'pre-authent' flags set. 835 836 837 838Zhu, et al. Expires May 7, 2009 [Page 15] 839 840Internet-Draft PKU2U November 2008 841 842 843 The 'authtime' field of the AS-REP MUST be set to the acceptor's 844 current time as it is when it formats the AS-REP. 845 846 Otherwise all other aspects of the AS-REP are as described in 847 [RFC4120]. 848 849 The values of the tkt-vno, realm and 'sname' fields of the Ticket 850 issued by the acceptor are unspecified. The initiator MUST NOT 851 examine them for correctness. Cut-n-paste attacks are prevented by 852 the fact that PKU2U provides integrity protection for all cleartext 853 in Kerberos V PDUs used by PKU2U (and for the mechanism OID). 854 8556.3. Context Tokens Imported from RFC4121 856 857 Once the initiator has a Kerberos V Ticket for the acceptor the 858 security context token exchange will continue with those of the 859 Kerberos V GSS-API mechanism [RFC4121] with the following 860 modifications: 861 862 o The mechanism OID of PKU2U SHALL be used instead of that of the 863 Kerberos V GSS-API mechanism; 864 865 o The 'crealm' field of the initiator's Authenticator MUST be set to 866 the PKU2U realm name and if the 'cname" field is the NULL 867 principal name, an authorization element of the type ad-pku2u- 868 client-name <143> MUST be included in the authenticator and this 869 authorization element contains the DER encoded InitiatorName in 870 the AS-REQ based on which the ticket was obtained; 871 872 o The sub-session key MUST be used in the initiator's Authenticator; 873 874 o The contents of the encrypted part of the Ticket can be 875 implementation specific since the only entity consuming it will be 876 the same entity that issues it; 877 878 o If the initiator's initial context token is a KRB_AS_REQ token 879 (i.e., not KRB_AP_REQ token), then the Exts field in the 880 Authenticator of the KRB_AP_REQ-derived token MUST contain an 881 extension [GSS-EXTS] of the type GSS_EXTS_FINISHED <2> as defined 882 next in this section. 883 884 The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of 885 the Authenticator are set as per [RFC4121] and [RFC4120]. 886 887 The 'cksum' field of the Authenticator MUST be set as per [RFC4121]. 888 The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS] 889 contains the DER encoding of the ASN.1 structure KRB-FINISHED. 890 891 892 893 894Zhu, et al. Expires May 7, 2009 [Page 16] 895 896Internet-Draft PKU2U November 2008 897 898 899 GSS_EXTS_FINISHED 2 900 --- The type for the checksum extension. 901 902 KRB-FINISHED ::= SEQUENCE { 903 gss-mic [1] Checksum, 904 -- Contains the checksum (RFC3961) of the GSS-API tokens 905 -- that have been exchanged between the initiator and the 906 -- acceptor and prior to the containing AP-REQ GSS-API token. 907 -- The checksum is performed over the GSS-API 908 -- context tokens in the order that the tokens were sent. 909 ... 910 } 911 912 The gss-mic field contains a Kerberos checksum [RFC3961] that is 913 computed over all the preceding context tokens of this GSS-API 914 context (including the InitialContextToken header), concatenated in 915 chronological order (note that GSS-API context token exchanges are 916 synchronous). The checksum type is the required checksum type of the 917 enctype of the subkey in the authenticator, the protocol key for the 918 checksum operation is the authenticator subkey, and the key usage 919 number is KEY_USAGE_FINISHED <41>. 920 921 The acceptor MUST process the KRB_AP_REQ token as usual for RFC4121, 922 except that if the context token exchange included an AS exchange, 923 then the acceptor MUST also validate the GSS_EXTS_FINISHED and return 924 an error if it is not valid or not present. But if a KRB_AP_REQ 925 context token is the initial context token then the acceptor MUST 926 return an error if GSS_EXTS_FINISHED is present. 927 928 The GSS_EXTS_FINISHED (along with the ticket) binds the second part 929 of the context token exchange to the first, and it binds the pa-data 930 used in the request as well (this needs to be done because PKINIT 931 does not bind pa-data other than PKINIT pa-data from the request). 932 GSS_EXTS_FINISHED also protects all otherwise unauthenticated 933 plaintext in Kerberos V PDUs. Note that GSS_EXTS_FINISHED also 934 protects the mechanism OID in the InitialContextToken header. 935 936 The acceptor MUST verify that the ad-pku2u-client-name authorization 937 element is present in the authenticator if and only there is an 938 authorization element of the same type in the ticket and the values 939 of these two elements MUST match exactly based on bit-wise 940 comparison. 941 942 9437. Guidelines for Credentials Selection 944 945 If a peer, either the initiator or the acceptor, has multiple pairs 946 of public-key private keys and certificates, a choice is to be made 947 948 949 950Zhu, et al. Expires May 7, 2009 [Page 17] 951 952Internet-Draft PKU2U November 2008 953 954 955 in choosing the best fit. The trustedCertifiers field in the PA-PK- 956 AS-REQ structure [RFC4556] SHOULD be filled by the initiator, to 957 provide hints for guiding the selection of an appropriate certificate 958 chain by the acceptor. 959 960 If the initiator's X.509 certificate cannot be validated according to 961 [RFC5280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS 962 structure [RFC4556] that provides hints for guiding the selection of 963 an appropriate certificate by the initiator. In this case 964 GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the 965 initiator gets to try again in its subsequent AS-REQ token. 966 967 The GSS-API does not provide a programming interface to make this 968 credential selection interactive, though implementers may provide 969 methods for user interaction related to credential selection and 970 acquisition (e.g., name and password/PIN prompts). Whenever the 971 execution context allows for direct interaction of the mechanism with 972 the user then it is RECOMMENDED that implementations interact with 973 the user to select a credential whenever multiple credentials are 974 equally usable and no other mechanism is available to inform the 975 credential selection. 976 977 If the certificates cannot be selected interactively, multiple 978 certificates are equally usable, and there is no other mechanism 979 available for credential selection, then it is RECOMMENDED that 980 initiators fail the context. Users should be able to retry using a 981 specific credential (this requires that distinct credentials have 982 distinct names that can be used to acquire each credential 983 separately). 984 985 9868. Security Considerations 987 988 The security considerations in [RFC4120], [RFC4121], [RFC4556] and 989 [RFC5280] apply here. This mechanism relaxes some requirements of 990 PKINIT and adds a device for protecting otherwise unauthenticated 991 plaintext in the protocol (see Section 6.3) -- it is crucial that 992 this device be faithfully implemented. It is also crucial that both 993 the initiator and the acceptor MUST be able to verify the binding 994 between the signing key and the asserted identity. 995 996 Note that PKU2U is just as susceptible to replays of AP-REQs as the 997 traditional Kerberos V GSS-API mechanism [RFC4121], though only when 998 using an AP-REQ as the initial security context token. It is 999 important, therefore, to use a replay cache to detect replays. 1000 1001 1002 1003 1004 1005 1006Zhu, et al. Expires May 7, 2009 [Page 18] 1007 1008Internet-Draft PKU2U November 2008 1009 1010 10119. Acknowledgements 1012 1013 The authors would like to thank Jeffrey Hutzelman for his insightful 1014 comments on the earlier revisions of this document. 1015 1016 In addition, the following individuals have provided review comments 1017 for this document: Sam Hartman, Leif Johansson, Olga Kornievskaia, 1018 Martin Rex, and Sunil Gottumukkala. 1019 1020 Ari Medvinsky provided help in editing the initial revisions of this 1021 document. 1022 1023 The text for the DN mapping is compiled from the email discussions 1024 among the following individuals: Howard Chu, Martin Rex, Jeffrey 1025 Hutzelman, Kevin Coffman, Henry B. Hotz, Leif Johansson, and Olga 1026 Kornievskaia. Howard and Jeffery clearly illustrated the challenges 1027 in creating a unique mapping, while Nicolas and Martin demonstrated 1028 the relevance and interactions to GSS-API and Kerberos. 1029 1030 103110. IANA Considerations 1032 1033 This document defines the PKU2U realm and the place-holder well-known 1034 principal name. The IANA registry for the reserved names should be 1035 updated to reference this document. Two entries are added: one entry 1036 for the well-known realm "WELLKNOWN:PKU2U", and another for the well- 1037 known principal name "WELLKNOWN/NULL". 1038 1039 This document defines GSS_EXTS_FINISHED extension type. The 1040 corresponding IANA registry [GSS-EXTS] need to be updated to 1041 reference this document. The following single registration should be 1042 added in the registry for "Kerberos V GSS-API mechanism extension 1043 types": 2, "GSS-API token checksum", "Extension to provide a checksum 1044 for GSS-API tokens", the RFC # of this document. 1045 1046 This document also instructs the IANA to extend the "SMI Security for 1047 Name System Designators Codes (nametypes)" registry to include an OID 1048 for each registration, and to allocate OIDs for the following GSS-API 1049 name-types in that registry: 1050 o gss-distinguished-name (GSS_C_NT_DN) 1051 o gss-hostname (GSS_C_NT_HOSTNAME) 1052 o gss-IP-address (GSS_C_NT_IP_ADDR) 1053 o gss-e-mail-address (GSS_C_NT_EMAIL_ADDR) 1054 1055 105611. Normative References 1057 1058 [CCITT.X680.2002] 1059 1060 1061 1062Zhu, et al. Expires May 7, 2009 [Page 19] 1063 1064Internet-Draft PKU2U November 2008 1065 1066 1067 International International Telephone and Telegraph 1068 Consultative Committee, "Abstract Syntax Notation One 1069 (ASN.1): Specification of basic notation", 1070 CCITT Recommendation X.680, July 2002. 1071 1072 [CCITT.X690.2002] 1073 International International Telephone and Telegraph 1074 Consultative Committee, "ASN.1 encoding rules: 1075 Specification of basic encoding Rules (BER), Canonical 1076 encoding rules (CER) and Distinguished encoding rules 1077 (DER)", CCITT Recommendation X.690, July 2002. 1078 1079 [GSS-EXTS] 1080 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 1081 Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility (work 1082 in progress), 2007. 1083 1084 [KRB-ANON] 1085 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 1086 draft-ietf-krb-wg-anon (work in progress), 2007. 1087 1088 [KRB-NAMING] 1089 Zhu, L., "Additional Kerberos Naming Constraints", 1090 draft-ietf-krb-wg-naming (work in progress), 2007. 1091 1092 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1093 text messages", STD 11, RFC 822, August 1982. 1094 1095 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1096 STD 13, RFC 1034, November 1987. 1097 1098 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1099 RFC 1964, June 1996. 1100 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, March 1997. 1103 1104 [RFC2743] Linn, J., "Generic Security Service Application Program 1105 Interface Version 2, Update 1", RFC 2743, January 2000. 1106 1107 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 1108 C-bindings", RFC 2744, January 2000. 1109 1110 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1111 "Internationalizing Domain Names in Applications (IDNA)", 1112 RFC 3490, March 2003. 1113 1114 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1115 1116 1117 1118Zhu, et al. Expires May 7, 2009 [Page 20] 1119 1120Internet-Draft PKU2U November 2008 1121 1122 1123 Kerberos 5", RFC 3961, February 2005. 1124 1125 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1126 Kerberos Network Authentication Service (V5)", RFC 4120, 1127 July 2005. 1128 1129 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1130 Version 5 Generic Security Service Application Program 1131 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1132 July 2005. 1133 1134 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1135 Extension for the Generic Security Service Application 1136 Program Interface (GSS-API)", RFC 4401, February 2006. 1137 1138 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1139 Kerberos V Generic Security Service Application Program 1140 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1141 1142 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 1143 (LDAP): String Representation of Distinguished Names", 1144 RFC 4514, June 2006. 1145 1146 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 1147 Syntaxes and Matching Rules", RFC 4517, June 2006. 1148 1149 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 1150 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 1151 1152 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1153 Housley, R., and W. Polk, "Internet X.509 Public Key 1154 Infrastructure Certificate and Certificate Revocation List 1155 (CRL) Profile", RFC 5280, May 2008. 1156 1157 1158Authors' Addresses 1159 1160 Larry Zhu 1161 Microsoft Corporation 1162 One Microsoft Way 1163 Redmond, WA 98052 1164 US 1165 1166 Email: lzhu@microsoft.com 1167 1168 1169 1170 1171 1172 1173 1174Zhu, et al. Expires May 7, 2009 [Page 21] 1175 1176Internet-Draft PKU2U November 2008 1177 1178 1179 Jeffery Altman 1180 Secure Endpoints 1181 255 W 94th St 1182 New York, NY 10025 1183 US 1184 1185 Email: jaltman@secure-endpoints.com 1186 1187 1188 Nicolas Williams 1189 Sun Microsystems 1190 5300 Riata Trace Ct 1191 Austin, TX 78727 1192 US 1193 1194 Email: Nicolas.Williams@sun.com 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230Zhu, et al. Expires May 7, 2009 [Page 22] 1231 1232Internet-Draft PKU2U November 2008 1233 1234 1235Full Copyright Statement 1236 1237 Copyright (C) The IETF Trust (2008). 1238 1239 This document is subject to the rights, licenses and restrictions 1240 contained in BCP 78, and except as set forth therein, the authors 1241 retain all their rights. 1242 1243 This document and the information contained herein are provided on an 1244 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1245 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1246 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1247 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1248 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1249 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1250 1251 1252Intellectual Property 1253 1254 The IETF takes no position regarding the validity or scope of any 1255 Intellectual Property Rights or other rights that might be claimed to 1256 pertain to the implementation or use of the technology described in 1257 this document or the extent to which any license under such rights 1258 might or might not be available; nor does it represent that it has 1259 made any independent effort to identify any such rights. Information 1260 on the procedures with respect to rights in RFC documents can be 1261 found in BCP 78 and BCP 79. 1262 1263 Copies of IPR disclosures made to the IETF Secretariat and any 1264 assurances of licenses to be made available, or the result of an 1265 attempt made to obtain a general license or permission for the use of 1266 such proprietary rights by implementers or users of this 1267 specification can be obtained from the IETF on-line IPR repository at 1268 http://www.ietf.org/ipr. 1269 1270 The IETF invites any interested party to bring to its attention any 1271 copyrights, patents or patent applications, or other proprietary 1272 rights that may cover technology that may be required to implement 1273 this standard. Please address the information to the IETF at 1274 ietf-ipr@ietf.org. 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286Zhu, et al. Expires May 7, 2009 [Page 23] 1287 1288 1289