source4/heimdal/doc/standardisation/draft-zhu-pkinit-ecc-00.txt

   1
   2
   3
   4 NETWORK WORKING GROUP                                             L. Zhu
   5 Internet-Draft                                             K. Jaganathan
   6 Expires: March 17, 2006                                        K. Lauter
   7                                                    Microsoft Corporation
   8                                                       September 13, 2005
   9
  10
  11                          ECC Support for PKINIT
  12                         draft-zhu-pkinit-ecc-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 March 17, 2006.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2005).
  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 March 17, 2006                 [Page 1]
  56 \f
  57 Internet-Draft           ECC Support for PKINIT           September 2005
  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  . . . . . . .  6
  68    6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  69    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
  70    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
  71    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  72      9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
  73      9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
  74    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
  75    Intellectual Property and Copyright Statements . . . . . . . . . . 11
  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
 111 Zhu, et al.              Expires March 17, 2006                 [Page 2]
 112 \f
 113 Internet-Draft           ECC Support for PKINIT           September 2005
 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].
 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 March 17, 2006                 [Page 3]
 168 \f
 169 Internet-Draft           ECC Support for PKINIT           September 2005
 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 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] for its
 198    ECDH public key in clientPublicValue of the PA-PK-AS-REQ message
 199    [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 [IEEE1363])
 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 March 17, 2006                 [Page 4]
 224 \f
 225 Internet-Draft           ECC Support for PKINIT           September 2005
 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 6.
 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, both the KDC and
 248    the client calculate the shared secret value and derive the reply key
 249    as follows:
 250
 251    1) Let DHSharedSecret be the x-coordinate of the shared secret value
 252       (an elliptic curve point).  DHSharedSecret is the output of
 253       operation ECSVDP-DH as described in Section 7.2.1 of [IEEE1363].
 254
 255    2) DHSharedSecret is first padded with leading zeros such that the
 256       size of DHSharedSecret in octets is the same as that of the
 257       modulus, then represented as a string of octets in big-endian
 258       order.
 259
 260    3) The DHSharedSecret value derived above is used as input to the
 261       octetstring2key() function to derive the AS reply key k, as
 262       described in Section 3.2.3.1 of [PKINIT].
 263
 264    Both the client and KDC then proceed as described in [PKINIT] and
 265    [RFC4120].
 266
 267    Lastly it should be noted that ECDH can be used with any certificates
 268    and signature schemes.  However, a significant advantage of using
 269    ECDH together with ECC certificates and signature schemes is that the
 270    ECC domain parameters in the client or KDC certificates can be used.
 271    This obviates the need of locally preconfigured domain parameters as
 272    described in Section 6.
 273
 274
 275
 276
 277
 278
 279 Zhu, et al.              Expires March 17, 2006                 [Page 5]
 280 \f
 281 Internet-Draft           ECC Support for PKINIT           September 2005
 282
 283
 284 5.  Choosing the Domain Parameters and the Key Size
 285
 286    The domain parameters and the key size should be chosen so as to
 287    provide sufficient cryptographic security [RFC3766].  The following
 288    table, based on table 2 on page 63 of NIST SP800-57 part 1
 289    [NISTSP80057], gives approximate comparable key sizes for symmetric-
 290    and asymmetric-key cryptosystems based on the best-known algorithms
 291    for attacking them.
 292
 293
 294                  Symmetric    |  ECC       |   RSA
 295                  -------------+----------- +------------
 296                     80        |  160 - 223 |   1024
 297                    112        |  224 - 255 |   2048
 298                    128        |  256 - 383 |   3072
 299                    192        |  384 - 511 |   7680
 300                    256        |  512+      |  15360
 301
 302                 Table 1: Comparable key sizes (in bits)
 303
 304    Thus, for example, when securing a 128-bit symmetric key, it is
 305    prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
 306    P-256 (secp256r1) as described below.
 307
 308    A set of ECDH domain parameters is also known as a curve.  A curve is
 309    a named curve if the domain paratmeters are well known and can be
 310    identified by an Object Identifier, otherwise it is called a custom
 311    curve.  [PKINIT] supports both named curves and custom curves, see
 312    Section 6 on the tradeoff of choosing between named curves and custom
 313    curves.
 314
 315    The named curves recommended in this document are also recommended by
 316    NIST [FIPS186-2].  These fifteen ECC curves are given in the
 317    following table [FIPS186-2] [SECG].
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Zhu, et al.              Expires March 17, 2006                 [Page 6]
 336 \f
 337 Internet-Draft           ECC Support for PKINIT           September 2005
 338
 339
 340               Description                      SEC 2 OID
 341               -----------------                ---------
 342
 343               ECPRGF192Random  group P-192     secp192r1
 344               EC2NGF163Random  group B-163     sect163r2
 345               EC2NGF163Koblitz group K-163     sect163k1
 346
 347               ECPRGF224Random  group P-224     secp224r1
 348               EC2NGF233Random  group B-233     sect233r1
 349               EC2NGF233Koblitz group K-233     sect233k1
 350
 351               ECPRGF256Random  group P-256     secp256r1
 352               EC2NGF283Random  group B-283     sect283r1
 353               EC2NGF283Koblitz group K-283     sect283k1
 354
 355               ECPRGF384Random  group P-384     secp384r1
 356               EC2NGF409Random  group B-409     sect409r1
 357               EC2NGF409Koblitz group K-409     sect409k1
 358
 359               ECPRGF521Random  group P-521     secp521r1
 360               EC2NGF571Random  group B-571     sect571r1
 361               EC2NGF571Koblitz group K-571     sect571k1
 362
 363
 364 6.  Security Considerations
 365
 366    Kerberos error messages are not integrity protected, as a result, the
 367    domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
 368    with by an attacker so that the set of domain parameters selected
 369    could be either weaker or not mutually preferred.  Local policy can
 370    configure sets of domain parameters acceptable locally, or disallow
 371    the negotiation of ECDH domain parameters.
 372
 373    Beyond elliptic curve size, the main issue is elliptic curve
 374    structure.  As a general principle, it is more conservative to use
 375    elliptic curves with as little algebraic structure as possible - thus
 376    random curves are more conservative than special curves such as
 377    Koblitz curves, and curves over F_p with p random are more
 378    conservative than curves over F_p with p of a special form (and
 379    curves over F_p with p random might be considered more conservative
 380    than curves over F_2^m as there is no choice between multiple fields
 381    of similar size for characteristic 2).  Note, however, that algebraic
 382    structure can also lead to implementation efficiencies and
 383    implementors and users may, therefore, need to balance conservatism
 384    against a need for efficiency.  Concrete attacks are known against
 385    only very few special classes of curves, such as supersingular
 386    curves, and these classes are excluded from the ECC standards such as
 387    [IEEE1363] and [X9.62].
 388
 389
 390
 391 Zhu, et al.              Expires March 17, 2006                 [Page 7]
 392 \f
 393 Internet-Draft           ECC Support for PKINIT           September 2005
 394
 395
 396    Another issue is the potential for catastrophic failures when a
 397    single elliptic curve is widely used.  In this case, an attack on the
 398    elliptic curve might result in the compromise of a large number of
 399    keys.  Again, this concern may need to be balanced against efficiency
 400    and interoperability improvements associated with widely-used curves.
 401    Substantial additional information on elliptic curve choice can be
 402    found in [IEEE1363], [X9.62] and [FIPS186-2].
 403
 404
 405 7.  IANA Considerations
 406
 407    No IANA actions are required for this document.
 408
 409
 410 8.  Acknowledgements
 411
 412    The following people have made significant contributions to this
 413    draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross and Sam
 414    Hartman.
 415
 416
 417 9.  References
 418
 419 9.1.  Normative References
 420
 421    [ECCPKALGS]
 422               RFC-Editor: To be replaced by RFC number for draft-ietf-
 423               pkix-ecc-pkalgs.  Work in Progress.
 424
 425    [FIPS186-2]
 426               NIST, "Digital Signature Standard", FIPS 186-2, 2000.
 427
 428    [IEEE1363]
 429               IEEE, "Standard Specifications for Public Key Cryptography",
 430               IEEE 1363, 2000.
 431
 432    [NISTSP80057]
 433               NIST, "Recommendation on Key Management",
 434               http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
 435               August 2005.
 436
 437    [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
 438               cat-kerberos-pk-init.  Work in Progress.
 439
 440
 441 Zhu, et al.              Expires March 17, 2006                 [Page 8]
 442 \f
 443 Internet-Draft           ECC Support for PKINIT           September 2005
 444
 445
 446
 447    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 448               Requirement Levels", BCP 14, RFC 2119, March 1997.
 449
 450    [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
 451               Identifiers for the Internet X.509 Public Key
 452               Infrastructure Certificate and Certificate Revocation List
 453               (CRL) Profile", RFC 3279, April 2002.
 454
 455    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
 456               X.509 Public Key Infrastructure Certificate and
 457               Certificate Revocation List (CRL) Profile", RFC 3280,
 458               April 2002.
 459
 460    [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)",
 461               RFC 3369, August 2002.
 462
 463    [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
 464               Public Keys Used For Exchanging Symmetric Keys", BCP 86,
 465               RFC 3766, April 2004.
 466
 467    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 468               Kerberos Network Authentication Service (V5)", RFC 4120,
 469               July 2005.
 470
 471    [X9.62]    ANSI, "Public Key Cryptography For The Financial Services
 472               Industry: The Elliptic Curve Digital Signature Algorithm
 473               (ECDSA)", ANSI X9.62, 1998.
 474
 475 9.2.  Informative References
 476
 477    [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
 478               Sizes", Journal of Cryptology 14 (2001) 255-293.
 479
 480    [SECG]     SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
 481               <http://www.secg.org/>.
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496 Zhu, et al.              Expires March 17, 2006                 [Page 9]
 497 \f
 498 Internet-Draft           ECC Support for PKINIT           September 2005
 499
 500
 501 Authors' Addresses
 502
 503    Larry Zhu
 504    Microsoft Corporation
 505    One Microsoft Way
 506    Redmond, WA  98052
 507    US
 508
 509    Email: lzhu@microsoft.com
 510
 511
 512    Karthik Jaganathan
 513    Microsoft Corporation
 514    One Microsoft Way
 515    Redmond, WA  98052
 516    US
 517
 518    Email: karthikj@microsoft.com
 519
 520
 521    Kristin Lauter
 522    Microsoft Corporation
 523    One Microsoft Way
 524    Redmond, WA  98052
 525    US
 526
 527    Email: klauter@microsoft.com
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552 Zhu, et al.              Expires March 17, 2006                [Page 10]
 553 \f
 554 Internet-Draft           ECC Support for PKINIT           September 2005
 555
 556
 557 Intellectual Property Statement
 558
 559    The IETF takes no position regarding the validity or scope of any
 560    Intellectual Property Rights or other rights that might be claimed to
 561    pertain to the implementation or use of the technology described in
 562    this document or the extent to which any license under such rights
 563    might or might not be available; nor does it represent that it has
 564    made any independent effort to identify any such rights.  Information
 565    on the procedures with respect to rights in RFC documents can be
 566    found in BCP 78 and BCP 79.
 567
 568    Copies of IPR disclosures made to the IETF Secretariat and any
 569    assurances of licenses to be made available, or the result of an
 570    attempt made to obtain a general license or permission for the use of
 571    such proprietary rights by implementers or users of this
 572    specification can be obtained from the IETF on-line IPR repository at
 573    http://www.ietf.org/ipr.
 574
 575    The IETF invites any interested party to bring to its attention any
 576    copyrights, patents or patent applications, or other proprietary
 577    rights that may cover technology that may be required to implement
 578    this standard.  Please address the information to the IETF at
 579    ietf-ipr@ietf.org.
 580
 581
 582 Disclaimer of Validity
 583
 584    This document and the information contained herein are provided on an
 585    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 586    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 587    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 588    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 589    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 590    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 591
 592
 593 Copyright Statement
 594
 595    Copyright (C) The Internet Society (2005).  This document is subject
 596    to the rights, licenses and restrictions contained in BCP 78, and
 597    except as set forth therein, the authors retain all their rights.
 598
 599
 600 Acknowledgment
 601
 602    Funding for the RFC Editor function is currently provided by the
 603    Internet Society.
 604
 605
 606
 607
 608 Zhu, et al.              Expires March 17, 2006                [Page 11]
 609 \f
 610