NETWORK WORKING GROUP L. Zhu Internet-Draft A. Medvinsky Updates: 4120 (if approved) Microsoft Corporation Intended status: Standards Track J. Altman Expires: May 11, 2007 Secure End Points November 7, 2006 Public Key Cryptography based User to User Authentication - (PKU2U) draft-zhu-pku2u-00 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 11, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines the Public Key Cryptography based User to User authentication protocol - PKU2U. PKU2U is based on RFC4456 and RFC4120. This enables peer to peer authentication using Kerberos messages without requiring an online trusted third party. In addition, the binding of PKU2U for the Generic Security Service Application Program Interface (GSS-API) per RFC2743 is defined based Zhu, et al. Expires May 11, 2007 [Page 1] Internet-Draft PKU2U November 2006 on RFC4121. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Conventions Used in This Document . . . . . . . . . . . . . . . 3 3 Protocol description . . . . . . . . . . . . . . . . . . . . . . 3 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7 Normative References . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Zhu, et al. Expires May 11, 2007 [Page 2] Internet-Draft PKU2U November 2006 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 the system highly scalable and robust. In addition, the peer-to-peer system is self- organized. These enable services that just work. In a peer-to-peer system, if the initiator can authenticate the acceptor and then establish trust in the information received from the peer, many attacks such as poisoning (e.g. providing data contents are different from the description) and polluting (e.g. inserting "bad" chunks/packets) can be mitigated or eliminated. However, currently there is no interoperable GSS-API mechanism for use in these environments. The PKU2U protocol defined in this document extends PKINIT to support peer-to-peer authentications without the use of Key Distribution Center (KDC) [RFC4120]. Thus it enables peer to peer authentication based on public key cryptography. In addition, this document defines the binding for GSS-API based on [RFC4121] and [WS-KERB], which makes PKU2U readily available to the widely deployed GSS-API applications. 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]. 3 Protocol description The PKU2U realm name is a reserved name that is defined according to [KRB-NAME]. It has the value of "RESERVED:PKU2U". PKU2U replaces the KDC in [RFC4556] with the identity of the acceptor, and it updates the protocol with the following changes: All the realm names in Kerberos messages are filled with the PKU2U reserved realm. The client name in AS-REQ [RFC4120] contains the name of the initiator, and the server name contains the Kerberos name of the acceptor. The initiator signs the pre-authentication data as needed per Zhu, et al. Expires May 11, 2007 [Page 3] Internet-Draft PKU2U November 2006 [RFC4120] and constructs an AS-REQ, and then sends the request to the acceptor using the same GSS-API encapsulation defined in [WS-KERB], except the mechanism Objection Identifier (OID) for PKU2U is id- kerberos-pku2u. id-kerberos-pku2u ::= { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) pku2u(7) } The client fills out the realm field in the ProxyData [WS-KERB] using the reserved PKU2U realm. Upon receipt of the WS_KRB_PROXY message, the GSS-API acceptor processes the Kerberos message (an AS-REQ) that follows the WS_KRB_PROXY header. The acceptor validates the pre-authentication data in the request per Section 3.2.2 of [RFC4556] and it MUST verify the binding between the client name and the client's signing key, if the pre-authentication data in the request is signed. The client's X.509 certificate, if present, MUST contain id-pkinit-KPClientAuth [RFC4556] or id-kp- clientAuth [RFC3280]. If the client is authenticated as expected, the acceptor issues a service ticket to the initiator per [RFC4120]. Upon receipt of the reply, the initiator validates the pre- authentication data in the reply per Section 3.2.4 of [RFC4556]. As stated earlier, there is no KDC in PKU2U, thus the requirement of the id-pkinit-KPKdc is not applicable when PKU2U is used. The initiator MUST verify the binding between the signing key in the reply and the acceptor. When the GSS-API acceptor is identified using the targ_name parameter of the GSS_Init_sec_context() call, the signing key MUST be bound with the targ_name. The acceptor's X.509 certificate MUST contain id-kp-clientAuth [RFC3280] or id-kp- serverAuth [RFC3280] or id-pkinit-KPClientAuth [RFC4556]. The Kerberos principal name form and the host-based service Name described in [RFC1964] MUST be supported by conforming implementations of this specification. Once the AS-REP in the reply is accepted, the initiator can use the obtained service to construct an AP-REQ and communicate with the acceptor. The rest of the protocol and the GSS-API binding are the same as defined in [WS-KERB] and [RFC4121]. 4 Security Considerations The security considerations in [RFC4556] apply here. In addition, the initiator and the acceptor MUST be able to verify the binding between the signing key and the associated identity. Zhu, et al. Expires May 11, 2007 [Page 4] Internet-Draft PKU2U November 2006 5 Acknowledgements The authors would like thanks Jeffery Hutzelman for his comments with regarding to unifying [WS-KERB] with PKU2U . 6 IANA Considerations Section 3 defines the PKU2U realm. The IANA registry for the reserved names should be updated to reference this document. 7. Normative References [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints", draft-ietf-krb-wg-naming, 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. [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 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. Zhu, et al. Expires May 11, 2007 [Page 5] Internet-Draft PKU2U November 2006 [WS-KERB] L. Zhu, "Kerberos for Web Services", draft-zhu-ws-kerb, work in progress. 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 Secure End Points 612 West 115th Street Room 716 New York, NY 10025 US Email: jaltman@secureendpoint.com Zhu, et al. Expires May 11, 2007 [Page 6] Internet-Draft PKU2U November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 May 11, 2007 [Page 7]