draft-zhu-pku2u-00.txt [plain text]
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]