< draft-ietf-tls-ecc-07.txt   draft-ietf-tls-ecc-08.txt >
TLS Working Group V. Gupta TLS Working Group V. Gupta
Internet-Draft Sun Labs Internet-Draft Sun Labs
Expires: June 1, 2005 S. Blake-Wilson Expires: September 2, 2005 S. Blake-Wilson
BCI BCI
B. Moeller B. Moeller
University of California, Berkeley University of Calgary
C. Hawk C. Hawk
Corriente Networks Corriente Networks
N. Bolyard N. Bolyard
Dec. 2004 Mar. 2005
ECC Cipher Suites for TLS ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-07.txt> <draft-ietf-tls-ecc-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2005. This Internet-Draft will expire on September 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes new key exchange algorithms based on Elliptic This document describes new key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the TLS (Transport Layer Security) Curve Cryptography (ECC) for the TLS (Transport Layer Security)
protocol. In particular, it specifies the use of Elliptic Curve protocol. In particular, it specifies the use of Elliptic Curve
Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
Elliptic Curve Digital Signature Algorithm (ECDSA) as a new Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
authentication mechanism. authentication mechanism.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
skipping to change at page 2, line 45 skipping to change at page 2, line 46
5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 20 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 20
5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 21 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 21
5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 22 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 22
5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 23 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 23
5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 25 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 25
5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 9.1 Normative References . . . . . . . . . . . . . . . . . . . 30
9.2 Informative References . . . . . . . . . . . . . . . . . . . 30 9.2 Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . 33
1. Introduction 1. Introduction
Elliptic Curve Cryptography (ECC) is emerging as an attractive Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem for mobile/wireless environments. Compared public-key cryptosystem for mobile/wireless environments. Compared
to currently prevalent cryptosystems such as RSA, ECC offers to currently prevalent cryptosystems such as RSA, ECC offers
equivalent security with smaller key sizes. This is illustrated in equivalent security with smaller key sizes. This is illustrated in
the following table, based on [12], which gives approximate the following table, based on [12], which gives approximate
skipping to change at page 13, line 39 skipping to change at page 13, line 39
NamedCurve elliptic_curve_list<1..2^8-1> NamedCurve elliptic_curve_list<1..2^8-1>
} EllipticCurveList; } EllipticCurveList;
Items in elliptic_curve_list are ordered according to the client's Items in elliptic_curve_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
As an example, a client that only supports secp192r1 (aka NIST P-192) As an example, a client that only supports secp192r1 (aka NIST P-192)
and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would
include an elliptic_curves extension with the following octets: include an elliptic_curves extension with the following octets:
00 ?? 02 13 15 00 ?? 00 03 02 13 15
A client that supports arbitrary explicit binary polynomial curves A client that supports arbitrary explicit binary polynomial curves
would include an extension with the following octets: would include an extension with the following octets:
00 ?? 01 fe 00 ?? 00 02 01 fe
enum { uncompressed (0), ansiX963_compressed (1), enum { uncompressed (0), ansiX963_compressed (1),
ansiX963_hybrid (2), (255) ansiX963_hybrid (2), (255)
} ECPointFormat; } ECPointFormat;
struct { struct {
ECPointFormat ec_point_format_list<1..2^8-1> ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList; } ECPointFormatList;
Three point formats are included in the defintion of ECPointFormat Three point formats are included in the defintion of ECPointFormat
above. The uncompressed point format is the default format that above. The uncompressed point format is the default format that
skipping to change at page 14, line 28 skipping to change at page 14, line 28
compressed y-coordinate to allow flexibility and improve efficiency compressed y-coordinate to allow flexibility and improve efficiency
in some cases. Implementations of this document MAY support the in some cases. Implementations of this document MAY support the
ansix963_compressed and ansix963_hybrid point formats. ansix963_compressed and ansix963_hybrid point formats.
Items in ec_point_format_list are ordered according to the client's Items in ec_point_format_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
A client that only supports the uncompressed point format includes an A client that only supports the uncompressed point format includes an
extension with the following octets: extension with the following octets:
00 ?? 01 00 00 ?? 00 02 01 00
A client that prefers the use of the ansiX963_compressed format over A client that prefers the use of the ansiX963_compressed format over
uncompressed may indicate that preference by including an extension uncompressed may indicate that preference by including an extension
with the following octets: with the following octets:
00 ?? 02 01 00 00 ?? 00 03 02 01 00
Actions of the sender: Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello appends A client that proposes ECC cipher suites in its ClientHello appends
these extensions (along with any others) enumerating the curves and these extensions (along with any others) enumerating the curves and
point formats it supports. point formats it supports.
Actions of the receiver: Actions of the receiver:
A server that receives a ClientHello containing one or both of these A server that receives a ClientHello containing one or both of these
skipping to change at page 16, line 17 skipping to change at page 16, line 17
When this message is sent: When this message is sent:
This message is sent in all non-anonymous ECC-based key exchange This message is sent in all non-anonymous ECC-based key exchange
algorithms. algorithms.
Meaning of this message: Meaning of this message:
This message is used to authentically convey the server's static This message is used to authentically convey the server's static
public key to the client. The following table shows the server public key to the client. The following table shows the server
certificate type appropriate for each key exchange algorithm. ECC certificate type appropriate for each key exchange algorithm. ECC
public keys must be encoded in certificates as described in Section public keys must be encoded in certificates as described in
5.9. Section 5.9.
NOTE: The server's Certificate message is capable of carrying a chain NOTE: The server's Certificate message is capable of carrying a chain
of certificates. The restrictions mentioned in Table 3 apply only to of certificates. The restrictions mentioned in Table 3 apply only to
the server's certificate (first in the chain). the server's certificate (first in the chain).
Key Exchange Algorithm Server Certificate Type Key Exchange Algorithm Server Certificate Type
---------------------- ----------------------- ---------------------- -----------------------
ECDH_ECDSA Certificate must contain an ECDH_ECDSA Certificate must contain an
ECDH-capable public key. It ECDH-capable public key. It
skipping to change at page 30, line 12 skipping to change at page 30, line 12
The authors wish to thank Bill Anderson and Tim Dierks. The authors wish to thank Bill Anderson and Tim Dierks.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
2246, January 1999. RFC 2246, January 1999.
[3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
T. Wright, "Transport Layer Security (TLS) Extensions", T. Wright, "Transport Layer Security (TLS) Extensions",
draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004. Internet-draft draft-ietf-tls-rfc3546bis-00.txt, Nov. 2004.
[4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
<http://www.secg.org/>. <http://www.secg.org/>.
[5] IEEE, "Standard Specifications for Public Key Cryptography", [5] IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000. IEEE 1363, 2000.
[6] ANSI, "Public Key Cryptography For The Financial Services [6] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
skipping to change at page 30, line 41 skipping to change at page 30, line 41
[8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
1.5", PKCS 1, November 1993. 1.5", PKCS 1, November 1993.
[10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
2000, <http://www.secg.org/>. 2000, <http://www.secg.org/>.
[11] Polk, T., Housley, R. and L. Bassham, "Algorithms and [11] Polk, T., Housley, R. and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC Certificate and Certificate Revocation List (CRL) Profile",
3279, April 2002. RFC 3279, April 2002.
9.2 Informative References 9.2 Informative References
[12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key [12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293, Sizes", Journal of Cryptology 14 (2001) 255-293,
<http://www.cryptosavvy.com/>. <http://www.cryptosavvy.com/>.
[13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol [13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
Version 3.0", November 1996, Version 3.0", November 1996,
<http://wp.netscape.com/eng/ssl3/draft302.txt>. <http://wp.netscape.com/eng/ssl3/draft302.txt>.
skipping to change at page 31, line 21 skipping to change at page 31, line 21
Authors' Addresses Authors' Addresses
Vipul Gupta Vipul Gupta
Sun Microsystems Laboratories Sun Microsystems Laboratories
16 Network Circle 16 Network Circle
MS UMPK16-160 MS UMPK16-160
Menlo Park, CA 94025 Menlo Park, CA 94025
USA USA
Phone: +1 650 786 7551 Phone: +1 650 786 7551
EMail: vipul.gupta@sun.com Email: vipul.gupta@sun.com
Simon Blake-Wilson Simon Blake-Wilson
Basic Commerce & Industries, Inc. Basic Commerce & Industries, Inc.
96 Spandia Ave 96 Spandia Ave
Unit 606 Unit 606
Toronto, ON M6G 2T6 Toronto, ON M6G 2T6
Canada Canada
Phone: +1 416 214 5961 Phone: +1 416 214 5961
EMail: sblakewilson@bcisse.com Email: sblakewilson@bcisse.com
Bodo Moeller Bodo Moeller
University of California, Berkeley University of Calgary
EECS -- Computer Science Division Dept of Math & Stats
513 Soda Hall 2500 University Dr NW
Berkeley, CA 94720-1776 Calgary, AB T2N 1N4
USA CA
EMail: bodo@openssl.org Email: bodo@openssl.org
Chris Hawk Chris Hawk
Corriente Networks Corriente Networks
EMail: chris@corriente.net Email: chris@corriente.net
Nelson Bolyard Nelson Bolyard
EMail: nelson@bolyard.com Email: nelson@bolyard.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 33, line 41 skipping to change at page 33, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 24 change blocks. 
32 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/