diff --git a/doc/standardisation/draft-zhu-pku2u-09.txt b/doc/standardisation/draft-zhu-pku2u-09.txt new file mode 100644 index 000000000..e6d1b75e7 --- /dev/null +++ b/doc/standardisation/draft-zhu-pku2u-09.txt @@ -0,0 +1,1288 @@ + + +NETWORK WORKING GROUP L. Zhu +Internet-Draft Microsoft Corporation +Intended status: Standards Track J. Altman +Expires: May 7, 2009 Secure Endpoints + N. Williams + Sun + November 3, 2008 + + + Public Key Cryptography Based User-to-User Authentication - (PKU2U) + draft-zhu-pku2u-09 + +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 May 7, 2009. + +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 May 7, 2009 [Page 1] + +Internet-Draft PKU2U November 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3 + 4. The NULL Principal Name . . . . . . . . . . . . . . . . . . . 4 + 5. PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . . 4 + 5.1. GSS_C_NT_DN . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.2. GSS_C_NT_HOSTNAME . . . . . . . . . . . . . . . . . . . . 6 + 5.3. GSS_C_NT_EMAIL_ADDR . . . . . . . . . . . . . . . . . . . 7 + 5.4. GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . . 7 + 5.5. GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . . 9 + 5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based + Principal Names to Acceptor Certificates . . . . . . . . . 9 + 6. The Protocol Description and the Context Establishment + Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Context Token Derived from KRB_AS_REQ . . . . . . . . . . 12 + 6.2. Context Token Derived from KRB_AS_REP . . . . . . . . . . 15 + 6.3. Context Tokens Imported from RFC4121 . . . . . . . . . . . 16 + 7. Guidelines for Credentials Selection . . . . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . . . 23 + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu, et al. Expires May 7, 2009 [Page 2] + +Internet-Draft PKU2U November 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) [RFC5280], + 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 [RFC5280]) 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". + + The PKU2U realm name has no meaning, but is intended to be used in + the Kebreros V Protocol Data Units (PDUs) that are re-used by PKU2U + wherever realm names are needed. Unless otherwise specified, the + + + +Zhu, et al. Expires May 7, 2009 [Page 3] + +Internet-Draft PKU2U November 2008 + + + realm name in any Kerberos message used by PKU2U is the PKU2U realm + name. + + +4. The NULL Principal Name + + The NULL Kerberos principal name is defined as a well-known Kerberos + principal name based on [KRB-NAMING]. The value of the name-type + field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name- + string field is a sequence of two KerberosString components: + "WELLKNOWN", "NULL". + + The NULL Kerberos principal name is used in the Kerberos messages + where there is no Kerberos representation of the principal name, for + example, when the client name is a Distinguished Name. When the NULL + principal name is used in the Kerberos messages, the principal name + is either not used or provided separately (for example in the + PA_PKU2U_NAME padata defined in Section 6.1). + + +5. PKU2U Principal Naming + + The GSS-API targ_name supplied for the initiator MUST NOT be + GSS_C_NO_NAME in PKU2U. + + PKU2U principal names can be Kerberos principal names, and they can + also be distiguished names, or subject alternative names [RFC5280] as + they appear in the certificate of any PKU2U peer, as well as any + names agreed to out of band that do not appear in the peer + certificates. + + Certificates may be associated with multiple principal names. This + presents problems for the GSS-API bindings of a PKI-based mechanism + because, for example, for any given, established GSS-API security + mechanism there can be only one initiator name, and one acceptor + name, and credential handles may be associated with only one name. + We resolve these problems as follows: + + o We define multiple GSS-API name types corresponding to several + GeneralName choices [RFC5280], 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 + 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 query and display syntaxes, + canonicalization rules, and exported name token format. + + + + + +Zhu, et al. Expires May 7, 2009 [Page 4] + +Internet-Draft PKU2U November 2008 + + + o The cred_name of a credential handle acquired with + GSS_C_NT_NO_NAME as the desired_name SHOULD be the Distinguished + Name (DN) of the certificate underlying the credential. If there + are multiple certificates and private keys, then either one MUST + be selected by local, implementation-specific means, or credential + acquisition with GSS_C_NT_NO_NAME MUST fail (implementers may + choose which of these two behaviors to provide). + + o When using desired_name values other than GSS_C_NT_NO_NAME for + credential handle acquisition then the implementation MUST use + exact matching of the given desired_name to a certificate's DN or + Subject Alternative Names (SANs) for all name-types given below, + except for GSS_C_NT_DN, where matching rules are fuzzier and given + below. The names of a X.509 certificate will be compared to the + given desired_name in this order: certificate DN first, then SANs + in the order in which they appear in the certificate. When + multiple certificates and private keys are available the order in + which the various certificates are searched is significant; no + canonical certificate collation order is defined herein. + + o The cred_name of a credential object acquired with a desired_name + other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or + SAN matched by the given desired_name. + + o We provide a method (see below) by which initiators can assert, in + their context tokens, one of these names of the initiator. We + also provide a method of asserting names that do not appear in a + X.509 certificate, in which case the binding of X.509 certificate + to the asserted name is done out-of band. The name to be + asserted, of course, is the cred_name of the cred_handle passed to + GSS_Init_sec_context(). + + o The initiator's context tokens may also indicate what is the + expected name of the acceptor -- the targ_name passed in to + GSS_Init_sec_context(). + + o No attempt is made to map Kerberos V realm names to trust anchor + certificate authority (CA) names. + + 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, c) existing certificates for + web servers, may be used as host-based service principal names as + though the service name were "HTTP". + + Thus GSS-API initiator applications that use the GSS_C_NO_NAME as the + + + +Zhu, et al. Expires May 7, 2009 [Page 5] + +Internet-Draft PKU2U November 2008 + + + 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 X.509 certificate's subject DN, and that + X.509 certificate's subject DN will be the name returned by + GSS_Inquire_cred() and GSS_Inquire_cred_by_mech(). + + 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 X.509 certificates predating this + specification. + +5.1. GSS_C_NT_DN + + The name type GSS_C_NT_DN, with Object Identifier (OID) (see + Section 10), is defined. This corresponds to the 'directoryName' + choice of the 'GeneralName' Abstract Syntax Notation One (ASN.1) + [CCITT.X680.2002] type defined in [RFC5280]. + + The query syntax and display form for names of this type SHALL be as + described in [RFC4514]. + + As RFC4514 says, "[c]omparison of DNs for equality is to be performed + in accordance with the distinguishedNameMatch matching rule + [RFC4517]". + + There is no reasonable way to canonicalize names of this type without + providing certificates to match query forms of GSS_C_NT_DN against, + such as in the form of a directory. Therefore + GSS_Canonicalize_name() as applied to names imported with the + GSS_C_NT_DN name-type MUST search available certificate databases, or + directories, or MUST fail. No method of locating and searching + directories for matching certificate DNs is specified herein. Note + though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context() + can and, indeed, MUST return "mechanism names" (MN) (see [RFC2743]). + + The exported name token format for names of this type SHALL be the + Distinguished Encoding Rules (DER) [CCITT.X680.2002] + [CCITT.X690.2002] encoding of a GeneralName with directoryName as the + choice. + + Implementation support for this name type is REQUIRED. + +5.2. GSS_C_NT_HOSTNAME + + The name type GSS_C_NT_HOSTNAME, with OID , is defined. This + corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type + + + +Zhu, et al. Expires May 7, 2009 [Page 6] + +Internet-Draft PKU2U November 2008 + + + defined in [RFC5280]. + + 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 + domain name in ACE form, with character case folded down. + Canonicalization consists merely of applying the ToASCII() function + and case-folding the result. + + 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 + domain name in ACE form and case folded down. + + Implementation support for this name type is OPTIONAL. + +5.3. GSS_C_NT_EMAIL_ADDR + + The name type GSS_C_NT_EMAIL_ADDR, with OID , is defined. This + corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1 + type defined in [RFC5280]. + + 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. Note that the domain name part of an addr-spec is + a "domain name slot" and so the canonicalization rules for + GSS_C_NT_HOSTNAME given above apply here as well. + + The exported name token form for this name type SHALL be the DER- + encoding of a GeneralName with the rfc822Name choice. + + Implementation support for this name type is OPTIONAL. + +5.4. GSS_KRB5_NT_PRINCIPAL_NAME + + PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964]. + + The query, display, canonical and exported name token forms of names + of this type SHALL be as specified in RFC4121. The realm name part + of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax; + when canonicalized, names of this type lacking a realm name will have + the well-known PKU2U realm name affixed. + + When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted + or otherwise is the well-known PKU2U realm name, then the "cname"' or + sname fields of the Kerberos V PDUs used to construct PKU2U security + + + +Zhu, et al. Expires May 7, 2009 [Page 7] + +Internet-Draft PKU2U November 2008 + + + context tokens MUST be set to the principal name part of the given + NAME. Otherwise the PA_PKU2U_NAME pre-authentication data MUST be + used to indicate a name of id-pkinit-san type [RFC4556] corresponding + to the given NAME. See Section 5.4. + + No attempt is made to map Kerberos V realm names to trust anchor + certificate authority (CA) names. + + Note that having more than one mechanism share name-types has + implications for multi-mechanism, pluggable GSS-API implementations + (commonly referred to as "mechglue"). Specifically: + + o It must be the responsibility of the mechanism, not of the + mechglue, to ensure that the standard exported name token header + (which includes a mechanism OID), is included in exported name + tokens. The exported name token for a GSS_KRB5_NT_PRINCIPAL_NAME + MN produced by PKU2U would have PKU2U's mechanism OID in the + header. + + o A pluggable mechglue must be able to find a mechanism that can + import an exported name token if an available mechanism can + produce that exported name token. For example, a pluggable + mechglue where PKU2U is available but where the Kerberos V + mechanism [RFC1964] is not should still be able to import exported + Kerberos V name tokens since PKU2U can create such tokens. One + way to do this would be for the mechglue to try the mechanism + named in the exported name token header, if it is available, else + try all other available mechanisms until one succeeds or all fail. + It would be reasonable for a mechglue implementer to require that + the Kerberos V mechanism be available if PKU2U is too. + + o It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use + a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name + argument value to acquire a PKU2U credential. Similarly, it must + be possible to use a Kerberos V MN as the target_name in a call to + GSS_Init_sec_context with PKU2U as the mech OID. A multi- + mechanism mechglue implementer would likely have a mechglue-layer + NAME object that internally keeps a reference to a NAME object + produced by the underlying mechanism, but a pluggable mechglue + could not expect two different mechanisms to be able to share + their internal NAME objects. A clever implementer can work around + this by exporting the one mechanism's MN and then re-importing + using the target mechanism's GSS_Import_name() service function. + + o It must be possible for the credential inquiry functions (e.g., + GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a + cred_name that is an MN of a different mechanism than the + credential element being inquired. + + + +Zhu, et al. Expires May 7, 2009 [Page 8] + +Internet-Draft PKU2U November 2008 + + + Implementation support for this name type, with defaulted realm name + or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use + with any other realm names. + +5.5. GSS_C_NT_ANONYMOUS + + This is a generic GSS-API name-type. Implementation support for this + name type is OPTIONAL. See Section 6.1 for more information. + + See [RFC2743] and [RFC2744] for more information about this name + type. + + The PKU2U mechanism only supports anonymous initiators, not + acceptors. + + Implementation support for this name type is RECOMMENDED. + +5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based Principal Names + to Acceptor Certificates + + Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described + herein. + + The query form of this name type is as per-RFC2743. The canonical + and exported name token forms are as per-RFC1964. The display form + of this name type is left unspecified, but should either be as per- + RFC2743 or the same as the display form for + GSS_KRB5_NT_PRINCIPAL_NAME [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 [RFC1964] but with a well-known realm name of "WELLKNOWN: + PKU2U" (see Section 5.4). + + 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, in order, to validate the initiator's assertion. + + 1. If there is an out-of-band binding of the peer's host-based + service name to its certificate, then the certificate matches. + + 2. If the peer has a certificate with an id-pkinit-san subject + alternative name matching the initiator-provided acceptor name, + then the X.509 certificate matches. + + + +Zhu, et al. Expires May 7, 2009 [Page 9] + +Internet-Draft PKU2U November 2008 + + + 3. If a X.509 certificate has 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 + X.509 certificate matches. The id-kp-serverAuth EKU SHALL be + considered to match the 'HTTP' service name. (See Section 10, + IANA considerations, where the GSS-API service name registry is + extended to include an EKU for each service name.) + + 4. Implementations SHOULD, subject to local configuration, allow + matches where the single-component cn of the DN of a X.509 + certificate 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 X.509 web certificates. + + Implementation support for this name type as an acceptor name is + REQUIRED. Implementation support for this name type as an initiator + name is OPTIONAL. + + +6. 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 GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same + as that of the Kerberos V GSS-API mechanism [RFC4402]. + + The PKU2U security context token exchange consists of KRB_AS_REQ and + KRB_AS_REP (and KRB_ERROR) Kerberos KDC PDUs (with no changes to + their ASN.1 description, but with other 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 in this document. Caching the + 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 reconnect" feature. + + PKU2U differs from Kerberos V with PKINIT in several minor ways as + follows (this is not a complete list): + + + + + + +Zhu, et al. Expires May 7, 2009 [Page 10] + +Internet-Draft PKU2U November 2008 + + + o KDC PDUs are not exchanged as usual in Kerberos, but wrapped as + [the first two] GSS-API context tokens. + + o PKU2U does not use 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 described in [RFC4120], but wrapped + as GSS-API context tokens. + + o PKU2U allows the use of principal names matching PKI naming (see + Section 5). PKU2U does support the use of Kerberos V naming, but + requires only support of Kerberos V naming to a limited extent + (full support is optional). + + o PKU2U adds an extension [GSS-EXTS] 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 X.509 certificate does not match + the acceptor's trust anchors, in which case the acceptor SHOULD + reply with a KRB-ERROR with TD-TRUSTED-CERTIFIERS indicating what + the acceptor's trust anchors are, and then the initiator can + engage in a second AS exchange within the same GSS-API context. + + 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. In the event of + security context token loss, message duplication, or out of order + message delivery, the security context MUST fail to establish. + + All security 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. + + + + + + + +Zhu, et al. Expires May 7, 2009 [Page 11] + +Internet-Draft PKU2U November 2008 + + + The PKU2U OID is: + + id-kerberos-pku2u ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) + pku2u(7) } + + 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 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 AS-REQ message and the 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]. + + It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U + can authenticate the acceptor without revealing the initiator's + identity + +6.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 from 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 + 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). + + The initiator MUST NOT set any KDC options in the 'kdc-options' field + of the AS-REQ. + + The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known + PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING]. + + If the initiator wishes to assert a name of type + GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it + MUST set the 'cname' field of the AS-REQ accordingly if and only if + the realm name part of the given name object is defaulted or the + + + +Zhu, et al. Expires May 7, 2009 [Page 12] + +Internet-Draft PKU2U November 2008 + + + well-known PKU2U realm name. 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 NULL principal name as + defined in Section 4. + + 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 of + the AS-REQ to match the parsed name as per [RFC4121]. If the target + name does not have a representation as a Kerberos principal name per + [RFC1964], then the initiator MUST add a pa-data element (see below) + stating the given targ_name and the initiator MUST set the 'sname' + field of the AS-REQ to the NULL principal name as defined in + Section 4. + + The padata used to convey initiator and target names is of type + PA_PKU2U_NAME <136> and it's value consists of the DER + [CCITT.X680.2002] [CCITT.X690.2002] encoding of the ASN.1 type + InitiatorNameAssertion (with explicit tagging). + + InitiatorName ::= CHOICE { + -- -1 -> certificate DN + -- 0..16384 -> subjectAltName named by + -- this index + sanIndex INTEGER (-1..16384), -- DN or SAN + nameNotInCert GeneralName, -- name not present in cert + -- (see RFC5280 for definition + of GeneralName) + ... + } + + TargetName ::= CHOICE { + exportedTargName OTCET STRING, -- exported krb5 name + generalName [0] GeneralName, -- all other PKI names + -- (tagged to distinguish + -- from nameNotInCert + -- choice of InitiatorName) + ... + } + + InitiatorNameAssertion ::= SEQUENCE { + initiatorName InitiatorName OPTIONAL, + targetName TargetName OPTIONAL, + ... + } + + The initiatorName, if present, contains the initiator's name. The + initiator can fill out either the sanIndex field or the nameNotInCert + field to indicate the name of the initiator. + + + +Zhu, et al. Expires May 7, 2009 [Page 13] + +Internet-Draft PKU2U November 2008 + + + The sanIndex field, if present, is used to refer to either the + Distinguished Name or the SubjectAltName in the initiator's X.509 + certificate. A sanIndex value of -1 value refers to the initiator's + certificate's DN. All other legal values of sanIndex refer to the + corresponding element of the SubjectAltName sequence. A value of 0 + means the first instance of GeneralName in the SubjectAltName + sequence, and 1 means the second, and so on. If the sanIndex value + is equal or biger than the number of GeneralName elements in the + SubjectAltName, the security context establishment attempt MUST fail. + + The nameNotInCert field, if present, contains the initiator's + GeneralName. + + If an initiator name assertion is included, the acceptor MUST verify + that this asserted name is either present in the initiator's + certificate or otherwise bound to the initiator's certificate by out- + of-band provisioning (e.g., by a table lookup). Failure to validate + the asserted initiator's name MUST cause GSS_Accept_sec_context() to + return an error and, optionally, to output a KRB_ERROR context token + as per-RFC4121. + + The initiatorName field MUST NOT be present if the initiator is + anonymous or if the 'cname' field of the AS-REQ is not the NULL name + (see Section 4). + + Target names passed to GSS_Init_sec_context() that can be represented + as Kerberos V principal names, namely, names of + GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be + represented as the 'sname' field of the AS-REQ or as the + exportedTargName choice of TargetName (if the realm part is not the + PKU2U realm name). The contents of the exportedTargName octet string + MUST be an exported name token for the Kerberos V mechanism + containing a Kerberos V principal name. + + Other target names are represented as a generalName choice of + TargetName. These may be present in an acceptor certificate, or + agreed out of band. + + The acceptor MUST select an appropriate acceptor credential that + matches the AS-REQ's 'sname' (if not NULL) or the targetName provided + in the InitiatorNameAssertion, when present. + + The targetName field MUST NOT be present if the 'sname' field of the + AS-REQ is not the NULL name. The targetName field MUST be present if + the 'sname' field of the AS-REQ is the NULL name. + + The PA_PKU2U_NAME padata SHOULD NOT be present when the initiatorName + and targetName both shouldn't be present. + + + +Zhu, et al. Expires May 7, 2009 [Page 14] + +Internet-Draft PKU2U November 2008 + + + Implementation note: the encrypted part of a PKU2U Ticket can be + anything at all since the only entity that will consumer a given + PKU2U Ticket is the same entity that issued it. Implementers may + choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and + DER encoding. + +6.2. Context Token Derived from KRB_AS_REP + + When the initiator's initial context token is a 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 initiator MUST use PKINIT pre-authentication and the acceptor + MUST require it. If the initiator does not use PKINIT pre- + authentication then the acceptor MUST respond with a KRB-ERROR and + indicate that PKINIT is required. + + If the initiator's KRB_AS_REQ token is valid, and the asserted + initiator's name, if present, is bound with the initiator's + certificate, and the acceptor can select a certificate based on the + initiator's asserted targ_name, the acceptor then constructs a + KRB_AS_REP using PKINIT as described in [RFC4556], except that the + acceptor's certificate is used in the place of the KDC certificate. + If and only if the initiator's X.509 certficate is validated using + PKI, the acceptor SHOULD include an authorization element + AD_INITIAL_VERIFIED_CAS [RFC4556] in the returned ticket. If an + InitiatorName is included in the PA_PKU2U_NAME padata in the request, + an authorization element of the type ad-pku2u-client-name <143> MUST + be included in the returned ticet and this authorization element + contains the DER encoded InitiatorName in the request. + + The initiator then validates the KRB-AS-REP reply context token + according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of + [RFC4556]. The inclusion of the EKU KeyPurposeId [RFC5280] 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 is bound with the targ_name passed in to + GSS_Init_sec_context(), by verifying either the targ_name matches + with either the subject DN or one instance of the SubjectAltName name + in the acceptor's certificate, or otherwise the targ_name is bound + with the acceptor's certificate by out-of-band provisioning (e.g., by + a table lookup). Failure to validate this name binding MUST cause + the authentication to be rejected. + + The 'flags' field of the AS-REP MUST have only the 'initial' and + 'pre-authent' flags set. + + + +Zhu, et al. Expires May 7, 2009 [Page 15] + +Internet-Draft PKU2U November 2008 + + + The 'authtime' field of the AS-REP MUST be set to the acceptor's + current time as it is when it formats the AS-REP. + + Otherwise all other aspects of the AS-REP are as described in + [RFC4120]. + + The values of the tkt-vno, realm and 'sname' fields of the Ticket + issued by the acceptor are unspecified. The initiator MUST NOT + examine them for correctness. Cut-n-paste attacks are prevented by + the fact that PKU2U provides integrity protection for all cleartext + in Kerberos V PDUs used by PKU2U (and for the mechanism OID). + +6.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 The 'crealm' field of the initiator's Authenticator MUST be set to + the PKU2U realm name and if the 'cname" field is the NULL + principal name, an authorization element of the type ad-pku2u- + client-name <143> MUST be included in the authenticator and this + authorization element contains the DER encoded InitiatorName in + the AS-REQ based on which the ticket was obtained; + + o The sub-session key MUST be used in the initiator's Authenticator; + + o The contents of the encrypted part of the Ticket can be + implementation specific since the only entity consuming it will be + the same entity that issues it; + + 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 MUST contain an + extension [GSS-EXTS] of the type GSS_EXTS_FINISHED <2> as defined + next in this section. + + The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of + the Authenticator are set as per [RFC4121] and [RFC4120]. + + The 'cksum' field of the Authenticator MUST be set as per [RFC4121]. + The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS] + contains the DER encoding of the ASN.1 structure KRB-FINISHED. + + + + +Zhu, et al. Expires May 7, 2009 [Page 16] + +Internet-Draft PKU2U November 2008 + + + GSS_EXTS_FINISHED 2 + --- The type for the checksum extension. + + KRB-FINISHED ::= SEQUENCE { + gss-mic [1] Checksum, + -- Contains the checksum (RFC3961) of the GSS-API tokens + -- that have been exchanged between the initiator and the + -- acceptor and prior to the containing AP-REQ GSS-API token. + -- The checksum is performed over the GSS-API + -- context tokens in the order that the tokens were sent. + ... + } + + The gss-mic field contains a Kerberos checksum [RFC3961] that is + computed over all the preceding context tokens of this GSS-API + context (including the InitialContextToken header), concatenated in + chronological order (note that GSS-API context token exchanges are + synchronous). The checksum type is the required checksum type of the + enctype of the subkey in the authenticator, the protocol key for the + checksum operation is the authenticator subkey, and the key usage + number is KEY_USAGE_FINISHED <41>. + + The acceptor MUST process the KRB_AP_REQ token as usual for RFC4121, + except that if the context token exchange included an AS exchange, + then the acceptor MUST also validate the GSS_EXTS_FINISHED and return + an error if it is not valid or not present. But if a KRB_AP_REQ + context token 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. + + The acceptor MUST verify that the ad-pku2u-client-name authorization + element is present in the authenticator if and only there is an + authorization element of the same type in the ticket and the values + of these two elements MUST match exactly based on bit-wise + comparison. + + +7. Guidelines for Credentials Selection + + If a peer, either the initiator or the acceptor, has multiple pairs + of public-key private keys and certificates, a choice is to be made + + + +Zhu, et al. Expires May 7, 2009 [Page 17] + +Internet-Draft PKU2U November 2008 + + + 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 + [RFC5280], 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 programming interface to make this + credential selection interactive, though implementers may provide + methods for user interaction related to credential selection and + acquisition (e.g., name and password/PIN prompts). Whenever the + execution context allows for direct interaction of the mechanism with + the user then it is RECOMMENDED that implementations interact with + the user to select a credential whenever multiple credentials are + equally usable and no other mechanism is available to inform the + credential selection. + + If the certificates cannot be selected interactively, multiple + certificates are equally usable, and there is no other mechanism + available for credential selection, then it is RECOMMENDED that + initiators fail the context. 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). + + +8. Security Considerations + + The security considerations in [RFC4120], [RFC4121], [RFC4556] and + [RFC5280] apply here. This mechanism relaxes some requirements of + PKINIT and adds a device for protecting otherwise unauthenticated + plaintext in the protocol (see Section 6.3) -- 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 asserted identity. + + Note that PKU2U is just as susceptible to replays of AP-REQs as the + traditional Kerberos V GSS-API mechanism [RFC4121], though only when + using an AP-REQ as the initial security context token. It is + important, therefore, to use a replay cache to detect replays. + + + + + + +Zhu, et al. Expires May 7, 2009 [Page 18] + +Internet-Draft PKU2U November 2008 + + +9. 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: 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 from the email discussions + among the following individuals: Howard Chu, Martin Rex, 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. + + +10. IANA Considerations + + This document defines the PKU2U realm and the place-holder well-known + principal name. The IANA registry for the reserved names should be + updated to reference this document. Two entries are added: one entry + for the well-known realm "WELLKNOWN:PKU2U", and another for the well- + known principal name "WELLKNOWN/NULL". + + This document defines GSS_EXTS_FINISHED extension type. The + corresponding IANA registry [GSS-EXTS] 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": 2, "GSS-API token checksum", "Extension to provide a checksum + for GSS-API tokens", the RFC # of this document. + + This document also instructs the IANA to extend the "SMI Security for + Name System Designators Codes (nametypes)" registry to include an OID + for each registration, and to allocate OIDs for the following GSS-API + name-types in that registry: + o gss-distinguished-name (GSS_C_NT_DN) + o gss-hostname (GSS_C_NT_HOSTNAME) + o gss-IP-address (GSS_C_NT_IP_ADDR) + o gss-e-mail-address (GSS_C_NT_EMAIL_ADDR) + + +11. Normative References + + [CCITT.X680.2002] + + + +Zhu, et al. Expires May 7, 2009 [Page 19] + +Internet-Draft PKU2U November 2008 + + + International International Telephone and Telegraph + Consultative Committee, "Abstract Syntax Notation One + (ASN.1): Specification of basic notation", + CCITT Recommendation X.680, July 2002. + + [CCITT.X690.2002] + International International Telephone and Telegraph + Consultative Committee, "ASN.1 encoding rules: + Specification of basic encoding Rules (BER), Canonical + encoding rules (CER) and Distinguished encoding rules + (DER)", CCITT Recommendation X.690, July 2002. + + [GSS-EXTS] + Emery, S., "Kerberos Version 5 GSS-API Channel Binding + Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility (work + in progress), 2007. + + [KRB-ANON] + Zhu, L. and P. Leach, "Kerberos Anonymity Support", + draft-ietf-krb-wg-anon (work in progress), 2007. + + [KRB-NAMING] + Zhu, L., "Additional Kerberos Naming Constraints", + draft-ietf-krb-wg-naming (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. + + [RFC2744] Wray, J., "Generic Security Service API Version 2 : + C-bindings", RFC 2744, January 2000. + + [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 + + + +Zhu, et al. Expires May 7, 2009 [Page 20] + +Internet-Draft PKU2U November 2008 + + + 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 + Version 5 Generic Security Service Application Program + Interface (GSS-API) Mechanism: Version 2", RFC 4121, + July 2005. + + [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API + Extension for the Generic Security Service Application + Program Interface (GSS-API)", RFC 4401, February 2006. + + [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the + Kerberos V Generic Security Service Application Program + Interface (GSS-API) Mechanism", RFC 4402, February 2006. + + [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): String Representation of Distinguished Names", + RFC 4514, June 2006. + + [RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): + Syntaxes and Matching Rules", RFC 4517, June 2006. + + [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial + Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + +Authors' Addresses + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + + + + + +Zhu, et al. Expires May 7, 2009 [Page 21] + +Internet-Draft PKU2U November 2008 + + + 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 May 7, 2009 [Page 22] + +Internet-Draft PKU2U November 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. + + + + + + + + + + + +Zhu, et al. Expires May 7, 2009 [Page 23] + +