[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                              A. Medvinsky
Intended status: Standards Track                   Microsoft Corporation
Expires: August 22, 2007                                       J. Altman
                                                        Secure Endpoints
                                                       February 18, 2007


  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 August 22, 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 22, 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 . . . . . . . . . . . . .  6
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   11. Normative References . . . . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8
   Intellectual Property and Copyright Statements . . . . . . . . . . 10



































Zhu, et al.              Expires August 22, 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 to establish 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 22, 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.

   Otherwise, 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.

   Otherwise the initiator does not have a service ticket to the
   acceptor initially, 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 pre-authentication data computed according to
   Section 3.2.1 of [RFC4556].  On the contrary with [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 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
   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



Zhu, et al.              Expires August 22, 2007                [Page 4]


Internet-Draft                    PKU2U                    February 2007


   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 validates the pre-
   authentication data in the reply according to 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 acceptor's
   name and the acceptor's public key.

   The GSS-API acceptor is identified using the targ_name parameter of
   the GSS_Init_sec_context() call, the initiator MUST verify the
   binding between the targ_name [RFC2743] 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
   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 communicates with the initiator by
   tunneling the authentication service exchange messages through the
   use of the GSS-API tokens and application traffic.  In the event of



Zhu, et al.              Expires August 22, 2007                [Page 5]


Internet-Draft                    PKU2U                    February 2007


   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 rest of the context establishment tokens 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.

   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:

        <CN=Larry, O=Microsoft, L=Redmond, S=Washington, C=US>


7.  Guidelines for Credentials Selection

   If a peer, either the initiator or the acceptor, has multiple pairs
   of public-key private keys, the choice has to be made 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 certificate cannot be validated



Zhu, et al.              Expires August 22, 2007                [Page 6]


Internet-Draft                    PKU2U                    February 2007


   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
   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

   [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



Zhu, et al.              Expires August 22, 2007                [Page 7]


Internet-Draft                    PKU2U                    February 2007


              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
              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




Zhu, et al.              Expires August 22, 2007                [Page 8]


Internet-Draft                    PKU2U                    February 2007


   Jeffery Altman
   Secure Endpoints
   255 W 94th St
   New York, NY  10025
   US

   Email: jaltman@secure-endpoints.com












































Zhu, et al.              Expires August 22, 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 22, 2007               [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/