Network Working Group D. Fu
Request for Comment: 4754 J. Solinas
Category: Standards Track NSA
January 2007
IKE and IKEv2 Authentication Usingthe Elliptic Curve Digital Signature Algorithm (ECDSA)
Status of This Memo
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 Notice
Copyright (C) The IETF Trust (2007).
Abstract
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.
Table of Contents
1. Introduction ....................................................22. Requirements Terminology ........................................23. ECDSA ...........................................................24. Specifying ECDSA within IKE and IKEv2 ...........................35. Security Considerations .........................................36. IANA Considerations .............................................47. ECDSA Data Formats ..............................................48. Test Vectors ....................................................48.1. ECDSA-256 ..................................................58.2. ECDSA-384 ..................................................78.3. ECDSA-521 .................................................109. References .....................................................139.1. Normative References ......................................139.2. Informative References ....................................14Fu & Solinas Standards Track [Page 1]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 20071. Introduction
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.
2. Requirements Terminology
The key word "SHALL" in this document is to be interpreted as
described in [RFC2119].
3. ECDSA
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.
Fu & Solinas Standards Track [Page 2]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 20074. Specifying ECDSA within IKE and IKEv2
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].
5. Security Considerations
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.
Fu & Solinas Standards Track [Page 3]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security
comparable with the AES-128, AES-192, and AES-256 respectively.
6. IANA Considerations
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.
7. ECDSA Data Formats
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.
8. Test Vectors
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
Fu & Solinas Standards Track [Page 4]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
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.
8.1. ECDSA-256
IANA assigned the ID value 9 to ECDSA-256.
The parameters for the group for this signature are
p:
FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF
b:
5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B
q:
FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551
gx:
6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296
gy:
4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5
Fu & Solinas Standards Track [Page 5]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
The static and ephemeral keys are given by
w:
DC51D386 6A15BACD E33D96F9 92FCA99D A7E6EF09 34E70975 59C27F16 14C88A7F
gwx:
2442A5CC 0ECD015F A3CA31DC 8E2BBC70 BF42D60C BCA20085 E0822CB0 4235E970
gwy:
6FC98BD7 E50211A4 A27102FA 3549DF79 EBCB4BF2 46B80945 CDDFE7D5 09BBFD7D
k:
9E56F509 196784D9 63D1C0A4 01510EE7 ADA3DCC5 DEE04B15 4BF61AF1 D5A6DECE
gkx:
CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E 97566EA1 C066957C
gky:
2B57C023 5FB74897 68D058FF 4911C20F DBE71E36 99D91339 AFBB903E E17255DC
The SHA-256 hash of the message "abc" (hex 616263) is
h:
BA7816BF 8F01CFEA 414140DE 5DAE2223 B00361A3 96177A9C B410FF61 F20015AD
The signature of the message is (r,s) where
kinv:
AFA27894 5AF74B1E 295008E0 3A8984E2 E1C69D9B BBC74AF1 4E3AC4E4 21ABFA61
r:
CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E 97566EA1 C066957C
s:
86FA3BB4 E26CAD5B F90B7F81 899256CE 7594BB1E A0C89212 748BFF3B 3D5B0315
The quantities required for verification of the signature are
sinv:
33BDC294 E90CFAD6 2A9F2FD1 F8741DA7 7C02A573 E1B53BA1 7A60BA90 4F491952
u:
C3875E57 C85038A0 D60370A8 7505200D C8317C8C 534948BE A6559C7C 18E6D4CE
v:
3B4E49C4 FDBFC006 FF993C81 A50EAE22 1149076D 6EC09DDD 9FB3B787 F85B6483
Fu & Solinas Standards Track [Page 6]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
gux:
4F749762 9362EFBB EE591206 D036568F 239789B2 34960635 C6607EC6 99062600
guy:
8490E12D E4DBB68C BF941721 5D8C648E 57A8E0E4 4E176856 3CD58697 001A8D08
gwvx:
726E5684 964DB8EA 341D8679 DFB70E04 EDA404E9 94BA730F A43F1E78 ED81211B
gwvy:
0C10CBA8 DD2620C1 12A4F9BE 578E4BE1 E64DC0F7 D1D526CA 167749F9 CEC0DF08
sumx:
CB28E099 9B9C7715 FD0A80D8 E47A7707 9716CBBF 917DD72E 97566EA1 C066957C
sumy:
2B57C023 5FB74897 68D058FF 4911C20F DBE71E36 99D91339 AFBB903E E17255DC
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
8.2. ECDSA-384
IANA assigned the ID value 10 to ECDSA-384.
The parameters for the group for this signature are
p:
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE
FFFFFFFF 00000000 00000000 FFFFFFFF
b:
B3312FA7 E23EE7E4 988E056B E3F82D19 181D9C6E FE814112 0314088F 5013875A
C656398D 8A2ED19D 2A85C8ED D3EC2AEF
q:
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF C7634D81 F4372DDF
581A0DB2 48B0A77A ECEC196A CCC52973
Fu & Solinas Standards Track [Page 7]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
gx:
AA87CA22 BE8B0537 8EB1C71E F320AD74 6E1D3B62 8BA79B98 59F741E0 82542A38
5502F25D BF55296C 3A545E38 72760AB7
gy:
3617DE4A 96262C6F 5D9E98BF 9292DC29 F8F41DBD 289A147C E9DA3113 B5F0B8C0
0A60B1CE 1D7E819D 7A431D7C 90EA0E5F
The static and ephemeral keys are given by
w:
0BEB6466 34BA8773 5D77AE48 09A0EBEA 865535DE 4C1E1DCB 692E8470 8E81A5AF
62E528C3 8B2A81B3 5309668D 73524D9F
gwx:
96281BF8 DD5E0525 CA049C04 8D345D30 82968D10 FEDF5C5A CA0C64E6 465A97EA
5CE10C9D FEC21797 41571072 1F437922
gwy:
447688BA 94708EB6 E2E4D59F 6AB6D7ED FF9301D2 49FE49C3 3096655F 5D502FAD
3D383B91 C5E7EDAA 2B714CC9 9D5743CA
k:
B4B74E44 D71A13D5 68003D74 89908D56 4C7761E2 29C58CBF A1895009 6EB7463B
854D7FA9 92F934D9 27376285 E63414FA
gkx:
FB017B91 4E291494 32D8BAC2 9A514640 B46F53DD AB2C6994 8084E293 0F1C8F7E
08E07C9C 63F2D21A 07DCB56A 6AF56EB3
gky:
2C735822 48686C41 8485E7B7 4E707625 A1832769 F7F56E81 7CF83B1E 4690E782
65B7AD37 BC2F865F DC290DB6 15CDF17F
The SHA-384 hash of the message "abc" (hex 616263) is
h:
CB00753F 45A35E8B B5A03D69 9AC65007 272C32AB 0EDED163 1A8B605A 43FF5BED
8086072B A1E7CC23 58BAECA1 34C825A7
The signature of the message is (r,s) where
kinv:
EB12876B F6191A29 1AA5780A 3887C3BF E7A5C7E3 21CCA674 886B1228 D9BB3D52
918EF19F E5CE67E9 80BEDC1E 613D39C0
Fu & Solinas Standards Track [Page 8]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
sumx:
0154FD38 36AF92D0 DCA57DD5 341D3053 988534FD E8318FC6 AAAAB68E 2E6F4339
B19F2F28 1A7E0B22 C269D93C F8794A92 78880ED7 DBB8D936 2CAEACEE 54432055
2251
sumy:
006D073D 72B272EA 86388D86 8EF64D4C 300A67AC 2981C0F8 E6710AEF A2FCF845
8117B05E B91BA11C 68BCFC1B C24587E3 A1D0CA2A FE398CDB CFD79CB3 0B36B218
B437
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
9. References9.1. Normative References
[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.
Fu & Solinas Standards Track [Page 13]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
[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).
9.2. Informative References
[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)
Authors' Addresses
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
Fu & Solinas Standards Track [Page 14]
RFC 4754 IKE and IKEv2 Authentication Using ECDSA January 2007
Full Copyright Statement
Copyright (C) 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.
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 currently provided by the
Internet Society.
Fu & Solinas Standards Track [Page 15]
