Script updating gh-pages from 2a219bd. [ci skip]

carsten-wglc-2/draft-ietf-core-groupcomm-bis.html

@@ -2633,7 +2633,7 @@ <h3 id="name-group-oscore-2">
         </h3>
 <p id="section-6.2-1">Group OSCORE provides end-to-end application-level security. This has many desirable properties, including maintaining security assurances while forwarding traffic through intermediaries (proxies). Application-level security also tends to more cleanly separate security from the specific dynamics of security group membership (e.g., the problem of distributing security keys across large groups with many members that come and go).<a href="#section-6.2-1" class="pilcrow">¶</a></p>
 <p id="section-6.2-2">CoAP group communication <span class="bcp14">MUST</span> be protected by using Group OSCORE as specified in <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, with the possible exception of specific, well-defined "unsecured steps" (see <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a>).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
-<p id="section-6.2-3">The security considerations from <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-24#section-13" class="relref">Section 13</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> hold for this specification.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
+<p id="section-6.2-3">The security considerations from <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-24#section-14" class="relref">Section 14</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> hold for this specification.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
 <div id="chap-security-considerations-sec-mode-key-mgmt">
 <section id="section-6.2.1">
           <h4 id="name-group-key-management">
@@ -2757,7 +2757,7 @@ <h3 id="name-replay-of-group-requests">
         </ul>
 <p id="section-6.4-3">It follows that, in either case, this replay attack would not accomplish anything on the client, although it does effectively target the servers in the group.<a href="#section-6.4-3" class="pilcrow">¶</a></p>
 <p id="section-6.4-4">If Group OSCORE is used, such a replay attack on the servers is prevented, since a client protects each different request with a different Sequence Number value, which is in turn included as Partial IV in the protected message and takes part in the construction of the AEAD cipher nonce. Thus, a server would be able to detect the replayed request, by checking the conveyed Partial IV against its own replay window in the OSCORE Recipient Context associated with the client.<a href="#section-6.4-4" class="pilcrow">¶</a></p>
-<p id="section-6.4-5">This requires a server to have a Replay Window that is in a valid state. If the server's Replay Window is initialized as invalid, e.g., due to a reboot, the server should use the challenge-response synchronization method based on the Echo Option for CoAP defined in <span>[<a href="#RFC9175" class="cite xref">RFC9175</a>]</span> as described in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-24#section-10" class="relref">Section 10</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, in order to make the Replay Window valid before resuming to accept incoming messages from other group members.<a href="#section-6.4-5" class="pilcrow">¶</a></p>
+<p id="section-6.4-5">This requires a server to have a Replay Window that is in a valid state. If the server's Replay Window is initialized as invalid, e.g., due to a reboot, the server should use the challenge-response synchronization method based on the Echo Option for CoAP defined in <span>[<a href="#RFC9175" class="cite xref">RFC9175</a>]</span> as described in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-24#section-9" class="relref">Section 9</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, in order to make the Replay Window valid before resuming to accept incoming messages from other group members.<a href="#section-6.4-5" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="use-of-coap-no-response-option">

carsten-wglc-2/draft-ietf-core-groupcomm-bis.txt

@@ -2351,7 +2351,7 @@ Table of Contents
    exception of specific, well-defined "unsecured steps" (see
    Section 4).
 
-   The security considerations from Section 13 of
+   The security considerations from Section 14 of
    [I-D.ietf-core-oscore-groupcomm] hold for this specification.
 
 6.2.1.  Group Key Management
@@ -2666,7 +2666,7 @@ Table of Contents
    state.  If the server's Replay Window is initialized as invalid,
    e.g., due to a reboot, the server should use the challenge-response
    synchronization method based on the Echo Option for CoAP defined in
-   [RFC9175] as described in Section 10 of
+   [RFC9175] as described in Section 9 of
    [I-D.ietf-core-oscore-groupcomm], in order to make the Replay Window
    valid before resuming to accept incoming messages from other group
    members.