Re: [tsvwg] SCTP-AUTH (RFC 4895) is Broken and Insecure

[Michael Tuexen <[e-mail]>]

> On 12. Oct 2022, at 17:27, John Mattsson <john.mattsson=[e-mail]> wrote:
> 
> Hi,
>  
> We made a thorough review of the cryptographic constructions and security properties of SCTP-AUTH (RFC 4895) and found several quite severe vulnerabilities. The conclusion is that SCTP-AUTH is quite broken and insecure.
>  
> SCTP-AUTH Background: During the SCTP handshake, both endpoints send a key vector consisting of the three chunks RANDOM, CHUNKS, and HMAC-ALGO. The new AUTH chunk contains the three fields “Shared Key Identifier”, “HMAC Identifier”, and “HMAC”. The “Shared Key Identifier” identifies an endpoint pair shared key. From the endpoint pair shared key an association shared key is computed as the concatenation of the endpoint pair shared key and the two key vectors. The “HMAC Identifier” identifies an HMAC algorithm. The “HMAC” field contains a MAC calculated with the HMAC algorithm and the association shared key over the chunks placed after the AUTH chunk in the SCTP packet.
Hi John,

thanks for reporting the issues.
>  
> Problems:
> 	• If the two endpoints use the same endpoint pair shared key, they use the same association shared key. As there is nothing binding the HMAC to a specific direction, an on-path attacker can take authenticated chunks from one direction and insert them into the other direction as long as the TSN (and other non-unique fields) match. I.e., an on-path attacker can reflect the authenticated part of a SCTP packet back to the sender.
It is correct that reflection is possible.

The initial focus when working on RFC 4895 was to protect ASCONF/ASCONF-ACK chunks.
If an attacker reflects such a chunk the sequence numbers would need to match exactly,
which is not impossible, but not likely. Also these numbers can not be controlled by the attacker.
Also the state of the association could be come strange resulting in all sorts of connectivity
problems.

But since you are referring to a TSN, you focus on DATA or I-DATA chunks, I guess. What happens depends
on the sequence numbers (TSN and possibly SSN). If the sequence number is too old, it is just dropped.
If the sequence number is higher than sent by the peer, the corresponding SACK will kill the association.
If there are inconsistencies between the TSN/SSN the association will also be killed. But there is a
window where the data gets accepted and will be delivered to the upper layer. If DTLS is the upper layer,
it would detect this, drop the user message and also drop the SCTP association.
So the attacker can terminate the association, but if the attacker can reflect packets, he can do that
anyway. Or am I missing something?
> 	• The 32-bit Transmission Sequence Number (TSN) wraps back to 0 after reaching 2^31–1. This means that the TSNs in one direction are not unique, and an on-path attacker can replay authenticated DATA chunks after an endpoint has sent 2^32 DATA chunks. Other chunks are even easier to replay. Authenticated ERROR, RE-CONFIG, or SACK chunks not sent in the same packet as a DATA chunk can e.g., be replayed at any time. Replaying a RE-CONFIG chunk sets the numbering sequence of the stream back to 'zero' and makes it easier to replay other types of chunks.
I don't consider this an issue of SCTP-AUTH, since SCTP-AUTH is not intended to provide and does not provide any additional replay protection over the base protocol.
> 	• The two endpoints might use different HMAC Identifiers with the same association shared key. A single endpoint might also use different HMAC Identifiers with the same association shared key. This is not secure in general. It is easy to construct cryptographic algorithms that are secure independently but where the security completely fails when the same key is used in both algorithms, a classic example is AES-CBC and CBC-MAC.
Interesting. Does there exist such an attack for HMAC-SHA1 and HMAC-SHA256, since these are currently the only defined
algorithms?
>  
> The first two problems are quite severe practical problems. SCTP-AUTH does not provide proof that the authenticated chunks were sent by the other endpoint. The authenticated chunks might be chunks from the other direction reflected back by a malicious attacker. SCTP-AUTH does not offer replay protection for some control chunks such as ERROR. After 2^32 DATA chunks protected with the same endpoint pair shared key, SCTP-AUTH does not offer replay protection of DATA chunks. The third problem is more theoretical and should be fixed but does likely not lead to any practical attacks with the current algorithms.
>  
> Potential solutions:
> 	• The reflection problem can be solved by enforcing that the two endpoints always use different endpoint pair shared key. Alternatively, something uniquely identifying the direction must be included in the HMAC calculation or in the association shared key calculation.
I guess it would be relatively easy to add the common header without 0 checksum in the HMAC computation. Then it would only
be possible to reflect if both sides use the same port number and the same verification tag. Since the same port number on
both sides must be supported, on could enforce that the verification tags are not the same when selecting them.
> 	• The replay of DATA chunks can be mitigated by enforcing that the endpoint pair shared key must be changed before the TSN wraps. Alternatively, the association is closed after 2^32 DATA chunks, longer TSNs are introduced, or the TSNs are complemented with a roll-over-counter in the HMAC calculation. The replay of ERROR (and other) chunks can be solved by enforcing that they are sent with DATA chunks, that the association shared key is changed for each AUTH chunk, or by introducing a new AUTH2 chunk with a sequence number. 
I don't think this is an issue for SCTP-AUTH, since it does not provide replay protection. When using DTLS/SCTP the
idea was that the start rekeying before the sequence numbers would wrap. This is one possible trigger for doing this.
> 	• If the endpoints are enforcing that the two endpoints use different endpoint pair shared key, the problem can be solved by enforcing that each endpoint must not use several “HMAC identifiers” with the same “Shared Key Identifier”. If the two endpoints use the same endpoint pair shared key, the problem can be solved by including the used “HMAC Identifier” in the association shared key computation.
Wouldn't it be simple to use the same algorithm in both directions?

I guess this is what is happening today: Assuming that end-points support algorithms always for sending and receiving,
which is true for all implementations I know of, the situation is simple, if one end-point only supports a single
algorithm, which is HMAC-SHA1. So both would use this. If both end-points support both algorithms, I guess both
would prefer HMAC-SHA256 over HMAC-SHA1. So in this case both would use HMAC-SHA256. The only possibility that both
algorithms are used would be than one end-point prefers HMAC-SHA1 over HMAC-SHA256 and the other would prefer HMAC-SHA256
over HMAC-SHA1. I don't think this makes much sense and I don't think this exists today.

But I do see the general problem...

I started to work on a RFC4895 bis (see https://www.ietf.org/archive/id/draft-tuexen-tsvwg-rfc4895-bis-02.html),
but I don't know if there is interest in the WG for adopting it. However, it wouldn't be complication to
address your first and third issue. I don't this your second issue should be addressed by SCTP-AUTH but by
upper layers of SCTP if they require a replay protection better than what is provided by SCTP.
>  
> The problems above applies to DTLS/SCTP (RFC 6083, draft-ietf-tsvwg-dtls-over-sctp-bis-04). We plan to address the issues in draft-ietf-tsvwg-dtls-over-sctp-bis-05 by defining different TLS exporter labels for the DTLS client and server, to require that no more than 2^32 DATA chunks are sent over a single DTLS connection, and to enforce that each sender use a single HMAC Identifier during the association.
I think SCTP implementations using the socket API or an equivalent one will always use a single HMAC for sending.
Right now, there is no API for letting the upper layer to select one.

Best regards
Michael
>  
> Cheers,
> John, Magnus, and Claudio