Merge pull request #202 from gloinul/security_props

Added some text related to the immaturity towards replay attacks

.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

.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

.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].*"

.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

draft-ietf-tsvwg-dtls-over-sctp-bis.md

@@ -105,15 +105,15 @@ 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.
 
    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
@@ -136,18 +136,20 @@ normative:
    Transmission Protocol (SCTP), as defined in {{RFC9260}} with
    Authenticated Chunks for SCTP (SCTP-AUTH) {{RFC4895}}.
 
-   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
+   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
    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:
@@ -177,6 +179,34 @@ 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 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:
+
+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
+
+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.
+
 ## Protocol Overview
 
 The DTLS/SCTP protection is defined as an SCTP adaptation layer
@@ -663,7 +693,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
@@ -694,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
 
@@ -1822,6 +1852,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