Valery Smyslov writes: > > 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.
That is something I realized on our way home, but it is easy to fix. We add suggestion to the draft that the responder should use same type of key than what initiator used. I.e Initiator selects algorithm based on the CERTREQ and his own preferences (and one of those might be algorithms already used previously, or previously tried). The Responder should select same type of key that was used by initiator, provided he has the that type of private key. If not, then he picks a key based on his policy. > I admit, that such situations are rare but not non-existent. > And manual configuration is not an option for large VPNs. Large VPNs should use centralized management systems anyways, and all of this is also avoidable by using suitable sub CA keys. You do not need to change the root CA, it is enough to change the sub CA used to signing the EE cert, and send CERTREQ containg that key instead. > Retry is not always possible and is a hack anyway. For initiator it is possiblity, for responder adding the text which says it should use same algoritm than other end will solve the issue. I do not think it as a hack, we already do that in IKEv2 with Diffie-Hellman group negotiation. On the other hand we do not want to complicate the IKEv2 more by making the retry inside the exchange like we do with INVALID_KE_PAYLOAD, but we could add new error notify that the responder can send which says INVALID_AUTH_KEY_TYPE, and we could even add supported key types in that notify. Or we can simply use the AUTHENTICATION_FAILED notify and assume that it might have been because of wrong key type, and as we do not have anything better to do, we can simply retry. Nothing will go through the tunnel anyways unless we do something... > There might also be implementations, that supports only md5, > but we do not consider them, do we? As I said in draft, MD5 is not considered safe enough to be used in the signatures. It is OK to use in HMAC etc cases, but not with signatures. > 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. This is feature, not bug as pointed out Johannes Merkle. > 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. Which is not problem, as the same policy is in both ends. I.e. if one end supports GOST it will send GOST hash. If the other end does not support, it will ignore GOST hash and use some other has (and some other type of key too). If both ends support GOST hash, and pick GOST key, they will use GOST hash, as that is only one that is allowed by their policy. If one end uses GOST key with any other hash algorithm it is violating the GOST specification, and it is not expected to work. > And even if you could use DSA with SHA-2 or even SHA-3, You can use DSA with SHA-2. You cannot use it in IKEv2, as the current DSS signature method is defined to always use SHA-1. This is one of the reasons we initially started this work. > 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. Agree on that, but it is easy to see that some implementations supporting RSA keys do support SHA-1, some support SHA-1 and SHA-2 and so on, so the hash negotiation is also needed there. The implementation which supports both SHA-1 and 2 for RSA cannot use RSA with SHA-2 unless it knows the other end can support SHA-2. I agree that my example with 1024-bit RSA support was not good, but the problem is that there are no good examples of why people would want to do implementations which only support some features. I.e. it makes my point stronger that this problem is not seen in real world. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
