Address new vulnerabilities found in SCTP-AUTH about draft-westerlund-tsvwg-dtls-over-sctp-bis

[emanjon]

Should the client and server endpoint shared secrets use the same Shared Key ID? Or should they use different?

[gloinul]

Should the client and server endpoint shared secrets use the same Shared Key ID? Or should they use different?

I don't think with RFC 4895 and the SCTP-API for it in RFC 6458 that you can have per direction different keys while using only one key-ID. To my understanding one will have to deploy two shared keys from each DTLS connection, intending to use one Key-ID per direction. I think the easiest algorithm is to have the SCTP association use odd number key-ID as there active sending key, and even number as the SCTP association server sending direction. That should be compatible with these specs. However, final wording need to ensure that the roles are watertight in face of simultaneous open of the SCTP association.

[gloinul]

Actually the requirement is a bit different for this "Require that no more than 2^32 DATA chunks are sent over a single DTLS connection". I think to be secure the requirement is:

Senders MUST retire the shared key before 2^32 DATA chunks have been sent since the first SCTP-AUTH protected packet with that key, i.e. before the TSN turns over the shared key that was previously used must no longer be valid to be received when any TSN number protected by that key would be accepted by the SCTP receiver.

[emanjon]

Actually the requirement is a bit different for this "Require that no more than 2^32 DATA chunks are sent over a single DTLS connection". I think to be secure the requirement is:

Senders MUST retire the shared key before 2^32 DATA chunks have been sent since the first SCTP-AUTH protected packet with that key, i.e. before the TSN turns over the shared key that was previously used must no longer be valid to be received when any TSN number protected by that key would be accepted by the SCTP receiver.

I changed my original text quite a lot before reading this. The current formulation talks about TSN as there can also be I-DATA chunks. Can you check the new formulation?

[emanjon]

   DTLS/SCTP does not provide replay protection for authenticated control
   chunks such as ERROR, RE-CONFIG, or SACK when sent in a SCTP packet
   without DATA or I-DATA chunks. Such replay could disrupt the SCTP association
   and could therefore be a denial-of-service attack. To prevent such attacks
   on availability it is RECOMMENDED to send control chunks in SCTP packets that
   also contains DATA or I-DATA chunks. Note that DATA or I-DATA chunks MAY contain
   zero bytes of user data.

Is this good enough? Can we enforce something stronger? Could we mandate DATA chunks for everything except the init and shutdown chunks? Do implementations support sending DATA chunks with zero length? I know that some TLS implementations dont support sending records with zero length even if it is allowed by the spec.

[emanjon]

Thinking more, just placing control chunks in the same packet as DATA does not help. SCTP-AUTH of course just authenticates everything and then SCTP process all of the chunks. Failure in a DATA chunk would not invalidate the ERROR chunk. Such behaivior would be a new processing step.

[emanjon]

To protect control chunks a sequence number for AUTH chunks is needed. Could be a AUTH2 chunk or it could be a new HMAC algorithm for AUTH that puts the sequence number in the HMAC field. We should analyze the impact of replayed control chunks.

[emanjon]

Should the indexes be

• 1 and 2 so that 65535 is never used?
• 2 and 3 so that 1 is never used?

[emanjon]

In addition to not being possible with the RFC 6458 API, directional keys are actually changing RFC 4895.

Receiving authenticated chunks

...

If the endpoint has at least one endpoint pair shared key for the peer,
it MUST use the key specified by the Shared Key Identifier if a key
has been configured for that Shared Key Identifier. 

[gloinul]

Leaving issue open until we have had some discussion in the WG if this mitigation is sufficient. But the draft to be releasted (-05) will have text on this.