Script updating gh-pages from 8197da1. [ci skip]

john-comments/draft-ietf-core-groupcomm-bis.html

@@ -2547,7 +2547,7 @@ <h3 id="name-group-oscore">
 <p id="section-5.1-3">OSCORE makes it possible to selectively protect different parts of a CoAP message in different ways, while still allowing intermediaries (e.g., CoAP proxies) to perform their intended functionalities. That is, some message parts are encrypted and integrity protected; other parts are only integrity protected to be accessible to, but not modifiable by, proxies; and some parts are kept as plain content to be both accessible to and modifiable by proxies. Such differences especially concern the CoAP options included in the unprotected message.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
 <p id="section-5.1-4">Group OSCORE <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> builds on OSCORE, and provides end-to-end security of CoAP messages exchanged between members of an OSCORE group, while fulfilling the same security requirements.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
 <p id="section-5.1-5">In particular, Group OSCORE protects CoAP group requests sent by a CoAP client, e.g., over UDP/IP multicast, as well as multiple corresponding CoAP responses sent as (IP) unicast by different CoAP servers. However, the same security material can also be used to protect CoAP requests sent over (IP) unicast to a single CoAP server in the OSCORE group, as well as the corresponding responses.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
-<p id="section-5.1-6">Group OSCORE ensures source authentication of all messages exchanged within the OSCORE group, by means of two possible methods.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
+<p id="section-5.1-6">Group OSCORE ensures source authentication of all messages exchanged within the OSCORE group. That is, the recipient of a CoAP message protected with Group OSCORE is able to securely verify whether the CoAP endpoint that has generated and sent the message is indeed the alleged one. This is achieved by means of two possible methods.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
 <p id="section-5.1-7">The first method, called group mode, relies on digital signatures. That is, sender devices sign their outgoing messages using their own private key, and embed the signature in the protected CoAP message.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
 <p id="section-5.1-8">The second method, called pairwise mode, relies on a symmetric key, which is derived from a pairwise shared secret computed from the asymmetric keys of the message sender and recipient. This method is intended for one-to-one messages sent in the security group, such as all responses individually sent by servers, as well as requests addressed to an individual server.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
 <p id="section-5.1-9">A Group Manager is responsible for managing one or multiple OSCORE groups. In particular, the Group Manager acts as repository of the security group members' authentication credentials including the corresponding public keys; manages, renews, and provides security material in the security group; and handles the join process of new members in the security group.<a href="#section-5.1-9" class="pilcrow">¶</a></p>
@@ -2663,7 +2663,8 @@ <h4 id="name-source-authentication">
           </h4>
 <p id="section-6.2.2-1">Both the group mode and the pairwise mode of Group OSCORE ensure source authentication of messages exchanged by CoAP endpoints through CoAP group communication.<a href="#section-6.2.2-1" class="pilcrow">¶</a></p>
 <p id="section-6.2.2-2">To this end, outgoing messages are either signed by the message sender endpoint with its own private key (group mode), or protected with a symmetric key, which is in turn derived using the asymmetric keys of the message sender and recipient (pairwise mode).<a href="#section-6.2.2-2" class="pilcrow">¶</a></p>
