Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc4895-bis-02.txt

[John Mattsson <[e-mail]>]

Hi,

This seems to be work in progress. I assume the plan is to address all the vulnerabilities in some way. I have only focused on the security aspects.

- I think the document needs an overview that describes the changes from RFC 4895 and why they are done. The draft should e.g., describe that directional keys are introduced to stop reflection attacks. As RFC4895bis intent to continue to operate with RFC 4895 all the security issues with RFC 4895 needs to be clearly described.
https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00

- If you decide to follow my previous suggestion to change HMAC to MAC. You could follow my other previous suggestion and register HMAC-SHA-256-128 instead. Having a 256-bit tag seems a bit overkill.

              +-----------------+----------------------------------------------+
              | MAC Identifier | Message Digest Algorithm
              | 0               | Reserved
              | 1               | HMAC-SHA-1
              | 2               | Reserved
              | 3               | HMAC-SHA-256
              | 4               | HMAC-SHA-256-128 with directional keys
              +-----------------+----------------------------------------------+

- "If the peer does not operate in legacy mode, the send context is
   defined as the concatenation of local key vector followed by the
   remote key vector.  The receive context is defined as the
   concatenation of the remote key vector followed by the local key
   vector.  For deriving the association shared send and receive keys, a
   method described in Section 3.1 of [RFC5926] is used.  The
   association shared send key is the result of using HMAC-SHA512 as the
   key derivation function with the endpoint shared key as the
   Master_Key, the send context as the Context and 512 as the
   Output_Length.  The association shared receive key is computed the
   same way, just using the receive context as the Context.  In both
   cases "SCTP-AUTH" is used as the Label."

   That this creates directional key contradicts another statement in the draft saying that "Otherwise, the key vectors are identical".

- My understanding that the new API text forbids per-packet switching of algorithms leading to the same key being used in several algorithms. This should be clearly described.

- My understanding is that the document does not protect against replay of control chunks. If that is not planned, the document should clearly state that is does not provide replay protection. The deduplication mechanism in RFC 9260 is not replay protection, and SCTP-AUTH is a security protocol.

- My understanding is that the document does not protect against replay of data chunks the same direction (yet). I.e., after 2^32 data chunks the TSN reaches the Initial TSN and an on-path attacker can replay authenticated data chunks as the Stream Identifier, and Stream Sequence Number “match”. If user messages are large (more chunks than 2^32), replay can trivially be done after 2^32 chunks when the TSN reaches the Initial TSN.

(If this is not fixed the document need to clearly describe that it does not provide integrity of user data. The document does not state that it does, but the reader cannot be expected to understand that the lack of replay protection lead to lack of integrity protection of the user data. The end user is likely interested in integrity of the user data).

Cheers,
John