doc/standardisation/draft-zhu-pkinit-ecc-01.txt

   1
   2
   3
   4 NETWORK WORKING GROUP                                             L. Zhu
   5 Internet-Draft                                             K. Jaganathan
   6 Expires: September 3, 2006                                     K. Lauter
   7                                                    Microsoft Corporation
   8                                                            March 2, 2006
   9
  10
  11                          ECC Support for PKINIT
  12                         draft-zhu-pkinit-ecc-01
  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 September 3, 2006.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  44
  45    This document describes the use of Elliptic Curve certificates,
  46    Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
  47    (ECDH) key agreement within the framework of PKINIT - the Kerberos
  48    Version 5 extension that provides for the use of public key
  49    cryptography.
  50
  51
  52
  53
  54
  55 Zhu, et al.             Expires September 3, 2006               [Page 1]
  56 \f
  57 Internet-Draft           ECC Support for PKINIT               March 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
  64    3.  Using Elliptic Curve Certificates and Elliptic Curve
  65        Signature Schemes  . . . . . . . . . . . . . . . . . . . . . .  3
  66    4.  Using ECDH Key Exchange  . . . . . . . . . . . . . . . . . . .  4
  67    5.  Choosing the Domain Parameters and the Key Size  . . . . . . .  5
  68    6.  Interoperability Requirements  . . . . . . . . . . . . . . . .  7
  69    7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  70    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
  71    9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
  72    10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  73      10.1.  Normative References  . . . . . . . . . . . . . . . . . .  8
  74      10.2.  Informative References  . . . . . . . . . . . . . . . . .  9
  75    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
  76    Intellectual Property and Copyright Statements . . . . . . . . . . 11
  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
 111 Zhu, et al.             Expires September 3, 2006               [Page 2]
 112 \f
 113 Internet-Draft           ECC Support for PKINIT               March 2006
 114
 115
 116 1.  Introduction
 117
 118    Elliptic Curve Cryptography (ECC) is emerging as an attractive
 119    public-key cryptosystem that provides security equivalent to
 120    currently popular public-key mechanisms such as RSA and DSA with
 121    smaller key sizes [LENSTRA] [NISTSP80057].
 122
 123    Currently [PKINIT] permits the use of ECC algorithms but it does not
 124    specify how ECC parameters are chosen and how to derive the shared
 125    key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
 126    [IEEE1363] [X9.63].
 127
 128    This document describes how to use Elliptic Curve certificates,
 129    Elliptic Curve signature schemes, and ECDH with [PKINIT].  However,
 130    it should be noted that there is no syntactic or semantic change to
 131    the existing [PKINIT] messages.  Both the client and the KDC
 132    contribute one ECDH key pair using the key agrement protocol
 133    described in this document.
 134
 135
 136 2.  Conventions Used in This Document
 137
 138    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 139    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 140    document are to be interpreted as described in [RFC2119].
 141
 142
 143 3.  Using Elliptic Curve Certificates and Elliptic Curve Signature
 144     Schemes
 145
 146    ECC certificates and signature schemes can be used in the
 147    Cryptographic Message Syntax (CMS) [RFC3369] content type
 148    'SignedData'.
 149
 150    X.509 certificates [RFC3280] containing ECC public keys or signed
 151    using ECC signature schemes MUST comply with [RFC3279].
 152
 153    The elliptic curve domain parameters recommended in [X9.62],
 154    [FIPS186-2], and [SECG] SHOULD be used.
 155
 156    The signatureAlgorithm field of the CMS data type SignerInfo can
 157    contain one of the following ECC signature algorithm identifiers:
 158
 159       ecdsa-with-Sha1   [ECCPKALGS]
 160       ecdsa-with-Sha256 [ECCPKALGS]
 161       ecdsa-with-Sha384 [ECCPKALGS]
 162       ecdsa-with-Sha512 [ECCPKALGS]
 163
 164
 165
 166
 167 Zhu, et al.             Expires September 3, 2006               [Page 3]
 168 \f
 169 Internet-Draft           ECC Support for PKINIT               March 2006
 170
 171
 172    The corresponding digestAlgorithm field contains one of the following
 173    hash algorithm identifiers respectively:
 174
 175       id-sha1           [RFC3279]
 176       id-sha256         [ECCPKALGS]
 177       id-sha384         [ECCPKALGS]
 178       id-sha512         [ECCPKALGS]
 179
 180    Namely id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-
 181    sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384
 182    MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512
 183    MUST be used in conjunction with ecdsa-with-Sha512.
 184
 185    Implementations of this specfication MUST support ecdsa-with-Sha256
 186    and SHOULD support ecdsa-with-Sha1.
 187
 188
 189 4.  Using ECDH Key Exchange
 190
 191    This section describes how ECDH can be used as the AS reply key
 192    delivery method [PKINIT].  Note that the protocol description here is
 193    similar to that of Modular Exponential Diffie-Hellman (MODP DH), as
 194    described in [PKINIT].
 195
 196    If the client wishes to use ECDH key agreement method, it encodes its
 197    ECDH public key value and the domain parameters [IEEE1363] [X9.63]
 198    for its ECDH public key in clientPublicValue of the PA-PK-AS-REQ
 199    message [PKINIT].
 200
 201    As described in [PKINIT], the ECDH domain parameters for the client's
 202    public key are specified in the algorithm field of the type
 203    SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value
 204    is mapped to a subjectPublicKey (a BIT STRING) according to
 205    [RFC3279].
 206
 207    The following algorithm identifier is used to identify the client's
 208    choice of the ECDH key agreement method for key delivery.
 209
 210         id-ecPublicKey (Elliptic Curve Diffie-Hellman [ECCPKALGS])
 211
 212    If the domain parameters are not accepted by the KDC, the KDC sends
 213    back an error message [RFC4120] with the code
 214    KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [PKINIT].  This error message
 215    contains the list of domain parameters acceptable to the KDC.  This
 216    list is encoded as TD-DH-PARAMETERS [PKINIT], and it is in the KDC's
 217    decreasing preference order.  The client can then pick a set of
 218    domain parameters from the list and retry the authentication.
 219
 220
 221
 222
 223 Zhu, et al.             Expires September 3, 2006               [Page 4]
 224 \f
 225 Internet-Draft           ECC Support for PKINIT               March 2006
 226
 227
 228    Both the client and the KDC MUST have local policy that specifies
 229    which set of domain parameters are acceptable if they do not have a
 230    priori knowledge of the chosen domain parameters.  The need for such
 231    local policy is explained in Section 7.
 232
 233    If the ECDH domain parameters are accepted by the KDC, the KDC sends
 234    back its ECDH public key value in the subjectPublicKey field of the
 235    PA-PK-AS-REP message [PKINIT].
 236
 237    As described in [PKINIT], the KDC's ECDH public key value is encoded
 238    as a BIT STRING according to [RFC3279].
 239
 240    Note that in the steps above, the client can indicate to the KDC that
 241    it wishes to reuse ECDH keys or to allow the KDC to do so, by
 242    including the clientDHNonce field in the request [PKINIT], and the
 243    KDC can then reuse the ECDH keys and include serverDHNonce field in
 244    the reply [PKINIT].  This logic is the same as that of the Modular
 245    Exponential Diffie-Hellman key agreement method [PKINIT].
 246
 247    If ECDH is negotiated as the key delivery method, then the PA-PK-AS-
 248    REP and AS reply key are generated as in Section 3.2.3.1 of [PKINIT]
 249    with the following difference: The DHSharedSecret is the x-coordinate
 250    of the shared secret value (an elliptic curve point); DHSharedSecret
 251    is the output of operation ECSVDP-DH as described in Section 7.2.1 of
 252    [IEEE1363].
 253
 254    Both the client and KDC then proceed as described in [PKINIT] and
 255    [RFC4120].
 256
 257    Lastly it should be noted that ECDH can be used with any certificates
 258    and signature schemes.  However, a significant advantage of using
 259    ECDH together with ECC certificates and signature schemes is that the
 260    ECC domain parameters in the client or KDC certificates can be used.
 261    This obviates the need of locally preconfigured domain parameters as
 262    described in Section 7.
 263
 264
 265 5.  Choosing the Domain Parameters and the Key Size
 266
 267    The domain parameters and the key size should be chosen so as to
 268    provide sufficient cryptographic security [RFC3766].  The following
 269    table, based on table 2 on page 63 of NIST SP800-57 part 1
 270    [NISTSP80057], gives approximate comparable key sizes for symmetric-
 271    and asymmetric-key cryptosystems based on the best-known algorithms
 272    for attacking them.
 273
 274
 275
 276
 277
 278
 279 Zhu, et al.             Expires September 3, 2006               [Page 5]
 280 \f
 281 Internet-Draft           ECC Support for PKINIT               March 2006
 282
 283
 284                  Symmetric    |  ECC       |   RSA
 285                  -------------+----------- +------------
 286                     80        |  160 - 223 |   1024
 287                    112        |  224 - 255 |   2048
 288                    128        |  256 - 383 |   3072
 289                    192        |  384 - 511 |   7680
 290                    256        |  512+      |  15360
 291
 292                 Table 1: Comparable key sizes (in bits)
 293
 294    Thus, for example, when securing a 128-bit symmetric key, it is
 295    prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
 296    P-256 (secp256r1) as described below.
 297
 298    A set of ECDH domain parameters is also known as a curve.  A curve is
 299    a named curve if the domain paratmeters are well known and can be
 300    identified by an Object Identifier, otherwise it is called a custom
 301    curve.  [PKINIT] supports both named curves and custom curves, see
 302    Section 7 on the tradeoff of choosing between named curves and custom
 303    curves.
 304
 305    The named curves recommended in this document are also recommended by
 306    NIST [FIPS186-2].  These fifteen ECC curves are given in the
 307    following table [FIPS186-2] [SECG].
 308
 309               Description                      SEC 2 OID
 310               -----------------                ---------
 311
 312               ECPRGF192Random  group P-192     secp192r1
 313               EC2NGF163Random  group B-163     sect163r2
 314               EC2NGF163Koblitz group K-163     sect163k1
 315
 316               ECPRGF224Random  group P-224     secp224r1
 317               EC2NGF233Random  group B-233     sect233r1
 318               EC2NGF233Koblitz group K-233     sect233k1
 319
 320               ECPRGF256Random  group P-256     secp256r1
 321               EC2NGF283Random  group B-283     sect283r1
 322               EC2NGF283Koblitz group K-283     sect283k1
 323
 324               ECPRGF384Random  group P-384     secp384r1
 325               EC2NGF409Random  group B-409     sect409r1
 326               EC2NGF409Koblitz group K-409     sect409k1
 327
 328               ECPRGF521Random  group P-521     secp521r1
 329               EC2NGF571Random  group B-571     sect571r1
 330               EC2NGF571Koblitz group K-571     sect571k1
 331
 332
 333
 334
 335 Zhu, et al.             Expires September 3, 2006               [Page 6]
 336 \f
 337 Internet-Draft           ECC Support for PKINIT               March 2006
 338
 339
 340 6.  Interoperability Requirements
 341
 342    Implementations conforming to this specification MUST support curve
 343    P-256 and P-384.
 344
 345
 346 7.  Security Considerations
 347
 348    Kerberos error messages are not integrity protected, as a result, the
 349    domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
 350    with by an attacker so that the set of domain parameters selected
 351    could be either weaker or not mutually preferred.  Local policy can
 352    configure sets of domain parameters acceptable locally, or disallow
 353    the negotiation of ECDH domain parameters.
 354
 355    Beyond elliptic curve size, the main issue is elliptic curve
 356    structure.  As a general principle, it is more conservative to use
 357    elliptic curves with as little algebraic structure as possible - thus
 358    random curves are more conservative than special curves such as
 359    Koblitz curves, and curves over F_p with p random are more
 360    conservative than curves over F_p with p of a special form (and
 361    curves over F_p with p random might be considered more conservative
 362    than curves over F_2^m as there is no choice between multiple fields
 363    of similar size for characteristic 2).  Note, however, that algebraic
 364    structure can also lead to implementation efficiencies and
 365    implementors and users may, therefore, need to balance conservatism
 366    against a need for efficiency.  Concrete attacks are known against
 367    only very few special classes of curves, such as supersingular
 368    curves, and these classes are excluded from the ECC standards such as
 369    [IEEE1363] and [X9.62].
 370
 371    Another issue is the potential for catastrophic failures when a
 372    single elliptic curve is widely used.  In this case, an attack on the
 373    elliptic curve might result in the compromise of a large number of
 374    keys.  Again, this concern may need to be balanced against efficiency
 375    and interoperability improvements associated with widely-used curves.
 376    Substantial additional information on elliptic curve choice can be
 377    found in [IEEE1363], [X9.62] and [FIPS186-2].
 378
 379
 380 8.  IANA Considerations
 381
 382    No IANA actions are required for this document.
 383
 384
 385 9.  Acknowledgements
 386
 387    The following people have made significant contributions to this
 388
 389
 390
 391 Zhu, et al.             Expires September 3, 2006               [Page 7]
 392 \f
 393 Internet-Draft           ECC Support for PKINIT               March 2006
 394
 395
 396    draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross, Sam Hartman,
 397    Tolga Acar, and Stefan Santesson.
 398
 399
 400 10.  References
 401
 402 10.1.  Normative References
 403
 404    [ECCPKALGS]
 405               RFC-Editor: To be replaced by RFC number for draft-ietf-
 406               pkix-ecc-pkalgs.  Work in Progress.
 407
 408    [FIPS186-2]
 409               NIST, "Digital Signature Standard", FIPS 186-2, 2000.
 410
 411    [IEEE1363]
 412               IEEE, "Standard Specifications for Public Key Cryptography",
 413               IEEE 1363, 2000.
 414
 415    [NISTSP80057]
 416               NIST, "Recommendation on Key Management",
 417               http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
 418               August 2005.
 419
 420
 421
 422 Zhu, et al.             Expires September 3, 2006               [Page 8]
 423 \f
 424 Internet-Draft           ECC Support for PKINIT               March 2006
 425
 426
 427
 428    [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
 429               cat-kerberos-pk-init.  Work in Progress.
 430
 431    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 432               Requirement Levels", BCP 14, RFC 2119, March 1997.
 433
 434    [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
 435               Identifiers for the Internet X.509 Public Key
 436               Infrastructure Certificate and Certificate Revocation List
 437               (CRL) Profile", RFC 3279, April 2002.
 438
 439    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
 440               X.509 Public Key Infrastructure Certificate and
 441               Certificate Revocation List (CRL) Profile", RFC 3280,
 442               April 2002.
 443
 444    [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)",
 445               RFC 3369, August 2002.
 446
 447    [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
 448               Public Keys Used For Exchanging Symmetric Keys", BCP 86,
 449               RFC 3766, April 2004.
 450
 451    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 452               Kerberos Network Authentication Service (V5)", RFC 4120,
 453               July 2005.
 454
 455    [X9.62]    ANSI, "Public Key Cryptography For The Financial Services
 456               Industry: The Elliptic Curve Digital Signature Algorithm
 457               (ECDSA)", ANSI X9.62, 1998.
 458
 459    [X9.63]    ANSI, "Public Key Cryptography for the Financial Services
 460               Industry: Key Agreement and Key Transport using Elliptic
 461               Curve Cryptography", ANSI X9.63, 2001.
 462
 463
 464 9.2.  Informative References
 465
 466    [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
 467               Sizes", Journal of Cryptology 14 (2001) 255-293.
 468
 469    [SECG]     SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
 470               <http://www.secg.org/>.
 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 Zhu, et al.             Expires September 3, 2006               [Page 9]
 498 \f
 499 Internet-Draft           ECC Support for PKINIT               March 2006
 500
 501
 502 Authors' Addresses
 503
 504    Larry Zhu
 505    Microsoft Corporation
 506    One Microsoft Way
 507    Redmond, WA  98052
 508    US
 509
 510    Email: lzhu@microsoft.com
 511
 512
 513    Karthik Jaganathan
 514    Microsoft Corporation
 515    One Microsoft Way
 516    Redmond, WA  98052
 517    US
 518
 519    Email: karthikj@microsoft.com
 520
 521
 522    Kristin Lauter
 523    Microsoft Corporation
 524    One Microsoft Way
 525    Redmond, WA  98052
 526    US
 527
 528    Email: klauter@microsoft.com
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553 Zhu, et al.             Expires September 3, 2006              [Page 10]
 554 \f
 555 Internet-Draft           ECC Support for PKINIT               March 2006
 556
 557
 558 Intellectual Property Statement
 559
 560    The IETF takes no position regarding the validity or scope of any
 561    Intellectual Property Rights or other rights that might be claimed to
 562    pertain to the implementation or use of the technology described in
 563    this document or the extent to which any license under such rights
 564    might or might not be available; nor does it represent that it has
 565    made any independent effort to identify any such rights.  Information
 566    on the procedures with respect to rights in RFC documents can be
 567    found in BCP 78 and BCP 79.
 568
 569    Copies of IPR disclosures made to the IETF Secretariat and any
 570    assurances of licenses to be made available, or the result of an
 571    attempt made to obtain a general license or permission for the use of
 572    such proprietary rights by implementers or users of this
 573    specification can be obtained from the IETF on-line IPR repository at
 574    http://www.ietf.org/ipr.
 575
 576    The IETF invites any interested party to bring to its attention any
 577    copyrights, patents or patent applications, or other proprietary
 578    rights that may cover technology that may be required to implement
 579    this standard.  Please address the information to the IETF at
 580    ietf-ipr@ietf.org.
 581
 582
 583 Disclaimer of Validity
 584
 585    This document and the information contained herein are provided on an
 586    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 587    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 588    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 589    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 590    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 591    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 592
 593
 594 Copyright Statement
 595
 596    Copyright (C) The Internet Society (2006).  This document is subject
 597    to the rights, licenses and restrictions contained in BCP 78, and
 598    except as set forth therein, the authors retain all their rights.
 599
 600
 601 Acknowledgment
 602
 603    Funding for the RFC Editor function is currently provided by the
 604    Internet Society.
 605
 606
 607
 608
 609 Zhu, et al.             Expires September 3, 2006              [Page 11]
 610 \f
 611