[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                     Microsoft Corporation
Intended status: Standards Track                               J. Altman
Expires: January 15, 2009                               Secure Endpoints
                                                             N. Williams
                                                                     Sun
                                                           July 14, 2008


  Public Key Cryptography Based User-to-User Authentication - (PKU2U)
                           draft-zhu-pku2u-07

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines a Generic Security Services Application Program
   Interface (GSS-API) mechanism based on Public Key Infrastructure
   (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the
   Kerberos V GSS-API mechanism, but without requiring a Kerberos Key
   Distribution Center (KDC).



Zhu, et al.             Expires January 15, 2009                [Page 1]


Internet-Draft                    PKU2U                        July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . .  3
   4.  PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . .  4
     4.1.  GSS_C_NT_DN  . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  GSS_C_NT_HOSTNAME  . . . . . . . . . . . . . . . . . . . .  5
     4.3.  GSS_C_NT_IP_ADDR . . . . . . . . . . . . . . . . . . . . .  5
     4.4.  GSS_C_NT_EMAIL_ADDR  . . . . . . . . . . . . . . . . . . .  6
     4.5.  GSS_C_NT_USER_NAME . . . . . . . . . . . . . . . . . . . .  6
     4.6.  GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . .  6
     4.7.  GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . .  7
     4.8.  Matching host-based service principal names to
           acceptor certificates  . . . . . . . . . . . . . . . . . .  7
   5.  The Protocol Description and the Context Establishment
       Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Context token derived from KRB_AS_REQ  . . . . . . . . . .  9
     5.2.  Context token derived from KRB_AS_REP  . . . . . . . . . . 11
     5.3.  Context tokens imported from RFC4121 . . . . . . . . . . . 11
   6.  Guidelines for Credentials Selection . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16
























Zhu, et al.             Expires January 15, 2009                [Page 2]


Internet-Draft                    PKU2U                        July 2008


1.  Introduction

   The Generic Security Services Application Programming Interface (GSS-
   API) is a generic protocol and API for providing authentication and
   session protection to applications.  It is generic in that it
   supports multiple authentication mechanisms.  Today there exists only
   one workable, widely deployed, standards-track GSS-API mechanism: the
   Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on
   Kerberos V [RFC4120].  There is a need to provide a GSS-API mechanism
   which does not require Kerberos V Key Distribution Center (KDC)
   infrastructure, and which supports the use of public key
   cryptography, particularly Public Key Infrastructure (PKI) [RFC3280],
   including the use of public key certificates without a PKI.

   This document specifies such a mechanism: the Public Key User to User
   mechanism (PKU2U).

   PKU2U is based on building blocks taken from Kerberos V [RFC4120],
   PKINIT, [RFC4556] (which in turn uses PKI [RFC3280]) building
   blocks), and the Kerberos V GSS-API mechanism [RFC1964] [RFC4121].
   In spite of using Kerberos V building blocks, PKU2U does not require
   any Kerberos V KDC infrastructure.  And though PKU2U also uses PKI
   building blocks, PKU2U can be used without a PKI by pre-sharing
   certificates and/or pre-associating name/certificate bindings.

   Therefore PKU2U can be used for true peer-to-peer authentication, as
   well as for PKI-based authentication.


2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In this document, the GSS-API initiator or acceptor is referred to as
   the peer when the description is applicable to both the initiator and
   the acceptor.


3.  The PKU2U Realm Name

   The PKU2U realm name is defined as a reserved Kerberos realm name per
   [KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U".

   Unless otherwise specified, the realm name in any Kerberos message
   used by PKU2U is the PKU2U realm name.




Zhu, et al.             Expires January 15, 2009                [Page 3]


Internet-Draft                    PKU2U                        July 2008


4.  PKU2U Principal Naming

   PKU2U principal names are certificate names and subject alternative
   names [RFC3280] as they appear in the certificate of any PKU2U peer,
   as well as any names agreed to out of band where a certificate
   authenticates a name that does not appear in the certificate.

   Thus certificates may be associated with multiple principal names.
   This presents problems for the GSS-API bindings of a PKI-based
   mechanism.  We resolve these problems as follows:

   o  We define multiple GSS-API name types corresponding to several
      GeneralName choices [RFC3280], along with syntaxes, display forms,
      and exported name token formats for each.  For most of the name-
      types listed below the exported name token formats consists of a
      BER-encoded GeneralName with the usual exported name token header
      as per-RFC2743.  Two name-types are shared with the Kerberos V
      mechanism and use the Kerberos V mechanism's exported name token
      format.
   o  The cred_name of credential object acquired with a desired_name
      other than GSS_C_NT_NO_NAME MUST be equal to the name used as the
      desired_name.
   o  We provide that the cred_name of a default credential, or of a
      credential acquired with the GSS_C_NT_NO_NAME desired_name MUST be
      the first id-pkinit-san subject alternative name of the
      certificate, if there is one, or else it MUST be the DN of its
      certificate.
   o  We provide a method by which initiators can assert one of these
      names to the other, and we provide a default of asserting the
      certificate DN.  We also provide a method of asserting names that
      do not appear in the caller's certificate.  This assertion
      consists of a traditional Kerberos V principal name appearing in
      the expected 'cname' fields of various Kerberos V PDUs used to
      construct PKU2U security context tokens, and an optional
      authorization-data type consisting of an integer which identifies
      one of the several names of the initiator's certificate.
   o  We provide a method of matching host-based service principal names
      to acceptor certificates, so that: a) initiators need not know the
      particulars of an acceptor's certificates' names a priori, b)
      acceptors can select a credential to accept a security context
      with that the initiator will accept.

   Thus GSS-API initiators that use the GSS_C_NO_NAME as the
   desired_name arguments of GSS_Acquire_cred() and GSS_Add_cred(), or
   GSS_C_NO_CREDENTIAL as the cred argument of GSS_Init_sec_context()
   will assert the selected certificate's DN, and that certificate's DN
   will be the name returned by GSS_Inquire_cred() and
   GSS_Inquire_cred_by_mech().



