Greetings again. Here is the long-sought-after consensus report from the design
team that was tasked with a proposal for better supporting ECDSA certificates
in IKEv2.
If you have any concern for this topic, please read the proposal below and send
comments to the list.
Thank you to the design team (Tero Kivinen, Johannes Merkle, Dan Harkins, Yoav
Nir, David McGrew) for their efforts.
--Paul Hoffman
The design team decided it is best to add just one new authentication
method, that will support all kinds of signature methods. This
includes all ECDSA and other EC-based methods (ECGDSA) and can also
support other algorithms too (RSA-PSS or even ElGamal).
The EC group is assumed to be known from the certificate or raw key,
and there is no need to explicitly negotiate or identify it.
The Authentication Data field in the Authetication Payload will
contain the signature algorithm OID (sha1WithRSAEncryption,
dsa-with-sha1, dsa-with-sha256, ecdsa-with-SHA1, ecdsa-with-SHA256
etc) and the actual signature.
The design group considered adding full AlgorithmIdentifier ASN.1 blob
too big and as the other information (EC group etc) is already known
from the certificate or raw key, the only thing needed here is the
actual signature algorithm and hash OID. To make skipping the OID
easier it is prefixed with 8-bit length field (even though the ASN.1
encoding of the OID has length of oid value in 2nd byte).
To select suitable hash function for each EC-group we should refer to
the existing guidance (SEC1 and RFC5639), and specify that the method
of X9.62, SEC1 and IO 14888-3 MUST be used for hash truncation. We can
add some non-normative guidance also in the draft for "common" curves.
This new method will be negotiated using the Notify Payloads in the
IKE_SA_INIT, and those same payloads can be used to indicate the
supported hash algoritms.
The old EC-DSA method should be deprecated, but only after the new
methods are supported, meaning the document should say that if new
method is supported by both ends it SHOULD/MUST be used.
----------------------------------------------------------------------
The Authentication Paylod will look like this:
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Authentication Payload Format
o Auth Method (1 octet) - Specifies the method of authentication
used.
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 algoritms 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 different format than in other Authentication
methods (see below).
o Authentication Data (variable length) - see Section 2.15 of
RFC5996. For "Digital Signature" format the Authentication data
contains special format as follows:
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 abow).
----------------------------------------------------------------------
The method is negotiated by sending and receiving
SIGNATURE_HASH_ALGORITHMS Notify payload:
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 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.
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 actual algoritm used when
calculating the signature is sent inside the Authentication Data field
of the Authentication Payload.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
