NETWORK WORKING GROUP L. Zhu Internet-Draft A. Medvinsky Intended status: Standards Track Microsoft Corporation Expires: August 30, 2007 J. Altman Secure Endpoints February 26, 2007 Public Key Cryptography Based User-to-User Authentication - (PKU2U) draft-zhu-pku2u-01 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 August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines the public key cryptography based user-to-user authentication protocol - PKU2U. This mechanism provides security services in peer to peer networking environments without requiring a trusted third party. Furthermore, the binding of PKU2U for the Generic Security Service Application Program Interface (GSS-API) per RFC2743 is defined based on RFC4121. Zhu, et al. Expires August 30, 2007 [Page 1] Internet-Draft PKU2U February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3 4. PKU2U Kerberos Principal Names . . . . . . . . . . . . . . . . 3 5. The Protocol Description and the Context Establishment Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. The GSS-API Binding for PKU2U . . . . . . . . . . . . . . . . 6 7. Guidelines for Credentials Selection . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Zhu, et al. Expires August 30, 2007 [Page 2] Internet-Draft PKU2U February 2007 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]. 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-NAME], and it has the value of "RESERVED:PKU2U". Unless otherwise specified, the realm name in any Kerberos message used by PKU2U is the PKU2U realm name. 4. PKU2U Kerberos Principal Names If the X.509 certificate [RFC3280] of a peer contains an id-pkinit- san Subject Alternative Name (SAN) as defined in Section 3.2.2 of Zhu, et al. Expires August 30, 2007 [Page 3] Internet-Draft PKU2U February 2007 [RFC4556] or an id-ms-sc-logon-upn SAN as defined in [REFERALS], then the Kerberos Principal Name for the peer is as specified in that SAN in the certificate. If the acceptor's X.509 certificate contains a dNSName SAN [RFC3280], the acceptor's Kerberos principal name is a two-components NT-SRV-HST type name as defined in Section 6.2.1 of [RFC4120], with the first component as "host" and the second component as the name in the dNSName SAN of the certificate. Otherwise unless otherwise specified, the peer's Kerberos principal name is of the NT-X500-PRINCIPAL type [RFC4120], and the name-string field [RFC4120] contains a single component whose value is a string representation of the peer's Distinguished Name [X500] encoded according to [RFC2253]. The Distinguished Name contained in the PKU2U Kerberos principal name MUST begin with the most specific attribute and continue with progressively broader attrbiutes. 5. The Protocol Description and the Context Establishment Tokens The PKU2U protocol is based on [RFC4120], and it can only be used in conjunction with GSS-API. This section describes how PKU2U works and how it differs from [RFC4120]. If initially the initiator has a service ticket to the acceptor, the initiator, acting as the client in the parlance of [RFC4120], performs the client-server authentication exchange according to [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as the server. 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 message, where the acceptor is identified as the server and the initiator is identified as the client, according to Section 3.1.1 of [RFC4120]. The initiator always includes the PA_PK_AS_REQ pre-authentication data computed according to Section 3.2.1 of [RFC4556]. In a modification to [RFC4120], the KRB_AS_REQ message is not sent directly to the acceptor, but instead returned within the output GSS-API token. GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED status [RFC2743] indicating at least one more token is needed in order to establish the context, and the KRB_AS_REQ message is returned as the innerContextToken defined in Section 3.1 of [RFC2743], in the output token. This output token that contains the KRB_AS_REQ message is then passed Zhu, et al. Expires August 30, 2007 [Page 4] Internet-Draft PKU2U February 2007 to GSS_Accept_security_context() as the input token in accordance with GSS-API. The acceptor processes the KRB_AS_REQ request according to Section 3.1.2 of [RFC4120]. The acceptor MUST verify that the server name in the request is that of the acceptor itself. The acceptor validates the pre-authentication data in the request according to Section 3.2.2 of [RFC4556]. The acceptor MUST verify the binding between the initiator's name and the initiator's public key. The initiator's X.509 certificate MUST contain the id-pkinit- KPClientAuth [RFC4556] Extended Key Usage (EKU) extension or the id- kp-clientAuth EKU [RFC3280]. If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the initiator to present to the acceptor and the response is a KRB_AS_REP message generated according to Section 3.1.3 of [RFC4120]. If an error occurs, however, the response is a KRB_ERROR message generated according to Section 3.1.4 of [RFC4120]. In all cases, GSS_Accept_security_context() returns GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a KRB_AS_REP message if a ticket was created or a KRB_ERROR message if there was an error while processing the request or the local policy prevented a ticket from being issued. The reply token is then passed to the initiator as the input token to GSS_Init_sec_context(). The initiator then processes the reply token according to Section 3.1.5 of [RFC4120] if a ticket has been returned. Upon receipt of the KRB_AS_REP message, the initiator MUST validate the PA_PK_AS_REP pre-authentication data in the reply according to 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 the binding between the acceptor's name and the acceptor's public key. The GSS-API acceptor is identified using the targ_name parameter [RFC2743] of the GSS_Init_sec_context() call, the initiator MUST verify the binding between the targ_name and the acceptor in order to provide authentication of the acceptor. In addition, the acceptor's X.509 certificate MUST contain the id-kp-clientAuth EKU [RFC3280] or id-kp-serverAuth EKU [RFC3280] or the id-pkinit-KPClientAuth EKU [RFC4556]. If an error message was returned, the initiator processes the response according to Section 3.1.6 of [RFC4120]. With the obtained ticket, the initiator then, acting as the client in Zhu, et al. Expires August 30, 2007 [Page 5] Internet-Draft PKU2U February 2007 the parlance of [RFC4120], performs the client-server authentication exchange according to [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as the server. 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. The syntax of the initial context establishment token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. PKU2U is identified by the Objection Identifier (OID) id-kerberos- pku2u. id-kerberos-pku2u ::= { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) pku2u(7) } Subsequent context establishment tokens MUST NOT be encapsulated in this GSS-API generic token framing. 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 [RFC4120] are defined in the table blow: Token TOK_ID Value in Hex ----------------------------------------- KRB_AS_REQ 01 01 KRB_AS_REP 02 02 The TOK_ID values for all other Kerberos messages are the same as defined in [RFC4121]. 6. The GSS-API Binding for PKU2U Section 5 defines the context establishment tokens. PKU2U per- message tokens are defined as the per-message tokens in [RFC4121]. The Kerberos principal name form and the host-based service Name described in [RFC1964] MUST be supported by implementations conforming to this specification. Zhu, et al. Expires August 30, 2007 [Page 6] Internet-Draft PKU2U February 2007 When the Kerberos principal name type is NT-X500-PRINCIPAL [RFC4120], the name-string field contains a single component that is a string representation of a Distinguished Name [X500]. The single string representation of an NT-X500-PRINCIPAL Kerberos principal name is computed as follows: the Kerberos principal name is first converted to a single string according to Section 2.1.1 of [RFC1964] and then enclosed in a pair of open and close angle brackets. For example, the following string is a single-string representation of a user: For implementations comforming to this specification, both the authenticator subkey and the TD_IAKERB_FINISHED element as defined in Section 3 of [IAKERB] MUST be present in the AP-REQ authenticator. The checksum in the TD_IAKERB_FINISHED element provides integrity protection for the messages exchanged between the initiator and the acceptor in the process of establishing the context. 7. 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. It is RECOMMENDED that implementations of this protocol expose sufficient information based on the hints described above to the users and allow the certificates to be selected interactively. If the certificates cannot be selected interactively, and multiple certificates can be used, it is RECOMMENDED that implementations fail the context establishment thus avoid confusions caused by an unexpected programmatic selection. 8. Security Considerations The security considerations in [RFC4556] apply here. It is crucial that both the initiator and the acceptor MUST be able to verify the binding between the signing key and the associated identity. Any of the attributes defined in the directory schema may be used to Zhu, et al. Expires August 30, 2007 [Page 7] Internet-Draft PKU2U February 2007 make up a Distinguished Name. The order of the component attribute value pairs is important. PKU2U requires that the most specific attribute comes first in the Distinguished name. The security considerations in Section 7 of [RFC2253] apply. 9. Acknowledgements The authors would like to thank Jeffery Hutzelman for his insightful comments on the earlier revisions of this document. 10. IANA Considerations Section 3 defines the PKU2U realm. The IANA registry for the reserved names should be updated to reference this document. 11. Normative References [IAKERB] L. Zhu and J. Altman, "Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB)", draft-zhu-ws-kerb, work in progress. [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints", draft-ietf-krb-wg-naming, work in progress. [REFERALS] Raeburn, K. and L. Zhu, "Generating KDC Referrals to Locate Kerberos Realms, draft-ietf-krb-wg-kerberos-referrals, work in progress. [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. [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 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. [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. [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Zhu, et al. Expires August 30, 2007 [Page 8] Internet-Draft PKU2U February 2007 Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [X500] The Directory -- overview of concepts, models and services. ITU-T Rec. X.500, 1993. Authors' Addresses Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Email: lzhu@microsoft.com Ari Medvinsky Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Email: arimed@microsoft.com Jeffery Altman Secure Endpoints 255 W 94th St New York, NY 10025 US Email: jaltman@secure-endpoints.com Zhu, et al. Expires August 30, 2007 [Page 9] Internet-Draft PKU2U February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 August 30, 2007 [Page 10]