-<p id="section-6.2.2-3">Thus, both modes allow a recipient CoAP endpoint to verify that a message has actually been originated by a specific and identified member of the OSCORE group.<a href="#section-6.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-6.2.2-3">Thus, both modes allow a recipient CoAP endpoint to verify that a message has actually been originated and sent by a specific and identified CoAP endpoint as a member of the OSCORE group.<a href="#section-6.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-6.2.2-4">Note that Group OSCORE does not protect the addressing information about the CoAP endpoint that has sent the message, e.g., the source IP address and port number used when sending the message. Therefore, Group OSCORE does not provide authentication of such source addressing information.<a href="#section-6.2.2-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="chap-security-considerations-sec-mode-attacks">
@@ -2677,7 +2678,7 @@ <h4 id="name-countering-attacks">
               <p id="section-6.2.3-2.1.1">Since Group OSCORE provides end-to-end confidentiality and integrity of request/response messages, proxies capable of group communication cannot break message protection, and thus cannot act as man-in-the-middle beyond their legitimate duties (see <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11.2" class="relref">Section 11.2</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>). In fact, intermediaries such as proxies are not assumed to have access to the OSCORE Security Context used by OSCORE group members. Also, with the notable addition of signatures for the group mode, Group OSCORE protects messages using the same procedure as OSCORE (see Sections <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-8" class="relref">8</a> and <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-9" class="relref">9</a> of <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>), and especially processes CoAP options according to the same classification in U/I/E classes.<a href="#section-6.2.3-2.1.1" class="pilcrow">¶</a></p>
 </li>
             <li class="normal" id="section-6.2.3-2.2">
-              <p id="section-6.2.3-2.2.1">Group OSCORE limits the feasibility and impact of amplification attacks (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a> of this document and <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11.3" class="relref">Section 11.3</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>), thanks to the handling of protected group requests on the server side. That is, upon receiving a group request protected with Group OSCORE, a server verifies whether the request is not a replay, and whether it originates from the alleged sender in the OSCORE group.<a href="#section-6.2.3-2.2.1" class="pilcrow">¶</a></p>
+              <p id="section-6.2.3-2.2.1">Group OSCORE limits the feasibility and impact of amplification attacks (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a> of this document and <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11.3" class="relref">Section 11.3</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>), thanks to the handling of protected group requests on the server side. That is, upon receiving a group request protected with Group OSCORE, a server verifies whether the request is not a replay, and whether it has been originated and sent by the alleged CoAP endpoint in the OSCORE group.<a href="#section-6.2.3-2.2.1" class="pilcrow">¶</a></p>
 <p id="section-6.2.3-2.2.2">
 In order to perform the latter check of source authentication, the server either: i) verifies the signature included in the request by using the public key of the client, when the request is protected using the group mode (see <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-8.2" class="relref">Section 8.2</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>); or ii) decrypts and verifies the request by means of an additionally derived pairwise key associated with the client, when the request is protected using the pairwise mode (see <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-9.4" class="relref">Section 9.4</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>).<a href="#section-6.2.3-2.2.2" class="pilcrow">¶</a></p>
 <p id="section-6.2.3-2.2.3">
@@ -2687,12 +2688,14 @@ <h4 id="name-countering-attacks">
 <p id="section-6.2.3-2.2.5">
 Furthermore, the adversary needs to consider a group request that specifically targets a resource for which the CoAP servers are configured to respond. While this can be often correctly inferable from the application context, it is not explicit from the group request itself, since Group OSCORE protects the Uri-Path and Uri-Query CoAP Options conveying the respective components of the target URI.<a href="#section-6.2.3-2.2.5" class="pilcrow">¶</a></p>
 <p id="section-6.2.3-2.2.6">
-As a further mitigation against amplification attacks, a server can also rely on the Echo Option for CoAP defined in <span>[<a href="#RFC9175" class="cite xref">RFC9175</a>]</span> and include it in a response to a group request. By doing so, the server can assert that the alleged sender of the group request (i.e., the CoAP client associated with a certain authentication credential including the corresponding public key) is indeed reachable at the claimed source address, especially if this differs from the one used in previous group requests from the same (authenticated) device. Although responses including the Echo Option do still result in amplification, this is limited in volume compared to when all servers reply with a full response.<a href="#section-6.2.3-2.2.6" class="pilcrow">¶</a></p>
+As a further mitigation against amplification attacks, a server can also rely on the Echo Option for CoAP defined in <span>[<a href="#RFC9175" class="cite xref">RFC9175</a>]</span> and include it in a response to a group request. By doing so, the server can assert that the alleged sender of the group request (i.e., the CoAP client associated with a certain authentication credential including the corresponding public key) is indeed reachable at the claimed source address of the group request, especially if such an address differs from the one used in previous group requests from the same (authenticated) device. Although responses including the Echo Option do still result in amplification, this is limited in volume compared to when all servers reply with a full response.<a href="#section-6.2.3-2.2.6" class="pilcrow">¶</a></p>
+<p id="section-6.2.3-2.2.7">
+Using the Echo Option does not provide authentication of source addressing information about the sender of a CoAP message. Also, using the Echo Option in itself does not provide source authentication of exchanged messages, which is achieved by means of Group OSCORE (see <a href="#chap-security-considerations-sec-mode-sauth" class="auto internal xref">Section 6.2.2</a>). Using the Echo Option together with Group OSCORE allows a CoAP server in the OSCORE group to assert the freshness of CoAP requests received from other members in the group.<a href="#section-6.2.3-2.2.7" class="pilcrow">¶</a></p>
 </li>
             <li class="normal" id="section-6.2.3-2.3">
-              <p id="section-6.2.3-2.3.1">Group OSCORE limits the impact of attacks based on IP spoofing over IP multicast (see <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11.4" class="relref">Section 11.4</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>). In fact, requests and corresponding responses sent in the OSCORE group can be correctly generated only by legitimate members of the group.<a href="#section-6.2.3-2.3.1" class="pilcrow">¶</a></p>
+              <p id="section-6.2.3-2.3.1">Group OSCORE limits the impact of attacks based on IP spoofing over IP multicast (see <span><a href="https://rfc-editor.org/rfc/rfc7252#section-11.4" class="relref">Section 11.4</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>). In fact, requests and corresponding responses sent in the OSCORE group can be correctly generated only by CoAP endpoints that are legitimate members of the group.<a href="#section-6.2.3-2.3.1" class="pilcrow">¶</a></p>
 <p id="section-6.2.3-2.3.2">
-Within an OSCORE group, the shared symmetric-key security material strictly provides only group-level authentication. However, source authentication of messages is also ensured, both in the group mode by means of signatures (see Sections <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-8.1" class="relref">8.1</a> and <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-8.3" class="relref">8.3</a> of <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>), and in the pairwise mode by using additionally derived pairwise keys (see Sections <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-9.3" class="relref">9.3</a> and <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-9.5" class="relref">9.5</a> of <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>). Thus, recipient endpoints can verify a message to be originated by the alleged, identifiable sender in the OSCORE group.<a href="#section-6.2.3-2.3.2" class="pilcrow">¶</a></p>
+Within an OSCORE group, the shared symmetric-key security material strictly provides only group-level authentication. However, source authentication of messages is also ensured, both in the group mode by means of signatures (see Sections <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-8.1" class="relref">8.1</a> and <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-8.3" class="relref">8.3</a> of <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>), and in the pairwise mode by using additionally derived pairwise keys (see Sections <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-9.3" class="relref">9.3</a> and <a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-9.5" class="relref">9.5</a> of <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>). Thus, recipient endpoints can verify a message to have been originated and sent by the alleged, identifiable CoAP endpoint in the OSCORE group.<a href="#section-6.2.3-2.3.2" class="pilcrow">¶</a></p>
 <p id="section-6.2.3-2.3.3">
 As noted above, the server may additionally rely on the Echo Option for CoAP defined in <span>[<a href="#RFC9175" class="cite xref">RFC9175</a>]</span>, in order to verify the aliveness and reachability of the client sending a request from a particular IP address.<a href="#section-6.2.3-2.3.3" class="pilcrow">¶</a></p>
 </li>
@@ -2720,7 +2723,7 @@ <h3 id="name-risk-of-amplification">
             <p id="section-6.3-4.1.1">SHOULD limit the support for CoAP group requests only to the group resources of the application group(s) using that CoAP group;<a href="#section-6.3-4.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-6.3-4.2">
-            <p id="section-6.3-4.2.1">SHOULD NOT accept group requests that cannot be authenticated in some way;<a href="#section-6.3-4.2.1" class="pilcrow">¶</a></p>
+            <p id="section-6.3-4.2.1">SHOULD NOT accept group requests that cannot be authenticated in some way, i.e., for which it is not possible to securely assert that they have been originated and sent by the alleged, identifiable CoAP endpoint in the OSCORE group;<a href="#section-6.3-4.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-6.3-4.3">
             <p id="section-6.3-4.3.1">SHOULD NOT provide large amplification factors through its responses to a non-authenticated group request, possibly employing CoAP block-wise transfers <span>[<a href="#RFC7959" class="cite xref">RFC7959</a>]</span> to reduce the amount of amplification.<a href="#section-6.3-4.3.1" class="pilcrow">¶</a></p>
@@ -3868,7 +3871,10 @@ <h3 id="name-version-09-to-10">
             <p id="appendix-E.1-1.7.1">Further stressed that group communication ought to be secured.<a href="#appendix-E.1-1.7.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.8">
-            <p id="appendix-E.1-1.8.1">Editorial fixes and improvements.<a href="#appendix-E.1-1.8.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.8.1">Clarification on source authentication, source addresses, and Echo Option.<a href="#appendix-E.1-1.8.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-E.1-1.9">
+            <p id="appendix-E.1-1.9.1">Editorial fixes and improvements.<a href="#appendix-E.1-1.9.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>