draft-kivinen-ipsecme-signature-auth-06.txt   draft-kivinen-ipsecme-signature-auth-07.txt 
IP Security Maintenance and Extensions T. Kivinen IP Security Maintenance and Extensions T. Kivinen
(ipsecme) INSIDE Secure (ipsecme) INSIDE Secure
Internet-Draft J. Snyder Internet-Draft J. Snyder
Updates: RFC 5996 (if approved) Opus One Updates: RFC 5996 (if approved) Opus One
Intended status: Standards Track May 7, 2014 Intended status: Standards Track July 21, 2014
Expires: November 8, 2014 Expires: January 22, 2015
Signature Authentication in IKEv2 Signature Authentication in IKEv2
draft-kivinen-ipsecme-signature-auth-06.txt draft-kivinen-ipsecme-signature-auth-07.txt
Abstract Abstract
The Internet Key Exchange Version 2 (IKEv2) protocol has limited The Internet Key Exchange Version 2 (IKEv2) protocol has limited
support for the Elliptic Curve Digital Signature Algorithm (ECDSA). support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
The current version only includes support for three Elliptic Curve The current version only includes support for three Elliptic Curve
groups, and there is a fixed hash algorithm tied to each group. This groups, and there is a fixed hash algorithm tied to each group. This
document generalizes IKEv2 signature support to allow any signature document generalizes IKEv2 signature support to allow any signature
method supported by the PKIX and also adds signature hash algorithm method supported by the PKIX and also adds signature hash algorithm
negotiation. This is a generic mechanism, and is not limited to negotiation. This is a generic mechanism, and is not limited to
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2014. This Internet-Draft will expire on January 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4 3. Authentication Payload . . . . . . . . . . . . . . . . . . . . 4
4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 7 4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 7
5. Selecting the Public Key Algorithm . . . . . . . . . . . . . . 8 5. Selecting the Public Key Algorithm . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 11 Appendix A. Commonly used ASN.1 objects . . . . . . . . . . . . . 12
A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12 A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12
A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12 A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12
A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12 A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 13
A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 12 A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13
A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13 A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13
A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13 A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13
A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 13 A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 14
A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14 A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14
A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14 A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14
A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 14 A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15
A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 14 A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15
A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 15 A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 15
A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 15 A.4.1. RSASSA-PSS with empty parameters . . . . . . . . . . . 15
A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 15 A.4.2. RSASSA-PSS with default parameters . . . . . . . . . . 16
A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 16 A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 16
Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 16 Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . . 17
B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17 B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document adds a new IKEv2 ([RFC5996]) authentication method to This document adds a new IKEv2 ([RFC5996]) authentication method to
support signature methods in a more general way. The current support signature methods in a more general way. The current
signature-based authentication methods in IKEv2 are per-algorithm, signature-based authentication methods in IKEv2 are per-algorithm,
i.e. there is one for RSA digital signatures, one for DSS digital i.e. there is one for RSA digital signatures, one for DSS digital
signatures (using SHA-1) and three for different ECDSA curves, each signatures (using SHA-1) and three for different ECDSA curves, each
tied to exactly one hash algorithm. This design is cumbersome when tied to exactly one hash algorithm. This design is cumbersome when
more signature algorithms, hash algorithms and elliptic curves need more signature algorithms, hash algorithms and elliptic curves need
to be supported: to be supported:
o The RSA digital signature format in IKEv2 is specified to use o In IKEv2, authentication using RSA digital signatures calls for
RSASSA-PKCS1-v1_5 padding, but "Additional Algorithms and padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA_PSS
Identifiers for RSA Cryptography for use in PKIX Profile" padding method is now recommended. (See section 5 of "Additional
([RFC4055])) recommends the use of the newer RSASSA_PSS (See Algorithms and Identifiers for RSA Cryptography for use in PKIX
section 5 of [RFC4055]) instead. Profile" [RFC4055]).
o With ECDSA and DSS there is no way to extract the hash algorithm o With ECDSA and DSS there is no way to extract the hash algorithm
from the signature. Thus, for each new hash function to be from the signature. Thus, for each new hash function to be
supported with ECDSA or DSA, new authentication methods would be supported with ECDSA or DSA, new authentication methods would be
needed. Support for new hash functions is particularly needed for needed. Support for new hash functions is particularly needed for
DSS because the current restriction to SHA-1 limits its security, DSS because the current restriction to SHA-1 limits its security,
meaning there is no point of using long keys with SHA-1. meaning there is no point of using long keys with SHA-1.
o The tying of ECDSA authentication methods to particular elliptic o The tying of ECDSA authentication methods to particular elliptic
curve groups requires definition of additional methods for each curve groups requires definition of additional methods for each
new group. The combination of new ECDSA groups and hash functions new group. The combination of new ECDSA groups and hash functions
will cause the number of required authentication methods to become will cause the number of required authentication methods to become
skipping to change at page 9, line 12 skipping to change at page 9, line 12
combined with table 3 gives recommendations for how to select combined with table 3 gives recommendations for how to select
suitable hash functions for the signature. suitable hash functions for the signature.
This new digital signature method does not tie the Elliptic Curve to This new digital signature method does not tie the Elliptic Curve to
a specific hash function, which was done in the old IKEv2 ECDSA a specific hash function, which was done in the old IKEv2 ECDSA
methods. This means it is possible to mix different security levels. methods. This means it is possible to mix different security levels.
For example, it is possible to use 512-bit Elliptic Curve with SHA1. For example, it is possible to use 512-bit Elliptic Curve with SHA1.
This means that the security of the authentication method is the This means that the security of the authentication method is the
security of the weakest component (signature algorithm, hash security of the weakest component (signature algorithm, hash
algorithm, or curve). This complicates the security analysis of the algorithm, or curve). This complicates the security analysis of the
system. Note that this kind of mixing of security levels can be system.
disallowed by policy.
IKEv2 peers have a series of policy databases (see [RFC4301] section
4.4 "Major IPsec Databases") that define which security algorithms
and methods should be used during establishment of security
associations. To help end-users select the desired security levels
for communications protected by IPsec, implementers may wish to
provide a mechanism in the IKE policy databases to limit the mixing
of security levels or to restrict combinations of protocols.
Security downgrade attacks, where more secure methods are deleted or
modified from a payload by a Man-in-the-Middle to force lower levels
of security, are not a significant concern in IKEv2 Authentication
Payloads as discussed in this RFC. This is because a modified AUTH
payload will be detected when the peer computes a signature over the
IKE messages.
One specific class of downgrade attacks requires selection of
catastrophically weak ciphers. In this type of attack, the Man-in-
the-Middle attacker is able to "break" the cryptography in real time.
This type of downgrade attack should be blocked by policy regarding
cipher algorithm selection, as discussed above.
The hash algorithm registry does not include MD5 as a supported hash The hash algorithm registry does not include MD5 as a supported hash
algorithm, as it is not considered safe enough for signature use algorithm, as it is not considered safe enough for signature use
([WY05]). ([WY05]).
The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known
security vulnerabilities ([KA08], [ME01]) and does not allow using security vulnerabilities ([KA08], [ME01]) and does not allow using
newer padding methods such as RSASSA-PSS. The new method described newer padding methods such as RSASSA-PSS. The new method described
in this RFC allows using other padding methods. in this RFC allows using other padding methods.
skipping to change at page 11, line 20 skipping to change at page 11, line 42
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005. June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009. Information", RFC 5480, March 2009.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure: Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA", Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, January 2010. RFC 5758, January 2010.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
skipping to change at page 15, line 7 skipping to change at page 15, line 33
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
Parameters are absent. Parameters are absent.
Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4 Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
Length = 12 Length = 12
0000: 300a 0608 2a86 48ce 3d04 0304 0000: 300a 0608 2a86 48ce 3d04 0304
A.4. RSASSA-PSS A.4. RSASSA-PSS
With RSASSA-PSS, the algorithm object identifier is always id-RSASSA- With RSASSA-PSS, the algorithm object identifier must always be id-
PSS, but the hash function is taken from the optional parameters, and RSASSA-PSS, and the hash function and padding parameters are conveyed
is required. See [RFC4055] for more information. in the parameters (which are not optional in this case). See
[RFC4055] for more information.
A.4.1. RSASSA-PSS with empty parameters A.4.1. RSASSA-PSS with empty parameters
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Parameters are empty, but the ASN.1 part of the sequence must be Parameters are empty, but the ASN.1 part of the sequence must be
there. This means default parameters are used (same as the next present. This means default parameters are used.
example).
0000 : SEQUENCE 0000 : SEQUENCE
0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000d : SEQUENCE 000d : SEQUENCE
Length = 15 Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
A.4.2. RSASSA-PSS with default parameters A.4.2. RSASSA-PSS with default parameters
 End of changes. 15 change blocks. 
27 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/