Scott C Moonen writes: > Generally, for authentication and PRF purposes, IKEv1 uses HMAC forms of > authentication algorithms. For most algorithms (e.g., MD5, SHA1, etc.) > there is both a non-keyed form of the hash and also a keyed HMAC form. > This doesn't seem to be true for AES-XCBC, which is explicitly defined as > a keyed hash function.
AES-XCBC cannot be used with IKEv1. It can be used for ESP/AH as http://www.iana.org/assignments/isakmp-registry registry has values for it, but http://www.iana.org/assignments/ipsec-registry registry which is used for IKEv1 SA itself does not have any entries for AES-XCBC. > RFC 3947 documents the use of a non-keyed hash for generating a NAT-D > payload. It says that "this uses the negotiated HASH algorithm". What > hash algorithm should one use if AES-XCBC is being used for > authentication? As AES-XCBC cannot be used for IKEv1 SA itself, you use the normal negotiated Hash algorithm for that IKEv1 SA. If AES-XCBC would be added for IKEv1 SAs also, then it would be added as PRF not as Hash algorith, and then IKEv1 SAs using it would have one Hash algorithm (MD5, Sha1 or similar) and one PRF negotiated. Hash algorithm would be used for example when generating the NAT-D payloads, and PRF would be used for generating key material and calculating message authentication codes for the IKEv1 packets. Of course I might be remembering wrong, as writing comments about protocol obsoleted 4 years ago while on vacation might cause that... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
