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-05 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 . . . . . . . . . . . . . . . . . . . 5 4.5. GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . . 6 4.6. Matching host-based service principal names to acceptor certificates . . . . . . . . . . . . . . . . . . 6 5. The Protocol Description and the Context Establishment Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Context token derived from KRB_AS_REQ . . . . . . . . . . 8 5.2. Context token derived from KRB_AS_REP . . . . . . . . . . 9 5.3. Context tokens imported from RFC4121 . . . . . . . . . . . 10 6. Guidelines for Credentials Selection . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Zhu, et al. Expires January 15, 2009 [Page 2] Internet-Draft PKU2U July 2008 1. Introduction Peer-to-peer systems are increasingly popular today. In a peer-to- peer system, all clients provide resources that contribute positively to the total capacity of the overall system and there is no single point of failure. This distributed nature makes such systems highly scalable and robust. A true peer-to-peer system is self-organized, typically there is no trusted third party in such environments. Consequently the Kerberos protocol as defined in [RFC4120] and [RFC4556] is inadequate to provide security services. Currently there is no interoperable GSS- API mechanism for establishing trust in the information received from the peer. The inability to authenticate the messages exchanged among peers enables many attacks such as poisoning (e.g. providing data contents are different from the description) and polluting (e.g. inserting "bad" packets). To remedy this, the PKU2U protocol extends [RFC4120] and [RFC4556] to support peer-to-peer authentication without the help of a Key Distribution Center (KDC) [RFC4120]. This mechanism can act as a bridge between Public Key Infrastructure (PKI) and GSS-API for such environments. In addition, the binding of PKU2U for GSS-API is defined based on [RFC4121]. 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. 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(). 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 Zhu, et al. Expires January 15, 2009 [Page 4] Internet-Draft PKU2U July 2008 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 , 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]. The exported name token format for names of this type SHALL be the 'Name' value as it appears in a certificate DN (or directoryName subject alternative name), but re-encoded in DER. Support for name type is REQUIRED. 4.2. GSS_C_NT_HOSTNAME We introduce a new name type, GSS_C_NT_HOSTNAME, with OID , corresponding to the 'dNSName' choice of the 'GeneralName' ASN.1 type defined in [RFC3280]. The query syntax, display and exported name token forms for names of this type SHALL be a DNS name [RFC1034] in ACE form [RFC3490]. Support for name type is OPTIONAL. 4.3. GSS_C_NT_IP_ADDR We introduce a new name type, GSS_C_NT_IP_ADDR, with OID , corresponding to the 'iPAddress' choice of the 'GeneralName' ASN.1 type defined in [RFC3280]. The query syntax, display and exported name token forms for names of this type SHALL be the text representation of an IPv4 or IPv6 address (XXX add references). Support for name type is OPTIONAL. 4.4. GSS_C_NT_EMAIL_ADDR We introduce a new name type, GSS_C_NT_EMAIL_ADDR, with OID , corresponding to the 'rfc822Name' choice of the 'GeneralName' ASN.1 type defined in [RFC3280]. The query syntax, display and exported name token forms for names of this type SHALL be the text representation of an 'addr-spec' as defined in [RFC0822]. Zhu, et al. Expires January 15, 2009 [Page 5] Internet-Draft PKU2U July 2008 Support for name type is OPTIONAL. 4.5. 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). Support for name type is REQUIRED. 4.6. Matching host-based service principal names to acceptor certificates Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described herein. 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 "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. 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 6] Internet-Draft PKU2U July 2008 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) 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. Zhu, et al. Expires January 15, 2009 [Page 7] Internet-Draft PKU2U July 2008 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 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]. If the initiator wishes to assert a name of type GSS_KRB5_NT_PRINCIPAL_NAME, then it MUST set the cname and realm fields 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 Zhu, et al. Expires January 15, 2009 [Page 8] Internet-Draft PKU2U July 2008 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 , 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 and its ad-value SHALL consist of the BER encoding of the following: InitiatorNameAssertion ::= CHOICE { INTEGER (-1..16384), GeneralName -- see [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 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 then the acceptor MUST select a certificate (if it has more than one) which matches the initiator's targ_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(). Zhu, et al. Expires January 15, 2009 [Page 9] Internet-Draft PKU2U July 2008 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 ) 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 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 Zhu, et al. Expires January 15, 2009 [Page 10] Internet-Draft PKU2U July 2008 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). 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, Zhu, et al. Expires January 15, 2009 [Page 11] Internet-Draft PKU2U July 2008 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. 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. Zhu, et al. Expires January 15, 2009 [Page 12] Internet-Draft PKU2U July 2008 [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 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 Zhu, et al. Expires January 15, 2009 [Page 13] Internet-Draft PKU2U July 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 January 15, 2009 [Page 14] 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 15]