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. 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. 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. 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. 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 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. > 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. > 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 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 place where have CERTREQ, i.e. responders IKE_SA_INIT, and initiators IKE_AUTH, as this is where that information is needed. > P.S. One small typo in the draft. > in Appendix A last sentence of first para: > > "These values are taken form the New > ASN.1 Modules..." > > s/form/from Fixed. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