Zhu, et al.             Expires January 15, 2009                [Page 4]


Internet-Draft                    PKU2U                        July 2008


   And portable GSS-API initiator applications using
   GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing
   a name to use as the targ_name input argument of
   GSS_Init_sec_context()) will have a reasonable chance of success in
   authenticating peers with certificates predating this specification.

4.1.  GSS_C_NT_DN

   We introduce a new name type, GSS_C_NT_DN, with OID <TBD>,
   corresponding to the 'Name' ASN.1 type defined in [RFC3280].

   The query syntax and display form for names of this type SHALL be as
   described in [RFC4514].

   There is no reasonable way to canonicalize names of this type without
   providing a directory against which to lookup the name.  The
   canonical form of this name is the same as that provided to
   GSS_Import_name() with GSS_C_NT_DN as the input_name_type.

   The exported name token format for names of this type SHALL be the
   DER encoding of a GeneralName with directoryName as the choice.

   Implementation support for this name type is REQUIRED.

4.2.  GSS_C_NT_HOSTNAME

   We introduce a new name type, GSS_C_NT_HOSTNAME, with OID <TBD>,
   corresponding to the 'dNSName' choice of the 'GeneralName' ASN.1 type
   defined in [RFC3280].

   The query syntax for names of this type SHALL be a DNS name [RFC1034]
   in either ACE or Unicode form [RFC3490].

   The display and canonical form of names of this type SHALL be a DNS
   domainname in ACE form, with character case folded down.

   The exported name token format for names of this type SHALL be the
   DER encoding of a GeneralName with dNSName as the choice and the DNS
   domainname in ACE form and case folded down.

   Implementation support for this name type is OPTIONAL.

4.3.  GSS_C_NT_IP_ADDR

   We introduce a new name type, GSS_C_NT_IP_ADDR, with OID <TBD>,
   corresponding to the 'iPAddress' choice of the 'GeneralName' ASN.1
   type defined in [RFC3280].




