ECDSA-capable public key and
be signed with ECDSA.
ECDSA_fixed_ECDH Certificate MUST contain an
ECDH-capable public key on the
same elliptic curve as the server’s
long-term ECDH key. This certificate
MUST be signed with ECDSA.
RSA_fixed_ECDH Certificate MUST contain an
ECDH-capable public key on the
same elliptic curve as the server’s
long-term ECDH key. This certificate
MUST be signed with RSA.
Table 4: Client Certificate Types
Structure of this message:
Identical to the TLS client Certificate format.
Actions of the sender:
The client constructs an appropriate certificate chain, and conveys
it to the server in the Certificate message.
Actions of the receiver:
The TLS server validates the certificate chain, extracts the client’s
public key, and checks that the key type is appropriate for the
client authentication method.
5.7. Client Key Exchange
When this message is sent:
This message is sent in all key exchange algorithms. If client
authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
message is empty. Otherwise, it contains the client’s ephemeral ECDH
public key.
Meaning of the message:
This message is used to convey ephemeral data relating to the key
exchange belonging to the client (such as its ephemeral ECDH public
key).
Structure of this message:
The TLS ClientKeyExchange message is extended as follows.
enum { implicit, explicit } PublicValueEncoding;
implicit, explicit: For ECC cipher suites, this indicates whether
the client’s ECDH public key is in the client’s certificate
("implicit") or is provided, as an ephemeral ECDH public key, in
the ClientKeyExchange message ("explicit"). (This is "explicit"
in ECC cipher suites except when the client uses the
ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
mechanism.)
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: ECPoint ecdh_Yc;
} ecdh_public;
} ClientECDiffieHellmanPublic;
ecdh_Yc: Contains the client’s ephemeral ECDH public key as a byte
string ECPoint.point, which may represent an elliptic curve point
in uncompressed or compressed format. Here, the format MUST
conform to what the server has requested through a Supported Point
Formats Extension if this extension was used, and MUST be
uncompressed if this extension was not used.
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender:
The client selects an ephemeral ECDH public key corresponding to the
parameters it received from the server according to the ECKAS-DH1
scheme from IEEE 1363 [6]. It conveys this information to the client
in the ClientKeyExchange message using the format defined above.
Actions of the receiver:
The server retrieves the client’s ephemeral ECDH public key from the
ClientKeyExchange message and checks that it is on the same elliptic
curve as the server’s ECDH key.
5.8. Certificate Verify
When this message is sent:
This message is sent when the client sends a client certificate
containing a public key usable for digital signatures, e.g., when the
client is authenticated using the ECDSA_sign mechanism.
Meaning of the message:
This message contains a signature that proves possession of the
private key corresponding to the public key in the client’s
Certificate message.
Structure of this message:
The TLS CertificateVerify message and the underlying Signature type
are defined in [2] and [3], and the latter is extended here in
Section 5.4. For the ecdsa case, the signature field in the
CertificateVerify message contains an ECDSA signature computed over
handshake messages exchanged so far, exactly similar to
CertificateVerify with other signing algorithms in [2] and [3]:
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
ECDSA signatures are computed as described in Section 5.10, and SHA
in the above template for sha_hash accordingly may denote a hash
algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature
consists of a pair of integers, r and s. The digitally-signed
element is encoded as an opaque vector <0..2^16-1>, the contents of
which are the DER encoding [9] corresponding to the following ASN.1
notation [8].
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Actions of the sender:
The client computes its signature over all handshake messages sent or
received starting at client hello and up to but not including this
message. It uses the private key corresponding to its certified
public key to compute the signature, which is conveyed in the format
defined above.
Actions of the receiver:
The server extracts the client’s signature from the CertificateVerify
message, and verifies the signature using the public key it received
in the client’s Certificate message.
5.9. Elliptic Curve Certificates
X.509 certificates containing ECC public keys or signed using ECDSA
MUST comply with [14] or another RFC that replaces or extends it.
Clients SHOULD use the elliptic curve domain parameters recommended
in ANSI X9.62 [7], FIPS 186-2 [11], and SEC 2 [13].
5.10. ECDH, ECDSA, and RSA Computations
All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation
function (KDF), so that the premaster secret is the x-coordinate of
the ECDH shared secret elliptic curve point represented as an octet
string. Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated.
(Note that this use of the identity KDF is a technicality. The
complete picture is that ECDH is employed with a non-trivial KDF
because TLS does not directly use the premaster secret for anything
other than for computing the master secret. As of TLS 1.0 [2] and
1.1 [3], this means that the MD5- and SHA-1-based TLS PRF serves as a
KDF; it is conceivable that future TLS versions or new TLS extensions
introduced in the future may vary this computation.)
All ECDSA computations MUST be performed according to ANSI X9.62 [7]
or its successors. Data to be signed/verified is hashed, and the
result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 [10], and sha_size (see
Sections 5.4 and 5.8) is 20. However, an alternative hash function,
such as one of the new SHA hash functions specified in FIPS 180-2
[10], may be used instead if the certificate containing the EC public
key explicitly requires use of another hash function. (The mechanism
for specifying the required hash function has not been standardized,
but this provision anticipates such standardization and obviates the
need to update this document in response. Future PKIX RFCs may
choose, for example, to specify the hash function to be used with a
public key in the parameters field of subjectPublicKeyInfo.)
All RSA signatures must be generated and verified according to PKCS#1
[12] block type 1.
6. Cipher Suites
The table below defines new ECC cipher suites that use the key
exchange algorithms specified in Section 2.
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x01 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x02 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 }
CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 }
CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 }
CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A }
CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B }
CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C }
CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D }
CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E }
CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F }
CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 }
CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 }
CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 }
CipherSuite TLS_ECDH_anon_WITH_NULL_SHA = { 0xC0, 0x15 }
CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 }
CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 }
CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 }
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 }
Table 5: TLS ECC cipher suites
The key exchange method, cipher, and hash algorithm for each of these
cipher suites are easily determined by examining the name. Ciphers
(other than AES ciphers) and hash algorithms are defined in [2] and
[3]. AES ciphers are defined in [19].
Server implementations SHOULD support all of the following cipher
suites, and client implementations SHOULD support at least one of
them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
7. Security Considerations
Security issues are discussed throughout this memo.
For TLS handshakes using ECC cipher suites, the security
considerations in appendices D.2 and D.3 of [2] and [3] apply
accordingly.
Security discussions specific to ECC can be found in [6] and [7].
One important issue that implementers and users must consider is
elliptic curve selection. Guidance on selecting an appropriate
elliptic curve size is given in Table 1.
Beyond elliptic curve size, the main issue is elliptic curve
structure. As a general principle, it is more conservative to use
elliptic curves with as little algebraic structure as possible.
Thus, random curves are more conservative than special curves such as
Koblitz curves, and curves over F_p with p random are more
conservative than curves over F_p with p of a special form (and
curves over F_p with p random might be considered more conservative
than curves over F_2^m as there is no choice between multiple fields
of similar size for characteristic 2). Note, however, that algebraic
structure can also lead to implementation efficiencies, and
implementers and users may, therefore, need to balance conservatism
against a need for efficiency. Concrete attacks are known against
only very few special classes of curves, such as supersingular
curves, and these classes are excluded from the ECC standards that
this document references [6], [7].
Another issue is the potential for catastrophic failures when a
single elliptic curve is widely used. In this case, an attack on the
elliptic curve might result in the compromise of a large number of
keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely-used curves.
Substantial additional information on elliptic curve choice can be
found in [5], [6], [7], and [11].
Implementers and users must also consider whether they need forward
secrecy. Forward secrecy refers to the property that session keys
are not compromised if the static, certified keys belonging to the
server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key
exchange algorithms provide forward secrecy protection in the event
of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
Similarly, if the client is providing a static, certified key,
ECDSA_sign client authentication provides forward secrecy protection
in the event of client key compromise, while ECDSA_fixed_ECDH and
RSA_fixed_ECDH do not. Thus, to obtain complete forward secrecy
protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
with ECDSA_sign used for client authentication if necessary. Here
again the security benefits of forward secrecy may need to be
balanced against the improved efficiency offered by other options.
8. IANA Considerations
This document describes three new name spaces for use with the TLS
protocol:
o NamedCurve (Section 5.1)
o ECPointFormat (Section 5.1)
o ECCurveType (Section 5.4)
For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight
values (ECPointFormat and ECCurveType) reserved for Private Use. Any
additional assignments require IETF Consensus action [16].
9. Acknowledgements
The authors wish to thank Bill Anderson and Tim Dierks.
10. References
10.1. Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006.
[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
<http://www.secg.org/>.
[6] IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000.
[7] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998.
[8] International Telecommunication Union, "Information technology
- Abstract Syntax Notation One (ASN.1): Specification of basic
notation", ITU-T Recommendation X.680, 2002.
[9] International Telecommunication Union, "Information technology
- ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690, 2002.
[10] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
[11] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[12] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
1.5", PKCS 1, November 1993.
[13] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
2000, <http://www.secg.org/>.
[14] Polk, T., Housley, R., and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 3279, April 2002.
[15] Housley, R., Polk, T., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
10.2. Informative References
[17] Harper, G., Menezes, A., and S. Vanstone, "Public-Key
Cryptosystems with Very Small Key Lengths", Advances in
Cryptology -- EUROCRYPT ’92, LNCS 658, 1993.
[18] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293,
<http://www.cryptosavvy.com/>.
[19] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
Appendix A. Equivalent Curves (Informative)
All of the NIST curves [11] and several of the ANSI curves [7] are
equivalent to curves listed in Section 5.1.1. In the following
table, multiple names in one row represent aliases for the same
curve.
------------------------------------------
Curve names chosen by
different standards organizations
------------+---------------+-------------
SECG | ANSI X9.62 | NIST
------------+---------------+-------------
sect163k1 | | NIST K-163
sect163r1 | |
sect163r2 | | NIST B-163
sect193r1 | |
sect193r2 | |
sect233k1 | | NIST K-233
sect233r1 | | NIST B-233
sect239k1 | |
sect283k1 | | NIST K-283
sect283r1 | | NIST B-283
sect409k1 | | NIST K-409
sect409r1 | | NIST B-409
sect571k1 | | NIST K-571
sect571r1 | | NIST B-571
secp160k1 | |
secp160r1 | |
secp160r2 | |
secp192k1 | |
secp192r1 | prime192v1 | NIST P-192
secp224k1 | |
secp224r1 | | NIST P-224
secp256k1 | |
secp256r1 | prime256v1 | NIST P-256
secp384r1 | | NIST P-384
secp521r1 | | NIST P-521
------------+---------------+-------------
Table 6: Equivalent curves defined by SECG, ANSI, and NIST
Authors’ Addresses
Simon Blake-Wilson
SafeNet Technologies BV
Amstelveenseweg 88-90
1075 XJ, Amsterdam
NL
Phone: +31 653 899 836
EMail: sblakewilson@safenet-inc.com
Nelson Bolyard
Sun Microsystems Inc.
4170 Network Circle
MS SCA17-201
Santa Clara, CA 95054
US
Phone: +1 408 930 1443
EMail: nelson@bolyard.com
Vipul Gupta
Sun Microsystems Laboratories
16 Network Circle
MS UMPK16-160
Menlo Park, CA 94025
US
Phone: +1 650 786 7551
EMail: vipul.gupta@sun.com
Chris Hawk
Corriente Networks LLC
1563 Solano Ave., #484
Berkeley, CA 94707
US
Phone: +1 510 527 0601
EMail: chris@corriente.net
Bodo Moeller
Ruhr-Uni Bochum
Horst-Goertz-Institut, Lehrstuhl fuer Kommunikationssicherheit
IC 4/139
44780 Bochum
DE
Phone: +49 234 32 26795
EMail: bodo@openssl.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).