1
2
3
4NETWORK WORKING GROUP                                             L. Zhu
5Internet-Draft                                             K. Jaganathan
6Expires: 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
14Status 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
39Copyright Notice
40
41   Copyright (C) The Internet Society (2005).
42
43Abstract
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
55Zhu, et al.              Expires March 17, 2006                 [Page 1]
56
57Internet-Draft           ECC Support for PKINIT           September 2005
58
59
60Table 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
111Zhu, et al.              Expires March 17, 2006                 [Page 2]
112
113Internet-Draft           ECC Support for PKINIT           September 2005
114
115
1161.  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
1362.  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
1433.  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
167Zhu, et al.              Expires March 17, 2006                 [Page 3]
168
169Internet-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
1894.  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
223Zhu, et al.              Expires March 17, 2006                 [Page 4]
224
225Internet-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
279Zhu, et al.              Expires March 17, 2006                 [Page 5]
280
281Internet-Draft           ECC Support for PKINIT           September 2005
282
283
2845.  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
335Zhu, et al.              Expires March 17, 2006                 [Page 6]
336
337Internet-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
3646.  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
391Zhu, et al.              Expires March 17, 2006                 [Page 7]
392
393Internet-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
4057.  IANA Considerations
406
407   No IANA actions are required for this document.
408
409
4108.  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
4179.  References
418
4199.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
441Zhu, et al.              Expires March 17, 2006                 [Page 8]
442
443Internet-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
4759.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
496Zhu, et al.              Expires March 17, 2006                 [Page 9]
497
498Internet-Draft           ECC Support for PKINIT           September 2005
499
500
501Authors' 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
552Zhu, et al.              Expires March 17, 2006                [Page 10]
553
554Internet-Draft           ECC Support for PKINIT           September 2005
555
556
557Intellectual 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
582Disclaimer 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
593Copyright 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
600Acknowledgment
601
602   Funding for the RFC Editor function is currently provided by the
603   Internet Society.
604
605
606
607
608Zhu, et al.              Expires March 17, 2006                [Page 11]
609
610
611