Re: [IPsec] Using ECC Brainpool curves with ipsec
> >>> Also I would be more happy to reuse the stuff from PKIX than adding >>> new registy for hashes. This would simplify the auth payload >>> processing too as the domain parameters and hash both could be seen >>> from the same place (i.e. from the auth payload) and then we do not >>> need to add stuff to this registry when new hash functions are added, >>> we can just assume someone will allocate oids for them. >> >> 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? > > One way is to just place the ASN.1 structure similar to a certificate > signature: a sequence containing an OID and a bitstring. That structure can > be placed there as the "Authentication Data" field. The only issue I have > with that is that there is no negotiation about support for the algorithm, so > the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not > even support SHA2-224, but that problem exists also with encoding the > SHA2-224 in the currently reserved fields. > > The advantage is that no specification would need to be updated when a new > hash function is defined. As long as it has an OID, the spec supports it with > no change. > This is a good solution, which can be used not only for ECDSA but for any signature method. So the question is if the new auth method should be defined for ECDSA only (generic_ECDSA) or for a broader scope (generic_ECC_signature, generic_signature). Johannes ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
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. 32 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
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Fri, July 27, 2012 12:13 am, Yoav Nir wrote: > > On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: > >> >> On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: >>> Dan Harkins writes: On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: > the fact that we need to study the protocol details and go into the > ASN.1 bits to ascertain that we have a problem, strongly suggests to me > that non-EC DSA is not terribly important. So if we can have a *simple* > solution that also deals with this problem, fine. Otherwise, let's just > focus on ECDSA. 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. > > Is that "we" as in the IPsecME group, or "we" the design team? Either way, > non-EC DSA is hardly used. There are effectively zero certificates on > https servers using it. People preferred RSA even in the days when RSA had > to be licensed and DSA was free. Why do we need to fix it now? I meant "we" as the WG. I think this design team is working at the pleasure of the WG anyway. I'm not sure why a survey of https servers can accurately gauge the use of DSA in IKEv2. One could also look at it in the light that the SHA-1-only nature of DSA in IKEv2 only became a problem recently (as FIPS 186-3 and SP 800-57 say such signatures were valid only through 2010). The reason we need to fix it now is that IKEv2 cannot produce a valid DSA signature today and unless IKEv3 is just around the corner I'd say we should fix it in IKEv2 (and given the sound of crickets I hear every time I bring up IKEv3 I'm less inclined to think it's just around the corner). >>> Also I would be more happy to reuse the stuff from PKIX than adding >>> new registy for hashes. This would simplify the auth payload >>> processing too as the domain parameters and hash both could be seen >>> from the same place (i.e. from the auth payload) and then we do not >>> need to add stuff to this registry when new hash functions are added, >>> we can just assume someone will allocate oids for them. >> >> 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? > > One way is to just place the ASN.1 structure similar to a certificate > signature: a sequence containing an OID and a bitstring. That structure > can be placed there as the "Authentication Data" field. The only issue I > have with that is that there is no negotiation about support for the > algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the > receiver does not even support SHA2-224, but that problem exists also with > encoding the SHA2-224 in the currently reserved fields. > > The advantage is that no specification would need to be updated when a new > hash function is defined. As long as it has an OID, the spec supports it > with no change. Yes that would work. Since there would be a new AUTH method we could overload the Authentication Data field. It seems sort of a "6 of one; half dozen of the other" kind of thing but I guess "we" can decide that. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Hi Yoav, I would take a new IANA registry over embedded ASN.1 snippets any time. Just my personal opinion, of course. Thanks, Yaron On 07/27/2012 10:13 AM, Yoav Nir wrote: On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: Dan Harkins writes: On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: the fact that we need to study the protocol details and go into the ASN.1 bits to ascertain that we have a problem, strongly suggests to me that non-EC DSA is not terribly important. So if we can have a *simple* solution that also deals with this problem, fine. Otherwise, let's just focus on ECDSA. 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. Is that "we" as in the IPsecME group, or "we" the design team? Either way, non-EC DSA is hardly used. There are effectively zero certificates on https servers using it. People preferred RSA even in the days when RSA had to be licensed and DSA was free. Why do we need to fix it now? Also I would be more happy to reuse the stuff from PKIX than adding new registy for hashes. This would simplify the auth payload processing too as the domain parameters and hash both could be seen from the same place (i.e. from the auth payload) and then we do not need to add stuff to this registry when new hash functions are added, we can just assume someone will allocate oids for them. 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? One way is to just place the ASN.1 structure similar to a certificate signature: a sequence containing an OID and a bitstring. That structure can be placed there as the "Authentication Data" field. The only issue I have with that is that there is no negotiation about support for the algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not even support SHA2-224, but that problem exists also with encoding the SHA2-224 in the currently reserved fields. The advantage is that no specification would need to be updated when a new hash function is defined. As long as it has an OID, the spec supports it with no change. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: > > On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: >> Dan Harkins writes: >>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: the fact that we need to study the protocol details and go into the ASN.1 bits to ascertain that we have a problem, strongly suggests to >>> me that non-EC DSA is not terribly important. So if we can have a >>> *simple* solution that also deals with this problem, fine. Otherwise, let's >>> just focus on ECDSA. >>> >>> 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. Is that "we" as in the IPsecME group, or "we" the design team? Either way, non-EC DSA is hardly used. There are effectively zero certificates on https servers using it. People preferred RSA even in the days when RSA had to be licensed and DSA was free. Why do we need to fix it now? >> Also I would be more happy to reuse the stuff from PKIX than adding >> new registy for hashes. This would simplify the auth payload >> processing too as the domain parameters and hash both could be seen >> from the same place (i.e. from the auth payload) and then we do not >> need to add stuff to this registry when new hash functions are added, >> we can just assume someone will allocate oids for them. > > 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? One way is to just place the ASN.1 structure similar to a certificate signature: a sequence containing an OID and a bitstring. That structure can be placed there as the "Authentication Data" field. The only issue I have with that is that there is no negotiation about support for the algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not even support SHA2-224, but that problem exists also with encoding the SHA2-224 in the currently reserved fields. The advantage is that no specification would need to be updated when a new hash function is defined. As long as it has an OID, the spec supports it with no change. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: > Dan Harkins writes: >> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >> > the fact that we need to study the protocol details and go into the >> > ASN.1 bits to ascertain that we have a problem, strongly suggests to >> me >> > that non-EC DSA is not terribly important. So if we can have a >> *simple* >> > solution that also deals with this problem, fine. Otherwise, let's >> just >> > focus on ECDSA. >> >> 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. > Also I would be more happy to reuse the stuff from PKIX than adding > new registy for hashes. This would simplify the auth payload > processing too as the domain parameters and hash both could be seen > from the same place (i.e. from the auth payload) and then we do not > need to add stuff to this registry when new hash functions are added, > we can just assume someone will allocate oids for them. 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? Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: > > the fact that we need to study the protocol details and go into the > > ASN.1 bits to ascertain that we have a problem, strongly suggests to me > > that non-EC DSA is not terribly important. So if we can have a *simple* > > solution that also deals with this problem, fine. Otherwise, let's just > > focus on ECDSA. > > 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. Also I would be more happy to reuse the stuff from PKIX than adding new registy for hashes. This would simplify the auth payload processing too as the domain parameters and hash both could be seen from the same place (i.e. from the auth payload) and then we do not need to add stuff to this registry when new hash functions are added, we can just assume someone will allocate oids for them. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: > Hi Tero, > > the fact that we need to study the protocol details and go into the > ASN.1 bits to ascertain that we have a problem, strongly suggests to me > that non-EC DSA is not terribly important. So if we can have a *simple* > solution that also deals with this problem, fine. Otherwise, let's just > focus on ECDSA. How does one currently indicate the hash algorithm used for non-EC DSA in IKEv2 today? Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Thu, July 26, 2012 11:06 am, Yoav Nir wrote: > In IKE we only have the bitstring, so we must infer the OID from something > else. Which is why I suggested we take some of the second bunch of RESERVED bits in the AUTH payload. Not to indicate an OID (not enough bits) but to just enumerate the valid hash algorithms that can be used with ECDSA. That way we know the curve from the subjectPublicKeyInfo (in either the signer's certificate or raw public key) and the hash algorithm used (from the 2nd bunch of RESERVED bits). There is nothing to infer. When more hash algorithms (like SHA3) get defined we just populate the registry that gets represented in the 2nd bunch of RESERVED bits. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Hi Tero, the fact that we need to study the protocol details and go into the ASN.1 bits to ascertain that we have a problem, strongly suggests to me that non-EC DSA is not terribly important. So if we can have a *simple* solution that also deals with this problem, fine. Otherwise, let's just focus on ECDSA. Thanks, Yaron On 07/26/2012 04:21 PM, Tero Kivinen wrote: Dan Harkins writes: Well FIPS 186-3 specifically refers to SP 800-57 for "information about the selection of the appropriate (L,N) pair in accordance with a desired security strength for a given time period for the generation of digital signatures." And SP 800-57 says that, for example, to produce a signature valid "beyond 2030" it requires a minimum of 128 bits of strength (table 4) and that when performing digital signatures of 128 bits of security the valid hash functions are SHA-256, SHA-384, and SHA-512. You want to restrict such signatures to SHA-256 so it's not really meeting the requirements of FIPS 186-3. Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc to know the answer myself). When we have DSS signature in FIPS 186-3 format, I have understood that there is no indication about whether the signature is ECDSA or normal DSA, or what is the domain parameters for the ECDSA, and what is the hash function used when generating the signature. I.e. the signature just consist of some raw bits, and there is no other information around it and all that other information must be carried to the verifier over some other medium? Is this correct? If that is correct how does the PKIX solve this? I.e. when I have certificate signed by the some other certificate using DSA? If my reading of RFC5280 is correct there is this signatureAlgorithm ASN.1 blob in front of the signature itself and that gives all that information (including the domain parameters and hash functions etc). Is my understanding correct? If so then I think we should use similar method in the IKEv2 too, and fix both ECDSA and normal DSA at the same time, i.e. create one new authentication method where the actual signature format that contains both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3 from the RFC5280). This will fix the problem for all DSA methods (EC or normal) and allows using any hash function allowed by signers policy. It also allows responder to immediately know the domain parameters and hash function even when certificate of the public key was not delivered inband of the IKEv2. If we define one new authentication method then we can also deprecate old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-* curve - 9-11), and recommend that new implementations will use this new method. Or we can still say that for SHA-1 DSS and SHA-2 with those curves still use the old methods. This same method could also be used for RSA, but as this problem of not knowing hash-function / parameters do not exists in RSA there is no point of changing the current RSA method. This would also make it so that we could use any public key method the PKIX decideds to define in the future without any changes to the IKEv2 document. If only this protocol was designed better True, we can only blame ourselves. This same problem was already there for IKEv1, but nobody noticed that we should fix this when we were defining IKEv2. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 26, 2012, at 4:21 PM, Tero Kivinen wrote: > If that is correct how does the PKIX solve this? I.e. when I have > certificate signed by the some other certificate using DSA? If my > reading of RFC5280 is correct there is this signatureAlgorithm ASN.1 > blob in front of the signature itself and that gives all that > information (including the domain parameters and hash functions etc). > > Is my understanding correct? Yes. If you print out a certificate signed with ECDSA with OpenSSL, it looks like this: MBA:tmp ynir$ openssl x509 -in the_ca_cert.crt -text Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA1 Issuer: Validity Not Before: Jul 26 17:56:00 2012 GMT Not After : Jul 26 17:56:00 2022 GMT Subject: Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:b9:36:b6:65:ee:65:27:70:f0:f9:16:67:78:53: b8:be:14:29:c5:36:09:a7:3b:0a:f0:0d:59:4d:31: 6d:9a:f3:be:fd:bf:e3:6e:0e:39:69:96:c9:d8:ae: 74:79:3d:f8:af:b5:5a:65:44:fe:76:c1:8c:52:18: f3:6e:49:43:23 ASN1 OID: prime256v1 X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 9B:D6:1D:1A:9B:B8:CE:2D:46:FD:B1:A5:6E:7D:35:E6:05:04:F0:36 X509v3 Key Usage: Certificate Sign, CRL Sign Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA Netscape Comment: xca certificate Signature Algorithm: ecdsa-with-SHA1 30:45:02:20:61:68:e4:5e:9c:47:2d:d6:49:f6:6b:24:cb:43: cd:20:2e:c4:5d:bb:1a:45:d9:95:09:6b:89:93:5b:00:d2:cb: 02:21:00:b9:c4:d3:d4:4a:98:e0:d6:20:45:b2:95:8b:4a:06: d5:6b:3d:90:f6:a7:81:be:1f:d0:c5:f1:a8:b5:6a:d0:b9 See the "Signature Algorithm" field before the signature itself? If we dump the ASN.1 the signature is a sequence of an OID and a bitstring: MBA:tmp ynir$ openssl asn1parse -in the_ca_cert.crt -i -dump 0:d=0 hl=4 l= 351 cons: SEQUENCE … 270:d=1 hl=2 l= 9 cons: SEQUENCE 272:d=2 hl=2 l= 7 prim: OBJECT:ecdsa-with-SHA1 281:d=1 hl=2 l= 72 prim: BIT STRING - 00 30 45 02 20 61 68 e4-5e 9c 47 2d d6 49 f6 6b .0E. ah.^.G-.I.k 0010 - 24 cb 43 cd 20 2e c4 5d-bb 1a 45 d9 95 09 6b 89 $.C. ..]..E...k. 0020 - 93 5b 00 d2 cb 02 21 00-b9 c4 d3 d4 4a 98 e0 d6 .[!.J... 0030 - 20 45 b2 95 8b 4a 06 d5-6b 3d 90 f6 a7 81 be 1fE...J..k=.. 0040 - d0 c5 f1 a8 b5 6a d0 b9- .j.. In IKE we only have the bitstring, so we must infer the OID from something else. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
>
> Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc
> to know the answer myself).
>
> When we have DSS signature in FIPS 186-3 format, I have understood
> that there is no indication about whether the signature is ECDSA or
> normal DSA, or what is the domain parameters for the ECDSA, and what
> is the hash function used when generating the signature.
>
> I.e. the signature just consist of some raw bits, and there is no
> other information around it and all that other information must be
> carried to the verifier over some other medium?
>
> Is this correct?
Yes, in both cases (DSA, ECDSA) the signature consists of two integers. RFC
3279 defines:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
And the bit length is typically comparable.
>
> If that is correct how does the PKIX solve this? I.e. when I have
> certificate signed by the some other certificate using DSA? If my
> reading of RFC5280 is correct there is this signatureAlgorithm ASN.1
> blob in front of the signature itself and that gives all that
> information (including the domain parameters and hash functions etc).
>
> Is my understanding correct?
>
Almost. The signature scheme and hash are specified in the signatureAlgorithm
identifier, e.g. id-dsa-with-sha256 and
ecdsa-with-SHA256. The parameters (DSA parameters and ECC domain parameters)
are stored in subjectPublicKey. But this is
specified in the certificate.
Note: for DSA is is admissible (according to RFC 3279) to omit the patrameters
and then the parameters of the CA key
apply, which are specified in the CA certificate. So it an be necessary to
parse the CA certificate as well to obtain
them.
> If so then I think we should use similar method in the IKEv2 too, and
> fix both ECDSA and normal DSA at the same time, i.e. create one new
> authentication method where the actual signature format that contains
> both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3
> from the RFC5280).
>
> This will fix the problem for all DSA methods (EC or normal) and
> allows using any hash function allowed by signers policy. It also
> allows responder to immediately know the domain parameters and hash
> function even when certificate of the public key was not delivered
> inband of the IKEv2.
>
That would work but would expand the auth payload by more than two or three
bytes. For instance the OID
ecdsa-with-SHA256 is 1.2.840.10045.4.3.2.
While this is still limited, for the new RSA-PSS scheme (see my response
regarding RSA below)
> If we define one new authentication method then we can also deprecate
> old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-*
> curve - 9-11), and recommend that new implementations will use this
> new method. Or we can still say that for SHA-1 DSS and SHA-2 with
> those curves still use the old methods.
>
Deprecation is the cleaner method but I fear that existing implementation will
not quickly adpat to the new rule, so
still allowing the old methods is more safe.
> This same method could also be used for RSA, but as this problem of
> not knowing hash-function / parameters do not exists in RSA there is
> no point of changing the current RSA method.
>
This may change. Since 2005, PKIX supports through RFC 4055 the signature
scheme RSASA-PSS which provides provable
security (in a certain mathematical model) and is generally considered the
better padding method as compared to the old
padding PKCS#1v1.5.
However, in RSASA-PSS, the encoding of the PKIX signature algorithm identifier
may be quite large as it has several
parameters:
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
saltLength [2] INTEGERDEFAULT 20,
trailerField [3] TrailerField DEFAULT trailerFieldBC
}
--
Johannes
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > Well FIPS 186-3 specifically refers to SP 800-57 for "information about > the selection of the appropriate (L,N) pair in accordance with a desired > security strength for a given time period for the generation of digital > signatures." And SP 800-57 says that, for example, to produce a > signature valid "beyond 2030" it requires a minimum of 128 bits of > strength (table 4) and that when performing digital signatures of 128 > bits of security the valid hash functions are SHA-256, SHA-384, and > SHA-512. You want to restrict such signatures to SHA-256 so it's > not really meeting the requirements of FIPS 186-3. Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc to know the answer myself). When we have DSS signature in FIPS 186-3 format, I have understood that there is no indication about whether the signature is ECDSA or normal DSA, or what is the domain parameters for the ECDSA, and what is the hash function used when generating the signature. I.e. the signature just consist of some raw bits, and there is no other information around it and all that other information must be carried to the verifier over some other medium? Is this correct? If that is correct how does the PKIX solve this? I.e. when I have certificate signed by the some other certificate using DSA? If my reading of RFC5280 is correct there is this signatureAlgorithm ASN.1 blob in front of the signature itself and that gives all that information (including the domain parameters and hash functions etc). Is my understanding correct? If so then I think we should use similar method in the IKEv2 too, and fix both ECDSA and normal DSA at the same time, i.e. create one new authentication method where the actual signature format that contains both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3 from the RFC5280). This will fix the problem for all DSA methods (EC or normal) and allows using any hash function allowed by signers policy. It also allows responder to immediately know the domain parameters and hash function even when certificate of the public key was not delivered inband of the IKEv2. If we define one new authentication method then we can also deprecate old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-* curve - 9-11), and recommend that new implementations will use this new method. Or we can still say that for SHA-1 DSS and SHA-2 with those curves still use the old methods. This same method could also be used for RSA, but as this problem of not knowing hash-function / parameters do not exists in RSA there is no point of changing the current RSA method. This would also make it so that we could use any public key method the PKIX decideds to define in the future without any changes to the IKEv2 document. > If only this protocol was designed better True, we can only blame ourselves. This same problem was already there for IKEv1, but nobody noticed that we should fix this when we were defining IKEv2. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 24, 2012, at 2:21 PM, Dan Brown wrote: > The next text after the question tried to clarify that I was not suggesting > any such limitation. Thank you: it was not clear. > Anyway, to answer your question: considerable thought was put into ECC > parameters in ECDSA standards, so their requirements should make for a good > sanity check on any newer curves. (Are the Brainpool curves actually newer?) > It should be possible to devise newer curve that also adheres to the past > ECDSA standards, but if not, there should be a good reason. Of course. Anything we do here should have good reason, and it should be documented. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
> -Original Message- > From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] > Sent: Tuesday, July 24, 2012 4:53 PM > To: Dan Brown > Cc: IPsecme WG > Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec > > On Jul 24, 2012, at 11:42 AM, Dan Brown wrote: > > > Do the Brainpool curves comply with all the requirements (and ideally the > recommendations too) that the ECDSA standards place on the elliptic curves? > > I'm confused by the question. "The ECDSA standards" (ANSI X9.62-2005 and SEC1- > v2.0) list things that newer curves might not meet because, well, they're > newer than the standards. Why should that be a limitation on what is used in > IPsec? The next text after the question tried to clarify that I was not suggesting any such limitation. Anyway, to answer your question: considerable thought was put into ECC parameters in ECDSA standards, so their requirements should make for a good sanity check on any newer curves. (Are the Brainpool curves actually newer?) It should be possible to devise newer curve that also adheres to the past ECDSA standards, but if not, there should be a good reason. > > --Paul Hoffman - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 24, 2012, at 11:42 AM, Dan Brown wrote: > Do the Brainpool curves comply with all the requirements (and ideally the > recommendations too) that the ECDSA standards place on the elliptic curves? I'm confused by the question. "The ECDSA standards" (ANSI X9.62-2005 and SEC1-v2.0) list things that newer curves might not meet because, well, they're newer than the standards. Why should that be a limitation on what is used in IPsec? --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Hi all, Just a technical question, not very IPSec-specific: Do the Brainpool curves comply with all the requirements (and ideally the recommendations too) that the ECDSA standards place on the elliptic curves? The intent of the ECDSA standards and IPSec is to have a secure, interoperable signature algorithm, which ought to be the case for the Brainpool curves used with ECDSA. So IPSec may choose to call various things "ECDSA", but IPSec may want to avoid saying something is ANSI X9.62-2005 unless if it is strictly compliant. The main ECDSA standards are ANSI X9.62-2005 and SEC1-v2.0 (which also specifies other ECC algorithms and syntax). FIPS 186-3 specifies ECDSA mostly by reference to ANSI X9.62-2005. ISO also specifies "EC-DSA". IEEE 1363-2000 and IEEE 1363a-2004 specify ECDSA under a slightly different acronym. As editor of ANSI X9.62-2005 and SEC1-v2.0, I ought able to help check compliance. As I recall, both standards impose requirements on the elliptic curves in order to avoid weak curves, and perhaps also to encourage interoperability. Maybe Johannes could contact me off-list to start this process. Best regards, Daniel Brown Research In Motion Limited - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Tue, July 24, 2012 4:17 am, Johannes Merkle wrote: >> If the mapping between curve and hash function is fixed then I don't >> see what you mean by "not hash-independent but only curve-independent". >> Seems that there is nothing independent, it's all fixed. > > I have the impression that we misunderstand each other. The solution that > I propose is to define one new auth method > ECDSA_generic which indicates that > - the curve shall be taken from the certificate > - the hash function shall be the minimum SHA-1/2 function matching or > exceeding the security level of the curve. So the signer says "ECDSA_generic" and the curve is determined from the subjectPublicKeyInfo and one infers the correct SHA-1/2 algorithm from the curve. OK, so if the curve is the 320-bit brainpool curve then we always use SHA-384. Got it. >> And there are 7 new brainpool curves so that's 7 new auth methods >> plus 4 new ones to deal with the non-EC version of DSA for a total >> of 11 new auth methods to go along with the existing 4. 15 different >> auth methods just for the digital signature standard! >> > Not with the approach I proposed: there is only one method ECDSA_generic. > > Note, that for DSA (on EC), it would also be sufficient to specify a new > auth method DSS_key_length_defined_hash > accompanied with the requirement to choose the hash function as the > smallest SHA-2 function meeting the minimum > requirements of FIPS-186-3. Well FIPS 186-3 specifically refers to SP 800-57 for "information about the selection of the appropriate (L,N) pair in accordance with a desired security strength for a given time period for the generation of digital signatures." And SP 800-57 says that, for example, to produce a signature valid "beyond 2030" it requires a minimum of 128 bits of strength (table 4) and that when performing digital signatures of 128 bits of security the valid hash functions are SHA-256, SHA-384, and SHA-512. You want to restrict such signatures to SHA-256 so it's not really meeting the requirements of FIPS 186-3. >> Yes, it is unfortunate. What's also unfortunate is that the 11 auth >> methods mentioned above (plus the 3 existing ECDSA auth methods) >> will probably have to be duplicated for SHA-3 thereby eating into this >> "scarce resource" of an 8-bit registry even further. > > We have the choice: Either spending many assignments out of the 256 > available, or to specify a generic auth method > deviating from the approach previously tken for ECDSA (but being in > accordance with the approach taken for DSA). But the "generic ECDSA" does not solve the problem with SHA-3. As you said above, "the hash function shall be the minimum SHA-1/2 function matching or exceeding the security level of the curve." So how do you support SHA-3? I guess we could assign a bit (clear=SHA-1/2, set = SHA-3) but that's getting pretty hackish. Or we could have 2 "generic ECDSA", one for SHA-1/2 and another for SHA-3. Yuck. If only this protocol was designed better Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
>> By generic ECDSA methods, I did not mean hash-independent but only >> curve-independent. >> >> At least for SHA-1/SHA-2, the mapping between size of the curve and hash >> function could be fixed in an RFC. The hash >> length shall not be smaller than the bit length of curve parameters >> (FIPS-186-3), and there is no need to choose an >> SHA-2 function longer than the minimum one meeting this requirement. > > If the mapping between curve and hash function is fixed then I don't > see what you mean by "not hash-independent but only curve-independent". > Seems that there is nothing independent, it's all fixed. I have the impression that we misunderstand each other. The solution that I propose is to define one new auth method ECDSA_generic which indicates that - the curve shall be taken from the certificate - the hash function shall be the minimum SHA-1/2 function matching or exceeding the security level of the curve. This method is flexible w.r.t the curve but not w.r.t the hash function, and that is what I called "not hash-independent but only curve-independent". Maybe the term "curve-flexible but not hash-flexible" is better. This approach is exactly the one followed for DSA (DSS Digital Signature), except that the latter one was limited to SHA-1. Thus, a curve-independent ECDSA method would be more consistent with the existing DSA method. This is the reason why I objected to your assertion of our approach being a "hack". But maybe you didn't refer to this approach at all? > >>> So to actually address this in the hash-specific canonical way >>> requires new auth methods for different permutations of DSS with >>> SHA-224, SHA-256, SHA-384, and SHA-512 as well as different >>> permutations of ECDSA with brainpool curves using the 5 different >>> SHA varients. But this is getting, as you say, "cumbersome". >>> >> As said above, I don't see the need to allow, for instance, the Brainpool >> p256 curve to be used with any hash function >> other than SHA-256. > > And there are 7 new brainpool curves so that's 7 new auth methods > plus 4 new ones to deal with the non-EC version of DSA for a total > of 11 new auth methods to go along with the existing 4. 15 different > auth methods just for the digital signature standard! > Not with the approach I proposed: there is only one method ECDSA_generic. Note, that for DSA (on EC), it would also be sufficient to specify a new auth method DSS_key_length_defined_hash accompanied with the requirement to choose the hash function as the smallest SHA-2 function meeting the minimum requirements of FIPS-186-3. >>> Of course one can decide not to use the hash-specific canonical >>> technique and come up with "generic DSA" and "generic ECDSA" to >>> address this but then we have the unfortunate state of hash-specific >>> (EC)DSA methods and "generic" methods and now it's getting ugly >>> (and hack-ish). >>> >> Such a co-existence of different approaches would also be the case if a >> curve-independent (but hash-specific) ECDSA >> method was specified, and I agreee that this is a bit unfortunate. But >> this is not a major issue compared to alternative >> of specifying separate methods for each curve in an 8 bit registry. > > Yes, it is unfortunate. What's also unfortunate is that the 11 auth > methods mentioned above (plus the 3 existing ECDSA auth methods) > will probably have to be duplicated for SHA-3 thereby eating into this > "scarce resource" of an 8-bit registry even further. We have the choice: Either spending many assignments out of the 256 available, or to specify a generic auth method deviating from the approach previously tken for ECDSA (but being in accordance with the approach taken for DSA). > >>> Instead of either negotiating a complete ciphersuite (the way TLS >>> does) or individual components (the way IKEv1 did), IKEv2 does both >>> and gets the worst of both worlds. >>> >> >> Means to negotiate the hash function could be specified as discussed >> earlier in this thread, but of course this is a >> more significant change. And I am not sure if this is necessary, given the >> clear recommendations of FIPS 186-3. > > I am not advocating the mixing-and-matching of curves and hash > functions of different security levels (and therefore one could argue > to fix them) but it should be noted that IKEv2 allows all sorts of mixing > and matching of ciphers, hash algorithms, and D-H groups of different > security levels to be negotiated-- AES-256 with the 768-bit DH group > authenticated with ECDSA using NISTP384 with SHA-384 and key > derivation using SHA-1. Why would someone do this? I have no idea. > Can someone? Yes. Is there a reason to enforce a "no mix-and-match" > policy on some primitives and a "laissez faire negotiation" policy on > others? No, at least not a good one. > I assume, the reason why the hash function is not negotiated is that at the time IKEv2 was specified there was mainly one hash function giving adequate
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > FIPS 186-3 (The Digital Signature Algorithm) specifies that security > strength levels of DSA are a minimum of the security strength of the > hash algorithm and the (L,N) pair from the domain parameter set. If > one wished to achieve a security strength level with DSA that would > be valid, according to NIST, "beyond 2030" one would need to use > SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature" > (authentication method value of 3) so that wouldn't work. That SHA-1 text is leftover from the RFC4306 and from the IKEv1, i.e. when the only supported DSS was the one using SHA-1. The RFC5996 did update from the 1994 FIPS 186 to draft FIPS 186-3 but that comment about SHA-1 did not get removed. On the other hand I would expect most of the implementations ignore that comment, and go with the actual DSS documentation when using DSS signatures, and use the hashes defined in there. This is one of those cases where, when that text was added it seemed to help understanding the issue, as SHA-1 was the only allowed hash function for DSS, but with updated documents with later references, that comment came misleading but did not get removed.. > So to actually address this in the hash-specific canonical way > requires new auth methods for different permutations of DSS with > SHA-224, SHA-256, SHA-384, and SHA-512 as well as different > permutations of ECDSA with brainpool curves using the 5 different > SHA varients. But this is getting, as you say, "cumbersome". So you are saying that each DSS even with ECDSA do require to tell what hash function is used separately? I have assume that when I do get DSA public key in the certificate, and know the length of the DSA key, I can know which hash function is used when using that key? But if I am mistaken, then we might need to add extra DSS methods too (but lets not add them to IKEv1, as I do not want new modifications to IKEv1. IKEv1 does this same way than IKEv2 does, i.e. it assumes you know which hash function is used with DSS and ignores the negotiated hash function when using DSS). Note, that there is no MUSTs or anything like that in the RFC5996 saying you MUST use SHA-1, it is just statement that DSS as defined in year 1994 version used SHA-1. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Johannes Merkle writes: > As I wrote to Dan, there is actually also the option of not > specifying the parameters in the cert, but this method > (implicitCurve) is supposed to be used only if the parameters are > known to the other pier by other means (e.g. by local configuration) So for IKEv2 use we can say that ECDSA MUST be used with certificates which give domain parameters in the certificate? That should solve the problem that we do not need separate auth methods for every different EC curve. > Even if the pier supports both SHA-1 and all SHA-2 functions, it > would require try-and-error to find out which one was used for the > signature. I now understand, when it was point out in some later emails, that in the ECDSA signatures there is no way to know the hash algorithm from the signature alone (compared to RSA, where is possible to extract the hash algorithm from signature). But there is still two different problems there. One is which hash algorithm to use, and another is how the other end knows which hash algorithm was used. There are multiple solutions to the problems. One solution to both of the problems would be to add new transform type for HASH algorithms and negotiate it. This would most likely be the cleanest way, but would require more changes than other solutions. Another option is to use method like or RSA to select which hash algorithm to use, and encode the hash algorithm to the auth payload reserved bytes. Yet another option is to specify the mandatory hash algorithm to be used for each specific curve, so hash function is known because of specific group is used. This is bit like what existing ECDSA groups are doing, i.e. each group defines hash function that must be used for it. This option does not require that every group will be given separate authentication method number. > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be > >done as individual draft, and does not need to be WG item, but if > >we are doing the rest in WG then I think this should also be WG > >item too). > I am not sure. If the rest is not specific for the Brainpool curves > (e.g. defining a generic ECDSA auth method) it is not so clear that > both efforts should be bundled. I do not think they need to be bundled. Thats why I proposed adding two separate charter items for them. I.e. this first step is something that can be done quickly and without any problems with just one informational RFC. I do not also expect there to be too much discussion whether this should be done or not, and how this should be done. > > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) > >in the IKEv2. This may require new standard track RFC defining new > >generic ECDSA method, and might also need solutions how hash > >function is selected for each group. > > > According to the policy of the IANA registry for ath methods, > standard track is not required but only IETF consensus, > i.e. an informational WG document would suffice. Yes information draft would be enough, but if we are really making generic ECDSA method, then we most likely do want to also say what we are going to do for the old ECDSA methods. For example if we do want to say that those methods are NOT RECOMMENDED then we need to update the standard track document (RFC4754). Also at least I would prefer that this kind of generic work should be standard track document. > From a cryptographic point of view, the correctness (and hence, the > integrity and authenticity) of the domain parameters is crucial, it > is not a restriction to require that, if a raw (trusted) EC public > key is used, the parameters must also be available by trusted means > (e.g. local configuration). In my draft-kivinen-oob-pubkey-00.txt which adds raw EC public keys, we did plan to use SubjectPublicKeyInfo part of the PKIX certificate, thus that would have the domain parameters in there. The local configuration would then indicate whether that raw key is trusted or not. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
>>> With RSA the hash algorithm is encoded into the padding so there is >>> no real need to independently agree on a hash algorithm. >> >> No, in RSA PKCS#1v1.5 padding (which is currently the only supported >> padding in IKEv2), the hash algorithm is *not* encoded in the padding. >> Only the length of the length of the hash value can be determined due >> to the reserved zero octet leading the hash value. For SHA-1 and the >> SHA-2 hash functions, the length also determines the function, so your >> assertion in in some way true for these functions. However, RFC 5996 >> does not restrict the hash function to these. As soon as one of the >> SHA-3 contributions is used, the function can not be determined from >> the padding, as SHA-3 contributions were required support 224, 256, >> 384, and 512-bit message digests, exactly the lengths generated by the >> SHA-2 functions. > > Actually, the hash type is indeed encoded in the signature in PKCS#1v1.5, aka > RSASSA-PKCS1-v1_5; refer to the PKCS #1 version 2.1 or to RFC3447, section > A.2.4 for both documents. > > To summarize, when using PKCS#1v1.5, the padded message is of the format: > 00 02 FF FF FF FF ... FF 00 > (where there are enough FF bytes to exactly fill the RSA block). > > The byte string I marked as is a string that depends on the hash > algorithm used; for SHA-256, it is: > 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 > Right, I was mistaken, I had looked into the padding scheme of the PKCS#1v1.5 encryption scheme not signature. Johannes ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Mon, July 23, 2012 12:15 pm, Johannes Merkle wrote: If we're gonna recharter, maybe we should just work on an IKEv3 because the problems in IKEv2 are becoming apparent. This "new authentication mode" suggestion, or the need for a "generic ECDSA" algorithm are just hacks that should not be necessary for a properly defined protocol. In addition, the >>> >>> I do not agree. The generic definition of the ECDSA auth method is >>> analogous to the auth methods defined for RSA and DSA >>> keys, and thus, is rather the proper (canonical) way to define it than >>> a >>> hack. >>> Of course, the fact than there are already 3 specific auth methods for >>> ECDSA (which are not canonically defined) makes >>> specification of a generic ECDSA method more cumbersome. >> >> With RSA the hash algorithm is encoded into the padding so there is >> no real need to independently agree on a hash algorithm. For DSA, > > No, in RSA PKCS#1v1.5 padding (which is currently the only supported > padding in IKEv2), the hash algorithm is *not* > encoded in the padding. Only the length of the length of the hash value > can be determined due to the reserved zero octet > leading the hash value. For SHA-1 and the SHA-2 hash functions, the length > also determines the function, so your > assertion in in some way true for these functions. However, RFC 5996 does > not restrict the hash function to these. As > soon as one of the SHA-3 contributions is used, the function can not be > determined from the padding, as SHA-3 > contributions were required support 224, 256, 384, and 512-bit message > digests, exactly the lengths generated by the > SHA-2 functions. I see that Scott Fluhrer has already responded to this; I agree with Scott. >> I disagree. The DSA algorithm definition is hash-specific so the hash- >> specific ECDSA auth methods are the canonical way. Let me point >> out, though, that canon law is not necessarily correct and this is an >> example. > > By generic ECDSA methods, I did not mean hash-independent but only > curve-independent. > > At least for SHA-1/SHA-2, the mapping between size of the curve and hash > function could be fixed in an RFC. The hash > length shall not be smaller than the bit length of curve parameters > (FIPS-186-3), and there is no need to choose an > SHA-2 function longer than the minimum one meeting this requirement. If the mapping between curve and hash function is fixed then I don't see what you mean by "not hash-independent but only curve-independent". Seems that there is nothing independent, it's all fixed. >> So to actually address this in the hash-specific canonical way >> requires new auth methods for different permutations of DSS with >> SHA-224, SHA-256, SHA-384, and SHA-512 as well as different >> permutations of ECDSA with brainpool curves using the 5 different >> SHA varients. But this is getting, as you say, "cumbersome". >> > As said above, I don't see the need to allow, for instance, the Brainpool > p256 curve to be used with any hash function > other than SHA-256. And there are 7 new brainpool curves so that's 7 new auth methods plus 4 new ones to deal with the non-EC version of DSA for a total of 11 new auth methods to go along with the existing 4. 15 different auth methods just for the digital signature standard! >> Of course one can decide not to use the hash-specific canonical >> technique and come up with "generic DSA" and "generic ECDSA" to >> address this but then we have the unfortunate state of hash-specific >> (EC)DSA methods and "generic" methods and now it's getting ugly >> (and hack-ish). >> > Such a co-existence of different approaches would also be the case if a > curve-independent (but hash-specific) ECDSA > method was specified, and I agreee that this is a bit unfortunate. But > this is not a major issue compared to alternative > of specifying separate methods for each curve in an 8 bit registry. Yes, it is unfortunate. What's also unfortunate is that the 11 auth methods mentioned above (plus the 3 existing ECDSA auth methods) will probably have to be duplicated for SHA-3 thereby eating into this "scarce resource" of an 8-bit registry even further. >> Instead of either negotiating a complete ciphersuite (the way TLS >> does) or individual components (the way IKEv1 did), IKEv2 does both >> and gets the worst of both worlds. >> > > Means to negotiate the hash function could be specified as discussed > earlier in this thread, but of course this is a > more significant change. And I am not sure if this is necessary, given the > clear recommendations of FIPS 186-3. I am not advocating the mixing-and-matching of curves and hash functions of different security levels (and therefore one could argue to fix them) but it should be noted that IKEv2 allows all sorts of mixing and matching of ciphers, hash algorithms, and D-H groups of different security levels to be negotiated-- AES-256 with the 768-bit DH group authenti
Re: [IPsec] Using ECC Brainpool curves with ipsec
-Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Johannes Merkle Sent: Monday, July 23, 2012 3:16 PM To: Dan Harkins Cc: ipsec@ietf.org; Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec >> >> With RSA the hash algorithm is encoded into the padding so there is >> no real need to independently agree on a hash algorithm. > > No, in RSA PKCS#1v1.5 padding (which is currently the only supported > padding in IKEv2), the hash algorithm is *not* encoded in the padding. > Only the length of the length of the hash value can be determined due > to the reserved zero octet leading the hash value. For SHA-1 and the > SHA-2 hash functions, the length also determines the function, so your > assertion in in some way true for these functions. However, RFC 5996 > does not restrict the hash function to these. As soon as one of the > SHA-3 contributions is used, the function can not be determined from > the padding, as SHA-3 contributions were required support 224, 256, > 384, and 512-bit message digests, exactly the lengths generated by the > SHA-2 functions. Actually, the hash type is indeed encoded in the signature in PKCS#1v1.5, aka RSASSA-PKCS1-v1_5; refer to the PKCS #1 version 2.1 or to RFC3447, section A.2.4 for both documents. To summarize, when using PKCS#1v1.5, the padded message is of the format: 00 02 FF FF FF FF ... FF 00 (where there are enough FF bytes to exactly fill the RSA block). The byte string I marked as is a string that depends on the hash algorithm used; for SHA-256, it is: 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 For SHA-1, it is: 30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 And there are other OIDs for a number of other hash functions. This OID (when concatenated with the hash) is a DER string the means "The result of is ". And, yes, a signature verifier can use this OID string to figure out which hash function to use (by running the RSA public operation on the signature, looking through the resulting block, checking which OID it lists, and then running the appropriate hash on the data). When SHA-3 comes out, they'll just allocate more OIDs (if they haven't already) to denote the various sizes of SHA-3; no confusion between SHA-256 and SHA-3-256 will be necessary. Perhaps you have this confused with signatures in IKEv1; there, they do something nonstandard and don't include the OID (possibly because they are not actually using the hash function, but instead the HMAC version). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
>>> If we're gonna recharter, maybe we should just work on an IKEv3 >>> because >>> the problems in IKEv2 are becoming apparent. This "new authentication >>> mode" >>> suggestion, or the need for a "generic ECDSA" algorithm are just hacks >>> that >>> should not be necessary for a properly defined protocol. In addition, >>> the >> >> I do not agree. The generic definition of the ECDSA auth method is >> analogous to the auth methods defined for RSA and DSA >> keys, and thus, is rather the proper (canonical) way to define it than a >> hack. >> Of course, the fact than there are already 3 specific auth methods for >> ECDSA (which are not canonically defined) makes >> specification of a generic ECDSA method more cumbersome. > > With RSA the hash algorithm is encoded into the padding so there is > no real need to independently agree on a hash algorithm. For DSA, No, in RSA PKCS#1v1.5 padding (which is currently the only supported padding in IKEv2), the hash algorithm is *not* encoded in the padding. Only the length of the length of the hash value can be determined due to the reserved zero octet leading the hash value. For SHA-1 and the SHA-2 hash functions, the length also determines the function, so your assertion in in some way true for these functions. However, RFC 5996 does not restrict the hash function to these. As soon as one of the SHA-3 contributions is used, the function can not be determined from the padding, as SHA-3 contributions were required support 224, 256, 384, and 512-bit message digests, exactly the lengths generated by the SHA-2 functions. > I disagree. The DSA algorithm definition is hash-specific so the hash- > specific ECDSA auth methods are the canonical way. Let me point > out, though, that canon law is not necessarily correct and this is an > example. By generic ECDSA methods, I did not mean hash-independent but only curve-independent. At least for SHA-1/SHA-2, the mapping between size of the curve and hash function could be fixed in an RFC. The hash length shall not be smaller than the bit length of curve parameters (FIPS-186-3), and there is no need to choose an SHA-2 function longer than the minimum one meeting this requirement. As I said in an earlier message, adding hash algorithm flexibility is a more general topic concerning not only ECDSA. It probably requires much more than simply defining a new auth method and specifying a rule, which hash function to chose for which ECDSA bit length. > > FIPS 186-3 (The Digital Signature Algorithm) specifies that security > strength levels of DSA are a minimum of the security strength of the > hash algorithm and the (L,N) pair from the domain parameter set. If > one wished to achieve a security strength level with DSA that would > be valid, according to NIST, "beyond 2030" one would need to use > SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature" > (authentication method value of 3) so that wouldn't work. > > Given that SP 800-57 requires that 80 bits of strength only be used > through 2010 (and SHA-1 does not provide more than that) and it > is now 2012 it appears that IKEv2 is not capable of producing a > signature of sufficient strength for certain customers (they might not > be your's but they do exist, and there's probably more of them than > there are people clamoring for AES-XCBC MAC). > This is definitely an issue when using DSA with IKEv2, and I do not doubt that something should be done, but I don't think that this needs to be coupled with an effort to specify a curve-independent ECDSA auth method. > So to actually address this in the hash-specific canonical way > requires new auth methods for different permutations of DSS with > SHA-224, SHA-256, SHA-384, and SHA-512 as well as different > permutations of ECDSA with brainpool curves using the 5 different > SHA varients. But this is getting, as you say, "cumbersome". > As said above, I don't see the need to allow, for instance, the Brainpool p256 curve to be used with any hash function other than SHA-256. > Of course one can decide not to use the hash-specific canonical > technique and come up with "generic DSA" and "generic ECDSA" to > address this but then we have the unfortunate state of hash-specific > (EC)DSA methods and "generic" methods and now it's getting ugly > (and hack-ish). > Such a co-existence of different approaches would also be the case if a curve-independent (but hash-specific) ECDSA method was specified, and I agreee that this is a bit unfortunate. But this is not a major issue compared to alternative of specifying separate methods for each curve in an 8 bit registry. > Instead of either negotiating a complete ciphersuite (the way TLS > does) or individual components (the way IKEv1 did), IKEv2 does both > and gets the worst of both worlds. > Means to negotiate the hash function could be specified as discussed earlier in this thread, but of course this is a more significant change. And I am not sure
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Mon, July 23, 2012 2:19 am, Tero Kivinen wrote: > Dan Harkins writes: >> So instead of being able to use the negotiated hash function to >> compute an ECDSA signature we're forced to eat through the "scarce >> resource" of the authentication method registry. Very clumsy, very >> hackish, very unfortunate. > > I disagree it being clumsy or hackish or unfortunate. It is just one > way of designing the system. Some peole do want to make sure there is > no way to mix algorithms of different strength. I myself think this > should be something that is restricted by policy, not by protocol, but > some people do disagree that and design systems differently. It is not > necessarely bad or good, it is just different. So some people want to do it one way and other's want to do it a different way. What's hackish is to do both and that's what IKEv2 does. For (EC)DSA the hash algorithm to use is determined by the auth method (no way to mix algorithms) but the cipher and D-H group are not (something restricted by policy). Doing it one way or the other might not necessarily be good or bad but doing it both is. > Also there is no reason why the ECDSA RFC could not have added a new > transform type for HASH function, but it instead decided to use fixed > hash functions for the curves (just like we do for DSA in the IKEv1, > which always used SHA-1 as hash function when calculating signature, > regardless what was negotiated in the SA payloads for HASH). And in IKEv2 you got rid of the hash negotiation but retained the SHA-1 only nature of DSA regardless of the PRF being negotiated. Section 3.8 of RFC 5996 says: "DSS Digital Signature 3 Computed as specified in Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash." Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Mon, July 23, 2012 4:31 am, Johannes Merkle wrote:
>>
>> The particular curve can be determined from the subjectPublicKeyInfo.
>> Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool
>> curves.
>
> Actually, this is not strictly correct:
> ANSI X9.62 defies three ways to specify the curve (domain parameters) in a
> certificate (extracted from RFC 5480):
> ECParameters ::= CHOICE {
>namedCurve OBJECT IDENTIFIER
>implicitCurve NULL
>specifiedCurve SpecifiedECDomain
> }
> implicitCurve means that "the parameters are explicitly defined
> elsewhere".
>
> So we can safely assume that the parameters are available to a pier
> receiving the certificate of the other one.
>
>
> By the way: While RFC 5480 prohibits the use of implicitCurve and
> specifiedCurve, there are certainly still many
> implementations of RFC 3279 out there which allowed all three methods.
For a guy who's always reminding everyone about how there are many
implementations of an older RFC I should keep that in mind. Thank you
for pointing that out. But, as you note, RFC 5480 prohibits implicitCurve
and specificCurve so all we have left is namedCurve which is, as I noted,
how the particular curve can be determined from the subjectPublicKeyInfo.
>> If we're gonna recharter, maybe we should just work on an IKEv3
>> because
>> the problems in IKEv2 are becoming apparent. This "new authentication
>> mode"
>> suggestion, or the need for a "generic ECDSA" algorithm are just hacks
>> that
>> should not be necessary for a properly defined protocol. In addition,
>> the
>
> I do not agree. The generic definition of the ECDSA auth method is
> analogous to the auth methods defined for RSA and DSA
> keys, and thus, is rather the proper (canonical) way to define it than a
> hack.
> Of course, the fact than there are already 3 specific auth methods for
> ECDSA (which are not canonically defined) makes
> specification of a generic ECDSA method more cumbersome.
With RSA the hash algorithm is encoded into the padding so there is
no real need to independently agree on a hash algorithm. For DSA,
I disagree. The DSA algorithm definition is hash-specific so the hash-
specific ECDSA auth methods are the canonical way. Let me point
out, though, that canon law is not necessarily correct and this is an
example.
FIPS 186-3 (The Digital Signature Algorithm) specifies that security
strength levels of DSA are a minimum of the security strength of the
hash algorithm and the (L,N) pair from the domain parameter set. If
one wished to achieve a security strength level with DSA that would
be valid, according to NIST, "beyond 2030" one would need to use
SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature"
(authentication method value of 3) so that wouldn't work.
Given that SP 800-57 requires that 80 bits of strength only be used
through 2010 (and SHA-1 does not provide more than that) and it
is now 2012 it appears that IKEv2 is not capable of producing a
signature of sufficient strength for certain customers (they might not
be your's but they do exist, and there's probably more of them than
there are people clamoring for AES-XCBC MAC).
So to actually address this in the hash-specific canonical way
requires new auth methods for different permutations of DSS with
SHA-224, SHA-256, SHA-384, and SHA-512 as well as different
permutations of ECDSA with brainpool curves using the 5 different
SHA varients. But this is getting, as you say, "cumbersome".
Of course one can decide not to use the hash-specific canonical
technique and come up with "generic DSA" and "generic ECDSA" to
address this but then we have the unfortunate state of hash-specific
(EC)DSA methods and "generic" methods and now it's getting ugly
(and hack-ish).
Instead of either negotiating a complete ciphersuite (the way TLS
does) or individual components (the way IKEv1 did), IKEv2 does both
and gets the worst of both worlds.
Dan.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On 7/20/12 7:13 AM, Johannes Merkle wrote: Yoav, As Tero said, the signature algorithms can be specified in the 3 reserved bytes, but support for such things should be indicated in the Notify payload. Yes, I agree. How about standardizing just one more authentication method? Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload. After sleeping on your idea, I realize that it may work very well for ECDSA. The main problem with elliptic curve signature schemes is that there are so many different domain parameters. Tero has pointed out that the authentication methods registry for IKEv2 is only 8-bit, limiting the number of assignable methods. On the other hand, the domain parameters are specified in the subject public key info in the certificate, either explicitly (listing all parameters) or by reference (registered OID). Thus, it is possible to define an authentication method ECDSA_generic where the domain parameters are read from the certificate. One code point for an unlimited number of domain parameters. Just thought I'd point out here that in RFC 5480 the only option is namedCurve (i.e., OIDs). But, the brainpool curves all have OIDs assigned in RFC 5639. For the hash function to be used, there are several options: 1. An RFC could specify the default for each domain parameter set, e.g. SHA-256 for Brainpool Curve p-256. 2. Alternatively or a means to override the default setting, a hash algo ID could be encoded in the 3 reserved bytes in the authentication payload 3. Since the authentication payload has variable length, it could also include a leading byte specifying the hash algorithm. Of course, this contradicts the current specification of the ECDSA authentication payload from RFC4754, but RFC4754 specifies the encoding only for the specific NIST curves ECDSA authentication methods defined therein. Johannes ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
> Hmm... so the EC domain parameters can be seen from the certificate? I > wonder why did the RFC4753 then made separate allocations for each EC > group? As I wrote to Dan, there is actually also the option of not specifying the parameters in the cert, but this method (implicitCurve) is supposed to be used only if the parameters are known to the other pier by other means (e.g. by local configuration) > >>> I think we should have made the ECDSA support for IKEv2 in such way >>> that we had added some subfields to the authentication field, i.e. >>> only allocated one value for ECDSA and put the curve number inside the >>> authentication payload and perhaps even separated the hash algorithm >>> from it. There is 3 bytes of reserved data in the authentication >>> payload immediately after the auth method. Perhaps we could use those. >> >> Adding hash algorithm flexibility is of course a more general topic >> concerning not only ECDSA but also RSA and DSA. This is out-of-scope >> of our endeavor and should be discussed separately. > > We already have this same problem in the RSA, and we do assume that it > is not a problem in real life. I.e. every implementation will use hash > algorithm that is supported by other end. I.e. if some impementation > is SHA-1 only then certificates are also SHA-1 only and everybody uses > SHA-1, and if certificates uses SHA-2, then everybody using those > certificates do support both SHA-1 and SHA-2, and it does not really > matter which hash function is used... This is the reason why we do not Even if the pier supports both SHA-1 and all SHA-2 functions, it would require try-and-error to find out which one was used for the signature. Maybe in most cases the tier uses the same hash function as the CA, but this does not need to be the case. I know of large-scale PKIs, where the CAs use longer hash functions than the end entities. This can be motivated by the (indisputably) higher security requirements for CAs than for end users. >> You touch the same point as Yoav, who pointed out that a generalized >> authentication method (e.g. ECDSA_generic) would imply that the same >> certificate (for a key pair using one of the NIST curves listed in >> RFC 4754) could be used ith two different authentication methods. >> Yoav has suggested to indicate support for the general method in the >> Notify payload, another option could be to introduce a new transform >> type AUTH, so that support for this AUTH method is indicated in the >> SA payload. Again, this is a protocol extension that exceeds our >> intended scope, and should be specified separately. >> >> An alternative to avoid the interoperability problems with existing >> implementations of RFC 4754 could be to require that ECDSA_generic >> MUST not be used for the curves listed in RFC 4754, or that >> implementations encountering authentication failures by the other >> peer MUST re-try using the "old" authentication methods from RFC >> 4754. > > I think the way forward is to take this WG and as whether WG would be > willing to recharter and add new items to its charter: Accidentally, I included by response to this in my reply to Dan. For completeness, I will repeat it here. > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be >done as individual draft, and does not need to be WG item, but if >we are doing the rest in WG then I think this should also be WG >item too). I am not sure. If the rest is not specific for the Brainpool curves (e.g. defining a generic ECDSA auth method) it is not so clear that both efforts should be bundled. > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) >in the IKEv2. This may require new standard track RFC defining new >generic ECDSA method, and might also need solutions how hash >function is selected for each group. > According to the policy of the IANA registry for ath methods, standard track is not required but only IETF consensus, i.e. an informational WG document would suffice. > Then we can start thinking in the WG what would be the best way to > solve those problems. I think the correct solution would be to make > new ECDSA_generic method and specify where the domain parameters come > (both with certificates and with raw public keys), and we might want >From a cryptographic point of view, the correctness (and hence, the integrity >and authenticity) of the domain parameters is crucial, it is not a restriction to require that, if a raw (trusted) EC public key is used, the parameters must also be available by trusted means (e.g. local configuration). Johannes ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
>>
>> Hmm... so the EC domain parameters can be seen from the certificate? I
>> wonder why did the RFC4753 then made separate allocations for each EC
>> group?
>
> The particular curve can be determined from the subjectPublicKeyInfo.
> Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool
> curves.
Actually, this is not strictly correct:
ANSI X9.62 defies three ways to specify the curve (domain parameters) in a
certificate (extracted from RFC 5480):
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
implicitCurve NULL
specifiedCurve SpecifiedECDomain
}
implicitCurve means that "the parameters are explicitly defined elsewhere".
So we can safely assume that the parameters are available to a pier receiving
the certificate of the other one.
By the way: While RFC 5480 prohibits the use of implicitCurve and
specifiedCurve, there are certainly still many
implementations of RFC 3279 out there which allowed all three methods.
>
> I'm not so sure it makes sense to define a new hash algorithm per curve
> though. I would suggest just using the negotiated hash function. That is
> going to be used for key derivation and will influence the level of security
> that the exchange affords. That is, if you define SHA-384 to use with
> brainpoolP384r1 but the two sides end up using SHA-1 for key derivation
> then I'm not sure what using SHA-384 for authentication is buying you.
Others have already pointed out that the PRF does not need to be a hash
function. But even if it had to, the
requirements are different. For a digital signature, you need a hash function
to be collision resistant, while for PRF
you need good mixing properties and, in some circumstances, one-wayness. The
requirements for a PRF are much easier to
achieve, e.g. even MD5 is still considered one-way and has good mixing
properties, while collisions have been found.
>
> [snip]
>>
>> I think the way forward is to take this WG and as whether WG would be
>> willing to recharter and add new items to its charter:
>>
>> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be
>>done as individual draft, and does not need to be WG item, but if
>>we are doing the rest in WG then I think this should also be WG
>>item too).
I am not sure. If the rest is not specific for the Brainpool curves (e.g.
defining a generic ECDSA auth method) it is
not so clear that both efforts should be bundled.
>> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA)
>>in the IKEv2. This may require new standard track RFC defining new
>>generic ECDSA method, and might also need solutions how hash
>>function is selected for each group.
According to the policy of the IANA registry for ath methods, standard track is
not required but only IETF consensus,
i.e. an informational WG document would suffice.
> If we're gonna recharter, maybe we should just work on an IKEv3 because
> the problems in IKEv2 are becoming apparent. This "new authentication mode"
> suggestion, or the need for a "generic ECDSA" algorithm are just hacks that
> should not be necessary for a properly defined protocol. In addition, the
I do not agree. The generic definition of the ECDSA auth method is analogous to
the auth methods defined for RSA and DSA
keys, and thus, is rather the proper (canonical) way to define it than a hack.
Of course, the fact than there are already 3 specific auth methods for ECDSA
(which are not canonically defined) makes
specification of a generic ECDSA method more cumbersome.
> issues with the incorrect definition of representation of the result of an
> ECDH (it's the x-coordinate, not the concatenation of the x- and
> y-coordinates) that's lead to interoperability issues, and the inability to
> handle point compression all lead one to the conclusion that this stuff
> should all be fixed once and for all and fixed cleanly.
>
> Dan.
>
>
Johannes
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > And this points out to another unfortunate design decision of > IKEv2. Instead of negotiating a fundamental cryptographic primitive > like a hash function, it negotiates a derivative construct like a > PRF. IKEv2 does not need hash function anywehere, and because of that it does not define it. Also there are PRFs which are not derived from the hash functions (PRF_AES128_XCBC and PRF_AES128_CMAC). It is much better to negotiate the algorithm you are using (i.e. MAC and PRF) instead of some other function which is not used anywhere directly, and which may or may not be used to derive other functions (hash). > So instead of being able to use the negotiated hash function to > compute an ECDSA signature we're forced to eat through the "scarce > resource" of the authentication method registry. Very clumsy, very > hackish, very unfortunate. I disagree it being clumsy or hackish or unfortunate. It is just one way of designing the system. Some peole do want to make sure there is no way to mix algorithms of different strength. I myself think this should be something that is restricted by policy, not by protocol, but some people do disagree that and design systems differently. It is not necessarely bad or good, it is just different. Also there is no reason why the ECDSA RFC could not have added a new transform type for HASH function, but it instead decided to use fixed hash functions for the curves (just like we do for DSA in the IKEv1, which always used SHA-1 as hash function when calculating signature, regardless what was negotiated in the SA payloads for HASH). I think RFC4754 aimed for the suite-B compatibility and it aimed to support ECDSA levels suitable for AES-128, AES-192, and AES-256, thus selecting matching EC groups and hash functions is what they decided to do: 5. Security Considerations ... ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security comparable with the AES-128, AES-192, and AES-256 respectively. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
-Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Sunday, July 22, 2012 9:54 AM To: Tero Kivinen Cc: ipsec@ietf.org; Johannes Merkle; Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec > I don't know either, but I can guess. With RSA the hash is much smaller than > the signature (128-512 bits vs 1024-4096 > bits) so we use the PKCS#1 structure that also describes the hash. So you > don't need to specify the hash up front - > it's encoded in the signature itself. > > With ECDSA, the hashes are the same sizes as the signatures, so there's no > room within the signature to encode the > hash algorithm. You need to know what it is by some other means. A comment from the pedants-R-us gallery: well, you've come to the correct conclusion (there's no way to determine from an ECDSA signature the hash used to generate the signature), however the reasoning you used to get there is incorrect. The issue isn't the size of an ECDSA signature (for example, a signature based on the P256 curve is 512 bits long, and uses only 256 bits from the hash). Instead, the way RSA works allows recovery of the padded hash; we can take advantage of that to signify the hash method in the padding bits. In contrast, ECDSA does not allow the analogous operation; even if we padded the hash, we couldn't recover the padding anyways from the signature. We can certainly test if a specific hash value is the one that goes with the signature (that's what the signature verification operation is); however, it is infeasible to recover information about that value (for example, any bits that might signify padding). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Sun, July 22, 2012 6:53 am, Yoav Nir wrote: > > With ECDSA, the hashes are the same sizes as the signatures, so there's no > room within the signature to encode the hash algorithm. You need to know > what it is by some other means. So they chose to encode it using the AUTH > method. Not very economical in terms of protecting the scarce resource of > auth methods. Actually that's not true. The length of the digest of the hash algorithm is not the same as the length of the prime of the curve (what I think you mean by the "same size as the signatures" since the the signature is R|S). X9.62 says that the length of the digest of the hash is a kind of low-water mark of the desired security level. If the digest is larger than the length of the prime then you're supposed to take the left-most length-of-prime bits of the digest and use that to compute "s". And this points out to another unfortunate design decision of IKEv2. Instead of negotiating a fundamental cryptographic primitive like a hash function, it negotiates a derivative construct like a PRF. So instead of being able to use the negotiated hash function to compute an ECDSA signature we're forced to eat through the "scarce resource" of the authentication method registry. Very clumsy, very hackish, very unfortunate. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 22, 2012, at 4:15 PM, Tero Kivinen wrote: > Dan Harkins writes: >> We've been through nearly 40 revisions of this protocol (18 for IKEv2, >> another >> 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it >> still >> needs hacks to add some new elliptic curves-- either N new authentication >> modes for N curves, or a new unified and general ECDSA in addition to the >> existing 3 for ECDSA (!!!)-- > > You forgot the IKEv1 drafts too, as IKEv1 does the ECDSA at the same > way than IKEv2 (they both come from the same RFC), so they should also > be counted as revisions. > > And, no, I have no idea why the people who added ECDSA did add it that > way. I don't know either, but I can guess. With RSA the hash is much smaller than the signature (128-512 bits vs 1024-4096 bits) so we use the PKCS#1 structure that also describes the hash. So you don't need to specify the hash up front - it's encoded in the signature itself. With ECDSA, the hashes are the same sizes as the signatures, so there's no room within the signature to encode the hash algorithm. You need to know what it is by some other means. So they chose to encode it using the AUTH method. Not very economical in terms of protecting the scarce resource of auth methods. My suggestion only improves this by making each curve go with a specific hash (specified in the document, not in the protocol). And you can probably replace the hashes with their SHA-3 (or GOST) equivalents by using the reserved fields in the AUTH payload. Regardless of what we do with the Brainpool curves, we also need to be ready for vanity curves, and there's no telling how many we're going to have. openssl/crypto/ec/ec_curve.c has several dozens of them, and I wouldn't want us to have to fight over allocation for each new curve. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > We've been through nearly 40 revisions of this protocol (18 for IKEv2, > another > 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it > still > needs hacks to add some new elliptic curves-- either N new authentication > modes for N curves, or a new unified and general ECDSA in addition to the > existing 3 for ECDSA (!!!)-- You forgot the IKEv1 drafts too, as IKEv1 does the ECDSA at the same way than IKEv2 (they both come from the same RFC), so they should also be counted as revisions. And, no, I have no idea why the people who added ECDSA did add it that way. I always assumed that there is no way to know the domain parameters and hash from the cert / signature, and thats why they needed to be encoded to the auth algorithm field. Now it seems my assumption was incorrect. But with the patent issues with elliptic curves, nobody really used EC, thus nobody really cared... (at least for me the reason I did not care about EC was those patent issues, and also as there was no real customer demand for them, or to say that the customer demand usually went away when they heard there are patent issues). > and even still there will be interoperability issues because some > people represent an ECDH shared secret as x||y and others represent > it as x. Yes, this just points how little people cared. Some people did notice it, but just assumed that ok, they just wanted to things differently and changed their code to do what original RFC4753 defined. Fixing that kind of problem with errata, was really bad mistake. And I still think fixing that problem without allocating new numbers were again mistake, but I lost that fight. Also it took several years before this issue was even noticed, that tells how little EC groups are really used (either in IKEv1 or IKEv2, as the same mistake was in both of them). > Notice how the Notify payload is becoming the overloaded payload of choice > to "fix" everything? It's hacked for EAP-only, it's hacked for secure > passwords, and it's the method of choice to hack in new curves. Yuck. I do not think notify payload has "become the overloaded payload of choice", it was originally defined in IKEV2 for that purposes also: -- 3.10. Notify Payload ... in any other message to indicate sender capabilities or to modify the meaning of the request. -- The main reason why notify is used in the IKEv2, is that it is secure (compared to IKEv1, where it cannot be used as it is not authenticated in phase 1) and easy way to do capability indications. I myself think notify payload is much better than using vendor ID payloads which was normally done in IKEv1. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > I'm not so sure it makes sense to define a new hash algorithm per curve > though. I would suggest just using the negotiated hash function. That is We do not negotiate hash function in IKEv2. We do negotiate Pseudo-random function (PRF) and Integrity Algorithm (MAC), but there is no HASH function negotiated. > going to be used for key derivation and will influence the level of security > that the exchange affords. That is, if you define SHA-384 to use with > brainpoolP384r1 but the two sides end up using SHA-1 for key derivation > then I'm not sure what using SHA-384 for authentication is buying you. IKEv2 do not use hash function for key deriviation it uses PRF for that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Sat, July 21, 2012 10:50 am, Yoav Nir wrote: > > On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote: > >> On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: [snip] >>> I think the way forward is to take this WG and as whether WG would be >>> willing to recharter and add new items to its charter: >>> >>> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be >>> done as individual draft, and does not need to be WG item, but if >>> we are doing the rest in WG then I think this should also be WG >>> item too). >>> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) >>> in the IKEv2. This may require new standard track RFC defining new >>> generic ECDSA method, and might also need solutions how hash >>> function is selected for each group. >> >> If we're gonna recharter, maybe we should just work on an IKEv3 because >> the problems in IKEv2 are becoming apparent. This "new authentication >> mode" >> suggestion, or the need for a "generic ECDSA" algorithm are just hacks >> that >> should not be necessary for a properly defined protocol. In addition, >> the >> issues with the incorrect definition of representation of the result of >> an >> ECDH (it's the x-coordinate, not the concatenation of the x- and >> y-coordinates) that's lead to interoperability issues, and the inability >> to >> handle point compression all lead one to the conclusion that this stuff >> should all be fixed once and for all and fixed cleanly. > > In 6 years IKEv2 has gained very little traction. All major vendors offer > it, but it's still not the default setting for any of them. It would be as > bad as saying that IPv6 has problems, so we should begin work on IPv8. We've been through nearly 40 revisions of this protocol (18 for IKEv2, another 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it still needs hacks to add some new elliptic curves-- either N new authentication modes for N curves, or a new unified and general ECDSA in addition to the existing 3 for ECDSA (!!!)-- and even still there will be interoperability issues because some people represent an ECDH shared secret as x||y and others represent it as x. Notice how the Notify payload is becoming the overloaded payload of choice to "fix" everything? It's hacked for EAP-only, it's hacked for secure passwords, and it's the method of choice to hack in new curves. Yuck. It's not apparent to me that the reasons for lack of deployment of IKEv2 are in any way similar to those of IPv6 (and, frankly, I would tend to doubt there is any relationship). It may be "bad" to say that we have a problem, but it's worse to deny that the problem exists. The first step to actually addressing one's problems of dysfunction is admitting to them. Let me begin: "Hello! My name is Dan. We have a problem." Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
-Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Saturday, July 21, 2012 1:51 PM To: Dan Harkins Cc: ipsec@ietf.org; Johannes Merkle; Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec > Not much, but not all PRF functions are hashes. What hash will you use if > your PRF is AES-XCBC? What if it's GHash? > Sure we could extend both those to be hash functions (just use AES-XCBC with > a fixed key) but we've never done this > before, and I don't have any idea if the cryptographers will approve. Cryptographers would certainly not approve; it's easy to generate preimages for AES-XCBC or GHash with a public key. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote: > > On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: >> Johannes Merkle writes: Adding them for authentication use (ECDSA use) will most likely get more opposition. First of all, I am not at all happy how the ECDSA groups are added to the IKEv2 authentication method. The authentication methods registry is only 8-bit in IKEv2 (it is 16-bit registry in IKEv1). This does not matter if we have only few ECDSA groups with one hash algorithm for each, but when we are adding more groups it seems to bad idea for each of them having separate number. Especially if someone later decides that they want to use all ECDSA groups with SHA 3 too... >>> >>> Today, I responded to Yoav's idea of taking algorithms details from >>> the certificate. At least the EC domain parameters could be taken >>> from it, and for the hash function, a default could be defined per >>> curve. So one new authentication method ECDSA_generic or >>> ECDSA_cert_defined could be sued for any EC domain parameters. >> >> Hmm... so the EC domain parameters can be seen from the certificate? I >> wonder why did the RFC4753 then made separate allocations for each EC >> group? > > The particular curve can be determined from the subjectPublicKeyInfo. > Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool > curves. > > I'm not so sure it makes sense to define a new hash algorithm per curve > though. I would suggest just using the negotiated hash function. That is > going to be used for key derivation and will influence the level of security > that the exchange affords. That is, if you define SHA-384 to use with > brainpoolP384r1 but the two sides end up using SHA-1 for key derivation > then I'm not sure what using SHA-384 for authentication is buying you. Not much, but not all PRF functions are hashes. What hash will you use if your PRF is AES-XCBC? What if it's GHash? Sure we could extend both those to be hash functions (just use AES-XCBC with a fixed key) but we've never done this before, and I don't have any idea if the cryptographers will approve. > [snip] >> >> I think the way forward is to take this WG and as whether WG would be >> willing to recharter and add new items to its charter: >> >> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be >> done as individual draft, and does not need to be WG item, but if >> we are doing the rest in WG then I think this should also be WG >> item too). >> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) >> in the IKEv2. This may require new standard track RFC defining new >> generic ECDSA method, and might also need solutions how hash >> function is selected for each group. > > If we're gonna recharter, maybe we should just work on an IKEv3 because > the problems in IKEv2 are becoming apparent. This "new authentication mode" > suggestion, or the need for a "generic ECDSA" algorithm are just hacks that > should not be necessary for a properly defined protocol. In addition, the > issues with the incorrect definition of representation of the result of an > ECDH (it's the x-coordinate, not the concatenation of the x- and > y-coordinates) that's lead to interoperability issues, and the inability to > handle point compression all lead one to the conclusion that this stuff > should all be fixed once and for all and fixed cleanly. In 6 years IKEv2 has gained very little traction. All major vendors offer it, but it's still not the default setting for any of them. It would be as bad as saying that IPv6 has problems, so we should begin work on IPv8. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: > Johannes Merkle writes: >> > Adding them for authentication use (ECDSA use) will most likely get >> > more opposition. First of all, I am not at all happy how the ECDSA >> > groups are added to the IKEv2 authentication method. The >> > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit >> > registry in IKEv1). This does not matter if we have only few ECDSA >> > groups with one hash algorithm for each, but when we are adding more >> > groups it seems to bad idea for each of them having separate number. >> > Especially if someone later decides that they want to use all ECDSA >> > groups with SHA 3 too... >> >> Today, I responded to Yoav's idea of taking algorithms details from >> the certificate. At least the EC domain parameters could be taken >> from it, and for the hash function, a default could be defined per >> curve. So one new authentication method ECDSA_generic or >> ECDSA_cert_defined could be sued for any EC domain parameters. > > Hmm... so the EC domain parameters can be seen from the certificate? I > wonder why did the RFC4753 then made separate allocations for each EC > group? The particular curve can be determined from the subjectPublicKeyInfo. Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool curves. I'm not so sure it makes sense to define a new hash algorithm per curve though. I would suggest just using the negotiated hash function. That is going to be used for key derivation and will influence the level of security that the exchange affords. That is, if you define SHA-384 to use with brainpoolP384r1 but the two sides end up using SHA-1 for key derivation then I'm not sure what using SHA-384 for authentication is buying you. [snip] > > I think the way forward is to take this WG and as whether WG would be > willing to recharter and add new items to its charter: > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be >done as individual draft, and does not need to be WG item, but if >we are doing the rest in WG then I think this should also be WG >item too). > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) >in the IKEv2. This may require new standard track RFC defining new >generic ECDSA method, and might also need solutions how hash >function is selected for each group. If we're gonna recharter, maybe we should just work on an IKEv3 because the problems in IKEv2 are becoming apparent. This "new authentication mode" suggestion, or the need for a "generic ECDSA" algorithm are just hacks that should not be necessary for a properly defined protocol. In addition, the issues with the incorrect definition of representation of the result of an ECDH (it's the x-coordinate, not the concatenation of the x- and y-coordinates) that's lead to interoperability issues, and the inability to handle point compression all lead one to the conclusion that this stuff should all be fixed once and for all and fixed cleanly. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Johannes Merkle writes: > > Adding them for authentication use (ECDSA use) will most likely get > > more opposition. First of all, I am not at all happy how the ECDSA > > groups are added to the IKEv2 authentication method. The > > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit > > registry in IKEv1). This does not matter if we have only few ECDSA > > groups with one hash algorithm for each, but when we are adding more > > groups it seems to bad idea for each of them having separate number. > > Especially if someone later decides that they want to use all ECDSA > > groups with SHA 3 too... > > Today, I responded to Yoav's idea of taking algorithms details from > the certificate. At least the EC domain parameters could be taken > from it, and for the hash function, a default could be defined per > curve. So one new authentication method ECDSA_generic or > ECDSA_cert_defined could be sued for any EC domain parameters. Hmm... so the EC domain parameters can be seen from the certificate? I wonder why did the RFC4753 then made separate allocations for each EC group? > > I think we should have made the ECDSA support for IKEv2 in such way > > that we had added some subfields to the authentication field, i.e. > > only allocated one value for ECDSA and put the curve number inside the > > authentication payload and perhaps even separated the hash algorithm > > from it. There is 3 bytes of reserved data in the authentication > > payload immediately after the auth method. Perhaps we could use those. > > Adding hash algorithm flexibility is of course a more general topic > concerning not only ECDSA but also RSA and DSA. This is out-of-scope > of our endeavor and should be discussed separately. We already have this same problem in the RSA, and we do assume that it is not a problem in real life. I.e. every implementation will use hash algorithm that is supported by other end. I.e. if some impementation is SHA-1 only then certificates are also SHA-1 only and everybody uses SHA-1, and if certificates uses SHA-2, then everybody using those certificates do support both SHA-1 and SHA-2, and it does not really matter which hash function is used... This is the reason why we do not explictly define what hash function needs to be used with RSA. > You touch the same point as Yoav, who pointed out that a generalized > authentication method (e.g. ECDSA_generic) would imply that the same > certificate (for a key pair using one of the NIST curves listed in > RFC 4754) could be used ith two different authentication methods. > Yoav has suggested to indicate support for the general method in the > Notify payload, another option could be to introduce a new transform > type AUTH, so that support for this AUTH method is indicated in the > SA payload. Again, this is a protocol extension that exceeds our > intended scope, and should be specified separately. > > An alternative to avoid the interoperability problems with existing > implementations of RFC 4754 could be to require that ECDSA_generic > MUST not be used for the curves listed in RFC 4754, or that > implementations encountering authentication failures by the other > peer MUST re-try using the "old" authentication methods from RFC > 4754. I think the way forward is to take this WG and as whether WG would be willing to recharter and add new items to its charter: 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be done as individual draft, and does not need to be WG item, but if we are doing the rest in WG then I think this should also be WG item too). 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) in the IKEv2. This may require new standard track RFC defining new generic ECDSA method, and might also need solutions how hash function is selected for each group. Then we can start thinking in the WG what would be the best way to solve those problems. I think the correct solution would be to make new ECDSA_generic method and specify where the domain parameters come (both with certificates and with raw public keys), and we might want to give some kind of implementation guidelines to the hash algorithm selection, or we might even define a way to specify it. > > I have been under impression that the point compression is one of > > those items which are patented and that is the reason why it is not > > This is not an issue. According to > http://cr.yp.to/patents/us/6141420.html the patent is almost > certainly invalid because its authors revealed the (known) existence > of prior art to the patent office, and furthermore, the patent > expires in 2014. We cannot really say whether some patent is invalid or not, but on the other hand saying it will expire 2014 is something that will help... > > > been used in the IKEv2. Also as I said earlier the authentication > > methods are not negotiated, thus if one ends send KE payload in point > > compressed format and other end does not implement point compre
Re: [IPsec] Using ECC Brainpool curves with ipsec
Tero, thank you for your valuable answers. Please find my responses below. >> [Question 0] Is the WG interested in shepherding an RFC specifying >> all that's necessary to use the Brainpool curves in ipsec? And what >> category would be preferred, standard track or informational. > > I think it might be good idea to get some usable elliptic curves too. > The groups 19-21 is mostly unusable now as we messed up with their > format in the original RFC4753 and they changes we made in RFC5903 are > not backward compatible with the original RFC4753 and the > interoperability problem just causes timeout on the initiator. This is a good argument. Another one is that it is always advisable to have more than one curve per bit length just in case that new cryptanalytic results point out weaknesses in one of them. Moreover, the fact that the selection of the seeds, from which the NIST curves have been generated, is not explained might also be considered as a missing link in their property of being verifiably pseudo-random. > >> [Question 1] Should we include IKEv1 in the specs as well? It seems >> that some people in the WG do not like the idea of updating this >> obsolete protocol. On the other hand, many applications still use >> IKEv1 and specifying the use of the Brainpool curves only for IKEv2 >> would exclude these. > > I would be strongly against for including support for protocol which > has been obsoleted 7 years ago. If people want to use this kind of > groups in IKEv1 they can use the new group mode and negotiate groups > on the fly. There is no need to add them to IKEv1. > I have followed your dispute with Dan and do not take a clear position here as I have not your experience with standardization of protocols. For me, IKEv1 does not have high priority, and I mainly aim at using the Brainpool curves with IKEv2. >> [Question 2] If IKEv1 is to be considered, the registry for IPSEC >> Authentication Methods (Value 3) needs to be updated, because the >> values for ECDSA are specific for each curve. What policy for >> updating this IANA registry can be assumed? IANA currently requires >> a standard track RFC, but there has recently been some discussion on >> relaxing this, in particular, >> http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and >> http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . >> For the corresponding IKEv2 registry (Auth Method), only Expert >> Review is required. > > Hmm... So you are talking adding them for both Diffie-Hellman and > ECDSA uses? > Yes, sorry for not stating this clearly. Why should an implementation use another parameter set for the signature as for the key exchange unless the other peer doesn't support the primary parameters? In particular, implementations in constraint environments would benefit from the option of using only a single set of domain parameters. > Adding them for authentication use (ECDSA use) will most likely get > more opposition. First of all, I am not at all happy how the ECDSA > groups are added to the IKEv2 authentication method. The > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit > registry in IKEv1). This does not matter if we have only few ECDSA > groups with one hash algorithm for each, but when we are adding more > groups it seems to bad idea for each of them having separate number. > Especially if someone later decides that they want to use all ECDSA > groups with SHA 3 too... Today, I responded to Yoav's idea of taking algorithms details from the certificate. At least the EC domain parameters could be taken from it, and for the hash function, a default could be defined per curve. So one new authentication method ECDSA_generic or ECDSA_cert_defined could be sued for any EC domain parameters. > > I think we should have made the ECDSA support for IKEv2 in such way > that we had added some subfields to the authentication field, i.e. > only allocated one value for ECDSA and put the curve number inside the > authentication payload and perhaps even separated the hash algorithm > from it. There is 3 bytes of reserved data in the authentication > payload immediately after the auth method. Perhaps we could use those. Adding hash algorithm flexibility is of course a more general topic concerning not only ECDSA but also RSA and DSA. This is out-of-scope of our endeavor and should be discussed separately. > > It is most likely too late now, but we still want to make sure we do > not allocate too many entries from that registry, i.e. is there need > to add all the groups in there, do we really need that many different > strengths? Which hash algorithm do we use with what group? > > Also note, that authentication methods are not negotiated in IKEv2, > i.e. there is no way to know whether the other end supports the > authentication algorithm you wanted to use. On the other hand as you > need to have credentials for the other end you are using, so most > if other end woul
Re: [IPsec] Using ECC Brainpool curves with ipsec
Yoav, > As Tero said, the signature algorithms can be specified in the 3 reserved > bytes, but support for such things should be indicated in the Notify payload. Yes, I agree. > How about standardizing just one more authentication method? > > Call it "public key signature" or some such, and make the signing algorithm > depend on the public key in the CERT payload. > After sleeping on your idea, I realize that it may work very well for ECDSA. The main problem with elliptic curve signature schemes is that there are so many different domain parameters. Tero has pointed out that the authentication methods registry for IKEv2 is only 8-bit, limiting the number of assignable methods. On the other hand, the domain parameters are specified in the subject public key info in the certificate, either explicitly (listing all parameters) or by reference (registered OID). Thus, it is possible to define an authentication method ECDSA_generic where the domain parameters are read from the certificate. One code point for an unlimited number of domain parameters. For the hash function to be used, there are several options: 1. An RFC could specify the default for each domain parameter set, e.g. SHA-256 for Brainpool Curve p-256. 2. Alternatively or a means to override the default setting, a hash algo ID could be encoded in the 3 reserved bytes in the authentication payload 3. Since the authentication payload has variable length, it could also include a leading byte specifying the hash algorithm. Of course, this contradicts the current specification of the ECDSA authentication payload from RFC4754, but RFC4754 specifies the encoding only for the specific NIST curves ECDSA authentication methods defined therein. Johannes ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > > Brainpool groups do not have number in the IANA registry, which makes > > them private for IKEv1 use. There is nothing there claiming that you > > can only use new group mode to negotiate groups that are not know for > > anybody else. > > "Brainpool groups do not have a number in the IANA registry". What do you > think the topic of this thread is? Look at the subject above. > > You are arguing against doing something because it hasn't been done yet > and that is illogical. No, I am arguing against it as Brainpool groups CAN ALREADY BE USED in IKEv1 without any changes to the specifications, or to the implementations. IKEv1 does not require every single group to be coded in to every implementation. > You know what? IKEv2 doesn't have any brainpool groups defined in its > IANA registry. Are you against such a code point allocation? If not, then > can I please ask you to be consistent in your positions? IKEv2 cannot use groups which do not have number allocated. There is no way to use brainpool groups in IKEv2 now. Thats why I do think adding them to the IKEv2 IANA registry is something that should be done. IKEv1 and IKEv2 situation is completely different because of that, i.e existing IKEv1 implementation can already use brainpool groups, IKEv2 implementations cannot. > Furthermore, not all implementations support domain parameter sets > being passed in SA payloads (do any?) or New Group Mode so what you > are advocating for causes more of the problems you are trying to use to > justify your advocacy. Our IKEv1 implemention 15 years ago did support both passing them in SA payloads and inside new group mode. I do not know about others. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Hi Johannes, On 7/3/12 11:59 AM, "Johannes Merkle" wrote: >Hi, > >in RFC 5639, we have specified a new set of elliptic curve parameters for >use in cryptographic applications. Meanwhile, >support for these "Brainpool Curves" has been included in some crypto >libraries as openssl (recently) and crypto++. >However, in order to use the Brainpool Curves with IKE and IPSec, still >some specifications and IANA registry updates >are needed. We are now planning to prepare such an RFC to allow usage of >the ECC Brainpool curves with ipsec. > >In order to go forward with this effort, we would like to discuss some >questions and potential issues. The WG feedback >on these is most appreciated. > >[Question 0] Is the WG interested in shepherding an RFC specifying all >that's necessary to use the Brainpool curves in >ipsec? And what category would be preferred, standard track or >informational. I think it could be reasonable to define new IKE groups based on RFC 5639. We need to avoid adding complexity to the IPsec RFC family and its implementations, so it would be important to align the use of new groups as much as possible to the existing uses of ECC in IKE, and to clarify the intended use of the new IKE groups. For instance, when should the new IKE groups be used? Which of the new groups is recommended for use? What other crypto algorithms should be used with each of those groups, to form an acceptable security policy? What are the technical merits of these new groups? I encourage you to take up these questions in your draft. Ideally, any new ECP ECC groups would retain as much of RFC 5903 as possible, such as Section 7 of that RFC, would include test cases, and would be compatible with RFC 6090. > >[Question 1] Should we include IKEv1 in the specs as well? It seems that >some people in the WG do not like the idea of >updating this obsolete protocol. On the other hand, many applications >still use IKEv1 and specifying the use of the >Brainpool curves only for IKEv2 would exclude these. The important question here is: are the anticipated users of RFC 5639 in IPsec able to use IKEv2? Perhaps this could be considered in the draft that you are planning. I would guess that the answer for most would be "yes". Currently, the main driver for the use of ECC in IPsec is RFC 6380, which requires IKEv2. > >[Question 2] If IKEv1 is to be considered, the registry for IPSEC >Authentication Methods (Value 3) needs to be updated, >because the values for ECDSA are specific for each curve. What policy for >updating this IANA registry can be assumed? >IANA currently requires a standard track RFC, but there has recently been >some discussion on relaxing this, in >particular, >http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and >http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . >For the corresponding IKEv2 registry (Auth Method), only Expert Review is >required. > >[Question 3] If IKEv1 is to be considered, it seems reasonable to write >only one RFC covering IKEv1 and IKEv2. Actually, >we also plan to prepare analogous specifications for TLS, so an option >would be to write a common RFC for IKE and TLS >analogously to RFC 5114. However, according to the update policy of the >IANA registry EC Named Curve for TLS, such an >RFC would have to be shepherded by the tls WG. Does this prevent or >considerably complicate the creation of a joint RFC >for IKE and TLS? Would preparing separate RFCs for IKE and TLS be >preferable? > >[Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, >320, 384, 512 two curves are defined, one >being the ³quadratic twist² of the other their algebraic structure (and >hence, security level) is equivalent, but one >of them allows particular efficient arithmetic. In order to leave the >choice of the curve for a given bit length to the >implementation we propose to register IANA values (for Auth method and >Diffie-Hellman Group) for both curves for each >bit length. Of course, this doubles the number of number assignments. Any >objections on this? No objection, there are about 1000 values available, and using 14 seems reasonable. > >[Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but >also ECGDSA (Elliptic Curve German Digital >Signature Algorithm) according to ISO 14888-3, which is a slight variant >of ECDSA. The advantage of ECGDSA over ECDSA is >that signature generation does not need any inversion modulo the group >order, which removes the necessity of >corresponding code. This advantage is particularly interesting when using >devices with limited computation power and >storage like smart cards or electronic control units in cars. In >particular, car manufacturers have expressed their >desire to deviate from EDSA For this reason, we would like to specify >values for ECGDSA (with the individual bit lengths >and curves) as Authentication Method as well. Would the WG support >inclusion of this additional signature
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 19, 2012, at 1:43 PM, Johannes Merkle wrote: >> >> How about standardizing just one more authentication method? >> >> Call it "public key signature" or some such, and make the signing algorithm >> depend on the public key in the CERT payload. >> >> If it's RSA, go by bit strength: >> - <=1024 - SHA-1 with RSA >> - 1024> - 2048> - >4096 - SHA2-512 with RSA >> >> DSA - always SHA-1 >> >> ECDSA will be defined by curve. The three NIST curves that everyone uses >> already have hashes associated with them. Any new curve would have to >> specify the signature algorithm in the same document. >> > > Adding new methods giving more flexibility seems a good approach but, > unfortunately, your proposal would not offer the > flexibility you aim at: > > The Subject Public Key Algorithm OID typically used in certs are defined in > RFC 3279 and these do not specify the > signature algorithm. For RSA, the RSAPublicKey OID allows both > RSASSA-PKCS1-v1_5 and RSASSA-PSS (currently, only an > authentication method for the former is specified but the latter is > definitely to be used in the future). For > RSASSA-PSS, more specific public key types are specified in RFC 4055 but use > of the old key identifiers is still > permitted and very common. In case of ECC keys, the identifier id-ecPublicKey > does also not specify the signature > algorithm. > > Thus, unless you want to enforce usage of the id-RSASSA-PSS OID from RFC 4055 > for (future) RSASA-PSS keys and restrict > ECC keys to ECDSA (thus, not allowing the future use any other EC-based > signature algorithm apart from ECDSA), any new > authentication method should at least specify the signature algorithm (e.g. > RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA). As > Tero suggested, the specification of the domain parameters and hash function > could possibly be required using the 3 > bytes of reserved data in the authentication payload immediately after the > auth method. As Tero said, the signature algorithms can be specified in the 3 reserved bytes, but support for such things should be indicated in the Notify payload. Yoav > It appears to me that an enhanced flexibility is also needed for the existing > RSASSA-PKCS1-v1_5 method as soon as other > hash functions than SH-1 are to be used. RFC 5996 is not very convincing in > its description how this can be accomplished: > > --- begin extract --- > Implementations can use the > certificates received from a given peer as a hint for selecting a > mutually understood hash function for the AUTH payload signature. > > Note, however, that the hash algorithm used in the AUTH payload > signature doesn't have to be the same as any hash algorithm(s) > used in the certificate(s). > --- end extract --- > > So implementations are supposed to use the hash algo used by the CA (!) as an > indication on what the peer uses, although > this does not need to be reliable? This seems to me as a lack of proper > specification. > > Johannes > > >> Since the same certificate can be used with both the old authentication >> method and the new, we'd have to signal support in a Notify, and that Notify >> could have bits for indicating support for other signature algorithms such >> as those that go with SHA3. >> >> Wouldn't this make adding future curves and other signature variants easier? >> >> Yoav >> >> > > -- > > Mit freundlichen Grüßen, > Johannes Merkle > -- > Dr. Johannes Merkle > Principal > Biometrie & Hoheitliche Dokumente > secunet Security Networks AG > Mergenthaler Allee 77 > 65760 Eschborn > Germany > Telefon +49 201 54 54-3091 > Telefax +49 201 54 54-1325 > Mobil +49 175 2224439 > johannes.mer...@secunet.com > www.secunet.com > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
> > How about standardizing just one more authentication method? > > Call it "public key signature" or some such, and make the signing algorithm > depend on the public key in the CERT payload. > > If it's RSA, go by bit strength: > - <=1024 - SHA-1 with RSA > - 1024 - 2048 - >4096 - SHA2-512 with RSA > > DSA - always SHA-1 > > ECDSA will be defined by curve. The three NIST curves that everyone uses > already have hashes associated with them. Any new curve would have to specify > the signature algorithm in the same document. > Adding new methods giving more flexibility seems a good approach but, unfortunately, your proposal would not offer the flexibility you aim at: The Subject Public Key Algorithm OID typically used in certs are defined in RFC 3279 and these do not specify the signature algorithm. For RSA, the RSAPublicKey OID allows both RSASSA-PKCS1-v1_5 and RSASSA-PSS (currently, only an authentication method for the former is specified but the latter is definitely to be used in the future). For RSASSA-PSS, more specific public key types are specified in RFC 4055 but use of the old key identifiers is still permitted and very common. In case of ECC keys, the identifier id-ecPublicKey does also not specify the signature algorithm. Thus, unless you want to enforce usage of the id-RSASSA-PSS OID from RFC 4055 for (future) RSASA-PSS keys and restrict ECC keys to ECDSA (thus, not allowing the future use any other EC-based signature algorithm apart from ECDSA), any new authentication method should at least specify the signature algorithm (e.g. RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA). As Tero suggested, the specification of the domain parameters and hash function could possibly be required using the 3 bytes of reserved data in the authentication payload immediately after the auth method. It appears to me that an enhanced flexibility is also needed for the existing RSASSA-PKCS1-v1_5 method as soon as other hash functions than SH-1 are to be used. RFC 5996 is not very convincing in its description how this can be accomplished: --- begin extract --- Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. Note, however, that the hash algorithm used in the AUTH payload signature doesn't have to be the same as any hash algorithm(s) used in the certificate(s). --- end extract --- So implementations are supposed to use the hash algo used by the CA (!) as an indication on what the peer uses, although this does not need to be reliable? This seems to me as a lack of proper specification. Johannes > Since the same certificate can be used with both the old authentication > method and the new, we'd have to signal support in a Notify, and that Notify > could have bits for indicating support for other signature algorithms such as > those that go with SHA3. > > Wouldn't this make adding future curves and other signature variants easier? > > Yoav > > -- Mit freundlichen Grüßen, Johannes Merkle -- Dr. Johannes Merkle Principal Biometrie & Hoheitliche Dokumente secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.mer...@secunet.com www.secunet.com ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Jul 18, 2012, at 9:45 PM, Tero Kivinen wrote: > Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman > use requires updating of one expert review 16-bit registry for IKEv2. > The same registry in the IKEv1 is RFC required, so it does not require > standard track RFC. > > Adding them for authentication use (ECDSA use) will most likely get > more opposition. First of all, I am not at all happy how the ECDSA > groups are added to the IKEv2 authentication method. The > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit > registry in IKEv1). This does not matter if we have only few ECDSA > groups with one hash algorithm for each, but when we are adding more > groups it seems to bad idea for each of them having separate number. > Especially if someone later decides that they want to use all ECDSA > groups with SHA 3 too... > > I think we should have made the ECDSA support for IKEv2 in such way > that we had added some subfields to the authentication field, i.e. > only allocated one value for ECDSA and put the curve number inside the > authentication payload and perhaps even separated the hash algorithm > from it. There is 3 bytes of reserved data in the authentication > payload immediately after the auth method. Perhaps we could use those. How about standardizing just one more authentication method? Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload. If it's RSA, go by bit strength: - <=1024 - SHA-1 with RSA - 10244096 - SHA2-512 with RSA DSA - always SHA-1 ECDSA will be defined by curve. The three NIST curves that everyone uses already have hashes associated with them. Any new curve would have to specify the signature algorithm in the same document. Since the same certificate can be used with both the old authentication method and the new, we'd have to signal support in a Notify, and that Notify could have bits for indicating support for other signature algorithms such as those that go with SHA3. Wouldn't this make adding future curves and other signature variants easier? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Wed, July 18, 2012 5:14 pm, Tero Kivinen wrote: > Dan Harkins writes: >> Nobody said anything about "adding everything". That is a complete >> straw >> man argument. In fact, it is decidedly not the case that "everything" is >> being >> added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so >> quick >> to leap to unfounded conclusions you would see this IANA update as the >> innocuous event that it really is. > > Not if you count the authentication methods in to it too. That do > require quite a bit of work to make sure everything is done correctly. > > Especially as IKEv1 exchanges are quite different depending which > authentication method is used. Adding only the Diffie-Hellman groups > is much easier, but I understood that the idea was to add both. > > And for SPSK there was also text for adding that to IKEv1 too, before > it was removed. Same is now with the ike-over-tcp, which again has > IKEv1 text in it. EXACTLY!!! That is what I was saying. "everything" is not being added to IKEv1 and we have documented evidence, you even provided another example. So your statement that this innocuous addition of code points to a registry is somehow "adding everything" is just hyperbole. >> This is allowing existing implementations to have more flexibility in >> the >> ECDH operations they perform to comply with various requirements that >> may exist in different locales or in different circumstances or >> situations. > > I would think the ECP groups we already have in the IKEv1 should be > enough for the most common case, i.e. the suite-b uses. Also I still > do not think that many implementations are going to update their IKEv1 > implementations. The brainpool curves have been defined for a purpose that, apparently, the NIST-defined curves does not satisfy. And your statement about "many implementations" is belied by your behavior. Why would someone be such a vocal advocate of a law that is not necessary? [snip] > So what is wrong with using the already existing mechanisms of using > groups directly in the SA for that already obsoleted protocol? It > seems the only reason to add numbers for them is to support non IPsec > use... They are for the situations in which the brainpool curves are necessary. That is not "to support non-IPsec use". That is not why the brainpool curves were defined. >> > This is exactly why new group mode was made a SHOULD in the IKEv1, >> > i.e. to allow adding new groups without need to changing the >> > specification or the actual code. >> >> Your recollection differs from the person who actually wrote the RFC. >> And when that happens one should typically defer to the author. In fact, >> your statement seems to differ from the RFC which says it SHOULD be >> supported as a mechanism to define "private groups". The brainpool >> groups are not private and there is no reason to treat them as such. > > Brainpool groups do not have number in the IANA registry, which makes > them private for IKEv1 use. There is nothing there claiming that you > can only use new group mode to negotiate groups that are not know for > anybody else. "Brainpool groups do not have a number in the IANA registry". What do you think the topic of this thread is? Look at the subject above. You are arguing against doing something because it hasn't been done yet and that is illogical. You know what? IKEv2 doesn't have any brainpool groups defined in its IANA registry. Are you against such a code point allocation? If not, then can I please ask you to be consistent in your positions? [snip] > I have never tried to hide the fact that I think IKEv2 is much better > protocol than IKEv1. IKEv1 do have some security problems (not big > enough to cause it to fail completely, but they are there). IKEv1 does > not have standardized support for many things that are there for > IKEv2. Many IKEv1 implementations uses methods described in the > expired Internet-drafts for some things, and there are multiple of > those methods different implementations use. > > I think IKEv1 needs to DIE. It is so broken I see no reason for it to > kept alive anymore. I do not want anybody to add anything to it for > two reasons: > > 1) I am the implementor who might need to implement them in our code. >Up to this point I have been able to say we do not want to do any >changes to IKEv1 code. > 2) It might make people feel like IKEv1 could still be used. > > This is my opinion and I do stick to it, and I do continue trying to > convince others to it too. I see no problem there. > > Are you saying that I am not allowed to try to do what I belive is > right? No, if you read what I said I wished you luck in your advocacy that people should stop using IKEv1. I'm not trying to stifle you, I'm saying that it is inappropriate to make life a programmatic hell for other people just because you, personally, want IKEv1 to die. >> > We do not need to keep adding features to the old obsoleted protocoles >>
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > Nobody said anything about "adding everything". That is a complete straw > man argument. In fact, it is decidedly not the case that "everything" is > being > added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick > to leap to unfounded conclusions you would see this IANA update as the > innocuous event that it really is. Not if you count the authentication methods in to it too. That do require quite a bit of work to make sure everything is done correctly. Especially as IKEv1 exchanges are quite different depending which authentication method is used. Adding only the Diffie-Hellman groups is much easier, but I understood that the idea was to add both. And for SPSK there was also text for adding that to IKEv1 too, before it was removed. Same is now with the ike-over-tcp, which again has IKEv1 text in it. > This is allowing existing implementations to have more flexibility in the > ECDH operations they perform to comply with various requirements that > may exist in different locales or in different circumstances or situations. I would think the ECP groups we already have in the IKEv1 should be enough for the most common case, i.e. the suite-b uses. Also I still do not think that many implementations are going to update their IKEv1 implementations. > > I think otherwise, as using new group mode allows using them without > > changing any single line of code, provided the IKEv1 implementation do > > support ECP groups at all (and support the new group mode which is > > SHOULD). > > There is a capability in New Group Mode to accept or reject the proposal > and this is to allow the recipient to verify that the group is acceptable. > Enabling this in IKEv1 for the brainpool curves would be substantially more > code than just using the existing code point interface that all > implementation > have. If I remember those old times when our code actually could use new group mode, I think there was two ways to use it, either accept any group other end proposed (without any verification, very useful for testing etc), or to allow the same groups defined in the configuration file. Of course if you were using the group for IKEv1 SA you can also include all the parameters in the SA propsals from RFC2409: Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B and Group Order-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation. So what is wrong with using the already existing mechanisms of using groups directly in the SA for that already obsoleted protocol? It seems the only reason to add numbers for them is to support non IPsec use... > > This is exactly why new group mode was made a SHOULD in the IKEv1, > > i.e. to allow adding new groups without need to changing the > > specification or the actual code. > > Your recollection differs from the person who actually wrote the RFC. > And when that happens one should typically defer to the author. In fact, > your statement seems to differ from the RFC which says it SHOULD be > supported as a mechanism to define "private groups". The brainpool > groups are not private and there is no reason to treat them as such. Brainpool groups do not have number in the IANA registry, which makes them private for IKEv1 use. There is nothing there claiming that you can only use new group mode to negotiate groups that are not know for anybody else. > Since groups added with New Group mode MUST be assigned private > code points it would result in a case of code bi-furcation because > the same domain parameter sets would be accessed using different > code points. That's unnecessary code complication for implementations > that support both IKEv1 and IKEv2. Or you can simply give all the parameters in the SA payload, and not give it number at all. Then it does not matter what the number is. The whole idea of that feature was to allow adding Diffie-Hellman groups to existing implementations by just changing the configuration without modifying the actual code. Implementations supporting IKEv1 and IKEv2 already needs to keep track of separate number spaces, as IANA registries for the IKEv1 and IKEv2 are separate. Also IKEv2 does not support this feature at all, so there is no over the wire negotiated private groups there. > > I agree on that. I do try to convince to switch to IKEv2, as it is > > MUCH better protocol and works much more robustly and has standarized > > features for things which IKEv1 only has multiple non-standardized > > non-interoperable protocols. > > And bully for you! I wish you much success in your advocacy. Actively > try
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Wed, July 18, 2012 3:12 pm, Tero Kivinen wrote: > Dan Harkins writes: >> > I would be strongly against for including support for protocol which >> > has been obsoleted 7 years ago. If people want to use this kind of >> > groups in IKEv1 they can use the new group mode and negotiate groups >> > on the fly. There is no need to add them to IKEv1. >> >> In spite of this designation IKEv1 is still widely used and I would >> posit >> that it is used more than IKEv2. > > It is widely used, but that does not mean we need to keep adding > everything there. I do not think that is that much more widely > implemented anymore. I would expect most of the implementations do > support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough. Nobody said anything about "adding everything". That is a complete straw man argument. In fact, it is decidedly not the case that "everything" is being added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick to leap to unfounded conclusions you would see this IANA update as the innocuous event that it really is. This is allowing existing implementations to have more flexibility in the ECDH operations they perform to comply with various requirements that may exist in different locales or in different circumstances or situations. >> IKE already has the way to handle new domain parameter sets that are >> publicly defined and that is through the IANA registry. Your suggestion >> to >> use New Group Mode to use brainpool ECC groups would only hamstring >> IKEv1 and make it harder to use. > > I think otherwise, as using new group mode allows using them without > changing any single line of code, provided the IKEv1 implementation do > support ECP groups at all (and support the new group mode which is > SHOULD). There is a capability in New Group Mode to accept or reject the proposal and this is to allow the recipient to verify that the group is acceptable. Enabling this in IKEv1 for the brainpool curves would be substantially more code than just using the existing code point interface that all implementation have. > This is exactly why new group mode was made a SHOULD in the IKEv1, > i.e. to allow adding new groups without need to changing the > specification or the actual code. Your recollection differs from the person who actually wrote the RFC. And when that happens one should typically defer to the author. In fact, your statement seems to differ from the RFC which says it SHOULD be supported as a mechanism to define "private groups". The brainpool groups are not private and there is no reason to treat them as such. Since groups added with New Group mode MUST be assigned private code points it would result in a case of code bi-furcation because the same domain parameter sets would be accessed using different code points. That's unnecessary code complication for implementations that support both IKEv1 and IKEv2. > I agree that there might be implementations which do not support it, > and for example I think we disabled it from our implementation when we > added IKEv2 support, as we wanted to keep the feature set provided by > our implemenation about the same regardless whether IKEv1 or IKEv2 is > used, and IKEv2 do not support such feature. > >> It would be a blunt club to force people into doing something that >> they haven't decided to do on their own (to your apparent chagrin). > > I agree on that. I do try to convince to switch to IKEv2, as it is > MUCH better protocol and works much more robustly and has standarized > features for things which IKEv1 only has multiple non-standardized > non-interoperable protocols. And bully for you! I wish you much success in your advocacy. Actively trying to make people's programmatic lives worse because your advocacy isn't as successful as you'd like is a completely different matter though and is, I think, inappropriate. The fact that you admit you want a blunt club to force compliance with your wishes speaks volumes. >> The IETF does not have a lot of success at forcing people to do things >> they do not want to do on their own and I think this sort of thing is >> somewhat inappropriate. > > We do not need to keep adding features to the old obsoleted protocoles > either. This is NOT a feature. ECDH already exists in IKEv1. This is allowing existing implementations, of which they are legion, to use certain domain parameter sets that may be required or desired in certain situations and in certain locales. >> Why there are two identical repositories to map unsigned shorts to >> complete domain parameter sets is beyond me but there are. These >> two repositories have been updated in concert in the past and and there >> is no good reason to have them diverge now. > > There is multiple repositories for diffie-hellman parameters. IKEv1, > IKEv2, EAP-EKE, and in addtion SSH, TLS etc have their repositories > etc. Registries are cheap, there is no point of reusing them for > completely differen
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > > I would be strongly against for including support for protocol which > > has been obsoleted 7 years ago. If people want to use this kind of > > groups in IKEv1 they can use the new group mode and negotiate groups > > on the fly. There is no need to add them to IKEv1. > > In spite of this designation IKEv1 is still widely used and I would posit > that it is used more than IKEv2. It is widely used, but that does not mean we need to keep adding everything there. I do not think that is that much more widely implemented anymore. I would expect most of the implementations do support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough. > IKE already has the way to handle new domain parameter sets that are > publicly defined and that is through the IANA registry. Your suggestion to > use New Group Mode to use brainpool ECC groups would only hamstring > IKEv1 and make it harder to use. I think otherwise, as using new group mode allows using them without changing any single line of code, provided the IKEv1 implementation do support ECP groups at all (and support the new group mode which is SHOULD). This is exactly why new group mode was made a SHOULD in the IKEv1, i.e. to allow adding new groups without need to changing the specification or the actual code. I agree that there might be implementations which do not support it, and for example I think we disabled it from our implementation when we added IKEv2 support, as we wanted to keep the feature set provided by our implemenation about the same regardless whether IKEv1 or IKEv2 is used, and IKEv2 do not support such feature. > It would be a blunt club to force people into doing something that > they haven't decided to do on their own (to your apparent chagrin). I agree on that. I do try to convince to switch to IKEv2, as it is MUCH better protocol and works much more robustly and has standarized features for things which IKEv1 only has multiple non-standardized non-interoperable protocols. > The IETF does not have a lot of success at forcing people to do things > they do not want to do on their own and I think this sort of thing is > somewhat inappropriate. We do not need to keep adding features to the old obsoleted protocoles either. > Why there are two identical repositories to map unsigned shorts to > complete domain parameter sets is beyond me but there are. These > two repositories have been updated in concert in the past and and there > is no good reason to have them diverge now. There is multiple repositories for diffie-hellman parameters. IKEv1, IKEv2, EAP-EKE, and in addtion SSH, TLS etc have their repositories etc. Registries are cheap, there is no point of reusing them for completely different purposes. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > > Why would any other protocol use IKEv1 IANA registries? Are you now > > talking about the authentication method registry or the diffie-hellman > > groups registry? > > The "diffie-hellman groups registry". > > > It is bad idea to use registry for any other reason than where it is > > created, and adding stuff to IKEv1 IANA registry not for IPsec use, > > but for use for some other protocols seems like quite funny. > > It was created to map an unsigned short to a complete domain parameter > set and that is exactly how it is being used. You forgot the "for IKEv1 use" in your reason why it was created. > > My personal opinion about that is that it is IEEE 802.11-2012 problem > > if they use IANA registry for some other purposes than what it is > > intended for. > I think your opinion that this is "some other purpose" is wrong. If they actually use IKEv1 and use that IANA registry to map group numbers to parameters for that use, then it is fine. If they are using it for some other purposes then I do not care, and I do not think we should care what they do for that, and we should not add stuff to our registry just because someone want some numbers there for some other reasons than for the IPsec use. There is no point of adding any new stuff to IKEv1 registries as it is OBSOLETED protocol. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
On Wed, July 18, 2012 11:45 am, Tero Kivinen wrote: [snip] >> [Question 1] Should we include IKEv1 in the specs as well? It seems >> that some people in the WG do not like the idea of updating this >> obsolete protocol. On the other hand, many applications still use >> IKEv1 and specifying the use of the Brainpool curves only for IKEv2 >> would exclude these. > > I would be strongly against for including support for protocol which > has been obsoleted 7 years ago. If people want to use this kind of > groups in IKEv1 they can use the new group mode and negotiate groups > on the fly. There is no need to add them to IKEv1. In spite of this designation IKEv1 is still widely used and I would posit that it is used more than IKEv2. IKE already has the way to handle new domain parameter sets that are publicly defined and that is through the IANA registry. Your suggestion to use New Group Mode to use brainpool ECC groups would only hamstring IKEv1 and make it harder to use. It would be a blunt club to force people into doing something that they haven't decided to do on their own (to your apparent chagrin). The IETF does not have a lot of success at forcing people to do things they do not want to do on their own and I think this sort of thing is somewhat inappropriate. Why there are two identical repositories to map unsigned shorts to complete domain parameter sets is beyond me but there are. These two repositories have been updated in concert in the past and and there is no good reason to have them diverge now. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Hello, On Wed, July 18, 2012 11:51 am, Tero Kivinen wrote: > Dan Harkins writes: >> Absolutely yes. There are still a lot of IKEv1 implementations out >> there >> and also there are other protocols that use the IANA registry from >> IKEv1, >> namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry >> has to be added to the IKEv1 registry. > > Why would any other protocol use IKEv1 IANA registries? Are you now > talking about the authentication method registry or the diffie-hellman > groups registry? The "diffie-hellman groups registry". > It is bad idea to use registry for any other reason than where it is > created, and adding stuff to IKEv1 IANA registry not for IPsec use, > but for use for some other protocols seems like quite funny. It was created to map an unsigned short to a complete domain parameter set and that is exactly how it is being used. > My personal opinion about that is that it is IEEE 802.11-2012 problem > if they use IANA registry for some other purposes than what it is > intended for. I think your opinion that this is "some other purpose" is wrong. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan Harkins writes: > Absolutely yes. There are still a lot of IKEv1 implementations out there > and also there are other protocols that use the IANA registry from IKEv1, > namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry > has to be added to the IKEv1 registry. Why would any other protocol use IKEv1 IANA registries? Are you now talking about the authentication method registry or the diffie-hellman groups registry? It is bad idea to use registry for any other reason than where it is created, and adding stuff to IKEv1 IANA registry not for IPsec use, but for use for some other protocols seems like quite funny. My personal opinion about that is that it is IEEE 802.11-2012 problem if they use IANA registry for some other purposes than what it is intended for. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Using ECC Brainpool curves with ipsec
[I have been on vacation for a month, so thats why I am only coming back to this now]. Johannes Merkle writes: > [Question 0] Is the WG interested in shepherding an RFC specifying > all that's necessary to use the Brainpool curves in ipsec? And what > category would be preferred, standard track or informational. I think it might be good idea to get some usable elliptic curves too. The groups 19-21 is mostly unusable now as we messed up with their format in the original RFC4753 and they changes we made in RFC5903 are not backward compatible with the original RFC4753 and the interoperability problem just causes timeout on the initiator. > [Question 1] Should we include IKEv1 in the specs as well? It seems > that some people in the WG do not like the idea of updating this > obsolete protocol. On the other hand, many applications still use > IKEv1 and specifying the use of the Brainpool curves only for IKEv2 > would exclude these. I would be strongly against for including support for protocol which has been obsoleted 7 years ago. If people want to use this kind of groups in IKEv1 they can use the new group mode and negotiate groups on the fly. There is no need to add them to IKEv1. > [Question 2] If IKEv1 is to be considered, the registry for IPSEC > Authentication Methods (Value 3) needs to be updated, because the > values for ECDSA are specific for each curve. What policy for > updating this IANA registry can be assumed? IANA currently requires > a standard track RFC, but there has recently been some discussion on > relaxing this, in particular, > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and > http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . > For the corresponding IKEv2 registry (Auth Method), only Expert > Review is required. Hmm... So you are talking adding them for both Diffie-Hellman and ECDSA uses? Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman use requires updating of one expert review 16-bit registry for IKEv2. The same registry in the IKEv1 is RFC required, so it does not require standard track RFC. Adding them for authentication use (ECDSA use) will most likely get more opposition. First of all, I am not at all happy how the ECDSA groups are added to the IKEv2 authentication method. The authentication methods registry is only 8-bit in IKEv2 (it is 16-bit registry in IKEv1). This does not matter if we have only few ECDSA groups with one hash algorithm for each, but when we are adding more groups it seems to bad idea for each of them having separate number. Especially if someone later decides that they want to use all ECDSA groups with SHA 3 too... I think we should have made the ECDSA support for IKEv2 in such way that we had added some subfields to the authentication field, i.e. only allocated one value for ECDSA and put the curve number inside the authentication payload and perhaps even separated the hash algorithm from it. There is 3 bytes of reserved data in the authentication payload immediately after the auth method. Perhaps we could use those. It is most likely too late now, but we still want to make sure we do not allocate too many entries from that registry, i.e. is there need to add all the groups in there, do we really need that many different strengths? Which hash algorithm do we use with what group? Also note, that authentication methods are not negotiated in IKEv2, i.e. there is no way to know whether the other end supports the authentication algorithm you wanted to use. On the other hand as you need to have credentials for the other end you are using, so most if other end would be accepting your authentication credentials it also supports the authentication method that needs to be used to use then. On the IKEv1 there is another problem. The authentication method is negotiated (in main mode), but it MUST be same for both directions, so both ends must support same types of credentials. Also as you pointed out the authentication algorithgms registry for IKEv1 is still Standard track RFC required and there has been multiple people in the WG opposing to changing it. So adding support for authentication methods do require more work for both IKEv1 and IKEv2. > [Question 3] If IKEv1 is to be considered, it seems reasonable to > write only one RFC covering IKEv1 and IKEv2. Actually, we also plan > to prepare analogous specifications for TLS, so an option would be > to write a common RFC for IKE and TLS analogously to RFC 5114. > However, according to the update policy of the IANA registry EC > Named Curve for TLS, such an RFC would have to be shepherded by the > tls WG. Does this prevent or considerably complicate the creation of > a joint RFC for IKE and TLS? Would preparing separate RFCs for IKE > and TLS be preferable? I would suggest writing separate RFCs for TLS. It might seem like good idea to write only one RFC, but that just causes confusion to the actual users of the RFC. They are either TLS or IPsec imp
Re: [IPsec] Using ECC Brainpool curves with ipsec
Dan, thanks for your reply. You happen to be the first one. See my comments below. >> [Question 1] Should we include IKEv1 in the specs as well? It seems that >> some people in the WG do not like the idea of >> updating this obsolete protocol. On the other hand, many applications >> still use IKEv1 and specifying the use of the >> Brainpool curves only for IKEv2 would exclude these. > > Absolutely yes. There are still a lot of IKEv1 implementations out there > and also there are other protocols that use the IANA registry from IKEv1, > namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry > has to be added to the IKEv1 registry. This is also our perception but we would prefer a WG consensus on that. > >> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, >> 320, 384, 512 two curves are defined, one >> being the “quadratic twist� of the other – their algebraic structure >> (and hence, security level) is equivalent, but one >> of them allows particular efficient arithmetic. In order to leave the >> choice of the curve for a given bit length to the >> implementation we propose to register IANA values (for Auth method and >> Diffie-Hellman Group) for both curves for each >> bit length. Of course, this doubles the number of number assignments. Any >> objections on this? > > There's approximately 65k available assignments so this shouldn't be a > problem. Why would anyone want to do the untwisted version if the twisted on > is more efficient? Are there any IPR considerations to the twisted version? A similar question has been raised as response to my analogous posting on the tls mailing list. The reason why some people might prefer the "normal" curves is that for these it is easier to avoid patents. This is always a big issue with ECC. While the Brainpool curves avoid special primes to facilitate patent-free implementations, we still wanted to leave the implementors a choice between "fast" and "slower but more patent-safe" by introducing the quadratic twist. > >> [Question 6] In cryptographic applications using elliptic curves, point >> compression (see Section 4.2 in RFC 6090) is >> frequently used in particular in environments with limited bandwidth and >> storage capacity. However, in IKE this >> mechanism is currently not supported as, according to RFC 5903, the KE >> payload consists of the concatenation of two >> components, x and y, each of which having the same length as the >> underlying finite field. We propose to add support for >> point compression for the KE Payload to IKE by allowing also the use of a >> compressed form of x, e.g. of 64 bits, >> representing only the least significant bit. In contrast to the (obsolete) >> draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 >> does not specify a data format for the ECDH KE payload in which the >> uncompressed form is explicitly specified (e.g. in a >> leading byte), uncompressed and compressed form could only be implicitly >> distinguished by their bit length (as specified >> in the KE header). Does this raise any issue with implementations? What >> are your opinions and preferences? > > My preference would be to leave the KE payload alone. So, you mean not to allow point compression? Our proposal is *not* to change the KE payload syntax but only to allow variation in its bit length and to define rules for interpretation depending on its length. This means merely an extension of the rules defined for the NIST curves (RFC 5903), not a contradiction. BTW: TLS explicitly allows point compression. Johannes -- Johannes Merkle secunet Security Networks AG johannes.mer...@secunet.com www.secunet.com ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Using ECC Brainpool curves with ipsec
Hello, On Tue, July 3, 2012 8:59 am, Johannes Merkle wrote: > Hi, > > in RFC 5639, we have specified a new set of elliptic curve parameters for > use in cryptographic applications. Meanwhile, > support for these "Brainpool Curves" has been included in some crypto > libraries as openssl (recently) and crypto++. > However, in order to use the Brainpool Curves with IKE and IPSec, still > some specifications and IANA registry updates > are needed. We are now planning to prepare such an RFC to allow usage of > the ECC Brainpool curves with ipsec. I think that's a great idea. > In order to go forward with this effort, we would like to discuss some > questions and potential issues. The WG feedback > on these is most appreciated. > > [Question 0] Is the WG interested in shepherding an RFC specifying all > that's necessary to use the Brainpool curves in > ipsec? And what category would be preferred, standard track or > informational. I can't speak for the group but I would like to see an RFC that defines the IANA considerations for using these curves in IKE. Informational is probably fine unless the answer to question 2 below requires Standards Track. > [Question 1] Should we include IKEv1 in the specs as well? It seems that > some people in the WG do not like the idea of > updating this obsolete protocol. On the other hand, many applications > still use IKEv1 and specifying the use of the > Brainpool curves only for IKEv2 would exclude these. Absolutely yes. There are still a lot of IKEv1 implementations out there and also there are other protocols that use the IANA registry from IKEv1, namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry has to be added to the IKEv1 registry. > [Question 2] If IKEv1 is to be considered, the registry for IPSEC > Authentication Methods (Value 3) needs to be updated, > because the values for ECDSA are specific for each curve. What policy for > updating this IANA registry can be assumed? > IANA currently requires a standard track RFC, but there has recently been > some discussion on relaxing this, in > particular, > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and > http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . > For the corresponding IKEv2 registry (Auth Method), only Expert Review is > required. Hopefully that will be relaxed. > [Question 3] If IKEv1 is to be considered, it seems reasonable to write > only one RFC covering IKEv1 and IKEv2. Actually, > we also plan to prepare analogous specifications for TLS, so an option > would be to write a common RFC for IKE and TLS > analogously to RFC 5114. However, according to the update policy of the > IANA registry EC Named Curve for TLS, such an > RFC would have to be shepherded by the tls WG. Does this prevent or > considerably complicate the creation of a joint RFC > for IKE and TLS? Would preparing separate RFCs for IKE and TLS be > preferable? This seems reasonable. The body of the RFC will probably just be IANA considerations. The domain parameter sets of the curves are already defined so you just need to get IANA to allocate magic numbers for their use. > [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, > 320, 384, 512 two curves are defined, one > being the âquadratic twistâ of the other â their algebraic structure > (and hence, security level) is equivalent, but one > of them allows particular efficient arithmetic. In order to leave the > choice of the curve for a given bit length to the > implementation we propose to register IANA values (for Auth method and > Diffie-Hellman Group) for both curves for each > bit length. Of course, this doubles the number of number assignments. Any > objections on this? There's approximately 65k available assignments so this shouldn't be a problem. Why would anyone want to do the untwisted version if the twisted on is more efficient? Are there any IPR considerations to the twisted version? > [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but > also ECGDSA (Elliptic Curve German Digital > Signature Algorithm) according to ISO 14888-3, which is a slight variant > of ECDSA. The advantage of ECGDSA over ECDSA is > that signature generation does not need any inversion modulo the group > order, which removes the necessity of > corresponding code. This advantage is particularly interesting when using > devices with limited computation power and > storage like smart cards or electronic control units in cars. In > particular, car manufacturers have expressed their > desire to deviate from EDSA For this reason, we would like to specify > values for ECGDSA (with the individual bit lengths > and curves) as Authentication Method as well. Would the WG support > inclusion of this additional signature algorithm? Unless this got wider acceptance my personal take is: pass. > [Question 6] In cryptographic applications using elliptic curves, point > compression (see Section 4.
[IPsec] Using ECC Brainpool curves with ipsec
Hi, in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile, support for these "Brainpool Curves" has been included in some crypto libraries as openssl (recently) and crypto++. However, in order to use the Brainpool Curves with IKE and IPSec, still some specifications and IANA registry updates are needed. We are now planning to prepare such an RFC to allow usage of the ECC Brainpool curves with ipsec. In order to go forward with this effort, we would like to discuss some questions and potential issues. The WG feedback on these is most appreciated. [Question 0] Is the WG interested in shepherding an RFC specifying all that's necessary to use the Brainpool curves in ipsec? And what category would be preferred, standard track or informational. [Question 1] Should we include IKEv1 in the specs as well? It seems that some people in the WG do not like the idea of updating this obsolete protocol. On the other hand, many applications still use IKEv1 and specifying the use of the Brainpool curves only for IKEv2 would exclude these. [Question 2] If IKEv1 is to be considered, the registry for IPSEC Authentication Methods (Value 3) needs to be updated, because the values for ECDSA are specific for each curve. What policy for updating this IANA registry can be assumed? IANA currently requires a standard track RFC, but there has recently been some discussion on relaxing this, in particular, http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . For the corresponding IKEv2 registry (Auth Method), only Expert Review is required. [Question 3] If IKEv1 is to be considered, it seems reasonable to write only one RFC covering IKEv1 and IKEv2. Actually, we also plan to prepare analogous specifications for TLS, so an option would be to write a common RFC for IKE and TLS analogously to RFC 5114. However, according to the update policy of the IANA registry EC Named Curve for TLS, such an RFC would have to be shepherded by the tls WG. Does this prevent or considerably complicate the creation of a joint RFC for IKE and TLS? Would preparing separate RFCs for IKE and TLS be preferable? [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one being the “quadratic twist” of the other – their algebraic structure (and hence, security level) is equivalent, but one of them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the implementation we propose to register IANA values (for Auth method and Diffie-Hellman Group) for both curves for each bit length. Of course, this doubles the number of number assignments. Any objections on this? [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but also ECGDSA (Elliptic Curve German Digital Signature Algorithm) according to ISO 14888-3, which is a slight variant of ECDSA. The advantage of ECGDSA over ECDSA is that signature generation does not need any inversion modulo the group order, which removes the necessity of corresponding code. This advantage is particularly interesting when using devices with limited computation power and storage like smart cards or electronic control units in cars. In particular, car manufacturers have expressed their desire to deviate from EDSA For this reason, we would like to specify values for ECGDSA (with the individual bit lengths and curves) as Authentication Method as well. Would the WG support inclusion of this additional signature algorithm? [Question 6] In cryptographic applications using elliptic curves, point compression (see Section 4.2 in RFC 6090) is frequently used in particular in environments with limited bandwidth and storage capacity. However, in IKE this mechanism is currently not supported as, according to RFC 5903, the KE payload consists of the concatenation of two components, x and y, each of which having the same length as the underlying finite field. We propose to add support for point compression for the KE Payload to IKE by allowing also the use of a compressed form of x, e.g. of 64 bits, representing only the least significant bit. In contrast to the (obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 does not specify a data format for the ECDH KE payload in which the uncompressed form is explicitly specified (e.g. in a leading byte), uncompressed and compressed form could only be implicitly distinguished by their bit length (as specified in the KE header). Does this raise any issue with implementations? What are your opinions and preferences? Johannes -- Johannes Merkle secunet Security Networks AG johannes.mer...@secunet.com www.secunet.com ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
