One document matched: draft-kivinen-ipsecme-signature-auth-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3447 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.xml'>
<!ENTITY rfc4055 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml'>
<!ENTITY rfc3279 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3279.xml'>
<!ENTITY rfc5280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY rfc5480 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml'>
<!ENTITY rfc5758 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5758.xml'>
<!ENTITY rfc5996 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
<!ENTITY rfc5912 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5912.xml'>
<!ENTITY x690 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml2/reference.CCITT.X690.2002.xml'>
]>
<rfc category='std' ipr='trust200902' updates='RFC 5996'
docName='draft-kivinen-ipsecme-signature-auth-06.txt'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc compact='yes' ?>
<?rfc strict='yes' ?>
<front>
<title>Signature Authentication in IKEv2</title>
<author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
<organization>INSIDE Secure</organization>
<address>
<postal>
<street>Eerikinkatu 28</street>
<code>FI-00180</code>
<city>HELSINKI</city>
<country>FI</country>
</postal>
<email>kivinen@iki.fi</email>
</address>
</author>
<author initials='J.' surname='Snyder' fullname='Joel Snyder'>
<organization>Opus One</organization>
<address>
<postal>
<street>1404 East Lind Road</street>
<code>85719</code>
<city>Tucson</city>
<region>AZ</region>
</postal>
<phone>+1 520 324 0494</phone>
<email>jms@opus1.com</email>
</address>
</author>
<date month='May' year='2014' />
<area>Security</area>
<workgroup>IP Security Maintenance and Extensions
(ipsecme)</workgroup>
<abstract>
<t>The Internet Key Exchange Version 2 (IKEv2) protocol has
limited support for the Elliptic Curve Digital Signature
Algorithm (ECDSA). The current version only includes
support for three Elliptic Curve groups, and there is a
fixed hash algorithm tied to each group. This document
generalizes IKEv2 signature support to allow any signature
method supported by the PKIX and also adds signature hash
algorithm negotiation. This is a generic mechanism, and is
not limited to ECDSA, but can also be used with other
signature algorithms.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>This document adds a new IKEv2 (<xref target='RFC5996'/>)
authentication method to support signature methods in a more
general way. The current signature-based authentication methods in
IKEv2 are per-algorithm, i.e. there is one for RSA digital
signatures, one for DSS digital signatures (using SHA-1) and three
for different ECDSA curves, each tied to exactly one hash
algorithm. This design is cumbersome when more signature
algorithms, hash algorithms and elliptic curves need to be
supported:</t>
<t><list style='symbols'>
<t>The RSA digital signature format in IKEv2 is specified
to use RSASSA-PKCS1-v1_5 padding, but "Additional
Algorithms and Identifiers for RSA Cryptography for use
in PKIX Profile" (<xref target="RFC4055"/>)) recommends
the use of the newer RSASSA_PSS (See section 5 of <xref
target="RFC4055"/>) instead.</t>
<t>With ECDSA and DSS there is no way to extract the hash
algorithm from the signature. Thus, for each new hash function
to be supported with ECDSA or DSA, new authentication methods
would be needed. Support for new hash functions is particularly
needed for DSS because the current restriction to SHA-1 limits
its security, meaning there is no point of using long keys with
SHA-1.</t>
<t>The tying of ECDSA authentication methods to particular
elliptic curve groups requires definition of additional methods
for each new group. The combination of new ECDSA groups and hash
functions will cause the number of required authentication
methods to become unmanageable. Furthermore, the restriction of
ECDSA authentication to a specific group is inconsistent with
the approach taken with DSS.</t>
</list></t>
<t>With the selection of SHA-3, it might be possible that a
signature method can be used with either SHA-3 or SHA-2.
This means that a new mechanism for negotiating the hash
algorithm for a signature algorithm is needed.</t>
<t>This document specifies two things:</t>
<t><list style='numbers'>
<t>A new authentication method which includes enough
information inside the Authentication payload data so
that the signature hash algorithm can be extracted (see
<xref target="authpayload"/>).</t>
<t>A method to indicate supported signature hash algorithms (see
<xref target="notify"/>). This allows the peer to know which
hash algorithms are supported by the other end and use one of
them (provided one is allowed by policy). There is no
requirement to actually negotiate one common hash algorithm, as
different hash algorithms can be used in different directions if
needed.</t>
</list></t>
<t>The new digital signature method is flexible enough to
include all current signature methods (RSA, DSA, ECDSA,
RSASSA-PSS, etc.), and add new methods (ECGDSA, ElGamal,
etc.) in the future. To support this flexibility, the
signature algorithm is specified in the same way that PKIX
(<xref target="RFC5280"/>) specifies the signature of the
Digital Certificate, by placing a simple ASN.1 object
before the actual signature data. This ASN.1 object
contains an OID specifying the algorithm and associated
parameters. When an IKEv2 implementation supports a fixed
set of signature methods with commonly used parameters, it
is acceptable for the implementation to treat the ASN.1
object as a binary blob which can be compared against the
fixed set of known values. IKEv2 implementations can also
parse the ASN.1 and extract the signature algorithm and
associated parameters.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target='RFC2119'/>.</t>
</section>
<section title="Authentication Payload" anchor="authpayload">
<t>This document specifies a new "Digital Signature"
authentication method. This method can be used with any
type of signature. As the authentication methods are not
negotiated in IKEv2, the peer is only allowed to use this
authentication method if the Notify payload of type
SIGNATURE_HASH_ALGORITHMS has been sent and received by
each peer.</t>
<t>In this authentication method, the Authentication Data
field inside the Authentication Payload does not just
include the signature value, as do other existing IKEv2
Authentication Payloads. Instead, the signature value is
prefixed with an ASN.1 object indicating the algorithm used
to generate the signature. The ASN.1 object contains the
algorithm identification OID, which identifies both the
signature algorithm and the hash used when calculating the
signature. In addition to the OID, the ASN.1 object can
contain optional parameters which might be needed for
algorithms such as RSASSA-PSS (Section 8.1 of <xref
target="RFC3447"/>).</t>
<t>To make implementations easier, the ASN.1 object is prefixed by
the 8-bit length field. This length field allows simple
implementations to know the length of the ASN.1 object without the
need to parse it, so they can use it as a binary blob to be
compared against known signature algorithm ASN.1 objects. Thus,
simple implementations may not need to be able to parse or
generate ASN.1 objects. See <xref target='asn1objects'/> for
commonly used ASN.1 objects.</t>
<t>The ASN.1 used here is the same ASN.1 used in the
AlgorithmIdentifier of PKIX (Section 4.1.1.2 of <xref
target="RFC5280"/>), encoded using distinguished encoding
rules (DER) <xref target="CCITT.X690.2002" />. The
algorithm OID inside the ASN.1 specifies the signature
algorithm and the hash function, both of which are needed
for signature verification.</t>
<t>Currently, only the RSASSA-PSS signature algorithm uses
the optional parameters. For other signature algorithms,
the parameters are either NULL or missing. Note, that for
some algorithms there are two possible ASN.1 encodings, one
with optional parameters included but set to NULL and the
other where the optional parameters are omitted. These dual
encodings exist because of the way those algorithms are
specified. When encoding the ASN.1, implementations SHOULD
use the preferred format called for by the algorithm
specification. If the algorithm specification says
"preferredPresent" then the parameters object needs to be
present, although it will be NULL if no parameters are
specified. If the algorithm specification says
"preferredAbsent", then the entire optional parameters
object is missing.</t>
<t>The Authentication payload is defined in IKEv2 as follows:</t>
<figure anchor="payload" title="Authentication Payload Format." ><artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style='symbols'>
<t>Auth Method (1 octet) - Specifies the method of
authentication used.
<figure><artwork><![CDATA[
Mechanism Value
-----------------------------------------------------------------
Digital Signature <TBD>
Computed as specified in Section 2.15 of RFC5996 using a
private key associated with the public key sent in the
Certificate payload, and using one of the hash algorithms
sent by the other end in the Notify payload of type
SIGNATURE_HASH_ALGORITHMS. If both ends send and receive
SIGNATURE_HASH_ALGORITHMS Notify payloads and signature
authentication is to be used, then the authentication
method specified in this Authentication payload MUST be
used. The format of the Authentication Data field is
different from other Authentication methods and is
specified below.
]]></artwork></figure></t>
<t>Authentication Data (variable length) - see Section 2.15 of
RFC5996. For "Digital Signature" format, the Authentication data
is formatted as follows:
<figure anchor="authdata" title="Authentication Data Format." ><artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ AlgorithmIdentifier ASN.1 object continuing ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style='symbols'>
<t>ASN.1 Length (1 octet) - This field contains the length of
the ASN.1 encoded AlgorithmIdentifier object.</t>
<t>Algorithm Identifier (variable length) - This field contains
the AlgorithmIdentifier ASN.1 object.</t>
<t>Signature Value (variable length) - This field contains the
actual signature value.</t>
</list>
There is no padding between ASN.1 object and signature value.
For hash truncation, the method specified in ANSI X9.62:2005
(<xref target="X9.62"/>) MUST be used.
</t>
</list></t>
</section>
<section title="Hash Algorithm Notification" anchor="notify">
<t>The supported hash algorithms that can be used for the
signature algorithms are indicated with a Notify payload of type
SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT
exchange.</t>
<t>This notification also implicitly indicates support of the new
"Digital Signature" algorithm method, as well as the list of hash
functions supported by the sending peer.</t>
<t>Both ends send their list of supported hash algorithms. When
calculating the digital signature, a peer MUST pick one algorithm
sent by the other peer. Note that different algorithms can be used
in different directions. The algorithm OID indicating the selected
hash algorithm (and signature algorithm) used when calculating the
signature is sent inside the Authentication Data field of the
Authentication payload (with Auth Method of "Digital Signature" as
defined above).</t>
<figure anchor="notifypayload" title="Notify Payload Format." ><artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The Notify payload format is defined in RFC5996 section
3.10. When a Notify payload of type
SIGNATURE_HASH_ALGORITHMS is sent, the Protocol ID field is
set to 0, the SPI Size is set to 0, and the Notify Message
Type is set to <TBD from status types>. </t>
<t>The Notification Data field contains the list of 16-bit hash
algorithm identifiers from the Hash Algorithm Identifiers for the
IKEv2 IANA registry. There is no padding between the hash
algorithm identifiers.</t>
</section>
<section title='Selecting the Public Key Algorithm'>
<t>This specification does not provide a way for the peers
to indicate the public / private key pair types they have.
This raises the question of how the responder selects a
public / private key pair type that the initiator supports.
This information can be found by several methods.</t>
<t>One method to signal the key the initiator wants the responder
to use is to indicate that in the IDr payload of the IKE_AUTH
request sent by the initiator. In this case, the initiator
indicates that it wants the responder to use a particular public /
private key pair by sending an IDr payload which indicates that
information. In this case, the responder has different identities
configured, with each of those identities associated to a public /
private key or key type.</t>
<t>Another method to ascertain the key the initiator wants the
responder to use is through a Certificate Request payload sent by
the initiator. For example, the initiator could indicate in the
Certificate Request payload that it trusts a CA signed by an ECDSA
key. This indication implies that the initiator can process ECDSA
signatures, which means that the responder can safely use ECDSA
keys when authenticating.</t>
<t>A third method is for the responder to check the key
type used by the initiator, and use same key type that the
initiator used. This method does not work if the initiator
is using shared secret or EAP authentication (i.e., is not
using public keys). If the initiator is using public key
authentication, this method is the best way for the
responder to ascertain the type of key the initiator
supports.</t>
<t>If the initiator uses a public key type that the responder does
not support, the responder replies with a Notify message with
error type AUTHENTICATION_FAILED. If the initiator has multiple
different keys, it may try a different key (and perhaps a
different key type) until it finds a key that the other end
accepts. The initiator can also use the Certificate Request
payload sent by the responder to help decide which public key
should be tried. In normal cases, when the initiator has multiple
public keys, out-of-band configuration is used to select a public
key for each connection.</t>
</section>
<section title='Security Considerations'>
<t>The "Recommendations for Key Management" (<xref
target='NIST800-57'/>) table 2 combined with table 3 gives
recommendations for how to select suitable hash functions for the
signature.</t>
<t>This new digital signature method does not tie the
Elliptic Curve to a specific hash function, which was done
in the old IKEv2 ECDSA methods. This means it is possible
to mix different security levels. For example, it is
possible to use 512-bit Elliptic Curve with SHA1. This
means that the security of the authentication method is the
security of the weakest component (signature algorithm,
hash algorithm, or curve). This complicates the security
analysis of the system. Note that this kind of mixing of
security levels can be disallowed by policy.</t>
<t>The hash algorithm registry does not include MD5 as a supported
hash algorithm, as it is not considered safe enough for signature
use (<xref target='WY05'/>).</t>
<t>The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has
known security vulnerabilities (<xref target='KA08'/>, <xref
target="ME01"/>) and does not allow using newer padding methods
such as RSASSA-PSS. The new method described in this RFC allows
using other padding methods.</t>
<t>The current IKEv2 protocol only allows use of normal DSA
with SHA-1, which means the security of the authentication
is limited to the security of SHA-1. This new method allows
using longer keys and longer hashes with DSA.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>This document creates a new IANA registry for IKEv2 Hash
Algorithms. Changes and additions to this registry are by expert
review.</t>
<t>The initial values of this registry are:</t>
<figure><artwork><![CDATA[
Hash Algorithm Value
-------------- -----
RESERVED 0
SHA1 1
SHA2-256 2
SHA2-384 3
SHA2-512 4
]]></artwork></figure>
<t>MD5 is not included in the hash algorithm list as it is not
considered safe enough for signature hash uses.</t>
<t>Values 5-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties.</t>
<t>This specification also adds one new "IKEv2 Notify Message
Types - Status Types" value for SIGNATURE_HASH_ALGORITHMS, and
adds one new "IKEv2 Authentication Method" value for "Digital
Signature".</t>
</section>
<section title='Acknowledgements'>
<t>Most of this work was based on the work done in the IPsecME
design team for the ECDSA. The design team members were: Dan
Harkins, Johannes Merkle, Tero Kivinen, David McGrew, and Yoav
Nir.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5280;
&rfc5996;
</references>
<references title='Informative References'>
&rfc3279;
&rfc3447;
&rfc4055;
&rfc5480;
&rfc5758;
&rfc5912;
<reference anchor='WY05'>
<front>
<title>How to break MD5 and other hash functions</title>
<author initials='X.' surname='Wang'><organization/></author>
<author initials='H.' surname='Yu'><organization/></author>
<date year='2005'/>
</front>
<seriesInfo name='Proceedings of EuroCrypt 2005, Lecture Notes in Computer Science' value='Vol. 3494'/>
</reference>
<reference anchor='KA08'>
<front>
<title>Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures</title>
<author initials='U.' surname='Kühn'><organization/></author>
<author initials='A.' surname='Pyshkin'><organization/></author>
<author initials='E.' surname='Tews'><organization/></author>
<author initials='R.' surname='Weinmann'><organization/></author>
</front>
<seriesInfo name='Proc. Sicherheit 2008' value='pp.97-109'/>
</reference>
<reference anchor="NIST800-57">
<front>
<title>Recommendations for Key Management</title>
<author initials="E." surname="Barker"><organization/></author>
<author initials="W." surname="Barker"><organization/></author>
<author initials="W." surname="Burr"><organization/></author>
<author initials="W." surname="Polk"><organization/></author>
<author initials="M." surname="Smid"><organization/></author>
<date month="March" year="2007"/>
</front>
<seriesInfo name="NIST SP" value="800-57"/>
</reference>
<reference anchor="X9.62">
<front>
<title>Public Key Cryptography for the Financial
Services Industry: The Elliptic Curve Digital Signature
Algorithm (ECDSA)</title>
<author>
<organization>American National Standards
Institute</organization>
</author>
<date month="November" year="2005"/>
</front>
<seriesInfo name="ANSI" value="X9.62"/>
</reference>
&x690;
<reference anchor="ME01">
<front>
<title>Evaluation of Security Level of Cryptography: RSA-OAEP,
RSA-PSS, RSA Signature</title>
<author initials="A." surname="Menezes">
<organization>University of Waterloo</organization></author>
<date month="December" year="2001"/>
</front>
</reference>
</references>
<section title='Commonly used ASN.1 objects' anchor='asn1objects'>
<t>This section lists commonly used ASN.1 objects in binary
form. This section is not normative, and these values
should only be used as examples. If the ASN.1 object listed
in Appendix A and the ASN.1 object specified by the
algorithm differ, then the algorithm specification must be
used. These values are taken from "New ASN.1 Modules for
the Public Key Infrastructure Using X.509 (PKIX)" (<xref
target='RFC5912' />).</t>
<section title='PKCS#1 1.5 RSA Encryption'>
<t>The algorithm identifiers here include several
different ASN.1 objects with different hash algorithms.
This document only includes the commonly used ones, i.e.
the ones using SHA-1 or SHA-2 as hash function. Some
other algorithms (such as MD2 and MD5) are not safe
enough to be used as signature hash algorithms, and are
omitted. The IANA registry does not have code points for
these other algorithms with RSA Encryption. Note that
there are no optional parameters in any of these
algorithm identifiers, but all included here need NULL
optional parameters present in the ASN.1.</t>
<t>See "Algorithms and Identifiers for PKIX Profile" (<xref
target='RFC3279'/>) and "Additional Algorithms and Identifiers
for RSA Cryptography for use in PKIX Profile" (<xref
target='RFC4055'/>) for more information.</t>
<section title='sha1WithRSAEncryption'>
<t>sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0505 00
]]></artwork></figure>
</section>
<section title='sha256WithRSAEncryption'>
<t>sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0b05 00
]]></artwork></figure>
</section>
<section title='sha384WithRSAEncryption'>
<t>sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0c05 00
]]></artwork></figure>
</section>
<section title='sha512WithRSAEncryption'>
<t>sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }</t>
<t>Parameters are required, and they must be NULL.</t>
<figure><artwork><![CDATA[
Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0d05 00
]]></artwork></figure>
</section>
</section>
<section title='DSA'>
<t>With DSA algorithms, optional parameters are always omitted.
Only algorithm combinations for DSA listed in the IANA registry
are included.</t>
<t>See "Algorithms and Identifiers for PKIX Profile" (<xref
target='RFC3279'/>) and "PKIX Additional Algorithms and
Identifiers for DSA and ECDSA" (<xref target='RFC5758'/> for
more information.</t>
<section title='dsa-with-sha1'>
<t>dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = dsa-with-sha1, oid = 1.2.840.10040.4.3
Length = 11
0000: 3009 0607 2a86 48ce 3804 03
]]></artwork></figure>
</section>
<section title='dsa-with-sha256'>
<t>dsa-with-sha256 OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) algorithms(4) id-dsa-with-sha2(3) 2 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2
Length = 13
0000: 300b 0609 6086 4801 6503 0403 02
]]></artwork></figure>
</section>
</section>
<section title='ECDSA'>
<t>With ECDSA algorithms, the optional parameters are always
omitted. Only algorithm combinations for ECDSA listed in the
IANA registry are included.</t>
<t>See "Elliptic Curve Cryptography Subject Public Key
Information" (<xref target='RFC5480'/>), "Algorithms and
Identifiers for PKIX Profile" (<xref target='RFC3279'/>) and
"PKIX Additional Algorithms and Identifiers for DSA and ECDSA"
(<xref target='RFC5758'/> for more information.</t>
<section title='ecdsa-with-sha1'>
<t>ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045)
signatures(4) 1 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1
Length = 11
0000: 3009 0607 2a86 48ce 3d04 01
]]></artwork></figure>
</section>
<section title='ecdsa-with-sha256'>
<t>ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2
Length = 12
0000: 300a 0608 2a86 48ce 3d04 0302
]]></artwork></figure>
</section>
<section title='ecdsa-with-sha384'>
<t>ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 3 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3
Length = 12
0000: 300a 0608 2a86 48ce 3d04 0303
]]></artwork></figure>
</section>
<section title='ecdsa-with-sha512'>
<t>ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 4 }</t>
<t>Parameters are absent.</t>
<figure><artwork><![CDATA[
Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
Length = 12
0000: 300a 0608 2a86 48ce 3d04 0304
]]></artwork></figure>
</section>
</section>
<section title='RSASSA-PSS'>
<t>With RSASSA-PSS, the algorithm object identifier is always
id-RSASSA-PSS, but the hash function is taken from the optional
parameters, and is required. See <xref target="RFC4055"/> for
more information.</t>
<section title='RSASSA-PSS with empty parameters'>
<t>id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }</t>
<t>Parameters are empty, but the ASN.1 part of the sequence
must be there. This means default parameters are used (same as
the next example).</t>
<figure><artwork><![CDATA[
0000 : SEQUENCE
0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000d : SEQUENCE
]]></artwork></figure>
<figure><artwork><![CDATA[
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
]]></artwork></figure>
</section>
<section title='RSASSA-PSS with default parameters'>
<t>id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }</t>
<t>Here the parameters are present, and contain the default
parameters, i.e. hashAlgorithm of SHA-1, maskGenAlgorithm of
mgf1SHA1, saltLength of 20, trailerField of 1.</t>
<figure><artwork><![CDATA[
0000 : SEQUENCE
0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000d : SEQUENCE
000f : CONTEXT 0
0011 : SEQUENCE
0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26)
001a : NULL
001c : CONTEXT 1
001e : SEQUENCE
0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
002b : SEQUENCE
002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26)
0034 : NULL
0036 : CONTEXT 2
0038 : INTEGER 0x14 (5 bits)
003b : CONTEXT 3
003d : INTEGER 0x1 (1 bits)
]]></artwork></figure>
<figure><artwork><![CDATA[
Name = RSASSA-PSS with default parameters,
oid = 1.2.840.113549.1.1.10
Length = 64
0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
]]></artwork></figure>
</section>
<section title='RSASSA-PSS with SHA-256'>
<t>id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }</t>
<t>Here the parameters are present, and contain hashAlgorithm
of SHA-256, maskGenAlgorithm of SHA-256, saltLength of 32,
trailerField of 1.</t>
<figure><artwork><![CDATA[
0000 : SEQUENCE
0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000d : SEQUENCE
000f : CONTEXT 0
0011 : SEQUENCE
0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
001e : NULL
0020 : CONTEXT 1
0022 : SEQUENCE
0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
002f : SEQUENCE
0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
003c : NULL
003e : CONTEXT 2
0040 : INTEGER 0x20 (6 bits)
0043 : CONTEXT 3
0045 : INTEGER 0x1 (1 bits)
]]></artwork></figure>
<figure><artwork><![CDATA[
Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
Length = 72
0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
0030: 0d06 0960 8648 0165 0304 0201 0500 a203
0040: 0201 20a3 0302 0101
]]></artwork></figure>
</section>
</section>
</section>
<section title='IKEv2 Payload Example'>
<section title='sha1WithRSAEncryption'>
<t>The IKEv2 AUTH payload would start like this:</t>
<figure><artwork><![CDATA[
00000000: NN00 00LL XX00 0000 0f30 0d06 092a 8648
00000010: 86f7 0d01 0105 0500 ....
]]></artwork></figure>
<t>Where the NN will be the next payload type (i.e. the value
depends on the next payload after this Authentication payload),
the LL will be the length of this payload, and after the
sha1WithRSAEncryption ASN.1 block (15 bytes) there will be the
actual signature, which is omitted here.</t>
<t>Note to the RFC editor / IANA, replace the XX above with the
newly allocated authentication method type for Digital
Signature, and remove this note.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:01:57 |