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