Skip to content

Commit

Permalink
Various changes to correct formulations.
Browse files Browse the repository at this point in the history
  • Loading branch information
@gloinul
gloinul committed Oct 23, 2023
1 parent 153cdf7 commit 2927f89
Showing 1 changed file with 44 additions and 36 deletions.
80 changes: 44 additions & 36 deletions draft-ietf-tsvwg-dtls-over-sctp-bis.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -132,13 +132,13 @@ normative:

This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol, as defined in DTLS 1.2 {{RFC6347}}, and
DTLS 1.3 {{RFC9147}}, over the Stream Control
Transmission Protocol (SCTP), as defined in {{RFC9260}} with
Authenticated Chunks for SCTP (SCTP-AUTH) {{RFC4895}}.
DTLS 1.3 {{RFC9147}}, over the Stream Control Transmission Protocol
(SCTP), as defined in {{RFC9260}} combined with Authenticated
Chunks for SCTP (SCTP-AUTH) {{RFC4895}}.

Once the assumptions are fulfilled (see {{Assumptions}}), this
specification provides mutual authentication of endpoints, data
confidentiality, data origin authentication, data integrity
Once the SCTP-AUTH assumptions are fulfilled (see {{Assumptions}}),
this specification provides mutual authentication of endpoints,
data confidentiality, data origin authentication, data integrity
protection, and a certain level of data replay protection of user
messages for applications that use SCTP as their transport protocol
(see in this regard what stated in {{replay_issues}}). Thus, it
Expand Down Expand Up @@ -179,15 +179,16 @@ normative:
limitations have been defined such that STARTTLS as specified in
{{RFC3788}} is no longer supported.

## Assumptions {#Assumptions}
## SCTP-AUTH Assumptions {#Assumptions}

In this document it is assumed that SCTP-AUTH is provided with
periodic rekeying by periodic usage the mechanism for DTLS rekeying
and re-authentication defined in this document. It is also assumed
that SCTP-AUTH specification {{RFC4895}} has been updated to address
most of the issues.
most of the known issues.

The current rfc4895 has been identified as weak in the following parts:
SCTP-AUTH as defined by RFC4895 has been identified as weak in the
following parts:

1. Reflection of authenticated data chunks

Expand All @@ -203,9 +204,10 @@ We are expecting the SCTP-AUTH update to fully address issue 1, 3 and
4. Issue 2 will be partially addressed in this specification through
periodic rekeying to prevent replay to inject data and affect
availability, but that is based on SCTP implementation correctly
handling replayed packets. SCTP-AUTH issues mitigated and having a
periodic rekeying is a condicio sine qua non (indispensable condition)
for this document to provide a working solution.
handling replayed or duplicated packets. SCTP-AUTH issues mitigated
and having a periodic rekeying is a condicio sine qua non
(indispensable condition) for this document to provide a working
solution.

## Protocol Overview

Expand Down Expand Up @@ -393,7 +395,7 @@ discarded.
* Mandates that more modern DTLS version are used (DTLS 1.2 or
1.3)

* Mandates support of modern HMAC algorithm (SHA-256) in the SCTP
* Mandates support of stronger HMAC algorithm (SHA-256) in the SCTP
authentication extension {{RFC4895}}.

* Recommends support of {{RFC8260}} to enable interleaving of large
Expand All @@ -407,8 +409,9 @@ discarded.

* Requires support of partial delivery of user messages.

* Derives direction specific SCTP-AUTH keys to mitigate reflection
attacks.
* Requires an updates SCTP-AUTH specification to mitigate packet
reflection attacks that can impact the SCTP association
availability.

* Mandates SCTP-AUTH rekeying before the TSN cycles back to the
Initial TSN to mitigate replay of data chunks.
Expand All @@ -431,7 +434,7 @@ discarded.
key updates. The number of key updates is limited to
2<sup>48</sup>.

* Strict AEAD significantly limits on how much many packets can be
* Strict AEAD significantly limits on how many DTLS records can be
sent before rekeying.

Many applications using DTLS/SCTP are of semi-permanent nature.
Expand Down Expand Up @@ -911,8 +914,8 @@ discarded.
own SCTP user messages with in order delivery. That mimics the RFC
6083 behavior without impacting the ULP. However, it assumes that
there are available streams to be used based on the SCTP
association handshake allowed streams (Section 5.1.1 of
{{RFC9260}}).
association handshake parameter for "maximum inbound streams"
(Section 5.1.1 of {{RFC9260}}).

## Chunk Handling