Zhu, et al.             Expires January 15, 2009                [Page 5]


Internet-Draft                    PKU2U                        July 2008


   The query syntax, and display and canonical forms for names of this
   type SHALL be the text representation of an IPv4 or IPv6 address (XXX
   add references).

   The exported name token form for this name type SHALL be a DER-
   encoded GeneralName with the iPAddress choice.

   Implementation support for this name type is OPTIONAL.

4.4.  GSS_C_NT_EMAIL_ADDR

   We introduce a new name type, GSS_C_NT_EMAIL_ADDR, with OID <TBD>,
   corresponding to the 'rfc822Name' choice of the 'GeneralName' ASN.1
   type defined in [RFC3280].

   The query syntax and display form for names of this type SHALL be the
   text representation of an 'addr-spec' as defined in [RFC0822].

   The canonical form of names of this type SHALL be the query form with
   case folded down.

   The exported name token form for this name type SHALL be a DER-
   encoded GeneralName with the rfc822Name choice.

   Implementation support for this name type is OPTIONAL.

4.5.  GSS_C_NT_USER_NAME

   For PKU2U the generic name type GSS_C_NT_USER_NAME SHALL be an alias
   of GSS_C_NT_EMAIL_ADDR.

   Implementation support for this name type is OPTIONAL.

4.6.  GSS_KRB5_NT_PRINCIPAL_NAME

   PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964].
   These appear as expected in various 'cname', 'crealm', 'sname' and
   'srealm' fields of the Kerberos V PDUs used to construct PKU2U
   security context tokens.  For PKU2U names of this type correspond to
   subject alternative names of type 'id-pkinit-san' [RFC4556].  When no
   such SAN appears in a certificate, then names of this type correspond
   to certificates as agreed out of band (e.g., there may be a table
   mapping certificates to Kerberos V principal names).

   The canonical form of names of this type SHALL be as specified in
   RFC4121.  (XXX Here we have two mechanisms sharing a single name type
   that originally was mechanism-specific.  This may cause problems with
   some mechglue implementations; we should describe this in detail.)



Zhu, et al.             Expires January 15, 2009                [Page 6]


Internet-Draft                    PKU2U                        July 2008


   Implementation support for this name type is REQUIRED.

4.7.  GSS_C_NT_ANONYMOUS

   This is a generic GSS-API name-type.  Implementation support for this
   name type is OPTIONAL.  See Section 5.1 for more information.

4.8.  Matching host-based service principal names to acceptor
      certificates

   Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described
   herein.

   The query and display forms of this name type are as per-RFC2743.
   The canonical and exported name token forms are as per-RFC1964.

   Initiators using names of type GSS_C_NT_HOSTBASED_SERVICE to identify
   target acceptors represent these names as Kerberos V principal names
   as per [RFC4121] but with a well-known realm name of "WELLKNOWN:
   PKU2U" (see Section 5.1).

   Acceptors match such names to acceptor certificates as follows.
   Initiators then match the certificate chosen by the acceptor in the
   same manner.

   Initiators can also assert host-based service names as the initiator
   name.  In this case acceptors MUST also apply the matching rules
   below to validate the initiator's assertion.

   1.  If the acceptor has a certificate with an id-pkinit-san subject
       alternative name matching the initiator-provided acceptor name,
       then the certificate matches.
   2.  If the acceptor has a certificate with a dNSName SAN that matches
       the hostname part of the host-based service principal name, and
       either the anyExtendedKeyUsage extended key usage (EKU), or no
       EKU is present, or an EKU is present which corresponds to the
       service part of the host-based service principal name, then the
       certificate matches.  The id-kp-serverAuth EKU SHALL be
       considered to match the 'HTTP' service name.  (See Section 9,
       IANA considerations, where the GSS-API service name registry is
       extended to include an EKU for each service name.)
   3.  Implementations SHOULD, subject to local configuration, allowing
       matches where the CN of the DN of a cert matches the hostname
       part of the host-based service name, for some or all service
       names.  This feature is needed to allow the use of existing web
       certificates.





