|
Network Working Group Request for Comment: 4754 Category: Standards Track |
D. Fu J. Solinas NSA January 2007 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The IETF Trust (2007).
This document describes how the Elliptic Curve Digital Signature
Algorithm (ECDSA) may be used as the authentication method within the
Internet Key Exchange (IKE) and Internet Key Exchange version 2
(IKEv2) protocols. ECDSA may provide benefits including
computational efficiency, small signature sizes, and minimal
bandwidth compared to other available digital signature methods.
This document adds ECDSA capability to IKE and IKEv2 without
introducing any changes to existing IKE operation.
1. Introduction
2. Requirements Terminology
3. ECDSA
4. Specifying ECDSA within IKE and IKEv2
5. Security Considerations
6. IANA Considerations
7. ECDSA Data Formats
8. Test Vectors
8.1. ECDSA-256
8.2. ECDSA-384
8.3. ECDSA-521
9. References
9.1. Normative References
9.2. Informative References
The Internet Key Exchange, or IKE [IKE], is a key agreement and security negotiation protocol; it is used for key establishment in IPsec. In the initial set of exchanges, both parties must authenticate each other using a negotiated authentication method. In the original version of IKE, this occurs in Phase 1; in IKEv2, it occurs in the exchange called IKE-AUTH. One option for the authentication method is digital signatures using public key cryptography. Currently, there are two digital signature methods defined for use within Phase 1 and IKE-AUTH: RSA signatures and Digital Signature Algorithm (DSA) Digital Signature Standard (DSS) signatures. This document introduces ECDSA signatures as a third method.
For any given level of security against the best attacks known, ECDSA signatures are smaller than RSA signatures, and ECDSA keys require less bandwidth than DSA keys [LV]; there are also advantages of computational speed and efficiency in many settings. Additional efficiency may be gained by simultaneously using ECDSA for IKE/IKEv2 authentication and using elliptic curve groups for the IKE/IKEv2 key exchange. Implementers of IPsec and IKE/IKEv2 may therefore find it desirable to use ECDSA as the Phase 1/IKE-AUTH authentication method.
The key word "SHALL" in this document is to be interpreted as described in [RFC2119].
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic curve analogue of the DSA (DSS) signature method [DSS]. It is defined in the ANSI X9.62 standard [X9.62-2003]. Other compatible specifications include FIPS 186-2 [DSS], IEEE 1363 [IEEE-1363], IEEE 1363A [IEEE-1363A], and SEC1 [SEC].
ECDSA signatures are smaller than RSA signatures of similar cryptographic strength. ECDSA public keys (and certificates) are smaller than similar strength DSA keys, resulting in improved communications efficiency. Furthermore, on many platforms, ECDSA operations can be computed more quickly than similar strength RSA or DSA operations (see [LV] for a security analysis of key sizes across public key algorithms). These advantages of signature size, bandwidth, and computational efficiency may make ECDSA an attractive choice for many IKE and IKEv2 implementations.
The original IKE key negotiation protocol consists of two phases, Phase 1 and Phase 2. Within Phase 1, the two negotiating parties authenticate each other using either pre-shared keys, digital signatures, or public key encryption.
The IKEv2 key negotiation protocol begins with two exchanges, IKE-SA-INIT and IKE-AUTH. When not using extensible authentication, the IKE-AUTH exchange includes a digital signature or Message Authentication Code (MAC) on a block of data.
The IANA-assigned attribute number for authentication using generic
ECDSA in IKE is 8 (see [IANA-IKE]), but the corresponding list of
IKEv2 authentication methods does not include ECDSA (see
[IANA-IKEv2]). Moreover, ECDSA cannot be specified for IKEv2
independently of an associated hash function since IKEv2 does not
have a transform type for hash functions. For this reason, it is
necessary to specify the hash function as part of the signature
algorithm. Furthermore, the elliptic curve group must be specified
since the choice of hash function depends on it as well. As a
result, it is necessary to specify three signature algorithms, named
ECDSA-256, ECDSA-384, and ECDSA-521. Each of these algorithms
represents an instantiation of the ECDSA algorithm using a particular
elliptic curve group and hash function. The three hash functions are
specified in [SHS]. For reasons of consistency, this document
defines the signatures for IKE in the same way.
Digital
Signature
Algorithm Elliptic Curve Group Hash Function
----------- -------------------------- ---------------
ECDSA-256 256-bit random ECP group SHA-256
ECDSA-384 384-bit random ECP group SHA-384
ECDSA-521 521-bit random ECP group SHA-512
The elliptic curve groups, including their base points, are specified in [IKE-ECP].
Since this document proposes new digital signatures for use within IKE and IKEv2, many of the security considerations contained within [IKE] and [IKEv2] apply here as well. Implementers should ensure that appropriate security measures are in place when they deploy ECDSA within IKE or IKEv2.
ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security comparable with the AES-128, AES-192, and AES-256 respectively.
IANA updated its registry of IPsec authentication methods in [IANA-IKE] and its registry of IKEv2 authentication methods in [IANA-IKEv2] to include ECDSA-256, ECDSA-384, and ECDSA-521.
When ECDSA-256, ECDSA-384, or ECDSA-521 is used as the digital signature in IKE or IKEv2, the signature payload SHALL contain an encoding of the computed signature consisting of the concatenation of a pair of integers r and s. The definitions of r and s are given in Section 8 of this document.
Digital
Signature Bit Lengths Bit Length
Algorithm of r and s of Signature
----------- ------------- --------------
ECDSA-256 256 512
ECDSA-384 384 768
ECDSA-521 528 1056
The bit lengths of r and s are enforced, if necessary, by pre-pending the value with zeros.
The following are examples of the IKEv2 authentication payload for each of the three signatures specified in this document.
The following notation is used. The Diffie-Hellman group is given by
the elliptic curve y^2 = (x^3 - 3 x + b) modulo p. If (x,y) is a point on the curve (i.e., x and y satisfy the above equation), then (x,y)^n denotes the scalar multiple of the point (x,y) by the integer n; it is another point on the curve. In the literature, the scalar multiple is typically denoted n(x,y); the notation (x,y)^n is used to conform to the notation used in [IKE], [IKEv2], and [IKE-ECP].
The group order for the curve group is denoted q. The generator is denoted g=(gx,gy). The hash of the message is denoted h. The signer's static private key is denoted w; it is an integer between zero and q. The signer's static public key is g^w=(gwx,gwy). The ephemeral private key is denoted k; it is an integer between zero and q. The ephemeral public key is g^k=(gkx,gky). The quantity kinv is
the integer between zero and q such that k*kinv = 1 modulo q. The
first signature component is denoted r; it is equal to gkx reduced modulo q. The second signature component is denoted s; it is equal to (h+r*w)*kinv reduced modulo q.
The test vectors below also include the data for verifying the ECDSA signature. The verifier computes h and the quantity sinv, which is
the integer between zero and q such that s*sinv = 1 modulo q. The
verifier computes
u = h*sinv modulo q
and
v = r*sinv modulo q.
The verifier computes (gx,gy)^u = (gux,guy) and (gwx,gwy)^v =
(gwvx,gwvy). The verifier computes the sum
(sumx,sumy) = (gux,guy) + (gwvx,gwvy)
where + denotes addition of points on the elliptic curve. The signature is verified if
sumx modulo q = r.
IANA assigned the ID value 9 to ECDSA-256.
The parameters for the group for this signature are
The static and ephemeral keys are given by
The SHA-256 hash of the message "abc" (hex 616263) is
The signature of the message is (r,s) where
The quantities required for verification of the signature are
The signature is valid since sumx modulo q equals r.
If the signature (r,s) were the one appearing in the authentication payload, then the payload would be as follows.
00000048 00090000 CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E 97566EA1 C066957C 86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E A0C89212 748BFF3B 3D5B0315
IANA assigned the ID value 10 to ECDSA-384.
The parameters for the group for this signature are
The static and ephemeral keys are given by
The SHA-384 hash of the message "abc" (hex 616263) is
The signature of the message is (r,s) where
The quantities required for verification of the signature are
The signature is valid since sumx modulo q equals r.
If the signature (r,s) were the one appearing in the authentication payload, then the payload would be as follows.
00000068 000A0000 FB017B91 4E291494 32D8BAC2 9A514640 B46F53DD AB2C6994 8084E293 0F1C8F7E 08E07C9C 63F2D21A 07DCB56A 6AF56EB3 B263A130 5E057F98 4D38726A 1B468741 09F417BC A112674C 528262A4 0A629AF1 CBB9F516 CE0FA7D2 FF630863 A00E8B9F
IANA assigned the ID value 11 to ECDSA-521.
The parameters for the group for this signature are
The static and ephemeral keys are given by
The hash of the message "abc" (hex 616263) is
Therefore, the quantity h is
The signature of the message is (r,s) where
The quantities required for verification of the signature are
The signature is valid since sumx modulo q equals r.
If the signature (r,s) were the one appearing in the authentication payload, then the payload would be as follows.
0000008C 000B0000 0154FD38 36AF92D0 DCA57DD5 341D3053 988534FD E8318FC6 AAAAB68E 2E6F4339 B19F2F28 1A7E0B22 C269D93C F8794A92 78880ED7 DBB8D936 2CAEACEE 54432055 22510177 05A70302 90D1CEB6 05A9A1BB 03FF9CDD 521E87A6 96EC926C 8C10C836 2DF49753 67101F67 D1CF9BCC BF2F3D23 9534FA50 9E70AAC8 51AE01AA C68D62F8 66472660
[IANA-IKE] Internet Assigned Numbers Authority, Internet Key
Exchange (IKE) Attributes.
(http://www.iana.org/assignments/ipsec-registry)
[IANA-IKEv2] IKEv2 Parameters.
(http://www.iana.org/assignments/ikev2-parameters)
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[IKE-ECP] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
RFC 4753, January 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SHS] FIPS 180-2, "Secure Hash Standard", National Institute
of Standards and Technology, 2002.
[X9.62-2005] American National Standards Institute, X9.62-2005: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA).
[DSS] U.S. Department of Commerce/National Institute of
Standards and Technology, Digital Signature Standard
(DSS), FIPS PUB 186-2, January 2000.
(http://csrc.nist.gov/publications/fips/index.html)
[IEEE-1363] Institute of Electrical and Electronics Engineers. IEEE 1363-2000, Standard for Public Key Cryptography. (http://grouper.ieee.org/groups/1363/index.html)
[IEEE-1363A] Institute of Electrical and Electronics Engineers. IEEE
1363A-2004, Standard for Public Key Cryptography -
Amendment 1: Additional Techniques.
(http://grouper.ieee.org/groups/1363/index.html)
[LV] A. Lenstra and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001), pp. 255-293.
[SEC] Standards for Efficient Cryptography Group. SEC 1 -
Elliptic Curve Cryptography, v. 1.0, 2000.
(http://www.secg.org)
David E. Fu
National Information Assurance Research Laboratory
National Security Agency
EMail: defu@orion.ncsc.mil
Jerome A. Solinas
National Information Assurance Research Laboratory
National Security Agency
EMail: jasolin@orion.ncsc.mil
Copyright © The IETF Trust (2007).
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, THE IETF TRUST 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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.