One document matched: draft-kivinen-ipsecme-signature-auth-00.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 rfc4055 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.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 rfc5996 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
]>
<rfc category='std' ipr='trust200902' updates='RFC 5996'
docName='draft-kivinen-ipsecme-signature-auth-00.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>
<date month='December' year='2012' />
<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 support only includes support for
three Elliptic Curve groups, and there is fixed hash algorithm
tied to each curve. This document generalizes the IKEv2 signature
support so it can support any signature method supported by the
PKIX and also adds signature hash algorithm negotiation. This
generic mechanism 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 support for new IKEv2 (<xref
target='RFC5996'/>) authentication method to support all kinds of
signature methods. The current signature based authentication
methods in the 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 starts to be cumbersome when more
ECDSA groups are added, as each of them would require new
authentication method and as with ECDSA there is no way to
extract the hash algorithm from the signature, each ECDSA
algorithm would need to come with fixed hash algorithm tied to
it.</t>
<t>With the SHA-3 definitions coming out, it is seen that it
might be possible that in the future the signature methods are
used with SHA-3 also, not only SHA-2. This means new mechanism
for negotiating the hash algorithm for the signature algorithms
is needed.</t>
<t>The RSA Digital Signatures format in the IKEv2 is specified to
use RSASSA-PKCS1-v1_5, but there has been some discussions that
newer padding methods should also be possible (See section 5 of
<xref target="RFC4055"/>). The DSS Digital Signatures format in
the IKEv2 is specified to always use SHA-1, which limits the
security of that, meaning there is no point of using long keys
with it.</t>
<t>This documents specifies two things, one is one new
authentication method, which includes the enough information
inside the Authentication payload data that the signature hash
algorithm can be extracted from there (see <xref
target="authpayload"/>). The another thing is to add indication
of supported signature hash algorithms by the peer (see <xref
target="notify"/>). This allows 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 need to actually
negotiate one common hash algorithm, as different hash algorithms
can be used in different directions if needed.</t>
<t>The new digital signature method needs to be flexible enough
to include all current signature methods (ECDSA, ECGDSA,
RSASSA-PSS, ElGamal, etc), and also allow adding new things in
the future. For this the signature algorithm is specified by and
OID which specifies both the signature and hash algorithms (i.e.
sha1WithRSAEncryption, dsa-with-sha1, dsa-with-sha256,
ecdsa-with-SHA1, ecdsa-with-SHA256 etc), meaning any signature
and hash algorithm specified by an OID can be used.</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 new "Digital Signature" authentication
method. This method can be used with any types of signatures. As
the authentication methods are not negotiated in the IKEv2, the
peer is only allowed to use this authentication method if the
SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and
received.</t>
<t>In this newly defined authentication method, the
Authentication Data field inside the Authentication Payload does
not include only the signature value, but instead the signature
value is prefixed with the algorithm identification OID. This OID
identifies both the signature algorithm and the hash used when
calculating the signature. To make implementations easier, the
OID is prefixed by the 8-bit length field. This length field
allows simple implementations to be able to know the length of
the OID, so they can use it as binary blob which is compared
against the known OIDs, i.e. they do not need to be able to parse
or generate ASN.1 DER OIDs (Note, that the 2nd byte of the ASN.1
DER OID, also includes the length, but adding it outside makes
things bit easier for implementors).</t>
<t>The OIDs used here are the same OIDs which are used inside the
AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of <xref
target="RFC5280"/>), but only the algorithm OID is included, no
parameters etc. The EC curve is always known by the peer because
it needs to have the certificate or the public key of the other
end before it can do signature verification and public key
specifies the curve.</t>
<t><list><t>XXX While reading RFC4055, it seemed that the OID is
not enough to specify the hash function used for the RSASSA-PSS,
i.e. it seems that we would need to include full
AlgorithmIdentifier ASN object, as it includes also the
parameters, and the hash function is specified in the parameters.
Is my reading of RFC4055 correct? XXX</t></list></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 certificate
payload, and using one of the hash algorithms sent by the other
end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both
ends send and receive SIGNATURE_HASH_ALGORITHMS and signature
authentication is to be used, then this method MUST be used.
The Authentication Data field has bit different format than in
other Authentication methods (see below).
]]></artwork></figure></t>
<t>Authentication Data (variable length) - see Section 2.15 of
RFC5996. For "Digital Signature" format the Authentication data
contains special format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID Length | OID (0x06) . OID value len . OID value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ OID value continuing ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
Where the OID Length is the length of the ASN.1 encoded OID
value, and after that is the actual Signature Algorithm OID
followed by the actual signature value. There is no padding
between OID and signature value. ASN.1 encoded OIDs always start
with byte of 0x06 followed by the length of the actual OID value
(which is shown in the figure above).
For the hash truncation the method of X9.62, SEC1 and IO 14888-3
MUST be used.
XXX Need reference for X9.62/SEC1 etchere XXX.</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 now indicated with new
SIGNATURE_HASH_ALGORITHMS Notification Payload sent inside the
IKE_SA_INIT exchange. This notification also indicates the
support of the new signature algorithm method, i.e sending this
notification tells that new "Digital Signature" authentication
method is supported and that following hash functions are
supported by sending peer. Both ends sends their list of
supported hash-algorithms and when calculating 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 matching selected hash algorithm (and signature
algorithm) used when calculating the signature is sent inside the
Authentication Data field of the Authentication Payload.</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>Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD
from status types>. The Notification Data value contains list
of 16-bit hash algorithm identifiers from the newly created Hash
Algorithm Identifiers for the IKEv2 IANA registry.</t>
</section>
<section title='Security Considerations'>
<t><list><t>XXX The text about the guidance how to select
suitable hash functions is missing here. XXX</t></list></t>
<t>This new digital signature method does not tie the EC curve to
the specific hash function, which was done in the old IKEv2 ECDSA
methods. This means it is possible to use 512-bit EC curve with
SHA1, i.e. this allows mixing different security levels. This
means that the security of the authentication method is the
security of the weakest of components (signature algorithm, hash
algorithm, curve). This might make the security analysis of the
system bit more complex. Note, that this kind of mixing of the
security can be disallowed by the policy.</t>
<t>The hash algorithm registry does not include MD5 as supported
hash algorithm, as it is not considered safe enough for signature
use.</t>
<t><list><t>XXX Need reference for MD5 considered unsafe.
XXX</t></list></t>
<t>The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow
using newer padding methods like RSASSA-PSS. This new method
allows using other padding methods.</t>
<t><list><t>XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5
security. XXX</t></list></t>
<t>The current IKEv2 only allows using normal DSA with SHA-1,
which means the security of the regular DSA is limited to the
security of SHA-1. This new methods allows using longer keys and
longer hashes with DSA.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>This document creates new IANA registry for IKEv2 Hash
Algorithms. Changes and additions to this registry is by expert
review.</t>
<t>The initial values of this registry is:</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 to 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>
</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
Harking, 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'>
&rfc4055;
&rfc5480;
</references>
<section title='Examples'>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:02:46 |