< draft-ietf-ipsec-ike-auth-ecdsa-02.txt   draft-ietf-ipsec-ike-auth-ecdsa-03.txt >
IPSec Working Group J. Solinas, NSA
IPSec Working Group S. Blake-Wilson and P. Fahn INTERNET-DRAFT
INTERNET-DRAFT Certicom Corp. Expires October 2, 2005 March 31, 2005
Expires: September 14, 2001 March 15, 2001
IKE Authentication Using ECDSA IKE Authentication Using ECDSA
<draft-ietf-ipsec-ike-auth-ecdsa-02.txt> <draft-ietf-ipsec-ike-auth-ecdsa-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all By submitting this Internet-Draft, each author represents that any
provisions of Section 10 of RFC2026. Internet-Drafts are working applicable patent or other IPR claims of which he or she is aware
documents of the Internet Engineering Task Force (IETF), its areas, have been or will be disclosed, and any of which he or she becomes
and its working groups. Note that other groups may also distribute aware will be disclosed, in accordance with Section 6 of BCP 79.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/ietf/1id-abstracts.txt Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html. and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Abstract The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
This document describes how the Elliptic Curve Digital Signature The list of Internet-Draft Shadow Directories can be accessed at
Algorithm (ECDSA) may be used as the authentication method within http://www.ietf.org/shadow.html
the Internet Key Exchange (IKE) protocol. 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 without
introducing any changes to existing IKE operation.
Table of Contents Abstract
1. Introduction ................................................. 2 This document describes how the Elliptic Curve Digital Signature
2. ECDSA ........................................................ 2 Algorithm (ECDSA) may be used as the authentication method within
3. Specifying ECDSA within IKE .................................. 3 the Internet Key Exchange (IKE) protocol. ECDSA may provide benefits
4. Security Considerations ...................................... 4 including computational efficiency, small signature sizes, and
5. Intellectual Property Rights ................................. 4 minimal bandwidth compared to other available digital signature
6. Acknowledgments .............................................. 4 methods. This document adds ECDSA capability to IKE without
7. References ................................................... 5 introducing any changes to existing IKE operation.
8. Authors' Addresses ........................................... 6
9. Full Copyright Statement ..................................... 6
1. Introduction 1. Introduction
The Internet Key Exchange, or IKE [RFC2409], is a key agreement The Internet Key Exchange, or IKE [IKE], is a key agreement and
and security negotiation protocol; it is used for key establishment in security negotiation protocol; it is used for key establishment in
IPSec. In Phase 1 of IKE, both parties must authenticate each other IPSec. In Phase 1 of IKE, both parties must authenticate each other
using a negotiated authentication method. One option for the using a negotiated authentication method. One option for the
authentication method is digital signatures using public key authentication method is digital signatures using public key
cryptography. Currently, there are two digital signature methods cryptography. Currently, there are two digital signature methods
defined for use within Phase 1: RSA signatures and DSA (DSS) defined for use within Phase 1: RSA signatures and DSA (DSS)
signatures. This document introduces ECDSA signatures as a third signatures. This document introduces ECDSA signatures as a third
method. 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; there are also advantages of computational
speed and efficiency in many settings. Additional efficiency may be
gained by simultaneously using ECDSA for IKE authentication and using
elliptic curve groups for the IKE key exchange. Implementers of IPSec
and IKE may therefore find it desirable to use ECDSA as the Phase 1
authentication method.
2. ECDSA 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; there are also advantages of
computational speed and efficiency in many settings. Additional
efficiency may be gained by simultaneously using ECDSA for IKE
authentication and using elliptic curve groups for the IKE key
exchange. Implementers of IPSec and IKE may therefore find it
desirable to use ECDSA as the Phase 1 authentication method.
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
curve analogue of the DSA (also called DSS) signature method "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
[FIPS186-2]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is document are to be interpreted as described in [RFC2119].
defined in the ANSI X9.62 standard [ANSIX962]; compatible
specifications include FIPS 186-2 [FIPS186-2], IEEE P1363 [IEEEP1363],
and SEC 1 [SEC1]. The use of ECDSA in X.509 certificates is described
in IETF PKIX [PKIX-ALG].
ECDSA signatures are smaller than RSA signatures of similar 2. ECDSA
cryptographic strength; see [KEYS] for a security analysis of key
sizes across public key algorithms. 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 faster than similar strength RSA or
DSA operations. These advantages of signature size, bandwidth, and
computational efficiency make ECDSA an attractive choice for many IKE
implementions.
Recommended elliptic curve domain parameters for use with ECDSA are The Elliptic Curve Digital Signature Algorithm (ECDSA) is the
given in FIPS 186-2 [FIPS186-2] and SEC 2 [SEC2]. A subset of these elliptic curve analogue of the DSA (DSS) signature method [DSS]. It
parameters are recommended in [ECC-GR] for use in the IKE key exchange. is defined in the ANSI X9.62 standard [X9.62]. Other compatible
specifications include FIPS 186-2 [DSS], IEEE 1363 [IEEE-1363], IEEE
1363A [IEEE-1363A], and SEC1 [SEC1].
Like DSA, ECDSA incorporates the use of a hash function; currently, Like DSA, ECDSA incorporates the use of a hash function. [SHS]
the only hash function defined for use with ECDSA is the SHA-1 message specifies hash functions that are appropriate for use with ECDSA.
digest algorithm [FIPS180-1]. Implementations of IKE using ECDSA SHOULD use one of these hash
functions.
3. Specifying ECDSA within IKE 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 implementations.
The IKE key negotiation protocol consists of two phases, Phase 1 and Recommended elliptic curve domain parameters for use with ECDSA are
Phase 2. Within Phase 1, the two negotiating parties authenticate each given in FIPS 186-2 [DSS], ANSI X9.62 [X9.62], and SEC 2 [SEC2].
other, using either pre-shared keys, digital signatures, or public-key
encryption. For digital signatures and public-key encryption methods,
there are multiple options. The authentication method is specified as
an attribute in the negotiated Phase 1 Security Association (SA).
Until now, there have been a total of seven specific authentication Implementations of IKE using ECDSA MAY use one of these domain
methods in Phase 1. We now add an eighth option: ECDSA signatures, parameters. A subset of these parameters are recommended in
specified by attribute value 8 in the SA. The new list of [IKE-ECP] for use in the IKE key exchange. These parameters MAY
IANA-assigned attribute numbers for Phase 1 authentication is: be used for ECDSA as well.
- Authentication Method 3. Specifying ECDSA within IKE
pre-shared key 1
DSS signatures 2
RSA signatures 3
Encryption with RSA 4
Revised encryption with RSA 5
Encryption with El-Gamal 6
Revised encryption with El-Gamal 7
ECDSA signatures 8
values 9-65000 are reserved to IANA. Values 65001-65535 are for The IKE key negotiation protocol consists of two phases, Phase 1 and
private use among mutually consenting parties. Phase 2. Within Phase 1, the two negotiating parties authenticate
each other, using either pre-shared keys, digital signatures, or
public-key encryption. For digital signatures and public-key
encryption methods, there are multiple options. The IANA-assigned
attribute number for Phase 1 authentication using ECDSA is 8 (see
[IANA]).
Phase 1 can be either Main Mode or Agressive Mode. The use and Phase 1 can be either Main Mode or Aggressive Mode. The use and
specification of ECDSA signatures as the authentication method applies specification of ECDSA signatures as the authentication method
to both modes. The sequence of Phase 1 message payloads is the same applies to both modes. The sequence of Phase 1 message payloads is
with ECDSA signatures as with DSS or RSA signatures. the same with ECDSA signatures as with DSS or RSA signatures.
When ECDSA is used in IKE, the signature payload shall contain an When ECDSA is used in IKE, the signature payload SHALL contain an
encoding of the computed signature, consisting of a pair of integers r encoding of the computed signature, consisting of a pair of integers
and s, encoded as a byte string using the ASN.1 syntax r and s, encoded as a byte string using the ASN.1 syntax
"ECDSA-Sig-Value" with DER encoding rules as specified in "ECDSA-Sig-Value" with DER encoding rules as specified in ANSI X9.62
ANSI X9.62 [ANSIX962]. [X9.62].
Note also that, like the other digital signature methods, ECDSA As with the other digital signature methods, ECDSA authentication
authentication requires the parties to know and trust each other's requires the parties to know and trust each other's public key. This
public key. This can be done by exchanging certificates, possibly can be done by exchanging certificates, possibly within the Phase 1
within the Phase 1 negotiation, if the public keys of the parties are negotiation, if the public keys of the parties are not already known
not already known to each other. The use of Internet X.509 public key to each other. The use of Internet X.509 public key infrastructure
infrastructure certificates [PKIX-CERT] is recommended; the certificates [RFC-3280] is recommended; the representation of ECDSA
representation of ECDSA keys in X.509 certificates is specified in keys in X.509 certificates is specified in [RFC-3279]. This
[PKIX-ALG]. representation SHOULD be used if X.509 certificates are used.
Since ECDSA requires the use of the SHA-1 hash function, Implemententers may find it convenient, when using ECDSA as the
implemententers may find it convenient to specify SHA-1 as the value authentication method, to specify the hash used by ECDSA as the
of the hash algorithm attribute when using ECDSA as the authentication value of the hash algorithm attribute. Implementers may also find
method. Implementers may also find it convenient to use ECDSA it convenient to use ECDSA authentication in conjunction with an
authentication in conjunction with an elliptic curve group for the IKE elliptic curve group for the IKE Diffie-Hellman key agreement; see
Diffie-Hellman key agreement; see [ECC-GR] for specific curves for the [IKE-ECP] for some specific curves for the key agreement.
key agreement.
4. Security Considerations 4. Security Considerations
Implementors should ensure that appropriate security measures are in Implementors should ensure that appropriate security measures are in
place when they deploy ECDSA within IKE. In particular, the security place when they deploy ECDSA within IKE. In particular, the security
of ECDSA requires the careful selection of both key sizes and elliptic of ECDSA requires the careful selection of both key sizes and
curve domain parameters. Selection guidelines for these parameters and elliptic curve domain parameters. Selection guidelines for these
some specific recommended curves that are considered safe are provided parameters and some specific recommended curves that are considered
in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], and SEC 2 [SEC2]. safe are provided in ANSI X9.62 [X9.62], FIPS 186-2 [DSS], and SEC 2
[SEC2].
5. Intellectual Property Rights 5. IANA Considerations
The IETF has been notified of intellectual property rights claimed in This document has no actions for IANA.
regard to the specification contained in this document. For more
information, consult the online list of claimed rights
(http://www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any 6. References
intellectual property 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; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can be obtained
from the IETF Secretariat.
6. Acknowledgments 6.1 Normative
The authors would like to thank Paul Lambert and Prakash Panjwani for [IKE] D. Harkins and D. Carrel, The Internet Key Exchange, RFC 2409,
their comments and suggestions. November 1998.
7. References [RFC-3279] Bassham, L., Housley, R., and Polk, W., RFC 3279,
Algorithms and Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL)
Profile, 2002. (http://www.ietf.org/rfc/rfc3279.txt)
[ANSIX962] ANSI X9.62-1999, "Public Key Cryptography For The Financial [RFC-3280] Housley, R., Polk, W., Ford, W. and D. Solo, RFC 3280,
Services Industry: The Elliptic Curve Digital Signature Internet X.509 Public Key Infrastructure Certificate and
Algorithm (ECDSA)", Americal National Standards Institute, Certificate Revocation List (CRL) Profile, 2002.
1998. (http://www.ietf.org/rfc/rfc3279.txt)
[ECC-GR] S. Blake-Wilson, M. Salter, and Y. Poeluev, "Additional [X9.62] American National Standards Institute, ANS X9.62-1998:
ECC Groups for IKE", IPSEC Working Group Internet-Draft Public Key Cryptography for the Financial Services Industry: The
draft-ietf-ipsec-ike-ecc-groups-03.txt. September 1999. Elliptic Curve Digital Signature Algorithm. January 1999.
[FIPS180-1] FIPS 180-1, "Secure Hash Standard", National Institute of 6.2 Informative
Standards and Technology, 1995.
[FIPS186-2] FIPS 186-2, "Digital Signature Standard", National Institute [DSS] U.S. Department of Commerce/National Institute of Standards
of Standards and Technology, 2000. and Technology, Digital Signature Standard (DSS), FIPS PUB 186-2,
January 2000. (http://csrc.nist.gov/publications/fips/index.html)
[IEEEP1363] IEEE P1363, "Standard Specifications for Public Key [IANA] Internet Assigned Numbers Authority, Internet Key Exchange
Cryptography", Institute of Electrical and Electronics (IKE) Attributes. (http://www.iana.org/assignments/ipsec-registry)
Engineers, 2000.
[KEYS] A. Lenstra and E. Verheul, "Selecting Cryptographic Key [IEEE-1363] Institute of Electrical and Electronics Engineers.
Sizes", October 1999. Presented at Public Key Cryptography IEEE 1363-2000, Standard for Public Key Cryptography.
Conference, Melbourne, Australia, January 2000. Available (http://grouper.ieee.org/groups/1363/index.html)
at <http://www.cryptosavvy.com/>.
[PKIX-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and [IEEE-1363A] Institute of Electrical and Electronics Engineers.
Identifiers for the Internet X.509 Public Key IEEE 1363A-2004, Standard for Public Key Cryptography -
Infrastructure Certificate and CRL Profile", PKIX Working Amendment 1: Additional Techniques.
Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt, (http://grouper.ieee.org/groups/1363/index.html)
March 2001.
[PKIX-CERT] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509 [IKE-ECP] J. Solinas, ECP Groups For IKE, 2005.
Public Key Infrastructure Certificate and CRL Profile", PKIX (draft-ietf-ipsec-ike-ecc-groups-05.txt)
Working Group Internet-Draft,
draft-ietf-pkix-new-part1-05.txt, March 2001.
[RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange", [LV] A. Lenstra and E. Verheul, "Selecting Cryptographic Key
IETF RFC 2409, November 1998. Sizes", Journal of Cryptology 14 (2001), pp. 255-293.
[SEC1] SEC 1, "Elliptic Curve Cryptography", Standards for Efficient [SEC1] Standards for Efficient Cryptography Group. SEC 1 - Elliptic
Cryptography Group, 2000. Curve Cryptography, v. 1.0, 2000. (http://www.secg.org)
[SEC2] SEC 2, "Recommended Elliptic Curve Domain Parameters", [SEC2] Standards for Efficient Cryptography Group. SEC 2 -
Standards for Efficient Cryptography Group, 2000. Recommended Elliptic Curve Domain Parameters, v. 1.0, 2000.
(http://www.secg.org)
8. Author's Address [SHS] FIPS 180-2, "Secure Hash Standard", National Institute of
Standards and Technology, 2002.
Simon Blake-Wilson 7. Author's Address
Certicom Corp.
sblake-wilson@certicom.com
Paul Fahn Jerome A. Solinas
Certicom Corp. National Security Agency
pfahn@certicom.com jsolinas@orion.ncsc.mil
9. Full Copyright Statement Comments are solicited and should be addressed to the author.
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2005).
This document and translations of it may be copied and furnished to This document is subject to the rights, licenses and restrictions
others, and derivative works that comment on or otherwise explain it contained in BCP 78, and except as set forth therein, the authors
or assist in its implementation may be prepared, copied, published retain all their rights.
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be This document and the information contained herein are provided on an
revoked by the Internet Society or its successors or assigns. "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.
This document and the information contained herein is provided on an Expires October 2, 2005
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
 End of changes. 50 change blocks. 
209 lines changed or deleted 167 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/