third_party/heimdal/doc/standardisation/draft-zhu-pku2u-00.txt

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                              A. Medvinsky
   5 Updates: 4120 (if approved)                        Microsoft Corporation
   6 Intended status: Standards Track                               J. Altman
   7 Expires: May 11, 2007                                  Secure End Points
   8                                                         November 7, 2006
   9
  10
  11   Public Key Cryptography based User to User Authentication - (PKU2U)
  12                            draft-zhu-pku2u-00
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on May 11, 2007.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  44
  45    This document defines the Public Key Cryptography based User to User
  46    authentication protocol - PKU2U. PKU2U is based on RFC4456 and
  47    RFC4120.  This enables peer to peer authentication using Kerberos
  48    messages without requiring an online trusted third party.  In
  49    addition, the binding of PKU2U for the Generic Security Service
  50    Application Program Interface (GSS-API) per RFC2743 is defined based
  51
  52
  53
  54 Zhu, et al.               Expires May 11, 2007                  [Page 1]
  55 \f
  56 Internet-Draft                    PKU2U                    November 2006
  57
  58
  59    on RFC4121.
  60
  61
  62 Table of Contents
  63
  64    1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  65    2  Conventions Used in This Document  . . . . . . . . . . . . . . . 3
  66    3  Protocol description . . . . . . . . . . . . . . . . . . . . . . 3
  67    4  Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
  68    5  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
  69    6  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
  70    7  Normative References . . . . . . . . . . . . . . . . . . . . . . 5
  71    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5
  72    Intellectual Property and Copyright Statements  . . . . . . . . . . 7
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Zhu, et al.               Expires May 11, 2007                  [Page 2]
 111 \f
 112 Internet-Draft                    PKU2U                    November 2006
 113
 114
 115 1  Introduction
 116
 117    Peer-to-peer systems are increasingly popular today.  In a peer-to-
 118    peer system, all clients provide resources that contribute positively
 119    to the total capacity of the overall system and there is no single
 120    point of failure.  This distributed nature makes the system highly
 121    scalable and robust.  In addition, the peer-to-peer system is self-
 122    organized.  These enable services that just work.
 123
 124    In a peer-to-peer system, if the initiator can authenticate the
 125    acceptor and then establish trust in the information received from
 126    the peer, many attacks such as poisoning (e.g. providing data
 127    contents are different from the description) and polluting (e.g.
 128    inserting "bad" chunks/packets) can be mitigated or eliminated.
 129    However, currently there is no interoperable GSS-API mechanism for
 130    use in these environments.
 131
 132    The PKU2U protocol defined in this document extends PKINIT to support
 133    peer-to-peer authentications without the use of Key Distribution
 134    Center (KDC) [RFC4120].  Thus it enables peer to peer authentication
 135    based on public key cryptography.  In addition, this document defines
 136    the binding for GSS-API based on [RFC4121] and [WS-KERB], which makes
 137    PKU2U readily available to the widely deployed GSS-API applications.
 138
 139
 140 2  Conventions Used in This Document
 141
 142    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 143    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 144    document are to be interpreted as described in [RFC2119].
 145
 146
 147 3  Protocol description
 148
 149    The PKU2U realm name is a reserved name that is defined according to
 150    [KRB-NAME].  It has the value of "RESERVED:PKU2U".
 151
 152    PKU2U replaces the KDC in [RFC4556] with the identity of the
 153    acceptor, and it updates the protocol with the following changes:
 154
 155    All the realm names in Kerberos messages are filled with the PKU2U
 156    reserved realm.
 157
 158    The client name in AS-REQ [RFC4120] contains the name of the
 159    initiator, and the server name contains the Kerberos name of the
 160    acceptor.
 161
 162    The initiator signs the pre-authentication data as needed per
 163
 164
 165
 166 Zhu, et al.               Expires May 11, 2007                  [Page 3]
 167 \f
 168 Internet-Draft                    PKU2U                    November 2006
 169
 170
 171    [RFC4120] and constructs an AS-REQ, and then sends the request to the
 172    acceptor using the same GSS-API encapsulation defined in [WS-KERB],
 173    except the mechanism Objection Identifier (OID) for PKU2U is id-
 174    kerberos-pku2u.
 175
 176       id-kerberos-pku2u ::=
 177         { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
 178           pku2u(7) }
 179
 180    The client fills out the realm field in the ProxyData [WS-KERB] using
 181    the reserved PKU2U realm.  Upon receipt of the WS_KRB_PROXY message,
 182    the GSS-API acceptor processes the Kerberos message (an AS-REQ) that
 183    follows the WS_KRB_PROXY header.
 184
 185    The acceptor validates the pre-authentication data in the request per
 186    Section 3.2.2 of [RFC4556] and it MUST verify the binding between the
 187    client name and the client's signing key, if the pre-authentication
 188    data in the request is signed.  The client's X.509 certificate, if
 189    present, MUST contain id-pkinit-KPClientAuth [RFC4556] or id-kp-
 190    clientAuth [RFC3280].  If the client is authenticated as expected,
 191    the acceptor issues a service ticket to the initiator per [RFC4120].
 192
 193    Upon receipt of the reply, the initiator validates the pre-
 194    authentication data in the reply per Section 3.2.4 of [RFC4556].  As
 195    stated earlier, there is no KDC in PKU2U, thus the requirement of the
 196    id-pkinit-KPKdc is not applicable when PKU2U is used.  The initiator
 197    MUST verify the binding between the signing key in the reply and the
 198    acceptor.  When the GSS-API acceptor is identified using the
 199    targ_name parameter of the GSS_Init_sec_context() call, the signing
 200    key MUST be bound with the targ_name.  The acceptor's X.509
 201    certificate MUST contain id-kp-clientAuth [RFC3280] or id-kp-
 202    serverAuth [RFC3280] or id-pkinit-KPClientAuth [RFC4556].
 203
 204    The Kerberos principal name form and the host-based service Name
 205    described in [RFC1964] MUST be supported by conforming
 206    implementations of this specification.
 207
 208    Once the AS-REP in the reply is accepted, the initiator can use the
 209    obtained service to construct an AP-REQ and communicate with the
 210    acceptor.  The rest of the protocol and the GSS-API binding are the
 211    same as defined in [WS-KERB] and [RFC4121].
 212
 213
 214 4  Security Considerations
 215
 216    The security considerations in [RFC4556] apply here.  In addition,
 217    the initiator and the acceptor MUST be able to verify the binding
 218    between the signing key and the associated identity.
 219
 220
 221
 222 Zhu, et al.               Expires May 11, 2007                  [Page 4]
 223 \f
 224 Internet-Draft                    PKU2U                    November 2006
 225
 226
 227 5  Acknowledgements
 228
 229    The authors would like thanks Jeffery Hutzelman for his comments with
 230    regarding to unifying [WS-KERB] with PKU2U .
 231
 232
 233 6  IANA Considerations
 234
 235    Section 3 defines the PKU2U realm.  The IANA registry for the
 236    reserved names should be updated to reference this document.
 237
 238
 239 7.  Normative References
 240
 241    [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints",
 242               draft-ietf-krb-wg-naming, work in progress.
 243
 244    [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 245               RFC 1964, June 1996.
 246
 247    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 248               Requirement Levels", BCP 14, RFC 2119, March 1997.
 249
 250    [RFC2743]  Linn, J., "Generic Security Service Application Program
 251               Interface Version 2, Update 1", RFC 2743, January 2000.
 252
 253    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
 254               X.509 Public Key Infrastructure Certificate and
 255               Certificate Revocation List (CRL) Profile", RFC 3280,
 256               April 2002.
 257
 258    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 259               Kerberos Network Authentication Service (V5)", RFC 4120,
 260               July 2005.
 261
 262    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 263               Version 5 Generic Security Service Application Program
 264               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 265               July 2005.
 266
 267    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 268               Simple and Protected Generic Security Service Application
 269               Program Interface (GSS-API) Negotiation Mechanism",
 270               RFC 4178, October 2005.
 271
 272    [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
 273               Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
 274
 275
 276
 277
 278 Zhu, et al.               Expires May 11, 2007                  [Page 5]
 279 \f
 280 Internet-Draft                    PKU2U                    November 2006
 281
 282
 283    [WS-KERB] L. Zhu, "Kerberos for Web Services", draft-zhu-ws-kerb, work
 284              in progress.
 285
 286 Authors' Addresses
 287
 288    Larry Zhu
 289    Microsoft Corporation
 290    One Microsoft Way
 291    Redmond, WA  98052
 292    US
 293
 294    Email: lzhu@microsoft.com
 295
 296
 297    Ari Medvinsky
 298    Microsoft Corporation
 299    One Microsoft Way
 300    Redmond, WA  98052
 301    US
 302
 303    Email: arimed@microsoft.com
 304
 305
 306    Jeffery
 307    Secure End Points
 308    612 West 115th Street Room 716
 309    New York, NY  10025
 310    US
 311
 312    Email: jaltman@secureendpoint.com
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337 Zhu, et al.               Expires May 11, 2007                  [Page 6]
 338 \f
 339 Internet-Draft                    PKU2U                    November 2006
 340
 341
 342 Full Copyright Statement
 343
 344    Copyright (C) The Internet Society (2006).
 345
 346    This document is subject to the rights, licenses and restrictions
 347    contained in BCP 78, and except as set forth therein, the authors
 348    retain all their rights.
 349
 350    This document and the information contained herein are provided on an
 351    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 352    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 353    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 354    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 355    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 356    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 357
 358
 359 Intellectual Property
 360
 361    The IETF takes no position regarding the validity or scope of any
 362    Intellectual Property Rights or other rights that might be claimed to
 363    pertain to the implementation or use of the technology described in
 364    this document or the extent to which any license under such rights
 365    might or might not be available; nor does it represent that it has
 366    made any independent effort to identify any such rights.  Information
 367    on the procedures with respect to rights in RFC documents can be
 368    found in BCP 78 and BCP 79.
 369
 370    Copies of IPR disclosures made to the IETF Secretariat and any
 371    assurances of licenses to be made available, or the result of an
 372    attempt made to obtain a general license or permission for the use of
 373    such proprietary rights by implementers or users of this
 374    specification can be obtained from the IETF on-line IPR repository at
 375    http://www.ietf.org/ipr.
 376
 377    The IETF invites any interested party to bring to its attention any
 378    copyrights, patents or patent applications, or other proprietary
 379    rights that may cover technology that may be required to implement
 380    this standard.  Please address the information to the IETF at
 381    ietf-ipr@ietf.org.
 382
 383
 384 Acknowledgment
 385
 386    Funding for the RFC Editor function is provided by the IETF
 387    Administrative Support Activity (IASA).
 388
 389
 390
 391
 392
 393 Zhu, et al.               Expires May 11, 2007                  [Page 7]
 394 \f
 395