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

[Michael Tuexen <[e-mail]>]

> On 10. Mar 2024, at 07:29, John Mattsson <john.mattsson=[e-mail]> wrote:
> 
> 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
Hi John,

maybe it is better to reach some consensus of what RFC 4895bis needs to provide.

The intention of RFC 4895 bis to provide a way for the receiver of some chunks
to make sure they were sent by the sender and not by an attacker. They main
use case was protecting ASCONF and ASCONF ACK chunks.

Do we agree on this?

Looking at the Security Issues listed in the presentation you cite, I see

(1) Reflection of authenticated DATA chunks.
I agree, the possibility of reflecting authenticated DATA chunks was not
intended and should be fixed in RFC 4895bis. But this is not specific
to DATA chunks. It applies to all chunks sent in an authenticated way.

(2) Replay of authenticated DATA chunks
Improving the replay protection was not a goal of RFC 4895. It might be
used in combination with other mechanisms like an appropriate key management
to provide this. I do understand that something like DTLS/SCTP needs to
provide this, but I do not see it as an security issue of RFC 4895.

(3) Single key used with different HMAC algorithms
I wasn't aware that this might be a problem. But it will be fixed in RFC 4895bis.

(4) Reflection of authenticated control chunks
This is (1). RFC 4895 makes no difference between DATA and control chunks.

(5) Replay of control chunks
As stated in (2), there is no intention to improve the base protocol here.
Also, the base protocol should not have any problems with respect to
control chunks not using sequence numbers. So I don't understand why replayed
HEARTBEAT ACK chunks should result in a problem. If they do, they do it right
now and that would need to be improved in the base protocol.
If you want to protect against problems with sequence number wrap arounds,
you always have to consider DATA and SACK, ASCONF and ASCONF ACK, RE-CONFIG
chunks.

So I do see (1) and (4) as a single security issue and (3) as another one
for RFC 4895. Both will be fixed in RFC 4895bis by using some sort of
key derivation.

Do you think improving RFC 4895 to also provide (2) and (5) needs also
to be done? I don't think so, but I would like to discuss this explicitly.

Best regards
Michael
>  - 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