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
