On 11/2/12 2:27 PM, Paul Hoffman wrote:
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.
I'd like to echo the thanks.
--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.
For the certificate case, I assume this means the draft will follow
what's in the RFC 5480 wrt the SPKI AlgorithmIdentifier - i.e., the
curve is always named by the OID.
Aside: For RSA-PSS parameters don't always appear in the SPKI
AlgorithmIdentifier field - see RFC 5756.
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.
RFC 5480 which has some recommendations about this topic and is probably
a better reference than RFC 5639 (one is IETF stream one is ISE stream).
It's basically the same recommendations, but RFC 5480 narrows the
curve/hash algorithm recommendations more. I want to avoid as many
downrefs as possible.
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.
A new registry I assume? (yep after reading farther down it's listed).
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.
Make sure the draft indicates it updates RFC 5996.
In the examples above, *WithRSAEncryption and dsa-with-* are listed so
are we really talking about deprecating all of the previous "signature"
values from the IANA registry:
V Alg Ref
--------------------------------------------------
1 RSA Digital Signature [RFC5996]
3 DSS Digital Signature [RFC5996]
9 ECDSA with SHA-256 on the P-256 curve [RFC4754]
10 ECDSA with SHA-384 on the P-384 curve [RFC4754]
11 ECDSA with SHA-512 on the P-521 curve [RFC4754]
----------------------------------------------------------------------
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.
Assuming here that this new notify is normally sent during the
IKE_SA_INIT exchange from the responder to the initiator:
a) The initiator actually figures out the signature algorithms supported
by the responder based on the new Notify message, Alg ID parameter, and
the cert's key usage extension? The SPKI will include id-ecPublicKey
not ecdsa-with-* right so you can't rely on that. You can't rely on
just the Alg ID parameter because the key usage extension can have any
combination of digitalSignature, nonRepudiation, and keyAgreement set.
So don't you have to look at all three?
Note: This approach ought to work for DSA to because they indicate the
id-dsa and you'll also have the new hash value. RSA is going to have
the same problem as EC algs though because the parameters are NULL and
the key usage might just be set to keyTransport.
b) I guess the question I have is whether inclusion of this notify means
that the entity only supports the new way? That is in the above is it:
Sending this notification tells that new "Digital Signature"
authentication method is supported and that following hash function are
supported by sending peer.
or
Sending this notification tells that new "Digital Signature"
authentication method is *also* supported and that following hash
functions are supported by sending peer.
If the initiator doesn't support it, then it just fails straight off?
How would we transition?
spt
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
