Thanks, Scott. So is the general consensus
that we should just leave HMAC-SHA-1 and HMAC-MD5 as the only algs for which
IKEv2 can negotiate either a truncated or non-truncated version?
Your comment also reminded me that RFCs
2404 (HMAC-SHA-1) and 2403 (HMAC-MD5) require truncated ICVs for IPsec. So I
guess I should change the new text to only allow IKEv2 to use both versions for
its own SAs, but not for IPsec SAs.
Sheila
From: Scott C Moonen
[mailto:smoonen at us.ibm.com]
Sent: Tuesday, October 27, 2009
12:17 PM
To: Frankel, Sheila E.
Cc: ipsec at ietf.org;
ipsec-bounces at ietf.org; Tero Kivinen; Paul Hoffman; suresh.krishnan at ericsson.com
Subject: Re: [IPsec] [ipsecme]
#112: Truncation of SHA-1 ICVs
Hi Sheila,
1)
I don't think we can expand the registry to include non-truncated versions of
HMAC-SHA2-*. RFC 4868 stipulates for IKE and IPsec in general that the
authenticator length "is always half the output length of the underlying
hash algorithm."
2)
RFCs 3566, 4494 are worded a bit more permissively for AES-XCBC and AES-CMAC,
so perhaps there's some wiggle room there.
3)
I'm not sure if HMAC-RIPEMD is defined for use in IKE (there is not even an
algorithm identifier for IKEv2), but its use for AH and ESP (RFC 2857)
currently only defines a truncated form of the algorithm.
Scott Moonen (smoonen at us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
|
From:
|
"Frankel, Sheila E." <sheila.frankel at nist.gov>
|
|
To:
|
"ipsec at ietf.org" <ipsec at ietf.org>
|
|
Cc:
|
Tero Kivinen <kivinen at iki.fi>, Paul Hoffman
<paul.hoffman at vpnc.org>, "suresh.krishnan at ericsson.com"
<suresh.krishnan at ericsson.com>
|
|
Date:
|
10/27/2009 11:46 AM
|
|
Subject:
|
Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs
|
#112: Truncation of SHA-1 ICVs
Proposed change to Roadmap doc:
Add text to Section 5.3 (Integrity-Protection
Algorithms)
Current text:
The integrity-protection algorithm RFCs
describe how to use these
algorithms to authenticate IKE and/or IPsec
traffic, providing
integrity protection to the traffic.
This protection is provided by
computing an Integrity Check Value (ICV),
which is sent in the
packet. The RFCs describe any special
constraints, requirements, or
changes to packet format appropriate for
the specific algorithm. In
general, they do not describe the detailed
algorithmic computations;
the reference section of each RFC includes
pointers to documents that
define the inner workings of the algorithm.
Some of the RFCs include
sample test data, to enable implementors to
compare their results
with standardized output.
Additional text:
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
IKEv1 SAs, they are not
truncated. 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 to
protect IKEv2 and/or IPsec-v3 SAs.
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.
NOTE to Tero, Paul, Yaron: do we want to expand
the IKEv2 IANA registry to include non-truncated AES-XCBC-MAC,
HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD?
________________________________________
From: ipsecme issue tracker [trac at tools.ietf.org]
Sent: Friday, October 16, 2009 8:25 PM
To: paul.hoffman at vpnc.org; Frankel, Sheila E.
Subject: [ipsecme] #112: Truncation of SHA-1 ICVs
#112: Truncation of SHA-1 ICVs
-----------------------------------+----------------------------------------
Reporter: paul.hoffman@…
| Owner: sheila.frankel@…
Type: defect
| Status:
new
Priority: normal
| Milestone:
Component: roadmap
| Severity: -
Keywords:
|
-----------------------------------+----------------------------------------
In RFC 2404, it mentions that SHA-1 ICVs are
truncated to 96 bits for
IPsec. We should also mention in Section 5.3
that this truncation is done
for IKEv2 as well. Same for RFC 2403. Text is
needed.
--
Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/112>
ipsecme <http://tools.ietf.org/ipsecme/>
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