Zhu, et al.             Expires January 15, 2009                [Page 7]


Internet-Draft                    PKU2U                        July 2008


   4.  If there is an out-of-band binding of the peer's host-based
       service name to its certificate, then the certificate matches.


5.  The Protocol Description and the Context Establishment Tokens

   The PKU2U mechanism is a GSS-API mechanism based on [RFC4120],
   [RFC4556] and [RFC4121].

   The per-message tokens of the PKU2U mechanism are the same as those
   of the Kerberos V GSS-API mechanism [RFC4121].

   The PKU2U security context token exchange consists of KRB-AS-REQ and
   KRB-AS-REP (and KRB-ERROR) Kerberos KDC PDUs (with minor changes/
   requirements described below) as context tokens, with the acceptor as
   the KDC, followed by context tokens from [RFC4121] using the Kerberos
   V Ticket PDU issued by the acceptor-as-KDC.  PKINIT [RFC4556] is the
   only acceptable pre-authentication method.  Caching that ticket
   issued by the acceptor allows subsequent security context exchanges
   between the same to peers to use a single context token round-trip --
   a "fast restart" feature.

   PKU2U differs from Kerberos V with PKINIT in several minor ways:

   o  KDC PDUs are not exchanged as usual in Kerberos, but wrapped as
      GSS-API context tokens
   o  PKU2U allows the use of out-of-band binding of certificates to
      principal names
   o  PKU2U does not require the use of KDC certificates
   o  PKU2U adds pa-data types for carrying the initiator's assertion of
      its name and the targ_name passed to GSS_Init_sec_context()

   PKU2U differs from the Kerberos V GSS-API mechanism in several ways:

   o  KDC PDUs are not exchanged as usual in Kerberos, but wrapped as
      GSS-API context tokens
   o  PKU2U allows the use of principal names matching PKI naming
   o  PKU2U adds an extension to the RFC4121 initial context token for
      binding the AP-REQ to the AS exchange that precedes is (that is,
      when the initiator has to request a ticket from the acceptor)
   o  The number of round-trips can vary.  If the initiator already has
      a ticket for the acceptor then the context token exchange will be
      half a round-trip or one round-trip, as per RFC4121.  Otherwise
      one or two round-trips are added for the AS exchanges needed to
      acquire a ticket.  Note that two AS exchanges may be required when
      the initiator's initial choice of certificate does not match the
      acceptor's trust anchors, in which case the acceptor will reply
      with a KRB-ERROR with TD-TRUSTED-CERTIFIERS indicating what the



Zhu, et al.             Expires January 15, 2009                [Page 8]


Internet-Draft                    PKU2U                        July 2008


      acceptor's trust anchors are, and then the initiator can engage in
      a second AS exchange within the same context token exchange.

   To recapitulate, the acceptor and the initiator communicate by
   tunneling the authentication service exchange messages through the
   use of the GSS-API tokens and application traffic.  The reliable
   delivery of the authentication service exchange messages at the GSS-
   API token level is mandatory.  In the event of message loss, message
   duplication, or out of order message delivery, the security context
   MUST fail to establish.

   All context establishment tokens MUST follow the InitialContextToken
   syntax defined in Section 3.1 of [RFC2743].  PKU2U is identified by
   the Objection Identifier (OID) id-kerberos-pku2u.

   All context establishment tokens consist of some Kerberos V PDU or
   another, prefixed with a two-octet token type ID, and the
   InitialContextToken header (see above).

   The PKU2U OID is:

            id-kerberos-pku2u ::=
            { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
            pku2u(7) }

   The innerToken described in section 3.1 of [RFC2743] and subsequent
   GSS-API mechanism tokens have the following formats: it starts with a
   two-octet token-identifier (TOK_ID), followed by a Kerberos message.
   The TOK_ID values for the KRB_AS_REQ message and the KRB_AS_REP
   message are defined in the table blow:

                       Token         TOK_ID Value in Hex
                       -----------------------------------------------
                       KRB_AS_REQ          05 00
                       KRB_AS_REP          06 00

   The TOK_ID values for all other Kerberos messages are the same as
   defined in [RFC4121].

   By using anonymous PKINIT [KRB-ANON], PKU2U can provide server-
   authentication without revealing the client's identity.

