Hi Tero,
Valery Smyslov writes:
The problem, that the draft is not solving, is the situation,
when one of the peers has more than one private key, each
for different signature algorithm. This may happen if in deployed
VPN there is a need to move from one signature alg
to another (for any reason, for example when old algorithm
is found to be broken or obsoleted by authorities). As the
transition cannot be done at once, there will be a period when
some of the hosts will have only a single key, while the others
will have more than one. In general, host with multiple keys
cannot decide which of them to use with different peers,
so there is a possibility, that IKE will fail, when it could have
completed. CERTREQ payloads may help in some cases,
but not in all (single CA may issue both certificates signed
with one trusted root) and they are optional anyway.
Lets take example where someone thinks that RSA keys are not strong
enough anymore, and should be replaced with ECDSA keys. They also have
old implementation which only support RSA, and then they have newer
implementation which support both.
To do the change, they need to provide newer implementations a ECDSA
certificates and keys, but also keep the old RSA keys around, as those
are needed to talk to the old implementations.
Right.
Also note, as they do consider RSA keys too weak to be used, they
would also need to change the signature algorithms on their
certificates. This would mean they would need to get new CA or sub CA
key with ECDSA keys to sign those new ECDSA certificates.
Most probably yes. But I can imagine situations when new ECDSA certificates
will be signed by old RSA keys. Root CA keys are usually made
much longer than EE keys, so they may still be considered secure
for mean time. Changing all CA infrastructure at once is a big
problem.
And algorithm weakness is only one example of the necessity to change it.
Trere may be other reasons as well (administartive requirements,
performance, licensing issues), and not all of them will require to
change CA and its algorithm.
So when the old device talks to new device, it will send CERTREQ to
the old RSA CA, and because the new implementation only has
RSA certificate for that older RSA CA, it will automatically pick RSA
key and use that. Everything works automatically.
The new device knows both ECDSA and RSA so it can always verify what
the old device sends. Things work automatically there too.
Yes, but see above.
CERTREQ payloads may be optional, but so is support for this. If you
want to support changing from one CA infrastructure to another you
need to support CERTREQ payloads.
Changing the underlaying key used in the IPsec is useless unless you
also change it in the certificate infrastructure too.
The real problem is that with Raw Public keys you do not have this
option, as CERTREQ payloads are not useful there (their contents are
empty). But on the other hand RFC5996bis does not have Raw public keys
anymore :-)
And you can always retry when you notice that you get authentication
error after using private key, provided you have multiple types of
keys.
In general you can't if it is responder who selected wrong key.
Anyways, I do not really consider this as serious problem in the real
world. In most of the cases the certificate hierarchy needs to be
changed anyways at the same time when changing authentication keys,
and then you get this negotiation automatically.
On those situations this does not work, then you can always manually
configure the devices to use specific keys, or try both keys.
I admit, that such situations are rare but not non-existent.
And manual configuration is not an option for large VPNs.
Retry is not always possible and is a hack anyway.
I suggest to change this as following. Instead of
adding IKE registry, listing hash algorithms,
add registry listing combinations of hash&signature
algorithms, as listed in Appendix A.
So, the registry would look like:
RESERVED 0
sha1WithRSAEncryption 1
sha256WithRSAEncryption 2
sha384WithRSAEncryption 3
sha512WithRSAEncryption 4
The problem here is that RSA Encryption is not enough. For example
there might be implementations which only support 1024-bit RSA keys,
as they have old crypto hardware.
There might also be implementations, that supports only md5,
but we do not consider them, do we?
And the problem with the current SIGNATURE_HASH_ALGORITHMS
is that it decouples hash from signature, assuming that any hash
could be used with any signature algorithm.
Actually this is not true, as some algorithms are administratively defined
only in conjunction with particular hash function.
For example GOST signature algorithm is defined ONLY with GOST hash.
And even if you could use DSA with SHA-2 or even SHA-3,
I would more likely expect the existence of crypto
that supports DSA only with SHA-1, than the crypto,
that supports only RSA with 1024 bit keys and no other RSA key sizes.
dsa-with-sha1 5
dsa-with-sha256 6
ecdsa-with-sha1 7
ecdsa-with-sha256 8
ecdsa-with-sha384 9
ecdsa-with-sha512 10
Or there is implementation which support ECDSA only with NIST curves,
and not with brainpool curves.
Probably they should also be added.
RSASSA-PSS-default 11
And to include values from this registry into
SIGNATURE_HASH_ALGORITHMS notification.
This will allow peer indicate not only hash alg,
but the particular pairs signature-hash which it supports.
The problem with that kind of registry is that the registry gets quite
large quite quickly, especially if we take different curves etc in to
Yes, this is a problem. But I hope the registry will
still be of reasonable size, much less that its capacity.
account too. And also it will make the initial IKE_SA_INIT packets
bigger. On the other hand we could move that negotiation at the same
Yes, this is also a problem. That's why I'd prefer registry
to approach, when supported ASN.1 are listed in the notification.
And I still expect, that the number of supported
hash-sign combinations in real life will be limited
(probably by configuration).
place where have CERTREQ, i.e. responders IKE_SA_INIT, and initiators
IKE_AUTH, as this is where that information is needed.
It will solve the last problem only partially.
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
