From 6960a4c7389b963d558e205761ca31aca1b2dd90 Mon Sep 17 00:00:00 2001 From: Claudio-Sjo Date: Thu, 12 Oct 2023 13:18:03 +0200 Subject: [PATCH 1/8] Added some text related to the immaturity towards replay attacks --- draft-ietf-tsvwg-dtls-over-sctp-bis.md | 49 +++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 4 deletions(-) diff --git a/draft-ietf-tsvwg-dtls-over-sctp-bis.md b/draft-ietf-tsvwg-dtls-over-sctp-bis.md index 09e050c..0fe310d 100644 --- a/draft-ietf-tsvwg-dtls-over-sctp-bis.md +++ b/draft-ietf-tsvwg-dtls-over-sctp-bis.md @@ -136,10 +136,12 @@ normative: Transmission Protocol (SCTP), as defined in {{RFC9260}} with Authenticated Chunks for SCTP (SCTP-AUTH) {{RFC4895}}. - This specification provides mutual authentication of endpoints, + Once the assumptions are fulfilled (see {{Assumptions}}), + this specification provides mutual authentication of endpoints, data confidentiality, data origin authentication, data integrity - protection, and data replay protection of user messages for - applications that use SCTP as their transport protocol. Thus, it + 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 allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. DTLS/SCTP @@ -177,6 +179,27 @@ normative: limitations have been defined such that STARTTLS as specified in {{RFC3788}} is no longer supported. +## Assumptions {#Assumptions} + +In this document it is assumed that SCTP-AUTH provides periodic rekeying +it is also assumed that the rfc4895 has been reworked, that is all the security +related issues found so far are fixed. + +The current rfc4895 has been identified as weak in the following parts: + +1. Reflection of authenticated data chunks + +2. Replay of authenticated data chunks + +3. Single key used with different HMAC algorithms + +4. Reflection of authenticated control chunks + +5. Replay of authenticated control chunks + +Being SCTP-AUTH fixed and having a periodic rekeying is a condicio sine qua non +for this document to provide a working solution. + ## Protocol Overview The DTLS/SCTP protection is defined as an SCTP adaptation layer @@ -663,7 +686,7 @@ discarded. contention related to large user messages. -## Replay Protection +## Replay Protection {#replay_protection} SCTP-AUTH {{RFC4895}} does not have explicit replay protection. However, the combination of SCTP-AUTH's protection of @@ -1822,6 +1845,24 @@ given to this specification. information from DTLS/SCTP together with information gathered from other protocols increase the risk of identifying individual users. +## Replay attacks {#replay_issues} + +Replay attack breaks data origin authentication, data integrity +protection, and data confidentiality. The peculiar architecture +of rfc6083 makes hard to predict how a replay attack can get success. +What is clear is that replay attack hasn't been considered when +rfc6083 has been specified, making it weak from the beginning. +In rfc6083 the replay window is open during the lifetime of the +SCTP-AUTH key validity and being TSN visible it's relatively +easy to inject an old Data Chunk that passes validation. +Since DTLS replay protection is not used and because a single +chunk is also a single DTLS record, the attack surface of rfc6083 +is large and even if SCTP-AUTH will be fixed in regards to +replay attack, the combination of SCTP-AUTH and DTLS as described +in rfc6083 is not by architecture. + +Details are described in {{replay_protection}} + # Contributors Michael Tüxen contributed as co-author to the initial versions From 194ed05b906acd602e75d90e89de9c083e302b3a Mon Sep 17 00:00:00 2001 From: Magnus Westerlund Date: Mon, 16 Oct 2023 15:52:18 +0200 Subject: [PATCH 2/8] Automatic update of .github/workflows/ghpages.yml --- .github/workflows/ghpages.yml | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/.github/workflows/ghpages.yml b/.github/workflows/ghpages.yml index 118cb52..a26b9db 100644 --- a/.github/workflows/ghpages.yml +++ b/.github/workflows/ghpages.yml @@ -20,25 +20,23 @@ jobs: runs-on: ubuntu-latest steps: - name: "Checkout" - uses: actions/checkout@v2 + uses: actions/checkout@v3 - - name: "Cache Setup" - id: cache-setup - run: | - mkdir -p "$HOME"/.cache/xml2rfc - echo "::set-output name=path::$HOME/.cache/xml2rfc" - date -u "+::set-output name=date::%FT%T" + - name: "Setup" + id: setup + run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" - - name: "Cache References" - uses: actions/cache@v2 + - name: "Caching" + uses: actions/cache@v3 with: path: | - ${{ steps.cache-setup.outputs.path }} + .refcache + .venv + .gems + node_modules .targets.mk - key: refcache-${{ steps.cache-setup.outputs.date }} - restore-keys: | - refcache-${{ steps.cache-setup.outputs.date }} - refcache- + key: i-d-${{ steps.setup.outputs.date }} + restore-keys: i-d- - name: "Build Drafts" uses: martinthomson/i-d-template@v1 @@ -53,7 +51,7 @@ jobs: token: ${{ github.token }} - name: "Archive Built Drafts" - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: path: | draft-*.html From e7be789a9c1fd097daca3872a426572155387edb Mon Sep 17 00:00:00 2001 From: Magnus Westerlund Date: Mon, 16 Oct 2023 15:52:19 +0200 Subject: [PATCH 3/8] Automatic update of .github/workflows/publish.yml --- .github/workflows/publish.yml | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml index dd94df9..8e01218 100644 --- a/.github/workflows/publish.yml +++ b/.github/workflows/publish.yml @@ -11,29 +11,27 @@ jobs: runs-on: ubuntu-latest steps: - name: "Checkout" - uses: actions/checkout@v2 + uses: actions/checkout@v3 # See https://github.com/actions/checkout/issues/290 - name: "Get Tag Annotations" run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} - - name: "Cache Setup" - id: cache-setup - run: | - mkdir -p "$HOME"/.cache/xml2rfc - echo "::set-output name=path::$HOME/.cache/xml2rfc" - date -u "+::set-output name=date::%FT%T" + - name: "Setup" + id: setup + run: date -u "+date=%FT%T" >>"$GITHUB_OUTPUT" - - name: "Cache References" - uses: actions/cache@v2 + - name: "Caching" + uses: actions/cache@v3 with: path: | - ${{ steps.cache-setup.outputs.path }} + .refcache + .venv + .gems + node_modules .targets.mk - key: refcache-${{ steps.date.outputs.date }} - restore-keys: | - refcache-${{ steps.date.outputs.date }} - refcache- + key: i-d-${{ steps.setup.outputs.date }} + restore-keys: i-d- - name: "Build Drafts" uses: martinthomson/i-d-template@v1 @@ -46,6 +44,6 @@ jobs: make: upload - name: "Archive Submitted Drafts" - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: - path: "draft-*-[0-9][0-9].xml" + path: "versioned/draft-*-[0-9][0-9].*" From fc00ab60ce6c1305e28bef78a679cae8b869a115 Mon Sep 17 00:00:00 2001 From: Magnus Westerlund Date: Mon, 16 Oct 2023 15:52:19 +0200 Subject: [PATCH 4/8] Automatic update of .github/workflows/archive.yml --- .github/workflows/archive.yml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/.github/workflows/archive.yml b/.github/workflows/archive.yml index bfad094..605b642 100644 --- a/.github/workflows/archive.yml +++ b/.github/workflows/archive.yml @@ -6,6 +6,11 @@ on: repository_dispatch: types: [archive] workflow_dispatch: + inputs: + archive_full: + description: 'Recreate the archive from scratch' + default: false + type: boolean jobs: build: @@ -15,8 +20,12 @@ jobs: - name: "Checkout" uses: actions/checkout@v2 + # Note: No caching for this build! + - name: "Update Archive" uses: martinthomson/i-d-template@v1 + env: + ARCHIVE_FULL: ${{ inputs.archive_full }} with: make: archive token: ${{ github.token }} @@ -28,6 +37,6 @@ jobs: token: ${{ github.token }} - name: "Save Archive" - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: path: archive.json From a0dcf3f850f18a82f0f76a9aec655dbdd26d03eb Mon Sep 17 00:00:00 2001 From: Magnus Westerlund Date: Mon, 16 Oct 2023 15:52:20 +0200 Subject: [PATCH 5/8] Automatic update of .github/workflows/update.yml --- .github/workflows/update.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/update.yml b/.github/workflows/update.yml index 79a3ca5..7a67007 100644 --- a/.github/workflows/update.yml +++ b/.github/workflows/update.yml @@ -1,4 +1,4 @@ -name: "Update generated files" +name: "Update Generated Files" # This rule is not run automatically. # It can be run manually to update all of the files that are part # of the template, specifically: @@ -20,13 +20,13 @@ on: workflow_dispatch jobs: build: - name: "Update files" + name: "Update Files" runs-on: ubuntu-latest steps: - name: "Checkout" uses: actions/checkout@v2 - - name: "Update generated files" + - name: "Update Generated Files" uses: martinthomson/i-d-template@v1 with: make: update-files From 4a3691926a40a82aec695769a7d71afb5624447c Mon Sep 17 00:00:00 2001 From: Magnus Westerlund Date: Mon, 16 Oct 2023 15:52:20 +0200 Subject: [PATCH 6/8] Remove old README.md --- README.md | 30 ------------------------------ 1 file changed, 30 deletions(-) delete mode 100644 README.md diff --git a/README.md b/README.md deleted file mode 100644 index ceb3390..0000000 --- a/README.md +++ /dev/null @@ -1,30 +0,0 @@ -# Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP) - -This is the working area for the IETF [TSVWG Working Group](https://datatracker.ietf.org/wg/tsvwg/documents/) Internet-Draft, "Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP)". - -* [Editor's Copy](https://gloinul.github.io/draft-westerlund-tsvwg-dtls-over-sctp-bis/#go.draft-ietf-tsvwg-dtls-over-sctp-bis.html) -* [Datatracker Page](https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis) -* [Working Group Draft](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-dtls-over-sctp-bis) -* [Compare Editor's Copy to Working Group Draft](https://gloinul.github.io/draft-westerlund-tsvwg-dtls-over-sctp-bis/#go.draft-ietf-tsvwg-dtls-over-sctp-bis.diff) - - -## Contributing - -See the -[guidelines for contributions](https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis/blob/main/CONTRIBUTING.md). - -Contributions can be made by creating pull requests. -The GitHub interface supports creating pull requests using the Edit (✏) button. - - -## Command Line Usage - -Formatted text and HTML versions of the draft can be built using `make`. - -```sh -$ make -``` - -Command line usage requires that you have the necessary software installed. See -[the instructions](https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md). - From 85bd93ea60edc0d2aceedc9a59b58bd8cefa29ce Mon Sep 17 00:00:00 2001 From: Magnus Westerlund Date: Mon, 16 Oct 2023 16:58:00 +0200 Subject: [PATCH 7/8] Updated text on SCTP-AUTH update and replay. --- draft-ietf-tsvwg-dtls-over-sctp-bis.md | 63 ++++++++++++++------------ 1 file changed, 35 insertions(+), 28 deletions(-) diff --git a/draft-ietf-tsvwg-dtls-over-sctp-bis.md b/draft-ietf-tsvwg-dtls-over-sctp-bis.md index 0fe310d..701217b 100644 --- a/draft-ietf-tsvwg-dtls-over-sctp-bis.md +++ b/draft-ietf-tsvwg-dtls-over-sctp-bis.md @@ -105,8 +105,8 @@ normative: alternative to the existing RFC 6083. DTLS over SCTP provides mutual authentication, confidentiality, - integrity protection, and replay protection for applications that - use SCTP as their transport protocol and allows client/server + integrity protection, and partial replay protection for applications + that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. @@ -136,20 +136,20 @@ normative: Transmission Protocol (SCTP), as defined in {{RFC9260}} 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 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 + messages for applications that use SCTP as their transport protocol + (see in this regard what stated in {{replay_issues}}). Thus, it allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. DTLS/SCTP uses DTLS for mutual authentication, key exchange with forward secrecy for SCTP-AUTH, and confidentiality of user messages. DTLS/SCTP use SCTP and SCTP-AUTH for integrity protection - and replay protection of all SCTP Chunks that can be authenticated, - including user messages. + and partial replay protection of all SCTP Chunks that can be + authenticated, including user messages. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. DTLS/SCTP supports: @@ -181,9 +181,11 @@ normative: ## Assumptions {#Assumptions} -In this document it is assumed that SCTP-AUTH provides periodic rekeying -it is also assumed that the rfc4895 has been reworked, that is all the security -related issues found so far are fixed. +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. The current rfc4895 has been identified as weak in the following parts: @@ -197,7 +199,12 @@ The current rfc4895 has been identified as weak in the following parts: 5. Replay of authenticated control chunks -Being SCTP-AUTH fixed and having a periodic rekeying is a condicio sine qua non +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 +suppressing 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. ## Protocol Overview @@ -717,8 +724,8 @@ discarded. DTLS optionally supports record replay detection. Such replay detection could result in the DTLS layer dropping valid messages received outside of the DTLS replay window. As DTLS/SCTP provides - replay protection even without DTLS replay protection, the replay - detection of DTLS MUST NOT be used. + the necessary replay protection even without DTLS replay + protection, the replay detection of DTLS MUST NOT be used. ## Path MTU Discovery @@ -1847,19 +1854,19 @@ given to this specification. ## Replay attacks {#replay_issues} -Replay attack breaks data origin authentication, data integrity -protection, and data confidentiality. The peculiar architecture -of rfc6083 makes hard to predict how a replay attack can get success. -What is clear is that replay attack hasn't been considered when -rfc6083 has been specified, making it weak from the beginning. -In rfc6083 the replay window is open during the lifetime of the -SCTP-AUTH key validity and being TSN visible it's relatively -easy to inject an old Data Chunk that passes validation. -Since DTLS replay protection is not used and because a single -chunk is also a single DTLS record, the attack surface of rfc6083 -is large and even if SCTP-AUTH will be fixed in regards to -replay attack, the combination of SCTP-AUTH and DTLS as described -in rfc6083 is not by architecture. + Replay attack breaks data origin authentication, data integrity + protection, and data confidentiality. The peculiar architecture of + rfc6083 makes hard to predict how a replay attack can get success. + What is clear is that replay attack hasn't been considered when + rfc6083 has been specified, making it weak from the beginning. In + rfc6083 the replay window is open during the lifetime of the + SCTP-AUTH key validity and being TSN visible it's relatively easy + to inject an old Data Chunk that passes validation. Since DTLS + replay protection is not used and because a single chunk is also a + single DTLS record, the attack surface of rfc6083 is large and even + if SCTP-AUTH will be fixed in regards to replay attack, the + combination of SCTP-AUTH and DTLS as described in rfc6083 is not by + architecture. Details are described in {{replay_protection}} From 47f938e1826065450d7b03019d0ae33aee6e1778 Mon Sep 17 00:00:00 2001 From: Magnus Westerlund Date: Tue, 17 Oct 2023 13:29:14 +0200 Subject: [PATCH 8/8] Minor editorial changes. --- draft-ietf-tsvwg-dtls-over-sctp-bis.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-tsvwg-dtls-over-sctp-bis.md b/draft-ietf-tsvwg-dtls-over-sctp-bis.md index 701217b..37ef87c 100644 --- a/draft-ietf-tsvwg-dtls-over-sctp-bis.md +++ b/draft-ietf-tsvwg-dtls-over-sctp-bis.md @@ -113,7 +113,7 @@ normative: Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. This document is an - improved alternative to RFC 6083 and removes the 16 kB limitation + improved alternative to RFC 6083 and removes the 16 kbytes limitation on protected user message size by defining a secure user message fragmentation so that multiple DTLS records can be used to protect a single user message. It further contains a large number of @@ -203,7 +203,7 @@ 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 -suppressing replayed packets. SCTP-AUTH issues mitigated and having a +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.