c284a8900a
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@18939 ec53bebd-3082-4978-b11e-865c3cabbd6b
396 lines
12 KiB
Plaintext
396 lines
12 KiB
Plaintext
|
||
|
||
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]
|
||
|
||
|