< draft-ietf-ipsec-ike-auth-ecdsa-01.txt   draft-ietf-ipsec-ike-auth-ecdsa-02.txt >
IPSec Working Group S. Blake-Wilson and P. Fahn IPSec Working Group S. Blake-Wilson and P. Fahn
INTERNET-DRAFT Certicom Corp. INTERNET-DRAFT Certicom Corp.
Expires: April 14, 2001 October 15, 2000 Expires: September 14, 2001 March 15, 2001
IKE Authentication Using ECDSA IKE Authentication Using ECDSA
<draft-ietf-ipsec-ike-auth-ecdsa-01.txt> <draft-ietf-ipsec-ike-auth-ecdsa-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." 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.
Abstract Abstract
This document describes how the Elliptic Curve Digital Signature This document describes how the Elliptic Curve Digital Signature
Algorithm (ECDSA) may be used as the authentication method within Algorithm (ECDSA) may be used as the authentication method within
the Internet Key Exchange (IKE) protocol. ECDSA provides the Internet Key Exchange (IKE) protocol. ECDSA may provide
authentication and non-repudiation with benefits of computational benefits including computational efficiency, small signature sizes,
efficiency, small signature sizes, and minimal bandwidth, compared and minimal bandwidth, compared to other available digital signature
to other available digital signature methods. This document adds methods. This document adds ECDSA capability to IKE without
ECDSA capability to IKE without introducing any changes to existing introducing any changes to existing IKE operation.
IKE operation.
Table of Contents
1. Introduction ................................................. 2
2. ECDSA ........................................................ 2
3. Specifying ECDSA within IKE .................................. 3
4. Security Considerations ...................................... 4
5. Intellectual Property Rights ................................. 4
6. Acknowledgments .............................................. 4
7. References ................................................... 5
8. Authors' Addresses ........................................... 6
9. Full Copyright Statement ..................................... 6
1. Introduction 1. Introduction
The Internet Key Exchange, or IKE [RFC2409, IKE], is a key agreement The Internet Key Exchange, or IKE [RFC2409], is a key agreement
and security negotiation protocol; it is used for key establishment in and 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, ECDSA signatures are smaller than RSA For any given level of security against the best attacks known, ECDSA
signatures and ECDSA keys require less bandwidth than DSA keys; there signatures are smaller than RSA signatures and ECDSA keys require less
are also advantages of computational speed and efficiency in many bandwidth than DSA keys; there are also advantages of computational
settings. Additional efficiency may be gained by simultaneously using speed and efficiency in many settings. Additional efficiency may be
ECDSA for IKE authentication and using elliptic curve groups for the gained by simultaneously using ECDSA for IKE authentication and using
IKE key exchange. Implementers of IPSec and IKE may therefore find it elliptic curve groups for the IKE key exchange. Implementers of IPSec
desirable to use ECDSA as the Phase 1 authentication method. and IKE may therefore find it desirable to use ECDSA as the Phase 1
authentication method.
2. ECDSA 2. ECDSA
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic
curve analogue of the DSA (also called DSS) signature method curve analogue of the DSA (also called DSS) signature method
[FIPS-186]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is [FIPS186-2]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is
defined in the ANSI X9.62 standard [X9.62]; a compatible defined in the ANSI X9.62 standard [ANSIX962]; compatible
specification, along with test vectors, can be found in the documents specifications include FIPS 186-2 [FIPS186-2], IEEE P1363 [IEEEP1363],
of the Standards for Efficient Cryptography Group at and SEC 1 [SEC1]. The use of ECDSA in X.509 certificates is described
<http://www.secg.org>. A profile for the use of ECDSA in X.509 in IETF PKIX [PKIX-ALG].
certificates [EPKIX] describes the means to carry ECDSA keys in X.509
certificates.
ECDSA signatures are smaller than RSA signatures of similar ECDSA signatures are smaller than RSA signatures of similar
cryptographic strength; see [KEYS] for a security analysis of key cryptographic strength; see [KEYS] for a security analysis of key
sizes across public key algorithms. ECDSA public keys (and sizes across public key algorithms. ECDSA public keys (and
certificates) are smaller than similar strength DSA keys, resulting in certificates) are smaller than similar strength DSA keys, resulting in
improved communications efficiency. Furthermore, on many platforms improved communications efficiency. Furthermore, on many platforms
ECDSA operations can be computed faster than similar strength RSA or ECDSA operations can be computed faster than similar strength RSA or
DSA operations. These advantages of signature size, bandwidth, and DSA operations. These advantages of signature size, bandwidth, and
computational efficiency make ECDSA an attractive choice for many IKE computational efficiency make ECDSA an attractive choice for many IKE
implementions. implementions.
Recommended elliptic curve domain parameters for use with ECDSA are Recommended elliptic curve domain parameters for use with ECDSA are
given in [SEC2]. A subset of these are recommended in [ECC-GR] for use given in FIPS 186-2 [FIPS186-2] and SEC 2 [SEC2]. A subset of these
in the IKE key exchange. parameters are recommended in [ECC-GR] for use in the IKE key exchange.
Like DSA, ECDSA incorporates the use of a hash function; currently, Like DSA, ECDSA incorporates the use of a hash function; currently,
the only hash function defined for use with ECDSA is the SHA-1 message the only hash function defined for use with ECDSA is the SHA-1 message
digest algorithm [FIPS-180]. digest algorithm [FIPS180-1].
3. Specifying ECDSA within IKE 3. Specifying ECDSA within IKE
The IKE key negotiation protocol consists of two phases, Phase 1 and The IKE key negotiation protocol consists of two phases, Phase 1 and
Phase 2. Within Phase 1, the two negotiating parties authenticate each Phase 2. Within Phase 1, the two negotiating parties authenticate each
other, using either pre-shared keys, digital signatures, or public-key other, using either pre-shared keys, digital signatures, or public-key
encryption. For digital signatures and public-key encryption methods, encryption. For digital signatures and public-key encryption methods,
there are multiple options. The authentication method is specified as there are multiple options. The authentication method is specified as
an attribute in the negotiated Phase 1 Security Association (SA). an attribute in the negotiated Phase 1 Security Association (SA).
skipping to change at line 123 skipping to change at page 3, line 39
values 9-65000 are reserved to IANA. Values 65001-65535 are for values 9-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties. private use among mutually consenting parties.
Phase 1 can be either Main Mode or Agressive Mode. The use and Phase 1 can be either Main Mode or Agressive Mode. The use and
specification of ECDSA signatures as the authentication method applies specification of ECDSA signatures as the authentication method applies
to both modes. The sequence of Phase 1 message payloads is the same to both modes. The sequence of Phase 1 message payloads is the same
with ECDSA signatures as with DSS or RSA signatures. 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 r
and s, encoded using the ASN.1 syntax "ECDSA-Sig-Value" as specified and s, encoded as a byte string using the ASN.1 syntax
in ANSI X9.62 [X9.62] and PKIX [EPKIX]. "ECDSA-Sig-Value" with DER encoding rules as specified in
ANSI X9.62 [ANSIX962].
Note also that, like the other digital signature methods, ECDSA Note also that, like the other digital signature methods, ECDSA
authentication requires the parties to know and trust each other's authentication requires the parties to know and trust each other's
public key. This can be done by exchanging certificates, possibly public key. This can be done by exchanging certificates, possibly
within the Phase 1 negotiation, if the public keys of the parties are within the Phase 1 negotiation, if the public keys of the parties are
not already known to each other. The use of Internet X.509 public key not already known to each other. The use of Internet X.509 public key
infrastructure certificates [RFC 2459] is recommended; the infrastructure certificates [PKIX-CERT] is recommended; the
representation of ECDSA keys in X.509 certificates is specified in representation of ECDSA keys in X.509 certificates is specified in
[EPKIX]. [PKIX-ALG].
Since ECDSA requires the use of the SHA-1 hash function, Since ECDSA requires the use of the SHA-1 hash function,
implemententers may find it convenient to specify SHA-1 as the value implemententers may find it convenient to specify SHA-1 as the value
of the hash algorithm attribute when using ECDSA as the authentication of the hash algorithm attribute when using ECDSA as the authentication
method. Implementers may also find it convenient to use ECDSA method. Implementers may also find it convenient to use ECDSA
authentication in conjunction with an elliptic curve group for the IKE authentication in conjunction with an elliptic curve group for the IKE
Diffie-Hellman key agreement; see [ECC-GR] for specific curves for the Diffie-Hellman key agreement; see [ECC-GR] for specific curves for the
key agreement. key agreement.
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 elliptic
curve domain parameters. Selection guidelines for these parameters and curve domain parameters. Selection guidelines for these parameters and
some specific recommended curves that are considered safe are provided some specific recommended curves that are considered safe are provided
in [X9.62], [NIST-ECC], and [SEC2]. in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], and SEC 2 [SEC2].
Intellectual Property Rights 5. Intellectual Property Rights
To be provided. The IETF has been notified of intellectual property rights claimed in
regard to the specification contained in this document. For more
information, consult the online list of claimed rights
(http://www.ietf.org/ipr.html).
[NOTE: The readers should be aware of the possibility that The IETF takes no position regarding the validity or scope of any
implementation of this draft may require use of inventions covered by intellectual property or other rights that might be claimed to pertain
patent rights.] 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.
Acknowledgments 6. Acknowledgments
The author would like to thank Simon Blake-Wilson, Prakash Panjwani, The authors would like to thank Paul Lambert and Prakash Panjwani for
and Paul Lambert for their comments and suggestions. their comments and suggestions.
References 7. References
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange", [ANSIX962] ANSI X9.62-1999, "Public Key Cryptography For The Financial
draft-ietf-ipsec-ike-01.txt, May 1999. Services Industry: The Elliptic Curve Digital Signature
Algorithm (ECDSA)", Americal National Standards Institute,
1998.
[RFC2409] Harkins, D. and Carrel, D., "The Internet Key Exchange" [ECC-GR] S. Blake-Wilson, M. Salter, and Y. Poeluev, "Additional
(RFC 2409). November, 1998. ECC Groups for IKE", IPSEC Working Group Internet-Draft
draft-ietf-ipsec-ike-ecc-groups-03.txt. September 1999.
[X9.62] American National Standards Institute. ANSI X9.62-1998, [FIPS180-1] FIPS 180-1, "Secure Hash Standard", National Institute of
"Public Key Cryptography for the Financial Services Standards and Technology, 1995.
Industry: The Elliptic Curve Digital Signature
Algorithm". January, 1999.
[KEYS] Lenstra, A.K. and Verheul, E.R., "Selecting Cryptographic [FIPS186-2] FIPS 186-2, "Digital Signature Standard", National Institute
Key Sizes", October 1999. Presented at Public Key of Standards and Technology, 2000.
Cryptography Conference, Melbourne, Australia, January,
2000. Available at <http://www.cryptosavvy.com/>.
[FIPS-180] Federal Information Processing Standards Publication [IEEEP1363] IEEE P1363, "Standard Specifications for Public Key
(FIPS PUB) 180-1, "Secure Hash Standard", April 17, Cryptography", Institute of Electrical and Electronics
1995. Engineers, 2000.
[FIPS-186] Federal Information Processing Standards Publication [KEYS] A. Lenstra and E. Verheul, "Selecting Cryptographic Key
(FIPS PUB) 186, "Digital Signature Standard", May 19, Sizes", October 1999. Presented at Public Key Cryptography
1994. Conference, Melbourne, Australia, January 2000. Available
at <http://www.cryptosavvy.com/>.
[NIST-ECC] National Institute for Standards and Technology, [PKIX-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and
"Recommended Elliptic Curves for Federal Government Use", Identifiers for the Internet X.509 Public Key
July 1999, <http://csrc.nist.gov/encryption/NISTReCur.pdf> Infrastructure Certificate and CRL Profile", PKIX Working
Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt,
March 2001.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [PKIX-CERT] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509
Elliptic Curve Cryptography", Version 0.5, September, Public Key Infrastructure Certificate and CRL Profile", PKIX
1999. <http://www.secg.org> Working Group Internet-Draft,
draft-ietf-pkix-new-part1-05.txt, March 2001.
[SEC2] Standards for Efficient Cryptography Group, "SEC 2: [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange",
Recommended Elliptic Curve Domain Parameters", IETF RFC 2409, November 1998.
Version 0.6, October, 1999. <http://www.secg.org>
[ECC-GR] Panjwani, P. and Poeluev, Y., "Additional ECC Groups for [SEC1] SEC 1, "Elliptic Curve Cryptography", Standards for Efficient
IKE", draft-ietf-ipsec-ike-ecc-groups-01.txt. September, Cryptography Group, 2000.
1999.
[RFC 2459] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509 [SEC2] SEC 2, "Recommended Elliptic Curve Domain Parameters",
Public Key Infrastructure: Certificate and CRL Profile", Standards for Efficient Cryptography Group, 2000.
January, 1999.
[EPKIX] Bassham, L., Johnson, D., and Polk, W., "Representation of 8. Author's Address
Elliptic Curve Digital Signature Algorithm (ECDSA) Keys
and Signatures in Internet X.509 Public Key Infrastructure
Certificates", draft-ietf-pkix-ipki-ecdsa-02.txt. October,
1999.
Author's Address Simon Blake-Wilson
Certicom Corp.
sblake-wilson@certicom.com
Paul Fahn Paul Fahn
Certicom Corp. Certicom Corp.
25801 Industrial Blvd. pfahn@certicom.com
Hayward, CA 94545
e-mail: pfahn@certicom.com
Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 44 change blocks. 
119 lines changed or deleted 138 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/