Early Review of draft-ietf-teas-rsvp-hmac-sha2-00
review-ietf-teas-rsvp-hmac-sha2-00-secdir-early-eastlake-2025-11-10-00

I have done an early review of this document as requested. Document editors
and the TEAS WG should treat these comments like other early draft comments.

The summary of the review is Ready with issues.

This draft specifies how to calculate HMAC-SHA-256, -384, and -512 for use
as Authentication Data in INTEGRITY Objects for RSVP cryptographic
authentication as specified in draft-ietf-teas-rsvp-auth-v2-00. This is an
early security review of draft-ietf-teas-rsvp-hmac-sha2-00 with a view
towards possibly improving the draft.

Security Comments
-----------------

The incremental effort in implementing HMAC-SHA-384 is tiny if HMAC-SHA-512
is implemented. It's just different initial values and a final truncation.
Since the latter is a MUST, I'm not sure why the former is just a MAY.
Unless the 32 extra bytes for 512 is truly insignificant, I would think 384
would be at least a SHOULD.

The references to RFC 4634 should be updated to RFC 6234.

I'm not sure that all the details of doing HMAC need to be spelled out here
but could just be incorporated by reference from RFC 2104. On the other
hand, I can understand a desire to provide a more "complete" specification.

Section 4, next to last paragraph: rather than an additional requirement to
notice if the sequence number is going to repeat within a security
association, it seems to me better to require that the security association
lifetime be less than, say, 2**63 times the minimum time per RSVP message
on the hop being protected. Then the normal requirement to rollover at the
end of the security association lifetime also solves this replay attack.
(This may require a change to draft-ietf-teas-rsvp-auth-v2-00.)

Minor
-----

Section 3.4 gives the impression that sender and receiver can always
instantly and simultaneously switch security association. But there is
always a chance of clock skew or delayed packets. This seems to be
discussed in draft-ietf-teas-rsvp-auth-v2-00 so perhaps something like
"timing details of key rollover are discussed in
draft-ietf-teas-rsvp-auth-v2-00" should be added.

Section 3.4 seems like there should be a few words about why supporting
more than two concurrent RSVP Security Associations simplifies security
management. (In fact draft-ietf-teas-rsvp-auth-v2-00 says "much larger"
than 2.)

References: The specifications NIST-SHS, NIST-HMAC, RFC 2104, RFC 4634
(should be 6234), NIST-ENTROPY, and RFC 4086 should be normative.

Nits
----

These are very minor:

Abstract: I think that where there is a non-square-bracketed RFC reference
in the abstract there should be a space between "RFC" and the following
four digit number.

Section 3: RFC references should have square brackets around them, not
double curly brackets.

Section 3.2: I don't think the words "rather than bits" add anything and
can be deleted.

Section 3.2: The last sentence of numbered item (2) doesn't seem to belong
there and seems redundant with the first sentence of "Implementation Notes"
so it could be deleted.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com