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