doc/specifications/draft-zhu-pku2u-00.txt

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                              A. Medvinsky
   5 Intended status: Standards Track                   Microsoft Corporation
   6 Expires: August 22, 2007                                       J. Altman
   7                                                         Secure Endpoints
   8                                                        February 18, 2007
   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 August 22, 2007.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2007).
  42
  43 Abstract
  44
  45    This document defines the public key cryptography based user-to-user
  46    authentication protocol - PKU2U. This mechanism provides security
  47    services in peer to peer networking environments without requiring a
  48    trusted third party.  Furthermore, the binding of PKU2U for the
  49    Generic Security Service Application Program Interface (GSS-API) per
  50    RFC2743 is defined based on RFC4121.
  51
  52
  53
  54 Zhu, et al.              Expires August 22, 2007                [Page 1]
  55 \f
  56 Internet-Draft                    PKU2U                    February 2007
  57
  58
  59 Table of Contents
  60
  61    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  62    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
  63    3.  The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . .  3
  64    4.  PKU2U Kerberos Principal Names . . . . . . . . . . . . . . . .  3
  65    5.  The Protocol Description and the Context Establishment
  66        Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  67    6.  The GSS-API Binding for PKU2U  . . . . . . . . . . . . . . . .  6
  68    7.  Guidelines for Credentials Selection . . . . . . . . . . . . .  6
  69    8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  70    9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
  71    10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
  72    11. Normative References . . . . . . . . . . . . . . . . . . . . .  7
  73    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8
  74    Intellectual Property and Copyright Statements . . . . . . . . . . 10
  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 August 22, 2007                [Page 2]
 111 \f
 112 Internet-Draft                    PKU2U                    February 2007
 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 such systems highly
 121    scalable and robust.
 122
 123    A true peer-to-peer system is self-organized, typically there is no
 124    trusted third party in such environments.  Consequently the Kerberos
 125    protocol as defined in [RFC4120] and [RFC4556] is inadequate to
 126    provide security services.  Currently there is no interoperable GSS-
 127    API mechanism to establish trust in the information received from the
 128    peer.  The inability to authenticate the messages exchanged among
 129    peers enables many attacks such as poisoning (e.g. providing data
 130    contents are different from the description) and polluting (e.g.
 131    inserting "bad" packets).
 132
 133    To remedy this, the PKU2U protocol extends [RFC4120] and [RFC4556] to
 134    support peer-to-peer authentication without the help of a Key
 135    Distribution Center (KDC) [RFC4120].  In addition, the binding of
 136    PKU2U for GSS-API is defined based on [RFC4121].
 137
 138
 139 2.  Conventions Used in This Document
 140
 141    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 142    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 143    document are to be interpreted as described in [RFC2119].
 144
 145    In this document, the GSS-API initiator or acceptor is referred to as
 146    the peer when the description is applicable to both the initiator and
 147    the acceptor.
 148
 149
 150 3.  The PKU2U Realm Name
 151
 152    The PKU2U realm name is defined as a reserved Kerberos realm name per
 153    [KRB-NAME], and it has the value of "RESERVED:PKU2U".
 154
 155    Unless otherwise specified, the realm name in any Kerberos message
 156    used by PKU2U is the PKU2U realm name.
 157
 158
 159 4.  PKU2U Kerberos Principal Names
 160
 161    If the X.509 certificate [RFC3280] of a peer contains an id-pkinit-
 162    san Subject Alternative Name (SAN) as defined in Section 3.2.2 of
 163
 164
 165
 166 Zhu, et al.              Expires August 22, 2007                [Page 3]
 167 \f
 168 Internet-Draft                    PKU2U                    February 2007
 169
 170
 171    [RFC4556] or an id-ms-sc-logon-upn SAN as defined in [REFERALS], then
 172    the Kerberos Principal Name for the peer is as specified in that SAN
 173    in the certificate.
 174
 175    Otherwise, the peer's Kerberos principal name is of the NT-X500-
 176    PRINCIPAL type [RFC4120], and the name-string field [RFC4120]
 177    contains a single component whose value is a string representation of
 178    the peer's Distinguished Name [X500] encoded according to [RFC2253].
 179    The Distinguished Name contained in the PKU2U Kerberos principal name
 180    MUST begin with the most specific attribute and continue with
 181    progressively broader attrbiutes.
 182
 183
 184 5.  The Protocol Description and the Context Establishment Tokens
 185
 186    The PKU2U protocol is based on [RFC4120], and it can only be used in
 187    conjunction with GSS-API.
 188
 189    This section describes how PKU2U works and how it differs from
 190    [RFC4120].
 191
 192    If initially the initiator has a service ticket to the acceptor, the
 193    initiator, acting as the client in the parlance of [RFC4120],
 194    performs the client-server authentication exchange according to
 195    [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as
 196    the server.
 197
 198    Otherwise the initiator does not have a service ticket to the
 199    acceptor initially, it requests a ticket from the acceptor instead of
 200    the KDC by constructing a KRB_AS_REQ message, where the acceptor is
 201    identified as the server and the initiator is identified as the
 202    client, according to Section 3.1.1 of [RFC4120].  The initiator
 203    always includes the pre-authentication data computed according to
 204    Section 3.2.1 of [RFC4556].  On the contrary with [RFC4120], the
 205    KRB_AS_REQ message is not sent directly to the acceptor, but instead
 206    returned within the output GSS-API token.  GSS_Init_sec_context()
 207    returns GSS_S_CONTINUE_NEEDED status [RFC2743] indicating at least
 208    one more token is needed to establish the context, and the KRB_AS_REQ
 209    message is returned as the innerContextToken defined in Section 3.1
 210    of [RFC2743], in the output token.
 211
 212    This output token that contains the KRB_AS_REQ message is then passed
 213    to GSS_Accept_security_context() as the input token in accordance
 214    with GSS-API.  The acceptor processes the KRB_AS_REQ request
 215    according to Section 3.1.2 of [RFC4120].  The acceptor MUST verify
 216    that the server name in the request is that of the acceptor itself.
 217    The acceptor validates the pre-authentication data in the request
 218    according to Section 3.2.2 of [RFC4556].  The acceptor MUST verify
 219
 220
 221
 222 Zhu, et al.              Expires August 22, 2007                [Page 4]
 223 \f
 224 Internet-Draft                    PKU2U                    February 2007
 225
 226
 227    the binding between the initiator's name and the initiator's public
 228    key.  The initiator's X.509 certificate MUST contain the id-pkinit-
 229    KPClientAuth [RFC4556] Extended Key Usage (EKU) extension or the id-
 230    kp-clientAuth EKU [RFC3280].
 231
 232    If all goes well, processing the KRB_AS_REQ message will result in
 233    the creation of a ticket for the initiator to present to the acceptor
 234    and the response is a KRB_AS_REP message generated according to
 235    Section 3.1.3 of [RFC4120].
 236
 237    If an error occurs, however, the response is a KRB_ERROR message
 238    generated according to Section 3.1.4 of [RFC4120].
 239
 240    In all cases, GSS_Accept_security_context() returns
 241    GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a
 242    KRB_AS_REP message if a ticket was created or a KRB_ERROR message if
 243    there was an error while processing the request or the local policy
 244    prevented a ticket from being issued.  The reply token is then passed
 245    to the initiator as the input token to GSS_Init_sec_context().
 246
 247    The initiator then processes the reply token according to Section
 248    3.1.5 of [RFC4120] if a ticket has been returned.  Upon receipt of
 249    the KRB_AS_REP message, the initiator validates the pre-
 250    authentication data in the reply according to Section 3.2.4 of
 251    [RFC4556].  As stated earlier, there is no KDC in PKU2U, thus the
 252    requirement of the id-pkinit-KPKdc is not applicable when PKU2U is
 253    used.  The initiator MUST verify the binding between the acceptor's
 254    name and the acceptor's public key.
 255
 256    The GSS-API acceptor is identified using the targ_name parameter of
 257    the GSS_Init_sec_context() call, the initiator MUST verify the
 258    binding between the targ_name [RFC2743] and the acceptor in order to
 259    provide authentication of the acceptor.  In addition, the acceptor's
 260    X.509 certificate MUST contain the id-kp-clientAuth EKU [RFC3280] or
 261    id-kp-serverAuth EKU [RFC3280] or the id-pkinit-KPClientAuth EKU
 262    [RFC4556].
 263
 264    If an error message was returned, the initiator processes the
 265    response according to Section 3.1.6 of [RFC4120].
 266
 267    With the obtained ticket, the initiator then, acting as the client in
 268    the parlance of [RFC4120], performs the client-server authentication
 269    exchange according to [RFC4121] and Section 3.2 of [RFC4120], with
 270    the acceptor acting as the server.
 271
 272    To recapitulate, the acceptor communicates with the initiator by
 273    tunneling the authentication service exchange messages through the
 274    use of the GSS-API tokens and application traffic.  In the event of
 275
 276
 277
 278 Zhu, et al.              Expires August 22, 2007                [Page 5]
 279 \f
 280 Internet-Draft                    PKU2U                    February 2007
 281
 282
 283    message loss, message duplication, or out of order message delivery,
 284    the security context MUST fail to establish.
 285
 286    The syntax of the initial context establishment token follows the
 287    initialContextToken syntax defined in Section 3.1 of [RFC2743].
 288    PKU2U is identified by the Objection Identifier (OID) id-kerberos-
 289    pku2u.
 290
 291       id-kerberos-pku2u ::=
 292         { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
 293           pku2u(7) }
 294
 295    Subsequent context establishment tokens MUST NOT be encapsulated in
 296    this GSS-API generic token framing.
 297
 298    The rest of the context establishment tokens are the same as defined
 299    in [RFC4121].
 300
 301
 302 6.  The GSS-API Binding for PKU2U
 303
 304    Section 5 defines the context establishment tokens.  PKU2U per-
 305    message tokens are defined as the per-message tokens in [RFC4121].
 306
 307    The Kerberos principal name form and the host-based service Name
 308    described in [RFC1964] MUST be supported by implementations
 309    conforming to this specification.
 310
 311    When the Kerberos principal name type is NT-X500-PRINCIPAL [RFC4120],
 312    the name-string field contains a single component that is a string
 313    representation of a Distinguished Name [X500].  The single string
 314    representation of an NT-X500-PRINCIPAL Kerberos principal name is
 315    computed as follows: the Kerberos principal name is first converted
 316    to a single string according to Section 2.1.1 of [RFC1964] and then
 317    enclosed in a pair of open and close angle brackets.  For example,
 318    the following string is a single-string representation of a user:
 319
 320         <CN=Larry, O=Microsoft, L=Redmond, S=Washington, C=US>
 321
 322
 323 7.  Guidelines for Credentials Selection
 324
 325    If a peer, either the initiator or the acceptor, has multiple pairs
 326    of public-key private keys, the choice has to be made choosing the
 327    best fit.  The trustedCertifiers field in the PA-PK-AS-REQ structure
 328    [RFC4556] SHOULD be filled by the initiator, to provide hints for
 329    guiding the selection of an appropriate certificate chain by the
 330    acceptor.  If the initiator's certificate cannot be validated
 331
 332
 333
 334 Zhu, et al.              Expires August 22, 2007                [Page 6]
 335 \f
 336 Internet-Draft                    PKU2U                    February 2007
 337
 338
 339    according to [RFC3280], the acceptor SHOULD send back the TD-TRUSTED-
 340    CERTIFIERS structure [RFC4556] that provides hints for guiding the
 341    selection of an appropriate certificate by the initiator.
 342
 343    It is RECOMMENDED that implementations of this protocol expose
 344    sufficient information based on the hints described above to the
 345    users and allow the certificates to be selected interactively.
 346
 347    If the certificates cannot be selected interactively, and multiple
 348    certificates can be used, it is RECOMMENDED that implementations fail
 349    the context establishment thus avoid confusions caused by an
 350    unexpected programmatic selection.
 351
 352
 353 8.  Security Considerations
 354
 355    The security considerations in [RFC4556] apply here.  It is crucial
 356    that both the initiator and the acceptor MUST be able to verify the
 357    binding between the signing key and the associated identity.
 358
 359    Any of the attributes defined in the directory schema may be used to
 360    make up a Distinguished Name.  The order of the component attribute
 361    value pairs is important.  PKU2U requires that the most specific
 362    attribute comes first in the Distinguished name.  The security
 363    considerations in Section 7 of [RFC2253] apply.
 364
 365
 366 9.  Acknowledgements
 367
 368    The authors would like to thank Jeffery Hutzelman for his insightful
 369    comments on the earlier revisions of this document.
 370
 371
 372 10.  IANA Considerations
 373
 374    Section 3 defines the PKU2U realm.  The IANA registry for the
 375    reserved names should be updated to reference this document.
 376
 377
 378 11.  Normative References
 379
 380    [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints",
 381               draft-ietf-krb-wg-naming, work in progress.
 382
 383    [REFERALS] Raeburn, K. and L. Zhu, "Generating KDC Referrals to
 384               Locate Kerberos Realms,
 385               draft-ietf-krb-wg-kerberos-referrals, work in progress.
 386
 387    [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 388               RFC 1964, June 1996.
 389
 390    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 391               Requirement Levels", BCP 14, RFC 2119, March 1997.
 392
 393    [RFC2253]  Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
 394
 395
 396
 397 Zhu, et al.              Expires August 22, 2007                [Page 7]
 398 \f
 399 Internet-Draft                    PKU2U                    February 2007
 400
 401
 402               Access Protocol (v3): UTF-8 String Representation of
 403               Distinguished Names", RFC 2253, December 1997.
 404
 405    [RFC2743]  Linn, J., "Generic Security Service Application Program
 406               Interface Version 2, Update 1", RFC 2743, January 2000.
 407
 408    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
 409               X.509 Public Key Infrastructure Certificate and
 410               Certificate Revocation List (CRL) Profile", RFC 3280,
 411               April 2002.
 412
 413    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 414               Kerberos Network Authentication Service (V5)", RFC 4120,
 415               July 2005.
 416
 417    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 418               Version 5 Generic Security Service Application Program
 419               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 420               July 2005.
 421
 422    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 423               Simple and Protected Generic Security Service Application
 424               Program Interface (GSS-API) Negotiation Mechanism",
 425               RFC 4178, October 2005.
 426
 427    [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
 428               Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
 429
 430    [X500]     The Directory -- overview of concepts, models and services.
 431               ITU-T Rec. X.500, 1993.
 432
 433 Authors' Addresses
 434
 435    Larry Zhu
 436    Microsoft Corporation
 437    One Microsoft Way
 438    Redmond, WA  98052
 439    US
 440
 441    Email: lzhu@microsoft.com
 442
 443
 444    Ari Medvinsky
 445    Microsoft Corporation
 446    One Microsoft Way
 447    Redmond, WA  98052
 448    US
 449
 450    Email: arimed@microsoft.com
 451
 452
 453
 454
 455 Zhu, et al.              Expires August 22, 2007                [Page 8]
 456 \f
 457 Internet-Draft                    PKU2U                    February 2007
 458
 459
 460    Jeffery Altman
 461    Secure Endpoints
 462    255 W 94th St
 463    New York, NY  10025
 464    US
 465
 466    Email: jaltman@secure-endpoints.com
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511 Zhu, et al.              Expires August 22, 2007                [Page 9]
 512 \f
 513 Internet-Draft                    PKU2U                    February 2007
 514
 515
 516 Full Copyright Statement
 517
 518    Copyright (C) The IETF Trust (2007).
 519
 520    This document is subject to the rights, licenses and restrictions
 521    contained in BCP 78, and except as set forth therein, the authors
 522    retain all their rights.
 523
 524    This document and the information contained herein are provided on an
 525    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 526    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 527    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 528    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 529    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 530    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 531
 532
 533 Intellectual Property
 534
 535    The IETF takes no position regarding the validity or scope of any
 536    Intellectual Property Rights or other rights that might be claimed to
 537    pertain to the implementation or use of the technology described in
 538    this document or the extent to which any license under such rights
 539    might or might not be available; nor does it represent that it has
 540    made any independent effort to identify any such rights.  Information
 541    on the procedures with respect to rights in RFC documents can be
 542    found in BCP 78 and BCP 79.
 543
 544    Copies of IPR disclosures made to the IETF Secretariat and any
 545    assurances of licenses to be made available, or the result of an
 546    attempt made to obtain a general license or permission for the use of
 547    such proprietary rights by implementers or users of this
 548    specification can be obtained from the IETF on-line IPR repository at
 549    http://www.ietf.org/ipr.
 550
 551    The IETF invites any interested party to bring to its attention any
 552    copyrights, patents or patent applications, or other proprietary
 553    rights that may cover technology that may be required to implement
 554    this standard.  Please address the information to the IETF at
 555    ietf-ipr@ietf.org.
 556
 557
 558 Acknowledgment
 559
 560    Funding for the RFC Editor function is provided by the IETF
 561    Administrative Support Activity (IASA).
 562
 563
 564
 565
 566
 567 Zhu, et al.              Expires August 22, 2007               [Page 10]
 568 \f
 569