[IPsec] Using ECC Brainpool curves with ipsec

[Tero Kivinen <[e-mail]>]

[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 implementors,
and it is confusing if you are not using the same terms which are
already used in those protocols.

We only write those documents once (hopefully), but they are (again
hopefully) used more than once, so it is better to optimize for the
reader... 

> [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 $,1r|(Bquadratic
> twist$,1r}(B of the other $,1rs(B 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?

For Diffie-Hellman groups with 16-bit registry, no. For the
Authentication Algorithms registry with only 8-bit registry, yes. On
the other hand if we do take those reserved fields in to use in the
IKEv2 authentication payload and put the parameters there then I see
no reason to limit the number of groups. 

> [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?

I think it might be good idea for IKEv2 (and bad idea for IKEv1), but
at least there I think we should add it differently than what is done
for the current ECDSA code, i.e not make separate number for each
group (which would be 28 (i.e. >10% of the whole registry) if we add
all 7 strengths with 2 formats and each with both ECDSA and ECGDSA).

> [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?

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
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 compression
because of licensing reasons they cannot talk to each other.

So as a summary (my opinion):

1) NO for IKEv1
2) Yes, for IKEv2 Diffie-Hellman groups
3) Maybe, for the IKEv2 ECDSA Authentication methods, with stronger
   support if we actually allocate only one authentication method
   number (or two, one for ECDSA, and another for ECGDSA) and move
   parameters inside the reserved fields. 

Adding the ECDSA do require more work, and for that I would think it
would be best to make this as a WG item (i.e. recharter to include
it). 
-- 
[e-mail]