idnits 2.17.1 draft-zhu-pku2u-09.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1022. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (November 3, 2008) is 5652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 576 -- Looks like a reference, but probably isn't: '1' on line 743 == Unused Reference: 'RFC4517' is defined on line 948, but no explicit reference was found in the text ** Downref: Normative reference to an Historic draft: draft-ietf-krb-wg-anon (ref. 'KRB-ANON') ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4402 (Obsoleted by RFC 7802) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft Microsoft Corporation 4 Intended status: Standards Track J. Altman 5 Expires: May 7, 2009 Secure Endpoints 6 N. Williams 7 Sun 8 November 3, 2008 10 Public Key Cryptography Based User-to-User Authentication - (PKU2U) 11 draft-zhu-pku2u-09 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 7, 2009. 38 Abstract 40 This document defines a Generic Security Services Application Program 41 Interface (GSS-API) mechanism based on Public Key Infrastructure 42 (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the 43 Kerberos V GSS-API mechanism, but without requiring a Kerberos Key 44 Distribution Center (KDC). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 50 3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3 51 4. The NULL Principal Name . . . . . . . . . . . . . . . . . . . 4 52 5. PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . . 4 53 5.1. GSS_C_NT_DN . . . . . . . . . . . . . . . . . . . . . . . 6 54 5.2. GSS_C_NT_HOSTNAME . . . . . . . . . . . . . . . . . . . . 6 55 5.3. GSS_C_NT_EMAIL_ADDR . . . . . . . . . . . . . . . . . . . 7 56 5.4. GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . . 7 57 5.5. GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . . 9 58 5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based 59 Principal Names to Acceptor Certificates . . . . . . . . . 9 60 6. The Protocol Description and the Context Establishment 61 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6.1. Context Token Derived from KRB_AS_REQ . . . . . . . . . . 12 63 6.2. Context Token Derived from KRB_AS_REP . . . . . . . . . . 15 64 6.3. Context Tokens Imported from RFC4121 . . . . . . . . . . . 16 65 7. Guidelines for Credentials Selection . . . . . . . . . . . . . 17 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 71 Intellectual Property and Copyright Statements . . . . . . . . . . 23 73 1. Introduction 75 The Generic Security Services Application Programming Interface (GSS- 76 API) is a generic protocol and API for providing authentication and 77 session protection to applications. It is generic in that it 78 supports multiple authentication mechanisms. Today there exists only 79 one workable, widely deployed, standards-track GSS-API mechanism: the 80 Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on 81 Kerberos V [RFC4120]. There is a need to provide a GSS-API mechanism 82 which does not require Kerberos V Key Distribution Center (KDC) 83 infrastructure, and which supports the use of public key 84 cryptography, particularly Public Key Infrastructure (PKI) [RFC5280], 85 including the use of public key certificates without a PKI. 87 This document specifies such a mechanism: the Public Key User to User 88 mechanism (PKU2U). 90 PKU2U is based on building blocks taken from Kerberos V [RFC4120], 91 PKINIT, [RFC4556] (which in turn uses PKI [RFC5280]) building 92 blocks), and the Kerberos V GSS-API mechanism [RFC1964] [RFC4121]. 93 In spite of using Kerberos V building blocks, PKU2U does not require 94 any Kerberos V KDC infrastructure. And though PKU2U also uses PKI 95 building blocks, PKU2U can be used without a PKI by pre-sharing 96 certificates and/or pre-associating name/certificate bindings. 98 Therefore PKU2U can be used for true peer-to-peer authentication, as 99 well as for PKI-based authentication. 101 2. Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 In this document, the GSS-API initiator or acceptor is referred to as 108 the peer when the description is applicable to both the initiator and 109 the acceptor. 111 3. The PKU2U Realm Name 113 The PKU2U realm name is defined as a reserved Kerberos realm name per 114 [KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U". 116 The PKU2U realm name has no meaning, but is intended to be used in 117 the Kebreros V Protocol Data Units (PDUs) that are re-used by PKU2U 118 wherever realm names are needed. Unless otherwise specified, the 119 realm name in any Kerberos message used by PKU2U is the PKU2U realm 120 name. 122 4. The NULL Principal Name 124 The NULL Kerberos principal name is defined as a well-known Kerberos 125 principal name based on [KRB-NAMING]. The value of the name-type 126 field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name- 127 string field is a sequence of two KerberosString components: 128 "WELLKNOWN", "NULL". 130 The NULL Kerberos principal name is used in the Kerberos messages 131 where there is no Kerberos representation of the principal name, for 132 example, when the client name is a Distinguished Name. When the NULL 133 principal name is used in the Kerberos messages, the principal name 134 is either not used or provided separately (for example in the 135 PA_PKU2U_NAME padata defined in Section 6.1). 137 5. PKU2U Principal Naming 139 The GSS-API targ_name supplied for the initiator MUST NOT be 140 GSS_C_NO_NAME in PKU2U. 142 PKU2U principal names can be Kerberos principal names, and they can 143 also be distiguished names, or subject alternative names [RFC5280] as 144 they appear in the certificate of any PKU2U peer, as well as any 145 names agreed to out of band that do not appear in the peer 146 certificates. 148 Certificates may be associated with multiple principal names. This 149 presents problems for the GSS-API bindings of a PKI-based mechanism 150 because, for example, for any given, established GSS-API security 151 mechanism there can be only one initiator name, and one acceptor 152 name, and credential handles may be associated with only one name. 153 We resolve these problems as follows: 155 o We define multiple GSS-API name types corresponding to several 156 GeneralName choices [RFC5280], along with syntaxes, display forms, 157 and exported name token formats for each. For most of the name- 158 types listed below the exported name token formats consists of a 159 GeneralName with the usual exported name token header as per- 160 RFC2743. Two name-types are shared with the Kerberos V mechanism 161 and use the Kerberos V mechanism's query and display syntaxes, 162 canonicalization rules, and exported name token format. 164 o The cred_name of a credential handle acquired with 165 GSS_C_NT_NO_NAME as the desired_name SHOULD be the Distinguished 166 Name (DN) of the certificate underlying the credential. If there 167 are multiple certificates and private keys, then either one MUST 168 be selected by local, implementation-specific means, or credential 169 acquisition with GSS_C_NT_NO_NAME MUST fail (implementers may 170 choose which of these two behaviors to provide). 172 o When using desired_name values other than GSS_C_NT_NO_NAME for 173 credential handle acquisition then the implementation MUST use 174 exact matching of the given desired_name to a certificate's DN or 175 Subject Alternative Names (SANs) for all name-types given below, 176 except for GSS_C_NT_DN, where matching rules are fuzzier and given 177 below. The names of a X.509 certificate will be compared to the 178 given desired_name in this order: certificate DN first, then SANs 179 in the order in which they appear in the certificate. When 180 multiple certificates and private keys are available the order in 181 which the various certificates are searched is significant; no 182 canonical certificate collation order is defined herein. 184 o The cred_name of a credential object acquired with a desired_name 185 other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or 186 SAN matched by the given desired_name. 188 o We provide a method (see below) by which initiators can assert, in 189 their context tokens, one of these names of the initiator. We 190 also provide a method of asserting names that do not appear in a 191 X.509 certificate, in which case the binding of X.509 certificate 192 to the asserted name is done out-of band. The name to be 193 asserted, of course, is the cred_name of the cred_handle passed to 194 GSS_Init_sec_context(). 196 o The initiator's context tokens may also indicate what is the 197 expected name of the acceptor -- the targ_name passed in to 198 GSS_Init_sec_context(). 200 o No attempt is made to map Kerberos V realm names to trust anchor 201 certificate authority (CA) names. 203 o We provide a method of matching host-based service principal names 204 to acceptor certificates, so that: a) initiators need not know the 205 particulars of an acceptor's certificates' names a priori, b) 206 acceptors can select a credential to accept a security context 207 with that the initiator will accept, c) existing certificates for 208 web servers, may be used as host-based service principal names as 209 though the service name were "HTTP". 211 Thus GSS-API initiator applications that use the GSS_C_NO_NAME as the 212 desired_name arguments of GSS_Acquire_cred() and GSS_Add_cred(), or 213 GSS_C_NO_CREDENTIAL as the cred argument of GSS_Init_sec_context() 214 will assert the selected X.509 certificate's subject DN, and that 215 X.509 certificate's subject DN will be the name returned by 216 GSS_Inquire_cred() and GSS_Inquire_cred_by_mech(). 218 And portable GSS-API initiator applications using 219 GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing 220 a name to use as the targ_name input argument of 221 GSS_Init_sec_context()) will have a reasonable chance of success in 222 authenticating peers with X.509 certificates predating this 223 specification. 225 5.1. GSS_C_NT_DN 227 The name type GSS_C_NT_DN, with Object Identifier (OID) (see 228 Section 10), is defined. This corresponds to the 'directoryName' 229 choice of the 'GeneralName' Abstract Syntax Notation One (ASN.1) 230 [CCITT.X680.2002] type defined in [RFC5280]. 232 The query syntax and display form for names of this type SHALL be as 233 described in [RFC4514]. 235 As RFC4514 says, "[c]omparison of DNs for equality is to be performed 236 in accordance with the distinguishedNameMatch matching rule 237 [RFC4517]". 239 There is no reasonable way to canonicalize names of this type without 240 providing certificates to match query forms of GSS_C_NT_DN against, 241 such as in the form of a directory. Therefore 242 GSS_Canonicalize_name() as applied to names imported with the 243 GSS_C_NT_DN name-type MUST search available certificate databases, or 244 directories, or MUST fail. No method of locating and searching 245 directories for matching certificate DNs is specified herein. Note 246 though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context() 247 can and, indeed, MUST return "mechanism names" (MN) (see [RFC2743]). 249 The exported name token format for names of this type SHALL be the 250 Distinguished Encoding Rules (DER) [CCITT.X680.2002] 251 [CCITT.X690.2002] encoding of a GeneralName with directoryName as the 252 choice. 254 Implementation support for this name type is REQUIRED. 256 5.2. GSS_C_NT_HOSTNAME 258 The name type GSS_C_NT_HOSTNAME, with OID , is defined. This 259 corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type 260 defined in [RFC5280]. 262 The query syntax for names of this type SHALL be a DNS name [RFC1034] 263 in either ACE or Unicode form [RFC3490]. 265 The display and canonical form of names of this type SHALL be a DNS 266 domain name in ACE form, with character case folded down. 267 Canonicalization consists merely of applying the ToASCII() function 268 and case-folding the result. 270 The exported name token format for names of this type SHALL be the 271 DER encoding of a GeneralName with dNSName as the choice and the DNS 272 domain name in ACE form and case folded down. 274 Implementation support for this name type is OPTIONAL. 276 5.3. GSS_C_NT_EMAIL_ADDR 278 The name type GSS_C_NT_EMAIL_ADDR, with OID , is defined. This 279 corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1 280 type defined in [RFC5280]. 282 The query syntax and display form for names of this type SHALL be the 283 text representation of an 'addr-spec' as defined in [RFC0822]. 285 The canonical form of names of this type SHALL be the query form with 286 case folded down. Note that the domain name part of an addr-spec is 287 a "domain name slot" and so the canonicalization rules for 288 GSS_C_NT_HOSTNAME given above apply here as well. 290 The exported name token form for this name type SHALL be the DER- 291 encoding of a GeneralName with the rfc822Name choice. 293 Implementation support for this name type is OPTIONAL. 295 5.4. GSS_KRB5_NT_PRINCIPAL_NAME 297 PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964]. 299 The query, display, canonical and exported name token forms of names 300 of this type SHALL be as specified in RFC4121. The realm name part 301 of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax; 302 when canonicalized, names of this type lacking a realm name will have 303 the well-known PKU2U realm name affixed. 305 When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted 306 or otherwise is the well-known PKU2U realm name, then the "cname"' or 307 sname fields of the Kerberos V PDUs used to construct PKU2U security 308 context tokens MUST be set to the principal name part of the given 309 NAME. Otherwise the PA_PKU2U_NAME pre-authentication data MUST be 310 used to indicate a name of id-pkinit-san type [RFC4556] corresponding 311 to the given NAME. See Section 5.4. 313 No attempt is made to map Kerberos V realm names to trust anchor 314 certificate authority (CA) names. 316 Note that having more than one mechanism share name-types has 317 implications for multi-mechanism, pluggable GSS-API implementations 318 (commonly referred to as "mechglue"). Specifically: 320 o It must be the responsibility of the mechanism, not of the 321 mechglue, to ensure that the standard exported name token header 322 (which includes a mechanism OID), is included in exported name 323 tokens. The exported name token for a GSS_KRB5_NT_PRINCIPAL_NAME 324 MN produced by PKU2U would have PKU2U's mechanism OID in the 325 header. 327 o A pluggable mechglue must be able to find a mechanism that can 328 import an exported name token if an available mechanism can 329 produce that exported name token. For example, a pluggable 330 mechglue where PKU2U is available but where the Kerberos V 331 mechanism [RFC1964] is not should still be able to import exported 332 Kerberos V name tokens since PKU2U can create such tokens. One 333 way to do this would be for the mechglue to try the mechanism 334 named in the exported name token header, if it is available, else 335 try all other available mechanisms until one succeeds or all fail. 336 It would be reasonable for a mechglue implementer to require that 337 the Kerberos V mechanism be available if PKU2U is too. 339 o It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use 340 a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name 341 argument value to acquire a PKU2U credential. Similarly, it must 342 be possible to use a Kerberos V MN as the target_name in a call to 343 GSS_Init_sec_context with PKU2U as the mech OID. A multi- 344 mechanism mechglue implementer would likely have a mechglue-layer 345 NAME object that internally keeps a reference to a NAME object 346 produced by the underlying mechanism, but a pluggable mechglue 347 could not expect two different mechanisms to be able to share 348 their internal NAME objects. A clever implementer can work around 349 this by exporting the one mechanism's MN and then re-importing 350 using the target mechanism's GSS_Import_name() service function. 352 o It must be possible for the credential inquiry functions (e.g., 353 GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a 354 cred_name that is an MN of a different mechanism than the 355 credential element being inquired. 357 Implementation support for this name type, with defaulted realm name 358 or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use 359 with any other realm names. 361 5.5. GSS_C_NT_ANONYMOUS 363 This is a generic GSS-API name-type. Implementation support for this 364 name type is OPTIONAL. See Section 6.1 for more information. 366 See [RFC2743] and [RFC2744] for more information about this name 367 type. 369 The PKU2U mechanism only supports anonymous initiators, not 370 acceptors. 372 Implementation support for this name type is RECOMMENDED. 374 5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based Principal Names 375 to Acceptor Certificates 377 Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described 378 herein. 380 The query form of this name type is as per-RFC2743. The canonical 381 and exported name token forms are as per-RFC1964. The display form 382 of this name type is left unspecified, but should either be as per- 383 RFC2743 or the same as the display form for 384 GSS_KRB5_NT_PRINCIPAL_NAME [RFC1964]. 386 Initiators using names of type GSS_C_NT_HOSTBASED_SERVICE to identify 387 target acceptors represent these names as Kerberos V principal names 388 as per [RFC1964] but with a well-known realm name of "WELLKNOWN: 389 PKU2U" (see Section 5.4). 391 Acceptors match such names to acceptor certificates as follows. 392 Initiators then match the certificate chosen by the acceptor in the 393 same manner. 395 Initiators can also assert host-based service names as the initiator 396 name. In this case acceptors MUST also apply the matching rules 397 below, in order, to validate the initiator's assertion. 399 1. If there is an out-of-band binding of the peer's host-based 400 service name to its certificate, then the certificate matches. 402 2. If the peer has a certificate with an id-pkinit-san subject 403 alternative name matching the initiator-provided acceptor name, 404 then the X.509 certificate matches. 406 3. If a X.509 certificate has a dNSName SAN that matches the 407 hostname part of the host-based service principal name, and 408 either the anyExtendedKeyUsage extended key usage (EKU), or no 409 EKU is present, or an EKU is present which corresponds to the 410 service part of the host-based service principal name, then the 411 X.509 certificate matches. The id-kp-serverAuth EKU SHALL be 412 considered to match the 'HTTP' service name. (See Section 10, 413 IANA considerations, where the GSS-API service name registry is 414 extended to include an EKU for each service name.) 416 4. Implementations SHOULD, subject to local configuration, allow 417 matches where the single-component cn of the DN of a X.509 418 certificate matches the hostname part of the host-based service 419 name, for some or all service names. This feature is needed to 420 allow the use of existing X.509 web certificates. 422 Implementation support for this name type as an acceptor name is 423 REQUIRED. Implementation support for this name type as an initiator 424 name is OPTIONAL. 426 6. The Protocol Description and the Context Establishment Tokens 428 The PKU2U mechanism is a GSS-API mechanism based on [RFC4120], 429 [RFC4556] and [RFC4121]. 431 The per-message tokens of the PKU2U mechanism are the same as those 432 of the Kerberos V GSS-API mechanism [RFC4121]. 434 The GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same 435 as that of the Kerberos V GSS-API mechanism [RFC4402]. 437 The PKU2U security context token exchange consists of KRB_AS_REQ and 438 KRB_AS_REP (and KRB_ERROR) Kerberos KDC PDUs (with no changes to 439 their ASN.1 description, but with other minor changes/requirements 440 described below) as context tokens, with the acceptor as the KDC, 441 followed by context tokens from [RFC4121] using the Kerberos V Ticket 442 PDU issued by the acceptor-as-KDC. PKINIT [RFC4556] is the only 443 acceptable pre-authentication method in this document. Caching the 444 ticket issued by the acceptor allows subsequent security context 445 exchanges between the same to peers to use a single context token 446 round-trip -- a "fast reconnect" feature. 448 PKU2U differs from Kerberos V with PKINIT in several minor ways as 449 follows (this is not a complete list): 451 o KDC PDUs are not exchanged as usual in Kerberos, but wrapped as 452 [the first two] GSS-API context tokens. 454 o PKU2U does not use KDC certificates. 456 o PKU2U adds pa-data types for carrying the initiator's assertion of 457 its name and the targ_name passed to GSS_Init_sec_context(). 459 PKU2U differs from the Kerberos V GSS-API mechanism in several ways: 461 o KDC PDUs are not exchanged as described in [RFC4120], but wrapped 462 as GSS-API context tokens. 464 o PKU2U allows the use of principal names matching PKI naming (see 465 Section 5). PKU2U does support the use of Kerberos V naming, but 466 requires only support of Kerberos V naming to a limited extent 467 (full support is optional). 469 o PKU2U adds an extension [GSS-EXTS] to the RFC4121 initial context 470 token for binding the AP-REQ to the AS exchange that precedes is 471 (that is, when the initiator has to request a ticket from the 472 acceptor). 474 o The number of round-trips can vary. If the initiator already has 475 a ticket for the acceptor then the context token exchange will be 476 half a round-trip or one round-trip, as per RFC4121. Otherwise 477 one or two round-trips are added for the AS exchanges needed to 478 acquire a ticket. Note that two AS exchanges may be required when 479 the initiator's initial choice of X.509 certificate does not match 480 the acceptor's trust anchors, in which case the acceptor SHOULD 481 reply with a KRB-ERROR with TD-TRUSTED-CERTIFIERS indicating what 482 the acceptor's trust anchors are, and then the initiator can 483 engage in a second AS exchange within the same GSS-API context. 485 To recapitulate, the acceptor and the initiator communicate by 486 tunneling the authentication service exchange messages through the 487 use of the GSS-API tokens and application traffic. In the event of 488 security context token loss, message duplication, or out of order 489 message delivery, the security context MUST fail to establish. 491 All security context establishment tokens MUST follow the 492 InitialContextToken syntax defined in Section 3.1 of [RFC2743]. 493 PKU2U is identified by the Objection Identifier (OID) id-kerberos- 494 pku2u. 496 The PKU2U OID is: 498 id-kerberos-pku2u ::= 499 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 500 pku2u(7) } 502 All context establishment tokens consist of some Kerberos V PDU or 503 another, prefixed with a two-octet token type ID, and the 504 InitialContextToken header (see above). 506 The innerToken described in section 3.1 of [RFC2743] and subsequent 507 GSS-API mechanism tokens have the following formats: it starts with a 508 two-octet token-identifier (TOK_ID), followed by a Kerberos message. 509 The TOK_ID values for the AS-REQ message and the AS-REP message are 510 defined in the table blow: 512 Token TOK_ID Value in Hex 513 ----------------------------------------------- 514 KRB_AS_REQ 05 00 515 KRB_AS_REP 06 00 517 The TOK_ID values for all other Kerberos messages are the same as 518 defined in [RFC4121]. 520 It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U 521 can authenticate the acceptor without revealing the initiator's 522 identity 524 6.1. Context Token Derived from KRB_AS_REQ 526 When the initiator does not have a service ticket to the acceptor, it 527 requests a ticket from the acceptor instead of from the KDC by 528 constructing a KRB_AS_REQ PDU [RFC4120] and using it as the context 529 token, with a token type ID prefixed. This will be the initiator's 530 initial context token, therefore it MUST also have the standard 531 header bearing the OID of the mechanism being used (in this case, 532 PKU2U's OID). 534 The initiator MUST NOT set any KDC options in the 'kdc-options' field 535 of the AS-REQ. 537 The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known 538 PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING]. 540 If the initiator wishes to assert a name of type 541 GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it 542 MUST set the 'cname' field of the AS-REQ accordingly if and only if 543 the realm name part of the given name object is defaulted or the 544 well-known PKU2U realm name. Otherwise the initiator MUST add a pa- 545 data element (see below) stating the name that the initiator wishes 546 to assert, it MUST set the cname field to the NULL principal name as 547 defined in Section 4. 549 If the targ_name passed to GSS_Init_sec_context() is of type 550 GSS_C_NT_HOSTBASED_NAME then the initiator sets the 'sname' field of 551 the AS-REQ to match the parsed name as per [RFC4121]. If the target 552 name does not have a representation as a Kerberos principal name per 553 [RFC1964], then the initiator MUST add a pa-data element (see below) 554 stating the given targ_name and the initiator MUST set the 'sname' 555 field of the AS-REQ to the NULL principal name as defined in 556 Section 4. 558 The padata used to convey initiator and target names is of type 559 PA_PKU2U_NAME <136> and it's value consists of the DER 560 [CCITT.X680.2002] [CCITT.X690.2002] encoding of the ASN.1 type 561 InitiatorNameAssertion (with explicit tagging). 563 InitiatorName ::= CHOICE { 564 -- -1 -> certificate DN 565 -- 0..16384 -> subjectAltName named by 566 -- this index 567 sanIndex INTEGER (-1..16384), -- DN or SAN 568 nameNotInCert GeneralName, -- name not present in cert 569 -- (see RFC5280 for definition 570 of GeneralName) 571 ... 572 } 574 TargetName ::= CHOICE { 575 exportedTargName OTCET STRING, -- exported krb5 name 576 generalName [0] GeneralName, -- all other PKI names 577 -- (tagged to distinguish 578 -- from nameNotInCert 579 -- choice of InitiatorName) 580 ... 581 } 583 InitiatorNameAssertion ::= SEQUENCE { 584 initiatorName InitiatorName OPTIONAL, 585 targetName TargetName OPTIONAL, 586 ... 587 } 589 The initiatorName, if present, contains the initiator's name. The 590 initiator can fill out either the sanIndex field or the nameNotInCert 591 field to indicate the name of the initiator. 593 The sanIndex field, if present, is used to refer to either the 594 Distinguished Name or the SubjectAltName in the initiator's X.509 595 certificate. A sanIndex value of -1 value refers to the initiator's 596 certificate's DN. All other legal values of sanIndex refer to the 597 corresponding element of the SubjectAltName sequence. A value of 0 598 means the first instance of GeneralName in the SubjectAltName 599 sequence, and 1 means the second, and so on. If the sanIndex value 600 is equal or biger than the number of GeneralName elements in the 601 SubjectAltName, the security context establishment attempt MUST fail. 603 The nameNotInCert field, if present, contains the initiator's 604 GeneralName. 606 If an initiator name assertion is included, the acceptor MUST verify 607 that this asserted name is either present in the initiator's 608 certificate or otherwise bound to the initiator's certificate by out- 609 of-band provisioning (e.g., by a table lookup). Failure to validate 610 the asserted initiator's name MUST cause GSS_Accept_sec_context() to 611 return an error and, optionally, to output a KRB_ERROR context token 612 as per-RFC4121. 614 The initiatorName field MUST NOT be present if the initiator is 615 anonymous or if the 'cname' field of the AS-REQ is not the NULL name 616 (see Section 4). 618 Target names passed to GSS_Init_sec_context() that can be represented 619 as Kerberos V principal names, namely, names of 620 GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be 621 represented as the 'sname' field of the AS-REQ or as the 622 exportedTargName choice of TargetName (if the realm part is not the 623 PKU2U realm name). The contents of the exportedTargName octet string 624 MUST be an exported name token for the Kerberos V mechanism 625 containing a Kerberos V principal name. 627 Other target names are represented as a generalName choice of 628 TargetName. These may be present in an acceptor certificate, or 629 agreed out of band. 631 The acceptor MUST select an appropriate acceptor credential that 632 matches the AS-REQ's 'sname' (if not NULL) or the targetName provided 633 in the InitiatorNameAssertion, when present. 635 The targetName field MUST NOT be present if the 'sname' field of the 636 AS-REQ is not the NULL name. The targetName field MUST be present if 637 the 'sname' field of the AS-REQ is the NULL name. 639 The PA_PKU2U_NAME padata SHOULD NOT be present when the initiatorName 640 and targetName both shouldn't be present. 642 Implementation note: the encrypted part of a PKU2U Ticket can be 643 anything at all since the only entity that will consumer a given 644 PKU2U Ticket is the same entity that issued it. Implementers may 645 choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and 646 DER encoding. 648 6.2. Context Token Derived from KRB_AS_REP 650 When the initiator's initial context token is a AS-REQ then the 651 acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or 652 a token derived from a KRB_AS_REP PDU [RFC4120] constructed to 653 respond to the initiator's KRB_AS_REQ. 655 The initiator MUST use PKINIT pre-authentication and the acceptor 656 MUST require it. If the initiator does not use PKINIT pre- 657 authentication then the acceptor MUST respond with a KRB-ERROR and 658 indicate that PKINIT is required. 660 If the initiator's KRB_AS_REQ token is valid, and the asserted 661 initiator's name, if present, is bound with the initiator's 662 certificate, and the acceptor can select a certificate based on the 663 initiator's asserted targ_name, the acceptor then constructs a 664 KRB_AS_REP using PKINIT as described in [RFC4556], except that the 665 acceptor's certificate is used in the place of the KDC certificate. 666 If and only if the initiator's X.509 certficate is validated using 667 PKI, the acceptor SHOULD include an authorization element 668 AD_INITIAL_VERIFIED_CAS [RFC4556] in the returned ticket. If an 669 InitiatorName is included in the PA_PKU2U_NAME padata in the request, 670 an authorization element of the type ad-pku2u-client-name <143> MUST 671 be included in the returned ticet and this authorization element 672 contains the DER encoded InitiatorName in the request. 674 The initiator then validates the KRB-AS-REP reply context token 675 according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of 676 [RFC4556]. The inclusion of the EKU KeyPurposeId [RFC5280] id- 677 pkinit-KPKdc in the X.509 certificate in the response is not 678 applicable when PKU2U is used because there is no KDC involved in 679 this protocol. The initiator MUST verify that the acceptor's 680 certificate is bound with the targ_name passed in to 681 GSS_Init_sec_context(), by verifying either the targ_name matches 682 with either the subject DN or one instance of the SubjectAltName name 683 in the acceptor's certificate, or otherwise the targ_name is bound 684 with the acceptor's certificate by out-of-band provisioning (e.g., by 685 a table lookup). Failure to validate this name binding MUST cause 686 the authentication to be rejected. 688 The 'flags' field of the AS-REP MUST have only the 'initial' and 689 'pre-authent' flags set. 691 The 'authtime' field of the AS-REP MUST be set to the acceptor's 692 current time as it is when it formats the AS-REP. 694 Otherwise all other aspects of the AS-REP are as described in 695 [RFC4120]. 697 The values of the tkt-vno, realm and 'sname' fields of the Ticket 698 issued by the acceptor are unspecified. The initiator MUST NOT 699 examine them for correctness. Cut-n-paste attacks are prevented by 700 the fact that PKU2U provides integrity protection for all cleartext 701 in Kerberos V PDUs used by PKU2U (and for the mechanism OID). 703 6.3. Context Tokens Imported from RFC4121 705 Once the initiator has a Kerberos V Ticket for the acceptor the 706 security context token exchange will continue with those of the 707 Kerberos V GSS-API mechanism [RFC4121] with the following 708 modifications: 710 o The mechanism OID of PKU2U SHALL be used instead of that of the 711 Kerberos V GSS-API mechanism; 713 o The 'crealm' field of the initiator's Authenticator MUST be set to 714 the PKU2U realm name and if the 'cname" field is the NULL 715 principal name, an authorization element of the type ad-pku2u- 716 client-name <143> MUST be included in the authenticator and this 717 authorization element contains the DER encoded InitiatorName in 718 the AS-REQ based on which the ticket was obtained; 720 o The sub-session key MUST be used in the initiator's Authenticator; 722 o The contents of the encrypted part of the Ticket can be 723 implementation specific since the only entity consuming it will be 724 the same entity that issues it; 726 o If the initiator's initial context token is a KRB_AS_REQ token 727 (i.e., not KRB_AP_REQ token), then the Exts field in the 728 Authenticator of the KRB_AP_REQ-derived token MUST contain an 729 extension [GSS-EXTS] of the type GSS_EXTS_FINISHED <2> as defined 730 next in this section. 732 The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of 733 the Authenticator are set as per [RFC4121] and [RFC4120]. 735 The 'cksum' field of the Authenticator MUST be set as per [RFC4121]. 736 The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS] 737 contains the DER encoding of the ASN.1 structure KRB-FINISHED. 739 GSS_EXTS_FINISHED 2 740 --- The type for the checksum extension. 742 KRB-FINISHED ::= SEQUENCE { 743 gss-mic [1] Checksum, 744 -- Contains the checksum (RFC3961) of the GSS-API tokens 745 -- that have been exchanged between the initiator and the 746 -- acceptor and prior to the containing AP-REQ GSS-API token. 747 -- The checksum is performed over the GSS-API 748 -- context tokens in the order that the tokens were sent. 749 ... 750 } 752 The gss-mic field contains a Kerberos checksum [RFC3961] that is 753 computed over all the preceding context tokens of this GSS-API 754 context (including the InitialContextToken header), concatenated in 755 chronological order (note that GSS-API context token exchanges are 756 synchronous). The checksum type is the required checksum type of the 757 enctype of the subkey in the authenticator, the protocol key for the 758 checksum operation is the authenticator subkey, and the key usage 759 number is KEY_USAGE_FINISHED <41>. 761 The acceptor MUST process the KRB_AP_REQ token as usual for RFC4121, 762 except that if the context token exchange included an AS exchange, 763 then the acceptor MUST also validate the GSS_EXTS_FINISHED and return 764 an error if it is not valid or not present. But if a KRB_AP_REQ 765 context token is the initial context token then the acceptor MUST 766 return an error if GSS_EXTS_FINISHED is present. 768 The GSS_EXTS_FINISHED (along with the ticket) binds the second part 769 of the context token exchange to the first, and it binds the pa-data 770 used in the request as well (this needs to be done because PKINIT 771 does not bind pa-data other than PKINIT pa-data from the request). 772 GSS_EXTS_FINISHED also protects all otherwise unauthenticated 773 plaintext in Kerberos V PDUs. Note that GSS_EXTS_FINISHED also 774 protects the mechanism OID in the InitialContextToken header. 776 The acceptor MUST verify that the ad-pku2u-client-name authorization 777 element is present in the authenticator if and only there is an 778 authorization element of the same type in the ticket and the values 779 of these two elements MUST match exactly based on bit-wise 780 comparison. 782 7. Guidelines for Credentials Selection 784 If a peer, either the initiator or the acceptor, has multiple pairs 785 of public-key private keys and certificates, a choice is to be made 786 in choosing the best fit. The trustedCertifiers field in the PA-PK- 787 AS-REQ structure [RFC4556] SHOULD be filled by the initiator, to 788 provide hints for guiding the selection of an appropriate certificate 789 chain by the acceptor. 791 If the initiator's X.509 certificate cannot be validated according to 792 [RFC5280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS 793 structure [RFC4556] that provides hints for guiding the selection of 794 an appropriate certificate by the initiator. In this case 795 GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the 796 initiator gets to try again in its subsequent AS-REQ token. 798 The GSS-API does not provide a programming interface to make this 799 credential selection interactive, though implementers may provide 800 methods for user interaction related to credential selection and 801 acquisition (e.g., name and password/PIN prompts). Whenever the 802 execution context allows for direct interaction of the mechanism with 803 the user then it is RECOMMENDED that implementations interact with 804 the user to select a credential whenever multiple credentials are 805 equally usable and no other mechanism is available to inform the 806 credential selection. 808 If the certificates cannot be selected interactively, multiple 809 certificates are equally usable, and there is no other mechanism 810 available for credential selection, then it is RECOMMENDED that 811 initiators fail the context. Users should be able to retry using a 812 specific credential (this requires that distinct credentials have 813 distinct names that can be used to acquire each credential 814 separately). 816 8. Security Considerations 818 The security considerations in [RFC4120], [RFC4121], [RFC4556] and 819 [RFC5280] apply here. This mechanism relaxes some requirements of 820 PKINIT and adds a device for protecting otherwise unauthenticated 821 plaintext in the protocol (see Section 6.3) -- it is crucial that 822 this device be faithfully implemented. It is also crucial that both 823 the initiator and the acceptor MUST be able to verify the binding 824 between the signing key and the asserted identity. 826 Note that PKU2U is just as susceptible to replays of AP-REQs as the 827 traditional Kerberos V GSS-API mechanism [RFC4121], though only when 828 using an AP-REQ as the initial security context token. It is 829 important, therefore, to use a replay cache to detect replays. 831 9. Acknowledgements 833 The authors would like to thank Jeffrey Hutzelman for his insightful 834 comments on the earlier revisions of this document. 836 In addition, the following individuals have provided review comments 837 for this document: Sam Hartman, Leif Johansson, Olga Kornievskaia, 838 Martin Rex, and Sunil Gottumukkala. 840 Ari Medvinsky provided help in editing the initial revisions of this 841 document. 843 The text for the DN mapping is compiled from the email discussions 844 among the following individuals: Howard Chu, Martin Rex, Jeffrey 845 Hutzelman, Kevin Coffman, Henry B. Hotz, Leif Johansson, and Olga 846 Kornievskaia. Howard and Jeffery clearly illustrated the challenges 847 in creating a unique mapping, while Nicolas and Martin demonstrated 848 the relevance and interactions to GSS-API and Kerberos. 850 10. IANA Considerations 852 This document defines the PKU2U realm and the place-holder well-known 853 principal name. The IANA registry for the reserved names should be 854 updated to reference this document. Two entries are added: one entry 855 for the well-known realm "WELLKNOWN:PKU2U", and another for the well- 856 known principal name "WELLKNOWN/NULL". 858 This document defines GSS_EXTS_FINISHED extension type. The 859 corresponding IANA registry [GSS-EXTS] need to be updated to 860 reference this document. The following single registration should be 861 added in the registry for "Kerberos V GSS-API mechanism extension 862 types": 2, "GSS-API token checksum", "Extension to provide a checksum 863 for GSS-API tokens", the RFC # of this document. 865 This document also instructs the IANA to extend the "SMI Security for 866 Name System Designators Codes (nametypes)" registry to include an OID 867 for each registration, and to allocate OIDs for the following GSS-API 868 name-types in that registry: 869 o gss-distinguished-name (GSS_C_NT_DN) 870 o gss-hostname (GSS_C_NT_HOSTNAME) 871 o gss-IP-address (GSS_C_NT_IP_ADDR) 872 o gss-e-mail-address (GSS_C_NT_EMAIL_ADDR) 874 11. Normative References 876 [CCITT.X680.2002] 877 International International Telephone and Telegraph 878 Consultative Committee, "Abstract Syntax Notation One 879 (ASN.1): Specification of basic notation", 880 CCITT Recommendation X.680, July 2002. 882 [CCITT.X690.2002] 883 International International Telephone and Telegraph 884 Consultative Committee, "ASN.1 encoding rules: 885 Specification of basic encoding Rules (BER), Canonical 886 encoding rules (CER) and Distinguished encoding rules 887 (DER)", CCITT Recommendation X.690, July 2002. 889 [GSS-EXTS] 890 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 891 Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility (work 892 in progress), 2007. 894 [KRB-ANON] 895 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 896 draft-ietf-krb-wg-anon (work in progress), 2007. 898 [KRB-NAMING] 899 Zhu, L., "Additional Kerberos Naming Constraints", 900 draft-ietf-krb-wg-naming (work in progress), 2007. 902 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 903 text messages", STD 11, RFC 822, August 1982. 905 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 906 STD 13, RFC 1034, November 1987. 908 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 909 RFC 1964, June 1996. 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, March 1997. 914 [RFC2743] Linn, J., "Generic Security Service Application Program 915 Interface Version 2, Update 1", RFC 2743, January 2000. 917 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 918 C-bindings", RFC 2744, January 2000. 920 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 921 "Internationalizing Domain Names in Applications (IDNA)", 922 RFC 3490, March 2003. 924 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 925 Kerberos 5", RFC 3961, February 2005. 927 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 928 Kerberos Network Authentication Service (V5)", RFC 4120, 929 July 2005. 931 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 932 Version 5 Generic Security Service Application Program 933 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 934 July 2005. 936 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 937 Extension for the Generic Security Service Application 938 Program Interface (GSS-API)", RFC 4401, February 2006. 940 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 941 Kerberos V Generic Security Service Application Program 942 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 944 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 945 (LDAP): String Representation of Distinguished Names", 946 RFC 4514, June 2006. 948 [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): 949 Syntaxes and Matching Rules", RFC 4517, June 2006. 951 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 952 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 954 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 955 Housley, R., and W. Polk, "Internet X.509 Public Key 956 Infrastructure Certificate and Certificate Revocation List 957 (CRL) Profile", RFC 5280, May 2008. 959 Authors' Addresses 961 Larry Zhu 962 Microsoft Corporation 963 One Microsoft Way 964 Redmond, WA 98052 965 US 967 Email: lzhu@microsoft.com 968 Jeffery Altman 969 Secure Endpoints 970 255 W 94th St 971 New York, NY 10025 972 US 974 Email: jaltman@secure-endpoints.com 976 Nicolas Williams 977 Sun Microsystems 978 5300 Riata Trace Ct 979 Austin, TX 78727 980 US 982 Email: Nicolas.Williams@sun.com 984 Full Copyright Statement 986 Copyright (C) The IETF Trust (2008). 988 This document is subject to the rights, licenses and restrictions 989 contained in BCP 78, and except as set forth therein, the authors 990 retain all their rights. 992 This document and the information contained herein are provided on an 993 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 994 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 995 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 996 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 997 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 998 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1000 Intellectual Property 1002 The IETF takes no position regarding the validity or scope of any 1003 Intellectual Property Rights or other rights that might be claimed to 1004 pertain to the implementation or use of the technology described in 1005 this document or the extent to which any license under such rights 1006 might or might not be available; nor does it represent that it has 1007 made any independent effort to identify any such rights. Information 1008 on the procedures with respect to rights in RFC documents can be 1009 found in BCP 78 and BCP 79. 1011 Copies of IPR disclosures made to the IETF Secretariat and any 1012 assurances of licenses to be made available, or the result of an 1013 attempt made to obtain a general license or permission for the use of 1014 such proprietary rights by implementers or users of this 1015 specification can be obtained from the IETF on-line IPR repository at 1016 http://www.ietf.org/ipr. 1018 The IETF invites any interested party to bring to its attention any 1019 copyrights, patents or patent applications, or other proprietary 1020 rights that may cover technology that may be required to implement 1021 this standard. Please address the information to the IETF at 1022 ietf-ipr@ietf.org.