Dan Harkins writes:
> >> How does one currently indicate the hash algorithm used for non-EC DSA
> >> in IKEv2 today?
> >
> > Same way than IKEv1 does it, meaning it is assumed to be SHA-1.
>
> OK, so you're admitting that there's a problem with non-EC DSA in
> IKEv2. Good, I agree. I would say the inability for IKEv2 to construct
> a signature that is valid today according to FIPS 186-3 is a problem
> and we should address it.
Yes, and no. I agree there is spefication problem as the RFC5996 says
SHA-1, when it should not say anything about has algorithm and left
that to the FIPS 186-3.
I would expect most implementations which support longer non-EC DSA
keys than what SHA-1 is enough for, most likely already do use SHA-2
for those regardless what RFC5996 says (i.e. they uses fips
specification as more authorative when selecting the hash algorithm
than the example in the RFC5996).
I do agree we should solve this now.
> The domain parameter comes from the CERT payload not the AUTH
> payload. In any event there's 1 bunch of 8 RESERVED bits and then on the
> next aligned ulong there's another 24, that's 32 available but disjoint
> bits. How do you propose encoding an OID into the AUTH payload?
----------------------------------------------------------------------
Using following payload format:
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and adding new auth method Generic DSA and say that the authentication
data field of the auth payload will have following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Algorithm ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
* Signature Algorithm is AlgorithmIdentifier ASN.1 blob from the
RFC5280 section 4.1.1.2
* Signature Data will be the actual signature value as specified in
the FIPS-186-3 section 4.6, i.e. (r,s).
Note, that the Signature Algorithm is ASN.1 SEQUENCE containing the
OID and optional parameters, and its length can be seen from the
SEQUENCE ASN.1 part. There is no padding between the Signature
Algorithm and Signature Data field, the Signature Data field is
directly concatenated to the Signature Algorithm field.
----------------------------------------------------------------------
In normal case that will add around 13-16 bytes to the Auth payload,
and it will solve the problem for both non-EC DSA and ECDSA.
The ASN.1 object of Signature Algorithm will usually be something
like:
0x30 0x0b - SEQUENCE
0x06 0x07 - OBJECT IDENTIFIER
0x2a 0x86 0x48 0xce 0x38 0x04 0x03 - 1.2.840.10040.4.3 dsa-with-sha1
0x05 0x00 - NULL
or
0x30 0x0c - SEQUENCE
0x06 0x08 - OBJECT IDENTIFIER
0x2a 0x86 0x48 0xce 0x3d 0x04 0x03 0x02 -
1.2. 840. 10045. 4. 3 2 ecdsa-with-SHA256(2)
0x05 0x00 - NULL
(Not sure if the ecdsa-with-SHA256(2) is correct oid for this, just
grabbing some random oid from google, also the asn1 encoding might be
wrong as was just manually doing it while writing the email).
Another option would be to use bit more asn.1, i.e. say that
authentication data is:
authenticationData ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
which would add 2 for initial sequence + 2 bytes for bit string header
for before the signature value, but I think the first version is
better, as the implementation can simply compare the initial bytes
against internal table if it does not want do asn.1 parsing here.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
