If there are no further comments, this issue will be closed. Issue #112: Truncation of SHA-1 ICVs
==> Several people commented that the non-truncated versions of HMAC-SHA-1 and HMAC-MD5 are only intended to be used for Fibre Channel traffic. Thus, IKEv2 can only negotiate these versions for that use, but not for IKEv2 or IPsec-v3 SAs. The revised text (below) reflects these comments. Proposed change to Roadmap doc: Add text to Section 5.3 (Integrity-Protection Algorithms) Additional text (revised since previous email): Some of these algorithms generate a fixed-length ICV, which is truncated when it is included in an IPsec-protected packet. For example, standard HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when it is used to provide integrity-protection to an ESP or AH packet. The individual RFC descriptions mention those algorithms that are truncated. When these algorithms are used to protect IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and MD5, respectively; these algorithms are not truncated when used to protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains values for both the truncated version and the standard non-truncated version; thus, IKEv2 has the capability to negotiate either version of the algorithm. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated version is reserved for use by the Fibre Channel protocol [RFC4595]. For the other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated version can be used for both IKEv2 and IPsec-v3 SAs.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