Expand Down Expand Up @@ -985,9 +988,9 @@ discarded.
required to ensure that the receiver can correctly identify the
DTLS connection and its security context when performing its
de-protection operations. There is also only a single SCTP-AUTH key
exported per DTLS connection ensuring that there is clear mapping
between the DTLS connection ID and the SCTP-AUTH security context for
each Key Identifier.
exported per DTLS connection and transmission direction ensuring
that there is clear mapping between the DTLS connection ID and the
SCTP-AUTH security context for each Key Identifier.

Application writers should be aware that establishing a new DTLS
connection may result in changes of security parameters. See
Expand Down Expand Up @@ -1036,8 +1039,8 @@ discarded.
The DTLS/SCTP endpoint timely indicates to its peer when the
previous DTLS connection and its context are no longer needed for
receiving any more data from this endpoint. This is done by sending
a DTLS/SCTP Control Message {{Control-Message}} of type
"Ready_To_Close" {{Ready_To_Close}} to its peer. The endpoint MUST
a DTLS/SCTP Control Message ({{Control-Message}}) of type
"Ready_To_Close" ({{Ready_To_Close}}) to its peer. The endpoint MUST
NOT send the Ready_To_Close until the following two conditions are
fulfilled:

Expand Down Expand Up @@ -1078,7 +1081,7 @@ discarded.
initiated before the change of security context, it will be forced to
track the SCTP messages and determine when all using the old
security context has been transmitted. This maybe be impossible to
do as completely reliable without tighter integration between the
do completely reliable without tighter integration between the
DTLS/SCTP layer and the SCTP implementation. This type of
implementations also has an implicit limitation in how large SCTP
messages it can support. Each SCTP message needs to have completed
Expand All @@ -1095,6 +1098,10 @@ discarded.

## Handling of Endpoint Pair Shared Secrets {#handling-endpoint-secret}

Editor's Note: Assuming that RFC 4895 is updates to address the
security issues this section is expected to be able to be updated
to not require generating two different keys.

SCTP-AUTH {{RFC4895}} is keyed using endpoint pair shared
secrets. In DTLS/SCTP, DTLS is used to establish these secrets.
The endpoint pair shared secrets MUST be provided to the SCTP stack
Expand All @@ -1113,10 +1120,10 @@ discarded.
"EXPORTER-DTLS-OVER-SCTP-SERVER-WRITE" with no terminating NUL, no
context, and length 64.

~~~~~~~~~~~
TLS-Exporter("EXPORTER-DTLS-OVER-SCTP-CLIENT-WRITE", , 64)
TLS-Exporter("EXPORTER-DTLS-OVER-SCTP-SERVER-WRITE", , 64)
~~~~~~~~~~~
~~~~~~~~~~~
TLS-Exporter("EXPORTER-DTLS-OVER-SCTP-CLIENT-WRITE", , 64)
TLS-Exporter("EXPORTER-DTLS-OVER-SCTP-SERVER-WRITE", , 64)
~~~~~~~~~~~

Keys derived with the label "EXPORTER-DTLS-OVER-SCTP-CLIENT-WRITE"
always have an even Shared Key Identifier. They are used by the
Expand Down Expand Up @@ -1285,13 +1292,14 @@ discarded.
and additional decryption overhead due to trial decoding and will
be left for future extension.

So, what size of SCTP receiver window this limitation corresponds to
is highly dependent on the SCTP user message size. If all SCTP user
messages are large, e.g., 1 MB, then most DTLS Records will be close
to maximum DTLS record size. Thus, the SCTP receiver window size
required before this becomes an issue becomes fairly close to 49152
times 16384, i.e., approximately 800 MB. While SCTP user messages of
100 bytes would only need a receiver window of approximately 5 MB.
So, what size of SCTP receiver window this limitation corresponds
to is highly dependent on the SCTP user message size. If all SCTP
user messages are large, e.g., 1 MB, then most DTLS Records will be
close to maximum DTLS record size. Thus, the SCTP receiver window
size required before this becomes an issue becomes fairly close to
49152 times 16384, i.e., approximately 800 MB. While SCTP user
messages of almost exclusively 100 bytes would only need a receiver
window of approximately 5 MB.

### SCTP API Limitations

Expand Down Expand Up @@ -1714,7 +1722,7 @@ given to this specification.
with such long lifetimes there is a need to frequently
re-authenticate both client and server. TLS Certificate lifetimes
significantly shorter than a year are common which is shorter than
many expected DTLS/SCTP associations.
expected to be used DTLS/SCTP associations lifetimes.

SCTP-AUTH re-rekeying, periodic authentication of both endpoints,
and frequent re-run of Diffie-Hellman to force attackers to dynamic
Expand Down

0 comments on commit 2927f89

Please sign in to comment.