5.1.  Context token derived from KRB_AS_REQ

   When the initiator does not have a service ticket to the acceptor, it
   requests a ticket from the acceptor instead of the KDC by
   constructing a KRB_AS_REQ PDU [RFC4120] and using it as the context
   token, with a token type ID prefixed.  This will be the initiator's



Zhu, et al.             Expires January 15, 2009                [Page 9]


Internet-Draft                    PKU2U                        July 2008


   initial context token, therefore it MUST also have the standard
   header bearing the OID of the mechanism being used (in this case,
   PKU2U's OID).

   If the initiator wishes to assert a name of type GSS_C_NT_ANONYMOUS
   then it MUST set the cname field to WELLKNOWN/WELLKNOWN with name
   type KRB_NT_WELLKNOWN [KRB-ANON], and it MUST NOT use a certificate
   [KRB-ANON].  If the initiator wishes to assert a name of type
   GSS_KRB5_NT_PRINCIPAL_NAME, then it MUST set the cname and realm
   fields of the KRB_AS_REQ to match.  Otherwise the initiator MUST add
   a pa-data element (see below) stating the name that the initiator
   wishes to assert, it MUST set the cname field to the anonymous
   principal name, and it MUST set the realm field to "WELLKNOWN:PKU2U"
   with type "other" [KRB-NAMING].

   If the targ_name passed to GSS_Init_sec_context() is of
   GSS_C_NT_ANONYMOUS type, then the sname field of the AS-REQ SHALL be
   set to WELLKNOWN/WELLKNOWN with name type KRB_NT_WELLKNOWN
   [KRB-ANON].  If the targ_name passed to GSS_Init_sec_context() is of
   type GSS_C_NT_HOSTBASED_NAME then the initiator sets the sname field
   to match the parsed name as per [RFC4121], and there is no notion of
   server realm name in this case.  In all other cases the initiator
   MUST produce the exported name token for the given targ_name and MUST
   include it as the pa-value of an pa-data element whose pa-type SHALL
   be <TBD>, and the initiator MUST set the sname field of the AS-REQ to
   WELLKNOWN/WELLKNOWN with name type KRB_NT_WELLKNOWN [KRB-ANON] -- the
   presence of the targ_name pa-data element means the targ_name is not
   of type GSS_C_NT_ANONYMOUS.

   The token type ID for this token SHALL be 05 00.

   The pa-data element for the initiator's name assertion SHALL be of
   ad-type <TBD> and its ad-value SHALL consist of the BER encoding of
   the following:

                           InitiatorNameAssertion ::= CHOICE {
                               -- -1 -> certificate DN
                               -- 0..16384 -> subjectAltName named by
                               --             this index
                               sanIndex INTEGER (-1..16384),
                               nameNotInCert GeneralName -- from RFC3280
                           }

   The acceptor MUST validate this token as a Kerberos V KDC would
   validate a PKINIT AS-REQ, and also MUST check that the initiator's
   asserted name is present in the initiator's certificate or otherwise
   bound to the initiator's certificate by out-of-band negotiation
   (e.g., by a table lookup).  Failure to validate this token MUST cause



Zhu, et al.             Expires January 15, 2009               [Page 10]


Internet-Draft                    PKU2U                        July 2008


   GSS_Accept_sec_context() to return an error and, optionally, to
   output a KRB-ERROR context token as per-RFC4121.

5.2.  Context token derived from KRB_AS_REP

   When the initiator's initial context token is a KRB_AS_REQ then the
   acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or
   a token derived from a KRB_AS_REP PDU [RFC4120] constructed to
   respond to the initiator's KRB_AS_REQ.

   The acceptor MUST only accept PKINIT pre-authentication.  If the
   initiator's KRB_AS_REQ token is valid, and the initiator's asserted
   name is bound to the certificate (see Section 5.1 and Section 4) then
   the acceptor MUST select a certificate (if it has more than one)
   which matches the initiator's targ_name (or any certificate at all,
   if the initiator's targ_name is the anonymous name), and then the
   acceptor MUST construct a KRB_AS_REP as usual for PKINIT, except that
   there is no requirement to use a KDC certificate.

   The initiator then validates this token according to Section 3.1.5 of
   [RFC4120] and Section 3.2.4 of [RFC4556].  The inclusion of the EKU
   KeyPurposeId [RFC3280] id-pkinit-KPKdc in the X.509 certificate in
   the response is not applicable when PKU2U is used because there is no
   KDC involved in this protocol.  The initiator MUST verify that the
   acceptor's certificate matches the targ_name passed in to
   GSS_Init_sec_context().

5.3.  Context tokens imported from RFC4121

   Once the initiator has a Kerberos V Ticket for the acceptor the
   security context token exchange will continue with those of the
   Kerberos V GSS-API mechanism [RFC4121] with the following
   modifications:

   o  the mechanism OID of PKU2U SHALL be used instead of that of the
      Kerberos V GSS-API mechanism;
   o  a sub-session key MUST be included in the initiator's
      Authenticator;
   o  if the initiator's initial context token is a KRB_AS_REQ token
      (i.e., not KRB_AP_REQ token), then the Exts field in the
      Authenticator of the KRB_AP_REQ-derived token [GSS-EXTS] MUST
      contain an extension of the type GSS_EXTS_FINISHED (extension type
      ID <TBA>) and the extension data contains a DER-encoded value of
      the Kerberos V 'Checksum' type, where the checksum (actually, a
      MAC, see [RFC3961]) is taken over all the preceding context tokens
      in this exchange (including the InitialContextToken header),
      concatenated in chronological order (remember, GSS-API context
      token exchanges are synchronous).  The key usage number for this



Zhu, et al.             Expires January 15, 2009               [Page 11]


Internet-Draft                    PKU2U                        July 2008


      checksum is KEY_USAGE_FINISHED (number 41).

   The acceptor MUST process this token as usual for RFC4121, except
   that if the context token exchange included an AS eschange, then the
   acceptor MUST also validate the GSS_EXTS_FINISHED and return an error
   if it is not valid or not present.  But if this is the initial
   context token then the acceptor MUST return an error if
   GSS_EXTS_FINISHED is present.

   The GSS_EXTS_FINISHED (along with the ticket) binds the second part
   of the context token exchange to the first, and it binds the pa-data
   used in the request as well (this needs to be done because PKINIT
   does not bind pa-data other than PKINIT pa-data from the request).
   GSS_EXTS_FINISHED also protects all otherwise unauthenticated
   plaintext in Kerberos V PDUs.  Note that GSS_EXTS_FINISHED also
   protects the mechanism OID in the InitialContextToken header.

                           KEY_USAGE_FINISHED            41


6.  Guidelines for Credentials Selection

   If a peer, either the initiator or the acceptor, has multiple pairs
   of public-key private keys, a choice is to be made in choosing the
   best fit.  The trustedCertifiers field in the PA-PK-AS-REQ structure
   [RFC4556] SHOULD be filled by the initiator, to provide hints for
   guiding the selection of an appropriate certificate chain by the
   acceptor.

   If the initiator's X.509 certificate cannot be validated according to
   [RFC3280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS
   structure [RFC4556] that provides hints for guiding the selection of
   an appropriate certificate by the initiator.  In this case
   GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the
   initiator gets to try again in its subsequent AS-REQ token.

   The GSS-API does not provide a way to make this credential selection
   interactive, however, whenever the context allows for direct
   interaction of the mechanism with the user then it is RECOMMENDED
   that implementations do so.

   If the certificates cannot be selected interactively, and multiple
   certificates can be used, it is RECOMMENDED that initiators fail the
   context establishment thus avoid confusions caused by an unexpected
   programmatic selection.  Users should be able to retry using a
   specific credential (this requires that distinct credentials have
   distinct names that can be used to acquire each credential
   separately).



Zhu, et al.             Expires January 15, 2009               [Page 12]


Internet-Draft                    PKU2U                        July 2008


7.  Security Considerations

   The security considerations in [RFC4556] apply here.  This mechanism
   relaxes some requirements of PKINIT and adds a device for protecting
   otherwise unauthenticated plaintext in the protocol -- it is crucial
   that this device be faithfully implemented.  It is also crucial that
   both the initiator and the acceptor MUST be able to verify the
   binding between the signing key and the associated identity.


8.  Acknowledgements

   The authors would like to thank Jeffrey Hutzelman for his insightful
   comments on the earlier revisions of this document.

   In addition, the following individuals have provided review comments
   for this document: Nicolas Williams, Sam Hartman, Leif Johansson,
   Olga Kornievskaia, Martin Rex, and Sunil Gottumukkala.

   Ari Medvinsky provided help in editing the initial revisions of this
   document.

   The text for the DN mapping is compiled directly from the email
   discussions among the following individuals: Howard Chu, Martin Rex,
   Nicolas Williams, Jeffrey Hutzelman, Kevin Coffman, Henry B. Hotz,
   Leif Johansson, and Olga Kornievskaia.  Howard and Jeffery clearly
   illustrated the challenges in creating a unique mapping, while
   Nicolas and Martin demonstrated the relevance and interactions to
   GSS-API and Kerberos.


9.  IANA Considerations

   Section 3 defines the PKU2U realm.  The IANA registry for the
   reserved names should be updated to reference this document.

   This document defines GSS_EXTS_FINISHED extension type.  The
   corresponding IANA registry need to be updated to reference this
   document.  The following single registration should be added in the
   registry for "Kerberos V GSS-API mechanism extension types":
   GSS_EXTS_FINISHED, "GSS-API token checksum", "Extension to provide a
   checksum for GSS-API tokens", the RFC # of this document.

   This document also expands the existing GSS-API service name
   registry, that IANA maintains, to have a an assignment of one or more
   OIDs for each service name.  The id-kp-serverAuth OID [RFC3280] is
   immediately registered as the OID for the "HTTP" service name.




Zhu, et al.             Expires January 15, 2009               [Page 13]


Internet-Draft                    PKU2U                        July 2008


10.  Normative References

   [GSS-EXTS]
              Emery, S., "Kerberos Version 5 GSS-API Channel Binding
              Hash Agility",
              draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in
              progress), 2007.

   [KRB-ANON]
              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.

   [KRB-NAMING]
              Zhu, L., "Additional Kerberos Naming Constraints",
              draft-ietf-krb-wg-naming-04 (work in progress), 2007.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
              RFC 1964, June 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, February 2005.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos



Zhu, et al.             Expires January 15, 2009               [Page 14]


Internet-Draft                    PKU2U                        July 2008


              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              July 2005.

   [RFC4514]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names",
              RFC 4514, June 2006.

   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.


Authors' Addresses

   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email: lzhu@microsoft.com


   Jeffery Altman
   Secure Endpoints
   255 W 94th St
   New York, NY  10025
   US

   Email: jaltman@secure-endpoints.com


   Nicolas Williams
   Sun Microsystems
   5300 Riata Trace Ct
   Austin, TX  78727
   US

   Email: Nicolas.Williams@sun.com












Zhu, et al.             Expires January 15, 2009               [Page 15]


Internet-Draft                    PKU2U                        July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Zhu, et al.             Expires January 15, 2009               [Page 16]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/